From dna-owner@webcamserver.eng.monash.edu.au Sun Dec 5 11:07:06 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17883 for ; Sun, 5 Dec 2004 11:07:04 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LI2A9KIUNG8WXRWY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 6 Dec 2004 03:06:51 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 34D978000A; Mon, 06 Dec 2004 03:06:43 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E1C0A3C014; Mon, 06 Dec 2004 03:06:42 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iB5G3ov30312 for dna-list; Mon, 06 Dec 2004 03:03:50 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iB5G3m630308 for ; Mon, 06 Dec 2004 03:03:48 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LI2A5APB9Y8WXRWY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 06 Dec 2004 03:03:17 +1100 Received: by localhost (Postfix, from userid 510) id CD23980009; Mon, 06 Dec 2004 03:03:16 +1100 (EST) Received: from thingmagic.com (tm-gw.cictr.com [207.31.248.245]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0816D3C002; Mon, 06 Dec 2004 03:03:15 +1100 (EST) Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 215435; Sun, 05 Dec 2004 10:56:30 -0500 Date: Sun, 05 Dec 2004 11:03:06 -0500 From: Margaret Wasserman Subject: [DNA] IESG Evaluation of draft-ietf-dna-goals-03.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: jinchoe@samsung.com, greg.daley@eng.monash.edu.au Cc: Thomas Narten , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) Content-Transfer-Encoding: 7BIT Hi JinHyeock and Greg, The IESG reviewed draft-ietf-dna-goals-03.txt on our telechat last Thursday (2-Dec), and I have included our review comments below. There was only one blocking issue (the "discuss" from Thomas), but there were several comments that you will probably want to consider when you update the document to address Thomas' issue. You will need to address Thomas' discuss to his satisfaction before the document will be approved. The comments are merely advice, and it is up to you how/if to reflect them in the new document. Please let me know if you have any questions about this, or if you need any further information to understand the IESG feedback. Margaret Discusses and Comments Harald Alvestrand: Comment: [2004-12-01] Reviewed by Spencer Dawkins, Gen-ART Only one serious concern raised, about the ambition level of goals: 3. Goals for Detecting Network Attachment The DNA working group has been chartered to define an improved scheme for detecting IPv6 network attachment. In this section, we define the goals that any such solutions should aim to fulfil. DNA solutions should correctly determine whether a link change has occurred. Additionally, they should be sufficiently fast so that there would be no or at most minimal service disruption. They should neither flood the link with related signaling nor introduce new security holes. Spencer - concern - is this high-level "should be sufficiently fast" consistent with the 1.5-2-second delays described in section 2 of this document? I guess I'm asking, is interactive voice clearly in scope/out of scope? Russ Housley: Comment: [2004-12-01] In section 3.1, G8: s/man in the middle/man-in-the-middle/ Allison Mankin: Comment: [2004-12-02] Good, clear document The IAB has a good document that's worth your reviewing, including issues of links that can be confusing about whether there is a change or not: draft-iab-link-indications-00.txt Thomas Narten: Discuss: [2004-12-02] These are all pretty minor, so should be easy to fix. > Detecting Network Attachment in IPv6 Goals change to something more readable? > When a host has established a new link-layer connection, it can send > and receive some IPv6 packets at the link, particularly those used > for configuration. On the other hand, the host has full Internet s/at the link/on the link/ s/particularly/including/ > detects the identity of its currently attached link to ascertains the s/ascertains/ascertain/ > refer [10]. s/refer/refer to/ (or "see") > difficult for a single RA message to indicate a link change. Third, > Router Discovery may take too long and result in service disruption. clarify? are there some unstated assumptions being made here? e.g., why doesn't a host just send out an RA immediately upon detecting a link up? Is this "too long"? > Usually a host gets the information necessary for IP configuration > from RA messages. Based on the current definition [1], it's > difficult for a host to check for link change upon a single RA > reception. True, but there are huristics that make good hints. Not absolute, but good hints. > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router > Advertisement sent in response to a Router Solicitation MUST be > delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 > seconds). is this text quoting another RFC? If so, please make that clear. Or, is this document defining normative behavior (which is probably inappropriate for this document). > G2 When upper-layer protocol sessions are being supported, DNA > schemes should detect the identity of an attached link with > minimal latency lest there should be service disruption. What does this mean? In particular, if the intention is that upper-layer communication failures should trigger DNA action, I suspect that is not a good idea. Bert Wijnen: Comment: [2004-12-02] *** matchref -- match citations and references. Input file: draft-ietf-dna-goals-03.txt !! Missing citation for Normative reference: P013 L013: [2] Thomson, S. and T. Narten, "IPv6 Stateless Address !! Missing citation for Informative reference: P013 L031: [7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. !! Missing citation for Informative reference: P013 L035: [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document ----------- Additional comments from OPSDIR review (by Pekka): This is a good document. Substantial issue: ------------------ G1 DNA schemes should detect the identity of the currently attached link to ascertain the validity of the existing IP configuration. They should recognize and determine whether a link change has occurred and initiate the process of acquiring a new configuration if necessary. ==> This may be worth a bit more discussion, and/or splitting to two Goals. Is it an explicit goal that the DNA scheme gets 100% certainty whether a link change has occurred? Or would it be OK to initiate the IP reconfiguration event even if you've received a reasonably strong hint about it (e.g., the link-local or link-layer addresses of a router has changed)? To me, it would seem that in most cases it would be very useful if one would not have to reach absolute certainty of what has happened: the typical IP configuration procedures actually work just fine (there's just a bit of extra signalling) even if there has not been an actual link change. Comment: -------- (There were numerous typos etc. which I have sent to the authors directly.) Section 2.3: [...] Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router Advertisement sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). ==> The text should be clearer that the uppercase keywords are just quoting the specification from RFC2461, not that this spec is making a specification of its own (without defininng the RFC2119 keywords). 5. Security Considerations Because DNA schemes are based on Neighbor Discovery, its trust models and threats are similar to the ones presented in RFC 3756 [6]. ==> this is not given, because we don't know what the DNA scheme will be; using existing mechanisms is also just a goal. A bit of rewording needed here. From dna-owner@webcamserver.eng.monash.edu.au Mon Dec 6 10:50:16 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23773 for ; Mon, 6 Dec 2004 10:50:14 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LI3CG6PZDY8Y56AS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 6 Dec 2004 21:20:12 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E3BB180003; Mon, 06 Dec 2004 21:20:06 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 95B583C00F; Mon, 06 Dec 2004 21:20:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iB6AIPD09108 for dna-list; Mon, 06 Dec 2004 21:18:25 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iB6AIO609104 for ; Mon, 06 Dec 2004 21:18:24 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LI3CDQ2RKW8WWSPO@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Dec 2004 21:18:08 +1100 Received: by localhost (Postfix, from userid 510) id 02976AB542; Mon, 06 Dec 2004 21:18:07 +1100 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 497214FB10; Mon, 06 Dec 2004 21:18:06 +1100 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I8A004GGPY4XB@mailout2.samsung.com>; Mon, 06 Dec 2004 19:18:04 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I8A008H2PVLSA@mailout2.samsung.com>; Mon, 06 Dec 2004 19:16:33 +0900 (KST) Received: from jinchoe ([75.2.91.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I8A00843PVKJK@mmp1.samsung.com>; Mon, 06 Dec 2004 19:16:32 +0900 (KST) Date: Mon, 06 Dec 2004 19:16:32 +0900 From: JinHyeock Choi Subject: Re: [DNA] IESG Evaluation of draft-ietf-dna-goals-03.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Margaret Wasserman , greg.daley@eng.monash.edu.au Cc: Thomas Narten , dna@eng.monash.edu.au, jinchoe@gmail.com, JinHyeock Choi Message-id: <00e001c4db7c$a91faeb0$e95b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) References: Content-Transfer-Encoding: 7BIT Dear Margaret Thanks for your trouble advancing DNA Goals draft. > The IESG reviewed draft-ietf-dna-goals-03.txt on our telechat last > Thursday (2-Dec), and I have included our review comments below. > There was only one blocking issue (the "discuss" from Thomas), but > there were several comments that you will probably want to consider > when you update the document to address Thomas' issue. We'll update the draft to address Thomas' issue. Also we'll reflect IESG comments into the draft. > You will need to address Thomas' discuss to his satisfaction before > the document will be approved. The comments are merely advice, and > it is up to you how/if to reflect them in the new document. ok. > Please let me know if you have any questions about this, or if you > need any further information to understand the IESG feedback. I have a question. Among the following comments of Thomas, which is/are the blocking issue(s)? Thomas Narten: Discuss: [2004-12-02] These are all pretty minor, so should be easy to fix. > Detecting Network Attachment in IPv6 Goals change to something more readable? > When a host has established a new link-layer connection, it can send > and receive some IPv6 packets at the link, particularly those used > for configuration. On the other hand, the host has full Internet s/at the link/on the link/ s/particularly/including/ > detects the identity of its currently attached link to ascertains the s/ascertains/ascertain/ > refer [10]. s/refer/refer to/ (or "see") > difficult for a single RA message to indicate a link change. Third, > Router Discovery may take too long and result in service disruption. clarify? are there some unstated assumptions being made here? e.g., why doesn't a host just send out an RA immediately upon detecting a link up? Is this "too long"? > Usually a host gets the information necessary for IP configuration > from RA messages. Based on the current definition [1], it's > difficult for a host to check for link change upon a single RA > reception. True, but there are huristics that make good hints. Not absolute, but good hints. > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router > Advertisement sent in response to a Router Solicitation MUST be > delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 > seconds). is this text quoting another RFC? If so, please make that clear. Or, is this document defining normative behavior (which is probably inappropriate for this document). > G2 When upper-layer protocol sessions are being supported, DNA > schemes should detect the identity of an attached link with > minimal latency lest there should be service disruption. What does this mean? In particular, if the intention is that upper-layer communication failures should trigger DNA action, I suspect that is not a good idea. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Dec 10 07:59:57 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11225 for ; Fri, 10 Dec 2004 07:59:55 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LI9367C7468WXWVW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 10 Dec 2004 23:59:42 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BF39EAB558; Fri, 10 Dec 2004 23:59:30 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 77E7A4FB03; Fri, 10 Dec 2004 23:59:30 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iBACtfj10575 for dna-list; Fri, 10 Dec 2004 23:55:41 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iBACtf610571 for ; Fri, 10 Dec 2004 23:55:41 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LI931778BI8Y5TQ7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 10 Dec 2004 23:55:29 +1100 Received: by localhost (Postfix, from userid 510) id DB653AB554; Fri, 10 Dec 2004 23:55:28 +1100 (EST) Received: from n2.nomadiclab.com (unknown [193.234.219.2]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4AC1D4FB0A for ; Fri, 10 Dec 2004 23:55:27 +1100 (EST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id D40E2212E96 for ; Fri, 10 Dec 2004 14:55:21 +0200 (EET) Received: from [IPv6:::1] (n2.nomadiclab.com [193.234.219.2]) by outside.nomadiclab.com (Postfix) with ESMTP id B94BB113E67 for ; Fri, 10 Dec 2004 14:55:21 +0200 (EET) Date: Fri, 10 Dec 2004 14:55:22 +0200 From: Pekka Nikander Subject: [DNA] Compiling minutes Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) Content-Transfer-Encoding: 7BIT Folks, I just want to let you know that I am finally compiling the minutes for the Washington meeting. Sorry for the delay. I expect to get them compiled later today, and due to the deadline, I have to send them right away to the secretary. However, we have time to check the minutes and send a revision until December 23rd. I am sorry for the trouble. --Pekka Nikander From dna-owner@webcamserver.eng.monash.edu.au Fri Dec 10 14:46:56 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10268 for ; Fri, 10 Dec 2004 14:46:53 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LI9HDI5YGU8Y6227@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 11 Dec 2004 06:46:43 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A34CAB555; Sat, 11 Dec 2004 06:46:15 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0B27E4FB05; Sat, 11 Dec 2004 06:46:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iBAJjEZ14972 for dna-list; Sat, 11 Dec 2004 06:45:14 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iBAJj2614968 for ; Sat, 11 Dec 2004 06:45:03 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LI9HBW7X8C8WXXFZ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 11 Dec 2004 06:44:58 +1100 Received: by localhost (Postfix, from userid 510) id 090CE80002; Sat, 11 Dec 2004 06:44:57 +1100 (EST) Received: from n2.nomadiclab.com (unknown [193.234.219.2]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8C3BC3C00A for ; Sat, 11 Dec 2004 06:44:54 +1100 (EST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 770DB212F9E for ; Fri, 10 Dec 2004 21:44:53 +0200 (EET) Received: from [IPv6:::1] (n2.nomadiclab.com [193.234.219.2]) by outside.nomadiclab.com (Postfix) with ESMTP id BC75D113E67 for ; Fri, 10 Dec 2004 21:44:52 +0200 (EET) Date: Fri, 10 Dec 2004 21:44:53 +0200 From: Pekka Nikander Subject: [DNA] Washington meeting minutes Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: multipart/mixed; boundary="Boundary_(ID_4xT+3k08aiASE90Y6/9isA)" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) --Boundary_(ID_4xT+3k08aiASE90Y6/9isA) Content-type: text/plain; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 7BIT Folks, I just submitted the enclosed Washington meeting minutes to the proceedings. Please check that they correctly convey what you meant to say, and send any corrections to me. I need to submit any corrected version to the secretariat by Dec 23rd, so please send your corrections to me latest on Dec 17th. --Pekka Nikander --Boundary_(ID_4xT+3k08aiASE90Y6/9isA) Content-type: text/html; name=ietf61_dna_minutes.html; x-unix-mode=0644 Content-disposition: attachment; filename=ietf61_dna_minutes.html Content-Transfer-Encoding: 7BIT IETF-61 DNA WG minutes

