From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 02 16:45:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx8od-0002r6-5N for dna-archive@lists.ietf.org; Sun, 02 Jul 2006 16:45:15 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx8ob-0001V3-4H for dna-archive@lists.ietf.org; Sun, 02 Jul 2006 16:45:15 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4CD5IGYW68YA0SY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 06:45:04 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C226480003; Mon, 03 Jul 2006 06:45:02 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7778B3C006; Mon, 03 Jul 2006 06:45:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k62Kcbd24062 for dna-list; Mon, 03 Jul 2006 06:38:37 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k62Kcau24056 for ; Mon, 03 Jul 2006 06:38:36 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4CCX73MG08XGVKE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 03 Jul 2006 06:38:21 +1000 Received: by localhost (Postfix, from userid 510) id B74AF80002; Mon, 03 Jul 2006 06:38:20 +1000 (EST) Received: from bay0-omc2-s17.bay0.hotmail.com (bay0-omc2-s17.bay0.hotmail.com [65.54.246.153]) by larry.its.monash.edu.au (Postfix) with ESMTP id BC7D73C006 for ; Mon, 03 Jul 2006 06:38:19 +1000 (EST) Received: from hotmail.com ([65.54.161.38]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 02 Jul 2006 13:38:17 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 02 Jul 2006 13:38:17 -0700 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 02 Jul 2006 20:38:12 +0000 (GMT) Date: Sun, 02 Jul 2006 13:38:12 -0700 From: Bernard Aboba Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt In-reply-to: <44A5C3FE.8070301@research.panasonic.com> X-Originating-IP: [24.16.73.85] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: gregd@research.panasonic.com Cc: dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 02 Jul 2006 20:38:17.0421 (UTC) FILETIME=[72CE7FD0:01C69E17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 > Where it is not known that forwarding operations are available, a > host needs to assume that STP is being performed, and may indicate > full connectivity only based on timeouts or reception of BPDUs. RSTP is now the default on new switches, so this paragraph introduces a delay even in situations where it is not necessary. In practice, DNA should be able to handle the situation of a non-ready port by retransmitting (at least this is what DNAv4 would do). >X The host may send link up indications as soon as the link is viable >X for packet transfer, although all such all indications sent until >X forwarding confirmation MUST contain the R-flag set to indicate risk >X of loss. Does the DNAv6 specification state what to do on receipt of the 'R-flag' (e.g. reset timers)? DNAv4 would just treat it as another "Link Up" indication and reset the timers (causing another reachability test to be sent). >X Where possible, hosts SHOULD monitor for Bridge PDUs, in order to >X determine what type of spanning tree may be running on the network. In practice, this would require hosts to implement passive RSTP/STP in order to provide a fully compliant DNA implementation. I'd question whether any implementations are likely to do this. DNAv4 implementations certainly will not do this (since DNAv4 is link layer agnostic). > If a BPDU is received, and the adjacent bridge is running the > original Spanning Tree Protocol, then a host cannot successfully send > packets until at least twice the ForwardDelay value in the received > BPDU has elapsed. After this time, a link up notification MUST be > generated. The host may not be capable of receiving packets until it has fully booted, so that it may have difficulty estimating when twice the ForwardDelay period has elapsed. Forcing a mandatory waiting period therefore may not be possible or even desirable. DNAv4 implementations will not implement this delay. >OK. I don't see why it can't use those hints, but we can modify the text >to. > > Due to the protocol's newness and lack of deployment, it is unclear > how this protocol will eventually affect DNA, particularly in IPv6 > networks. DNAv4 does not utilize any link layer hints other than 'Link Up'. It does not do so because it is faster and more general to try all operable addresses instead. Therefore DNAv4 implementations will not utilize 802.1AB (or RSTP/STP for that matter). The proposed text still seems vague about this. From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 02 20:28:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxCIq-0003ud-1U for dna-archive@lists.ietf.org; Sun, 02 Jul 2006 20:28:40 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxCIo-0008Aw-Ti for dna-archive@lists.ietf.org; Sun, 02 Jul 2006 20:28:40 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4CKXXQDAQ8WXB26@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 10:28:05 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4069580005; Mon, 03 Jul 2006 10:28:00 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 061B83C005; Mon, 03 Jul 2006 10:28:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k630OWo26197 for dna-list; Mon, 03 Jul 2006 10:24:32 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k630OWu26193 for ; Mon, 03 Jul 2006 10:24:32 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4CKTE7KFA8XGUXO@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 03 Jul 2006 10:24:25 +1000 Received: by localhost (Postfix, from userid 510) id A108DAB544; Mon, 03 Jul 2006 10:24:22 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 400E74FB04 for ; Mon, 03 Jul 2006 10:24:21 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k630OLus016286; Sun, 02 Jul 2006 20:24:21 -0400 Received: from [150.169.1.225] ([150.169.1.225]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGP56621; Sun, 02 Jul 2006 20:22:14 -0400 (EDT) Date: Sun, 02 Jul 2006 20:24:18 -0400 From: Greg Daley Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr, Alper Yegin Message-id: <44A863B2.1070304@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Hi Bernard, Bernard Aboba wrote: >> Where it is not known that forwarding operations are available, a >> host needs to assume that STP is being performed, and may indicate >> full connectivity only based on timeouts or reception of BPDUs. > > RSTP is now the default on new switches, so this paragraph introduces a > delay even in situations where it is not necessary. In practice, DNA > should be able to handle the situation of a non-ready port by > retransmitting (at least this is what DNAv4 would do). I apologize. I didn't fix that text. Where it is not known that forwarding operations are available, a host needs to assume that RSTP or STP is being performed, and may indicate full connectivity only based on timeouts or reception of BPDUs. >> X The host may send link up indications as soon as the link is viable >> X for packet transfer, although all such all indications sent until >> X forwarding confirmation MUST contain the R-flag set to indicate risk >> X of loss. > > Does the DNAv6 specification state what to do on receipt of the 'R-flag' > (e.g. reset timers)? DNAv4 would just treat it as another "Link Up" > indication and reset the timers (causing another reachability test to be > sent). DNAv6 will reset timers based on indications, as described in RFC2461bis. The R-flag isn't necessarily being used, but the information that a prior indication may have been false can probably be fed into hysteresis algorithms. As you know, hysteresis algorithms are not typically not standardized in IETF, unless there is a particular reason, which affects the network, or interoperability. >> X Where possible, hosts SHOULD monitor for Bridge PDUs, in order to >> X determine what type of spanning tree may be running on the network. > > In practice, this would require hosts to implement passive RSTP/STP in > order to provide a fully compliant DNA implementation. I'd question > whether any implementations are likely to do this. DNAv4 > implementations certainly will not do this (since DNAv4 is link layer > agnostic). We don't want to even suggest that DNA can't be implemented without spanning tree knowledge. It is beneficial in this case though, so we should probably change it to a MAY. I'd contend that this has nothing to do with DNA (v4 or v6) at all, though. It's the Link-layer's responsibility to provide hints. We're not talking about DNA function. It just receives one or more hints from the link-layer. DNAv4 or v6 remains link-layer agnostic, since it's not interpreting individual link-layers' events, and is being given only the abstract "Transition to availability", regardless of whether the link-layer monitored spanning tree, or auto-negotiation. To suggest that either v4 or v6 hosts will not be interested in this, is near-sighted, IMO. >> If a BPDU is received, and the adjacent bridge is running the >> original Spanning Tree Protocol, then a host cannot successfully send >> packets until at least twice the ForwardDelay value in the received >> BPDU has elapsed. After this time, a link up notification MUST be >> generated. > > The host may not be capable of receiving packets until it has fully > booted, so that it may have difficulty estimating when twice the > ForwardDelay period has elapsed. Forcing a mandatory waiting period > therefore may not be possible or even desirable. DNAv4 implementations > will not implement this delay. Estimation's not so hard as you indicate. We're not talking about boot anyway, DNA is not for boot, it's for change detection. Forward Delay is listed in the parameters of the BPDU. If you don't delay, there will be no packet forwarding, on any STP port. The link indication is wasted, and timers for retransmission in the network layer will be invoked as the first packets are dropped. Indeed, we're suggesting _two_ indications. One on attachment, and one on STP completion (And RSTP as indicated in other paragraphs). This means that at the earliest possible time, the host is informed of the availability of the link. If the prior indication is erroneous, and DNA(?) packets may have been lost, it gets another shot because of the additional indication. >> OK. I don't see why it can't use those hints, but we can modify the >> text to. >> >> Due to the protocol's newness and lack of deployment, it is unclear >> how this protocol will eventually affect DNA, particularly in IPv6 >> networks. > > DNAv4 does not utilize any link layer hints other than 'Link Up'. It > does not do so because it is faster and more general to try all operable > addresses instead. Therefore DNAv4 implementations will not utilize > 802.1AB (or RSTP/STP for that matter). The proposed text still seems > vague about this. Events generated due to 802.11AB and RSTP/STP completion _are_ Link Up indications. They just are generated on other events than completion of autonegotiation. It's not actually more efficient to try all addresses in DNAv4 in the case you mention, if any spanning tree calculation (Rapid or not) as NONE of the addresses is operable and will respond to probing. These additional link hints are exactly to reset the timers as you indicated (as mentioned about RFC2461bis above). Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 02 21:08:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxCuv-00085M-6h for dna-archive@lists.ietf.org; Sun, 02 Jul 2006 21:08:01 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxCus-0003oq-Nj for dna-archive@lists.ietf.org; Sun, 02 Jul 2006 21:08:01 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4CMBTWAIO8YKFBC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 11:07:38 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DD078AB543; Mon, 03 Jul 2006 11:07:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 91E154FB02; Mon, 03 Jul 2006 11:07:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6314EO26618 for dna-list; Mon, 03 Jul 2006 11:04:14 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6314Eu26614 for ; Mon, 03 Jul 2006 11:04:14 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4CM7EYPQA8XH5D4@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 03 Jul 2006 11:04:02 +1000 Received: by localhost (Postfix, from userid 510) id 17514AB544; Mon, 03 Jul 2006 11:04:02 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2BB464FB07 for ; Mon, 03 Jul 2006 11:04:00 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k63142be016960; Sun, 02 Jul 2006 21:04:02 -0400 Received: from [150.169.1.225] ([150.169.1.225]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGP57723; Sun, 02 Jul 2006 21:01:54 -0400 (EDT) Date: Sun, 02 Jul 2006 21:03:59 -0400 From: Greg Daley Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt In-reply-to: <44A863B2.1070304@research.panasonic.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Bernard Aboba , dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr, Alper Yegin Message-id: <44A86CFF.20806@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Junkmail-Status: score=10/57, host=redwood.research.panasonic.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090203.44A86AF9.0009,ss=1,fgs=0, ip=150.169.1.225, so=2006-02-11 11:31:14, dmn=5.2.4/2006-05-04 References: <44A863B2.1070304@research.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Greg Daley wrote: [cut] > As you know, hysteresis algorithms are not typically not > standardized in IETF, unless there is a particular reason, > which affects the network, or interoperability. Please ignore the double negative, the additional not emerged in editing a sentence. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 03 06:42:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxLsw-0003NX-Hr for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 06:42:34 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxLst-0006W4-Hn for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 06:42:34 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4D6E8IFCA8Y9DL4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 20:42:09 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F2E8FAB544; Mon, 03 Jul 2006 20:42:02 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A7D3B4FB02; Mon, 03 Jul 2006 20:42:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k63AcKo32198 for dna-list; Mon, 03 Jul 2006 20:38:20 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k63AcJu32194 for ; Mon, 03 Jul 2006 20:38:19 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4D69A3PFU8XGT9V@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 03 Jul 2006 20:38:04 +1000 Received: by localhost (Postfix, from userid 510) id 4586080002; Mon, 03 Jul 2006 20:38:04 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by larry.its.monash.edu.au (Postfix) with ESMTP id 267BA3C006 for ; Mon, 03 Jul 2006 20:38:03 +1000 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9C7C9898B9; Mon, 03 Jul 2006 13:38:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 515A1898B8; Mon, 03 Jul 2006 13:38:00 +0300 (EEST) Date: Mon, 03 Jul 2006 13:37:56 +0300 From: Jari Arkko Subject: Re: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: <0MKoyl-1FqwH50ag1-0002nr@mrelay.perfora.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: dna@eng.monash.edu.au Message-id: <44A8F384.1060303@piuha.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Virus-Scanned: ClamAV using ClamSMTP References: <0MKoyl-1FqwH50ag1-0002nr@mrelay.perfora.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Alper Yegin wrote: >Jari, all: > >Please see below for the revised text for the security considerations >section. > >Especially the last paragraph. I personally find it useful. But if you >believe it is not useful, or harmful, etc., I don't mind deleting it. > >Suggest deletion/modification/etc as you see appropriate. > It does make a MUST requirement without specifying in detail what needs to be done to satisfy it (e.g. specific mechanisms). I do not personally worry too much about it, but it may raise a few eyebrows in the rest of the IESG. And I don't see a lot of use for the statement in any case, so my recommendation would be to just delete it. I'm not forcing you to do that as a part of my AD review, however. --Jari > >4. Security Considerations > >Attackers may spoof various indications at the link-layer, or >manipulate the physical medium directly in an effort to confuse the >host about the state of the link-layer. For instance, attackers may >spoof error messages or disturb the wireless medium to cause the host >to move its connection elsewhere or to even disconnect. Attackers may >also spoof information to make the host believe it has a connection >when, in reality, it does not. > >These attacks may cause use of non-preferred networks or even >denial-of-service. > >This specification does not provide any protection of its own for the >the indications from the lower layers. But the vulnerabilities >can be mitigated through the use of techniques in other >parts of the protocol stack. In particular, it is RECOMMENDED >that authentication, replay and integrity protection of link-layer >management messages is enabled when available. Additionally, protocol stack >may also use some upper layer mechanisms to achieve partial protection >against situations where incorrect event notifications are generated (e.g., >upper-layer confirmation of the link-layer event). > >When the link-layer and the network-layer reside on separate nodes as in a >distributed stack implementation, the event notifications MUST be >authenticated, replay and integrity protected as they are delivered. The >specific mechanisms to achieve the security of notifications are outside the >scope of this document. > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 03 07:21:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxMU9-00012t-Bm for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 07:21:01 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxMU7-0001fI-Jt for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 07:21:01 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4D7PJ69D08XGDLF@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 21:20:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DA69680003; Mon, 03 Jul 2006 21:20:10 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 869763C004; Mon, 03 Jul 2006 21:20:10 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k63BHIl32615 for dna-list; Mon, 03 Jul 2006 21:17:18 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k63BHIu32609 for ; Mon, 03 Jul 2006 21:17:18 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4D7LVYHUI8YA3WG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 03 Jul 2006 21:17:16 +1000 Received: by localhost (Postfix, from userid 510) id C741DAB542; Mon, 03 Jul 2006 21:17:16 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by curly.its.monash.edu.au (Postfix) with ESMTP id AF1094FB03 for ; Mon, 03 Jul 2006 21:17:15 +1000 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F0225898B9; Mon, 03 Jul 2006 14:17:12 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B8946898B8; Mon, 03 Jul 2006 14:17:12 +0300 (EEST) Date: Mon, 03 Jul 2006 14:17:09 +0300 From: Jari Arkko Subject: Re: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: <0MKp2t-1FrLON1cmc-0003cA@mrelay.perfora.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: 'Bernard Aboba' , dna@eng.monash.edu.au Message-id: <44A8FCB5.1090008@piuha.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Virus-Scanned: ClamAV using ClamSMTP References: <0MKp2t-1FrLON1cmc-0003cA@mrelay.perfora.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Alper Yegin wrote: >>>Additionally, protocol stack >>>may also use some upper layer mechanisms to achieve partial protection >>>against situations where incorrect event notifications are generated >>> >>> >>(e.g., >> >> >>>upper-layer confirmation of the link-layer event). >>> >>> >>Are you referring to DNA itself here? (e.g. use of SEND) >> >> > >I know the above text is vague. If we try to make it more concrete by giving >examples, I'm afraid we need to further expand on it as it is not straight >forward how one can use SEND, etc. to achieve that added protection. > >If we cannot capture a solid solution (even as an example) without >generating more questions than we answer, I'm inclined to delete the above >paragraph as it may not help in this form. > > How about this: "Additionally, the protocol stack may also use some network layer mechanisms to achieve partial protection. For instance, SEND [RFC 3971] could be used to confirm secure reachability with a router. However, network layer mechanisms are unable to deal with all problems, such as with insecure lower layer notifications that lead to the link not functioning properly. --Jari From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 03 17:20:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVqL-00047h-Ip for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 17:20:33 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxVqI-0005ww-O1 for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 17:20:33 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4DSOATSO48WXCX9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 04 Jul 2006 07:20:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 88EC580003; Tue, 04 Jul 2006 07:20:05 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4A6453C008; Tue, 04 Jul 2006 07:20:05 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k63LDEV06018 for dna-list; Tue, 04 Jul 2006 07:13:14 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k63LDCu06014 for ; Tue, 04 Jul 2006 07:13:12 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4DSFCSQ128YABO3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 04 Jul 2006 07:12:57 +1000 Received: by localhost (Postfix, from userid 510) id B1C7EAB542; Tue, 04 Jul 2006 07:12:57 +1000 (EST) Received: from bay0-omc1-s11.bay0.hotmail.com (bay0-omc1-s11.bay0.hotmail.com [65.54.246.83]) by curly.its.monash.edu.au (Postfix) with ESMTP id 86D5C4FB04 for ; Tue, 04 Jul 2006 07:12:56 +1000 (EST) Received: from hotmail.com ([65.54.161.22]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 03 Jul 2006 14:12:53 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 03 Jul 2006 14:12:53 -0700 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 03 Jul 2006 21:12:50 +0000 (GMT) Date: Mon, 03 Jul 2006 14:12:50 -0700 From: Bernard Aboba Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt In-reply-to: <44A863B2.1070304@research.panasonic.com> X-Originating-IP: [131.107.0.87] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: gregd@research.panasonic.com Cc: dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr, alper.yegin@yegin.org, narten@us.ibm.com Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 03 Jul 2006 21:12:53.0842 (UTC) FILETIME=[72DCF320:01C69EE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe >The R-flag isn't necessarily being used, but the information >that a prior indication may have been false can probably be >fed into hysteresis algorithms. If the DNAv6 specification doesn't use the 'R-flag' then I'm not clear why it has to be defined here. >We don't want to even suggest that DNA can't be implemented without >spanning tree knowledge. It is beneficial in this case though, so >we should probably change it to a MAY. That makes sense. >I'd contend that this has nothing to do with DNA (v4 or v6) at all, though. I'd agree that this doesn't have anything to do with DNA. >To suggest that either v4 or v6 hosts will not be interested in this, is >near-sighted, IMO. The DNAv4 specification depends only on "Link Up". On receipt of a "Link Up" event, the DNAv4 reachability tests will be carried out, and timers will be reset. However DNAv4 is rate limited so that "jittery" links will not result in packet storms (maximum of one DNAv4 reachability test/second). So if the "Link Up" events occur more closely spaced than this they will be delayed. Overall, there is no special processing that will occur due to the 'R' bit, since there is no backoff or other state created by the false indication, other than the dampening. >Estimation's not so hard as you indicate. We're not talking >about boot anyway, DNA is not for boot, it's for change detection. DNAv4 is applicable both to boot/resume from sleep as well as movement between networks. If operational addresses are saved in stable storage, they are tested like any other address when the host reboots or resumes from sleep. This can have a major impact on boot time reduction (several seconds) so that DNAv4 boot integration is expected to be fairly popular. >This means that at the earliest possible time, the host is informed >of the availability of the link. If the prior indication is erroneous, and >DNA(?) packets may have been lost, it gets another shot because of the >additional indication. The issue with multiple indications is that this causes twice as many packets to be sent. This is particularly problematic if the link is jittery and hosts do not implement dampening, since packet storms can result. >Events generated due to 802.1AB and RSTP/STP completion _are_ Link Up >indications. They just are generated on other events than completion of >autonegotiation. IEEE 802.1AB packets can only be sent *after* a link is already usable by IP traffic. For example, .1AB traffic occurs after completion of IEEE 802.1X, IEEE 802.11i 4-way handshake, etc. So .1AB packets are not indicative of "Link Up", except in the unauthenticated wired case, where receipt of the packets might be taken as an indication that the link is up, short circuiting an RSTP/STP timer. >NONE of the addresses is operable and will respond to probing. In that case, DNAv4 will reset when the second "Link Up" is sent. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 03 20:38:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYwI-00074t-5v for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 20:38:54 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYwF-0008QY-UM for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 20:38:54 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4DZJSXIBY8XGSFK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 04 Jul 2006 10:37:36 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 57372AB543; Tue, 04 Jul 2006 10:37:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0E22D4FB02; Tue, 04 Jul 2006 10:37:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k640XxV08002 for dna-list; Tue, 04 Jul 2006 10:33:59 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k640Xwu07998 for ; Tue, 04 Jul 2006 10:33:58 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4DZFBMOGO8WXBX1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 04 Jul 2006 10:33:41 +1000 Received: by localhost (Postfix, from userid 510) id B097580002; Tue, 04 Jul 2006 10:33:40 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by larry.its.monash.edu.au (Postfix) with ESMTP id A05E53C004 for ; Tue, 04 Jul 2006 10:33:37 +1000 (EST) Received: from [68.126.193.27] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FxYr61ZJZ-0003P9; Mon, 03 Jul 2006 20:33:35 -0400 Date: Mon, 03 Jul 2006 17:33:27 -0700 From: Alper Yegin Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: <44A8F384.1060303@piuha.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: 'Jari Arkko' Cc: dna@eng.monash.edu.au Message-id: <0MKp2t-1FxYr61ZJZ-0003P9@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaejMJbZIQuKh1HRy6gRqHy5lrcyAAdJZog X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Jari, OK, I'll follow your recommendation unless someone else has any issues with it. Alper > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, July 03, 2006 3:38 AM > To: Alper Yegin > Cc: dna@eng.monash.edu.au > Subject: Re: [DNA] RE: draft-ietf-dna-link-information-03 > > Alper Yegin wrote: > > >Jari, all: > > > >Please see below for the revised text for the security considerations > >section. > > > >Especially the last paragraph. I personally find it useful. But if you > >believe it is not useful, or harmful, etc., I don't mind deleting it. > > > >Suggest deletion/modification/etc as you see appropriate. > > > It does make a MUST requirement without specifying in detail what needs > to be done to satisfy it (e.g. specific mechanisms). > > I do not personally worry too much about it, but it may raise a few > eyebrows > in the rest of the IESG. And I don't see a lot of use for the statement > in any > case, so my recommendation would be to just delete it. I'm not forcing you > to do that as a part of my AD review, however. > > --Jari > > > > >4. Security Considerations > > > >Attackers may spoof various indications at the link-layer, or > >manipulate the physical medium directly in an effort to confuse the > >host about the state of the link-layer. For instance, attackers may > >spoof error messages or disturb the wireless medium to cause the host > >to move its connection elsewhere or to even disconnect. Attackers may > >also spoof information to make the host believe it has a connection > >when, in reality, it does not. > > > >These attacks may cause use of non-preferred networks or even > >denial-of-service. > > > >This specification does not provide any protection of its own for the > >the indications from the lower layers. But the vulnerabilities > >can be mitigated through the use of techniques in other > >parts of the protocol stack. In particular, it is RECOMMENDED > >that authentication, replay and integrity protection of link-layer > >management messages is enabled when available. Additionally, protocol > stack > >may also use some upper layer mechanisms to achieve partial protection > >against situations where incorrect event notifications are generated > (e.g., > >upper-layer confirmation of the link-layer event). > > > >When the link-layer and the network-layer reside on separate nodes as in > a > >distributed stack implementation, the event notifications MUST be > >authenticated, replay and integrity protected as they are delivered. The > >specific mechanisms to achieve the security of notifications are outside > the > >scope of this document. > > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 03 20:42:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxZ0C-0000Tj-FH for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 20:42:56 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxZ0A-0000DV-P0 for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 20:42:56 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4DZL1QIG08Y9Z17@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 04 Jul 2006 10:38:23 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4F138AB545; Tue, 04 Jul 2006 10:38:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0C76B4FB10; Tue, 04 Jul 2006 10:38:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k640ZfT08024 for dna-list; Tue, 04 Jul 2006 10:35:41 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k640Zfu08020 for ; Tue, 04 Jul 2006 10:35:41 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4DZHI5FU88XGSFK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 04 Jul 2006 10:35:28 +1000 Received: by localhost (Postfix, from userid 510) id 98DC0AB544; Tue, 04 Jul 2006 10:35:27 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by moe.its.monash.edu.au (Postfix) with ESMTP id D26134FB04 for ; Tue, 04 Jul 2006 10:35:26 +1000 (EST) Received: from [68.126.193.27] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FxYsm1QST-0003Ky; Mon, 03 Jul 2006 20:35:23 -0400 Date: Mon, 03 Jul 2006 17:35:11 -0700 From: Alper Yegin Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: <44A8FCB5.1090008@piuha.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: 'Jari Arkko' Cc: 'Bernard Aboba' , dna@eng.monash.edu.au Message-id: <0MKp2t-1FxYsm1QST-0003Ky@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaekjxBzIsQ6+1PRQaq+gAiqY/kugAb2HQA X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > How about this: "Additionally, the protocol stack may also use some > network > layer mechanisms to achieve partial protection. For instance, SEND [RFC > 3971] > could be used to confirm secure reachability with a router. However, > network > layer mechanisms are unable to deal with all problems, such as with > insecure > lower layer notifications that lead to the link not functioning properly. Unless I hear from anyone else, I'll directly incorporate that text. Thanks Jari. Alper From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 03 21:10:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxZQp-00081W-T6 for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 21:10:27 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxZQo-0002DT-2D for dna-archive@lists.ietf.org; Mon, 03 Jul 2006 21:10:27 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4E0PLA3JO8WXBN4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 04 Jul 2006 11:10:16 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BD170AB543; Tue, 04 Jul 2006 11:10:11 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 806C84FB05; Tue, 04 Jul 2006 11:10:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6417Li08392 for dna-list; Tue, 04 Jul 2006 11:07:21 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6417Ku08388 for ; Tue, 04 Jul 2006 11:07:20 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4E0LLZQ8M8WXAUI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 04 Jul 2006 11:07:11 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1C8C8AB543; Tue, 04 Jul 2006 11:07:09 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 020434FB04; Tue, 04 Jul 2006 11:07:09 +1000 (EST) Received: from [150.169.1.225] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 03 Jul 2006 21:07:07 -0400 Date: Mon, 03 Jul 2006 21:07:07 -0400 From: Greg Daley Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: gregd@research.panasonic.com, dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr, alper.yegin@yegin.org, narten@us.ibm.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en References: <44A863B2.1070304@research.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Hi Bernard, ----- Original Message ----- From: Bernard Aboba Date: Monday, July 3, 2006 5:20 pm Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt To: gregd@research.panasonic.com Cc: dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr, alper.yegin@yegin.org, narten@us.ibm.com > >The R-flag isn't necessarily being used, but the information > >that a prior indication may have been false can probably be > >fed into hysteresis algorithms. > > If the DNAv6 specification doesn't use the 'R-flag' then I'm not > clear why it has to be defined here. OK, I see your point more clearly now, as we're taking the same approach with link-down. > >To suggest that either v4 or v6 hosts will not be interested in > > this, is near-sighted, IMO. > > The DNAv4 specification depends only on "Link Up". On receipt > of a "Link Up" event, the DNAv4 reachability tests will be > carried out, and timers will be reset. However DNAv4 is rate > limited so that "jittery" links will not result in packet storms > (maximum of one DNAv4 reachability test/second). So if the > "Link Up" events occur more closely spaced than this they will be > delayed. Overall, there is no special processing that will occur > due to the 'R' bit, since there is no backoff or other state > created by the false indication, other than the dampening. I'd suggest that the special handling would be to ignore the second indication, after receiving the original R-bit, if it were used at all. As you mentioned though, if there's no DNA protocol change, we can leave it out. > >Estimation's not so hard as you indicate. We're not talking > >about boot anyway, DNA is not for boot, it's for change detection. > > DNAv4 is applicable both to boot/resume from sleep as well as > movement between networks. If operational addresses are saved > in stable storage, they are tested like any other address when > the host reboots or resumes from sleep. This can have a major > impact on boot time reduction (several seconds) so that DNAv4 > boot integration is expected to be fairly popular. OK, given this, and the fact that a node may not have processed any STP/RSTP packets because of the boot operations, is it reasonable to send an indication when the process receives the link-up indication only? Or should it also send at a timered indication associated with the type of link (for point-to-point assuming RSTP) or STP (to be sure)? The estimation could be wrong, and so would be conservative in that case (to ensure the medium is forwarding). > >This means that at the earliest possible time, the host is informed > >of the availability of the link. If the prior indication is > >erroneous, and DNA(?) packets may have been lost, it gets another > >shot because of the additional indication. > > The issue with multiple indications is that this causes twice as > many packets to be sent. This is particularly problematic if the > link is jittery and hosts do not implement dampening, since packet > storms can result. Yes. This has been an issue with coaxial ethernet, and on systems with faulty switches/hubs. Simultaneous indications only are prevented in causing storms from the media becoming available, because the ports aren't forwarding though. > >Events generated due to 802.1AB and RSTP/STP completion _are_ Link > >Up indications. They just are generated on other events than > > completion of autonegotiation. > > IEEE 802.1AB packets can only be sent *after* a link is already > usable by IP traffic. For example, .1AB traffic occurs after > completion of IEEE 802.1X, IEEE 802.11i 4-way handshake, etc. > So .1AB packets are not indicative of "Link Up", except in the > unauthenticated wired case, where receipt of the > packets might be taken as an indication that the link is up, short > circuiting an RSTP/STP timer. 802.1AB packets aren't forwarded by switches though, so the impression I got was that they were available before R/STP completed. That's why we put this in the subsection on 802.1D networks. It's not actually useful for this purpose anywhere else. We could append a disclaimer about their applicability only to .1D networks in this case. > >NONE of the addresses is operable and will respond to probing. > > In that case, DNAv4 will reset when the second "Link Up" is sent. So do we need a second Link-Up indication from a timer? Is it sufficient to recommend a small delay variation (+tive) to prevent packet collisions? Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 04 18:25:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtL4-0005Et-Ma for dna-archive@lists.ietf.org; Tue, 04 Jul 2006 18:25:50 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxtL2-0000vj-FL for dna-archive@lists.ietf.org; Tue, 04 Jul 2006 18:25:50 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4F98BS7RC8YIGKO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 05 Jul 2006 08:25:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 712CFAB543; Wed, 05 Jul 2006 08:25:11 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 31F9A4FB06; Wed, 05 Jul 2006 08:25:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k64MKXp21452 for dna-list; Wed, 05 Jul 2006 08:20:33 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k64MKWu21448 for ; Wed, 05 Jul 2006 08:20:32 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4F92972Q08YAB8V@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 05 Jul 2006 08:20:16 +1000 Received: by localhost (Postfix, from userid 510) id 037FFAB543; Wed, 05 Jul 2006 08:20:15 +1000 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by moe.its.monash.edu.au (Postfix) with ESMTP id 265D14FB0B for ; Wed, 05 Jul 2006 08:20:14 +1000 (EST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 151534F0035; Wed, 05 Jul 2006 00:20:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 05 Jul 2006 00:20:10 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 05 Jul 2006 00:20:10 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 04 Jul 2006 17:20:07 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 04 Jul 2006 17:20:07 -0500 Date: Tue, 04 Jul 2006 18:25:50 -0400 From: Suresh Krishnan Subject: [DNA] REVIEWS NEEDED: draft-ietf-dna-network In-reply-to: <44A59A3B.3060409@research.panasonic.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: Greg Daley Reply-to: suresh.krishnan@ericsson.com Message-id: <44AAEAEE.6000801@ericsson.ca> Organization: Ericsson MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Brightmail-Tracker: AAAAAA== References: <44A59A3B.3060409@research.panasonic.com> X-OriginalArrivalTime: 04 Jul 2006 22:20:07.0614 (UTC) FILETIME=[019775E0:01C69FB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Hi Folks, The DNA routers draft (renamed to draft-ietf-dna-network-00) is ready to be last called before being sent to the IESG for publication. Please take some time to read the draft and respond to the mailing list with your reviews. Thanks Suresh & Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 05 09:07:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy75o-0004ta-TU for dna-archive@lists.ietf.org; Wed, 05 Jul 2006 09:07:00 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy75n-0004cW-34 for dna-archive@lists.ietf.org; Wed, 05 Jul 2006 09:07:00 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4G3OQ1RFY8YA7BB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 05 Jul 2006 22:57:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5375FAB543; Wed, 05 Jul 2006 22:57:22 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 164B34FB08; Wed, 05 Jul 2006 22:57:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k65Crfp30551 for dna-list; Wed, 05 Jul 2006 22:53:41 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k65Creu30546 for ; Wed, 05 Jul 2006 22:53:40 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4G3JTC3YO8XH8LB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 05 Jul 2006 22:53:25 +1000 Received: by localhost (Postfix, from userid 510) id 0FE8BAB542; Wed, 05 Jul 2006 22:53:24 +1000 (EST) Received: from mh1.eu.ntt.net (mh1.eu.ntt.net [212.119.0.10]) by moe.its.monash.edu.au (Postfix) with SMTP id 2A1CC4FB07 for ; Wed, 05 Jul 2006 22:53:19 +1000 (EST) Received: (qmail 6251 invoked by uid 2101); Wed, 05 Jul 2006 13:53:17 +0100 Received: from julien.IETF@laposte.net by mh1 by uid 0 with qmail-scanner-1.22st (clamdscan: 0.85.1. spamassassin: 3.0.4. perlscan: 1.22st. Clear:RC:1 (212.119.9.178):. Processed in 0.086246 secs); Wed, 05 Jul 2006 12:53:17 +0000 Received: from unknown (HELO ?192.168.1.117?) (212.119.9.178) by mx1.eu.ntt.net with SMTP; Wed, 05 Jul 2006 13:53:17 +0100 Date: Wed, 05 Jul 2006 14:53:28 +0200 From: Julien Laganier Subject: Re: [DNA] REVIEWS NEEDED: draft-ietf-dna-network In-reply-to: <44AAEAEE.6000801@ericsson.ca> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: suresh.krishnan@ericsson.com, Greg Daley Message-id: <200607051453.28631.julien.IETF@laposte.net> MIME-version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id k65Creu30547 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline User-Agent: KMail/1.8.2 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <44A59A3B.3060409@research.panasonic.com> <44AAEAEE.6000801@ericsson.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d On Wednesday 05 July 2006 00:25, Suresh Krishnan wrote: > Hi Folks, > The DNA routers draft (renamed to draft-ietf-dna-network-00) is > ready to be last called before being sent to the IESG for > publication. Please take some time to read the draft and respond to > the mailing list with your reviews. Folks,=20 I reviewed the draft and I have some comments. Not being a native= =20 English speaker, apologize if some of the editorial suggestions don't= =20 make sense. I thought the draft was in very good shape; Most of my= =20 comments are editorial. I have two suggestions which apply to the entire draft: - The document always refer to hosts, as opposed to routers. I= =20 understand the point, but now that we have NEMO and mobile routers, what about replacing everywhere host by node? that would still maintain a difference between nodes and router which= =20 I assume is what is wanted. - For consistency with RFC2461, I suggest replacing everywhere neighbour with neighbor. Then throughout the draft: =20 > Abstract >=20 > Hosts experiencing rapid link-layer changes may require to do > configuration change detection procedures more frequently than > traditional fixed hosts. This document describes practices = =20 > available to network deployers in order to support such hosts in > Detecting Network Attachment in IPv6 networks. Suggest to rephrase as: Mobile nodes experiencing rapid link-layer changes may have to= =20 detect configuration change more frequently than fixed hosts. = =20 This document describes practices for network deployers to support such nodes in Detecting Network Attachment in IPv6 networks. > 1. Introduction >=20 > Hosts on the Internet may be connected by various media. It has > become common that hosts have access through wireless media and= =20 > are mobile. The frequency of configuration change for wireless > and nomadic devices are elevated, due to the vagaries of wireles= s > propagation or the motion of the hosts themselves. Suggest to rephrase as: Nodes on the Internet are connected by various media. Nowadays it is common that nodes are mobile and access Internet through wireless media. The frequency of configuration changes for wireless and nomadic devices is elevated, due to the vagaries of wireless propagation or the motion of the hosts themselves. > Such hosts need to determine if they have moved to a new IPv6= =20 > link rapidly, in order that configuration procedures may be run > and application packet delivery services restored. Detecting > Network Attachment (DNA) is a strategy to assist such > configuration changes by rapidly determining whether they are > required.=20 Suggest to rephrase as: Such nodes need to quickly determine if they have moved to a new IPv6 link, so that they can start reconfiguration procedures and restore packet delivery to applications. Detecting Network Attachment (DNA) is a strategy to assist such reconfiguration procedures by rapidly determining whether they are required.=20 > > [...] > > It should be noted that many already deployed routers will not > support these recommendations, and that hosts SHOULD NOT rely on > their being in place, unless they have particular reason to do > so.=20 Suggest to rephrase as: It should be noted that many routers already deployed will not support these recommendations. Therefore, nodes SHOULD NOT rely on them being in place unless they have a particular reason to do so. > 1.1 Terms and Abbreviations >=20 > Access network: A network where hosts are present. Especially, = a > network used for the support of visiting wireless hosts. Suggest to rephrase as: Access Network: An IP network which has on its edge one or more routers handling the last hop to mobile nodes, typically but necessarily over a wireless link =20 > Link: A link is the range across which communications can pass > without being forwarded through a router [1]. >=20 > Link-Change: Link-Change occurs when a host moves from a > point-of-attachment on a link, to another point-of-attachment > where it is unable to reach devices belonging to the previous > link, without being forwarded through a router. Why not simply have: Link-Change: Link-Change occurs when a host moves from a point-of-attachment on a given link to another=20 point-of-attachment on a different link. > > [...] > > 2.1 Multicast and Unicast RA Responses > > The dis-advantage in sending unicast RA is that the router will =3D> The disadvantage [...] =20 > not be able to aggregate its response for multiple RS messages =3D> not be able to aggregate its responses to multiple RS messages > from multiple hosts received during the waiting period before RA > transmission. Moreover, using unicast RA to respond to RS > disables routers' ability to limit the rate of unicast RA. > > For multicast Router Advertisements, a minimum separating delay > exists so that these RAs may not be scheduled close to each other= . =3D> exists so that these RAs may not be scheduled too close to each other. > When a host solicits and attempts to schedule a multicast RA =3D> When a host solicits and the router attempts to schedule a multicast RA > within MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile > IPv6 [3]) of the previous multicast Router Advertisement, the > scheduling of a response will be deferred until the minimum > separation expires.=20 > > [...] > > It is noted that computational requirements for SEND may preclude =3D> It is noted that computational requirements of SEND may preclud= e > this subsequent aggregation in some environments. > > [...] > > In some cases it is not possible to provide unicast responses,= =20 > since solicitations may be sent with an unspecified address, or > solicitations do not provide enough link-layer addressing > information to send an unicast response without neighbour=20 > discovery exchange. In these cases, a router may need to send > multicast responses, even if the expected delay is greater. If the RS was sent from an unspecified address, would it be possible= =20 to send a multicast RA to a unicast link-layer address? (Fred L.=20 Templin suggested that to me) =20 > 2.1.1 Recommendations >=20 > Routers SHOULD respond to a RS message with unicast RA=20 > message.=20 >=20 > Routers SHOULD aggregate RA messages into a multi-cast RA= =20 =3D> Routers SHOULD aggregate RA messages into a multicast RA= =20 > message if more than 3 unicast RA messages are queued for > transmission.=20 > > [...]=20 > > 2.2 Router Advertisement Parameters Where hosts often change their link attachment (e.g., because they =3D> Where hosts often change their link of attachment... OR, Where hosts often change their point-of-attachment... > are mobile), there may be a number of prefixes or routers stored > in the host's memory, which are no longer directly reachable.= =20 > This additional storage may make movement detection slower where > hosts rapidly pass through networks, or pass through networks > which have very long advertised timeouts. > > [...] > > 3.1 Link Extent and Composition > > Most of today's access networks deploy link-layer bridging > technologies in order to extend their logical range beyond a =3D> technologies to extend their logical range beyond a > single Medium Access Control domain. > > Consequently, while many routers will come with traditional wired > or optic-fibre interfaces, packets travelling within the same lin= k =3D> or optic fibre interfaces, packets travelling within the same l= ink > may have been bridged across from a wired segment to a wireless > segment.=20 >=20 > [...] >=20 > 3.2 Multiple Router Links =3D> 3.2 Multiple Routers Links OR, 3.2 Links with Multiple Routers > > [...] > > 5.1 Providing Router Authorization > > In DNA, some hosts will begin configuration procedures based on a > single message transmitted by a router. As such the ability of > routing infrastructure to prove its authenticity and authorizatio= n > is important to support correct operation of hosts. Authenticatio= n > and authorization mechanisms exist which allow hosts to check > security of routers when they receive Router Advertisements > indicating link change. The mechanisms mentionned above are SEND, or there are others? If thi= s=20 is SEND only I suggest citing SEND here, by e.g. rephrasing as: In DNA, some hosts will begin configuration procedures based on a single message transmitted by a router. As such the ability of routing infrastructure to prove its authenticity and authorization is important to support correct operation of hosts. Secure Neighbor Discovery (SEND) [4] defines authentication and authorization mechanisms which allow hosts to check security of routers when they receive Router Advertisements indicating link change. > [...] > > Hosts which wish to have secured exchanges with neighbours and on= - > link routers may use Secured Neighbour Discovery (SEND) [4]. SEN= D =3D> link routers may use Secure Neighbour Discovery (SEND) [4]. SE= ND (s/Secured/secure/) > provides authenticity as well as response matching, using nonces > copied from solicitations into advertisements. > > [...] That's it. Best, --julien --=20 -- Dr. Ing. Julien H. Laganier =20 Researcher DoCoMo Communications Laboratories Europe GmbH Landsbergerstrasse 312, 80687 Munchen, Deutschland "So einfach wie m=09glich. Aber nicht einfacher." -- Albert Einstein "La perfection est atteinte non quand il ne reste rien =E0 ajouter,= =20 mais quand il ne reste rien =E0 enlever." -- Antoine de Saint-Exup= =E9ry "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian W. Kernighan From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 10 17:19:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G039l-0007MH-Cg for dna-archive@lists.ietf.org; Mon, 10 Jul 2006 17:19:05 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G039j-00087N-Dw for dna-archive@lists.ietf.org; Mon, 10 Jul 2006 17:19:05 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4NKO5NP508WXM3X@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 11 Jul 2006 07:18:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F3DBD80003; Tue, 11 Jul 2006 07:18:49 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id B485A3C008; Tue, 11 Jul 2006 07:18:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6ALDwv11811 for dna-list; Tue, 11 Jul 2006 07:13:58 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6ALDvu11807 for ; Tue, 11 Jul 2006 07:13:57 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4NKHUUEAM8XIIVA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 11 Jul 2006 07:13:45 +1000 Received: by localhost (Postfix, from userid 510) id 6256EAB542; Tue, 11 Jul 2006 07:13:45 +1000 (EST) Received: from mgw-ext14.nokia.com (mgw-ext14.nokia.com [131.228.20.173]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 140594FB04 for ; Tue, 11 Jul 2006 07:13:43 +1000 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ALDa7i007944; Tue, 11 Jul 2006 00:13:38 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 00:13:36 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 00:13:36 +0300 Date: Tue, 11 Jul 2006 00:13:35 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] REVIEWS NEEDED: draft-ietf-dna-network In-reply-to: <44AAEAEE.6000801@ericsson.ca> Sender: owner-dna@ecselists.eng.monash.edu.au To: suresh.krishnan@ericsson.com, dna@eng.monash.edu.au Cc: gregd@research.panasonic.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] REVIEWS NEEDED: draft-ietf-dna-network Thread-Index: AcafuNcMCcixFqouR4eOruQnvmlG6AErMsNQ Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Jul 2006 21:13:36.0531 (UTC) FILETIME=[B5330630:01C6A465] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Stupid question - did you want a review before a WGLC or during WGLC? John >-----Original Message----- >From: owner-dna@ecselists.eng.monash.edu.au >[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of >ext Suresh Krishnan >Sent: 04 July, 2006 18:26 >To: Dna >Cc: Greg Daley >Subject: [DNA] REVIEWS NEEDED: draft-ietf-dna-network > >Hi Folks, > The DNA routers draft (renamed to >draft-ietf-dna-network-00) is ready to be last called before >being sent to the IESG for publication. Please take some time >to read the draft and respond to the mailing list with your reviews. > >Thanks >Suresh & Greg > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 10 19:26:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G04yj-0002Qk-IZ for dna-archive@lists.ietf.org; Mon, 10 Jul 2006 19:15:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03Ot-0000Uw-RN for dna-archive@lists.ietf.org; Mon, 10 Jul 2006 17:34:43 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G03Ji-0002lG-4u for dna-archive@lists.ietf.org; Mon, 10 Jul 2006 17:29:23 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4NL0B7G2W8WXKXC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 11 Jul 2006 07:28:40 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0649CAB543; Tue, 11 Jul 2006 07:28:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C131F4FB05; Tue, 11 Jul 2006 07:28:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6ALPkT11951 for dna-list; Tue, 11 Jul 2006 07:25:46 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6ALPku11947 for ; Tue, 11 Jul 2006 07:25:46 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4NKWF8LH48YB4UJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 11 Jul 2006 07:25:31 +1000 Received: by localhost (Postfix, from userid 510) id 3656880002; Tue, 11 Jul 2006 07:25:31 +1000 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 428343C00D for ; Tue, 11 Jul 2006 07:25:29 +1000 (EST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id k6ALcq1o020154; Mon, 10 Jul 2006 16:38:52 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:25:25 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:25:24 -0500 Date: Mon, 10 Jul 2006 17:31:15 -0400 (EDT) From: Suresh Krishnan Subject: RE: [DNA] REVIEWS NEEDED: draft-ietf-dna-network In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au X-X-Sender: suresh@localhost.localdomain To: john.loughney@nokia.com Cc: suresh.krishnan@ericsson.com, dna@eng.monash.edu.au, gregd@research.panasonic.com Reply-to: Suresh Krishnan Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: X-OriginalArrivalTime: 10 Jul 2006 21:25:24.0893 (UTC) FILETIME=[5B6A7CD0:01C6A467] X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi John, We would prefer if you could do the reviews before the WGLC, but if you are stuck for time, commenting during the WGLC period would be fine as well. Thanks Suresh & Greg On Tue, 11 Jul 2006, john.loughney@nokia.com wrote: > Stupid question - did you want a review before a WGLC or during WGLC? > > John > >> -----Original Message----- >> From: owner-dna@ecselists.eng.monash.edu.au >> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of >> ext Suresh Krishnan >> Sent: 04 July, 2006 18:26 >> To: Dna >> Cc: Greg Daley >> Subject: [DNA] REVIEWS NEEDED: draft-ietf-dna-network >> >> Hi Folks, >> The DNA routers draft (renamed to >> draft-ietf-dna-network-00) is ready to be last called before >> being sent to the IESG for publication. Please take some time >> to read the draft and respond to the mailing list with your reviews. >> >> Thanks >> Suresh & Greg >> >> >> > From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 12 13:59:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0izO-0000CG-TH for dna-archive@lists.ietf.org; Wed, 12 Jul 2006 13:59:10 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0izL-0003zP-R6 for dna-archive@lists.ietf.org; Wed, 12 Jul 2006 13:59:10 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4Q6A3Q7CK8WXNQ0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 13 Jul 2006 03:59:03 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F10E5AB543; Thu, 13 Jul 2006 03:59:00 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id AD1374FB37; Thu, 13 Jul 2006 03:59:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6CHsRJ05547 for dna-list; Thu, 13 Jul 2006 03:54:27 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6CHsQu05543 for ; Thu, 13 Jul 2006 03:54:26 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4Q64DLR668XIT6H@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 13 Jul 2006 03:54:25 +1000 Received: by localhost (Postfix, from userid 510) id 0650680002; Thu, 13 Jul 2006 03:54:24 +1000 (EST) Received: from mgw-ext13.nokia.com (mgw-ext13.nokia.com [131.228.20.172]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id C6DE93C00E for ; Thu, 13 Jul 2006 03:54:23 +1000 (EST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CHsEaA029042; Wed, 12 Jul 2006 20:54:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 20:54:14 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 20:54:13 +0300 Date: Wed, 12 Jul 2006 20:54:13 +0300 From: john.loughney@nokia.com Subject: [DNA] REVIEW of draft-ietf-dna-network In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: suresh.krishnan@ericsson.com Cc: dna@eng.monash.edu.au, gregd@research.panasonic.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: REVIEW of draft-ietf-dna-network Thread-Index: AcakZ2sDoSOo5DLARuyBPSsIFFWh+QBcYCLw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Jul 2006 17:54:13.0833 (UTC) FILETIME=[2FB3AB90:01C6A5DC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Hi all, Here is a short review of the document. Technically, it seems OK, but I think it needs a lot of editorial fixes, as the document doesn't really read well. A general comment, I found a lot of the draft written in a quite awkward manner, especially in the abstract and first few sections. More comments follow: 1) The style seems a bit forced and confused me in a number of places. For example, the Abstract says: Hosts experiencing rapid link-layer changes may require to do configuration change detection procedures more frequently than traditional fixed hosts. Could you actually state what "configuration change detection procedures" are? I found this wording strange. ... This document describes practices available to network deployers in order to support such hosts in Detecting Network Attachment in IPv6 networks. I know you are trying to reuse DNA here, but I think it could be reworded: This document describes practices available to network deployers in order to support such hosts in Detecting Network Attachment in IPv6 networks. I think what you are saying is that there are router-side solutions to help detect when a note attaches, or re-attaches, to an IPv6 network. 2) The Introduction continues: Hosts on the Internet may be connected by various media. It has become common that hosts have access through wireless media and are mobile. The frequency of configuration change for wireless and nomadic devices are elevated, due to the vagaries of wireless propagation or the motion of the hosts themselves. I think it might read better to say something like: Hosts on may connect to the Internet via different layer-2 technologies; many which may be wireless. Has both wired and wireless hosts become mobile, the frequency of attachment or re-attachment events may be more frequent than traditional, fixed hosts. Specific wireless technologies may also have an impact upon this. 3) Also: Such hosts need to determine if they have moved to a new IPv6 link rapidly, ... As the attachment is fairly binary, I don't think that the movement can be rapid, but it is more that the rate of change in re-attaching to different links may be rapid or not. I think this should be re-worded. 4) General comment: can we replace "network-side" with a more exact term? Do we mean routers here? 5) Question on this definition: Reachability Detection: Determination that a device (such as a router) is currently reachable, over both a wireless medium, and any attached fixed network. This is typically achieved using Neighbor Unreachability Detection procedure [1]. Is there a reason why it must be both wireless and wired? Could you have only wireless links on the router? I think reachability detection doesn't specifically require such a configuration. 6) Generally, might want to sync some of the terminology with http://www.ietf.org/rfc/rfc3753.txt (I don't exactly like the term "wireless medium") ... 7) minor nit: fix strange indenting in section 1.3. 8) I don't have time to fully go through all of the recommendations, but I think they generally look OK. 9) Appendicies are always non-normative in RFCs, I assume this document is meant to be informational, so maybe it is a non-issue. I found that having the recommendations as a non-normative appendicies is a little strange. I think it might make sense if this were in the body of the text. John From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 17 19:47:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2coX-0000MF-9J for dna-archive@lists.ietf.org; Mon, 17 Jul 2006 19:47:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2cUE-0004oC-I9 for dna-archive@lists.ietf.org; Mon, 17 Jul 2006 19:26:50 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2c2V-0001Nz-Bl for dna-archive@lists.ietf.org; Mon, 17 Jul 2006 18:58:13 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4XG3L4G1Q8YBRM3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 08:55:41 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5BB2180005; Tue, 18 Jul 2006 08:55:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 21A133C010; Tue, 18 Jul 2006 08:55:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6HMowq24015 for dna-list; Tue, 18 Jul 2006 08:50:58 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6HMoru24011 for ; Tue, 18 Jul 2006 08:50:53 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4XFWEIRQU8YMPKV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 18 Jul 2006 08:50:42 +1000 Received: by localhost (Postfix, from userid 510) id F2EFDAB542; Tue, 18 Jul 2006 08:50:41 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by moe.its.monash.edu.au (Postfix) with ESMTP id DC51C4FB0C for ; Tue, 18 Jul 2006 08:50:36 +1000 (EST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2CFF8B8; Tue, 18 Jul 2006 00:50:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 00:50:31 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 00:50:30 +0200 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 17:50:28 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 17:50:28 -0500 Date: Mon, 17 Jul 2006 18:57:48 -0400 From: Suresh Krishnan Subject: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: greg Daley , Bernard Aboba , "Jari Arkko (JO/LMF)" , Alper Yegin Reply-to: suresh.krishnan@ericsson.com Message-id: <44BC15EC.3060900@ericsson.ca> Organization: Ericsson MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 17 Jul 2006 22:50:28.0358 (UTC) FILETIME=[6635B260:01C6A9F3] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hi Folks, In its current form draft-ietf-dna-link-information-03 provides information about both link up and link down events. There were some concerns raised about the presence of link down events in this document, since DNA does not necessarily use the link down event. So instead of spending time to understand how to treat this event in this WG, one proposed solution was to remove link down related info from this document and let other wgs(perhaps future ones) work on it. If you have any opposition to this solution please respond to the mailing list by the 24th of July 2006 stating your objection. Cheers Suresh and Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 08:23:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ocB-0007HN-QS for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 08:23:51 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2oc8-0000Gr-Fx for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 08:23:51 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4Y8AJVOS28YCDVI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 22:23:05 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CF57180003; Tue, 18 Jul 2006 22:22:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 887293C007; Tue, 18 Jul 2006 22:22:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6ICLc600607 for dna-list; Tue, 18 Jul 2006 22:21:38 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6ICLbu00603 for ; Tue, 18 Jul 2006 22:21:37 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4Y88IAXZI8XJUJV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 18 Jul 2006 22:21:20 +1000 Received: by localhost (Postfix, from userid 510) id 2410EAB544; Tue, 18 Jul 2006 22:21:20 +1000 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by curly.its.monash.edu.au (Postfix) with ESMTP id 268214FB15 for ; Tue, 18 Jul 2006 22:21:17 +1000 (EST) Received: by ug-out-1314.google.com with SMTP id q2so459428uge for ; Tue, 18 Jul 2006 05:21:15 -0700 (PDT) Received: by 10.78.151.15 with SMTP id y15mr1459990hud; Tue, 18 Jul 2006 05:21:15 -0700 (PDT) Received: by 10.78.196.17 with HTTP; Tue, 18 Jul 2006 05:21:15 -0700 (PDT) Date: Tue, 18 Jul 2006 13:21:15 +0100 From: JinHyeock Choi Subject: [DNA] A Merging Proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au, JinHyeock Choi Message-id: <92e919fb0607180521p7d269464n59f22bcb911b8a8a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=MhSzppKldpccpPtdSZVTamQT9ExFdofGzBsOj2QHhh2fTrfGXNNHVrDi9jgYEop4McKLmzpuzBX7x0Kz24ozrdpKwnRTwCzk+sF6DDbIZu7JgANpx5tmOXLhCQb0UpkWMYp2/rpOTNM5Z+1CeYLGYACnJzGzfe0GQXvBE0lVU+o= X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Dear All As Greg told in the meeting, we started working on a merge. We aim to combine multiple drafts into an integrated solution without inconsistency or redundancy. I had a discussion with the authors and am glad to say that we seem to be in an agreement (at least, there was no objection. :-)). I propose to combine the existing schemes as below. Kindly see that the merging proposal is ok. Your feedback would be appreciated. Thanks for your kind consideration. Best Regards JinHyeock ------------------------------------------------------------------------------------------------- Right now, DNAv6 doesn't manage the Complete Prefix List (CPL). While it manages the Prefix List with DNAHostPrefixList, it doesn't concern whether the Prefix List is complete or not. We can combine CPL & DNAv6 to make a host always manage not only the Prefix List but also its COMPLETENESS. So roughly DNA host checks for link change as below. First, a host manages the CPL for an each link. Second, when the host moves to a new link, Case 1. When the host WITH the CPL - The host compares the CPL with the Prefix List in an incoming RA and assumes a link change if and only if there is no common prefix between two. (Take notice that it doesn't matter whether the host moves to a DNA link or a non-DNA link.) Case 2. When the host WITHOUT a CPL moves to a DNA link, - The host should send an RS with a Landmark prefix. - Upon receiving the RS, - If a DNA router can send a CompleteRA, it sends the CompleteRA to provide the (possibly new) CPL. Upon receiving the RA, the host can check for link change by comparing its Prefix List with the CPL in the RA. (Even when a DNA router can send a CPL, it may simply reply with the Landmark prefix in case of no link change to save bandwidth.) - If the router can't sends a CompleteRA (because of too many prefixes), it replies with the Landmark Option with YES/ NO indication. The host check for link change with the Landmark Option. Case 3. When the host WITHOUT a CPL moves to a non-DNA link, - If the host happens to move to a non-DNA link without a CPL, it checks for link change as of CPL by performing (multiple) RS/ RA exchanges to generate the (new) CPL Also LinkID prefix makes that any two RAs in a link have at least one common prefix to assure graceful prefix addition or removal. There would be no false decision, even when there is a temporary asynchronization among DNARouterPrefixList. In this way, I think we can integrate CPL and DNAv6 in an efficient way. I elaborated the above further as below. 1. DNA Host Operation 1.1 CPL management. 1) A host generates the Prefix List of a currently attached link. 2) The host declares the existing Prefix List is complete when - it receives a CompleteRA (as of DNAv6 in a DNA link where a router can send a CompleteRA.) or - it performs RS/ RA exchange num_RS_RA times (as of CPL either in a non-DNA link or in a DNA link where a router can't send the CompleteRA) - The Prefix List needs a complete flag to indicate its completeness. Currently, in CPL, Candidate Link Object uses the number of RS/ RA exchanges to indicate its completeness. 1.2 Link Identification. 1) Assume a host receives a hint of a possible link change. 2) Then the host sends an RS with a Landmark Option. * If the host has the CPL, I think it can omit the Landmark without degrading performance. 3) Upon receiving an RA with at least one prefix, the host checks for link change as below. IF the host has the CPL (Complete Prefix List) the host assumes a link change if and only if its Prefix List and the Prefix List from the incoming RA have no common prefix. ELSE { IF it receives the CompleteRA, the host assumes a link change if and only if its Prefix List and the Prefix List from the incoming RA have no common prefix. ELSE { IF it receives the RA with the Landmark Option which it sent the host assumes a link change if and only if the Landmark Option indicates a link change with NO ELSE the host checks for link change as of CPL. (i.e. it performs RS/ RA exchange num_RS_RA times to generates a (new) Prefix List and compare it with the existing one.) } } * I guess we can make Sec 5.2.5 of DNAv6 more clear with the above. 2. DNA Router Operation 2.1 CPL Management 1) A router generates the CPL (Complete Prefix List) by performing multiple RS/ RA exchanges as of DNAv6. 2) The router includes the LinkID Prefix as of DNAv6 to assure that two RAs always have a common prefix. * With this, we can add or remove a prefix without resulting in false link identification. 2.2 Link Identification. 1) Upon receiving an RS, the router sends back the CompleteRA, if possible. 2) If not possible, the router indicate a link identity with Landmark Option with YES/ NO bit. * I think we may do away with YES bit because we simply put the Landmark prefix in PIO to indicate YES. 3) Or we may make a modification to save bandwidth as below. The router first checks the Landmark Option in an RS and IF the Landmark is in the same link, the router simply sends back the Landmark Option with YES. ELSE { IF possible, the router sends the CompleteRA. * because the host needs the CPL anyway. ELSE the router sends back the Landmark Option with NO. } From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 12:28:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sQd-0001MH-Ti for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 12:28:11 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2sQc-0001v7-EE for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 12:28:11 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YGHSV5ZM8XJZ9B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 02:18:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B9C280004; Wed, 19 Jul 2006 02:17:53 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 26A513C00F; Wed, 19 Jul 2006 02:17:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6IGH1B03035 for dna-list; Wed, 19 Jul 2006 02:17:01 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6IGGxu03030 for ; Wed, 19 Jul 2006 02:16:59 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4YGGNFVNM8YC9DT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 02:16:58 +1000 Received: by localhost (Postfix, from userid 510) id DEB22AB542; Wed, 19 Jul 2006 02:16:57 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id C4F4E4FB0F for ; Wed, 19 Jul 2006 02:16:56 +1000 (EST) Date: Tue, 18 Jul 2006 09:18:49 -0700 From: James Kempf Subject: Re: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 Sender: owner-dna@ecselists.eng.monash.edu.au To: suresh.krishnan@ericsson.com, Dna Cc: greg Daley , Bernard Aboba , "Jari Arkko (JO/LMF)" , Alper Yegin Message-id: <01c101c6aa85$da4560f0$196115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * References: <44BC15EC.3060900@ericsson.ca> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 I'm fine with this. The history of Link Down in IETF is that nobody has ever figured out a way to allow it to be done securely. I hope that we can record this somewhere (maybe an RFC "Link Down Considered Harmful"? from the IAB) so people stop wasting time on it. jak ----- Original Message ----- From: "Suresh Krishnan" To: "Dna" Cc: "greg Daley" ; "Bernard Aboba" ; "Jari Arkko (JO/LMF)" ; "Alper Yegin" Sent: Monday, July 17, 2006 3:57 PM Subject: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 > Hi Folks, > In its current form draft-ietf-dna-link-information-03 provides > information about both link up and link down events. There were some > concerns raised about the presence of link down events in this document, > since DNA does not necessarily use the link down event. So instead of > spending time to understand how to treat this event in this WG, one > proposed solution was to remove link down related info from this document > and let other wgs(perhaps future ones) work on it. If you have any > opposition to this solution please respond to the mailing list by the 24th > of July 2006 stating your objection. > > Cheers > Suresh and Greg > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 13:00:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2swE-0001Ps-TZ for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 13:00:50 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2smB-0002LQ-30 for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 12:50:29 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4YHLU7TBU8WXU6Z@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 02:50:13 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 27A24AB543; Wed, 19 Jul 2006 02:50:10 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B73544FB14; Wed, 19 Jul 2006 02:50:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6IGnlR03396 for dna-list; Wed, 19 Jul 2006 02:49:47 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6IGnku03392 for ; Wed, 19 Jul 2006 02:49:46 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YHL6MLV08YMQRS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 02:49:39 +1000 Received: by localhost (Postfix, from userid 510) id 00BE4AB542; Wed, 19 Jul 2006 02:49:38 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id B68CD4FB11 for ; Wed, 19 Jul 2006 02:49:37 +1000 (EST) Date: Tue, 18 Jul 2006 09:51:25 -0700 From: James Kempf Subject: Re: [DNA] A Merging Proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , dna@eng.monash.edu.au, JinHyeock Choi Message-id: <021b01c6aa8a$67e02770$196115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * References: <92e919fb0607180521p7d269464n59f22bcb911b8a8a@mail.gmail.com> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f > Right now, DNAv6 doesn't manage the Complete Prefix List (CPL). > While it manages the Prefix List with DNAHostPrefixList, it doesn't > concern whether the Prefix List is complete or not. > > We can combine CPL & DNAv6 to make a host always manage > not only the Prefix List but also its COMPLETENESS. So roughly > DNA host checks for link change as below. > > First, a host manages the CPL for an each link. > > Second, when the host moves to a new link, > > Case 1. When the host WITH the CPL > - The host compares the CPL with the Prefix List in an incoming RA > and assumes a link change if and only if > there is no common prefix between two. > (Take notice that it doesn't matter whether the host moves to > a DNA link or a non-DNA link.) > > Case 2. When the host WITHOUT a CPL moves to a DNA link, > - The host should send an RS with a Landmark prefix. > - Upon receiving the RS, > - If a DNA router can send a CompleteRA, > it sends the CompleteRA > to provide the (possibly new) CPL. > Upon receiving the RA, the host can check for link change > by comparing its Prefix List with the CPL in the RA. > (Even when a DNA router can send a CPL, > it may simply reply with the Landmark prefix > in case of no link change to save bandwidth.) > - If the router can't sends a CompleteRA > (because of too many prefixes), > it replies with the Landmark Option with YES/ NO indication. > The host check for link change with the Landmark Option. > Why would a DNA host not have CPL? How would it know if it had CPL or not? jak > Case 3. When the host WITHOUT a CPL moves to a non-DNA link, > - If the host happens to move to a non-DNA link without a CPL, > it checks for link change as of CPL > by performing (multiple) RS/ RA exchanges to generate the (new) CPL > > Also LinkID prefix makes that any two RAs in a link have > at least one common prefix to assure graceful prefix addition or removal. > There would be no false decision, even when there is a temporary > asynchronization among DNARouterPrefixList. > > In this way, I think we can integrate CPL and DNAv6 in an efficient way. > > I elaborated the above further as below. > > 1. DNA Host Operation > > 1.1 CPL management. > 1) A host generates the Prefix List of a currently attached link. > > 2) The host declares the existing Prefix List is complete when > - it receives a CompleteRA > (as of DNAv6 in a DNA link where a router can send a CompleteRA.) > or > - it performs RS/ RA exchange num_RS_RA times > (as of CPL either in a non-DNA link or in a DNA link where a router > can't send the CompleteRA) > - The Prefix List needs a complete flag to indicate its completeness. > Currently, in CPL, Candidate Link Object uses the number of > RS/ RA exchanges to indicate its completeness. > > 1.2 Link Identification. > 1) Assume a host receives a hint of a possible link change. > > 2) Then the host sends an RS with a Landmark Option. > * If the host has the CPL, I think it can omit the Landmark > without degrading performance. > > 3) Upon receiving an RA with at least one prefix, > the host checks for link change as below. > > IF the host has the CPL (Complete Prefix List) > the host assumes a link change > if and only if > its Prefix List and the Prefix List from the incoming RA > have no common prefix. > > ELSE { > IF it receives the CompleteRA, > the host assumes a link change > if and only if > its Prefix List and the Prefix List from the incoming RA > have no common prefix. > > ELSE { > IF it receives the RA with the Landmark Option > which it sent > the host assumes a link change > if and only if > the Landmark Option indicates a link change with > NO > > ELSE > the host checks for link change as of CPL. > (i.e. it performs RS/ RA exchange num_RS_RA > times > to generates a (new) Prefix List and > compare it with the existing one.) > } > } > > * I guess we can make Sec 5.2.5 of DNAv6 more clear with the above. > > 2. DNA Router Operation > > 2.1 CPL Management > 1) A router generates the CPL (Complete Prefix List) by performing > multiple RS/ RA exchanges as of DNAv6. > > 2) The router includes the LinkID Prefix as of DNAv6 > to assure that two RAs always have a common prefix. > * With this, we can add or remove a prefix without resulting in > false link identification. > > 2.2 Link Identification. > 1) Upon receiving an RS, the router sends back the CompleteRA, > if possible. > > 2) If not possible, the router indicate a link identity > with Landmark Option with YES/ NO bit. > * I think we may do away with YES bit because we simply put > the Landmark prefix in PIO to indicate YES. > > 3) Or we may make a modification to save bandwidth as below. > > The router first checks the Landmark Option in an RS and > > IF the Landmark is in the same link, > the router simply sends back the Landmark Option with YES. > > ELSE { > IF possible, the router sends the CompleteRA. > * because the host needs the CPL anyway. > ELSE the router sends back the Landmark Option with NO. > } > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 13:02:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sxs-0002Ox-Aw for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 13:02:32 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2sxq-0004nm-Ns for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 13:02:32 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YI1B2GXA8YMLOD@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 03:02:04 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 77BFFAB542; Wed, 19 Jul 2006 03:01:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 313174FB0E; Wed, 19 Jul 2006 03:01:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6IH1Zs03531 for dna-list; Wed, 19 Jul 2006 03:01:35 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6IH1Yu03527 for ; Wed, 19 Jul 2006 03:01:34 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4YI0KIGZE8YBZAP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 03:01:21 +1000 Received: by localhost (Postfix, from userid 510) id 317A080002; Wed, 19 Jul 2006 03:01:21 +1000 (EST) Received: from web60311.mail.yahoo.com (web60311.mail.yahoo.com [209.73.178.134]) by larry.its.monash.edu.au (Postfix) with SMTP id 43AB53C00C for ; Wed, 19 Jul 2006 03:01:18 +1000 (EST) Received: (qmail 79762 invoked by uid 60001); Tue, 18 Jul 2006 17:01:14 +0000 Received: from [12.129.211.52] by web60311.mail.yahoo.com via HTTP; Tue, 18 Jul 2006 10:01:14 -0700 (PDT) Date: Tue, 18 Jul 2006 10:01:14 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [DNA] A Merging Proposal In-reply-to: <92e919fb0607180521p7d269464n59f22bcb911b8a8a@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , dna@eng.monash.edu.au Reply-to: Behcet Sarikaya Message-id: <20060718170114.79760.qmail@web60311.mail.yahoo.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PPVBlvlI7Culul9uRL4Ndw)" DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Wv0WIK5T4KqLDGbugNraPh/XJd0gxMX3oryJlpXPTpYet1WilNW4P9TWAuHIwIVjdBST3EKX26WcaBqaOizN+VBdA5s2RNPlP013bKScjq+k8+o7MYIG10WpHijLBnuvLcAvdqYw4+bVIr3xtEqNpxcLgD/0uM7zDH2QNHAyoOs= ; X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 --Boundary_(ID_PPVBlvlI7Culul9uRL4Ndw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi JinHyeock, Please keep the very last two reserved bits left in the RA messages and introduce options instead. I mentioned this to Suresh in Montreal. Regards, --behcet ----- Original Message ---- From: JinHyeock Choi To: dna@eng.monash.edu.au; JinHyeock Choi Sent: Tuesday, July 18, 2006 7:21:15 AM Subject: [DNA] A Merging Proposal Dear All As Greg told in the meeting, we started working on a merge. We aim to combine multiple drafts into an integrated solution without inconsistency or redundancy. I had a discussion with the authors and am glad to say that we seem to be in an agreement (at least, there was no objection. :-)). I propose to combine the existing schemes as below. Kindly see that the merging proposal is ok. Your feedback would be appreciated. Thanks for your kind consideration. Best Regards JinHyeock ------------------------------------------------------------------------------------------------- Right now, DNAv6 doesn't manage the Complete Prefix List (CPL). While it manages the Prefix List with DNAHostPrefixList, it doesn't concern whether the Prefix List is complete or not. We can combine CPL & DNAv6 to make a host always manage not only the Prefix List but also its COMPLETENESS. So roughly DNA host checks for link change as below. First, a host manages the CPL for an each link. Second, when the host moves to a new link, Case 1. When the host WITH the CPL - The host compares the CPL with the Prefix List in an incoming RA and assumes a link change if and only if there is no common prefix between two. (Take notice that it doesn't matter whether the host moves to a DNA link or a non-DNA link.) Case 2. When the host WITHOUT a CPL moves to a DNA link, - The host should send an RS with a Landmark prefix. - Upon receiving the RS, - If a DNA router can send a CompleteRA, it sends the CompleteRA to provide the (possibly new) CPL. Upon receiving the RA, the host can check for link change by comparing its Prefix List with the CPL in the RA. (Even when a DNA router can send a CPL, it may simply reply with the Landmark prefix in case of no link change to save bandwidth.) - If the router can't sends a CompleteRA (because of too many prefixes), it replies with the Landmark Option with YES/ NO indication. The host check for link change with the Landmark Option. Case 3. When the host WITHOUT a CPL moves to a non-DNA link, - If the host happens to move to a non-DNA link without a CPL, it checks for link change as of CPL by performing (multiple) RS/ RA exchanges to generate the (new) CPL Also LinkID prefix makes that any two RAs in a link have at least one common prefix to assure graceful prefix addition or removal. There would be no false decision, even when there is a temporary asynchronization among DNARouterPrefixList. In this way, I think we can integrate CPL and DNAv6 in an efficient way. I elaborated the above further as below. 1. DNA Host Operation 1.1 CPL management. 1) A host generates the Prefix List of a currently attached link. 2) The host declares the existing Prefix List is complete when - it receives a CompleteRA (as of DNAv6 in a DNA link where a router can send a CompleteRA.) or - it performs RS/ RA exchange num_RS_RA times (as of CPL either in a non-DNA link or in a DNA link where a router can't send the CompleteRA) - The Prefix List needs a complete flag to indicate its completeness. Currently, in CPL, Candidate Link Object uses the number of RS/ RA exchanges to indicate its completeness. 1.2 Link Identification. 1) Assume a host receives a hint of a possible link change. 2) Then the host sends an RS with a Landmark Option. * If the host has the CPL, I think it can omit the Landmark without degrading performance. 3) Upon receiving an RA with at least one prefix, the host checks for link change as below. IF the host has the CPL (Complete Prefix List) the host assumes a link change if and only if its Prefix List and the Prefix List from the incoming RA have no common prefix. ELSE { IF it receives the CompleteRA, the host assumes a link change if and only if its Prefix List and the Prefix List from the incoming RA have no common prefix. ELSE { IF it receives the RA with the Landmark Option which it sent the host assumes a link change if and only if the Landmark Option indicates a link change with NO ELSE the host checks for link change as of CPL. (i.e. it performs RS/ RA exchange num_RS_RA times to generates a (new) Prefix List and compare it with the existing one.) } } * I guess we can make Sec 5.2.5 of DNAv6 more clear with the above. 2. DNA Router Operation 2.1 CPL Management 1) A router generates the CPL (Complete Prefix List) by performing multiple RS/ RA exchanges as of DNAv6. 2) The router includes the LinkID Prefix as of DNAv6 to assure that two RAs always have a common prefix. * With this, we can add or remove a prefix without resulting in false link identification. 2.2 Link Identification. 1) Upon receiving an RS, the router sends back the CompleteRA, if possible. 2) If not possible, the router indicate a link identity with Landmark Option with YES/ NO bit. * I think we may do away with YES bit because we simply put the Landmark prefix in PIO to indicate YES. 3) Or we may make a modification to save bandwidth as below. The router first checks the Landmark Option in an RS and IF the Landmark is in the same link, the router simply sends back the Landmark Option with YES. ELSE { IF possible, the router sends the CompleteRA. * because the host needs the CPL anyway. ELSE the router sends back the Landmark Option with NO. } --Boundary_(ID_PPVBlvlI7Culul9uRL4Ndw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi JinHyeock,
  Please keep the very last two reserved bits left in the RA messages and introduce options instead. I mentioned this to Suresh in Montreal.

