From ipv6-bounces@ietf.org Mon Jan 01 07:27:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1MDP-0003UI-76; Mon, 01 Jan 2007 07:24:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1MDN-0003QP-Kr for ipv6@ietf.org; Mon, 01 Jan 2007 07:24:29 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1MDM-0007IL-2G for ipv6@ietf.org; Mon, 01 Jan 2007 07:24:29 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l01COQIi102680 for ; Mon, 1 Jan 2007 12:24:26 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l01COQSw1884370 for ; Mon, 1 Jan 2007 12:24:26 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l01COQbG004582 for ; Mon, 1 Jan 2007 12:24:26 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l01COQEg004575; Mon, 1 Jan 2007 12:24:26 GMT Received: from [9.4.210.199] ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA69676; Mon, 1 Jan 2007 13:24:24 +0100 Message-ID: <4598FD78.3020404@zurich.ibm.com> Date: Mon, 01 Jan 2007 13:24:24 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brian Haberman References: <4593CEF5.50308@innovationslab.net> In-Reply-To: <4593CEF5.50308@innovationslab.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ipv6@ietf.org, Pekka Savola Subject: Re: RFC2461(bis): normativeness of protocol constants X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2006-12-28 15:04, Brian Haberman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Pekka Savola wrote: >> Hi, >> >> Speaking of RFC 2461(bis), some time ago I noticed the following >> behaviour with a popular router implementation (a support case is open >> on this): for forwarded packets, it takes up to 24 hours (in recent >> software versions, up to 20 minutes) for the hardware forwarding to >> notice that an IP address moved from one link-layer address to another >> on the same link if unsolicited NAs (section 7.2.6, only an >> optimization; few host implementations seem to send these) are not sent >> by the hosts. >> >> My reading of the spec is that this is not compliant with RFC2461, where >> protocol constants are REACHABLE_TIME (30s) and DELAY_FIRST_PROBE_TIME >> (5s) -- unreachability detection could take about 35 times longer than >> the spec. >> >> However, the spec doesn't say whether the defined protocol constants are >> normative, and this could be explicitly stated if that's deemed a >> necessary addition. >> >> Any thoughts? >> > > Given that 2461 (and 2461bis) are DS, I would find it very disturbing if > implementers did not treat the entire document as normative. In order > to be compliant with a spec (any spec), an implementation MUST adhere to > all aspects including protocol constants. Otherwise, how would we ever > have interoperability? I do not see any benefit in having any > specification state *which* components of the document are normative. > > Regards, > Brian But that is why we have the RFC 2119 keywords; and they do have value when working out what to test at an interop. I think it would be safer, even if logically redeundant, to prefix section 10 with a sentence stating that the listed values MUST be used. Also there are some lower case "shoulds" in the paragraph about ReachableTime - are those intended to be normative? Regards, Another Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 04 02:29:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Mye-0005rm-La; Thu, 04 Jan 2007 02:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Myd-0005rg-SF for ipv6@ietf.org; Thu, 04 Jan 2007 02:25:27 -0500 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2MyX-0002Kt-Vo for ipv6@ietf.org; Thu, 04 Jan 2007 02:25:27 -0500 Received: from PC20005 ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070104072505.WYWH14364.omta05sl.mx.bigpond.com@PC20005>; Thu, 4 Jan 2007 07:25:05 +0000 From: "Hesham Soliman" To: "'Brian Haberman'" , "'Pekka Savola'" Date: Thu, 4 Jan 2007 18:24:59 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccqjoBT3mXTcl93QVK5iTDWrZm6xwFQn33Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4593CEF5.50308@innovationslab.net> Message-Id: <20070104072505.WYWH14364.omta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ipv6@ietf.org Subject: RE: RFC2461(bis): normativeness of protocol constants X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Catching up on email.. > Pekka Savola wrote: > > Hi, > > > > Speaking of RFC 2461(bis), some time ago I noticed the following > > behaviour with a popular router implementation (a support > case is open > > on this): for forwarded packets, it takes up to 24 hours (in recent > > software versions, up to 20 minutes) for the hardware forwarding to > > notice that an IP address moved from one link-layer > address to another > > on the same link if unsolicited NAs (section 7.2.6, only an > > optimization; few host implementations seem to send these) > are not sent > > by the hosts. > > > > My reading of the spec is that this is not compliant with > RFC2461, where > > protocol constants are REACHABLE_TIME (30s) and > DELAY_FIRST_PROBE_TIME > > (5s) -- unreachability detection could take about 35 times > longer than > > the spec. > > > > However, the spec doesn't say whether the defined protocol > constants are > > normative, and this could be explicitly stated if that's deemed a > > necessary addition. > > > > Any thoughts? > > > > In order > to be compliant with a spec (any spec), an implementation > MUST adhere to > all aspects including protocol constants. Otherwise, how > would we ever > have interoperability? => I agree with this. Pekka himself mentioned that this is not a compliant behviour according to 2461. A contant is a *contant*, which means it doesn't change :) .... Variables are also given max and min values, which by the english meaning of max and min implies that you can't go outside those boundaries. So I don't see the gain in adding that "protocol constants MUST be used" or something like that. Hesham I do not see any benefit in having any > specification state *which* components of the document are normative. > > Regards, > Brian > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFk871FShYTeGgKiYRCPx8AKC8V6OuAVzbTouoPkQcP928EeifYACdEYnR > Z4w2IEwW0XV18LLxOWTSlvc= > =J1Ds > -----END PGP SIGNATURE----- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 04 02:40:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NCG-0005ws-To; Thu, 04 Jan 2007 02:39:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2NCE-0005wi-Uh for ipv6@ietf.org; Thu, 04 Jan 2007 02:39:30 -0500 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2NCD-00049Q-7P for ipv6@ietf.org; Thu, 04 Jan 2007 02:39:30 -0500 Received: from oaamta02sl.mx.bigpond.com ([124.191.178.123]) by omta02sl.mx.bigpond.com with ESMTP id <20070104073922.UYRX17746.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Thu, 4 Jan 2007 07:39:22 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005>; Thu, 4 Jan 2007 07:39:21 +0000 From: "Hesham Soliman" To: "'Alexandru Petrescu'" Date: Thu, 4 Jan 2007 18:39:15 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Accl2i/lgHeaXC8qS1KbNUE2FesHDQJ93oSA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <458BF378.1040308@motorola.com> Message-Id: <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ipv6@ietf.org Subject: RE: point-to-point links and ND (was: Review of draft-ietf-ipv6-2461bis-09.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Hi Hesham, please allow me to interfere, splitting the thread to a > different topic. I do not give an oppinion in this message about the > original message's comments. > > Do you or co-authors think it may be useful to add several > clarifications in the 2461bis with respect to how ND would run on > point-to-point links? => I don't think this spec is the right place for it. Let me give some context to the discussion. The term p-to-p links is actually a larger umbrella than its common use seems to imply. Under this umbrella you'll find many cellular *systems* that emulate their systems as point to point links. The requirements vary significantly. And unfortunately, due to the lack of good definitions and common language we will find that a lot of people will have their own requirements (initiated by their systems) for point to point links. As far as ND is concerned point to point links have a narrow meaning (mainly related to multicast support). BTW, this topic was supposed to be included to the charter according to the meeting in San Francisco a few years ago but I don't know what happened to it. > > For example, the draft says multicast 'can' be trivially provided on > point to point links, and interfaces 'can' be assigned link-local > addresses. But does this mean that a host should do a MLD JOIN on a > point to point link. => The spec says that nothing needs to be done for those links, so yes do an MLD join, what's wrong with that? It may be inefficient, but it doesn't break anything in the spec AFAIK. Does this mean that a packet sent to a > link-local > multicast address sent by one end should be received by the > other w/ or > w/o doing MLD JOIN. => Please see above. Does this mean the node should join the > solicited-node multicast address (derived from its IID) when over a > point-to-point link? => Why not? That's the default operation in the spec and it clearly states that nothing needs to be done differently for those links. > Another aspect is the use of S/TLLAOs on links with no link-layer > headers, typically point to point. => No link layer header? I guess you mean no link layer addresses. For example, is it mandatory to > _not_ use S/TLLAOs if there's no link-layer header, or should they be > used instead. > > For example this text: > > Target link-layer address The link-layer address for the target, > > i.e., the sender of the advertisement. This option MUST > be included > > on link layers that have addresses when responding to multicast > > solicitations. When responding to a unicast Neighbor Solicitation > > this option SHOULD be included. > > First, should a NS over point to point link be unicasted or > multicasted, > in terms of its dst address. Second, it says this option MUST be > included when link-layer has addresses. It doesn't say it > shouldn't be > included if the link-layer doesn't have addresses. => I think that's pretty obvious from the condition in the text. The inclusion is bound to the existence of an address. I think it should > either say that or its contrary, but not be silent on this. => It's not silent IMO, it does say it. > > Finally, link-layer addresses have a tight relationship with > what goes > in the last 64bits of an address. On ppp (and maybe others?) links > there's no link-layer address but there's means to have something go > into the last 64bits. So could we consider that IID to be a > link-layer > address. => No we can't, the IID is in a completely different layer. The fact that you can use an L2 address to generate the IID, does not mean you can use the IID as an L2 address. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 04 06:05:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2QM4-0001WX-GV; Thu, 04 Jan 2007 06:01:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2QM2-0001WQ-RQ for ipv6@ietf.org; Thu, 04 Jan 2007 06:01:50 -0500 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2QM1-00024E-9k for ipv6@ietf.org; Thu, 04 Jan 2007 06:01:50 -0500 Received: from oaamta01ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070104110139.OGGZ24786.omta01ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com>; Thu, 4 Jan 2007 11:01:39 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01ps.mx.bigpond.com with ESMTP id <20070104110135.XTVV12380.oaamta01ps.mx.bigpond.com@PC20005>; Thu, 4 Jan 2007 11:01:35 +0000 From: "Hesham Soliman" To: "'Hesham Soliman'" , "'Brian Haberman'" , "'Pekka Savola'" Date: Thu, 4 Jan 2007 22:01:25 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AccqjoBT3mXTcl93QVK5iTDWrZm6xwFQn33QAAenGIA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070104110135.XTVV12380.oaamta01ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipv6@ietf.org Subject: RE: RFC2461(bis): normativeness of protocol constants X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > => I agree with this. Pekka himself mentioned that this is > not a compliant behviour according to 2461. A contant is a > *contant*, which means it doesn't change :) .... => I obviously meant constant :) Hesham > Variables are also given max and min values, which by the > english meaning of max and min implies that you can't go > outside those boundaries. So I don't see the gain in adding > that "protocol constants MUST be used" or something like that. > > Hesham > > > > > > > > I do not see any benefit in having any > > specification state *which* components of the document > are normative. > > > > Regards, > > Brian > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (Darwin) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFFk871FShYTeGgKiYRCPx8AKC8V6OuAVzbTouoPkQcP928EeifYACdEYnR > > Z4w2IEwW0XV18LLxOWTSlvc= > > =J1Ds > > -----END PGP SIGNATURE----- > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 04 12:48:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WfK-0007um-P9; Thu, 04 Jan 2007 12:46:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WfJ-0007r8-Og for ipv6@ietf.org; Thu, 04 Jan 2007 12:46:09 -0500 Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WfF-0001ve-07 for ipv6@ietf.org; Thu, 04 Jan 2007 12:46:09 -0500 Received: from vms171.mailsrvcs.net ([192.168.1.2]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JBC00D74UOJOARO@vms040.mailsrvcs.net> for ipv6@ietf.org; Thu, 04 Jan 2007 11:45:55 -0600 (CST) Received: from 129.55.200.20 ([129.55.200.20]) by vms171.mailsrvcs.net (Verizon Webmail) with HTTP; Thu, 04 Jan 2007 11:45:55 -0600 (CST) Date: Thu, 04 Jan 2007 11:45:55 -0600 (CST) From: Tim Enos X-Originating-IP: [129.55.200.20] To: Hesham Soliman , 'Brian Haberman' , 'Pekka Savola' Message-id: <18867022.2792171167932755554.JavaMail.root@vms171.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ipv6@ietf.org Subject: RE: RFC2461(bis): normativeness of protocol constants X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Good afternoon, >From: Hesham Soliman >Date: 2007/01/04 Thu AM 01:24:59 CST >To: 'Brian Haberman' , 'Pekka Savola' >Cc: ipv6@ietf.org >Subject: RE: RFC2461(bis): normativeness of protocol constants >Catching up on email.. > > > Pekka Savola wrote: > > > Hi, > > > > > > Speaking of RFC 2461(bis), some time ago I noticed the following > > > behaviour with a popular router implementation (a support > > case is open > > > on this): for forwarded packets, it takes up to 24 hours (in recent > > > software versions, up to 20 minutes) for the hardware forwarding to > > > notice that an IP address moved from one link-layer > > address to another > > > on the same link if unsolicited NAs (section 7.2.6, only an > > > optimization; few host implementations seem to send these) > > are not sent > > > by the hosts. > > > > > > My reading of the spec is that this is not compliant with > > RFC2461, where > > > protocol constants are REACHABLE_TIME (30s) and > > DELAY_FIRST_PROBE_TIME > > > (5s) -- unreachability detection could take about 35 times > > longer than > > > the spec. > > > > > > However, the spec doesn't say whether the defined protocol > > constants are > > > normative, and this could be explicitly stated if that's deemed a > > > necessary addition. > > > > > > Any thoughts? > > > > > > > In order > > to be compliant with a spec (any spec), an implementation > > MUST adhere to > > all aspects including protocol constants. I agree. Otherwise, how > > would we ever > > have interoperability? > >=> I agree with this. Pekka himself mentioned that this is not a compliant >behviour according to 2461. A contant is a *contant*, which means it doesn't >change :) .... At least they don't change for implementations on the same link-layer type. >Variables are also given max and min values, which by the english meaning of >max and min implies that you can't go outside those boundaries. Exactly. So I don't >see the gain in adding that "protocol constants MUST be used" or something >like that. Agreed, but explicitly stating it would seem to reduce the likelihood that designers/implementers would stray. I say 'reduce' as opposed to 'eliminate' as in other cases I've seen implementations hard-code variable values where the spec explicitly said they MUST be configurable. > >Hesham Best Regards, Tim Enos Rom 8:28 > > > > > > > >I do not see any benefit in having any > > specification state *which* components of the document are normative. > > > > Regards, > > Brian > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (Darwin) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFFk871FShYTeGgKiYRCPx8AKC8V6OuAVzbTouoPkQcP928EeifYACdEYnR > > Z4w2IEwW0XV18LLxOWTSlvc= > > =J1Ds > > -----END PGP SIGNATURE----- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 04 13:55:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XiJ-0007Br-5W; Thu, 04 Jan 2007 13:53:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XiI-0007BR-5A for ipv6@ietf.org; Thu, 04 Jan 2007 13:53:18 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2XiG-0004iJ-Q4 for ipv6@ietf.org; Thu, 04 Jan 2007 13:53:18 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1167936789!7977697!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 19727 invoked from network); 4 Jan 2007 18:53:09 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-119.messagelabs.com with SMTP; 4 Jan 2007 18:53:09 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l04Ir4q9008030; Thu, 4 Jan 2007 11:53:04 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l04Ir2U9011691; Thu, 4 Jan 2007 12:53:03 -0600 (CST) Message-ID: <459D4D0D.2010806@motorola.com> Date: Thu, 04 Jan 2007 19:53:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hesham Soliman References: <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005> In-Reply-To: <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ipv6@ietf.org Subject: Re: point-to-point links and ND (was: Review of draft-ietf-ipv6-2461bis-09.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hesham Soliman wrote: > >> Hi Hesham, please allow me to interfere, splitting the thread to a >> different topic. I do not give an oppinion in this message about >> the original message's comments. >> >> Do you or co-authors think it may be useful to add several >> clarifications in the 2461bis with respect to how ND would run on >> point-to-point links? > > => I don't think this spec is the right place for it. Let me give > some context to the discussion. The term p-to-p links is actually a > larger umbrella than its common use seems to imply. Under this > umbrella you'll find many cellular *systems* that emulate their > systems as point to point links. Emulate as ptp links? Sounds strange. I thought they'd emulate shared links over ptp. What are these systems you mention? I think you may be wrong cell-system ptp links are emulated. Emulation of what on top of what. I think maybe you don't talk about emulation but about real ppp interfaces provided by a wide range of cell-systems. > The requirements vary significantly. And unfortunately, due to the > lack of good definitions and common language we will find that a lot > of people will have their own requirements (initiated by their > systems) for point to point links. It still holds that ppp protocol runs over a very wide range of such cellular point to point links, regardless of the system builders requirements. > As far as ND is concerned point to point links have a narrow meaning > (mainly related to multicast support). Well, ND to run over ppp links means ND to run on much more than just cell-systems. All these are concerned by ND clarifications. > BTW, this topic was supposed to be included to the charter according > to the meeting in San Francisco a few years ago but I don't know > what happened to it. I was not aware of that. I'm not after a new Charter item, just document clarification for pursuing along the Standards Track. >> For example, the draft says multicast 'can' be trivially provided >> on point to point links, and interfaces 'can' be assigned >> link-local addresses. But does this mean that a host should do a >> MLD JOIN on a point to point link. > > => The spec says that nothing needs to be done for those links, so > yes do an MLD join, what's wrong with that? It may be inefficient, > but it doesn't break anything in the spec AFAIK. That reads like a suggestion for a 'MAY', to which I somehow agree. In a certain context, widespread IP implementations qualify a p2p link as non-ND capable, while by your interpretation the spec says nothing should be done about those links - if so just remove all the p2p language from ND text. >> Does this mean the node should join the solicited-node multicast >> address (derived from its IID) when over a point-to-point link? > > => Why not? That's the default operation in the spec and it clearly > states that nothing needs to be done differently for those links. Well that's a hidden statement; it should better say "do MLD on p2p links". Or say "don't do MLD on p2p links", or MAY or so. Implementations don't. >> Another aspect is the use of S/TLLAOs on links with no link-layer >> headers, typically point to point. > > => No link layer header? I guess you mean no link layer addresses. I meant both. On most ptp links the IP stack doesn't build a link-layer header and there are no link-layer addresses; on some IEEE ptp links there's an id identifying the pair of two ends. >>> For example this text: Target link-layer address The link-layer >>> address for the target, i.e., the sender of the advertisement. >>> This option MUST be included on link layers that have addresses >>> when responding to multicast solicitations. When responding to a >>> unicast Neighbor Solicitation this option SHOULD be included. >> >> First, should a NS over point to point link be unicasted or >> multicasted, in terms of its dst address. Second, it says this >> option MUST be included when link-layer has addresses. It doesn't >> say it shouldn't be included if the link-layer doesn't have >> addresses. > > => I think that's pretty obvious from the condition in the text. The > inclusion is bound to the existence of an address. It says it "SHOULD" include a TLLAO in the NA for a received unicasted NS. It doesn't condition that "SHOULD" on the existence of link-layer addresses. The condition is on the "MUST" and on the NA multicasted. Some implementation doesn't send NS to multicast addresses on the ptp link. So the implementer is left with the text that doesn't have that condition. I agree it may be a generic problem with long "MUST" phrases, but it's obviously a clarification needed (IMHO). >> I think it should either say that or its contrary, but not be >> silent on this. > > => It's not silent IMO, it does say it. read again: > This option [TLLAO] MUST be included on link layers that have > addresses when responding to multicast solicitations. Is there a non-written "and" between "have addresses" and "when responding to multicast"? Or an "or"? How do you like to read it? >> Finally, link-layer addresses have a tight relationship with what >> goes in the last 64bits of an address. On ppp (and maybe others?) >> links there's no link-layer address but there's means to have >> something go into the last 64bits. So could we consider that IID >> to be a link-layer address. > > => No we can't, the IID is in a completely different layer. The fact > that you can use an L2 address to generate the IID, does not mean > you can use the IID as an L2 address. Ok, I tend to think the same, too. But ppp gives an Interface ID and there's no other means in ppp to have an endpoint identifier. So the easiest way for ND to run over ppp would be to build some virtual link-layer headers with Interface IDs in it. All other ND mechanisms (multicast, DAD, etc) would run unmodified. We build virtual headers for csum and other AHish stuff, so why not for ND on ptp links. Widespread packet capture software builds 'cooked' headers too. An "Interface ID" is exactly what ND needs on a ppp link. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 04 15:14:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YxE-0007Zu-Fw; Thu, 04 Jan 2007 15:12:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YxC-0007Zo-Nu for ipv6@ietf.org; Thu, 04 Jan 2007 15:12:46 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Yx9-0006FS-4q for ipv6@ietf.org; Thu, 04 Jan 2007 15:12:46 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l04KCg6t016941 for ; Thu, 4 Jan 2007 13:12:42 -0700 (MST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l04KCfi2020218 for ; Thu, 4 Jan 2007 15:12:41 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l04KGh76021002; Thu, 4 Jan 2007 15:16:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l04KGhgO020999; Thu, 4 Jan 2007 15:16:43 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17821.24747.178330.936711@gargle.gargle.HOWL> Date: Thu, 4 Jan 2007 15:16:43 -0500 From: James Carlson To: Alexandru Petrescu In-Reply-To: <459D4D0D.2010806@motorola.com> References: <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005> <459D4D0D.2010806@motorola.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: Re: point-to-point links and ND (was: Review of draft-ietf-ipv6-2461bis-09.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Alexandru Petrescu writes: > >> Finally, link-layer addresses have a tight relationship with what > >> goes in the last 64bits of an address. On ppp (and maybe others?) > >> links there's no link-layer address but there's means to have > >> something go into the last 64bits. So could we consider that IID > >> to be a link-layer address. > > > > => No we can't, the IID is in a completely different layer. The fact > > that you can use an L2 address to generate the IID, does not mean > > you can use the IID as an L2 address. > > Ok, I tend to think the same, too. But ppp gives an Interface ID and > there's no other means in ppp to have an endpoint identifier. So the > easiest way for ND to run over ppp would be to build some virtual > link-layer headers with Interface IDs in it. All other ND mechanisms > (multicast, DAD, etc) would run unmodified. I'm very much opposed to this idea. Those Interface IDs are not link layer addresses. ND options including link layer addresses should be added _only_ when link layer addresses exist on the underlying media -- and they don't exist for point-to-point links. I fear changing this behavior to include Interface IDs instead of link layer addresses will confuse and break existing implementations. > An "Interface ID" is exactly what ND needs on a ppp link. Disagree. Why does it need _any_ link layer address? Why should it care? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 04 17:53:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bRY-0001SB-K8; Thu, 04 Jan 2007 17:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bRX-0001S5-Ln for ipv6@ietf.org; Thu, 04 Jan 2007 17:52:15 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2bRX-0006xz-5u for ipv6@ietf.org; Thu, 04 Jan 2007 17:52:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l04MqC48020549; Fri, 5 Jan 2007 00:52:13 +0200 Date: Fri, 5 Jan 2007 00:52:12 +0200 (EET) From: Pekka Savola To: Brian Haberman In-Reply-To: <4593CEF5.50308@innovationslab.net> Message-ID: References: <4593CEF5.50308@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2412/Thu Jan 4 02:53:52 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: RFC2461(bis): normativeness of protocol constants X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 28 Dec 2006, Brian Haberman wrote: > Given that 2461 (and 2461bis) are DS, I would find it very disturbing if > implementers did not treat the entire document as normative. In order > to be compliant with a spec (any spec), an implementation MUST adhere to > all aspects including protocol constants. Otherwise, how would we ever > have interoperability? I do not see any benefit in having any > specification state *which* components of the document are normative. Indeed -- but maybe I was not explicit enough. I see three things here: 1) With most of these constants, there is no interoperability issue if an implementation were to choose different values. Quickly looking, I wasn't able to see any defined constant that the current protocol would require to be exactly the way it is for interoperability. Instead, this is more of an issue of harmonizing protocol behaviour across implementations, not so much about interoperability. 2) Strictly speaking, if constants are normative, if an implementation has (say) REACHABLE_TIME of 10 seconds (three times "faster" than the spec) it should be considered incompliant. 3) in some other protocols what we have defined as constants could very well have been defined as suggested default values (for example). This is more than strictly required for interoperability. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 05 03:45:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kdY-000765-Mp; Fri, 05 Jan 2007 03:41:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kdV-000760-PR for ipv6@ietf.org; Fri, 05 Jan 2007 03:41:13 -0500 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2kdS-0004Dx-PB for ipv6@ietf.org; Fri, 05 Jan 2007 03:41:13 -0500 Received: from oaamta02ps.mx.bigpond.com ([124.191.178.123]) by omta02ps.mx.bigpond.com with ESMTP id <20070105084103.SDKI24597.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Fri, 5 Jan 2007 08:41:03 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070105084102.LOHC17919.oaamta02ps.mx.bigpond.com@PC20005>; Fri, 5 Jan 2007 08:41:02 +0000 From: "Hesham Soliman" To: "'Hesham Soliman'" , "'Ralph Droms'" , "'Thomas Narten'" Date: Fri, 5 Jan 2007 19:40:56 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AccT714WnL8L/n/iEduj3AARJOT6egR4cU0wArTRBaA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070105084102.LOHC17919.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ipv6@ietf.org, 'Brian Haberman' , 'Erik Nordmark' , 'Bob Hinden' , 'William Allen Simpson' Subject: RE: Review of draft-ietf-ipv6-2461bis-09.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hello again, This is a follow up on the comments we discussed earlier. Ralph, please let me know if you're ok with my suggestions below. The document is waiting on your response! The rest of your comments are all in the document. > > > I think this is general advice to people thinking about > > how ND applies > > > to link layers other than, say, ethernet. Clearly, ND > > applies to all > > > specs, unless superceded by another spec for a particular link > > > layer. That is all that this section is (IMO) trying to > > say. I.e., to > > > suggest when another spec might be needed and where not. > > > > I think I understand the meaning the text is supposed to > > convey. But the > > text doesn't seem (to me, anyway) to convey that meaning > > very well; I note > > your interpretation is qualified with "IMO" and perhaps > > another reader might > > have a different opinion? > > > > To be more concrete, it appears that the section is > > describing how or which > > parts of ND should be implemented on links with certain > > attributes. But the > > last several entries don't seem to be very clear or precise. > > => Ok, does anyone object to removing that statement from the spec? > The statemement I'm referring to is the one Ralph refers to above: > "Neighbor Discovery should be implemented as described in > this document." > It seems superfluous anyway. => So here is the text for the section in question: point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point-to-point links, and interfaces can be assigned link-local addresses.) multicast - Neighbor Discovery supports multicast capable links as described in this document. > > Yeah, I agree the text means "don't draw any conclusions > about on- or > > off-link is L bit is not set". What are the ramifications > > of the L bit not > > being set; what other parts of this or other protocols > are affected? > > => If the L bit is not set a host cannot assume that an > address is on-link, therefore it will send all packets to > its Default router, unless a redirect is received for a > particular address. => I've clarified the definition a bit more: L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is not set a host MUST NOT assume that an addresse derived from the prefix is on-link unless it is explicitly told in another message (e.g. Redirect). For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on- link and others being off-link. Any objections? > > Except for its use in supplying the initial for the 'A' > bit in prefix > > options... > > => I agree. So how about we state in the document that the > terms "stateless autoconfiguration" and "autonomous > autoconfiguration" are used interchangeably? People are > familiar with the meaning of the A flag and with the term > "stateless autoconfig", removing either one is probably > going to add more confusion than clarity. It might have to > be one of those imperfections of a doc that developed over a > long time. Is this ok? => Is this ok? Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 05 05:51:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mdX-0003wJ-LZ; Fri, 05 Jan 2007 05:49:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mdW-0003vo-Oa for ipv6@ietf.org; Fri, 05 Jan 2007 05:49:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2mdT-0005Ir-4c for ipv6@ietf.org; Fri, 05 Jan 2007 05:49:22 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2007 02:49:17 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l05AnI6m017186; Fri, 5 Jan 2007 02:49:18 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l05AnGIl012158; Fri, 5 Jan 2007 02:49:16 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 05:49:16 -0500 Received: from 10.86.242.17 ([10.86.242.17]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Jan 2007 10:49:15 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 05 Jan 2007 05:49:17 -0500 From: Ralph Droms To: Hesham Soliman , Thomas Narten Message-ID: Thread-Topic: Review of draft-ietf-ipv6-2461bis-09.txt Thread-Index: AccT714WnL8L/n/iEduj3AARJOT6egR4cU0wArTRBaAABK+Jew== In-Reply-To: <20070105084102.LOHC17919.oaamta02ps.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Jan 2007 10:49:16.0245 (UTC) FILETIME=[25124050:01C730B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5699; t=1167994158; x=1168858158; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Review=20of=20draft-ietf-ipv6-2461bis-09.txt=20 |Sender:=20; bh=tKJ/sqolStQ7HSOVWj4RLGWf9QGVXrlmT3K2p+Q+peQ=; b=PHH1XM0RBrWn6MQ4OB1MyELd8JvdWnzzJ703lKj3IBAYYyNcjkv6mAk4nFOxaIDk4eG1HB4q 0UTpzx9HjxLCPCrB8uO9xW3/7GtTJpfZkRxjqLUuzaIsRCoJDiv0DSPN; Authentication-Results: sj-dkim-7; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ipv6@ietf.org, 'Brian Haberman' , 'Erik Nordmark' , 'Bob Hinden' , 'William Allen Simpson' Subject: Re: Review of draft-ietf-ipv6-2461bis-09.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hesham - you're suggested revisions are fine with me. One typo - in the text for the on-link flag, s/addresse/address/ And, at the risk of being overly picky, after searching through the RFC for occurrences of "autoconfiguration", it seems there is some inconsistency in the use of other related terms, like autoconfiguration and address autoconfiguration (used for both SLAAC and DHCP). The definition in the terminology section seems OK: Address Autoconfiguration: How nodes automatically configure an address for an interface. ...referring to both stateless address autoconfiguration and DHCP. Howvever, at the end of section 2.3: (e.g., while verifying an address is unused during address autoconfiguration [ADDRCONF]) While this is not normative text, I use it as an example. If, in this case, "address autoconfiguration" refers to just SLAAC, it should be "stateless address autoconfiguration". On the other hand, if "address autoconfiguration" is correct, then there should be a reference to DHCPv6 (RFC 3315) as well as [ADDRCONF]. As another example, at the end of section 4.2: Prefix Information These options specify the prefixes that are on-link and/or are used for address autoconfiguration. Here, the reference should be to "stateless address autoconfiguration"; the prefix information is not used by a host using DHCP. I apologize for noticing this issue at the last minute. In response to the question about "stateless autoconfiguration" and "autonomous autoconfiguration", I wanted to see if there were other phrases using "autoconfiguration". That search lead to the discovery of the inconsistent uses of "autoconfiguration". - Ralph On 1/5/07 3:40 AM, "Hesham Soliman" wrote: > Hello again, > > This is a follow up on the comments we discussed earlier. Ralph, please let > me know if you're ok with my suggestions below. The document is waiting on > your response! The rest of your comments are all in the document. > >>>> I think this is general advice to people thinking about >>> how ND applies >>>> to link layers other than, say, ethernet. Clearly, ND >>> applies to all >>>> specs, unless superceded by another spec for a particular link >>>> layer. That is all that this section is (IMO) trying to >>> say. I.e., to >>>> suggest when another spec might be needed and where not. >>> >>> I think I understand the meaning the text is supposed to >>> convey. But the >>> text doesn't seem (to me, anyway) to convey that meaning >>> very well; I note >>> your interpretation is qualified with "IMO" and perhaps >>> another reader might >>> have a different opinion? >>> >>> To be more concrete, it appears that the section is >>> describing how or which >>> parts of ND should be implemented on links with certain >>> attributes. But the >>> last several entries don't seem to be very clear or precise. >> >> => Ok, does anyone object to removing that statement from the spec? >> The statemement I'm referring to is the one Ralph refers to above: >> "Neighbor Discovery should be implemented as described in >> this document." >> It seems superfluous anyway. > > => So here is the text for the section in question: > > point-to-point - Neighbor Discovery handles such links just like > multicast links. (Multicast can be trivially > provided on point-to-point links, and interfaces > can be assigned link-local addresses.) > > > multicast - Neighbor Discovery supports multicast capable > links as described in this document. > > >>> Yeah, I agree the text means "don't draw any conclusions >> about on- or >>> off-link is L bit is not set". What are the ramifications >>> of the L bit not >>> being set; what other parts of this or other protocols >> are affected? >> >> => If the L bit is not set a host cannot assume that an >> address is on-link, therefore it will send all packets to >> its Default router, unless a redirect is received for a >> particular address. > > => I've clarified the definition a bit more: > > L 1-bit on-link flag. When set, indicates that this > prefix can be used for on-link determination. When > not set the advertisement makes no statement about > on-link or off-link properties of the prefix. In > other words, if the L flag is not set a host MUST > NOT assume that an addresse derived from the prefix > is on-link unless it is explicitly told in another > message (e.g. Redirect). For instance, the prefix > might be used for address configuration with some > of the addresses belonging to the prefix being on- > link and others being off-link. > > Any objections? > >>> Except for its use in supplying the initial for the 'A' >> bit in prefix >>> options... >> >> => I agree. So how about we state in the document that the >> terms "stateless autoconfiguration" and "autonomous >> autoconfiguration" are used interchangeably? People are >> familiar with the meaning of the A flag and with the term >> "stateless autoconfig", removing either one is probably >> going to add more confusion than clarity. It might have to >> be one of those imperfections of a doc that developed over a >> long time. Is this ok? > > => Is this ok? > > > Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 05 06:38:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nOF-0005VQ-FR; Fri, 05 Jan 2007 06:37:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nOE-0005VC-IM for ipv6@ietf.org; Fri, 05 Jan 2007 06:37:38 -0500 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nOC-0002Ss-1W for ipv6@ietf.org; Fri, 05 Jan 2007 06:37:38 -0500 Received: from oaamta04ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070105113727.KYPX295.omta04ps.mx.bigpond.com@oaamta04ps.mx.bigpond.com>; Fri, 5 Jan 2007 11:37:27 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04ps.mx.bigpond.com with ESMTP id <20070105113726.IWWL29846.oaamta04ps.mx.bigpond.com@PC20005>; Fri, 5 Jan 2007 11:37:26 +0000 From: "Hesham Soliman" To: "'Ralph Droms'" , "'Thomas Narten'" Date: Fri, 5 Jan 2007 22:37:19 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AccT714WnL8L/n/iEduj3AARJOT6egR4cU0wArTRBaAABK+JewABhC9A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070105113726.IWWL29846.oaamta04ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: ipv6@ietf.org, 'Brian Haberman' , 'Erik Nordmark' , 'Bob Hinden' , 'William Allen Simpson' Subject: RE: Review of draft-ietf-ipv6-2461bis-09.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > Hesham - you're suggested revisions are fine with me. => Ok, thanks! > > One typo - in the text for the on-link flag, s/addresse/address/ => Done. > > And, at the risk of being overly picky, after searching > through the RFC for > occurrences of "autoconfiguration", it seems there is some > inconsistency in > the use of other related terms, like autoconfiguration and address > autoconfiguration (used for both SLAAC and DHCP). > > The definition in the terminology section seems OK: > > Address Autoconfiguration: How nodes automatically configure an > address for an interface. > > ...referring to both stateless address autoconfiguration and DHCP. > > Howvever, at the end of section 2.3: > > (e.g., while verifying an address is unused > during address autoconfiguration [ADDRCONF]) > > While this is not normative text, I use it as an example. > If, in this case, > "address autoconfiguration" refers to just SLAAC, it should > be "stateless > address autoconfiguration". On the other hand, if "address > autoconfiguration" is correct, then there should be a > reference to DHCPv6 > (RFC 3315) as well as [ADDRCONF]. > > As another example, at the end of section 4.2: > > Prefix Information > These options specify the prefixes that > are on-link > and/or are used for address autoconfiguration. > > Here, the reference should be to "stateless address > autoconfiguration"; the > prefix information is not used by a host using DHCP. => Understood. I'll do a search and change it where it needs to be changed, I'm assuming the above doesn't cover all places. > > I apologize for noticing this issue at the last minute. In > response to the > question about "stateless autoconfiguration" and "autonomous > autoconfiguration", I wanted to see if there were other phrases using > "autoconfiguration". That search lead to the discovery of > the inconsistent > uses of "autoconfiguration". => No problems, they're all good catches. Thanks for your feedback and quick response. I intend to submit the draft tomorrow. Hesham > > - Ralph > > > On 1/5/07 3:40 AM, "Hesham Soliman" wrote: > > > Hello again, > > > > This is a follow up on the comments we discussed earlier. > Ralph, please let > > me know if you're ok with my suggestions below. The > document is waiting on > > your response! The rest of your comments are all in the document. > > > >>>> I think this is general advice to people thinking about > >>> how ND applies > >>>> to link layers other than, say, ethernet. Clearly, ND > >>> applies to all > >>>> specs, unless superceded by another spec for a particular link > >>>> layer. That is all that this section is (IMO) trying to > >>> say. I.e., to > >>>> suggest when another spec might be needed and where not. > >>> > >>> I think I understand the meaning the text is supposed to > >>> convey. But the > >>> text doesn't seem (to me, anyway) to convey that meaning > >>> very well; I note > >>> your interpretation is qualified with "IMO" and perhaps > >>> another reader might > >>> have a different opinion? > >>> > >>> To be more concrete, it appears that the section is > >>> describing how or which > >>> parts of ND should be implemented on links with certain > >>> attributes. But the > >>> last several entries don't seem to be very clear or precise. > >> > >> => Ok, does anyone object to removing that statement from > the spec? > >> The statemement I'm referring to is the one Ralph refers to above: > >> "Neighbor Discovery should be implemented as described in > >> this document." > >> It seems superfluous anyway. > > > > => So here is the text for the section in question: > > > > point-to-point - Neighbor Discovery handles such links just like > > multicast links. (Multicast can be trivially > > provided on point-to-point links, and interfaces > > can be assigned link-local addresses.) > > > > > > multicast - Neighbor Discovery supports multicast capable > > links as described in this document. > > > > > >>> Yeah, I agree the text means "don't draw any conclusions > >> about on- or > >>> off-link is L bit is not set". What are the ramifications > >>> of the L bit not > >>> being set; what other parts of this or other protocols > >> are affected? > >> > >> => If the L bit is not set a host cannot assume that an > >> address is on-link, therefore it will send all packets to > >> its Default router, unless a redirect is received for a > >> particular address. > > > > => I've clarified the definition a bit more: > > > > L 1-bit on-link flag. When set, indicates > that this > > prefix can be used for on-link > determination. When > > not set the advertisement makes no > statement about > > on-link or off-link properties of the prefix. In > > other words, if the L flag is not set a host MUST > > NOT assume that an addresse derived from > the prefix > > is on-link unless it is explicitly told > in another > > message (e.g. Redirect). For instance, the prefix > > might be used for address configuration with some > > of the addresses belonging to the prefix > being on- > > link and others being off-link. > > > > Any objections? > > > >>> Except for its use in supplying the initial for the 'A' > >> bit in prefix > >>> options... > >> > >> => I agree. So how about we state in the document that the > >> terms "stateless autoconfiguration" and "autonomous > >> autoconfiguration" are used interchangeably? People are > >> familiar with the meaning of the A flag and with the term > >> "stateless autoconfig", removing either one is probably > >> going to add more confusion than clarity. It might have to > >> be one of those imperfections of a doc that developed over a > >> long time. Is this ok? > > > > => Is this ok? > > > > > > Hesham > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 05 08:48:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pP8-0001W6-7N; Fri, 05 Jan 2007 08:46:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pP7-0001Vw-0d for ipv6@ietf.org; Fri, 05 Jan 2007 08:46:41 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pP3-0000Bg-Rt for ipv6@ietf.org; Fri, 05 Jan 2007 08:46:40 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l05Dkbj8020762 for ; Fri, 5 Jan 2007 06:46:37 -0700 (MST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l05DkaVC017489 for ; Fri, 5 Jan 2007 08:46:36 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l05DocmL023122; Fri, 5 Jan 2007 08:50:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l05DocKs023117; Fri, 5 Jan 2007 08:50:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17822.22446.547132.229861@gargle.gargle.HOWL> Date: Fri, 5 Jan 2007 08:50:38 -0500 From: James Carlson To: Pekka Savola In-Reply-To: References: <4593CEF5.50308@innovationslab.net> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Brian Haberman , ipv6@ietf.org Subject: Re: RFC2461(bis): normativeness of protocol constants X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pekka Savola writes: > This is more than strictly required for interoperability. I think that's the key point. It's very important to make sure that the things marked as "MUST" or "MUST NOT" are actually requirements for interoperability or anticipated development, and not just needless strictures. Otherwise, it becomes much more tedious to support enviroments that require slightly different values or implementations that trade off simplicity against precision. (Given that I've encountered test suites that enforce even "MAY" clauses, I think caution about over-specifying things is warranted.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 05 12:07:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sVf-0002lo-Db; Fri, 05 Jan 2007 12:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sVe-0002li-3o for ipv6@ietf.org; Fri, 05 Jan 2007 12:05:38 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sVc-0005CW-MO for ipv6@ietf.org; Fri, 05 Jan 2007 12:05:38 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2007 09:05:36 -0800 X-IronPort-AV: i="4.12,243,1165219200"; d="scan'208"; a="50078816:sNHT58236684" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l05H5ahX026766; Fri, 5 Jan 2007 12:05:36 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l05H5Z7h017908; Fri, 5 Jan 2007 12:05:35 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 12:05:35 -0500 Received: from 10.82.240.17 ([10.82.240.17]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Jan 2007 17:05:34 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 05 Jan 2007 12:05:37 -0500 From: Ralph Droms To: Hesham Soliman , Thomas Narten Message-ID: Thread-Topic: Review of draft-ietf-ipv6-2461bis-09.txt Thread-Index: AccT714WnL8L/n/iEduj3AARJOT6egR4cU0wArTRBaAABK+JewABhC9AAAuggPw= In-Reply-To: <20070105113726.IWWL29846.oaamta04ps.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Jan 2007 17:05:35.0065 (UTC) FILETIME=[B718C490:01C730EB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6590; t=1168016736; x=1168880736; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Review=20of=20draft-ietf-ipv6-2461bis-09.txt=20 |Sender:=20 |To:=20Hesham=20Soliman=20, =0A=20=20=20=20=20=2 0=20=20Thomas=20Narten=20; bh=/beQTvijnscrSPaQruwnBRYc2XT0HCl9cZt0u2UK5Cg=; b=ZZO2OUUb+fao1xISUDLOMrMpSSLCte3SgXFizC/zHIR6yo1RaTXwzCAQQZGcMSALFwVQ2361 htHn3NTJI2LOpYbXztaJKpSj77Pc0ZdJPVw/faxXk1lAK7MQsAAFgQAH; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: ipv6@ietf.org, 'Brian Haberman' , 'Erik Nordmark' , 'Bob Hinden' , 'William Allen Simpson' Subject: Re: Review of draft-ietf-ipv6-2461bis-09.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hesham - thanks for all your hard work on the doc... - Ralph On 1/5/07 6:37 AM, "Hesham Soliman" wrote: >> >> Hesham - you're suggested revisions are fine with me. > > => Ok, thanks! > >> >> One typo - in the text for the on-link flag, s/addresse/address/ > > => Done. > >> >> And, at the risk of being overly picky, after searching >> through the RFC for >> occurrences of "autoconfiguration", it seems there is some >> inconsistency in >> the use of other related terms, like autoconfiguration and address >> autoconfiguration (used for both SLAAC and DHCP). >> >> The definition in the terminology section seems OK: >> >> Address Autoconfiguration: How nodes automatically configure an >> address for an interface. >> >> ...referring to both stateless address autoconfiguration and DHCP. >> >> Howvever, at the end of section 2.3: >> >> (e.g., while verifying an address is unused >> during address autoconfiguration [ADDRCONF]) >> >> While this is not normative text, I use it as an example. >> If, in this case, >> "address autoconfiguration" refers to just SLAAC, it should >> be "stateless >> address autoconfiguration". On the other hand, if "address >> autoconfiguration" is correct, then there should be a >> reference to DHCPv6 >> (RFC 3315) as well as [ADDRCONF]. >> >> As another example, at the end of section 4.2: >> >> Prefix Information >> These options specify the prefixes that >> are on-link >> and/or are used for address autoconfiguration. >> >> Here, the reference should be to "stateless address >> autoconfiguration"; the >> prefix information is not used by a host using DHCP. > > => Understood. I'll do a search and change it where it needs to be changed, > I'm assuming the above doesn't cover all places. > >> >> I apologize for noticing this issue at the last minute. In >> response to the >> question about "stateless autoconfiguration" and "autonomous >> autoconfiguration", I wanted to see if there were other phrases using >> "autoconfiguration". That search lead to the discovery of >> the inconsistent >> uses of "autoconfiguration". > > => No problems, they're all good catches. Thanks for your feedback and quick > response. > I intend to submit the draft tomorrow. > > Hesham > >> >> - Ralph >> >> >> On 1/5/07 3:40 AM, "Hesham Soliman" wrote: >> >>> Hello again, >>> >>> This is a follow up on the comments we discussed earlier. >> Ralph, please let >>> me know if you're ok with my suggestions below. The >> document is waiting on >>> your response! The rest of your comments are all in the document. >>> >>>>>> I think this is general advice to people thinking about >>>>> how ND applies >>>>>> to link layers other than, say, ethernet. Clearly, ND >>>>> applies to all >>>>>> specs, unless superceded by another spec for a particular link >>>>>> layer. That is all that this section is (IMO) trying to >>>>> say. I.e., to >>>>>> suggest when another spec might be needed and where not. >>>>> >>>>> I think I understand the meaning the text is supposed to >>>>> convey. But the >>>>> text doesn't seem (to me, anyway) to convey that meaning >>>>> very well; I note >>>>> your interpretation is qualified with "IMO" and perhaps >>>>> another reader might >>>>> have a different opinion? >>>>> >>>>> To be more concrete, it appears that the section is >>>>> describing how or which >>>>> parts of ND should be implemented on links with certain >>>>> attributes. But the >>>>> last several entries don't seem to be very clear or precise. >>>> >>>> => Ok, does anyone object to removing that statement from >> the spec? >>>> The statemement I'm referring to is the one Ralph refers to above: >>>> "Neighbor Discovery should be implemented as described in >>>> this document." >>>> It seems superfluous anyway. >>> >>> => So here is the text for the section in question: >>> >>> point-to-point - Neighbor Discovery handles such links just like >>> multicast links. (Multicast can be trivially >>> provided on point-to-point links, and interfaces >>> can be assigned link-local addresses.) >>> >>> >>> multicast - Neighbor Discovery supports multicast capable >>> links as described in this document. >>> >>> >>>>> Yeah, I agree the text means "don't draw any conclusions >>>> about on- or >>>>> off-link is L bit is not set". What are the ramifications >>>>> of the L bit not >>>>> being set; what other parts of this or other protocols >>>> are affected? >>>> >>>> => If the L bit is not set a host cannot assume that an >>>> address is on-link, therefore it will send all packets to >>>> its Default router, unless a redirect is received for a >>>> particular address. >>> >>> => I've clarified the definition a bit more: >>> >>> L 1-bit on-link flag. When set, indicates >> that this >>> prefix can be used for on-link >> determination. When >>> not set the advertisement makes no >> statement about >>> on-link or off-link properties of the prefix. In >>> other words, if the L flag is not set a host MUST >>> NOT assume that an addresse derived from >> the prefix >>> is on-link unless it is explicitly told >> in another >>> message (e.g. Redirect). For instance, the prefix >>> might be used for address configuration with some >>> of the addresses belonging to the prefix >> being on- >>> link and others being off-link. >>> >>> Any objections? >>> >>>>> Except for its use in supplying the initial for the 'A' >>>> bit in prefix >>>>> options... >>>> >>>> => I agree. So how about we state in the document that the >>>> terms "stateless autoconfiguration" and "autonomous >>>> autoconfiguration" are used interchangeably? People are >>>> familiar with the meaning of the A flag and with the term >>>> "stateless autoconfig", removing either one is probably >>>> going to add more confusion than clarity. It might have to >>>> be one of those imperfections of a doc that developed over a >>>> long time. Is this ok? >>> >>> => Is this ok? >>> >>> >>> Hesham >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 05 13:01:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tMU-00081C-C2; Fri, 05 Jan 2007 13:00:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tMT-000815-FH for ipv6@ietf.org; Fri, 05 Jan 2007 13:00:13 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tMR-0004QP-6E for ipv6@ietf.org; Fri, 05 Jan 2007 13:00:13 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l05Hxv0A015415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Jan 2007 09:59:57 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l05HxuZg009795; Fri, 5 Jan 2007 09:59:57 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l05HxlOJ009264; Fri, 5 Jan 2007 09:59:56 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:59:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jan 2007 09:59:55 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774576@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070105084102.LOHC17919.oaamta02ps.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-ipv6-2461bis-09.txt Thread-Index: AccT714WnL8L/n/iEduj3AARJOT6egR4cU0wArTRBaAAEtyNQA== From: "Templin, Fred L" To: "Hesham Soliman" , "Ralph Droms" , "Thomas Narten" X-OriginalArrivalTime: 05 Jan 2007 17:59:55.0932 (UTC) FILETIME=[4EB995C0:01C730F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Bob Hinden , Brian Haberman , Erik Nordmark , ipv6@ietf.org, William Allen Simpson Subject: RE: Review of draft-ietf-ipv6-2461bis-09.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hesham, Regarding the new sentence under the 'L' bit definition: =20 > In=20 > other words, if the L flag is not set a host MUST=20 > NOT assume that an addresse derived from the prefix=20 > is on-link unless it is explicitly told in another=20 > message (e.g. Redirect). the on-link property of an address need not be due to a message, e.g., it could be due to manual config. Suggest rewriting as: "In other words, if the L flag is not set a host MUST NOT assume that an address derived from the prefix is on-link unless it is explicitly told through some other means (e.g. Redirect)." Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 05 19:47:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2zet-000103-5q; Fri, 05 Jan 2007 19:43:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2zer-0000zw-Gy for ipv6@ietf.org; Fri, 05 Jan 2007 19:43:37 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2zep-0001gm-2y for ipv6@ietf.org; Fri, 05 Jan 2007 19:43:37 -0500 Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070106004324.MBAV19269.omta05ps.mx.bigpond.com@PC20005>; Sat, 6 Jan 2007 00:43:24 +0000 From: "Hesham Soliman" To: "'Templin, Fred L'" , "'Ralph Droms'" , "'Thomas Narten'" Date: Sat, 6 Jan 2007 11:43:20 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774576@XCH-NW-7V2.nw.nos.boeing.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccT714WnL8L/n/iEduj3AARJOT6egR4cU0wArTRBaAAEtyNQAAO8XKg Message-Id: <20070106004324.MBAV19269.omta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'Bob Hinden' , 'Brian Haberman' , 'Erik Nordmark' , ipv6@ietf.org, 'William Allen Simpson' Subject: RE: Review of draft-ietf-ipv6-2461bis-09.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Fred, Ok, thanks, I've made the change. Hesham > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Saturday, January 06, 2007 5:00 AM > To: Hesham Soliman; Ralph Droms; Thomas Narten > Cc: ipv6@ietf.org; Brian Haberman; Erik Nordmark; Bob > Hinden; William Allen Simpson > Subject: RE: Review of draft-ietf-ipv6-2461bis-09.txt > > Hesham, > > Regarding the new sentence under the 'L' bit definition: > > > In > > other words, if the L flag is not set a > host MUST > > NOT assume that an addresse derived from > the prefix > > is on-link unless it is explicitly told > in another > > message (e.g. Redirect). > > the on-link property of an address need not be due to a > message, e.g., it could be due to manual config. Suggest > rewriting as: > > "In other words, if the L flag is not set a host MUST NOT > assume that an address derived from the prefix is on-link > unless it is explicitly told through some other means > (e.g. Redirect)." > > Fred > fred.l.templin@boeing.com > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 06 19:04:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3LSN-00053g-1V; Sat, 06 Jan 2007 19:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3LSM-00053b-BT for ipv6@ietf.org; Sat, 06 Jan 2007 19:00:10 -0500 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3LSK-0003N0-7y for ipv6@ietf.org; Sat, 06 Jan 2007 19:00:09 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 70DC528426 for ; Sun, 7 Jan 2007 00:00:03 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 07 Jan 2007 00:00:03 +0000 Message-Id: <20070107000003.70DC528426@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 35.29% | 6 | 35.42% | 40286 | hesham@elevatemobile.com 11.76% | 2 | 19.32% | 21969 | rdroms@cisco.com 11.76% | 2 | 8.98% | 10217 | james.d.carlson@sun.com 5.88% | 1 | 8.87% | 10084 | alexandru.petrescu@motorola.com 5.88% | 1 | 6.04% | 6866 | timbeck04@verizon.net 5.88% | 1 | 5.34% | 6078 | brc@zurich.ibm.com 5.88% | 1 | 4.59% | 5217 | fred.l.templin@boeing.com 5.88% | 1 | 4.32% | 4914 | pekkas@netcore.fi 5.88% | 1 | 3.84% | 4372 | mailman-owner@ietf.org 5.88% | 1 | 3.28% | 3734 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 17 |100.00% | 113737 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 08 15:53:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41SD-0003il-Dv; Mon, 08 Jan 2007 15:50:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41Rx-0003IY-Ra; Mon, 08 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H41Rx-0005uy-Fc; Mon, 08 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 05007175FD; Mon, 8 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H41RS-0004vJ-If; Mon, 08 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-2461bis-10.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-2461bis-10.txt Pages : 88 Date : 2007-1-8 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-2461bis-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-2461bis-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-8125235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-2461bis-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-2461bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-8125235.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Wed Jan 10 08:19:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dJW-0005Wr-6y; Wed, 10 Jan 2007 08:16:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dJU-0005RJ-JB for ipv6@ietf.org; Wed, 10 Jan 2007 08:16:20 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4dJB-0006V8-Le for ipv6@ietf.org; Wed, 10 Jan 2007 08:16:20 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0ADFxf0013875 for ; Wed, 10 Jan 2007 06:15:59 -0700 (MST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l0ADFwiI001171 for ; Wed, 10 Jan 2007 08:15:59 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0ADFwMZ008193; Wed, 10 Jan 2007 08:15:58 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0ADFwxN008190; Wed, 10 Jan 2007 08:15:58 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17828.59150.365134.221293@gargle.gargle.HOWL> Date: Wed, 10 Jan 2007 08:15:58 -0500 From: James Carlson To: pars.mutaf@int-evry.fr In-Reply-To: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf writes: > Dot-local DNS is also very useful in MANETs. However, you have > to flood the network to resolve a name. This consumes bandwidth > and energy in the whole network. It isn't just multicast DNS that depends on the use of multicast -- there are many protocols (including neighbor discovery) that will either fail to work properly if multicast is outlawed or will need modifications or limitations. This sounds like a syntax error to me. The system in question apparently wants to use what are effectively point-to-point links but is instead modeling as a crippled broadcast-type network. I say "apparently," because the proposal below wouldn't work unless there's some central node involved. As part of resolving that IPv6 link-local address to an L2 address, nodes will send multicast neighbor solicitations. The apparent fact that this doesn't wake everyone up means that the network is already partitioned. Given that use of multicast typically isn't a privileged operation, how does that central node stop someone from draining everyone else's batteries anyway, even if this one protocol is fixed? > link-local subnet prefix | 64bithash("johnsmith.local") > > where hash is SHA1, and '|' means concatenation. It can be noted > that 64bithash("johnsmith.local") is the IPv6 interface ID. > The link-local subnet prefix is constant and well-known. [...] > http://www.freewebs.com/pmutaf/humid.html So, the proposal is that if the hash collides for different names, then "johnsmith.local" must rename himself, right? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 10:17:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4f9o-0007aW-2H; Wed, 10 Jan 2007 10:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4f9m-0007a8-Mi for ipv6@ietf.org; Wed, 10 Jan 2007 10:14:26 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4f9i-0005iG-Kn for ipv6@ietf.org; Wed, 10 Jan 2007 10:14:24 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id C22492FD91; Wed, 10 Jan 2007 16:14:17 +0100 (CET) From: Pars Mutaf To: James Carlson In-Reply-To: <17828.59150.365134.221293@gargle.gargle.HOWL> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <17828.59150.365134.221293@gargle.gargle.HOWL> Content-Type: text/plain Organization: INT Evry Date: Wed, 10 Jan 2007 16:14:26 +0100 Message-Id: <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, 2007-01-10 at 08:15 -0500, James Carlson wrote: > Pars Mutaf writes: > > Dot-local DNS is also very useful in MANETs. However, you have > > to flood the network to resolve a name. This consumes bandwidth > > and energy in the whole network. > > It isn't just multicast DNS that depends on the use of multicast -- > there are many protocols (including neighbor discovery) that will > either fail to work properly if multicast is outlawed or will need > modifications or limitations. > > This sounds like a syntax error to me. The system in question > apparently wants to use what are effectively point-to-point links but > is instead modeling as a crippled broadcast-type network. > > I say "apparently," because the proposal below wouldn't work unless > there's some central node involved. As part of resolving that IPv6 > link-local address to an L2 address, nodes will send multicast > neighbor solicitations. The apparent fact that this doesn't wake > everyone up means that the network is already partitioned. > > Given that use of multicast typically isn't a privileged operation, > how does that central node stop someone from draining everyone else's > batteries anyway, even if this one protocol is fixed? This threat is probably another good reason for not allowing multicast. >From an abstract point of view (hoping to answer all your concerns above): if we already know the destination's unicast address, then we should not send a multicast query. We should send a unicast query. This is my proposal. This is the conservative approach IMHO. As an example, we can take WiMax (IPv6 over WiMax is being standardized by the 16ng WG). In 16ng, the access router has a list of all nodes. This corresponds to what you call a central node. DAD (duplicate address detection) is achieved using unicast. This is work in progress. As for neighbor discovery, I agree that it is more reliable over L2 multicast. I hope that the access router can use it to recover from loss of state, but not during normal operation (because it is costly). 16ng WG will decide. Now one can say: if the WiMax AR knows knows everything, why not register the localname->address bindings also to the AR? My answer is that installing DNS in a router is going to far. I'm proposing a solution for not doing this. The AR speaks IPv6, so lets encode the names into IPv6 addresses. But again, IMHO, from an abstract point of view, unicast will always be the conservative approach. I.e. not only for WiMax. > > link-local subnet prefix | 64bithash("johnsmith.local") > > > > where hash is SHA1, and '|' means concatenation. It can be noted > > that 64bithash("johnsmith.local") is the IPv6 interface ID. > > The link-local subnet prefix is constant and well-known. > [...] > > http://www.freewebs.com/pmutaf/humid.html > > So, the proposal is that if the hash collides for different names, > then "johnsmith.local" must rename himself, right? Right. Please let me know if you see a problem with this. Thanks! pars > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 10:58:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4foL-0004jv-86; Wed, 10 Jan 2007 10:56:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4foK-0004jq-6M for ipv6@ietf.org; Wed, 10 Jan 2007 10:56:20 -0500 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4foF-0002xr-RL for ipv6@ietf.org; Wed, 10 Jan 2007 10:56:20 -0500 Received: from auguste.remlab.net (unknown [IPv6:2001:0:53aa:64c:0:f226:3d90:ae62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id 6173A96504; Wed, 10 Jan 2007 16:56:06 +0100 (CET) From: =?windows-1252?q?R=E9mi_Denis-Courmont?= Organization: SimPhalempin.Com To: pars.mutaf@int-evry.fr, ipv6@ietf.org Date: Wed, 10 Jan 2007 17:56:00 +0200 User-Agent: KMail/1.9.5 References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <17828.59150.365134.221293@gargle.gargle.HOWL> <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701101756.00347@auguste.remlab.net> X-Spam-Score: -2.8 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Le mercredi 10 janvier 2007 17:14, Pars Mutaf a =E9crit : > > So, the proposal is that if the hash collides for different names, > > then "johnsmith.local" must rename himself, right? > > Right. Please let me know if you see a problem with this. My understanding of James remarks is that your proposal merely moves the=20 problem away from DNS to Neighbor Discovery, but does not solve the=20 core issue at all, which is that some kind of multicast/broadcast is=20 needed for non-point-to-point IPv6 links. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 12:37:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hIk-0003b9-4W; Wed, 10 Jan 2007 12:31:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hIi-0003b0-4N for ipv6@ietf.org; Wed, 10 Jan 2007 12:31:48 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4hIe-00075k-36 for ipv6@ietf.org; Wed, 10 Jan 2007 12:31:48 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1168450302!12736757!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8444 invoked from network); 10 Jan 2007 17:31:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 10 Jan 2007 17:31:42 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0AHVXWW026094; Wed, 10 Jan 2007 10:31:37 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0AHVWCO014593; Wed, 10 Jan 2007 11:31:32 -0600 (CST) Message-ID: <45A522F3.5020106@motorola.com> Date: Wed, 10 Jan 2007 18:31:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: pars.mutaf@int-evry.fr References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <17828.59150.365134.221293@gargle.gargle.HOWL> <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf wrote: > On Wed, 2007-01-10 at 08:15 -0500, James Carlson wrote: >> Pars Mutaf writes: >>> Dot-local DNS is also very useful in MANETs. However, you have to >>> flood the network to resolve a name. This consumes bandwidth and >>> energy in the whole network. >> It isn't just multicast DNS that depends on the use of multicast -- >> there are many protocols (including neighbor discovery) that will >> either fail to work properly if multicast is outlawed or will need >> modifications or limitations. >> >> This sounds like a syntax error to me. The system in question >> apparently wants to use what are effectively point-to-point links >> but is instead modeling as a crippled broadcast-type network. >> >> I say "apparently," because the proposal below wouldn't work unless >> there's some central node involved. As part of resolving that >> IPv6 link-local address to an L2 address, nodes will send multicast >> neighbor solicitations. The apparent fact that this doesn't wake >> everyone up means that the network is already partitioned. >> >> Given that use of multicast typically isn't a privileged operation, >> how does that central node stop someone from draining everyone >> else's batteries anyway, even if this one protocol is fixed? > > This threat is probably another good reason for not allowing > multicast. > >> From an abstract point of view (hoping to answer all your concerns > above): if we already know the destination's unicast address, then we > should not send a multicast query. We should send a unicast query. > This is my proposal. This is the conservative approach IMHO. I agree. I'm not sure whether that draft allows this behaviour or not (send direct DNS message instead of multicast). It can be suggested though. > As an example, we can take WiMax (IPv6 over WiMax is being > standardized by the 16ng WG). They look mostly at 802.16 less at WiMax which is somehow normal to me since WiMax are moving more than 802.16. > In 16ng, the access router has a list of all nodes. Not sure which entity you mention? Not necessarily WiMax. I think any router has a list of its neighbours in NC. > This corresponds to what you call a central node. DAD (duplicate > address detection) is achieved using unicast. Not sure which document you refer to. The first DADing NS is sent to solicited-node multicast address (by rfc2462), and not to unicast address. Some documents in 16ng talk 'Relay DAD' which would maintain a list and then unicast a NS; but other signals in WiMax forum seem to indicate deprecating the use of 'Relay ND' for rfc4541 instead. > This is work in progress. As for neighbor discovery, I agree that it > is more reliable over L2 multicast. Yes, more reliable and mandatory. Actually IPv6 ND doesn't work at all over a link-layer that isn't doing multicast link-layer addresses. > I hope that the access router can use it to recover from loss of > state, but not during normal operation (because it is costly). 16ng > WG will decide. > > Now one can say: if the WiMax AR knows knows everything, why not > register the localname->address bindings also to the AR? Because not scalable? Ie memory can overflow if too many nodes? > My answer is that installing DNS in a router is going to far. I'm > proposing a solution for not doing this. The AR speaks IPv6, so lets > encode the names into IPv6 addresses. Err...? If I want to encode my private key and my name into my IPv6 64bits would this work? Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 13:46:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQN-00040O-ME; Wed, 10 Jan 2007 13:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hj6-00005n-UD for ipv6@ietf.org; Wed, 10 Jan 2007 12:59:04 -0500 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hj3-0001lA-3B for ipv6@ietf.org; Wed, 10 Jan 2007 12:59:04 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 315F811425; Wed, 10 Jan 2007 17:58:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: pars.mutaf@int-evry.fr In-Reply-To: Your message of "Wed, 10 Jan 2007 11:06:38 +0100." <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 10 Jan 2007 17:58:52 +0000 Message-ID: <98793.1168451932@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 10 Jan 2007 13:43:43 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ... > These problems make me think that dot-local usage is not as general > as it should be in IPv6. What about this approach? > > It works exactly as multicast DNS, except that there is no multicast. > > 1. Let the responder's DNS name be "johnsmith.local". The responder > configures a name-based link-local IPv6 address: > > link-local subnet prefix | 64bithash("johnsmith.local") > > where hash is SHA1, and '|' means concatenation. It can be noted > that 64bithash("johnsmith.local") is the IPv6 interface ID. > The link-local subnet prefix is constant and well-known. you'll also have to cope with networks that aren't using EUI64 or for that matter aren't using a 64-bit netmask. and you'll have to cope with hash collisions, however improbable they may be. > 2. When the initiator user (or application) enters the name > johnsmith.local, the DNS request is sent to the above address, > instead of being multicast. > > Am I missing something? L2 broadcast will have to work in order to support ARP. if your L2 does not support broadcast at all then i don't know what to suggest beyond some kind of distinguished destination address that operates a location brokerage for other services. if your L2 supports broadcast but at significant power cost then i suggest we revive bmanning's old DNS DISCOVER proposal. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 13:46:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQN-00040I-5J; Wed, 10 Jan 2007 13:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4f6y-0006uJ-65 for ipv6@ietf.org; Wed, 10 Jan 2007 10:11:32 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4f4K-00053r-G2 for ipv6@ietf.org; Wed, 10 Jan 2007 10:08:49 -0500 Received: by wx-out-0506.google.com with SMTP id h31so131965wxd for ; Wed, 10 Jan 2007 07:08:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hxdhOqSs0FOqXtCad4SyzRNgFW/P5Gkzn8VqSWyZGPx/N8H1dtLxwGcbTrgieVN4EgIC/PGS2N+LG49B4imspbCw9HjqKtyTDiOf1J6/b0Xjgqc39oQadi7/lzQNHuxBY6EYh8zVp4/obv1EcJmm32+y3epQOOnAmelMk0IIXuI= Received: by 10.70.48.11 with SMTP id v11mr840541wxv.1168441728125; Wed, 10 Jan 2007 07:08:48 -0800 (PST) Received: from ?207.74.179.30? ( [207.74.179.30]) by mx.google.com with ESMTP id 7sm8753896wrl.2007.01.10.07.08.43; Wed, 10 Jan 2007 07:08:48 -0800 (PST) Message-ID: <45A50187.3000502@gmail.com> Date: Wed, 10 Jan 2007 10:08:55 -0500 From: William Allen Simpson User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Hesham Soliman , Thomas Narten , Erik Nordmark References: <20070106004324.MBAV19269.omta05ps.mx.bigpond.com@PC20005> In-Reply-To: <20070106004324.MBAV19269.omta05ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Wed, 10 Jan 2007 13:43:43 -0500 Cc: Brian Haberman , Bob Hinden , IETF Discussion , Scott W Brim , ipv6@ietf.org, General Area Review Team Subject: Review of draft-ietf-ipv6-2461bis-10.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Thank you for informing me of the re-write. A few obvious editorial corrections: EMail: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com The former machine hasn't existed since circa 1994, and the latter since circa 1998. Easy Googling has given reviewers one of my half dozen active emails (and notified me of this draft). I've recently retired wsimpson@greendragon.com that was on most recent RFCs, as that company concluded bankruptcy some time ago. Please replace with my more current email above! (Hopefully, Gmail will be useful for the next Internet Lifetime.) The Introduction has a list of acknowledgments for reviewers. They aren't really introductory. In the past, I've always included them in a separate ACKNOWLEDGMENTS section, following more usual academic practice. That also permits more explicit indication of which individuals proposed which (mis-)features. Please replace the rampant misuse of "e.g." and "i.e." with the more appropriate "for example," "such as," "that is," "specifically," or in many parentheticals simply eliminate it entirely! Also, it would be better to follow the RFC writing practices that I've developed for such things as describing state machines, later cited as exemplary in the Guide for Internet Standards Writers (RFC 2360). I'd hoped that a draft derived from my earlier work would continue the clean style and form, even as it deviates from the substance. And speaking of substance, I'm not convinced this draft is ready for prime time. Far too much continues to be relegated to "further study". For example, multi-homed hosts are fairly common in operational practice, and my original 1992-1993 work included them. After 15 years, greater experience ought to clarify, rather than muddy the waters. This should never have made it to Draft Standard. Moreover, as I've stated before, I'm deeply disappointed that the substance has departed from my original vision: virtually no configuration for hosts or routers, other than identifiers and secrets necessary for security. Although there have been modest improvements in this recent draft, the elimination of explicit security support has retreated ever farther from the goal. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 13:46:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQN-00040O-ME; Wed, 10 Jan 2007 13:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hj6-00005n-UD for ipv6@ietf.org; Wed, 10 Jan 2007 12:59:04 -0500 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hj3-0001lA-3B for ipv6@ietf.org; Wed, 10 Jan 2007 12:59:04 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 315F811425; Wed, 10 Jan 2007 17:58:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: pars.mutaf@int-evry.fr In-Reply-To: Your message of "Wed, 10 Jan 2007 11:06:38 +0100." <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 10 Jan 2007 17:58:52 +0000 Message-ID: <98793.1168451932@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 10 Jan 2007 13:43:43 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ... > These problems make me think that dot-local usage is not as general > as it should be in IPv6. What about this approach? > > It works exactly as multicast DNS, except that there is no multicast. > > 1. Let the responder's DNS name be "johnsmith.local". The responder > configures a name-based link-local IPv6 address: > > link-local subnet prefix | 64bithash("johnsmith.local") > > where hash is SHA1, and '|' means concatenation. It can be noted > that 64bithash("johnsmith.local") is the IPv6 interface ID. > The link-local subnet prefix is constant and well-known. you'll also have to cope with networks that aren't using EUI64 or for that matter aren't using a 64-bit netmask. and you'll have to cope with hash collisions, however improbable they may be. > 2. When the initiator user (or application) enters the name > johnsmith.local, the DNS request is sent to the above address, > instead of being multicast. > > Am I missing something? L2 broadcast will have to work in order to support ARP. if your L2 does not support broadcast at all then i don't know what to suggest beyond some kind of distinguished destination address that operates a location brokerage for other services. if your L2 supports broadcast but at significant power cost then i suggest we revive bmanning's old DNS DISCOVER proposal. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 13:46:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQN-00040I-5J; Wed, 10 Jan 2007 13:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4f6y-0006uJ-65 for ipv6@ietf.org; Wed, 10 Jan 2007 10:11:32 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4f4K-00053r-G2 for ipv6@ietf.org; Wed, 10 Jan 2007 10:08:49 -0500 Received: by wx-out-0506.google.com with SMTP id h31so131965wxd for ; Wed, 10 Jan 2007 07:08:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hxdhOqSs0FOqXtCad4SyzRNgFW/P5Gkzn8VqSWyZGPx/N8H1dtLxwGcbTrgieVN4EgIC/PGS2N+LG49B4imspbCw9HjqKtyTDiOf1J6/b0Xjgqc39oQadi7/lzQNHuxBY6EYh8zVp4/obv1EcJmm32+y3epQOOnAmelMk0IIXuI= Received: by 10.70.48.11 with SMTP id v11mr840541wxv.1168441728125; Wed, 10 Jan 2007 07:08:48 -0800 (PST) Received: from ?207.74.179.30? ( [207.74.179.30]) by mx.google.com with ESMTP id 7sm8753896wrl.2007.01.10.07.08.43; Wed, 10 Jan 2007 07:08:48 -0800 (PST) Message-ID: <45A50187.3000502@gmail.com> Date: Wed, 10 Jan 2007 10:08:55 -0500 From: William Allen Simpson User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Hesham Soliman , Thomas Narten , Erik Nordmark References: <20070106004324.MBAV19269.omta05ps.mx.bigpond.com@PC20005> In-Reply-To: <20070106004324.MBAV19269.omta05ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Wed, 10 Jan 2007 13:43:43 -0500 Cc: Brian Haberman , Bob Hinden , IETF Discussion , Scott W Brim , ipv6@ietf.org, General Area Review Team Subject: Review of draft-ietf-ipv6-2461bis-10.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Thank you for informing me of the re-write. A few obvious editorial corrections: EMail: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com The former machine hasn't existed since circa 1994, and the latter since circa 1998. Easy Googling has given reviewers one of my half dozen active emails (and notified me of this draft). I've recently retired wsimpson@greendragon.com that was on most recent RFCs, as that company concluded bankruptcy some time ago. Please replace with my more current email above! (Hopefully, Gmail will be useful for the next Internet Lifetime.) The Introduction has a list of acknowledgments for reviewers. They aren't really introductory. In the past, I've always included them in a separate ACKNOWLEDGMENTS section, following more usual academic practice. That also permits more explicit indication of which individuals proposed which (mis-)features. Please replace the rampant misuse of "e.g." and "i.e." with the more appropriate "for example," "such as," "that is," "specifically," or in many parentheticals simply eliminate it entirely! Also, it would be better to follow the RFC writing practices that I've developed for such things as describing state machines, later cited as exemplary in the Guide for Internet Standards Writers (RFC 2360). I'd hoped that a draft derived from my earlier work would continue the clean style and form, even as it deviates from the substance. And speaking of substance, I'm not convinced this draft is ready for prime time. Far too much continues to be relegated to "further study". For example, multi-homed hosts are fairly common in operational practice, and my original 1992-1993 work included them. After 15 years, greater experience ought to clarify, rather than muddy the waters. This should never have made it to Draft Standard. Moreover, as I've stated before, I'm deeply disappointed that the substance has departed from my original vision: virtually no configuration for hosts or routers, other than identifiers and secrets necessary for security. Although there have been modest improvements in this recent draft, the elimination of explicit security support has retreated ever farther from the goal. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 13:46:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQM-0003xe-Gp; Wed, 10 Jan 2007 13:43:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cUY-0008Eh-1P for ipv6@ietf.org; Wed, 10 Jan 2007 07:23:42 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4cUW-0008Fk-E4 for ipv6@ietf.org; Wed, 10 Jan 2007 07:23:42 -0500 Received: (qmail 51404 invoked from network); 10 Jan 2007 12:42:03 -0000 Received: from softbank219001188039.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.39) by necom830.hpcl.titech.ac.jp with SMTP; 10 Jan 2007 12:42:03 -0000 Message-ID: <45A4DAC2.4070308@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Jan 2007 21:23:30 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: pars.mutaf@int-evry.fr References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Wed, 10 Jan 2007 13:43:43 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf wrote: > I believe that dot-local DNS (also called multicast DNS) will be > even more useful in the future. However, I suspect that there is > a problem. For example, in WiMax, a cellular standard, nodes cannot > L2 multicast. As was learned with the abandoned attempt of NBMA, link protocols not being capable of broadcast is useless. > Even if they could, L2 multicast would wake up every > dormant host. That's fine as long as L2 broadcast is infrequent. Note that L2 broadcast is as costly as L2 multicast. So, don't bother to say "multicast", when broadcast is harmful which is the case of CATENET, which is partly why IPv6 failed. IP over 1394 failed, too, because of purposeless attempt to avoid broadcast. > 1. Let the responder's DNS name be "johnsmith.local". The responder > configures a name-based link-local IPv6 address: > > link-local subnet prefix | 64bithash("johnsmith.local") And the address is a multicast address joined by all the hosts with 64bithash("johnsmith.local")=64bithash(DNS name). Masataka Ohta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 13:46:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4iQL-0003x3-Tt; Wed, 10 Jan 2007 13:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4aoW-0003IY-0R for ipv6@ietf.org; Wed, 10 Jan 2007 05:36:12 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4aoU-0005Ta-NT for ipv6@ietf.org; Wed, 10 Jan 2007 05:36:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 1AE4826C1F9; Wed, 10 Jan 2007 11:36:06 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D718226C1A3; Wed, 10 Jan 2007 11:36:02 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C9FA958ED21; Wed, 10 Jan 2007 11:36:02 +0100 (CET) Date: Wed, 10 Jan 2007 11:36:02 +0100 From: Stephane Bortzmeyer To: Pars Mutaf Message-ID: <20070110103602.GA18137@nic.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 10 Jan 2007 13:43:43 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, Jan 10, 2007 at 11:06:38AM +0100, Pars Mutaf wrote a message of 52 lines which said: > I believe that dot-local DNS (also called multicast DNS) Multicast DNS does not imply the Bad (tm) ".local"! Read draft-ietf-dnsext-mdns-47.txt (approved by the IESG on 31 Oct 2006 and stucked in RFC editor queue since, for unknown reasons). > It works exactly as multicast DNS, except that there is no multicast. > > 1. Let the responder's DNS name be "johnsmith.local". The responder > configures a name-based link-local IPv6 address: > > link-local subnet prefix | 64bithash("johnsmith.local") It really looks like PNRP : http://www.microsoft.com/technet/itsolutions/network/p2p/pnrp.mspx http://en.wikipedia.org/wiki/PNRP -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 10 13:58:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ieJ-0002qu-BX; Wed, 10 Jan 2007 13:58:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ieI-0002qp-7N for ipv6@ietf.org; Wed, 10 Jan 2007 13:58:10 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4ieF-00019J-SD for ipv6@ietf.org; Wed, 10 Jan 2007 13:58:10 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0AIw4AD017298 for ; Wed, 10 Jan 2007 10:58:05 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l0AIw44X004846 for ; Wed, 10 Jan 2007 13:58:04 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0AIw4NA009594; Wed, 10 Jan 2007 13:58:04 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0AIw4O7009591; Wed, 10 Jan 2007 13:58:04 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17829.14140.152784.308285@gargle.gargle.HOWL> Date: Wed, 10 Jan 2007 13:58:04 -0500 From: James Carlson To: pars.mutaf@int-evry.fr In-Reply-To: <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <17828.59150.365134.221293@gargle.gargle.HOWL> <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf writes: > My answer is that installing DNS in a router is going to far. Once you step off the cliff of altering the protocols to suit the limitations, it's probably hard to know where to stop. :-> > > So, the proposal is that if the hash collides for different names, > > then "johnsmith.local" must rename himself, right? > > Right. Please let me know if you see a problem with this. I don't necessarily; I was just trying to clarify the proposal. Fortunately, he can call himself "jacksmith.local" with no loss of information. The general multicast issue, though, seems like a hazardous one. If it's a walled garden (where users just "can't" send multicast), then you're obviously free to do anything you like. You don't even need to use IP. If it's not such a deployment, then it seems to me that outlawing multicast is a near impossible task and trying to modify protocols to avoid it is a losing proposition. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 03:29:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vFo-0003Ta-RI; Thu, 11 Jan 2007 03:25:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vFm-0003Re-UQ for ipv6@ietf.org; Thu, 11 Jan 2007 03:25:42 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4vFk-00046L-Bq for ipv6@ietf.org; Thu, 11 Jan 2007 03:25:42 -0500 Received: by ug-out-1314.google.com with SMTP id 72so358166ugd for ; Thu, 11 Jan 2007 00:25:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=XZQkp12Kw3fnqOPTswJS8iCCwBl2FyitgcYthHWZ4oxsjxQ0QUIGKJf6NUQNd74pwc9wdQkuYq5b+BxBGofWQH18lYIZANu2RrUwEmhw13rOBJJG6PcDyd+UfjozjiHEiTG9Eb2MfdAob4mulJNLxYv6DR5/9krfZJyVWqAfYh4= Received: by 10.67.19.20 with SMTP id w20mr1387032ugi.1168503939358; Thu, 11 Jan 2007 00:25:39 -0800 (PST) Received: from ?192.168.1.110? ( [212.119.9.178]) by mx.google.com with ESMTP id c1sm389287ugf.2007.01.11.00.25.38; Thu, 11 Jan 2007 00:25:38 -0800 (PST) From: Julien Laganier To: ipv6@ietf.org, pars.mutaf@int-evry.fr Date: Thu, 11 Jan 2007 09:24:34 +0100 User-Agent: KMail/1.8.2 References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701110924.34933.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: namedroppers@ops.ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Pars, On Wednesday 10 January 2007 11:06, Pars Mutaf wrote: > (IPv6 WG CCed sorry all for cross-posting) > > Dear namedroppers, > > I believe that dot-local DNS (also called multicast > DNS) will be even more useful in the future. > However, I suspect that there is a problem. For > example, in WiMax, a cellular standard, nodes cannot > L2 multicast. Even if they could, L2 multicast would > wake up every dormant host. WiMAX is one system architecture built upon IEEE 802.16 standard. AFAIK 802.16 MAC is point-to-point between a mobile station and the base station, and perfectly capable of multicast, it's just that at most two nodes can receive a multicast packet: the two end of the point-to-point link. --julien > Dormant mode for energy > efficiency is very important in this context. There > is also a serious L2-specific signaling cost > associated with dormant mode. (I'm not entering into > details.) > > Dot-local DNS is also very useful in MANETs. > However, you have to flood the network to resolve a > name. This consumes bandwidth and energy in the > whole network. > > These problems make me think that dot-local usage is > not as general as it should be in IPv6. What about > this approach? > > It works exactly as multicast DNS, except that there > is no multicast. > > 1. Let the responder's DNS name be > "johnsmith.local". The responder configures a > name-based link-local IPv6 address: > > link-local subnet prefix | > 64bithash("johnsmith.local") > > where hash is SHA1, and '|' means concatenation. It > can be noted that 64bithash("johnsmith.local") is > the IPv6 interface ID. The link-local subnet prefix > is constant and well-known. > > 2. When the initiator user (or application) enters > the name johnsmith.local, the DNS request is sent to > the above address, instead of being multicast. > > Am I missing something? > > Thanks. > > pars mutaf > > ps: An earlier version of this work proposed the > "blind" usage of name-based addresses (also called > HUMID addresses). It can be found here: > > http://www.freewebs.com/pmutaf/humid.html > > > > ---------------------------------------------------- >---------------- IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > ---------------------------------------------------- >---------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 04:55:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4wbr-0003CK-7y; Thu, 11 Jan 2007 04:52:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4wbq-000374-0r for ipv6@ietf.org; Thu, 11 Jan 2007 04:52:34 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4wbo-0005Ix-Kk for ipv6@ietf.org; Thu, 11 Jan 2007 04:52:34 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0B9qVYh055986 for ; Thu, 11 Jan 2007 09:52:31 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0B9qV8R1716424 for ; Thu, 11 Jan 2007 09:52:31 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0B9qVbk025800 for ; Thu, 11 Jan 2007 09:52:31 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0B9qUOf025772; Thu, 11 Jan 2007 09:52:30 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA127144; Thu, 11 Jan 2007 10:52:29 +0100 Message-ID: <45A608DC.1050407@zurich.ibm.com> Date: Thu, 11 Jan 2007 10:52:28 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <20070110103602.GA18137@nic.fr> In-Reply-To: <20070110103602.GA18137@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Multicast DNS does not imply the Bad (tm) ".local"! Read > draft-ietf-dnsext-mdns-47.txt (approved by the IESG on 31 Oct 2006 and > stucked in RFC editor queue since, for unknown reasons). It isn't stuck as far as I can see, it's just a member of the queue. And indeed, as far as I know, there is no TLD called "local". Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 05:29:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4x9t-0004K1-1y; Thu, 11 Jan 2007 05:27:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4x9r-0004JQ-Rz for ipv6@ietf.org; Thu, 11 Jan 2007 05:27:43 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4x9q-00047c-Fu for ipv6@ietf.org; Thu, 11 Jan 2007 05:27:43 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1168511261!2956252!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28070 invoked from network); 11 Jan 2007 10:27:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 11 Jan 2007 10:27:41 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0BARaZ7021902; Thu, 11 Jan 2007 03:27:36 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0BARYpx001827; Thu, 11 Jan 2007 04:27:35 -0600 (CST) Message-ID: <45A61115.7010407@motorola.com> Date: Thu, 11 Jan 2007 11:27:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: James Carlson References: <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005> <459D4D0D.2010806@motorola.com> <17821.24747.178330.936711@gargle.gargle.HOWL> In-Reply-To: <17821.24747.178330.936711@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ipv6@ietf.org Subject: Re: point-to-point links and ND (was: Review of draft-ietf-ipv6-2461bis-09.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org James Carlson wrote: > Alexandru Petrescu writes: >>>> Finally, link-layer addresses have a tight relationship with >>>> what goes in the last 64bits of an address. On ppp (and maybe >>>> others?) links there's no link-layer address but there's means >>>> to have something go into the last 64bits. So could we >>>> consider that IID to be a link-layer address. >>> => No we can't, the IID is in a completely different layer. The >>> fact that you can use an L2 address to generate the IID, does not >>> mean you can use the IID as an L2 address. >> Ok, I tend to think the same, too. But ppp gives an Interface ID >> and there's no other means in ppp to have an endpoint identifier. >> So the easiest way for ND to run over ppp would be to build some >> virtual link-layer headers with Interface IDs in it. All other ND >> mechanisms (multicast, DAD, etc) would run unmodified. > > I'm very much opposed to this idea. Those Interface IDs are not link > layer addresses. ND options including link layer addresses should > be added _only_ when link layer addresses exist on the underlying > media -- and they don't exist for point-to-point links. > > I fear changing this behavior to include Interface IDs instead of > link layer addresses will confuse and break existing implementations. > > Let's see... not that I've tried it. If a ppp peer negotiates an Interface ID and puts it in the Neighbour Cache attached to the ppp0 entry, won't break anything. When displaying the NC the entry simply won't show up empty. If same ppp peer declares that ppp0 interface nd-capable (instead of currently declared nd-non-capable), and builds a virtual ll header structure whose format is (src, dst on 64bits) and then declare some other constants for special ll multicast addresses then that ppp peer won't crash. The issue is what to declare on the other ppp peer. By existing ND implementations I assume it's meant ND over an ll-full (an interface with link-layer address). I think that as long as the ND/ptp enhancements are applied only on ll-less interfaces that can generate an IID then the other interfaces' implementations (eth, tun, etc) won't be affected. No? >> An "Interface ID" is exactly what ND needs on a ppp link. > > Disagree. Why does it need _any_ link layer address? Why should it > care? A main ND's goal is to resolve the IP address into a ll address, so if there's no ll address then no need of ND exchanges (especially no need of NS/NA). At which point it would be difficult to say that ND runs over ll-less addresses ok. I think. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 09:17:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50gb-0005VQ-Hs; Thu, 11 Jan 2007 09:13:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4m4w-0006m1-Vg for ipv6@ietf.org; Wed, 10 Jan 2007 17:37:54 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4m4r-0002ji-Gw for ipv6@ietf.org; Wed, 10 Jan 2007 17:37:54 -0500 Received: (qmail 66718 invoked from network); 10 Jan 2007 22:56:24 -0000 Received: from softbank219001188039.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.39) by necom830.hpcl.titech.ac.jp with SMTP; 10 Jan 2007 22:56:24 -0000 Message-ID: <45A56AB8.20206@necom830.hpcl.titech.ac.jp> Date: Thu, 11 Jan 2007 07:37:44 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: pars.mutaf@int-evry.fr References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <17828.59150.365134.221293@gargle.gargle.HOWL> <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Thu, 11 Jan 2007 09:13:44 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf wrote: > This threat is probably another good reason for not allowing > multicast. Wrong. As I already stated reasons, there is no point not allowing broadcast. Masataka Ohta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 09:31:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50wy-0004bY-MT; Thu, 11 Jan 2007 09:30:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50wx-0004bR-Bk for ipv6@ietf.org; Thu, 11 Jan 2007 09:30:39 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H50ws-0007lT-Ti for ipv6@ietf.org; Thu, 11 Jan 2007 09:30:39 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 298A42FF2B; Thu, 11 Jan 2007 15:30:26 +0100 (CET) From: Pars Mutaf To: Paul Vixie In-Reply-To: <98793.1168451932@sa.vix.com> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> Content-Type: text/plain Organization: INT Evry Date: Thu, 11 Jan 2007 15:30:26 +0100 Message-Id: <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi all, Thank you all for your comments! Alex and Julien: thanks for clarifications on 16ng. Stephane and Brian Carpenter: I used the term .local with no particular reason. If recent advances showed that it is unnecessary. That's OK for me. I'm not even sure if my proposal needs to be "local". I can also reach other subnets in theory (if my host has learned the list of neighboring subnets). I also take note of RFC4541. Thanks. But I still don't see why I would send a multicast query if I know the destination's unicast address. Sending the DNS query directly to the destination may be useful. For example, the host may have already resolved the destination's MAC address (through multicast). But the user is trying many different names... (for example). My question to Paul Vixie: On Wed, 2007-01-10 at 17:58 +0000, Paul Vixie wrote: > > ... > > These problems make me think that dot-local usage is not as general > > as it should be in IPv6. What about this approach? > > > > It works exactly as multicast DNS, except that there is no multicast. > > > > 1. Let the responder's DNS name be "johnsmith.local". The responder > > configures a name-based link-local IPv6 address: > > > > link-local subnet prefix | 64bithash("johnsmith.local") > > > > where hash is SHA1, and '|' means concatenation. It can be noted > > that 64bithash("johnsmith.local") is the IPv6 interface ID. > > The link-local subnet prefix is constant and well-known. > > you'll also have to cope with networks that aren't using EUI64 or for that > matter aren't using a 64-bit netmask. Is this an important limitation? (I'm asking the question) > and you'll have to cope with hash > collisions, however improbable they may be. Fortunately, there is no problem with that. If a given name-based address was accidentally configured the query will be silently dropped. > > 2. When the initiator user (or application) enters the name > > johnsmith.local, the DNS request is sent to the above address, > > instead of being multicast. > > > > Am I missing something? > > L2 broadcast will have to work in order to support ARP. if your L2 does not > support broadcast at all then i don't know what to suggest beyond some kind > of distinguished destination address that operates a location brokerage for > other services. if your L2 supports broadcast but at significant power cost > then i suggest we revive bmanning's old DNS DISCOVER proposal. I have no problem with that. Thanks pars -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 09:41:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H516R-000249-TG; Thu, 11 Jan 2007 09:40:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H516P-00022z-Qc for ipv6@ietf.org; Thu, 11 Jan 2007 09:40:25 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H516N-0000x6-JH for ipv6@ietf.org; Thu, 11 Jan 2007 09:40:25 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0BEeK5N009193 for ; Thu, 11 Jan 2007 09:40:20 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0BEeKBA160660 for ; Thu, 11 Jan 2007 09:40:20 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0BEeJ6G022576 for ; Thu, 11 Jan 2007 09:40:19 -0500 Received: from cichlid (wecm-9-67-117-236.wecm.ibm.com [9.67.117.236]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0BEeJHp022543; Thu, 11 Jan 2007 09:40:19 -0500 Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l0BEeB09018425; Thu, 11 Jan 2007 09:40:12 -0500 Message-Id: <200701111440.l0BEeB09018425@cichlid> To: pars.mutaf@int-evry.fr In-reply-to: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> Comments: In-reply-to Pars Mutaf message dated "Wed, 10 Jan 2007 11:06:38 +0100." Date: Thu, 11 Jan 2007 09:40:11 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf writes: > I believe that dot-local DNS (also called multicast DNS) will be > even more useful in the future. However, I suspect that there is > a problem. For example, in WiMax, a cellular standard, nodes cannot > L2 multicast. Who cares what happens at L2? That is not a concern to IP. If you are really saying that over a WiMax network, IP multicast is not supported, well, I would expect that this will be a problem for any application that relies on multicast. Presumably the market will sort out whether this is a problem or not. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 09:44:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51AQ-0005RT-MK; Thu, 11 Jan 2007 09:44:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51AO-0005Mf-JZ for ipv6@ietf.org; Thu, 11 Jan 2007 09:44:32 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51AL-0001jy-56 for ipv6@ietf.org; Thu, 11 Jan 2007 09:44:32 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0BEiMtA023073 for ; Thu, 11 Jan 2007 06:44:28 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l0BEiHoU007545 for ; Thu, 11 Jan 2007 09:44:21 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0BEiHag012967; Thu, 11 Jan 2007 09:44:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0BEiHKx012964; Thu, 11 Jan 2007 09:44:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17830.19776.818035.448466@gargle.gargle.HOWL> Date: Thu, 11 Jan 2007 09:44:16 -0500 From: James Carlson To: Alexandru Petrescu In-Reply-To: <45A61115.7010407@motorola.com> References: <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005> <459D4D0D.2010806@motorola.com> <17821.24747.178330.936711@gargle.gargle.HOWL> <45A61115.7010407@motorola.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ipv6@ietf.org Subject: Re: point-to-point links and ND (was: Review of draft-ietf-ipv6-2461bis-09.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Alexandru Petrescu writes: > If a ppp peer negotiates an Interface ID and puts it in the Neighbour > Cache attached to the ppp0 entry, won't break anything. When displaying > the NC the entry simply won't show up empty. Yes, it will break something. - Such a system will send Neighbor Advertisements that include the Target link-layer address option. If that message is sent to a peer that does *not* include this 'feature', then, from the peer's point of view, the option will include a bogus hardware address. The result is likely a loss of connectivity, as the peer may try (unsuccessfully) to send to a link-layer address that doesn't exist. - Such a system will receive Neighbor Advertisements from its peer that do not include the Target link-layer address option. What will it do? Per section 7.2.5 of RFC 2461, and because the system mistakenly believes that point-to-point links have L2 addresses, it will just *DISCARD* those messages, and will never attain REACHABLE state. Again, that leads to a loss of connectivity. The latter of those two seems crucial to me. Worse still, the ID numbers you're talking about are negotiated by PPP. This means that both ends of the link are already keenly aware of the ID numbers in use. It serves no purpose whatsoever to have the peers telling each other something that they already know. It's a solution off in search of a problem. > If same ppp peer declares that ppp0 interface nd-capable (instead of > currently declared nd-non-capable), I'm not sure what you're talking about here. There's no such "nd-capable" feature in the system I work on. In fact, I suspect having such a feature may be a design flaw, as RFC 2461 makes it pretty clear that ND is supposed to run on all links using IPv6. > and builds a virtual ll header > structure whose format is (src, dst on 64bits) Virtual LL header? I don't know what that is. > and then declare some > other constants for special ll multicast addresses then that ppp peer > won't crash. The issue is what to declare on the other ppp peer. > > By existing ND implementations I assume it's meant ND over an ll-full > (an interface with link-layer address). I think that as long as the > ND/ptp enhancements are applied only on ll-less interfaces that can > generate an IID then the other interfaces' implementations (eth, tun, > etc) won't be affected. No? That part is correct. Non-point-to-point interfaces are not affected by your proposal. But I believe interoperability for existing point-to-point systems is destroyed. > >> An "Interface ID" is exactly what ND needs on a ppp link. > > > > Disagree. Why does it need _any_ link layer address? Why should it > > care? > > A main ND's goal is to resolve the IP address into a ll address, so if > there's no ll address then no need of ND exchanges (especially no need > of NS/NA). Actually, ND does more than that. It verifies that the peer actually has the IPv6 address in question. If it doesn't have that address, then it doesn't respond, and you end up with an unreachable destination. This is part of the "unreachability detection" logic. It also has at least one "special" feature, which is the "R" bit. Peers can detect which one (or both) is a router. > At which point it would be difficult to say that ND runs > over ll-less addresses ok. I think. I disagree. The current RFC makes clear provisions for links (such as point-to-point links) that lack link-layer addressing. I think implementations should follow the current RFC advice. I do agree that ND has only somewhat marginal value on point-to-point links, but I don't think that implies that it should now be changed in an incompatible manner. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 10:57:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52HJ-0008Ft-T1; Thu, 11 Jan 2007 10:55:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52HI-0008EO-Ae for ipv6@ietf.org; Thu, 11 Jan 2007 10:55:44 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H52HG-0008EE-WE for ipv6@ietf.org; Thu, 11 Jan 2007 10:55:44 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 75F502FF39; Thu, 11 Jan 2007 16:55:36 +0100 (CET) From: Pars Mutaf To: Thomas Narten In-Reply-To: <200701111440.l0BEeB09018425@cichlid> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <200701111440.l0BEeB09018425@cichlid> Content-Type: text/plain Organization: INT Evry Date: Thu, 11 Jan 2007 16:55:37 +0100 Message-Id: <1168530937.11364.38.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 2007-01-11 at 09:40 -0500, Thomas Narten wrote: > Pars Mutaf writes: > > > I believe that dot-local DNS (also called multicast DNS) will be > > even more useful in the future. However, I suspect that there is > > a problem. For example, in WiMax, a cellular standard, nodes cannot > > L2 multicast. > > Who cares what happens at L2? That is not a concern to IP. But we can build new applications comfortably if we know that the signaling and energy costs were minimized ? (I mean regardless of L2 specific details) pars > If you are really saying that over a WiMax network, IP multicast is > not supported, well, I would expect that this will be a problem for > any application that relies on multicast. Presumably the market will > sort out whether this is a problem or not. > > Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 11:29:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52mW-0000oM-TM; Thu, 11 Jan 2007 11:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52mV-0000oE-Ee for ipv6@ietf.org; Thu, 11 Jan 2007 11:27:59 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H52mS-00021w-9H for ipv6@ietf.org; Thu, 11 Jan 2007 11:27:59 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1168532875!12872287!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 23831 invoked from network); 11 Jan 2007 16:27:55 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-2.tower-119.messagelabs.com with SMTP; 11 Jan 2007 16:27:55 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l0BGRk4q014582; Thu, 11 Jan 2007 10:27:50 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0BGRhoX026941; Thu, 11 Jan 2007 10:27:44 -0600 (CST) Message-ID: <45A6657E.703@motorola.com> Date: Thu, 11 Jan 2007 17:27:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: James Carlson References: <20070104073921.NUWB18162.oaamta02sl.mx.bigpond.com@PC20005> <459D4D0D.2010806@motorola.com> <17821.24747.178330.936711@gargle.gargle.HOWL> <45A61115.7010407@motorola.com> <17830.19776.818035.448466@gargle.gargle.HOWL> In-Reply-To: <17830.19776.818035.448466@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ipv6@ietf.org Subject: Re: point-to-point links and ND (was: Review of draft-ietf-ipv6-2461bis-09.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org JAmes, yes, it's a solution in search of a problem. There are problems in search of solutions too although not so apparent now. For example ND over tunnel interfaces, etc. For below items: (1) yes, IID as ll addresses may break legacy systems but then one could define new option Target 'Virtual' ll address so legacy will ignore them, (2) yes ND exchanging IIDs is redundant with ppp doing same, but then ND doesn't use ppp's IIDs in the NC either, (3) on system I work on ppp links never exchange NS/NA, (4) 'Virtual' Link Layer header is like 'Cooked' header in Ethereal captures over tunnel ifaces, (5) yes ND is about NUD too and finally (6) yes implementations should follow current RFCs and no incompatible extensions should be advanced. Thanks, Alex James Carlson wrote: > Alexandru Petrescu writes: >> If a ppp peer negotiates an Interface ID and puts it in the >> Neighbour Cache attached to the ppp0 entry, won't break anything. >> When displaying the NC the entry simply won't show up empty. > > Yes, it will break something. > > - Such a system will send Neighbor Advertisements that include the > Target link-layer address option. If that message is sent to a peer > that does *not* include this 'feature', then, from the peer's point > of view, the option will include a bogus hardware address. > > The result is likely a loss of connectivity, as the peer may try > (unsuccessfully) to send to a link-layer address that doesn't exist. > > - Such a system will receive Neighbor Advertisements from its peer > that do not include the Target link-layer address option. What will > it do? Per section 7.2.5 of RFC 2461, and because the system > mistakenly believes that point-to-point links have L2 addresses, it > will just *DISCARD* those messages, and will never attain REACHABLE > state. Again, that leads to a loss of connectivity. > > The latter of those two seems crucial to me. > > Worse still, the ID numbers you're talking about are negotiated by > PPP. This means that both ends of the link are already keenly aware > of the ID numbers in use. It serves no purpose whatsoever to have > the peers telling each other something that they already know. It's > a solution off in search of a problem. > >> If same ppp peer declares that ppp0 interface nd-capable (instead >> of currently declared nd-non-capable), > > I'm not sure what you're talking about here. There's no such > "nd-capable" feature in the system I work on. In fact, I suspect > having such a feature may be a design flaw, as RFC 2461 makes it > pretty clear that ND is supposed to run on all links using IPv6. > >> and builds a virtual ll header structure whose format is (src, dst >> on 64bits) > > Virtual LL header? I don't know what that is. > >> and then declare some other constants for special ll multicast >> addresses then that ppp peer won't crash. The issue is what to >> declare on the other ppp peer. >> >> By existing ND implementations I assume it's meant ND over an >> ll-full (an interface with link-layer address). I think that as >> long as the ND/ptp enhancements are applied only on ll-less >> interfaces that can generate an IID then the other interfaces' >> implementations (eth, tun, etc) won't be affected. No? > > That part is correct. Non-point-to-point interfaces are not affected > by your proposal. > > But I believe interoperability for existing point-to-point systems is > destroyed. > >>>> An "Interface ID" is exactly what ND needs on a ppp link. >>> Disagree. Why does it need _any_ link layer address? Why should >>> it care? >> A main ND's goal is to resolve the IP address into a ll address, so >> if there's no ll address then no need of ND exchanges (especially >> no need of NS/NA). > > Actually, ND does more than that. It verifies that the peer actually > has the IPv6 address in question. If it doesn't have that address, > then it doesn't respond, and you end up with an unreachable > destination. This is part of the "unreachability detection" logic. > > It also has at least one "special" feature, which is the "R" bit. > Peers can detect which one (or both) is a router. > >> At which point it would be difficult to say that ND runs over >> ll-less addresses ok. I think. > > I disagree. The current RFC makes clear provisions for links (such > as point-to-point links) that lack link-layer addressing. I think > implementations should follow the current RFC advice. > > I do agree that ND has only somewhat marginal value on point-to-point > links, but I don't think that implies that it should now be changed > in an incompatible manner. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 11:42:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52zc-0005wV-4a; Thu, 11 Jan 2007 11:41:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52za-0005vD-1t for ipv6@ietf.org; Thu, 11 Jan 2007 11:41:30 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H52zY-0005Ui-NA for ipv6@ietf.org; Thu, 11 Jan 2007 11:41:29 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 992832FF46; Thu, 11 Jan 2007 17:41:25 +0100 (CET) From: Pars Mutaf To: Stephane Bortzmeyer In-Reply-To: <20070111145544.GA15771@nic.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <20070111145544.GA15771@nic.fr> Content-Type: text/plain Organization: INT Evry Date: Thu, 11 Jan 2007 17:41:26 +0100 Message-Id: <1168533686.11364.60.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 2007-01-11 at 15:55 +0100, Stephane Bortzmeyer wrote: > On Thu, Jan 11, 2007 at 03:30:26PM +0100, > Pars Mutaf wrote > a message of 81 lines which said: > > > I used the term .local with no particular reason. If recent advances > > showed that it is unnecessary. > > Not unecessary: bad. If I'm correct, it is bad because everyone would > have a ".local" and merging of two organizations would become a > nightmare. It is quite easy and cheap to get a real domain name so > every organization, even non connected, should use one. Thanks for the clarification. > > I'm not even sure if my proposal needs to be "local". I can also > > reach other subnets in theory > > The domain name in use has nothing to do with the fact that the > protocol is routable or single-link. Different layers. > > > But I still don't see why I would send a multicast query if I know > > the destination's unicast address. Sending the DNS query directly to > > the destination may be useful. > > Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is > clearly possible (section 2.4). But it is still multicast DNS? pars -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 12:22:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53aW-0003oa-Pk; Thu, 11 Jan 2007 12:19:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53aV-0003oT-Fd for ipv6@ietf.org; Thu, 11 Jan 2007 12:19:39 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53aG-0005qT-6a for ipv6@ietf.org; Thu, 11 Jan 2007 12:19:39 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0BHJJPw019856 for ; Thu, 11 Jan 2007 09:19:23 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l0BHJICa011923 for ; Thu, 11 Jan 2007 12:19:18 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0BHJI67014156; Thu, 11 Jan 2007 12:19:18 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0BHJIvD014153; Thu, 11 Jan 2007 12:19:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17830.29078.392927.818232@gargle.gargle.HOWL> Date: Thu, 11 Jan 2007 12:19:18 -0500 From: James Carlson To: pars.mutaf@int-evry.fr In-Reply-To: <1168530937.11364.38.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <200701111440.l0BEeB09018425@cichlid> <1168530937.11364.38.camel@lor-maknavic3.int-evry.fr> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Thomas Narten , namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf writes: > On Thu, 2007-01-11 at 09:40 -0500, Thomas Narten wrote: > > Pars Mutaf writes: > > > > > I believe that dot-local DNS (also called multicast DNS) will be > > > even more useful in the future. However, I suspect that there is > > > a problem. For example, in WiMax, a cellular standard, nodes cannot > > > L2 multicast. > > > > Who cares what happens at L2? That is not a concern to IP. > > But we can build new applications comfortably if we know that the > signaling and energy costs were minimized ? > (I mean regardless of L2 specific details) I suspect that doing so implies the use of point-to-point links (rather than what appears to be broadcast emulation), and reducing energy costs would seem to require having cached data available on the single peer node to avoid querying "everybody." -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 13:36:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54l2-0003Di-6d; Thu, 11 Jan 2007 13:34:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54l0-0002xq-FQ for ipv6@ietf.org; Thu, 11 Jan 2007 13:34:34 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H54ku-0005nk-Un for ipv6@ietf.org; Thu, 11 Jan 2007 13:34:32 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l0BIWvkM030051; Thu, 11 Jan 2007 18:32:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l0BIWfbD030046; Thu, 11 Jan 2007 18:32:41 GMT Date: Thu, 11 Jan 2007 18:32:41 +0000 From: bmanning@karoshi.com To: Paul Vixie Message-ID: <20070111183241.GC29716@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60272.1168537982@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > > L2 broadcast will have to work in order to support ARP. if your L2 does > > > not support broadcast at all then i don't know what to suggest beyond some > > > kind of distinguished destination address that operates a location > > > brokerage for other services. if your L2 supports broadcast but at > > > significant power cost then i suggest we revive bmanning's old DNS > > > DISCOVER proposal. > > > > I have no problem with that. > > yo, bill! > yes? you mean the DISCOVER ID that is -still- in the RFCED queue? (and has been in one form or another for the past eight years?) why, under $DIETIES green earth would you want to push a dead technology? The IESG is dead-set against this. --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 11 16:26:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57Pw-0005h1-1K; Thu, 11 Jan 2007 16:25:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57Pt-0005g5-Tc for ipv6@ietf.org; Thu, 11 Jan 2007 16:24:57 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57Ps-0006qN-Gs for ipv6@ietf.org; Thu, 11 Jan 2007 16:24:57 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l0BLNOkM031711; Thu, 11 Jan 2007 21:23:24 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l0BLN2eV031707; Thu, 11 Jan 2007 21:23:02 GMT Date: Thu, 11 Jan 2007 21:23:01 +0000 From: bmanning@karoshi.com To: Paul Vixie Message-ID: <20070111212301.GA31575@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> <20070111183241.GC29716@vacation.karoshi.com.> <69870.1168541446@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69870.1168541446@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > why, under $DIETIES green earth would you want to push a dead > > technology? The IESG is dead-set against this. > > because the IESG has turned over N times during those 8 years, and the idea > is still solid and useful and interesting, and the current proposed RFC is > experimental, and most importantly, because the need for it will continue to > resurface until we push it over the top of the hill and roll it down to the > town. sigh... let me ramp up here. do you want the code (8.1.2 based and haq'ed into 9.3.1 ) or do you want to start fresh? the text will be pumped out shortly. --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 04:39:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Iq0-000097-1F; Fri, 12 Jan 2007 04:36:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ipx-00008q-Br for ipv6@ietf.org; Fri, 12 Jan 2007 04:36:37 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Ipw-0004ck-TB for ipv6@ietf.org; Fri, 12 Jan 2007 04:36:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l0C9aVYe015212; Fri, 12 Jan 2007 11:36:32 +0200 Date: Fri, 12 Jan 2007 11:36:31 +0200 (EET) From: Pekka Savola To: Paul Vixie In-Reply-To: <69870.1168541446@sa.vix.com> Message-ID: References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> <20070111183241.GC29716@vacation.karoshi.com.> <69870.1168541446@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2437/Fri Jan 12 01:59:09 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com Subject: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org [DNS opcode DISCOVER] On Thu, 11 Jan 2007, Paul Vixie wrote: > yes, it has. > >> why, under $DIETIES green earth would you want to push a dead >> technology? The IESG is dead-set against this. > > because the IESG has turned over N times during those 8 years, and the idea > is still solid and useful and interesting, and the current proposed RFC is > experimental, and most importantly, because the need for it will continue to > resurface until we push it over the top of the hill and roll it down to the > town. The problem was, AFAIR, that allocating opcodes requires a Standards Action. No experimental spec can do that. If DISCOVER is to be revived it will need to use one of other publication processes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXy-0005nm-3k; Fri, 12 Jan 2007 07:30:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5BxQ-0000Lh-JG for ipv6@ietf.org; Thu, 11 Jan 2007 21:15:52 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5BxN-0007tO-Gv for ipv6@ietf.org; Thu, 11 Jan 2007 21:15:52 -0500 Received: (qmail 13717 invoked from network); 12 Jan 2007 02:34:40 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 12 Jan 2007 02:34:40 -0000 Message-ID: <45A6EF31.9040300@necom830.hpcl.titech.ac.jp> Date: Fri, 12 Jan 2007 11:15:13 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: pars.mutaf@int-evry.fr References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <200701111440.l0BEeB09018425@cichlid> <1168530937.11364.38.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168530937.11364.38.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: Thomas Narten , namedroppers@ops.ietf.org, ipv6@ietf.org Subject: IPv6 design flaw to force all-nodes multicast X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf wrote: >>Who cares what happens at L2? That is not a concern to IP. > But we can build new applications comfortably if we know that the > signaling and energy costs were minimized ? > (I mean regardless of L2 specific details) With the obvious example of you, link-local subnet prefix | 64bithash("johnsmith.local") supporting a L3 multicast address over broadcast L1 is just as costly as supporting a L3 unicast address over broadcast L1, regardless of L2 specific details. Wireless L2 protocols not supporting L3 multicast is just poor. In addition, wireless L2 protocols can also naturally support L2 broadcast. If power consumption of terminals but not central stations is the issue, broadcast can be issued only from (or relayed by) central stations and can be rate limited. Thus, all the properly designed L3 or upper protocols can enjoy properly designed L2 multicast at any rate and L2 broadcast maybe with rate limitation. It has nothing specific to mDNS. However, there is an IPv6 design flaw that all the nodess join all-nodes multicast, which is just a common multicast address for L2. The flaw was derived from a misconception that multicast were less costly than broadcast, though broadcast is less costly than multicast. All-nodes multicast can cost a lot if someone use it frequently. For example, ND is specified with: o MinRtrAdvInterval 0.03 seconds That is, as IPv6 is not propderly designed, L2 under it MAY suppress multicast entirely and SHOULD supress the all-nodes multicast address. A dirty workaround is to supress rate of L2 address of all-nodes multicast and never use the same L2 address for other rate-unlimited multicast addresses. Masataka Ohta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -----------From ipv6-bounces@ietf.org Fri Jan 12 07:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXy-0005nm-3k; Fri, 12 Jan 2007 07:30:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5BxQ-0000Lh-JG for ipv6@ietf.org; Thu, 11 Jan 2007 21:15:52 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5BxN-0007tO-Gv for ipv6@ietf.org; Thu, 11 Jan 2007 21:15:52 -0500 Received: (qmail 13717 invoked from network); 12 Jan 2007 02:34:40 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 12 Jan 2007 02:34:40 -0000 Message-ID: <45A6EF31.9040300@necom830.hpcl.titech.ac.jp> Date: Fri, 12 Jan 2007 11:15:13 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: pars.mutaf@int-evry.fr References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <200701111440.l0BEeB09018425@cichlid> <1168530937.11364.38.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168530937.11364.38.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: Thomas Narten , namedroppers@ops.ietf.org, ipv6@ietf.org Subject: IPv6 design flaw to force all-nodes multicast X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars Mutaf wrote: >>Who cares what happens at L2? That is not a concern to IP. > But we can build new applications comfortably if we know that the > signaling and energy costs were minimized ? > (I mean regardless of L2 specific details) With the obvious example of you, link-local subnet prefix | 64bithash("johnsmith.local") supporting a L3 multicast address over broadcast L1 is just as costly as supporting a L3 unicast address over broadcast L1, regardless of L2 specific details. Wireless L2 protocols not supporting L3 multicast is just poor. In addition, wireless L2 protocols can also naturally support L2 broadcast. If power consumption of terminals but not central stations is the issue, broadcast can be issued only from (or relayed by) central stations and can be rate limited. Thus, all the properly designed L3 or upper protocols can enjoy properly designed L2 multicast at any rate and L2 broadcast maybe with rate limitation. It has nothing specific to mDNS. However, there is an IPv6 design flaw that all the nodess join all-nodes multicast, which is just a common multicast address for L2. The flaw was derived from a misconception that multicast were less costly than broadcast, though broadcast is less costly than multicast. All-nodes multicast can cost a lot if someone use it frequently. For example, ND is specified with: o MinRtrAdvInterval 0.03 seconds That is, as IPv6 is not propderly designed, L2 under it MAY suppress multicast entirely and SHOULD supress the all-nodes multicast address. A dirty workaround is to supress rate of L2 address of all-nodes multicast and never use the same L2 address for other rate-unlimited multicast addresses. Masataka Ohta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXw-0005it-PH; Fri, 12 Jan 2007 07:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H550k-0004Sj-SB for ipv6@ietf.org; Thu, 11 Jan 2007 13:50:50 -0500 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H550g-0001JD-Q9 for ipv6@ietf.org; Thu, 11 Jan 2007 13:50:50 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 413AD11425; Thu, 11 Jan 2007 18:50:46 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bmanning@karoshi.com In-Reply-To: Your message of "Thu, 11 Jan 2007 18:32:41 GMT." <20070111183241.GC29716@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> <20070111183241.GC29716@vacation.karoshi.com.> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 11 Jan 2007 18:50:46 +0000 Message-ID: <69870.1168541446@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > > > ... if your L2 supports broadcast but at significant power cost then i > > > > suggest we revive bmanning's old DNS DISCOVER proposal. > > > > > > I have no problem with that. > > > > yo, bill! > > yes? yes, you. > you mean the DISCOVER ID that is -still- in the RFCED queue? yes, that one. > (and has been in one form or another for the past eight years?) yes, it has. > why, under $DIETIES green earth would you want to push a dead > technology? The IESG is dead-set against this. because the IESG has turned over N times during those 8 years, and the idea is still solid and useful and interesting, and the current proposed RFC is experimental, and most importantly, because the need for it will continue to resurface until we push it over the top of the hill and roll it down to the town. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXw-0005it-PH; Fri, 12 Jan 2007 07:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H550k-0004Sj-SB for ipv6@ietf.org; Thu, 11 Jan 2007 13:50:50 -0500 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H550g-0001JD-Q9 for ipv6@ietf.org; Thu, 11 Jan 2007 13:50:50 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 413AD11425; Thu, 11 Jan 2007 18:50:46 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bmanning@karoshi.com In-Reply-To: Your message of "Thu, 11 Jan 2007 18:32:41 GMT." <20070111183241.GC29716@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> <20070111183241.GC29716@vacation.karoshi.com.> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 11 Jan 2007 18:50:46 +0000 Message-ID: <69870.1168541446@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > > > ... if your L2 supports broadcast but at significant power cost then i > > > > suggest we revive bmanning's old DNS DISCOVER proposal. > > > > > > I have no problem with that. > > > > yo, bill! > > yes? yes, you. > you mean the DISCOVER ID that is -still- in the RFCED queue? yes, that one. > (and has been in one form or another for the past eight years?) yes, it has. > why, under $DIETIES green earth would you want to push a dead > technology? The IESG is dead-set against this. because the IESG has turned over N times during those 8 years, and the idea is still solid and useful and interesting, and the current proposed RFC is experimental, and most importantly, because the need for it will continue to resurface until we push it over the top of the hill and roll it down to the town. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXy-0005oO-Kh; Fri, 12 Jan 2007 07:30:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Hm8-0002yU-G6 for ipv6@ietf.org; Fri, 12 Jan 2007 03:28:36 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Hm6-0006hu-75 for ipv6@ietf.org; Fri, 12 Jan 2007 03:28:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7C0A626C224; Fri, 12 Jan 2007 09:28:22 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B588126C159; Fri, 12 Jan 2007 09:28:21 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A7A5C58ED14; Fri, 12 Jan 2007 09:28:21 +0100 (CET) Date: Fri, 12 Jan 2007 09:28:21 +0100 From: Stephane Bortzmeyer To: Pars Mutaf Message-ID: <20070112082821.GA22673@nic.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <20070111145544.GA15771@nic.fr> <1168533686.11364.60.camel@lor-maknavic3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1168533686.11364.60.camel@lor-maknavic3.int-evry.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, Stephane Bortzmeyer , ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, Jan 11, 2007 at 05:41:26PM +0100, Pars Mutaf wrote a message of 31 lines which said: > > Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is > > clearly possible (section 2.4). > > But it is still multicast DNS? I really do not understand you. Try in French :-) Because, obviously, if it is unicast, it is not multicast :-) Also, it is not really DNS, it is LLMNR (same packet format, many similar concepts but a different protocol). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXw-0005hu-6d; Fri, 12 Jan 2007 07:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5470-0006jQ-Cd for ipv6@ietf.org; Thu, 11 Jan 2007 12:53:14 -0500 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H546x-0003Te-Ic for ipv6@ietf.org; Thu, 11 Jan 2007 12:53:14 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6640211427; Thu, 11 Jan 2007 17:53:02 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: pars.mutaf@int-evry.fr In-Reply-To: Your message of "Thu, 11 Jan 2007 15:30:26 +0100." <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 11 Jan 2007 17:53:02 +0000 Message-ID: <60272.1168537982@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > My question to Paul Vixie: > > > you'll also have to cope with networks that aren't using EUI64 or for that > > matter aren't using a 64-bit netmask. > > Is this an important limitation? (I'm asking the question) i think so, but it's a subjective matter. we're funded to do some early DHCPv6 work at the moment, showing that at least one large company in the world doesn't think stateless autoconfig is the right way to go. i think there's also reason to believe that the "/64 per LAN" ideology might be tied to the stateless autoconfig ideology. (DHCPv6 and /112's work fine.) > > you'll have to cope with hash collisions, however improbable they may be. > > Fortunately, there is no problem with that. If a given name-based address > was accidentally configured the query will be silently dropped. that sounds like a problem, to me. why isn't it a problem? > > L2 broadcast will have to work in order to support ARP. if your L2 does > > not support broadcast at all then i don't know what to suggest beyond some > > kind of distinguished destination address that operates a location > > brokerage for other services. if your L2 supports broadcast but at > > significant power cost then i suggest we revive bmanning's old DNS > > DISCOVER proposal. > > I have no problem with that. yo, bill! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXv-0005ho-Ct; Fri, 12 Jan 2007 07:30:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51LS-0002pO-3Z for ipv6@ietf.org; Thu, 11 Jan 2007 09:55:58 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51LQ-0003of-Qx for ipv6@ietf.org; Thu, 11 Jan 2007 09:55:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0F6DC26C281; Thu, 11 Jan 2007 15:55:45 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7188D26C18A; Thu, 11 Jan 2007 15:55:44 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6D9DC58ED21; Thu, 11 Jan 2007 15:55:44 +0100 (CET) Date: Thu, 11 Jan 2007 15:55:44 +0100 From: Stephane Bortzmeyer To: Pars Mutaf Message-ID: <20070111145544.GA15771@nic.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, Jan 11, 2007 at 03:30:26PM +0100, Pars Mutaf wrote a message of 81 lines which said: > I used the term .local with no particular reason. If recent advances > showed that it is unnecessary. Not unecessary: bad. If I'm correct, it is bad because everyone would have a ".local" and merging of two organizations would become a nightmare. It is quite easy and cheap to get a real domain name so every organization, even non connected, should use one. > I'm not even sure if my proposal needs to be "local". I can also > reach other subnets in theory The domain name in use has nothing to do with the fact that the protocol is routable or single-link. Different layers. > But I still don't see why I would send a multicast query if I know > the destination's unicast address. Sending the DNS query directly to > the destination may be useful. Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is clearly possible (section 2.4). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXy-0005oO-Kh; Fri, 12 Jan 2007 07:30:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Hm8-0002yU-G6 for ipv6@ietf.org; Fri, 12 Jan 2007 03:28:36 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Hm6-0006hu-75 for ipv6@ietf.org; Fri, 12 Jan 2007 03:28:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7C0A626C224; Fri, 12 Jan 2007 09:28:22 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B588126C159; Fri, 12 Jan 2007 09:28:21 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A7A5C58ED14; Fri, 12 Jan 2007 09:28:21 +0100 (CET) Date: Fri, 12 Jan 2007 09:28:21 +0100 From: Stephane Bortzmeyer To: Pars Mutaf Message-ID: <20070112082821.GA22673@nic.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <20070111145544.GA15771@nic.fr> <1168533686.11364.60.camel@lor-maknavic3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1168533686.11364.60.camel@lor-maknavic3.int-evry.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, Stephane Bortzmeyer , ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, Jan 11, 2007 at 05:41:26PM +0100, Pars Mutaf wrote a message of 31 lines which said: > > Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is > > clearly possible (section 2.4). > > But it is still multicast DNS? I really do not understand you. Try in French :-) Because, obviously, if it is unicast, it is not multicast :-) Also, it is not really DNS, it is LLMNR (same packet format, many similar concepts but a different protocol). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXw-0005hu-6d; Fri, 12 Jan 2007 07:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5470-0006jQ-Cd for ipv6@ietf.org; Thu, 11 Jan 2007 12:53:14 -0500 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H546x-0003Te-Ic for ipv6@ietf.org; Thu, 11 Jan 2007 12:53:14 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6640211427; Thu, 11 Jan 2007 17:53:02 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: pars.mutaf@int-evry.fr In-Reply-To: Your message of "Thu, 11 Jan 2007 15:30:26 +0100." <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 11 Jan 2007 17:53:02 +0000 Message-ID: <60272.1168537982@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > My question to Paul Vixie: > > > you'll also have to cope with networks that aren't using EUI64 or for that > > matter aren't using a 64-bit netmask. > > Is this an important limitation? (I'm asking the question) i think so, but it's a subjective matter. we're funded to do some early DHCPv6 work at the moment, showing that at least one large company in the world doesn't think stateless autoconfig is the right way to go. i think there's also reason to believe that the "/64 per LAN" ideology might be tied to the stateless autoconfig ideology. (DHCPv6 and /112's work fine.) > > you'll have to cope with hash collisions, however improbable they may be. > > Fortunately, there is no problem with that. If a given name-based address > was accidentally configured the query will be silently dropped. that sounds like a problem, to me. why isn't it a problem? > > L2 broadcast will have to work in order to support ARP. if your L2 does > > not support broadcast at all then i don't know what to suggest beyond some > > kind of distinguished destination address that operates a location > > brokerage for other services. if your L2 supports broadcast but at > > significant power cost then i suggest we revive bmanning's old DNS > > DISCOVER proposal. > > I have no problem with that. yo, bill! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 07:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LXv-0005ho-Ct; Fri, 12 Jan 2007 07:30:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51LS-0002pO-3Z for ipv6@ietf.org; Thu, 11 Jan 2007 09:55:58 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51LQ-0003of-Qx for ipv6@ietf.org; Thu, 11 Jan 2007 09:55:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0F6DC26C281; Thu, 11 Jan 2007 15:55:45 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7188D26C18A; Thu, 11 Jan 2007 15:55:44 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6D9DC58ED21; Thu, 11 Jan 2007 15:55:44 +0100 (CET) Date: Thu, 11 Jan 2007 15:55:44 +0100 From: Stephane Bortzmeyer To: Pars Mutaf Message-ID: <20070111145544.GA15771@nic.fr> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Fri, 12 Jan 2007 07:30:10 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, Jan 11, 2007 at 03:30:26PM +0100, Pars Mutaf wrote a message of 81 lines which said: > I used the term .local with no particular reason. If recent advances > showed that it is unnecessary. Not unecessary: bad. If I'm correct, it is bad because everyone would have a ".local" and merging of two organizations would become a nightmare. It is quite easy and cheap to get a real domain name so every organization, even non connected, should use one. > I'm not even sure if my proposal needs to be "local". I can also > reach other subnets in theory The domain name in use has nothing to do with the fact that the protocol is routable or single-link. Different layers. > But I still don't see why I would send a multicast query if I know > the destination's unicast address. Sending the DNS query directly to > the destination may be useful. Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is clearly possible (section 2.4). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 09:29:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NNr-0001a9-6S; Fri, 12 Jan 2007 09:27:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NNp-0001a3-OF for ipv6@ietf.org; Fri, 12 Jan 2007 09:27:53 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NNo-00072h-AP for ipv6@ietf.org; Fri, 12 Jan 2007 09:27:53 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l0CEQNkM006840; Fri, 12 Jan 2007 14:26:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l0CEPwBw006831; Fri, 12 Jan 2007 14:25:58 GMT Date: Fri, 12 Jan 2007 14:25:57 +0000 From: bmanning@karoshi.com To: Pekka Savola Message-ID: <20070112142557.GA6738@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> <20070111183241.GC29716@vacation.karoshi.com.> <69870.1168541446@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com, Paul Vixie Subject: Re: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, Jan 12, 2007 at 11:36:31AM +0200, Pekka Savola wrote: > [DNS opcode DISCOVER] > > On Thu, 11 Jan 2007, Paul Vixie wrote: > >yes, it has. > > > >> why, under $DIETIES green earth would you want to push a dead > >> technology? The IESG is dead-set against this. > > > >because the IESG has turned over N times during those 8 years, and the idea > >is still solid and useful and interesting, and the current proposed RFC is > >experimental, and most importantly, because the need for it will continue > >to > >resurface until we push it over the top of the hill and roll it down to the > >town. > > The problem was, AFAIR, that allocating opcodes requires a Standards > Action. No experimental spec can do that. If DISCOVER is to be > revived it will need to use one of other publication processes. > > -- > Pekka Savola "You each name yourselves king, yet the of course, the justification for requiring a Standards Track action for the allocation of an opcode was never questioned. the impediment that such a requirement places on development is so onerous that many folks just ignore the IETF's strictures and don't bring their work to that forum. Who was it that promoted an RFC on getting allocations for experimental use? Can't remember who that was, but it was a little to late. DISCOVER is in no shape to be a full-fledged Standards track item. It IS an idea that is worthy of further use/experimentation to see if it can be integrated into a data-driven networking architecture. And for that reason, it is worthy of an opcode assignment. But, thats my opinion and we know what that is worth. --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 12:19:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q2F-0005sH-73; Fri, 12 Jan 2007 12:17:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q2D-0005je-Gg for ipv6@ietf.org; Fri, 12 Jan 2007 12:17:45 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Q2C-0006G5-83 for ipv6@ietf.org; Fri, 12 Jan 2007 12:17:45 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 831D830013; Fri, 12 Jan 2007 18:17:41 +0100 (CET) From: Pars Mutaf To: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont In-Reply-To: <200701101756.00347@auguste.remlab.net> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <17828.59150.365134.221293@gargle.gargle.HOWL> <1168442066.23741.30.camel@lor-maknavic3.int-evry.fr> <200701101756.00347@auguste.remlab.net> Content-Type: text/plain; charset=UTF-8 Organization: INT Evry Date: Fri, 12 Jan 2007 18:17:46 +0100 Message-Id: <1168622266.8657.16.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, 2007-01-10 at 17:56 +0200, R=C3=A9mi Denis-Courmont wrote: > Le mercredi 10 janvier 2007 17:14, Pars Mutaf a =C3=A9crit : > > > So, the proposal is that if the hash collides for different names, > > > then "johnsmith.local" must rename himself, right? > > > > Right. Please let me know if you see a problem with this. >=20 > My understanding of James remarks is that your proposal merely moves th= e=20 > problem away from DNS to Neighbor Discovery, but does not solve the=20 > core issue at all, which is that some kind of multicast/broadcast is=20 > needed for non-point-to-point IPv6 links. Hi Remi,=20 (Sorry for the delay, I'm trying to respond to each mail but I rate limited myself) The main idea of my proposal was: "If it works using unicast, then we *really* don't care what=20 happens at L2." Is it multicast capable or not? It is poor design or not? Is it=20 costly or not ? (in terms of energy and signaling)... All these=20 questions would disappear. That was my point. But folks say: multicast is a MUST. I can't really argue=20 against that. pars (I CCed again namedroppers without your permission, supposing=20 that is not a problem for you) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 12 13:21:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QzC-0006Kv-1m; Fri, 12 Jan 2007 13:18:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QzA-0006FE-El for ipv6@ietf.org; Fri, 12 Jan 2007 13:18:40 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Qz8-0003lE-29 for ipv6@ietf.org; Fri, 12 Jan 2007 13:18:40 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id E75482FF53; Fri, 12 Jan 2007 19:18:32 +0100 (CET) From: Pars Mutaf To: Paul Vixie In-Reply-To: <60272.1168537982@sa.vix.com> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> Content-Type: text/plain Organization: INT Evry Date: Fri, 12 Jan 2007 19:18:38 +0100 Message-Id: <1168625918.10983.14.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 2007-01-11 at 17:53 +0000, Paul Vixie wrote: > > My question to Paul Vixie: > > > > > you'll also have to cope with networks that aren't using EUI64 or for that > > > matter aren't using a 64-bit netmask. > > > > Is this an important limitation? (I'm asking the question) > > i think so, but it's a subjective matter. we're funded to do some early > DHCPv6 work at the moment, showing that at least one large company in the > world doesn't think stateless autoconfig is the right way to go. i think > there's also reason to believe that the "/64 per LAN" ideology might be > tied to the stateless autoconfig ideology. (DHCPv6 and /112's work fine.) > Yes I'm from mobile/stateless school :-) > > > you'll have to cope with hash collisions, however improbable they may be. > > > > Fortunately, there is no problem with that. If a given name-based address > > was accidentally configured the query will be silently dropped. > > that sounds like a problem, to me. why isn't it a problem? Quick reminder: The responder configured IPv6 address from hash(name). The query is sent to that unicast address. For example John wants to reach Carol. But Carol isn't here. Instead there is David. And accidentally hash(Carol)=hash(David). The DNS query(Carol) will be received by David. David can silently drop it. Or he can respond: I'm not Carol. I missed something? Thanks pars > > > L2 broadcast will have to work in order to support ARP. if your L2 does > > > not support broadcast at all then i don't know what to suggest beyond some > > > kind of distinguished destination address that operates a location > > > brokerage for other services. if your L2 supports broadcast but at > > > significant power cost then i suggest we revive bmanning's old DNS > > > DISCOVER proposal. > > > > I have no problem with that. > > yo, bill! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 08:11:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ib7-0006Nm-Ti; Sat, 13 Jan 2007 08:07:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ib6-0006Ng-Nx for ipv6@ietf.org; Sat, 13 Jan 2007 08:07:00 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5ib5-0005gI-5k for ipv6@ietf.org; Sat, 13 Jan 2007 08:07:00 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l0DD5okM016270; Sat, 13 Jan 2007 13:05:50 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l0DD5gqS016269; Sat, 13 Jan 2007 13:05:42 GMT Date: Sat, 13 Jan 2007 13:05:41 +0000 From: bmanning@karoshi.com To: Stephane Bortzmeyer Message-ID: <20070113130541.GA16232@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <20070111145544.GA15771@nic.fr> <1168533686.11364.60.camel@lor-maknavic3.int-evry.fr> <20070112082821.GA22673@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070112082821.GA22673@nic.fr> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, Jan 12, 2007 at 09:28:21AM +0100, Stephane Bortzmeyer wrote: > On Thu, Jan 11, 2007 at 05:41:26PM +0100, > Pars Mutaf wrote > a message of 31 lines which said: > > > > Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is > > > clearly possible (section 2.4). > > > > But it is still multicast DNS? > > I really do not understand you. Try in French :-) Because, obviously, > if it is unicast, it is not multicast :-) unicast is a degenerative case of multicast. > Also, it is not really DNS, it is LLMNR (same packet format, many > similar concepts but a different protocol). LLMNR is not DNS mostly 'cause the IESG mandated it. one could easly see this as DNS on a different port#. --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 08:16:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ikG-0004Ji-0t; Sat, 13 Jan 2007 08:16:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ikF-0004JH-4h for ipv6@ietf.org; Sat, 13 Jan 2007 08:16:27 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5ikB-0007IQ-Vk for ipv6@ietf.org; Sat, 13 Jan 2007 08:16:27 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l0DDEnkM016343; Sat, 13 Jan 2007 13:14:49 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l0DDESrk016341; Sat, 13 Jan 2007 13:14:28 GMT Date: Sat, 13 Jan 2007 13:14:23 +0000 From: bmanning@karoshi.com To: Paul Vixie Message-ID: <20070113131423.GA16306@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <98793.1168451932@sa.vix.com> <1168525826.11364.32.camel@lor-maknavic3.int-evry.fr> <60272.1168537982@sa.vix.com> <20070111183241.GC29716@vacation.karoshi.com.> <69870.1168541446@sa.vix.com> <20070111212301.GA31575@vacation.karoshi.com.> <10383.1168556624@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10383.1168556624@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: namedroppers@ops.ietf.org, bmanning@karoshi.com, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, Jan 11, 2007 at 11:03:44PM +0000, Paul Vixie wrote: > > do you want the code (8.1.2 based and haq'ed into 9.3.1 ) or do you > > want to start fresh? > > put both up for ftp and share the url's here, and isc among others will take > a look at them. i think i will defer for the moment. the code uses OPCODE 5, which, if seen in the wild would further antagonise the IESG. > > > the text will be pumped out shortly. > > thanksly. the last iteration, castrated and pacified for IESG/IETF consumption. --------------------------------------------------------------------- Network Working Group Bill Manning draft-manning-opcode-discover-02.txt ep.net Expires: May 2006 Paul Vixie ISC 16 November 2005 DISCOVER: Supporting Multicast DNS Queries By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on XXXXXX. Distribution of this memo is unlimited. Abstract This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. 1. Introduction In the standard Domain Name System (DNS) [3] [4], queries are always unicast using the QUERY opcode. The TBDS research project, funded under DARPA grant F30602-99-1-0523, explored the use of multicast DNS [3][4] queries for resource discovery. Multicast queries may return multiple replies, while the standard DNS QUERY operation [5] expects a single reply. Instead of extending the QUERY opcode, the project developed and tested a new query operation, DISCOVER, that is designed to accommodate multiple responses from a multicast query. This memo documents the processing rules for DISCOVER, for possible incorporation in a future revision of the DNS specification. 2. DISCOVER Processing Rules A requester will send a DISCOVER query message to a multicast destination address, with some particular multicast scope. The requester must be prepared to receive multiple replies from multiple responders, although we expect that there will be a single reply per responder. DISCOVER responses (i.e., response messages from DISCOVER queries) have standard Answer, Authority, and Additional sections. For example, the DISCOVER response is the same as the response to a QUERY operation. Zero-content answers should not be sent, to avoid badly formed or unfulfilled requests. Responses should be sent to th unicast address of the requester, and the source address should reflect the unicast address of the responder. DISCOVER responses may echo the request's Question section or leave it blank, just as for QUERY. DISCOVER works like QUERY, except: 1. The Question section of a DISCOVER operation contains tuples, if the section is present. Within TBDS, this structure was augmented with: . While this worked, it would be cleaner to ask the SRV question in a separate pass, and any future work should take this into consideration. 2. If QDCOUNT equals 0, then only servers willing to do recursion should answer; other servers must silently discard a DISCOVER request with QDCOUNT equals 0. 3. if QDCOUNT is not equal to 0, then only servers that are authoritative for the zones named by some QNAME should answer. Hence, replies to DISCOVER queries will always be authoritative or else have RA (Recursion Available) set. 3. Using DISCOVER Queries 3.1 Performing Host Lookups To perform a hostname lookup using DISCOVER, a node could: o Compute the zone name of the enclosing in-addr.arpa, ip6.int, or ip6.arpa domain. o DISCOVER whether any in-scope server(s) are authoritative for this zone. If so, query these authoritative servers for local in-addr/ip6 names. o If not, DISCOVER whether there are recursive servers available. If so, query these recursive servers for local in-addr/ip6 names. The requester can determine from the replies whether there are any DNS servers that are authoritative (or support recursion) for the zone. o Once the host's FQDN is known, repeat the process to discover the closest enclosing authoritative server for this local name. o Cache all NS and A data learned in this process, respecting TTL's. 3.2 Performing Service Lookups To lookup a service name using DISCOVER, the following steps may be used: o Use DISCOVER as outlines in Section 3.1 to perform gethostbyaddr() and then gethostbyname() on one's own link-local address. This gives a list of local authoritative servers. o Assume that the closest enclosing zone for which an authoritative server responds to an in-scope DISCOVER message is this host's "parent domain", and compute the SRV name as _service._transport.*.parentdomain. This is a change to the definition as defined in RFC 1034 [3]. A wildcard label ("*") in the QNAME used in a DNS message with op-code DISCOVER should be evaluated with special rules: the wildcardshould match any label for which the DNS server data is authoritative. For example 'x.*.example.com.' would match 'x.y.example.com.' and 'x.yy.example.com.', provided that the server was authoritative for 'example.com.' o Finally, send a SRV query for this SRV name to the discovered local authoritative servers, to complete the getservbyname() call. This call returns a structure that can be populated by response values, as follows: s_name The name of the service, "_service" without the preceding underscore. s_aliases The names returned in the SRV RRs in replies to the query. s_port The port number in the SRV RRs replies to the query. If these port numbers disagree - one of the port numbers is chosen, and only those names which correspond are returned. s_proto The transport protocol from named by the "_transport" label, without the preceding underscore. 3.3 Using DISCOVER for Disconnected Names DISCOVER allows discovery of a host (for example, a printer offering LPD services) whose DNS server answers authoritatively for a domain name that hasn't been delegated to it, but is defined within some local scope. Since DISCOVER is explicitly defined to discover undelegated zones for tightly-scoped queries, this behavior isn't a violation of DNS's coherency principles. Note that a responder to DISCOVER might not be traditional DNS software, it could be special-purpose software. DISCOVER usage for disconnected networks with no authoritative servers can be achieved using the following conditions. o Hosts run a "stub server" that acts as though its FQDN were a zone name. o The computed SOA gives the host's FQDN as the MNAME, "." as the ANAME, seconds-since-1Jan2000 as the SERIAL, and low constants for EXPIRE and the other SOA timers. o NS is used as the host's FQDN. o The glue is computed as the host's link-local address, or hosts may run a "DNS stub server" that acts as though its FQDN were a zone name. The rules governing the behavior of this stub server are given elsewhere [1] [2]. Such stub servers should answer DISCOVER packets for its zone, and will be found by the iterative "discover closest enclosing authority server" by DISCOVER clients, in either the gethostbyname() or SRV cases described above. Note that stub servers answer only with zone names which exactly match QNAME's, not with zone names which are owned by QNAME's. 4. IANA Considerations The IANA will need to assign a numeric value for the DISCOVER opcode. 5. Security Considerations No new security considerations are known to be introduced with a new DNS query operation. However, using multicast for service discovery has the potential for denial of service from flooding attacks. It may also be possible to enable deliberate misconfiguration of clients simply by running a malicious DNS server that falsely claims to be authoritative for delegations. One possible way to mitigate this threat is to use credentials, such as CERT resource records within an RR set. The TBDS project took this approach. TBDS did not directly utilize DNSSEC and so possible interactions with DNSSEC aware/capable servers are unknown. 6. Acknowledgments This material was generated in discussions on the mdns maili list hosted by Zocalo in March 2000 and updated by discussions in September/October 2003 on a closed mailing list. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, Erik Guttman were active contributors. Suzanne Woolf was part of the original implementation team and an invaluable sanity checker. 7. References [1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS", Work in Progress, November 2000. [2] Woodcock, B., Manning, B., "Multicast Domain Name Service", Work in Progress, August 2000. [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987. [5] QUERY opcode -- defined in section 3.7, 4.3, and section 5 of RFC 1034 and in section 4.1.1 of RFC 1035. Authors' Addresses Bill Manning PO 12317 Marina del Rey, CA. 90295 Paul Vixie 950 Charter Street Redwood City, CA 94063 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 08:34:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5j1W-0007ty-GA; Sat, 13 Jan 2007 08:34:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S6D-0003R7-U0 for ipv6@ietf.org; Fri, 12 Jan 2007 14:30:01 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5S6C-0004Qk-Ed for ipv6@ietf.org; Fri, 12 Jan 2007 14:30:01 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l0CJTxSP022641; Fri, 12 Jan 2007 11:29:59 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 11:29:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jan 2007 11:29:50 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD370105A34B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] Thread-Index: Acc2fym/61dP33zaQ3+FkTBYC2T5LgAAIzoQ From: "Hallam-Baker, Phillip" To: "Ted Hardie" , "Pekka Savola" , "Paul Vixie" X-OriginalArrivalTime: 12 Jan 2007 19:29:58.0597 (UTC) FILETIME=[0BDB1750:01C73680] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-Mailman-Approved-At: Sat, 13 Jan 2007 08:34:15 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I still don't understand what the plan is. There is a lot of Internet broadband content distribution going on = today. I do not see where this proposal fits in. Is this the choice of the right tool or 'have hammer, will use it' or = 'have always wanted this particular hammer and looking for excuse to get = one' ? > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com]=20 > Sent: Friday, January 12, 2007 2:23 PM > To: Hallam-Baker, Phillip; Pekka Savola; Paul Vixie > Cc: bmanning@karoshi.com; pars.mutaf@int-evry.fr;=20 > namedroppers@ops.ietf.org; ipv6@ietf.org > Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without=20 > multicast (in IPv6 only)] >=20 > At 10:43 AM -0800 1/12/07, Hallam-Baker, Phillip wrote: > >I am really confused here. > > > >First, I know that multicast has a base in the IETF. Is=20 > there at this point any real prospect of widespread use?=20 > Multicast violates the principle of keeping the core of the=20 > Internet as simple and unchanging as possible. Multicast is=20 > also the amplification mechanism to beat all amplification mechanisms. >=20 > There is ongoing (okay, possibly petering out) discussion on=20 > the NANOG list at the moment on this topic, related to=20 > "internet video" (the NANOG archives are at=20 > http://www.merit.edu/mail.archives/nanog/ . The threads are=20 > "Network end users to pull down 2 gig" and "Internet Video:=20 > The Next Wave of Massive Disruption to the US Peering Ecosystem".) >=20 > One of the points made early on by Sean Donelan is that there=20 > isn't a bright line here where multicast is useful above and=20 > isn't useful below. > To quote one of his points: >=20 > Multicast doesn't have to be real-time. If you collect=20 > interested subscribers over a longer time period, e.g.=20 > scheduled downloads over the next hour, day, week, month, you=20 > can aggregate more multicast receivers through the same=20 > stream. TiVo collects its content using a broadcast schedule. >=20 > I believe you will find the rest of the thread gives an=20 > interesting set of perspectives on how multicast fits in=20 > among other technologies; particularly, it gives you a sense=20 > of how one operational community might use to smooth spikes in usage. >=20 > Ted >=20 >=20 > >A distributed caching model achieves the same effect with=20 > considerably less impact on the core Internet infrastructure.=20 > Instead of doing branching in the network core we do it at=20 > the next level up in the stack. This allows us to build in=20 > security in a coherent way. It also eliminate the probably=20 > bogus assumption that all participants are interacting=20 > synchronously. This is not the case in video-on-demand due to=20 > pause features. > > > >What is it that is being proposed? Is it a feature that is=20 > to assist deployment of multicast or a feature that has some=20 > other advantage that happens to use multicast? > >=20 > > > >I would like to see a concise statement of objectives and=20 > requirements that does not reference a previous post in the thread. > > > > > >> -----Original Message----- > >> From: owner-namedroppers@ops.ietf.org=20 > >> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Pekka Savola > >> Sent: Friday, January 12, 2007 4:37 AM > >> To: Paul Vixie > >> Cc: bmanning@karoshi.com; pars.mutaf@int-evry.fr;=20 > >> namedroppers@ops.ietf.org; ipv6@ietf.org > >> Subject: DNS opcode DISCOVER [Re: multicast DNS without=20 > multicast (in=20 > >> IPv6 only)] > >> > >> [DNS opcode DISCOVER] > >> > >> On Thu, 11 Jan 2007, Paul Vixie wrote: > >> > yes, it has. > >> > > >> >> why, under $DIETIES green earth would you want to push a dead > >> >> technology? The IESG is dead-set against this. > >> > > >> > because the IESG has turned over N times during those 8 > >> years, and the > >> > idea is still solid and useful and interesting, and the current=20 > >> > proposed RFC is experimental, and most importantly, because > >> the need > >> > for it will continue to resurface until we push it over the > >> top of the > >> > hill and roll it down to the town. > >> > >> The problem was, AFAIR, that allocating opcodes requires a=20 > Standards=20 > >> Action. No experimental spec can do that. If DISCOVER is to be=20 > >> revived it will need to use one of other publication processes. > >> > >> -- > >> Pekka Savola "You each name yourselves=20 > king, yet the > >> Netcore Oy kingdom bleeds." > >> Systems. Networks. Security. -- George R.R. Martin: A=20 > Clash of Kings > >> > >> -- > >> to unsubscribe send a message to > >> namedroppers-request@ops.ietf.org with the word 'unsubscribe' > >> in a single line as the message text body. > >> archive: > >> > > > >-- > >to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with=20 > >the word 'unsubscribe' in a single line as the message text body. > >archive: >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 08:35:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5j1U-0007s4-US; Sat, 13 Jan 2007 08:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Rrs-0003IU-Gu for ipv6@ietf.org; Fri, 12 Jan 2007 14:15:12 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RMz-0007tm-IU for ipv6@ietf.org; Fri, 12 Jan 2007 13:43:18 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l0CIhGS5020725; Fri, 12 Jan 2007 10:43:16 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 10:43:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jan 2007 10:43:08 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD370105A33D@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] Thread-Index: Acc2LliEEq7VqgSGSS2EnJTBNFiT3wAShMnw From: "Hallam-Baker, Phillip" To: "Pekka Savola" , "Paul Vixie" X-OriginalArrivalTime: 12 Jan 2007 18:43:16.0025 (UTC) FILETIME=[85648A90:01C73679] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-Mailman-Approved-At: Sat, 13 Jan 2007 08:34:15 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I am really confused here. First, I know that multicast has a base in the IETF. Is there at this = point any real prospect of widespread use? Multicast violates the = principle of keeping the core of the Internet as simple and unchanging = as possible. Multicast is also the amplification mechanism to beat all = amplification mechanisms.=20 A distributed caching model achieves the same effect with considerably = less impact on the core Internet infrastructure. Instead of doing = branching in the network core we do it at the next level up in the = stack. This allows us to build in security in a coherent way. It also = eliminate the probably bogus assumption that all participants are = interacting synchronously. This is not the case in video-on-demand due = to pause features. What is it that is being proposed? Is it a feature that is to assist = deployment of multicast or a feature that has some other advantage that = happens to use multicast? =20 I would like to see a concise statement of objectives and requirements = that does not reference a previous post in the thread. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org=20 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Friday, January 12, 2007 4:37 AM > To: Paul Vixie > Cc: bmanning@karoshi.com; pars.mutaf@int-evry.fr;=20 > namedroppers@ops.ietf.org; ipv6@ietf.org > Subject: DNS opcode DISCOVER [Re: multicast DNS without=20 > multicast (in IPv6 only)] >=20 > [DNS opcode DISCOVER] >=20 > On Thu, 11 Jan 2007, Paul Vixie wrote: > > yes, it has. > > > >> why, under $DIETIES green earth would you want to push a dead > >> technology? The IESG is dead-set against this. > > > > because the IESG has turned over N times during those 8=20 > years, and the=20 > > idea is still solid and useful and interesting, and the current=20 > > proposed RFC is experimental, and most importantly, because=20 > the need=20 > > for it will continue to resurface until we push it over the=20 > top of the=20 > > hill and roll it down to the town. >=20 > The problem was, AFAIR, that allocating opcodes requires a=20 > Standards Action. No experimental spec can do that. If=20 > DISCOVER is to be revived it will need to use one of other=20 > publication processes. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > -- > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with the word 'unsubscribe'=20 > in a single line as the message text body. > archive: >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 08:35:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5j1V-0007t1-SY; Sat, 13 Jan 2007 08:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RzM-0005e4-Ar for ipv6@ietf.org; Fri, 12 Jan 2007 14:22:56 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RzJ-0002AB-S4 for ipv6@ietf.org; Fri, 12 Jan 2007 14:22:56 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0CJMpG8010746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Jan 2007 11:22:52 -0800 Received: from [129.46.225.123] (carbuncle.qualcomm.com [129.46.225.123]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0CJMdsA012210; Fri, 12 Jan 2007 11:22:40 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD370105A33D@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD370105A33D@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Fri, 12 Jan 2007 11:22:38 -0800 To: "Hallam-Baker, Phillip" , "Pekka Savola" , "Paul Vixie" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Sat, 13 Jan 2007 08:34:15 -0500 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At 10:43 AM -0800 1/12/07, Hallam-Baker, Phillip wrote: >I am really confused here. > >First, I know that multicast has a base in the IETF. Is there at this point any real prospect of widespread use? Multicast violates the principle of keeping the core of the Internet as simple and unchanging as possible. Multicast is also the amplification mechanism to beat all amplification mechanisms. There is ongoing (okay, possibly petering out) discussion on the NANOG list at the moment on this topic, related to "internet video" (the NANOG archives are at http://www.merit.edu/mail.archives/nanog/ . The threads are "Network end users to pull down 2 gig" and "Internet Video: The Next Wave of Massive Disruption to the US Peering Ecosystem".) One of the points made early on by Sean Donelan is that there isn't a bright line here where multicast is useful above and isn't useful below. To quote one of his points: Multicast doesn't have to be real-time. If you collect interested subscribers over a longer time period, e.g. scheduled downloads over the next hour, day, week, month, you can aggregate more multicast receivers through the same stream. TiVo collects its content using a broadcast schedule. I believe you will find the rest of the thread gives an interesting set of perspectives on how multicast fits in among other technologies; particularly, it gives you a sense of how one operational community might use to smooth spikes in usage. Ted >A distributed caching model achieves the same effect with considerably less impact on the core Internet infrastructure. Instead of doing branching in the network core we do it at the next level up in the stack. This allows us to build in security in a coherent way. It also eliminate the probably bogus assumption that all participants are interacting synchronously. This is not the case in video-on-demand due to pause features. > >What is it that is being proposed? Is it a feature that is to assist deployment of multicast or a feature that has some other advantage that happens to use multicast? > > >I would like to see a concise statement of objectives and requirements that does not reference a previous post in the thread. > > >> -----Original Message----- >> From: owner-namedroppers@ops.ietf.org >> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Pekka Savola >> Sent: Friday, January 12, 2007 4:37 AM >> To: Paul Vixie >> Cc: bmanning@karoshi.com; pars.mutaf@int-evry.fr; >> namedroppers@ops.ietf.org; ipv6@ietf.org >> Subject: DNS opcode DISCOVER [Re: multicast DNS without >> multicast (in IPv6 only)] >> >> [DNS opcode DISCOVER] >> >> On Thu, 11 Jan 2007, Paul Vixie wrote: >> > yes, it has. >> > >> >> why, under $DIETIES green earth would you want to push a dead >> >> technology? The IESG is dead-set against this. >> > >> > because the IESG has turned over N times during those 8 >> years, and the >> > idea is still solid and useful and interesting, and the current >> > proposed RFC is experimental, and most importantly, because >> the need >> > for it will continue to resurface until we push it over the >> top of the >> > hill and roll it down to the town. >> >> The problem was, AFAIR, that allocating opcodes requires a >> Standards Action. No experimental spec can do that. If >> DISCOVER is to be revived it will need to use one of other >> publication processes. >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> -- >> to unsubscribe send a message to >> namedroppers-request@ops.ietf.org with the word 'unsubscribe' >> in a single line as the message text body. >> archive: >> > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 08:54:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5jKQ-0003Sb-CP; Sat, 13 Jan 2007 08:53:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5jKO-0003Qv-Vd for ipv6@ietf.org; Sat, 13 Jan 2007 08:53:48 -0500 Received: from purgatory.unfix.org ([213.136.24.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5jKN-0006Et-2F for ipv6@ietf.org; Sat, 13 Jan 2007 08:53:48 -0500 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 3AB19140C1CB; Sat, 13 Jan 2007 14:53:42 +0100 (CET) X-Virus-Scanned: purgatory.unfix.org - http://unfix.org Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory.unfix.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x9ePAf0LKUO; Sat, 13 Jan 2007 14:53:38 +0100 (CET) Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 47561140C136; Sat, 13 Jan 2007 14:53:35 +0100 (CET) Message-ID: <45A8E467.50408@spaghetti.zurich.ibm.com> Date: Sat, 13 Jan 2007 13:53:43 +0000 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <198A730C2044DE4A96749D13E167AD370105A34B@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD370105A34B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.94.1.2 OpenPGP: id=333E7C23 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: bmanning@karoshi.com, Pekka Savola , Ted Hardie , namedroppers@ops.ietf.org, ipv6@ietf.org, Paul Vixie Subject: Re: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1566085277==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1566085277== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44AD8A17B11586C8EDAF0793" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44AD8A17B11586C8EDAF0793 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hallam-Baker, Phillip wrote: > I still don't understand what the plan is. >=20 > There is a lot of Internet broadband content distribution > going on today. I do not see where this proposal fits in. "Content Distribution" in the form of Akamai and other such solutions are GREAT for Big Companies(tm). But Big Companies(tm) are not the only users of the Internet! Multicast allows EVERY user of the Internet to very easily use a small amount of bandwidth to send one single copy into the Internet and have tens of thousands of other users enjoy it. You could argue "just upload your video's up to youtube". Some users don't want their works to be owned by third parties, some people want to provide it in different formats. The Internet is about freedom, freedom in what you do and how you do it. Having multicast available to end users gives extra freedom to the users of the Internet. Multicast will allow that for anything without having to play around in the application stack and having to make application/protocol specific caches for every sort of application. Of course we could just do everything over HTTP, but hey where is the fun in that? Also, what is the largest cost for ISP's anyway associated by those traffic hogs like P2P? They are transmitting the same kind of data over and over over their transit links. Multicast would solve that as the data is only sent ones and fanned out to the end users that want it. Read: your data goes over the transit once, and only once: that actually saves money... and that is where one of the catches lies, do transit providers want ISP's to save money!? :) For warez-content distribution it seems that NNTP is nowadays the clear winner anyway, with companies solely dedicated to providing access to the TeraBytes of "NNTP Caches" that they have set up. The big problem with multicast of course is the configuration of it and the trust one has to have in its peers, as it can create a lot of havoc when something goes bad, see for nice cruel bedtime horror stories the various mbone,m6bone etc lists ;) Greets, Jeroen -- Additional lesson on how to send bypass greylists, especially: telnet sa.dom.com 25 EHLO purgatory.unfix.org 250-sa.dom.com 250-PIPELINING 250-SIZE 102400000 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: 250 2.1.0 Ok RCPT TO: 450 4.7.1 : Recipient address rejected: Greylisted for 1 minutes And then send your mail ;) --------------enig44AD8A17B11586C8EDAF0793 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkWo5GcuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I9wqAJ4qqg+kH5A2Li5F6l29DAQ2n7DB ZwCfVUBPwQRviFPE6S5pUGwE1SnClyc= =ZCeZ -----END PGP SIGNATURE----- --------------enig44AD8A17B11586C8EDAF0793-- --===============1566085277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1566085277==-- From ipv6-bounces@ietf.org Sat Jan 13 14:36:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ods-0003ys-BH; Sat, 13 Jan 2007 14:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5odq-0003vP-KA for ipv6@ietf.org; Sat, 13 Jan 2007 14:34:14 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5odo-00037C-B2 for ipv6@ietf.org; Sat, 13 Jan 2007 14:34:14 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 13 Jan 2007 11:34:11 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.24; Sat, 13 Jan 2007 11:34:11 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Sat, 13 Jan 2007 11:34:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Cen/ E11E GDk1 GdWz O8Fp Wgdr X25r acjq b9N/ f/k4 g6mL jLFO kty1 nmDj uSTq wytg; 4; YgBtAGEAbgBuAGkAbgBnAEAAawBhAHIAbwBzAGgAaQAuAGMAbwBtADsAYgBvAHIAdAB6AG0AZQB5AGUAcgBAAG4AaQBjAC4AZgByADsAaQBwAHYANgBAAGkAZQB0AGYALgBvAHIAZwA7AG4AYQBtAGUAZAByAG8AcABwAGUAcgBzAEAAbwBwAHMALgBpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {3F7BDF7D-D6AF-42F7-A24B-9A9FF0B7E1DB}; aAB1AGkAdABlAG0AYQBAAHcAaQBuAGQAbwB3AHMALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Sat, 13 Jan 2007 19:32:53 GMT; UgBFADoAIABtAHUAbAB0AGkAYwBhAHMAdAAgAEQATgBTACAAdwBpAHQAaABvAHUAdAAgAG0AdQBsAHQAaQBjAGEAcwB0ACAAKABpAG4AIABJAFAAdgA2ACAAbwBuAGwAeQApAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {3F7BDF7D-D6AF-42F7-A24B-9A9FF0B7E1DB} Content-Class: urn:content-classes:message Date: Sat, 13 Jan 2007 11:32:53 -0800 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064033D1950@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <20070113130541.GA16232@vacation.karoshi.com.> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: multicast DNS without multicast (in IPv6 only) thread-index: Acc3FFTPiEbiJzwRQPSyonYCirw6QwANBp/A References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr><98793.1168451932@sa.vix.com><1168525826.11364.32.camel@lor-maknavic3.int-evry.fr><20070111145544.GA15771@nic.fr><1168533686.11364.60.camel@lor-maknavic3.int-evry.fr><20070112082821.GA22673@nic.fr> <20070113130541.GA16232@vacation.karoshi.com.> From: Christian Huitema To: , Stephane Bortzmeyer X-OriginalArrivalTime: 13 Jan 2007 19:34:11.0260 (UTC) FILETIME=[CCDE27C0:01C73749] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: RE: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > I really do not understand you. Try in French :-) Because, obviously, > > if it is unicast, it is not multicast :-) >=20 > unicast is a degenerative case of multicast. Bill, this is emphatically not true for high speed wireless links, such as the upcoming IEEE 802.11n standard.=20 In high speed wireless networks, the physical layer gets tuned between sender and receiver, resulting in huge gains in transmission quality. You can only apply a fraction of these tunings to multicast traffic.=20 There are also some nasty interactions between multicast and power saving. To save power, the stations sleep most of the time, wake up occasionally, and poll the server for any queued data. For multicast, you have to either guarantee that all stations wake up at the same time, which is hard, or accept to effectively replicate the multicast packet for each station. Transmission tuning and power saving are both very desirable. The natural consequence is to try avoid multicast operation whenever possible. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 14:51:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5otp-000602-8m; Sat, 13 Jan 2007 14:50:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5otn-0005zs-KM for ipv6@ietf.org; Sat, 13 Jan 2007 14:50:43 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5otl-00058J-MB for ipv6@ietf.org; Sat, 13 Jan 2007 14:50:43 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l0DJnOkM018527; Sat, 13 Jan 2007 19:49:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l0DJnO9h018526; Sat, 13 Jan 2007 19:49:24 GMT Date: Sat, 13 Jan 2007 19:49:24 +0000 From: bmanning@karoshi.com To: Christian Huitema Message-ID: <20070113194924.GA18476@vacation.karoshi.com.> References: <20070113130541.GA16232@vacation.karoshi.com.> <70C6EFCDFC8AAD418EF7063CD132D064033D1950@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064033D1950@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Stephane Bortzmeyer , ipv6@ietf.org, bmanning@karoshi.com, namedroppers@ops.ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Sat, Jan 13, 2007 at 11:32:53AM -0800, Christian Huitema wrote: > > > I really do not understand you. Try in French :-) Because, > obviously, > > > if it is unicast, it is not multicast :-) > > > > unicast is a degenerative case of multicast. > > Bill, this is emphatically not true for high speed wireless links, such > as the upcoming IEEE 802.11n standard. > > In high speed wireless networks, the physical layer gets tuned between > sender and receiver, resulting in huge gains in transmission quality. > You can only apply a fraction of these tunings to multicast traffic. re wireless... unless you have tightly coupled directional antennas, high speed wireless (one presumes that "high speed" in this context is the 802.11n draft standard) there is a "footprint" of signal propogation that -any- receiver within that "footprint" may receive. > There are also some nasty interactions between multicast and power > saving. To save power, the stations sleep most of the time, wake up > occasionally, and poll the server for any queued data. For multicast, > you have to either guarantee that all stations wake up at the same time, > which is hard, or accept to effectively replicate the multicast packet > for each station. for multicast, you can assume that all intended receivers are "awake" for your application design, but that is not (to my understanding) an intrinsic component of multicast. > Transmission tuning and power saving are both very desirable. The > natural consequence is to try avoid multicast operation whenever > possible. The first i agree with, the second depends on design goals. --bill > > -- Christian Huitema > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 13 19:03:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5snF-0006I5-1z; Sat, 13 Jan 2007 19:00:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5snD-0006Hw-R8 for ipv6@ietf.org; Sat, 13 Jan 2007 19:00:11 -0500 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5snB-0002dQ-QQ for ipv6@ietf.org; Sat, 13 Jan 2007 19:00:10 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 29E5F28426 for ; Sun, 14 Jan 2007 00:00:03 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 14 Jan 2007 00:00:03 +0000 Message-Id: <20070114000003.29E5F28426@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.28% | 7 | 15.06% | 37183 | pars.mutaf@int-evry.fr 13.95% | 6 | 16.23% | 40077 | bmanning@karoshi.com 9.30% | 4 | 9.56% | 23606 | james.d.carlson@sun.com 9.30% | 4 | 7.09% | 17497 | paul@vix.com 6.98% | 3 | 9.23% | 22774 | alexandru.petrescu@motorola.com 6.98% | 3 | 5.61% | 13860 | bortzmeyer@nic.fr 6.98% | 3 | 5.51% | 13614 | mohta@necom830.hpcl.titech.ac.jp 4.65% | 2 | 6.22% | 15357 | pbaker@verisign.com 2.33% | 1 | 3.26% | 8042 | jeroen@unfix.org 2.33% | 1 | 3.11% | 7668 | hardie@qualcomm.com 2.33% | 1 | 2.72% | 6719 | internet-drafts@ietf.org 2.33% | 1 | 2.59% | 6390 | william.allen.simpson@gmail.com 2.33% | 1 | 2.53% | 6254 | julien.ietf@laposte.net 2.33% | 1 | 2.46% | 6069 | huitema@windows.microsoft.com 2.33% | 1 | 1.88% | 4637 | narten@us.ibm.com 2.33% | 1 | 1.81% | 4473 | brc@zurich.ibm.com 2.33% | 1 | 1.80% | 4451 | pekkas@netcore.fi 2.33% | 1 | 1.66% | 4098 | sra+ipng@hactrn.net 2.33% | 1 | 1.66% | 4090 | rdenis@simphalempin.com --------+------+--------+----------+------------------------ 100.00% | 43 |100.00% | 246859 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 02:10:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5zST-00052H-Uv; Sun, 14 Jan 2007 02:07:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5zSR-000529-DI for ipv6@ietf.org; Sun, 14 Jan 2007 02:07:11 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5zSP-0000zF-QL for ipv6@ietf.org; Sun, 14 Jan 2007 02:07:11 -0500 Received: (qmail 89130 invoked from network); 14 Jan 2007 07:26:37 -0000 Received: from softbank219001188039.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.39) by necom830.hpcl.titech.ac.jp with SMTP; 14 Jan 2007 07:26:37 -0000 Message-ID: <45A9D691.4060506@necom830.hpcl.titech.ac.jp> Date: Sun, 14 Jan 2007 16:06:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: bmanning@karoshi.com References: <20070113130541.GA16232@vacation.karoshi.com.> <70C6EFCDFC8AAD418EF7063CD132D064033D1950@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <20070113194924.GA18476@vacation.karoshi.com.> In-Reply-To: <20070113194924.GA18476@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Christian Huitema , namedroppers@ops.ietf.org, Stephane Bortzmeyer , ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org bmanning@karoshi.com wrote: >>There are also some nasty interactions between multicast and power >>saving. To save power, the stations sleep most of the time, wake up >>occasionally, and poll the server for any queued data. For multicast, >>you have to either guarantee that all stations wake up at the same time, >>which is hard, or accept to effectively replicate the multicast packet >>for each station. > for multicast, you can assume that all intended receivers are > "awake" for your application design, but that is not (to my understanding) > an intrinsic component of multicast. It is merely that each station is required to wake up when packets to the station are transmitted, regardless of whether the packets are unicast, multicast or broadcast. Thus, the amount of power consumption of a station increases proportional to the number of multicast addresses the station joins. It's not a problem if the station is running streaming applications, which, anyway, consume considerable amount of power. However, frequently multicast RAs to all-nodes multicast address are really annoying. Masataka Ohta PS A real difference between unicast and multicast/broadcast of CSMA/CA wireless link such as 802.11 is that the latter can not be ACKed and is unreliable. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 06:05:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H637Z-0001lZ-85; Sun, 14 Jan 2007 06:01:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H637X-0001lT-0b for ipv6@ietf.org; Sun, 14 Jan 2007 06:01:51 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H637V-0003gB-El for ipv6@ietf.org; Sun, 14 Jan 2007 06:01:50 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DA11989845; Sun, 14 Jan 2007 13:01:45 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8FD8289844; Sun, 14 Jan 2007 13:01:45 +0200 (EET) Message-ID: <45AA0D9D.4080705@piuha.net> Date: Sun, 14 Jan 2007 13:01:49 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: pars.mutaf@int-evry.fr References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pars, Various possible DNS designs are possible. However, I want to go back to your suggestion that multicasting will cause significant inefficiencies when running over WiMax and 802.16. It might, indeed -- Christian's note about the high speed wireless designs was right on. But the question is whether it will actually be the case for WiMax as it is being defined and used. As you may know, there has been active work in the 16ng working group during the summer and autumn, and that has resulted in a number of changes to the way that people originally planned to run this. In particular, the WG has considered issues relating to waking up dormant hosts. My understanding is that their current designs do NOT have that problem. For instance, they plan to recommend a point to point like link model where the host's ND or other link local multicast traffic does not impact other hosts. And there is a plan on employing RFC 4541 (MLD snooping) where 802.16 is run as an Ethernet. As a result, it seems fairly effective in ensuring that multicast does not wake up unnecessary neighbors. It does not solve all problems -- if you were to run LLMNR over it you would still be sending to every node, because only one multicast address is used. But then again, I'm not sure how big practical problem this is. I hope the providers are not setting up their 802.16 networks so that people can find printer.local in the Tokyo subnet... Anyway, if we think of the hash approach independently of your 802.16 use case, I think there are still several significant problems. As others have mentioned, you still need something that allows ND to work, and it, in turn is based on multicast at IP level. Perhaps more fundamentally, I think a local unmanaged naming system should be able to live with collisions. As your scheme combines the name space to the IP space this becomes very difficult. For starters, to allow multiple similar names, you would have to disable DAD and change ND, and I suspect it would not work with current TCP and applications. Also, there are operational issues such as inability to search except for exact match. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 08:21:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H65F9-0006TA-FU; Sun, 14 Jan 2007 08:17:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H65F8-0006Rz-8K for ipv6@ietf.org; Sun, 14 Jan 2007 08:17:50 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H65F6-0000wy-IY for ipv6@ietf.org; Sun, 14 Jan 2007 08:17:50 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l0EDGbkM031107; Sun, 14 Jan 2007 13:16:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l0EDGVJS031105; Sun, 14 Jan 2007 13:16:31 GMT Date: Sun, 14 Jan 2007 13:16:31 +0000 From: bmanning@karoshi.com To: Jari Arkko Message-ID: <20070114131631.GA31034@vacation.karoshi.com.> References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <45AA0D9D.4080705@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AA0D9D.4080705@piuha.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > As a result, it seems fairly effective in ensuring > that multicast does not wake up unnecessary > neighbors. It does not solve all problems -- if > you were to run LLMNR over it you would still > be sending to every node, because only one > multicast address is used. But then again, > I'm not sure how big practical problem this > is. I hope the providers are not setting up > their 802.16 networks so that people can > find printer.local in the Tokyo subnet... and this would be bad in what way? :) > Anyway, if we think of the hash approach independently > of your 802.16 use case, I think there are still several > significant problems. As others have mentioned, you > still need something that allows ND to work, and it, > in turn is based on multicast at IP level. Perhaps > more fundamentally, I think a local unmanaged naming > system should be able to live with collisions. As your > scheme combines the name space to the IP space > this becomes very difficult. For starters, to allow > multiple similar names, you would have to disable > DAD and change ND, and I suspect it would not work > with current TCP and applications. Also, there > are operational issues such as inability to search > except for exact match. DISCOVER works with namespace collisions. fuzzy matching -after- the collision is detected requires more than just the FQDN and address. When we did the original work on this (a decade ago) in the TBDS project, we used a local crypto key as a third discriminator. Neither DISCOVER or TBDS is v6-specific. > > Jari > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 11:54:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68Zj-00039v-Iq; Sun, 14 Jan 2007 11:51:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68Zi-00039b-12 for ipv6@ietf.org; Sun, 14 Jan 2007 11:51:18 -0500 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H68Zc-0000DX-PW for ipv6@ietf.org; Sun, 14 Jan 2007 11:51:18 -0500 Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp [2001:200:1b1::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2308A1525D; Mon, 15 Jan 2007 01:51:04 +0900 (JST) Date: Mon, 15 Jan 2007 01:51:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, v6ops@ops.ietf.org, users@ipv6.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: CFP: "IPv6 and the Future of the Internet" workshop @ SIGCOMM 2007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org (excuse me cross posting - hopefully it's not so noisy) Dear all, On behalf of the program committee, I'd like to make an announcement of a CFP for a forthcoming SIGCOMM workshop on IPv6. Details are available at http://www.sigcomm.org/sigcomm-conference-current/ipv6/ (major contents of the web page are also pasted below). Although you might think SIGCOMM is too "academic" for such practical forums as IETF, we are actually seeking practical insights as well as theoretical analyses in this workshop as described in the CFP. So, please consider submitting a paper on your recent research/engineering results related to IPv6. Also, it would be very nice if you can distribute the CFP to whatever venues that you think are suitable for this workshop. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 1. Motivation and rationale for the workshop This one-day workshop aims to bring together researchers and practitioners from academia and industry to engage in an in-depth discussion on various research and deployment issues of IPv6 and their impact on the future of the Internet. In recent years the global deployment of IPv6 started taking off, especially in the Asian-Pacific area. To date IPv6 development efforts have mainly focused on protocol standardization, product development, and network operations, rather than as a research target. However, we believe that the accumulated experiences in these practices now provide interesting research opportunities, not only for those who have been involved in IPv6 development but also for the broader network research community. We expect the workshop to open a dialog between networking researchers and practitioners, and foster synergistic activities thereafter. 2. Call for Paper (CFP) ACM SIGCOMM IPv6 and the Future of the Internet (IPv6+) Workshop seeks papers describing significant research contributions to the field of IPv6 and their relevance on the future of the Internet. IPv6 was primarily motivated by the address shortage problem of IPv4. It provides a much larger address space than IPv4. However, the competing technology Network Address Translation (NAT) has alleviated the address shortage problem to some extent, and other problems, such as routing scalability, management, mobility, and security, have become increasingly prominent. At the mean time, the global deployment of IPv6 has gradually taken off. Modern operating systems are shipped with both IPv4 and IPv6 stacks, and IPv6-compatible backbones came into existence. As it is costly to migrate from one network architecture to another one, can we take this opportunity to address additional problems in the IPv4 Internet by extending the IPv6 protocol suite? What new problems are/were encountered in the process of deploying IPv6? And what lessons have we learned? We invite submissions that shed light on the above questions. Submissions in both academic and operational flavors are welcome. Topics of interest include, but are not limited to: * Experiences and lessons learned from pilot deployments of IPv6 networks and applications * Experimental and measurement results from operational IPv6 networks * Advantages and challenges the very large IPv6 address space bring to the Internet routing system * Scalable and robust solutions to multi-homing and traffic engineering * Host and Network Mobility * Multicast and Anycast protocols * Worms, DoS, and other security threats in IPv6 networks and possible enhancements to address these challenges. * IPv6's Applicability to sensor networks, low-power personal area networks, and other types of challenged networks * Impact on application development and deployment * A critical assessment of IPv6's viability as a global communication infrastructure for the future or of its fundamental limitations, if any. 3. Submission guideline Submissions must be no greater than 6 pages in length, must be a pdf file, and must follow the formatting guidelines at http://www.sigcomm.org/sigcomm2007/workshop-psg.html. Submissions that deviate from these guidelines will be rejected without consideration. Reviews will be single-blind: authors name and affiliation should be included in the submission. Authors of accepted papers are expected to present their papers at the workshop. Submissions must be original work not under review at any other workshop, conference, or journal. 4. Workshop dates Paper submission due: April 6, 2007 Paper acceptance notification: May 11, 2007 Camera-ready due: June 8, 2007 Workshop: Aug 31, 2007 5. Program committee Program Co-chairs: Xiaowei Yang UC Irvine, US Tatuya Jinmei Toshiba, Japan Program Committee members: Maoke Chen Tsinghua, China Kilnam Chon KAIST, Korea Rich Draves Microsoft, US Paul Francis Cornell, US Tony Hain Cisco, US Masaki Hirabaru NICT, Japan Xing Li Tsinghua, China Yoshifumi Nishida Sony CSL, Japan Pekka Savola CSC/FUNET, Finland Dave Thaler Microsoft, US Beichuan Zhang University of Arizona, US Lixia Zhang UCLA, US -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 13:54:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ASS-00041L-25; Sun, 14 Jan 2007 13:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ASR-00041G-Ca for ipv6@ietf.org; Sun, 14 Jan 2007 13:51:55 -0500 Received: from massilia.int-evry.fr ([157.159.10.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ASP-0003sT-UK for ipv6@ietf.org; Sun, 14 Jan 2007 13:51:55 -0500 Received: from massilia.int-evry.fr (localhost.localdomain [127.0.0.1]) by massilia.int-evry.fr (8.12.11/8.12.11) with ESMTP id l0EIpgSD006060; Sun, 14 Jan 2007 19:51:42 +0100 Received: (from apache@localhost) by massilia.int-evry.fr (8.12.11/8.12.11/Submit) id l0EIpf2U006059; Sun, 14 Jan 2007 19:51:41 +0100 X-Authentication-Warning: massilia.int-evry.fr: apache set sender to Pars.Mutaf@int-evry.fr using -f Received: from www.passagesaintsebastien.com (www.passagesaintsebastien.com [81.57.101.151]) by imp.int-evry.fr (IMP) with HTTP for ; Sun, 14 Jan 2007 19:51:41 +0100 Message-ID: <1168800701.45aa7bbdc4fdb@imp.int-evry.fr> Date: Sun, 14 Jan 2007 19:51:41 +0100 From: Pars MUTAF To: Jari Arkko References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <45AA0D9D.4080705@piuha.net> In-Reply-To: <45AA0D9D.4080705@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 81.57.101.151 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Selon Jari Arkko : > Pars, > > Various possible DNS designs are possible. However, > I want to go back to your suggestion that multicasting > will cause significant inefficiencies when running over > WiMax and 802.16. > Thank you very much for this mail. Please see below: > It might, indeed -- Christian's note about the high > speed wireless designs was right on. But the question > is whether it will actually be the case for WiMax as > it is being defined and used. As you may know, there has > been active work in the 16ng working group during the > summer and autumn, and that has resulted in a > number of changes to the way that people originally > planned to run this. In particular, the WG has > considered issues relating to waking up dormant > hosts. My understanding is that their current > designs do NOT have that problem. For instance, > they plan to recommend a point to point like link > model where the host's ND or other link local > multicast traffic does not impact other hosts. > And there is a plan on employing RFC 4541 (MLD > snooping) where 802.16 is run as an Ethernet. > As a result, it seems fairly effective in ensuring > that multicast does not wake up unnecessary > neighbors. Great news. This means that ND and DAD will work without waking up all dormant hosts. If I understand correctly. > It does not solve all problems -- if > you were to run LLMNR over it you would still > be sending to every node, because only one > multicast address is used. But then again, > I'm not sure how big practical problem this > is. I hope the providers are not setting up > their 802.16 networks so that people can > find printer.local in the Tokyo subnet... I'm not sure why LLMNR uses only one multicast address. I see serious problems with that. A LLMNR query would wake up every dormant host, in this case. Why this may be a serious problem? Firstly, the multicast name resolution idea that started with ZEROCONF (if I'm correct), has the potential to find many new and popular applications. This means that many users may use it in the future, especially in wireless broadband networks. However, this also means that it may create a lot of multicast queries that wake up every host and consume a lot of energy. >From this point of view, I suspect that LLMNR's potentials are underestimated by its own design. (I mean: if a LLMNR query must be forwarded to every node) Secondly, nothing prevents a user from trying different names again and again. Each query would wake up many dormant hosts. Can we call this a DoS attack? I'm not even sure. He/she is doing that for fun perhaps. But the consequences would be bad if a LLMNR query must be forwarded to all (probably dormant) devices. > > Anyway, if we think of the hash approach independently > of your 802.16 use case, I think there are still several > significant problems. As others have mentioned, you > still need something that allows ND to work, and it, > in turn is based on multicast at IP level. Perhaps > more fundamentally, I think a local unmanaged naming > system should be able to live with collisions. As your > scheme combines the name space to the IP space > this becomes very difficult. For starters, to allow > multiple similar names, you would have to disable > DAD and change ND, and I suspect it would not work > with current TCP and applications. Also, there > are operational issues such as inability to search > except for exact match. Pushing my own scheme is not my intent in this discussion. (I wanted feedback, and I had a lot and I thank you all) However, the good news that you have announced in your mail are also good news for my proposal. My proposal *needs* ND for address resolution, and DAD for address (i.e. name) collision detection. If these protocols will run without waking up every dormant host, then this is also great for me. I will think more about your other comments (I'm not sure to understand). Thanks! pars ps: I'm not sure if folks realize the costs of waking up every dormant host at the same time. It is not only an energy consumption problem. It is also a signaling problem. The most efficient dormant is achieved using a mechanism called "paging". This is a generic protocol. To wake up a dormant host, you have to search it in many cells. This is for one host. You can probably imagine what would happen if you try to page every dormant host. > > Jari > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 15:35:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6C28-0004e4-Lx; Sun, 14 Jan 2007 15:32:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6C27-0004dy-IC for ipv6@ietf.org; Sun, 14 Jan 2007 15:32:51 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6C25-0004mb-8a for ipv6@ietf.org; Sun, 14 Jan 2007 15:32:51 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sun, 14 Jan 2007 12:32:45 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.24; Sun, 14 Jan 2007 12:32:44 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Sun, 14 Jan 2007 12:32:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ns4= EWZ0 I/zX KJhL NI5Y Ps4t XrgJ dbpI d47h ePPt eqqX geKV jlUa kUDM mEM9 n9tq; 4; aQBwAHYANgBAAGkAZQB0AGYALgBvAHIAZwA7AGoAYQByAGkALgBhAHIAawBrAG8AQABwAGkAdQBoAGEALgBuAGUAdAA7AG4AYQBtAGUAZAByAG8AcABwAGUAcgBzAEAAbwBwAHMALgBpAGUAdABmAC4AbwByAGcAOwBwAGEAcgBzAC4AbQB1AHQAYQBmAEAAaQBuAHQALQBlAHYAcgB5AC4AZgByAA==; Sosha1_v1; 7; {85761150-0A72-4982-9BAF-E4E1AC19D198}; aAB1AGkAdABlAG0AYQBAAHcAaQBuAGQAbwB3AHMALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Sun, 14 Jan 2007 20:32:07 GMT; UgBFADoAIABtAHUAbAB0AGkAYwBhAHMAdAAgAEQATgBTACAAdwBpAHQAaABvAHUAdAAgAG0AdQBsAHQAaQBjAGEAcwB0ACAAKABpAG4AIABJAFAAdgA2ACAAbwBuAGwAeQApAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {85761150-0A72-4982-9BAF-E4E1AC19D198} Content-Class: urn:content-classes:message Date: Sun, 14 Jan 2007 12:32:07 -0800 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064033D19BC@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <1168800701.45aa7bbdc4fdb@imp.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: multicast DNS without multicast (in IPv6 only) thread-index: Acc4DYvLBjhq3f88RgG15GPtnf75LwACzgzw References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr><45AA0D9D.4080705@piuha.net> <1168800701.45aa7bbdc4fdb@imp.int-evry.fr> From: Christian Huitema To: Pars MUTAF , Jari Arkko X-OriginalArrivalTime: 14 Jan 2007 20:32:44.0548 (UTC) FILETIME=[255D1C40:01C7381B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: RE: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I'm not sure why LLMNR uses only one multicast address. > I see serious problems with that. A LLMNR query would > wake up every dormant host, in this case. Why this may > be a serious problem? There was actually a reasonably thorough discussion of this issue during the design of LLMNR. You can find it in the list archive. At one time, there was a design proposal to use multiple multicast groups. The group-id would be derived from the queried name. The proposal was eventually discarded. Part of the reason was implementation complexity. A hash based solution requires to write the name in canonical form before hashing. Canonical functions are hard to get right, especially with international names, and could cause significant interoperability issues.=20 Another reason was the general overhead of multiple multicast groups. Many station interfaces can only handle a limited number of groups, and fall back to promiscuous mode and software filtering after that number. In switched environments, switches have to maintain routing state for the multiple groups. The multiple groups may reduce the overhead of individual queries, but there is a significant management overhead. Given that, it was decided to just keep it simple, and use exactly one group. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 19:01:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6FEj-000105-Rv; Sun, 14 Jan 2007 18:58:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6FEi-0000xk-QT for ipv6@ietf.org; Sun, 14 Jan 2007 18:58:04 -0500 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6FEf-0007gG-5m for ipv6@ietf.org; Sun, 14 Jan 2007 18:58:04 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.8/8.13.8) with ESMTP id l0ENvfil085991; Mon, 15 Jan 2007 10:57:41 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200701142357.l0ENvfil085991@drugs.dv.isc.org> To: Masataka Ohta From: Mark Andrews In-reply-to: Your message of "Sun, 14 Jan 2007 16:06:57 +0900." <45A9D691.4060506@necom830.hpcl.titech.ac.jp> Date: Mon, 15 Jan 2007 10:57:41 +1100 X-Spam-Score: -2.8 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Christian Huitema , namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com, Stephane Bortzmeyer Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > PS > > A real difference between unicast and multicast/broadcast of CSMA/CA > wireless link such as 802.11 is that the latter can not be ACKed and > is unreliable. Multicast is unreliable, period. This is independent of the media being used. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 14 19:27:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6FgY-0006af-IO; Sun, 14 Jan 2007 19:26:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6FgT-0006X3-2I for ipv6@ietf.org; Sun, 14 Jan 2007 19:26:45 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6FY8-0001zV-8L for ipv6@ietf.org; Sun, 14 Jan 2007 19:18:09 -0500 Received: (qmail 14368 invoked from network); 15 Jan 2007 00:37:56 -0000 Received: from softbank219001188028.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.28) by necom830.hpcl.titech.ac.jp with SMTP; 15 Jan 2007 00:37:56 -0000 Message-ID: <45AAC83B.2020601@necom830.hpcl.titech.ac.jp> Date: Mon, 15 Jan 2007 09:18:03 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Mark Andrews References: <200701142357.l0ENvfil085991@drugs.dv.isc.org> In-Reply-To: <200701142357.l0ENvfil085991@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Christian Huitema , namedroppers@ops.ietf.org, ipv6@ietf.org, bmanning@karoshi.com, Stephane Bortzmeyer Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Mark Andrews wrote: >>A real difference between unicast and multicast/broadcast of CSMA/CA >>wireless link such as 802.11 is that the latter can not be ACKed and >>is unreliable. > > > Multicast is unreliable, period. This is independent of the > media being used. If you assume L4 ack and retransmission, you are right. However, even at L4, unidirectional UDP unicast is just as reliable as unidirectional UDP multicast. At L2, Ethernet multicast is as reliable as Ethernet unicast and 802.11 unicast, because there are CD or ACK and retransmissions. OTOH, 802.11 multicast with no CD, ACK nor retransmission is a lot less reliable. Masataka Ohta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 15 11:58:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6V7j-0001cm-5S; Mon, 15 Jan 2007 11:55:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6V7h-0001ca-Na for ipv6@ietf.org; Mon, 15 Jan 2007 11:55:53 -0500 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6V7g-0002CC-S3 for ipv6@ietf.org; Mon, 15 Jan 2007 11:55:53 -0500 Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp [2001:200:1b1::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 676E715267; Tue, 16 Jan 2007 01:55:44 +0900 (JST) Date: Tue, 16 Jan 2007 01:55:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, v6ops@ops.ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: Re: [IPv6 Users] CFP: "IPv6 and the Future of the Internet" workshop @ SIGCOMM 2007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 15 Jan 2007 01:51:00 +0900, >>>>> JINMEI Tatuya said: > (excuse me cross posting - hopefully it's not so noisy) I was reminded that (this type of) conference information was inappropriate for IETF lists according to the general rule described in RFC3005. Of course, I didn't intend to abuse the lists, but clearly I should have checked the policy more carefully before posting it. I'd apologize if any of you felt uncomfortable about the unsolicited message. I won't (ab)use IETF lists about subsequent information (if any) on this matter. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 16 05:05:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6lAN-00030Q-J6; Tue, 16 Jan 2007 05:03:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6lAL-00030K-T5 for ipv6@ietf.org; Tue, 16 Jan 2007 05:03:41 -0500 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6lAK-0001mg-4K for ipv6@ietf.org; Tue, 16 Jan 2007 05:03:41 -0500 Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:7cfb:d79f:f5ea:b4ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A338C1521E; Tue, 16 Jan 2007 18:37:40 +0900 (JST) Date: Tue, 16 Jan 2007 18:37:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: James Carlson In-Reply-To: <17822.22446.547132.229861@gargle.gargle.HOWL> References: <4593CEF5.50308@innovationslab.net> <17822.22446.547132.229861@gargle.gargle.HOWL> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Brian Haberman , ipv6@ietf.org, Pekka Savola Subject: Re: RFC2461(bis): normativeness of protocol constants X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 5 Jan 2007 08:50:38 -0500, >>>>> James Carlson said: >> This is more than strictly required for interoperability. > I think that's the key point. It's very important to make sure that > the things marked as "MUST" or "MUST NOT" are actually requirements > for interoperability or anticipated development, and not just needless > strictures. > Otherwise, it becomes much more tedious to support enviroments that > require slightly different values or implementations that trade off > simplicity against precision. FWIW, I agree. I've not assess whether each of the RFC2461(bis) constants can be a source of an interoperability issue, but if it's not, "MUST" or "MUST NOT" is clearly a wrong choice. Although SHOULD (NOT) might help clarify the intent (and I don't oppose to adding it in this case), I'm not sure if it has a real effect; there's always a vendor that misunderstands or even ignores a particular part of a specification even if it's specified as a MUST. So we won't be able to eliminate such abnormal implementations by giving a spec a SHOULD or MUST. We may be able to convince such a vendor of fixing their implementation with the specific keywords, but I personally don't see significant difference for that purpose in this case, with or without an RFC2119 keyword. In any case, I have no strong opinion on whether to add an RFC2119 keyword to 2461bis (as long as it's not an unnecessary MUST). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 16 12:54:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sUS-0006ze-0K; Tue, 16 Jan 2007 12:52:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6j5V-0004w7-P2 for ipv6@ietf.org; Tue, 16 Jan 2007 02:50:33 -0500 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6j5U-0005XZ-CF for ipv6@ietf.org; Tue, 16 Jan 2007 02:50:33 -0500 Received: from Iseran (p1176-ipbf311niho.hiroshima.ocn.ne.jp [122.23.72.176]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0G7oOTX019049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 08:50:28 +0100 Date: Tue, 16 Jan 2007 08:50:08 +0100 From: Thierry Ernst To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Message-Id: <20070116085008.965e714d.thierry.ernst@inria.fr> In-Reply-To: References: Organization: INRIA X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.10.6; powerpc-apple-darwin8.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Miltered: at discorde with ID 45AC83C0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l0G7oOTX019049 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 16 Jan 2007 12:52:53 -0500 Cc: v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: [IPv6 Users] CFP: "IPv6 and the Future of the Internet" workshop @ SIGCOMM 2007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I've never read RFC 3005, but my take is that in this specific advertisement is very meaningful for both IPv6 and V6ops mailing lists, so I wouldn't see where there would be a problem this time. But on a general basis, I've seen too many postings which were really not appropriate to be sent on to the mailing lists where there were sent to. So, I guess it's a matter of self-restrain. Thierry. On Tue, 16 Jan 2007 01:55:43 +0900 JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>>>> On Mon, 15 Jan 2007 01:51:00 +0900,=20 >>>>>> JINMEI Tatuya said: > >> (excuse me cross posting - hopefully it's not so noisy) > >I was reminded that (this type of) conference information was >inappropriate for IETF lists according to the general rule described >in RFC3005. Of course, I didn't intend to abuse the lists, but >clearly I should have checked the policy more carefully before posting >it. I'd apologize if any of you felt uncomfortable about the >unsolicited message. I won't (ab)use IETF lists about subsequent >information (if any) on this matter. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 18 02:28:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7RcS-0002dZ-Oc; Thu, 18 Jan 2007 02:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7RcR-0002ZY-LS for ipv6@ietf.org; Thu, 18 Jan 2007 02:23:31 -0500 Received: from web31708.mail.mud.yahoo.com ([68.142.201.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7RcP-0000yx-UF for ipv6@ietf.org; Thu, 18 Jan 2007 02:23:31 -0500 Received: (qmail 64280 invoked by uid 60001); 18 Jan 2007 07:23:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=j8vbeefl/BbcId/i1Q5K1EoprhyoAmUYC/gzOXnPeQ7cjcu49f2+ipmEUxy85dYxsXI3mzXzUxgV6BJkb2Z1E8Lqm4fYpGo/oFS/mIxBbLFZhJmQdY3YyDRt1xT4KJcp3VBJj6KlgCdTje7eO+Gg2ecgENDlFrx0zzVrRMH/vl8=; X-YMail-OSG: drU9A8QVM1nFG14SfbShlSTP5Tpf.cso4AYGQ.ElD5VRNOVX1gLxWt0IAZI5YaZrCyQham8AlA85MBpPsy1YWMHdA_u7TafPo9wTzugRdKtM9rStLIXWg1zLADGhR7zNJXvWZqEP.bfRAA-- Received: from [59.163.146.11] by web31708.mail.mud.yahoo.com via HTTP; Wed, 17 Jan 2007 23:23:29 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Wed, 17 Jan 2007 23:23:29 -0800 (PST) From: Ram Kumar To: ipv6@ietf.org MIME-Version: 1.0 Message-ID: <325900.64238.qm@web31708.mail.mud.yahoo.com> X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1164529071==" Errors-To: ipv6-bounces@ietf.org --===============1164529071== Content-Type: multipart/alternative; boundary="0-1045604592-1169105009=:64238" --0-1045604592-1169105009=:64238 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AWith reference to the following link:=0Ahttp://www1.ietf.org/mail-= archive/web/ipv6/current/msg03823.html=0A=0ADoes Lucent or motorola has a D= HCPv6 server? Where can I find information regarding the same.=0APlease do = provide me with a complete list of commercial DHCPv6 servers available..=0A= =0AThanks.=0A=0ARegards,=0ARam Kumar H=0A=0A=0A=0A=0A=0A=09=09=0A__________= ________________________________________________=0AYahoo! India Answers: Sh= are what you know. Learn something new=0Ahttp://in.answers.yahoo.com/ --0-1045604592-1169105009=:64238 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

With reference to the following link:http://www1.ietf.org/mail-archi= ve/web/ipv6/current/msg03823.html

Does Lucent or motorola= has a DHCPv6 server? Where can I find information regarding the same.
P= lease do provide me with a complete list of commercial DHCPv6 servers avail= able..

Thanks.

Regards,
Ram Kumar H


=0A=09=0A=0A=09=0A=09=09
=0AHere=92s a new way to= find what you're looking for - Yahoo! Answers --0-1045604592-1169105009=:64238-- --===============1164529071== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1164529071==-- From ipv6-bounces@ietf.org Thu Jan 18 08:02:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Wso-00081W-48; Thu, 18 Jan 2007 08:00:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Wsm-00081I-UN for ipv6@ietf.org; Thu, 18 Jan 2007 08:00:44 -0500 Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Wsl-0007XM-GX for ipv6@ietf.org; Thu, 18 Jan 2007 08:00:44 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-3.tower-125.messagelabs.com!1169125241!15576740!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 5571 invoked from network); 18 Jan 2007 13:00:41 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-3.tower-125.messagelabs.com with SMTP; 18 Jan 2007 13:00:41 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l0ID0fNt007593; Thu, 18 Jan 2007 07:00:41 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0ID0cFf020944; Thu, 18 Jan 2007 07:00:39 -0600 (CST) Message-ID: <45AF6F75.1080805@motorola.com> Date: Thu, 18 Jan 2007 14:00:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ram Kumar References: <325900.64238.qm@web31708.mail.mud.yahoo.com> In-Reply-To: <325900.64238.qm@web31708.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Ram Kumar wrote: > Hi, > > With reference to the following link: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg03823.html > > Does Lucent or motorola has a DHCPv6 server? Where can I find > information regarding the same. Please do provide me with a complete > list of commercial DHCPv6 servers available.. Err... I work for Motorola. I have written some DHCPv6 software. I don't sell it. Why do you need list of commercial DHCPv6 servers? You're surely aware DHCPv6 may come built-in other boxes that aren't necessarily named 'DHCPv6 servers' but DHCP is a feature in the feature list. If you need to experiment, there is a bunch of DHCPv6 software widely available in the open-source communities, check SourceForge, FreeBSD, Dibbler, Debian, maybe ISC has something too. Alex > > Thanks. > > Regards, Ram Kumar H > > > ------------------------------------------------------------------------ > Here’s a new way to find what you're looking for - Yahoo! Answers > > > > > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 18 08:02:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Wrd-0007gk-7A; Thu, 18 Jan 2007 07:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Wrb-0007gf-Ui for ipv6@ietf.org; Thu, 18 Jan 2007 07:59:31 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7WrZ-0007PY-FI for ipv6@ietf.org; Thu, 18 Jan 2007 07:59:31 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 07:55:02 -0500 X-IronPort-AV: i="4.13,204,1167627600"; d="scan'208,217"; a="111950301:sNHT5947037872" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0ICt2sd003757; Thu, 18 Jan 2007 07:55:02 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0ICt2OA004371; Thu, 18 Jan 2007 07:55:02 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 07:55:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Jan 2007 07:55:01 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21030785C4@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <325900.64238.qm@web31708.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 servers Thread-Index: Acc60hM/FiYXFjHhSgezRI0WRhEgigALZTyQ From: "Bernie Volz \(volz\)" To: "Ram Kumar" , X-OriginalArrivalTime: 18 Jan 2007 12:55:02.0041 (UTC) FILETIME=[DE161890:01C73AFF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3330; t=1169124902; x=1169988902; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20DHCPv6=20servers |Sender:=20 |To:=20=22Ram=20Kumar=22=20,=20; bh=IwO7PTS3iVqd10YrePzmHnDyeOH44Z0XNVd44QzPvp8=; b=vMzSiLcIK4ayZToz8W53f5u8LD2rCnyWkwqKloZWS1RNjOHSa79zDnqVIECpbluOvm6BhxcC 5myjFI93ij/SR5TaQVaaTvpWhau5f+8fbcwsT2Nkn5TSE68N4jTkFtOz; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: RE: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2034334143==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============2034334143== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73AFF.DDE8143E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73AFF.DDE8143E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cisco has one -- see Cisco Network Registrar -- http://www.cisco.com/en/US/products/sw/netmgtsw/ps1982/index.html. =20 - Bernie ________________________________ From: Ram Kumar [mailto:hrk_y2k1@yahoo.com]=20 Sent: Thursday, January 18, 2007 2:23 AM To: ipv6@ietf.org Subject: reg: DHCPv6 servers Hi, With reference to the following link: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03823.html Does Lucent or motorola has a DHCPv6 server? Where can I find information regarding the same. Please do provide me with a complete list of commercial DHCPv6 servers available.. Thanks. Regards, Ram Kumar H=20 ________________________________ Here's a new way to find what you're looking for - Yahoo! Answers ------_=_NextPart_001_01C73AFF.DDE8143E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Cisco has one -- see Cisco Network Registrar -- = http://www.cisco.com/en/US/products/sw/netmgtsw/ps1982/index.html.<= /FONT>
 
- Bernie

From: Ram Kumar = [mailto:hrk_y2k1@yahoo.com]=20
Sent: Thursday, January 18, 2007 2:23 AM
To:=20 ipv6@ietf.org
Subject: reg: DHCPv6 = servers

Hi,

With=20 reference to the following link:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg0382= 3.html

Does=20 Lucent or motorola has a DHCPv6 server? Where can I find information = regarding=20 the same.
Please do provide me with a complete list of commercial = DHCPv6=20 servers available..

Thanks.

Regards,
Ram Kumar H


Here’s a new way to find what you're looking for - Yahoo!=20 Answers ------_=_NextPart_001_01C73AFF.DDE8143E-- --===============2034334143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2034334143==-- From ipv6-bounces@ietf.org Thu Jan 18 08:13:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7X4c-0007go-Ek; Thu, 18 Jan 2007 08:12:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7X4b-0007e0-0E for ipv6@ietf.org; Thu, 18 Jan 2007 08:12:57 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7X4T-0001CH-BB for ipv6@ietf.org; Thu, 18 Jan 2007 08:12:56 -0500 X-VirusChecked: Checked X-Env-Sender: Reji.Varghese@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1169125967!3538844!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 9178 invoked from network); 18 Jan 2007 13:12:47 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-9.tower-128.messagelabs.com with SMTP; 18 Jan 2007 13:12:47 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l0IDClHD012699 for ; Thu, 18 Jan 2007 07:12:47 -0600 (CST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0IDCjcX027107 for ; Thu, 18 Jan 2007 07:12:46 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Jan 2007 21:11:11 +0800 Message-ID: <36AA252D80F2584CAF9649BCE8EC87ED01605CB3@ZMY16EXM67.ds.mot.com> In-Reply-To: <325900.64238.qm@web31708.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 servers Thread-Index: Acc60hJsecPhnzCSQI+TzdRXisNnvgAL3quQ From: "Varghese Reji-A16389" To: "Ram Kumar" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: RE: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075842176==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1075842176== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73B02.5760C879" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73B02.5760C879 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Probably you should try with Incognito (http://www.incognito.com/) =20 Regards Reji Varghese ________________________________ From: Ram Kumar [mailto:hrk_y2k1@yahoo.com]=20 Sent: Thursday, January 18, 2007 12:53 PM To: ipv6@ietf.org Subject: reg: DHCPv6 servers Hi, With reference to the following link: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03823.html Does Lucent or motorola has a DHCPv6 server? Where can I find information regarding the same. Please do provide me with a complete list of commercial DHCPv6 servers available.. Thanks. Regards, Ram Kumar H=20 ________________________________ Here's a new way to find what you're looking for - Yahoo! Answers ------_=_NextPart_001_01C73B02.5760C879 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Probably you should try with Incognito (http://www.incognito.com/)<= /SPAN>
 
Regards
Reji Varghese

From: Ram Kumar = [mailto:hrk_y2k1@yahoo.com]=20
Sent: Thursday, January 18, 2007 12:53 PM
To:=20 ipv6@ietf.org
Subject: reg: DHCPv6 = servers

Hi,

With=20 reference to the following link:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg0382= 3.html

Does=20 Lucent or motorola has a DHCPv6 server? Where can I find information = regarding=20 the same.
Please do provide me with a complete list of commercial = DHCPv6=20 servers available..

Thanks.

Regards,
Ram Kumar H


Here’s a new way to find what you're looking for - Yahoo!=20 Answers ------_=_NextPart_001_01C73B02.5760C879-- --===============1075842176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1075842176==-- From ipv6-bounces@ietf.org Thu Jan 18 08:16:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7X82-0002ux-KV; Thu, 18 Jan 2007 08:16:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7X80-0002us-Vu for ipv6@ietf.org; Thu, 18 Jan 2007 08:16:28 -0500 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7X7v-000251-ID for ipv6@ietf.org; Thu, 18 Jan 2007 08:16:28 -0500 Received: from DESPACHO by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002351980.msg for ; Thu, 18 Jan 2007 14:13:36 +0100 From: "Alvaro Vives" To: Date: Thu, 18 Jan 2007 14:16:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc60pT1MNkJq3qDQYy8ZyRP1jqqOQAL6qvg In-Reply-To: <325900.64238.qm@web31708.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Authenticated-Sender: alvaro.vives@consulintel.es X-HashCash: 1:20:070118:ipv6@ietf.org::C/GFQUUiDqxUymNs:00001eJp X-MDRemoteIP: 88.11.55.111 X-Return-Path: alvaro.vives@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org Message-ID: X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Thu, 18 Jan 2007 14:13:37 +0100 X-MDAV-Processed: consulintel.es, Thu, 18 Jan 2007 14:13:37 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: RE: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alvaro.vives@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, In the following link you can find some of them just doing a free search of 'DHCP': http://www.ipv6-to-standard.org/index.php Regards, Alvaro Vives ________________________________________ De: Ram Kumar [mailto:hrk_y2k1@yahoo.com] Enviado el: jueves, 18 de enero de 2007 8:23 Para: ipv6@ietf.org Asunto: reg: DHCPv6 servers Hi, With reference to the following link: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03823.html Does Lucent or motorola has a DHCPv6 server? Where can I find information regarding the same. Please do provide me with a complete list of commercial DHCPv6 servers available.. Thanks. Regards, Ram Kumar H ________________________________________ Here's a new way to find what you're looking for - Yahoo! Answers ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 18 14:38:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7d3T-0002dM-Cb; Thu, 18 Jan 2007 14:36:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7d3Q-0002dG-V5 for ipv6@ietf.org; Thu, 18 Jan 2007 14:36:08 -0500 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7d3N-0008Ki-Mj for ipv6@ietf.org; Thu, 18 Jan 2007 14:36:08 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B07AD11425 for ; Thu, 18 Jan 2007 19:35:56 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 18 Jan 2007 14:00:37 +0100." <45AF6F75.1080805@motorola.com> References: <325900.64238.qm@web31708.mail.mud.yahoo.com> <45AF6F75.1080805@motorola.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 18 Jan 2007 19:35:56 +0000 Message-ID: <78718.1169148956@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Re: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > If you need to experiment, there is a bunch of DHCPv6 software widely > available in the open-source communities, check SourceForge, FreeBSD, > Dibbler, Debian, maybe ISC has something too. isc has been doing some contract sw/dev on dhcpv6, but it's not ready for general release yet. i also gave a preso on this general topic, entitled: DHCPv6 - The Case Against Stateless Autoconfig at the NAV6TF meeting at san jose state last year. (slides available upon request.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 18 14:50:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dFt-0000Bs-BJ; Thu, 18 Jan 2007 14:49:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dFr-0000Bk-B0 for ipv6@ietf.org; Thu, 18 Jan 2007 14:48:59 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dFo-0002CM-3b for ipv6@ietf.org; Thu, 18 Jan 2007 14:48:59 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0IJmrKH007381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jan 2007 13:48:53 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0IJmqFV012228; Thu, 18 Jan 2007 11:48:52 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0IJmkTg011947; Thu, 18 Jan 2007 11:48:52 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 11:48:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jan 2007 11:48:45 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017745CE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <78718.1169148956@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: reg: DHCPv6 servers Thread-Index: Acc7OEmTmMWAkFhKTUGCHmXvLmUnywAATGNA From: "Templin, Fred L" To: , X-OriginalArrivalTime: 18 Jan 2007 19:48:47.0000 (UTC) FILETIME=[AAEA3980:01C73B39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: RE: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > i also gave a preso on this general=20 > topic, entitled: >=20 > DHCPv6 - The Case Against Stateless Autoconfig >=20 > at the NAV6TF meeting at san jose state last year. (slides=20 > available upon request.) Yes, please. Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 19 14:46:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zdT-0005qT-VQ; Fri, 19 Jan 2007 14:42:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zdS-0005qL-Nw for ipv6@ietf.org; Fri, 19 Jan 2007 14:42:50 -0500 Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7zdR-0003Wk-Cb for ipv6@ietf.org; Fri, 19 Jan 2007 14:42:50 -0500 Received: from vms073.mailsrvcs.net ([192.168.1.2]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JC400KTUS301JT0@vms040.mailsrvcs.net> for ipv6@ietf.org; Fri, 19 Jan 2007 13:42:36 -0600 (CST) Received: from 129.55.200.20 ([129.55.200.20]) by vms073.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 19 Jan 2007 13:42:36 -0600 (CST) Date: Fri, 19 Jan 2007 13:42:36 -0600 (CST) From: Tim Enos X-Originating-IP: [129.55.200.20] To: Paul Vixie , ipv6@ietf.org Message-id: <2875244.8028871169235756544.JavaMail.root@vms073.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: Re: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Paul, >From: Paul Vixie >Date: 2007/01/18 Thu PM 01:35:56 CST >To: ipv6@ietf.org >Subject: Re: reg: DHCPv6 servers >i also gave a preso on this general topic, entitled: > > DHCPv6 - The Case Against Stateless Autoconfig > >at the NAV6TF meeting at san jose state last year. (slides available upon >request.) Interesting title. Would you please also send me a copy of the slides? Best Regards, Tim Enos Rom 8:28 > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 19 15:50:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80ec-0003tx-EH; Fri, 19 Jan 2007 15:48:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80eb-0003tf-9W for ipv6@ietf.org; Fri, 19 Jan 2007 15:48:05 -0500 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H80eY-0006ma-Vi for ipv6@ietf.org; Fri, 19 Jan 2007 15:48:05 -0500 Received: by an-out-0708.google.com with SMTP id d30so319984and for ; Fri, 19 Jan 2007 12:48:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:from:subject:date:importance:x-priority:to:content-transfer-encoding:content-type:message-id; b=iSaMEykD1Ef5EumOx0bolsMDZFhp+wWH/QzhMwrBkMQDknspLkXJR/87vsxkEJZFruEI+vAmIPxG3Ee66bN16VaCAF1266wEdPtvcz6h1Jwk8NaZLT1BI5hOVkQn5VjLKr5NhuXyCMJJ3qztz/FVoOoC0dZ4szimqcV9b/bFlFA= Received: by 10.48.48.18 with SMTP id v18mr2803326nfv.1169239681784; Fri, 19 Jan 2007 12:48:01 -0800 (PST) Received: from Inbox ( [75.199.91.210]) by mx.google.com with ESMTP id n23sm5450141nfc.2007.01.19.12.47.42; Fri, 19 Jan 2007 12:48:01 -0800 (PST) MIME-Version: 1.0 From: TJ Date: Fri, 19 Jan 2007 15:47:59 -0500 Importance: normal X-Priority: 3 To: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45b12e81.397e7c8f.0640.2aee@mx.google.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: RE: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Please add me to the 'interested' list. Thanks! /TJ (mobile) -----Original Message----- From: "Tim Enos" To: "Paul Vixie" ; ipv6@ietf.org Sent: 01/19/07 14:42 Subject: Re: reg: DHCPv6 servers Hi Paul, >From: Paul Vixie >Date: 2007/01/18 Thu PM 01:35:56 CST >To: ipv6@ietf.org >Subject: Re: reg: DHCPv6 servers >i also gave a preso on this general topic, entitled: > > DHCPv6 - The Case Against Stateless Autoconfig > >at the NAV6TF meeting at san jose state last year. (slides available upon >request.) Interesting title. Would you please also send me a copy of the slides? Best Regards, Tim Enos Rom 8:28 > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 19 16:00:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80pM-000418-2K; Fri, 19 Jan 2007 15:59:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80pK-0003yT-Vf for ipv6@ietf.org; Fri, 19 Jan 2007 15:59:10 -0500 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H80pH-0000Sk-LK for ipv6@ietf.org; Fri, 19 Jan 2007 15:59:10 -0500 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JC400129VMHRM@firewall.mci.com> for ipv6@ietf.org; Fri, 19 Jan 2007 20:59:05 +0000 (GMT) Received: from instserve0.corp.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: instserve0.corp.us.uu.net [153.39.89.142]) id QQvxvn26320 for ; Fri, 19 Jan 2007 20:59:04 +0000 (GMT) Received: by instserve0.corp.us.uu.net id QQvxvn28543; Fri, 19 Jan 2007 15:58:47 -0500 (EST) Date: Fri, 19 Jan 2007 15:58:47 -0500 From: Anthony Williams To: ipv6@ietf.org Message-id: <20070119155847.A28170@uu.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: alby.williams@verizonbusiness.com Subject: Re: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Throw me on the list. -Alby On 19/01/07 15:47 -0500, TJ wrote: > Please add me to the 'interested' list. > > Thanks! > /TJ (mobile) > > -----Original Message----- > From: "Tim Enos" > To: "Paul Vixie" ; ipv6@ietf.org > Sent: 01/19/07 14:42 > Subject: Re: reg: DHCPv6 servers > > Hi Paul, > > >From: Paul Vixie > >Date: 2007/01/18 Thu PM 01:35:56 CST > >To: ipv6@ietf.org > >Subject: Re: reg: DHCPv6 servers > > >i also gave a preso on this general topic, entitled: > > > > DHCPv6 - The Case Against Stateless Autoconfig > > > >at the NAV6TF meeting at san jose state last year. (slides available upon > >request.) > > Interesting title. Would you please also send me a copy of the slides? > > Best Regards, > > Tim Enos > Rom 8:28 > > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 19 16:02:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80rj-0004hG-Lp; Fri, 19 Jan 2007 16:01:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80ri-0004h1-AW for ipv6@ietf.org; Fri, 19 Jan 2007 16:01:38 -0500 Received: from mailhost1.sra.com ([163.252.31.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H80rg-0000uA-Js for ipv6@ietf.org; Fri, 19 Jan 2007 16:01:38 -0500 Received: from flex3.sra.com ([163.252.31.50]) by mailhost1.sra.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Jan 2007 16:01:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jan 2007 16:01:35 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: reg: DHCPv6 servers Thread-Index: Acc8DLRzaYGlZ+dSQVyui3m0IvdYcAAAB5/A References: <20070119155847.A28170@uu.net> From: "Whitlock, Tommy Lee" To: X-OriginalArrivalTime: 19 Jan 2007 21:01:36.0243 (UTC) FILETIME=[01998C30:01C73C0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: RE: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Please send to me as well. Thanks! =20 Cheers, Tommy Lee Whitlock =20 > -----Original Message----- > From: Anthony Williams [mailto:alby.williams@verizonbusiness.com] > Sent: Friday, January 19, 2007 3:59 PM > To:=20 > Cc: alby.williams@verizonbusiness.com > Subject: Re: reg: DHCPv6 servers >=20 >=20 > Throw me on the list. >=20 > -Alby >=20 >=20 >=20 >=20 >=20 > On 19/01/07 15:47 -0500, TJ wrote: > > Please add me to the 'interested' list. > > > > Thanks! > > /TJ (mobile) > > > > -----Original Message----- > > From: "Tim Enos" > > To: "Paul Vixie" ; ipv6@ietf.org > > Sent: 01/19/07 14:42 > > Subject: Re: reg: DHCPv6 servers > > > > Hi Paul, > > > > >From: Paul Vixie > > >Date: 2007/01/18 Thu PM 01:35:56 CST > > >To: ipv6@ietf.org > > >Subject: Re: reg: DHCPv6 servers > > > > >i also gave a preso on this general topic, entitled: > > > > > > DHCPv6 - The Case Against Stateless Autoconfig > > > > > >at the NAV6TF meeting at san jose state last year. (slides available upon > > >request.) > > > > Interesting title. Would you please also send me a copy of the slides? > > > > Best Regards, > > > > Tim Enos > > Rom 8:28 > > > > > > > >-------------------------------------------------------------------- > > >IETF IPv6 working group mailing list > > >ipv6@ietf.org > > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > >-------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 20 01:40:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H89rX-0002FR-5u; Sat, 20 Jan 2007 01:38:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H89rV-0002E9-HB for ipv6@ietf.org; Sat, 20 Jan 2007 01:38:01 -0500 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H89rM-0003gA-1R for ipv6@ietf.org; Sat, 20 Jan 2007 01:38:01 -0500 Received: by py-out-1112.google.com with SMTP id f31so336795pyh for ; Fri, 19 Jan 2007 22:37:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Agis0xgPhwDMIWV34MxaXt6AbpQn/rfexOPjbMlzycEH8DFKhc1Wnl3J2aooIkPGT2m1vwgGSNpRHt84eVndSOUsiELWeoJWFrzoMVu8TKRGO2dRES8Ujh2HX+uyVAF8P9yhhrks7lgPy4WhUGPjayiW9Ix+3wybSOdk0/CL4jE= Received: by 10.35.96.7 with SMTP id y7mr319695pyl.1169275071553; Fri, 19 Jan 2007 22:37:51 -0800 (PST) Received: by 10.35.83.12 with HTTP; Fri, 19 Jan 2007 22:37:51 -0800 (PST) Message-ID: <2a86e2e0701192237l28e5731ckd904891ee09c7c7c@mail.gmail.com> Date: Sat, 20 Jan 2007 15:37:51 +0900 From: "Syed Obaid Amin" To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: Is there IPv6 support in NS 2 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Dear Colleagues I am new to NS-2 and doesnt know much about it. I have to simulate an IPv6 network on NS-2 but unable to find any clue so far. Any help or pointer would be great help for me. Thanking you in advance Best Regards Obaid -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 20 08:42:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8GQK-0007yc-2W; Sat, 20 Jan 2007 08:38:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dLw-0003xK-AV for ipv6@ietf.org; Thu, 18 Jan 2007 14:55:16 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dLq-0003Xu-0w for ipv6@ietf.org; Thu, 18 Jan 2007 14:55:16 -0500 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.59]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 5A0C53474A; Thu, 18 Jan 2007 13:55:09 -0600 (CST) Received: from G3W0065.americas.hpqcorp.net ([16.232.1.17]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 13:55:06 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jan 2007 13:55:05 -0600 Message-ID: <7EC821B346EB8A42AE38E123DD9CFD6F0167353A@G3W0065.americas.hpqcorp.net> In-Reply-To: <78718.1169148956@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: reg: DHCPv6 servers Thread-Index: Acc7OFV9HmsD+G0wQqmDjbCp4EXfjgAAgYUA From: "Burden, Ken" To: "Paul Vixie" , X-OriginalArrivalTime: 18 Jan 2007 19:55:06.0061 (UTC) FILETIME=[8CDA57D0:01C73B3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Sat, 20 Jan 2007 08:38:21 -0500 Cc: Subject: RE: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Please send me a copy. Ken Ken.burden@hp.com -----Original Message----- From: Paul Vixie [mailto:paul@vix.com]=20 Sent: Thursday, January 18, 2007 11:36 AM To: ipv6@ietf.org Subject: Re: reg: DHCPv6 servers=20 > If you need to experiment, there is a bunch of DHCPv6 software widely > available in the open-source communities, check SourceForge, FreeBSD, > Dibbler, Debian, maybe ISC has something too. isc has been doing some contract sw/dev on dhcpv6, but it's not ready for general release yet. i also gave a preso on this general topic, entitled: DHCPv6 - The Case Against Stateless Autoconfig at the NAV6TF meeting at san jose state last year. (slides available upon request.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 20 13:27:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Ksg-0006eN-G3; Sat, 20 Jan 2007 13:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Ksf-0006eF-8P for ipv6@ietf.org; Sat, 20 Jan 2007 13:23:57 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Ksd-0007ge-UW for ipv6@ietf.org; Sat, 20 Jan 2007 13:23:57 -0500 Received: by ug-out-1314.google.com with SMTP id 72so640691ugd for ; Sat, 20 Jan 2007 10:23:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q8xaDOvWxQdlt78+HQU/LcT2SiCuO8aWYFDhdcjjIHvUn4oq8B+Rjuzkhga/lZx5VXCytjQDDohNFpThh6HxfWh6X/irCY2+DHMfTMT9FmJmkFoIxoVv44yvkZQwphU1oIHauM6BXT5J9B3QshaBLfrGhvyUUb1SvTaYN2rNXO8= Received: by 10.67.92.1 with SMTP id u1mr4975081ugl.1169317434972; Sat, 20 Jan 2007 10:23:54 -0800 (PST) Received: by 10.66.239.6 with HTTP; Sat, 20 Jan 2007 10:23:54 -0800 (PST) Message-ID: <90cbfd80701201023o3a9b8782o1167ef382d503fb1@mail.gmail.com> Date: Sat, 20 Jan 2007 16:23:54 -0200 From: "Guilherme Sperb Machado" To: "Paul Vixie" In-Reply-To: <78718.1169148956@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325900.64238.qm@web31708.mail.mud.yahoo.com> <45AF6F75.1080805@motorola.com> <78718.1169148956@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org Subject: Re: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Please, send me a copy. I'm really interested. :) On 1/18/07, Paul Vixie wrote: > > If you need to experiment, there is a bunch of DHCPv6 software widely > > available in the open-source communities, check SourceForge, FreeBSD, > > Dibbler, Debian, maybe ISC has something too. > > isc has been doing some contract sw/dev on dhcpv6, but it's not ready for > general release yet. i also gave a preso on this general topic, entitled: > > DHCPv6 - The Case Against Stateless Autoconfig > > at the NAV6TF meeting at san jose state last year. (slides available upon > request.) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jan 20 19:04:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Q83-00016c-Vj; Sat, 20 Jan 2007 19:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Q83-00016X-6e for ipv6@ietf.org; Sat, 20 Jan 2007 19:00:11 -0500 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Q81-0004PR-68 for ipv6@ietf.org; Sat, 20 Jan 2007 19:00:10 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 886C628426 for ; Sun, 21 Jan 2007 00:00:02 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 21 Jan 2007 00:00:02 +0000 Message-Id: <20070121000002.886C628426@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.54% | 3 | 12.85% | 17832 | jinmei@isl.rdc.toshiba.co.jp 7.69% | 2 | 6.56% | 9107 | mohta@necom830.hpcl.titech.ac.jp 3.85% | 1 | 6.19% | 8599 | volz@cisco.com 3.85% | 1 | 6.02% | 8362 | pars.mutaf@int-evry.fr 3.85% | 1 | 5.69% | 7894 | reji.varghese@motorola.com 3.85% | 1 | 4.46% | 6188 | huitema@windows.microsoft.com 3.85% | 1 | 4.39% | 6099 | hrk_y2k1@yahoo.com 3.85% | 1 | 4.08% | 5661 | tommylee_whitlock@sra.com 3.85% | 1 | 3.98% | 5526 | jari.arkko@piuha.net 3.85% | 1 | 3.88% | 5382 | alexandru.petrescu@motorola.com 3.85% | 1 | 3.64% | 5048 | alby.williams@verizonbusiness.com 3.85% | 1 | 3.63% | 5044 | thierry.ernst@inria.fr 3.85% | 1 | 3.55% | 4933 | bmanning@karoshi.com 3.85% | 1 | 3.50% | 4860 | alvaro.vives@consulintel.es 3.85% | 1 | 3.44% | 4781 | trejrco@gmail.com 3.85% | 1 | 3.34% | 4638 | gsmachado@gmail.com 3.85% | 1 | 3.34% | 4636 | sra+ipng@hactrn.net 3.85% | 1 | 3.31% | 4597 | ken.burden@hp.com 3.85% | 1 | 3.16% | 4381 | fred.l.templin@boeing.com 3.85% | 1 | 2.88% | 3997 | timbeck04@verizon.net 3.85% | 1 | 2.73% | 3783 | obaidasyed@gmail.com 3.85% | 1 | 2.72% | 3769 | mark_andrews@isc.org 3.85% | 1 | 2.66% | 3690 | paul@vix.com --------+------+--------+----------+------------------------ 100.00% | 26 |100.00% | 138807 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 21 03:29:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Y17-0002zT-RJ; Sun, 21 Jan 2007 03:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Y16-0002rO-Me for ipv6@ietf.org; Sun, 21 Jan 2007 03:25:32 -0500 Received: from salmon.maths.tcd.ie ([2001:770:10:300::86e2:510b]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8Y11-0006U7-6X for ipv6@ietf.org; Sun, 21 Jan 2007 03:25:30 -0500 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 21 Jan 2007 08:25:17 +0000 (GMT) Date: Sun, 21 Jan 2007 08:25:17 +0000 From: David Malone To: Syed Obaid Amin Message-ID: <20070121082517.GB98256@walton.maths.tcd.ie> References: <2a86e2e0701192237l28e5731ckd904891ee09c7c7c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a86e2e0701192237l28e5731ckd904891ee09c7c7c@mail.gmail.com> User-Agent: Mutt/1.5.6i X-Spam-Score: -2.8 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org Subject: Re: Is there IPv6 support in NS 2 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Sat, Jan 20, 2007 at 03:37:51PM +0900, Syed Obaid Amin wrote: > I am new to NS-2 and doesnt know much about it. I have to simulate an > IPv6 network on NS-2 but unable to find any clue so far. What aspects of IPv6 do you want to simulate? The addressing used in NS is usually kind-of abstracted, and so doesn't directly correspond to IPv6 or IPv4. I'd also guess that you'd be more likely to get an answer to a question like this on the ns-users mailing list. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 21 23:16:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8qWR-0002oK-0y; Sun, 21 Jan 2007 23:11:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8qWP-0002o0-5b; Sun, 21 Jan 2007 23:11:05 -0500 Received: from smtp19.orange.fr ([80.12.242.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8qWK-0006nX-QM; Sun, 21 Jan 2007 23:11:05 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1918.orange.fr (SMTP Server) with ESMTP id 2DB541C000B0; Mon, 22 Jan 2007 05:11:00 +0100 (CET) Received: from will.lan (LPuteaux-151-41-30-75.w217-128.abo.wanadoo.fr [217.128.82.75]) by mwinf1918.orange.fr (SMTP Server) with ESMTP id DB87A1C00098; Mon, 22 Jan 2007 05:10:59 +0100 (CET) X-ME-UUID: 20070122041059899.DB87A1C00098@mwinf1918.orange.fr From: Guillaume FORTAINE Organization: Power.org To: ipv6@ietf.org Date: Mon, 22 Jan 2007 05:10:45 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701220510.45803.guillaume.fortaine@wanadoo.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: stds-802-21@ieee.org, monami6@ietf.org Subject: Next Generation Networks X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Misters, Happy New year to you :) ! Let me introduce myself : Guillaume FORTAINE, French engineer in informatic= s. I found your research projects because I am currently researching people wi= th=20 a strong background in Networking. Me and my collaborator have a team of NA= SA=20 and Nokia engineers.We would want to start a project to develop=20 a new standard a la 802.20 but without repeating/or correcting the past err= or=20 from IPv6 ( included in MAC/PHY layer of 802.20). =46or the HandOver part, we have not made the final choice : There are FMIPv6: http://www.fmipv6.org/ or Monami6 : http://www.ietf.org/html.charters/monami6-charter.html or 802.21 : http://www.ieee802.org/21/ Dr. Jose Morales Barroso from L&M Data Communications =A0sent me this link andI believe of interest for you the following paper,= =20 presented at the last eChallenges Conference: =A0 =A0 http://www.lmdata.es/uets/eChallenges-e2006-uets-paper.pdf To quote : "Your comments are welcomed." We look forward to your answer, Best Regards, =A0 =A0 =A0 =A0 =A0 Guillaume -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 22 17:11:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97L1-0001a3-TO; Mon, 22 Jan 2007 17:08:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97L1-0001Zl-5x for ipv6@ietf.org; Mon, 22 Jan 2007 17:08:27 -0500 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H97Kw-0004dM-Iz for ipv6@ietf.org; Mon, 22 Jan 2007 17:08:27 -0500 Received: by an-out-0708.google.com with SMTP id d30so506505and for ; Mon, 22 Jan 2007 14:08:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Pb9KMrw+ixpTCbMi/sGBiNNQaWELaecB/QpJrZEFOJPzkrLwNSVyxNx368ErzzH07fT6DM39Kt1IMxJzbHo4FKBiNYE0OfRglPIR0lBO1UnO+51DjDg6HThvgmOvZB0dWJ4Fz268o05NcEbj3hAnVQntdMsVHjBQUp4duA5NrCQ= Received: by 10.100.124.5 with SMTP id w5mr735043anc.1169503701527; Mon, 22 Jan 2007 14:08:21 -0800 (PST) Received: by 10.100.151.4 with HTTP; Mon, 22 Jan 2007 14:08:21 -0800 (PST) Message-ID: Date: Tue, 23 Jan 2007 07:08:21 +0900 From: "Daniel Park" To: guillaume.fortaine@wanadoo.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ipv6@ietf.org, stds-802-21@ieee.org, monami6@ietf.org Subject: Re:Next Generation Networks X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Guillaume, First off, your question seems a bit ambiguous. Do you want to transmit IPv6 packets over 802.20 networks ? If yes, it is not a big issues. Rather, you should study on how to transmit IPv6 packets over 802.20 networks. IETF has many experiences regarding IPv6 over foo. If you are awaring of any specific characteristics of 802.20 networks, these should be analyzed first, then bring it to IETF. Example: 16ng (IP over 802.16 networks). Also, choosing a specific solution among FMIP, Momani, 802.21 depends on your purpose as well as application. In short, IETF is ready for helping out with the working in every L2 technologies. Hope this helps. Daniel ================================== Misters, Happy New year to you :) ! Let me introduce myself : Guillaume FORTAINE, French engineer in informatics. I found your research projects because I am currently researching people with a strong background in Networking. Me and my collaborator have a team of NASA and Nokia engineers.We would want to start a project to develop a new standard a la 802.20 but without repeating/or correcting the past error from IPv6 ( included in MAC/PHY layer of 802.20). For the HandOver part, we have not made the final choice : There are FMIPv6: http://www.fmipv6.org/ or Monami6 : http://www.ietf.org/html.charters/monami6-charter.html or 802.21 : http://www.ieee802.org/21/ Dr. Jose Morales Barroso from L&M Data Communications sent me this link andI believe of interest for you the following paper, presented at the last eChallenges Conference: http://www.lmdata.es/uets/eChallenges-e2006-uets-paper.pdf To quote : "Your comments are welcomed." We look forward to your answer, Best Regards, Guillaume -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 22 18:17:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98Ng-0006Cq-4G; Mon, 22 Jan 2007 18:15:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98Nf-0006Ci-B3; Mon, 22 Jan 2007 18:15:15 -0500 Received: from smtp23.orange.fr ([193.252.23.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H98Nd-0007gN-1c; Mon, 22 Jan 2007 18:15:15 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2306.orange.fr (SMTP Server) with ESMTP id 0C7D61C0009F; Tue, 23 Jan 2007 00:15:10 +0100 (CET) Received: from will.lan (LPuteaux-151-41-30-75.w217-128.abo.wanadoo.fr [217.128.82.75]) by mwinf2306.orange.fr (SMTP Server) with ESMTP id BAF3A1C00082; Tue, 23 Jan 2007 00:15:09 +0100 (CET) X-ME-UUID: 20070122231509765.BAF3A1C00082@mwinf2306.orange.fr From: Guillaume FORTAINE Organization: Power.org To: "Daniel Park" Date: Tue, 23 Jan 2007 00:14:50 +0100 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701230014.50363.guillaume.fortaine@wanadoo.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org, stds-802-21@ieee.org, monami6@ietf.org Subject: Re: Next Generation Networks X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Monday 22 January 2007 23:08, Daniel Park wrote: > Guillaume, > > First off, your question seems a bit ambiguous. Do you want to > transmit IPv6 packets over 802.20 networks ? If yes, it is not a big > issues. Stupid question : What is an IPv6 packet ? If it was so "easy", I believe that we would already be in an IPv6 World ... > Rather, you should study on how to transmit IPv6 packets over > 802.20 networks. As IP ( v4 & v6 ) is already in the MAC/PHY layer, I don't see what we can analyse here ... It is not like 16ng ( below ) ... > IETF has many experiences regarding IPv6 over foo. If > you are awaring of any specific characteristics of 802.20 networks, > these should be analyzed first, then bring it to IETF. Example: 16ng > (IP over 802.16 networks). Also, choosing a specific solution among > FMIP, Momani, 802.21 depends on your purpose as well as application. > In short, IETF is ready for helping out with the working in every L2 > technologies. > > Hope this helps. Thank you :) > Daniel Best Regards, Guillaume -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 22 19:35:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99aH-0007eo-6L; Mon, 22 Jan 2007 19:32:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99aF-0007ei-ED for ipv6@ietf.org; Mon, 22 Jan 2007 19:32:19 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H99aD-00019w-7c for ipv6@ietf.org; Mon, 22 Jan 2007 19:32:19 -0500 Received: by an-out-0708.google.com with SMTP id d30so529604and for ; Mon, 22 Jan 2007 16:32:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JQai8oiWx29K/3CTnZ5w1c3QekyASdDp6P6dxzQbEufrgzRifnpznmMZ8Yb5aX+m6MQlZt6RoirRsaMCNls2BhspmAb2WTUkf7VruhtmG/HVc+4snUdA8zTPKu+Iyv7osgwmFT/hXJv4yc5auwiFB5vc2eyRUYyyZjFMLb/dxnI= Received: by 10.100.174.16 with SMTP id w16mr714125ane.1169512334934; Mon, 22 Jan 2007 16:32:14 -0800 (PST) Received: by 10.100.151.4 with HTTP; Mon, 22 Jan 2007 16:32:14 -0800 (PST) Message-ID: Date: Tue, 23 Jan 2007 09:32:14 +0900 From: "Daniel Park" To: "Guillaume FORTAINE" In-Reply-To: <200701230014.50363.guillaume.fortaine@wanadoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200701230014.50363.guillaume.fortaine@wanadoo.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org Subject: Re: Next Generation Networks X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Guillaume, Inline: On 1/23/07, Guillaume FORTAINE wrote: > On Monday 22 January 2007 23:08, Daniel Park wrote: > > Guillaume, > > > > First off, your question seems a bit ambiguous. Do you want to > > transmit IPv6 packets over 802.20 networks ? If yes, it is not a big > > issues. > > Stupid question : What is an IPv6 packet ? If it was so "easy", I believe that > we would already be in an IPv6 World ... You are digressing from the core. I didn't say any IPv6 world, but just wanted to let you know IP over foo could be dealt with IETF as well. IPv6 world, um... it does not belong to IETF. -- Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 23 06:59:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9KEx-0001li-KE; Tue, 23 Jan 2007 06:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9KEu-0001j4-My for ipv6@ietf.org; Tue, 23 Jan 2007 06:55:00 -0500 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9KEo-0003FQ-6T for ipv6@ietf.org; Tue, 23 Jan 2007 06:54:58 -0500 Received: from DESPACHO by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002357973.msg for ; Tue, 23 Jan 2007 12:52:06 +0100 From: "Alvaro Vives" To: Date: Tue, 23 Jan 2007 12:53:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc7OFhcRtqMcVb3T5aIPVZsxzIRbwDrLZWw In-Reply-To: <78718.1169148956@sa.vix.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Authenticated-Sender: alvaro.vives@consulintel.es X-HashCash: 1:20:070123:ipv6@ietf.org::Oe1F22u7D3cTFmfR:00000+m1 X-MDRemoteIP: 88.16.50.201 X-Return-Path: alvaro.vives@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org Message-ID: X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Tue, 23 Jan 2007 12:52:06 +0100 X-MDAV-Processed: consulintel.es, Tue, 23 Jan 2007 12:52:07 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: RE: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alvaro.vives@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Please, I also would like a copy of that slides. Thanks! BR, Alvaro > -----Mensaje original----- > De: Paul Vixie [mailto:paul@vix.com] > Enviado el: jueves, 18 de enero de 2007 20:36 > Para: ipv6@ietf.org > Asunto: Re: reg: DHCPv6 servers > > > If you need to experiment, there is a bunch of DHCPv6 software widely > > available in the open-source communities, check SourceForge, FreeBSD, > > Dibbler, Debian, maybe ISC has something too. > > isc has been doing some contract sw/dev on dhcpv6, but it's not ready for > general release yet. i also gave a preso on this general topic, entitled: > > DHCPv6 - The Case Against Stateless Autoconfig > > at the NAV6TF meeting at san jose state last year. (slides available upon > request.) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 23 07:26:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9KiL-0007CP-VQ; Tue, 23 Jan 2007 07:25:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9KiK-0007CE-Kn for ipv6@ietf.org; Tue, 23 Jan 2007 07:25:24 -0500 Received: from mail2.iabg.de ([62.245.167.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9KiF-0004pW-Uz for ipv6@ietf.org; Tue, 23 Jan 2007 07:25:24 -0500 Received: from mail2.iabg.de (localhost [127.0.0.1]) by localhost.iabg.de (Mailserver2 IABG) with ESMTP id B106D12A6; Tue, 23 Jan 2007 13:25:09 +0100 (CET) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail2.iabg.de (Mailserver2 IABG) with ESMTP id 9DEF8CCE; Tue, 23 Jan 2007 13:25:09 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jan 2007 13:25:11 +0100 Message-ID: <69A5E767EC979846826F566C7932A3F204CCFB2C@exchange03.iabg.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: reg: DHCPv6 servers Thread-Index: Acc7OFhcRtqMcVb3T5aIPVZsxzIRbwDrLZWwAAENSGA= References: <78718.1169148956@sa.vix.com> From: "Bartsch Wolfgang" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: RE: reg: DHCPv6 servers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I was able to download a copy at http://www.ipv6conference.com/. Best, Wolfgang IABG mbH IK 22 - PPP & Sourcing Strategien =20 =20 >-----Original Message----- >From: Alvaro Vives [mailto:alvaro.vives@consulintel.es]=20 >Sent: Tuesday, January 23, 2007 12:54 PM >To: ipv6@ietf.org >Subject: RE: reg: DHCPv6 servers > >Please, I also would like a copy of that slides. Thanks! > >BR, >Alvaro > >> -----Mensaje original----- >> De: Paul Vixie [mailto:paul@vix.com] >> Enviado el: jueves, 18 de enero de 2007 20:36 >> Para: ipv6@ietf.org >> Asunto: Re: reg: DHCPv6 servers >>=20 >> > If you need to experiment, there is a bunch of DHCPv6 software=20 >> > widely available in the open-source communities, check=20 >SourceForge,=20 >> > FreeBSD, Dibbler, Debian, maybe ISC has something too. >>=20 >> isc has been doing some contract sw/dev on dhcpv6, but it's=20 >not ready=20 >> for general release yet. i also gave a preso on this=20 >general topic, entitled: >>=20 >> DHCPv6 - The Case Against Stateless Autoconfig >>=20 >> at the NAV6TF meeting at san jose state last year. (slides=20 >available=20 >> upon >> request.) >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > >********************************************** >The IPv6 Portal: http://www.ipv6tf.org > >Bye 6Bone. Hi, IPv6 ! >http://www.ipv6day.org > >This electronic message contains information which may be=20 >privileged or confidential. The information is intended to be=20 >for the use of the individual(s) named above. If you are not=20 >the intended recipient be aware that any disclosure, copying,=20 >distribution or use of the contents of this information,=20 >including attached files, is prohibited. > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 23 19:36:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9W4m-0005wG-RC; Tue, 23 Jan 2007 19:33:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9W4l-0005tn-Pb for ipv6@ietf.org; Tue, 23 Jan 2007 19:33:19 -0500 Received: from smtp19.orange.fr ([80.12.242.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9W4k-0003J8-Gk for ipv6@ietf.org; Tue, 23 Jan 2007 19:33:19 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1928.orange.fr (SMTP Server) with ESMTP id C51C61C0009B; Wed, 24 Jan 2007 01:33:17 +0100 (CET) Received: from will.lan (LPuteaux-151-41-30-75.w217-128.abo.wanadoo.fr [217.128.82.75]) by mwinf1928.orange.fr (SMTP Server) with ESMTP id 7D9381C00083; Wed, 24 Jan 2007 01:33:17 +0100 (CET) X-ME-UUID: 20070124003317514.7D9381C00083@mwinf1928.orange.fr From: Guillaume FORTAINE Organization: Power.org To: ipv6@ietf.org Date: Wed, 24 Jan 2007 01:32:50 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701240132.50630.guillaume.fortaine@wanadoo.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "JFCM, " Subject: IPv6 Adress Shortage X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hello, Somebodyu sent me this : "I would allow all users to register in their own name (i.e.allowing multiple users to have the same user name), you can say I am an anti dot com guy, this way one can get rid of cyber squatters. Recently there was an article that mentions quote " Shanghainese frusted over name game" in which it states that there are over 3937 people named Chen Jie and 3751 people named Zhang Min and purely in terms of Surnames (last name) Zhang comes out first with almost 90000 occurrences Unquote. Similarly practically every third person in Korea is a Kim and if I talk about Indians I bet you must have heard a at least one Patel not to mention John Smith in England or US. My work is more towards enabling one on one contact universally, which is presently not possible, as ICANN method does not allow it" and "Addressing and numbering problems is more than just hierarchical structure. I know one thing that both IPV4 and IPV6 have posed the address shortage problem and that too when the net user percentage is just between 10 to 20% of the world population, so it is best to have this approach as it has covered practically all possibilities. " Any comments about it ? I look forward to your answer, Best Regards, Guillaume -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 23 20:06:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Wa6-0006gr-0e; Tue, 23 Jan 2007 20:05:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Wa4-0006eJ-C4 for ipv6@ietf.org; Tue, 23 Jan 2007 20:05:40 -0500 Received: from purgatory.unfix.org ([213.136.24.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Wa2-0002lP-UL for ipv6@ietf.org; Tue, 23 Jan 2007 20:05:40 -0500 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 0C06C140C34F; Wed, 24 Jan 2007 02:05:34 +0100 (CET) X-Virus-Scanned: purgatory.unfix.org - http://unfix.org Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory.unfix.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqmKJqsfvnOx; Wed, 24 Jan 2007 02:05:30 +0100 (CET) Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 5AA12140C357; Wed, 24 Jan 2007 02:05:30 +0100 (CET) Message-ID: <45B6B0DC.5000104@spaghetti.zurich.ibm.com> Date: Wed, 24 Jan 2007 01:05:32 +0000 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Guillaume FORTAINE References: <200701240132.50630.guillaume.fortaine@wanadoo.fr> In-Reply-To: <200701240132.50630.guillaume.fortaine@wanadoo.fr> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=333E7C23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ipv6@ietf.org Subject: Re: IPv6 Adress Shortage X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0847913264==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0847913264== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig19211193CAE28D24490E5528" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig19211193CAE28D24490E5528 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Guillaume FORTAINE wrote: > Hello, >=20 > Somebodyu sent me this : [..unrelated quotes about naming and ICANN in general..] Either contact dnsop, where it is probably not appropriate either or better discuss it at any of the ICANN forums. ipv6@ietf.org is not the place as that is about IPv6 "The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6)." See: https://www1.ietf.org/html.charters/ipv6-charter.html for the charter. This thus not include discussion about ICANN or naming. Also note that the person you cc'd is banned from a large number of IETF lists for a reason. Please uphold the decision of the IETF. Greets, Jeroen --------------enig19211193CAE28D24490E5528 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHQEARECADUFAkW2sNwuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58Iw2dAJ9EYbik+9uXaz7w0+Mup2BEAaME 9ACYsqv/kdpqx0KxB2cmYIzGonObWQ== =XGSV -----END PGP SIGNATURE----- --------------enig19211193CAE28D24490E5528-- --===============0847913264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0847913264==-- From ipv6-bounces@ietf.org Wed Jan 24 02:24:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cRl-0004VI-TN; Wed, 24 Jan 2007 02:21:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cRk-0004V6-5k for ipv6@ietf.org; Wed, 24 Jan 2007 02:21:28 -0500 Received: from 59-124-182-147.hinet-ip.hinet.net ([59.124.182.147] helo=zyadd226.zyxel.com.tw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9cRi-0000wz-Em for ipv6@ietf.org; Wed, 24 Jan 2007 02:21:28 -0500 Received: from zytwfe02.ZyXEL.com ([172.23.5.50]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Wed, 24 Jan 2007 15:21:48 +0800 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zytwfe02.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 15:21:45 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 15:21:44 +0800 Received: from tw12012 ([172.23.17.72]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 15:21:44 +0800 Message-ID: <000e01c73f88$2b5e7020$481117ac@tw12012> From: "Sofina Kuo" To: Date: Wed, 24 Jan 2007 15:20:47 +0800 MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-OriginalArrivalTime: 24 Jan 2007 07:21:44.0196 (UTC) FILETIME=[4CEB9C40:01C73F88] X-Spam-Score: 2.0 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Subject: Some questions adout RFC 4293 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936521696==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0936521696== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C73FCB.39604570" This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C73FCB.39604570 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi all, I have some questions about RFC4293: IP MIB: 1.Some table's row state min access is read only, ex: = ipv6RouterAdvertRowStatus and ipAddressRowStatus. But ip address table's ipAddressRowStatus max-access is read-create. It = doesn't describe min-access in RFC 4293. 2. fe80::/10 is well-known prefix. How about fe80::/64? I am not sure = it's ipAddressPrefixOrigin should be well-know type or otherwise. 3.ipSystemStatsOutForwDatagrams Description: The number of datagrams for which this entity was not their final IP = destination and for which it was successful in finding a path to their = final destination. In entities that do not act as IP routers, this = counter will include only those datagrams that were Source-Routed via = this entity, and the Source-Route processing was successful. When tracking interface statistics, the counter of the outgoing = interface is incremented for a "successfully forwarded datagram". ipSystemStatsInForwDatagrams Description: The number of input datagrams for which this entity was not their final = IP destination and for which this entity attempted to find a route to forward them to that final destination. = In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed = via this entity, and the Source-Route processing was successful. =20 When tracking interface statistics, the counter of the incoming = interface is incremented for" each datagram". What's the diferent between ipSystemStatsOutForwDatagrams and = ipSystemStatsInForwDatagrams? Originally, I thought ipSystemStatsOutForwDatagrams =3D = ipSystemStatsInForwDatagrams + forward failed(ex no route). Is that right? In ipSystemStatsInForwDatagrams description, it described the packet = Source-Route processing should be successful. But the counter of the incoming interface is incremented for" each = datagram" not successfully forwarded datagram. Thanks, Regards, sofina ------=_NextPart_000_000B_01C73FCB.39604570 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi all,
I have some questions about RFC4293: IP MIB:
 
1.Some table's row state min access is read only, ex:=20 ipv6RouterAdvertRowStatus and ipAddressRowStatus.
But ip address table's ipAddressRowStatus max-access is = read-create. It=20 doesn't describe min-access in RFC 4293.
2. fe80::/10 is well-known prefix. How about fe80::/64? I am not = sure it's=20 ipAddressPrefixOrigin  should be well-know type or=20 otherwise.
3.ipSystemStatsOutForwDatagrams
Description:
The number of datagrams for which this entity was not = their final IP=20 destination and for which it was successful in finding a path to = their=20 final destination.  In entities that do not act as IP routers, = this=20 counter will include only those datagrams that were Source-Routed via=20 this entity, and the Source-Route processing was successful.
When tracking interface statistics, the counter of = the outgoing=20 interface is incremented for a "successfully  forwarded=20 datagram".
 
ipSystemStatsInForwDatagrams
Description:
The number of input datagrams for which this entity was = not their=20 final IP destination and for which this entity
  attempted = to find=20 a route to forward them to that final destination.  In = entities that=20 do not act as IP routers,
  this counter will include only = those=20 datagrams that were Source-Routed via this entity, and the=20 Source-Route
  processing was=20 successful.
  
  When tracking interface = statistics,=20 the counter of the incoming interface is incremented for" each=20 datagram".

What's the diferent between ipSystemStatsOutForwDatagrams and=20 ipSystemStatsInForwDatagrams?
Originally, I thought ipSystemStatsOutForwDatagrams =3D=20 ipSystemStatsInForwDatagrams + forward failed(ex no route).
Is that right?
In ipSystemStatsInForwDatagrams description, it described the = packet=20 Source-Route processing should be successful.
But the counter of the incoming interface is incremented for" = each=20 datagram" not successfully  forwarded datagram.
 
Thanks,
Regards,
sofina


 
------=_NextPart_000_000B_01C73FCB.39604570-- --===============0936521696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0936521696==-- From ipv6-bounces@ietf.org Wed Jan 24 02:37:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cg2-0003dF-O8; Wed, 24 Jan 2007 02:36:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cg0-0003bn-Td for ipv6@ietf.org; Wed, 24 Jan 2007 02:36:12 -0500 Received: from 59-124-182-147.hinet-ip.hinet.net ([59.124.182.147] helo=zyadd226.zyxel.com.tw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9caw-0003nj-W6 for ipv6@ietf.org; Wed, 24 Jan 2007 02:31:14 -0500 Received: from zytwfe02.ZyXEL.com ([172.23.5.50]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Wed, 24 Jan 2007 15:31:23 +0800 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zytwfe02.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 15:31:19 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 15:31:19 +0800 Received: from tw12012 ([172.23.17.72]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 15:31:18 +0800 Message-ID: <002f01c73f89$81a852b0$481117ac@tw12012> From: "Sofina Kuo" To: "Sofina Kuo" , Date: Wed, 24 Jan 2007 15:30:21 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-OriginalArrivalTime: 24 Jan 2007 07:31:18.0443 (UTC) FILETIME=[A332BFB0:01C73F89] X-Spam-Score: 1.2 (+) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: Subject: Re: Some questions adout RFC 4293 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0044196203==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0044196203== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C73FCC.8FA56D10" This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C73FCC.8FA56D10 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Sorry, the first question is: Some table's row state min access is read only, ex: = ipv6RouterAdvertRowStatus and ipAddressRowStatus. But ipNetToPhysicalTable's ipNetToPhysicalRowStatus max-access is = read-create. It doesn't describe min-access in RFC 4293. Regards, sofina ----- Original Message -----=20 From: Sofina Kuo=20 To: ipv6@ietf.org=20 Sent: Wednesday, January 24, 2007 3:20 PM Subject: Some questions adout RFC 4293 Hi all, I have some questions about RFC4293: IP MIB: 1.Some table's row state min access is read only, ex: = ipv6RouterAdvertRowStatus and ipAddressRowStatus. But ip address table's ipAddressRowStatus max-access is read-create. = It doesn't describe min-access in RFC 4293. 2. fe80::/10 is well-known prefix. How about fe80::/64? I am not sure = it's ipAddressPrefixOrigin should be well-know type or otherwise. 3.ipSystemStatsOutForwDatagrams Description: The number of datagrams for which this entity was not their final IP = destination and for which it was successful in finding a path to their = final destination. In entities that do not act as IP routers, this = counter will include only those datagrams that were Source-Routed via = this entity, and the Source-Route processing was successful. When tracking interface statistics, the counter of the outgoing = interface is incremented for a "successfully forwarded datagram". ipSystemStatsInForwDatagrams Description: The number of input datagrams for which this entity was not their = final IP destination and for which this entity attempted to find a route to forward them to that final destination. = In entities that do not act as IP routers, this counter will include only those datagrams that were = Source-Routed via this entity, and the Source-Route processing was successful. =20 When tracking interface statistics, the counter of the incoming = interface is incremented for" each datagram". What's the diferent between ipSystemStatsOutForwDatagrams and = ipSystemStatsInForwDatagrams? Originally, I thought ipSystemStatsOutForwDatagrams =3D = ipSystemStatsInForwDatagrams + forward failed(ex no route). Is that right? In ipSystemStatsInForwDatagrams description, it described the packet = Source-Route processing should be successful. But the counter of the incoming interface is incremented for" each = datagram" not successfully forwarded datagram. Thanks, Regards, sofina ------=_NextPart_000_002C_01C73FCC.8FA56D10 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Sorry, the first question is:
Some table's row state min access is read only, ex:=20 ipv6RouterAdvertRowStatus and ipAddressRowStatus.
But ipNetToPhysicalTable's ipNetToPhysicalRowStatus max-access = is=20 read-create. It doesn't describe min-access in RFC 4293.
 
Regards,
sofina
----- Original = Message -----
From:=20 Sofina Kuo=20
Sent: = Wednesday, January 24, 2007 3:20=20 PM
Subject: Some = questions adout RFC=20 4293

Hi all,
I have some questions about RFC4293: IP MIB:
 
1.Some table's row state min access is read only, ex:=20 ipv6RouterAdvertRowStatus and ipAddressRowStatus.
But ip address table's ipAddressRowStatus max-access is = read-create. It=20 doesn't describe min-access in RFC 4293.
2. fe80::/10 is well-known prefix. How about fe80::/64? I am not = sure=20 it's ipAddressPrefixOrigin  should be well-know type or = otherwise.
3.ipSystemStatsOutForwDatagrams
Description:
The number of datagrams for which this entity was not = their final IP=20 destination and for which it was successful in finding a path to = their=20 final destination.  In entities that do not act as IP = routers, this=20 counter will include only those datagrams that were Source-Routed via=20 this entity, and the Source-Route processing was = successful.
When tracking interface statistics, the counter of = the outgoing=20 interface is incremented for a "successfully  forwarded=20 datagram".
 
ipSystemStatsInForwDatagrams
Description:
The number of input datagrams for which this entity was = not their=20 final IP destination and for which this = entity
  attempted to=20 find a route to forward them to that final destination.  In = entities=20 that do not act as IP routers,
  this counter will = include only=20 those datagrams that were Source-Routed via this entity, and the=20 Source-Route
  processing was=20 successful.
  
  When tracking interface = statistics,=20 the counter of the incoming interface is incremented for" each=20 datagram".

What's the diferent between ipSystemStatsOutForwDatagrams and=20 ipSystemStatsInForwDatagrams?
Originally, I thought ipSystemStatsOutForwDatagrams =3D=20 ipSystemStatsInForwDatagrams + forward failed(ex no route).
Is that right?
In ipSystemStatsInForwDatagrams description, it described the = packet=20 Source-Route processing should be successful.
But the counter of the incoming interface is incremented = for" each=20 datagram" not successfully  forwarded datagram.
 
Thanks,
Regards,
sofina


 
------=_NextPart_000_002C_01C73FCC.8FA56D10-- --===============0044196203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0044196203==-- From ipv6-bounces@ietf.org Sat Jan 27 19:05:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAxSs-0003sg-15; Sat, 27 Jan 2007 19:00:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAxSp-0003kl-93 for ipv6@ietf.org; Sat, 27 Jan 2007 19:00:08 -0500 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAxSo-0000I1-00 for ipv6@ietf.org; Sat, 27 Jan 2007 19:00:07 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 5A4C328429 for ; Sun, 28 Jan 2007 00:00:03 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 28 Jan 2007 00:00:03 +0000 Message-Id: <20070128000003.5A4C328429@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.18% | 2 | 31.48% | 20558 | chkuo@zyxel.com.tw 18.18% | 2 | 15.67% | 10232 | soohongp@gmail.com 18.18% | 2 | 13.75% | 8983 | guillaume.fortaine@wanadoo.fr 9.09% | 1 | 9.22% | 6019 | jeroen@unfix.org 9.09% | 1 | 8.90% | 5810 | bartsch@iabg.de 9.09% | 1 | 7.81% | 5102 | alvaro.vives@consulintel.es 9.09% | 1 | 7.49% | 4893 | sra+ipng@hactrn.net 9.09% | 1 | 5.69% | 3714 | dwmalone@maths.tcd.ie --------+------+--------+----------+------------------------ 100.00% | 11 |100.00% | 65311 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 28 02:56:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB4pm-0000Hj-UE; Sun, 28 Jan 2007 02:52:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB4pl-0000Gz-DY for ipv6@ietf.org; Sun, 28 Jan 2007 02:52:17 -0500 Received: from [220.189.211.171] (helo=zist.edu.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HB4pg-0004Nt-D4 for ipv6@ietf.org; Sun, 28 Jan 2007 02:52:17 -0500 X-EYOU-SPAMVALUE: 0 X-EYOU-DEALDRC: Received: (eyou anti_spam gateway 3.0); Sun, 28 Jan 2007 15:37:18 +0800 Message-ID: <369969838.17695@zist.edu.cn> X-EYOUMAIL-SMTPAUTH: licanhuang@zstu.edu.cn Received: from 60.176.82.20 by 192.168.101.2 with SMTP; Sun, 28 Jan 2007 15:37:17 +0800 Message-ID: <002f01c742b1$310d7a80$6401a8c0@benq44baf9946b> From: "huang lican" To: References: <17849.65109.342816.974964@hadron.switch.ch> <369965018.12555@zstu.edu.cn> Date: Sun, 28 Jan 2007 15:51:59 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ipv6@ietf.org Subject: new internet draft about Distributed DNS Implementation in IpV6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0254338567==" Errors-To: ipv6-bounces@ietf.org --===============0254338567== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBpbnRlcm5ldCBkcmFmdCBhYm91dCBkaXN0 cmlidXRlZCBETlMgaW1wbGVtZW50YXRpb24gaW4gSVBWNi4NClRoZSBmb2xsb3dpbmcgaXMgdGhl IGFkZHJlc3M6DQogaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pLWQtYW5u b3VuY2UvY3VycmVudC9tc2cxMzU5Ny5odG1sDQpvcg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1saWNhbmh1YW5nLWRuc29wLWRpc3RyaWJ1dGVkZG5zLTAwLnR4 dA0KDQpQbGVhc2UgZ2l2ZSB5b3VyIGNvbW1lbnRzLg0KDQpUaGFua3MgYSBsb3QuDQoNCg0KTGlj YW4gSHVhbmcNCg0K --===============0254338567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0254338567==-- From ipv6-bounces@ietf.org Tue Jan 30 11:59:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwDJ-0002eR-Tt; Tue, 30 Jan 2007 11:52:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwDI-0002bZ-Nb for ipv6@ietf.org; Tue, 30 Jan 2007 11:52:08 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwDH-00078f-37 for ipv6@ietf.org; Tue, 30 Jan 2007 11:52:08 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:52:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 17:52:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a problem about dhcpv6 using 'dhcp-0.10.tgz' Thread-Index: AcdBL/9ue0+ntLI1TkmlONFpcDjSrgDXGDawAACiwRA= From: "zze-FENG Zhimin RD-CORE-CAE" To: X-OriginalArrivalTime: 30 Jan 2007 16:52:05.0910 (UTC) FILETIME=[F9214360:01C7448E] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Subject: TR: a problem about dhcpv6 using 'dhcp-0.10.tgz' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249215532==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1249215532== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7448E.F881BF41" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448E.F881BF41 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Dear Sir or Madame, > I am an intern of France Telecom R&D . I am trying to setup a DHCPv6 > server-client system using the 'dhcp-0.10.tgz'. The server end is ok > , however , I meet a problem : in the DHCPv6 client , where I always > get a error message : ' interface eth0 iaid failed to be created' . > And I do not know how to resolve it. Can you give me an advice? > Thank you very much!=20 > I am looking forward to your reply!=20 > Yours sincerely, > =20 > Zhimin FENG=20 >=20 > And there are these configurations in my computers :=20 >=20 > In the HDCPv6 server :=20 > /etc/ dhcp6s.conf=20 > interface eth0 { > server-preference 255; > renew-time 60; > rebind-time 90; > prefer-life-time 130; > valid-life-time 160; > allow rapid-commit; > link BBB { > pool { > prefix 2001:1234:100::/48; > }; > }; > }; > =09 >=20 > And the terminal :=20 > [root@localhost ~]# dhcp6s -dDf eth0 > Jan/26/2007 09:43:59 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6s_duid: 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd > Jan/26/2007 09:43:59 set timer for syncing file ... > Jan/26/2007 09:43:59 interface definition for eth0 is ok=09 >=20 >=20 > In the DHCPv6 Clinet : >=20 > Dhcp6c.conf=20 >=20 > interface eth0 { > # information-only; > send rapid-commit; > request prefix-delegation; > # request temp-address; > }; > =09 >=20 > In the terminal : > [root@localhost dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0 >=20 > Jan/26/2007 09:39:57 <3>[interface] (9) > Jan/26/2007 09:39:57 <5>[eth0] (4) > Jan/26/2007 09:39:57 <3>begin of closure [{] (1) > Jan/26/2007 09:39:57 <3>comment [# information-only;] (19) > Jan/26/2007 09:39:57 <3>[send] (4) > Jan/26/2007 09:39:57 <3>[rapid-commit] (12) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>[request] (7) > Jan/26/2007 09:39:57 <3>[prefix-delegation] (17) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>comment [# request temp-address;] (23) > Jan/26/2007 09:39:57 <3>end of closure [}] (1) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6c_duid: > 00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4 > Jan/26/2007 09:39:57 link local addr is fe80::250:daff:fe47:8ff9 > Jan/26/2007 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28 > Jan/26/2007 09:39:57 found an interface eth0 harware bfdeed25 > Jan/26/2007 09:39:57 interface eth0 iaid failed to be created=09 >=20 >=20 ------_=_NextPart_001_01C7448E.F881BF41 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable TR: a problem about dhcpv6 using 'dhcp-0.10.tgz'

Dear Sir or = Madame,
I am an intern = of France Telecom R&D . I am trying to setup  a DHCPv6 = server-client system using the 'dhcp-0.10.tgz'.  The server end is = ok , however , I meet a problem : in the DHCPv6 client , where I always = get a error message : ' interface eth0 iaid failed to be created' = . And I do not know how to resolve it. Can you give me an = advice?

Thank you very = much!
I am looking = forward to your reply!
Yours = sincerely,
 
Zhimin FENG =

And there are = these configurations  in my  computers :

In the HDCPv6 = server :
/etc/ = dhcp6s.conf
interface eth0 = {
      server-preference = 255;
     renew-time 60;
     rebind-time 90;
    prefer-life-time 130;
    valid-life-time 160;
    allow rapid-commit;
   = link BBB {
       pool {
           = prefix 2001:1234:100::/48;
       };
          = };
};
       
And  the = terminal :
[root@localhost = ~]# dhcp6s -dDf eth0
Jan/26/2007 = 09:43:59 extracted an existing DUID from /var/lib/dhcpv6/dhcp6s_duid: = 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd

Jan/26/2007 = 09:43:59 set timer for syncing file ...
Jan/26/2007 = 09:43:59 interface definition for eth0 is = ok       

In the DHCPv6 = Clinet :

Dhcp6c.conf =

interface eth0 = {
#       = information-only;
           send = rapid-commit;
        = request prefix-delegation;
#       request = temp-address;
};
       
In the terminal = :
[root@localhost = dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0

Jan/26/2007 = 09:39:57 <3>[interface] (9)
Jan/26/2007 = 09:39:57 <5>[eth0] (4)
Jan/26/2007 = 09:39:57 <3>begin of closure [{] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      = information-only;] (19)
Jan/26/2007 = 09:39:57 <3>[send] (4)
Jan/26/2007 = 09:39:57 <3>[rapid-commit] (12)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>[request] (7)
Jan/26/2007 = 09:39:57 <3>[prefix-delegation] (17)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      request = temp-address;] (23)
Jan/26/2007 = 09:39:57 <3>end of closure [}] (1)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 extracted an existing DUID from = /var/lib/dhcpv6/dhcp6c_duid:
00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4
Jan/26/2007 = 09:39:57 link local addr is fe80::250:daff:fe47:8ff9
Jan/26/2007 = 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28
Jan/26/2007 = 09:39:57 found an interface eth0 harware bfdeed25
Jan/26/2007 = 09:39:57 interface eth0 iaid failed to be created  

------_=_NextPart_001_01C7448E.F881BF41-- --===============1249215532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1249215532==-- From ipv6-bounces@ietf.org Tue Jan 30 17:28:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1NE-0002rv-VO; Tue, 30 Jan 2007 17:22:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1ND-0002rp-Iz for ipv6@ietf.org; Tue, 30 Jan 2007 17:22:43 -0500 Received: from massilia.int-evry.fr ([157.159.10.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC1NC-0006W0-5q for ipv6@ietf.org; Tue, 30 Jan 2007 17:22:43 -0500 Received: from massilia.int-evry.fr (localhost.localdomain [127.0.0.1]) by massilia.int-evry.fr (8.12.11/8.12.11) with ESMTP id l0UMMcmo020978; Tue, 30 Jan 2007 23:22:38 +0100 Received: (from apache@localhost) by massilia.int-evry.fr (8.12.11/8.12.11/Submit) id l0UMMchi020977; Tue, 30 Jan 2007 23:22:38 +0100 X-Authentication-Warning: massilia.int-evry.fr: apache set sender to Pars.Mutaf@int-evry.fr using -f Received: from www.passagesaintsebastien.com (www.passagesaintsebastien.com [81.57.101.151]) by imp.int-evry.fr (IMP) with HTTP for ; Tue, 30 Jan 2007 23:22:37 +0100 Message-ID: <1170195757.45bfc52de120e@imp.int-evry.fr> Date: Tue, 30 Jan 2007 23:22:37 +0100 From: Pars MUTAF To: Pars MUTAF References: <1168423598.15925.24.camel@lor-maknavic3.int-evry.fr> <45AA0D9D.4080705@piuha.net> <1168800701.45aa7bbdc4fdb@imp.int-evry.fr> In-Reply-To: <1168800701.45aa7bbdc4fdb@imp.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 81.57.101.151 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: namedroppers@ops.ietf.org, ipv6@ietf.org Subject: Re: multicast DNS without multicast (in IPv6 only) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Selon Pars MUTAF : > Firstly, the multicast name resolution idea that started > with ZEROCONF (if I'm correct), has the potential to find > many new and popular applications. Dear AD, chairs, folks; I would like to bring a new problem statement draft to your attention (1 page). Until it appears in the I-D rep, please find it here: http://www.freewebs.com/pmutaf/draft-mutaf-piqproblem-00.txt I believe that not having this application would be very unfortunate. (I think this is an INT area topic.) And currently available name resolution techniques do not address this problem as they should. Do you have any comments on this problem statement? Thanks. pars mutaf ps: sorry I kept the IPv6 WG CCed, but it looked like a good idea because I was forwarded to namedroppers by IPv6 folks. I wanted to keep them informed. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 31 05:24:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCXe-0007ZA-G9; Wed, 31 Jan 2007 05:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCXc-0007Yv-BS for ipv6@ietf.org; Wed, 31 Jan 2007 05:18:12 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCCXb-0005X4-1c for ipv6@ietf.org; Wed, 31 Jan 2007 05:18:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1170238690!19976954!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 27767 invoked from network); 31 Jan 2007 10:18:10 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-119.messagelabs.com with SMTP; 31 Jan 2007 10:18:10 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0VAI9bW027136; Wed, 31 Jan 2007 03:18:09 -0700 (MST) Received: from [10.161.194.21] (ZFR01-2117.ea.mot.com [10.161.194.21]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0VAI7vA001528; Wed, 31 Jan 2007 04:18:08 -0600 (CST) Message-ID: <45C06CDE.6070205@motorola.com> Date: Wed, 31 Jan 2007 11:18:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: zze-FENG Zhimin RD-CORE-CAE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ipv6@ietf.org Subject: Re: TR: a problem about dhcpv6 using 'dhcp-0.10.tgz' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Zhimin, this is a very well formulated question but not posted to the right place. I would post this first to the mailing list dedicated to the software you're using dhcp-0.10.tgz. What is the name of this soft? Where did you take it from (download, a colleague, part of linux distribution?). Or write mail to software author and indicate it's spelled 'hardware' nor 'harware' - s/he'll be glad to correct. Then I'd post to users@ipv6.org, then to KAME or USAGI distribution lists. And only then I would post it _maybe_ to the DHC WG mailing list (but not the IPv6 WG mailing list). Finally, maybe you need to put the interface up before starting dhcp, or make sure you're root, or maybe stop the ongoing ethereal, and make sure client and server can ping6 each other, etc. Alex zze-FENG Zhimin RD-CORE-CAE wrote: > > > Dear Sir or Madame, > I am an intern of France Telecom R&D . I am trying to setup a DHCPv6 > server-client system using the 'dhcp-0.10.tgz'. The server end is ok , > however , I meet a problem : in the DHCPv6 client , where I always get a > error message :* ' interface eth0 iaid failed to be created' .* And I do > not know how to resolve it. Can you give me an advice? > > Thank you very much! > I am looking forward to your reply! > Yours sincerely, > > Zhimin FENG > > And there are these configurations in my computers : > > In the HDCPv6 server : > /etc/ dhcp6s.conf > interface eth0 { > server-preference 255; > renew-time 60; > rebind-time 90; > prefer-life-time 130; > valid-life-time 160; > allow rapid-commit; > link BBB { > pool { > prefix 2001:1234:100::/48; > }; > }; > }; > > > And the terminal : > [root@localhost ~]# dhcp6s -dDf eth0 > Jan/26/2007 09:43:59 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6s_duid: 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd > > Jan/26/2007 09:43:59 set timer for syncing file ... > Jan/26/2007 09:43:59 interface definition for eth0 is ok > > In the DHCPv6 Clinet : > > Dhcp6c.conf > > interface eth0 { > # information-only; > send rapid-commit; > request prefix-delegation; > # request temp-address; > }; > > > In the terminal : > [root@localhost dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0 > > Jan/26/2007 09:39:57 <3>[interface] (9) > Jan/26/2007 09:39:57 <5>[eth0] (4) > Jan/26/2007 09:39:57 <3>begin of closure [{] (1) > Jan/26/2007 09:39:57 <3>comment [# information-only;] (19) > Jan/26/2007 09:39:57 <3>[send] (4) > Jan/26/2007 09:39:57 <3>[rapid-commit] (12) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>[request] (7) > Jan/26/2007 09:39:57 <3>[prefix-delegation] (17) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>comment [# request temp-address;] (23) > Jan/26/2007 09:39:57 <3>end of closure [}] (1) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6c_duid: > 00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4 > Jan/26/2007 09:39:57 link local addr is fe80::250:daff:fe47:8ff9 > Jan/26/2007 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28 > Jan/26/2007 09:39:57 found an interface eth0 harware bfdeed25 > Jan/26/2007 09:39:57 interface eth0 iaid failed to be created > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 31 14:46:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLJd-0007Dq-2y; Wed, 31 Jan 2007 14:40:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvwc-0001R3-8z; Tue, 30 Jan 2007 11:34:54 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvwa-0003jj-Kc; Tue, 30 Jan 2007 11:34:54 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:34:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 17:34:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a problem about dhcpv6 using 'dhcp-0.10.tgz' Thread-Index: AcdBL/9ue0+ntLI1TkmlONFpcDjSrgDXGDaw From: "zze-FENG Zhimin RD-CORE-CAE" To: X-OriginalArrivalTime: 30 Jan 2007 16:34:48.0098 (UTC) FILETIME=[8E8BB820:01C7448C] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d X-Mailman-Approved-At: Wed, 31 Jan 2007 14:40:19 -0500 Cc: dhcwg@ietf.org Subject: TR: a problem about dhcpv6 using 'dhcp-0.10.tgz' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2138007222==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============2138007222== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7448C.8DDB235A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448C.8DDB235A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Dear Sir or Madame, > I am an intern of France Telecom R&D . I am trying to setup a DHCPv6 > server-client system using the 'dhcp-0.10.tgz'. The server end is ok > , however , I meet a problem : in the DHCPv6 client , where I always > get a error message : ' interface eth0 iaid failed to be created' . > And I do not know how to resolve it. Can you give me an advice? > Thank you very much!=20 > I am looking forward to your reply!=20 > Yours sincerely, > =20 > Zhimin FENG=20 >=20 > And there are these configurations in my computers :=20 >=20 > In the HDCPv6 server :=20 > /etc/ dhcp6s.conf=20 > interface eth0 { > server-preference 255; > renew-time 60; > rebind-time 90; > prefer-life-time 130; > valid-life-time 160; > allow rapid-commit; > link BBB { > pool { > prefix 2001:1234:100::/48; > }; > }; > }; > =09 >=20 > And the terminal :=20 > [root@localhost ~]# dhcp6s -dDf eth0 > Jan/26/2007 09:43:59 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6s_duid: 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd > Jan/26/2007 09:43:59 set timer for syncing file ... > Jan/26/2007 09:43:59 interface definition for eth0 is ok=09 >=20 >=20 > In the DHCPv6 Clinet : >=20 > Dhcp6c.conf=20 >=20 > interface eth0 { > # information-only; > send rapid-commit; > request prefix-delegation; > # request temp-address; > }; > =09 >=20 > In the terminal : > [root@localhost dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0 >=20 > Jan/26/2007 09:39:57 <3>[interface] (9) > Jan/26/2007 09:39:57 <5>[eth0] (4) > Jan/26/2007 09:39:57 <3>begin of closure [{] (1) > Jan/26/2007 09:39:57 <3>comment [# information-only;] (19) > Jan/26/2007 09:39:57 <3>[send] (4) > Jan/26/2007 09:39:57 <3>[rapid-commit] (12) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>[request] (7) > Jan/26/2007 09:39:57 <3>[prefix-delegation] (17) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>comment [# request temp-address;] (23) > Jan/26/2007 09:39:57 <3>end of closure [}] (1) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6c_duid: > 00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4 > Jan/26/2007 09:39:57 link local addr is fe80::250:daff:fe47:8ff9 > Jan/26/2007 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28 > Jan/26/2007 09:39:57 found an interface eth0 harware bfdeed25 > Jan/26/2007 09:39:57 interface eth0 iaid failed to be created=09 >=20 >=20 ------_=_NextPart_001_01C7448C.8DDB235A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable TR: a problem about dhcpv6 using 'dhcp-0.10.tgz'

Dear Sir or = Madame,
I am an intern = of France Telecom R&D . I am trying to setup  a DHCPv6 = server-client system using the 'dhcp-0.10.tgz'.  The server end is = ok , however , I meet a problem : in the DHCPv6 client , where I always = get a error message : ' interface eth0 iaid failed to be created' = . And I do not know how to resolve it. Can you give me an = advice?

Thank you very = much!
I am looking = forward to your reply!
Yours = sincerely,
 
Zhimin FENG =

And there are = these configurations  in my  computers :

In the HDCPv6 = server :
/etc/ = dhcp6s.conf
interface eth0 = {
      server-preference = 255;
     renew-time 60;
     rebind-time 90;
    prefer-life-time 130;
    valid-life-time 160;
    allow rapid-commit;
   = link BBB {
       pool {
           = prefix 2001:1234:100::/48;
       };
          = };
};
       
And  the = terminal :
[root@localhost = ~]# dhcp6s -dDf eth0
Jan/26/2007 = 09:43:59 extracted an existing DUID from /var/lib/dhcpv6/dhcp6s_duid: = 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd

Jan/26/2007 = 09:43:59 set timer for syncing file ...
Jan/26/2007 = 09:43:59 interface definition for eth0 is = ok       

In the DHCPv6 = Clinet :

Dhcp6c.conf =

interface eth0 = {
#       = information-only;
           send = rapid-commit;
        = request prefix-delegation;
#       request = temp-address;
};
       
In the terminal = :
[root@localhost = dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0

Jan/26/2007 = 09:39:57 <3>[interface] (9)
Jan/26/2007 = 09:39:57 <5>[eth0] (4)
Jan/26/2007 = 09:39:57 <3>begin of closure [{] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      = information-only;] (19)
Jan/26/2007 = 09:39:57 <3>[send] (4)
Jan/26/2007 = 09:39:57 <3>[rapid-commit] (12)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>[request] (7)
Jan/26/2007 = 09:39:57 <3>[prefix-delegation] (17)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      request = temp-address;] (23)
Jan/26/2007 = 09:39:57 <3>end of closure [}] (1)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 extracted an existing DUID from = /var/lib/dhcpv6/dhcp6c_duid:
00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4
Jan/26/2007 = 09:39:57 link local addr is fe80::250:daff:fe47:8ff9
Jan/26/2007 = 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28
Jan/26/2007 = 09:39:57 found an interface eth0 harware bfdeed25
Jan/26/2007 = 09:39:57 interface eth0 iaid failed to be created  

------_=_NextPart_001_01C7448C.8DDB235A-- --===============2138007222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2138007222==--