Detecting IPv6 Network Attachment (DNA) Working Group

These are the minutes for the Detecting IPv6 Network Attachement (DNA) working group meeting, held at the 61st IETF meeting on Monday, November 8, 2004, at Hilton Washington. Thanks to Michael Richardson and James Kempf, for the notes, on which these minutes are based on.

Presentations and Discussion

Agenda and Document status

The DNA goals draft had been submitted to the IESG for consideration to be published as an Informational RFC. The chairs expressed their thanks to the editor, JinHeyock Choi, for his hard work. For the other documents, see the explicit presentations below

Link Layer Events and Notifications for DNA

Eric Nejdjou gave a presentation about the DNA link indications draft. Currently the draft covers only a few different link technologies, and it was decided already in the previous meeting to add coverage for new technologies.

One particular confusing area appears to be in connection to using PPP and GPRS. In particular, for the final end-host (like a laptop) the actual IP link appears as a PPP link, not as a GPRS link. Hence, in that scenario the "link up" event is generated when NCP concludes. The situation is somehwat different when ther eis no PPP link, e.g. when a 3GPP handset is directly communicating using IP. There are also differences in address assignment in PPP, and this seems to be confusing people.

Bernard Aboba:
Are you proposing a new IP address assignment mechanisms, delivering the IPv6 address directly from the PDP context, i.e., without router adverticements.
Hesham Soliman:
No. When PPP is not used, the RA/RS gives you the address, but PPP gives it when it is used.
Greg Daley:
In the IPv6 case, PPP does not deliver the address. It just hands over a unique interface identifier token, which can be used to construct a link local IP address.
Bernard Aboba:
From the application point of view, that is not a link up event. You don't have a globally routable IP address.
Pekka Nikander:
The link is up for IP, not for apps. These are two different events.
Bernard Aboba:
The draft does not make this clear. There is lack of clarity on how IPv6 address assignment works in this case.
Erik Nordmark:
The situation is similar when running IPv6 over ethernet. There is a difference between the event when the link is up for IP and when it is ready for apps.