Regards,

--behcet
----- Original Message ----
From: JinHyeock Choi <jinchoe@gmail.com>
To: dna@eng.monash.edu.au; JinHyeock Choi <jinchoe@samsung.com>
Sent: Tuesday, July 18, 2006 7:21:15 AM
Subject: [DNA] A Merging Proposal

Dear All

As Greg told in the meeting, we started working on a merge. We aim to
combine multiple drafts into an integrated solution without
inconsistency or redundancy. I had a discussion with the authors and
am glad to say that we seem to be in an agreement (at least, there was
no objection. :-)). I propose to combine the existing schemes as
below. Kindly see that the merging proposal is ok. Your feedback would
be appreciated.

Thanks for your kind consideration.

Best Regards

JinHyeock

-------------------------------------------------------------------------------------------------
Right now, DNAv6 doesn't manage the Complete Prefix List (CPL).
While it manages the Prefix List with DNAHostPrefixList, it doesn't
concern whether the Prefix List is complete or not.

We can combine CPL & DNAv6 to make a host always manage
not only the Prefix List but also its COMPLETENESS. So roughly
DNA host checks for link change as below.

First, a host manages the CPL for an each link.

Second, when the host moves to a new link,

Case 1. When the host WITH the CPL
- The host compares the CPL with the Prefix List in an incoming RA
and assumes a link change if and only if
there is no common prefix between two.
(Take notice that it doesn't matter whether the host moves to
a DNA link or a non-DNA link.)

