In 802.16, the MAC address is not = used for data transfer in only the IP-CS mode, which is not strictly an 802 = thing. In the Ethernet emulation modes, it certainly is. Also in the IP-CS modes, = the MAC addresses are known at both ends of the = connection.

An IP-CS connection is more akin to = a point to point IP link than an Ethernet. The decision to send a packet = down the connection is a L3 one. L2 has only one connection to send it down, = address resolution is moot. Such spoofing sounds like a hack to satisfy an = address resolution attempt that shouldn’t be happening because the = interface doesn’t warrant it.

----

David Johnston. dj.johnston@intel.com Cell= : 503 380 5578, Desk: 503 712 4457

From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Bernard = Aboba
Sent: Thursday, January = 10, 2008 11:05 AM
To: JinHyeock Choi
Cc: Wes Beebee (wbeebee); dna@eng.monash.edu.au; Hemant Singh (shemant); gmonte@microsoft.com
Subject: RE: [DNA] DNAv6 = Review from Mobopts

> It may cause some problem for DNA scheme to = rely on MAC address as below.
>
> First, in certain technology such as 802.16, MAC address is not = used
> for data transfer. In some implementation, when a host performs
> address resolution to find the router's MAC address, its device = driver
> intercepts the message and provides a bogus MAC address.

So the device driver is spoofing a response to the Neighbor = Solicitation?
Won't this cause problems if and when SEND is implemented?

> Moreover, when a host moves to another subnet/ link, it won't speed = up
> DNA procedure to check whether its existing default router is = still
> reachable. So the scheme will give little help when, IMO, fast DNA = is
> needed the most, i.e. when a host doesn't have a valid address, = so
> should get a new one ASAP.

Since ND and RS/RA are done simultaneously in simple DNAv6, the = completion
time is determined by the faster of the two exchanges. In the case = where the
host doesn't have a valid address, the ND exchanges will fail (no = response),
and the host will obtain an address via the normal RS/RA procedure. =