(Some more discussion about IPv6 address assignment; the editor couldn't make sense about the notes.)

Rajeev Koodli:
Look at som 3GPP2 proposals, they have something on this.
Hesham Soliman:
If you can't get an IP address directly from PPP, then this is a large problem, not just 3GPP.
Pete McCann:
3GPP2 still runs RS/RA, they use PPCP to get the interface identifier only.
Pekka Nikander (chairing):
There seems to be some serious problems in the draft, maybe already in the introduction. It looks like that we need more people working on the draft to get this right.
Eric Nejdjou:
Applications never need to interpret link events.
Greg Daley (chairing):
Let's take this to the list.
Greg Daley (chairing):
Should we add a section on 802.16 link hints? Are there any commercial interest on this?
James Kempf
No, we shouldn't touch 802.16 yet. The 802.16 mobility features are not mature enough yet. We shoudld wait until it has been cleaned up.
Ralph Droms:
Let's wait until IEEE gets the document in order.
Greg Daley (chairing):
How about 802.3 then? We definitely should have a section on that. Any volunteers?

Editor's note: No volunteers during the face-to-face meeting, but one was found afterwards.

Best Current Practice (BCP) drafts

Sathya Narayanan gave a presentation about a draft proposed as a baseline for the WG BCP draft.

JinHyeock Choi:
Why so much emphasis on bi-directional reachability? Partial connectivity is enough.
Speaker:
If you can easily check bi-directional reachability, why not? I agree that partial reachability works, but it is much harder to check for it. You need to check the reachability of the current default router anyway; that is part of what you just have to do. Hence, why just not do it?
Erik Nordmark:
Do you check the reachability of all last hop routers, e.g., the all 17 of them?
Speaker:
Do you mean that we need partial reachability with all of them in order to perform DNA?
Erik Nordmark:
According to RFC 2461, some connections may go out over some routers, other on others.
Greg Daley:
"Before proceeding" set NC state to "stale". May take 8 seconds.
Eric Njedjou (?)
After you have decided or when probably moved?
Greg Daley:
It might still be the same link. If you have an AP that says you've received an RA, that doesn't guarantee that you can send something up through the router, may be discontinuous.
Eric Njedjou (?)
The issue is to detect if you are moving at all? To detect if you are on a new network or the same. Or is it that wireless behaves differently?
Greg Daley:
Different link layers may have different failure characteristics.
Jinheyock Choi:
Sure it would be nice to perform bi-directional reachability checks, but not right as a part of the DNA.
Hesham Soliman:
Are we trying to detect if we are on a new link or if the IP configuration is still okay?
Greg Daley:
Yes (laughter).
Hesham Soliman:
These are two different types of actions. The question is when to send an RS.
Greg Daley:
That will be covered in additional recommendations.
Jinheyock Choi:
Is DNA by check for link change or by IP config change?
Speaker:
It is not a clear either-or. It could be based on explicit link od, or address validation, or default router.
Vijay Depravalli:
The default router's adverticements may not include all the prefixes.
Greg Daley:
We need to define what is the best practice for router configuration. For example, if it helps to have overlapping prefixes advertised by different routers on the link, we should define it.
Speaker:
Define the Best Current Practice, within the current standards. Follow these procedures and things will get better. For example, what is the preferred timer ranges. How about recommending a subset of the existing range.
Hesham Soliman
There is no real current practice here. Buf if we recommend something, it depends on the context in which say that. For example, if we want to have short beacons, the prefixes should be sent once. Hence, the recommendations will necessarily have some context dependencies.
Pekka Nikander (chairing)
We should remember that one of the primary reasons for the DNA WG to exist is that it is hard to detect link change and update the configuration within the current standards. Remember that we have also the solutions work, which is separate from this BCP work.
Greg Daley:
The intention is that the hosts are able to work in any access network, regardless of whether or not the networks have the tweaks.
Pekka Nikander:
If we suggest something for the routers, we have to remember that many people won't do it, i.e., they will not tweak the parameters to get better performance. Rather we might want to focus more on the host side; how to get reasonable results there.
James Kempf:
We should also include advice for network designers, how to lay out their networks, too.
Pekka Nikander:
Right, mostly host but also network.
Christian Huitema:
We should tell the network managers about the consequences, i.e., identify the tredoffs in configuration. That is, you can do various things, but if you do, you may gain flexibility but make roaming more difficult.
Erik Nordmark:
This sounds like two BCPs. One for host implementors, telling them how to make the hosts to behave better however the routers are configured. The other one on how one would configure a router, network, etc.

(Sens of the room on two drafts, majority favouring)

Rajeev Koodli:
Do you need two separate documents?
Vijay Depravalli:
Are we describing what is out there, or recommending a solution?
Greg Daley:
An example is CPL, which is a good idea in certain situations. We want to illustrate tradeoffs and certain configurations within the boundaries of the existing protocols.
Vijay Depravalli:
If recommending configuration, couldn't that involve both the mobile node and the router. Hence, shouldn't we just have one document?
Erik Nordmark:
If the document is split, then one half will not delay the other, since the review communities are very different.
Hesham Soliman:
There is likely to be dependencies between host recommendations and route recommendations.
Pekak Nikander:
The CPL work should go into the host document.
Jinheyock Choi:
The discussion about CPL is more fruitful after the CPL presentation. The slide is misleading.
Pekka Nikander:
I think we need a separate document focusing on hosts, maybe build around the CPL work.

Erik Nordmark gave a brief presentation about the current status of the CPL work.

Solutions framework

JinHeyock Choi gave a presentation about the solutions framework document.

Greg Daley:
Should we make this a working group document? We might merge this with the eventual solution.
Pekka Nikander:
Should we adopt this, run a quick last call, and submit to the IESG for informational?
Vijay Depravalli:
What if the outlined solution does not work; shouldn't we have a link identifier draft first?
Pekka Nikander:
If it turns out that the outlined solution does not work, we can change the RFC status to historical.
Vijay Depravalli:
Shouldn't this rather be a document that you take through with an implementation?
Greg Daley:
We have various options.
Erik Nordmark:
There is some issue with interactions with the IPv6 WG, optimistic DAD. Maybe we should send a message to them that we expect them to do something.
Greg Daley:
The IPv6 WG is proceeding with Opti-DAD. Our solutions are not that advanced. The tentative link layer address is not yet baked.
Sathya Narayanan:
Should we accept this as a WG item or not?
Pekka Nikander (chairing):
Two questions:
  • Should we accept this as a WG item or not?
  • Should we proceed quickly with this?

Consensus in the room to adopt the document as a WG item.

Sathya Narayanan:
Let's make a compromise, not submit it immediately, but wait until the solutions work is halfway done.
Samita Chakrabarti:
The document discusses several solutions in a framework. Is the purpose is to describe a framework for different solutions in different cases, or requirements?
Pekka Nikander:
We should think about this as a framework for thought, something that we can use when thinking about solutions. The aim is to standardise a single solution in the end. There are possibilities in this document.

Individual solutions discussion

Chairs:
The plan is to set up a design team of people tha thave worked on the solutions. The design team then should come up with a single solution.

Greg Daley gave a brief presentation about Fast Router Discovery with RA caching, basically nothing that the proposal crosses layers 2 and 3, and enters a grey area for the IETF. The access points are modified. It does not modify packet formats.

Hesham Soliman:
This is applicable only if the access point is separated from the access router, and there is no protocol to inform the access router about entering hosts.
Jinheyock Choi:
Some link layers won't need this.
Greg Daley:
It is trivial to include this kind of functionality if you have a single access router acting also as the access point.
Hesham Soliman:
The RA is sent by the MAC layer here. I see this applicable only to WLAN where the AP is separate from the router.
Erik Nordmark:
The generalized technique applies always, also when L2 and L3 are combined.
Vijay Depravalli:
We want to make sure that the AP cahces the most recent RAs. The AP needs to check every packet to see if its IPv6, if the destination address is multicast etc.

(Presentation continues)

Chairs:
We recommed continuing this work as experimental, either within our outside of the working group.
Rajeev Koodli:
So, you cache new router RA on AP. What about SEND, RA/RS, grey area, could attach to rogue AP, to what do you point?
Greg Daley:
If SEND is used, you can't accept RA until you have checked authorization. That would require addtional exchange anyway.
Rajeev Koodli:
We have to consider the host and ARw security.
Hesham Soliman:
No strong disagreement to move forward, but limited applicability. There is the danger of replay attack, no strong need. This needs a strong applicability statement.
Sathya Narayanan:
If you have multiple rotuers, how do you make choice about which RA to send?
Greg Daley:
That is not clear.
Jinheyock Choi:
When a host makes a new connection, l2 knows, l3 doesn't. AP or base station initiates RA earliest possible time. AP in 802.11 specific case.
Rajeev Koodli:
Many APs today are capable of doing some IP stuff.
Chairs:
We propose experimental. Should we proceed within the working group or as individual work. Anybody interested.

Only one hand in addition to the authors.

Chairs:
Continue as individual draft, but solicit people to do external review.

Greg Daley gave a brief presentation about Deterministic Fast Router Advertisement Configuration.

Brett Petland gave a brief presentation about Router Advertisement Link Identifiers.

Pekka Nikander:
Have hash of all prefixes of link?
Speaker:
Was considered, too complex, need to keep track of all prefixes on link, need to detect and change link id.
Greg Daley:
Tradeoff between large unique number or something that only has local unique properties.
Speaker:
Simpler to pick a large random number. More overhead though.
Erik Nordmark:
First, a prefix option with no other flag set has no semantics. The host only acts when one or more flag bits are set. One possibility is to advertise a prefix for the purpose of being a link id, with no other bits set. Second, we have to consider how long it takes for a link id to experire and how long does it take for one to travel. You travel around world w. laptop suspended. How long is the travel time and how long is the expiry time? The host will forget. Limit times when collisions occur. How bad is it?
Erik Nordmark:
NC goes to stale. One of addresses may have a preferred lifetime, move, get another prefix, think old prefix is valid because lifetime hasn't expired.
Tony Hain:
Any concept using prefixes is wrong, prefix will change, don't want link id to change when prefix changes. 48 bits, local prefix. Use 64 bits to pad. Global ids won't work.

Sathya Narayanan gave a presentation about Router Reachability Detection.

Greg Daley:
Failings of DRA is that some hosts will pick up same router, change which responds fastest, all routers know which order to respond, router to respond first, others delay around list. If router not part of list, DRA rules. If not in list, then sent quickly.
Erik Nordmark:
Does this draft propose that all routers agree what designated prefix is?
Speaker:
No.
Erik Nordmark:
Used router and prefix. Are they still there?
Speaker:
Yes. Two different hosts have two different ids.

(Some discussion missed.)

Sathya Narayanan gave a presentation comparing the approaches.

Summary

  1. The Link ID draft apparently needs more work.
  2. Aim for two BCPs, one for hosts, one for network configuration.
  3. Adopt the solutions framework as a WG draft. No consensus on the pace of going foward, discuss this on the list. Does not restrict the design team work.
  4. RA caching as individual experimental until more interest.
    Jinheyock Choi:
    The chairs did not ask author, chairs did not mention presentation to him beforhand.
    It appears that there were communication problems between the author and the chairs, and therefore this decision was decided to be made void and to be reconsidered on the mailing list.
  5. The chairs will form a design team that will consider the various solutions drafts, with the goal of coming up with a proposal of how to go foward at the next IETF meeting.

Consensus call on forming a DT; about 20 hands in favour, no one objecting.

Valid XHTML 1.0!

Copyright  ©  2004 Internet Engineering Task Force.

--Boundary_(ID_4xT+3k08aiASE90Y6/9isA)-- From dna-owner@webcamserver.eng.monash.edu.au Thu Dec 16 11:57:52 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12936 for ; Thu, 16 Dec 2004 11:57:50 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIHP8H6FMC8Y5HOZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 17 Dec 2004 03:57:42 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ACB54AB543; Fri, 17 Dec 2004 03:57:36 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 59DE04FB12; Fri, 17 Dec 2004 03:57:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iBGGsLM11174 for dna-list; Fri, 17 Dec 2004 03:54:21 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iBGGsI611168 for ; Fri, 17 Dec 2004 03:54:18 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIHP41TNRY8WXYDH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 17 Dec 2004 03:54:03 +1100 Received: by localhost (Postfix, from userid 510) id B010A80002; Fri, 17 Dec 2004 03:54:02 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3A49D3C00E for ; Fri, 17 Dec 2004 03:54:00 +1100 (EST) Received: by rproxy.gmail.com with SMTP id r35so35475rna for ; Thu, 16 Dec 2004 08:53:59 -0800 (PST) Received: by 10.38.207.1 with SMTP id e1mr1494154rng; Thu, 16 Dec 2004 08:53:59 -0800 (PST) Received: by 10.38.125.40 with HTTP; Thu, 16 Dec 2004 08:53:58 -0800 (PST) Date: Fri, 17 Dec 2004 01:53:58 +0900 From: JinHyeock Choi Subject: Re: [DNA] IESG Evaluation of draft-ietf-dna-goals-03.txt In-reply-to: <00e001c4db7c$a91faeb0$e95b024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: Margaret Wasserman , Thomas Narten Cc: greg.daley@eng.monash.edu.au, Pekka Nikander , dna@eng.monash.edu.au, JinHyeock Choi , JinHyeock Choi Reply-to: JinHyeock Choi Message-id: <92e919fb04121608532bc9ed22@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=h6CfqQt4V17C9T3ZZa/j1e7HzCfha0N7uAsa6oqXZLvdCcKT9UhVz8bES5hUlBU5q61cWjXDPXIkV6pVK1oNiEmrxUn+b09O+vVayGF+XjuOzOGshVQPULG3TbxhLaJbTnNKtKnZAQtGQTRH/Jq1jWxOMaODLvhKDpMj+VAFU6Y= X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) References: <00e001c4db7c$a91faeb0$e95b024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear Margaret We discussed with Thomas to address his discuss and believe that we have reached an understanding. We reflected IESG review, both discuss & comments, to update the draft and the current version is available at http://www.diffeo.com/drafts/draft-ietf-dna-goals-04.txt Kindly find in-line comments. > Discusses and Comments > Harald Alvestrand: > Comment: > [2004-12-01] Reviewed by Spencer Dawkins, Gen-ART > > Only one serious concern raised, about the ambition level of goals: > > 3. Goals for Detecting Network Attachment > > The DNA working group has been chartered to define an improved scheme > for detecting IPv6 network attachment. In this section, we define > the goals that any such solutions should aim to fulfil. > > DNA solutions should correctly determine whether a link change has > occurred. Additionally, they should be sufficiently fast so that > there would be no or at most minimal service disruption. They should > neither flood the link with related signaling nor introduce new > security holes. > > Spencer - concern - is this high-level "should be sufficiently fast" > consistent with the 1.5-2-second delays described in section 2 of > this document? I guess I'm asking, is interactive voice clearly in > scope/out of scope? 1.5-2 second delays in Sec 2 indicate the current state of art. They are the delays related to particular DNA schemes. DNA process can be faster & interactive voice is clearly in scope. > Russ Housley: > Comment: > [2004-12-01] In section 3.1, G8: s/man in the middle/man-in-the-middle/ ok. > Allison Mankin: > Comment: > [2004-12-02] Good, clear document > > The IAB has a good document that's worth your reviewing, including issues > of links that can be confusing about whether there is a change or not: > > draft-iab-link-indications-00.txt Thanks. > Thomas Narten: > Discuss: > [2004-12-02] These are all pretty minor, so should be easy to fix. > > > Detecting Network Attachment in IPv6 Goals > > change to something more readable? With Thomas' suggestion, we have changed the title to Goals of Detecting Network Attachment in IPv6 > > When a host has established a new link-layer connection, it can send > > and receive some IPv6 packets at the link, particularly those used > > for configuration. On the other hand, the host has full Internet > > s/at the link/on the link/ > s/particularly/including/ ok. > > detects the identity of its currently attached link to ascertains the > > s/ascertains/ascertain/ ok. > > refer [10]. > > s/refer/refer to/ (or "see") ok. > > difficult for a single RA message to indicate a link change. Third, > > Router Discovery may take too long and result in service disruption. > > clarify? are there some unstated assumptions being made here? e.g., > why doesn't a host just send out an RA immediately upon detecting a > link up? Is this "too long"? After discussing with Thoams, we have changed the above to ............................................. Third, the current Router Discovery specification specifies that routers wait a random delay of 0-.5 seconds prior to responding with a solicited RA. This delay can be significant and may result in service disruption. > > Usually a host gets the information necessary for IP configuration > > from RA messages. Based on the current definition [1], it's > > difficult for a host to check for link change upon a single RA > > reception. > > True, but there are huristics that make good hints. Not absolute, but > good hints. We wish to make those good hints into better confirmation. We found out that a few factors such as 'link-local router address' or 'prefix omission', may result in a false link change detection. We explained more about the difficulties/ ambiguities concerning link identity detection with a single RA reception in Sub-sec 2.2 'Link identity detection with a single RA'. > > Before a host sends an initial solicitation, it SHOULD delay the > > transmission for a random amount of time between 0 and > > MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router > > Advertisement sent in response to a Router Solicitation MUST be > > delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 > > seconds). > > is this text quoting another RFC? If so, please make that clear. Or, > is this document defining normative behavior (which is probably > inappropriate for this document). After discussing with Thoams, we have changed the above to According to RFC 2461 [1]: - before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second). - Furthermore, any Router Advertisement sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). > > G2 When upper-layer protocol sessions are being supported, DNA > > schemes should detect the identity of an attached link with > > minimal latency lest there should be service disruption. > > What does this mean? In particular, if the intention is that > upper-layer communication failures should trigger DNA action, I > suspect that is not a good idea. No, that is not our intention. We put 'upper-layer' part to underline the necessity of a fast DNA procedure. However, it seems that the part is not so much illuminating as confusing. So we have removed the part all together as below. G2 DNA schemes should detect the identity of an attached link with minimal latency lest there should be service disruption. > Bert Wijnen: > Comment: > [2004-12-02] *** matchref -- match citations and references. > Input file: draft-ietf-dna-goals-03.txt > > !! Missing citation for Normative reference: > P013 L013: [2] Thomson, S. and T. Narten, "IPv6 Stateless Address > > !! Missing citation for Informative reference: > P013 L031: [7] Droms, R., Bound, J., Volz, B., Lemon, T., > Perkins, C. and M. > > !! Missing citation for Informative reference: > P013 L035: [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP > Security Document We have removed all un-cited refs. > Additional comments from OPSDIR review (by Pekka): > > This is a good document. > > Substantial issue: > ------------------ > > G1 DNA schemes should detect the identity of the currently attached > link to ascertain the validity of the existing IP configuration. > They should recognize and determine whether a link change has > occurred and initiate the process of acquiring a new configuration > if necessary. > > ==> This may be worth a bit more discussion, and/or splitting to two > Goals. Is it an explicit goal that the DNA scheme gets 100% certainty > whether a link change has occurred? Or would it be OK to initiate the > IP reconfiguration event even if you've received a reasonably strong > hint about it (e.g., the link-local or link-layer addresses of a > router has changed)? We aims 'No false positive' but, if necessary, a reasonable false error rate is acceptable. WG will decide what reasonable/ acceptable error rate will be. We plan to design a DNA scheme with negligible, hopefully infinitesimal, error rate. > To me, it would seem that in most cases it would be very useful if one > would not have to reach absolute certainty of what has happened: the > typical IP configuration procedures actually work just fine (there's > just a bit of extra signalling) even if there has not been an actual > link change. It may be ok for a host to falsely assume a link change when it remains at the same link. However, the inverse case that a host fails to detect a link change may cause more serious problem. For example, if a host checks for link change with the link-local address of its default router, it may fail to detect a chance and experience a service disruption. > Section 2.3: > [...] > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router > Advertisement sent in response to a Router Solicitation MUST be > delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 > seconds). > > ==> The text should be clearer that the uppercase keywords are just > quoting the specification from RFC2461, not that this spec is making a > specification of its own (without defininng the RFC2119 keywords). ok. > 5. Security Considerations > > Because DNA schemes are based on Neighbor Discovery, its trust models > and threats are similar to the ones presented in RFC 3756 [6]. > > ==> this is not given, because we don't know what the DNA scheme will > be; using existing mechanisms is also just a goal. A bit of rewording > needed here. We have changed the above to DNA process is intimately related to Neighbor Discovery protocol [1] and its trust model and threats have much in common with the ones presented in RFC 3756 [5]. Kindly let us know if there still is a blocking issue for the draft. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Dec 16 11:58:57 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13049 for ; Thu, 16 Dec 2004 11:58:56 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIHP9OM8TO8WXXL3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 17 Dec 2004 03:58:45 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 08D6DAB544; Fri, 17 Dec 2004 03:58:35 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B1C754FB0F; Fri, 17 Dec 2004 03:58:34 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iBGGwXb11245 for dna-list; Fri, 17 Dec 2004 03:58:33 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iBGGwW611241 for ; Fri, 17 Dec 2004 03:58:32 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIHP9CD7EM8WXXL3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 17 Dec 2004 03:58:18 +1100 Received: by localhost (Postfix, from userid 510) id AAA0DAB543; Fri, 17 Dec 2004 03:58:17 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4E8E84FB0F for ; Fri, 17 Dec 2004 03:58:15 +1100 (EST) Received: by rproxy.gmail.com with SMTP id a41so1409895rng for ; Thu, 16 Dec 2004 08:58:14 -0800 (PST) Received: by 10.38.152.70 with SMTP id z70mr2345398rnd; Thu, 16 Dec 2004 08:58:10 -0800 (PST) Received: by 10.38.125.40 with HTTP; Thu, 16 Dec 2004 08:58:10 -0800 (PST) Date: Fri, 17 Dec 2004 01:58:10 +0900 From: JinHyeock Choi Subject: [DNA] DNA in IPv6 Goals 04 I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna , Pekka Nikander , Greg Daley , JinHyeock Choi Reply-to: JinHyeock Choi Message-id: <92e919fb04121608584dfbc8c5@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CjqHmA2tfbpf3gWYnCh1jPByHLYN6PzCL2iw4HuTOVlcWp4ojt1ZNqH+FYkzkoTM31Gp9KmMVhNfiZjTv8iOxn1qi/ZPf89E+GcmLl+PTgzMEiWFOMiQdBQwK+5JQyScM7vJ2y5qRhD3L1YgyBAiOFVVPk7B6dYuTYSes4redMw= X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) Content-Transfer-Encoding: 7BIT Dear DNA WG We discussed with Thomas to address his discuss and believe that we have reached an understanding. We reflected IESG review, both discuss & comments, to update the draft and the current version is available at http://www.diffeo.com/drafts/draft-ietf-dna-goals-04.txt Aside editorials, these are the main changes. 1st, reflecting Thomas' comment, we have changed the title to Goals of Detecting Network Attachment in IPv6 2nd, reflecting Spencer's comment, we have changed In practice, the host doesn't know which of its addresses are valid on the newly attached link. The host knows neither if its existing default router is on this link, nor whether its neighbor cache entries are valid. to In practice, the host doesn't know which of its addresses are valid on the newly attached link. It also doesn't know whether its existing default router is on this link nor if its neighbor cache entries are valid. 3rd, reflecting Spencer's comment, we have changed ...................................On the other hand, the host has full Internet connectivity only when it is able to exchange packets with arbitrary destinations. to ......................On the other hand, the host has Internet connectivity only when it is able to exchange packets with off-link destinations. 4th, reflecting Thomas' comment, we have changed .............Third, Router Discovery may take too long and result in service disruption. to .......................................Third, the current Router Discovery specification specifies that routers wait a random delay of 0-.5 seconds prior to responding with a solicited RA. This delay can be significant and may result in service disruption. 5th, reflecting Thomas & Pekka's comment, we have changed Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router Advertisement sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). to According to RFC 2461 [1]: - before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second). - Furthermore, any Router Advertisement sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). 6th, reflecting Thomas & Spencer's comment, we have changed G2 When upper-layer protocol sessions are being supported, DNA schemes should detect the identity of an attached link with minimal latency lest there should be service disruption. to G2 DNA schemes should detect the identity of an attached link with minimal latency lest there should be service disruption. We put 'upper-layer' part to underline the necessity of a fast DNA procedure. However, it seems that the part is not so much illuminating as confusing. So we have removed the part all together. 7th, reflecting Pekka's comment, we have changed Because DNA schemes are based on Neighbor Discovery, its trust models and threats are similar to the ones presented in RFC 3756 [6]. to DNA Process is intimately related to Neighbor Discovery protocol [1] and its trust model and threats have much in common with the ones presented in RFC 3756 [5]. 8th, reflecting Bert Wijnen's comment, we have removed all un-cited refs. Kindly give your opinion whether everything is all right. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Dec 17 03:56:50 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25532 for ; Fri, 17 Dec 2004 03:56:48 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LIIMQHE3628Y7M28@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 17 Dec 2004 19:56:43 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E004BAB543; Fri, 17 Dec 2004 19:56:37 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 974434FB08; Fri, 17 Dec 2004 19:56:37 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iBH8s6521421 for dna-list; Fri, 17 Dec 2004 19:54:06 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iBH8s5621417 for ; Fri, 17 Dec 2004 19:54:05 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIIMN48O7G8WY2FD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 17 Dec 2004 19:53:55 +1100 Received: by localhost (Postfix, from userid 510) id 051E4AB542; Fri, 17 Dec 2004 19:53:54 +1100 (EST) Received: from n2.nomadiclab.com (unknown [193.234.219.2]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6A7D94FB12; Fri, 17 Dec 2004 19:53:53 +1100 (EST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 14028212F96; Fri, 17 Dec 2004 10:53:50 +0200 (EET) Date: Fri, 17 Dec 2004 10:53:49 +0200 From: Pekka Nikander Subject: [DNA] Re: DNA in IPv6 Goals 04 I-D In-reply-to: <92e919fb04121608584dfbc8c5@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , Dna , Greg Daley Message-id: <2B2F9793-5009-11D9-977D-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) References: <92e919fb04121608584dfbc8c5@mail.gmail.com> Content-Transfer-Encoding: 7BIT > We discussed with Thomas to address his discuss and believe > that we have reached an understanding. > Aside editorials, these are the main changes. > Kindly give your opinion whether everything is all right. Looks good to me. --Pekka Nikander From dna-owner@webcamserver.eng.monash.edu.au Fri Dec 17 09:11:24 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20315 for ; Fri, 17 Dec 2004 09:11:24 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIIXPE0RR48Y6JCE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 18 Dec 2004 01:11:13 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 45A0C80003; Sat, 18 Dec 2004 01:11:06 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 030F33C00F; Sat, 18 Dec 2004 01:11:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iBHEAbG25295 for dna-list; Sat, 18 Dec 2004 01:10:37 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iBHEAZ625291 for ; Sat, 18 Dec 2004 01:10:35 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIIXOEEUII8Y6JCE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 18 Dec 2004 01:10:18 +1100 Received: by localhost (Postfix, from userid 510) id 7BA9EAB544; Sat, 18 Dec 2004 01:10:18 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by moe.its.monash.edu.au (Postfix) with ESMTP id 736D54FB03 for ; Sat, 18 Dec 2004 01:10:16 +1100 (EST) Received: by rproxy.gmail.com with SMTP id r35so59307rna for ; Fri, 17 Dec 2004 06:10:15 -0800 (PST) Received: by 10.38.13.53 with SMTP id 53mr117196rnm; Fri, 17 Dec 2004 06:10:15 -0800 (PST) Received: by 10.38.125.40 with HTTP; Fri, 17 Dec 2004 06:10:15 -0800 (PST) Date: Fri, 17 Dec 2004 23:10:15 +0900 From: JinHyeock Choi Subject: [DNA] Re: DNA in IPv6 Goals 04 I-D In-reply-to: <2B2F9793-5009-11D9-977D-000D9331AFB0@nomadiclab.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: JinHyeock Choi , Dna , Greg Daley Reply-to: JinHyeock Choi Message-id: <92e919fb04121706107fb3c0af@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kRLfQmBZCrCVStv454CYSIPA0vxcx2mhVIXJOrRNmzggrkY9SQYTjTQWY357J3f6CeeJZBm8ZHJnPklDrFIDkiPCxpSXF77kmbXevBcd2mLaEzq0yZjWPj68dpBIMI2Eqndp6nC2KSlYYkzQPjYDslvXXg12HnAFQQ2T7npteZQ= X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) References: <92e919fb04121608584dfbc8c5@mail.gmail.com> <2B2F9793-5009-11D9-977D-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Dear WG Greg kindly produced HTML diff that is online at: http://www.ctie.monash.edu.au/dna/draft-ietf-dna-goals-04-from-3.diff.html Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Dec 27 15:38:49 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20018 for ; Mon, 27 Dec 2004 15:38:47 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIXA6BS2Z48Y7MMV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Dec 2004 07:38:42 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D1C07AB543; Tue, 28 Dec 2004 07:38:39 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 861F04FB08; Tue, 28 Dec 2004 07:38:39 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iBRKb5M20019 for dna-list; Tue, 28 Dec 2004 07:37:05 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iBRKb1620015 for ; Tue, 28 Dec 2004 07:37:02 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LIXA49K6NA8WY9HS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 28 Dec 2004 07:37:00 +1100 Received: by localhost (Postfix, from userid 510) id 4A6D4AB542; Tue, 28 Dec 2004 07:37:00 +1100 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by moe.its.monash.edu.au (Postfix) with ESMTP id C46B84FB06 for ; Tue, 28 Dec 2004 07:36:53 +1100 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19763; Mon, 27 Dec 2004 15:36:50 -0500 (EST) Date: Mon, 27 Dec 2004 15:36:50 -0500 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-goals-04.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: <200412272036.PAA19763@ietf.org> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_cPwvXSLdSryYATLP7qeVjw)" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) --Boundary_(ID_cPwvXSLdSryYATLP7qeVjw) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 Goals Author(s) : J. Choi, G. Daley Filename : draft-ietf-dna-goals-04.txt Pages : 15 Date : 2004-12-27 At the time a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change, i.e. determine whether a link change has occurred, and then, based on the result, it can automatically decide whether its IP configuration is still valid or not. During link identity detection, the host may also collect necessary information to initiate a new IP configuration for the case that the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure and of limited signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-goals-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dna-goals-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_cPwvXSLdSryYATLP7qeVjw) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_kbG4WKAuqfoUuUhrFwBjcw)" --Boundary_(ID_kbG4WKAuqfoUuUhrFwBjcw) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-27154717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-goals-04.txt --Boundary_(ID_kbG4WKAuqfoUuUhrFwBjcw) Content-type: Message/External-body; name=draft-ietf-dna-goals-04.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-goals-04.txt Content-Type: text/plain Content-ID: <2004-12-27154717.I-D@ietf.org> --Boundary_(ID_kbG4WKAuqfoUuUhrFwBjcw)-- --Boundary_(ID_cPwvXSLdSryYATLP7qeVjw)--