Case 2. When the host WITHOUT a CPL moves to a DNA link,
- The host should send an RS with a Landmark prefix.
- Upon receiving the RS,
- If a DNA router can send a CompleteRA,
it sends the CompleteRA
to provide the (possibly new) CPL.
Upon receiving the RA, the host can check for link change
by comparing its Prefix List with the CPL in the RA.
(Even when a DNA router can send a CPL,
  it may simply reply with the Landmark prefix
  in case of no link change to save bandwidth.)
- If the router can't sends a CompleteRA
(because of too many prefixes),
it replies with the Landmark Option with YES/ NO indication.
The host check for link change with the Landmark Option.

Case 3. When the host WITHOUT a CPL moves to a non-DNA link,
- If the host happens to move to a non-DNA link without a CPL,
it checks for link change as of CPL
by performing (multiple) RS/ RA exchanges to generate the (new) CPL

Also LinkID prefix makes that any two RAs in a link have
at least one common prefix to assure graceful prefix addition or removal.
There would be no false decision, even when there is a temporary
asynchronization among DNARouterPrefixList.

In this way, I think we can integrate CPL and DNAv6 in an efficient way.

I elaborated the above further as below.

1. DNA Host Operation

1.1 CPL management.
1) A host generates the Prefix List of a currently attached link.