------_=_NextPart_001_01C853C7.B2414EE1-- From dna-owner@webcamserver.eng.monash.edu.au Thu Jan 10 18:57:05 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD7Gj-0007KC-HJ for dna-archive@lists.ietf.org; Thu, 10 Jan 2008 18:57:05 -0500 Received: from kyle.its.monash.edu.au ([130.194.13.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD7Gj-0001kP-28 for dna-archive@lists.ietf.org; Thu, 10 Jan 2008 18:57:05 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUG00DIAD6Q3EG0@kyle.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 11 Jan 2008 10:56:50 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7B78380032; Fri, 11 Jan 2008 10:56:49 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8AD043C00A; Fri, 11 Jan 2008 10:56:46 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0ANroB23755 for dna-list; Fri, 11 Jan 2008 10:53:50 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0ANrnQ23751 for ; Fri, 11 Jan 2008 10:53:49 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUG00401A99RC00@stan.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 11 Jan 2008 10:53:50 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUG00IR3D1N2UK0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 11 Jan 2008 10:53:50 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 0A35280031; Fri, 11 Jan 2008 10:53:49 +1100 (EST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8EEEA3C00A for ; Fri, 11 Jan 2008 10:53:48 +1100 (EST) Received: by fk-out-0910.google.com with SMTP id b27so853033fka.11 for ; Thu, 10 Jan 2008 15:53:45 -0800 (PST) Received: by 10.78.200.20 with SMTP id x20mr3191033huf.43.1200009225298; Thu, 10 Jan 2008 15:53:45 -0800 (PST) Received: by 10.78.158.5 with HTTP; Thu, 10 Jan 2008 15:53:45 -0800 (PST) Date: Fri, 11 Jan 2008 04:23:45 +0430 From: JinHyeock Choi Subject: Re: [DNA] DNAv6 Review from Mobopts In-reply-to: <6FD1CF412364944DB56F3D2ECF1544891E7C15@xmb-rtp-211.amer.cisco.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Wes Beebee (wbeebee)" Cc: Bernard Aboba , dna@eng.monash.edu.au, "Hemant Singh (shemant)" Message-id: <92e919fb0801101553m40f888adw75d7c0ce37c91882@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cbuUuT+DnMQclC2KLmRHc2K4uWbypM+T22qh58xV+eU=; b=U/zdR7LhsVV89KnwbGfdmcJfm9lcR+2mrdjjAQNkknBRimKS3rBWPtWRwR7q+gnF1UK2M4Lcg6I9qqxtrTbHgN1SOQ/ydCZxoXlEUB6b0+ac+iOZN3rj4g5EYbW4kdvXEfBkHN/KokRMGx0093/Siqn2ZUw0RQ31b8HP801u5u4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wI1HK6TUfiKTaCcvTRUL1FLuVXUOd9Ocr4atYqPGG6I0fwHL/lck80rlP9OvtVTAHooA4WIlXTnQrNzFCoNEm31/i+UtY3+X67TOaUprNyuU1zdX8qTOzP76jiN18NZjSKEgLXjaczRkSZxy9fjHFayvEFteYx9GPKJwcoS7Pt4= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <92e919fb0801091605o1fe58703nd6eede674c56f6c@mail.gmail.com> <6FD1CF412364944DB56F3D2ECF1544891E7C15@xmb-rtp-211.amer.cisco.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 > > thanks for your sharing ideas with us. I wish you would also comment > on the existing simple DNA solution to facilitate its advancement. > > Sure thing. Please send me a copy of the current drafts/point me to > their location and I will look at it when I have the time. http://www.ietf.org/internet-drafts/draft-krishnan-dna-simple-01.txt best regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jan 10 18:57:28 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD7H6-0007Wr-C6 for dna-archive@lists.ietf.org; Thu, 10 Jan 2008 18:57:28 -0500 Received: from cartman.its.monash.edu.au ([130.194.13.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD7H5-0001ke-Pm for dna-archive@lists.ietf.org; Thu, 10 Jan 2008 18:57:28 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUG004ITD7IG460@cartman.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 11 Jan 2008 10:57:19 +1100 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7DA76AB56B; Fri, 11 Jan 2008 10:57:18 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4BD3B4FB03; Fri, 11 Jan 2008 10:57:15 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0ANss823768 for dna-list; Fri, 11 Jan 2008 10:54:54 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0ANssQ23764 for ; Fri, 11 Jan 2008 10:54:54 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUG00401A99RC00@stan.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 11 Jan 2008 10:54:54 +1100 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUG00IU2D3E2UK0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 11 Jan 2008 10:54:54 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 3BFFEAB579; Fri, 11 Jan 2008 10:54:54 +1100 (EST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by curly.its.monash.edu.au (Postfix) with ESMTP id 108784FB07 for ; Fri, 11 Jan 2008 10:54:52 +1100 (EST) Received: by fk-out-0910.google.com with SMTP id b27so853402fka.11 for ; Thu, 10 Jan 2008 15:54:47 -0800 (PST) Received: by 10.78.170.17 with SMTP id s17mr3193463hue.35.1200009287346; Thu, 10 Jan 2008 15:54:47 -0800 (PST) Received: by 10.78.158.5 with HTTP; Thu, 10 Jan 2008 15:54:47 -0800 (PST) Date: Fri, 11 Jan 2008 04:24:47 +0430 From: JinHyeock Choi Subject: Re: [DNA] DNAv6 Review from Mobopts In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: "Wes Beebee (wbeebee)" , dna@eng.monash.edu.au, "Hemant Singh (shemant)" , gmonte@microsoft.com Message-id: <92e919fb0801101554i13366422sde589da8a4260d1b@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=N/rhgK4kTUDMwcUE5DjPfkaB3MLC9zapnQaHdHAtX38=; b=wBeLvW4kFWmjwtVnpKUYsqrug35OVOg9f/fAX/gI1LA9Tj2SsP5gvBxMDx+VsQ1303yEscWfiuYKdRt6JEzMc6OrphvYFt3LBLUYycE6GHcr0pVT5XSQbYcUbt2gGRNJuAdtiRi+or7xgnLdWjKvpzVqXkQT9PD82QiiXQNr8Vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EExGInfbmkLeiTUgEBJwZrGJtvnl9AzQm5a7zfBG4AmXcK7DF02Rla0v7EbFw+UvXXJDZ4slVXvoz8NDff3ufKzVRL+Raw2JrvI+3M69rXisgNoxdh9yqpgfdUUwJltIRLqisz/+xfDXYQKhwAo8mkhCNJOt/cW5nZyB/rAax1A= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <92e919fb0801071615i668abc6ci66ec1a954fc40239@mail.gmail.com> <6FD1CF412364944DB56F3D2ECF154489029885@xmb-rtp-211.amer.cisco.com> <92e919fb0801091605o1fe58703nd6eede674c56f6c@mail.gmail.com> <92e919fb0801100021m3723987fh3c60b3c8b0090ed9@mail.gmail.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > > It may cause some problem for DNA scheme to rely on MAC address as below. > > > > First, in certain technology such as 802.16, MAC address is not used > > for data transfer. In some implementation, when a host performs > > address resolution to find the router's MAC address, its device driver > > intercepts the message and provides a bogus MAC address. > > So the device driver is spoofing a response to the Neighbor Solicitation? > Won't this cause problems if and when SEND is implemented? It spoofs a solicitation and just replies the message for itself. NS message won't go out of a host. It may cause a problem for SEND and some other cases. > > Moreover, when a host moves to another subnet/ link, it won't speed up > > DNA procedure to check whether its existing default router is still > > reachable. So the scheme will give little help when, IMO, fast DNA is > > needed the most, i.e. when a host doesn't have a valid address, so > > should get a new one ASAP. > > Since ND and RS/RA are done simultaneously in simple DNAv6, the completion > time is determined by the faster of the two exchanges. In the case where > the > host doesn't have a valid address, the ND exchanges will fail (no > response), > and the host will obtain an address via the normal RS/RA procedure. So for handoff cases, DNA performs no better than existing ND. In other words, DNA contributes little for seamless handoff. I wonder whether it's an enough improvement. best regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Sun Jan 13 21:02:12 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEEeS-0004dE-02 for dna-archive@lists.ietf.org; Sun, 13 Jan 2008 21:02:12 -0500 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEEeP-0001ao-AK for dna-archive@lists.ietf.org; Sun, 13 Jan 2008 21:02:11 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUM005WI2ZE4VG0@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 13:02:03 +1100 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8EA3FAB54B; Mon, 14 Jan 2008 13:02:02 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 05DFC4FB07; Mon, 14 Jan 2008 13:01:58 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0E1w1810982 for dna-list; Mon, 14 Jan 2008 12:58:01 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0E1w0Q10978 for ; Mon, 14 Jan 2008 12:58:00 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUM006010D5QQ00@kyle.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 14 Jan 2008 12:58:00 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUM00HWF2SIAK90@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 14 Jan 2008 12:58:00 +1100 (EST) Received: by localhost (Postfix, from userid 510) id AE945AB547; Mon, 14 Jan 2008 12:58:00 +1100 (EST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4DED84FB07 for ; Mon, 14 Jan 2008 12:57:55 +1100 (EST) Received: by fg-out-1718.google.com with SMTP id 22so1953821fge.23 for ; Sun, 13 Jan 2008 17:57:52 -0800 (PST) Received: by 10.78.118.5 with SMTP id q5mr6681704huc.10.1200275872737; Sun, 13 Jan 2008 17:57:52 -0800 (PST) Received: by 10.78.158.5 with HTTP; Sun, 13 Jan 2008 17:57:52 -0800 (PST) Date: Mon, 14 Jan 2008 06:27:52 +0430 From: JinHyeock Choi Subject: Re: [DNA] DNAv6 Review from Mobopts In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Hemant Singh (shemant)" Cc: "Wes Beebee (wbeebee)" , Bernard Aboba , dna@eng.monash.edu.au Message-id: <92e919fb0801131757q48386d0cw738dd9aaec097e13@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=AZWoJStRkfjDqFPar2z1jhLWHW8/QkbNhyLetHGvxe4=; b=EQzzgS8jaLUwLdeW4ra/vMEpEKu0iLJBpqidQmdyS9CLBBbk2qHCY3kDrv+q9C7pmNivkkDQIe8ceQZIVnzlZFo49BPDLx8pehfzG7S/KH7mG79VNzdYqBidTkskdLn+DyOA+xL4f+VG+eTSDNM+Uz5pC0SJzWokoaWM2Qzcxpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mbzBpaFpBmFZ+ZXSH/6I+KN4OR1Kl5EWtX5Cy1E0kZ8Cr/aJalhaHYwkSN5dqFuo1XBZDj8LOkK/PuBst9wOl53N4BwVHbY9ZCNY1MCE1QDUPkNI6XbO+XnLt3+sAbTxTvmwsv6U6wpYe6NTLreJVKWk/7Ixqd2hPc5TZxg3QiE= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <92e919fb0801091605o1fe58703nd6eede674c56f6c@mail.gmail.com> <6FD1CF412364944DB56F3D2ECF1544891E7C15@xmb-rtp-211.amer.cisco.com> <92e919fb0801101553m40f888adw75d7c0ce37c91882@mail.gmail.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Dear Hemant Thanks for your kind elaboration, which made me understand the cable case the better, I hope. :-) I assume that, in CMTS, 'bundle of L2 links' form a kind of single (virtual) L3 link. While working on DNA, I found out that the concept of 'link' is more complicated than I had expected. :-( Another thanks for your trouble and it would be nice if you comment on Simple DNA draft. best regards JinHyeock On Jan 11, 2008 2:40 PM, Hemant Singh (shemant) wrote: > JinHyeock, > > My humble apologies for jumping in late on this thread. Let me explain > why the cable deployment is good and not as messed up as one might think > - I will explain the details. I don't consider the cable network as a > multi-link network. It's more of a point to point network. Here is why. > > The cable router, which is also called a CMTS (Cable Modem Termination > System), has a property of a virtual bundle network interface. CMTS is > also a DHCP relay agent. The L3 virtual network interface aggregates a > bunch of physical L2 cable interfaces. For example, a Cisco CMTS router > can have 40 cable network L2 interfaces - each of the 40 L2 cable > interface can serve about 5000 homes. It doesn't make sense for the > cable operator to assign L3 IP addresses to all of the 40 cable network > interfaces - it's a configuration hassle for operators. That is where > the L3 virtual bundle interface comes into play. One can aggregate say, > 20 cable interfaces, under one bundle interface on the CMTS router. So, > now the CMTS with 40 cable network L2 interfaces has only two L3 virtual > bundle interfaces to which IP addresses and subnets are assigned. For > IPv6, every bundle interface on the CMTS is one link. Yes, the multiple > L2 cable interfaces represent physical links going to various homes, but > the single L3 virtual bundle interface serves all the homes. > > Further, the physical connectivity of the cable deployment is such that > no host behind a cable modem can communicate directly to another host > behind another modem. All host traffic has to go through the CMTS > router. Since hosts send traffic directly to router to communicate with > any other host, that is why cable deployment if always off-link for both > IPv4 or IPv6. That is also why the cable model maps to a point to point > model. > > That is why cable folks were looking at ND to see how to specify > off-link in ND for CMTS router. After going thru the ND RFC's we > realized there was ONLY one way one could signal off-link in ND. That > was by not sending any PIO (Prefix Information Option) in RA. > > When I get the time, I will review DNA simple draft as well and send my > comments. > > Kind Regards. > > Hemant > > -----Original Message----- > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > Sent: Thursday, January 10, 2008 6:54 PM > To: Wes Beebee (wbeebee) > Cc: Bernard Aboba; dna@eng.monash.edu.au; Hemant Singh (shemant) > Subject: Re: [DNA] DNAv6 Review from Mobopts > > > > > thanks for your sharing ideas with us. I wish you would also > > > comment > > on the existing simple DNA solution to facilitate its advancement. > > > > Sure thing. Please send me a copy of the current drafts/point me to > > their location and I will look at it when I have the time. > > http://www.ietf.org/internet-drafts/draft-krishnan-dna-simple-01.txt > > best regards > > JinHyeock > From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 14 05:03:03 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEM9n-0002S5-RL for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 05:03:03 -0500 Received: from kyle.its.monash.edu.au ([130.194.13.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEM9n-0007xS-8x for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 05:03:03 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUM00MYPP8UL500@kyle.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 21:02:55 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 480F680006; Mon, 14 Jan 2008 21:02:54 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2DF5B3C009; Mon, 14 Jan 2008 21:02:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0E9xpj12537 for dna-list; Mon, 14 Jan 2008 20:59:51 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0E9xoQ12533 for ; Mon, 14 Jan 2008 20:59:50 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUM00H01HOTK000@kenny.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 14 Jan 2008 20:59:51 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUM003V0P3PF140@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 14 Jan 2008 20:59:51 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 1919B80006; Mon, 14 Jan 2008 20:59:51 +1100 (EST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by larry.its.monash.edu.au (Postfix) with ESMTP id 09ECE3C003 for ; Mon, 14 Jan 2008 20:59:49 +1100 (EST) Received: by fk-out-0910.google.com with SMTP id b27so1398152fka.11 for ; Mon, 14 Jan 2008 01:59:47 -0800 (PST) Received: by 10.78.123.4 with SMTP id v4mr6928993huc.18.1200304786781; Mon, 14 Jan 2008 01:59:46 -0800 (PST) Received: by 10.78.158.5 with HTTP; Mon, 14 Jan 2008 01:59:46 -0800 (PST) Date: Mon, 14 Jan 2008 14:29:46 +0430 From: JinHyeock Choi Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> Sender: owner-dna@ecselists.eng.monash.edu.au To: Suresh Krishnan Cc: Bernard_Aboba@hotmail.com, dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8VDDQIq5cnicwYwNwvx/4Y+450gltqC/ovtHK8P12tM=; b=g8FjbpRJxE2GzjqELPr5meLjjOOQceCenJkhtcLDQHVvONtKU0SwRkoJ0oLEgWYK8iV59CXcVIADvvgl2HaEshj3zJBeDPDH7HZDaUaS2FmZayLkvLFa1mZ9fV249iunqpuCEJoQJXHtYNgSiX769aRmj3sg3cQITXFA/KsIuQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IhSyLPaqwssf9q7rrGkVoPzLm973uy3j/M9JcJjy8vwEcp90rAhBFKHdqK5z1N8LkWfqke7cSlyWN5T/M+nwX24z25Q9Mm91J3eN7Vj+RJxINTaQnaWs5hqdgujYLnRGSTumxPq/ffRQhszQadwWTPOllph/lyZeTowJ0fgbkDs= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Dear Suresh & Greg I managed to go over the draft and thanks for your trouble. Before making comments, I'd like to ensure that I understand the draft right. Here are a few clarifying questions. 1. Assumption The draft seems to assume the following w.r.t prefix advertisement. 1) All routers on the link advertise the same prefixes. 2) It's out of scope how routers would synchronize their advertisement. Do I understand right? 2. Link identification. The draft seems to check for link change as below. 1) Upon receiving link-layer indication, a host would send an RS and an NS simultaneously. 2) If the host receives a solicited NA from a known node of a previously attached link, the host assumes it still remains in the same link. 3) If the host receives a solicited RA with a known prefix of a previously attached link, the host assumes it still remains in the same link. Otherwise, i.e. the host receives no known prefix in the RA, the host assumes it moved to a different link. 4) When 2 & 3 give conflicting answers, 3's decision is definite. Do I understand right? 3. Fast Router Advertisement The draft seems to speed up RA delivery as below. 1) Upon receiving an RS with a tentative option, a DNA router immediately sends back an unicast RA without random delay (with token bucket based rate control) 2) It's out of the scope how mulitple DNA routers would avoid collision. Do I understand right? Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 14 13:44:38 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEUIY-0006HA-8H for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 13:44:38 -0500 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEUIX-0002HF-5p for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 13:44:38 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUN00KS8DDXH460@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Jan 2008 05:44:22 +1100 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B9255AB54B; Tue, 15 Jan 2008 05:44:21 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 868224FB04; Tue, 15 Jan 2008 05:44:19 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0EIeRg14750 for dna-list; Tue, 15 Jan 2008 05:40:27 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0EIeOQ14746 for ; Tue, 15 Jan 2008 05:40:25 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUN00D017AMNZ00@kenny.its.monash.edu.au> (original mail from bernard_aboba@hotmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Jan 2008 05:40:25 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUN003EZD78FD90@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 15 Jan 2008 05:40:25 +1100 (EST) Received: by localhost (Postfix, from userid 510) id C9B2EAB549; Tue, 15 Jan 2008 05:40:25 +1100 (EST) Received: from bay0-omc1-s18.bay0.hotmail.com (bay0-omc1-s18.bay0.hotmail.com [65.54.246.90]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4B3474FB05; Tue, 15 Jan 2008 05:40:24 +1100 (EST) Received: from BAY117-W10 ([207.46.8.45]) by bay0-omc1-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 10:40:19 -0800 Date: Mon, 14 Jan 2008 10:40:19 -0800 From: Bernard Aboba Subject: RE: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> X-Originating-IP: [67.183.152.50] Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Suresh Krishnan Cc: dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=_bcc78707-7eac-4970-9fe1-02b65905c168_ Importance: Normal X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> X-OriginalArrivalTime: 14 Jan 2008 18:40:19.0801 (UTC) FILETIME=[E9F52490:01C856DC] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 --_bcc78707-7eac-4970-9fe1-02b65905c168_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments below. > Date: Mon, 14 Jan 2008 14:29:46 +0430> From: jinchoe@gmai= l.com> To: suresh.krishnan@ericsson.com> Subject: Re: [DNA] RE: Review of d= raft-krishnan-dna-simple-01.txt> CC: Bernard_Aboba@hotmail.com; dna@eng.mon= ash.edu.au; greg.daley@eng.monash.edu.au; narten@us.ibm.com; erik.nordmark@= sun.com; jari.arkko@piuha.net> > Dear Suresh & Greg> > I managed to go over= the draft and thanks for your trouble.> > Before making comments, I'd like= to ensure that I understand the draft right.> Here are a few clarifying qu= estions.> > 1. Assumption> The draft seems to assume the following w.r.t pr= efix advertisement.> > 1) All routers on the link advertise the same prefix= es. =20 [BA] No. It is possible to send multiple NS so that this assumption is not= required.=20 > 2) It's out of scope how routers would synchronize their advertisement.> = > Do I understand right?> > 2. Link identification.> The draft seems to che= ck for link change as below.> > 1) Upon receiving link-layer indication,> a= host would send an RS and an NS simultaneously. =20 [BA] Yes. > 2) If the host receives a solicited NA from a known node> of a previously= attached link,> the host assumes it still remains in the same link. =20 [BA] Yes -- unless the RA provides different information.=20 > 3) If the host receives a solicited RA with a known prefix> of a previous= ly attached link,> the host assumes it still remains in the same link.> Oth= erwise, i.e. the host receives no known prefix in the RA,> the host assumes= it moved to a different link. =20 [BA] There is also the possibility that DHCPv6 is in use, in which case 2) can confirm the validity of an IPv6 address whose lease has not yet expired.=20 > 4) When 2 & 3 give conflicting answers, 3's decision is definite. =20 [BA] Correct -- except for DHCPv6 case, where 2) may confirm the validity of a previously assigned address, but 3) may indicate the need to send a DHCPv6 request. As before if the DHCPv6 assigned address conflicts with the address determined in 2), then DHCPv6 wins.=20 = --_bcc78707-7eac-4970-9fe1-02b65905c168_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments below.

