From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 23:41:47 2005 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 XAA23058 for ; Tue, 31 May 2005 23:41:46 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOY608XWPQ977S8B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 13:41:34 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C4F0580006; Wed, 01 Jun 2005 13:41:07 +1000 (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 570FC3C003; Wed, 01 Jun 2005 13:41:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j513du514615 for dna-list; Wed, 01 Jun 2005 13:39:56 +1000 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 j513dur14611 for ; Wed, 01 Jun 2005 13:39:56 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY5XHTH9M99JQLE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 13:39:41 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7BED4AB543 for ; Wed, 01 Jun 2005 13:39:41 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5599B4FB06 for ; Wed, 01 Jun 2005 13:39:41 +1000 (EST) Date: Wed, 01 Jun 2005 13:39:40 +1000 From: Greg Daley Subject: [DNA] MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429D2DFC.1080806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT In the draft it states: "The list will be referred to in this document as "DNAPrefixList". For each prefix the router MUST store the following information: 1. Prefix 2. Prefix length 3. Valid lifetime 4. Time last refreshed" In my (existing) implementation I'm storing the expiry time of the prefix (which is calculated based on the valid lifetime at the RA reception time). Is this insufficient? I can understand having an indication of when data expires, but it seems overkill explicitly pointing out which data types have to be internally stored in the host unless there's further reasons behind it. Would it be possible to make this descriptive and informational (being internal to the host) rather than prescriptive, using standards language? Greg From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 23:42:07 2005 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 XAA23080 for ; Tue, 31 May 2005 23:42:06 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY611V1AU9ANYY8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 13:41:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9F03F80003; Wed, 01 Jun 2005 13:41:46 +1000 (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 5F68C3C003; Wed, 01 Jun 2005 13:41:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j513fhU14655 for dna-list; Wed, 01 Jun 2005 13:41:43 +1000 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 j513fgr14650 for ; Wed, 01 Jun 2005 13:41:42 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOY60T7WAK977GDR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 13:41:35 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0039B80004 for ; Wed, 01 Jun 2005 13:41:35 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id D590D3C006 for ; Wed, 01 Jun 2005 13:41:34 +1000 (EST) Date: Wed, 01 Jun 2005 13:41:34 +1000 From: Greg Daley Subject: [DNA] Re: MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D2DFC.1080806@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429D2E6E.1020800@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D2DFC.1080806@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT My apologies, I forgot the section number: That's in section 5.1.1 Greg Daley wrote: > In the draft it states: > > "The list will be > referred to in this document as "DNAPrefixList". For each prefix the > router MUST store the following information: > > 1. Prefix > > 2. Prefix length > > 3. Valid lifetime > > 4. Time last refreshed" > > In my (existing) implementation I'm storing the expiry time > of the prefix (which is calculated based on the valid lifetime > at the RA reception time). > > Is this insufficient? > > I can understand having an indication of when data expires, > but it seems overkill explicitly pointing out which data types > have to be internally stored in the host unless there's > further reasons behind it. > > Would it be possible to make this descriptive and informational > (being internal to the host) rather than prescriptive, > using standards language? > > Greg > From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 23:46:43 2005 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 XAA23427 for ; Tue, 31 May 2005 23:46:42 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY66VNXGC9AO1IR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 13:46:31 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 86EC2AB543; Wed, 01 Jun 2005 13:46:28 +1000 (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 243314FB08; Wed, 01 Jun 2005 13:46:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j513kOF14767 for dna-list; Wed, 01 Jun 2005 13:46:24 +1000 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 j513kNr14763 for ; Wed, 01 Jun 2005 13:46:23 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY66GLQ189AO0XG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 13:46:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 56842AB545 for ; Wed, 01 Jun 2005 13:46:08 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4754D4FB09 for ; Wed, 01 Jun 2005 13:46:06 +1000 (EST) Date: Wed, 01 Jun 2005 13:46:00 +1000 From: Greg Daley Subject: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429D2F78.1000008@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT I'm confused by this statement in the draft: In Section 5.1.4: "... If the RS contains a Landmark Option whose prefix does not match any of those in the interface's stored prefix list, then the Landmark option with the Landmark prefix is included in the RA but with the No flag set. All fixed options (MTU, Advertisement Interval, flags, etc.) are added to the Router Advertisement. Prefix Information Options for any explicitly configured prefixes SHOULD be added to the Router Advertisement, while the DNAO for learned prefixes MUST not be added." Is there a reason why DNAO MUST NOT be sent in this case? Isn't it useful to indicate immediately which of the prefixes are available on the new link? Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 00:24:31 2005 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 AAA25996 for ; Wed, 1 Jun 2005 00:24:30 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOY7FDWDP8977FCV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 14:23:17 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C57480007; Wed, 01 Jun 2005 14:22:21 +1000 (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 E2FB43C007; Wed, 01 Jun 2005 14:22:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j514MCA15234 for dna-list; Wed, 01 Jun 2005 14:22:12 +1000 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 j514MCr15230 for ; Wed, 01 Jun 2005 14:22:12 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY7F525CG99JUFX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 14:22:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9BF69AB545; Wed, 01 Jun 2005 14:22:09 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 7C9484FB04; Wed, 01 Jun 2005 14:22:09 +1000 (EST) Date: Wed, 01 Jun 2005 14:22:08 +1000 From: Brett Pentland Subject: Re: [DNA] Re: MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D2E6E.1020800@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <429D37F0.5020406@eng.monash.edu.au> 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.2-1.3.3 (X11/20050513) References: <429D2DFC.1080806@eng.monash.edu.au> <429D2E6E.1020800@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Yes, that sounds reasonable. Perhaps we need some text that states that how the information is stored internally is up to the implementor, as long as the result is the same as described. Brett. Greg Daley wrote: > My apologies, I forgot the section number: > > That's in section 5.1.1 > > Greg Daley wrote: > >> In the draft it states: >> >> "The list will be >> referred to in this document as "DNAPrefixList". For each prefix the >> router MUST store the following information: >> >> 1. Prefix >> >> 2. Prefix length >> >> 3. Valid lifetime >> >> 4. Time last refreshed" >> >> In my (existing) implementation I'm storing the expiry time >> of the prefix (which is calculated based on the valid lifetime >> at the RA reception time). >> >> Is this insufficient? >> >> I can understand having an indication of when data expires, >> but it seems overkill explicitly pointing out which data types >> have to be internally stored in the host unless there's >> further reasons behind it. >> >> Would it be possible to make this descriptive and informational >> (being internal to the host) rather than prescriptive, >> using standards language? >> >> Greg >> -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brett Pentland brett.pentland@eng.monash.edu.au CTIE - Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University, VIC, 3800, Australia Phone : +61 3 9905-5245 Fax : +61 3 9905-3454 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 00:27:41 2005 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 AAA26190 for ; Wed, 1 Jun 2005 00:27:40 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY7LJDFTU99JL6K@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 14:27:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DD3B580007; Wed, 01 Jun 2005 14:27:18 +1000 (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 924143C00E; Wed, 01 Jun 2005 14:27:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j514RB715334 for dna-list; Wed, 01 Jun 2005 14:27:11 +1000 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 j514RAr15330 for ; Wed, 01 Jun 2005 14:27:10 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY7L9SB0E99JL6K@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 14:27:06 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 303E5AB543; Wed, 01 Jun 2005 14:27:06 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 0D4EB4FB05; Wed, 01 Jun 2005 14:27:06 +1000 (EST) Date: Wed, 01 Jun 2005 14:27:05 +1000 From: Brett Pentland Subject: Re: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D2F78.1000008@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <429D3919.8020709@eng.monash.edu.au> 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.2-1.3.3 (X11/20050513) References: <429D2F78.1000008@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT MUST NOT is probably too strong. SHOULD NOT or even MAY NOT might be ok. I don't think there's much value in the DNA option in this case, because the host cannot use the prefixes in it for configuration. Those same prefixes should arrive in PIOs in RAs from the router(s) where they are explicitly configured, very soon anyway. Brett. Greg Daley wrote: > I'm confused by this statement in the draft: > > In Section 5.1.4: > > "... If the RS contains a Landmark Option whose prefix does not > match any of those in the interface's stored prefix list, then > the Landmark option with the Landmark prefix is included in the > RA but with the No flag set. All fixed options (MTU, > Advertisement Interval, flags, etc.) are added to the Router > Advertisement. Prefix Information Options for any explicitly > configured prefixes SHOULD be added to the Router > Advertisement, while the DNAO for learned prefixes MUST not be > added." > > Is there a reason why DNAO MUST NOT be sent in this case? > > Isn't it useful to indicate immediately which of the > prefixes are available on the new link? > > Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 00:34:20 2005 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 AAA26509 for ; Wed, 1 Jun 2005 00:34:19 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOY7TH0MRE976MYR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 14:33:59 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D262DAB543; Wed, 01 Jun 2005 14:33:42 +1000 (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 919F54FB03; Wed, 01 Jun 2005 14:33:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j514XX215452 for dna-list; Wed, 01 Jun 2005 14:33:33 +1000 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 j514XXr15448 for ; Wed, 01 Jun 2005 14:33:33 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY7T45RQA99JQPX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 14:33:25 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 99F4EAB54A for ; Wed, 01 Jun 2005 14:33:25 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 796C14FB02 for ; Wed, 01 Jun 2005 14:33:25 +1000 (EST) Date: Wed, 01 Jun 2005 14:33:20 +1000 From: Greg Daley Subject: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429D3A90.6070309@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, In section 5.1.5, the proposal says: "If the source address of the Router Solicitation is the Unspecified Address or if it does not contain a landmark option, then the router builds a CompleteRA and schedules it for multicast transmission as per RFC 2461. The interface MUST remain in the UnicastSender state." Is it intended that hosts which don't divulge their previously attached prefix in a RS landmark option aren't provided with FastRA service? Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 00:38:10 2005 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 AAA26629 for ; Wed, 1 Jun 2005 00:38:09 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY7XVVF5I9AO1Y7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 14:37:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F2EFF80009; Wed, 01 Jun 2005 14:37:15 +1000 (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 912353C00B; Wed, 01 Jun 2005 14:37:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j514bDg15534 for dna-list; Wed, 01 Jun 2005 14:37:13 +1000 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 j514bDr15530 for ; Wed, 01 Jun 2005 14:37:13 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY7X8WT9S9AO1Y7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 14:36:46 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1E869AB54A for ; Wed, 01 Jun 2005 14:36:45 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id EB4974FB08 for ; Wed, 01 Jun 2005 14:36:44 +1000 (EST) Date: Wed, 01 Jun 2005 14:36:39 +1000 From: Greg Daley Subject: [DNA] Re: No FastRA unless Landmark? (draft-pentland-dna-protocol-00) In-reply-to: <429D3A90.6070309@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429D3B57.7000504@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D3A90.6070309@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Sorry to reply to myself again. Also, the subsequent paragraph has the same logic. "If the source address of the RS is NOT the unspecified address, AND the RS message contains a Landmark option, the router consumes one unicast send token and then builds a Router Advertisement as follows:" It would be good to know why Hash Based Fast RA (based on the source address only) requires the Landmark Option. Greg Greg Daley wrote: > Hi, > > In section 5.1.5, the proposal says: > > "If the source address of the Router Solicitation is the > Unspecified Address or if it does not contain a landmark option, > then the router builds a CompleteRA and schedules it for multicast > transmission as per RFC 2461. The interface MUST remain in the > UnicastSender state." > > Is it intended that hosts which don't divulge their previously > attached prefix in a RS landmark option aren't provided with > FastRA service? > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 00:53:13 2005 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 AAA27243 for ; Wed, 1 Jun 2005 00:53:12 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY8I7X1SQ99JTR5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 14:52:58 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1C4B1AB544; Wed, 01 Jun 2005 14:52:53 +1000 (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 C3BAB4FB06; Wed, 01 Jun 2005 14:52:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j514qXr15721 for dna-list; Wed, 01 Jun 2005 14:52:33 +1000 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 j514qWr15717 for ; Wed, 01 Jun 2005 14:52:32 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY8HF9I9G99JQSI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 14:52:14 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 99FB0AB545 for ; Wed, 01 Jun 2005 14:52:14 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7E7E84FB08 for ; Wed, 01 Jun 2005 14:52:14 +1000 (EST) Date: Wed, 01 Jun 2005 14:52:13 +1000 From: Greg Daley Subject: [DNA] leaving out options on Landmark RA = Yes (draft-pentland-dna-protocol-00.txt)? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429D3EFD.1080500@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear WG, The contents of Landmark RAs with the Yes flag set are described in two locations: Section 3.2: "In the case when the host is still attached to the same link, which might occur when the host has changed from using one layer 2 access point to another, but the access points are on the same link, the Router Advertisement(s) it receives will contain a "yes, that prefix is on this link" answer, and no other information. Thus, such RA messages are quite small." Section 5.1.5: "If the RS contains a Landmark Option whose prefix matches one of those in the interface's stored prefix list, then the Landmark option with the Landmark prefix is included in the RA but with the Yes flag set. At this point the RA is ready for transmission, and is scheduled as specified in Section 5.1.7." I have a comment and question. Comment: The descriptions here ignore SEND options, which need to be included if SEND is used. This will increase the size of the RA. Question: Can we have standards language for this? There's no flexibility in the description of what options are able to be included in the "Yes" Landmark. That sounds like a MUST NOT include other PIO, DNAO. etc. Personally, I'd prefer something saying something like "RAs with the 'Yes' Flag set in a Landmark option MAY leave out all configuration related options such as PIOs, DNAOs, Advertisement Intervals etc, since this information is assumed to have already been received to be able to construct a matching Landmark Router Solicitation". I'd prefer MAY to SHOULD or MUST, since it's an optimization, and the presence of additional options doesn't harm hosts. In RADVD, it's easier for me to not remove the other options in the RA just because the Landmark option Yes flag is set. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 00:55:11 2005 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 AAA27309 for ; Wed, 1 Jun 2005 00:55:10 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY8KUZ4G499JQSI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 14:55:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 922CAAB546; Wed, 01 Jun 2005 14:55:00 +1000 (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 4C5C94FB04; Wed, 01 Jun 2005 14:55:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j514swS15791 for dna-list; Wed, 01 Jun 2005 14:54:58 +1000 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 j514svr15787 for ; Wed, 01 Jun 2005 14:54:57 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY8KPTFGE9ANY1H@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 14:54:55 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B70A3AB544; Wed, 01 Jun 2005 14:54:46 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3C7474FB04; Wed, 01 Jun 2005 14:54:46 +1000 (EST) Date: Wed, 01 Jun 2005 14:54:44 +1000 From: Greg Daley Subject: Re: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D3919.8020709@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429D3F94.8000807@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D2F78.1000008@eng.monash.edu.au> <429D3919.8020709@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Brett Pentland wrote: > MUST NOT is probably too strong. SHOULD NOT or even MAY NOT > might be ok. I don't think there's much value > in the DNA option in this case, because the host cannot use the > prefixes in it for configuration. Those same prefixes > should arrive in PIOs in RAs from the router(s) where they are > explicitly configured, very soon anyway. Can't the host use the prefixes learnt from the DNAO to not be surprised by prefixes in responding RAs (which may not be DNA RAs) to its existing solicitation? Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 00:57:54 2005 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 AAA27417 for ; Wed, 1 Jun 2005 00:57:54 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY8NR1TY299JU68@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 14:57:23 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8B807AB545; Wed, 01 Jun 2005 14:57:20 +1000 (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 3D4274FB02; Wed, 01 Jun 2005 14:57:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j514vHV15859 for dna-list; Wed, 01 Jun 2005 14:57:17 +1000 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 j514vHr15855 for ; Wed, 01 Jun 2005 14:57:17 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOY8NF6MWQ9AO083@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 14:57:04 +1000 Received: by localhost (Postfix, from userid 510) id B2D64AB545; Wed, 01 Jun 2005 14:57:04 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id 944054FB05; Wed, 01 Jun 2005 14:57:02 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHE00I3T331QM@mailout3.samsung.com>; Wed, 01 Jun 2005 13:57:01 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IHE00INA32YED@mmp2.samsung.com>; Wed, 01 Jun 2005 13:57:00 +0900 (KST) Date: Wed, 01 Jun 2005 10:24:47 +0530 From: Ranjitsinh Wable Subject: Re: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <014e01c56666$0a7da170$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429D2F78.1000008@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, I agree on your point. But as per my understanding this is the case when the node has moved to the new link and want to configure the address and based on the source address of the RS and ranking the router which decide to respond need to send its prefixes. Router can send all the learned prefixes but at this point of time the host will not be interested in learned prefix information unless host have any preferences of prefixes and based on this information want to wait for more RAs. So there is no point in adding this information and the consuming the bandwidth. This is my understanding but its better if authors clear the point. Thanks and Regards, Wable R. U. ----- Original Message ----- From: "Greg Daley" To: Sent: Wednesday, June 01, 2005 9:16 AM Subject: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) > I'm confused by this statement in the draft: > > In Section 5.1.4: > > "... If the RS contains a Landmark Option whose prefix does not > match any of those in the interface's stored prefix list, then > the Landmark option with the Landmark prefix is included in the > RA but with the No flag set. All fixed options (MTU, > Advertisement Interval, flags, etc.) are added to the Router > Advertisement. Prefix Information Options for any explicitly > configured prefixes SHOULD be added to the Router > Advertisement, while the DNAO for learned prefixes MUST not be > added." > > Is there a reason why DNAO MUST NOT be sent in this case? > > Isn't it useful to indicate immediately which of the > prefixes are available on the new link? > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 01:39:41 2005 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 BAA00116 for ; Wed, 1 Jun 2005 01:39:40 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYA3VDS5G99JM77@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 15:38:38 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DB532AB545; Wed, 01 Jun 2005 15:38:34 +1000 (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 880284FB06; Wed, 01 Jun 2005 15:38:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j515cNC16352 for dna-list; Wed, 01 Jun 2005 15:38:23 +1000 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 j515cNr16346 for ; Wed, 01 Jun 2005 15:38:23 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYA39US2U99JPK2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 15:38:06 +1000 Received: by localhost (Postfix, from userid 510) id 0217280003; Wed, 01 Jun 2005 15:38:05 +1000 (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 6F06B3C00D; Wed, 01 Jun 2005 15:38:03 +1000 (EST) Received: from esebh106.NOE.Nokia.com ([172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j515bsAi031390; Wed, 01 Jun 2005 08:37:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 01 Jun 2005 08:36:55 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 01 Jun 2005 08:36:55 +0300 Date: Wed, 01 Jun 2005 08:36:54 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] Re: MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: brett.pentland@eng.monash.edu.au, greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <1AA39B75171A7144A73216AED1D7478D5C11D2@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Re: MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) Thread-Index: AcVmYcIiTCVFInpmRLii3NLr3hZtVwACcvVg Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 01 Jun 2005 05:36:55.0651 (UTC) FILETIME=[EBFA4B30:01C5666B] Content-Transfer-Encoding: 7BIT Brett, > Yes, that sounds reasonable. Perhaps we need some text that states > that how the information is stored internally is up to the implementor, > as long as the result is the same as described. It wouldn't hurt to mention the types of things that could be stored, without using keywords, as a guide to implementors. IF you describe the reults needed, implementers will come back asking what kind of things to store. I think Greg was just pointing out that the current text should be softened, explaining that the things in the list are examples of what could be stored ... John > Greg Daley wrote: > > My apologies, I forgot the section number: > > > > That's in section 5.1.1 > > > > Greg Daley wrote: > > > >> In the draft it states: > >> > >> "The list will be > >> referred to in this document as "DNAPrefixList". For > each prefix the > >> router MUST store the following information: > >> > >> 1. Prefix > >> > >> 2. Prefix length > >> > >> 3. Valid lifetime > >> > >> 4. Time last refreshed" > >> > >> In my (existing) implementation I'm storing the expiry time > >> of the prefix (which is calculated based on the valid lifetime > >> at the RA reception time). > >> > >> Is this insufficient? > >> > >> I can understand having an indication of when data expires, > >> but it seems overkill explicitly pointing out which data types > >> have to be internally stored in the host unless there's > >> further reasons behind it. > >> > >> Would it be possible to make this descriptive and informational > >> (being internal to the host) rather than prescriptive, > >> using standards language? > >> > >> Greg > >> > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Brett Pentland brett.pentland@eng.monash.edu.au > CTIE - Centre for Telecommunications and Information Engineering > Department of Electrical and Computer Systems Engineering > Monash University, VIC, 3800, Australia > Phone : +61 3 9905-5245 Fax : +61 3 9905-3454 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 01:46:50 2005 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 BAA00446 for ; Wed, 1 Jun 2005 01:46:49 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYAC6U8KS94OM61@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 15:46:13 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 30E99AB542; Wed, 01 Jun 2005 15:45:17 +1000 (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 D9DD84FB04; Wed, 01 Jun 2005 15:45:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j515j6C16461 for dna-list; Wed, 01 Jun 2005 15:45:06 +1000 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 j515j5r16457 for ; Wed, 01 Jun 2005 15:45:05 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYABN88I899IIPT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 15:44:51 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EA468AB54C; Wed, 01 Jun 2005 15:44:50 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 B0C214FB06; Wed, 01 Jun 2005 15:44:50 +1000 (EST) Date: Wed, 01 Jun 2005 15:44:50 +1000 From: Brett Pentland Subject: Re: [DNA] Re: MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) In-reply-to: <1AA39B75171A7144A73216AED1D7478D5C11D2@esebe100.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <429D4B52.7050306@eng.monash.edu.au> 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.2-1.3.3 (X11/20050513) References: <1AA39B75171A7144A73216AED1D7478D5C11D2@esebe100.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT I think there is a sort of middle ground that is needed. There is a MUST in the sense that the information represented in those four points is essential to the operation of the protocol, but in the case that Greg pointed out, it doesn't matter whether the time last refreshed is stored and an expiry time calculated from that, or an expiry time is stored explicitly, as long as the information goes away when the expiry time arrives. Brett. john.loughney@nokia.com wrote: > Brett, > > >>Yes, that sounds reasonable. Perhaps we need some text that states >>that how the information is stored internally is up to the implementor, >>as long as the result is the same as described. > > > It wouldn't hurt to mention the types of things that could be stored, without > using keywords, as a guide to implementors. IF you describe the reults needed, > implementers will come back asking what kind of things to store. I think > Greg was just pointing out that the current text should be softened, explaining > that the things in the list are examples of what could be stored ... > > John > > > >>Greg Daley wrote: >> >>>My apologies, I forgot the section number: >>> >>>That's in section 5.1.1 >>> >>>Greg Daley wrote: >>> >>> >>>>In the draft it states: >>>> >>>> "The list will be >>>> referred to in this document as "DNAPrefixList". For >> >>each prefix the >> >>>> router MUST store the following information: >>>> >>>> 1. Prefix >>>> >>>> 2. Prefix length >>>> >>>> 3. Valid lifetime >>>> >>>> 4. Time last refreshed" >>>> >>>>In my (existing) implementation I'm storing the expiry time >>>>of the prefix (which is calculated based on the valid lifetime >>>>at the RA reception time). >>>> >>>>Is this insufficient? >>>> >>>>I can understand having an indication of when data expires, >>>>but it seems overkill explicitly pointing out which data types >>>>have to be internally stored in the host unless there's >>>>further reasons behind it. >>>> >>>>Would it be possible to make this descriptive and informational >>>>(being internal to the host) rather than prescriptive, >>>>using standards language? >>>> >>>>Greg >>>> >> >>-- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Brett Pentland brett.pentland@eng.monash.edu.au >> CTIE - Centre for Telecommunications and Information Engineering >> Department of Electrical and Computer Systems Engineering >> Monash University, VIC, 3800, Australia >> Phone : +61 3 9905-5245 Fax : +61 3 9905-3454 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brett Pentland brett.pentland@eng.monash.edu.au CTIE - Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University, VIC, 3800, Australia Phone : +61 3 9905-5245 Fax : +61 3 9905-3454 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 01:52:43 2005 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 BAA00664 for ; Wed, 1 Jun 2005 01:52:42 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYAISCEA499JIVB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 15:50:44 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 568E6AB54F; Wed, 01 Jun 2005 15:50:36 +1000 (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 F21604FB07; Wed, 01 Jun 2005 15:50:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j515oTb16568 for dna-list; Wed, 01 Jun 2005 15:50:29 +1000 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 j515oSr16564 for ; Wed, 01 Jun 2005 15:50:28 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYAIE1HY299JQRT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 15:50:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 448A2AB543; Wed, 01 Jun 2005 15:50:17 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 283B24FB08; Wed, 01 Jun 2005 15:50:17 +1000 (EST) Date: Wed, 01 Jun 2005 15:50:16 +1000 From: Brett Pentland Subject: Re: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D3F94.8000807@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <429D4C98.5040408@eng.monash.edu.au> 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.2-1.3.3 (X11/20050513) References: <429D2F78.1000008@eng.monash.edu.au> <429D3919.8020709@eng.monash.edu.au> <429D3F94.8000807@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Hi Brett, > > Brett Pentland wrote: > >> MUST NOT is probably too strong. SHOULD NOT or even MAY NOT >> might be ok. I don't think there's much value >> in the DNA option in this case, because the host cannot use the >> prefixes in it for configuration. Those same prefixes >> should arrive in PIOs in RAs from the router(s) where they are >> explicitly configured, very soon anyway. > > > Can't the host use the prefixes learnt from the DNAO to not be > surprised by prefixes in responding RAs (which may not be DNA RAs) > to its existing solicitation? Yes, but the DNA router responses would usually be received first, and the non-DNA router responses would have to be dealt with using CPL logic anyway, and shouldn't cause confusion. Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 06:32:54 2005 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 GAA25483 for ; Wed, 1 Jun 2005 06:32:53 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYKDJQDRG99IHJ4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 20:32:51 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CE118AB543; Wed, 01 Jun 2005 20:32:42 +1000 (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 8E0E24FB0A; Wed, 01 Jun 2005 20:32:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51AWBP19525 for dna-list; Wed, 01 Jun 2005 20:32:11 +1000 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 j51AWAr19521 for ; Wed, 01 Jun 2005 20:32:10 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYKCS8G989AO123@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 20:32:06 +1000 Received: by localhost (Postfix, from userid 510) id 0B31DAB542; Wed, 01 Jun 2005 20:32:05 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id CAA284FB04 for ; Wed, 01 Jun 2005 20:32:04 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHE009E5ILEXB@mailout2.samsung.com> for dna@eng.monash.edu.au; Wed, 01 Jun 2005 19:32:02 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHE005UTILB2H@mmp1.samsung.com> for dna@eng.monash.edu.au; Wed, 01 Jun 2005 19:32:02 +0900 (KST) Date: Wed, 01 Jun 2005 15:59:47 +0530 From: Subba Reddy Subject: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: Syam Madanpalli Message-id: <012601c56694$d7730700$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_t1H06US/Bvl0oE+E+b26Ww)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) This is a multi-part message in MIME format. --Boundary_(ID_t1H06US/Bvl0oE+E+b26Ww) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, few comments and questions on the DNAv6 draft. 1. In Section 3.2 ".... In the case when the landmark prefix is unknown to the responding router, the host will receive a "No" answer to its landmark question, and also the information it needs to configure itself for the new link. The routers try to include as much information as possible in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ such messages, so that the host can be informed of all the prefixes assigned to the new link as soon as possible." but as per section 5.1.5, DNAO for learned prefixes must not be added in the unicast RAs. i.e, we are not adding as much information as possible. 2. While bootstrapping DNA data structures(section 5.1.3), a) will the router reply for RSs without landmark option (may be sent by other routers) b) will the router reply for RSs that contains landmark option (may be sent by DNA host) 3. While a router is in multicast sender state (during 3 seconds), will it increase the token count or will it consider the token count as MaxUnicastRABurst? 4. In section 5.2.4, ".....If the unicast Router Advertisement contains a Landmark option that matches the Landmark Option in the last transmitted Router Solicitation ....." Is a case where, a unicast router advertisement comes without landmark option is possible? (DNA routers which are bootstrapping may just send RA) If possible, some text which tells what to do in such cases may need to be added. 5. To deal with amplification effect, what about having a threshold on number of routers sending fast RA? For example, only first 5 routers (as per the fast RA rankings) only will reply for RSs (in addition to the method specified in the draft) Here are some typo errors 1. In section 5.1.1 " The routers maintain a set of conceptual data structures for each interface to track the prefixes advertised by other routers on the link, and also the set of DNA routers (the routers that will quickly respond to RAs) on the link. For each interface, routers maintain a ^^^^^^^^^^^^^^^^ list of all prefixes advertised on the link. The list will be referred to in this document as "DNAPrefixList". For each prefix the router MUST store the following information:" I think it is either "the routers that will quickly respond with RAs" or "the routers that will quickly respond to RSs" 2. In section 5.1.4 " When a router receives a Router Advertisement, it first validates the RA per the rules in RFC 2461, and then performs the actions specified ^^^^^^^^ in RFC 2461." "RA as per" Thanks & Regards, Subba Reddy --Boundary_(ID_t1H06US/Bvl0oE+E+b26Ww) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
  
   few comments and questions on the DNAv6 draft.
 
1. In Section 3.2
 
"....    In the case when the landmark prefix is unknown to the responding
   router, the host will receive a "No" answer to its landmark question,
   and also the information it needs to configure itself for the new
   link.  The routers try to include as much information as possible in
                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   such messages, so that the host can be informed of all the prefixes
   assigned to the new link as soon as possible."
 
but as per section 5.1.5, DNAO for learned prefixes must not be added in the unicast RAs.
i.e, we are not adding as much information as possible.
 
2. While bootstrapping DNA data structures(section 5.1.3),
     a) will the router reply for RSs without landmark option (may be sent by other routers)
     b) will the router reply for RSs that contains landmark option (may be sent by DNA host)
 
3. While a router is in multicast sender state (during 3 seconds), will it increase the token count or will it consider the token count as MaxUnicastRABurst?
 
4. In section 5.2.4,

 ".....If the unicast Router Advertisement contains a Landmark option
      that matches the Landmark Option in the last transmitted Router
      Solicitation ....."
 
Is a case where, a unicast router advertisement comes without landmark option is possible? (DNA routers which are bootstrapping may just send RA) If possible, some text which tells what to do in such cases may need to be added. 
 
5. To deal with amplification effect, what about having a threshold on number of routers sending fast RA? For example, only first 5 routers (as per the fast RA rankings) only will reply for RSs (in addition to the method specified in the draft)
 
 
Here are some typo errors
1. In section 5.1.1
 
"   The routers maintain a set of conceptual data structures for each
   interface to track the prefixes advertised by other routers on the
   link, and also the set of DNA routers (the routers that will quickly
   respond to RAs) on the link.  For each interface, routers maintain a
   ^^^^^^^^^^^^^^^^
   list of all prefixes advertised on the link.  The list will be
   referred to in this document as "DNAPrefixList".  For each prefix the
   router MUST store the following information:"

  I think it is either "the routers that will quickly respond with RAs" or
"the routers that will quickly respond to RSs"
 
2. In section 5.1.4
"   When a router receives a Router Advertisement, it first validates the
   RA per the rules in RFC 2461, and then performs the actions specified
  ^^^^^^^^
   in RFC 2461."
 
"RA as per"
 
 
Thanks & Regards,
Subba Reddy
 --Boundary_(ID_t1H06US/Bvl0oE+E+b26Ww)-- From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 09:25:06 2005 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 JAA15665 for ; Wed, 1 Jun 2005 09:25:05 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYQE1D9DK9ANZRY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 23:24:59 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7C50F80003; Wed, 01 Jun 2005 23:24:54 +1000 (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 29A623C00B; Wed, 01 Jun 2005 23:24:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51DOOi21366 for dna-list; Wed, 01 Jun 2005 23:24:24 +1000 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 j51DOOr21362 for ; Wed, 01 Jun 2005 23:24:24 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYQDCOK6299JRLD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 23:24:21 +1000 Received: by localhost (Postfix, from userid 510) id 76BC580002; Wed, 01 Jun 2005 23:24:21 +1000 (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 58BEA3C009; Wed, 01 Jun 2005 23:24:19 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j51DOHbR013464; Wed, 01 Jun 2005 09:24:17 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 894231E8186; Wed, 01 Jun 2005 09:16:04 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 7DEC41E8180; Wed, 01 Jun 2005 09:16:04 -0400 (EDT) Received: from [68.39.6.87] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Wed, 01 Jun 2005 09:24:17 -0400 Date: Wed, 01 Jun 2005 09:24:17 -0400 From: Sathya Narayanan Subject: Re: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:58.02637 C:21 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-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg - > > In section 5.1.5, the proposal says: > > "If the source address of the Router Solicitation is the > Unspecified Address or if it does not contain a landmark option, > then the router builds a CompleteRA and schedules it for multicast > transmission as per RFC 2461. The interface MUST remain in the > UnicastSender state." > > Is it intended that hosts which don't divulge their previously > attached prefix in a RS landmark option aren't provided with FastRA service? No. Looks like there are two reasons why a host will not include a landmark option (I thought about only the first): 1) Host is a non-DNA host 2) Host doesn't want to divulge their landmark The text in the draft is targetted at the first case, i.e. if the RS message doesn't have a landmark option it is a non-DNA host. The only way to help out the host is by sending a CompleteRA because the router doesn't not know what question to answer. For a non-DNA host, a completeRA will be only partially helpful, if it hasn't moved link and sees its current prefix in the completeRA in a PIO - because it can neither recognize the completeRA bit nor the DNAO. Sending too-many unicast CompleteRA with the hope that it is useful for the host is not good for link-utilization and hence the recommendation. Now, I think, the same logic applies for the second case too, even though a DNA-host could receive better benefit from the CompleteRA. The router has no-way of knowing whether the sender is a dna-host or not. So, the question is do you (WG) think that it makes sense to respond with a CompleteRA message every time a RS message without a landmark arrives. IMHO, no. regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 09:33:36 2005 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 JAA16213 for ; Wed, 1 Jun 2005 09:33:35 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYQO5V02A977Z54@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 23:33:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D302AB542; Wed, 01 Jun 2005 23:33:04 +1000 (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 A62724FB05; Wed, 01 Jun 2005 23:33:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51DWuo21497 for dna-list; Wed, 01 Jun 2005 23:32:56 +1000 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 j51DWtr21493 for ; Wed, 01 Jun 2005 23:32:55 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYQNMI7JO94MX2A@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 23:32:38 +1000 Received: by localhost (Postfix, from userid 510) id 694F780003; Wed, 01 Jun 2005 23:32:38 +1000 (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 55B3F3C00C; Wed, 01 Jun 2005 23:32:37 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j51DWamY013661; Wed, 01 Jun 2005 09:32:36 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 64A401EC16A; Wed, 01 Jun 2005 09:24:23 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 59D4D1E8180; Wed, 01 Jun 2005 09:24:23 -0400 (EDT) Received: from [68.39.6.87] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Wed, 01 Jun 2005 09:32:36 -0400 Date: Wed, 01 Jun 2005 09:32:36 -0400 From: Sathya Narayanan Subject: Re: [DNA] leaving out options on Landmark RA =Yes(draft-pentland-dna-protocol-00.txt)? Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:15 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg - Under the assumption that the 'Yes' case is more likely, i.e. the ratio AP/AR is big, it makes sense to emphasize the importance of this optimization by making it a MUST/SHOULD, IMHO. With the size of PIOs, possibly many of them and wireless channels etc., there is possibly significant savings in link-utilization. - Sathya ----- Original Message ----- From: Greg Daley Date: Wednesday, June 1, 2005 0:52 am Subject: [DNA] leaving out options on Landmark RA = Yes(draft-pentland-dna-protocol-00.txt)? > Dear WG, > > The contents of Landmark RAs with the Yes flag set > are described in two locations: > > Section 3.2: > > "In the case when the host is still attached to the same link, which > might occur when the host has changed from using one layer 2 access > point to another, but the access points are on the same link, the > Router Advertisement(s) it receives will contain a "yes, that prefix > is on this link" answer, and no other information. Thus, such RA > messages are quite small." > > Section 5.1.5: > > "If the RS contains a Landmark Option whose prefix matches one > of those in the interface's stored prefix list, then the > Landmark option with the Landmark prefix is included in the RA > but with the Yes flag set. At this point the RA is ready for > transmission, and is scheduled as specified in Section 5.1.7." > > I have a comment and question. > > Comment: > > The descriptions here ignore SEND options, which need to be included > if SEND is used. This will increase the size of the RA. > > Question: > > Can we have standards language for this? > > There's no flexibility in the description of what options are > able to be included in the "Yes" Landmark. That sounds like a > MUST NOT include other PIO, DNAO. etc. > > Personally, I'd prefer something saying something like > > "RAs with the 'Yes' Flag set in a Landmark option MAY leave out all > configuration related options such as PIOs, DNAOs, Advertisement > Intervals etc, since this information is assumed to have > already been received to be able to construct a matching > Landmark Router Solicitation". > > I'd prefer MAY to SHOULD or MUST, since it's an optimization, > and the presence of additional options doesn't harm hosts. > > In RADVD, it's easier for me to not remove the other options > in the RA just because the Landmark option Yes flag is set. > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 10:55:14 2005 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 KAA23449 for ; Wed, 1 Jun 2005 10:55:13 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYTHC3DPM94OQWO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 00:54:11 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5012580003; Thu, 02 Jun 2005 00:53:51 +1000 (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 0BADB3C007; Thu, 02 Jun 2005 00:53:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51ErNu22478 for dna-list; Thu, 02 Jun 2005 00:53:23 +1000 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 j51ErNr22472 for ; Thu, 02 Jun 2005 00:53:23 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYTGJZSPY976V3R@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 00:53:14 +1000 Received: by localhost (Postfix, from userid 510) id CD07FAB543; Thu, 02 Jun 2005 00:53:13 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by moe.its.monash.edu.au (Postfix) with ESMTP id F09B94FB03 for ; Thu, 02 Jun 2005 00:53:11 +1000 (EST) Received: by rproxy.gmail.com with SMTP id b11so300337rne for ; Wed, 01 Jun 2005 07:53:10 -0700 (PDT) Received: by 10.38.74.75 with SMTP id w75mr7750184rna; Wed, 01 Jun 2005 07:53:10 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Wed, 01 Jun 2005 07:53:10 -0700 (PDT) Date: Wed, 01 Jun 2005 20:23:10 +0530 From: Syam Madanapalli Subject: Re: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Reply-to: Syam Madanapalli Message-id: <10e14db205060107534e9cae40@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:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F6a3npQTdXZfCwCNL7Y+GKGcVJl44BBz/r5BTSwEDStmKUyQe3maaVkVQsk/iDg5kTf0F32E9OjlXsxqs7U9Ie5Nn73+oU8bd0RO013AILOsa+toXo6yJ9sc3qA47KBEyM1ZGqxEbdJ0H6TlQ4FEwKaxI6QZ0NGFRc7w/Ap6QGc= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: Content-Transfer-Encoding: 7BIT Hi Sathya > > So, the question is do you (WG) think that it makes sense to respond with a CompleteRA message every time a RS message without a landmark arrives. IMHO, no. I think it may make sense to send a completeRA every time an RS is received. For example if I prefer implementing Link Identifier based approach instead of Landmark based approach, the complete RA is useful. The FastRA method should have been a seperate draft, unless we are going to have a single DNA solution. > > regards, > Sathya > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 12:46:16 2005 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 MAA03466 for ; Wed, 1 Jun 2005 12:46:14 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYXE9VNRA977FMP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 02:46:03 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6254480004; Thu, 02 Jun 2005 02:45:55 +1000 (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 0FAC33C004; Thu, 02 Jun 2005 02:45:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51GjIv23719 for dna-list; Thu, 02 Jun 2005 02:45:18 +1000 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 j51GjIr23715 for ; Thu, 02 Jun 2005 02:45:18 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYXDA0XD694OGJN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 02:45:07 +1000 Received: by localhost (Postfix, from userid 510) id 44816AB542; Thu, 02 Jun 2005 02:45:07 +1000 (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 614904FB02; Thu, 02 Jun 2005 02:45:05 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j51Gj3jO020142; Wed, 01 Jun 2005 10:45:03 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j51Gj24A226335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Jun 2005 09:45:03 -0700 (PDT) Date: Wed, 01 Jun 2005 09:45:20 -0700 From: Erik Nordmark Subject: Re: [DNA] Re: No FastRA unless Landmark? (draft-pentland-dna-protocol-00) In-reply-to: <429D3B57.7000504@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <429DE620.9000006@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429D3A90.6070309@eng.monash.edu.au> <429D3B57.7000504@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > "If the source address of the RS is NOT the unspecified address, > AND the RS message contains a Landmark option, the router consumes > one unicast send token and then builds a Router Advertisement as > follows:" > > > It would be good to know why Hash Based Fast RA (based on the > source address only) requires the Landmark Option. I don't think it does. The current text might just reflect the focus on the most important cases, and also tries to limit the number of cases. But the fastRA decision could be made to be orthogonal to the content of the RA (i.e. whether there is a LO or not). Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 13:53:45 2005 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 NAA09954 for ; Wed, 1 Jun 2005 13:53:44 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYZQM73F69AO2BB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 03:53:15 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C90F2AB544; Thu, 02 Jun 2005 03:53:07 +1000 (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 73B964FB0C; Thu, 02 Jun 2005 03:53:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51HqeW24449 for dna-list; Thu, 02 Jun 2005 03:52:40 +1000 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 j51Hqer24445 for ; Thu, 02 Jun 2005 03:52:40 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYZPOMT2694O8EU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 03:52:23 +1000 Received: by localhost (Postfix, from userid 510) id 57FDC80002; Thu, 02 Jun 2005 03:52:23 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5DEAA3C00C; Thu, 02 Jun 2005 03:52:21 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j51HqK0R001523; Wed, 01 Jun 2005 11:52:20 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j51HqJLN256747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Jun 2005 10:52:19 -0700 (PDT) Date: Wed, 01 Jun 2005 10:52:37 -0700 From: Erik Nordmark Subject: Re: [DNA] MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D2DFC.1080806@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <429DF5E5.9090400@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429D2DFC.1080806@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg, Thanks for your comments on the draft. Greg Daley wrote: > In the draft it states: > > "The list will be > referred to in this document as "DNAPrefixList". For each prefix the > router MUST store the following information: > > 1. Prefix > > 2. Prefix length > > 3. Valid lifetime > > 4. Time last refreshed" > > In my (existing) implementation I'm storing the expiry time > of the prefix (which is calculated based on the valid lifetime > at the RA reception time). Is this for #3 above? Are you also storing #4? > Is this insufficient? Storing the expiry time for the valid lifetime is what's needed for #3. > I can understand having an indication of when data expires, > but it seems overkill explicitly pointing out which data types > have to be internally stored in the host unless there's > further reasons behind it. > > Would it be possible to make this descriptive and informational > (being internal to the host) rather than prescriptive, > using standards language? The intent is to provide enough *conceptual* data structure descriptions so that the protocol can be described in detail, but not constrain how an implementation actual does things as long as the externally visible behavior of the implementation is consistent with the specification. There is text in section 5 in RFC 2461 which says this, so perhaps we can just borrow that text. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 13:59:40 2005 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 NAA10338 for ; Wed, 1 Jun 2005 13:59:39 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOYZY8IYTG94O24E@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 03:59:32 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D63AC80004; Thu, 02 Jun 2005 03:59:16 +1000 (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 867863C008; Thu, 02 Jun 2005 03:59:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51HxA324573 for dna-list; Thu, 02 Jun 2005 03:59:10 +1000 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 j51Hx9r24569 for ; Thu, 02 Jun 2005 03:59:09 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOYZXXFHMG9AO1J0@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 03:59:02 +1000 Received: by localhost (Postfix, from userid 510) id 256D4AB543; Thu, 02 Jun 2005 03:59:02 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by moe.its.monash.edu.au (Postfix) with ESMTP id 213E64FB03; Thu, 02 Jun 2005 03:58:59 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.68.130]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j51Hww0R007869; Wed, 01 Jun 2005 11:58:59 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j51Hwv70260037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Jun 2005 10:58:58 -0700 (PDT) Date: Wed, 01 Jun 2005 10:59:16 -0700 From: Erik Nordmark Subject: Re: [DNA] leaving out options on Landmark RA = Yes (draft-pentland-dna-protocol-00.txt)? In-reply-to: <429D3EFD.1080500@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <429DF774.6060909@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429D3EFD.1080500@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Comment: > > The descriptions here ignore SEND options, which need to be included > if SEND is used. This will increase the size of the RA. Probably. I haven't looked at exactly what SEND information would be needed in the different cases of an RA being sent. If the host didn't move, the RAs will in most cases be sent from routers that the host has previously received RAs from, thus the SEND information can be minimized. But when the landmark indicates that the host has moved it makes sense for the RAs to include more SEND information if that makes a SEND host complete the movement faster. Is anybody looking at the details of how SEND and DNA can interact efficiently? > Question: > > Can we have standards language for this? > > There's no flexibility in the description of what options are > able to be included in the "Yes" Landmark. That sounds like a > MUST NOT include other PIO, DNAO. etc. In think the text in section 3 is fine with its use of English, because it tries to introduce the concepts by saying what typically happens. But in the core of the draft it makes sense being more specific. > Personally, I'd prefer something saying something like > > "RAs with the 'Yes' Flag set in a Landmark option MAY leave out all > configuration related options such as PIOs, DNAOs, Advertisement > Intervals etc, since this information is assumed to have > already been received to be able to construct a matching > Landmark Router Solicitation". > > I'd prefer MAY to SHOULD or MUST, since it's an optimization, > and the presence of additional options doesn't harm hosts. My gut feel is that we should make it a SHOULD NOT, because the host doesn't have any need for this extra stuff, and one of the DNA goals is to be efficient. > In RADVD, it's easier for me to not remove the other options > in the RA just because the Landmark option Yes flag is set. And the purpose of a SHOULD NOT would be to make you do the work :-), so that we can get an efficient way to do DNA. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 14:04:23 2005 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 OAA10632 for ; Wed, 1 Jun 2005 14:04:22 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZ04ON0CG9778DJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 04:04:11 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A485CAB561; Thu, 02 Jun 2005 04:02:17 +1000 (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 309684FB03; Thu, 02 Jun 2005 04:02:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51I28I24736 for dna-list; Thu, 02 Jun 2005 04:02:08 +1000 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 j51I25r24723 for ; Thu, 02 Jun 2005 04:02:06 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZ02DKCZS99JVXD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 04:01:50 +1000 Received: by localhost (Postfix, from userid 510) id 67A57AB543; Thu, 02 Jun 2005 04:01:50 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id 84A1B4FB07; Thu, 02 Jun 2005 04:01:48 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j51I1lGJ019483; Wed, 01 Jun 2005 11:01:47 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j51I1jXx260802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Jun 2005 11:01:46 -0700 (PDT) Date: Wed, 01 Jun 2005 11:02:04 -0700 From: Erik Nordmark Subject: Re: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D3F94.8000807@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: <429DF81C.2000609@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429D2F78.1000008@eng.monash.edu.au> <429D3919.8020709@eng.monash.edu.au> <429D3F94.8000807@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Can't the host use the prefixes learnt from the DNAO to not be > surprised by prefixes in responding RAs (which may not be DNA RAs) > to its existing solicitation? What did you have in mind the host would actually do to be "less surprised"? If it records the DNAO prefix somehow, what would it then do when it - receives an RA with a prefix which was recorded from the DNAO - receives an RA with a new prefix which was not recorded from a DNAO? FWIW the conceptual data structures in RFC 2461 can only capture prefixes for which all the information in the PIO is present, i.e. the lifetimes and the flags must be includes. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 14:12:24 2005 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 OAA11281 for ; Wed, 1 Jun 2005 14:12:23 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZ0F98YKA99JVXD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 04:12:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 58684AB542; Thu, 02 Jun 2005 04:12:13 +1000 (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 1A8884FB05; Thu, 02 Jun 2005 04:12:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51IC2E25033 for dna-list; Thu, 02 Jun 2005 04:12:02 +1000 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 j51IBxr25029 for ; Thu, 02 Jun 2005 04:12:00 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZ0ENVP249776SL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 04:11:44 +1000 Received: by localhost (Postfix, from userid 510) id C1968AB542; Thu, 02 Jun 2005 04:11:44 +1000 (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 BA0414FB02 for ; Thu, 02 Jun 2005 04:11:42 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j51IBf0R022632; Wed, 01 Jun 2005 12:11:41 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j51IBeXs266178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Jun 2005 11:11:40 -0700 (PDT) Date: Wed, 01 Jun 2005 11:11:58 -0700 From: Erik Nordmark Subject: Re: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) In-reply-to: <012601c56694$d7730700$39476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: dna@eng.monash.edu.au, Syam Madanpalli Message-id: <429DFA6E.4090603@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <012601c56694$d7730700$39476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Subba Reddy wrote: > Hi, > > few comments and questions on the DNAv6 draft. Thanks for the comments. > 1. In Section 3.2 > > ".... In the case when the landmark prefix is unknown to the > responding router, the host will receive a "No" answer to its > landmark question, and also the information it needs to configure > itself for the new link. The routers try to include as much > information as possible in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ such > messages, so that the host can be informed of all the prefixes > assigned to the new link as soon as possible." > > but as per section 5.1.5, DNAO for learned prefixes must not be added > in the unicast RAs. i.e, we are not adding as much information as > possible. Well, sending DNAOs to hosts when responding yes or no to a landmark question doesn't actually provide the host with any (useful) information. In order to provide information to the host in a "no" landmark RA, the DNAO would have to include the prefix lifetimes and the flags. > 2. While bootstrapping DNA data structures(section 5.1.3), a) will > the router reply for RSs without landmark option (may be sent by > other routers) b) will the router reply for RSs that contains > landmark option (may be sent by DNA host) I think the current text says that it will not respond at all. This is a bit suboptimal when multiple routers boot at the same time. I suspect we need to figure out how to tweak this. Suggestions? > 3. While a router is in multicast sender state (during 3 seconds), > will it increase the token count or will it consider the token count > as MaxUnicastRABurst? The token bucket gets tokens added periodically independently of whether its in multicast state or not, as long as the bucket isn't full (already at MaxUnicastRABurst) > 4. In section 5.2.4, > > ".....If the unicast Router Advertisement contains a Landmark option > that matches the Landmark Option in the last transmitted Router > Solicitation ....." > > Is a case where, a unicast router advertisement comes without > landmark option is possible? (DNA routers which are bootstrapping may > just send RA) If possible, some text which tells what to do in such > cases may need to be added. We should probably say what to do in any case, since an existing RFC 2461 router is free to unicast RAs (even if the RFC suggests to always multicast them) > 5. To deal with amplification effect, what about having a threshold > on number of routers sending fast RA? For example, only first 5 > routers (as per the fast RA rankings) only will reply for RSs (in > addition to the method specified in the draft) That might make sense. I assume the 6+ ranked routers would not be completely quiet, but instead schedule a 3 second multicast RA. This is needed in the case that the routers annouce different prefixes, and also to make the host discover that it has >5 default routers. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 17:29:36 2005 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 RAA10737 for ; Wed, 1 Jun 2005 17:29:35 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZ7AC6YPO9ANO8T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 07:29:08 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C4A59AB545; Thu, 02 Jun 2005 07:29:04 +1000 (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 5EF2B4FB06; Thu, 02 Jun 2005 07:29:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51LST427070 for dna-list; Thu, 02 Jun 2005 07:28:29 +1000 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 j51LSSr27066 for ; Thu, 02 Jun 2005 07:28:28 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZ79C8PNI9ANO8T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 07:28:16 +1000 Received: by localhost (Postfix, from userid 510) id 9C27680002; Thu, 02 Jun 2005 07:28:16 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id DBFF13C008; Thu, 02 Jun 2005 07:28:14 +1000 (EST) Date: Wed, 01 Jun 2005 14:04:09 -0700 From: James Kempf Subject: Re: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli , Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <02bc01c566f0$fc15abb0$5a6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <10e14db205060107534e9cae40@mail.gmail.com> Content-Transfer-Encoding: 7BIT > The FastRA method should have been a seperate draft, unless we are going to > have a single DNA solution. > Right, so what is planned on this? Is there going to be a discussion about whether more than one solution is needed? Whether people want more than one? Currently, I believe we have two. jak From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 18:47:45 2005 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 SAA17304 for ; Wed, 1 Jun 2005 18:47:44 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZA0TII3S9AO2PE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 08:46:57 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B719480005; Thu, 02 Jun 2005 08:46:54 +1000 (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 66FD83C003; Thu, 02 Jun 2005 08:46:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51MkWA27879 for dna-list; Thu, 02 Jun 2005 08:46:32 +1000 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 j51MkVr27875 for ; Thu, 02 Jun 2005 08:46:31 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZA02B2AK99JM8T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 08:46:18 +1000 Received: by localhost (Postfix, from userid 510) id 3D774AB544; Thu, 02 Jun 2005 08:46:18 +1000 (EST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by curly.its.monash.edu.au (Postfix) with ESMTP id D3C8C4FB09 for ; Thu, 02 Jun 2005 08:46:15 +1000 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 02 Jun 2005 00:45:49 +0200 Date: Thu, 02 Jun 2005 00:45:48 +0200 From: NJEDJOU Eric RD-RESA-REN Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j51MkVr27876 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Thread-Topic: [DNA] Definition of "Link Up" and "Link Down" events? Thread-Index: AcVjyCc2fCIl/cN5TkOLXHriU+EP3wDLb64g Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 01 Jun 2005 22:45:49.0515 (UTC) FILETIME=[A83A61B0:01C566FB] Content-Transfer-Encoding: 8BIT I have a little problem with the most recent defintion (Bernard's) of Link-Down suggested. The statement "A Link Down event is only generated once the link layer considers the link unusable" looks (to me at least) a bit contradictory to the first sentence of the definition in the sense that the link layer can consider the link unusable even without any change having occured in the link state machine: PDP context activated in GPRS/UMTS but very high BER Said differently, the definition implies that the event cause can be "state changed" in the link layer state machine as well "state did not changed" (as the link can become unusable within the same state) which is a problem. Hope my concern is understood. Insn't "An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating IP packets. transient periods of high frame loss are not sufficient." enough for Link down definition? Please advice Eric Njedjou -----Message d'origine----- De : owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de Bernard Aboba Envoyé : samedi 28 mai 2005 22:58 À : dna@eng.monash.edu.au Objet : Re: [DNA] Definition of "Link Up" and "Link Down" events? Erik Nordmark wisely observed: > I think it would be good if the definitions would clarify that even if > the link layer on the host sees 100% packet loss for a short while, it > doesn't necessarily imply that a link down event should be generated. > (It presumably shouldn't be generated until the link layer abandons > the > L2 association/connection/whatever.) How about this? Link Down An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating IP packets. A Link Down event is only generated once the link layer considers the link unusable; transient periods of high frame loss are not sufficient. Link Up An event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating IP packets. From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 19:52:31 2005 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 TAA21357 for ; Wed, 1 Jun 2005 19:52:30 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZC9RDU3G94OD4F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 09:52:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 57D16AB544; Thu, 02 Jun 2005 09:51:23 +1000 (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 1698F4FB08; Thu, 02 Jun 2005 09:51:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j51Noil28571 for dna-list; Thu, 02 Jun 2005 09:50:44 +1000 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 j51Nohr28567 for ; Thu, 02 Jun 2005 09:50:43 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZC8KM11M99JRYI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 09:50:26 +1000 Received: by localhost (Postfix, from userid 510) id EC70DAB547; Thu, 02 Jun 2005 09:50:25 +1000 (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 1D2694FB0B; Thu, 02 Jun 2005 09:50:23 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j51NoKGJ014758; Wed, 01 Jun 2005 16:50:20 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j51NoELk398930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Jun 2005 16:50:20 -0700 (PDT) Date: Wed, 01 Jun 2005 16:50:33 -0700 From: Erik Nordmark Subject: Re: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) In-reply-to: <02bc01c566f0$fc15abb0$5a6015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Syam Madanapalli , Sathya Narayanan , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <429E49C9.3070701@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <10e14db205060107534e9cae40@mail.gmail.com> <02bc01c566f0$fc15abb0$5a6015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT James Kempf wrote: >>The FastRA method should have been a seperate draft, unless we are going to >>have a single DNA solution. >> > > > Right, so what is planned on this? Is there going to be a discussion about > whether more than one solution is needed? Whether people want more than one? > Currently, I believe we have two. I assume the desired result is that we end up with one overall solution to implement in hosts and routers, and not N different schemes, because that doesn't help with interoperability. However, in the overall solution I think the hosts this needs to have the ability to handle unmodified routers (for which we have CPL as the core piece on the table) and do something more efficient ("the solution") when the routers do the new DNA thing. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 20:57:20 2005 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 UAA24906 for ; Wed, 1 Jun 2005 20:57:19 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZEK187WC99JTQA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 10:57:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3812780007; Thu, 02 Jun 2005 10:56:56 +1000 (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 D1D013C00B; Thu, 02 Jun 2005 10:56:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j520uUZ29330 for dna-list; Thu, 02 Jun 2005 10:56:30 +1000 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 j520uUr29326 for ; Thu, 02 Jun 2005 10:56:30 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZEJ7HCA89AO0V9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 10:56:17 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 57D67AB547; Thu, 02 Jun 2005 10:56:16 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 16A394FB0F; Thu, 02 Jun 2005 10:56:16 +1000 (EST) Date: Thu, 02 Jun 2005 10:56:15 +1000 From: Greg Daley Subject: Re: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) In-reply-to: <429DFA6E.4090603@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Subba Reddy , dna@eng.monash.edu.au, Syam Madanpalli Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E592F.7040001@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <012601c56694$d7730700$39476c6b@sisodomain.com> <429DFA6E.4090603@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, I think we should fall back to RFC2461 ND behaviour in the bootstrap and responding router load cases. Please see below for my reasoning. Erik Nordmark wrote: > Subba Reddy wrote: [cut] > >> 2. While bootstrapping DNA data structures(section 5.1.3), a) will >> the router reply for RSs without landmark option (may be sent by >> other routers) b) will the router reply for RSs that contains >> landmark option (may be sent by DNA host) > > > I think the current text says that it will not respond at all. This is a > bit suboptimal when multiple routers boot at the same time. > I suspect we need to figure out how to tweak this. > Suggestions? If we respond as if we have an RFC2461 host, then any problems experienced will be the same as if a host has transitioned to a network not supporting DNA (except that it will have a link-layer hint to distinguish). It's a short0lived transient situation though. The additional trouble of blocking out responses can hamper initialization after failures. This is already well covered for fixed hosts within 2461 and should be taken advantage of. [cut] > >> 5. To deal with amplification effect, what about having a threshold >> on number of routers sending fast RA? For example, only first 5 >> routers (as per the fast RA rankings) only will reply for RSs (in >> addition to the method specified in the draft) > > > That might make sense. > > I assume the 6+ ranked routers would not be completely quiet, but > instead schedule a 3 second multicast RA. This is needed in the case > that the routers annouce different prefixes, and also to make the host > discover that it has >5 default routers. I think that we want to not make the system worse in the face of bogus routers. The existing RFC2461 behaviour is to perform random delay (0-500ms), multicast, and induce additional delay if the minimum multicast advertisement interval has not passed. I guess that's actually as effective as the Nth router 3 second delay, and is robust to fake routers. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 21:03:04 2005 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 VAA25255 for ; Wed, 1 Jun 2005 21:03:03 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZERDXD5G9AO2UF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 11:02:57 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E7BDF80005; Thu, 02 Jun 2005 11:02:51 +1000 (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 AAAA83C003; Thu, 02 Jun 2005 11:02:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5212kQ29458 for dna-list; Thu, 02 Jun 2005 11:02:46 +1000 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 j5212jr29452 for ; Thu, 02 Jun 2005 11:02:45 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZEQUQIQI94OI47@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 11:02:28 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 379FC80003; Thu, 02 Jun 2005 11:02:26 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id B3A063C003; Thu, 02 Jun 2005 11:02:25 +1000 (EST) Date: Thu, 02 Jun 2005 11:02:25 +1000 From: Greg Daley Subject: Re: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E5AA1.6030104@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Sathya, Sathya Narayanan wrote: > Greg - [cut] > No. > > Looks like there are two reasons why a host will not include a landmark option > (I thought about only the first): > 1) Host is a non-DNA host > 2) Host doesn't want to divulge their landmark > > The text in the draft is targetted at the first case, i.e. if the RS message > doesn't have a landmark option it is a non-DNA host. The only way to help out > the host is by sending a CompleteRA because the router doesn't not know what > question to answer. For a non-DNA host, a completeRA will be only partially helpful, > if it hasn't moved link and sees its current prefix in the completeRA in a PIO - > because it can neither recognize the completeRA bit nor the DNAO. Sending too-many > unicast CompleteRA with the hope that it is useful for the host is not good for > link-utilization and hence the recommendation. The question wasn't about completeRA, it was about FastRA. Non-DNA hosts aren't going to benefit from the RA's DNA content, but they are going to benefit from a fast response. So there really shouldn't be a problem with supplying fast response so long as the solicitation is compliant with the algorithm for delivering an RA quickly (has a source address, and can create, or already has an NCE). (Now visiting the CompleteRA without Landmark solicitation issue). > Now, I think, the same logic applies for the second case too, even though a DNA-host > could receive better benefit from the CompleteRA. The router has no-way of knowing > whether the sender is a dna-host or not. This is the essential point for completeRA without landmarks. Why doesn't it know? because without the landmark you can't tell that it's DNA capable. Fortunately, there are plenty of bits left in the RS header (32) which could be used to identify a DNA solicitation without divulging the last attached prefix of the host in a landmark option. Please be aware that I personally consider location privacy to be a 'big issue'. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 21:06:27 2005 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 VAA25437 for ; Wed, 1 Jun 2005 21:06:26 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZEV9749A99JTR8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 11:06:02 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 11221AB54C; Thu, 02 Jun 2005 11:05:59 +1000 (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 A24354FB0C; Thu, 02 Jun 2005 11:05:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5215tX29539 for dna-list; Thu, 02 Jun 2005 11:05:55 +1000 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 j5215sr29535 for ; Thu, 02 Jun 2005 11:05:54 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZEV4G35094OMUW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 11:05:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B706CAB545; Thu, 02 Jun 2005 11:05:52 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9872E4FB0C; Thu, 02 Jun 2005 11:05:52 +1000 (EST) Date: Thu, 02 Jun 2005 11:05:52 +1000 From: Greg Daley Subject: Re: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429D4C98.5040408@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E5B70.4090404@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D2F78.1000008@eng.monash.edu.au> <429D3919.8020709@eng.monash.edu.au> <429D3F94.8000807@eng.monash.edu.au> <429D4C98.5040408@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Brett Pentland wrote: > Greg Daley wrote: [cut] >> Can't the host use the prefixes learnt from the DNAO to not be >> surprised by prefixes in responding RAs (which may not be DNA RAs) >> to its existing solicitation? > > > Yes, but the DNA router responses would usually be received first, > and the non-DNA router responses would have to be dealt with using > CPL logic anyway, and shouldn't cause confusion. As you know, I'm not arguing against the possibility of leaving out the options per se, but I'd guess we were trying to avoid using CPL logic in most circumstances (wanting definitive identification, rather than implicit). If routers know there is limited cost to providing this, I guess that there's no reason to prohibit them. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 21:10:48 2005 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 VAA25701 for ; Wed, 1 Jun 2005 21:10:47 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZF0RP4KK9AO19R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 11:10:39 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F7A2AB547; Thu, 02 Jun 2005 11:10:25 +1000 (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 1525E4FB05; Thu, 02 Jun 2005 11:10:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j521AIf29629 for dna-list; Thu, 02 Jun 2005 11:10:18 +1000 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 j521AHr29625 for ; Thu, 02 Jun 2005 11:10:18 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZF0DU2KK977PQ9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 11:10:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3BDFFAB543; Thu, 02 Jun 2005 11:10:07 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 08D5E4FB0F; Thu, 02 Jun 2005 11:10:07 +1000 (EST) Date: Thu, 02 Jun 2005 11:10:06 +1000 From: Greg Daley Subject: Re: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) In-reply-to: <02bc01c566f0$fc15abb0$5a6015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Syam Madanapalli , Sathya Narayanan , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E5C6E.7030100@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <10e14db205060107534e9cae40@mail.gmail.com> <02bc01c566f0$fc15abb0$5a6015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>The FastRA method should have been a seperate draft, unless we are going > > to > >>have a single DNA solution. >> > > > Right, so what is planned on this? Is there going to be a discussion about > whether more than one solution is needed? Whether people want more than one? > Currently, I believe we have two. I believed that at the last IETF the rough consensus was that there will eventually be one solution, which must be selected by the WG (with expertise from the DT to assist). There's only one solutions document on the charter of the WG. So I guess I don't see the need for a separate 'Fast RA' document at the moment. That's not to say that draft-pentland-dna-protocol is the complete solution just because Hash Based FastRA is defined there (for example). The Fast RA scheme is sound regardless of whether landmarks or completeRA are used. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 21:11:14 2005 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 VAA25756 for ; Wed, 1 Jun 2005 21:11:13 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZF1HOCFO99JT5X@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 11:11:03 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B6791AB54E; Thu, 02 Jun 2005 11:11:00 +1000 (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 D0B434FB08; Thu, 02 Jun 2005 11:10:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j521Avk29659 for dna-list; Thu, 02 Jun 2005 11:10:57 +1000 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 j521Aur29654 for ; Thu, 02 Jun 2005 11:10:56 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZF141YSQ99JS6B@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 11:10:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7932EAB545; Thu, 02 Jun 2005 11:10:42 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5B5F84FB05; Thu, 02 Jun 2005 11:10:42 +1000 (EST) Date: Thu, 02 Jun 2005 11:10:42 +1000 From: Greg Daley Subject: Re: [DNA] Re: No FastRA unless Landmark? (draft-pentland-dna-protocol-00) In-reply-to: <429DE620.9000006@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E5C92.1040404@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D3A90.6070309@eng.monash.edu.au> <429D3B57.7000504@eng.monash.edu.au> <429DE620.9000006@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> "If the source address of the RS is NOT the unspecified address, >> AND the RS message contains a Landmark option, the router consumes >> one unicast send token and then builds a Router Advertisement as >> follows:" >> >> >> It would be good to know why Hash Based Fast RA (based on the >> source address only) requires the Landmark Option. > > > I don't think it does. The current text might just reflect the focus on > the most important cases, and also tries to limit the number of cases. > > But the fastRA decision could be made to be orthogonal to the content of > the RA (i.e. whether there is a LO or not). Thanks for clarifying. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 21:23:21 2005 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 VAA26510 for ; Wed, 1 Jun 2005 21:23:20 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZFFM5IVW977SXF@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 11:23:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D7EE180004; Thu, 02 Jun 2005 11:22:23 +1000 (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 7D6F13C006; Thu, 02 Jun 2005 11:22:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j521MEv29846 for dna-list; Thu, 02 Jun 2005 11:22:14 +1000 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 j521MEr29842 for ; Thu, 02 Jun 2005 11:22:14 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZFFBP5L699JXD1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 11:22:10 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EB23CAB543; Thu, 02 Jun 2005 11:22:09 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id CAA4E4FB0B; Thu, 02 Jun 2005 11:22:09 +1000 (EST) Date: Thu, 02 Jun 2005 11:22:09 +1000 From: Greg Daley Subject: Re: [DNA] MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429DF5E5.9090400@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E5F41.5060607@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D2DFC.1080806@eng.monash.edu.au> <429DF5E5.9090400@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: [cut] >> 3. Valid lifetime >> >> 4. Time last refreshed" >> >> In my (existing) implementation I'm storing the expiry time >> of the prefix (which is calculated based on the valid lifetime >> at the RA reception time). > > > Is this for #3 above? Are you also storing #4? I think that the issue was basically that the term "store" means "allocate space for" to me. When that's combined with a MUST, I have to change data structures... >> Is this insufficient? > > > Storing the expiry time for the valid lifetime is what's needed for #3. Ok. That clarifies things. [cut] > > The intent is to provide enough *conceptual* data structure descriptions > so that the protocol can be described in detail, but not constrain how > an implementation actual does things as long as the externally visible > behavior of the implementation is consistent with the specification. > > There is text in section 5 in RFC 2461 which says this, so perhaps we > can just borrow that text. I see (in 5.1 conceptual data structures). "Prefix List entries are created from information received in Router Advertisements. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid" This approach sounds good to me. Thanks, Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 21:35:23 2005 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 VAA27086 for ; Wed, 1 Jun 2005 21:35:22 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZFV8WQ3Y9AO2VB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 11:35:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1731DAB545; Thu, 02 Jun 2005 11:35:00 +1000 (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 B47624FB14; Thu, 02 Jun 2005 11:34:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j521Ymr30022 for dna-list; Thu, 02 Jun 2005 11:34:48 +1000 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 j521Ylr30018 for ; Thu, 02 Jun 2005 11:34:47 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZFUM7T3E9781O6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 11:34:30 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 96F71AB543; Thu, 02 Jun 2005 11:34:29 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 782354FB02; Thu, 02 Jun 2005 11:34:29 +1000 (EST) Date: Thu, 02 Jun 2005 11:34:28 +1000 From: Greg Daley Subject: Re: [DNA] leaving out options on Landmark RA = Yes (draft-pentland-dna-protocol-00.txt)? In-reply-to: <429DF774.6060909@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E6224.70402@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D3EFD.1080500@eng.monash.edu.au> <429DF774.6060909@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> Comment: >> >> The descriptions here ignore SEND options, which need to be included >> if SEND is used. This will increase the size of the RA. > > > Probably. > I haven't looked at exactly what SEND information would be needed in the > different cases of an RA being sent. > If the host didn't move, the RAs will in most cases be sent from routers > that the host has previously received RAs from, thus the SEND > information can be minimized. > But when the landmark indicates that the host has moved it makes sense > for the RAs to include more SEND information if that makes a SEND host > complete the movement faster. > > Is anybody looking at the details of how SEND and DNA can interact > efficiently? Not really, but here's the minimum required (which may violate SEND, but should be OK in this situation): For a solicited RA Landmark=yes: Nonce(8/16), Timestamp(16), RSA Signature (big). This assumes that the host has seen this Router's RA before, and has given its trust chain to the host. If this is insufficient, then CCS/CCA exchange may occur, as well as NS/NA to get the CGA options... The host will have to have seen at least one DNA router on the link though, so it may be possible to wait until another RA from a trusted router arrives from the same RS. For a Solicited RA, Landmark=No: Nonce(8/16), Timestamp (16), CGA Option (big), RSA Signature (big). Additional exchange of certificate chains may be required in order to create trust with the router, if the host has never visited it before (or doesn't remember it). As far as I can see, to achieve SEND's full replay protection you can't do any better than this. >> Question: >> >> Can we have standards language for this? >> >> There's no flexibility in the description of what options are >> able to be included in the "Yes" Landmark. That sounds like a >> MUST NOT include other PIO, DNAO. etc. > > > In think the text in section 3 is fine with its use of English, because > it tries to introduce the concepts by saying what typically happens. > But in the core of the draft it makes sense being more specific. That makes sense. >> Personally, I'd prefer something saying something like >> >> "RAs with the 'Yes' Flag set in a Landmark option MAY leave out all >> configuration related options such as PIOs, DNAOs, Advertisement >> Intervals etc, since this information is assumed to have >> already been received to be able to construct a matching >> Landmark Router Solicitation". >> >> I'd prefer MAY to SHOULD or MUST, since it's an optimization, >> and the presence of additional options doesn't harm hosts. > > > My gut feel is that we should make it a SHOULD NOT, because the host > doesn't have any need for this extra stuff, and one of the DNA goals is > to be efficient. OK. >> In RADVD, it's easier for me to not remove the other options >> in the RA just because the Landmark option Yes flag is set. > > > And the purpose of a SHOULD NOT would be to make you do the work :-), so > that we can get an efficient way to do DNA. That's OK. My initial work will try to get things going without the benefits of efficient RA sizing (so long as it's compliant - which is why I'm asking questions). Subsequently I'll add an AbbrevAdvertisement option (defaulting to on) which should cover the Landmark=No and Landmark=Yes cases. That may take a couple of extra days... :) Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 21:44:41 2005 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 VAA27445 for ; Wed, 1 Jun 2005 21:44:40 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZG7FB9Z49AO23D@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 11:44:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 38CF180003; Thu, 02 Jun 2005 11:44:02 +1000 (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 CC62A3C00C; Thu, 02 Jun 2005 11:44:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j521htX30167 for dna-list; Thu, 02 Jun 2005 11:43:55 +1000 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 j521hsr30163 for ; Thu, 02 Jun 2005 11:43:54 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZG6XVNT499J6CS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 11:43:39 +1000 Received: by localhost (Postfix, from userid 510) id D5B63AB544; Thu, 02 Jun 2005 11:43:38 +1000 (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 ABD384FB0B; Thu, 02 Jun 2005 11:43:36 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j521hZ3E005943; Wed, 01 Jun 2005 21:43:35 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 9098F1EC0C9; Wed, 01 Jun 2005 21:35:21 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 864861EBE04; Wed, 01 Jun 2005 21:35:21 -0400 (EDT) Received: from [68.39.6.87] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Wed, 01 Jun 2005 21:43:34 -0400 Date: Wed, 01 Jun 2005 21:43:34 -0400 From: Sathya Narayanan Subject: Re: [DNA] No FastRA unless Landmark?(draft-pentland-dna-protocol-00) Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:44.66086 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) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg - > > The question wasn't about completeRA, it was about FastRA. Yes - I understand (understood) this, but I was thinking without a completeRA the hosts will not be able to really answer the 'Link change question' - please see below. > Non-DNA hosts aren't going to benefit from the RA's DNA content, > but they are going to benefit from a fast response. I guess, here is the problem in my understanding - do the non-DNA hosts really benefit from receiving fastRA that is NOT complete. What would you like to include in these RA messages? Including all PIOs may help - atleast if there was no link change, because the host will see a prefix it is using in one of the RA messages. If there was a link change, the non-DNA host will still have to wait for MAX_RA_DELAY_TIME before they decide that they have moved, which is still better than waiting for the multicast. This is a cost-benefit question, is it worth the extra messages to support non-DNA hosts? I don't have an opinion on this. > (Now visiting the CompleteRA without Landmark solicitation issue). > > Why doesn't it know? because without the landmark you can't tell that it's DNA capable. > > Fortunately, there are plenty of bits left in the RS header (32) > which could be used to identify a DNA solicitation without divulging > the last attached prefix of the host in a landmark option. Yeah - we can do this. We just need to be aware that sending unicast-completeRA at fastRA rate from all routers for every received RS message makes the amplification effect more deadly. > > Please be aware that I personally consider location privacy to be a 'big issue'. I don't understand this concern. When a IPv6 hosts transmits IPv6 packets on the network wouldn't its IPv6 address become public immediately - or when it responds to NS message for that matter - what information are you trying to protect by not including a landmark option in the RS message. Please explain. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 22:02:05 2005 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 WAA28551 for ; Wed, 1 Jun 2005 22:02:04 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZGSGQNFI99JWV9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 12:01:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 03436AB54B; Thu, 02 Jun 2005 12:01:00 +1000 (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 AC91D4FB03; Thu, 02 Jun 2005 12:00:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5220YA30403 for dna-list; Thu, 02 Jun 2005 12:00:34 +1000 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 j5220Yr30399 for ; Thu, 02 Jun 2005 12:00:34 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZGRLJXY094OLUC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 12:00:19 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 38D1580002; Thu, 02 Jun 2005 12:00:18 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1306D3C00F; Thu, 02 Jun 2005 12:00:18 +1000 (EST) Date: Thu, 02 Jun 2005 12:00:12 +1000 From: Greg Daley Subject: Re: [DNA] No FastRA unless Landmark?(draft-pentland-dna-protocol-00) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E682C.2010609@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Sathya, Sathya Narayanan wrote: > Greg - [cut] > > Including all PIOs may help - atleast if there was no link change, because the > host will see a prefix it is using in one of the RA messages. If there was a > link change, the non-DNA host will still have to wait for MAX_RA_DELAY_TIME > before they decide that they have moved, which is still better than waiting > for the multicast. This is a cost-benefit question, is it worth the extra > messages to support non-DNA hosts? I don't have an opinion on this. I think you're assuming that they employ lazy cell switching. There are various heuristics already available in the research and implementation spaces (MIPv6 is a PS...). Additionally, the host may have other reasons to believe link change is required, even if it was implemented before DNA is standardized (such as it uses FMIPv6, or is on a particular access technology). We don't need to force devices to change (O/S) code in order to provide them with a useful service. > > >>(Now visiting the CompleteRA without Landmark solicitation issue). > > > >>Why doesn't it know? because without the landmark you can't tell that it's DNA capable. >> >>Fortunately, there are plenty of bits left in the RS header (32) >>which could be used to identify a DNA solicitation without divulging >>the last attached prefix of the host in a landmark option. > > > Yeah - we can do this. We just need to be aware that sending unicast-completeRA > at fastRA rate from all routers for every received RS message makes the > amplification effect more deadly. It really depends on the tokens and how they're used. If a token provides ABC (appropriate byte counting), then the transmission of a message with completeRA would diminish the number of RA messages to be sent. This in effect would mean that peak FastRA bandwidth would be prescribed. > >>Please be aware that I personally consider location privacy to be a 'big issue'. > > > I don't understand this concern. When a IPv6 hosts transmits IPv6 packets on > the network wouldn't its IPv6 address become public immediately - or when it > responds to NS message for that matter - what information are you trying to > protect by not including a landmark option in the RS message. Please explain. How about if I used a different MAC address and IPv6 address (+key?) to do DNA every time I got a link up indication? If I was on the same link, I could go back to my existing identity. This temporary identity couldn't be tied back to my existing identity. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 22:06:22 2005 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 WAA28750 for ; Wed, 1 Jun 2005 22:06:21 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZGYBD10Y9AO0J2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 12:05:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 21F13AB542; Thu, 02 Jun 2005 12:05:43 +1000 (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 CB59F4FB04; Thu, 02 Jun 2005 12:05:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5225bG30514 for dna-list; Thu, 02 Jun 2005 12:05:37 +1000 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 j5225ar30510 for ; Thu, 02 Jun 2005 12:05:36 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZGXTKBWQ9771GB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 12:05:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 360CAAB543; Thu, 02 Jun 2005 12:05:19 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 158D34FB06; Thu, 02 Jun 2005 12:05:19 +1000 (EST) Date: Thu, 02 Jun 2005 12:05:13 +1000 From: Greg Daley Subject: Re: [DNA] leaving out options on Landmark RA =Yes(draft-pentland-dna-protocol-00.txt)? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E6959.5060502@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Sathya, Sathya Narayanan wrote: > Greg - > > Under the assumption that the 'Yes' case is more likely, i.e. > the ratio AP/AR is big, it makes sense to emphasize the > importance of this optimization by making it a MUST/SHOULD, IMHO. > With the size of PIOs, possibly many of them and wireless > channels etc., there is possibly significant savings in > link-utilization. I think it is a fairly important issue (since people took the patience to explain it to me). So I think a SHOULD (limit the options) is OK. IMO, MUST is really for a) Interoperability (as per RFC2119) b) preventing damage to the network. The damage is light here particularly for media like Wireless LAN where the rate of messages is more important than their size. I can't see a reason to say MUST in this case. SHOULD is still a strong statement in IETF. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 22:13:06 2005 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 WAA03202 for ; Wed, 1 Jun 2005 22:13:05 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZH6Z76LQ94MRHX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 12:13:00 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2043EAB542; Thu, 02 Jun 2005 12:12:42 +1000 (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 C278E4FB0A; Thu, 02 Jun 2005 12:12:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j522CWP30636 for dna-list; Thu, 02 Jun 2005 12:12:32 +1000 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 j522CWr30632 for ; Thu, 02 Jun 2005 12:12:32 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZH6IJF6A99JTQL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 12:12:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B8C6980006; Thu, 02 Jun 2005 12:12:19 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 160FE3C004; Thu, 02 Jun 2005 12:12:19 +1000 (EST) Date: Thu, 02 Jun 2005 12:12:18 +1000 From: Greg Daley Subject: Re: [DNA] MUST NOT add DNA Option when landmark RA = NO? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429DF81C.2000609@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E6B02.1010005@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D2F78.1000008@eng.monash.edu.au> <429D3919.8020709@eng.monash.edu.au> <429D3F94.8000807@eng.monash.edu.au> <429DF81C.2000609@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> Can't the host use the prefixes learnt from the DNAO to not be >> surprised by prefixes in responding RAs (which may not be DNA RAs) >> to its existing solicitation? > > > What did you have in mind the host would actually do to be "less > surprised"? I'm still cooking something, but to talk now on list wouldn't really help the discussion Please contact me if it's important to know now. > If it records the DNAO prefix somehow, what would it then do when it > - receives an RA with a prefix which was recorded from the DNAO It would be able to tell they belong to the same link. > - receives an RA with a new prefix which was not recorded from a DNAO? That depends... If it was 'surprised' I guess it would be treated as a hint of change (like in CPL). I think it's possible to do better than CPL with the learning phase though (since you have an explicit CPL in the CompleteRA). > FWIW the conceptual data structures in RFC 2461 can only capture > prefixes for which all the information in the PIO is present, i.e. the > lifetimes and the flags must be includes. Yes, that's right. It's not necessary to use exactly these data structures, though if you're not using them for address configuration, just for link identification. (Though the link identification logic could be assisted if you knew them). Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 23:20:45 2005 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 XAA05044 for ; Wed, 1 Jun 2005 23:20:44 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZJJR9YRY9AO17N@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 13:20:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 49BDA80002; Thu, 02 Jun 2005 13:20:16 +1000 (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 09AC53C003; Thu, 02 Jun 2005 13:20:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j523JrF31388 for dna-list; Thu, 02 Jun 2005 13:19:53 +1000 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 j523Jqr31383 for ; Thu, 02 Jun 2005 13:19:52 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZJJ3T7N094OSFL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 13:19:45 +1000 Received: by localhost (Postfix, from userid 510) id D5A4BAB543; Thu, 02 Jun 2005 13:19:44 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0DB504FB0A for ; Thu, 02 Jun 2005 13:19:42 +1000 (EST) Date: Wed, 01 Jun 2005 20:20:36 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: NJEDJOU Eric RD-RESA-REN , Bernard Aboba , dna@eng.monash.edu.au Message-id: <004f01c56722$116afb60$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: Content-Transfer-Encoding: 7BIT Eric, I have a little problem with the most recent defintion (Bernard's) of Link-Down suggested. The statement "A Link Down event is only generated once the link layer considers the link unusable" looks (to me at least) a bit contradictory to the first sentence of the definition in the sense that the link layer can consider the link unusable even without any change having occured in the link state machine: PDP context activated in GPRS/UMTS but very high BER Said differently, the definition implies that the event cause can be "state changed" in the link layer state machine as well "state did not changed" (as the link can become unusable within the same state) which is a problem. Hope my concern is understood. Insn't "An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating IP packets. transient periods of high frame loss are not sufficient." enough for Link down definition? Please advice jak>> I guess I don't understand the problem. The definition leaves it up to the link layer to decide what "unusable" means. Whether or not that involves a state machine change or some other consideration is pretty much up to the link layer to decide. jak From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 1 23:57:44 2005 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 XAA07460 for ; Wed, 1 Jun 2005 23:57:43 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZKUSBUPC99JW07@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 13:57:32 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 51AA0AB54B; Thu, 02 Jun 2005 13:57:24 +1000 (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 E365B4FB09; Thu, 02 Jun 2005 13:57:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j523ubx31793 for dna-list; Thu, 02 Jun 2005 13:56:37 +1000 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 j523uZr31789 for ; Thu, 02 Jun 2005 13:56:36 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZKTGW4Z89AO30T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 13:56:20 +1000 Received: by localhost (Postfix, from userid 510) id B0B9080004; Thu, 02 Jun 2005 13:56:20 +1000 (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 C7A283C009; Thu, 02 Jun 2005 13:56:18 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j523uHv1012211; Wed, 01 Jun 2005 23:56:17 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 1DD981EC166; Wed, 01 Jun 2005 23:48:04 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 1324F1E8180; Wed, 01 Jun 2005 23:48:04 -0400 (EDT) Received: from [68.39.6.87] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Wed, 01 Jun 2005 23:56:17 -0400 Date: Wed, 01 Jun 2005 23:56:17 -0400 From: Sathya Narayanan Subject: Re: [DNA] leaving out options on LandmarkRA=Yes(draft-pentland-dna-protocol-00.txt)? Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT > Hi Sathya, > > Sathya Narayanan wrote: > > Greg - > > > > Under the assumption that the 'Yes' case is more likely, i.e. > > the ratio AP/AR is big, it makes sense to emphasize the > > importance of this optimization by making it a MUST/SHOULD, IMHO. > > With the size of PIOs, possibly many of them and wireless > > channels etc., there is possibly significant savings in > > link-utilization. > > I think it is a fairly important issue (since people took > the patience to explain it to me). > > So I think a SHOULD (limit the options) is OK. OK. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 00:07:04 2005 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 AAA07798 for ; Thu, 2 Jun 2005 00:07:03 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZL49RNK494OUJG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 14:05:43 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F1B34AB544; Thu, 02 Jun 2005 14:05:02 +1000 (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 A8AC44FB02; Thu, 02 Jun 2005 14:05:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5244nW31943 for dna-list; Thu, 02 Jun 2005 14:04:49 +1000 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 j5244nr31939 for ; Thu, 02 Jun 2005 14:04:49 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZL3NKPNS9AO310@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 14:04:33 +1000 Received: by localhost (Postfix, from userid 510) id 6276A80003; Thu, 02 Jun 2005 14:04:33 +1000 (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 5B6BB3C009; Thu, 02 Jun 2005 14:04:32 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j5244VWI012330; Thu, 02 Jun 2005 00:04:31 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id A1AEA1EC8F3; Wed, 01 Jun 2005 23:56:17 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 966581E8180; Wed, 01 Jun 2005 23:56:17 -0400 (EDT) Received: from [68.39.6.87] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Thu, 02 Jun 2005 00:04:31 -0400 Date: Thu, 02 Jun 2005 00:04:31 -0400 From: Sathya Narayanan Subject: Re: [DNA] No FastRA unlessLandmark?(draft-pentland-dna-protocol-00) Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 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) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg - > > > >>Why doesn't it know? because without the landmark you can't tell > that it's DNA capable. > >> > >>Fortunately, there are plenty of bits left in the RS header (32) > >>which could be used to identify a DNA solicitation without divulging > >>the last attached prefix of the host in a landmark option. > > > > > > Yeah - we can do this. We just need to be aware that sending unicast-completeRA > > at fastRA rate from all routers for every received RS message makes the > > amplification effect more deadly. > > It really depends on the tokens and how they're used. If a token > provides ABC (appropriate byte counting), then the transmission of > a message with completeRA would diminish the number of RA messages to be sent. Are you suggesting we change the token-bucket behavior to do ABC? I am not very comfortable with it - but I should think more about it. > > > >>Please be aware that I personally consider location privacy to be a 'big issue'. > > > > > > I don't understand this concern. When a IPv6 hosts transmits IPv6 packets on > > the network wouldn't its IPv6 address become public immediately - or when it > > responds to NS message for that matter - what information are you trying to > > protect by not including a landmark option in the RS message. Please explain. > > How about if I used a different MAC address and IPv6 address (+key?) > to do DNA every time I got a link up indication? > > If I was on the same link, I could go back to my existing identity. > > This temporary identity couldn't be tied back to my existing identity. Hmmmm - thats interesting. I understand. But, since the landmark is only the prefix and not the whole address, you are still not revealing your whole identity - isn't that enough? Or is there use-cases where you don't even want to reveal the prefix you are using? Even though the text suggests (with a MUST) in section 5.2.2 to select a prefix being used for its non-link-local address, it is not necessary to keep it as a MUST. We could relax that condition to a SHOULD - will that help with the privacy issue since the host could always chose a different prefix as the landmark. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 00:26:28 2005 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 AAA09083 for ; Thu, 2 Jun 2005 00:26:26 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZLUA6EFC99JMMF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 14:26:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 43CA8AB54B; Thu, 02 Jun 2005 14:26:01 +1000 (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 CD9604FB05; Thu, 02 Jun 2005 14:26:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j524Pad32282 for dna-list; Thu, 02 Jun 2005 14:25:36 +1000 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 j524PZr32278 for ; Thu, 02 Jun 2005 14:25:35 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZLTBRU0Y977YIK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 14:25:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1BF73AB54B; Thu, 02 Jun 2005 14:25:15 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id CC0F34FB03; Thu, 02 Jun 2005 14:25:14 +1000 (EST) Date: Thu, 02 Jun 2005 14:25:08 +1000 From: Greg Daley Subject: Re: [DNA] No FastRA unlessLandmark?(draft-pentland-dna-protocol-00) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429E8A24.50407@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Sathya, Sathya Narayanan wrote: [cut] > > Are you suggesting we change the token-bucket behavior to do ABC? I am not > very comfortable with it - but I should think more about it. OK. I was not suggesting we immediately adopt ABC, but if there's a need to distinguish between RAs with content and those without, I guess there's a potential way to do so. RFC 3465 is only 10 pages and TCP's aim in ABC is similar (self-pacing data into the network, where packet sizes vary), so it should be possible to evaluate its applicability to DNA if we need the distinction. >>>>Please be aware that I personally consider location privacy to be a 'big issue'. >>> >>> >>>I don't understand this concern. When a IPv6 hosts transmits IPv6 packets on >>>the network wouldn't its IPv6 address become public immediately - or when it >>>responds to NS message for that matter - what information are you trying to >>>protect by not including a landmark option in the RS message. Please explain. >> >>How about if I used a different MAC address and IPv6 address (+key?) >>to do DNA every time I got a link up indication? >> >>If I was on the same link, I could go back to my existing identity. >> >>This temporary identity couldn't be tied back to my existing identity. > > > Hmmmm - thats interesting. I understand. But, since the landmark is only the prefix > and not the whole address, you are still not revealing your whole identity - > isn't that enough? Or is there use-cases where you don't even want to reveal > the prefix you are using? If the user community is small enough on the previous link, the timing of your last packet receptions combined with the prefix from that link can create a pseudo-identifier. These pseudo-identifiers can be tracked across link boundaries, and can prevent movement and location-identity(if the identity was revealed on a previous or future link) privacy. > Even though the text suggests (with a MUST) in section 5.2.2 to select a > prefix being used for its non-link-local address, it is not necessary to > keep it as a MUST. We could relax that condition to a SHOULD - will that > help with the privacy issue since the host could always chose a different > prefix as the landmark. Yes, that would help too. If there's a need to distinguish DNA and non DNA hosts, we'd still need either a DNA bit in the RS or a landmark. If a host wanted a high likelihood NO, and still to be able to (without SEND nonces) it could even craft a nonsense landmark, this would remove the need for the bit. I'm not sure if that would be necessary though. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 00:50:56 2005 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 AAA10609 for ; Thu, 2 Jun 2005 00:50:55 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZMNGGWEK9778J9@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 14:49:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AF61480003; Thu, 02 Jun 2005 14:48:45 +1000 (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 5D44F3C008; Thu, 02 Jun 2005 14:48:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j524kSl32523 for dna-list; Thu, 02 Jun 2005 14:46:28 +1000 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 j524kRr32519 for ; Thu, 02 Jun 2005 14:46:27 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZMKGQQJU9AO12V@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 14:46:21 +1000 Received: by localhost (Postfix, from userid 510) id 14F6B80004; Thu, 02 Jun 2005 14:46:21 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5E68E3C007 for ; Thu, 02 Jun 2005 14:46:19 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHF00E25X7XUH@mailout2.samsung.com> for dna@eng.monash.edu.au; Thu, 02 Jun 2005 13:45:33 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHF00MKZX7T9Q@mmp1.samsung.com> for dna@eng.monash.edu.au; Thu, 02 Jun 2005 13:45:33 +0900 (KST) Date: Thu, 02 Jun 2005 10:13:16 +0530 From: Subba Reddy Subject: Re: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au, Syam Madanpalli Message-id: <00bc01c5672d$9a16ec70$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <012601c56694$d7730700$39476c6b@sisodomain.com> <429DFA6E.4090603@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Thanks for input. Please see below... > Subba Reddy wrote: > > Hi, > > > > few comments and questions on the DNAv6 draft. > > 2. While bootstrapping DNA data structures(section 5.1.3), a) will > > the router reply for RSs without landmark option (may be sent by > > other routers) b) will the router reply for RSs that contains > > landmark option (may be sent by DNA host) > > I think the current text says that it will not respond at all. This is a > bit suboptimal when multiple routers boot at the same time. > I suspect we need to figure out how to tweak this. > Suggestions? > I think, it may be better to reply with normal RA (like RFC 2461) during bootstrapping. With this, If more than one router is bootstrapping, routers can know each others prefixes. It may help even the hosts to learn the prefixes of the new router fast. > > 4. In section 5.2.4, > > > > ".....If the unicast Router Advertisement contains a Landmark option > > that matches the Landmark Option in the last transmitted Router > > Solicitation ....." > > > > Is a case where, a unicast router advertisement comes without > > landmark option is possible? (DNA routers which are bootstrapping may > > just send RA) If possible, some text which tells what to do in such > > cases may need to be added. > > We should probably say what to do in any case, since an existing RFC > 2461 router is free to unicast RAs (even if the RFC suggests to always > multicast them) > Yes. It may be better to add the text for this case. > > 5. To deal with amplification effect, what about having a threshold > > on number of routers sending fast RA? For example, only first 5 > > routers (as per the fast RA rankings) only will reply for RSs (in > > addition to the method specified in the draft) > > That might make sense. > > I assume the 6+ ranked routers would not be completely quiet, but > instead schedule a 3 second multicast RA. This is needed in the case > that the routers annouce different prefixes, and also to make the host > discover that it has >5 default routers. > Yes. 6+ ranked routers need to schedule the multicast even though token is available. > Erik > > Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 02:53:17 2005 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 CAA09908 for ; Thu, 2 Jun 2005 02:53:16 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZQZJVFXE977WRR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 16:53:13 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8C949AB545; Thu, 02 Jun 2005 16:53:02 +1000 (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 342864FB0A; Thu, 02 Jun 2005 16:53:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j526q8001413 for dna-list; Thu, 02 Jun 2005 16:52:08 +1000 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 j526q2r01409 for ; Thu, 02 Jun 2005 16:52:02 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZQXY58GM94OP4W@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 16:51:45 +1000 Received: by localhost (Postfix, from userid 510) id 426D880003; Thu, 02 Jun 2005 16:51:45 +1000 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) (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 518643C00C for ; Thu, 02 Jun 2005 16:51:43 +1000 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j526nD4W004767 for ; Thu, 02 Jun 2005 02:49:13 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j526n64W004520 for ; Thu, 02 Jun 2005 02:49:11 -0400 (EDT) Date: Thu, 02 Jun 2005 09:51:31 +0300 From: "Romascanu, Dan (Dan)" Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf , NJEDJOU Eric RD-RESA-REN , Bernard Aboba , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Definition of "Link Up" and "Link Down" events? Thread-Index: AcVnIh+rBCsBXpDdQyS7+mjsZuYy4wAHD1tw content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT I would like to draw again the attention of the group that IMO the use of 'IP packets' to define low link layer link Up / link Down events may not be appropriate. The 'capability of communicating IP packets' cannot be detected in some cases by lower link layers state machines . Regards, Dan > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > James Kempf > Sent: Thursday, June 02, 2005 6:21 AM > To: NJEDJOU Eric RD-RESA-REN; Bernard Aboba; dna@eng.monash.edu.au > Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? > > Eric, > > > I have a little problem with the most recent defintion > (Bernard's) of Link-Down suggested. The statement "A Link > Down event is only generated once the link layer considers > the link unusable" looks (to me at least) a bit contradictory > to the first sentence of the definition in the sense that the > link layer can consider the link unusable even without any > change having occured in the link state machine: PDP context > activated in GPRS/UMTS but very high BER Said differently, > the definition implies that the event cause can be "state > changed" in the link layer state machine as well "state did > not changed" (as the link can become unusable within the same > state) which is a problem. > > Hope my concern is understood. > > Insn't > "An event provided by the link layer that signifies a state > change associated with the interface no longer being capable > of communicating IP packets. transient periods of high frame > loss are not sufficient." enough for Link down definition? > > Please advice > > jak>> I guess I don't understand the problem. The definition > leaves it > jak>> up to > the link layer to decide what "unusable" means. Whether or > not that involves a state machine change or some other > consideration is pretty much up to the link layer to decide. > > jak > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 03:02:32 2005 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 DAA11346 for ; Thu, 2 Jun 2005 03:02:31 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZRA3EK74977HT4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 17:02:11 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E5E2C8000B; Thu, 02 Jun 2005 17:01:30 +1000 (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 E171F3C01E; Thu, 02 Jun 2005 17:01:29 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5271K701571 for dna-list; Thu, 02 Jun 2005 17:01:20 +1000 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 j5271Jr01563 for ; Thu, 02 Jun 2005 17:01:19 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZR9I355E99JRS7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 17:01:04 +1000 Received: by localhost (Postfix, from userid 510) id 07D56AB545; Thu, 02 Jun 2005 17:01:03 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id D64934FB07 for ; Thu, 02 Jun 2005 17:01:01 +1000 (EST) Date: Thu, 02 Jun 2005 00:01:56 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: "Romascanu, Dan (Dan)" , NJEDJOU Eric RD-RESA-REN , Bernard Aboba , dna@eng.monash.edu.au Message-id: <012401c56740$fd3f9e60$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: Content-Transfer-Encoding: 7BIT Dan, Then what would you suggest is the appropriate way to phrase this? jak ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "James Kempf" ; "NJEDJOU Eric RD-RESA-REN" ; "Bernard Aboba" ; Sent: Wednesday, June 01, 2005 11:51 PM Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? I would like to draw again the attention of the group that IMO the use of 'IP packets' to define low link layer link Up / link Down events may not be appropriate. The 'capability of communicating IP packets' cannot be detected in some cases by lower link layers state machines . Regards, Dan > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > James Kempf > Sent: Thursday, June 02, 2005 6:21 AM > To: NJEDJOU Eric RD-RESA-REN; Bernard Aboba; dna@eng.monash.edu.au > Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? > > Eric, > > > I have a little problem with the most recent defintion > (Bernard's) of Link-Down suggested. The statement "A Link > Down event is only generated once the link layer considers > the link unusable" looks (to me at least) a bit contradictory > to the first sentence of the definition in the sense that the > link layer can consider the link unusable even without any > change having occured in the link state machine: PDP context > activated in GPRS/UMTS but very high BER Said differently, > the definition implies that the event cause can be "state > changed" in the link layer state machine as well "state did > not changed" (as the link can become unusable within the same > state) which is a problem. > > Hope my concern is understood. > > Insn't > "An event provided by the link layer that signifies a state > change associated with the interface no longer being capable > of communicating IP packets. transient periods of high frame > loss are not sufficient." enough for Link down definition? > > Please advice > > jak>> I guess I don't understand the problem. The definition > leaves it > jak>> up to > the link layer to decide what "unusable" means. Whether or > not that involves a state machine change or some other > consideration is pretty much up to the link layer to decide. > > jak > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 03:02:51 2005 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 DAA11369 for ; Thu, 2 Jun 2005 03:02:50 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZRA5ZTBY94OODS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 17:02:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 39764AB546; Thu, 02 Jun 2005 17:01:36 +1000 (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 E7AE14FB0A; Thu, 02 Jun 2005 17:01:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5271Kd01573 for dna-list; Thu, 02 Jun 2005 17:01:20 +1000 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 j5271Jr01566 for ; Thu, 02 Jun 2005 17:01:19 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZR9QPUZY9AO013@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 17:01:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5A371AB545; Thu, 02 Jun 2005 17:01:15 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8DA714FB0B; Thu, 02 Jun 2005 17:01:14 +1000 (EST) Date: Thu, 02 Jun 2005 17:01:08 +1000 From: Greg Daley Subject: Re: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) In-reply-to: <00bc01c5672d$9a16ec70$39476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: Erik Nordmark , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429EAEB4.7090807@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <012601c56694$d7730700$39476c6b@sisodomain.com> <429DFA6E.4090603@sun.com> <00bc01c5672d$9a16ec70$39476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Subba, Subba Reddy wrote: [cut] > > > Yes. 6+ ranked routers need to schedule the multicast even though token > is available. I guess it would be a host configurable threshold. In general, I can't see a use for more than three Fast RAs (unless there are problems with the timing of the first three RAs - for example due to SEND signature computation). How about we have fastra_threshold defaulting to FASTRA_THRESHOLD (3). if fastra_threshold < Rank (given that Rank starts at #0), then a Fast RA is scheduled at Rank * RASeparation. Otherwise, the token is put back in the bucket and a multicast RA is scheduled? Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 03:13:34 2005 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 DAA12123 for ; Thu, 2 Jun 2005 03:13:33 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZRNFF2WC99JXR7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 17:12:30 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B54BBAB54D; Thu, 02 Jun 2005 17:12:11 +1000 (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 6ABCB4FB03; Thu, 02 Jun 2005 17:12:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j527C2q01779 for dna-list; Thu, 02 Jun 2005 17:12:02 +1000 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 j527C1r01775 for ; Thu, 02 Jun 2005 17:12:01 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZRN2JCIW9780SX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 17:12:00 +1000 Received: by localhost (Postfix, from userid 510) id 768F4AB545; Thu, 02 Jun 2005 17:12:00 +1000 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 4AD164FB07 for ; Thu, 02 Jun 2005 17:11:58 +1000 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5279R4W004208 for ; Thu, 02 Jun 2005 03:09:28 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5279K4W004041 for ; Thu, 02 Jun 2005 03:09:26 -0400 (EDT) Date: Thu, 02 Jun 2005 10:11:44 +0300 From: "Romascanu, Dan (Dan)" Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf , NJEDJOU Eric RD-RESA-REN , Bernard Aboba , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Definition of "Link Up" and "Link Down" events? Thread-Index: AcVnQPaH3tVXFv10SPOg18mjq28qtgAANSVg content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT I would just refer to the capability of passing packets, without mentioning IP. This is the approach taken by RFC 2863. Regards, Dan > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, June 02, 2005 10:02 AM > To: Romascanu, Dan (Dan); NJEDJOU Eric RD-RESA-REN; Bernard > Aboba; dna@eng.monash.edu.au > Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? > > Dan, > > Then what would you suggest is the appropriate way to phrase this? > > jak > > > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "James Kempf" ; "NJEDJOU Eric > RD-RESA-REN" > ; "Bernard Aboba" > ; > Sent: Wednesday, June 01, 2005 11:51 PM > Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? > > > I would like to draw again the attention of the group that IMO the use > of 'IP packets' to define low link layer link Up / link Down > events may > not be appropriate. The 'capability of communicating IP > packets' cannot > be detected in some cases by lower link layers state machines . > > Regards, > > Dan > > > > > -----Original Message----- > > From: owner-dna@ecselists.eng.monash.edu.au > > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > > James Kempf > > Sent: Thursday, June 02, 2005 6:21 AM > > To: NJEDJOU Eric RD-RESA-REN; Bernard Aboba; dna@eng.monash.edu.au > > Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? > > > > Eric, > > > > > > I have a little problem with the most recent defintion > > (Bernard's) of Link-Down suggested. The statement "A Link > > Down event is only generated once the link layer considers > > the link unusable" looks (to me at least) a bit contradictory > > to the first sentence of the definition in the sense that the > > link layer can consider the link unusable even without any > > change having occured in the link state machine: PDP context > > activated in GPRS/UMTS but very high BER Said differently, > > the definition implies that the event cause can be "state > > changed" in the link layer state machine as well "state did > > not changed" (as the link can become unusable within the same > > state) which is a problem. > > > > Hope my concern is understood. > > > > Insn't > > "An event provided by the link layer that signifies a state > > change associated with the interface no longer being capable > > of communicating IP packets. transient periods of high frame > > loss are not sufficient." enough for Link down definition? > > > > Please advice > > > > jak>> I guess I don't understand the problem. The definition > > leaves it > > jak>> up to > > the link layer to decide what "unusable" means. Whether or > > not that involves a state machine change or some other > > consideration is pretty much up to the link layer to decide. > > > > jak > > > > > > > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 03:22:58 2005 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 DAA13484 for ; Thu, 2 Jun 2005 03:22:57 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZS13R0QC977RDP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 17:22:44 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4F78EAB542; Thu, 02 Jun 2005 17:22:32 +1000 (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 04D184FB08; Thu, 02 Jun 2005 17:22:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j527MPf01936 for dna-list; Thu, 02 Jun 2005 17:22:25 +1000 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 j527MNr01932 for ; Thu, 02 Jun 2005 17:22:23 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZS0SE5YG94OU09@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 17:22:17 +1000 Received: by localhost (Postfix, from userid 510) id 18883AB542; Thu, 02 Jun 2005 17:22:17 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id BBC054FB0C for ; Thu, 02 Jun 2005 17:22:14 +1000 (EST) Date: Thu, 02 Jun 2005 00:23:08 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: "Romascanu, Dan (Dan)" , NJEDJOU Eric RD-RESA-REN , Bernard Aboba , dna@eng.monash.edu.au Message-id: <014001c56743$f3b7b5a0$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: Content-Transfer-Encoding: 7BIT Sounds fine. jak ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "James Kempf" ; "NJEDJOU Eric RD-RESA-REN" ; "Bernard Aboba" ; Sent: Thursday, June 02, 2005 12:11 AM Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? I would just refer to the capability of passing packets, without mentioning IP. This is the approach taken by RFC 2863. Regards, Dan > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, June 02, 2005 10:02 AM > To: Romascanu, Dan (Dan); NJEDJOU Eric RD-RESA-REN; Bernard > Aboba; dna@eng.monash.edu.au > Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? > > Dan, > > Then what would you suggest is the appropriate way to phrase this? > > jak > > > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "James Kempf" ; "NJEDJOU Eric > RD-RESA-REN" > ; "Bernard Aboba" > ; > Sent: Wednesday, June 01, 2005 11:51 PM > Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? > > > I would like to draw again the attention of the group that IMO the use > of 'IP packets' to define low link layer link Up / link Down > events may > not be appropriate. The 'capability of communicating IP > packets' cannot > be detected in some cases by lower link layers state machines . > > Regards, > > Dan > > > > > -----Original Message----- > > From: owner-dna@ecselists.eng.monash.edu.au > > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > > James Kempf > > Sent: Thursday, June 02, 2005 6:21 AM > > To: NJEDJOU Eric RD-RESA-REN; Bernard Aboba; dna@eng.monash.edu.au > > Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? > > > > Eric, > > > > > > I have a little problem with the most recent defintion > > (Bernard's) of Link-Down suggested. The statement "A Link > > Down event is only generated once the link layer considers > > the link unusable" looks (to me at least) a bit contradictory > > to the first sentence of the definition in the sense that the > > link layer can consider the link unusable even without any > > change having occured in the link state machine: PDP context > > activated in GPRS/UMTS but very high BER Said differently, > > the definition implies that the event cause can be "state > > changed" in the link layer state machine as well "state did > > not changed" (as the link can become unusable within the same > > state) which is a problem. > > > > Hope my concern is understood. > > > > Insn't > > "An event provided by the link layer that signifies a state > > change associated with the interface no longer being capable > > of communicating IP packets. transient periods of high frame > > loss are not sufficient." enough for Link down definition? > > > > Please advice > > > > jak>> I guess I don't understand the problem. The definition > > leaves it > > jak>> up to > > the link layer to decide what "unusable" means. Whether or > > not that involves a state machine change or some other > > consideration is pretty much up to the link layer to decide. > > > > jak > > > > > > > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 03:45:03 2005 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 DAA14996 for ; Thu, 2 Jun 2005 03:45:02 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZSSDM3929ANZ9N@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 17:44:37 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A9CB180004; Thu, 02 Jun 2005 17:44:31 +1000 (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 66C2F3C009; Thu, 02 Jun 2005 17:44:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j527iLt02198 for dna-list; Thu, 02 Jun 2005 17:44:21 +1000 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 j527iLr02194 for ; Thu, 02 Jun 2005 17:44:21 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZSRUIOYG99JUVP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 17:44:06 +1000 Received: by localhost (Postfix, from userid 510) id 29B3880003; Thu, 02 Jun 2005 17:44:06 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6F1533C00B; Thu, 02 Jun 2005 17:44:04 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHG006E55HE92@mailout2.samsung.com>; Thu, 02 Jun 2005 16:44:02 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHG001L95HAGF@mmp1.samsung.com>; Thu, 02 Jun 2005 16:44:02 +0900 (KST) Date: Thu, 02 Jun 2005 13:11:45 +0530 From: Syam Madanapalli Subject: Re: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, Subba Reddy Cc: Erik Nordmark , dna@eng.monash.edu.au Message-id: <015901c56746$88c1a190$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <012601c56694$d7730700$39476c6b@sisodomain.com> <429DFA6E.4090603@sun.com> <00bc01c5672d$9a16ec70$39476c6b@sisodomain.com> <429EAEB4.7090807@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > Hi Subba, > > Subba Reddy wrote: > [cut] >> >> >> Yes. 6+ ranked routers need to schedule the multicast even though token >> is available. > > I guess it would be a host configurable threshold. You mean Router configurable threshold? > > In general, I can't see a use for more than three > Fast RAs (unless there are problems with the timing > of the first three RAs - for example due to SEND > signature computation). > > How about we have fastra_threshold defaulting to > FASTRA_THRESHOLD (3). I think 3 is good enough. And anyway we can make it configurable. > > if fastra_threshold < Rank (given that Rank starts > at #0), then a Fast RA is scheduled at Rank * RASeparation. Small correction, if Rank < fastra_threshold (given that Rank starts at #0), then a Fast RA is scheduled at Rank * RASeparation. > > Otherwise, the token is put back in the bucket and > a multicast RA is scheduled? > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 03:47:45 2005 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 DAA15167 for ; Thu, 2 Jun 2005 03:47:44 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOZSVQZ3AW99JUVP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Jun 2005 17:47:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BDC9A80002; Thu, 02 Jun 2005 17:47:14 +1000 (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 62DD83C008; Thu, 02 Jun 2005 17:47:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j527lBJ02271 for dna-list; Thu, 02 Jun 2005 17:47:11 +1000 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 j527lAr02267 for ; Thu, 02 Jun 2005 17:47:10 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOZSVDWJEM94OVND@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Jun 2005 17:46:57 +1000 Received: by localhost (Postfix, from userid 510) id 507BB80002; Thu, 02 Jun 2005 17:46:57 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id AB6963C006; Thu, 02 Jun 2005 17:46:56 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHG006OU5M793@mailout2.samsung.com>; Thu, 02 Jun 2005 16:46:55 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHG001KT5M4OC@mmp1.samsung.com>; Thu, 02 Jun 2005 16:46:55 +0900 (KST) Date: Thu, 02 Jun 2005 13:14:39 +0530 From: Subba Reddy Subject: Re: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , dna@eng.monash.edu.au Message-id: <011201c56746$efda9b20$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <012601c56694$d7730700$39476c6b@sisodomain.com> <429DFA6E.4090603@sun.com> <00bc01c5672d$9a16ec70$39476c6b@sisodomain.com> <429EAEB4.7090807@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, Please see below. > Hi Subba, > > Subba Reddy wrote: > [cut] > > > > > > Yes. 6+ ranked routers need to schedule the multicast even though token > > is available. > > I guess it would be a host configurable threshold. > > In general, I can't see a use for more than three > Fast RAs (unless there are problems with the timing > of the first three RAs - for example due to SEND > signature computation). > > How about we have fastra_threshold defaulting to > FASTRA_THRESHOLD (3). > I just gave 5 as an example for threshold. As you said 3 may be ok for default value (FASTRA_THRESHOLD). > if fastra_threshold < Rank (given that Rank starts > at #0), then a Fast RA is scheduled at Rank * RASeparation. > > Otherwise, the token is put back in the bucket and > a multicast RA is scheduled? Yes. I think we need to put the token back in the bucket. > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 11:18:42 2005 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 LAA24717 for ; Thu, 2 Jun 2005 11:18:38 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP08M217JM977K7T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 01:17:55 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B5EE180008; Fri, 03 Jun 2005 01:17:33 +1000 (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 764EE3C005; Fri, 03 Jun 2005 01:17:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j52FGmG06943 for dna-list; Fri, 03 Jun 2005 01:16:48 +1000 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 j52FGkr06937 for ; Fri, 03 Jun 2005 01:16:46 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP08KPO8G099JX3A@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 01:16:29 +1000 Received: by localhost (Postfix, from userid 510) id C4FD0AB543; Fri, 03 Jun 2005 01:16:28 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 360BB4FB02 for ; Fri, 03 Jun 2005 01:16:27 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DdrQl-000OJZ-JY; Thu, 02 Jun 2005 11:16:23 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j52FGMK09280; Thu, 02 Jun 2005 08:16:22 -0700 Date: Thu, 02 Jun 2005 08:16:22 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <004f01c56722$116afb60$5e6015ac@dcml.docomolabsusa.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <004f01c56722$116afb60$5e6015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > "An event provided by the link layer that signifies a state change > associated with the interface no longer being capable of communicating IP > packets. transient periods of high frame loss are not sufficient." enough > for Link down definition? The above is ok from my point of view. > jak>> I guess I don't understand the problem. The definition leaves it up to > the link layer to decide what "unusable" means. Whether or not that involves > a state machine change or some other consideration is pretty much up to the > link layer to decide. I think Erik's point was that we don't want a "Link Down" to be sent just because a few frames were lost. While that might initiate a search for a new point of attachment, the problem might be highly transient. Where there is multi-link interference, for example, we see the S/N ratio drop 20-30 dB within a very short distance. From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 11:20:05 2005 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 LAA25007 for ; Thu, 2 Jun 2005 11:20:04 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP08NUGQQ89AO1YG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 01:19:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4617F80003; Fri, 03 Jun 2005 01:19:00 +1000 (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 EDB833C005; Fri, 03 Jun 2005 01:18:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j52FIth06985 for dna-list; Fri, 03 Jun 2005 01:18:55 +1000 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 j52FIrr06980 for ; Fri, 03 Jun 2005 01:18:53 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP08MU18TK9AO1YG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 01:18:11 +1000 Received: by localhost (Postfix, from userid 510) id 67919AB543; Fri, 03 Jun 2005 01:18:11 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 D5DB34FB05 for ; Fri, 03 Jun 2005 01:18:09 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DdrSR-000OqA-Fs; Thu, 02 Jun 2005 11:18:07 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j52FI5U09365; Thu, 02 Jun 2005 08:18:05 -0700 Date: Thu, 02 Jun 2005 08:18:05 -0700 (PDT) From: Bernard Aboba Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Romascanu, Dan (Dan)" Cc: James Kempf , NJEDJOU Eric RD-RESA-REN , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: Content-Transfer-Encoding: 7BIT > I would like to draw again the attention of the group that IMO the use > of 'IP packets' to define low link layer link Up / link Down events may > not be appropriate. The 'capability of communicating IP packets' cannot > be detected in some cases by lower link layers state machines . Right. It really should be "communicating data frames". From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 11:46:41 2005 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 LAA29961 for ; Thu, 2 Jun 2005 11:46:40 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP09LM6TIE9789LU@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 01:46:24 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C6E43AB543; Fri, 03 Jun 2005 01:46:13 +1000 (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 797F54FB03; Fri, 03 Jun 2005 01:46:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j52Fk0T07334 for dna-list; Fri, 03 Jun 2005 01:46:00 +1000 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 j52Fk0r07330 for ; Fri, 03 Jun 2005 01:46:00 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP09L4I9C8977W6D@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 01:45:50 +1000 Received: by localhost (Postfix, from userid 510) id 34FB3AB542; Fri, 03 Jun 2005 01:45:50 +1000 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by curly.its.monash.edu.au (Postfix) with ESMTP id D9FD74FB03 for ; Fri, 03 Jun 2005 01:45:47 +1000 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 02 Jun 2005 17:45:05 +0200 Date: Thu, 02 Jun 2005 17:47:19 +0200 From: NJEDJOU Eric RD-RESA-REN Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , James Kempf Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j52Fk0r07331 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Thread-Topic: [DNA] Definition of "Link Up" and "Link Down" events? Thread-Index: AcVnhmB6UMqi8GWxT+iHtvqfPCE7ZgAA8DYA Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 02 Jun 2005 15:45:05.0543 (UTC) FILETIME=[0C0FB170:01C5678A] Content-Transfer-Encoding: 8BIT Bernard, That whas exactly my concern. Good that you are ok whith taking out the second statement of the definition Eric Njejdou -----Message d'origine----- De : owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de Bernard Aboba Envoyé : jeudi 2 juin 2005 17:16 À : James Kempf Cc : dna@eng.monash.edu.au Objet : Re: [DNA] Definition of "Link Up" and "Link Down" events? > "An event provided by the link layer that signifies a state change > associated with the interface no longer being capable of communicating > IP packets. transient periods of high frame loss are not sufficient." > enough for Link down definition? The above is ok from my point of view. > jak>> I guess I don't understand the problem. The definition leaves it > jak>> up to > the link layer to decide what "unusable" means. Whether or not that > involves a state machine change or some other consideration is pretty > much up to the link layer to decide. I think Erik's point was that we don't want a "Link Down" to be sent just because a few frames were lost. While that might initiate a search for a new point of attachment, the problem might be highly transient. Where there is multi-link interference, for example, we see the S/N ratio drop 20-30 dB within a very short distance. From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 13:25:17 2005 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 NAA09072 for ; Thu, 2 Jun 2005 13:25:15 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP0D1WWN3W9785MI@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 03:25:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 74469AB543; Fri, 03 Jun 2005 03:24:52 +1000 (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 2BAF04FB07; Fri, 03 Jun 2005 03:24:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j52HOJB08444 for dna-list; Fri, 03 Jun 2005 03:24:19 +1000 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 j52HOIr08440 for ; Fri, 03 Jun 2005 03:24:18 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP0D0ZHLTA99JVHE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 03:24:08 +1000 Received: by localhost (Postfix, from userid 510) id EB343AB543; Fri, 03 Jun 2005 03:24:07 +1000 (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 E122C4FB02; Fri, 03 Jun 2005 03:24:06 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j52HO4sj005703; Thu, 02 Jun 2005 13:24:04 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 9CC961EC8FF; Thu, 02 Jun 2005 13:15:50 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 8574D1EC153; Thu, 02 Jun 2005 13:15:50 -0400 (EDT) Date: Thu, 02 Jun 2005 13:23:48 -0400 From: Sathya Narayanan Subject: Re: [DNA] leaving out options on Landmark RA = Yes(draft-pentland-dna-protocol-00.txt)? In-reply-to: <429E6224.70402@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, Dna Message-id: <429F40A4.9070801@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-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:8 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429D3EFD.1080500@eng.monash.edu.au> <429DF774.6060909@sun.com> <429E6224.70402@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg - > > >> >> Is anybody looking at the details of how SEND and DNA can interact >> efficiently? > > > Not really, but here's the minimum required (which may violate SEND, > but should be OK in this situation): Why do you say 'may violate SEND'? It looks correct to me. > > For a solicited RA Landmark=yes: > > Nonce(8/16), Timestamp(16), RSA Signature (big). > > This assumes that the host has seen this Router's RA before, and > has given its trust chain to the host. > > If this is insufficient, then CCS/CCA exchange may occur, as well > as NS/NA to get the CGA options... > > The host will have to have seen at least one DNA router on the link > though, so it may be possible to wait until another RA from a > trusted router arrives from the same RS. > > > For a Solicited RA, Landmark=No: > > Nonce(8/16), Timestamp (16), CGA Option (big), RSA Signature (big). Why do you include the CGA option for 'No' answer - SEND doesn't require CGA option in the RA messages, unless the interface is configured to use CGA? Is that correct? If that is the case, the CGA option should be present for both 'Yes' and 'No' answers - unless the CGA option is needed only for the first time? Is that so? I couldn't find anything in 3971 that suggests that CGA option is needed only for the first time. Please explain. thanks, Sathya > > Additional exchange of certificate chains may be required in order > to create trust with the router, if the host has never visited it before > (or doesn't remember it). > > > As far as I can see, to achieve SEND's full replay protection you > can't do any better than this. > >>> Question: >>> >>> Can we have standards language for this? >>> >>> There's no flexibility in the description of what options are >>> able to be included in the "Yes" Landmark. That sounds like a >>> MUST NOT include other PIO, DNAO. etc. >> >> >> >> In think the text in section 3 is fine with its use of English, >> because it tries to introduce the concepts by saying what typically >> happens. >> But in the core of the draft it makes sense being more specific. > > > That makes sense. > >>> Personally, I'd prefer something saying something like >>> >>> "RAs with the 'Yes' Flag set in a Landmark option MAY leave out all >>> configuration related options such as PIOs, DNAOs, Advertisement >>> Intervals etc, since this information is assumed to have >>> already been received to be able to construct a matching >>> Landmark Router Solicitation". >>> >>> I'd prefer MAY to SHOULD or MUST, since it's an optimization, >>> and the presence of additional options doesn't harm hosts. >> >> >> >> My gut feel is that we should make it a SHOULD NOT, because the host >> doesn't have any need for this extra stuff, and one of the DNA goals >> is to be efficient. > > > OK. > >>> In RADVD, it's easier for me to not remove the other options >>> in the RA just because the Landmark option Yes flag is set. >> >> >> >> And the purpose of a SHOULD NOT would be to make you do the work :-), >> so that we can get an efficient way to do DNA. > > > > That's OK. My initial work will try to get things going without > the benefits of efficient RA sizing (so long as it's compliant - > which is why I'm asking questions). > > Subsequently I'll add an AbbrevAdvertisement option (defaulting to on) > which should cover the Landmark=No and Landmark=Yes cases. > > That may take a couple of extra days... :) > > Greg > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 13:35:22 2005 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 NAA10191 for ; Thu, 2 Jun 2005 13:35:21 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP0DERO3FE9AO3NR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 03:35:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4C0D280004; Fri, 03 Jun 2005 03:35:14 +1000 (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 E28923C009; Fri, 03 Jun 2005 03:35:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j52HZ4h08594 for dna-list; Fri, 03 Jun 2005 03:35:04 +1000 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 j52HZ3r08590 for ; Fri, 03 Jun 2005 03:35:03 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP0DEBZB2294OSZ4@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 03:34:53 +1000 Received: by localhost (Postfix, from userid 510) id 934AA80002; Fri, 03 Jun 2005 03:34:53 +1000 (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 C06273C006 for ; Fri, 03 Jun 2005 03:34:51 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j52HYoNS006127; Thu, 02 Jun 2005 13:34:50 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id E12781EC153; Thu, 02 Jun 2005 13:26:35 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id D30D21EAE8A; Thu, 02 Jun 2005 13:26:35 -0400 (EDT) Date: Thu, 02 Jun 2005 13:34:33 -0400 From: Sathya Narayanan Subject: [DNA] Route vs Advertise Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Dna Message-id: <429F4329.1040807@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-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:51.61358 C:10 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Erik - It was my understanding that, a host can choose a prefix advertised by R1 for its address configuration and use R2 as the default router through which it sends is packets; i.e. advertising a prefix doesn't mean the router is the only one that can route it. In SEND, 3971, section 7.3: Constrained If the network operator wants to constrain which routers are allowed to route particular subnet prefixes, routers should be configured with certificates having subnet prefixes listed in the prefix extension. These routers SHOULD advertise the subnet prefixes that they are certified to route, or a subset thereof. .... Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration. If none of the advertised subnet prefixes match, the host SHOULD use a different advertising router as its default router, if one is available. This text seems to imply that routers advertising a prefix means they are the ones allowed to route it. Am I missing something? thanks, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 18:54:28 2005 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 SAA09410 for ; Thu, 2 Jun 2005 18:54:27 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP0OKBRI3W99K0XB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 08:54:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CDA1780002; Fri, 03 Jun 2005 08:54:17 +1000 (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 8DFBF3C003; Fri, 03 Jun 2005 08:54:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j52Mrah12040 for dna-list; Fri, 03 Jun 2005 08:53:36 +1000 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 j52Mrar12036 for ; Fri, 03 Jun 2005 08:53:36 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP0OJ7KPQ29AO1B1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 08:53:24 +1000 Received: by localhost (Postfix, from userid 510) id EB219AB54A; Fri, 03 Jun 2005 08:53:23 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id 09DE44FB05; Fri, 03 Jun 2005 08:53:21 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.56.144]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j52MrLFF006136; Thu, 02 Jun 2005 15:53:21 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j52MrKLs240957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Jun 2005 15:53:21 -0700 (PDT) Date: Thu, 02 Jun 2005 15:53:38 -0700 From: Erik Nordmark Subject: Re: [DNA] MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt) In-reply-to: <429E5F41.5060607@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <429F8DF2.40200@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429D2DFC.1080806@eng.monash.edu.au> <429DF5E5.9090400@sun.com> <429E5F41.5060607@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > I see (in 5.1 conceptual data structures). > > "Prefix List entries are created from information received in Router > Advertisements. Each entry has an associated invalidation timer > value (extracted from the advertisement) used to expire prefixes > when they become invalid" And there is also the first paragraph oin 5 which says This section describes a conceptual model of one possible data structure organization that hosts (and to some extent routers) will maintain in interacting with neighboring nodes. The described organization is provided to facilitate the explanation of how the Neighbor Discovery protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 19:26:00 2005 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 TAA10900 for ; Thu, 2 Jun 2005 19:25:59 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP0PLX8OKI977SYI@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 09:25:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B89B80003; Fri, 03 Jun 2005 09:24:36 +1000 (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 013153C006; Fri, 03 Jun 2005 09:24:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j52NONH12409 for dna-list; Fri, 03 Jun 2005 09:24:23 +1000 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 j52NONr12405 for ; Fri, 03 Jun 2005 09:24:23 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP0PLC69AY9788QA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 09:24:12 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 13775AB543; Fri, 03 Jun 2005 09:24:08 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id E5DF84FB05; Fri, 03 Jun 2005 09:24:07 +1000 (EST) Date: Fri, 03 Jun 2005 09:24:07 +1000 From: Greg Daley Subject: Re: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt) In-reply-to: <015901c56746$88c1a190$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Subba Reddy , Erik Nordmark , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429F9517.7010405@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <012601c56694$d7730700$39476c6b@sisodomain.com> <429DFA6E.4090603@sun.com> <00bc01c5672d$9a16ec70$39476c6b@sisodomain.com> <429EAEB4.7090807@eng.monash.edu.au> <015901c56746$88c1a190$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Syam Madanapalli wrote: > Small correction, > > if Rank < fastra_threshold (given that Rank starts > at #0), then a Fast RA is scheduled at Rank * RASeparation. Oops. I'm glad you read between the lines there. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 22:16:13 2005 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 WAA20433 for ; Thu, 2 Jun 2005 22:16:12 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP0VJ1M0SO94O9ZJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 12:14:51 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1927080002; Fri, 03 Jun 2005 12:14:05 +1000 (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 B63B93C00A; Fri, 03 Jun 2005 12:14:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j532DUa14244 for dna-list; Fri, 03 Jun 2005 12:13:30 +1000 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 j532DUr14240 for ; Fri, 03 Jun 2005 12:13:30 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP0VHJB7VS99JZBH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 12:13:24 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 55D6D80016; Fri, 03 Jun 2005 12:12:47 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id F3CD03C008; Fri, 03 Jun 2005 12:12:46 +1000 (EST) Date: Fri, 03 Jun 2005 12:12:46 +1000 From: Greg Daley Subject: Re: [DNA] Route vs Advertise In-reply-to: <429F4329.1040807@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <429FBC9E.1070507@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429F4329.1040807@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, Sathya Narayanan wrote: > Erik - > > It was my understanding that, a host can choose a prefix advertised by > R1 for its address configuration and use R2 as the default router > through which it sends is packets; i.e. advertising a prefix doesn't > mean the router is the only one that can route it. > > In SEND, 3971, section 7.3: > > Constrained > > If the network operator wants to constrain which routers are > allowed to route particular subnet prefixes, routers should be > configured with certificates having subnet prefixes listed in the > prefix extension. These routers SHOULD advertise the subnet > prefixes that they are certified to route, or a subset thereof. > > .... > > Nodes SHOULD use one of the certified subnet prefixes for stateless > autoconfiguration. If none of the advertised subnet prefixes match, > the host SHOULD use a different advertising router as its default > router, if one is available. > > > This text seems to imply that routers advertising a prefix means they > are the ones allowed to route it. > Am I missing something? I remember this issue from SEND. Someone else may remember better though. The issue in SEND is essentially that in some circumstances we want to guarantee that a router is actually delegated authority to route for that prefix. This is in the Certificate, not the PIO. I'd guess that the origin of the prefix doesn't matter (which RA the PIO arrives in), although the certificate would indicate that only those prefixes which are similarly authorized should be used as next hops for packets with that source address. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 2 22:25:31 2005 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 WAA20959 for ; Thu, 2 Jun 2005 22:25:30 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP0VWHITB299JYKA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 12:25:00 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 50A0DAB542; Fri, 03 Jun 2005 12:24:55 +1000 (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 D821D4FB08; Fri, 03 Jun 2005 12:24:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j532Ojx14406 for dna-list; Fri, 03 Jun 2005 12:24:45 +1000 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 j532Oir14402 for ; Fri, 03 Jun 2005 12:24:44 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP0VW5X1QE99JXYV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 12:24:40 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C7FEFAB543; Fri, 03 Jun 2005 12:24:39 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9F0254FB07; Fri, 03 Jun 2005 12:24:39 +1000 (EST) Date: Fri, 03 Jun 2005 12:24:39 +1000 From: Greg Daley Subject: Re: [DNA] leaving out options on Landmark RA = Yes(draft-pentland-dna-protocol-00.txt)? In-reply-to: <429F40A4.9070801@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <429FBF67.7090800@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429D3EFD.1080500@eng.monash.edu.au> <429DF774.6060909@sun.com> <429E6224.70402@eng.monash.edu.au> <429F40A4.9070801@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya. Sathya Narayanan wrote: [cut] > Why do you say 'may violate SEND'? It looks correct to me. Perhaps it is, I was working on the principle that a solicited RA needs to have a CGA option... I'd need to check again to see if that's the case (I think it's actually a MAY include the option). [cut] > Why do you include the CGA option for 'No' answer - SEND doesn't require > CGA option in the RA messages, unless the interface is configured to use > CGA? Is that correct? Well, SEND doesn't yet provide a way (other than explicit certificates) to authenticate the origin and content of messages except through using CGA. The CGA option provides not only the static parameters for the CGA, but also the Public key of the CGA sender. So it's not required to be sent, but it is required to be known, if we want to believe that the message is unmodified from the sender. > If that is the case, the CGA option should be > present for both 'Yes' and 'No' answers - unless the CGA option is > needed only for the first time? Is that so? I couldn't find anything in > 3971 that suggests that CGA option is needed only for the first time. > Please explain. The content in the CGA option but should be cached from the first RA (or NS or NA) reception. So it's not needed in every message. It's typically not required in an unsolicited RA for example (in fact it is a MAY for reception in RAs). Rules are detailed in 5.1.1. (Processing Rules for Senders) For the landmark=NO case, we want to verify (at least the message integrity) without additional transmissions. This requires passing the public key and CGA parameters in the same message as the responding RA. Otherwise, the message is unverifiable without external message exchanges. So CGA Option in a landmark=NO is important if we want message origin integrity because we're assuming the host hasn't been on the link before. For Landmark=YES, we make the opposite assumption. Therefore, we can leave out the CGA Option. There's a chance that a responding RA is from a router which hasn't been seen, or is no longer cached. I guess this is the same assumption made in unicast NS which doesn't mandate SLLAO though. In general I think you're right. CGA option wouldn't be needed. I think it's pretty important if we're assuming the option isn't in the cache. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 01:07:07 2005 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 BAA29118 for ; Fri, 3 Jun 2005 01:07:06 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP11JRBV0094P3DW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 15:06:43 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 76004AB54A; Fri, 03 Jun 2005 15:06:27 +1000 (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 244284FB08; Fri, 03 Jun 2005 15:06:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5353RT16093 for dna-list; Fri, 03 Jun 2005 15:03:27 +1000 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 j5353Qr16089 for ; Fri, 03 Jun 2005 15:03:26 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP11FPQ1VM9AO3ML@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 15:03:12 +1000 Received: by localhost (Postfix, from userid 510) id 14666AB544; Fri, 03 Jun 2005 15:03:12 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3D4304FB07; Fri, 03 Jun 2005 15:03:10 +1000 (EST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHH007Y9SP85R@mailout1.samsung.com>; Fri, 03 Jun 2005 14:03:08 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IHH00I21SP2WO@mmp2.samsung.com>; Fri, 03 Jun 2005 14:03:08 +0900 (KST) Date: Fri, 03 Jun 2005 10:30:47 +0530 From: Syam Madanapalli Subject: Re: [DNA] No FastRA unless Landmark? (draft-pentland-dna-protocol-00) Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, James Kempf Cc: Syam Madanapalli , Sathya Narayanan , dna@eng.monash.edu.au Message-id: <00a701c567f9$38035fb0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <10e14db205060107534e9cae40@mail.gmail.com> <02bc01c566f0$fc15abb0$5a6015ac@dcml.docomolabsusa.com> <429E5C6E.7030100@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > Hi James, > > James Kempf wrote: >>>The FastRA method should have been a seperate draft, unless we are going >> >> to >> >>>have a single DNA solution. >>> >> >> >> Right, so what is planned on this? Is there going to be a discussion >> about >> whether more than one solution is needed? Whether people want more than >> one? >> Currently, I believe we have two. > > > I believed that at the last IETF the rough consensus was that > there will eventually be one solution, which must be selected > by the WG (with expertise from the DT to assist). This is the best way to goforward and avoid to have multiple solutions at the same time, which causes interoperability problems and burden on implementers. > > There's only one solutions document on the charter of the WG. > > So I guess I don't see the need for a separate 'Fast RA' > document at the moment. This is true, as long as we have a single solution. I hope we will not rework in the future to come up with a new solution for DNA where we would also require the FastRA. > > That's not to say that draft-pentland-dna-protocol is the > complete solution just because Hash Based FastRA is defined there > (for example). I agree with you and WG will decide. But I see two proposals 1. Landmark based and 2. Linkid based, both are from Design team. I think somebody from the design team can put the pros and cons of each method on WG mailing list, so that people will have some idea before the WG meeting in Paris > > The Fast RA scheme is sound regardless of whether landmarks or > completeRA are used. Indeed. And the idea of limiting the no. of FASTRAs to FASTRA_THRESHOLD (3) is a good addition, hoping that no other adverse implications > > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 01:19:31 2005 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 BAA29962 for ; Fri, 3 Jun 2005 01:19:30 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP120KB93U9AO48E@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 15:19:17 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A601FAB545; Fri, 03 Jun 2005 15:19:13 +1000 (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 60A774FB03; Fri, 03 Jun 2005 15:19:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j535J4m16303 for dna-list; Fri, 03 Jun 2005 15:19:04 +1000 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 j535J2r16299 for ; Fri, 03 Jun 2005 15:19:02 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1206RCZU94OYPE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 15:18:58 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6FBF880002; Fri, 03 Jun 2005 15:18:55 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 187463C00A; Fri, 03 Jun 2005 15:18:55 +1000 (EST) Date: Fri, 03 Jun 2005 15:18:49 +1000 From: Greg Daley Subject: Suggestions for working toward a single solution (was Re: [DNA] No FastRA unless Landmark) In-reply-to: <00a701c567f9$38035fb0$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: James Kempf , Sathya Narayanan , dna@eng.monash.edu.au, Pekka Nikander Reply-to: greg.daley@eng.monash.edu.au Message-id: <429FE839.7090408@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <10e14db205060107534e9cae40@mail.gmail.com> <02bc01c566f0$fc15abb0$5a6015ac@dcml.docomolabsusa.com> <429E5C6E.7030100@eng.monash.edu.au> <00a701c567f9$38035fb0$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam, Syam Madanapalli wrote: [cut] >> >> That's not to say that draft-pentland-dna-protocol is the >> complete solution just because Hash Based FastRA is defined there >> (for example). > > > I agree with you and WG will decide. But I see two proposals > 1. Landmark based and 2. Linkid based, both are from Design > team. I think somebody from the design team can put the pros > and cons of each method on WG mailing list, so that people > will have some idea before the WG meeting in Paris Please be aware that the draft-pentland-dna-protocol's link identification is not just a landmark based scheme, but also provides a LinkID in the form of CompleteRA. Since there's such good discussion going on, I think it would be good to get the points presented on-list to decide well before the meeting. There may be issues raised beforehand which need to be resolved, but we can make consensus calls (with appropriate durations and prior warnings) on-list. Only the issues which can't be resolved would have to wait until the meeting. Does that sound reasonable? It would require that people are familiar with solutions to the point where they could make a decision. So anyone who hasn't been reading the solutions proposals, please find some time to do so soon. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 09:39:25 2005 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 JAA27026 for ; Fri, 3 Jun 2005 09:39:24 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1JGKBO6I9AO2NR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 23:39:19 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D59A380003; Fri, 03 Jun 2005 23:39:16 +1000 (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 8A7683C010; Fri, 03 Jun 2005 23:39:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53DcVJ21470 for dna-list; Fri, 03 Jun 2005 23:38:31 +1000 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 j53DcVr21466 for ; Fri, 03 Jun 2005 23:38:31 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1JFDRONE94P813@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 23:38:20 +1000 Received: by localhost (Postfix, from userid 510) id C0514AB548; Fri, 03 Jun 2005 23:38:19 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id B99AB4FB12; Fri, 03 Jun 2005 23:38:17 +1000 (EST) Date: Fri, 03 Jun 2005 06:36:59 -0700 From: James Kempf Subject: Re: [DNA] Route vs Advertise Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, Sathya Narayanan Cc: Erik Nordmark , Dna Message-id: <024201c56841$a9491870$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg, That is right, however, this is an optional feature of SEND, because many ISPs may not have the ability to add the special attributes to the router certs. jak ----- Original Message ----- From: "Greg Daley" To: "Sathya Narayanan" Cc: "Erik Nordmark" ; "Dna" Sent: Thursday, June 02, 2005 7:12 PM Subject: Re: [DNA] Route vs Advertise > Hi Sathya, > > Sathya Narayanan wrote: > > Erik - > > > > It was my understanding that, a host can choose a prefix advertised by > > R1 for its address configuration and use R2 as the default router > > through which it sends is packets; i.e. advertising a prefix doesn't > > mean the router is the only one that can route it. > > > > In SEND, 3971, section 7.3: > > > > Constrained > > > > If the network operator wants to constrain which routers are > > allowed to route particular subnet prefixes, routers should be > > configured with certificates having subnet prefixes listed in the > > prefix extension. These routers SHOULD advertise the subnet > > prefixes that they are certified to route, or a subset thereof. > > > > .... > > > > Nodes SHOULD use one of the certified subnet prefixes for stateless > > autoconfiguration. If none of the advertised subnet prefixes match, > > the host SHOULD use a different advertising router as its default > > router, if one is available. > > > > > > This text seems to imply that routers advertising a prefix means they > > are the ones allowed to route it. > > Am I missing something? > > I remember this issue from SEND. > > Someone else may remember better though. > > The issue in SEND is essentially that in some circumstances we want to > guarantee that a router is actually delegated authority to route for > that prefix. This is in the Certificate, not the PIO. > > I'd guess that the origin of the prefix doesn't matter (which RA the > PIO arrives in), although the certificate would indicate that only > those prefixes which are similarly authorized should be used as next > hops for packets with that source address. > > Greg > From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 09:50:27 2005 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 JAA27683 for ; Fri, 3 Jun 2005 09:50:26 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1JTV4QMO94OH7F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Jun 2005 23:50:09 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2CEF7AB543; Fri, 03 Jun 2005 23:50:00 +1000 (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 DD0D74FB04; Fri, 03 Jun 2005 23:49:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53Dnp221633 for dna-list; Fri, 03 Jun 2005 23:49:51 +1000 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 j53Dnor21629 for ; Fri, 03 Jun 2005 23:49:50 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1JTBHPCQ9ANQ7X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Jun 2005 23:49:34 +1000 Received: by localhost (Postfix, from userid 510) id F0E5EAB542; Fri, 03 Jun 2005 23:49:33 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2C40F4FB02 for ; Fri, 03 Jun 2005 23:49:32 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHI00I48GZQWF@mailout2.samsung.com> for dna@eng.monash.edu.au; Fri, 03 Jun 2005 22:47:51 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IHI009AMGZN7R@mmp2.samsung.com> for dna@eng.monash.edu.au; Fri, 03 Jun 2005 22:47:50 +0900 (KST) Date: Fri, 03 Jun 2005 19:15:31 +0530 From: Subba Reddy Subject: [DNA] comments on draft-ietf-dna-hosts-00 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: Syam Madanpalli , rkrishnan.s@samsung.com, Ranjitsinh Wable Message-id: <018401c56842$84c4afe0$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hi, Here are few comments and questions on host BCP document. 1. In Section 4.1, ".....When a host attaches itself to a new L2 link, if the corresponding stored prefix list doesn't contain the prefix it is using, the host SHOULD conclude that it has changed link and initiate new configuration procedure. If the host finds the prefix it is using in the stored list of prefixes, a host MAY conclude that it is on the same link...." I think here "SHOULD" and "MAY" need to be swapped. In section 4.3.1, it is correctly mentioned as follows ".... A host SHOULD conclude that it is on the same link if any of the following events happen. Reception of a RA with a known prefix on the link...." 2. In section 4.5, in the table, for RS/multicast RA case, I think Upstream is N and Downstream is Y. Downstream is Y because we received multicast RA. We are not sure whether RS host sent was received by router or not amd hence Upstream is N. 3. In section 4.2, "... While hosts performing DNA do not know if they have arrived on a new link, they SHOULD treat their addresses as if they were. This means ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that link-local addresses SHOULD be treated as either optimistic or tentative, and globally unique addresses SHOULD NOT be used in a way which creates neighbor cache state on their peers, while DNA procedures are underway. The different treatment of IP addressing comes from the fact that on the global addresses cannot have an address conflict if they move to a topologically incorrect network where link-local addresses may. Even though global addresses will not collide, the incorrect creation of neighbor cache entries on legacy peers may cause them some harm...." Can you please elaborate as what "SHOULD treat their addresses as if they were" underlined above means? I am little confused with this line. Also IMHO, this paragraph is a bit difficult to understand. It may be better to rephrase it in simple terms. 4. Some typos 1. In section 4.5, last paragraph bracket is not closed. "... Whenever a host receives a hint (see Section 5, after identifying the link, it SHOULD verify partial reachability from its default router to itself." 2. In section 6, ".... Invalidationof router and prefix list ..." s/Invalidation of/Invalidationof 3. In section 7.2, ".......If a host is changing is IPv6 link, the new ^^^ router on that link may have a different configuration and may introduce more delay than the previous default router of the host...." s/its/is 4.In section 8.2, ".... If a non-SEND node forges a DAD defense for an address which is still in peers' neighbor cache entries, a host may send a SEND protected unicast neighbor solicitation without a source link-layer address option to one its peers (which also uses SEND). ...." ^^^^^^^^^ s/one of its/one its Regards Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 10:52:19 2005 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 KAA05037 for ; Fri, 3 Jun 2005 10:52:18 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1M0R9YZU977WSU@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 00:52:12 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3337AB543; Sat, 04 Jun 2005 00:52:02 +1000 (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 6EA044FB0B; Sat, 04 Jun 2005 00:52:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53EpSU22318 for dna-list; Sat, 04 Jun 2005 00:51:28 +1000 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 j53EpOr22314 for ; Sat, 04 Jun 2005 00:51:24 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1LYP5O6099K2K0@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 00:51:10 +1000 Received: by localhost (Postfix, from userid 510) id 2306F80003; Sat, 04 Jun 2005 00:51:10 +1000 (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 1B5DC3C009 for ; Sat, 04 Jun 2005 00:51:08 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j53Ep7le016574; Fri, 03 Jun 2005 10:51:07 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id B05351EC951; Fri, 03 Jun 2005 10:42:51 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id A1AD01EC941; Fri, 03 Jun 2005 10:42:51 -0400 (EDT) Date: Fri, 03 Jun 2005 10:50:50 -0400 From: Sathya Narayanan Subject: Re: [DNA] comments on draft-ietf-dna-hosts-00 In-reply-to: <018401c56842$84c4afe0$39476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: dna@eng.monash.edu.au, Syam Madanpalli , rkrishnan.s@samsung.com, Ranjitsinh Wable Message-id: <42A06E4A.5020005@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-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 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) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <018401c56842$84c4afe0$39476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Subba Reddy wrote: > Here are few comments and questions on host BCP document. > > Thanks for your comments. I was hoping to receive some feedback before I created another version of the draft - targetting for mid-to-late June. >1. In Section 4.1, > > ".....When a host attaches itself to a new L2 link, if the > corresponding stored prefix list doesn't contain the prefix it is > using, the host SHOULD conclude that it has changed link and initiate > new configuration procedure. If the host finds the prefix it is > using in the stored list of prefixes, a host MAY conclude that it is > on the same link...." > > > In section 4.1, we are suggesting that hosts could maintain a cache history of all its previous L2-L3 mapping information and use the stored information to make link change detection. Since, mapping information is not guaranteed to be correct (there is no lifetime associated to it by the standards), we want to be conservative - i.e. its OK to conclude link-change erroneously as during the configuration procedure you will figure it out, hence the SHOULD - while we don't want to make strong recommendation on concluding same-link - hence the MAY. > I think here "SHOULD" and "MAY" need to be swapped. In section 4.3.1, > it is correctly mentioned as follows > > ".... A host SHOULD conclude that it is on the same link if any of the > following events happen. > > Reception of a RA with a known prefix on the link...." > > In section 4.3.1, we are refering to the current list of know prefixes with their associated lifetime - I guess this difference is not clear - I will try to make it better in the next version. >2. In section 4.5, in the table, for RS/multicast RA case, I think Upstream >is N and > Downstream is Y. Downstream is Y because we received multicast RA. We >are not > sure whether RS host sent was received by router or not amd hence >Upstream is N. > > > ;-) Thanks for the catch. I will change it. >3. In section 4.2, > "... While hosts performing DNA do not know if they have arrived on a >new > link, they SHOULD treat their addresses as if they were. This means > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > that link-local addresses SHOULD be treated as either optimistic or > tentative, and globally unique addresses SHOULD NOT be used in a way > which creates neighbor cache state on their peers, while DNA > procedures are underway. The different treatment of IP addressing > comes from the fact that on the global addresses cannot have an > address conflict if they move to a topologically incorrect network > where link-local addresses may. Even though global addresses will > not collide, the incorrect creation of neighbor cache entries on > legacy peers may cause them some harm...." > > Can you please elaborate as what "SHOULD treat their addresses > as if they were" underlined above means? > > The following line tries to explain the meaning. > I am little confused with this line. Also IMHO, this paragraph is a bit >difficult to understand. It may be better to rephrase it in simple terms. > > Sure. We will try to improve this section for the next version. >4. >Some typos > >1. In section 4.5, last paragraph bracket is not closed. > "... Whenever a host receives a hint (see Section 5, after identifying >the > link, it SHOULD verify partial reachability from its default router > to itself." > >2. In section 6, >".... Invalidationof router and prefix list ..." > >s/Invalidation of/Invalidationof > >3. In section 7.2, >".......If a host is changing is IPv6 link, the new > ^^^ > router on that link may have a different configuration and may > introduce more delay than the previous default router of the host...." > >s/its/is > >4.In section 8.2, >".... If a non-SEND node forges a DAD defense for an address which is >still > in peers' neighbor cache entries, a host may send a SEND protected > unicast neighbor solicitation without a source link-layer address > option to one its peers (which also uses SEND). ...." > ^^^^^^^^^ >s/one of its/one its > > > Thanks again. regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 11:00:37 2005 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 LAA05827 for ; Fri, 3 Jun 2005 11:00:35 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1MB1OKUO9AO2WF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 01:00:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 64253AB543; Sat, 04 Jun 2005 01:00:20 +1000 (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 0ED7A4FB0A; Sat, 04 Jun 2005 01:00:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53F0BV22485 for dna-list; Sat, 04 Jun 2005 01:00:11 +1000 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 j53F0Ar22481 for ; Sat, 04 Jun 2005 01:00:10 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1MANWDM494P166@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 01:00:02 +1000 Received: by localhost (Postfix, from userid 510) id 0F123AB543; Sat, 04 Jun 2005 01:00:02 +1000 (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 0736E4FB02; Sat, 04 Jun 2005 01:00:00 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j53Exlqp016819; Fri, 03 Jun 2005 10:59:47 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 2797F1E9E14; Fri, 03 Jun 2005 10:51:32 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 178BA1E81A6; Fri, 03 Jun 2005 10:51:32 -0400 (EDT) Date: Fri, 03 Jun 2005 10:59:30 -0400 From: Sathya Narayanan Subject: Re: [DNA] Route vs Advertise In-reply-to: <024201c56841$a9491870$5e6015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <42A07052.5070709@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-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:7 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> <024201c56841$a9491870$5e6015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Jim - >That is right, however, this is an optional feature of SEND, > From 3971, "nodes SHOULD verify that the prefix specified" and " Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration" These conditions are SHOULDs to leave these features optional, is it? >because many >ISPs may not have the ability to add the special attributes to the router >certs. > > Can you please point me to the place where these special attributes may not be added to the certificates? thanks, Sathya >----- Original Message ----- >From: "Greg Daley" >To: "Sathya Narayanan" >Cc: "Erik Nordmark" ; "Dna" >Sent: Thursday, June 02, 2005 7:12 PM >Subject: Re: [DNA] Route vs Advertise > > > > >>Hi Sathya, >> >>Sathya Narayanan wrote: >> >> >>>Erik - >>> >>>It was my understanding that, a host can choose a prefix advertised by >>>R1 for its address configuration and use R2 as the default router >>>through which it sends is packets; i.e. advertising a prefix doesn't >>>mean the router is the only one that can route it. >>> >>>In SEND, 3971, section 7.3: >>> >>>Constrained >>> >>> If the network operator wants to constrain which routers are >>> allowed to route particular subnet prefixes, routers should be >>> configured with certificates having subnet prefixes listed in the >>> prefix extension. These routers SHOULD advertise the subnet >>> prefixes that they are certified to route, or a subset thereof. >>> >>>.... >>> >>> Nodes SHOULD use one of the certified subnet prefixes for stateless >>> autoconfiguration. If none of the advertised subnet prefixes match, >>> the host SHOULD use a different advertising router as its default >>> router, if one is available. >>> >>> >>>This text seems to imply that routers advertising a prefix means they >>>are the ones allowed to route it. >>>Am I missing something? >>> >>> >>I remember this issue from SEND. >> >>Someone else may remember better though. >> >>The issue in SEND is essentially that in some circumstances we want to >>guarantee that a router is actually delegated authority to route for >>that prefix. This is in the Certificate, not the PIO. >> >>I'd guess that the origin of the prefix doesn't matter (which RA the >>PIO arrives in), although the certificate would indicate that only >>those prefixes which are similarly authorized should be used as next >>hops for packets with that source address. >> >>Greg >> >> From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 11:13:10 2005 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 LAA06780 for ; Fri, 3 Jun 2005 11:13:09 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1MQCB6FY978M57@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 01:12:56 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 54641AB543; Sat, 04 Jun 2005 01:12:40 +1000 (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 E78CA4FB0D; Sat, 04 Jun 2005 01:12:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53FCOQ22656 for dna-list; Sat, 04 Jun 2005 01:12:24 +1000 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 j53FCOr22652 for ; Sat, 04 Jun 2005 01:12:24 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1MPWB8NQ9AO3PB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 01:12:19 +1000 Received: by localhost (Postfix, from userid 510) id F14BEAB543; Sat, 04 Jun 2005 01:12:18 +1000 (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 C8A384FB03; Sat, 04 Jun 2005 01:12:16 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j53FCFoE017205; Fri, 03 Jun 2005 11:12:15 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 38B9A1E9E14; Fri, 03 Jun 2005 11:04:00 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 29F7A1E81A6; Fri, 03 Jun 2005 11:04:00 -0400 (EDT) Date: Fri, 03 Jun 2005 11:11:58 -0400 From: Sathya Narayanan Subject: Re: [DNA] Route vs Advertise In-reply-to: <429FBC9E.1070507@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , Dna Message-id: <42A0733E.2060403@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-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:7 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg - Thanks for the response. Before I go further, I started reading up on SEND to see how DNA should work with it - the questions I am asking at the moment are for my own clarifications - but we MAY have to address how the host can verify the authenticity of the prefixes in a DNAO or even in the Landmark option, if the certificates tightly bound the prefixes to individual routers. Please stop me if I am barking up the wrong tree here. > I remember this issue from SEND. > > Someone else may remember better though. > > The issue in SEND is essentially that in some circumstances we want to > guarantee that a router is actually delegated authority to route for > that prefix. This is in the Certificate, not the PIO. > > I'd guess that the origin of the prefix doesn't matter (which RA the > PIO arrives in), although the certificate would indicate that only > those prefixes which are similarly authorized should be used as next > hops for packets with that source address. Look at the following lines from 3971: A router MAY, however, advertise a combination of certified and uncertified subnet prefixes. Uncertified subnet prefixes are treated as unsecured (i.e., processed in the same way as unsecured router advertisements sent by non-SEND routers). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured information. If the network operator wants to constrain which routers are allowed to route particular subnet prefixes, routers should be configured with certificates having subnet prefixes listed in the prefix extension. These routers SHOULD advertise the subnet prefixes that they are certified to route, or a subset thereof. Upon processing a Prefix Information option within a Router Advertisement, nodes SHOULD verify that the prefix specified in this option falls within the range defined by the certificate, if the certificate contains a prefix extension. Options failing this check are treated as containing uncertified subnet prefixes. Upon receiving PIO in a RA, nodes SHOULD verify that the prefix falls within the range defined by the certificate - if the check fails, treat the PIO as unsecure, if a host doesn't want to interoperate with non-SEND router, it can discard the unsecure PIOs. So, in a all-SEND nodes world, if hosts do the check on the PIOs - is it fair to conclude that the routing and advertising of any given prefix will have to be from the same router(s). thanks, Sathya From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 13:44:58 2005 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 NAA18008 for ; Fri, 3 Jun 2005 13:44:57 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1S1W6L7E99K4GG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 03:44:49 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A57A8AB545; Sat, 04 Jun 2005 03:44:45 +1000 (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 578634FB05; Sat, 04 Jun 2005 03:44:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53Hi6824343 for dna-list; Sat, 04 Jun 2005 03:44:06 +1000 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 j53Hi5r24339 for ; Sat, 04 Jun 2005 03:44:05 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1S0SQTRG977HXR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 03:43:53 +1000 Received: by localhost (Postfix, from userid 510) id B67D780003; Sat, 04 Jun 2005 03:43:52 +1000 (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 0F3A93C00A; Sat, 04 Jun 2005 03:43:50 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j53HhnFF001836; Fri, 03 Jun 2005 10:43:49 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j53Hhm8p853141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 03 Jun 2005 10:43:49 -0700 (PDT) Date: Fri, 03 Jun 2005 10:44:07 -0700 From: Erik Nordmark Subject: Re: [DNA] Route vs Advertise In-reply-to: <429FBC9E.1070507@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Sathya Narayanan , Dna Message-id: <42A096E7.9090608@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > The issue in SEND is essentially that in some circumstances we want to > guarantee that a router is actually delegated authority to route for > that prefix. This is in the Certificate, not the PIO. > > I'd guess that the origin of the prefix doesn't matter (which RA the > PIO arrives in), although the certificate would indicate that only > those prefixes which are similarly authorized should be used as next > hops for packets with that source address. Is this something which has been implemented in the host SEND implementations? I can see it being quite hard since it fits neither the BSD-style code, nor the RFC 2461 conceptual model of a host. Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 13:45:12 2005 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 NAA18050 for ; Fri, 3 Jun 2005 13:45:11 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1S21Q3EW94P8PG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 03:45:03 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1EF8080003; Sat, 04 Jun 2005 03:44:53 +1000 (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 CB4693C009; Sat, 04 Jun 2005 03:44:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53HinX24367 for dna-list; Sat, 04 Jun 2005 03:44:49 +1000 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 j53Himr24363 for ; Sat, 04 Jun 2005 03:44:48 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1S1RJZFC9AO2TK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 03:44:39 +1000 Received: by localhost (Postfix, from userid 510) id 8B96780002; Sat, 04 Jun 2005 03:44:39 +1000 (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 ABD9F3C009 for ; Sat, 04 Jun 2005 03:44:37 +1000 (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 j53HiaFF002439; Fri, 03 Jun 2005 10:44:36 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j53HiacF853360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 03 Jun 2005 10:44:36 -0700 (PDT) Date: Fri, 03 Jun 2005 10:44:55 -0700 From: Erik Nordmark Subject: [DNA] Re: Route vs Advertise In-reply-to: <429F4329.1040807@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: <42A09717.1040508@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429F4329.1040807@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Erik - > > It was my understanding that, a host can choose a prefix advertised by > R1 for its address configuration and use R2 as the default router > through which it sends is packets; i.e. advertising a prefix doesn't > mean the router is the only one that can route it. Your understanding is correct. Should we move the SEND discussion/clarification to the SEND list until we have an answer? Erik > In SEND, 3971, section 7.3: > > Constrained > > If the network operator wants to constrain which routers are > allowed to route particular subnet prefixes, routers should be > configured with certificates having subnet prefixes listed in the > prefix extension. These routers SHOULD advertise the subnet > prefixes that they are certified to route, or a subset thereof. > > .... > > Nodes SHOULD use one of the certified subnet prefixes for stateless > autoconfiguration. If none of the advertised subnet prefixes match, > the host SHOULD use a different advertising router as its default > router, if one is available. > > > This text seems to imply that routers advertising a prefix means they > are the ones allowed to route it. > Am I missing something? > > thanks, > Sathya From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 13:55:31 2005 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 NAA18713 for ; Fri, 3 Jun 2005 13:55:30 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP1SF1ZHSC9AO4SZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 03:55:25 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3D564AB545; Sat, 04 Jun 2005 03:55:22 +1000 (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 D0AC94FB06; Sat, 04 Jun 2005 03:55:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j53HtBt24550 for dna-list; Sat, 04 Jun 2005 03:55:11 +1000 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 j53HtAr24546 for ; Sat, 04 Jun 2005 03:55:10 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP1SEJRQ0294P3ZO@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 03:54:58 +1000 Received: by localhost (Postfix, from userid 510) id E0E6080002; Sat, 04 Jun 2005 03:54:57 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by larry.its.monash.edu.au (Postfix) with ESMTP id D0B6D3C008; Sat, 04 Jun 2005 03:54:55 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.68.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j53Hssn0001703; Fri, 03 Jun 2005 11:54:54 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j53HsmJH859916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 03 Jun 2005 10:54:54 -0700 (PDT) Date: Fri, 03 Jun 2005 10:55:07 -0700 From: Erik Nordmark Subject: Re: [DNA] No FastRA unlessLandmark?(draft-pentland-dna-protocol-00) In-reply-to: <429E8A24.50407@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Sathya Narayanan , dna@eng.monash.edu.au Message-id: <42A0997B.3090701@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429E8A24.50407@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > If the user community is small enough on the previous link, > the timing of your last packet receptions combined with the > prefix from that link can create a pseudo-identifier. > > These pseudo-identifiers can be tracked across link boundaries, > and can prevent movement and location-identity(if the identity was > revealed on a previous or future link) privacy. I guess I don't understand the problem you are trying to solve here, so that I can gauge what the current threat situations looks like without DNA. Is the threat is that of an attacker which can simultaneously observe packets on both link 1 and link 2, and you are concerned that such an attacker can correlate the packets seen from the host on link 1 and on link 2? Without DNA this can be easily accomplished by looking at the traffic patterns. For example, given TCP connection might attempt to continue with the same source port number and destination port/ip after the move, or the host might have done IKE+ESP to IP address 1.2.3.4 before the move and after the move the host restarts IKE to IP address 1.2.3.4 (the host's VPN gateway). If mobile IP is used then you'll see an ESP protected packet (with a size of a binding update) being sent to the same IP address as before (the host's HA); it might even have a Home address option in the clear. And for http in the clear, the fact that the host has RSS feeds from their favorite places will tell it apart. So traffic analysis can do lots in this space when the movement is near instantaneous. That is quite different than the threat of an attacker which saw Ethernet address X (and an IPv6 address with X as the IID) 2 months ago and again sees the same Ethernet address. In that case some traffic analysis might be helpful to the attacker even when the Ethernet address has changed, but the host's traffic patterns might have changed in the meantime. So I suggest we define what privacy problems we think we need to address, and compare those with non-DNA related threats, before we start working on solutions to privacy issues. Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 20:42:00 2005 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 UAA29302 for ; Fri, 3 Jun 2005 20:41:59 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP26LWT5PK94P8A4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 10:41:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C763C80002; Sat, 04 Jun 2005 10:41:45 +1000 (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 808D23C003; Sat, 04 Jun 2005 10:41:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j540f7728944 for dna-list; Sat, 04 Jun 2005 10:41:07 +1000 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 j540f6r28940 for ; Sat, 04 Jun 2005 10:41:06 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP26KTQXQK9AO43J@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 10:40:53 +1000 Received: by localhost (Postfix, from userid 510) id 6688EAB543; Sat, 04 Jun 2005 10:40:53 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id A12664FB04; Sat, 04 Jun 2005 10:40:51 +1000 (EST) Date: Fri, 03 Jun 2005 17:41:44 -0700 From: James Kempf Subject: Re: [DNA] Route vs Advertise Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <02af01c5689e$37c2ec50$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> <024201c56841$a9491870$5e6015ac@dcml.docomolabsusa.com> <42A07052.5070709@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT > >That is right, however, this is an optional feature of SEND, > > > From 3971, > > "nodes SHOULD verify that the prefix specified" > and > " Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration" > > These conditions are SHOULDs to leave these features optional, is it? > Yes. > >because many > >ISPs may not have the ability to add the special attributes to the router > >certs. > > > > > Can you please point me to the place where these special attributes may > not be added to the certificates? > Nothing in the spec, just an observation on the current deployment situation. For example, if the ISP gets their router cert directly from Verisign rather than running their own PKI, it might be hard to get the additional attributes added, and might additionlly constrain network management flexibility. The IESG requested that we change the MUST to SHOULD prior to going to RFC for this reason. jak From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 20:50:34 2005 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 UAA29667 for ; Fri, 3 Jun 2005 20:50:33 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP26WM8K7299K4VE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 10:50:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B20FAB543; Sat, 04 Jun 2005 10:50:23 +1000 (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 0F2234FB02; Sat, 04 Jun 2005 10:50:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j540oH029090 for dna-list; Sat, 04 Jun 2005 10:50:17 +1000 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 j540oHr29086 for ; Sat, 04 Jun 2005 10:50:17 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP26W5SCAI9AO3BE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 10:50:02 +1000 Received: by localhost (Postfix, from userid 510) id A241D80002; Sat, 04 Jun 2005 10:50:01 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id B9F153C007; Sat, 04 Jun 2005 10:50:00 +1000 (EST) Date: Fri, 03 Jun 2005 17:50:55 -0700 From: James Kempf Subject: Re: [DNA] Route vs Advertise Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan , greg.daley@eng.monash.edu.au Cc: Erik Nordmark , Dna Message-id: <02b701c5689f$7f935d20$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> <42A0733E.2060403@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT > Before I go further, I started reading up on SEND to see how DNA should > work with it - the questions I am asking at the moment are for my own > clarifications - but we MAY have to address how the host can verify the > authenticity of the prefixes in a DNAO or even in the Landmark option, > if the certificates tightly bound the prefixes to individual routers. > Please stop me if I am barking up the wrong tree here. > If the certs have prefixes in them, there is no reason why the certs must only list the prefixes that are currently being advertised. The SEND spec allows the certs to list a range of prefixes, or even a set of prefixes. So the range or set could contain all the prefixes on the link, even those not currently being advertised, indeed, the range could include all the prefixes in the access network, if the ISP uses a "site" certificate, like many Web services operators do. > A router MAY, however, advertise a > combination of certified and uncertified subnet prefixes. > Uncertified subnet prefixes are treated as unsecured (i.e., processed > in the same way as unsecured router advertisements sent by non-SEND > routers). The processing of unsecured messages is specified in > Section 8. Note that SEND nodes that do not attempt to interoperate > with non-SEND nodes MAY simply discard the unsecured information. > Note that this does not imply that the router advertisement should be considered insecure, just the uncertified prefix. If the advertisement has a signature verifiable with the router's certified public key, then the router is trustworthy. > If the network operator wants to constrain which routers are > allowed to route particular subnet prefixes, routers should be > configured with certificates having subnet prefixes listed in the > prefix extension. These routers SHOULD advertise the subnet > prefixes that they are certified to route, or a subset thereof. > > Upon processing a Prefix Information option within a Router > Advertisement, nodes SHOULD verify that the prefix specified in this > option falls within the range defined by the certificate, if the > certificate contains a prefix extension. Options failing this check > are treated as containing uncertified subnet prefixes. > > > Upon receiving PIO in a RA, nodes SHOULD verify that the prefix falls > within the range defined by the certificate - if the check fails, treat > the PIO as unsecure, if a host doesn't want to interoperate with > non-SEND router, it can discard the unsecure PIOs. So, in a all-SEND > nodes world, if hosts do the check on the PIOs - is it fair to conclude > that the routing and advertising of any given prefix will have to be > from the same router(s). > That was the intent, a certified prefix means the router is authorized to route the prefix as advertised. jak From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 3 22:50:17 2005 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 WAA06919 for ; Fri, 3 Jun 2005 22:50:16 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP2B2MC7JY978HB2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Jun 2005 12:50:11 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0043880002; Sat, 04 Jun 2005 12:49:46 +1000 (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 AEBCD3C009; Sat, 04 Jun 2005 12:49:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j542nAG30371 for dna-list; Sat, 04 Jun 2005 12:49:10 +1000 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 j542n9r30367 for ; Sat, 04 Jun 2005 12:49:09 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP2B1JXNQM9AO30J@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Jun 2005 12:48:54 +1000 Received: by localhost (Postfix, from userid 510) id 7F4B9AB545; Sat, 04 Jun 2005 12:48:54 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8B9A94FB02; Sat, 04 Jun 2005 12:48:52 +1000 (EST) Date: Fri, 03 Jun 2005 19:49:52 -0700 From: James Kempf Subject: Re: [DNA] Route vs Advertise Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , greg.daley@eng.monash.edu.au Cc: Sathya Narayanan , Dna Message-id: <032801c568b0$1adad910$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> <42A096E7.9090608@sun.com> Content-Transfer-Encoding: 7BIT Out implementation doesn't work that way. It just uses the prefixes in the certificate to check whether the prefixes are certified or not, and drops those that are uncertified if the host is configured to do so. It doesn't uses the certification to determine what addresses to send to what router since, as Erik says, that is not in the RFC 2461 conceptual model. jak ----- Original Message ----- From: "Erik Nordmark" To: Cc: "Sathya Narayanan" ; "Dna" Sent: Friday, June 03, 2005 10:44 AM Subject: Re: [DNA] Route vs Advertise > Greg Daley wrote: > > > The issue in SEND is essentially that in some circumstances we want to > > guarantee that a router is actually delegated authority to route for > > that prefix. This is in the Certificate, not the PIO. > > > > I'd guess that the origin of the prefix doesn't matter (which RA the > > PIO arrives in), although the certificate would indicate that only > > those prefixes which are similarly authorized should be used as next > > hops for packets with that source address. > > Is this something which has been implemented in the host SEND > implementations? I can see it being quite hard since it fits neither the > BSD-style code, nor the RFC 2461 conceptual model of a host. > > Erik > From dna-owner@webcamserver.eng.monash.edu.au Sun Jun 5 21:53:06 2005 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 VAA20948 for ; Sun, 5 Jun 2005 21:53:04 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP51KUKVHG94POTL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Jun 2005 11:52:01 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5BAF280008; Mon, 06 Jun 2005 11:50:30 +1000 (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 001983C012; Mon, 06 Jun 2005 11:50:29 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j561n1u30857 for dna-list; Mon, 06 Jun 2005 11:49:01 +1000 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 j561n0r30851 for ; Mon, 06 Jun 2005 11:49:00 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP51ION7UW97913R@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Jun 2005 11:48:50 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BC77980006; Mon, 06 Jun 2005 11:48:45 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8229D3C00F; Mon, 06 Jun 2005 11:48:45 +1000 (EST) Date: Mon, 06 Jun 2005 11:48:44 +1000 From: Greg Daley Subject: Re: [DNA] Route vs Advertise In-reply-to: <032801c568b0$1adad910$5e6015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Erik Nordmark , Sathya Narayanan , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A3AB7C.6040706@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429F4329.1040807@Research.Panasonic.COM> <429FBC9E.1070507@eng.monash.edu.au> <42A096E7.9090608@sun.com> <032801c568b0$1adad910$5e6015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James and Erik, James Kempf wrote: > Out implementation doesn't work that way. It just uses the prefixes in the > certificate to check whether the prefixes are certified or not, and drops > those that are uncertified if the host is configured to do so. It doesn't > uses the certification to determine what addresses to send to what router > since, as Erik says, that is not in the RFC 2461 conceptual model. Thanks for your clarification James. I wasn't explicitly referring to any particular codebase in my surmise. Greg > jak > > ----- Original Message ----- > From: "Erik Nordmark" > To: > Cc: "Sathya Narayanan" ; "Dna" > > Sent: Friday, June 03, 2005 10:44 AM > Subject: Re: [DNA] Route vs Advertise > > > >>Greg Daley wrote: >> >> >>>The issue in SEND is essentially that in some circumstances we want to >>>guarantee that a router is actually delegated authority to route for >>>that prefix. This is in the Certificate, not the PIO. >>> >>>I'd guess that the origin of the prefix doesn't matter (which RA the >>>PIO arrives in), although the certificate would indicate that only >>>those prefixes which are similarly authorized should be used as next >>>hops for packets with that source address. >> >>Is this something which has been implemented in the host SEND >>implementations? I can see it being quite hard since it fits neither the >>BSD-style code, nor the RFC 2461 conceptual model of a host. >> >> Erik >> > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 03:06:38 2005 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 DAA02128 for ; Mon, 6 Jun 2005 03:06:37 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP5CLL4ERE99JZ8T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Jun 2005 17:05:57 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F403AB544; Mon, 06 Jun 2005 17:05:40 +1000 (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 38B224FB15; Mon, 06 Jun 2005 17:05:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5672Mb01729 for dna-list; Mon, 06 Jun 2005 17:02:22 +1000 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 j5672Lr01725 for ; Mon, 06 Jun 2005 17:02:21 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP5C0FOOYS9792P1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Jun 2005 16:48:39 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6CB70AB54B; Mon, 06 Jun 2005 16:48:37 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4A4F84FB03; Mon, 06 Jun 2005 16:48:37 +1000 (EST) Date: Mon, 06 Jun 2005 16:48:31 +1000 From: Greg Daley Subject: Re: [DNA] No FastRA unlessLandmark?(draft-pentland-dna-protocol-00) In-reply-to: <42A0997B.3090701@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Sathya Narayanan , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A3F1BF.60605@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <429E8A24.50407@eng.monash.edu.au> <42A0997B.3090701@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, I guess this is largely tangential. Please tell me if you think we're going too far for on-list. Erik Nordmark wrote: > Greg Daley wrote: > >> If the user community is small enough on the previous link, >> the timing of your last packet receptions combined with the >> prefix from that link can create a pseudo-identifier. >> >> These pseudo-identifiers can be tracked across link boundaries, >> and can prevent movement and location-identity(if the identity was >> revealed on a previous or future link) privacy. > > > I guess I don't understand the problem you are trying to solve here, so > that I can gauge what the current threat situations looks like without DNA. > > Is the threat is that of an attacker which can simultaneously observe > packets on both link 1 and link 2, and you are concerned that such an > attacker can correlate the packets seen from the host on link 1 and on > link 2? I think primarily this is the case which would be applicable to DNA. > Without DNA this can be easily accomplished by looking at the traffic > patterns. For example, given TCP connection might attempt to continue > with the same source port number and destination port/ip after the move, > or the host might have done IKE+ESP to IP address 1.2.3.4 before the > move and after the move the host restarts IKE to IP address 1.2.3.4 (the > host's VPN gateway). If mobile IP is used then you'll see an ESP > protected packet (with a size of a binding update) being sent to the > same IP address as before (the host's HA); it might even have a Home > address option in the clear. And for http in the clear, the fact that > the host has RSS feeds from their favorite places will tell it apart. > > So traffic analysis can do lots in this space when the movement is near > instantaneous. Yes, that's certainly the case. when the user communities are small, it's fairly hard to hide movement from traffic analysis. On the other hand, one of the things to come out of the MoMiPriv list (and MobileIP based privacy work), is that there's a requirement for privacy analysis with each of the protocols used when attempting to maintain privacy. So the Application layers, ESP, IKE, MIPv6, DNAv6, and 802.1X etc. all have a role to play in maintaining dissociation between particular locations and identities (or movements across network boundaries). Certain of this information may not be possible to hide from AAA or Home Agents for example. I guess though, that there's an interest in the longer term to make communications casually untraceable. Some of this may require protocol re-engineering, although it may be possible to make some "Privacy Considerations", if we're aware of the basic problems around specification time. > That is quite different than the threat of an attacker which saw > Ethernet address X (and an IPv6 address with X as the IID) 2 months ago > and again sees the same Ethernet address. In that case some traffic > analysis might be helpful to the attacker even when the Ethernet address > has changed, but the host's traffic patterns might have changed in the > meantime. > > So I suggest we define what privacy problems we think we need to > address, and compare those with non-DNA related threats, before we start > working on solutions to privacy issues. Definitiely, I agree. The distinction is also a good one. It would be good though to have flexibility in DNAv6, to avoid passing out identifiers if a host doesn't explicitly need to. If we need to have a look at these issues in depth, there's likely to be work in Mobopts and MIP6, as well as on a couple of existing lists such as MoMiPriv. Some of the assumptions under which the discussions have been operating may be directly applicable to DNA. (So we may not have to develop them ourselves... I'll have a look at these if I have time soon). Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 03:07:10 2005 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 DAA02524 for ; Mon, 6 Jun 2005 03:07:09 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP5CMS925Y99K9IG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Jun 2005 17:06:43 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6A4FBAB545; Mon, 06 Jun 2005 17:06:38 +1000 (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 1EFD44FB0F; Mon, 06 Jun 2005 17:06:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5676au01807 for dna-list; Mon, 06 Jun 2005 17:06:36 +1000 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 j5676ar01802 for ; Mon, 06 Jun 2005 17:06:36 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP5CMBFK9299K9IG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Jun 2005 17:06:16 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DFBC880003; Mon, 06 Jun 2005 17:06:15 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 924513C018; Mon, 06 Jun 2005 17:06:15 +1000 (EST) Date: Mon, 06 Jun 2005 17:06:09 +1000 From: Greg Daley Subject: [DNA] Revised text for link-information Ethernet section for comment Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au, Alper Yegin Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A3F5E1.6020101@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear Alper and WG, Here is an update of the text provided before last IETF for Ethernet in the link-information document. I'm not sure how useful the recommendations are to people, and apparently there was some difficulty even amongst DNA illuminati in understanding what I was getting at in the last version. So if you have any opinions or experience, please comment on-list, in order that forward progress can be made. Greg Text follows, potentially to be inserted as a section in the draft-ietf-dna-link-information. ------------------------------------------------- Ethernet is the most commonly deployed Local Area Network technology in use today. As deployed today, it is specified by both a physical layer/medium access control (MAC) layer specification [802.3], and a bridging specification used for connecting different ethernet LAN segments together [802.1d]. In Ethernet networks, hosts are connected by wires or by optic fibre to a switch (bridge), a bus (e.g. co-axial cable), a repeater (hub), or directly to another ethernet device. Interfaces are symmetric, in that while many different physical laters may be present, medium access control is uniform for all devices. In order to determine whether the physical medium is ready for frame transfer, Ethernet specifies its own link monitoring mechanism. This Link Integrity Test operation is used to identify when packets are able to be received on an ethernet segment. It is applicable to both wired and optical physical layers, although details vary between technologies (link pulses in copper, light levels in fibre). Subsection: Link Integrity Tests in 802.3 networks. --------------------------------------------------- The status of the link as determined by the Link Integrity Test is stored in the variable 'link_status'. Changes to the value of link_status (for example due to Link Integrity Test failure) will generate link indications if the technology dependent interface is implemented on an ethernet device [802.3]. The link_status has possible values of FAIL, READY and OK. When an interface is in FAIL state, Link Integrity Tests have failed. Where status is READY, the link segment has passed integrity tests, but autonegotiation has not completed. OK state indicates that the medium is able to send and receive packets. Upon transition to a particular state the Physical Medium Attachment subsystems generates a PMA_LINK.indicate(link_status). Indications of OK state may be used as Link-Up indications for DNA. PMA_LINK.indicate(FAIL) may be used as a Link-Down indication reliably by DNA[802.3]. Such indications do not definitively ensure that packets will be able to be received through the switching infrastructure which composes a broadcast domain, though. Such operations are governed by bridging. Subsection: 802.1d Bridging and its effects on link indications -------------------------------------------------------------- Ethernet networks are commonly bridged. Bridging is a mechanism which provides loopless paths across a series of link-segments. Due to its necessity in preventing bridge loops, bridging has become synonymous with the spanning tree protocol. The spanning tree protocol and its variants provide loopless forwarding between ethernet-like switches within a broadcast domain. The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit (BPDU) frames in order to pass information about which switches are connected to others. By default, the spanning tree protocol does not know whether a particular newly connected piece of ethernet will cause a bridge loop. Therefore it typically blocks all traffic from a port until spanning tree operations can determine if a loop exists. For these technologies, even though the link-layer appears available, no forwarding will occur until the network is satisfied that the connected is not another bridge or repeater port. No explicit indication that forwarding has begun is sent from a switch to its peer devices. Therefore, a host may not know when STP operations have completed, and when it is safe to inform upper layers to transmit packets. As described in (Subsection on 802.1AB LLDP) explicit knowledge may be available through the new Link-Layer Discovery Protocol as to whether frame forwarding operation is immediately available. Where it is not known that forwarding operations are available, a host needs to assume that STP is being performed, and may indicate full connectivity only based on reception of BPDUs or timeouts. Upon learning that an adjacent port is running STP or RSTP, the host may send a Link-Up indication with a 'forwarding available' parameter upon expiry of calculated delays to indicate that general packet transfer is available across the LAN. If no bridge configuration messages are received within the default Bridge_Max_Age interval (20s), then it is unlikely that the peer device is a bridge, since at least two BPDU hello messages have been lost. Upon this timeout, a host may (re)-send a link-layer indication showing that packets sent within the prior interval were likely to have traversed the forwarding path. If a BPDU is received, and the peer is running the original Spanning Tree Protocol, then host cannot successfully send packets until at least the peer's ForwardDelay timer has expired twice. This timeout defaults to 30 seconds (2 * 15 seconds) [802.1d]. After this time, the host can send a link-layer up indication showing that the previous interval after the PMA_LINK.indicate(OK) event was one of loss. If the switch is identified as performing Rapid Spanning Tree Protocol (RSTP), it instead waits Bridge_Max_Age after packet reception (advertised in the BPDU's Max Age field), before forwarding. For ports which are known to be point-to-point through autonegotiation, this delay is abbreviated to 3 seconds after autonegotiation completes [802.1d]. After either of these delays, a link-layer indication updating the PMA_LINK.indicate(OK) can show that the interval between indications was a lossy interval. Subsection: 802.1AB Link-Layer Discovery Protocol. ------------------------------------------------- The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) provides information to directly connected devices about its MAC peer[802.1AB]. LLDP sends information periodically, and at link status change time to indicate the configuration parameters of the device. Devices may either send or receive these messages, or both. The LLDP message may a System Capabilities TLV, which describes the MAC and IP layer functions which a device is currently using. Where a host receives the Systems Capabilities TLV which indicate that no Bridging or Repeating is occurring on the link-layer peer, then no delays for STP calculation will be applied to packets sent from this host. This would allow an authoritative link-layer indication to be sent to upper-layers about the availability of packet transfer. Additionally, if a host receives a Systems Capabilities TLV which indicates that the peer is a switch or repeater, the host's advertisement that it is an (end-host) Station-Only, may tell the peer switch not to run STP, and immediately allow forwarding. Proprietary extensions may also indicate that data forwarding is already available on such a port. Discussions of such optimizations is out-of-scope for this document. Due to the protocol's newness and lack of deployment, it is unclear how this protocol will eventually affect DNA in IPv4 or IPv6 networks. Summary ------- Link-Layer indications in Ethernet-like networks are complicated by additional unadvertised delays due to Spanning Tree calculations. This may cause re-indication or retraction of indications previously sent to upper layer protocols. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 03:15:21 2005 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 DAA05134 for ; Mon, 6 Jun 2005 03:15:20 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP5CX8OWY29AO6FT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Jun 2005 17:15:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3DAA0AB54B; Mon, 06 Jun 2005 17:15:04 +1000 (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 E1F6F4FB0A; Mon, 06 Jun 2005 17:15:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j567EYi01949 for dna-list; Mon, 06 Jun 2005 17:14:34 +1000 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 j567EXr01945 for ; Mon, 06 Jun 2005 17:14:33 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP5CWBGPAM94PQ81@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Jun 2005 17:14:21 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 93858AB542 for ; Mon, 06 Jun 2005 17:14:19 +1000 (EST) Received: from relay1.mail.vrmd.de (relay1.mail.vrmd.de [81.28.232.18]) by curly.its.monash.edu.au (Postfix) with ESMTP id A22284FB06 for ; Mon, 06 Jun 2005 17:14:17 +1000 (EST) Received: from [213.196.207.223] (helo=[213.196.207.223]) by vm8.bln2.vrmd.de with asmtp (Exim 4.41) id 1DfBoM-00018S-Jd for dna@eng.monash.edu.au; Mon, 06 Jun 2005 09:14:15 +0200 Date: Mon, 06 Jun 2005 09:14:22 +0200 From: Marc Manthey Subject: [DNA] Is there life after DNS ? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-20-148426174; protocol="application/pkcs7-signature" X-Relay-User: marc@let.de --Apple-Mail-20-148426174 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi all, did you ever ask yourself that question? With 2369 domains we have the best root. We are the frontier. We have to think what comes after DNS. ICANN does not face that frontier. They used to have 250 Domains but they lost one. No they are back to 249. They cannot go up to 250 again because the next domain they want to introduse is "xxx." and that gets filtered and accused on most servers they use because they are owned by universities. It just happened to me and several others on NANOG. :) IPv6 will be a challenge. No normal human beeing thinks of typing in IPv6 addresses. Cut and paste, maybe - but typing, no! IPv6 will break DNS! There are nameservers behind firewalls that dont allow tpc connections to the namesevers. IPv6 addresses will break packet borders and they will finally break these nameservers. You dont need IPv6? Ipv4 is good enuf for you? Joe and me, we have seen IPv9 working. Stay with your old IPv4 machines and let governements decide what is good for you. Send your emails to the governement and let them decide what is spam. They are looking forward to reading and maybe forwarding or not your emails. Who needs to run a mailserver anyhow. Dont you think its a good idea of the goverment to close port 25 forwarding? If you dont think so read on! Today we have to worlds a host might live in. There are some good guys running servers running important machines with fixed addresses. They make up the world of DNS. Everybody can ask DNS for their addresses and maybe their names. And then we have hosts like yours and mine connected via NAT-routers to dsl- or cable-modems or to good old pots via good old modems. Whenever I connect to the internet I get a new ip. An ip that somebody else might have used for sending spam the I cannot use it for sending emails. An ip that nobody knows not even me. If I dont disconnect and reconnect my provider will do that for me once every 24 hours. That is the world of P2P users and services like no-ip.com . How do these hosts know eachother? How do they find eachother. How do they connect? How do they identify? There is live outside DNS. I have met them. Before we had DNS there was /etc/hosts and there still is NIS. NIS+ might have become DNS but SUN has given up. It does not scale up. Still there is P2P. It is losely connected to DNS by services like no- ip.com Does P2P really need static ip addresses?. The DSLAM the concentrator and router I am connected to, manages some 4K addresses. To find echnaton.serveftp.com just try 4K ip addresses and you have got me. If only 100 hosts of those 4K possible addresses in the voicinity of frankfurt on main, germany had a P2P-nameservice running you would only have to ask 40 addresses to get me. You got me? best regards regards, marc manthey www.cuseeme.de ******************************************************** opencuseeme / peer2peer multiparty conferencing ******************************************************** --Apple-Mail-20-148426174 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHHzCCA0kw ggKyoAMCAQICDgpqAAEAAntSGyw2RRVxMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50 ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu ZGUwHhcNMDUwNTA5MTQzMjQ4WhcNMDYwNTA5MTQzMjQ4WjBAMQswCQYDVQQGEwJERTEVMBMGA1UE AxMMTWFyYyBNYW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAvwCjxxISYuhol4fmTuqlvYN3JOLxcceKV3T8OzmBqQVkbKvmkqh+d5ue O+Dz4ZD9sYKbvbAcQmfLqra94of91kM20oPlAalNcSNe8HUEDEVb4GHdqPVwmaVK9jJ5BUPDMheq W5TR5X/ATEfQU7oCZSI/7+h9Ww3anbUXIZeCCOMCAwEAAaOByDCBxTAMBgNVHRMBAf8EAjAAMA4G A1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cu dHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzBBNkEwMDAxMDAwMjdCNTIxQjJD MzY0NTE1NzE/MA0GCSqGSIb3DQEBBAUAA4GBAE94N6LMW8iv8HvV9RC77acqqCw4JyLYB6pcgTK9 bpEYxkdggTJRUnCMzz8TOOzVvfA2mzEmwoKDnMYUFugAxdLbFPuxsw4aJ9vMZPdppz28nBDdx1jt lmoJvm3fogTLCGfhWyrd68/tqneYNf540iiXPkp9bwVs8qvQFyEUa8Y8MIIDzjCCAzegAwIBAgIP AJn2AAAAAtbxQYHMGpdhMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMH SGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNl Y3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDUw MjA0MTY0ODQ3WhcNMDYwMjA0MTY0ODQ3WjBAMQswCQYDVQQGEwJERTEVMBMGA1UEAxMMTWFyYyBN YW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANL2cTdJD0oNKje7z4466yUIRX8DJbmjCZBMLtnmHiEqMrpK2rQps8Gcmp3ueB+d o7lGwU7YH3m676a5XhyvcaYwmu1C2gLfBiOzbijbZLP95vP0Aowf9HyuO6iTS42el73q+6MKCY8h O1px1R1blj9cxFeGfFXiG8Oz2QOi7sfJHB+Vp9WVU8ZI1I8NibF/wAN8HzZSdbKkEArGarBCYZ8J Em9C7UZpxc3fx61PePP/z5j4GeQVt+iI5FzBMlg0T7W5X16D0yQuLQb2ajeYJhstFC0KrbO+v9eV WnOsXzOYo+PkPH4O6tOKyX14GFITKYWTwyU6It03XrO/lAvn80kCAwEAAaOByDCBxTAMBgNVHRMB Af8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNl bnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0 cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzk5RjYwMDAwMDAw MkQ2RjE0MTgxQ0MxQTk3NjE/MA0GCSqGSIb3DQEBBAUAA4GBAF3ZoITTnsH5RDnrDWReZJPv9WUF yGPjjKIUHQlGeEg+JY4T5b8SrHJGkyxyoc2dj3E5G7iJ173mz5IK42YizLRNCcw3gZcSJQl8SqiL L7VN/xdOZfbZKFhDStraQXghJ9tvoD5CNzFKblW71W0iv2f1R7GPwR+lKB9S5ZejZj+CMYIDoTCC A50CAQEwgc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1i dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3Jr cyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOCmoAAQACe1IbLDZFFXEwCQYFKw4DAhoFAKCC AicwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNjA2MDcxNDIz WjAjBgkqhkiG9w0BCQQxFgQUuoffkgdkzBxjSgRkSIqNjhXluqYwgeEGCSsGAQQBgjcQBDGB0zCB 0DCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4 BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgx IjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AmfYAAAAC1vFBgcwal2EwgeMGCyqGSIb3DQEJEAILMYHT oIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6 MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQEFAASB gCbk58BFQWVbSTOh63JOgdSta3b1nx+aFNKoP1qyY1Ic+IQJSxqJ8xkjYiQOhdIJoJJ5UNWnpVX0 J7RBz+R2wPufzSmjOOpe1jbjUunvfc1DBji7jlHxiyRTLAKoOxtAKgYvuZ7lsgTZCAWzaXVJbGZ1 uKPYriIOlkLyqitwqYwqAAAAAAAA --Apple-Mail-20-148426174-- From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 04:00:04 2005 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 EAA08077 for ; Mon, 6 Jun 2005 04:00:03 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP5EH8U0CA97984H@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Jun 2005 17:59:36 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6C8A480002; Mon, 06 Jun 2005 17:59:26 +1000 (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 912853C003; Mon, 06 Jun 2005 17:59:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j567xGo02472 for dna-list; Mon, 06 Jun 2005 17:59:16 +1000 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 j567xEr02468 for ; Mon, 06 Jun 2005 17:59:14 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP5EGTF8JU97984H@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Jun 2005 17:59:06 +1000 Received: by localhost (Postfix, from userid 510) id DE07C80002; Mon, 06 Jun 2005 17:59:05 +1000 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) (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 7721D3C005; Mon, 06 Jun 2005 17:59:04 +1000 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j567uYdd018143; Mon, 06 Jun 2005 03:56:34 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j567uUdd018105; Mon, 06 Jun 2005 03:56:32 -0400 (EDT) Date: Mon, 06 Jun 2005 10:58:54 +0300 From: "Romascanu, Dan (Dan)" Subject: RE: [DNA] Revised text for link-information Ethernet section for comment Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au, Alper Yegin Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Revised text for link-information Ethernet section for comment Thread-Index: AcVqZlLJvWbIriXbQXmYDgPbiXpOWAABmjDw content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg, I am the chair of the Ethernet MIB WG and co-chair of the Bridge MIB WG. I do have experience with link state information in Ethernet and IEEE 802.1 bridges. I will read the proposed text and provide my individual opinion. I would recommend that you submit this text for review to the Ethernet MIB WG list (hubmib@ietf.org) and to the Bridge MIB WG list (bridge-mib@ietf.org) so that more experts have a look at the text. I can also forward this mail to these lists and ask for opinions to be fed back into the dna list. Regards, Dan > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley > Sent: Monday, June 06, 2005 10:06 AM > To: dna@eng.monash.edu.au; Alper Yegin > Subject: [DNA] Revised text for link-information Ethernet > section for comment > > Dear Alper and WG, > > Here is an update of the text provided before last IETF for > Ethernet in the link-information document. > > I'm not sure how useful the recommendations are to people, > and apparently there was some difficulty even amongst DNA > illuminati in understanding what I was getting at in the last version. > > So if you have any opinions or experience, please comment > on-list, in order that forward progress can be made. > > Greg > > > Text follows, potentially to be inserted as a section in the > draft-ietf-dna-link-information. > > ------------------------------------------------- > > Ethernet is the most commonly deployed Local Area Network > technology in use today. > As deployed today, it is specified by both a physical > layer/medium access control (MAC) layer specification > [802.3], and a bridging specification used for connecting > different ethernet LAN segments together [802.1d]. > > In Ethernet networks, hosts are connected by wires or by > optic fibre to a switch (bridge), a bus (e.g. co-axial > cable), a repeater (hub), or directly to another ethernet > device. Interfaces are symmetric, in that while many > different physical laters may be present, medium access > control is uniform for all devices. > > In order to determine whether the physical medium is ready > for frame transfer, Ethernet specifies its own link > monitoring mechanism. > This Link Integrity Test operation is used to identify when > packets are able to be received on an ethernet segment. > It is applicable to both wired and optical physical layers, > although details vary between technologies (link pulses in > copper, light levels in fibre). > > Subsection: Link Integrity Tests in 802.3 networks. > --------------------------------------------------- > > The status of the link as determined by the Link Integrity > Test is stored in the variable 'link_status'. Changes to the > value of link_status (for example due to Link Integrity Test > failure) will generate link indications if the technology > dependent interface is implemented on an ethernet device [802.3]. > > The link_status has possible values of FAIL, READY and OK. > When an interface is in FAIL state, Link Integrity Tests have failed. > Where status is READY, the link segment has passed integrity > tests, but autonegotiation has not completed. OK state > indicates that the medium is able to send and receive packets. > > Upon transition to a particular state the Physical Medium > Attachment subsystems generates a > PMA_LINK.indicate(link_status). Indications of OK state may > be used as Link-Up indications for DNA. > PMA_LINK.indicate(FAIL) may be used as a Link-Down indication > reliably by DNA[802.3]. > > Such indications do not definitively ensure that packets will > be able to be received through the switching infrastructure > which composes a broadcast domain, though. Such operations > are governed by bridging. > > Subsection: 802.1d Bridging and its effects on link indications > -------------------------------------------------------------- > > Ethernet networks are commonly bridged. > Bridging is a mechanism which provides loopless paths across > a series of link-segments. > > Due to its necessity in preventing bridge loops, bridging has > become synonymous with the spanning tree protocol. > The spanning tree protocol and its variants provide loopless > forwarding between ethernet-like switches within a broadcast domain. > > The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit > (BPDU) frames in order to pass information about which > switches are connected to others. > By default, the spanning tree protocol does not know whether > a particular newly connected piece of ethernet will cause a > bridge loop. > Therefore it typically blocks all traffic from a port until > spanning tree operations can determine if a loop exists. > > For these technologies, even though the link-layer appears > available, no forwarding will occur until the network is > satisfied that the connected is not another bridge or repeater port. > > No explicit indication that forwarding has begun is sent from > a switch to its peer devices. Therefore, a host may not know > when STP operations have completed, and when it is safe to > inform upper layers to transmit packets. > > As described in (Subsection on 802.1AB LLDP) explicit > knowledge may be available through the new Link-Layer > Discovery Protocol as to whether frame forwarding operation > is immediately available. > > Where it is not known that forwarding operations are > available, a host needs to assume that STP is being > performed, and may indicate full connectivity only based on > reception of BPDUs or timeouts. > > Upon learning that an adjacent port is running STP or RSTP, > the host may send a Link-Up indication with a 'forwarding available' > parameter upon expiry of calculated delays to indicate that > general packet transfer is available across the LAN. > > If no bridge configuration messages are received within the > default Bridge_Max_Age interval (20s), then it is unlikely > that the peer device is a bridge, since at least two BPDU > hello messages have been lost. > Upon this timeout, a host may (re)-send a link-layer > indication showing that packets sent within the prior > interval were likely to have traversed the forwarding path. > > If a BPDU is received, and the peer is running the original > Spanning Tree Protocol, then host cannot successfully send > packets until at > least the peer's ForwardDelay timer has expired twice. This timeout > defaults to 30 seconds (2 * 15 seconds) [802.1d]. After this > time, the host can send a link-layer up indication showing > that the previous interval after the PMA_LINK.indicate(OK) > event was one of loss. > > If the switch is identified as performing Rapid Spanning Tree > Protocol (RSTP), it instead waits Bridge_Max_Age after packet > reception (advertised in the BPDU's Max Age field), before forwarding. > For ports which are known to be point-to-point through > autonegotiation, this delay is abbreviated to 3 seconds after > autonegotiation completes [802.1d]. > After either of these delays, a link-layer indication updating the > PMA_LINK.indicate(OK) can show that the interval between > indications was a lossy interval. > > > Subsection: 802.1AB Link-Layer Discovery Protocol. > ------------------------------------------------- > > The recently defined 802.1AB Link-Layer Discovery Protocol > (LLDP) provides information to directly connected devices > about its MAC peer[802.1AB]. > > LLDP sends information periodically, and at link status > change time to indicate the configuration parameters of the device. > Devices may either send or receive these messages, or both. > > The LLDP message may a System Capabilities TLV, which > describes the MAC and IP layer functions which a device is > currently using. > Where a host receives the Systems Capabilities TLV which > indicate that no Bridging or Repeating is occurring on the > link-layer peer, then no delays for STP calculation will be > applied to packets sent from this host. This would allow an > authoritative link-layer indication to be sent to > upper-layers about the availability of packet transfer. > > Additionally, if a host receives a Systems Capabilities TLV > which indicates that the peer is a switch or repeater, the > host's advertisement that it is an (end-host) Station-Only, > may tell the peer switch not to run STP, and immediately > allow forwarding. > > Proprietary extensions may also indicate that data forwarding > is already available on such a port. Discussions of such > optimizations is out-of-scope for this document. > > Due to the protocol's newness and lack of deployment, it is > unclear how this protocol will eventually affect DNA in IPv4 > or IPv6 networks. > > > Summary > ------- > > Link-Layer indications in Ethernet-like networks are > complicated by additional unadvertised delays due to Spanning > Tree calculations. > This may cause re-indication or retraction of indications > previously sent to upper layer protocols. > > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 05:02:28 2005 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 FAA11208 for ; Mon, 6 Jun 2005 05:02:27 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP5GNNWP7097955X@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Jun 2005 19:02:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D8DB580004; Mon, 06 Jun 2005 19:01:52 +1000 (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 955703C005; Mon, 06 Jun 2005 19:01:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5691Sw03180 for dna-list; Mon, 06 Jun 2005 19:01:28 +1000 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 j5691Rr03176 for ; Mon, 06 Jun 2005 19:01:27 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP5GMT8ZCI9AO7OF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Jun 2005 19:01:12 +1000 Received: by localhost (Postfix, from userid 510) id E636180002; Mon, 06 Jun 2005 19:01:11 +1000 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) (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 5EA033C006; Mon, 06 Jun 2005 19:01:09 +1000 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j568wddd026600; Mon, 06 Jun 2005 04:58:39 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j568wXdd026482; Mon, 06 Jun 2005 04:58:34 -0400 (EDT) Date: Mon, 06 Jun 2005 12:00:58 +0300 From: "Romascanu, Dan (Dan)" Subject: RE: [DNA] Revised text for link-information Ethernet section for comment Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au, Alper Yegin Cc: dbharrington@comcast.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Revised text for link-information Ethernet section for comment Thread-Index: AcVqZlLJvWbIriXbQXmYDgPbiXpOWAACVVLg content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Please see comments to this section below. As I said in my previous mail, it would be good to run this text with the Ethernet Interfaces MIB and Bridge MIB lists. The co-chair of the Bridge MIB is also copied. Regards, Dan > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley > Sent: Monday, June 06, 2005 10:06 AM > To: dna@eng.monash.edu.au; Alper Yegin > Subject: [DNA] Revised text for link-information Ethernet > section for comment > > Dear Alper and WG, > > Here is an update of the text provided before last IETF for > Ethernet in the link-information document. > > I'm not sure how useful the recommendations are to people, > and apparently there was some difficulty even amongst DNA > illuminati in understanding what I was getting at in the last version. > > So if you have any opinions or experience, please comment > on-list, in order that forward progress can be made. > > Greg > > > Text follows, potentially to be inserted as a section in the > draft-ietf-dna-link-information. > > ------------------------------------------------- > > Ethernet is the most commonly deployed Local Area Network > technology in use today. > As deployed today, it is specified by both a physical > layer/medium access control (MAC) layer specification > [802.3], and a bridging specification used for connecting > different ethernet LAN segments together [802.1d]. No - this is not accurate. Ethernet is only IEEE 802.3 technology. Bridging technology as defined by IEEE 802.1D and other standards in the 802.1 family can run with different MAC technologies, Ethernet included, but is not Ethernet. > > In Ethernet networks, hosts are connected by wires or by > optic fibre to a switch (bridge), a bus (e.g. co-axial > cable), a repeater (hub), or directly to another ethernet > device. Interfaces are symmetric, in that while many > different physical laters may be present, medium access > control is uniform for all devices. > > In order to determine whether the physical medium is ready > for frame transfer, Ethernet specifies its own link > monitoring mechanism. > This Link Integrity Test operation is used to identify when > packets are able to be received on an ethernet segment. > It is applicable to both wired and optical physical layers, > although details vary between technologies (link pulses in > copper, light levels in fibre). > > Subsection: Link Integrity Tests in 802.3 networks. > --------------------------------------------------- > > The status of the link as determined by the Link Integrity > Test is stored in the variable 'link_status'. Changes to the > value of link_status (for example due to Link Integrity Test > failure) will generate link indications if the technology > dependent interface is implemented on an ethernet device [802.3]. > > The link_status has possible values of FAIL, READY and OK. > When an interface is in FAIL state, Link Integrity Tests have failed. > Where status is READY, the link segment has passed integrity > tests, but autonegotiation has not completed. OK state > indicates that the medium is able to send and receive packets. > > Upon transition to a particular state the Physical Medium > Attachment subsystems generates a > PMA_LINK.indicate(link_status). Indications of OK state may > be used as Link-Up indications for DNA. > PMA_LINK.indicate(FAIL) may be used as a Link-Down indication > reliably by DNA[802.3]. > > Such indications do not definitively ensure that packets will > be able to be received through the switching infrastructure > which composes a broadcast domain, though. Such operations > are governed by bridging. 'The term switching infrastructure' has no firm definition in standards. Beyond this, 'switches' can be deplotyed beyond one single broadcast domain. You probably would like to use 'bridging domain' instead. > > Subsection: 802.1d Bridging and its effects on link indications > -------------------------------------------------------------- The correct spelling is (IEEE) 802.1D > > Ethernet networks are commonly bridged. > Bridging is a mechanism which provides loopless paths across > a series of link-segments. 'Link-segments' is again fuzzy from a standard terminology perspective. Maybe 'Briding is a mechanisms which provides loopless paths across LANs interconnected by IEEE 802.1D bridges' > > Due to its necessity in preventing bridge loops, bridging has > become synonymous with the spanning tree protocol. > The spanning tree protocol and its variants provide loopless > forwarding between ethernet-like switches within a broadcast domain. > > The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit > (BPDU) frames in order to pass information about which > switches are connected to others. Better use 'bridges' rather than 'switches'. > By default, the spanning tree protocol does not know whether > a particular newly connected piece of ethernet will cause a > bridge loop. Just 'loop'. > Therefore it typically blocks all traffic from a port until > spanning tree operations can determine if a loop exists. > Better - 'therefore it will block all traffic from and to a newly connected ports with the exception of the STP BPDUs. The STP will determine is the port can be connected to the network in a loop-free environment'. > For these technologies, even though the link-layer appears > available, no forwarding will occur until the network is > satisfied that the connected is not another bridge or repeater port. Better '... Until it is determined that the port can be connected to the network in a loop-free environment'. > > No explicit indication that forwarding has begun is sent from > a switch to its peer devices. Therefore, a host may not know > when STP operations have completed, and when it is safe to > inform upper layers to transmit packets. > > As described in (Subsection on 802.1AB LLDP) explicit > knowledge may be available through the new Link-Layer > Discovery Protocol as to whether frame forwarding operation > is immediately available. > > Where it is not known that forwarding operations are > available, a host needs to assume that STP is being > performed, and may indicate full connectivity only based on > reception of BPDUs or timeouts. > > Upon learning that an adjacent port is running STP or RSTP, > the host may send a Link-Up indication with a 'forwarding available' > parameter upon expiry of calculated delays to indicate that > general packet transfer is available across the LAN. No need to do this IMO. For its own availability a host knows when a local port is transiting into forwarding state. See IEEE 802.1D-1998: clause 8.5.5.2 and the dot1dStpPortState in the Bridge MIB (latest version http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bridge-brid gemib-smiv2-10.txt to be published as a proposed standard any time now). > > If no bridge configuration messages are received within the > default Bridge_Max_Age interval (20s), then it is unlikely > that the peer device is a bridge, since at least two BPDU > hello messages have been lost. > Upon this timeout, a host may (re)-send a link-layer > indication showing that packets sent within the prior > interval were likely to have traversed the forwarding path. > > If a BPDU is received, and the peer is running the original > Spanning Tree Protocol, then host cannot successfully send > packets until at > least the peer's ForwardDelay timer has expired twice. This timeout > defaults to 30 seconds (2 * 15 seconds) [802.1d]. After this > time, the host can send a link-layer up indication showing > that the previous interval after the PMA_LINK.indicate(OK) > event was one of loss. > > If the switch is identified as performing Rapid Spanning Tree > Protocol (RSTP), it instead waits Bridge_Max_Age after packet > reception (advertised in the BPDU's Max Age field), before forwarding. > For ports which are known to be point-to-point through > autonegotiation, this delay is abbreviated to 3 seconds after > autonegotiation completes [802.1d]. > After either of these delays, a link-layer indication updating the > PMA_LINK.indicate(OK) can show that the interval between > indications was a lossy interval. What is the bridge port is disabled by a management command? See IEEE 802.1D-1998: clause 8.5.5.2, and the dot1dStpPortEnable object in the Bridge MIB. > > > Subsection: 802.1AB Link-Layer Discovery Protocol. > ------------------------------------------------- > > The recently defined 802.1AB Link-Layer Discovery Protocol > (LLDP) provides information to directly connected devices > about its MAC peer[802.1AB]. > > LLDP sends information periodically, and at link status > change time to indicate the configuration parameters of the device. > Devices may either send or receive these messages, or both. > > The LLDP message may a System Capabilities TLV, which > describes the MAC and IP layer functions which a device is > currently using. > Where a host receives the Systems Capabilities TLV which > indicate that no Bridging or Repeating is occurring on the > link-layer peer, then no delays for STP calculation will be > applied to packets sent from this host. This would allow an > authoritative link-layer indication to be sent to > upper-layers about the availability of packet transfer. This does not look right. The IEEE 802.1AB system capabilities reflects only what capabilities are enabled on the remote host (see Section 9.5.8.1 in the IEEE 802.1AB specification). The fact that a bridge for example is connected at the other end does not mean that the port of the bridge is enabled, or that spanning tree allows data packet transfer. > > Additionally, if a host receives a Systems Capabilities TLV > which indicates that the peer is a switch or repeater, the > host's advertisement that it is an (end-host) Station-Only, > may tell the peer switch not to run STP, and immediately > allow forwarding. > > Proprietary extensions may also indicate that data forwarding > is already available on such a port. Discussions of such > optimizations is out-of-scope for this document. > > Due to the protocol's newness and lack of deployment, it is > unclear how this protocol will eventually affect DNA in IPv4 > or IPv6 networks. > > > Summary > ------- > > Link-Layer indications in Ethernet-like networks are > complicated by additional unadvertised delays due to Spanning > Tree calculations. > This may cause re-indication or retraction of indications > previously sent to upper layer protocols. > > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 12:13:54 2005 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 MAA13581 for ; Mon, 6 Jun 2005 12:13:52 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP5VQ1NLD89AO60N@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 02:13:44 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6FE4FAB543; Tue, 07 Jun 2005 02:13:41 +1000 (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 2778F4FB02; Tue, 07 Jun 2005 02:13:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j56GCtO07767 for dna-list; Tue, 07 Jun 2005 02:12:55 +1000 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 j56GCsr07763 for ; Tue, 07 Jun 2005 02:12:54 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP5VOXBPU499K52X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 02:12:47 +1000 Received: by localhost (Postfix, from userid 510) id 63CE7AB542; Tue, 07 Jun 2005 02:12:47 +1000 (EST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4D9814FB07; Tue, 07 Jun 2005 02:12:44 +1000 (EST) Received: from pc6 (1Cust96.tnt10.lnd4.gbr.da.uu.net [62.188.139.96]) by galaxy.systems.pipex.net (Postfix) with SMTP id 89FFDE00009B; Mon, 06 Jun 2005 17:12:37 +0100 (BST) Date: Mon, 06 Jun 2005 17:07:24 +0200 From: Tom Petch Subject: Re: [DNA] Revised text for link-information Ethernet section for comment Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Reply-to: Tom Petch Message-id: <04e001c56aa9$87ae6de0$0601a8c0@pc6> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: Content-Transfer-Encoding: 7BIT I agree with Dan and would add: Properly the technology is IEEE 802.3 CSMA/CD (and even that leaves out quite a lot of the title) and I would like you to introduce it as such, adding something like 'commonly referred to as Ethernet' If you are going to use Ethernet (as opposed to say CSMA/CD or IEEE 802.3) in the rest of the document, then you should add a sentence to that effect (the term Ethernet scarcely appears in IEEE 802.3). It is wrong to say that all media have Link Integrity Tests eg 10BASE5 (yes, it is still in use). The default I see is BPDU Hello every two seconds so within the default 20s, more than two will have been lost. But this paragraph and the following one confuse me with references to peer device. This is broadcast, a degenerate case being only two devices, and if there is a bridge anywhere in the topology, then I expect to see BPDU every 2s. Spanning Tree will not work without them so not seeing them says either no bridges or Spanning Tree has been disabled (does happen, used to be common with slow - eg WAN - links) Tom Petch ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: ; ; "Alper Yegin" Cc: Sent: Monday, June 06, 2005 11:00 AM Subject: RE: [DNA] Revised text for link-information Ethernet section for comment > Please see comments to this section below. As I said in my previous > mail, it would be good to run this text with the Ethernet Interfaces MIB > and Bridge MIB lists. > > The co-chair of the Bridge MIB is also copied. > > Dan > > > -----Original Message----- > > From: owner-dna@ecselists.eng.monash.edu.au > > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley > > Sent: Monday, June 06, 2005 10:06 AM > > To: dna@eng.monash.edu.au; Alper Yegin > > Subject: [DNA] Revised text for link-information Ethernet > > section for comment > > > > Dear Alper and WG, > > > > Here is an update of the text provided before last IETF for > > Ethernet in the link-information document. > > > > I'm not sure how useful the recommendations are to people, > > and apparently there was some difficulty even amongst DNA > > illuminati in understanding what I was getting at in the last version. > > > > So if you have any opinions or experience, please comment > > on-list, in order that forward progress can be made. > > > > Greg > > > > Text follows, potentially to be inserted as a section in the > > draft-ietf-dna-link-information. > > > > ------------------------------------------------- > > > > Ethernet is the most commonly deployed Local Area Network > > technology in use today. > > As deployed today, it is specified by both a physical > > layer/medium access control (MAC) layer specification > > [802.3], and a bridging specification used for connecting > > different ethernet LAN segments together [802.1d]. > > No - this is not accurate. Ethernet is only IEEE 802.3 technology. > Bridging technology as defined by IEEE 802.1D and other standards in the > 802.1 family can run with different MAC technologies, Ethernet included, > but is not Ethernet. > > > > > In Ethernet networks, hosts are connected by wires or by > > optic fibre to a switch (bridge), a bus (e.g. co-axial > > cable), a repeater (hub), or directly to another ethernet > > device. Interfaces are symmetric, in that while many > > different physical laters may be present, medium access > > control is uniform for all devices. > > > > In order to determine whether the physical medium is ready > > for frame transfer, Ethernet specifies its own link > > monitoring mechanism. > > This Link Integrity Test operation is used to identify when > > packets are able to be received on an ethernet segment. > > It is applicable to both wired and optical physical layers, > > although details vary between technologies (link pulses in > > copper, light levels in fibre). > > > > Subsection: Link Integrity Tests in 802.3 networks. > > --------------------------------------------------- > > > > The status of the link as determined by the Link Integrity > > Test is stored in the variable 'link_status'. Changes to the > > value of link_status (for example due to Link Integrity Test > > failure) will generate link indications if the technology > > dependent interface is implemented on an ethernet device [802.3]. > > > > The link_status has possible values of FAIL, READY and OK. > > When an interface is in FAIL state, Link Integrity Tests have failed. > > Where status is READY, the link segment has passed integrity > > tests, but autonegotiation has not completed. OK state > > indicates that the medium is able to send and receive packets. > > > > Upon transition to a particular state the Physical Medium > > Attachment subsystems generates a > > PMA_LINK.indicate(link_status). Indications of OK state may > > be used as Link-Up indications for DNA. > > PMA_LINK.indicate(FAIL) may be used as a Link-Down indication > > reliably by DNA[802.3]. > > > > Such indications do not definitively ensure that packets will > > be able to be received through the switching infrastructure > > which composes a broadcast domain, though. Such operations > > are governed by bridging. > > 'The term switching infrastructure' has no firm definition in standards. > Beyond this, 'switches' can be deplotyed beyond one single broadcast > domain. You probably would like to use 'bridging domain' instead. > > > > > Subsection: 802.1d Bridging and its effects on link indications > > -------------------------------------------------------------- > > The correct spelling is (IEEE) 802.1D > > > > > Ethernet networks are commonly bridged. > > Bridging is a mechanism which provides loopless paths across > > a series of link-segments. > > 'Link-segments' is again fuzzy from a standard terminology perspective. > Maybe 'Briding is a mechanisms which provides loopless paths across LANs > interconnected by IEEE 802.1D bridges' > > > > > Due to its necessity in preventing bridge loops, bridging has > > become synonymous with the spanning tree protocol. > > The spanning tree protocol and its variants provide loopless > > forwarding between ethernet-like switches within a broadcast domain. > > > > The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit > > (BPDU) frames in order to pass information about which > > switches are connected to others. > > Better use 'bridges' rather than 'switches'. > > > By default, the spanning tree protocol does not know whether > > a particular newly connected piece of ethernet will cause a > > bridge loop. > > Just 'loop'. > > > Therefore it typically blocks all traffic from a port until > > spanning tree operations can determine if a loop exists. > > > > Better - 'therefore it will block all traffic from and to a newly > connected ports with the exception of the STP BPDUs. The STP will > determine is the port can be connected to the network in a loop-free > environment'. > > > For these technologies, even though the link-layer appears > > available, no forwarding will occur until the network is > > satisfied that the connected is not another bridge or repeater port. > > Better '... Until it is determined that the port can be connected to the > network in a loop-free environment'. > > > > > No explicit indication that forwarding has begun is sent from > > a switch to its peer devices. Therefore, a host may not know > > when STP operations have completed, and when it is safe to > > inform upper layers to transmit packets. > > > > As described in (Subsection on 802.1AB LLDP) explicit > > knowledge may be available through the new Link-Layer > > Discovery Protocol as to whether frame forwarding operation > > is immediately available. > > > > Where it is not known that forwarding operations are > > available, a host needs to assume that STP is being > > performed, and may indicate full connectivity only based on > > reception of BPDUs or timeouts. > > > > Upon learning that an adjacent port is running STP or RSTP, > > the host may send a Link-Up indication with a 'forwarding available' > > parameter upon expiry of calculated delays to indicate that > > general packet transfer is available across the LAN. > > > No need to do this IMO. For its own availability a host knows when a > local port is transiting into forwarding state. See IEEE 802.1D-1998: > clause 8.5.5.2 and the dot1dStpPortState in the Bridge MIB (latest > version > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bridge-brid > gemib-smiv2-10.txt to be published as a proposed standard any time now). > > > > > If no bridge configuration messages are received within the > > default Bridge_Max_Age interval (20s), then it is unlikely > > that the peer device is a bridge, since at least two BPDU > > hello messages have been lost. > > Upon this timeout, a host may (re)-send a link-layer > > indication showing that packets sent within the prior > > interval were likely to have traversed the forwarding path. > > > > If a BPDU is received, and the peer is running the original > > Spanning Tree Protocol, then host cannot successfully send > > packets until at > > least the peer's ForwardDelay timer has expired twice. This timeout > > defaults to 30 seconds (2 * 15 seconds) [802.1d]. After this > > time, the host can send a link-layer up indication showing > > that the previous interval after the PMA_LINK.indicate(OK) > > event was one of loss. > > > > If the switch is identified as performing Rapid Spanning Tree > > Protocol (RSTP), it instead waits Bridge_Max_Age after packet > > reception (advertised in the BPDU's Max Age field), before forwarding. > > For ports which are known to be point-to-point through > > autonegotiation, this delay is abbreviated to 3 seconds after > > autonegotiation completes [802.1d]. > > After either of these delays, a link-layer indication updating the > > PMA_LINK.indicate(OK) can show that the interval between > > indications was a lossy interval. > > What is the bridge port is disabled by a management command? See IEEE > 802.1D-1998: clause 8.5.5.2, and the dot1dStpPortEnable object in the > Bridge MIB. > > > > > > > Subsection: 802.1AB Link-Layer Discovery Protocol. > > ------------------------------------------------- > > > > The recently defined 802.1AB Link-Layer Discovery Protocol > > (LLDP) provides information to directly connected devices > > about its MAC peer[802.1AB]. > > > > LLDP sends information periodically, and at link status > > change time to indicate the configuration parameters of the device. > > Devices may either send or receive these messages, or both. > > > > The LLDP message may a System Capabilities TLV, which > > describes the MAC and IP layer functions which a device is > > currently using. > > Where a host receives the Systems Capabilities TLV which > > indicate that no Bridging or Repeating is occurring on the > > link-layer peer, then no delays for STP calculation will be > > applied to packets sent from this host. This would allow an > > authoritative link-layer indication to be sent to > > upper-layers about the availability of packet transfer. > > This does not look right. The IEEE 802.1AB system capabilities reflects > only what capabilities are enabled on the remote host (see Section > 9.5.8.1 in the IEEE 802.1AB specification). The fact that a bridge for > example is connected at the other end does not mean that the port of the > bridge is enabled, or that spanning tree allows data packet transfer. > > > > > Additionally, if a host receives a Systems Capabilities TLV > > which indicates that the peer is a switch or repeater, the > > host's advertisement that it is an (end-host) Station-Only, > > may tell the peer switch not to run STP, and immediately > > allow forwarding. > > > > Proprietary extensions may also indicate that data forwarding > > is already available on such a port. Discussions of such > > optimizations is out-of-scope for this document. > > > > Due to the protocol's newness and lack of deployment, it is > > unclear how this protocol will eventually affect DNA in IPv4 > > or IPv6 networks. > > > > > > Summary > > ------- > > > > Link-Layer indications in Ethernet-like networks are > > complicated by additional unadvertised delays due to Spanning > > Tree calculations. > > This may cause re-indication or retraction of indications > > previously sent to upper layer protocols. > > > > > > Greg > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 14:43:47 2005 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 OAA27741 for ; Mon, 6 Jun 2005 14:43:46 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP60YUQ27099KANA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 04:43:38 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 13503AB545; Tue, 07 Jun 2005 04:43:34 +1000 (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 BBAD84FB07; Tue, 07 Jun 2005 04:43:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j56Ih2209611 for dna-list; Tue, 07 Jun 2005 04:43:02 +1000 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 j56Ih0r09607 for ; Tue, 07 Jun 2005 04:43:00 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP60XXIELE94PYXZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 04:42:49 +1000 Received: by localhost (Postfix, from userid 510) id 751F280003; Tue, 07 Jun 2005 04:42:49 +1000 (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 5B71C3C004; Tue, 07 Jun 2005 04:42:47 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j56IgVX9000657; Mon, 06 Jun 2005 14:42:31 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id ED3BC1E81B0; Mon, 06 Jun 2005 14:34:11 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id DE3C91E8171; Mon, 06 Jun 2005 14:34:11 -0400 (EDT) Date: Mon, 06 Jun 2005 14:42:13 -0400 From: Sathya Narayanan Subject: Re: [DNA] Route vs Advertise In-reply-to: <02b701c5689f$7f935d20$5e6015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <42A49905.1030406@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-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:59.79473 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429F4329.1040807@Research.Panasonic.COM> <42A0733E.2060403@Research.Panasonic.COM> <02b701c5689f$7f935d20$5e6015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Jim - >>A router MAY, however, advertise a >> combination of certified and uncertified subnet prefixes. >> Uncertified subnet prefixes are treated as unsecured (i.e., processed >> in the same way as unsecured router advertisements sent by non-SEND >> routers). The processing of unsecured messages is specified in >> Section 8. Note that SEND nodes that do not attempt to interoperate >> with non-SEND nodes MAY simply discard the unsecured information. >> >> >Note that this does not imply that the router advertisement should be >considered insecure, just the uncertified prefix. If the advertisement has a >signature verifiable with the router's certified public key, then the router >is trustworthy. > > I understand. Do you think we need to say 'the prefixes in the DNAO SHOULD NOT be verified against the prefixes listed in the certificate' in DNAv6? - Sathya From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 14:52:01 2005 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 OAA28171 for ; Mon, 6 Jun 2005 14:52:00 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP61963GX09AO748@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 04:51:55 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F093EAB545; Tue, 07 Jun 2005 04:51:52 +1000 (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 A42784FB09; Tue, 07 Jun 2005 04:51:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j56IpkL09739 for dna-list; Tue, 07 Jun 2005 04:51:46 +1000 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 j56Ipjr09735 for ; Tue, 07 Jun 2005 04:51:45 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP618OL4PY94PYXZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 04:51:29 +1000 Received: by localhost (Postfix, from userid 510) id 99938AB542; Tue, 07 Jun 2005 04:51:29 +1000 (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 7F25C4FB06; Tue, 07 Jun 2005 04:51:28 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j56IpOJI000966; Mon, 06 Jun 2005 14:51:24 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 0CC181E817A; Mon, 06 Jun 2005 14:43:05 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id F2DD41E8171; Mon, 06 Jun 2005 14:43:04 -0400 (EDT) Date: Mon, 06 Jun 2005 14:51:06 -0400 From: Sathya Narayanan Subject: Re: [DNA] Route vs Advertise In-reply-to: <032801c568b0$1adad910$5e6015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Erik Nordmark , greg.daley@eng.monash.edu.au, Dna Message-id: <42A49B1A.8080005@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-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:15 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <429F4329.1040807@Research.Panasonic.COM> <42A096E7.9090608@sun.com> <032801c568b0$1adad910$5e6015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Jim - >Out implementation doesn't work that way. It just uses the prefixes in the >certificate to check whether the prefixes are certified or not, and drops >those that are uncertified if the host is configured to do so. It doesn't >uses the certification to determine what addresses to send to what router >since, as Erik says, that is not in the RFC 2461 conceptual model. > > In another email, you say ' That was the intent, a certified prefix means the router is authorized to route the prefix as advertised.' So, are you saying your implementation doesn't follow this 'intent'? Either way, are the 2461 conceptual model and this 'intent' in conflict with each other? Sathya > jak > >----- Original Message ----- >From: "Erik Nordmark" >To: >Cc: "Sathya Narayanan" ; "Dna" > >Sent: Friday, June 03, 2005 10:44 AM >Subject: Re: [DNA] Route vs Advertise > > > > >>Greg Daley wrote: >> >> >> >>>The issue in SEND is essentially that in some circumstances we want to >>>guarantee that a router is actually delegated authority to route for >>>that prefix. This is in the Certificate, not the PIO. >>> >>>I'd guess that the origin of the prefix doesn't matter (which RA the >>>PIO arrives in), although the certificate would indicate that only >>>those prefixes which are similarly authorized should be used as next >>>hops for packets with that source address. >>> >>> >>Is this something which has been implemented in the host SEND >>implementations? I can see it being quite hard since it fits neither the >>BSD-style code, nor the RFC 2461 conceptual model of a host. >> >> Erik >> >> >> > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 15:08:21 2005 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 PAA29619 for ; Mon, 6 Jun 2005 15:08:20 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP61TF59WY99KDAH@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 05:08:16 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1957180005; Tue, 07 Jun 2005 05:08:12 +1000 (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 A4DD93C004; Tue, 07 Jun 2005 05:08:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j56J7vX09973 for dna-list; Tue, 07 Jun 2005 05:07:57 +1000 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 j56J7vr09969 for ; Tue, 07 Jun 2005 05:07:57 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP61SVE2OU99KDAH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 05:07:46 +1000 Received: by localhost (Postfix, from userid 510) id 1DCF780002; Tue, 07 Jun 2005 05:07:46 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 218B43C004; Tue, 07 Jun 2005 05:07:43 +1000 (EST) Date: Mon, 06 Jun 2005 12:08:46 -0700 From: James Kempf Subject: Re: [DNA] Route vs Advertise Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , greg.daley@eng.monash.edu.au, Dna Message-id: <048a01c56acb$2f1e7e00$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <429F4329.1040807@Research.Panasonic.COM> <42A096E7.9090608@sun.com> <032801c568b0$1adad910$5e6015ac@dcml.docomolabsusa.com> <42A49B1A.8080005@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT > >Out implementation doesn't work that way. It just uses the prefixes in the > >certificate to check whether the prefixes are certified or not, and drops > >those that are uncertified if the host is configured to do so. It doesn't > >uses the certification to determine what addresses to send to what router > >since, as Erik says, that is not in the RFC 2461 conceptual model. > > > > > In another email, you say ' That was the intent, a certified prefix > means the router is authorized to route the prefix as advertised.' > > So, are you saying your implementation doesn't follow this 'intent'? > > Either way, are the 2461 conceptual model and this 'intent' in conflict > with each other? > No, the implementation checks the prefix against the cert (if the cert has an attribute with prefixes) when the RA is received. That's what I meant by "router is authorized to route the prefix as advertised". But then the prefix is put onto the merged prefix list if it passes, as RFC 2461 intends. The cert is not used to make any routing decisions. So I don't think the 2461 conceptual model is in conflict. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 15:25:37 2005 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 PAA01583 for ; Mon, 6 Jun 2005 15:25:35 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP62FP8CEY94PVWG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 05:25:31 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A5A6AB544; Tue, 07 Jun 2005 05:25:23 +1000 (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 1631B4FB08; Tue, 07 Jun 2005 05:25:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j56JP6210194 for dna-list; Tue, 07 Jun 2005 05:25:06 +1000 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 j56JP5r10190 for ; Tue, 07 Jun 2005 05:25:05 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP62F92DM299KCQ3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 05:25:02 +1000 Received: by localhost (Postfix, from userid 510) id E2249AB543; Tue, 07 Jun 2005 05:25:01 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0BC844FB0B; Tue, 07 Jun 2005 05:25:00 +1000 (EST) Date: Mon, 06 Jun 2005 12:26:03 -0700 From: James Kempf Subject: Re: [DNA] Route vs Advertise Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <049001c56acd$9984bbe0$5e6015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <429F4329.1040807@Research.Panasonic.COM> <42A0733E.2060403@Research.Panasonic.COM> <02b701c5689f$7f935d20$5e6015ac@dcml.docomolabsusa.com> <42A49905.1030406@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT > >Note that this does not imply that the router advertisement should be > >considered insecure, just the uncertified prefix. If the advertisement has a > >signature verifiable with the router's certified public key, then the router > >is trustworthy. > > > > > I understand. > > Do you think we need to say 'the prefixes in the DNAO SHOULD NOT be > verified against the prefixes listed in the certificate' in DNAv6? > AFIKT, the DNAO is really only useful in multicast RAs. If the RA is unicast, then the "yes" or "no" bit will be enough to tell the host whether or not it is on or off link, the host cannot use the DNAO to configure the address, and it need not use the prefixes in the DNAO to tell whether it is on or off link because the router does that directly through the "yes/no" bit. (BTW, why again is the DNAO required in unicast RAs if the host isn't on link?) So the host will make its on or off link decision based on the DNAO if it gets a multicast RA. As long as the RA is covered by a signature, the host knows that it wasn't modified in transit, that is, that it came from a router possessing the private key matching the certified public key. Now, it is possible that the router may be compromised and the attacker may try to convince the host that it is on or off link when it isn't by sending out a collection of bogus DNAO prefixes. If we want to exclude this possibility, then we should require the DNAO prefixes to be compared against those in the certificate as well. But since the host doesn't use these for address configuration or routing, there should be no possibility that the host is convinced to route through a bogus router (though if the router sending the RA is compromised, it can, of course, make trouble for packets that are routed through it even if the host selects a certified prefix). That is a somewhat longwinded way of saying that SHOULD NOT is probably OK. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 20:05:22 2005 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 UAA06315 for ; Mon, 6 Jun 2005 20:05:21 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP6C2D7OWY9AO5K9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 10:01:05 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 95FB7AB54A; Tue, 07 Jun 2005 10:00:57 +1000 (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 4E4D84FB03; Tue, 07 Jun 2005 10:00:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5700CO13059 for dna-list; Tue, 07 Jun 2005 10:00:12 +1000 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 j5700Ar13055 for ; Tue, 07 Jun 2005 10:00:10 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP6C12PVF499KCCI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 09:59:56 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EB7F4AB542; Tue, 07 Jun 2005 09:59:55 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id C534F4FB02; Tue, 07 Jun 2005 09:59:55 +1000 (EST) Date: Tue, 07 Jun 2005 09:59:55 +1000 From: Greg Daley Subject: Re: [DNA] Revised text for link-information Ethernet section for comment In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Romascanu, Dan (Dan)" Cc: dna@eng.monash.edu.au, Alper Yegin Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A4E37B.7030203@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Dan, Romascanu, Dan (Dan) wrote: > Greg, > > I am the chair of the Ethernet MIB WG and co-chair of the Bridge MIB WG. > > > I do have experience with link state information in Ethernet and IEEE > 802.1 bridges. I will read the proposed text and provide my individual > opinion. > > I would recommend that you submit this text for review to the Ethernet > MIB WG list (hubmib@ietf.org) and to the Bridge MIB WG list > (bridge-mib@ietf.org) so that more experts have a look at the text. I > can also forward this mail to these lists and ask for opinions to be fed > back into the dna list. Thanks for this. We know there's a need to cover these technologies in the document (which is why it has been attempted), but real expertise would certainly help. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 21:08:40 2005 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 VAA11658 for ; Mon, 6 Jun 2005 21:08:39 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP6EEYD82I99KH2T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 11:08:27 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1AFE5AB54B; Tue, 07 Jun 2005 11:08:23 +1000 (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 D0D914FB0B; Tue, 07 Jun 2005 11:08:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5717tr13829 for dna-list; Tue, 07 Jun 2005 11:07:55 +1000 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 j5717sr13825 for ; Tue, 07 Jun 2005 11:07:54 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP6EE18PQG979ENN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 11:07:39 +1000 Received: by localhost (Postfix, from userid 510) id D4AA6AB545; Tue, 07 Jun 2005 11:07:38 +1000 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by moe.its.monash.edu.au (Postfix) with ESMTP id 37F954FB05; Tue, 07 Jun 2005 11:07:36 +1000 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j570Zb006255; Mon, 06 Jun 2005 17:35:37 -0700 Received: from mvdhcp141133.americas.nokia.com (172.18.141.133, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdE58ECP; Mon, 06 Jun 2005 17:35:35 -0700 (PDT) Date: Mon, 06 Jun 2005 18:07:22 -0700 From: Vijay Devarapalli Subject: Re: [DNA] DNAO format revision? In-reply-to: <42913E16.4020600@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, Erik Nordmark Message-id: <42A4F34A.1040504@iprg.nokia.com> 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.2 (Windows/20050317) X-mProtect: <200506070035> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42913E16.4020600@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT variant 1. prefixes have always been 128 bit fields, atleast, in whatever IETF IPv6 specs I have worked with. Vijay Greg Daley wrote: > Hi DNA, > > I've been talking to Erik and most of my questions regarding > the DNA proposal have been answered. > > What I'd like to do now is to ask questions about message > formats and text, in a way which reinforces the hard work > undertaken by the DT. > > > Here's Q number 1: > > Is there a DNA option format which we can agree upon which > preserves Prefix alignment on 8 octet boundaries? > > I guess alignment is desirable to allow consistency with > earlier specifications 2461, 3810, and potentially allow > word-size based operations on some hosts. > > At the moment, the option format contains a list of > sequential 17 octet records. > > With 2 prefixes, the current format is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Len 1 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > + + > | | > + Prefix 1 + > | | > + +-+-+-+-+-+-+-+-+ > | | Prefix Len 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 2 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (32bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > Erik has convinced me of the need to support 128 bit > prefixes in DNA, for future expansion, but it may be > possible to achieve this while preserving alignment. > > > One variant makes use of the ordering of prefixes and > their lengths but uses two separate lists (one for > the lengths and one for the prefixes. Pad is introduced > at the end of the list of prefix lengths, instead > of at the end of the option. > > I'll call this Variant #1: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Len 1 | Prefix Len 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (32bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 1 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 2 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > It's also possible to have differing storage for > prefixes, so long as it is 8 octet aligned: > > The differing legnths of prefix mean that a number of prefixes > indication is required a the front of the prefix length list, > to remove ambiguity (it's not inferred just by the option length). > > I'll call this variant 2: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | # prefixes | Prefix Len 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Len 2 | Padding (24 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 1 (128 bits) + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Prefix 2 (64bits) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Variant 1 (along with the current option format) has > the advantage that records are constant length, and that > the prefix lengths don't have to be read in order to > locate any particular prefix. > > Variant 2 has the advantage that if the prefix length is > less than or equal to 64 (today's common case), the > storage used is only 8 bytes. A host would have to read > the list of prefix lengths in order to parse the prefixes though. > > Does anyone have an opinion as to whether a change to the > DNA option would be good or not? > > Please respond indicating if you like any of the > existing proposals (Current, Variant 1 or Variant 2), > or prefer something different. > > Greg > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 6 22:43:50 2005 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 WAA16979 for ; Mon, 6 Jun 2005 22:43:49 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP6HPPRW8Y9AO72J@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 12:43:36 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6C436AB543; Tue, 07 Jun 2005 12:43:18 +1000 (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 A0B824FB09; Tue, 07 Jun 2005 12:43:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j572go814864 for dna-list; Tue, 07 Jun 2005 12:42:50 +1000 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 j572gmr14860 for ; Tue, 07 Jun 2005 12:42:48 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP6HOTUHQO979FGC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 12:42:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 450A080004; Tue, 07 Jun 2005 12:42:38 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0155C3C007; Tue, 07 Jun 2005 12:42:38 +1000 (EST) Date: Tue, 07 Jun 2005 12:42:32 +1000 From: Greg Daley Subject: Re: [DNA] Revised text for link-information Ethernet section for comment In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Romascanu, Dan (Dan)" Cc: dna@eng.monash.edu.au, Alper Yegin , dbharrington@comcast.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A50998.6020502@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Dan, Thanks for this. Romascanu, Dan (Dan) wrote: > Please see comments to this section below. As I said in my previous > mail, it would be good to run this text with the Ethernet Interfaces MIB > and Bridge MIB lists. I've just subscribed to the lists, so I'll send the text to them, with suggested amendments marked. Below I've ACK'ed or asked questions about your comments. Sorry about the length of the message, but I've tried to keep sufficient context to allow discussion of alternate variants of text. Any further feedback you can provide would be appreciated. Greg > The co-chair of the Bridge MIB is also copied. > > Regards, > > Dan > > > >>-----Original Message----- >>From: owner-dna@ecselists.eng.monash.edu.au >>[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley >>Sent: Monday, June 06, 2005 10:06 AM >>To: dna@eng.monash.edu.au; Alper Yegin >>Subject: [DNA] Revised text for link-information Ethernet >>section for comment >> >>Dear Alper and WG, >> >>Here is an update of the text provided before last IETF for >>Ethernet in the link-information document. >> >>I'm not sure how useful the recommendations are to people, >>and apparently there was some difficulty even amongst DNA >>illuminati in understanding what I was getting at in the last version. >> >>So if you have any opinions or experience, please comment >>on-list, in order that forward progress can be made. >> >>Greg >> >> >>Text follows, potentially to be inserted as a section in the >>draft-ietf-dna-link-information. >> >>------------------------------------------------- >> >>Ethernet is the most commonly deployed Local Area Network >>technology in use today. >>As deployed today, it is specified by both a physical >>layer/medium access control (MAC) layer specification >>[802.3], and a bridging specification used for connecting >>different ethernet LAN segments together [802.1d]. > > > No - this is not accurate. Ethernet is only IEEE 802.3 technology. > Bridging technology as defined by IEEE 802.1D and other standards in the > 802.1 family can run with different MAC technologies, Ethernet included, > but is not Ethernet. I think Tom Petch has a description which could supply replacement text. I'll reply to that one separately. [cut] >>Such indications do not definitively ensure that packets will >>be able to be received through the switching infrastructure >>which composes a broadcast domain, though. Such operations >>are governed by bridging. > > > 'The term switching infrastructure' has no firm definition in standards. > Beyond this, 'switches' can be deplotyed beyond one single broadcast > domain. You probably would like to use 'bridging domain' instead. Thanks. That sounds appropriate. > >>Subsection: 802.1d Bridging and its effects on link indications >>-------------------------------------------------------------- > > > The correct spelling is (IEEE) 802.1D Thanks. I'll adopt the proper convention with document names. >>Ethernet networks are commonly bridged. >>Bridging is a mechanism which provides loopless paths across >>a series of link-segments. > > > 'Link-segments' is again fuzzy from a standard terminology perspective. > Maybe 'Briding is a mechanisms which provides loopless paths across LANs > interconnected by IEEE 802.1D bridges' That's good. Thanks. [cut] >>The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit >>(BPDU) frames in order to pass information about which >>switches are connected to others. > > > Better use 'bridges' rather than 'switches'. OK. >>By default, the spanning tree protocol does not know whether >>a particular newly connected piece of ethernet will cause a >>bridge loop. > > > Just 'loop'. OK. > >>Therefore it typically blocks all traffic from a port until >>spanning tree operations can determine if a loop exists. >> > > > Better - 'therefore it will block all traffic from and to a newly > connected ports with the exception of the STP BPDUs. The STP will > determine is the port can be connected to the network in a loop-free > environment'. I have a question. Doesn't it allow transmission of other packets which are LAN only (non-bridged)? I was trying to allow for 802.1AB LLDP packet arrival. Perhaps: "...therefore it will block all traffic from and to a newly connected ports with the exception of some unbridged management frames. The STP will determine if the port can be connected to the network in a loop-free environment." >>For these technologies, even though the link-layer appears >>available, no forwarding will occur until the network is >>satisfied that the connected is not another bridge or repeater port. > > > Better '... Until it is determined that the port can be connected to the > network in a loop-free environment'. Thanks. [cut] >>Upon learning that an adjacent port is running STP or RSTP, >>the host may send a Link-Up indication with a 'forwarding available' >>parameter upon expiry of calculated delays to indicate that >>general packet transfer is available across the LAN. > > > > No need to do this IMO. For its own availability a host knows when a > local port is transiting into forwarding state. See IEEE 802.1D-1998: > clause 8.5.5.2 and the dot1dStpPortState in the Bridge MIB (latest > version > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bridge-brid > gemib-smiv2-10.txt to be published as a proposed standard any time now). I guess that what I've been mostly focussed on is the action and reasoning of an end-host connecting to an ethernet-LAN when the host doesn't actually run STP itself. I'd agree that if the host is actually capable of bridging these rules would apply. If the host isn't STP capable (for example by not being a bridge) it won't know what its STP port state is. It does need to know if the frames will be dropped by an adjacent bridge. Would it be useful to state some of these assumptions at the top of the subsection? >>If no bridge configuration messages are received within the >>default Bridge_Max_Age interval (20s), then it is unlikely >>that the peer device is a bridge, since at least two BPDU >>hello messages have been lost. >>Upon this timeout, a host may (re)-send a link-layer >>indication showing that packets sent within the prior >>interval were likely to have traversed the forwarding path. >> >>If a BPDU is received, and the peer is running the original >>Spanning Tree Protocol, then host cannot successfully send >>packets until at >>least the peer's ForwardDelay timer has expired twice. This timeout >>defaults to 30 seconds (2 * 15 seconds) [802.1d]. After this >>time, the host can send a link-layer up indication showing >>that the previous interval after the PMA_LINK.indicate(OK) >>event was one of loss. >> >>If the switch is identified as performing Rapid Spanning Tree >>Protocol (RSTP), it instead waits Bridge_Max_Age after packet >>reception (advertised in the BPDU's Max Age field), before forwarding. >>For ports which are known to be point-to-point through >>autonegotiation, this delay is abbreviated to 3 seconds after >>autonegotiation completes [802.1d]. >>After either of these delays, a link-layer indication updating the >>PMA_LINK.indicate(OK) can show that the interval between >>indications was a lossy interval. > > > What is the bridge port is disabled by a management command? See IEEE > 802.1D-1998: clause 8.5.5.2, and the dot1dStpPortEnable object in the > Bridge MIB. > I guess that's a good point. The MAC on either device is actually enabled, but it's not possible to tell except for the fact that no packets are forwarded... How about?: (replacing the first quoted paragraph above, with three short paras) "If no bridge configuration messages are received within the default Bridge_Max_Age interval (20s), then it is likely that the peer's port is Disabled for bridging (S8.4.5), or the device is not a bridge, since at least two BPDU hello messages have been lost. It is not easy for a non-STP host to distinguish between Disabled ports and non-bridge ports with no IP nodes on them, as Disabled ports will have no traffic on them, and incur 100% sender loss. Upon this Bridge_Max_Age timeout, a host may (re)-send a link-layer indication showing that packets sent within the prior interval were likely to have traversed the forwarding path (unless the port is disabled)." [cut] >> >>The LLDP message may a System Capabilities TLV, which >>describes the MAC and IP layer functions which a device is >>currently using. >>Where a host receives the Systems Capabilities TLV which >>indicate that no Bridging or Repeating is occurring on the >>link-layer peer, then no delays for STP calculation will be >>applied to packets sent from this host. This would allow an >>authoritative link-layer indication to be sent to >>upper-layers about the availability of packet transfer. > > > This does not look right. The IEEE 802.1AB system capabilities reflects > only what capabilities are enabled on the remote host (see Section > 9.5.8.1 in the IEEE 802.1AB specification). The fact that a bridge for > example is connected at the other end does not mean that the port of the > bridge is enabled, or that spanning tree allows data packet transfer. You're right. If the local host is not STP enabled (as assumed before), and neither is the other port (at the other end advertises that it isn't a switch or repeater) then I guess it can be inferred that STP won't be available on the other end. If this isn't a valid assumption, we may have to revisit this. The disabled port issue would be the same as no LLDP, but the fact that the link-layer device states it is not a bridge, means the issue of whether packets can get through is not determinable through the link-layer. I'd suggest replacing the paragraph you were indicating with the one below: "The LLDP message may a System Capabilities TLV, which describes the MAC and IP layer functions which a device is currently using. Where a host receives the Systems Capabilities TLV which indicate that no Bridging or Repeating is occurring on the link-layer peer, then no delays for STP calculation will be applied to packets sent from this host, if does not perform STP itself. This would allow the host's link-layer to indicate that to its knowledge the link is available for packet transfer." Is this text better?: Below I'd also add the references to 802.1D discussed in the previous section: > >>Additionally, if a host receives a Systems Capabilities TLV >>which indicates that the peer is a switch or repeater, the >>host's advertisement that it is an (end-host) Station-Only, >>may tell the peer switch not to run STP, and immediately >>allow forwarding. >>Proprietary extensions may also indicate that data forwarding >>is already available on such a port. Discussions of such >>optimizations is out-of-scope for this document. Here is some added text which may clarify fallback to 802.1D assumptions: "Where the LLDP indicates that a peer is a switch or a repeater, senders of link-layer indications need to assume that the peer is dropping frames on the newly connected link in conformance with STP[802.1D]. It should therefore adopt the delays as stated in (Subsection: 802.1D Bridging...) above." >>Due to the protocol's newness and lack of deployment, it is >>unclear how this protocol will eventually affect DNA in IPv4 >>or IPv6 networks. >> >> >>Summary >>------- >> >>Link-Layer indications in Ethernet-like networks are >>complicated by additional unadvertised delays due to Spanning >>Tree calculations. >>This may cause re-indication or retraction of indications >>previously sent to upper layer protocols. >> >> >>Greg >> > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 7 01:41:36 2005 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 BAA26447 for ; Tue, 7 Jun 2005 01:41:31 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP6NWU7AMM94PSM4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 15:41:15 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 90D0780007; Tue, 07 Jun 2005 15:40:53 +1000 (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 446943C003; Tue, 07 Jun 2005 15:40:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j575eGe16787 for dna-list; Tue, 07 Jun 2005 15:40:16 +1000 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 j575eFr16783 for ; Tue, 07 Jun 2005 15:40:15 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP6NVQMKLI99K4S6@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 15:40:00 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 81B67AB545; Tue, 07 Jun 2005 15:40:00 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5E4B54FB0A; Tue, 07 Jun 2005 15:40:00 +1000 (EST) Date: Tue, 07 Jun 2005 15:39:55 +1000 From: Greg Daley Subject: Re: [DNA] Revised text for link-information Ethernet section for comment In-reply-to: <04e001c56aa9$87ae6de0$0601a8c0@pc6> Sender: owner-dna@ecselists.eng.monash.edu.au To: Tom Petch Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A5332B.2070606@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <04e001c56aa9$87ae6de0$0601a8c0@pc6> Content-Transfer-Encoding: 7BIT Hi, I've tried to address some of your concerns below. Please tell me if it's still off-track. Tom Petch wrote: > I agree with Dan and would add: > > Properly the technology is IEEE 802.3 CSMA/CD (and even that leaves out quite a > lot of the > title) and I would like you to introduce it as such, adding something like > 'commonly referred to as Ethernet' > > If you are going to use Ethernet (as opposed to say CSMA/CD or IEEE 802.3) in > the rest of the document, then you should add a sentence to that effect (the > term Ethernet scarcely appears in IEEE 802.3). That sounds fair enough. How about the following introduction: "Section title: IEEE 802.3 CSMA/CD ------------------------------------ IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most commonly deployed Local Area Network technology in use today. As deployed today, it is specified by both a physical layer/medium access control (MAC) layer specification[802.3]. In order to provide connection of different LANs together into a larger network, 802.3 LANs are often bridged together[802.1d]. In this section, the terms 802.3 and Ethernet are used interchangeably. This section describes some issues in providing link-layer indications on Ethernet networks, and shows how bridging affects these indications." Is this more accurate? > > It is wrong to say that all media have Link Integrity Tests eg 10BASE5 (yes, it > is still in use). OK... Perhaps it is worth introducing the concept more explicitly. "In order to determine whether the physical medium is ready for frame transfer, IEEE 802.3 Ethernet specifies its own link monitoring mechanism, which is defined for some, but not all classes of media. Where available, this Link Integrity Test operation is used to identify when packets are able to be received on an Ethernet segment. It is applicable to both wired and optical physical layers, although details vary between technologies (link pulses in twisted pair copper, light levels in fibre)." Is that a reasonable description of the variation between media? > The default I see is BPDU Hello every two seconds so within the default 20s, > more than two will have been lost. But this paragraph and the following one > confuse me with references to peer device. This is broadcast, a degenerate case > being only two devices, and if there is a bridge anywhere in the topology, then > I expect to see BPDU every 2s. Spanning Tree will not work without them so not > seeing them says either no bridges or Spanning Tree has been disabled (does > happen, used to be common with slow - eg WAN - links) I guess the peer LAN connected device could be either a bridge, an end-station (router or host) or a repeater (in which case any other device becomes visible on the LAN). I there are bridges anywhere on the LAN, then you would expect to see Hellos (although, topologies without bridges are valid too). In section 8.10.2 of 802.1D 1998, (Table 8-3, the Hello timer has a range of 1.0-10.0 seconds). Also, there's an inequality: Bridge_Max_Age >= 2 x (Bridge_Hello_Time + 1.0 seconds) So I assumed that the inference of at least 2 messages were lost could be applied. Should I be more explicit about the maximum timeout? I'm wondering if explicit statements about what a 'peer' may be, and which devices are STP participants would help. How about this?: "... For these technologies, even though the link-layer appears available, no forwarding will occur until it is determined that the port can be connected to the network in a loop-free environment. (new text) For host which are providing indications to upper layer protocols, even if the host itself does not implement bridging or STP, packet delivery across the network can be affected by their directly adjacent LAN peer which may be a bridge, or if this is a repeater, by the presence of STP bridges upon that LAN. Where the host is not running STP itself, (end new text) No explicit indication that forwarding has begun is sent from a switch to its peer devices. Therefore, a host may not know when STP operations have completed, and when it is safe to inform upper layers to transmit packets. ..." Does this provide sufficient context to help disambiguate the role of each device, and whether it is running STP? Thanks for your work on this. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 7 01:51:12 2005 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 BAA27020 for ; Tue, 7 Jun 2005 01:51:08 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP6O9ODW8099KJ0W@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 15:50:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C40D180004; Tue, 07 Jun 2005 15:50:27 +1000 (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 7183C3C00A; Tue, 07 Jun 2005 15:50:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j575oLC16929 for dna-list; Tue, 07 Jun 2005 15:50:21 +1000 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 j575oKr16925 for ; Tue, 07 Jun 2005 15:50:21 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP6O9B4UHW94PAH1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 15:50:11 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 00C2EAB543 for ; Tue, 07 Jun 2005 15:50:10 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id D4D334FB02 for ; Tue, 07 Jun 2005 15:50:09 +1000 (EST) Date: Tue, 07 Jun 2005 15:50:04 +1000 From: Greg Daley Subject: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A5358C.2090101@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi DNA WG, After Tom and Dan's reviews of the 802.3 section for the link information draft, here's a summary of the text proposals: These have not been confirmed on-list, but are placed here for reference in order that the potential changes can be all seen together. Greg ------------------------------------------------------- Section title: IEEE 802.3 CSMA/CD ------------------------------------ (begin revised) IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most commonly deployed Local Area Network technology in use today. As deployed today, it is specified by both a physical layer/medium access control (MAC) layer specification[802.3]. In order to provide connection of different LANs together into a larger network, 802.3 LANs are often bridged together[802.1d]. In this section, the terms 802.3 and Ethernet are used interchangeably. This section describes some issues in providing link-layer indications on Ethernet networks, and shows how bridging affects these indications. (end revised) In Ethernet networks, hosts are connected by wires or by optic fibre to a switch (bridge), a bus (e.g. co-axial cable), a repeater (hub), or directly to another ethernet device. Interfaces are symmetric, in that while many different physical laters may be present, medium access control is uniform for all devices. (begin revised) In order to determine whether the physical medium is ready for frame transfer, IEEE 802.3 Ethernet specifies its own link monitoring mechanism, which is defined for some, but not all classes of media. Where available, this Link Integrity Test operation is used to identify when packets are able to be received on an Ethernet segment. It is applicable to both wired and optical physical layers, although details vary between technologies (link pulses in twisted pair copper, light levels in fibre). (end revised) Subsection: Link Integrity Tests in 802.3 networks. --------------------------------------------------- The status of the link as determined by the Link Integrity Test is stored in the variable 'link_status'. Changes to the value of link_status (for example due to Link Integrity Test failure) will generate link indications if the technology dependent interface is implemented on an ethernet device [802.3]. The link_status has possible values of FAIL, READY and OK. When an interface is in FAIL state, Link Integrity Tests have failed. Where status is READY, the link segment has passed integrity tests, but autonegotiation has not completed. OK state indicates that the medium is able to send and receive packets. Upon transition to a particular state the Physical Medium Attachment subsystems generates a PMA_LINK.indicate(link_status). Indications of OK state may be used as Link-Up indications for DNA. PMA_LINK.indicate(FAIL) may be used as a Link-Down indication reliably by DNA[802.3]. (begin revised) Such indications do not definitively ensure that packets will be able to be received through the bridge domain, though. Such operations are governed by bridging. (end revised) Subsection: IEEE 802.1D Bridging and its effects on link indications -------------------------------------------------------------- (begin revised) Ethernet networks are commonly bridged. Bridging is a mechanisms which provides loopless paths across LANs interconnected by IEEE 802.1D bridges. Due to its necessity in preventing bridge loops, bridging has become synonymous with the spanning tree protocol. The spanning tree protocol and its variants provide loopless forwarding between ethernet-like bridges within a bridging domain. The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit (BPDU) frames in order to pass information about which bridges are connected to others. By default, the spanning tree protocol does not know whether a particular newly connected piece of ethernet will cause a loop. Therefore it will block all traffic from and to a newly connected ports with the exception of some unbridged management frames. The STP will determine if the port can be connected to the network in a loop-free environment. For these technologies, even though the link-layer appears available, no forwarding will occur until it is determined that the port can be connected to the network in a loop-free environment. (end revised) (start added context) For host which are providing indications to upper layer protocols, even if the host itself does not implement bridging or STP, packet delivery across the network can be affected by their directly adjacent LAN peer which may be a bridge, or if this is a repeater, by the presence of STP bridges upon that LAN. (end added context) (start revised) Where the host is not running STP itself, no explicit indication that forwarding has begun is sent from a switch to its peer devices. Therefore, a host may not know when STP operations have completed, and when it is safe to inform upper layers to transmit packets. (end revised) As described in (Subsection on 802.1AB LLDP) explicit knowledge may be available through the new Link-Layer Discovery Protocol as to whether frame forwarding operation is immediately available. Where it is not known that forwarding operations are available, a host needs to assume that STP is being performed, and may indicate full connectivity only based on reception of BPDUs or timeouts. Upon learning that an adjacent port is running STP or RSTP, the host may send a Link-Up indication with a 'forwarding available' parameter upon expiry of calculated delays to indicate that general packet transfer is available across the LAN. (begin revised) If no bridge configuration messages are received within the default Bridge_Max_Age interval (20s), then it is likely that the peer's port is Disabled for bridging (S8.4.5 of [802.1D]), or the device is not a bridge, since at least two BPDU hello messages have been lost. It is not easy for a non-STP host to distinguish between Disabled ports and non-bridge ports with no IP nodes on them, as Disabled ports will have no traffic on them, and incur 100% sender loss. Upon this Bridge_Max_Age timeout, a host may (re)-send a link-layer indication showing that packets sent within the prior interval were likely to have traversed the forwarding path (unless the port is disabled). (end revised) If a BPDU is received, and the peer is running the original Spanning Tree Protocol, then host cannot successfully send packets until at least the peer's ForwardDelay timer has expired twice. This timeout defaults to 30 seconds (2 * 15 seconds) [802.1d]. After this time, the host can send a link-layer up indication showing that the previous interval after the PMA_LINK.indicate(OK) event was one of loss. If the switch is identified as performing Rapid Spanning Tree Protocol (RSTP), it instead waits Bridge_Max_Age after packet reception (advertised in the BPDU's Max Age field), before forwarding. For ports which are known to be point-to-point through autonegotiation, this delay is abbreviated to 3 seconds after autonegotiation completes [802.1d]. After either of these delays, a link-layer indication updating the PMA_LINK.indicate(OK) can show that the interval between indications was a lossy interval. Subsection: 802.1AB Link-Layer Discovery Protocol. ------------------------------------------------- The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) provides information to directly connected devices about its MAC peer[802.1AB]. LLDP sends information periodically, and at link status change time to indicate the configuration parameters of the device. Devices may either send or receive these messages, or both. (begin revised) The LLDP message may a System Capabilities TLV, which describes the MAC and IP layer functions which a device is currently using. Where a host receives the Systems Capabilities TLV which indicate that no Bridging or Repeating is occurring on the link-layer peer, then no delays for STP calculation will be applied to packets sent from this host, if does not perform STP itself. This would allow the host's link-layer to indicate that to its knowledge the link is available for packet transfer. (end revised) Additionally, if a host receives a Systems Capabilities TLV which indicates that the peer is a switch or repeater, the host's advertisement that it is an (end-host) Station-Only, may tell the peer switch not to run STP, and immediately allow forwarding. Proprietary extensions may also indicate that data forwarding is already available on such a port. Discussions of such optimizations is out-of-scope for this document. Due to the protocol's newness and lack of deployment, it is unclear how this protocol will eventually affect DNA in IPv4 or IPv6 networks. Summary ------- Link-Layer indications in Ethernet-like networks are complicated by additional unadvertised delays due to Spanning Tree calculations. This may cause re-indication or retraction of indications previously sent to upper layer protocols. From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 7 06:04:08 2005 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 GAA06196 for ; Tue, 7 Jun 2005 06:04:07 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP6X3BIYOC94PQ8T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Jun 2005 20:03:54 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 98075AB542; Tue, 07 Jun 2005 20:03:25 +1000 (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 55BEA4FB0C; Tue, 07 Jun 2005 20:03:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j57A1tg19596 for dna-list; Tue, 07 Jun 2005 20:01:55 +1000 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 j57A1sr19592 for ; Tue, 07 Jun 2005 20:01:54 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP6X16JL5O9AO7V1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Jun 2005 20:01:42 +1000 Received: by localhost (Postfix, from userid 510) id 57EB280002; Tue, 07 Jun 2005 20:01:42 +1000 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) (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 CC83E3C005; Tue, 07 Jun 2005 20:01:40 +1000 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j579xAdd010856; Tue, 07 Jun 2005 05:59:10 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j579x8dd010821; Tue, 07 Jun 2005 05:59:09 -0400 (EDT) Date: Tue, 07 Jun 2005 13:01:33 +0300 From: "Romascanu, Dan (Dan)" Subject: RE: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section Thread-Index: AcVrJQTNYqku0t96R8uXZHl85MWtYwAAnZxw content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg, One comment: > As described in (Subsection on 802.1AB LLDP) explicit > knowledge may be available through the new Link-Layer > Discovery Protocol as to whether frame forwarding operation > is immediately available. > This is not accurate. LLDP may tell you that on the other end of the link there is a bridge or repeater, but not whether frame forwarding is immediately available. I suggest to wipe out this paragraph. Could you send me a 'clean' version, without editorial brackets to forward to the Ethernet and Bridge MIB lists for further scrutiny? Dan > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley > Sent: Tuesday, June 07, 2005 8:50 AM > To: dna@eng.monash.edu.au > Subject: [DNA] (For reference) text with unconfirmed > modifications to L2 indications Ethernet/802.3 section > > Hi DNA WG, > > After Tom and Dan's reviews of the 802.3 section for the link > information draft, here's a summary of the text proposals: > > These have not been confirmed on-list, but are placed here > for reference in order that the potential changes can be all > seen together. > > Greg > > > ------------------------------------------------------- > > > Section title: IEEE 802.3 CSMA/CD > ------------------------------------ > > (begin revised) > IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the > most commonly deployed Local Area Network technology in use today. > As deployed today, it is specified by both a physical layer/medium > access control (MAC) layer specification[802.3]. > In order to provide connection of different LANs together into > a larger network, 802.3 LANs are often bridged together[802.1d]. > > In this section, the terms 802.3 and Ethernet are used > interchangeably. This section describes some issues in providing > link-layer indications on Ethernet networks, and shows how bridging > affects these indications. > (end revised) > > In Ethernet networks, hosts are connected by wires or by > optic fibre to a switch (bridge), a bus (e.g. co-axial > cable), a repeater (hub), or directly to another ethernet > device. Interfaces are symmetric, in that while many > different physical laters may be present, medium access > control is uniform for all devices. > > (begin revised) > In order to determine whether the physical medium is ready for > frame transfer, IEEE 802.3 Ethernet specifies its own link > monitoring mechanism, which is defined for some, but not all > classes of media. > Where available, this Link Integrity Test operation is used > to identify when packets are able to be received on an > Ethernet segment. It is applicable to both wired and optical > physical layers, although details vary between technologies > (link pulses in twisted pair copper, light levels in fibre). > (end revised) > > > Subsection: Link Integrity Tests in 802.3 networks. > --------------------------------------------------- > > The status of the link as determined by the Link Integrity > Test is stored in the variable 'link_status'. Changes to the > value of link_status (for example due to Link Integrity Test > failure) will generate link indications if the technology > dependent interface is implemented on an ethernet device [802.3]. > > The link_status has possible values of FAIL, READY and OK. > When an interface is in FAIL state, Link Integrity Tests have failed. > Where status is READY, the link segment has passed integrity > tests, but autonegotiation has not completed. OK state > indicates that the medium is able to send and receive packets. > > Upon transition to a particular state the Physical Medium > Attachment subsystems generates a PMA_LINK.indicate(link_status). > Indications of OK state may be used as Link-Up indications for DNA. > PMA_LINK.indicate(FAIL) may be used as a Link-Down indication > reliably by DNA[802.3]. > > (begin revised) > Such indications do not definitively ensure that packets will > be able to be received through the bridge domain, though. Such > operations are governed by bridging. > (end revised) > > > Subsection: IEEE 802.1D Bridging and its effects on link indications > -------------------------------------------------------------- > > (begin revised) > Ethernet networks are commonly bridged. Bridging is a mechanisms > which provides loopless paths across LANs interconnected by > IEEE 802.1D bridges. > > > Due to its necessity in preventing bridge loops, bridging has > become synonymous with the spanning tree protocol. > The spanning tree protocol and its variants provide loopless > forwarding between ethernet-like bridges within a bridging domain. > > The Spanning Tree Protocol (STP) exchanges Bridge Protocol > Data Unit > (BPDU) frames in order to pass information about which > bridges are connected to others. > > By default, the spanning tree protocol does not know whether > a particular newly connected piece of ethernet will cause a > loop. > > Therefore it will block all traffic from and to a newly connected > ports with the exception of some unbridged management frames. > The STP will determine if the port can be connected to the > network in > a loop-free environment. > > For these technologies, even though the link-layer appears > available, no forwarding will occur until it is determined that > the port can be connected to the network in a loop-free > environment. > (end revised) > > (start added context) > For host which are providing indications to upper layer protocols, > even if the host itself does not implement bridging or STP, > packet delivery across the network can be affected by their > directly adjacent LAN peer which may be a bridge, or if this is > a repeater, by the presence of STP bridges upon that LAN. > (end added context) > > (start revised) > Where the host is not running STP itself, no explicit indication > that forwarding has begun is sent from a switch to its > peer devices. > Therefore, a host may not know when STP operations have completed, > and when it is safe to inform upper layers to transmit packets. > (end revised) > > As described in (Subsection on 802.1AB LLDP) explicit > knowledge may be available through the new Link-Layer > Discovery Protocol as to whether frame forwarding operation > is immediately available. > > Where it is not known that forwarding operations are > available, a host needs to assume that STP is being > performed, and may indicate full connectivity only based on > reception of BPDUs or timeouts. > > Upon learning that an adjacent port is running STP or RSTP, > the host may send a Link-Up indication with a 'forwarding available' > parameter upon expiry of calculated delays to indicate that > general packet transfer is available across the LAN. > > (begin revised) > If no bridge configuration messages are received within the > default Bridge_Max_Age interval (20s), then it is likely that > the peer's port is Disabled for bridging (S8.4.5 of [802.1D]), > or the device is not a bridge, since at least two BPDU hello > messages have been lost. > > It is not easy for a non-STP host to distinguish between > Disabled ports and non-bridge ports with no IP nodes on them, > as Disabled ports will have no traffic on them, and incur > 100% sender loss. > > Upon this Bridge_Max_Age timeout, a host may (re)-send a > link-layer indication showing that packets sent within the prior > interval were likely to have traversed the forwarding path > (unless the port is disabled). > (end revised) > > If a BPDU is received, and the peer is running the original > Spanning Tree Protocol, then host cannot successfully send > packets until at least the peer's ForwardDelay timer has expired > twice. This timeout defaults to 30 seconds (2 * 15 seconds) > [802.1d]. After this time, the host can send a link-layer up > indication showing that the previous interval after the > PMA_LINK.indicate(OK) event was one of loss. > > If the switch is identified as performing Rapid Spanning Tree > Protocol (RSTP), it instead waits Bridge_Max_Age after packet > reception (advertised in the BPDU's Max Age field), before forwarding. > For ports which are known to be point-to-point through > autonegotiation, this delay is abbreviated to 3 seconds after > autonegotiation completes [802.1d]. > After either of these delays, a link-layer indication updating the > PMA_LINK.indicate(OK) can show that the interval between > indications was a lossy interval. > > > Subsection: 802.1AB Link-Layer Discovery Protocol. > ------------------------------------------------- > > The recently defined 802.1AB Link-Layer Discovery Protocol > (LLDP) provides information to directly connected devices > about its MAC peer[802.1AB]. > > LLDP sends information periodically, and at link status > change time to indicate the configuration parameters of the device. > Devices may either send or receive these messages, or both. > > (begin revised) > The LLDP message may a System Capabilities TLV, which > describes the MAC and IP layer functions which a device is > currently using. Where a host receives the > Systems Capabilities TLV which indicate that no Bridging or > Repeating is occurring on the link-layer peer, then no delays > for STP calculation will be applied to packets sent from this > host, if does not perform STP itself. This would allow the > host's link-layer to indicate that to its knowledge the link > is available for packet transfer. > (end revised) > > Additionally, if a host receives a Systems Capabilities TLV > which indicates that the peer is a switch or repeater, the > host's advertisement that it is an (end-host) Station-Only, > may tell the peer switch not to run STP, and immediately > allow forwarding. > > Proprietary extensions may also indicate that data forwarding > is already available on such a port. Discussions of such > optimizations is out-of-scope for this document. > > Due to the protocol's newness and lack of deployment, it is > unclear how this protocol will eventually affect DNA in IPv4 > or IPv6 networks. > > > Summary > ------- > > Link-Layer indications in Ethernet-like networks are > complicated by additional unadvertised delays due to Spanning > Tree calculations. This may cause re-indication or > retraction of indications previously sent to upper layer protocols. > > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 7 15:47:53 2005 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 PAA26630 for ; Tue, 7 Jun 2005 15:47:51 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP7HHROY6Q99KEH8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Jun 2005 05:47:46 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B170AB542; Wed, 08 Jun 2005 05:47:44 +1000 (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 0CE1B4FB02; Wed, 08 Jun 2005 05:47:44 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j57Jkxq25931 for dna-list; Wed, 08 Jun 2005 05:46:59 +1000 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 j57Jkxr25925 for ; Wed, 08 Jun 2005 05:46:59 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP7HGP0KCS9AO99E@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Jun 2005 05:46:52 +1000 Received: by localhost (Postfix, from userid 510) id 7C380AB542; Wed, 08 Jun 2005 05:46:52 +1000 (EST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9C7614FB02; Wed, 08 Jun 2005 05:46:50 +1000 (EST) Received: from pc6 (1Cust221.tnt1.lnd4.gbr.da.uu.net [62.188.130.221]) by galaxy.systems.pipex.net (Postfix) with SMTP id 05922E0003E3; Tue, 07 Jun 2005 20:46:44 +0100 (BST) Date: Tue, 07 Jun 2005 20:43:57 +0200 From: Tom Petch Subject: Re: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Reply-to: Tom Petch Message-id: <024401c56b91$46a251c0$0601a8c0@pc6> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42A5358C.2090101@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Some more comments in line. I do find that my style is somewhat different to yours, so it may not be helpful to interpose my words directly between yours. Two semantic concerns, I have not encountered hosts (ie not bridge/switches) that listen to BDPU to find out what is happening but that may be just my ignorance; certainly technically feasible and sensible for DNA, but do boxes actually do it? You make several references to it. (By contrast, I do encounter boxes which listen to routing protocol traffic to find out what is happening at layer three). And this peer thingy; I don't get it (except in the case of two boxes directly connected by one piece of UTP or fibre). I don't see repeater or bridge as peer. Repeater is physically repeating, passive except in so far as it propagates collisions and participates in Link Integrity. Bridge is also (usually) transparent; you don't see it, apart from added delays, until it decides not to forward, for up to 50s, as part of a topology change (or unless you listen in to BPDU which, as I said, I only see bridges doing). I struggle to see it as peer in any meaningful sense. Tom Petch ----- Original Message ----- From: "Greg Daley" To: Sent: Tuesday, June 07, 2005 7:50 AM Subject: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section > ------------------------------------------------------- > Section title: IEEE 802.3 CSMA/CD > ------------------------------------ > > (begin revised) > IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the > most commonly deployed Local Area Network technology in use today. > As deployed today, it is specified by both a physical layer/medium > access control (MAC) layer specification[802.3]. > In order to provide connection of different LANs together into > a larger network, 802.3 LANs are often bridged together[802.1d]. > > In this section, the terms 802.3 and Ethernet are used > interchangeably. This section describes some issues in providing > link-layer indications on Ethernet networks, and shows how bridging > affects these indications. > (end revised) > > In Ethernet networks, hosts are connected by wires or by optic fibre > to a switch (bridge), a bus (e.g. co-axial cable), a repeater (hub), > or directly to another ethernet device. Interfaces are symmetric, > in that while many different physical laters may be present, medium > access control is uniform for all devices. > > (begin revised) > In order to determine whether the physical medium is ready for > frame transfer, IEEE 802.3 Ethernet specifies its own link > monitoring mechanism, which is defined for some, but not all > classes of media. > Where available, this Link Integrity Test operation is used > to identify when packets are able to be received on an > Ethernet segment. It is applicable to both wired and optical > physical layers, although details vary between technologies > (link pulses in twisted pair copper, light levels in fibre). > (end revised) > > > Subsection: Link Integrity Tests in 802.3 networks. > --------------------------------------------------- > > The status of the link as determined by the Link Integrity > Test is stored in the variable 'link_status'. Changes to the > value of link_status (for example due to Link Integrity Test > failure) will generate link indications if the technology > dependent interface is implemented on an ethernet device [802.3]. > > The link_status has possible values of FAIL, READY and OK. > When an interface is in FAIL state, Link Integrity Tests have failed. > Where status is READY, the link segment has passed integrity > tests, but autonegotiation has not completed. OK state > indicates that the medium is able to send and receive packets. > > Upon transition to a particular state the Physical Medium > Attachment subsystems generates a PMA_LINK.indicate(link_status). > Indications of OK state may be used as Link-Up indications for DNA. > PMA_LINK.indicate(FAIL) may be used as a Link-Down indication > reliably by DNA[802.3]. > > (begin revised) > Such indications do not definitively ensure that packets will > be able to be received through the bridge domain, though. Such > operations are governed by bridging. > (end revised) > > > Subsection: IEEE 802.1D Bridging and its effects on link indications > -------------------------------------------------------------- > (suggest this instead of the subsequent three paragraphs) Ethernet networks commonly consist of LANs joined together by transparent bridges (usually implemented as switches). Tranparent bridges require the active topology to be loop free. The Spanning Tree Protocol (STP) achieves this by the exchange of Bridge Protocol Data Unit (BPDU), as defined in [802.1D], which leads to, where required, the blocking of ports (ie not forwarding). > (begin revised) > Ethernet networks are commonly bridged. Bridging is a mechanisms > which provides loopless paths across LANs interconnected by > IEEE 802.1D bridges. > > Due to its necessity in preventing bridge loops, bridging has > become synonymous with the spanning tree protocol. > The spanning tree protocol and its variants provide loopless > forwarding between ethernet-like bridges within a bridging domain. > > The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit > (BPDU) frames in order to pass information about which > bridges are connected to others. > > By default, the spanning tree protocol does not know whether > a particular newly connected piece of ethernet will cause a > loop. > > Therefore it will block all traffic from and to a newly connected > ports with the exception of some unbridged management frames. > The STP will determine if the port can be connected to the network in > a loop-free environment. > > For these technologies, even though the link-layer appears > available, no forwarding will occur until it is determined that > the port can be connected to the network in a loop-free > environment. > (end revised) > > (start added context) > For host which are providing indications to upper layer protocols, > even if the host itself does not implement bridging or STP, > packet delivery across the network can be affected by their > directly adjacent LAN peer which may be a bridge, or if this is > a repeater, by the presence of STP bridges upon that LAN. > (end added context) (I've still got problems with peer - this could be coax, no LAN peer; and any bridge anywhere can block packet delivery on a temporary basis as you describe below; I would say 'Packet delivery across the network can be affected by the presence of bridges' and leave it at that) > > (start revised) > Where the host is not running STP itself, no explicit indication > that forwarding has begun is sent from a switch to its peer devices. > Therefore, a host may not know when STP operations have completed, > and when it is safe to inform upper layers to transmit packets. > (end revised) > > As described in (Subsection on 802.1AB LLDP) explicit > knowledge may be available through the new Link-Layer > Discovery Protocol as to whether frame forwarding operation > is immediately available. > > Where it is not known that forwarding operations are > available, a host needs to assume that STP is being > performed, and may indicate full connectivity only based on > reception of BPDUs or timeouts. > > Upon learning that an adjacent port is running STP or RSTP, > the host may send a Link-Up indication with a 'forwarding available' > parameter upon expiry of calculated delays to indicate that > general packet transfer is available across the LAN. > > (begin revised) > If no bridge configuration messages are received within the > default Bridge_Max_Age interval (20s), then it is likely that > the peer's port is Disabled for bridging (S8.4.5 of [802.1D]), > or the device is not a bridge, since at least two BPDU hello > messages have been lost. > (suggest) If no bridge configuration messages are received within the Bridge_Max_Age interval (default 20s), then it is likely that ... (but then the reference to peer still confuses me; no BPDU for me means no bridge in the topology or a failure) > the peer's port is Disabled for bridging (S8.4.5 of [802.1D]), > or the device is not a bridge, since at least two BPDU hello > messages have been lost > It is not easy for a non-STP host to distinguish between > Disabled ports and non-bridge ports with no IP nodes on them, > as Disabled ports will have no traffic on them, and incur > 100% sender loss. > > Upon this Bridge_Max_Age timeout, a host may (re)-send a > link-layer indication showing that packets sent within the prior > interval were likely to have traversed the forwarding path > (unless the port is disabled). > (end revised) > > If a BPDU is received, and the peer is running the original > Spanning Tree Protocol, then host cannot successfully send > packets until at least the peer's ForwardDelay timer has expired > twice. This timeout defaults to 30 seconds (2 * 15 seconds) > [802.1d]. After this time, the host can send a link-layer up > indication showing that the previous interval after the > PMA_LINK.indicate(OK) event was one of loss. > > If the switch is identified as performing Rapid Spanning Tree > Protocol (RSTP), it instead waits Bridge_Max_Age after packet > reception (advertised in the BPDU's Max Age field), before forwarding. > For ports which are known to be point-to-point through > autonegotiation, this delay is abbreviated to 3 seconds after > autonegotiation completes [802.1d]. > After either of these delays, a link-layer indication updating the > PMA_LINK.indicate(OK) can show that the interval between > indications was a lossy interval. > > > Subsection: 802.1AB Link-Layer Discovery Protocol. > ------------------------------------------------- > > The recently defined 802.1AB Link-Layer Discovery Protocol > (LLDP) provides information to directly connected devices > about its MAC peer[802.1AB]. > > LLDP sends information periodically, and at link status > change time to indicate the configuration parameters of the device. > Devices may either send or receive these messages, or both. > > (begin revised) > The LLDP message may a System Capabilities TLV, which > describes the MAC and IP layer functions which a device is > currently using. Where a host receives the > Systems Capabilities TLV which indicate that no Bridging or > Repeating is occurring on the link-layer peer, then no delays > for STP calculation will be applied to packets sent from this > host, if does not perform STP itself. This would allow the > host's link-layer to indicate that to its knowledge the link > is available for packet transfer. > (end revised) > > Additionally, if a host receives a Systems Capabilities TLV > which indicates that the peer is a switch or repeater, the > host's advertisement that it is an (end-host) Station-Only, > may tell the peer switch not to run STP, and immediately > allow forwarding. > > Proprietary extensions may also indicate that data forwarding > is already available on such a port. Discussions of such > optimizations is out-of-scope for this document. > > Due to the protocol's newness and lack of deployment, it is > unclear how this protocol will eventually affect DNA in IPv4 > or IPv6 networks. > > > Summary > ------- > > Link-Layer indications in Ethernet-like networks are > complicated by additional unadvertised delays due to Spanning > Tree calculations. This may cause re-indication or retraction > of indications previously sent to upper layer protocols. > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 7 18:54:31 2005 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 SAA22022 for ; Tue, 7 Jun 2005 18:54:30 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP7O1248ZQ99KC08@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Jun 2005 08:54:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 67F19AB543; Wed, 08 Jun 2005 08:54:17 +1000 (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 1F17C4FB07; Wed, 08 Jun 2005 08:54:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j57Mrdn27868 for dna-list; Wed, 08 Jun 2005 08:53:39 +1000 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 j57Mrbr27864 for ; Wed, 08 Jun 2005 08:53:37 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP7NYW8WX094Q5VD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Jun 2005 08:53:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AF82A80003; Wed, 08 Jun 2005 08:53:20 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 986AE3C006; Wed, 08 Jun 2005 08:53:20 +1000 (EST) Date: Wed, 08 Jun 2005 08:53:20 +1000 From: Greg Daley Subject: Re: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Romascanu, Dan (Dan)" Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A62560.1090309@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Dan, I'll take your suggestion. There's a little iteration to be done from Tom's guidance, but I'm agreeing with his text suggestions, so I'll send the text which has been merged. Greg Romascanu, Dan (Dan) wrote: > Greg, > > > One comment: > > >>As described in (Subsection on 802.1AB LLDP) explicit >>knowledge may be available through the new Link-Layer >>Discovery Protocol as to whether frame forwarding operation >>is immediately available. >> > > > This is not accurate. LLDP may tell you that on the other end of the > link there is a bridge or repeater, but not whether frame forwarding is > immediately available. I suggest to wipe out this paragraph. > > Could you send me a 'clean' version, without editorial brackets to > forward to the Ethernet and Bridge MIB lists for further scrutiny? > > Dan > > > > > > > >>-----Original Message----- >>From: owner-dna@ecselists.eng.monash.edu.au >>[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley >>Sent: Tuesday, June 07, 2005 8:50 AM >>To: dna@eng.monash.edu.au >>Subject: [DNA] (For reference) text with unconfirmed >>modifications to L2 indications Ethernet/802.3 section >> >>Hi DNA WG, >> >>After Tom and Dan's reviews of the 802.3 section for the link >>information draft, here's a summary of the text proposals: >> >>These have not been confirmed on-list, but are placed here >>for reference in order that the potential changes can be all >>seen together. >> >>Greg >> >> >>------------------------------------------------------- >> >> >>Section title: IEEE 802.3 CSMA/CD >>------------------------------------ >> >>(begin revised) >> IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the >> most commonly deployed Local Area Network technology in use today. >> As deployed today, it is specified by both a physical layer/medium >> access control (MAC) layer specification[802.3]. >> In order to provide connection of different LANs together into >> a larger network, 802.3 LANs are often bridged together[802.1d]. >> >> In this section, the terms 802.3 and Ethernet are used >> interchangeably. This section describes some issues in providing >> link-layer indications on Ethernet networks, and shows how bridging >> affects these indications. >>(end revised) >> >>In Ethernet networks, hosts are connected by wires or by >>optic fibre to a switch (bridge), a bus (e.g. co-axial >>cable), a repeater (hub), or directly to another ethernet >>device. Interfaces are symmetric, in that while many >>different physical laters may be present, medium access >>control is uniform for all devices. >> >>(begin revised) >> In order to determine whether the physical medium is ready for >> frame transfer, IEEE 802.3 Ethernet specifies its own link >> monitoring mechanism, which is defined for some, but not all >> classes of media. >> Where available, this Link Integrity Test operation is used >> to identify when packets are able to be received on an >> Ethernet segment. It is applicable to both wired and optical >> physical layers, although details vary between technologies >> (link pulses in twisted pair copper, light levels in fibre). >>(end revised) >> >> >>Subsection: Link Integrity Tests in 802.3 networks. >>--------------------------------------------------- >> >>The status of the link as determined by the Link Integrity >>Test is stored in the variable 'link_status'. Changes to the >>value of link_status (for example due to Link Integrity Test >>failure) will generate link indications if the technology >>dependent interface is implemented on an ethernet device [802.3]. >> >>The link_status has possible values of FAIL, READY and OK. >>When an interface is in FAIL state, Link Integrity Tests have failed. >>Where status is READY, the link segment has passed integrity >>tests, but autonegotiation has not completed. OK state >>indicates that the medium is able to send and receive packets. >> >>Upon transition to a particular state the Physical Medium >>Attachment subsystems generates a PMA_LINK.indicate(link_status). >>Indications of OK state may be used as Link-Up indications for DNA. >>PMA_LINK.indicate(FAIL) may be used as a Link-Down indication >>reliably by DNA[802.3]. >> >>(begin revised) >> Such indications do not definitively ensure that packets will >> be able to be received through the bridge domain, though. Such >> operations are governed by bridging. >>(end revised) >> >> >>Subsection: IEEE 802.1D Bridging and its effects on link indications >>-------------------------------------------------------------- >> >>(begin revised) >> Ethernet networks are commonly bridged. Bridging is a mechanisms >> which provides loopless paths across LANs interconnected by >> IEEE 802.1D bridges. >> >> >> Due to its necessity in preventing bridge loops, bridging has >> become synonymous with the spanning tree protocol. >> The spanning tree protocol and its variants provide loopless >> forwarding between ethernet-like bridges within a bridging domain. >> >> The Spanning Tree Protocol (STP) exchanges Bridge Protocol >>Data Unit >> (BPDU) frames in order to pass information about which >> bridges are connected to others. >> >> By default, the spanning tree protocol does not know whether >> a particular newly connected piece of ethernet will cause a >> loop. >> >> Therefore it will block all traffic from and to a newly connected >> ports with the exception of some unbridged management frames. >> The STP will determine if the port can be connected to the >>network in >> a loop-free environment. >> >> For these technologies, even though the link-layer appears >> available, no forwarding will occur until it is determined that >> the port can be connected to the network in a loop-free >> environment. >>(end revised) >> >>(start added context) >> For host which are providing indications to upper layer protocols, >> even if the host itself does not implement bridging or STP, >> packet delivery across the network can be affected by their >> directly adjacent LAN peer which may be a bridge, or if this is >> a repeater, by the presence of STP bridges upon that LAN. >>(end added context) >> >>(start revised) >> Where the host is not running STP itself, no explicit indication >> that forwarding has begun is sent from a switch to its >>peer devices. >> Therefore, a host may not know when STP operations have completed, >> and when it is safe to inform upper layers to transmit packets. >>(end revised) >> >>As described in (Subsection on 802.1AB LLDP) explicit >>knowledge may be available through the new Link-Layer >>Discovery Protocol as to whether frame forwarding operation >>is immediately available. >> >>Where it is not known that forwarding operations are >>available, a host needs to assume that STP is being >>performed, and may indicate full connectivity only based on >>reception of BPDUs or timeouts. >> >>Upon learning that an adjacent port is running STP or RSTP, >>the host may send a Link-Up indication with a 'forwarding available' >>parameter upon expiry of calculated delays to indicate that >>general packet transfer is available across the LAN. >> >>(begin revised) >> If no bridge configuration messages are received within the >> default Bridge_Max_Age interval (20s), then it is likely that >> the peer's port is Disabled for bridging (S8.4.5 of [802.1D]), >> or the device is not a bridge, since at least two BPDU hello >> messages have been lost. >> >> It is not easy for a non-STP host to distinguish between >> Disabled ports and non-bridge ports with no IP nodes on them, >> as Disabled ports will have no traffic on them, and incur >> 100% sender loss. >> >> Upon this Bridge_Max_Age timeout, a host may (re)-send a >> link-layer indication showing that packets sent within the prior >> interval were likely to have traversed the forwarding path >> (unless the port is disabled). >>(end revised) >> >>If a BPDU is received, and the peer is running the original >>Spanning Tree Protocol, then host cannot successfully send >>packets until at least the peer's ForwardDelay timer has expired >>twice. This timeout defaults to 30 seconds (2 * 15 seconds) >>[802.1d]. After this time, the host can send a link-layer up >>indication showing that the previous interval after the >>PMA_LINK.indicate(OK) event was one of loss. >> >>If the switch is identified as performing Rapid Spanning Tree >>Protocol (RSTP), it instead waits Bridge_Max_Age after packet >>reception (advertised in the BPDU's Max Age field), before forwarding. >>For ports which are known to be point-to-point through >>autonegotiation, this delay is abbreviated to 3 seconds after >>autonegotiation completes [802.1d]. >>After either of these delays, a link-layer indication updating the >>PMA_LINK.indicate(OK) can show that the interval between >>indications was a lossy interval. >> >> >>Subsection: 802.1AB Link-Layer Discovery Protocol. >>------------------------------------------------- >> >>The recently defined 802.1AB Link-Layer Discovery Protocol >>(LLDP) provides information to directly connected devices >>about its MAC peer[802.1AB]. >> >>LLDP sends information periodically, and at link status >>change time to indicate the configuration parameters of the device. >>Devices may either send or receive these messages, or both. >> >>(begin revised) >> The LLDP message may a System Capabilities TLV, which >> describes the MAC and IP layer functions which a device is >> currently using. Where a host receives the >> Systems Capabilities TLV which indicate that no Bridging or >> Repeating is occurring on the link-layer peer, then no delays >> for STP calculation will be applied to packets sent from this >> host, if does not perform STP itself. This would allow the >> host's link-layer to indicate that to its knowledge the link >> is available for packet transfer. >>(end revised) >> >>Additionally, if a host receives a Systems Capabilities TLV >>which indicates that the peer is a switch or repeater, the >>host's advertisement that it is an (end-host) Station-Only, >>may tell the peer switch not to run STP, and immediately >>allow forwarding. >> >>Proprietary extensions may also indicate that data forwarding >>is already available on such a port. Discussions of such >>optimizations is out-of-scope for this document. >> >>Due to the protocol's newness and lack of deployment, it is >>unclear how this protocol will eventually affect DNA in IPv4 >>or IPv6 networks. >> >> >>Summary >>------- >> >>Link-Layer indications in Ethernet-like networks are >>complicated by additional unadvertised delays due to Spanning >>Tree calculations. This may cause re-indication or >>retraction of indications previously sent to upper layer protocols. >> >> > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 7 21:16:24 2005 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 VAA04769 for ; Tue, 7 Jun 2005 21:16:23 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP7SXDN27M94Q5X8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Jun 2005 11:16:12 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B65638000D; Wed, 08 Jun 2005 11:14:53 +1000 (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 557433C009; Wed, 08 Jun 2005 11:14:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j581ENR29373 for dna-list; Wed, 08 Jun 2005 11:14:23 +1000 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 j581EMr29367 for ; Wed, 08 Jun 2005 11:14:22 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP7SWCB8P29AO9JK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Jun 2005 11:14:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A8C42AB543; Wed, 08 Jun 2005 11:14:03 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8CB5A4FB06; Wed, 08 Jun 2005 11:14:03 +1000 (EST) Date: Wed, 08 Jun 2005 11:13:58 +1000 From: Greg Daley Subject: Re: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section In-reply-to: <024401c56b91$46a251c0$0601a8c0@pc6> Sender: owner-dna@ecselists.eng.monash.edu.au To: Tom Petch Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A64656.6060600@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42A5358C.2090101@eng.monash.edu.au> <024401c56b91$46a251c0$0601a8c0@pc6> Content-Transfer-Encoding: 7BIT Hi Tom, Tom Petch wrote: > Some more comments in line. I do find that my style is somewhat different to > yours, so it may not be helpful to interpose my words directly between yours. I've done that. Thanks for the text. > Two semantic concerns, I have not encountered hosts (ie not bridge/switches) > that listen to BDPU to find out what is happening but that may be just my > ignorance; certainly technically feasible and sensible for DNA, but do boxes > actually do it? You make several references to it. (By contrast, I do > encounter boxes which listen to routing protocol traffic to find out what is > happening at layer three). I think that what is not expressed properly is that devices which can't inspect BPDU frames need to either: a) Accept that up to 50 s of packets can be lost if they transmit immediately upon link arrival b) Accept an induced delay of up to 50s (but probably 30s) before transmission of packets. This has to be indicated to upper layer protocols. The inspection of BPDU frames would have to be an optimization. Here's my text proposal: "... Where it is not known that forwarding operations are available, a host needs to assume that STP is being performed, and may indicate full connectivity only based on timeouts or reception of BPDUs. (added) Most hosts today do not listen to BPDU frames. For these hosts, connectivity to the a port which is potentially bridged (any Ethernet port) carries the potential of frame loss if transmissions occur before any bridges' ForwardDelay timers have expired twice. This timeout defaults to 30 seconds (2 * 15 seconds), but may be as high as 60s[802.1d]. When sending indications to upper layers, the period where frame forwarding is potentially unavailable should be indicated to upper-layer protocols. Alternatively, a host can listen for BPDUs and use them to determine the length of port blockage which will occur in their particular circumstances. (end added) Upon learning that an adjacent port is running STP or RSTP, the host may send a Link-Up indication with a 'forwarding available' parameter upon expiry of calculated delays to indicate that general packet transfer is available across the LAN. ..." This brings forward discussion of Forward Delay parameters Which means that the same gets removed from a later paragraph. "... If a BPDU is received, and the adjacent switch is running the original Spanning Tree Protocol, then host cannot successfully send packets until at least twice the ForwardDelay value in the received BPDU has elapsed. After this time, the host can send a link-layer up indication showing that the previous interval after the PMA_LINK.indicate(OK) event was one of loss. ..." > And this peer thingy; I don't get it (except in the case of two boxes directly > connected by one piece of UTP or fibre). I don't see repeater or bridge as > peer. Repeater is physically repeating, passive except in so far as it > propagates collisions and participates in Link Integrity. Bridge is also > (usually) transparent; you don't see it, apart from added delays, until it > decides not to forward, for up to 50s, as part of a topology change (or unless > you listen in to BPDU which, as I said, I only see bridges doing). I struggle > to see it as peer in any meaningful sense. You're right about the peers. They're misleading. Any bridge on the path between a host and its destination will block frames. In addition to your suggestions, I've removed the references to peers with the following two paragraphs. ------------ Replace: "... Where the host is not running STP itself, no explicit indication that forwarding has begun is sent from a switch to its peer devices. Therefore, a host may not know when STP operations have completed, and when it is safe to inform upper layers to transmit packets. ..." With: "... Where the host is not running STP itself, no explicit indication that forwarding has begun is sent from a switch. Therefore, a host may not know when STP operations have completed, and when it is safe to inform upper layers to transmit packets. ..." ----------- Replace: "... If no bridge configuration messages are received within the default Bridge_Max_Age interval (20s), then it is likely that the peer's port is Disabled for bridging (S8.4.5 of [802.1D]), or the device is not a bridge, since at least two BPDU hello messages have been lost. ..." With: "... If no bridge configuration messages are received within the Bridge_Max_Age interval (default 20s), then it is likely that there is no visible bridge whose port is enabled for bridging (S8.4.5 of [802.1D]), since at least two BPDU hello messages would have been lost. ..." ----------- Replace: "... The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) provides information to directly connected devices about its MAC peer[802.1AB]. ..." With: "... The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) provides information to devices which are directly adjacent to them on the local LAN[802.1AB]. ..." ----------- Replace: "... The LLDP message may a System Capabilities TLV, which describes the MAC and IP layer functions which a device is currently using. Where a host receives the Systems Capabilities TLV which indicate that no Bridging or Repeating is occurring on the link-layer peer, then no delays for STP calculation will be applied to packets sent from this host, if does not perform STP itself. This would allow the host's link-layer to indicate that to its knowledge the link is available for packet transfer. ..." With: "... The LLDP message may a System Capabilities TLV, which describes the MAC and IP layer functions which a device is currently using. Where a host receives the Systems Capabilities TLV which indicate that no Bridging or Repeating is occurring on the LLDP transmitter, then no delays for STP calculation will be applied to packets sent through this transmitter, if the host does not perform STP itself. This would allow the host's link-layer to indicate that to its knowledge the link is available for packet transfer. ..." --------- Replace: "... Additionally, if a host receives a Systems Capabilities TLV which indicates that the peer is a switch or repeater, the host's advertisement that it is an (end-host) Station-Only, may tell the peer switch not to run STP, and immediately allow forwarding. ..." With: "... Additionally, if a host receives a Systems Capabilities TLV which indicates that the LLDP transmitter is a switch, the host's advertisement that it is an (end-host) Station-Only, may tell the switch not to run STP, and immediately allow forwarding. ..." ---------- I'll send a completed revision off-list. Thanks once again for your input. Greg. From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 7 22:33:57 2005 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 WAA10501 for ; Tue, 7 Jun 2005 22:33:56 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP7VN7L8Y4979K2Z@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Jun 2005 12:33:26 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6617A80004; Wed, 08 Jun 2005 12:32:59 +1000 (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 20C6C3C005; Wed, 08 Jun 2005 12:32:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j582WVY30295 for dna-list; Wed, 08 Jun 2005 12:32:31 +1000 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 j582WVr30291 for ; Wed, 08 Jun 2005 12:32:31 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP7VMCPGL294QA3V@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Jun 2005 12:32:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EBD8F80002 for ; Wed, 08 Jun 2005 12:32:17 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id CBC963C003 for ; Wed, 08 Jun 2005 12:32:17 +1000 (EST) Date: Wed, 08 Jun 2005 12:32:17 +1000 From: Greg Daley Subject: [DNA] Reminder about topics of messages for DNA WG. Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42A658B1.60808@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear WG, I'm reminding people that this list is for the purposes of Detecting Network Attachment standardization, and its related technologies. As such, BCP 94 (RFC 3934) regarding management of mailing lists is in force. If you have not read this document, please do so. I encourage people to focus discussion on development of DNA solutions and documents in their e-mails. Yours Faithfully, Greg Daley From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 8 21:06:48 2005 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 VAA09118 for ; Wed, 8 Jun 2005 21:06:46 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LP96WAK7IK9792OC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 09 Jun 2005 11:05:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 70FD280004; Thu, 09 Jun 2005 11:05:40 +1000 (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 06ADD3C00A; Thu, 09 Jun 2005 11:05:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j59142Y12608 for dna-list; Thu, 09 Jun 2005 11:04:02 +1000 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 j59141r12604 for ; Thu, 09 Jun 2005 11:04:01 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LP96U2RUIU99KMIT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 09 Jun 2005 11:03:53 +1000 Received: by localhost (Postfix, from userid 510) id 8B8E5AB54B; Thu, 09 Jun 2005 11:03:53 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 A68EB4FB0B for ; Thu, 09 Jun 2005 11:03:50 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DgBSV-0004F2-RL for dna@eng.monash.edu.au; Wed, 08 Jun 2005 21:03:48 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j5913jT03582 for ; Wed, 08 Jun 2005 18:03:46 -0700 Date: Wed, 08 Jun 2005 18:03:45 -0700 (PDT) From: Bernard Aboba Subject: [DNA] Link-layer notifications in the presence of RSTP (802.1/802.3) (fwd) X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Here are some comments by Mick Seaman of IEEE 802.1. >From: Mick Seaman >Reply-To: mick_seaman@ieee.org >To: STDS-802-1-L@listserv.ieee.org >Subject: [802.1] Link-layer notifications in the presence of RSTP >(802.1/802.3) >Date: Wed, 8 Jun 2005 16:03:43 -0700 > >Paul Congdon notified the 802.1 email list of the existence of > >http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-06/msg00088.html > >which discusses link up/down for 802.3/802.1 networks. > >Here are a few thoughts/information points on the subject: > >When a 802.3 link (LAN) comes up and at least one of the attached stations >is a bridge (port) running RSTP, with the other being another bridge >running >RSTP or an end station, then the following cases will determine the delay >to, and knowledge of "link up" (i.e. bridge port state Forwarding, to be >specific). > >A. The LAN is point-to-point (as per auto negotiation or forced by >management - adminPointToPointMAC in a Bridge), or shared media > >B. The setting of the RSTP AdminEdge and AutoEdge RSTP parameters, which >the >RSTP state machines use to determine operEdge i.e. am I connected to >another bridge? > >Leaving shared media on one side at the moment, as being of minority >interest currently, and just looking at point to point, scenarios include: > >PP1: Point to point, RSTP bridge to end station, with bridge with AdminEdge >TRUE: > > Bridge brings link up immediately. > >PP2: Point to point, RSTP bridge to end station, with bridge with AdminEdge >FALSE and AutoEdge TRUE: > > Bridge brings link up after 3 seconds approx. > >PP3: Point to point, RSTP Bridge to RSTP Bridge. AdminEdge and AutoEdge >both >don't care. > > Both bridges will bring link up after 0-2 seconds, as the RSTP >Proposal >Agreement handshake will work in that time. > >PP4: Point to point, end station to end station. > > End stations can assume link up after 3 seconds, if no better >knowledge >is available. > >The following are potentially useful end station behaviors in the short >term, not specified in 802.1D because that doesn't specify end station >behavior. > >ES1: Receive BPDUs. If none are received with 3 seconds, then assume link >is >up. That will deal with legacy STP Bridges. If an RSTP BPDU is received >then >declare link up if and only if the Forwarding flag in the BPDU is set, that >allows bridges with AdminEdge TRUE to be autodetected by the end station. >If >an STP BPDU is received wait the requisite long time to bring the link up. > >ES2: Send RSTP BPDUs with lowest priority and the Agreement flag set, that >should cause the/any RSTP Bridge to bring the link up - which can be >detected by the end station as per ES1. (This is probably not the right >long >term behavior). > >ES3: Use .1AB to advertise "I am not a bridge". This would couple with >bridge behavior. > >The following is potentially useful bridge behavior: > >BR1: Use receipt of a .1AB "I am not a bridge" message to autoset >AdminEdge, >or directly to nudge the RSTP state machine in the same way. Taken as a >package ES3, BR1, and ES1 do well. > >A longer term view of link-up/down should take into account the probability >of Port-based Network Access Control being used to regulate end station >access to the network. This requires a much better focus on what is really >meant by "link up" -- "up" from whose point of view and to do what? The >preferred placement of .1AB and RSTP is above MAC Security. If the security >framework returns authentication and authorization attributes, possibly as >Radius attributes to a bridge port functioning as the network access port, >then both an RSTP capable bridge and an end station newly attached to a >bridge port should be able to unambiguously answer the questions "am I >attached to a bridge/am I attached to a station that I will allow to >operate >as a bridge?". The bridge port can come "up" as soon as soon as it knows >that it is attached to an end station, which should be just as .1AB and >RSTP >are about to run. Behavior ES1 may still be useful to mark the exact start >of link up, though ideally the completion of the distribution of session >keys would mark "link up" except in those cases where further active human >intervention would be required. > >Mick > >IEEE 802.1 list info: http://www.ieee802.org/1/email-pages/hngih305.html From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 10 21:45:12 2005 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 VAA02268 for ; Fri, 10 Jun 2005 21:45:11 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPC0US0KEM9AOBRD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 11 Jun 2005 11:45:05 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E9E9CAB544; Sat, 11 Jun 2005 11:45:01 +1000 (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 A6DB94FB04; Sat, 11 Jun 2005 11:45:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5B1hlI11080 for dna-list; Sat, 11 Jun 2005 11:43:47 +1000 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 j5B1hlr11074 for ; Sat, 11 Jun 2005 11:43:47 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPC0T0RDZW9AOBRD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 11 Jun 2005 11:43:37 +1000 Received: by localhost (Postfix, from userid 510) id 201AFAB543; Sat, 11 Jun 2005 11:43:37 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2420B4FB03 for ; Sat, 11 Jun 2005 11:43:34 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHW008J8CSJ6H@mailout2.samsung.com> for dna@eng.monash.edu.au; Sat, 11 Jun 2005 10:43:31 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHW00GL9CSJIX@mmp1.samsung.com> for dna@eng.monash.edu.au; Sat, 11 Jun 2005 10:43:31 +0900 (KST) Date: Sat, 11 Jun 2005 10:43:32 +0900 From: "Soohong Daniel Park@samsung.com" Subject: [DNA] [New I-D] FW: I-D ACTION:draft-daniel-dna-fastraopt-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <010501c56e26$fa021420$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/mixed; boundary="Boundary_(ID_ZYvPP8pq2+VU2jVBuHR+vw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) This is a multi-part message in MIME format. --Boundary_(ID_ZYvPP8pq2+VU2jVBuHR+vw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT fyi. All commnets are highly welcome. Regards, --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Saturday, June 11, 2005 4:37 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-daniel-dna-fastraopt-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : IPv6 Fast Neighbor Discovery Option > Author(s) : S. Park > Filename : draft-daniel-dna-fastraopt-00.txt > Pages : 0 > Date : 2005-6-10 > > To minimize router delay in response to Router Solicitation message, > several scheme are being discussed in IETF. This document > suggests a > new Neighbor Discovery option which is included in Router > Solicitation and/or Router Advertisement messages to achieve fast > network attachment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-dna-fastraopt-00.txt --Boundary_(ID_ZYvPP8pq2+VU2jVBuHR+vw) Content-type: Message/External-body; name=ATT00197.dat Content-disposition: attachment; filename=ATT00197.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-6-10154500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daniel-dna-fastraopt-00.txt --Boundary_(ID_ZYvPP8pq2+VU2jVBuHR+vw) Content-type: Message/External-body; name=draft-daniel-dna-fastraopt-00.txt Content-disposition: attachment; filename=draft-daniel-dna-fastraopt-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-6-10154500.I-D@ietf.org> --Boundary_(ID_ZYvPP8pq2+VU2jVBuHR+vw) Content-type: text/plain; name=ATT00200.txt Content-disposition: attachment; filename=ATT00200.txt Content-Transfer-Encoding: 7BIT _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_ZYvPP8pq2+VU2jVBuHR+vw)-- From dna-owner@webcamserver.eng.monash.edu.au Sun Jun 12 21:04:00 2005 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 VAA24633 for ; Sun, 12 Jun 2005 21:03:59 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPES0DKZ7M9AOE3H@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 13 Jun 2005 11:03:54 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1856AAB545; Mon, 13 Jun 2005 11:03:50 +1000 (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 CB9954FB02; Mon, 13 Jun 2005 11:03:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5D12Ol12029 for dna-list; Mon, 13 Jun 2005 11:02:24 +1000 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 j5D12Nr12025 for ; Mon, 13 Jun 2005 11:02:23 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPERXCO00G99L1WH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 13 Jun 2005 11:02:11 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B629180002; Mon, 13 Jun 2005 11:02:10 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 918803C003; Mon, 13 Jun 2005 11:02:10 +1000 (EST) Date: Mon, 13 Jun 2005 11:02:09 +1000 From: Brett Pentland Subject: Re: [DNA] [New I-D] FW: I-D ACTION:draft-daniel-dna-fastraopt-00.txt In-reply-to: <010501c56e26$fa021420$6cc6dba8@daniel> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Soohong Daniel Park@samsung.com" Cc: dna@eng.monash.edu.au Message-id: <42ACDB11.3040109@eng.monash.edu.au> 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.2-1.3.3 (X11/20050513) References: <010501c56e26$fa021420$6cc6dba8@daniel> Content-Transfer-Encoding: 7BIT Hello Daniel, I read through your draft and have a question. In the introduction, you recognise that the reason for the RA random delay in RFC 2461 is to prevent simultaneous responses from multiple routers. I can't see anything in your draft that replaces the random delay to provide this separation. Are you just proposing that like draft-mkhalil-ipv6-fastra-05.txt, one router be configured to provide fast responses? The difference would then just be that fast responses are only given by that configured router to hosts that specifically request it. If you have to go to the effort of configuring one router to be able to provide fast responses, then why would you ever want it not to provide a fast response? Brett. Soohong Daniel Park@samsung.com wrote: > fyi. > > All commnets are highly welcome. > > Regards, > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > > >>-----Original Message----- >>From: i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>Internet-Drafts@ietf.org >>Sent: Saturday, June 11, 2005 4:37 AM >>To: i-d-announce@ietf.org >>Subject: I-D ACTION:draft-daniel-dna-fastraopt-00.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >> >> >> Title : IPv6 Fast Neighbor Discovery Option >> Author(s) : S. Park >> Filename : draft-daniel-dna-fastraopt-00.txt >> Pages : 0 >> Date : 2005-6-10 >> >>To minimize router delay in response to Router Solicitation message, >> several scheme are being discussed in IETF. This document >>suggests a >> new Neighbor Discovery option which is included in Router >> Solicitation and/or Router Advertisement messages to achieve fast >> network attachment. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-daniel-dna-fastraopt-00.txt >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 13 12:53:13 2005 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 MAA29320 for ; Mon, 13 Jun 2005 12:53:12 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPFP58QQWQ99L55L@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 02:53:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 82C0C80002; Tue, 14 Jun 2005 02:53:02 +1000 (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 321D53C00B; Tue, 14 Jun 2005 02:53:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5DGq8J22155 for dna-list; Tue, 14 Jun 2005 02:52:08 +1000 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 j5DGq7r22151 for ; Tue, 14 Jun 2005 02:52:07 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPFP3TJ3Y294RI4R@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 02:51:54 +1000 Received: by localhost (Postfix, from userid 510) id D3399AB542; Tue, 14 Jun 2005 02:51:53 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7A3A34FB07 for ; Tue, 14 Jun 2005 02:51:50 +1000 (EST) Date: Mon, 13 Jun 2005 09:52:57 -0700 From: James Kempf Subject: Re: [DNA] [New I-D] FW: I-D ACTION:draft-daniel-dna-fastraopt-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: "Soohong Daniel Park@samsung.com" , dna@eng.monash.edu.au Message-id: <00d301c57038$5cef8e10$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> Content-Transfer-Encoding: 7BIT Danial, The DT considered having a designated "fast responder" and rejected the idea based on the need for configuration. The algorithm described in draft-pentland doesn't require configuring any router to be the fast responder. This has two benefical effects: 1) it removes the possibility of error and need for additional human attention which makes network management easier, 2) it removes problems if the designated fast responder crashes or is taken offline. jak ----- Original Message ----- From: "Soohong Daniel Park@samsung.com" To: Sent: Friday, June 10, 2005 6:43 PM Subject: [DNA] [New I-D] FW: I-D ACTION:draft-daniel-dna-fastraopt-00.txt > fyi. > > All commnets are highly welcome. > > Regards, > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Saturday, June 11, 2005 4:37 AM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-daniel-dna-fastraopt-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : IPv6 Fast Neighbor Discovery Option > > Author(s) : S. Park > > Filename : draft-daniel-dna-fastraopt-00.txt > > Pages : 0 > > Date : 2005-6-10 > > > > To minimize router delay in response to Router Solicitation message, > > several scheme are being discussed in IETF. This document > > suggests a > > new Neighbor Discovery option which is included in Router > > Solicitation and/or Router Advertisement messages to achieve fast > > network attachment. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-daniel-dna-fastraopt-00.txt > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 13 13:44:37 2005 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 NAA03046 for ; Mon, 13 Jun 2005 13:44:36 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPFQXQN5BC99L8MH@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 03:44:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 84CAA80003; Tue, 14 Jun 2005 03:44:15 +1000 (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 428EE3C006; Tue, 14 Jun 2005 03:44:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5DHi1222704 for dna-list; Tue, 14 Jun 2005 03:44:01 +1000 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 j5DHi0r22700 for ; Tue, 14 Jun 2005 03:44:00 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPFQX41ZB29AOFQ2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 03:43:45 +1000 Received: by localhost (Postfix, from userid 510) id 596F9AB542; Tue, 14 Jun 2005 03:43:45 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1F7944FB04 for ; Tue, 14 Jun 2005 03:43:43 +1000 (EST) Date: Mon, 13 Jun 2005 10:44:52 -0700 From: James Kempf Subject: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT I've been meaning to write this up for some time. Below is some text for a section to add to draft-pentland about the interaction of DNA with host address configuration, both unicast and multicast. It covers stateful and stateless address configuration. The text is intended to be for a new section in draft-pentland, presuming, of course, that the WG approves draft-pentland as the basis for the WG draft. Comments? jak --------------------------- 5.2.5 DNA and Address Configuration When a host moves to a new link, a potential exists for a change in the validity of its unicast link local and global addresses, and its multicast addresses. In this section, host processing for address configuration is specified. The section considers both statelessly and statefully configured addresses. 5.2.5.1 Duplicate Address Detection A DNA host MUST support optimistic Duplicate Address Detection [RFCoDAD] for autoconfiguring unicast link local addresses. If a DNA host uses address autoconfiguration [RFC2462] for global addresses, the DNA host MUST support optimistic Duplicate Address Detection for autoconfiguring global unicast addresses. 5.2.5.2 DNA and the Address Autoconfiguration State Machine When a link level event occurs indicating that the host has moved from one link to another, DNA requires the host to determine whether a change in IP link has occured by sending an RS. The DNA host SHOULD select one of its link local addresses that is in the "Confirmed" state (i.e. assigned to an interface) and utilize that as the source address on the DNA RS. If the host has no "Confirmed" link local addresses but does have an address in the "Optimistic" state, it MUST utilize that as the source address. Since optimistic Duplicate Address Detection is required for DNA, the host should not have any addresses in the "Tentative" state. If the host currently has no link local addresses, it MUST construct one and put it into the "Optimistic" state. Note that the presence of a duplicate link local address on the link will not interfere with the ability of the link to route a unicast RA from the router back to the host, because the TSLLA option is included in the RS and is utilized by the router on the RA frame. If the host receives no RA in reply, it MUST transition all addresses to the "Optimistic" state and act according to [RFC2461] as if no router has been discovered on the link. If the received RAs indicate that the host has not moved to a new IP link (i.e. the IP link has not changed) either because a DNA RA has been received or nonDNA RAs have been received and the host performs CPL, then the host is REQUIRED to leave the state of all "Confirmed" and "Optimistic" addresses unchanged and continue with optimistic Duplicate Address Detection for "Optimistic" addresses. This includes both unicast link local and statelessly autoconfigured unicast global addresses (but not statefully configured global unicast addresses). If the received RAs indicate that the host has moved to a new IP link (i.e. the IP link has changed), either because a DNA RA has been received or nonDNA RAs have been received and the host performs CPL, the host MUST transition all autoconfigured addresses in the "Confirmed" state to "Optimistic" and begin optimistic Duplicate Address Detection signaling for them. Optimistic Duplicate Address Detection signaling for "Optimistic" addresses MUST also be restarted and continued until either a duplicate is detected or the signaling timeout occurs, according to [RFCoDAD]. 5.2.5.3 DNA and Statefully Configured Addresses The DHCPv6 specification [RFC3315] requires hosts to send a DHCPv6 CONFIRM message when a change in link is detected. Since the DNA protocol provides the same level of movement detection as the DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive signaling. When a DNA RA is received, statefully configured addresses are handled similarly to autoconfigured addresses. If the received RA indicates that the host has not moved to a new IP link, the statefully configured addresses are still valid and can continue to be used until their lease expires. If the DNA RA indicates that the host has moved to another link, the host is REQUIRED to begin stateful configuration again. If, however, a nonDNA RA is received, the host SHOULD use the DHCPv6 CONFIRM message as described in RFC 3315 rather than wait for additional RAs to perform CPL, since it reduces the amount of time required for the host to confirm whether or not it has moved to a new link. If the CONFIRM message validates the addresses, then the host can continue to use them. If not, the host MUST perform DHCPv6 stateful address configuration again, as described by RFC 3315. 5.2.5.4 Change in IP Link Address Configuration Type It is possible that a host may encounter a change in IP link address configuration type (for example, from stateful to stateless) when it moves from one IP link to another. The solicited RA will indicate what type of address configuration to perform in this case, and MUST be followed. In general, a change in IP link address configuration type should not occur if the host does not change IP link. However, if the initial DNA RA indicates that the host has not changed IP link but the IP link address configuration type is different from the last indication of the address configuration type on the link, the host SHOULD wait for additional RAs before beginning address reconfiguration. If all RAs agree as to the address configuration type change, then the host MUST perform address reconfiguration as specified by the RAs even though it has not changed to a new link. If the RAs do not agree, then it is likely that the routers are misconfigured, and the host MAY continue to use previous addresses as described above, but an error message should be logged to inform the network administrator, and the host should be vigilant for possible errors. 5.2.5.5 Multicast Address Configuration If the returned DNA RA indicates that the host has not moved to a new IP link, no further action is required for multicast addresses to which the host has subscribed. If, on the other hand, the DNA RA indicates that the host has moved to a new IP link, the host MUST issue MLD [RFC3810] messages to the router for subscribed multicast addresses, including the Solicited_Node_Multicast_Address for any unicast addresses configured. From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 13 18:25:24 2005 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 SAA13722 for ; Mon, 13 Jun 2005 18:25:23 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPG0R36KNQ9AOCZD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 08:25:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DEF5780006; Tue, 14 Jun 2005 08:25:12 +1000 (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 93EEF3C004; Tue, 14 Jun 2005 08:25:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5DMMXc25755 for dna-list; Tue, 14 Jun 2005 08:22:33 +1000 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 j5DMMWr25751 for ; Tue, 14 Jun 2005 08:22:32 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPG0NOJGNS99KZXZ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 08:22:29 +1000 Received: by localhost (Postfix, from userid 510) id 04DCFAB544; Tue, 14 Jun 2005 08:22:28 +1000 (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 06EAB4FB06 for ; Tue, 14 Jun 2005 08:22:26 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5DMMMqg012849; Mon, 13 Jun 2005 16:22:23 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5DMMLqg700316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2005 15:22:22 -0700 (PDT) Date: Mon, 13 Jun 2005 15:22:44 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Message-id: <42AE0734.7040807@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT James Kempf wrote: > > When a link level event occurs indicating that the host has moved from one > link to another, DNA requires the host to determine whether a change in IP > link has occured by sending an RS. The DNA host SHOULD select one of its > link local addresses that is in the "Confirmed" state (i.e. assigned to an > interface) and utilize that as the source address on the DNA RS. Doesn't this imply that if the host has moved to a new link, and the Confirmed address is a duplicate on that link, that the host might accidentally overwrite the neighbor cache entry for the existing user of that link-local address? That would seem to defeat the purpose of DAD. It is safer to, immediately when the link level event arrives, switch all Confirmed addresses to Optimistic. Then if it turns out that the host didn't move, it can switch those back to Confirmed. And if it turns out that the host did move, it can send the actual NS DAD probe for all the IP addresses it has (the existing link-local addresses, as well as any newly configured IP addresses). > If the returned DNA RA indicates that the host has not moved to a new IP > link, no further action is required for multicast addresses to which the > host has subscribed. > > If, on the other hand, the DNA RA indicates that the host has moved to a new > IP link, the host MUST issue MLD [RFC3810] messages to the router for > subscribed multicast addresses, including the > Solicited_Node_Multicast_Address for any unicast addresses configured. It actually needs to handle the Solicited node multicast addresses before starting any DAD procedure, to ensure that it will receive DAD messages when there are MLD snooping L2 switches. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 13 19:59:13 2005 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 TAA22625 for ; Mon, 13 Jun 2005 19:59:12 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPG411NPLC97AP1G@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 09:58:59 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B357080006; Tue, 14 Jun 2005 09:58:45 +1000 (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 6596D3C007; Tue, 14 Jun 2005 09:58:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5DNwIQ26824 for dna-list; Tue, 14 Jun 2005 09:58:18 +1000 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 j5DNwHr26820 for ; Tue, 14 Jun 2005 09:58:17 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPG40BZR5O94RF26@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 09:58:12 +1000 Received: by localhost (Postfix, from userid 510) id 6018CAB54A; Tue, 14 Jun 2005 09:58:11 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1C8954FB09 for ; Tue, 14 Jun 2005 09:58:09 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0II100AN6RWUV2@mailout3.samsung.com> for dna@eng.monash.edu.au; Tue, 14 Jun 2005 08:58:06 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0II10042HRWTTB@mmp1.samsung.com> for dna@eng.monash.edu.au; Tue, 14 Jun 2005 08:58:06 +0900 (KST) Date: Tue, 14 Jun 2005 08:58:08 +0900 From: "Soohong Daniel Park@samsung.com" Subject: RE: [DNA] [New I-D] FW: I-D ACTION:draft-daniel-dna-fastraopt-00.txt In-reply-to: <00d301c57038$5cef8e10$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'James Kempf'" , dna@eng.monash.edu.au Message-id: <00ff01c57073$bff3c0e0$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Jak, The purpose of this approach is just to separate fixed node and mobile node as well as avoid configuring router to support fast router response. That is all. As Brett pointed out, I was also think of multiple router issues to prevent simultaneous responses from them, but in my experience, it was not so serious problem in the real networks. Regarding DT consideration, I didn't know of that since non-DT guys are not able to see what happen in DT..:-) Regards, --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, June 14, 2005 1:53 AM > To: Soohong Daniel Park@samsung.com; dna@eng.monash.edu.au > Subject: Re: [DNA] [New I-D] FW: I-D > ACTION:draft-daniel-dna-fastraopt-00.txt > > > Danial, > > The DT considered having a designated "fast responder" and > rejected the idea > based on the need for configuration. The algorithm described in > draft-pentland doesn't require configuring any router to be the fast > responder. This has two benefical effects: 1) it removes the > possibility of > error and need for additional human attention which makes > network management > easier, 2) it removes problems if the designated fast > responder crashes or > is taken offline. > > jak > > ----- Original Message ----- > From: "Soohong Daniel Park@samsung.com" > To: > Sent: Friday, June 10, 2005 6:43 PM > Subject: [DNA] [New I-D] FW: I-D > ACTION:draft-daniel-dna-fastraopt-00.txt > > > > fyi. > > > > All commnets are highly welcome. > > > > Regards, > > --------------------------------------------- > > Daniel (Soohong Daniel Park) > > Mobile Platform Laboratory, SAMSUNG Electronics. > > > > > > > -----Original Message----- > > > From: i-d-announce-bounces@ietf.org > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > Internet-Drafts@ietf.org > > > Sent: Saturday, June 11, 2005 4:37 AM > > > To: i-d-announce@ietf.org > > > Subject: I-D ACTION:draft-daniel-dna-fastraopt-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > > > > Title : IPv6 Fast Neighbor Discovery Option > > > Author(s) : S. Park > > > Filename : draft-daniel-dna-fastraopt-00.txt > > > Pages : 0 > > > Date : 2005-6-10 > > > > > > To minimize router delay in response to Router > Solicitation message, > > > several scheme are being discussed in IETF. This document > > > suggests a > > > new Neighbor Discovery option which is included in Router > > > Solicitation and/or Router Advertisement messages to > achieve fast > > > network attachment. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-daniel-dna-fastraopt-00.txt > > > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 13 20:37:47 2005 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 UAA25459 for ; Mon, 13 Jun 2005 20:37:46 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPG5D7QTTC99L2I7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 10:37:39 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D7D88AB54A; Tue, 14 Jun 2005 10:37:35 +1000 (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 93B214FB02; Tue, 14 Jun 2005 10:37:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5E0bLX27284 for dna-list; Tue, 14 Jun 2005 10:37:21 +1000 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 j5E0bLr27280 for ; Tue, 14 Jun 2005 10:37:21 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPG5CLB56U99L8TS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 10:37:06 +1000 Received: by localhost (Postfix, from userid 510) id EA108AB542; Tue, 14 Jun 2005 10:37:05 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 564144FB05 for ; Tue, 14 Jun 2005 10:37:04 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0II100K98TPPY2@mailout2.samsung.com> for dna@eng.monash.edu.au; Tue, 14 Jun 2005 09:37:01 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0II1008T5TPP35@mmp2.samsung.com> for dna@eng.monash.edu.au; Tue, 14 Jun 2005 09:37:01 +0900 (KST) Date: Tue, 14 Jun 2005 09:37:04 +0900 From: "Soohong Daniel Park@samsung.com" Subject: RE: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'James Kempf'" , dna@eng.monash.edu.au Message-id: <000301c57079$2fd04820$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Jak, >5.2.5.3 DNA and Statefully Configured Addresses >When a DNA RA is received, statefully configured addresses are handled >similarly to autoconfigured addresses. Just curious to know, It means that DNA RA has a kind of M/O flags of a general RA (rfc2462) or just uses them ? Above mention does not clear for me at this point. >If the DNA RA indicates that the host has moved to another link, the host is >REQUIRED to begin stateful configuration again. Suggested to be added following above sentence (if appropriate of course), In DNA, it is beneficial to rapidly configure hosts. The DHCPv6 operation as 4-message exchange, however, allows for redundancy (multiple DHCPv6 servers) without wasting addresses, as addresses are only provisionally assigned to a host until the host chooses and requests one of the provisionally assigned addresses. If the DNA host supports the Rapid Commit Option [RFC3315], it is possible that the exchange can be shortened from a 4-message exchange to a 2-message exchange. Regards, --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 13 20:44:05 2005 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 UAA25830 for ; Mon, 13 Jun 2005 20:44:04 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPG5K6L3QK97BFBO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 10:43:39 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BCE24AB544; Tue, 14 Jun 2005 10:43:12 +1000 (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 728784FB03; Tue, 14 Jun 2005 10:43:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5E0h8H27372 for dna-list; Tue, 14 Jun 2005 10:43:08 +1000 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 j5E0h7r27368 for ; Tue, 14 Jun 2005 10:43:07 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPG5K1UTHE9AOFVI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 10:43:07 +1000 Received: by localhost (Postfix, from userid 510) id BB63FAB543; Tue, 14 Jun 2005 10:43:06 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id B937A4FB06 for ; Tue, 14 Jun 2005 10:43:05 +1000 (EST) Date: Mon, 13 Jun 2005 17:44:12 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> Content-Transfer-Encoding: 7BIT > Doesn't this imply that if the host has moved to a new link, and the > Confirmed address is a duplicate on that link, that the host might > accidentally overwrite the neighbor cache entry for the existing user of > that link-local address? > > That would seem to defeat the purpose of DAD. > Draft-pentland in Section 5.2.3 says this: Hosts MUST include a tentative source link layer address option (TSLLAO) in the RS message [13]. The router solicitation message is sent to the All_Routers_Multicast address and the source address MUST be the link local address of the host. The router uses the TSLLAO to route back to the host, and the definition of the TSLLAO means that it won't pollute the neighbor cache if there's a duplicate. So there should be no effect on the router neighbor cache even if there is a duplicate, and the router shouldn't send the RS to any other node even if there is a duplicate because the TSLLAO will allow link routing to work correctly. > It is safer to, immediately when the link level event arrives, switch > all Confirmed addresses to Optimistic. > Then if it turns out that the host didn't move, it can switch those back > to Confirmed. > And if it turns out that the host did move, it can send the actual NS > DAD probe for all the IP addresses it has (the existing link-local > addresses, as well as any newly configured IP addresses). > I considered that, but the problem is that if the addresses are switched to "Optimistic" . Section 3.3 of draft-ietf-ipv6-optimistic-dad says this about the "Optimistic" state: * (modifies 5.4) As soon as the initial Neighbor Solicitation is sent, the Optimistic Address is configured on the interface and available for use immediately. The address MUST be flagged as 'Optimistic'. so what this means to me is that the node would have to send NSes on the link prior to switching its addresses to Optimistic, even if it is on the same link, because it doesn't find out that it is on the same link until after the RA returns. I'm not sure whether the extra traffic overhead on each move is really necessary or beneficial. Unfortunately, there's no good solution here. Here are the possible states and their problems: - Optimistic: requires NS/DAD signaling even if the host hasn't switched IP links. If the host has switched IP links, then any packets sent with a global unicast address while the RS/RA transaction is underway will be sent with an address that is topologically incorrect (because the host may send packets while an address is in "Optimistic"). - Confirmed: If the host has switched links, then any packets sent with a global unicast address will be sent with an address that is topologically incorrect, as above. - Tentative: requires NS/DAD signaling even if the host hasn't switched IP links, but no topologically incorrect addresses will be used if the host has switched links since a host can't send any packets from a Tentative address. - Deprecated: not relevant, since the host can continue to use the address for existing connections and therefore would have the same problem with topological incorrectness here as with Optimistic and Confirmed. If we are OK with having the host signal to reconfirm addresses on every move, then we could switch the link local address used as the source address on the RS to Optimistic, and the others to Tentative prior to sending the RS. This would avoid the problem with topological incorrectness for global unicast addresses. When the RS returns, we could switch everything to Optimistic if the host is on the same IP link, since no change in topology has occured. If the IP link has changed, then the link local addresses could be switched to Optimistic and the unicast global addresses could be dropped (actually "dropped" is not in the state machine, and Deprecated isn't appropriate because RFC 2462 allows the host to continue using Deprecated addresses), and the host would then configure new global unicast addresses. Any other ideas about how to handle this? > > > > If the returned DNA RA indicates that the host has not moved to a new IP > > link, no further action is required for multicast addresses to which the > > host has subscribed. > > > > If, on the other hand, the DNA RA indicates that the host has moved to a new > > IP link, the host MUST issue MLD [RFC3810] messages to the router for > > subscribed multicast addresses, including the > > Solicited_Node_Multicast_Address for any unicast addresses configured. > > It actually needs to handle the Solicited node multicast addresses > before starting any DAD procedure, to ensure that it will receive DAD > messages when there are MLD snooping L2 switches. > Yes, that's true. I'll switch that around to make it clear. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 13 20:55:54 2005 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 UAA26487 for ; Mon, 13 Jun 2005 20:55:53 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPG6034DSE99L0SV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 10:55:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 95E15AB545; Tue, 14 Jun 2005 10:55:14 +1000 (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 468E74FB05; Tue, 14 Jun 2005 10:55:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5E0t5x27520 for dna-list; Tue, 14 Jun 2005 10:55:05 +1000 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 j5E0t4r27516 for ; Tue, 14 Jun 2005 10:55:04 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPG5YLDKCA94R8YB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 10:54:51 +1000 Received: by localhost (Postfix, from userid 510) id 3B973AB545; Tue, 14 Jun 2005 10:54:50 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3B62C4FB0B for ; Tue, 14 Jun 2005 10:54:48 +1000 (EST) Date: Mon, 13 Jun 2005 17:55:54 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: "Soohong Daniel Park@samsung.com" , dna@eng.monash.edu.au Message-id: <03ee01c5707b$d61f21e0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <000301c57079$2fd04820$6cc6dba8@daniel> Content-Transfer-Encoding: 7BIT > >5.2.5.3 DNA and Statefully Configured Addresses > > >When a DNA RA is received, statefully configured addresses are handled > >similarly to autoconfigured addresses. > > Just curious to know, > It means that DNA RA has a kind of M/O flags of a general RA (rfc2462) > or just uses them ? Above mention does not clear for me at this point. > The existing flags are unchanged. > >If the DNA RA indicates that the host has moved to another link, the host > is > >REQUIRED to begin stateful configuration again. > > Suggested to be added following above sentence (if appropriate of course), > > In DNA, it is beneficial to rapidly configure hosts. The DHCPv6 operation as > 4-message exchange, however, allows for redundancy (multiple DHCPv6 > servers) without wasting addresses, as addresses are only provisionally > assigned to a host until the host chooses and requests one of the > provisionally > assigned addresses. If the DNA host supports the Rapid Commit Option > [RFC3315], it is possible that the exchange can be shortened from a > 4-message exchange to a 2-message exchange. > Sure, thanx for pointing this out. jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 14 01:03:54 2005 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 BAA18183 for ; Tue, 14 Jun 2005 01:03:53 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPGEMDOLRC974PF6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 15:02:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 173F08000A; Tue, 14 Jun 2005 15:02:17 +1000 (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 C17053C004; Tue, 14 Jun 2005 15:02:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5E50iI30067 for dna-list; Tue, 14 Jun 2005 15:00:44 +1000 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 j5E50hr30061 for ; Tue, 14 Jun 2005 15:00:43 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPGEK31E7W9AOEPE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 15:00:27 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BA96F80004; Tue, 14 Jun 2005 15:00:26 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 9A5D43C00D; Tue, 14 Jun 2005 15:00:26 +1000 (EST) Date: Tue, 14 Jun 2005 15:00:26 +1000 From: Brett Pentland Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Message-id: <42AE646A.4090107@eng.monash.edu.au> 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.2-1.3.3 (X11/20050513) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi Jim, Thanks for doing this. It looks like it will be a good addition to the draft once the few issues that have been raised are addressed. I have a couple of comments too: > 5.2.5.2 DNA and the Address Autoconfiguration State Machine > > When a link level event occurs indicating that the host has moved from one > link to another, DNA requires the host to determine whether a change in IP > link has occured by sending an RS. The DNA host SHOULD select one of its We need to keep the terminology consistent (and this goes for the rest of the draft too...) The last discussions on this list that I can find (around 26/5/05) talked about "point of attachment" for what you have here called "link", and "link" for what you have called "IP link". I think the intention is to have them defined in the "L2 event notifications for DNA" document. > If the received RAs indicate that the host has moved to a new IP link (i.e. > the IP link has changed), either because a DNA RA has been received or > nonDNA RAs have been received and the host performs CPL, the host MUST > transition all autoconfigured addresses in the "Confirmed" state to > "Optimistic" and begin optimistic Duplicate Address Detection signaling for > them. Optimistic Duplicate Address Detection signaling for "Optimistic" > addresses MUST also be restarted and continued until either a duplicate is > detected or the signaling timeout occurs, according to [RFCoDAD]. This sounds right for link-local addresses, but I think global addresses will be invalid because of the link change and should be dropped altogether. New global addresses may be formed based on the prefix information in the RA and those should go into the Optimistic state. Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 14 07:22:04 2005 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 HAA04139 for ; Tue, 14 Jun 2005 07:22:03 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPGRUZXAZ094RDMF@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Jun 2005 21:22:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A41FCAB545; Tue, 14 Jun 2005 21:21:50 +1000 (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 E999E4FB13; Tue, 14 Jun 2005 21:21:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5EBKxK01638 for dna-list; Tue, 14 Jun 2005 21:20:59 +1000 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 j5EBKxr01634 for ; Tue, 14 Jun 2005 21:20:59 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPGRTKMRTU977YJX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Jun 2005 21:20:43 +1000 Received: by localhost (Postfix, from userid 510) id 14BCDAB545; Tue, 14 Jun 2005 21:20:43 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6044C4FB03; Tue, 14 Jun 2005 21:20:40 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0II200HVYNIE0W@mailout1.samsung.com>; Tue, 14 Jun 2005 20:20:38 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0II2005X2NIE2T@mmp1.samsung.com>; Tue, 14 Jun 2005 20:20:38 +0900 (KST) Date: Tue, 14 Jun 2005 20:20:41 +0900 From: "Soohong Daniel Park@samsung.com" Subject: [DNA] DNA Protocol vs. Protocol 2 In-reply-to: <92e919fb05052717366bb2ce24@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'JinHyeock Choi'" , greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <000c01c570d3$19842c30$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hello folks, In my understanding, Brett and Jinhyeock documents seem to achieve the same goal. I am just curious to know of why we need two documents not merged one. Is there any internal decision from DT ? To me, a single document seems mostly like an appropriate approach... Regards, --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > JinHyeock Choi > Sent: Saturday, May 28, 2005 9:37 AM > To: greg.daley@eng.monash.edu.au > Cc: dna@eng.monash.edu.au > Subject: [DNA] [New I-D] DNA Solution: Link Identifier based approach > > > Dear DNA Group > > We submitted the following draft as a solution work. > > DNA Solution: Link Identifier based approach > draft-jinchoi-dna-protocol2-00.txt > > As Brett mentioned, two approaches were discussed > in DT, Landmark based & Link Identifier based. > > The draft presents the second one and describes how > to check for link change with the prefix based linkid. > > Routers pick the smallest prefix as the linkid prefix and > include the linkid prefix in every RA. In short, if a host > sees the same linkid prefix, it is at the same link and if it > sees a different linkid prefix, it has moved to a new link. > > This document is available at the URL: > > http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-00.txt > > We are looking forward to your feedback. > > Best Regards > > JinHyeock Choi > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 14 11:17:48 2005 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 LAA26016 for ; Tue, 14 Jun 2005 11:17:47 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPH04B9USY9AOE82@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Jun 2005 01:17:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8741AAB542; Wed, 15 Jun 2005 01:17:39 +1000 (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 3A9084FB04; Wed, 15 Jun 2005 01:17:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5EFFgq04191 for dna-list; Wed, 15 Jun 2005 01:15:42 +1000 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 j5EFFfr04187 for ; Wed, 15 Jun 2005 01:15:41 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPH01JDK229AOE82@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Jun 2005 01:15:25 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 54CC080002; Wed, 15 Jun 2005 01:15:25 +1000 (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 3F30C3C00A; Wed, 15 Jun 2005 01:15:25 +1000 (EST) Received: from [211.28.184.100] by mail-store-2.its.monash.edu.au (mshttpd) ; Wed, 15 Jun 2005 01:15:25 +1000 Date: Wed, 15 Jun 2005 01:15:25 +1000 From: Greg Daley Subject: [DNA] Re: DNA Protocol vs. Protocol 2 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Soohong Daniel Park@samsung.com" Cc: "'JinHyeock Choi'" , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) 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 Daniel, ----- Original Message ----- From: "Soohong Daniel Park@samsung.com" Date: Tuesday, June 14, 2005 9:20 pm Subject: DNA Protocol vs. Protocol 2 > Hello folks, > > In my understanding, Brett and Jinhyeock documents > seem to achieve the same goal. I am just curious > to know of why we need two documents not merged > one. Is there any internal decision from DT ? I believe that the protocol document is aimed at providing one complete solution. I believe that the protocol-2 document is aimed by its authors at replacing a single portion of the protocol-00 document dependent on what the WG thinks. Both documents have received DT comments, and had discussion off-list. DT members may provide feedback to update this. There are still some differences in opinion regarding which trade-offs matter to which situations. In my guess, there are many solutions, most of which are 'good-enough' for DNA's purposes. > To me, a single document seems mostly like an > appropriate approach... Yes a single document is the appropriate approach. The WG should discuss the benefits of various components and determine if they warrant inclusion in the ultimate solution. Please comment on the documents. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 14 11:27:06 2005 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 LAA27146 for ; Tue, 14 Jun 2005 11:27:04 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPH0FPR5NU9AOCUT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Jun 2005 01:26:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1B594AB545; Wed, 15 Jun 2005 01:26:51 +1000 (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 B6AD04FB06; Wed, 15 Jun 2005 01:26:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5EFQfP04321 for dna-list; Wed, 15 Jun 2005 01:26:41 +1000 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 j5EFQer04317 for ; Wed, 15 Jun 2005 01:26:40 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPH0F67RWQ99L5CV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Jun 2005 01:26:25 +1000 Received: by localhost (Postfix, from userid 510) id EFE6380002; Wed, 15 Jun 2005 01:26:24 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 315113C009; Wed, 15 Jun 2005 01:26:23 +1000 (EST) Date: Tue, 14 Jun 2005 08:27:29 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Message-id: <044201c570f5$979c2ba0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE646A.4090107@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, > > 5.2.5.2 DNA and the Address Autoconfiguration State Machine > > > > When a link level event occurs indicating that the host has moved from one > > link to another, DNA requires the host to determine whether a change in IP > > link has occured by sending an RS. The DNA host SHOULD select one of its > > We need to keep the terminology consistent (and this goes for the rest > of the draft too...) The last discussions on this list that I can find > (around 26/5/05) talked about "point of attachment" for what you have > here called "link", and "link" for what you have called "IP link". I > think the intention is to have them defined in the "L2 event > notifications for DNA" document. > OK, sorry, I wrote it up quickly and didn't pay much attention to making the terminology consistent. I'll clean it up once we have discussion complete. > > If the received RAs indicate that the host has moved to a new IP link (i.e. > > the IP link has changed), either because a DNA RA has been received or > > nonDNA RAs have been received and the host performs CPL, the host MUST > > transition all autoconfigured addresses in the "Confirmed" state to > > "Optimistic" and begin optimistic Duplicate Address Detection signaling for > > them. Optimistic Duplicate Address Detection signaling for "Optimistic" > > addresses MUST also be restarted and continued until either a duplicate is > > detected or the signaling timeout occurs, according to [RFCoDAD]. > > This sounds right for link-local addresses, but I think global addresses > will be invalid because of the link change and should be dropped > altogether. New global addresses may be formed based on the prefix > information in the RA and those should go into the Optimistic state. > Right, that makes sense. jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 14 11:33:31 2005 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 LAA27526 for ; Tue, 14 Jun 2005 11:33:30 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPH0NX1H5W9AODNR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Jun 2005 01:33:29 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C21F1AB543; Wed, 15 Jun 2005 01:33:27 +1000 (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 6F93B4FB03; Wed, 15 Jun 2005 01:33:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5EFXLs04446 for dna-list; Wed, 15 Jun 2005 01:33:21 +1000 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 j5EFXJr04442 for ; Wed, 15 Jun 2005 01:33:19 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPH0NFB7SA99JS03@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Jun 2005 01:33:04 +1000 Received: by localhost (Postfix, from userid 510) id 204BD80002; Wed, 15 Jun 2005 01:33:04 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 136743C00C; Wed, 15 Jun 2005 01:33:01 +1000 (EST) Date: Tue, 14 Jun 2005 08:34:07 -0700 From: James Kempf Subject: Re: [DNA] DNA Protocol vs. Protocol 2 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Soohong Daniel Park@samsung.com" , "'JinHyeock Choi'" , greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <000c01c570d3$19842c30$6cc6dba8@daniel> Content-Transfer-Encoding: 7BIT Actually, the two documents contain protocols that are designed to solve the same problem in two completely different ways. So I don't think it is a matter of merging them, I think one or the other must be chosen. WG chairs, do you have any thoughts about how the decision on this will be made? Will we try to make a decision prior to the IETF meeting through discussion and s concensus call on the list, or do you want to wait until the meeting and have presentations on each proposal, then a straw poll? jak ----- Original Message ----- From: "Soohong Daniel Park@samsung.com" To: "'JinHyeock Choi'" ; Cc: Sent: Tuesday, June 14, 2005 4:20 AM Subject: [DNA] DNA Protocol vs. Protocol 2 > Hello folks, > > In my understanding, Brett and Jinhyeock documents > seem to achieve the same goal. I am just curious > to know of why we need two documents not merged > one. Is there any internal decision from DT ? > > To me, a single document seems mostly like an > appropriate approach... > > Regards, > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > > > -----Original Message----- > > From: owner-dna@ecselists.eng.monash.edu.au > > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > > JinHyeock Choi > > Sent: Saturday, May 28, 2005 9:37 AM > > To: greg.daley@eng.monash.edu.au > > Cc: dna@eng.monash.edu.au > > Subject: [DNA] [New I-D] DNA Solution: Link Identifier based approach > > > > > > Dear DNA Group > > > > We submitted the following draft as a solution work. > > > > DNA Solution: Link Identifier based approach > > draft-jinchoi-dna-protocol2-00.txt > > > > As Brett mentioned, two approaches were discussed > > in DT, Landmark based & Link Identifier based. > > > > The draft presents the second one and describes how > > to check for link change with the prefix based linkid. > > > > Routers pick the smallest prefix as the linkid prefix and > > include the linkid prefix in every RA. In short, if a host > > sees the same linkid prefix, it is at the same link and if it > > sees a different linkid prefix, it has moved to a new link. > > > > This document is available at the URL: > > > > http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-00.txt > > > > We are looking forward to your feedback. > > > > Best Regards > > > > JinHyeock Choi > > > > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 15 03:54:05 2005 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 DAA20122 for ; Wed, 15 Jun 2005 03:54:04 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPHYW5Z4T894REY0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Jun 2005 17:53:57 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 68C62AB544; Wed, 15 Jun 2005 17:53:38 +1000 (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 21D1E4FB0D; Wed, 15 Jun 2005 17:53:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5F7qGu15036 for dna-list; Wed, 15 Jun 2005 17:52:16 +1000 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 j5F7qEr15032 for ; Wed, 15 Jun 2005 17:52:14 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPHYU7YRFY97B8WF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Jun 2005 17:52:04 +1000 Received: by localhost (Postfix, from userid 510) id 69BE1AB543; Wed, 15 Jun 2005 17:52:04 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by moe.its.monash.edu.au (Postfix) with ESMTP id A020B4FB07 for ; Wed, 15 Jun 2005 17:52:02 +1000 (EST) Received: by rproxy.gmail.com with SMTP id b11so680869rne for ; Wed, 15 Jun 2005 00:52:01 -0700 (PDT) Received: by 10.38.24.21 with SMTP id 21mr1914780rnx; Wed, 15 Jun 2005 00:52:01 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Wed, 15 Jun 2005 00:52:01 -0700 (PDT) Date: Wed, 15 Jun 2005 13:22:01 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA Protocol vs. Protocol 2 In-reply-to: <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: "Soohong Daniel Park@samsung.com" , JinHyeock Choi , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Reply-to: Syam Madanapalli Message-id: <10e14db205061500523dcce13b@mail.gmail.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_viKYB9Eti2Lx/zvZ2hWNbg)" DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gdjooDUysIslxYmicGzFYoBVKbZqvrZW6rcUaIADzsEPHs8M0CXIBrSQ8/VNuTBZsYD3CY0BC3vyJ1kAXQE+yyN2dhL15y9pc17S2Lh0HiKMWCv7a5Of2NzXSUozts28DwZg/Q1c7bp2/nFYkZqTdcxM+VK/Lgyz+fqxU36Agek= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <000c01c570d3$19842c30$6cc6dba8@daniel> <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> --Boundary_(ID_viKYB9Eti2Lx/zvZ2hWNbg) Content-type: text/plain; charset=ISO-8859-1 Content-disposition: inline Content-Transfer-Encoding: 7BIT I think it is better to split the DNAv6 draft into three 1. Link Identification 2. Fast RA 3. DNA Procedure or Operation This way it is easy to understand and implement. This will also help WG to better understand about each method that is solving a particular problem. -Syam --Boundary_(ID_viKYB9Eti2Lx/zvZ2hWNbg) Content-type: text/html; charset=ISO-8859-1 Content-disposition: inline Content-Transfer-Encoding: 7BIT
 
I think it is better to split the DNAv6 draft into three
1. Link Identification
2. Fast RA
3. DNA Procedure or Operation
 
This way it is easy to understand and implement. This will also
help WG to better understand about each method that is solving
a particular problem.
 
-Syam
--Boundary_(ID_viKYB9Eti2Lx/zvZ2hWNbg)-- From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 15 04:30:30 2005 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 EAA22428 for ; Wed, 15 Jun 2005 04:30:28 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPI06M77XA99LCIR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Jun 2005 18:30:22 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7E05C80002; Wed, 15 Jun 2005 18:30:18 +1000 (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 36C533C004; Wed, 15 Jun 2005 18:30:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5F8U5X15493 for dna-list; Wed, 15 Jun 2005 18:30:05 +1000 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 j5F8U3r15489 for ; Wed, 15 Jun 2005 18:30:04 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPI05XGN8Y94QDXM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Jun 2005 18:29:51 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3BC70AB547; Wed, 15 Jun 2005 18:29:44 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 CA0B54FB06; Wed, 15 Jun 2005 18:29:43 +1000 (EST) Date: Wed, 15 Jun 2005 18:29:43 +1000 From: Brett Pentland Subject: Re: [DNA] DNA Protocol vs. Protocol 2 In-reply-to: <10e14db205061500523dcce13b@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: James Kempf , "Soohong Daniel Park@samsung.com" , JinHyeock Choi , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <42AFE6F7.1040402@eng.monash.edu.au> 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.2-6 (X11/20050513) References: <000c01c570d3$19842c30$6cc6dba8@daniel> <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> <10e14db205061500523dcce13b@mail.gmail.com> Content-Transfer-Encoding: 7BIT All three of these are parts of a DNA solution and to me they are just sections of a single document. Having three separate documents adds overhead, but I don't really see it adding much value. I might make sense to break it into three if we want to be able to pick and choose bits and pieces but then we end up with all sorts of interoperability problems. I think it's better as a single document, and if clarity is a problem, then that probably just indicates that the document needs some reorganisation. Brett. Syam Madanapalli wrote: > > I think it is better to split the DNAv6 draft into three > 1. Link Identification > 2. Fast RA > 3. DNA Procedure or Operation > > This way it is easy to understand and implement. This will also > help WG to better understand about each method that is solving > a particular problem. > > -Syam From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 15 10:56:33 2005 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 KAA24505 for ; Wed, 15 Jun 2005 10:56:32 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPIDMXDCZS99LDIO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 16 Jun 2005 00:56:10 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0C98680004; Thu, 16 Jun 2005 00:56:04 +1000 (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 A16773C009; Thu, 16 Jun 2005 00:56:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5FEtMl19455 for dna-list; Thu, 16 Jun 2005 00:55:22 +1000 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 j5FEtKr19451 for ; Thu, 16 Jun 2005 00:55:20 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPIDLSEZ6C97BIJ7@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 16 Jun 2005 00:55:10 +1000 Received: by localhost (Postfix, from userid 510) id C15C1AB545; Thu, 16 Jun 2005 00:55:09 +1000 (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 D3B404FB0E; Thu, 16 Jun 2005 00:55:07 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j5FEsoPo012773; Wed, 15 Jun 2005 10:54:50 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 0CC361E819F; Wed, 15 Jun 2005 10:46:20 -0400 (EDT) Received: from [150.169.1.186] (dhcp186.Research.Panasonic.COM [150.169.1.186]) by redwood.research.panasonic.com (Postfix) with ESMTP id E1BBB1E819D; Wed, 15 Jun 2005 10:46:19 -0400 (EDT) Date: Wed, 15 Jun 2005 10:55:33 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA Protocol vs. Protocol 2 In-reply-to: <42AFE6F7.1040402@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Syam Madanapalli , James Kempf , "Soohong Daniel Park@samsung.com" , JinHyeock Choi , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <42B04165.1020601@Research.Panasonic.COM> Organization: Panasonic Digital Networking Lab 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 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:52.70016 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) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <000c01c570d3$19842c30$6cc6dba8@daniel> <"048c01c570f6$85bed8f0$01 6115ac"@dcml.docomolabsusa.com> <10e14db205061500523dcce13b@mail.gmail.com> <42AFE6F7.1040402@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT I agree with Brett. The first draft produced by the design team, http://www.ietf.org/internet-drafts/draft-dnadt-dna-discussion-00.txt, discussed different solutions for the two components of DNA (Link Identification and FastRA) individually. Splitting the solution now will be a step backwards. thanks, Sathya Brett Pentland wrote: > All three of these are parts of a DNA solution and to me they are > just sections of a single document. Having three separate documents > adds overhead, but I don't really see it adding much value. > > I might make sense to break it into three if we want to be able to > pick and choose bits and pieces but then we end up with all sorts of > interoperability problems. I think it's better as a single document, > and if clarity is a problem, then that probably just indicates that > the document needs some reorganisation. > > Brett. > > Syam Madanapalli wrote: > >> >> I think it is better to split the DNAv6 draft into three >> 1. Link Identification >> 2. Fast RA >> 3. DNA Procedure or Operation >> >> This way it is easy to understand and implement. This will also >> help WG to better understand about each method that is solving >> a particular problem. >> >> -Syam > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 16 03:17:22 2005 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 DAA21159 for ; Thu, 16 Jun 2005 03:17:18 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPJBVMEAFS97BENW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 16 Jun 2005 17:16:57 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CC64DAB545; Thu, 16 Jun 2005 17:16:36 +1000 (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 83CE34FB0F; Thu, 16 Jun 2005 17:16:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5G7FjU29933 for dna-list; Thu, 16 Jun 2005 17:15:45 +1000 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 j5G7Fir29929 for ; Thu, 16 Jun 2005 17:15:44 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPJBU9P3HG94S62W@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 16 Jun 2005 17:15:31 +1000 Received: by localhost (Postfix, from userid 510) id 94BD780002; Thu, 16 Jun 2005 17:15:31 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id E25A33C011; Thu, 16 Jun 2005 17:15:29 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0II600N8U1HR1V@mailout3.samsung.com>; Thu, 16 Jun 2005 16:15:27 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0II6009JR1HIP0@mmp1.samsung.com>; Thu, 16 Jun 2005 16:15:27 +0900 (KST) Date: Thu, 16 Jun 2005 12:42:39 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA Protocol vs. Protocol 2 Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Syam Madanapalli Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <000701c57242$cd1858a0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <000c01c570d3$19842c30$6cc6dba8@daniel> <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> <10e14db205061500523dcce13b@mail.gmail.com> <42AFE6F7.1040402@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, > All three of these are parts of a DNA solution and to me they are > just sections of a single document. Having three separate documents > adds overhead, but I don't really see it adding much value. What I was thinking is that these three can be used individually, one can implement just Fast RA on routers, may be for other purposes. > > I might make sense to break it into three if we want to be able to > pick and choose bits and pieces but then we end up with all sorts of > interoperability problems. I said 3 drafts but a single solution for now as a solution of the DNA WG. These drafts will address different issues of DNA. There will not multiple solutions that solves the single problem. > I think it's better as a single document, > and if clarity is a problem, then that probably just indicates that > the document needs some reorganisation. This just a thought, everybody feels that single document is good, then it is fine with me. When I read the DNAv6 first I felt it is very complex, as it is solving multiple issues. And may be we can improve the clarity of the document by reorganisation. > > Brett. > > Syam Madanapalli wrote: >> >> I think it is better to split the DNAv6 draft into three >> 1. Link Identification >> 2. Fast RA >> 3. DNA Procedure or Operation >> >> This way it is easy to understand and implement. This will also >> help WG to better understand about each method that is solving >> a particular problem. >> >> -Syam > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 16 04:25:45 2005 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 EAA25293 for ; Thu, 16 Jun 2005 04:25:44 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPJEAO8DPA99LJ7W@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 16 Jun 2005 18:25:18 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EC2BAAB545; Thu, 16 Jun 2005 18:25:13 +1000 (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 8AAE24FB03; Thu, 16 Jun 2005 18:25:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5G8NxK30657 for dna-list; Thu, 16 Jun 2005 18:23:59 +1000 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 j5G8Nvr30653 for ; Thu, 16 Jun 2005 18:23:57 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPJE8QUJCE9AOBZC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 16 Jun 2005 18:23:41 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D138EAB543; Thu, 16 Jun 2005 18:23:40 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 678044FB07; Thu, 16 Jun 2005 18:23:40 +1000 (EST) Date: Thu, 16 Jun 2005 18:23:39 +1000 From: Brett Pentland Subject: Re: [DNA] DNA Protocol vs. Protocol 2 In-reply-to: <000701c57242$cd1858a0$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Syam Madanapalli , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <42B1370B.7050807@eng.monash.edu.au> 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.2-6 (X11/20050513) References: <000c01c570d3$19842c30$6cc6dba8@daniel> <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> <10e14db205061500523dcce13b@mail.gmail.com> <42AFE6F7.1040402@eng.monash.edu.au> <000701c57242$cd1858a0$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Syam Madanapalli wrote: >> I think it's better as a single document, >> and if clarity is a problem, then that probably just indicates that >> the document needs some reorganisation. > > > This just a thought, everybody feels that single document is good, then > it is fine with me. When I read the DNAv6 first I felt it is very complex, > as it is solving multiple issues. > > And may be we can improve the clarity of the document by reorganisation. I'm open to suggestions. What sort of reorganization would help? As it stands, section 3 is an overview and it clearly breaks the problem down into separate sections: 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6 3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6 3.3 Fast Router Advertisment . . . . . . . . . . . . . . . . . 7 Section 5 goes into the details of what each device has to do to solve both problems: 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 11 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 11 5.1.2 Router Configuration Variables . . . . . . . . . . . . 12 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 13 5.1.4 Processing Router Advertisements . . . . . . . . . . . 13 5.1.5 Processing Router Solicitations . . . . . . . . . . . 13 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 15 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 15 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 16 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 16 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 5.2.2 Selection of a Landmark Prefix . . . . . . . . . . . . 17 5.2.3 Sending Router Solicitations . . . . . . . . . . . . . 17 5.2.4 Processing Router Advertisements . . . . . . . . . . . 17 Is this general structure ok (just needing some reorganization within sections)? Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 16 05:28:37 2005 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 FAA00485 for ; Thu, 16 Jun 2005 05:28:35 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPJGHUGMM299LEU6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 16 Jun 2005 19:28:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5707C80004; Thu, 16 Jun 2005 19:28:16 +1000 (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 0DDA33C00E; Thu, 16 Jun 2005 19:28:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5G9Rig31351 for dna-list; Thu, 16 Jun 2005 19:27:44 +1000 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 j5G9Rhr31347 for ; Thu, 16 Jun 2005 19:27:43 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPJGGYR69U97C198@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 16 Jun 2005 19:27:34 +1000 Received: by localhost (Postfix, from userid 510) id 88936AB543; Thu, 16 Jun 2005 19:27:34 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id DF3544FB02; Thu, 16 Jun 2005 19:27:32 +1000 (EST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0II6001H07LV0V@mailout1.samsung.com>; Thu, 16 Jun 2005 18:27:31 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0II6004VC7LMYA@mmp2.samsung.com>; Thu, 16 Jun 2005 18:27:31 +0900 (KST) Date: Thu, 16 Jun 2005 14:54:42 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA Protocol vs. Protocol 2 Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Syam Madanapalli , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <004601c57255$402636c0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <000c01c570d3$19842c30$6cc6dba8@daniel> <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> <10e14db205061500523dcce13b@mail.gmail.com> <42AFE6F7.1040402@eng.monash.edu.au> <000701c57242$cd1858a0$59476c6b@sisodomain.com> <42B1370B.7050807@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Over all the TOC is okay, what I was mentioning is about the content of the sections. > > I'm open to suggestions. What sort of reorganization would help? > > As it stands, section 3 is an overview and it clearly breaks the problem > down into separate sections: > > 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6 > 3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6 > 3.3 Fast Router Advertisment . . . . . . . . . . . . . . . . . 7 Can we describe these 2 completely in this sections? Meaning, can we for example, just replace the Link Identification method with some other approach? > > Section 5 goes into the details of what each device has to do to solve > both problems: > > 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 > 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 11 > 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 11 > 5.1.2 Router Configuration Variables . . . . . . . . . . . . 12 > 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 13 > 5.1.4 Processing Router Advertisements . . . . . . . . . . . 13 > 5.1.5 Processing Router Solicitations . . . . . . . . . . . 13 > 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 15 > 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 15 > 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 16 > 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 16 > 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 > 5.2.2 Selection of a Landmark Prefix . . . . . . . . . . . . 17 > 5.2.3 Sending Router Solicitations . . . . . . . . . . . . . 17 > 5.2.4 Processing Router Advertisements . . . . . . . . . . . 17 > > Is this general structure ok (just needing some reorganization within > sections)? > > Brett. > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 16 23:04:34 2005 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 XAA08471 for ; Thu, 16 Jun 2005 23:04:32 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPKHCUGBNA97BU74@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 17 Jun 2005 13:04:20 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 038B4AB544; Fri, 17 Jun 2005 13:04:04 +1000 (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 B9B714FB03; Fri, 17 Jun 2005 13:04:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5H33AH10136 for dna-list; Fri, 17 Jun 2005 13:03:10 +1000 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 j5H339r10132 for ; Fri, 17 Jun 2005 13:03:09 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPKHBE976I9AOIJK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 17 Jun 2005 13:02:54 +1000 Received: by localhost (Postfix, from userid 510) id 0FFF680004; Fri, 17 Jun 2005 13:02:54 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by larry.its.monash.edu.au (Postfix) with ESMTP id 139663C006 for ; Fri, 17 Jun 2005 13:02:51 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.68.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5H32iKg005564; Thu, 16 Jun 2005 20:02:45 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5H32VL4627118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 16 Jun 2005 20:02:37 -0700 (PDT) Date: Thu, 16 Jun 2005 20:02:57 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Message-id: <42B23D61.9090608@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT James Kempf wrote: > Draft-pentland in Section 5.2.3 says this: > > Hosts MUST include a tentative source link layer address option > (TSLLAO) in the RS message [13]. The router solicitation message is > sent to the All_Routers_Multicast address and the source address MUST > be the link local address of the host. > > The router uses the TSLLAO to route back to the host, and the definition of > the TSLLAO means that it won't pollute the neighbor cache if there's a > duplicate. So there should be no effect on the router neighbor cache even if > there is a duplicate, and the router shouldn't send the RS to any other node > even if there is a duplicate because the TSLLAO will allow link routing to > work correctly. This handles the RS not overwriting a previous entry in the routers neighbor cache, but doesn't prevent other hosts on the link (which send a NS for instance) from being polluted. > I considered that, but the problem is that if the addresses are switched to > "Optimistic" . Section 3.3 of draft-ietf-ipv6-optimistic-dad says this about > the "Optimistic" state: > > * (modifies 5.4) As soon as the initial Neighbor Solicitation is > sent, the Optimistic Address is configured on the interface and > available for use immediately. The address MUST be flagged as > 'Optimistic'. > > so what this means to me is that the node would have to send NSes on the > link prior to switching its addresses to Optimistic, even if it is on the > same link, because it doesn't find out that it is on the same link until > after the RA returns. I'm not sure whether the extra traffic overhead on > each move is really necessary or beneficial. There is no technical reason for optimistic DAD to require that the NS be sent before or even after state change AFAIK. Do you see a technical reason? AFAIK The state change says "don't pollute" and the NS is there to find out whether there is a duplicate. Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 17 03:18:55 2005 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 DAA19809 for ; Fri, 17 Jun 2005 03:18:54 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPKQ9E86X89AOI0N@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 17 Jun 2005 17:18:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9955080002; Fri, 17 Jun 2005 17:18:35 +1000 (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 4B2D63C00F; Fri, 17 Jun 2005 17:18:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5H7Hn912812 for dna-list; Fri, 17 Jun 2005 17:17:49 +1000 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 j5H7Hmr12808 for ; Fri, 17 Jun 2005 17:17:48 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPKQ8C9KE097BO3S@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 17 Jun 2005 17:17:44 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A2CB680003; Fri, 17 Jun 2005 17:17:44 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 663473C00F; Fri, 17 Jun 2005 17:17:44 +1000 (EST) Date: Fri, 17 Jun 2005 17:17:43 +1000 From: Brett Pentland Subject: Re: [DNA] [New I-D] FW: I-D ACTION:draft-daniel-dna-fastraopt-00.txt In-reply-to: <00ff01c57073$bff3c0e0$6cc6dba8@daniel> Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <42B27917.3010006@eng.monash.edu.au> 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.2-6 (X11/20050513) References: <00ff01c57073$bff3c0e0$6cc6dba8@daniel> Content-Transfer-Encoding: 7BIT Soohong Daniel Park@samsung.com wrote: > Regarding DT consideration, I didn't know of that since > non-DT guys are not able to see what happen in DT..:-) Regarding this, we have just opened up the design team mailing list archive in case anyone is interested. The archive is at: http://www.ctie.monash.edu.au/warchive/dna-dt Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 17 03:21:33 2005 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 DAA20031 for ; Fri, 17 Jun 2005 03:21:32 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPKQC6WAEU94RIU7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 17 Jun 2005 17:21:21 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D9D09AB544; Fri, 17 Jun 2005 17:20:50 +1000 (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 7E73D4FB07; Fri, 17 Jun 2005 17:20:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5H7Kmq12867 for dna-list; Fri, 17 Jun 2005 17:20:48 +1000 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 j5H7Klr12861 for ; Fri, 17 Jun 2005 17:20:47 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPKQBQNW2M97BOWY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 17 Jun 2005 17:20:29 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1A8F6AB543; Fri, 17 Jun 2005 17:20:29 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (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 DB0D94FB0E; Fri, 17 Jun 2005 17:20:28 +1000 (EST) Date: Fri, 17 Jun 2005 17:20:28 +1000 From: Brett Pentland Subject: [DNA] DNA design team mailing list archive In-reply-to: <42B27917.3010006@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <42B279BC.5030201@eng.monash.edu.au> 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.2-6 (X11/20050513) References: <00ff01c57073$bff3c0e0$6cc6dba8@daniel> <42B27917.3010006@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Oops. Should have given the previous email a relevant subject header. Brett. Brett Pentland wrote: > Soohong Daniel Park@samsung.com wrote: > > >> Regarding DT consideration, I didn't know of that since non-DT guys >> are not able to see what happen in DT..:-) > > > > Regarding this, we have just opened up the design team mailing list > archive in case anyone is interested. > > The archive is at: > > http://www.ctie.monash.edu.au/warchive/dna-dt > > Cheers, > Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 20 12:32:18 2005 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 MAA15675 for ; Mon, 20 Jun 2005 12:32:17 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPPGFIUM0M99LPB1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 21 Jun 2005 02:31:13 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CFBA180002; Tue, 21 Jun 2005 02:31:09 +1000 (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 7F1D73C003; Tue, 21 Jun 2005 02:31:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5KGTdw02652 for dna-list; Tue, 21 Jun 2005 02:29:39 +1000 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 j5KGTcr02648 for ; Tue, 21 Jun 2005 02:29:38 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPPGDKXBRU99LWSI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 21 Jun 2005 02:29:36 +1000 Received: by localhost (Postfix, from userid 510) id F3CD680002; Tue, 21 Jun 2005 02:29:35 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 267483C006; Tue, 21 Jun 2005 02:29:33 +1000 (EST) Date: Mon, 20 Jun 2005 09:30:44 -0700 From: James Kempf Subject: Re: [DNA] DNA Protocol vs. Protocol 2 Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: "Soohong Daniel Park@samsung.com" , JinHyeock Choi , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <00be01c575b5$6aaf7060$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <000c01c570d3$19842c30$6cc6dba8@daniel> <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> <10e14db205061500523dcce13b@mail.gmail.com> Content-Transfer-Encoding: 7BIT I disagree. The problem is that someone wanting to implement the protocol would have to track down each draft and figure out how they fit together. We went through exactly the same debate in the MIP6 bootstrapping DT, and decided against splitting the draft because it would make the task of figuring out how the protocol worked more complicated. It is hard enough just following up on references in IETF documents, by having to do searches on the clumsy IETF Web site, much less having to do the same thing for the protocol spec itself. Now, if the IETF used modern hypertext-based documentation technology, rather than antiquated ASCII files, to publish its specifications, I would have completely the opposite opinion. However, we're stuck with ASCII for now, unfortunately. jak ----- Original Message ----- From: "Syam Madanapalli" To: "James Kempf" Cc: "Soohong Daniel Park@samsung.com" ; "JinHyeock Choi" ; ; Sent: Wednesday, June 15, 2005 12:52 AM Subject: Re: [DNA] DNA Protocol vs. Protocol 2 I think it is better to split the DNAv6 draft into three 1. Link Identification 2. Fast RA 3. DNA Procedure or Operation This way it is easy to understand and implement. This will also help WG to better understand about each method that is solving a particular problem. -Syam From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 20 13:17:41 2005 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 NAA19989 for ; Mon, 20 Jun 2005 13:17:41 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPPI1ZBH5C99LX3R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 21 Jun 2005 03:17:33 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B8FE0AB545; Tue, 21 Jun 2005 03:17:30 +1000 (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 5A8CE4FB04; Tue, 21 Jun 2005 03:17:30 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5KHHIn03222 for dna-list; Tue, 21 Jun 2005 03:17:18 +1000 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 j5KHHGr03218 for ; Tue, 21 Jun 2005 03:17:16 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPPI1HDXMG94SPOT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 21 Jun 2005 03:17:06 +1000 Received: by localhost (Postfix, from userid 510) id A429D80003; Tue, 21 Jun 2005 03:17:06 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 922043C007; Tue, 21 Jun 2005 03:17:04 +1000 (EST) Date: Mon, 20 Jun 2005 10:18:15 -0700 From: James Kempf Subject: Re: [DNA] DNA Protocol vs. Protocol 2 Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli , Brett Pentland Cc: Syam Madanapalli , greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <015f01c575bc$0e6e7ab0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <000c01c570d3$19842c30$6cc6dba8@daniel> <048c01c570f6$85bed8f0$016115ac@dcml.docomolabsusa.com> <10e14db205061500523dcce13b@mail.gmail.com> <42AFE6F7.1040402@eng.monash.edu.au> <000701c57242$cd1858a0$59476c6b@sisodomain.com> <42B1370B.7050807@eng.monash.edu.au> <004601c57255$402636c0$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT > > 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6 > > 3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6 > > 3.3 Fast Router Advertisment . . . . . . . . . . . . . . . . . 7 > > Can we describe these 2 completely in this sections? Meaning, can we > for example, just replace the Link Identification method with some other > approach? > No, I think the protocol needs one link identification method. That means, as difficult and painful as it may seem to the WG, we need to choose between the two drafts. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 20 18:10:34 2005 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 SAA15195 for ; Mon, 20 Jun 2005 18:10:32 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPPS9MOVUK9AON2X@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 21 Jun 2005 08:10:03 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F6D9AB54A; Tue, 21 Jun 2005 08:10:00 +1000 (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 312B34FB08; Tue, 21 Jun 2005 08:10:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5KM9AM06370 for dna-list; Tue, 21 Jun 2005 08:09:10 +1000 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 j5KM9Ar06366 for ; Tue, 21 Jun 2005 08:09:10 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPPS8FZUCM9AON2X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 21 Jun 2005 08:09:03 +1000 Received: by localhost (Postfix, from userid 510) id 49AE7AB545; Tue, 21 Jun 2005 08:09:03 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 54A954FB03 for ; Tue, 21 Jun 2005 08:09:01 +1000 (EST) Date: Mon, 20 Jun 2005 15:10:09 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> Content-Transfer-Encoding: 7BIT > > Draft-pentland in Section 5.2.3 says this: > > > > Hosts MUST include a tentative source link layer address option > > (TSLLAO) in the RS message [13]. The router solicitation message is > > sent to the All_Routers_Multicast address and the source address MUST > > be the link local address of the host. > > > > The router uses the TSLLAO to route back to the host, and the definition of > > the TSLLAO means that it won't pollute the neighbor cache if there's a > > duplicate. So there should be no effect on the router neighbor cache even if > > there is a duplicate, and the router shouldn't send the RS to any other node > > even if there is a duplicate because the TSLLAO will allow link routing to > > work correctly. > > This handles the RS not overwriting a previous entry in the routers > neighbor cache, but doesn't prevent other hosts on the link (which send > a NS for instance) from being polluted. > Right, it would mean suspending NS responses for the duration of the response to the RS. Of course, that's what Optimistic does. > > I considered that, but the problem is that if the addresses are switched to > > "Optimistic" . Section 3.3 of draft-ietf-ipv6-optimistic-dad says this about > > the "Optimistic" state: > > > > * (modifies 5.4) As soon as the initial Neighbor Solicitation is > > sent, the Optimistic Address is configured on the interface and > > available for use immediately. The address MUST be flagged as > > 'Optimistic'. > > > > so what this means to me is that the node would have to send NSes on the > > link prior to switching its addresses to Optimistic, even if it is on the > > same link, because it doesn't find out that it is on the same link until > > after the RA returns. I'm not sure whether the extra traffic overhead on > > each move is really necessary or beneficial. > > There is no technical reason for optimistic DAD to require that the NS > be sent before or even after state change AFAIK. Do you see a technical > reason? > No, but unfortunately the oDAD document doesn't say anything about this. Most implementors of oDAD will probably send it out when the state change to Optimistic happens, because the draft says that, but when combined with DNA, I suspect there may be some confusion unless we make it clear. How about: the node SHOULD avoid sending the NS until after the RS is returned? Note that even if we do change the state to Optimistic, there is still the issue I raised about the node originating packets with a topologically incorrect source address if it has moved to a new IP link. The only way to prevent that from happening is to make the addresses Tentative (and suppress the DAD NS until after the RA returns) until the node actually finds out in the RA whether it actually has moved to a new IP link or not. > AFAIK The state change says "don't pollute" and the NS is there to find > out whether there is a duplicate. > That is the spirit. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 20 20:35:09 2005 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 UAA26076 for ; Mon, 20 Jun 2005 20:35:08 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPPX6EEH0894T2DR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 21 Jun 2005 10:32:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 07DA5AB58D; Tue, 21 Jun 2005 10:30:48 +1000 (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 9869752ECB; Tue, 21 Jun 2005 08:34:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5KMYjY06658 for dna-list; Tue, 21 Jun 2005 08:34:45 +1000 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 j5KMYjr06654 for ; Tue, 21 Jun 2005 08:34:45 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPPT3YE3RE97CIRP@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 21 Jun 2005 08:34:27 +1000 Received: by localhost (Postfix, from userid 510) id 94167AB545; Tue, 21 Jun 2005 08:34:27 +1000 (EST) Received: from borg.st.net.au (zorg.st.net.au [203.16.233.9]) by moe.its.monash.edu.au (Postfix) with ESMTP id 09CCB4FB08 for ; Tue, 21 Jun 2005 08:34:26 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 36D5B3946EC; Tue, 21 Jun 2005 08:34:40 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id 7B7B1394458; Tue, 21 Jun 2005 08:34:39 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id 665FD703392; Tue, 21 Jun 2005 08:34:16 +1000 (EST) X-URL: http://zoic.org/sharkey/ Date: Tue, 21 Jun 2005 08:34:16 +1000 From: "Nick 'Sharkey' Moore" Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Erik Nordmark , dna@eng.monash.edu.au Message-id: <20050620223415.GA21811@zoic.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT On 2005-06-20, James Kempf wrote: > > No, but unfortunately the oDAD document doesn't say anything about this. > Most implementors of oDAD will probably send it out when the state change to > Optimistic happens, because the draft says that, but when combined with DNA, > I suspect there may be some confusion unless we make it clear. G'day James, OptiDAD got a "discuss" from IESG, so there's a last round of revision happening some time Real Soon Now. If there's something you reckon needs clarification, now's the time to discuss it! > Note that even if we do change the state to Optimistic, there is still the > issue I raised about the node originating packets with a topologically > incorrect source address if it has moved to a new IP link. The only way to > prevent that from happening is to make the addresses Tentative (and suppress > the DAD NS until after the RA returns) until the node actually finds out in > the RA whether it actually has moved to a new IP link or not. Yeah, I think the safest thing is to Deprecate any addresses at Link Down, and Tentative/Optimistic them at Link Up. That should allow source address selection to behave correctly in the case of multiple interface devices as well. -----N From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 01:23:19 2005 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 BAA19046 for ; Tue, 21 Jun 2005 01:23:18 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPQ7D4RRO299LOGX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 21 Jun 2005 15:22:49 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 43C7FAB545; Tue, 21 Jun 2005 15:22:43 +1000 (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 DD7834FB03; Tue, 21 Jun 2005 15:22:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5L5M4r11083 for dna-list; Tue, 21 Jun 2005 15:22:04 +1000 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 j5L5M3r11079 for ; Tue, 21 Jun 2005 15:22:03 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPQ7C3LYJA94SX1F@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 21 Jun 2005 15:21:55 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5BB2EAB545; Tue, 21 Jun 2005 15:21:53 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 37B4D4FB05; Tue, 21 Jun 2005 15:21:53 +1000 (EST) Date: Tue, 21 Jun 2005 15:21:52 +1000 From: Greg Daley Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <20050620223415.GA21811@zoic.org> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Nick 'Sharkey' Moore" Cc: James Kempf , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42B7A3F0.5090704@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <20050620223415.GA21811@zoic.org> Content-Transfer-Encoding: 7BIT Hi Nick. Nick 'Sharkey' Moore wrote: > On 2005-06-20, James Kempf wrote: [cut] >>Note that even if we do change the state to Optimistic, there is still the >>issue I raised about the node originating packets with a topologically >>incorrect source address if it has moved to a new IP link. The only way to >>prevent that from happening is to make the addresses Tentative (and suppress >>the DAD NS until after the RA returns) until the node actually finds out in >>the RA whether it actually has moved to a new IP link or not. > > > Yeah, I think the safest thing is to Deprecate any addresses at Link > Down, and Tentative/Optimistic them at Link Up. That should allow > source address selection to behave correctly in the case of multiple > interface devices as well. This may be the safest way (making them deprecated) but may also result in devices having no non-::1 addresses available to applications when they receive a (momentary) link-layer down indication. (Just asking): Is this appropriate behaviour? It would be good to have an applications perspective on this... Perhaps it would be OK in a MIPv6 environment, since there could always be a home address to bind to, even if it's no good for routing to the internet at the moment while all links are down... Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 02:26:15 2005 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 CAA14870 for ; Tue, 21 Jun 2005 02:26:14 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPQ9JUGCBO94T69W@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 21 Jun 2005 16:25:44 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D4186AB543; Tue, 21 Jun 2005 16:25:23 +1000 (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 64E6A4FB06; Tue, 21 Jun 2005 16:25:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5L6Ow811730 for dna-list; Tue, 21 Jun 2005 16:24:58 +1000 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 j5L6Ovr11726 for ; Tue, 21 Jun 2005 16:24:57 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPQ9IHBLOK97CW4L@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 21 Jun 2005 16:24:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7142F80003 for ; Tue, 21 Jun 2005 16:24:17 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 48D3C3C014 for ; Tue, 21 Jun 2005 16:24:17 +1000 (EST) Date: Tue, 21 Jun 2005 16:24:16 +1000 From: Greg Daley Subject: [DNA] [Fwd: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France] Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42B7B290.6030607@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi everyone, Please check the cutoff dates for this IETF. Particular note should be made of changes to procedures starting with this meeting. Greg -------- Original Message -------- Date: Fri, 17 Jun 2005 07:33:37 -0400 From: Margaret Wasserman Subject: Fwd: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France To: int-chairs@ietf.org Hi All, Please make sure that your document authors are aware of the draft cut-off dates for Paris. Margaret >From: ietf-secretariat@ietf.org >Date: Fri, 17 Jun 2005 00:00:02 -0400 > > >There are two (2) Internet-Draft cutoff dates for the 63rd >IETF Meeting in Paris, France: > >July 11th: Cutoff Date for Initial (i.e., version -00) >Internet-Draft Submissions > >All initial Internet-Drafts (version -00) must be submitted by Monday, >July 11th at 9:00 AM ET. As always, all initial submissions with a >filename beginning with "draft-ietf" must be approved by the >appropriate WG Chair before they can be processed or announced. The >Secretariat would appreciate receiving WG Chair approval by Tuesday, >July 5th at 9:00 AM ET. > >July 18th: Cutoff Date for Revised (i.e., version -01 and higher) >Internet-Draft Submissions > >All revised Internet-Drafts (version -01 and higher) must be submitted >by Monday, July 18th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their respective >cutoff dates will not be made available in the Internet-Drafts >directory or announced until on or after Monday, August 1st at 9:00 >AM ET, when Internet-Draft posting resumes. Please do not wait until >the last minute to submit. > >PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or >revised Internet-Draft after their respective cutoff deadlines, then >your document will be retained and posted when Internet-Draft >processing resumes. You will no longer be required to resubmit the >document. > >Thank you for your understanding and cooperation. If you have any >questions or concerns, then please send a message to >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other significant dates >for the 63rd IETF Meeting can be found at >http://www.ietf.org/meetings/cutoff_dates_63.html. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 06:17:42 2005 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 GAA01143 for ; Tue, 21 Jun 2005 06:17:41 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPQHNKVM5O9AOKX6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 21 Jun 2005 20:17:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6850D80004; Tue, 21 Jun 2005 20:17:28 +1000 (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 0FBB23C012; Tue, 21 Jun 2005 20:17:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5LAGpl14171 for dna-list; Tue, 21 Jun 2005 20:16:51 +1000 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 j5LAGpr14167 for ; Tue, 21 Jun 2005 20:16:51 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPQHMLP98Q99LWCB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 21 Jun 2005 20:16:41 +1000 Received: by localhost (Postfix, from userid 510) id 47784AB543; Tue, 21 Jun 2005 20:16:41 +1000 (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 49DEB4FB04 for ; Tue, 21 Jun 2005 20:16:39 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.17.57]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j5LAGZw4018461; Tue, 21 Jun 2005 04:16:35 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5LAGUs2183290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2005 03:16:33 -0700 (PDT) Date: Tue, 21 Jun 2005 03:16:57 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Message-id: <42B7E919.5080000@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT James Kempf wrote: >>There is no technical reason for optimistic DAD to require that the NS >>be sent before or even after state change AFAIK. Do you see a technical >>reason? >> > > > No, but unfortunately the oDAD document doesn't say anything about this. I suspect the oDAD document has no need to say anything. It isn't until one tries to combine oDAD with DNA that the issue of separating the optimistic state change and the sending of the NS appears. > Most implementors of oDAD will probably send it out when the state change to > Optimistic happens, because the draft says that, but when combined with DNA, > I suspect there may be some confusion unless we make it clear. Agreed. > How about: the node SHOULD avoid sending the NS until after the RS is > returned? Or. more generally, until it has determined that it has moved to a new link. If an RS is returned which indicates that it didn't move, then there is no need to send an RS. > Note that even if we do change the state to Optimistic, there is still the > issue I raised about the node originating packets with a topologically > incorrect source address if it has moved to a new IP link. The only way to > prevent that from happening is to make the addresses Tentative (and suppress > the DAD NS until after the RA returns) until the node actually finds out in > the RA whether it actually has moved to a new IP link or not. Originating such packets is ok I think. If the host has moved to a new link it will not receive any "replies". It might make sense and assume that it didn't move in this case until it's discovered that it did move. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 11:41:49 2005 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 LAA01959 for ; Tue, 21 Jun 2005 11:41:48 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPQSYUBARQ9AOMW0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 01:41:09 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B23AE80003; Wed, 22 Jun 2005 01:41:07 +1000 (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 5F8B63C010; Wed, 22 Jun 2005 01:41:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5LFeHI17508 for dna-list; Wed, 22 Jun 2005 01:40:17 +1000 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 j5LFeGr17504 for ; Wed, 22 Jun 2005 01:40:16 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPQSXOZ4MY94T1IU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 01:40:12 +1000 Received: by localhost (Postfix, from userid 510) id 40AB8AB543; Wed, 22 Jun 2005 01:40:12 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 74B3C4FB02 for ; Wed, 22 Jun 2005 01:40:10 +1000 (EST) Date: Tue, 21 Jun 2005 08:41:17 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: "Nick 'Sharkey' Moore" Cc: Erik Nordmark , dna@eng.monash.edu.au Message-id: <04f701c57677$ae532ec0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <20050620223415.GA21811@zoic.org> Content-Transfer-Encoding: 7BIT > OptiDAD got a "discuss" from IESG, so there's a last round > of revision happening some time Real Soon Now. If there's something > you reckon needs clarification, now's the time to discuss it! > I'll take another look at the draft and see if I can come up with some suggested changes. Where should I send them? > Yeah, I think the safest thing is to Deprecate any addresses at Link > Down, and Tentative/Optimistic them at Link Up. That should allow > source address selection to behave correctly in the case of multiple > interface devices as well. > The problem with Deprecated is that any apps with such addresses active still continue to send on the address, though new socket connections will not be opened, so new connections will favor interfaces with Confirmed addresses. I suppose one could take the position that this is OK, and it is up to some additional mechanism (seamless handover support?, buffering in the IP stack while the link transition is occuring?) to handle this problem; that is, it is outside the scope of DNA to handle it. jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 12:48:49 2005 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 MAA07101 for ; Tue, 21 Jun 2005 12:48:48 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPQVBC0WKI9AOLYP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 02:48:32 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C4E8C80003; Wed, 22 Jun 2005 02:48:27 +1000 (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 7A55F3C019; Wed, 22 Jun 2005 02:48:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5LGjGU18275 for dna-list; Wed, 22 Jun 2005 02:45:16 +1000 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 j5LGjFr18271 for ; Wed, 22 Jun 2005 02:45:15 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPQV73TPOY99M4JW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 02:45:03 +1000 Received: by localhost (Postfix, from userid 510) id 86FD2AB543; Wed, 22 Jun 2005 02:45:03 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id A62134FB0A for ; Wed, 22 Jun 2005 02:45:01 +1000 (EST) Date: Tue, 21 Jun 2005 09:46:07 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> Content-Transfer-Encoding: 7BIT > Or. more generally, until it has determined that it has moved to a new > link. If an RS is returned which indicates that it didn't move, then > there is no need to send an RS. > You mean "no need to send an NS" I think. Well, there is unfortunately an off chance that, while the host is in transit from one wireless AP to another, someone comes on the link, sends out one NS to DAD an address that the in-transit host had claimed, and gets back no response. The new host would therefore conclude that the address was not a duplicate, but when the in-transit host came back on the link, it would be a duplicate. Considering the low probability of a collision in general (which is what makes oDAD statistically possible in the first place), this case is even more wildly unlikely, but it is still not completely impossible. :-( > > Note that even if we do change the state to Optimistic, there is still the > > issue I raised about the node originating packets with a topologically > > incorrect source address if it has moved to a new IP link. The only way to > > prevent that from happening is to make the addresses Tentative (and suppress > > the DAD NS until after the RA returns) until the node actually finds out in > > the RA whether it actually has moved to a new IP link or not. > > Originating such packets is ok I think. If the host has moved to a new > link it will not receive any "replies". It might make sense and assume > that it didn't move in this case until it's discovered that it did move. > OK. So moving to Optimistic prior to sending the RS rather than to Tentative is probably OK. I think this aligns with what I mentioned in my response to Nick, that handling packets sent to an address while the host is in transit is out of scope for DNA. Do you think making the addresses Deprecated on Link Down is OK, like Nick suggested? This would prevent any new applications from opening sockets on them. If the host is multi-interface, these sockets would be directed to a Confirmed or Optimistic address on another interface, which might or might not be a benefit. jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 18:59:14 2005 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 SAA23566 for ; Tue, 21 Jun 2005 18:59:12 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPR89MEP8Y94SW1E@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 08:59:03 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 729C9AB543; Wed, 22 Jun 2005 08:58:55 +1000 (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 2FCD84FB04; Wed, 22 Jun 2005 08:58:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5LMwhK22402 for dna-list; Wed, 22 Jun 2005 08:58:43 +1000 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 j5LMwgr22398 for ; Wed, 22 Jun 2005 08:58:42 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPR890653E99M2SJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 08:58:25 +1000 Received: by localhost (Postfix, from userid 510) id BBBA0AB546; Wed, 22 Jun 2005 08:58:25 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id DAC0A4FB0A for ; Wed, 22 Jun 2005 08:58:23 +1000 (EST) Date: Tue, 21 Jun 2005 15:59:29 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <074e01c576b4$e5f53390$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> <42B88F4D.8000400@sun.com> Content-Transfer-Encoding: 7BIT > > Well, there is unfortunately an off chance that, while the host is in > > transit from one wireless AP to another, someone comes on the link, sends > > out one NS to DAD an address that the in-transit host had claimed, and gets > > back no response. The new host would therefore conclude that the address was > > not a duplicate, but when the in-transit host came back on the link, it > > would be a duplicate. Considering the low probability of a collision in > > general (which is what makes oDAD statistically possible in the first > > place), this case is even more wildly unlikely, but it is still not > > completely impossible. :-( > > There is also an off chance with a wired Ethernet and hosts that never > move, that when A boots up and sends the NS, the some switch or link is > overloaded so that it drops the single NS, hence B (which has the same > address as A) never sees the NS. > > The point is that DAD was not designed to discover duplicates under any > assumptions; it was designed to be a light-weight mechanism to discover > (infrequently occurring) duplicate address with a reasonable > probability, since without any DAD, should a duplicate exist, it is > quite painful to debug for the user/operator. > OK, sounds fine. Then I guess we can say that the host moves the addresses to Optimistic before it sends the RS, but defers NS until it knows whether or not it is on a new IP link. > > OK. So moving to Optimistic prior to sending the RS rather than to Tentative > > is probably OK. I think this aligns with what I mentioned in my response to > > Nick, that handling packets sent to an address while the host is in transit > > is out of scope for DNA. > > > > Do you think making the addresses Deprecated on Link Down is OK, like Nick > > suggested? This would prevent any new applications from opening sockets on > > them. If the host is multi-interface, these sockets would be directed to a > > Confirmed or Optimistic address on another interface, which might or might > > not be a benefit. > > Multihoming is out of scope of RFC 2461 for a good reason :-) > > I actually don't think we want to overload the deprecated or any other > existing state with the notion that an interface is (suspected to be) > not working, or flaky, or high packet loss. I think all those quality > metrics should be captured using a separate mechanism. The the stack, > when it has multiple interfaces to choose from, take those quality > metrics into account. > So then it sounds like we should keep the address state unchanged until the Link Up, and only then change to Optimistic. > My 2 cents, Anybody else have a comment? jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 20:02:42 2005 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 UAA28921 for ; Tue, 21 Jun 2005 20:02:41 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPR6FUI0IU9AOJXH@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 08:06:42 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8C489AB54A; Wed, 22 Jun 2005 08:06:40 +1000 (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 1CBB64FB07; Wed, 22 Jun 2005 08:06:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5LM5pe21841 for dna-list; Wed, 22 Jun 2005 08:05:51 +1000 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 j5LM5or21837 for ; Wed, 22 Jun 2005 08:05:50 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPR6EP4ZUC97DBV1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 08:05:45 +1000 Received: by localhost (Postfix, from userid 510) id 35B28AB543; Wed, 22 Jun 2005 08:05:45 +1000 (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 2AEAA4FB03 for ; Wed, 22 Jun 2005 08:05:42 +1000 (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 j5LM5dw4011853; Tue, 21 Jun 2005 16:05:39 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5LM5aXO431643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2005 15:05:38 -0700 (PDT) Date: Tue, 21 Jun 2005 15:06:05 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Message-id: <42B88F4D.8000400@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT James Kempf wrote: > You mean "no need to send an NS" I think. Oops - yes. > Well, there is unfortunately an off chance that, while the host is in > transit from one wireless AP to another, someone comes on the link, sends > out one NS to DAD an address that the in-transit host had claimed, and gets > back no response. The new host would therefore conclude that the address was > not a duplicate, but when the in-transit host came back on the link, it > would be a duplicate. Considering the low probability of a collision in > general (which is what makes oDAD statistically possible in the first > place), this case is even more wildly unlikely, but it is still not > completely impossible. :-( There is also an off chance with a wired Ethernet and hosts that never move, that when A boots up and sends the NS, the some switch or link is overloaded so that it drops the single NS, hence B (which has the same address as A) never sees the NS. The point is that DAD was not designed to discover duplicates under any assumptions; it was designed to be a light-weight mechanism to discover (infrequently occurring) duplicate address with a reasonable probability, since without any DAD, should a duplicate exist, it is quite painful to debug for the user/operator. > OK. So moving to Optimistic prior to sending the RS rather than to Tentative > is probably OK. I think this aligns with what I mentioned in my response to > Nick, that handling packets sent to an address while the host is in transit > is out of scope for DNA. > > Do you think making the addresses Deprecated on Link Down is OK, like Nick > suggested? This would prevent any new applications from opening sockets on > them. If the host is multi-interface, these sockets would be directed to a > Confirmed or Optimistic address on another interface, which might or might > not be a benefit. Multihoming is out of scope of RFC 2461 for a good reason :-) I actually don't think we want to overload the deprecated or any other existing state with the notion that an interface is (suspected to be) not working, or flaky, or high packet loss. I think all those quality metrics should be captured using a separate mechanism. The the stack, when it has multiple interfaces to choose from, take those quality metrics into account. My 2 cents, Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 21 21:24:01 2005 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 VAA05029 for ; Tue, 21 Jun 2005 21:24:00 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPRD9WZ4PI94SD7G@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 11:23:01 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DD21EAB543; Wed, 22 Jun 2005 11:22:42 +1000 (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 9BC054FB0A; Wed, 22 Jun 2005 11:22:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5M1M0224008 for dna-list; Wed, 22 Jun 2005 11:22:00 +1000 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 j5M1M0r24004 for ; Wed, 22 Jun 2005 11:22:00 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPRD8O822S97DG65@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 11:21:44 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 08066AB544; Wed, 22 Jun 2005 11:21:43 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id E200B4FB09; Wed, 22 Jun 2005 11:21:42 +1000 (EST) Date: Wed, 22 Jun 2005 11:21:36 +1000 From: Greg Daley Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <074e01c576b4$e5f53390$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Erik Nordmark , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42B8BD20.8040401@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> <42B88F4D.8000400@sun.com> <074e01c576b4$e5f53390$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James & Eric, James Kempf wrote: [cut] >> >>Multihoming is out of scope of RFC 2461 for a good reason :-) >> >>I actually don't think we want to overload the deprecated or any other >>existing state with the notion that an interface is (suspected to be) >>not working, or flaky, or high packet loss. I think all those quality >>metrics should be captured using a separate mechanism. The the stack, >>when it has multiple interfaces to choose from, take those quality >>metrics into account. >> > > > So then it sounds like we should keep the address state unchanged until the > Link Up, and only then change to Optimistic. > > >>My 2 cents, > > > Anybody else have a comment? Sounds like a reasonable assumption. Should this be tied to the Link-Up indications, or to the DNA reception and processing of hints? For example, if no link-layer indication is received does the reception of an 'unexpected' RA and subsequent initiation of DNA operations cause Optimistic to be set? I'd guess it's tied to DNA initiation, rather than the Link-Up explicitly. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 22 06:44:02 2005 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 GAA23320 for ; Wed, 22 Jun 2005 06:44:01 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPRWVI0EJG97D7GF@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 20:44:00 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 610CEAB543; Wed, 22 Jun 2005 20:43:45 +1000 (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 1549C4FB09; Wed, 22 Jun 2005 20:43:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5MAh1i29961 for dna-list; Wed, 22 Jun 2005 20:43:01 +1000 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 j5MAh0r29955 for ; Wed, 22 Jun 2005 20:43:00 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPRWU8KH3294TE1T@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 20:42:44 +1000 Received: by localhost (Postfix, from userid 510) id 854FD80004; Wed, 22 Jun 2005 20:42:44 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 2756B3C010; Wed, 22 Jun 2005 20:42:42 +1000 (EST) Received: from p54b39c99.dip0.t-ipconnect.de ([84.179.156.153] helo=[192.168.112.112]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Dl2ge-0003Oq-2t; Wed, 22 Jun 2005 12:42:31 +0200 Date: Wed, 22 Jun 2005 12:42:18 +0200 From: Christian Vogt Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <42B7E919.5080000@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: James Kempf , dna@eng.monash.edu.au, Gregory Daley , Mark Doll , Roland Bless Message-id: <42B9408A.90602@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed 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.0.4 (2005-06-05) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> Content-Transfer-Encoding: 7BIT >>> There is no technical reason for optimistic DAD to require that >>> the NS be sent before or even after state change AFAIK. Do you >>> see a technical reason? >> >> No, but unfortunately the oDAD document doesn't say anything about >> this. > > I suspect the oDAD document has no need to say anything. It isn't > until one tries to combine oDAD with DNA that the issue of separating > the optimistic state change and the sending of the NS appears. Hi Erik, hi all, yes, there ARE scenarios without DNA where you would want to use a tentative/optimistic address before the initial NS is sent. I am actually working on a little draft that identifies some of those situations. Below is the relevant extract. (Credits also go to Greg; we have been discussing some of this before.) In essence: There are (at least) three situations in which having to send the NS implies additional delays: The NS must be preceeded by a MLD Report, and there is a delay of up to 1 second for the MLD Report after interface re-activation in RFC 2462bis. There are two possible solutions: (1) Allow a MN to send the MLD Report without delay (like it may send an RS without delay according to RFC2461bis). (2) Allow the MN to use a tentative/optimistic address before the initial NS is sent. I have proposed the first option on the IPv6 list where folks agreed that this should probably be attended to within the DNA WG. I'm at a conference right now, but will try to wrap the draft up in between. - Christian ++++ 2.3. Situation C --- Routers on the new IP link do not support the TSLLAO for RSs. The mobile node solicits a unicast RA. Soliciting a unicast RA requires the mobile node to send a RS from an optimistic address. - MN sends a MLD Report for an optimistic address. - MN sends a NS for the optimistic address, initiating ODAD. - MN sends a RS from the optimistic address. - MN receives a unicast RA. The MLD Report (step 1) is delayed for up to 1 second (MAX_RTR_SOLICITATION_DELAY) because it is the first message transmitted after (re-) enabling the interface [RFC2462bis]. 2.4. Situation D --- Routers on the new IP link do not support the TSLLAO for RSs, but do send unsolicited multicast RAs every 30ms to 70ms according to rules in [RFC3775]. - MN receives a multicast RA. - MN sends a MLD Report for an optimistic address. - MN sends an initial NS for the optimistic address (ODAD). The MLD Report (step 2) is delayed for two reasons. First, it is the first message transmitted after (re-) enabling the interface. This calls for a delay of up to 1 second (MAX_RTR_SOLICITATION_DELAY) [RFC2462bis]. Second, the MLD Report is sent in response to a multicast RA. This also calls for a delay of up to 1 seconds (MAX_RTR_SOLICITATION_DELAY) [RFC2462bis]. 2.5. Situation E --- Routers on the new IP link do not support the TSLLAO for RSs. The mobile node solicits a multicast RA. The mobile node can send the RS from the unspecified address, eliminating the requirement to initiate ODAD at this point. - MN sends an RS from the unspecified address. - MN receives a multicast RA. - MN sends a MLD Report for an optimistic address. - MN send a NS for the optimistic address, initiating ODAD. The RS (step 1) may be sent immediately, even though this is the first message transmitted after (re-) enabling the interface [RFC2461bis]. The multicast RA (step 2) is delayed for up to 3 seconds (maximum of MAX_RA_DELAY_TIME and MIN_DELAY_BETWEEN_RAS) [RFC2461bis]. The MLD Report (step 3) is delayed for up to 1 second (MAX_RTR_SOLICITATION_DELAY) because it is sent in response to a multicast RA [RFC2462bis]. ++++ -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Erik Nordmark wrote: > James Kempf wrote: > >>> There is no technical reason for optimistic DAD to require that >>> the NS be sent before or even after state change AFAIK. Do you >>> see a technical reason? >>> >> >> >> No, but unfortunately the oDAD document doesn't say anything about >> this. > > > I suspect the oDAD document has no need to say anything. It isn't > until one tries to combine oDAD with DNA that the issue of separating > the optimistic state change and the sending of the NS appears. > >> Most implementors of oDAD will probably send it out when the state >> change to Optimistic happens, because the draft says that, but >> when combined with DNA, I suspect there may be some confusion >> unless we make it clear. > > > Agreed. > >> How about: the node SHOULD avoid sending the NS until after the RS >> is returned? > > > Or. more generally, until it has determined that it has moved to a > new link. If an RS is returned which indicates that it didn't move, > then there is no need to send an RS. > >> Note that even if we do change the state to Optimistic, there is >> still the issue I raised about the node originating packets with a >> topologically incorrect source address if it has moved to a new IP >> link. The only way to prevent that from happening is to make the >> addresses Tentative (and suppress the DAD NS until after the RA >> returns) until the node actually finds out in the RA whether it >> actually has moved to a new IP link or not. > > > Originating such packets is ok I think. If the host has moved to a > new link it will not receive any "replies". It might make sense and > assume that it didn't move in this case until it's discovered that it > did move. > > Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 22 07:45:23 2005 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 HAA28973 for ; Wed, 22 Jun 2005 07:45:22 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPRYZUY7OE9AOM74@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 21:44:35 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 56C1D80002; Wed, 22 Jun 2005 21:44:32 +1000 (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 147DD3C019; Wed, 22 Jun 2005 21:44:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5MBi3X30593 for dna-list; Wed, 22 Jun 2005 21:44:03 +1000 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 j5MBi0r30589 for ; Wed, 22 Jun 2005 21:44:00 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPRYYWVY7C94TABP@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 21:43:46 +1000 Received: by localhost (Postfix, from userid 510) id A5136AB543; Wed, 22 Jun 2005 21:43:46 +1000 (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 BA89A4FB0D; Wed, 22 Jun 2005 21:43:44 +1000 (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 j5MBhfFF013865; Wed, 22 Jun 2005 04:43:41 -0700 (PDT) Received: from [129.159.101.108] (d-eesp02-101-108.Finland.Sun.COM [129.159.101.108]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5MBhZIk202881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2005 04:43:37 -0700 (PDT) Date: Wed, 22 Jun 2005 04:44:05 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction In-reply-to: <42B8BD20.8040401@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: James Kempf , dna@eng.monash.edu.au Message-id: <42B94F05.6030805@sun.com> 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.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> <42B88F4D.8000400@sun.com> <074e01c576b4$e5f53390$016115ac@dcml.docomolabsusa.com> <42B8BD20.8040401@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Should this be tied to the Link-Up indications, or to the DNA reception > and processing of hints? > > For example, if no link-layer indication is received does the > reception of an 'unexpected' RA and subsequent initiation of > DNA operations cause Optimistic to be set? > > I'd guess it's tied to DNA initiation, rather than the Link-Up > explicitly. Things wouldn't work safely from a DAD perspective if there is no link-up notification. Take an example: 1. Host moves and attaches to link B (no link-up notification) 2. Host receives a NS for it's link-local address. It responds since it isn't aware that it might have moved to a different link. 3. Host receives an unsolicited RA, which has some 'unexpected' things in it (e.g., only unknown prefixes). This triggers DNA; move addresses to optimistic state and send RS. The issue is that if the link-local address is a duplicate on the new link, then at #2 the host would mess up things for the existing user of that link-local address on the new link. So things can't be very robust without a link-up notification. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 22 09:00:00 2005 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 IAA05759 for ; Wed, 22 Jun 2005 08:59:59 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS1LHOI5Q99M7B4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 22 Jun 2005 22:59:17 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A0BE3AB543; Wed, 22 Jun 2005 22:59:14 +1000 (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 557BF4FB08; Wed, 22 Jun 2005 22:59:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5MCwYL31440 for dna-list; Wed, 22 Jun 2005 22:58:34 +1000 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 j5MCwVr31436 for ; Wed, 22 Jun 2005 22:58:31 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS1K9ZG7A99M6PR@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 22 Jun 2005 22:58:16 +1000 Received: by localhost (Postfix, from userid 510) id 19396AB544; Wed, 22 Jun 2005 22:58:16 +1000 (EST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (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 20F624FB03; Wed, 22 Jun 2005 22:58:14 +1000 (EST) Received: from [129.6.50.9] (scorpion.antd.nist.gov [129.6.50.9]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j5MCw3E5029443; Wed, 22 Jun 2005 08:58:03 -0400 Date: Wed, 22 Jun 2005 08:56:43 -0400 From: Nicolas Montavont Subject: [DNA] Re: Going forward with draft-ietf-dna-link-information In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au, Bernard Aboba Cc: Pekka Nikander , Alper Yegin , "'Nicolas Montavont'" , "'Greg Daley'" , "'NJEDJOU Eric RD-RESA-REN'" , noel@dpt-info.u-strasbrg.fr.cnri.reston.va.us, sivav@qualcomm.com Message-id: <42B9600B.4040405@nist.gov> 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: Debian Thunderbird 1.0.2 (X11/20050602) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: montavon@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <011c01c562ec$e6875580$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Hi Bernard and all, I sent this e-mail couple of weeks ago, but it never appeared in the DNA mailing list, sorry about that. Please, consider my replies inline about 802.11 section of link-information draft. [chop] > > > >> 2.3 IEEE 802.11/WiFi >> >> A STA must establish a IEEE >> 802.11 link with an AP in order to send and receive IP packets. >> > > > In > > >> a >> WiFi network that supports Robust Secure Network (RSN >> [IEEE-802.11i]), successful completion of 4-way handshake between >> the >> STA and AP commences the availability of IP service. The link up >> event notification must be generated upon this event. In >> non-RSN-based networks, successful association or re-association >> events on the link-layer must cause a link up notification sent to >> the IP-layer. >> >> As part of the link establishment, Basic Service Set >> > > > Identification > > >> (BSSID) and Service Set Identifier (SSID) associated with the AP >> > > > is > > >> learned by the STA. BSSID is a unique identifier of the AP. Its >> value is set to the MAC address of the AP. >> >> [BA] I would delete the last sentence; an AP may have multiple MAC >> addresses (e.g. on the wired side and on the wireless side). >> > > > > I see, OK. > > As this is the default configuration of APs, wouldn't it be valuable to keep the following sentence instead: "BSSID is a unique identifier of the AP, usually set to the MAC address of the wireless interface of the AP." > > >> In ad-hoc mode, mobile station (STA) in range may directly >> communicate with others, i.e., without any infrastructure or >> intermediate hop. The set of communicating STAs is called IBSS >> > > > for > > >> Indepedant Basic Service Set. In an IBSS, only station services >> > > > are > > >> Indepedant -> Independent >> >> available, i.e. authentication, deauthentication, privacy and >> > > > MSDU > > >> delivery. STAs do not associate with each other, and therefore >> > > > may > > >> exchange data frames in state 2 (authenticated and not associated) >> or >> even in state 1 (unauthenticated and unassociated) if >> > > > authentication > > >> is not used. >> >> [BA] They can exchange data frames in state 1 only if "To DS" and >> > > > "From > > >> DS" bits are clear. This is not dependent on authentication (e.g. >> State >> 1, not State 2). >> > > > > I'd need to ask co-author Nicolas to look at this. I'm not too familiar > with these details. > > What about this modified text: "In an IBSS, only station services are available, i.e. authentication, deauthentication, privacy and MSDU delivery. STAs do not associate with each other, and therefore may exchange data frames in state 2 (authenticated and not associated) or even in state 1 (unauthenticated and unassociated) if the Distribution System is not used (i.e. "To DS" and "From DS" bits are clear)." > > > >> Although a link up indication can be generated upon >> authentication, one may not be present per latter usage. If >> authentication is performed, a deauthentication event is used for >> generating the link down indication. Concerning the link layer >> identification, both the BSSID (which is a random MAC address >> > > > chosen > > >> by a STA of the IBSS) and SSID may be used to identify a link, but >> not to make any assumptions on the IP network configuration. >> >> [BA] This is a reasonable guess at how it should work, but I'm not >> clear >> that it is strictly correct. If the goal is only for two nodes to >> exchange data frames, this can occur in State 1 without >> > > > authentication. > > >> So if the packets can be exchanged, the link can be "up". Without >> explicit link establishment, whether the link is "up" or "down" >> > > > becomes > > >> dependent on the frame loss, which is non-deterministic. >> >> To clear this up, you might ask Bob O'Hara, editor of 802.11ma. >> > > > > I'm deferring this to Nicolas as well. > > About the Link Up, I agree with you: if two nodes which are in ad-hoc mode, communicate together without using authentication, you won't have a proper Link Up (from my understanding). Should we insist on that point in the draft, by adding few sentences? I guess, we can not propose to use other parameters such as frame loss rate. Otherwise, Beacons are also sent in ad-hoc mode, and it is used to configure the BSSID on nodes. Setting a BSSID could be considered as a link Up, couldn't it? Thank you again for the review. Nicolas From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 22 11:25:59 2005 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 LAA23171 for ; Wed, 22 Jun 2005 11:25:58 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPS6PIGO2297DN00@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 23 Jun 2005 01:25:45 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A5FCAAB543; Thu, 23 Jun 2005 01:25:15 +1000 (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 5E3024FB0F; Thu, 23 Jun 2005 01:25:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5MFOat00621 for dna-list; Thu, 23 Jun 2005 01:24:36 +1000 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 j5MFOar00617 for ; Thu, 23 Jun 2005 01:24:36 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS6OO8BMI9AOMQP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 23 Jun 2005 01:24:35 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2DF7880002; Thu, 23 Jun 2005 01:24:35 +1000 (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 179423C00B; Thu, 23 Jun 2005 01:24:35 +1000 (EST) Received: from [211.28.113.69] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 23 Jun 2005 01:24:35 +1000 Date: Thu, 23 Jun 2005 01:24:35 +1000 From: Greg Daley Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, James Kempf , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) 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 Erik, ----- Original Message ----- [cut] > > I'd guess it's tied to DNA initiation, rather than the Link-Up > > explicitly. > > Things wouldn't work safely from a DAD perspective if there is no > link-up notification. > > Take an example: > 1. Host moves and attaches to link B (no link-up notification) > 2. Host receives a NS for it's link-local address. It responds > since it > isn't aware that it might have moved to a different link. > 3. Host receives an unsolicited RA, which has some 'unexpected' things > in it (e.g., only unknown prefixes). This triggers DNA; move > addresses to optimistic state and send RS. > > The issue is that if the link-local address is a duplicate on the > new > link, then at #2 the host would mess up things for the existing > user of > that link-local address on the new link. > > So things can't be very robust without a link-up notification. Yes, I agree with your point, that link-indications are required. That's not what I was trying to get at though. The DAD doesn't need to be done _directly_ due to the link-indication. It needs to be done because the host thinks it should be doing DNA. The link-indications pass to the DNA module which then (processing the hint) initializes DNA procedures, including marking of the optimistic flag. Perhaps it is a minor nit, but I guess it's not a requirement from the link-indication, rather it is a DNA requirement which also requires link-indications to function correctly. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 22 11:41:04 2005 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 LAA24667 for ; Wed, 22 Jun 2005 11:41:03 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS78KUV7A9AON52@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 23 Jun 2005 01:40:43 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9A1A180006; Thu, 23 Jun 2005 01:40:37 +1000 (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 3B0D13C00B; Thu, 23 Jun 2005 01:40:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5MFeLU00832 for dna-list; Thu, 23 Jun 2005 01:40:21 +1000 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 j5MFeKr00828 for ; Thu, 23 Jun 2005 01:40:20 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS77WMGQY99LX9W@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 23 Jun 2005 01:40:05 +1000 Received: by localhost (Postfix, from userid 510) id 94AF3AB543; Thu, 23 Jun 2005 01:40:05 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id C749A4FB06; Thu, 23 Jun 2005 01:40:04 +1000 (EST) Date: Wed, 22 Jun 2005 08:41:11 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , dna@eng.monash.edu.au Message-id: <005201c57740$d53b6920$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> <42B88F4D.8000400@sun.com> <074e01c576b4$e5f53390$016115ac@dcml.docomolabsusa.com> <42B8BD20.8040401@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > Sounds like a reasonable assumption. > > Should this be tied to the Link-Up indications, or to the DNA reception > and processing of hints? > > For example, if no link-layer indication is received does the > reception of an 'unexpected' RA and subsequent initiation of > DNA operations cause Optimistic to be set? > > I'd guess it's tied to DNA initiation, rather than the Link-Up > explicitly. > Well, there's a couple cases to consider. Case 1: Multicast RA Suppose the host receives a multicast DNA RA, either as a result of failover to multicast mode due to RS overload on the router or simply as a multicast beacon. If the host can conclude that it has not moved to a new IP link, no changes in address state are required. If the host can conclude that it has moved to a new IP link, the old addresses should be Deprecated, the host should form a new link local address, set state to Optimistic, oDAD it, and then form new global unicast addresses, etc., just as if it had moved, even if it didn't get a link event indicating movement (the link event may have failed for some reason). But the host doesn't need to do anything "prior" to sending the RS, because it didn't send one. Case 2: Unsolicted unicast RA This case is pretty unlikely and is probably due to an error (or somebody playing a trick on the host by sending an RS with the victim's link address in the TSLLAO and the victim's link local address as the source address). I'd say in this case the host should be cautious and should issue a unicast DNA RA in order to confirm. But I don't think it should make any changes in its address state machine in this case, because there is no link event indicating a link change. If a link change actually did occur, of course, the addresses need to be reconfigured. How does that sound? jak From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 22 12:12:42 2005 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 MAA27770 for ; Wed, 22 Jun 2005 12:12:41 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS8BF6X8E9AONY2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 23 Jun 2005 02:11:12 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EA256AB543; Thu, 23 Jun 2005 02:11:09 +1000 (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 AC2214FB0D; Thu, 23 Jun 2005 02:11:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5MGAs301176 for dna-list; Thu, 23 Jun 2005 02:10:54 +1000 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 j5MGArr01172 for ; Thu, 23 Jun 2005 02:10:53 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS8AZQWIW9AON5J@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 23 Jun 2005 02:10:49 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6335AAB544; Thu, 23 Jun 2005 02:10:49 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4EDF24FB04; Thu, 23 Jun 2005 02:10:49 +1000 (EST) Received: from [211.28.113.69] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 23 Jun 2005 02:10:49 +1000 Date: Thu, 23 Jun 2005 02:10:49 +1000 From: Greg Daley Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) 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 James, ----- Original Message ----- From: James Kempf Date: Thursday, June 23, 2005 1:41 am Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction > > > Sounds like a reasonable assumption. > > > > Should this be tied to the Link-Up indications, or to the DNA > reception> and processing of hints? > > > > For example, if no link-layer indication is received does the > > reception of an 'unexpected' RA and subsequent initiation of > > DNA operations cause Optimistic to be set? > > > > I'd guess it's tied to DNA initiation, rather than the Link-Up > > explicitly. > > > > Well, there's a couple cases to consider. > > Case 1: Multicast RA > > Suppose the host receives a multicast DNA RA, either as a result > of failover > to multicast mode due to RS overload on the router or simply as a > multicastbeacon. If the host can conclude that it has not moved to > a new IP link, no > changes in address state are required. If the host can conclude > that it has > moved to a new IP link, the old addresses should be Deprecated, > the host > should form a new link local address, set state to Optimistic, > oDAD it, and > then form new global unicast addresses, etc., just as if it had > moved, even > if it didn't get a link event indicating movement (the link event > may have > failed for some reason). But the host doesn't need to do anything > "prior" to > sending the RS, because it didn't send one. It's an interesting point. I'd guess that for non-authoritative link-change RA reception, you'd want to initiate DNA procedures and send RS. If the content of the RA message was enough to go off and configure addresses (or check router trust with SEND), then the RS would be unnecessary, as you say. I'm interested for the hosts document which may need to touch on this (while cutting parts out...). > Case 2: Unsolicted unicast RA > > This case is pretty unlikely and is probably due to an error (or > somebodyplaying a trick on the host by sending an RS with the > victim's link address > in the TSLLAO and the victim's link local address as the source > address).I'd say in this case the host should be cautious and > should issue a unicast > DNA RA in order to confirm. But I don't think it should make any > changes in > its address state machine in this case, because there is no link event > indicating a link change. If a link change actually did occur, of > course,the addresses need to be reconfigured. I guess you mean RS. > How does that sound? Sounds OK, with the caveat that we wouldn't leave out the Link-hints (so we don't have confusion on that point). Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 22 12:46:56 2005 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 MAA01107 for ; Wed, 22 Jun 2005 12:46:55 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPS9IY5IP699LZFM@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 23 Jun 2005 02:46:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0DCB6AB54B; Thu, 23 Jun 2005 02:46:15 +1000 (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 92A494FB05; Thu, 23 Jun 2005 02:46:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5MGjUd01620 for dna-list; Thu, 23 Jun 2005 02:45:30 +1000 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 j5MGjTr01616 for ; Thu, 23 Jun 2005 02:45:29 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPS9HV139A97CQT9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 23 Jun 2005 02:45:23 +1000 Received: by localhost (Postfix, from userid 510) id 2C7CFAB543; Thu, 23 Jun 2005 02:45:23 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 481024FB07; Thu, 23 Jun 2005 02:45:21 +1000 (EST) Date: Wed, 22 Jun 2005 09:46:26 -0700 From: James Kempf Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <00d101c57749$f37fe3d0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <010501c56e26$fa021420$6cc6dba8@daniel> <42ACDB11.3040109@eng.monash.edu.au> <00f901c5703f$9e1a6e30$016115ac@dcml.docomolabsusa.com> <42AE0734.7040807@sun.com> <03e201c5707a$33415d90$016115ac@dcml.docomolabsusa.com> <42B23D61.9090608@sun.com> <042201c575e4$d6b07910$016115ac@dcml.docomolabsusa.com> <42B7E919.5080000@sun.com> <055f01c57680$bd83cc70$016115ac@dcml.docomolabsusa.com> <42B88F4D.8000400@sun.com> <074e01c576b4$e5f53390$016115ac@dcml.docomolabsusa.com> <42B8BD20.8040401@eng.monash.edu.au> <42B94F05.6030805@sun.com> Content-Transfer-Encoding: 7BIT Erik, Yes, I agree, I think we discussed this in the DT. But I think it's still possible that it might be an error case. There two error cases are that the host receives a multicast RA w.o. any Link Up, and the host receives an unsolicited unicast RA w.o. a any Link Up. In a separate email, I proposed a couple ways to handle this, maybe you could take a look at it and comment? It's also possible that the host receives a multicast RA with Link Up, as, for example, if it sends an RS and the router is overloaded, but that case should be covered by the procedure for what to do before sending a DNA RS. jak ----- Original Message ----- From: "Erik Nordmark" To: Cc: "James Kempf" ; Sent: Wednesday, June 22, 2005 4:44 AM Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction > Greg Daley wrote: > > > Should this be tied to the Link-Up indications, or to the DNA reception > > and processing of hints? > > > > For example, if no link-layer indication is received does the > > reception of an 'unexpected' RA and subsequent initiation of > > DNA operations cause Optimistic to be set? > > > > I'd guess it's tied to DNA initiation, rather than the Link-Up > > explicitly. > > Things wouldn't work safely from a DAD perspective if there is no > link-up notification. > > Take an example: > 1. Host moves and attaches to link B (no link-up notification) > 2. Host receives a NS for it's link-local address. It responds since it > isn't aware that it might have moved to a different link. > 3. Host receives an unsolicited RA, which has some 'unexpected' things > in it (e.g., only unknown prefixes). This triggers DNA; move > addresses to optimistic state and send RS. > > The issue is that if the link-local address is a duplicate on the new > link, then at #2 the host would mess up things for the existing user of > that link-local address on the new link. > > So things can't be very robust without a link-up notification. > > Erik > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 23 19:06:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlamL-0007K6-TS for dna-archive@megatron.ietf.org; Thu, 23 Jun 2005 19:06:37 -0400 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 TAA13515 for ; Thu, 23 Jun 2005 19:06:34 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPU13LGCBK9AOQ6Y@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 24 Jun 2005 09:06:28 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 15F5F80004; Fri, 24 Jun 2005 09:06:24 +1000 (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 B80363C011; Fri, 24 Jun 2005 09:06:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5NN21420905 for dna-list; Fri, 24 Jun 2005 09:02:01 +1000 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 j5NN20r20901 for ; Fri, 24 Jun 2005 09:02:01 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPU0XXQ07Y9AOP7A@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 24 Jun 2005 09:01:50 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 682D280002; Fri, 24 Jun 2005 09:01:50 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 F05163C005; Fri, 24 Jun 2005 09:01:49 +1000 (EST) Received: from hsi-kbw-085-216-018-180.hsi.kabelbw.de ([85.216.18.180] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Dlahb-0002Eq-ER; Fri, 24 Jun 2005 01:01:46 +0200 Date: Fri, 24 Jun 2005 01:01:38 +0200 From: Christian Vogt Subject: [DNA] Analysis of IPv6 Relocation Delays Sender: owner-dna@ecselists.eng.monash.edu.au To: DNA Cc: Roland Bless , Mark Doll , Gregory Daley Message-id: <42BB3F52.7000407@tm.uka.de> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=------------enigD49447C63226CFB8FD24FDF2 X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -49.3 (-------------------------------------------------) X-Spam-Status: No This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD49447C63226CFB8FD24FDF2 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, as I had mentioned on this list before, we wrote a little draft on the latency of IPv6 relocation due to delayed MLD Reports. Here is the abstract: Mobile nodes require fast IPv6 relocation. Yet, router discovery, address auto-configuration, and support for TSLLAOs depend on delayed MLD signaling, defeating existing optimizations in many situations. This document identifies problematic situations. It proposes delay relaxations for MLD Reports or use of optimistic addresses prior to the initial Neighbor Solicitation to improve them. Until the draft becomes available at the official repository, you can access it here: http://doc.tm.uka.de/2005/draft-vogt-dna-relocation-00.txt Note that the purpose of this draft is NOT to evolve itself within the DNA WG. Rather, it is supposed to be a basis for a mailing-list discussion and maybe provide some text for existing WG documents. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ --------------enigD49447C63226CFB8FD24FDF2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCuz9WwstEk8gl2rURArJ+AJ9QDcrPjf8+CZ6dvTBiIEP9zllOwQCgsFwG LERkfL69qgCJ5JPS9A99wyQ= =9bXB -----END PGP SIGNATURE----- --------------enigD49447C63226CFB8FD24FDF2-- From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 23 22:06:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dldaa-000670-KY for dna-archive@megatron.ietf.org; Thu, 23 Jun 2005 22:06:40 -0400 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 WAA26126 for ; Thu, 23 Jun 2005 22:06:38 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPU7BZ89AY94TBZW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 24 Jun 2005 12:05:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 603B8AB54A; Fri, 24 Jun 2005 12:04:57 +1000 (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 019944FB10; Fri, 24 Jun 2005 12:04:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5O23uS22837 for dna-list; Fri, 24 Jun 2005 12:03:56 +1000 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 j5O23sr22833 for ; Fri, 24 Jun 2005 12:03:54 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPU7AE1GXC9AON7A@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 24 Jun 2005 12:03:41 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3804AB542; Fri, 24 Jun 2005 12:03:39 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 98A0C4FB02; Fri, 24 Jun 2005 12:03:39 +1000 (EST) Date: Fri, 24 Jun 2005 12:03:39 +1000 From: Greg Daley Subject: [DNA] Re: Analysis of IPv6 Relocation Delays In-reply-to: <42BB3F52.7000407@tm.uka.de> Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt Cc: DNA , Roland Bless , Mark Doll Reply-to: greg.daley@eng.monash.edu.au Message-id: <42BB69FB.9070503@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42BB3F52.7000407@tm.uka.de> Content-Transfer-Encoding: 7BIT Hi Christian, Thanks for the draft, and your efforts in raising this for discussion. This is definitely an important issue. I guess that the primary issue is with regard to snooping switches, since otherwise multicast delivery will succeed. The problem is that a host cannot necessarily know if snooping is in place, when it arrives at a point-of-attachment. Perhaps it would be good to mention this in the draft (referring also to the snoop draft). Thanks Again, Greg Christian Vogt wrote: > Hi everybody, > > as I had mentioned on this list before, we wrote a little draft on the > latency of IPv6 relocation due to delayed MLD Reports. Here is the > abstract: > > Mobile nodes require fast IPv6 relocation. Yet, router discovery, > address auto-configuration, and support for TSLLAOs depend on delayed > MLD signaling, defeating existing optimizations in many situations. > > This document identifies problematic situations. It proposes delay > relaxations for MLD Reports or use of optimistic addresses prior to > the initial Neighbor Solicitation to improve them. > > Until the draft becomes available at the official repository, you can > access it here: > > http://doc.tm.uka.de/2005/draft-vogt-dna-relocation-00.txt > > Note that the purpose of this draft is NOT to evolve itself within the > DNA WG. Rather, it is supposed to be a basis for a mailing-list > discussion and maybe provide some text for existing WG documents. > > Regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 24 10:19:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlp2E-0005H1-Hx for dna-archive@megatron.ietf.org; Fri, 24 Jun 2005 10:19:58 -0400 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 KAA13062 for ; Fri, 24 Jun 2005 10:19:55 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPUWZR8ED099MCLQ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 25 Jun 2005 00:19:39 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 52010AB54B; Sat, 25 Jun 2005 00:19:33 +1000 (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 E58D94FB04; Sat, 25 Jun 2005 00:19:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5OEIXd30541 for dna-list; Sat, 25 Jun 2005 00:18:33 +1000 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 j5OEIWr30537 for ; Sat, 25 Jun 2005 00:18:32 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPUWY61OYS94U2QX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 25 Jun 2005 00:18:17 +1000 Received: by localhost (Postfix, from userid 510) id 3D51AAB543; Sat, 25 Jun 2005 00:18:17 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 B3E854FB02; Sat, 25 Jun 2005 00:18:14 +1000 (EST) Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Dlp0Q-000543-UI; Fri, 24 Jun 2005 16:18:11 +0200 Date: Fri, 24 Jun 2005 16:18:06 +0200 From: Christian Vogt Subject: [DNA] Re: Analysis of IPv6 Relocation Delays In-reply-to: <42BB69FB.9070503@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: DNA , Roland Bless , Mark Doll Message-id: <42BC161E.8040402@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42BB3F52.7000407@tm.uka.de> <42BB69FB.9070503@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg. > I guess that the primary issue is with regard to snooping switches, > since otherwise multicast delivery will succeed. > The problem is that a host cannot necessarily know if snooping > is in place, when it arrives at a point-of-attachment. Right. > Perhaps it would be good to mention this in the draft (referring > also to the snoop draft). Yes, I added this paragraph to the "Brief Analysis" section (for the 01 version). "[*]" is a reference to draft-ietf-magma-snoop-12.txt. ++++ Transmission of MLD Reports can lead to undesired signaling overhead. Furthermore, with respect to router discovery and address auto- configuration, MLD Reports have a benefit only in the presence of snooping switches [*]. The crux is that a mobile node usually does not know a new link's topology at attachment time, so it seems that omission of MLD Reports would become feasible only with appropriate support from the link layer. ++++ Bye, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Greg Daley wrote: > Hi Christian, > > Thanks for the draft, and your efforts in raising this for discussion. > > This is definitely an important issue. > > I guess that the primary issue is with regard to snooping switches, > since otherwise multicast delivery will succeed. > The problem is that a host cannot necessarily know if snooping > is in place, when it arrives at a point-of-attachment. > > Perhaps it would be good to mention this in the draft (referring > also to the snoop draft). > > Thanks Again, > > Greg > > Christian Vogt wrote: > >> Hi everybody, >> >> as I had mentioned on this list before, we wrote a little draft on the >> latency of IPv6 relocation due to delayed MLD Reports. Here is the >> abstract: >> >> Mobile nodes require fast IPv6 relocation. Yet, router discovery, >> address auto-configuration, and support for TSLLAOs depend on delayed >> MLD signaling, defeating existing optimizations in many situations. >> >> This document identifies problematic situations. It proposes delay >> relaxations for MLD Reports or use of optimistic addresses prior to >> the initial Neighbor Solicitation to improve them. >> >> Until the draft becomes available at the official repository, you can >> access it here: >> >> http://doc.tm.uka.de/2005/draft-vogt-dna-relocation-00.txt >> >> Note that the purpose of this draft is NOT to evolve itself within the >> DNA WG. Rather, it is supposed to be a basis for a mailing-list >> discussion and maybe provide some text for existing WG documents. >> >> Regards, >> - Christian >> >> -- >> Christian Vogt, Institute of Telematics, University of Karlsruhe >> www.tm.uka.de/~chvogt/pubkey/ From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 24 19:23:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlxWC-0008Jn-BN for dna-archive@megatron.ietf.org; Fri, 24 Jun 2005 19:23:28 -0400 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 TAA07876 for ; Fri, 24 Jun 2005 19:23:24 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPVFYLRR0E9AOPJE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 25 Jun 2005 09:23:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 03CEE80012; Sat, 25 Jun 2005 09:23:03 +1000 (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 7AA683C0CF; Sat, 25 Jun 2005 09:23:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5ONLoh03969 for dna-list; Sat, 25 Jun 2005 09:21:50 +1000 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 j5ONLnr03965 for ; Sat, 25 Jun 2005 09:21:49 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPVFWX8JOY9AOPC8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 25 Jun 2005 09:21:42 +1000 Received: by localhost (Postfix, from userid 510) id 0703B80010; Sat, 25 Jun 2005 09:21:41 +1000 (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 159E43D6A0 for ; Sat, 25 Jun 2005 05:43:21 +1000 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5OJhHvp009616 for ; Fri, 24 Jun 2005 22:43:18 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Jun 2005 22:43:15 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Jun 2005 14:43:10 -0500 Date: Fri, 24 Jun 2005 12:43:09 -0700 From: Mahesh.Sivakumar@nokia.com Subject: [DNA] optimistic DAD: sending router solicitations Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF01653370853746129B@mvebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: optimistic DAD: sending router solicitations Thread-Index: AcV49PL5NqvR5xVjTTuiUJtePvFn/A== Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 24 Jun 2005 19:43:10.0359 (UTC) FILETIME=[F3902270:01C578F4] Content-Transfer-Encoding: 7BIT Hi, I am studying optimistic DAD and had the following questions. Without optimistic DAD, when DAD completes, the address is configured on the interface and the node starts sending router solicitations. But with Optimistic DAD, the draft suggests that router solicitations MAY be sent from an optimistic address without including the SLLAO option. When optimistic DAD completes, (i) do we have to configure the address on the interface again, (ii) do we stop the router solicitations that were scheduled when optimistic DAD started, and (iii) when we start sending router solicitations (afte Optimistic DAD completes), do we allow a delay or send it right away. Thanks Mahesh From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 24 20:12:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlyHB-00031X-1s for dna-archive@megatron.ietf.org; Fri, 24 Jun 2005 20:12:05 -0400 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 UAA11805 for ; Fri, 24 Jun 2005 20:11:58 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPVHNUPV2G97DSM1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 25 Jun 2005 10:11:48 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 64C29AB543; Sat, 25 Jun 2005 10:11:39 +1000 (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 1BE2E4FB02; Sat, 25 Jun 2005 10:11:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5P0BNh04492 for dna-list; Sat, 25 Jun 2005 10:11:23 +1000 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 j5P0BMr04488 for ; Sat, 25 Jun 2005 10:11:22 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPVHNGA72Q99MEAD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 25 Jun 2005 10:11:20 +1000 Received: by localhost (Postfix, from userid 510) id 14DE2AB542; Sat, 25 Jun 2005 10:11:20 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 28F9A4FB03 for ; Sat, 25 Jun 2005 10:11:17 +1000 (EST) Date: Fri, 24 Jun 2005 17:12:23 -0700 From: James Kempf Subject: Re: [DNA] optimistic DAD: sending router solicitations Sender: owner-dna@ecselists.eng.monash.edu.au To: Mahesh.Sivakumar@nokia.com, dna@eng.monash.edu.au Message-id: <05f401c5791a$9476ee60$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <8A76136424391244A5CF01653370853746129B@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT I think the basic idea is that the host changes the addresses to Optimistic prior to sending the RS after it has detected a link event indicating a link move, and includes TSLLAO in the RS (the latter is already in the draft) so the router can unicast the RA back but the router's neighbor cache doesn't get changed. The host also deferrs oDAD signaling (NA) until after the RA returns. If the RA comes back and the host hasn't changed IP links, it can switch the addressses back to Confirmed. If the RA comes back and the host has changed IP links, the host moves the addresses to Deprecated and configures new addresses on the link as Optimistic and does the oDAD signaling (NA). So the idea is to couple DNA with oDAD in a way that reduces the amount of signaling and allows the host to recover quickly if it hasn't changed IP links. jak ----- Original Message ----- From: To: Sent: Friday, June 24, 2005 12:43 PM Subject: [DNA] optimistic DAD: sending router solicitations > Hi, > I am studying optimistic DAD and had the following questions. > > Without optimistic DAD, when DAD completes, the address is configured on the interface and the node starts sending router solicitations. But with Optimistic DAD, the draft suggests that router solicitations MAY be sent from an optimistic address without including the SLLAO option. When optimistic DAD completes, (i) do we have to configure the address on the interface again, (ii) do we stop the router solicitations that were scheduled when optimistic DAD started, and (iii) when we start sending router solicitations (afte Optimistic DAD completes), do we allow a delay or send it right away. > > Thanks > Mahesh > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 01:17:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmlzt-0005IS-IE for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 01:17:30 -0400 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 BAA18604 for ; Mon, 27 Jun 2005 01:17:27 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPYKWJ626G9AOO9B@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 27 Jun 2005 15:16:35 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 410ADAB545; Mon, 27 Jun 2005 15:16:32 +1000 (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 016564FB02; Mon, 27 Jun 2005 15:16:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5R5EOU09740 for dna-list; Mon, 27 Jun 2005 15:14:24 +1000 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 j5R5EOr09736 for ; Mon, 27 Jun 2005 15:14:24 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPYKTLNWXY9AOOUE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 27 Jun 2005 15:14:10 +1000 Received: by localhost (Postfix, from userid 510) id 9EE0E8000F; Mon, 27 Jun 2005 15:14:10 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 D889F3C010 for ; Mon, 27 Jun 2005 15:14:08 +1000 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DmlwY-00022w-H1 for ; Mon, 27 Jun 2005 07:14:06 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DmlwW-0002Sz-QF; Mon, 27 Jun 2005 07:14:00 +0200 Date: Mon, 27 Jun 2005 07:14:00 +0200 From: Christian Vogt Subject: [DNA] New I-D: draft-vogt-dna-relocation-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: DNA Cc: TM-RO2 Message-id: <42BF8B18.8080203@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Hi everybody, there was recently a discussion [1] on the IPv6 mailing list about recommmended backoff delays for MLD Report messages sent by a MN upon link (re-) attachment. These delays are according to RFC 2462bis. The consent was to move any such mobility-related discussion to DNA. We did a brief analysis on IPv6 relocation delays... - identifying problematic situations, and - proposing delay relaxations for MLD Reports or use of optimistic addresses prior to the initial NS to improve such situations. You find this work here: http://www.ietf.org/internet-drafts/draft-vogt-dna-relocation-00.txt Kind regards, - Christian [1] 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/ From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 01:55:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmmaJ-0002qz-MS for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 01:55:08 -0400 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 BAA21277 for ; Mon, 27 Jun 2005 01:55:05 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPYM8DLO3O99MN9Q@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 27 Jun 2005 15:54:41 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ADE908000F; Mon, 27 Jun 2005 15:54:17 +1000 (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 0FC403C010; Mon, 27 Jun 2005 15:54:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5R5s4V10249 for dna-list; Mon, 27 Jun 2005 15:54:04 +1000 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 j5R5s3r10245 for ; Mon, 27 Jun 2005 15:54:03 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPYM7PQ3Q49AORGL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 27 Jun 2005 15:53:48 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C55B0AB545; Mon, 27 Jun 2005 15:53:47 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id A1ECD4FB0A; Mon, 27 Jun 2005 15:53:47 +1000 (EST) Date: Mon, 27 Jun 2005 15:53:41 +1000 From: Greg Daley Subject: [DNA] DNA and TSLLAO Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: Pekka Nikander Reply-to: greg.daley@eng.monash.edu.au Message-id: <42BF9465.1020707@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear WG, Please be aware that there's some conflict of interest here (being one of the authors of the document), so I'd like to be guided by the WG's opinion. I've been discussing the use of Tentative Source Link-Layer Address Options (TSLLAO)s with some of the people in the DT, and it seems that there's some belief that TSLLAOs are useful for DNA. I'd like to confirm if this is the case on the mailing list, and if so, determine what to do with the existing draft. The draft is: draft-daley-ipv6-tsllao-01.txt It's referenced from draft-pentland-dna-protocol-00.txt, and is relied upon for delivery of unicast fast RAs to Optimistic addresses. There's an experimental implementation of the technology available using RADVD, as well as a partial implementation (doesn't use optimistic DAD) for an RS sender. Do people think it would be useful for this technology to be standardized? If so, where should it go: a) within the DNA solution b) as a separate document within DNA c) ask IPv6 (or another suggested WG) to work on it? At this stage, discussion is encouraged, so that people can devlop opinions over time. If there's significant interest, though, I can tentatively approach the IPv6 chairs for their (early) opinion too. Please tell me what you think, and alternative ideas and opinions are welcome. Greg. From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 05:54:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqKN-0006w3-Fs for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 05:54:55 -0400 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 FAA00790 for ; Mon, 27 Jun 2005 05:54:51 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPYULO3KAS97E7OT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 27 Jun 2005 19:54:35 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5560FAB543; Mon, 27 Jun 2005 19:54:06 +1000 (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 14C224FB06; Mon, 27 Jun 2005 19:54:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5R9rRI12758 for dna-list; Mon, 27 Jun 2005 19:53:27 +1000 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 j5R9rRr12754 for ; Mon, 27 Jun 2005 19:53:27 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPYUKIWQT49AOSN8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 27 Jun 2005 19:53:11 +1000 Received: by localhost (Postfix, from userid 510) id 73EBFAB545; Mon, 27 Jun 2005 19:53:11 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by moe.its.monash.edu.au (Postfix) with ESMTP id 36E994FB03 for ; Mon, 27 Jun 2005 19:53:10 +1000 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2FA7189872; Mon, 27 Jun 2005 12:53:07 +0300 (EEST) Date: Mon, 27 Jun 2005 12:53:17 +0300 From: Jari Arkko Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42BF8B18.8080203@tm.uka.de> Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt Cc: DNA Message-id: <42BFCC8D.1080604@kolumbus.fi> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42BF8B18.8080203@tm.uka.de> Content-Transfer-Encoding: 7BIT Hi Christian, and thanks for writing this draft. Some comments: Technical: > o MN sends a RS with a TSLLAO from the unspecified address. > o MN receives an IPv6-multicast RA by link-layer unicast. > o MN sends a MLD Report for an optimistic address. > o MN send a NS for the optimistic address, initiating ODAD. > > The RS (step 1) may be sent immediately, even though this is the > first message transmitted after (re-) enabling the interface RFC > 2461bis. > > From a standard's perspective, it is debatable whether or not the MLD > Report must be delayed. RFC 2462bis says in section 5.4.2: My belief is that the original delays in IPv6 specifications were written in order to avoid broadcast storms and other similar problems that might occur when, for instance, the electricity is turned on for a large set of nodes after a power failure. Similarly, this can address (in some cases) the wireless movement patterns such as a bus load of people coming to the range of a cell at the same time. But I get worried if its followed blindly, such as in the above scenario where other messages precede MLD signaling anyway. Basically, I believe we need to look at the problem as a whole, and build in safeguards that prevent packet storms. But once they exist in a given situation, that should be sufficient and neither ND nor MLD delays should be needed. Here's what RFC 3775 said about the matter: The Mobile Node SHOULD delay according to the mechanisms specified in RFC 2462 unless the implementation has a behavior that desynchronizes the steps that happen before the DAD in the case that multiple nodes experience handover at the same time. Such desynchronizing behaviors might be due to random delays in the L2 protocols or device drivers, or due to the movement detection mechanism that is used. > It hence seems feasible to eliminate the backoff for MLD Reports when > applied after IPv6 relocation. In particular, both of the following > two conditions would have to be met: > > 1. The mobile node has received a trigger from its local link layer > indicating that interface reattachment has taken place. > 2. The MLD Report is either the first message transmitted on the new > link or it is sent in response to a unicast RA indicating IPv6 > relocation. What does "reattachment" mean, exactly? I believe you mean that an interface which was previously operational has gone down and has now come up again. But the text should be clear about this, to avoid confusion with re-attaching to the same link that you have previously visited. Also, I find it curious that your conditions above don't call for the same de-sync knowledge as the RFC 3775 text did. I'm not sure if it is needed, just pointing out the difference... Editorial: > Mobile nodes require fast IPv6 relocation. Yet, router discovery, > address auto-configuration, and support for TSLLAOs depend on delayed > MLD signaling, defeating existing optimizations in many situations. > > This document identifies problematic situations. It proposes delay > relaxations for MLD Reports or use of optimistic addresses prior to > the initial Neighbor Solicitation to improve them. Remove acronyms from the abstract (TSLLAO, MLD). What's "relocation"? Maybe write the abstract as As mobile nodes move to new links, they need to resume their communications in a timely fashion. To communicate, IPv6 nodes need to complete router discovery, address auto-configuration, and other tasks. Unfortunately, many of these tasks depend on prior completion of the Multicast Listener Discovery (MLD) protocol, which introduces a mandatory delay of up to a second. This document discusses where this can be problematic and proposes some solutions that can alleviate the problem. > relocation delays indentified in section 2. s/indentified/identified/ > IPv6 Neighbor Discovery [1] accellerates router discovery in that it My speller doesn't like the fourth word. Maybe "IPv6 ND [1] allows mobile nodes to forego ..." > accelleration for this, defeating the benefits of the afore-mentioned Same here. Maybe write it simpler as "... can currently not be optimized away, defeating ..." > Both of the following two approaches can eliminate the high IPv6 > relocation delays indentified in section 2. There's three subsections following this. --Jari From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 12:13:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmwEd-00034U-5S for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 12:13:27 -0400 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 MAA07646 for ; Mon, 27 Jun 2005 12:13:19 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZ7SH7Y7U99LCZ1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 02:12:15 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 52F0380010; Tue, 28 Jun 2005 02:12:13 +1000 (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 119EE3C005; Tue, 28 Jun 2005 02:12:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5RGBZ816952 for dna-list; Tue, 28 Jun 2005 02:11:35 +1000 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 j5RGBYr16948 for ; Tue, 28 Jun 2005 02:11:34 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZ7RD2FPE94UG6E@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 02:11:19 +1000 Received: by localhost (Postfix, from userid 510) id 5AC40AB542; Tue, 28 Jun 2005 02:11:19 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 478BD4FB02; Tue, 28 Jun 2005 02:11:17 +1000 (EST) Date: Mon, 27 Jun 2005 09:12:28 -0700 From: James Kempf Subject: Re: [DNA] DNA and TSLLAO Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Cc: Pekka Nikander Message-id: <00bb01c57b33$064c2810$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <42BF9465.1020707@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT I think TSLLAO needs to be folded into the DNA document. I think we should maintain the tradition of defining enhancements to ND based on a link techology with a host MAC address that was started by 2461, and therefore in the general case the router will need the TSLLAO in order to unicast the RA back to host. Other link layer types or corner-case uses of 802 link technologies that don't support MAC addresses on the wireless link (like 802.16) need to be seen as exceptions, to be handled by extension RFCs (like RFC 2491 does for ATM). jak ----- Original Message ----- From: "Greg Daley" To: Cc: "Pekka Nikander" Sent: Sunday, June 26, 2005 10:53 PM Subject: [DNA] DNA and TSLLAO > Dear WG, > > Please be aware that there's some conflict of interest here > (being one of the authors of the document), so I'd like to > be guided by the WG's opinion. > > I've been discussing the use of > Tentative Source Link-Layer Address Options (TSLLAO)s > with some of the people in the DT, and it seems that > there's some belief that TSLLAOs are useful for DNA. > > I'd like to confirm if this is the case on the mailing list, > and if so, determine what to do with the existing draft. > > The draft is: draft-daley-ipv6-tsllao-01.txt > > It's referenced from draft-pentland-dna-protocol-00.txt, > and is relied upon for delivery of unicast fast RAs to > Optimistic addresses. > > There's an experimental implementation of the technology > available using RADVD, as well as a partial implementation > (doesn't use optimistic DAD) for an RS sender. > > Do people think it would be useful for this technology to > be standardized? > > If so, where should it go: > > a) within the DNA solution > > b) as a separate document within DNA > > c) ask IPv6 (or another suggested WG) to work on it? > > At this stage, discussion is encouraged, so that people > can devlop opinions over time. > > If there's significant interest, though, I can tentatively > approach the IPv6 chairs for their (early) opinion too. > > Please tell me what you think, and alternative ideas and > opinions are welcome. > > Greg. From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 12:24:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmwPW-0007S9-4O for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 12:24:38 -0400 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 MAA08740 for ; Mon, 27 Jun 2005 12:24:34 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZ88AZAO29AOR4E@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 02:24:14 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 14388AB54A; Tue, 28 Jun 2005 02:24:12 +1000 (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 B8AA74FB03; Tue, 28 Jun 2005 02:24:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5RGO3b17119 for dna-list; Tue, 28 Jun 2005 02:24:03 +1000 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 j5RGO3r17115 for ; Tue, 28 Jun 2005 02:24:03 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZ87T0LGE97FKOS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 02:23:48 +1000 Received: by localhost (Postfix, from userid 510) id 06006AB542; Tue, 28 Jun 2005 02:23:47 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 8116B4FB04 for ; Tue, 28 Jun 2005 02:23:46 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DmwOd-0002pp-KZ for dna@eng.monash.edu.au; Mon, 27 Jun 2005 12:23:43 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j5RGNfD22926 for ; Mon, 27 Jun 2005 09:23:42 -0700 Date: Mon, 27 Jun 2005 09:23:40 -0700 (PDT) From: Bernard Aboba Subject: [DNA] DNAv4-13 Strawman Available In-reply-to: <00bb01c57b33$064c2810$016115ac@dcml.docomolabsusa.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42BF9465.1020707@eng.monash.edu.au> <00bb01c57b33$064c2810$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT DNAv4 has completed IETF last call and IESG review. The issues that were raised are available here: http://www.drizzle.com/~aboba/DNA/ A strawman version of DNAv4-13 addressing the comments is available here: http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-13.txt Comments/additional issues to me. From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 12:28:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmwSy-0008JX-Bg for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 12:28:12 -0400 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 MAA09091 for ; Mon, 27 Jun 2005 12:28:08 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZ8CLOPDI94TJ1S@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 02:27:46 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E2CAC8000F; Tue, 28 Jun 2005 02:27:39 +1000 (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 8DDD53C005; Tue, 28 Jun 2005 02:27:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5RGRXZ17177 for dna-list; Tue, 28 Jun 2005 02:27:33 +1000 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 j5RGRXr17173 for ; Tue, 28 Jun 2005 02:27:33 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZ8C7RNA094TJ1S@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 02:27:22 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F0BE8000F; Tue, 28 Jun 2005 02:27:21 +1000 (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 2D2843C00C; Tue, 28 Jun 2005 02:27:21 +1000 (EST) Received: from [211.28.184.80] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 28 Jun 2005 02:27:21 +1000 Date: Tue, 28 Jun 2005 02:27:21 +1000 From: Greg Daley Subject: Re: [DNA] DNA and TSLLAO Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au, Pekka Nikander 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 James, Not trying to preempt the rest of the discussion, but asking a clarifying question: ----- Original Message ----- From: James Kempf Date: Tuesday, June 28, 2005 2:12 am Subject: Re: [DNA] DNA and TSLLAO > I think TSLLAO needs to be folded into the DNA document. I think > we should maintain the tradition of defining enhancements to ND > based on a link techology with a host MAC address that was > started by 2461, and therefore in the general case the router will > need the TSLLAO in order to unicast the RA back to host. Other > link layer types or corner-case uses of 802 link > technologies that don't support MAC addresses on the wireless link > (like802.16) need to be seen as exceptions, to be handled by > extension RFCs (like RFC 2491 does for ATM). Just clarifying: if TSLLAO was folded into DNA, then I guess we'd only need the part with RS from an Optimistic address (the part I've already implemented ;-) , without NS or Directed Multicast? Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 14:49:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyfF-0002wU-Vo for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 14:49:02 -0400 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 OAA23629 for ; Mon, 27 Jun 2005 14:48:58 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZD91IYQ899MKO6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 04:48:26 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 03F02AB54A; Tue, 28 Jun 2005 04:48:21 +1000 (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 ABE674FB05; Tue, 28 Jun 2005 04:48:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5RIlfL18915 for dna-list; Tue, 28 Jun 2005 04:47:41 +1000 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 j5RIler18911 for ; Tue, 28 Jun 2005 04:47:40 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZD7WBO5Y9AOQ7D@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 04:47:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AABE5AB542; Tue, 28 Jun 2005 04:47:25 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 962D34FB03; Tue, 28 Jun 2005 04:47:25 +1000 (EST) Received: from [211.28.184.80] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 28 Jun 2005 04:47:25 +1000 Date: Tue, 28 Jun 2005 04:47:25 +1000 From: Greg Daley Subject: [DNA] About draft-ietf-dna-cpl-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: athene@sait.samsung.co.kr, erik.nordmark@sun.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 Dear Erik and JinHyeock, I've recently read through CPL, and am pleased with how it is shaping up. While reading through, I noticed some minor issues which may need to be considered: Section 2.1, 3rd paragraph: "... This works because each and every valid global prefix on a link must not be used on any other link thus the sets of global prefixes on different links must be disjoint. ..." Please consider adding a reference to RFC3513 here, so that people know that there's a reason for this rule. Section 2.2, Third paragraph: "... We also assume that when a host changes its attachment point, the DNA module will be notified of the event using some form of 'link UP' event notification, and that the DNA module determine which RAs arrived before the event and which arrived after the event. This assumption places some requirements on the host implementation, but does not place any assumptions on the layer 2 protocol. ..." Please consider placing a reference (informative) to draft-ietf-dna- link-information Section 2.3, Third Paragraph: "... If the IP stack is notified by the link layer when a new attachment is established (e.g., when associating to a different access point in 802.11), this will serve as such a hint. It helps to reduce the risk that the assignment of an additional prefix to a link will be misinterpreted as being attached to a different link. Note that this hint is merely a local notification and does not require any protocol changes. For instance, in many implementations this would be a notification passed from a link-layer device driver to the IP layer. ..." Please note that The link-information draft describes how the association may not be the best indication of link-up in 802.11 if RSN/802.11i is available. A reference (informative) to draft-ietf-dna-link-information at the end of the paragraph would help here. Second Last paragraph on Page 6 (Section 2.3): "... Otherwise, to make matters certain, the host may need at least to wait for more than the first RAs, or additionally, perform multiple RS/ RA exchanges after the hint. The first level of trying harder is to, after the RS transmission, wait for all RAs that would have been triggered by the RS. The second level of trying harder is to send multiple RSs (and waiting for the resulting RAs). ..." I think that this paragraph needs to be more direct: Suggest: "... Otherwise, to make matters certain, the host may need to attempt further procedures. A first step to clarify link identity is to wait for all RAs which would have been sent in response to the RS. A further step is to send multiple RSs (and wait for the resulting RAs). ..." Third Paragraph of Page 8 (section 3.1): "... To ascertain whether its existing prefix list is complete or not, the host can set its own policy. The host may take into consideration the packet loss rate of the link and the number of RAs it received or should have received from each router while it was attached to the link. Per [1] each router should multicast a RA at least every 1800 seconds. Furthermore, [5] defines a Advertisement Interval option, which the host can use to determine how often it should receive RAs. ..." the packet loss rate for a link which has never been visited is unknown. s/the packet loss rate/the estimated packet loss rate/ Fourth Paragraph of Page 8 (section 3.1): s/For example, the host may keep track of how RAs it has received from/ For example, the host may keep track of how many RAs it has received from/ Section 3.3 paragraph 1: "... When a host receives a hint that indicates a possible link change, it initiates DNA procedure to determine whether it still remains at the same link or not. At this time, the complete prefix generation may or may not be finished. ..." I think that the complete prefix _list_ is to be generated. s/complete prefix generation/complete prefix list generation/ Section 3.3 paragraph 2: "... First, if the host has finished the complete prefix list generation and can be reasonably sure of its completeness, the receipt of a single RA (with at least one valid prefix) is enough to detect the identify of the currently attached link. ..." Two uses of the word complete(ness) in the same sentence. s/identify/identity/ Suggest: "... First, if the host has finished prefix list generation and can be reasonably sure of its completeness, the receipt of a single RA (with at least one valid prefix) is enough to detect the identity of the currently attached link. ..." Section 4.4: After the last paragraph, it is not clear if the link-layer indications reset the number of router solicitations for MAX_RTR_SOLICITATIONS comparison. I'd consider adding the following paragraph. "... Note that if link-layer indications are reliable, a host can reset the number of sent Router Solicitations to 0, while still maintaining RTR_SOLICITATION_INTERVAL between RSs. ..." Page 15 Paragraph 2, Section 4.5: "... Otherwise, if the received RA contains one or more prefixes which is part of the prefix list in some retained Candidate Link object, then the host has most likely moved back to that link. In this case the host will retain the content of the CCL for future matching, but switch the CCL to be that matching object. The, now new, CCL should be updated based on the information in the RA. Then the DNA module informs the Neighbor Discovery module to replace the old information with the information in the new CCL as specified in Section 4.6. ..." s/prefixes which is/prefixes which are/ (since is now a multiple, and non specific) s/part of the existing prefix list/part of an existing prefix list/ (retaining the CCL is a caching operation, should be optional:) s/the host will retain the content/the host may retain the content/ Page 15 Paragraph 2, Section 4.5: "... It is possible that the above comparison will result in matching multiple Candidate Link objects. For example, if the RA contains the prefixes P1 and P2, and there is one Candidate Link object with P1 and P3 and other Candidate Link object with P2 and P4. This should not happen during normal operation, but if links have been renumbered or physically separate links have been made into one link (before the lifetimes in the Candidate Link objects expired), then the host could observe this. The most sensible action would be for the host to merge all such matching Candidate Link objects together with the information in the receive RA and make this the new CCL. Doing this merging correctly probably requires that each Candidate Link object contains the time it was last updated by a RA, so that more recent information can override older information. Note that this case is one reason one needs to be concerned about security issues when Candidate Link objects are shared across multiple interfaces ..." * "The most sensible action would be for " is actually debatable, since this may lead to false detection in the case that existing CCLs hold out-of-date information (if a no-longer present prefix is retained). s/The most sensible action would be for/One possible action would be for/ * If strict ordering for CCL is required, then that reduces the risk of false information being added to the CCL, so we can remove probably: s/merging correctly probably requires/merging correctly requires/ * There's a sentence at the bottom of the paragraph: "Note that this case is one reason ...multiple interfaces" This is inappropriate given the location, and the fact that sharing between interfaces has already been prohibited due to security reasons (which override the later consideration). The sentence should be deleted to ensure that people don't get distracted from the main content. Page 15 Paragraph 4+5, Section 4.5: "... The easy cases of staying on the same link or moving to a previously visited link have been handled above. The harder case is when the first RA after a link UP notification contains prefixes that are new to the host. In this case it isn't obvious whether the host has moved or not, because a new prefix could have been added to the existing link instead of being associated with a different link. In order to distinguish those to cases the host needs to do some extra work. The host handles this by creating a new Candidate Link object which it initializes with the information in the received RA, and makes 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. Then the host waits for more RA messages. At a minimum it waits for 4 seconds, that is, it starts a timer and 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 4 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.) Note that the arrival of a new link UP notification during the 4 second timer must prevent the timer from firing. In this case the host might yet again have moved so it is necessary to restart the process of inspecting the RAs. ..." The first paragraph is incorrect since it forgets (or misstates) when the CCL is complete that any received RA should be treated as from a separate link if there are no prefixes in common with the CCL. Suggested Text (including paragraph boundary movement): "... When the first RA afte a link UP notification contains prefixes which are disjoint from those in the CCL, it may not be immediately obvious whether the host has moved or not. Where the CCL is believed to be complete, though, any advertisement which arrives that does not contain common prefixes with the CCL can be assumed to be a link change in accordance with section 4.6. Otherwise, the host needs to create a new CCL with the new router's advertisement. This CCL should not yet be treated as if it belongs to a new link though, and the operations defined in 4.6 should not yet occur. Instead, the host waits a minimum it waits for 4 seconds, and 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 4 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.) Note that the arrival of a new link UP notification during the 4 second timer must prevent the timer from firing. In this case the host might yet again have moved so it is necessary to restart the process of inspecting the RAs. ..." Page 16 Last paragrpah of section 4.5: "... 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 4 seconds. 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 text needs to be made more direct: s/can try harder than just waiting for 4 seconds./can send Router Solicitations in order to gather information./ Section 5, paragraph 7. s/examplified/exemplified/ Section 11: Open issues. We can discuss these on-list, and attempt to resolve them. All in all though, it looks OK. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 15:40:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzT6-0003yk-RY for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 15:40:33 -0400 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 PAA28569 for ; Mon, 27 Jun 2005 15:40:26 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZF0QEKKK94UJ3O@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 05:39:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3899AB54C; Tue, 28 Jun 2005 05:38:54 +1000 (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 8042A4FB06; Tue, 28 Jun 2005 05:38:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5RJccN19472 for dna-list; Tue, 28 Jun 2005 05:38:38 +1000 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 j5RJcbr19468 for ; Tue, 28 Jun 2005 05:38:37 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZF02FXAA99MQI2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 05:38:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DA21DAB542 for ; Tue, 28 Jun 2005 05:38:22 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 BE0264FB06 for ; Tue, 28 Jun 2005 05:38:21 +1000 (EST) Received: from hsi-kbw-085-216-018-180.hsi.kabelbw.de ([85.216.18.180] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DmzQr-0007xT-21; Mon, 27 Jun 2005 21:38:18 +0200 Date: Mon, 27 Jun 2005 21:38:07 +0200 From: Christian Vogt Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42BFCC8D.1080604@kolumbus.fi> Sender: owner-dna@ecselists.eng.monash.edu.au To: Jari Arkko Cc: DNA , Mark Doll , Roland Bless Message-id: <42C0559F.9080101@tm.uka.de> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=------------enig1A549B5625A88040D58C3152 X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -42.8 (------------------------------------------) X-Spam-Status: No References: <42BF8B18.8080203@tm.uka.de> <42BFCC8D.1080604@kolumbus.fi> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1A549B5625A88040D58C3152 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Jari, thanks for your review and comments. Some responses are inline. > Technical: > >> o MN sends a RS with a TSLLAO from the unspecified address. o MN >> receives an IPv6-multicast RA by link-layer unicast. o MN sends a >> MLD Report for an optimistic address. o MN send a NS for the >> optimistic address, initiating ODAD. >> >> The RS (step 1) may be sent immediately, even though this is the >> first message transmitted after (re-) enabling the interface RFC >> 2461bis. >> >> From a standard's perspective, it is debatable whether or not the >> MLD Report must be delayed. RFC 2462bis says in section 5.4.2: > > > My belief is that the original delays in IPv6 specifications were > written in order to avoid broadcast storms and other similar problems > that might occur when, for instance, the electricity is turned on > for a large set of nodes after a power failure. Similarly, this can > address (in some cases) the wireless movement patterns such as a bus > load of people coming to the range of a cell at the same time. > > But I get worried if its followed blindly, such as in the above > scenario where other messages precede MLD signaling anyway. > Basically, I believe we need to look at the problem as a whole, and > build in safeguards that prevent packet storms. But once they exist > in a given situation, that should be sufficient and neither ND nor > MLD delays should be needed. Here's what RFC 3775 said about the > matter: > >> The Mobile Node SHOULD delay according to the mechanisms specified in >> RFC 2462 unless the implementation has a behavior that >> desynchronizes the steps that happen before the DAD in the case that >> multiple nodes experience handover at the same time. Such >> desynchronizing behaviors might be due to random delays in the L2 >> protocols or device drivers, or due to the movement detection >> mechanism that is used. I do agree that the extent to which desynchonization should be performed is application- and environment-specific. RFC246[12][bis] is tailored towards stationary nodes, so the delays of up to 1s (MAX_RTR_SOLICITATION_DELAY) are acceptable and make sense. But we can't do VoIP for mobile nodes with such delays. The problem is that we cannot necessarily hard-code application- and environment-specific behavior into the nodes simply because we don't know a priori what the applications and environments will be. But maybe there may be a resort: I see a difference between messages for which collision is recoverable and messages for which it is not. E.g., loss of a RS would simply be detected by the mobile node by lack of a responding RA. So in the (unlikely) case that there was a collision, the mobile node loses some time, but will eventually retransmit the RS. OTOH, loss of a MLD Report or NS sent during (O)DAD cannot be detected---because there is no expected response---and might lead to an address duplicate, which is NOT recoverable (in the case of RFC2462[bis]). But MLD Reports and NSs for (O)DAD can be retransmitted in background mode. So an optimistic address would be considered unique only after two, three, or more transmissions of the MLD Report and NS resulted in no response. In addition, there may be plenty of desynchronization delay because we are doing all this in background mode. BTW, this is what draft-vogt-dna-relocation-00 mentions in section 4.3. >> It hence seems feasible to eliminate the backoff for MLD Reports >> when applied after IPv6 relocation. In particular, both of the >> following two conditions would have to be met: >> >> 1. The mobile node has received a trigger from its local link >> layer indicating that interface reattachment has taken place. 2. >> The MLD Report is either the first message transmitted on the new >> link or it is sent in response to a unicast RA indicating IPv6 >> relocation. > > > What does "reattachment" mean, exactly? I believe you mean that an > interface which was previously operational has gone down and has now > come up again. But the text should be clear about this, to avoid > confusion with re-attaching to the same link that you have previously > visited. I agree; the text is unclear. > Also, I find it curious that your conditions above don't call for the > same de-sync knowledge as the RFC 3775 text did. I'm not sure if it > is needed, just pointing out the difference... See above. Maybe it makes sense to send non-critical messages (those for which collision is recoverable) immediately where possible, and to desynchronize and retransmit critical messages in background mode. > Editorial: > [...] Thanks for the additional comments and suggested text passages. I guess there is going to be a 01 version of this draft before Paris. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Jari Arkko wrote: > Hi Christian, > > and thanks for writing this draft. Some comments: > > Technical: > >> o MN sends a RS with a TSLLAO from the unspecified address. >> o MN receives an IPv6-multicast RA by link-layer unicast. >> o MN sends a MLD Report for an optimistic address. >> o MN send a NS for the optimistic address, initiating ODAD. >> >> The RS (step 1) may be sent immediately, even though this is the >> first message transmitted after (re-) enabling the interface RFC >> 2461bis. >> >> From a standard's perspective, it is debatable whether or not the MLD >> Report must be delayed. RFC 2462bis says in section 5.4.2: > > > My belief is that the original delays in IPv6 specifications were > written in order to avoid broadcast storms and other similar > problems that might occur when, for instance, the electricity > is turned on for a large set of nodes after a power failure. Similarly, > this can address (in some cases) the wireless movement patterns > such as a bus load of people coming to the range of a cell at the > same time. > > But I get worried if its followed blindly, such as in the above > scenario where other messages precede MLD signaling anyway. > Basically, I believe we need to look at the problem as a whole, > and build in safeguards that prevent packet storms. But once they > exist in a given situation, that should be sufficient and neither > ND nor MLD delays should be needed. Here's what RFC 3775 said > about the matter: > > The Mobile > Node SHOULD delay according to the mechanisms specified in RFC 2462 > unless the implementation has a behavior that desynchronizes the > steps that happen before the DAD in the case that multiple nodes > experience handover at the same time. Such desynchronizing behaviors > might be due to random delays in the L2 protocols or device drivers, > or due to the movement detection mechanism that is used. > >> It hence seems feasible to eliminate the backoff for MLD Reports when >> applied after IPv6 relocation. In particular, both of the following >> two conditions would have to be met: >> >> 1. The mobile node has received a trigger from its local link layer >> indicating that interface reattachment has taken place. >> 2. The MLD Report is either the first message transmitted on the new >> link or it is sent in response to a unicast RA indicating IPv6 >> relocation. > > > What does "reattachment" mean, exactly? I believe you mean that > an interface which was previously operational has gone down and has > now come up again. But the text should be clear about this, to > avoid confusion with re-attaching to the same link that you have > previously visited. > > Also, I find it curious that your conditions above don't call for > the same de-sync knowledge as the RFC 3775 text did. I'm not sure > if it is needed, just pointing out the difference... > > Editorial: > >> Mobile nodes require fast IPv6 relocation. Yet, router discovery, >> address auto-configuration, and support for TSLLAOs depend on delayed >> MLD signaling, defeating existing optimizations in many situations. >> >> This document identifies problematic situations. It proposes delay >> relaxations for MLD Reports or use of optimistic addresses prior to >> the initial Neighbor Solicitation to improve them. > > > Remove acronyms from the abstract (TSLLAO, MLD). What's > "relocation"? Maybe write the abstract as > > As mobile nodes move to new links, they need to resume their > communications in a timely fashion. To communicate, IPv6 nodes need > to complete router discovery, address auto-configuration, and > other tasks. Unfortunately, many of these tasks depend on prior > completion of the Multicast Listener Discovery (MLD) protocol, > which introduces a mandatory delay of up to a second. This > document discusses where this can be problematic and proposes > some solutions that can alleviate the problem. > >> relocation delays indentified in section 2. > > > s/indentified/identified/ > >> IPv6 Neighbor Discovery [1] accellerates router discovery in that it > > > My speller doesn't like the fourth word. Maybe "IPv6 ND [1] > allows mobile nodes to forego ..." > >> accelleration for this, defeating the benefits of the afore-mentioned > > > Same here. Maybe write it simpler as "... can currently not be optimized > away, defeating ..." > >> Both of the following two approaches can eliminate the high IPv6 >> relocation delays indentified in section 2. > > > There's three subsections following this. > > --Jari --------------enig1A549B5625A88040D58C3152 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwFWjwstEk8gl2rURAjrhAJ99pMfV17YOtoo/+DVxK7BjYg+gKgCfeaa3 +tiok3XMBdDIiWUBc78j6R4= =XQHd -----END PGP SIGNATURE----- --------------enig1A549B5625A88040D58C3152-- From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 15:58:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzki-00012l-8i for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 15:58:44 -0400 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 PAA02320 for ; Mon, 27 Jun 2005 15:58:40 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZFO8M1RC9AOQMI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 05:57:56 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2E990AB543; Tue, 28 Jun 2005 05:57:52 +1000 (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 D8EA44FB07; Tue, 28 Jun 2005 05:57:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5RJvRN19704 for dna-list; Tue, 28 Jun 2005 05:57:27 +1000 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 j5RJvPr19700 for ; Tue, 28 Jun 2005 05:57:25 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZFNG4ENU94UFZE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 05:57:14 +1000 Received: by localhost (Postfix, from userid 510) id 035C9AB542; Tue, 28 Jun 2005 05:57:13 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id F03684FB02; Tue, 28 Jun 2005 05:57:11 +1000 (EST) Date: Mon, 27 Jun 2005 12:58:29 -0700 From: James Kempf Subject: Re: [DNA] DNA and TSLLAO Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au, Pekka Nikander Message-id: <004801c57b52$96880b00$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: Content-Transfer-Encoding: 7BIT Hi Greg, > Just clarifying: if TSLLAO was folded into DNA, then I guess > we'd only need the part with RS from an Optimistic address > (the part I've already implemented ;-) , > without NS or Directed Multicast? > I think we could fold the NS usage into DNA too, since testing for bidirectional reachability could arguably be part of detecting attachment (if you suspect you've lost attachment, this is one way you might want to check). Alternatively, one could view the DNA RS/RA as another way to do attachment checking, and therefore that NS/NA checking isn't necessary, in which case the NS could be dropped. With regard to Directed Multicast, I'm not sure I see a general use for this, can you give some examples? Typically multicast is used when the IP address is undefined. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 17:09:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn0r9-0001sX-MI for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 17:09:28 -0400 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 RAA19442 for ; Mon, 27 Jun 2005 17:09:23 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZI66TEDI94USTL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 07:09:12 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 71FEBAB543; Tue, 28 Jun 2005 07:08:49 +1000 (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 319AF4FB05; Tue, 28 Jun 2005 07:08:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5RL8GR20542 for dna-list; Tue, 28 Jun 2005 07:08:16 +1000 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 j5RL8Fr20528 for ; Tue, 28 Jun 2005 07:08:15 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZI56DDF49AOU06@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 07:08:00 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8819EAB545; Tue, 28 Jun 2005 07:08:00 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 C9E024FB02; Tue, 28 Jun 2005 07:07:59 +1000 (EST) Received: from hsi-kbw-085-216-018-180.hsi.kabelbw.de ([85.216.18.180] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Dn0pd-0002D1-Qm; Mon, 27 Jun 2005 23:07:56 +0200 Date: Mon, 27 Jun 2005 23:07:52 +0200 From: Christian Vogt Subject: Re: [DNA] DNA and TSLLAO In-reply-to: <42BF9465.1020707@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, Pekka Nikander Message-id: <42C06AA8.3060007@tm.uka.de> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=------------enig8129792401C0B0CD5FDFEB92 X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -37.5 (-------------------------------------) X-Spam-Status: No References: <42BF9465.1020707@eng.monash.edu.au> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8129792401C0B0CD5FDFEB92 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Greg, I think TSLLAO is very useful and should be standardized. Further, IMO TSLLAO should be standardized as a stand-alone document. The reason is that TSLLAO can be useful even when the DNA protocol itself is not implemented. "Situation A" and "Situation B" in draft-vogt-dna-relocation-00.txt are two examples. Previous discussions on the IPv6 mailing list have shown that optimizations like TSLLAO are not the kind of thing for which the IPv6 WG is the right place. Folks have repeatedly refered to the DNA WG to handle such optimizations. (See, e.g., the thread starting at [1].) - Christian [1] 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: > Dear WG, > > Please be aware that there's some conflict of interest here > (being one of the authors of the document), so I'd like to > be guided by the WG's opinion. > > I've been discussing the use of > Tentative Source Link-Layer Address Options (TSLLAO)s > with some of the people in the DT, and it seems that > there's some belief that TSLLAOs are useful for DNA. > > I'd like to confirm if this is the case on the mailing list, > and if so, determine what to do with the existing draft. > > The draft is: draft-daley-ipv6-tsllao-01.txt > > It's referenced from draft-pentland-dna-protocol-00.txt, > and is relied upon for delivery of unicast fast RAs to > Optimistic addresses. > > There's an experimental implementation of the technology > available using RADVD, as well as a partial implementation > (doesn't use optimistic DAD) for an RS sender. > > Do people think it would be useful for this technology to > be standardized? > > If so, where should it go: > > a) within the DNA solution > > b) as a separate document within DNA > > c) ask IPv6 (or another suggested WG) to work on it? > > At this stage, discussion is encouraged, so that people > can devlop opinions over time. > > If there's significant interest, though, I can tentatively > approach the IPv6 chairs for their (early) opinion too. > > Please tell me what you think, and alternative ideas and > opinions are welcome. > > Greg. --------------enig8129792401C0B0CD5FDFEB92 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwGqowstEk8gl2rURAklJAJ4gM8x2VQ6V5ZahEUG0yxVMHDgLowCgshUj oQMqYhmJiUCcZ951hImBgtU= =EhTd -----END PGP SIGNATURE----- --------------enig8129792401C0B0CD5FDFEB92-- From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 21:17:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn4ii-0000RF-Pe for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 21:17:01 -0400 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 VAA19924 for ; Mon, 27 Jun 2005 21:16:57 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZQQYOA6294UO80@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 11:15:05 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4EFFDAB545; Tue, 28 Jun 2005 11:14:38 +1000 (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 0900D4FB06; Tue, 28 Jun 2005 11:14:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5S1Dsn23324 for dna-list; Tue, 28 Jun 2005 11:13:54 +1000 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 j5S1Drr23320 for ; Tue, 28 Jun 2005 11:13:53 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZQPQ9OJE97871U@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 11:13:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B02118000D; Tue, 28 Jun 2005 11:13:38 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8CABE3C012; Tue, 28 Jun 2005 11:13:38 +1000 (EST) Date: Tue, 28 Jun 2005 11:13:33 +1000 From: Greg Daley Subject: Re: [DNA] DNA and TSLLAO In-reply-to: <004801c57b52$96880b00$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au, Pekka Nikander Reply-to: greg.daley@eng.monash.edu.au Message-id: <42C0A43D.1080200@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <004801c57b52$96880b00$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Hi Greg, > > >>Just clarifying: if TSLLAO was folded into DNA, then I guess >>we'd only need the part with RS from an Optimistic address >>(the part I've already implemented ;-) , >>without NS or Directed Multicast? >> > > > I think we could fold the NS usage into DNA too, since testing for > bidirectional reachability could arguably be part of detecting attachment > (if you suspect you've lost attachment, this is one way you might want to > check). Alternatively, one could view the DNA RS/RA as another way to do > attachment checking, and therefore that NS/NA checking isn't necessary, in > which case the NS could be dropped. OK, That sounds reasonable. The document's structure's pretty logical due to work by Erik, so it's easy to see where changes would have to be made in either case. > With regard to Directed Multicast, I'm not sure I see a general use for > this, can you give some examples? Typically multicast is used when the IP > address is undefined. Yes. I was wondering if a host may use TSLLAO even though it doesn't have a full Optimistic DAD implementation. In that case, unspecified source addresses would be necessary. Whether it's worthwhile designing in things for hosts which can implement one protocol and not another may be debatable though. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 27 22:52:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6D8-0002f6-QI for dna-archive@megatron.ietf.org; Mon, 27 Jun 2005 22:52:31 -0400 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 WAA26242 for ; Mon, 27 Jun 2005 22:52:27 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZU4QYL0O94UOWB@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 12:51:30 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AC484AB545; Tue, 28 Jun 2005 12:51:15 +1000 (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 6BB934FB12; Tue, 28 Jun 2005 12:51:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5S2oof24480 for dna-list; Tue, 28 Jun 2005 12:50:50 +1000 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 j5S2onr24476 for ; Tue, 28 Jun 2005 12:50:49 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZU446E6O94U4CM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 12:50:45 +1000 Received: by localhost (Postfix, from userid 510) id 3649AAB542; Tue, 28 Jun 2005 12:50:45 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by curly.its.monash.edu.au (Postfix) with ESMTP id 766544FB02 for ; Tue, 28 Jun 2005 12:50:43 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 13so297456nzp for ; Mon, 27 Jun 2005 19:50:42 -0700 (PDT) Received: by 10.36.222.40 with SMTP id u40mr5090700nzg; Mon, 27 Jun 2005 19:50:42 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 27 Jun 2005 19:50:41 -0700 (PDT) Date: Tue, 28 Jun 2005 11:50:41 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA and TSLLAO In-reply-to: <42C06AA8.3060007@tm.uka.de> Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au, Pekka Nikander Reply-to: JinHyeock Choi Message-id: <92e919fb0506271950254a9133@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:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uKpITITnKVnN+jQRWDwzlh7lnvtAPo9+/ZEB1V11HcQS9sCVgpA9mBZvrKONuyDuFCd+uxhy5aUPios6gaRx1cxfO7NjExYOAj85J4DmiaFTCqa729wP8p0c3u3rQNWWr/4TkDoH/4Di8Uds2Z/L4bUb/Xx/nQ7jfJBgXjZjFU0= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42BF9465.1020707@eng.monash.edu.au> <42C06AA8.3060007@tm.uka.de> Content-Transfer-Encoding: 7BIT Dear Christian > I think TSLLAO is very useful and should be standardized. agree. > Further, IMO TSLLAO should be standardized as a stand-alone document. > The reason is that TSLLAO can be useful even when the DNA protocol > itself is not implemented. "Situation A" and "Situation B" in > draft-vogt-dna-relocation-00.txt are two examples. agree. > Previous discussions on the IPv6 mailing list have shown that > optimizations like TSLLAO are not the kind of thing for which the IPv6 > WG is the right place. Folks have repeatedly refered to the DNA WG to > handle such optimizations. (See, e.g., the thread starting at [1].) I prefer TSALLAO to be advanced in IPv6 WG. But in case IPv6 WG is reluctant, I wish DNA WG handles it instead. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 28 00:37:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn7qQ-0006K1-Qh for dna-archive@megatron.ietf.org; Tue, 28 Jun 2005 00:37:10 -0400 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 AAA04253 for ; Tue, 28 Jun 2005 00:37:06 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPZXRCO5B699MQ1N@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 14:35:51 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72417AB54C; Tue, 28 Jun 2005 14:35:46 +1000 (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 243864FB0B; Tue, 28 Jun 2005 14:35:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5S4YtK25597 for dna-list; Tue, 28 Jun 2005 14:34:55 +1000 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 j5S4Ysr25593 for ; Tue, 28 Jun 2005 14:34:54 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LPZXQ56PSG978LAR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 14:34:49 +1000 Received: by localhost (Postfix, from userid 510) id 14A4D8000E; Tue, 28 Jun 2005 14:34:48 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0AE0C3C003 for ; Tue, 28 Jun 2005 14:34:46 +1000 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BECF589801; Tue, 28 Jun 2005 07:34:42 +0300 (EEST) Date: Tue, 28 Jun 2005 07:34:53 +0300 From: Jari Arkko Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42C0559F.9080101@tm.uka.de> Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt Cc: DNA Message-id: <42C0D36D.5060102@kolumbus.fi> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42BFCC8D.1080604@kolumbus.fi> <42C0559F.9080101@tm.uka.de> Content-Transfer-Encoding: 7BIT Christian Vogt wrote: > > I do agree that the extent to which desynchonization should be performed > is application- and environment-specific. RFC246[12][bis] is tailored > towards stationary nodes, so the delays of up to 1s > (MAX_RTR_SOLICITATION_DELAY) are acceptable and make sense. But we > can't do VoIP for mobile nodes with such delays. Right. > The problem is that we cannot necessarily hard-code application- and > environment-specific behavior into the nodes simply because we don't > know a priori what the applications and environments will be. Well, we could have (bad) default behavior and better, optimized behaviour when the stack knows more about what's happening underneath. But I agree that this is not the best possible solution. What you describe below seems to work more universally. > But maybe there may be a resort: > > I see a difference between messages for which collision is recoverable > and messages for which it is not. E.g., loss of a RS would simply be > detected by the mobile node by lack of a responding RA. So in the > (unlikely) case that there was a collision, the mobile node loses some > time, but will eventually retransmit the RS. OTOH, loss of a MLD Report > or NS sent during (O)DAD cannot be detected---because there is no > expected response---and might lead to an address duplicate, which is NOT > recoverable (in the case of RFC2462[bis]). Right. > > But MLD Reports and NSs for (O)DAD can be retransmitted in background > mode. So an optimistic address would be considered unique only after > two, three, or more transmissions of the MLD Report and NS resulted in > no response. In addition, there may be plenty of desynchronization > delay because we are doing all this in background mode. Ok, it makes a lot of sense. Thanks for explaining it. > > > Also, I find it curious that your conditions above don't call for the > > same de-sync knowledge as the RFC 3775 text did. I'm not sure if it > > is needed, just pointing out the difference... > > See above. Maybe it makes sense to send non-critical messages (those > for which collision is recoverable) immediately where possible, and to > desynchronize and retransmit critical messages in background mode. Ok. --Jari From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 28 07:31:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEJc-0002Lf-S0 for dna-archive@megatron.ietf.org; Tue, 28 Jun 2005 07:31:45 -0400 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 HAA24910 for ; Tue, 28 Jun 2005 07:31:42 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQ0CA2M7V2973W3U@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 21:31:14 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04BABAB542; Tue, 28 Jun 2005 21:30:57 +1000 (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 B47554FB06; Tue, 28 Jun 2005 21:30:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5SBTPa30146 for dna-list; Tue, 28 Jun 2005 21:29:25 +1000 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 j5SBTOr30142 for ; Tue, 28 Jun 2005 21:29:24 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ0C7UGF3O9AOUPA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 21:29:09 +1000 Received: by localhost (Postfix, from userid 510) id 64164AB545; Tue, 28 Jun 2005 21:29:09 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id BE1984FB0B for ; Tue, 28 Jun 2005 21:29:07 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IIS00LFTL8HRV@mailout2.samsung.com> for dna@eng.monash.edu.au; Tue, 28 Jun 2005 20:29:05 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IIS00G1JL88RM@mmp2.samsung.com> for dna@eng.monash.edu.au; Tue, 28 Jun 2005 20:29:05 +0900 (KST) Date: Tue, 28 Jun 2005 16:55:54 +0530 From: Syam Madanapalli Subject: [DNA] Implementation of Linkid Prefix Scheme Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: JinHyeock Choi Message-id: <01cb01c57bd4$2c2df620$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Dear DNA WG, We have implemented the Linkid Prefix Scheme. We wrote a code over Linux OS (Kernel 2.4.18) platform. For router side, we added code to RA Daemon (Samsung ISO implementation based on Linux RADVD version 0.7.2) and code lines are 390. For host side, we added code to our own IPv6 stack (SISOv6) and code lines are 160. Right now we are testing its performance. We set two links consisting of three routers respectively and move a host between two links to see how it works. Till now, the host seems to check for link change correctly. More detailed report will be provided later. We also reflected the implementation experience to update the draft, which is available at http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-01.txt Best Regards, Syam From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 28 08:35:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFJM-0002AD-8F for dna-archive@megatron.ietf.org; Tue, 28 Jun 2005 08:35:32 -0400 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 IAA02234 for ; Tue, 28 Jun 2005 08:35:30 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ0EI7JQNG9AOQ6Z@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 22:34:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 861538000F; Tue, 28 Jun 2005 22:34:46 +1000 (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 365F53C005; Tue, 28 Jun 2005 22:34:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5SCYNx30860 for dna-list; Tue, 28 Jun 2005 22:34:23 +1000 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 j5SCYMr30854 for ; Tue, 28 Jun 2005 22:34:22 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQ0EHNN64Y94UJXR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 22:34:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DF33BAB545 for ; Tue, 28 Jun 2005 22:34:19 +1000 (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 CCB6A4FB0A for ; Tue, 28 Jun 2005 22:34:19 +1000 (EST) Received: from [211.28.185.17] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 28 Jun 2005 22:34:19 +1000 Date: Tue, 28 Jun 2005 22:34:19 +1000 From: Greg Daley Subject: [DNA] Early patches for draft-pentland-dna-protocol-00 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <5b6c75f9ab.5f9ab5b6c7@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 Dear WG, Considering Syam's good news about the LinkID implementation, I'd like to pass on some code. Here's a partial implementation for the protocol proposed in: draft-pentland-dna-protocol-00.txt With the modifications discussed in issues on-list. It works on Linux 2.4.8.1 with an unmodified kernel. We've been using Cisco Aironet/350 cards which support wireless events. The host portion is dual-licensed (BSD with one way GPL trapdoor) pair of RS transmission tools, one of which sends a single RS, and another which waits for a Link-UP event from the wireless LAN system: http://www.ctie.monash.edu.au/dna/eventrs0.01.tgz The router portion is a patch against RADVD 0.7.3: http://www.ctie.monash.edu.au/dna/DNARADVD.protocol-00.0.01.patch What's there: Host (Userspace)- :: source address transmission SLLAO transmission TSLLAO transmission Landmark transmission Link-Layer events using Linux Wireless Extensions Router (Radvd/Userspace)- SLLAO processing TSLLAO processing (experimental - bug for many neighbours) Modified RA scheduling algorithm for simultaneous RAs Token Bucket for FastRAs Hash Based Fast RA. Unicast Responses for RAs Landmark Responses CompleteRA What's missing: Host (Userspace)- The response matching on the host dynamic landmark selection for eventrs actually setting interface flags for optimistic (not in scope) SEND (not in scope) Router (Radvd/Userspace)- Strict packet and bounds checking *you've been warned* SEND (not in scope) I'll see if I can come out with an updated version of the host code this week with the response matching component. Instructions: Installation instructions for the RADVD patch are available here: http://www.ctie.monash.edu.au/warchive/dna-dt/2005-05/msg00181.html Please be aware that I've changed the name of the patch to DNARADVD.protocol-00.0.01.patch to avoid confusion about which proposal this covers. Warning: this requires a recent version of OpenSSL, for Hash FastRA. Host: tar xzvf eventrs0.01.tgz cd eventrs0.01 more README.txt su root ./sendrs tap0 -s -t -L 3ffe:8001:0012:0a88 Please note the leading zeros and colons. Happy hacking. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 28 09:48:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGRo-0005MM-Ky for dna-archive@megatron.ietf.org; Tue, 28 Jun 2005 09:48:20 -0400 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 JAA09008 for ; Tue, 28 Jun 2005 09:48:17 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ0H0KTC1K99MRJB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Jun 2005 23:46:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2768D8000F; Tue, 28 Jun 2005 23:46:51 +1000 (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 C5C393C003; Tue, 28 Jun 2005 23:46:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5SDkK431630 for dna-list; Tue, 28 Jun 2005 23:46:20 +1000 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 j5SDkJr31626 for ; Tue, 28 Jun 2005 23:46:19 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ0GZRQ8TO99ML0O@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Jun 2005 23:46:12 +1000 Received: by localhost (Postfix, from userid 510) id 2635C8000F; Tue, 28 Jun 2005 23:46:12 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by larry.its.monash.edu.au (Postfix) with ESMTP id 552113C00B for ; Tue, 28 Jun 2005 23:46:10 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so341665nzd for ; Tue, 28 Jun 2005 06:46:09 -0700 (PDT) Received: by 10.36.222.21 with SMTP id u21mr508506nzg; Tue, 28 Jun 2005 06:46:09 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 28 Jun 2005 06:46:09 -0700 (PDT) Date: Tue, 28 Jun 2005 22:46:09 +0900 From: JinHyeock Choi Subject: Re: [DNA] About draft-ietf-dna-cpl-00.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: athene@sait.samsung.co.kr, erik.nordmark@sun.com, dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb05062806468b021ed@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:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kf33IMSt1kEvTytldueJMhhYlnS6kqGqB4yoj47IqwegPy3I6ft4vnk7zXZAQ1tNUuo6Tw2ppOzQ82COdrKyKEZeuV2wIxIPFOHpDHU4sn6yvORCfycfpwEfQAkp4Ct/V+KbW4w9BzJ1wy/zeIRWLO3v36cZAGizhjh5MUhWrmk= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Dear Greg Thanks for your kind and detailed feedback. I will look through it and reply it in more detail. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jun 29 20:22:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnmpA-0006g9-Gl for dna-archive@megatron.ietf.org; Wed, 29 Jun 2005 20:22:36 -0400 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 UAA14367 for ; Wed, 29 Jun 2005 20:22:34 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ2HH89QME9AOUE8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 30 Jun 2005 10:21:54 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9F8AAAB54D; Thu, 30 Jun 2005 10:21:51 +1000 (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 5466D4FB04; Thu, 30 Jun 2005 10:21:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5U0JwW21867 for dna-list; Thu, 30 Jun 2005 10:19:58 +1000 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 j5U0Jvr21863 for ; Thu, 30 Jun 2005 10:19:57 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQ2HELS6XE94VE1Z@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 30 Jun 2005 10:19:46 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B6D53AB54D; Thu, 30 Jun 2005 10:19:44 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 933904FB02; Thu, 30 Jun 2005 10:19:44 +1000 (EST) Date: Thu, 30 Jun 2005 10:19:43 +1000 From: Greg Daley Subject: [DNA] Lead up to IETF63 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: Pekka Nikander Reply-to: greg.daley@eng.monash.edu.au Message-id: <42C33A9F.3080201@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, In the lead up to IETF 63, Pekka and I would like to focus the working group on issue resolution, in order to progress towards document completion. In that vein, we'll be trying to run the (one) session at Paris focussed on issue resolution. For that we need remaining (and new) issues to be identified beforehand. For the following Working Group documents, it would be good to know which issues are resolved (and how :) draft-ietf-dna-cpl-00 draft-ietf-dna-hosts-00 draft-ietf-dna-link-information-01 draft-ietf-dna-soln-frame-00 draft-narayanan-dna-routers-bcp-00 (accepted) Please update us with the expected submission dates, so we have enough time that the WG can agree to the changes, and attempt to get external review (or closure on existing reviews). If you're an author or editor on one of these drafts, and have tricky issues, or procedural uncertainties in this regard, please don't hesitate to contact Pekka and I. Please be aware that we're not focussing on getting things done for IETF, we're focussing on getting as much done _before_ IETF. This also includes solutions work. Currently there's been some discussion about differences between particular solution flavours. Now's the time to start resolving the remaining issues on-list. There are beginning to be implementations, which should assist that. If we've had a good discussion on-list, it may be possible to consensus call the solution before IETF. This would be good, as then the meeting could be used for outlining and resolving solution specification issues. I know people are working hard on DNA. Let's focus on getting the specifications out. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 30 01:10:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnrK6-0004bI-Gq for dna-archive@megatron.ietf.org; Thu, 30 Jun 2005 01:10:50 -0400 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 BAA10909 for ; Thu, 30 Jun 2005 01:10:49 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQ2RJ4NV6K94UWSB@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 30 Jun 2005 15:10:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 559138000D; Thu, 30 Jun 2005 15:09:43 +1000 (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 178F73C003; Thu, 30 Jun 2005 15:09:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j5U58XJ24894 for dna-list; Thu, 30 Jun 2005 15:08:33 +1000 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 j5U58Xr24890 for ; Thu, 30 Jun 2005 15:08:33 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQ2RHH8BOW97FQ2N@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 30 Jun 2005 15:08:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72061AB543 for ; Thu, 30 Jun 2005 15:08:23 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 242444FB03 for ; Thu, 30 Jun 2005 15:08:23 +1000 (EST) Date: Thu, 30 Jun 2005 15:08:22 +1000 From: Greg Daley Subject: [DNA] Landmark Options variable size? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42C37E46.4050403@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, In my implementation I overlooked the fact that Landmark options are supposed to be 16 octets if the prefix length is less than 64, and 24 octets otherwise. Currently the format for the DNA option is 16 (+1 for plen) octets per prefix, using DNA option variant 1 (http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-05/msg00063.html) Should the existing landmark option format also be fixed size: 24 octets (16 of which are prefix)? There's a possibility we need to revisit the DNAO format because of this. I'd like to get peoples' impressions. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 30 23:45:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCTR-0001np-1r for dna-archive@megatron.ietf.org; Thu, 30 Jun 2005 23:45:53 -0400 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 XAA06789 for ; Thu, 30 Jun 2005 23:45:49 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQ42VZ1W7G97FN62@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 01 Jul 2005 13:45:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A91FD8000D; Fri, 01 Jul 2005 13:45:26 +1000 (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 674CF3C00D; Fri, 01 Jul 2005 13:45:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j613hpD01166 for dna-list; Fri, 01 Jul 2005 13:43:51 +1000 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 j613how01155 for ; Fri, 01 Jul 2005 13:43:50 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ3UAEV4FS99N0DX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 01 Jul 2005 09:39:01 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CFB0EAB543; Fri, 01 Jul 2005 09:38:59 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id ABD994FB02; Fri, 01 Jul 2005 09:38:59 +1000 (EST) Date: Fri, 01 Jul 2005 09:38:59 +1000 From: Greg Daley Subject: Re: [DNA] Lead up to IETF63 In-reply-to: <021601c57dbb$14795720$6401a8c0@sisa.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: dna@eng.monash.edu.au, "'Pekka Nikander'" Reply-to: greg.daley@eng.monash.edu.au Message-id: <42C48293.9090909@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <021601c57dbb$14795720$6401a8c0@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Hi Alper, Thanks for the update. Alper Yegin wrote: > > Re: draft-ietf-dna-link-information-01 > > Most of the issues from Pekka/Bernard reviews and other mailing list > discussions are resolved. I'm waiting for the resolution of some .11 and > 3GPP issues from the co-authors. Meanwhile, the integration of the 802.3 > text is ongoing. I'll submit the I-D next week (with whatever I have at > hand). > > Alper > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 30 23:46:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCTw-0001oM-9u for dna-archive@megatron.ietf.org; Thu, 30 Jun 2005 23:46:24 -0400 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 XAA06828 for ; Thu, 30 Jun 2005 23:46:20 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ42W57D5699MRFX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 01 Jul 2005 13:45:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D1346AB545; Fri, 01 Jul 2005 13:45:34 +1000 (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 8BAB04FB0A; Fri, 01 Jul 2005 13:45:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j613hwG01242 for dna-list; Fri, 01 Jul 2005 13:43:58 +1000 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 j613hww01235 for ; Fri, 01 Jul 2005 13:43:58 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ3PVE8RQ69AOX47@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 01 Jul 2005 07:33:08 +1000 Received: by localhost (Postfix, from userid 510) id 6E493AB543; Fri, 01 Jul 2005 07:33:08 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id ABADE4FB07; Fri, 01 Jul 2005 07:33:06 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IIX0047T2J3RX@mailout3.samsung.com>; Fri, 01 Jul 2005 06:33:03 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IIX00B4Z2J102@mmp1.samsung.com>; Fri, 01 Jul 2005 06:33:03 +0900 (KST) Date: Thu, 30 Jun 2005 14:31:28 -0700 From: Alper Yegin Subject: RE: [DNA] Lead up to IETF63 In-reply-to: <42C33A9F.3080201@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Cc: "'Pekka Nikander'" Message-id: <021601c57dbb$14795720$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Re: draft-ietf-dna-link-information-01 Most of the issues from Pekka/Bernard reviews and other mailing list discussions are resolved. I'm waiting for the resolution of some .11 and 3GPP issues from the co-authors. Meanwhile, the integration of the 802.3 text is ongoing. I'll submit the I-D next week (with whatever I have at hand). Alper > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner- > dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley > Sent: Wednesday, June 29, 2005 5:20 PM > To: dna@eng.monash.edu.au > Cc: Pekka Nikander > Subject: [DNA] Lead up to IETF63 > > Hi, > > > In the lead up to IETF 63, Pekka and I would like to focus > the working group on issue resolution, in order to progress > towards document completion. > > In that vein, we'll be trying to run the (one) session at > Paris focussed on issue resolution. For that we need remaining > (and new) issues to be identified beforehand. > > For the following Working Group documents, it would be > good to know which issues are resolved (and how :) > > draft-ietf-dna-cpl-00 > draft-ietf-dna-hosts-00 > draft-ietf-dna-link-information-01 > draft-ietf-dna-soln-frame-00 > draft-narayanan-dna-routers-bcp-00 (accepted) > > Please update us with the expected submission dates, so > we have enough time that the WG can agree to the changes, > and attempt to get external review (or closure on existing reviews). > > If you're an author or editor on one of these drafts, and > have tricky issues, or procedural uncertainties in this > regard, please don't hesitate to contact Pekka and I. > > Please be aware that we're not focussing on getting things > done for IETF, we're focussing on getting as much done _before_ > IETF. > > This also includes solutions work. Currently there's been some > discussion about differences between particular solution flavours. > Now's the time to start resolving the remaining issues on-list. > There are beginning to be implementations, which should assist that. > > If we've had a good discussion on-list, it may be possible to consensus > call the solution before IETF. This would be good, as then the meeting > could be used for outlining and resolving solution specification issues. > > I know people are working hard on DNA. > > Let's focus on getting the specifications out. > > Greg >