2) The host declares the existing Prefix List is complete when
- it receives a CompleteRA
(as of DNAv6 in a DNA link where a router can send a CompleteRA.)
or
- it performs RS/ RA exchange num_RS_RA times
(as of CPL either in a non-DNA link or in a DNA link where a router
can't send the CompleteRA)
- The Prefix List needs a complete flag to indicate its completeness.
Currently, in CPL, Candidate Link Object uses the number of
RS/ RA exchanges to indicate its completeness.

1.2 Link Identification.
1) Assume a host receives a hint of a possible link change.

2) Then the host sends an RS with a Landmark Option.
  * If the host has the CPL, I think it can omit the Landmark
  without degrading performance.

3) Upon receiving an RA with at least one prefix,
  the host checks for link change as below.

IF the host has the CPL (Complete Prefix List)
    the host assumes a link change
    if and only if
    its Prefix List and the Prefix List from the incoming RA
    have no common prefix.

ELSE {
          IF it receives the CompleteRA,
               the host assumes a link change
               if and only if
               its Prefix List and the Prefix List from the incoming RA
               have no common prefix.

          ELSE {
                     IF it receives the RA with the Landmark Option
which it sent
                          the host assumes a link change
                          if and only if
                          the Landmark Option indicates a link change with NO

                     ELSE
                             the host checks for link change as of CPL.
                             (i.e. it performs RS/ RA exchange num_RS_RA times
                             to generates a (new) Prefix List and
                             compare it with the existing one.)
          }
}