> Date: Mon, 14 Jan 2008 14:29:46 +0430
> = From: jinchoe@gmail.com
> To: suresh.krishnan@ericsson.com
> Su= bject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt
> CC:= Bernard_Aboba@hotmail.com; dna@eng.monash.edu.au; greg.daley@eng.monash.ed= u.au; narten@us.ibm.com; erik.nordmark@sun.com; jari.arkko@piuha.net
>= ;
> Dear Suresh & Greg
>
> I managed to go over the= draft and thanks for your trouble.
>
> Before making comments= , I'd like to ensure that I understand the draft right.
> Here are a = few clarifying questions.
>
> 1. Assumption
> The draft = seems to assume the following w.r.t prefix advertisement.
>
> = 1) All routers on the link advertise the same prefixes.

[BA] No. It is possible to send multiple NS so that this assumption i= s not required.

> 2) It's out of scope how routers would synchronize their advertise= ment.
>
> Do I understand right?
>
> 2. Link iden= tification.
> The draft seems to check for link change as below.
&= gt;
> 1) Upon receiving link-layer indication,
> a host would = send an RS and an NS simultaneously.

[BA] Yes.

> 2) If the host receives a solicited NA from a known node
> o= f a previously attached link,
> the host assumes it still remains in = the same link.

[BA] Yes -- unless the RA provides different information.

> 3) If the host receives a solicited RA with a known prefix
>= of a previously attached link,
> the host assumes it still remains i= n the same link.
> Otherwise, i.e. the host receives no known prefix = in the RA,
> the host assumes it moved to a different link.

[BA] There is also the possibility that DHCPv6 is in use, in which
case 2) can confirm the validity of an IPv6 address whose lease has
not yet expired.

> 4) When 2 & 3 give conflicting answers, 3's decision is defini= te.

[BA] Correct -- except for DHCPv6 case, where 2) may confirm
the validity of a previously assigned address, but 3) may indicate
the need to send a DHCPv6 request. As before if the DHCPv6
assigned address conflicts with the address determined in 2),
then DHCPv6 wins.

= --_bcc78707-7eac-4970-9fe1-02b65905c168_-- From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 14 15:45:10 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEWBC-0003NK-OP for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 15:45:10 -0500 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEWBB-0005Df-Tw for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 15:45:10 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUN00KLXIYZH070@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Jan 2008 07:45:00 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C0EC080007; Tue, 15 Jan 2008 07:44:59 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3E5463C00A; Tue, 15 Jan 2008 07:44:57 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0EKg1C15241 for dna-list; Tue, 15 Jan 2008 07:42:01 +1100 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0EKg0Q15237 for ; Tue, 15 Jan 2008 07:42:00 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUN00I01CK35X00@cartman.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Jan 2008 07:42:01 +1100 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUN00H1QIU0XI70@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 15 Jan 2008 07:42:00 +1100 (EST) Received: by localhost (Postfix, from userid 510) id C7DC0AB54A; Tue, 15 Jan 2008 07:42:00 +1100 (EST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9A4A74FB06 for ; Tue, 15 Jan 2008 07:41:59 +1100 (EST) Received: by fk-out-0910.google.com with SMTP id b27so1665976fka.11 for ; Mon, 14 Jan 2008 12:41:55 -0800 (PST) Received: by 10.78.133.2 with SMTP id g2mr8082519hud.26.1200343315112; Mon, 14 Jan 2008 12:41:55 -0800 (PST) Received: by 10.78.158.5 with HTTP; Mon, 14 Jan 2008 12:41:55 -0800 (PST) Date: Tue, 15 Jan 2008 05:41:55 +0900 From: JinHyeock Choi Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Suresh Krishnan , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MUsuG06fQo/yKuH97cNj6OzvW7GRTwJo6tWPdV+gECg=; b=IWT+lWEQMnPWrEGTOwNXaPm9Px51dAuW9Let8a1+1ubuJYFDSLbbzYG3urdglqVON8MpGg23QUr4IKRiKBa3gIHRsqsKt1iKBRIwuGlNLaXQgxCKfq89WGqyc+Heaji11nIRQZOI+Pk1CxowvNd3NhXzCc3Hl2vOHN3TDNknwHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OfkAqV4URXaPLqJCwE3WeLoaIkDUOuIeuUtKM5NiagFY+whMLMIy7nifjUXckHAQtpMKfHe3GmUyIAtEADoHcbsgI6DOFu3lngWJkMp70RFHUu93eQD0UjhS3jQN+pYquWWH4/pCsu7YCm/XT9CSF2nVeZ/DKgF9jJSJd5GcQRc= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Dear Bernard thanks for your comments. > > 1. Assumption > > The draft seems to assume the following w.r.t prefix advertisement. > > > > 1) All routers on the link advertise the same prefixes. > > [BA] No. It is possible to send multiple NS so that this assumption is not > required. Multiple NSs won't correct the wrong DNA decision from RAs with disjoint prefix lists. An NS/NA based DNA decision is overruled by RA based DNA decision. Upon receiving an RA with no known prefix, a host will assume a link change even if NS/ NA exchange indicates no link change. > > 2) It's out of scope how routers would synchronize their advertisement. > > > > Do I understand right? > > > > 2. Link identification. > > The draft seems to check for link change as below. > > > > 1) Upon receiving link-layer indication, > > a host would send an RS and an NS simultaneously. > > [BA] Yes. ok. > > 2) If the host receives a solicited NA from a known node > > of a previously attached link, > > the host assumes it still remains in the same link. > > [BA] Yes -- unless the RA provides different information. ok. > > 3) If the host receives a solicited RA with a known prefix > > of a previously attached link, > > the host assumes it still remains in the same link. > > Otherwise, i.e. the host receives no known prefix in the RA, > > the host assumes it moved to a different link. > > [BA] There is also the possibility that DHCPv6 is in use, in which > case 2) can confirm the validity of an IPv6 address whose lease has > not yet expired. ok. > > 4) When 2 & 3 give conflicting answers, 3's decision is definite. > > [BA] Correct -- except for DHCPv6 case, where 2) may confirm > the validity of a previously assigned address, but 3) may indicate > the need to send a DHCPv6 request. As before if the DHCPv6 > assigned address conflicts with the address determined in 2), > then DHCPv6 wins. ok. Thanks for your kind consideration. best regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 14 21:12:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEbIE-00056M-1b for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 21:12:46 -0500 Received: from kyle.its.monash.edu.au ([130.194.13.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEbIA-00027D-5J for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 21:12:46 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUN00MCNY4ZL5A0@kyle.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Jan 2008 13:12:36 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6C1F080004; Tue, 15 Jan 2008 13:12:35 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 46B573C007; Tue, 15 Jan 2008 13:12:32 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0F29Hx16427 for dna-list; Tue, 15 Jan 2008 13:09:17 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0F29GQ16423 for ; Tue, 15 Jan 2008 13:09:16 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUN00B01U21N400@kyle.its.monash.edu.au> (original mail from bernard_aboba@hotmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Jan 2008 13:09:17 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUN00MOZXZFLG90@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 15 Jan 2008 13:09:17 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 2067680003; Tue, 15 Jan 2008 13:09:17 +1100 (EST) Received: from bay0-omc1-s7.bay0.hotmail.com (bay0-omc1-s7.bay0.hotmail.com [65.54.246.79]) by larry.its.monash.edu.au (Postfix) with ESMTP id EA7E03C006; Tue, 15 Jan 2008 13:09:15 +1100 (EST) Received: from BAY117-W32 ([207.46.8.67]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 18:09:13 -0800 Date: Mon, 14 Jan 2008 18:09:13 -0800 From: Bernard Aboba Subject: RE: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> X-Originating-IP: [131.107.0.75] Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Suresh Krishnan , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=_d10827bb-847e-4248-a790-89b397bf5b36_ Importance: Normal X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> X-OriginalArrivalTime: 15 Jan 2008 02:09:13.0817 (UTC) FILETIME=[9FE1D490:01C8571B] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 --_d10827bb-847e-4248-a790-89b397bf5b36_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Multiple NSs won't correct the wrong DNA decision from RAs with> disjoint= prefix lists. An NS/NA based DNA decision is overruled by RA> based DNA de= cision. Upon receiving an RA with no known prefix, a host> will assume a li= nk change even if NS/ NA exchange indicates no link> change. =20 [BA] Why? If a NUD exchange suceeds, the host should merely assume that the information it got from that particular router is still valid, not= that it has confirmed *all* the information from *all* the routers. So if it assigned a still-valid address based on a particular prefix announcement, it need only confirm reachability to the router that sent that prefix announcement. Receiving an RA with no known prefix from some other router is immaterial. And of course, if that same router updates its prefi= x list, then the previously cached DNA configuration information is invalidated.=20 =20 As an example, if a host previously recieved an RA with no known prefix, and as a result got a valid address assigned via DHCPv6, it should be able to confirm the validity of that address based on a NUD exchange with the router (while doing a DHCPv6 configuration exchange in the background). = --_d10827bb-847e-4248-a790-89b397bf5b36_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Multiple NSs won't correct the wrong DNA decision from RAs with
>= ; disjoint prefix lists. An NS/NA based DNA decision is overruled by RA
= > based DNA decision. Upon receiving an RA with no known prefix, a host<= BR>> will assume a link change even if NS/ NA exchange indicates no link=
> change.