* I guess we can make Sec 5.2.5 of DNAv6 more clear with the above.

2. DNA Router Operation

2.1 CPL Management
1) A router generates the CPL (Complete Prefix List) by performing
  multiple RS/ RA exchanges as of DNAv6.

2) The router includes the LinkID Prefix as of DNAv6
  to assure that two RAs always have a common prefix.
  * With this, we can add or remove a prefix without resulting in
  false link identification.

2.2 Link Identification.
1) Upon receiving an RS, the router sends back the CompleteRA,
  if possible.

2) If not possible, the router indicate a link identity
  with Landmark Option with YES/ NO bit.
  * I think we may do away with YES bit because we simply put
  the Landmark prefix in PIO to indicate YES.

3) Or we may make a modification to save bandwidth as below.

The router first checks the Landmark Option in an RS and

IF the Landmark is in the same link,
the router simply sends back the Landmark Option with YES.

ELSE {
          IF possible, the router sends the CompleteRA.
              * because the host needs the CPL anyway.
          ELSE the router sends back the Landmark Option with NO.
}

--Boundary_(ID_PPVBlvlI7Culul9uRL4Ndw)-- From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 15:47:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vXn-0006XR-2j for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 15:47:47 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2vXl-0005m6-V7 for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 15:47:47 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4YNQ6CE128YCBBK@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 05:45:30 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DF6C6AB543; Wed, 19 Jul 2006 05:45:27 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A2C874FB0D; Wed, 19 Jul 2006 05:45:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6IJgZf05330 for dna-list; Wed, 19 Jul 2006 05:42:35 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6IJgZu05324 for ; Wed, 19 Jul 2006 05:42:35 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YNM9YK1U8XHQON@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 05:42:19 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 46C0780002; Wed, 19 Jul 2006 05:42:19 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 29D5A3C004; Wed, 19 Jul 2006 05:42:19 +1000 (EST) Received: from [68.36.162.17] by mail-store-2.its.monash.edu.au (mshttpd); Tue, 18 Jul 2006 15:42:18 -0400 Date: Tue, 18 Jul 2006 15:42:18 -0400 From: Greg Daley Subject: Re: [DNA] A Merging Proposal In-reply-to: <20060718170114.79760.qmail@web60311.mail.yahoo.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Behcet Sarikaya Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en References: <92e919fb0607180521p7d269464n59f22bcb911b8a8a@mail.gmail.com> <20060718170114.79760.qmail@web60311.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Hi Behcet, We don't necessarily need to keep the flags available, as future extensions could define a flags field in an option. We will coordinate with the IPv6 WG, the ADs and IANA, to make sure that problems don't occur, and the best outcome is achieved. Greg ----- Original Message ----- From: Behcet Sarikaya Date: Tuesday, July 18, 2006 1:01 pm Subject: Re: [DNA] A Merging Proposal To: JinHyeock Choi , dna@eng.monash.edu.au > Hi JinHyeock, > Please keep the very last two reserved bits left in the RA > messages and introduce options instead. I mentioned this to Suresh > in Montreal. > > Regards, > > --behcet > ----- Original Message ---- > From: JinHyeock Choi > To: dna@eng.monash.edu.au; JinHyeock Choi > Sent: Tuesday, July 18, 2006 7:21:15 AM > Subject: [DNA] A Merging Proposal > > Dear All > > As Greg told in the meeting, we started working on a merge. We aim to > combine multiple drafts into an integrated solution without > inconsistency or redundancy. I had a discussion with the authors and > am glad to say that we seem to be in an agreement (at least, there was > no objection. :-)). I propose to combine the existing schemes as > below. Kindly see that the merging proposal is ok. Your feedback would > be appreciated. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock > > -------------------------------------------------------------------- > ----------------------------- > Right now, DNAv6 doesn't manage the Complete Prefix List (CPL). > While it manages the Prefix List with DNAHostPrefixList, it doesn't > concern whether the Prefix List is complete or not. > > We can combine CPL & DNAv6 to make a host always manage > not only the Prefix List but also its COMPLETENESS. So roughly > DNA host checks for link change as below. > > First, a host manages the CPL for an each link. > > Second, when the host moves to a new link, > > Case 1. When the host WITH the CPL > - The host compares the CPL with the Prefix List in an incoming RA > and assumes a link change if and only if > there is no common prefix between two. > (Take notice that it doesn't matter whether the host moves to > a DNA link or a non-DNA link.) > > Case 2. When the host WITHOUT a CPL moves to a DNA link, > - The host should send an RS with a Landmark prefix. > - Upon receiving the RS, > - If a DNA router can send a CompleteRA, > it sends the CompleteRA > to provide the (possibly new) CPL. > Upon receiving the RA, the host can check for link change > by comparing its Prefix List with the CPL in the RA. > (Even when a DNA router can send a CPL, > it may simply reply with the Landmark prefix > in case of no link change to save bandwidth.) > - If the router can't sends a CompleteRA > (because of too many prefixes), > it replies with the Landmark Option with YES/ NO indication. > The host check for link change with the Landmark Option. > > Case 3. When the host WITHOUT a CPL moves to a non-DNA link, > - If the host happens to move to a non-DNA link without a CPL, > it checks for link change as of CPL > by performing (multiple) RS/ RA exchanges to generate the (new) CPL > > Also LinkID prefix makes that any two RAs in a link have > at least one common prefix to assure graceful prefix addition or > removal.There would be no false decision, even when there is a > temporaryasynchronization among DNARouterPrefixList. > > In this way, I think we can integrate CPL and DNAv6 in an efficient > way. > I elaborated the above further as below. > > 1. DNA Host Operation > > 1.1 CPL management. > 1) A host generates the Prefix List of a currently attached link. > > 2) The host declares the existing Prefix List is complete when > - it receives a CompleteRA > (as of DNAv6 in a DNA link where a router can send a CompleteRA.) > or > - it performs RS/ RA exchange num_RS_RA times > (as of CPL either in a non-DNA link or in a DNA link where a router > can't send the CompleteRA) > - The Prefix List needs a complete flag to indicate its completeness. > Currently, in CPL, Candidate Link Object uses the number of > RS/ RA exchanges to indicate its completeness. > > 1.2 Link Identification. > 1) Assume a host receives a hint of a possible link change. > > 2) Then the host sends an RS with a Landmark Option. > * If the host has the CPL, I think it can omit the Landmark > without degrading performance. > > 3) Upon receiving an RA with at least one prefix, > the host checks for link change as below. > > IF the host has the CPL (Complete Prefix List) > the host assumes a link change > if and only if > its Prefix List and the Prefix List from the incoming RA > have no common prefix. > > ELSE { > IF it receives the CompleteRA, > the host assumes a link change > if and only if > its Prefix List and the Prefix List from the > incoming RA > have no common prefix. > > ELSE { > IF it receives the RA with the Landmark Option > which it sent > the host assumes a link change > if and only if > the Landmark Option indicates a link > change with NO > > ELSE > the host checks for link change as of > CPL. (i.e. it performs RS/ RA exchange > num_RS_RA times > to generates a (new) Prefix List and > compare it with the existing one.) > } > } > > * I guess we can make Sec 5.2.5 of DNAv6 more clear with the above. > > 2. DNA Router Operation > > 2.1 CPL Management > 1) A router generates the CPL (Complete Prefix List) by performing > multiple RS/ RA exchanges as of DNAv6. > > 2) The router includes the LinkID Prefix as of DNAv6 > to assure that two RAs always have a common prefix. > * With this, we can add or remove a prefix without resulting in > false link identification. > > 2.2 Link Identification. > 1) Upon receiving an RS, the router sends back the CompleteRA, > if possible. > > 2) If not possible, the router indicate a link identity > with Landmark Option with YES/ NO bit. > * I think we may do away with YES bit because we simply put > the Landmark prefix in PIO to indicate YES. > > 3) Or we may make a modification to save bandwidth as below. > > The router first checks the Landmark Option in an RS and > > IF the Landmark is in the same link, > the router simply sends back the Landmark Option with YES. > > ELSE { > IF possible, the router sends the CompleteRA. > * because the host needs the CPL anyway. > ELSE the router sends back the Landmark Option with NO. > } > > > > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 16:26:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2w9L-0002r8-Ji for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 16:26:35 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2w9K-0003Il-F0 for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 16:26:35 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YP4TPJQE8XJRH2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 06:25:46 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F36AEAB545; Wed, 19 Jul 2006 06:25:30 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B244A4FB10; Wed, 19 Jul 2006 06:25:30 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6IKMRW05758 for dna-list; Wed, 19 Jul 2006 06:22:27 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6IKMRu05754 for ; Wed, 19 Jul 2006 06:22:27 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YP0POVWW8YMPWI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 06:22:12 +1000 Received: by localhost (Postfix, from userid 510) id 4FE0B80004; Wed, 19 Jul 2006 06:22:12 +1000 (EST) Received: from av12-1-sn2.hy.skanova.net (av12-1-sn2.hy.skanova.net [81.228.8.185]) by larry.its.monash.edu.au (Postfix) with ESMTP id 50E9A3C006; Wed, 19 Jul 2006 06:22:10 +1000 (EST) Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id B906038276; Tue, 18 Jul 2006 22:22:06 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id ABF7737EFF; Tue, 18 Jul 2006 22:22:06 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 6E4EC37E44; Tue, 18 Jul 2006 22:22:06 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1G2w4y-0000p8-IY; Tue, 18 Jul 2006 22:22:05 +0200 Date: Tue, 18 Jul 2006 22:22:04 +0200 From: Henrik Levkowetz Subject: Re: [DNA] A Merging Proposal In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: dna@eng.monash.edu.au Message-id: <44BD42EC.9020604@levkowetz.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false References: <92e919fb0607180521p7d269464n59f22bcb911b8a8a@mail.gmail.com> <20060718170114.79760.qmail@web60311.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Hi Greg, on 2006-07-18 21:42 Greg Daley said the following: > Hi Behcet, > > We don't necessarily need to keep the flags available, as > future extensions could define a flags field in an option. > > We will coordinate with the IPv6 WG, the ADs and IANA, > to make sure that problems don't occur, and the best > outcome is achieved. You might want to consider using the last flag as an extension indicator, indicating that more flags are available in an option. That would give a fast-out path for the cases where no flags defined in the possible future flag option are used (i.e. the flag option and extension flag is absent). I think this might be better than using the last flag slot for a regular flag. Henrik > Greg > > ----- Original Message ----- > From: Behcet Sarikaya > Date: Tuesday, July 18, 2006 1:01 pm > Subject: Re: [DNA] A Merging Proposal > To: JinHyeock Choi , dna@eng.monash.edu.au > >> Hi JinHyeock, >> Please keep the very last two reserved bits left in the RA >> messages and introduce options instead. I mentioned this to Suresh >> in Montreal. >> >> Regards, >> >> --behcet >> ----- Original Message ---- >> From: JinHyeock Choi >> To: dna@eng.monash.edu.au; JinHyeock Choi >> Sent: Tuesday, July 18, 2006 7:21:15 AM >> Subject: [DNA] A Merging Proposal >> >> Dear All >> >> As Greg told in the meeting, we started working on a merge. We aim to >> combine multiple drafts into an integrated solution without >> inconsistency or redundancy. I had a discussion with the authors and >> am glad to say that we seem to be in an agreement (at least, there was >> no objection. :-)). I propose to combine the existing schemes as >> below. Kindly see that the merging proposal is ok. Your feedback would >> be appreciated. >> >> Thanks for your kind consideration. >> >> Best Regards >> >> JinHyeock >> >> -------------------------------------------------------------------- >> ----------------------------- >> Right now, DNAv6 doesn't manage the Complete Prefix List (CPL). >> While it manages the Prefix List with DNAHostPrefixList, it doesn't >> concern whether the Prefix List is complete or not. >> >> We can combine CPL & DNAv6 to make a host always manage >> not only the Prefix List but also its COMPLETENESS. So roughly >> DNA host checks for link change as below. >> >> First, a host manages the CPL for an each link. >> >> Second, when the host moves to a new link, >> >> Case 1. When the host WITH the CPL >> - The host compares the CPL with the Prefix List in an incoming RA >> and assumes a link change if and only if >> there is no common prefix between two. >> (Take notice that it doesn't matter whether the host moves to >> a DNA link or a non-DNA link.) >> >> Case 2. When the host WITHOUT a CPL moves to a DNA link, >> - The host should send an RS with a Landmark prefix. >> - Upon receiving the RS, >> - If a DNA router can send a CompleteRA, >> it sends the CompleteRA >> to provide the (possibly new) CPL. >> Upon receiving the RA, the host can check for link change >> by comparing its Prefix List with the CPL in the RA. >> (Even when a DNA router can send a CPL, >> it may simply reply with the Landmark prefix >> in case of no link change to save bandwidth.) >> - If the router can't sends a CompleteRA >> (because of too many prefixes), >> it replies with the Landmark Option with YES/ NO indication. >> The host check for link change with the Landmark Option. >> >> Case 3. When the host WITHOUT a CPL moves to a non-DNA link, >> - If the host happens to move to a non-DNA link without a CPL, >> it checks for link change as of CPL >> by performing (multiple) RS/ RA exchanges to generate the (new) CPL >> >> Also LinkID prefix makes that any two RAs in a link have >> at least one common prefix to assure graceful prefix addition or >> removal.There would be no false decision, even when there is a >> temporaryasynchronization among DNARouterPrefixList. >> >> In this way, I think we can integrate CPL and DNAv6 in an efficient >> way. >> I elaborated the above further as below. >> >> 1. DNA Host Operation >> >> 1.1 CPL management. >> 1) A host generates the Prefix List of a currently attached link. >> >> 2) The host declares the existing Prefix List is complete when >> - it receives a CompleteRA >> (as of DNAv6 in a DNA link where a router can send a CompleteRA.) >> or >> - it performs RS/ RA exchange num_RS_RA times >> (as of CPL either in a non-DNA link or in a DNA link where a router >> can't send the CompleteRA) >> - The Prefix List needs a complete flag to indicate its completeness. >> Currently, in CPL, Candidate Link Object uses the number of >> RS/ RA exchanges to indicate its completeness. >> >> 1.2 Link Identification. >> 1) Assume a host receives a hint of a possible link change. >> >> 2) Then the host sends an RS with a Landmark Option. >> * If the host has the CPL, I think it can omit the Landmark >> without degrading performance. >> >> 3) Upon receiving an RA with at least one prefix, >> the host checks for link change as below. >> >> IF the host has the CPL (Complete Prefix List) >> the host assumes a link change >> if and only if >> its Prefix List and the Prefix List from the incoming RA >> have no common prefix. >> >> ELSE { >> IF it receives the CompleteRA, >> the host assumes a link change >> if and only if >> its Prefix List and the Prefix List from the >> incoming RA >> have no common prefix. >> >> ELSE { >> IF it receives the RA with the Landmark Option >> which it sent >> the host assumes a link change >> if and only if >> the Landmark Option indicates a link >> change with NO >> >> ELSE >> the host checks for link change as of >> CPL. (i.e. it performs RS/ RA exchange >> num_RS_RA times >> to generates a (new) Prefix List and >> compare it with the existing one.) >> } >> } >> >> * I guess we can make Sec 5.2.5 of DNAv6 more clear with the above. >> >> 2. DNA Router Operation >> >> 2.1 CPL Management >> 1) A router generates the CPL (Complete Prefix List) by performing >> multiple RS/ RA exchanges as of DNAv6. >> >> 2) The router includes the LinkID Prefix as of DNAv6 >> to assure that two RAs always have a common prefix. >> * With this, we can add or remove a prefix without resulting in >> false link identification. >> >> 2.2 Link Identification. >> 1) Upon receiving an RS, the router sends back the CompleteRA, >> if possible. >> >> 2) If not possible, the router indicate a link identity >> with Landmark Option with YES/ NO bit. >> * I think we may do away with YES bit because we simply put >> the Landmark prefix in PIO to indicate YES. >> >> 3) Or we may make a modification to save bandwidth as below. >> >> The router first checks the Landmark Option in an RS and >> >> IF the Landmark is in the same link, >> the router simply sends back the Landmark Option with YES. >> >> ELSE { >> IF possible, the router sends the CompleteRA. >> * because the host needs the CPL anyway. >> ELSE the router sends back the Landmark Option with NO. >> } >> >> >> >> >> > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 18:59:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2yXZ-0006uC-4l for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 18:59:45 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2yXX-0007BZ-Cv for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 18:59:45 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4YUEUBNJA8WXSOK@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 08:56:33 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CD6CFAB542; Wed, 19 Jul 2006 08:56:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7F70C4FB10; Wed, 19 Jul 2006 08:56:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6IMqSl07258 for dna-list; Wed, 19 Jul 2006 08:52:28 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6IMqQu07254 for ; Wed, 19 Jul 2006 08:52:26 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4YU9Y202O8WXSOK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 08:52:25 +1000 Received: by localhost (Postfix, from userid 510) id 4E29880004; Wed, 19 Jul 2006 08:52:25 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3F7223C006 for ; Wed, 19 Jul 2006 08:52:19 +1000 (EST) Received: from [207.62.247.10] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1G2yQ73q1a-0003Jv; Tue, 18 Jul 2006 18:52:10 -0400 Date: Tue, 18 Jul 2006 15:52:01 -0700 From: Alper Yegin Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 In-reply-to: <01c101c6aa85$da4560f0$196115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: 'James Kempf' , suresh.krishnan@ericsson.com, 'Dna' Cc: 'greg Daley' , 'Bernard Aboba' , "'Jari Arkko (JO/LMF)'" Message-id: <0MKoyl-1G2yQ73q1a-0003Jv@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Index: AcaqhZX2n31MOvNHRWuPkq45wdjmFAANu23Q X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi James, Can you expand on that a bit more? It sounds like you are suggesting there are L2 technologies and architectures that can secure link up but not link down? Otherwise link up would be as harmful as link down is. Alper > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, July 18, 2006 9:19 AM > To: suresh.krishnan@ericsson.com; Dna > Cc: greg Daley; Bernard Aboba; Jari Arkko (JO/LMF); Alper Yegin > Subject: Re: [DNA] QUESTION: Remove Link Down information in draft-ietf- > dna-link-information-03 > > I'm fine with this. The history of Link Down in IETF is that nobody has > ever > figured out a way to allow it to be done securely. I hope that we can > record > this somewhere (maybe an RFC "Link Down Considered Harmful"? from the IAB) > so people stop wasting time on it. > > jak > > ----- Original Message ----- > From: "Suresh Krishnan" > To: "Dna" > Cc: "greg Daley" ; "Bernard Aboba" > ; "Jari Arkko (JO/LMF)" ; > "Alper Yegin" > Sent: Monday, July 17, 2006 3:57 PM > Subject: [DNA] QUESTION: Remove Link Down information in > draft-ietf-dna-link-information-03 > > > > Hi Folks, > > In its current form draft-ietf-dna-link-information-03 provides > > information about both link up and link down events. There were some > > concerns raised about the presence of link down events in this document, > > since DNA does not necessarily use the link down event. So instead of > > spending time to understand how to treat this event in this WG, one > > proposed solution was to remove link down related info from this > document > > and let other wgs(perhaps future ones) work on it. If you have any > > opposition to this solution please respond to the mailing list by the > 24th > > of July 2006 stating your objection. > > > > Cheers > > Suresh and Greg > > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 20:46:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G30Cm-000180-EE for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 20:46:24 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G30Ck-00052x-Ni for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 20:46:24 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4YY6NTV8S8WXV6R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 10:44:25 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D03CCAB544; Wed, 19 Jul 2006 10:44:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 911564FB05; Wed, 19 Jul 2006 10:44:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6J0ela08357 for dna-list; Wed, 19 Jul 2006 10:40:47 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6J0eju08353 for ; Wed, 19 Jul 2006 10:40:45 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YY1W61AE8XJZ36@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 10:40:32 +1000 Received: by localhost (Postfix, from userid 510) id B165DAB542; Wed, 19 Jul 2006 10:40:32 +1000 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by moe.its.monash.edu.au (Postfix) with ESMTP id CC18F4FB0D for ; Wed, 19 Jul 2006 10:40:31 +1000 (EST) Received: by ug-out-1314.google.com with SMTP id q2so83053uge for ; Tue, 18 Jul 2006 17:40:29 -0700 (PDT) Received: by 10.78.166.7 with SMTP id o7mr58903hue; Tue, 18 Jul 2006 17:40:29 -0700 (PDT) Received: by 10.78.196.17 with HTTP; Tue, 18 Jul 2006 17:40:28 -0700 (PDT) Date: Wed, 19 Jul 2006 01:40:29 +0100 From: JinHyeock Choi Subject: Re: [DNA] A Merging Proposal In-reply-to: <021b01c6aa8a$67e02770$196115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au, JinHyeock Choi Message-id: <92e919fb0607181740m3f37418ai9057f12fcab227df@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oZPjUacoawyhunOc3gezASYmilEtlVVYI1K27tr8BmvAFtV9QhVrfM8Lux9nbuT9n6b1lyfzQhAbwN4vFYilHuPhXHwTnrhuu+JpBK5pgQNUkmhmwdR31FF11RlfuryNzKMHhUm12jbLv0Ds87FipSMgPx936usr4b5Y5qnIcCg= X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <92e919fb0607180521p7d269464n59f22bcb911b8a8a@mail.gmail.com> <021b01c6aa8a$67e02770$196115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Dear Jak > Why would a DNA host not have CPL? How would it know if it had CPL or not? A DNA host assumes that its Prefix List is complete, i.e. it has the CPL when 1) it receives a Complete RA or 2) it performs a certain number of RS/ RA exchanges. (The current CPL drafts recommends one RS/ RA exchange.) With the above, I assume that a DNA host would keep the CPL for the most of time. However, if a DNA host stays in a non-DNA link for a very shot time, the host would neither receive a Complete RA nor be able to perform even single RS/ RA exchange. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 18 20:48:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G30Ey-0001AS-TE for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 20:48:40 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G30Ex-00055q-5e for dna-archive@lists.ietf.org; Tue, 18 Jul 2006 20:48:40 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YYA98QH28XJYAS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 10:47:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 50297AB544; Wed, 19 Jul 2006 10:47:12 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0E8DD4FB0B; Wed, 19 Jul 2006 10:47:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6J0ieK08409 for dna-list; Wed, 19 Jul 2006 10:44:40 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6J0ieu08405 for ; Wed, 19 Jul 2006 10:44:40 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4YY6X7SKK8YMZOY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 10:44:31 +1000 Received: by localhost (Postfix, from userid 510) id 0F81A80002; Wed, 19 Jul 2006 10:44:31 +1000 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by larry.its.monash.edu.au (Postfix) with ESMTP id 326B63C007 for ; Wed, 19 Jul 2006 10:44:29 +1000 (EST) Received: by ug-out-1314.google.com with SMTP id q2so84252uge for ; Tue, 18 Jul 2006 17:44:27 -0700 (PDT) Received: by 10.78.122.11 with SMTP id u11mr59920huc; Tue, 18 Jul 2006 17:44:27 -0700 (PDT) Received: by 10.78.196.17 with HTTP; Tue, 18 Jul 2006 17:44:26 -0700 (PDT) Date: Wed, 19 Jul 2006 01:44:26 +0100 From: JinHyeock Choi Subject: Re: [DNA] A Merging Proposal In-reply-to: <20060718170114.79760.qmail@web60311.mail.yahoo.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Behcet Sarikaya Cc: dna@eng.monash.edu.au Message-id: <92e919fb0607181744k7dac4bbdyd3c626106a4a9677@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j9shz7G57CaVcYUHWAPsQaTQQ4MiOP2fN0XWnqno/88hs83+i1EOg4DUnGj/dza92/Rf3bMau6eJHi2i9urP6NwzgLvHCwRB7vFsrFituD3TRW5VpYgHzuqbMX7RzfcsXDBLyOkSSXnEbuoOY/60MRlG0IDUKByK1S2l2ako7a0= X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <92e919fb0607180521p7d269464n59f22bcb911b8a8a@mail.gmail.com> <20060718170114.79760.qmail@web60311.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Dear Behcet > Please keep the very last two reserved bits left in the RA messages and > introduce options instead. I mentioned this to Suresh in Montreal. Thanks for kindly pointing this out. If needed, we may use options instead, as you suggest. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 19 02:26:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G35Vx-0000zO-QC for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 02:26:33 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G35Vw-0007tm-2Y for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 02:26:33 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4ZA0JR8ZC8YC8T3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 16:23:06 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8FFC0AB543; Wed, 19 Jul 2006 16:23:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4E3D04FB04; Wed, 19 Jul 2006 16:23:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6J6JbX12078 for dna-list; Wed, 19 Jul 2006 16:19:37 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6J6JZu12074 for ; Wed, 19 Jul 2006 16:19:35 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4Z9UWJWA48XI6EN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 19 Jul 2006 16:19:12 +1000 Received: by localhost (Postfix, from userid 510) id 49E5CAB544; Wed, 19 Jul 2006 16:19:12 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by curly.its.monash.edu.au (Postfix) with ESMTP id 866464FB05 for ; Wed, 19 Jul 2006 16:19:09 +1000 (EST) Received: from [68.126.193.27] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1G35Oa3srd-0003KO; Wed, 19 Jul 2006 02:19:06 -0400 Date: Tue, 18 Jul 2006 23:18:54 -0700 From: Alper Yegin Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: 'Bernard Aboba' Cc: 'James Kempf' , suresh.krishnan@ericsson.com, 'Dna' , 'greg Daley' , "'Jari Arkko (JO/LMF)'" Message-id: <0MKoyl-1G35Oa3srd-0003KO@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Index: Acaq7V688F4p089BRXGvaGLwqh+FJwADPHGg X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > > are L2 technologies and architectures that can secure link up but not > link > > down? Otherwise link up would be as harmful as link down is. > > Perhaps this is referring to the ability to spoof management traffic that > can result in a "Link Down" indication? For example, in 802.11 the 4-way > handshake is secured, but management traffic such as Disassociate, > Deauthnticate, etc. are not (this is fixed in 802.11w). So "Link Up" is > not spoofable (at least in 802.11i) but "Link Down" is. > > On the other hand, a microwave oven, or large scissors will also do the > trick for many links ;) Yes, this is a good example. But are there enough many other examples to say "nobody has ever figured out a way to allow it (link down) to be done securely."? Btw, this does not say "link down is harmful" to me. It says there are technologies whose link can be brought down by attackers. Whether a link is brought down legitimately or maliciously, it is down as far as the L2 and L3 are concerned. Alper From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 19 13:11:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FZz-0002w9-Kz for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 13:11:23 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3FZx-0007dW-01 for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 13:11:23 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M4ZWMHKCEG8XJLWH@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 20 Jul 2006 03:10:44 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 709A680004; Thu, 20 Jul 2006 03:10:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 26ABA3C005; Thu, 20 Jul 2006 03:10:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6JH9Bv18749 for dna-list; Thu, 20 Jul 2006 03:09:11 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6JH99u18745 for ; Thu, 20 Jul 2006 03:09:09 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M4ZWKK3AZY8YC5GC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 20 Jul 2006 03:09:04 +1000 Received: by localhost (Postfix, from userid 510) id 7599EAB542; Thu, 20 Jul 2006 03:09:04 +1000 (EST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 3F1E54FB0B for ; Thu, 20 Jul 2006 03:09:01 +1000 (EST) Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6JH8kIm071271; Wed, 19 Jul 2006 13:08:48 -0400 (EDT envelope-from yohba@tari.toshiba.com) Date: Wed, 19 Jul 2006 13:08:35 -0400 From: Yoshihiro Ohba Subject: Re: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 In-reply-to: <01c101c6aa85$da4560f0$196115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: suresh.krishnan@ericsson.com, Dna , greg Daley , Bernard Aboba , "Jari Arkko (JO/LMF)" , Alper Yegin Mail-followup-to: James Kempf , suresh.krishnan@ericsson.com, Dna , greg Daley , Bernard Aboba , "Jari Arkko (JO/LMF)" , Alper Yegin Message-id: <20060719170835.GB12694@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * Lines: 47 References: <44BC15EC.3060900@ericsson.ca> <01c101c6aa85$da4560f0$196115ac@dcml.docomolabsusa.com> X-Dispatcher: imput version 20050308(IM148) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 FYI, IEEE 802.21 defines link down indication, but with more detailed information on why the indication has been generated. Depending on the detailed information the receiver of the indication is allowed to take different actions including silent discarding the indication. It may be possible to define more sophisticated indications in a future. My personal opinion is that it sounds premature to conclude that link down indication is harmful in general. Yoshihiro Ohba On Tue, Jul 18, 2006 at 09:18:49AM -0700, James Kempf wrote: > I'm fine with this. The history of Link Down in IETF is that nobody has > ever figured out a way to allow it to be done securely. I hope that we can > record this somewhere (maybe an RFC "Link Down Considered Harmful"? from > the IAB) so people stop wasting time on it. > > jak > > ----- Original Message ----- > From: "Suresh Krishnan" > To: "Dna" > Cc: "greg Daley" ; "Bernard Aboba" > ; "Jari Arkko (JO/LMF)" ; > "Alper Yegin" > Sent: Monday, July 17, 2006 3:57 PM > Subject: [DNA] QUESTION: Remove Link Down information in > draft-ietf-dna-link-information-03 > > > >Hi Folks, > > In its current form draft-ietf-dna-link-information-03 provides > >information about both link up and link down events. There were some > >concerns raised about the presence of link down events in this document, > >since DNA does not necessarily use the link down event. So instead of > >spending time to understand how to treat this event in this WG, one > >proposed solution was to remove link down related info from this document > >and let other wgs(perhaps future ones) work on it. If you have any > >opposition to this solution please respond to the mailing list by the 24th > >of July 2006 stating your objection. > > > >Cheers > >Suresh and Greg > > > > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 19 16:07:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3IK1-0007VW-J1 for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 16:07:05 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3IJz-0007KP-OD for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 16:07:05 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M502QBAHF48YC9WR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 20 Jul 2006 06:05:31 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DF5CAB543; Thu, 20 Jul 2006 06:05:28 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3611C4FB0B; Thu, 20 Jul 2006 06:05:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6JK4ZQ20837 for dna-list; Thu, 20 Jul 2006 06:04:35 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6JK4Yu20833 for ; Thu, 20 Jul 2006 06:04:34 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M502OPDNKW8YMPZ1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 20 Jul 2006 06:04:24 +1000 Received: by localhost (Postfix, from userid 510) id 129D480002; Thu, 20 Jul 2006 06:04:24 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id B485A3C006 for ; Thu, 20 Jul 2006 06:04:22 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k6JK4MgJ014329; Wed, 19 Jul 2006 16:04:22 -0400 Received: from [150.169.1.225] ([150.169.1.225]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGZ26780; Wed, 19 Jul 2006 16:01:57 -0400 (EDT) Date: Wed, 19 Jul 2006 16:04:18 -0400 From: Greg Daley Subject: Re: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 In-reply-to: <20060719170835.GB12694@steelhead> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf , suresh.krishnan@ericsson.com, Dna , greg Daley , Bernard Aboba , "Jari Arkko (JO/LMF)" , Alper Yegin Message-id: <44BE9042.8040602@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * X-Junkmail-Status: score=10/57, host=redwood.research.panasonic.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090202.44BE8DB9.0032,ss=1,fgs=0, ip=150.169.1.225, so=2006-02-11 11:31:14, dmn=5.2.4/2006-05-04 References: <44BC15EC.3060900@ericsson.ca> <01c101c6aa85$da4560f0$196115ac@dcml.docomolabsusa.com> <20060719170835.GB12694@steelhead> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hi, I think that this is a good point. There's a mix of protocols which have different properties regarding Link-Down indications. 802.21 is one of those which is potentially better behaved, while PPP (LCP) and existing 802.11 are poorly behaved, as anyone may forge a packet to tear down the connection. In the PPP case it was because the protocol was designed when people trusted the physical layer to be under the MAC, in 802.11, I guess it was an oversight. The better behaved protocols may potentially be used to send indications up the stack to control packet queuing and vertical handovers. We haven't described 802.21 here though, because of the simultaneous development of the specifications. Greg Yoshihiro Ohba wrote: > FYI, IEEE 802.21 defines link down indication, but with more detailed > information on why the indication has been generated. Depending on > the detailed information the receiver of the indication is allowed to > take different actions including silent discarding the indication. It > may be possible to define more sophisticated indications in a future. > My personal opinion is that it sounds premature to conclude that link > down indication is harmful in general. > > Yoshihiro Ohba > > > On Tue, Jul 18, 2006 at 09:18:49AM -0700, James Kempf wrote: >> I'm fine with this. The history of Link Down in IETF is that nobody has >> ever figured out a way to allow it to be done securely. I hope that we can >> record this somewhere (maybe an RFC "Link Down Considered Harmful"? from >> the IAB) so people stop wasting time on it. >> >> jak >> >> ----- Original Message ----- >> From: "Suresh Krishnan" >> To: "Dna" >> Cc: "greg Daley" ; "Bernard Aboba" >> ; "Jari Arkko (JO/LMF)" ; >> "Alper Yegin" >> Sent: Monday, July 17, 2006 3:57 PM >> Subject: [DNA] QUESTION: Remove Link Down information in >> draft-ietf-dna-link-information-03 >> >> >>> Hi Folks, >>> In its current form draft-ietf-dna-link-information-03 provides >>> information about both link up and link down events. There were some >>> concerns raised about the presence of link down events in this document, >>> since DNA does not necessarily use the link down event. So instead of >>> spending time to understand how to treat this event in this WG, one >>> proposed solution was to remove link down related info from this document >>> and let other wgs(perhaps future ones) work on it. If you have any >>> opposition to this solution please respond to the mailing list by the 24th >>> of July 2006 stating your objection. >>> >>> Cheers >>> Suresh and Greg >>> >> >> From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 19 16:40:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Iqe-0002PG-O9 for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 16:40:48 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Iqb-0002AG-TY for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 16:40:48 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M503XOS31A8YMK6D@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 20 Jul 2006 06:40:40 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2CC6DAB542; Thu, 20 Jul 2006 06:40:27 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id DA0074FB03; Thu, 20 Jul 2006 06:40:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6JKe2x21217 for dna-list; Thu, 20 Jul 2006 06:40:02 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6JKe0u21211 for ; Thu, 20 Jul 2006 06:40:00 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M503WKG8928YC5V2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 20 Jul 2006 06:39:44 +1000 Received: by localhost (Postfix, from userid 510) id B336EAB544; Thu, 20 Jul 2006 06:39:44 +1000 (EST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 98EF64FB06 for ; Thu, 20 Jul 2006 06:39:42 +1000 (EST) Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6JKdVo8072545; Wed, 19 Jul 2006 16:39:32 -0400 (EDT envelope-from yohba@tari.toshiba.com) Date: Wed, 19 Jul 2006 16:39:26 -0400 From: Yoshihiro Ohba Subject: Re: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 In-reply-to: <029f01c6ab6d$1261ebb0$196115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Yoshihiro Ohba , suresh.krishnan@ericsson.com, Dna , greg Daley , Bernard Aboba , "Jari Arkko (JO/LMF)" , Alper Yegin Mail-followup-to: James Kempf , Yoshihiro Ohba , suresh.krishnan@ericsson.com, Dna , greg Daley , Bernard Aboba , "Jari Arkko (JO/LMF)" , Alper Yegin Message-id: <20060719203926.GE12694@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * Lines: 95 References: <44BC15EC.3060900@ericsson.ca> <01c101c6aa85$da4560f0$196115ac@dcml.docomolabsusa.com> <20060719170835.GB12694@steelhead> <029f01c6ab6d$1261ebb0$196115ac@dcml.docomolabsusa.com> X-Dispatcher: imput version 20050308(IM148) X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Security of link layer indications would heavily depend on the link layer security characteristics. I'd say that any link-layer indication generated as a result of receipt of unprotected link-layer frames is an issue even if IEEE 802.21 is used. On the other hand, if indications are generated as a result of receipt of protected link-layer frames, then the indications can be useful even if 802.21 is not used. 802.21 also supports remote delivery of link layer indications using MIHF (Medie-Independent Handover Function) protocol. This remote delivery needs to be proteced by MIHF protocol transport. BTW, there was a tutorial on IEEE 802.21 in IEEE 802 plenary yesterday and the slides are available at: http://www.ieee802.org/21/doctree/2006-07_meeting_docs/802%2021-IEEE-Tutorial.ppt Hope this helps, Yoshihiro Ohba On Wed, Jul 19, 2006 at 12:53:57PM -0700, James Kempf wrote: > Yoshi, > > What kind of security is on this? > > jak > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "James Kempf" > Cc: ; "Dna" ; "greg > Daley" ; "Bernard Aboba" > ; "Jari Arkko (JO/LMF)" ; > "Alper Yegin" > Sent: Wednesday, July 19, 2006 10:08 AM > Subject: Re: [DNA] QUESTION: Remove Link Down information in > draft-ietf-dna-link-information-03 > > > >FYI, IEEE 802.21 defines link down indication, but with more detailed > >information on why the indication has been generated. Depending on > >the detailed information the receiver of the indication is allowed to > >take different actions including silent discarding the indication. It > >may be possible to define more sophisticated indications in a future. > >My personal opinion is that it sounds premature to conclude that link > >down indication is harmful in general. > > > >Yoshihiro Ohba > > > > > >On Tue, Jul 18, 2006 at 09:18:49AM -0700, James Kempf wrote: > >>I'm fine with this. The history of Link Down in IETF is that nobody has > >>ever figured out a way to allow it to be done securely. I hope that we > >>can > >>record this somewhere (maybe an RFC "Link Down Considered Harmful"? from > >>the IAB) so people stop wasting time on it. > >> > >> jak > >> > >>----- Original Message ----- > >>From: "Suresh Krishnan" > >>To: "Dna" > >>Cc: "greg Daley" ; "Bernard Aboba" > >>; "Jari Arkko (JO/LMF)" ; > >>"Alper Yegin" > >>Sent: Monday, July 17, 2006 3:57 PM > >>Subject: [DNA] QUESTION: Remove Link Down information in > >>draft-ietf-dna-link-information-03 > >> > >> > >>>Hi Folks, > >>> In its current form draft-ietf-dna-link-information-03 provides > >>>information about both link up and link down events. There were some > >>>concerns raised about the presence of link down events in this document, > >>>since DNA does not necessarily use the link down event. So instead of > >>>spending time to understand how to treat this event in this WG, one > >>>proposed solution was to remove link down related info from this > >>>document > >>>and let other wgs(perhaps future ones) work on it. If you have any > >>>opposition to this solution please respond to the mailing list by the > >>>24th > >>>of July 2006 stating your objection. > >>> > >>>Cheers > >>>Suresh and Greg > >>> > >> > >> > >> > > > > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 19 18:19:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3KO8-00085x-T4 for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 18:19:28 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3KO7-0006xa-4U for dna-archive@lists.ietf.org; Wed, 19 Jul 2006 18:19:28 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M507BCJ59K8YCJUB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 20 Jul 2006 08:17:07 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DE08AB543; Thu, 20 Jul 2006 08:17:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 18C614FB03; Thu, 20 Jul 2006 08:17:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6JMGAU22245 for dna-list; Thu, 20 Jul 2006 08:16:10 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6JMG8u22241 for ; Thu, 20 Jul 2006 08:16:08 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M507A9Y6TI8WXVV6@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 20 Jul 2006 08:16:06 +1000 Received: by localhost (Postfix, from userid 510) id 290D0AB543; Thu, 20 Jul 2006 08:16:06 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by curly.its.monash.edu.au (Postfix) with ESMTP id D27314FB02 for ; Thu, 20 Jul 2006 08:16:04 +1000 (EST) Received: from [68.126.193.27] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1G3KKc2uj7-00044B; Wed, 19 Jul 2006 18:15:58 -0400 Date: Wed, 19 Jul 2006 15:15:48 -0700 From: Alper Yegin Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 In-reply-to: <025501c6ab6b$94bf6760$196115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: 'James Kempf' , 'Bernard Aboba' Cc: suresh.krishnan@ericsson.com, 'Dna' , 'greg Daley' , "'Jari Arkko (JO/LMF)'" Message-id: <0MKp2t-1G3KKc2uj7-00044B@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Index: Acara1RATplbNfxTQ2eFSDqjzPazTwAFN6ew X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Jim, I think we shall pinpoint where the "fundamental problem" is. I don't think the fundamental problem is with the "link down" when it comes to spoofing. When such threat is possible, the fundamental problem is with the specific L2 design that does not allow signing (authenticating) L2 management signaling that leads to link down. And that applies to any other L2 management signal that is not signed - link *. If someone wants to write a document "not signing L2 management signaling for wireless networks is considered harmful", that's fine. But than, that's very obvious. Alper > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, July 19, 2006 12:43 PM > To: Alper Yegin; 'Bernard Aboba' > Cc: suresh.krishnan@ericsson.com; 'Dna'; 'greg Daley'; 'Jari Arkko > (JO/LMF)' > Subject: Re: [DNA] QUESTION: Remove Link Down information in draft-ietf- > dna-link-information-03 > > Alper, > > "Is harmful" is typically a title for an RFC that discusses concerns about > some topic. As Bernard says, the problem is that, at the IP level, it is > possible to spoof "Link Down" traffic As you say, it is possible that some > L2 protocol could provide a secure way to indicate "Link Down". My point > was > that the topic of IP level "Link Down" has been discussed now in one WG > (DNA) and one BOF (TRIGTRAN) and also I think in another BOF over the last > few years., and the conclusions have been the same I believe that one > could > reasonably conclude the problem can't be solved, barring some fundamental > change in network to host signaling security. Am I missing something here? > > jak > > ----- Original Message ----- > From: "Alper Yegin" > To: "'Bernard Aboba'" > Cc: "'James Kempf'" ; > ; "'Dna'" ; "'greg > Daley'" ; "'Jari Arkko (JO/LMF)'" > > Sent: Tuesday, July 18, 2006 11:18 PM > Subject: RE: [DNA] QUESTION: Remove Link Down information in > draft-ietf-dna-link-information-03 > > > >> > are L2 technologies and architectures that can secure link up but not > >> link > >> > down? Otherwise link up would be as harmful as link down is. > >> > >> Perhaps this is referring to the ability to spoof management traffic > that > >> can result in a "Link Down" indication? For example, in 802.11 the 4- > way > >> handshake is secured, but management traffic such as Disassociate, > >> Deauthnticate, etc. are not (this is fixed in 802.11w). So "Link Up" > is > >> not spoofable (at least in 802.11i) but "Link Down" is. > >> > >> On the other hand, a microwave oven, or large scissors will also do the > >> trick for many links ;) > > > > Yes, this is a good example. But are there enough many other examples to > > say > > "nobody has ever figured out a way to allow it (link down) to be done > > securely."? > > > > Btw, this does not say "link down is harmful" to me. It says there are > > technologies whose link can be brought down by attackers. Whether a link > > is > > brought down legitimately or maliciously, it is down as far as the L2 > and > > L3 > > are concerned. > > > > > > Alper > > > > > > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 21 03:07:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3p5k-0007S2-3h for dna-archive@lists.ietf.org; Fri, 21 Jul 2006 03:06:32 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3oyO-00029d-9T for dna-archive@lists.ietf.org; Fri, 21 Jul 2006 02:58:58 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M523SLBV268WXUZO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 21 Jul 2006 16:57:59 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ACFD9AB547; Fri, 21 Jul 2006 16:57:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5EE754FB04; Fri, 21 Jul 2006 16:57:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6L6qrV10486 for dna-list; Fri, 21 Jul 2006 16:52:53 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6L6qou10482 for ; Fri, 21 Jul 2006 16:52:51 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M523GYHWVG8WXWHJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 21 Jul 2006 16:48:37 +1000 Received: by localhost (Postfix, from userid 510) id 95E2E8000C; Fri, 21 Jul 2006 16:48:31 +1000 (EST) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 503B03C00C for ; Fri, 21 Jul 2006 16:48:28 +1000 (EST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6L5ga10015652; Fri, 21 Jul 2006 08:42:39 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 09:42:32 +0300 Received: from dapmg001.ext.nokia.com ([147.243.142.158]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 01:42:25 -0500 Date: Fri, 21 Jul 2006 09:42:25 +0300 (EEST) From: Michael Williams Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03 Sender: owner-dna@ecselists.eng.monash.edu.au To: alper.yegin@yegin.org, aboba@internaut.com Cc: gregd@research.panasonic.com, jari.arkko@ericsson.com, kempf@docomolabs-usa.com, suresh.krishnan@ericsson.com, dna@eng.monash.edu.au Message-id: <32313484.1153464145799.JavaMail.root@dapmg001.ext.nokia.com> MIME-version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id k6L6qqu10483 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * X-OriginalArrivalTime: 21 Jul 2006 06:42:25.0387 (UTC) FILETIME=[D3B6ABB0:01C6AC90] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Is it possible there is too much value being placed on the link indic= ations.. i.e. the mitigation of risk being requested here goes beyond= the value of the 'asset'? We've lived with relatively weak routing p= rotocol mitigation for some time. Although that may need to change, t= he link indications are significantly less risky aren't they? =E2= =80=A8The initial concern about link indications was about reliabilit= y of the eaning of the hint. =20 > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au on behalf of ext Alper = Yegin > Received: Fri Jul 21 04:30:03 EEST 2006 > To: 'Bernard Aboba' > Cc: 'James Kempf', suresh.krishnan@ericsson.com, 'Dna', 'greg Daley= ', 'Jari Arkko (JO/LMF)' > Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-= ietf-dna-link-information-03 >=20 > I think this is a different problem than what we've been discussing= so far. > The former issue was "spoofed indications due to lack of message > authentication." Now what you are talking about is "spoofed indicat= ions due > to misbehavior of authentic peers." >=20 > Dealing with the latter is a *lot* harder problem, which I don't th= ink we > want to deal in DNA WG. (well, probably you are not suggesting that > anyways). >=20 > Alper >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Wednesday, July 19, 2006 7:16 PM > > To: Alper Yegin > > Cc: 'James Kempf'; suresh.krishnan@ericsson.com; 'Dna'; 'greg Dal= ey'; > > 'Jari Arkko (JO/LMF)' > > Subject: RE: [DNA] QUESTION: Remove Link Down information in draf= t-ietf- > > dna-link-information-03 > >=20 > > > I believe that one could reasonably conclude the problem can't = be > > > solved, barring some fundamental change in network to host sign= aling > > > security. Am I missing something here? > >=20 > > I'd observe that the transmission of remoted link status > > indications (including but not limited to "link down") is in pri= nciple no > > different from transmission of Link Status Advertisements (LSAs) > > within a routing protocol. > >=20 > > The question is how the LSAs are secured. Just as transmission l= ayer > > security may not be enough when dealing with injection of faulty > > prefixes by trusted parties (think BGP peers using IPsec or TCP M= D5 to > > protect the session), there are issues that go beyond whether the= remoted > > link status message is secured or not. For example, even if the = message > > were to be signed by the sending router (e.g. via SEND), there wo= uld still > > be the question about whether the sending router was actually on = the path > > or not. > >=20 > > So yes, the problem is hard, but it is more or less the same prob= lem as > > routing protocol security (which is hard). >=20 >=20 >=20 >=20 From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 24 18:56:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G59Ln-0005UR-NK for dna-archive@lists.ietf.org; Mon, 24 Jul 2006 18:56:35 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G59Lk-0003ai-SJ for dna-archive@lists.ietf.org; Mon, 24 Jul 2006 18:56:35 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M577ONECAQ8WXZGB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 25 Jul 2006 08:43:18 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E69DCAB542; Tue, 25 Jul 2006 08:43:13 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A764C4FB02; Tue, 25 Jul 2006 08:43:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k6OMf5p03330 for dna-list; Tue, 25 Jul 2006 08:41:05 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k6OMf4u03326 for ; Tue, 25 Jul 2006 08:41:04 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01M577LVLXRE8WXZGB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 25 Jul 2006 08:41:00 +1000 Received: by localhost (Postfix, from userid 510) id A4EDBAB543; Tue, 25 Jul 2006 08:41:00 +1000 (EST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id C4F264FB05 for ; Tue, 25 Jul 2006 08:40:58 +1000 (EST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id k6OMeru4008912; Mon, 24 Jul 2006 17:40:53 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 17:40:18 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 17:40:18 -0500 Date: Mon, 24 Jul 2006 18:48:31 -0400 From: Suresh Krishnan Subject: Re: [DNA] A Merging Proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Behcet Sarikaya Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <44C54E3F.1010507@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * X-OriginalArrivalTime: 24 Jul 2006 22:40:18.0209 (UTC) FILETIME=[236C9910:01C6AF72] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi Behcet, I raised this issue during the 16ng meeting (since your end proposal [draft-xia-16ng-end-00.txt] was trying to reuse the home agent bit from mipv6 and it was hard to keep track of the bits). I had spoken to the ipv6 chairs regarding the issue. We do not know at this point if it is really a problem to use the last two bits. I would trust the ipv6 chairs and the ADs to think about this and come up with the right recommendation. I would wait a little bit before we choose to switch to an option instead of a bit. Thanks Suresh > Hi JinHyeock, > Please keep the very last two reserved bits left in the RA messages > and introduce options instead. I mentioned this to Suresh in Montreal. > Regards, > --behcet