[BA] Why? If a NUD exchange suceeds, the host should merely assu= me
that the information it got from that particular router is still valid, not= that
it has confirmed *all* the information from *all* the routers. &n= bsp; So if it
assigned a still-valid address based on a particular prefix announcement, it need only confirm reachability to the router that sent that prefix
announcement. Receiving an RA with no known prefix from some other router is immaterial. And of course, if that same router updates its = prefix list,
then the previously cached DNA configuration information is invalidated.
As an example, if a host previously recieved an RA with no known prefix, and as a result got a valid address assigned via DHCPv6, it should be able<= BR> to confirm the validity of that address based on a NUD exchange with the router (while doing a DHCPv6 configuration exchange in the background). = --_d10827bb-847e-4248-a790-89b397bf5b36_-- From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 14 22:21:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEcMR-0003ka-5T for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 22:21:11 -0500 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEcMO-0003EG-Fz for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 22:21:11 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUO00K511B3GWC0@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Jan 2008 14:21:03 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F052480004; Tue, 15 Jan 2008 14:21:02 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3D8DE3C003; Tue, 15 Jan 2008 14:21:00 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0F3I2r16742 for dna-list; Tue, 15 Jan 2008 14:18:02 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0F3HvQ16738 for ; Tue, 15 Jan 2008 14:17:57 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUN00C01ZG11E00@kenny.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Jan 2008 14:17:58 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUO0095U15WYB10@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 15 Jan 2008 14:17:58 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 2C6DEAB542; Tue, 15 Jan 2008 14:17:58 +1100 (EST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by moe.its.monash.edu.au (Postfix) with ESMTP id 84D7B4FB0B for ; Tue, 15 Jan 2008 14:17:56 +1100 (EST) Received: by fg-out-1718.google.com with SMTP id 22so2380905fge.23 for ; Mon, 14 Jan 2008 19:17:53 -0800 (PST) Received: by 10.78.131.8 with SMTP id e8mr8378413hud.52.1200367073600; Mon, 14 Jan 2008 19:17:53 -0800 (PST) Received: by 10.78.158.5 with HTTP; Mon, 14 Jan 2008 19:17:53 -0800 (PST) Date: Tue, 15 Jan 2008 07:47:53 +0430 From: JinHyeock Choi Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Suresh Krishnan , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <92e919fb0801141917s3acc44c1gf59d5a765a5cb5f3@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=TONjR1sEt7TAIL4YdTuQgJ06rljKOHp03dgezlBOsrw=; b=nje/Eh2eb38ZwqgsSG1SxqABJQn3B/2H/3sRm8ZCdvntAMZKGU31lgJ/m9gGwnJincBQ0P1pcn7L090+mZ+6qJWyAGA/3PYCqtuoub9H0RUPWEWruUtlrP4u4twoI0itJBBfvBpQWBWbHrwBy1mLBMVxKRo8DwKagxQV2Q/xz+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vLsI1mzGR5zKUlQelYPKiM61VE2BvEV6F+pNYOK0svCRWOR3x5b7UsX1+kj36SNkxWxbguL23J4Af36AEeRV16JDPB7Y6UQy8sWSz6C7RxeenTf8Vx0VmxZBuevALv2KRIG83sSsDIohhWK8ywwcf7hyLcoVP7yciYkOWPg5c7c= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Bernard > > Multiple NSs won't correct the wrong DNA decision from RAs with > > disjoint prefix lists. An NS/NA based DNA decision is overruled by RA > > based DNA decision. Upon receiving an RA with no known prefix, a host > > will assume a link change even if NS/ NA exchange indicates no link > > change. > > [BA] Why? From the below, I had assumed that RA based decision always takes precedent. > > > 4) When 2 & 3 give conflicting answers, 3's decision is definite. > > > > [BA] Correct -- except for DHCPv6 case, where 2) may confirm > > the validity of a previously assigned address, but 3) may indicate > > the need to send a DHCPv6 request. As before if the DHCPv6 > > assigned address conflicts with the address determined in 2), > > then DHCPv6 wins. However, from your remarks below, it seems that sometimes NS/ NA based decision overrules RA based decision. > If a NUD exchange suceeds, the host should merely assume > that the information it got from that particular router is still valid, not > that > it has confirmed *all* the information from *all* the routers. So if it > assigned a still-valid address based on a particular prefix announcement, > it need only confirm reachability to the router that sent that prefix > announcement. Receiving an RA with no known prefix from some other > router is immaterial. ok. However this necessitates hosts to maintain the state of pairs, (a prefix, a router which advertise the prefix). Also if an RA with no known prefix arrives before a solicited NA, I assume the host immediately decides a link change, instead of waiting for the NA. I have difficulty discerning the above mechanism from the draft. That's why I first tried to clarify DNA operation lest we should discuss over irrelevant items. > And of course, if that same router updates its > prefix list, > then the previously cached DNA configuration information is invalidated. ND allows a router to omits some prefixes when it advertises an RA. So from a prefix list in an RA, a host has difficulty discerning whether a missing prefix is invalidated or simply omitted. > As an example, if a host previously recieved an RA with no known prefix, > and as a result got a valid address assigned via DHCPv6, it should be able > to confirm the validity of that address based on a NUD exchange with the > router (while doing a DHCPv6 configuration exchange in the background). This is not clear. With which router a host should perform NUD to validate a DHCP based address? No router has specific relation with the DHCP based address. Any router will do? If that's the case, why can't we use that criterion for non-DHCP based address. Now I come to wonder why RA based decision is assumed definite. Maybe it's better to make NS/NA based decision takes precedents over RA based decision. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 14 22:52:02 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEcqI-0008I2-3a for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 22:52:02 -0500 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEcqG-0003aT-W5 for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 22:52:02 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUO00KTG2Q2H2C0@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Jan 2008 14:51:39 +1100 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA17BAB542; Tue, 15 Jan 2008 14:51:38 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 09E774FB0B; Tue, 15 Jan 2008 14:51:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0F3n9Q16986 for dna-list; Tue, 15 Jan 2008 14:49:09 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0F3n8Q16982 for ; Tue, 15 Jan 2008 14:49:08 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUO00D011K7MX00@kenny.its.monash.edu.au> (original mail from bernard_aboba@hotmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Jan 2008 14:49:09 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUO009GU2LSY810@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 15 Jan 2008 14:49:09 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 22455AB542; Tue, 15 Jan 2008 14:49:09 +1100 (EST) Received: from bay0-omc1-s35.bay0.hotmail.com (bay0-omc1-s35.bay0.hotmail.com [65.54.246.107]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2FE7F4FB03; Tue, 15 Jan 2008 14:49:07 +1100 (EST) Received: from hotmail.com ([207.46.8.12]) by bay0-omc1-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 19:49:05 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jan 2008 19:49:04 -0800 Received: from 131.107.0.73 by BAY117-DAV2.phx.gbl with DAV; Tue, 15 Jan 2008 03:49:02 +0000 Date: Mon, 14 Jan 2008 19:49:02 -0800 From: Bernard Aboba Subject: RE: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: <92e919fb0801141917s3acc44c1gf59d5a765a5cb5f3@mail.gmail.com> X-Originating-IP: [131.107.0.73] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: 'JinHyeock Choi' Cc: 'Suresh Krishnan' , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, 'Jari Arkko' Message-id: Message-id: <000001c85729$9147da20$b3d78e60$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7bit Thread-index: AchXJamMGuyDmrzjR82yuXnWBqohQQAADKDA X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Originating-Email: [bernard_aboba@hotmail.com] References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> <92e919fb0801141917s3acc44c1gf59d5a765a5cb5f3@mail.gmail.com> X-OriginalArrivalTime: 15 Jan 2008 03:49:04.0640 (UTC) FILETIME=[92B0E000:01C85729] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f > > > 4) When 2 & 3 give conflicting answers, 3's decision is definite. > > > > [BA] Correct -- except for DHCPv6 case, where 2) may confirm > > the validity of a previously assigned address, but 3) may indicate > > the need to send a DHCPv6 request. As before if the DHCPv6 > > assigned address conflicts with the address determined in 2), > > then DHCPv6 wins. [JC] However, from your remarks below, it seems that sometimes NS/ NA based decision overrules RA based decision. [BA] I think that an RA from a router will over-ride an NA from that same router, with respect to a given address. But an RA from another router will not. > If a NUD exchange suceeds, the host should merely assume > that the information it got from that particular router is still valid, not > that > it has confirmed *all* the information from *all* the routers. So if it > assigned a still-valid address based on a particular prefix announcement, > it need only confirm reachability to the router that sent that prefix > announcement. Receiving an RA with no known prefix from some other > router is immaterial. [JC] ok. However this necessitates hosts to maintain the state of pairs, (a prefix, a router which advertise the prefix). Also if an RA with no known prefix arrives before a solicited NA, I assume the host immediately decides a link change, instead of waiting for the NA. [BA] The way I think of it is that the host needs to determine whether its existing addresses are valid. It can determine that based on receipt of an NS from a router, or receipt of RAs. Let us assume that formerly router A announced a prefix from which the host formed address A. Now with Simple DNA, the host tries to determine if that address is still valid. In response to an RS, it receives an RA from that same router with no known prefix. It can now conclude that address A is not valid, under the assumption that the prefix should have been included if the router was still advertising it. However, the host could also have formed another address B based on an announcement from router B. With Simple DNA, the host sends a unicast NS to router B which responds with a solicited NA. The host can now assume that address B is still valid -- unless it receives an RA from router B that is missing the prefix from which that address was derived. [JC] I have difficulty discerning the above mechanism from the draft. That's why I first tried to clarify DNA operation lest we should discuss over irrelevant items. [BA] You are correct that the current draft does not describe how Simple DNA needs to operate. As you state, for simple DNAv6 the host needs to maintain lists of valid addresses and the corresponding routers from which they obtained those addresses. This is how DNAv4 works. > And of course, if that same router updates its > prefix list, > then the previously cached DNA configuration information is invalidated. [JC] ND allows a router to omit some prefixes when it advertises an RA. So from a prefix list in an RA, a host has difficulty discerning whether a missing prefix is invalidated or simply omitted. [BA] Right -- but if the router wants to deprecate a previously announced prefix, it does have to announce it, no? We are assuming that the host only uses simple DNAv6 to re-confirm addresses that would otherwise be still valid (e.g. addresses whose DHCPv6 lease has not yet expired, or whose prefix is still valid). If the address is invalid, then the host should not be using simple DNAv6. > As an example, if a host previously recieved an RA with no known prefix, > and as a result got a valid address assigned via DHCPv6, it should be able > to confirm the validity of that address based on a NUD exchange with the > router (while doing a DHCPv6 configuration exchange in the background). [JC] This is not clear. With which router a host should perform NUD to validate a DHCP based address? No router has specific relation with the DHCP based address. Any router will do? If that's the case, why can't we use that criterion for non-DHCP based address. [BA] To validate a DHCPv6-based address, the host should perform NUD to the router which lead it to believe that DHCPv6 was supported on the link. If it receives an NA, it can assume that the DHCPv6 address is still valid, assuming that the original lease has not yet expired. Of course, if it receives an RA from that router indicating that conditions have changed (e.g. now DHCPv6 is no longer supported), or receives a response from the DHCPv6 server indicating that another address is being assigned, then the host's configuration should change. [JC] Now I come to wonder why RA based decision is assumed definite. Maybe it's better to make NS/NA based decision takes precedents over RA based decision. [BA] Receipt of an RA is additional information which may invalidate an assumption made as a result of receipt of an NA. For example, the RA could indicate different prefixes, or a change in address assignment mechanism (stateless to stateful or the other way around). In any case, I think it is important that we write all of this down in the Simple DNAv6 draft so that we can evaluate it and understand how well it works and under what conditions it might not work. I had sent my comments on the draft in a previous mail. From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 14 23:03:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEd1Y-0000Xx-Ap for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 23:03:40 -0500 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEd1X-0003gs-OA for dna-archive@lists.ietf.org; Mon, 14 Jan 2008 23:03:40 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUO00K6A39TGYD0@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Jan 2008 15:03:33 +1100 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D0800AB542; Tue, 15 Jan 2008 15:03:32 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 00CE04FB04; Tue, 15 Jan 2008 15:03:27 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0F40lr17119 for dna-list; Tue, 15 Jan 2008 15:00:47 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0F40lQ17115 for ; Tue, 15 Jan 2008 15:00:47 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUO00D011K7MX00@kenny.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Jan 2008 15:00:47 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUO009ND359Y810@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 15 Jan 2008 15:00:46 +1100 (EST) Received: by localhost (Postfix, from userid 510) id B7D8F80003; Tue, 15 Jan 2008 15:00:46 +1100 (EST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) (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 CAC263C003; Tue, 15 Jan 2008 15:00:42 +1100 (EST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m0F40cB9030311; Mon, 14 Jan 2008 22:00:38 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 22:00:37 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 22:00:37 -0600 Date: Mon, 14 Jan 2008 23:02:24 -0500 From: Suresh Krishnan Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: JinHyeock Choi , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <478C3050.8080801@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071022) X-OriginalArrivalTime: 15 Jan 2008 04:00:37.0600 (UTC) FILETIME=[2FBA2E00:01C8572B] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Bernard and Jin, Bernard Aboba wrote: > > Multiple NSs won't correct the wrong DNA decision from RAs with > > disjoint prefix lists. An NS/NA based DNA decision is overruled by RA > > based DNA decision. Upon receiving an RA with no known prefix, a host > > will assume a link change even if NS/ NA exchange indicates no link > > change. > > [BA] Why? If a NUD exchange suceeds, the host should merely assume > that the information it got from that particular router is still valid, > not that > it has confirmed *all* the information from *all* the routers. So if it > assigned a still-valid address based on a particular prefix announcement, > it need only confirm reachability to the router that sent that prefix > announcement. Receiving an RA with no known prefix from some other > router is immaterial. And of course, if that same router updates its > prefix list, > then the previously cached DNA configuration information is invalidated. > > As an example, if a host previously recieved an RA with no known prefix, > and as a result got a valid address assigned via DHCPv6, it should be able > to confirm the validity of that address based on a NUD exchange with the > router (while doing a DHCPv6 configuration exchange in the background). I have to admit that when we wrote the draft, we did not consider the precedence between the NS/NA tests and the RS/RA test. The way I see it today, an RA from a router containing disjoint prefixes will only override a positive NA confirmation from the same router and other than this there will be no interaction between the NS/NA tests and te RS/RA tests. I will give this a little more thought and come up with some text on this regard. Thanks Suresh From dna-owner@webcamserver.eng.monash.edu.au Wed Jan 16 04:18:05 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF4PN-00059q-TY for dna-archive@lists.ietf.org; Wed, 16 Jan 2008 04:18:05 -0500 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF4PM-0000S9-LB for dna-archive@lists.ietf.org; Wed, 16 Jan 2008 04:18:05 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUQ00H3GCHW3EX0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Jan 2008 20:17:57 +1100 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B2CFFAB545; Wed, 16 Jan 2008 20:17:56 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7858B4FB04; Wed, 16 Jan 2008 20:17:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0G9DBL24048 for dna-list; Wed, 16 Jan 2008 20:13:11 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0G9D8Q24044 for ; Wed, 16 Jan 2008 20:13:08 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUQ008019MYSX00@kenny.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 16 Jan 2008 20:13:09 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUQ00HUBC9X3EW0@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Wed, 16 Jan 2008 20:13:09 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 6BAECAB542; Wed, 16 Jan 2008 20:13:09 +1100 (EST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by moe.its.monash.edu.au (Postfix) with ESMTP id C60E04FB0C for ; Wed, 16 Jan 2008 20:13:07 +1100 (EST) Received: by mu-out-0910.google.com with SMTP id i10so188333mue.3 for ; Wed, 16 Jan 2008 01:13:04 -0800 (PST) Received: by 10.78.193.5 with SMTP id q5mr404445huf.30.1200474784328; Wed, 16 Jan 2008 01:13:04 -0800 (PST) Received: by 10.78.158.5 with HTTP; Wed, 16 Jan 2008 01:13:04 -0800 (PST) Date: Wed, 16 Jan 2008 13:43:04 +0430 From: JinHyeock Choi Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Suresh Krishnan , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <92e919fb0801160113x49221875h9a283b4ae0ee2a07@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=iBreJnT+ketGDHvWI9ojDXTGw9T+NmTFklOevFWoVUY=; b=d2JkKluDuBAe0KGBih0PEWNx0xUFh6oRslPJa3e7qc7APjoGHujNHcBJtG94QBoM81KXgcONr/x+Tsyjf8UyWjbgEg5re6eMnksD72s6R6hmeHNc/OXYEk4+FE7w7F1Ii7qok2vtMp69KeI1dj+3okhDRmvNFboiK6wUT2Kbk2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gjHWhpGGq7fwSvUQ5BWkUgd26NuxPMlc6HZmXASvatClpKvJUgR97QM7cBCqeZfz9QO2jf6DilIipcV3fCj9bReVpb619fDweHIelo2/v+Pf802sgt4J2MDwOsrRz+zgtsLb2s6TsZPrqTLqrFAfOsFzcGPIqXluUsBy80TlUuY= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> <92e919fb0801141917s3acc44c1gf59d5a765a5cb5f3@mail.gmail.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Bernard > [JC] However, from your remarks below, it seems that sometimes NS/ NA based > decision overrules RA based decision. > > [BA] I think that an RA from a router will over-ride an NA from that same > router, with respect to a given address. But an RA from another router will > not. Then the host should treat RAs differently according to sending routers. That entails added complexity, which, I'm not sure desirable. Simple DNA is supposed to simplify DNA operation. > [JC] ok. However this necessitates hosts to maintain the state of pairs, (a > prefix, a router which advertise the prefix). Also if an RA with no > known prefix arrives before a solicited NA, I assume the host > immediately decides a link change, instead of waiting for the NA. > > [BA] The way I think of it is that the host needs to determine > whether its existing addresses are valid. It can determine that based > on receipt of an NS from a router, or receipt of RAs. From your remark, I assume that a host verifies its addresses one bye one. The verification of one address doesn't guarantee the validity of others, right? This also entails added complexity. Previously DNA checks whether the host still remains in the same link or not, then accordingly verify (or invalidate) all its addresses at the same time. > Let us assume that formerly router A announced a prefix from which the > host formed address A. Now with Simple DNA, the host tries to determine > if that address is still valid. In response to an RS, it receives an RA > from that same router with no known prefix. It can now conclude that > address A is not valid, under the assumption that the prefix should have > been included if the router was still advertising it. > > However, the host could also have formed another address B based on an > announcement from router B. With Simple DNA, the host sends a unicast NS > to router B which responds with a solicited NA. The host can now assume > that > address B is still valid -- unless it receives an RA from router B > that is missing the prefix from which that address was derived. IMO, the host can verify address B based on the verification of address A. If address A and B were valid in the same link and address A is proven still valid, it's reasonable to assume that address B also is still valid (except in some corner cases.) > [JC] Now I come to wonder why RA based decision is assumed definite. Maybe > it's better to make NS/NA based decision takes precedents over RA > based decision. > > [BA] Receipt of an RA is additional information which may invalidate an > assumption made as a result of receipt of an NA. For example, the RA > could indicate different prefixes, or a change in address assignment > mechanism (stateless to stateful or the other way around). I have in mind the following example. Assume a host is attached to a link with two access router R1 and R2 which advertise prefix 1 and prefix 2 respectively. The host autoconfigures address 1 with prefix 1. After a while, the host executes DNA and performs NUD with R1 and R2. When a solicited NA from R2 arrives to confirm R2's reachability, IMO, it's reasonable to assume that address 1 with prefix 1 is still valid, even though a solicited NA from R1 didn't arrive yet (or never). > In any case, I think it is important that we write all of this down in the > Simple DNAv6 draft so that we can evaluate it and understand how well it > works and under what conditions it might not work. agree. I wish simple DNA operation is presented more clearly lest we should argue over irrelevant issues. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jan 16 04:33:53 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF4ef-0000Fc-B5 for dna-archive@lists.ietf.org; Wed, 16 Jan 2008 04:33:53 -0500 Received: from kyle.its.monash.edu.au ([130.194.13.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF4ec-0000oT-V6 for dna-archive@lists.ietf.org; Wed, 16 Jan 2008 04:33:53 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUQ00LYGD8DEUV0@kyle.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Jan 2008 20:33:49 +1100 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CF4E4AB548; Wed, 16 Jan 2008 20:33:48 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0281A4FB0A; Wed, 16 Jan 2008 20:33:46 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0G9V4r24203 for dna-list; Wed, 16 Jan 2008 20:31:04 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0G9V3Q24199 for ; Wed, 16 Jan 2008 20:31:03 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUQ008019MYSX00@kenny.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 16 Jan 2008 20:31:04 +1100 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUQ00HTVD3Q3EX0@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Wed, 16 Jan 2008 20:31:04 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 25683AB542; Wed, 16 Jan 2008 20:31:04 +1100 (EST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by curly.its.monash.edu.au (Postfix) with ESMTP id EC7984FB09 for ; Wed, 16 Jan 2008 20:31:02 +1100 (EST) Received: by fg-out-1718.google.com with SMTP id 22so213768fge.23 for ; Wed, 16 Jan 2008 01:31:00 -0800 (PST) Received: by 10.78.200.3 with SMTP id x3mr471867huf.0.1200475859976; Wed, 16 Jan 2008 01:30:59 -0800 (PST) Received: by 10.78.158.5 with HTTP; Wed, 16 Jan 2008 01:30:59 -0800 (PST) Date: Wed, 16 Jan 2008 14:00:59 +0430 From: JinHyeock Choi Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: <478C3050.8080801@ericsson.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Suresh Krishnan Cc: Bernard Aboba , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <92e919fb0801160130i78e76f5ek7f0acfe47f9a0577@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=k7Sv5wvyVYKFUbc2yrQTO0R7a7XP9Ttv/Mmlb2dlR6w=; b=kYIdsBEhUYmzluywP/vAu9sMpl+Ykg02RhTforbk8gwqiBABdertCeSVPWHyf2TCi5N/h43pcf0DYUHavdBnDhz3B2IsuLknrQZ85RRR6tO8PJi7VlffJcwrorv6ABMTHuOFkBd4yAQ/J9vdMk+QZTRqow6DNVeS0Yw96SDJD7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UzBmVIMZu+5yezCjtkHLQhMJEwDUbnIF0ghjHHMUhKxPzwDzuvbjqV+aWmRlDL2gNjA6I9Nk/l1ZKtJjdnysMcW86NPOxbLouhPfRFuS1Un5ee+8yriCHyjYvFyTFA1gryPH8kBseecfJfCj/SVSGG3mfZ0YUmTxe9rpvQBg2y0= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> <478C3050.8080801@ericsson.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Dear Suresh > I have to admit that when we wrote the draft, we did not consider the > precedence between the NS/NA tests and the RS/RA test. The way I see it > today, an RA from a router containing disjoint prefixes will only > override a positive NA confirmation from the same router and other than > this there will be no interaction between the NS/NA tests and te RS/RA > tests. I will give this a little more thought and come up with some text > on this regard. I'm not sure such an intricate deliberation is necessary. In the first place, simple DNA is supposed to be simple even though it may not cover some corner cases. For example, simple DNA can work as below. 1. In a link, a host generates 1) router list and 2) prefix list. 2. Upon initiating DNA, the host performs 1) NUD with routers and 2) Router/ Prefix discovery. 3. If a solicited NA from a known router arrives, the host assumes that 1) it still remains at the same link and 2) its addresses are still valid (but it may perform oDAD in case). and turn-off DNA. 4. If no solicited NA arrives and an RA with no known prefix arrives, the host assumes that it has moves to another link and invalidates all its addresses. Then we don't have to worry about RA sources but the above will work for most of the cases. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jan 17 01:47:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFOWj-0004uW-I7 for dna-archive@lists.ietf.org; Thu, 17 Jan 2008 01:47:01 -0500 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFOWi-0002iF-L0 for dna-archive@lists.ietf.org; Thu, 17 Jan 2008 01:47:01 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUS00AZX06425P0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 17 Jan 2008 17:46:53 +1100 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 88FE2AB549; Thu, 17 Jan 2008 17:46:52 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 831624FB04; Thu, 17 Jan 2008 17:46:50 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0H6gHU29174 for dna-list; Thu, 17 Jan 2008 17:42:17 +1100 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0H6gBQ29170 for ; Thu, 17 Jan 2008 17:42:11 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUR00201WFHLA00@cartman.its.monash.edu.au> (original mail from bernard_aboba@hotmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 17 Jan 2008 17:42:11 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUR00E2SZY98PU0@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Thu, 17 Jan 2008 17:42:11 +1100 (EST) Received: by localhost (Postfix, from userid 510) id AAD74AB542; Thu, 17 Jan 2008 17:42:11 +1100 (EST) Received: from bay0-omc1-s22.bay0.hotmail.com (bay0-omc1-s22.bay0.hotmail.com [65.54.246.94]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9E9824FB09; Thu, 17 Jan 2008 17:42:10 +1100 (EST) Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc1-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 22:42:04 -0800 Date: Wed, 16 Jan 2008 22:42:29 -0800 From: Bernard_Aboba@hotmail.com Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> <92e919fb0801141917s3acc44c1gf59d5a765a5cb5f3@mail.gmail.com> <92e919fb0801160113x49221875h9a283b4ae0ee2a07@mail.gmail.com> X-Originating-IP: [67.183.152.50] Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Suresh Krishnan , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V12.0.1606 X-Mailer: Microsoft Windows Live Mail 12.0.1606 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-Unsent: 1 References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> <92e919fb0801141917s3acc44c1gf59d5a765a5cb5f3@mail.gmail.com> <92e919fb0801160113x49221875h9a283b4ae0ee2a07@mail.gmail.com> X-OriginalArrivalTime: 17 Jan 2008 06:42:04.0429 (UTC) FILETIME=[125A7BD0:01C858D4] X-Spam-Level: X-Spam-Score: 1.7 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 >> [BA] The way I think of it is that the host needs to determine >> whether its existing addresses are valid. It can determine that based >> on receipt of an NS from a router, or receipt of RAs. > > From your remark, I assume that a host verifies its addresses one bye > one. The verification of one address doesn't guarantee the validity of > others, right? The host verifies a subset of routers which generated valid addresses by doing NUD to them and sending an RS. Verifying reachability via NUD confirms all prefixes formerly advertised by that router, so it can validate multiple addresses at once. > This also entails added complexity. Previously DNA checks whether the > host still remains in the same link or not, then accordingly verify > (or invalidate) all its addresses at the same time. Simple DNA can do the same thing, by verifying all addresses obtained from the same router simultaneously. Since there are typically only a few valid addresses, it is not a complex operation to send a few NSes and one RS. > IMO, the host can verify address B based on the verification of > address A. If address A and B were valid in the same link and address > A is proven still valid, it's reasonable to assume that address B also > is still valid (except in some corner cases.) If router B is no longer present, and does not answer NS or send RAs for prefix B, then the host probably should not conclude that address B is still valid, even if router A is present and sends NA or RA. > I have in mind the following example. > > Assume a host is attached to a link > with two access router R1 and R2 > which advertise prefix 1 and prefix 2 respectively. > > The host autoconfigures address 1 with prefix 1. > > After a while, the host executes DNA and performs NUD with R1 and R2. > > When a solicited NA from R2 arrives to confirm R2's reachability, > IMO, it's reasonable to assume that > address 1 with prefix 1 is still valid, > even though a solicited NA from R1 didn't arrive yet (or never). Simple DNA will perform NUD to R1 and R2 simultaneous with sending an RS. When the solicited NA arrives from R1 it will autoconfigure address 1. If R2 answers the NS, it will autoconfigure address 2. It will also process the RAs from R1 and/or R2. However, if R2 doesn't answer the unicast NS or the RS, then it won't auto-configure address 2 until it hears evidence that R2 is still there. From dna-owner@webcamserver.eng.monash.edu.au Sat Jan 19 01:08:28 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG6sW-000831-Gi for dna-archive@lists.ietf.org; Sat, 19 Jan 2008 01:08:28 -0500 Received: from cartman.its.monash.edu.au ([130.194.13.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG6sV-0007wj-Km for dna-archive@lists.ietf.org; Sat, 19 Jan 2008 01:08:28 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUV00IFTNQ1FS80@cartman.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 19 Jan 2008 17:08:25 +1100 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFAA9AB545; Sat, 19 Jan 2008 17:08:24 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id D3AB14FB03; Sat, 19 Jan 2008 17:08:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id m0J64Ke07692 for dna-list; Sat, 19 Jan 2008 17:04:20 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id m0J64JQ07688 for ; Sat, 19 Jan 2008 17:04:19 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JUV00K01JSG7U00@kyle.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 19 Jan 2008 17:04:19 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JUV009MFNJ7WHG0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 19 Jan 2008 17:04:19 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 919D2AB544; Sat, 19 Jan 2008 17:04:19 +1100 (EST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by moe.its.monash.edu.au (Postfix) with ESMTP id 488214FB07 for ; Sat, 19 Jan 2008 17:04:16 +1100 (EST) Received: by mu-out-0910.google.com with SMTP id i10so1057496mue.3 for ; Fri, 18 Jan 2008 22:04:14 -0800 (PST) Received: by 10.78.136.9 with SMTP id j9mr5971898hud.46.1200722653932; Fri, 18 Jan 2008 22:04:13 -0800 (PST) Received: by 10.78.158.5 with HTTP; Fri, 18 Jan 2008 22:04:13 -0800 (PST) Date: Sat, 19 Jan 2008 10:34:13 +0430 From: JinHyeock Choi Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard_Aboba@hotmail.com Cc: Suresh Krishnan , dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <92e919fb0801182204v22692edar85a31cfa2252c6eb@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OAxcc8soBU7IOmpV/Z0OCQluzZ/OUMU82pZF9vb3RTg=; b=oBkkIxZG4wGzsWnB1I96DD1a71yIV7u6xJt4hwPmu0POvbKHPlxLxK8E1ML395dh7mDtatZxaXgsDyLoHOAKJ9YG3bSEuQyzF19CV5Ck2bMNsvSXlKLy47jUAJkfxtjTv3z3kBn6ZUVIvAZDGGwKGI0kMZWT+u7ReKYWaFMZcLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IR/4f/HMCUdAdQ+DAGyDvi9jtVPW8wHRVEvU4f5OPxhi0Oelb8YTIMXJjTrf9PkpdRSrFOlLf2etgK3brRBvbyqXSLZKECr72FezG3h4DnhI75gw9It0M5R9tQBSqwluD3j0sz6ZyeYr7UtioycGE204ySv6Du89vkOuNOihatU= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> <92e919fb0801140159j35fc64bbj8bb17dc0d62d5009@mail.gmail.com> <92e919fb0801141241n75f4cf0fic3da617d43ca935f@mail.gmail.com> <92e919fb0801141917s3acc44c1gf59d5a765a5cb5f3@mail.gmail.com> <92e919fb0801160113x49221875h9a283b4ae0ee2a07@mail.gmail.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Bernard now I come to understand simple DNA procedures the better. thanks for your clarification. > The host verifies a subset of routers which generated valid addresses by > doing > NUD to them and sending an RS. Verifying reachability via NUD confirms all > prefixes formerly advertised by that router, so it can validate > multiple addresses at once. ok. Simple DNA verifies addresses per a router, whereas previous DNA verifies addresses per a link. > > IMO, the host can verify address B based on the verification of > > address A. If address A and B were valid in the same link and address > > A is proven still valid, it's reasonable to assume that address B also > > is still valid (except in some corner cases.) > > If router B is no longer present, and does not answer NS or send > RAs for prefix B, then the host probably should not conclude that > address B is still valid, even if router A is present and sends NA or RA. The above will happen only when router B becomes out of order during DNA procedure. It may be a corner case which simple DNA don't have to worry. > > I have in mind the following example. > > > > Assume a host is attached to a link > > with two access router R1 and R2 > > which advertise prefix 1 and prefix 2 respectively. > > > > The host autoconfigures address 1 with prefix 1. > > > > After a while, the host executes DNA and performs NUD with R1 and R2. > > > > When a solicited NA from R2 arrives to confirm R2's reachability, > > IMO, it's reasonable to assume that > > address 1 with prefix 1 is still valid, > > even though a solicited NA from R1 didn't arrive yet (or never). > > Simple DNA will perform NUD to R1 and R2 simultaneous with sending an > RS. When the solicited NA arrives from R1 it will autoconfigure address 1. > If R2 answers the NS, it will autoconfigure address 2. It will also > process > the RAs from R1 and/or R2. However, if R2 doesn't answer the unicast NS > or the RS, then it won't auto-configure address 2 until it hears evidence > that > R2 is still there. The example above is not about how a host would autoconfigure a new address in relationship with DNA operation but about how a host would verify (already autoconfigured) existing addresses. IMO, when the host receives a solicted NA from R1, the host can use the existing address 2 (configured with the information from R2) even if it hears no evidence that R2 is still there. At least, that's how current DNA operates. Thanks for your kind consideration. Best Regards JinHyeock