draft-ietf-dhc-suboptions-kdc-serveraddress-02

From mailnull@www1.ietf.org Sun Dec 1 14:46:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14390 for ; Sun, 1 Dec 2002 14:46:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB1JmRx29021 for dhcwg-archive@odin.ietf.org; Sun, 1 Dec 2002 14:48:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1JmRv29018 for ; Sun, 1 Dec 2002 14:48:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14381 for ; Sun, 1 Dec 2002 14:45:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1JiUv28927; Sun, 1 Dec 2002 14:44:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1Jf5v28850 for ; Sun, 1 Dec 2002 14:41:05 -0500 Received: from web10907.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14246 for ; Sun, 1 Dec 2002 14:38:10 -0500 (EST) Message-ID: <20021201194058.13741.qmail@web10907.mail.yahoo.com> Received: from [80.128.12.204] by web10907.mail.yahoo.com via HTTP; Sun, 01 Dec 2002 11:40:58 PST Date: Sun, 1 Dec 2002 11:40:58 -0800 (PST) From: "Petar Chobanov Pi." To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-727659751-1038771658=:12810" Subject: [dhcwg] unsubscribe please Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --0-727659751-1038771658=:12810 Content-Type: text/plain; charset=us-ascii Please unsubscribe this Email Address: TchobanovPeter@Yahoo.com best regards P. Chobanov +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Best Regards from | | PETAR K. CHOBANOV | | ś:) 1. Chobanov@Mac.Com | | ś:) 2. Chobanov@in.tum.de | | ś:) 3. ChobanovPetar@Yahoo.Com | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-727659751-1038771658=:12810 Content-Type: text/html; charset=us-ascii

Please unsubscribe this Email Address:

TchobanovPeter@Yahoo.com

best regards

P. Chobanov

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-727659751-1038771658=:12810-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Sun Dec 1 23:08:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23035 for ; Sun, 1 Dec 2002 23:08:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB24BEk20213 for dhcwg-archive@odin.ietf.org; Sun, 1 Dec 2002 23:11:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB24BEv20210 for ; Sun, 1 Dec 2002 23:11:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23020 for ; Sun, 1 Dec 2002 23:08:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB248cv20058; Sun, 1 Dec 2002 23:08:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB245Jv19392 for ; Sun, 1 Dec 2002 23:05:19 -0500 Received: from arianne.in.ishoni.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22861 for ; Sun, 1 Dec 2002 23:02:18 -0500 (EST) Received: from leonoid.in.ishoni.com (leonoid.in.ishoni.com [192.168.1.12]) by arianne.in.ishoni.com (8.11.6/Ishonir2) with ESMTP id gB248ht05643 for ; Mon, 2 Dec 2002 09:38:44 +0530 Received: by leonoid.in.ishoni.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 09:38:34 +0530 Message-ID: <7CFD7CA8510CD6118F950002A519EA3003A15D57@leonoid.in.ishoni.com> From: Archana Gudi To: dhcwg@ietf.org Date: Mon, 2 Dec 2002 09:38:33 +0530 X-MS-TNEF-Correlator: <7CFD7CA8510CD6118F950002A519EA3003A15D57@leonoid.in.ishoni.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C299B8.7B1C4E40" Subject: [dhcwg] unsubscribe please Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C299B8.7B1C4E40 Content-Type: text/plain; charset="iso-8859-1" Please unsubscribe this Email Address: archanag@ishoni.com best regards Archana Gudi ------_=_NextPart_000_01C299B8.7B1C4E40 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiMEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0gcMAAIACQAmACEAAQA4AQEggAMADgAAANIHDAAC AAkAJgAhAAEAOAEBCYABACEAAABGN0M2OThFODUxMDNENzExODFEMjAwQzA0RjBDQ0Q2QwApBwEE gAEAEwAAAHVuc3Vic2NyaWJlIHBsZWFzZQA/BwENgAQAAgAAAAIAAgABA5AGAMwIAAAxAAAACwAC AAEAAAADAC4AAAAAAEAAOQBAThx7uJnCAR4AcAABAAAAGwAAAFtkaGN3Z10gdW5zdWJzY3JpYmUg cGxlYXNlAAACAXEAAQAAABsAAAABwpl+IYg8Q0z+BWYR153tAJAn5ThzAA7sFkAAHgAxQAEAAAAI AAAAQVJDSEFOQQADABpAAAAAAB4AMEABAAAACAAAAEFSQ0hBTkEAAwAZQAAAAAACAQkQAQAAAKoD AACmAwAADQsAAExaRnWFEV9vAwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEK wHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TMERhDZ+RLvZjQQbxF2EeMI7wn3 9jsavw4wNRvfHOMR4QxgzmMAUAsJAWQzNhFgC6VkNCAQAipcDrIBkGcBILAzIDwhRE9DAFRZUEUg SFRNAEwgUFVCTElDACAiLS8vVzNDkSNwRFREIoQ0LhFg5FRyAHJ0aQIgB0AjcPBFTiI+EeMhJyHQ CqP5JdwxOSHgIpIlziDAKDD4RUFEJc0O8SbvKt8ntAI2DvA8TUVUQSDHBaACMAnwdD0iBeAik0I1 JIAwLjI5KAAuwDYzMDciICVAB4AEPUclkEVSQVRP6lIlzTQtoS8pvyGRLE8FIYE1EWA8Qk9EWUcl zSAxM69nOTY04UyBIiBLUVVPVEUlwPshMwAhIAAAOJURYDVvNn+vILARYDwQJdw2KYFQOG8ROXNc bGkgElBsZZJhETAgdQCAdWIE8pJiP5B0aAQAIEUAwLEDEUFkZBrABBA6PZb/CqI9hwpyPaYKokMI Oa0BwP8yET1hOc863zvvPP8+DyAhrSDrOCmBLgBoGsBmLpBxQNJ0bzoKwBDxJUBnSkAEAGgCIGku BaBtZCZuP/BwOyWxSdlmaQiQbGQhAmZQIAuAcyh0e0giUVIjEE5LByNATR9OJ1wnYTAifxnQAfFQ IBEgIXAaIABBdYcDIUQvTAdTUEFORuSNSFBjC2AEED05NCAgADgxODA0LTAyPw4gAdBYQEm/VS8O EDQ4gSHgRk9OVCBmANDvMFAHE1bGAJB6MFBYvBgw/wOyAdBUyVIvA3BVfk60WNjXU1JZjyelNTeR L1tCWMn7Qmgg3DlFklaCZJ8+hGeP92ifZa9mtEEp/i2ANOEw8fNDKD7gbmVD/1XPVt9X789Y/1oP WxYaMz0jL0AvQP8BIFuPXJ9zYlRgM3Fd72MP/2Qfam9mP2dPaZxCL0M/fL//RV9Gb0d/SI9Jn0qv b79wwP9xX3Jvc39gn2GvjZ99z37f60BAUNAgGsBnCxEYsH///4EPgh+DL4Q/hU+GX4dviH//iY+K n4uvnI+XP3UPdh93L494P3lPBxBfMyBHdVCg/44Pjx+QL3qve7+r75Gffu//lH+Vj5afl68nLaBw MhE3z7+uLzQaWxG3UDUfIaA3MhILKF8mp329wAAAHgBCEAEAAAA1AAAAPDIwMDIxMjAxMTk0MDU4 LjEzNzQxLnFtYWlsQHdlYjEwOTA3Lm1haWwueWFob28uY29tPgAAAAADAN4/r28AAAMAAlkAABYA AwAJWQIAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAABShQAAJ2oBAB4ABIAIIAYAAAAAAMAAAAAA AABGAAAAAFSFAAABAAAABAAAADkuMAAeAAWACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEA AAAAAAAAHgAGgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AB4AIIAYAAAAA AMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAAiACCAGAAAAAADAAAAAAAAARgAAAACChQAA AQAAAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAIOFAAABAAAAEwAAADk0NjA4MTgwNC0wMjEyMjAw MgAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAALABCACCAGAAAAAADAAAAAAAAARgAA AAAGhQAAAAAAAAMADIAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAKgAggBgAAAAAAwAAA AAAAAEYAAAAAA4UAAAAAAAALAA2ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMADoAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAPgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAD APE/CQQAAAMAJgAAAAAAAwA2AAAAAAADAP0/5AQAAAMAgBD/////AgFHAAEAAAAwAAAAYz1VUzth PSA7cD1pc2hvbmk7bD1MRU9OT0lELTAyMTIwMjA0MDgzM1otMTE2MjMAHgA4QAEAAAAIAAAAQVJD SEFOQQAeADlAAQAAAAgAAABBUkNIQU5BAEAABzAiUxx7uJnCAUAACDCmKjR7uJnCAR4APQABAAAA AQAAAAAAAAAeAB0OAQAAABMAAAB1bnN1YnNjcmliZSBwbGVhc2UAAB4ANRABAAAAQQAAADw3Q0ZE N0NBODUxMENENjExOEY5NTAwMDJBNTE5RUEzMDAzQTE1RDU3QGxlb25vaWQuaW4uaXNob25pLmNv bT4AAAAACwApAAAAAAALACMAAAAAAAMABhDkzYSjAwAHEGQAAAADABAQAAAAAAMAERAAAAAAHgAI EAEAAABlAAAAUExFQVNFVU5TVUJTQ1JJQkVUSElTRU1BSUxBRERSRVNTOjxNQUlMVE86QVJDSEFO QUdASVNIT05JQ09NQVJDSEFOQUdASVNIT05JQ09NQkVTVFJFR0FSRFNBUkNIQU5BR1VESQAAAAAC AX8AAQAAAEEAAAA8N0NGRDdDQTg1MTBDRDYxMThGOTUwMDAyQTUxOUVBMzAwM0ExNUQ1N0BsZW9u b2lkLmluLmlzaG9uaS5jb20+AAAAAGYT ------_=_NextPart_000_01C299B8.7B1C4E40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Tue Dec 3 08:05:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17601 for ; Tue, 3 Dec 2002 08:05:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3D7o405874 for dhcwg-archive@odin.ietf.org; Tue, 3 Dec 2002 08:07:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3D7ov05869 for ; Tue, 3 Dec 2002 08:07:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17588 for ; Tue, 3 Dec 2002 08:04:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3D57v05201; Tue, 3 Dec 2002 08:05:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3D1Pv05065 for ; Tue, 3 Dec 2002 08:01:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16796; Tue, 3 Dec 2002 07:58:33 -0500 (EST) Message-Id: <200212031258.HAA16796@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Dec 2002 07:58:32 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt Pages : 18 Date : 2002-12-2 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dhc-dhcpv6-opt-prefix-delegation-01.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-dhc-dhcpv6-opt-prefix-delegation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-2135606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-2135606.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Sat Dec 7 13:43:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04109 for ; Sat, 7 Dec 2002 13:43:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB7Ijn927199 for dhcwg-archive@odin.ietf.org; Sat, 7 Dec 2002 13:45:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7Ijnv27196 for ; Sat, 7 Dec 2002 13:45:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04099 for ; Sat, 7 Dec 2002 13:42:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7Ihav27150; Sat, 7 Dec 2002 13:43:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7GtVv21902 for ; Sat, 7 Dec 2002 11:55:31 -0500 Received: from gw.xargs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01630 for ; Sat, 7 Dec 2002 11:52:34 -0500 (EST) Received: (qmail 3265 invoked from network); 7 Dec 2002 16:55:26 -0000 Received: from gw.xargs.com (democracy@192.168.11.1) by gw.xargs.com with SMTP; 7 Dec 2002 16:55:26 -0000 Date: Sat, 7 Dec 2002 08:55:26 -0800 (PST) From: Thamer Al-Harbash X-X-Sender: shadows@gw.xargs.com To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] rfc2131 and releasing leases Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I understand under rfc2131 that there is no way to acknowledge a release from a DHCP client. Are there any extensions, or any plans on incorporating a release acknowledgement? Problem: Client sends DHCP release. Client shuts down. Server doesn't get the release datagram because it was dropped before it reached the Server. The server holds onto the lease. How is this scenario avoided by the server if no acknowledgement is ever sent to the client? The problem becomes worse when the client machine reboots to another OS and tries to acquire the same lease with a different client-id. -- Thamer Al-Harbash http://www.whitefang.com/ team dresch made me do it _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Sat Dec 7 13:43:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04131 for ; Sat, 7 Dec 2002 13:43:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB7Ik4w27217 for dhcwg-archive@odin.ietf.org; Sat, 7 Dec 2002 13:46:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7Ik4v27214 for ; Sat, 7 Dec 2002 13:46:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04103 for ; Sat, 7 Dec 2002 13:43:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7IhFv27132; Sat, 7 Dec 2002 13:43:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gASDwSv21534 for ; Thu, 28 Nov 2002 08:58:28 -0500 Received: from scooter.gcal.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27960 for ; Thu, 28 Nov 2002 08:55:40 -0500 (EST) Received: from exch1.gcal.ac.uk (GCUEXCH.gcal.ac.uk) [193.62.224.40] by scooter.gcal.ac.uk; Thu, 28 Nov 2002 13:58:22 +0000 Received: by GCUEXCH.gcal.ac.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 13:58:23 -0000 Message-ID: From: Boyle Bernadette To: "'dhcwg@ietf.org'" Date: Thu, 28 Nov 2002 13:58:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C296E6.35D82F40" Subject: [dhcwg] using omapi for failover on dhcp Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C296E6.35D82F40 Content-Type: text/plain Hello, I have two dhcp machines running on redhat 7.2 and I want to use the omshell to inform the primary server that the second one will be down on day x. I'm having trouble trying to find information on how to go about this. If anyone could point me in the right direction I'd be very grateful. Bernadette ---------------------------------------------------------------------------- ----------------------- Bernadette Boyle b.boyle@gcal.ac.uk 0141 331 8822 ---------------------------------------------------------------------------- -------------------------- ------_=_NextPart_001_01C296E6.35D82F40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello,

I have two dhcp machines = running on redhat 7.2 and I want to use the omshell to inform the primary server that the = second one will be down on day x. I'm having trouble trying to find information on how to go about this.

If anyone could point me in the right direction I'd = be very grateful.

Bernadette

= ------------------------------------------------------------------------= ---------------------------

= Bernadette Boyle

= b.boyle@gcal.ac.uk

= 0141 331 8822

= ------------------------------------------------------------------------= ------------------------------

------_=_NextPart_001_01C296E6.35D82F40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Mon Dec 9 21:46:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14369 for ; Mon, 9 Dec 2002 21:46:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA2mmP18640 for dhcwg-archive@odin.ietf.org; Mon, 9 Dec 2002 21:48:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA2mmv18637 for ; Mon, 9 Dec 2002 21:48:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14358 for ; Mon, 9 Dec 2002 21:45:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA2kOv18567; Mon, 9 Dec 2002 21:46:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA2iAv18497 for ; Mon, 9 Dec 2002 21:44:10 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14257 for ; Mon, 9 Dec 2002 21:41:05 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA2iTfr017799 for ; Mon, 9 Dec 2002 21:44:30 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-266.cisco.com [10.82.241.10]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA15150 for ; Mon, 9 Dec 2002 21:43:57 -0500 (EST) Message-Id: <4.3.2.7.2.20021209143603.01a32b10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Dec 2002 17:08:26 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17384597==_.ALT" Subject: [dhcwg] Editorial changes to DHCPv6 specification Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=====================_17384597==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed FYI...The IESG has requested changes in two sections of draft-ietf-dhc-dhcpv6-28.txt, prior to its acceptance as a Proposed Standard and publication as an RFC. The changes are noted in the text included below from sections 21.1 and 23. The change is motivated by the observation that manual keying does not prevent replay attacks. The sentence identified in the first paragraph of 21.1 will be removed. The list item labeled "Key Management" will be replaced with the text shown below. The previous text mentioned only manual keying. The indicated (last) paragraph in section 23 will be added. - Ralph ===== 21.1. Security of Messages Sent Between Servers and Relay Agents Relay agents and servers that exchange messages securely use the | IPsec mechanisms for IPv6 [11]. Relay agents and servers MUST | support manual configuration and installation of static keys. If | a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships. That is, if messages from client C will be relayed by relay agent A to relay agent B and then to the server, relay agents A and B must be configured to use IPSec for the messages they exchange, and relay agent B and the server must be configured to use IPSec for the messages they exchange. Relay agents and servers that support secure relay agent to server or relay agent to relay agent communication use IPsec under the following conditions: Selectors Relay agents are manually configured with the addresses of the relay agent or server to which DHCP messages are to be forwarded. Each relay agent and server that will be using IPsec for securing DHCP messages must also be configured with a list of the relay agents to which messages will be returned. The selectors for the relay agents and servers will be the pairs of addresses defining relay agents and servers that exchange DHCP messages on the DHCPv6 UDP ports 546 and 547. Mode Relay agents and servers use transport mode and ESP. The information in DHCP messages is not generally considered confidential, so encryption need not be used (i.e., NULL encryption can be used). | Key management Because the relay agents and servers are used | within an organization, public key schemes are | not necessary. Because the relay agents and | servers must be manually configured, manually | configured key management may suffice, but | doesn't provide defense against replayed | messages. Accordingly, IKE with preshared | secrets SHOULD be supported. IKE with public | keys MAY be supported. Security policy DHCP messages between relay agents and servers should only be accepted from DHCP peers as identified in the local configuration. Authentication Shared keys, indexed to the source IP address of the received DHCP message, are adequate in this application. Availability Appropriate IPsec implementations are likely to be available for servers and for relay agents in more featureful devices used in enterprise and core ISP networks. IPsec is less likely to be available for relay agents in low end devices primarily used in the home or small office markets. 23. Security Considerations [...] Communication between a server and a relay agent and communication between relay agents can be secured through the use of IPSec, as described in section 21.1. The use of manual configuration and installation of static keys are acceptable in this instance because relay agents and the server will belong to the same administrative domain and the relay agents will require other specific configuration (for example, configuration of the DHCP server address) as well as the IPSec configuration. | Use of manually configured preshared keys for IPsec | between relay agents and servers does not defend against | replayed DHCP messages. Replayed messages can | represent a DOS attack through exhaustion of | processing resources, but not through mis-configuration | or exhaustion of other resources such as assignable addresses. --=====================_17384597==_.ALT Content-Type: text/html; charset="us-ascii" FYI...The IESG has requested changes in two sections of draft-ietf-dhc-dhcpv6-28.txt, prior to its acceptance as a Proposed Standard and publication as an RFC. The changes are noted in the text included below from sections 21.1 and 23. The change is motivated by the observation that manual keying does not prevent replay attacks.

The sentence identified in the first paragraph of 21.1 will be removed. The list item labeled "Key Management" will be replaced with the text shown below. The previous text mentioned only manual keying. The indicated (last) paragraph in section 23 will be added.

- Ralph

=====

21.1. Security of Messages Sent Between Servers and Relay Agents

   Relay agents and servers that exchange messages securely use the
| IPsec mechanisms for IPv6 [11]. Relay agents and servers MUST
| support manual configuration and installation of static keys. If
| a client message is relayed through multiple relay agents, each of
   the relay agents must have established independent, pairwise trust
   relationships. That is, if messages from client C will be relayed by
   relay agent A to relay agent B and then to the server, relay agents A
   and B must be configured to use IPSec for the messages they exchange,
   and relay agent B and the server must be configured to use IPSec for
   the messages they exchange.

   Relay agents and servers that support secure relay agent to server
   or relay agent to relay agent communication use IPsec under the
   following conditions:

      Selectors        Relay agents are manually configured with the
                       addresses of the relay agent or server to which
                       DHCP messages are to be forwarded. Each relay
                       agent and server that will be using IPsec for
                       securing DHCP messages must also be configured
                       with a list of the relay agents to which messages
                       will be returned. The selectors for the relay
                       agents and servers will be the pairs of addresses
                       defining relay agents and servers that exchange
                       DHCP messages on the DHCPv6 UDP ports 546 and
                       547.

      Mode             Relay agents and servers use transport mode and
                       ESP. The information in DHCP messages is not
                       generally considered confidential, so encryption
                       need not be used (i.e., NULL encryption can be
                       used).

|     Key management   Because the relay agents and servers are used
|                      within an organization, public key schemes are
|                      not necessary. Because the relay agents and
|                      servers must be manually configured, manually
|                      configured key management may suffice, but
|                      doesn't provide defense against replayed
|                      messages. Accordingly, IKE with preshared
|                      secrets SHOULD be supported. IKE with public
|                      keys MAY be supported.

      Security policy DHCP messages between relay agents and servers
                       should only be accepted from DHCP peers as
                       identified in the local configuration.

      Authentication   Shared keys, indexed to the source IP address of
                       the received DHCP message, are adequate in this
                       application.

      Availability     Appropriate IPsec implementations are likely to
                       be available for servers and for relay agents in
                       more featureful devices used in enterprise and
                       core ISP networks. IPsec is less likely to be
                       available for relay agents in low end devices
                       primarily used in the home or small office
                       markets.

23. Security Considerations
   [...]

   Communication between a server and a relay agent and communication
   between relay agents can be secured through the use of IPSec, as
   described in section 21.1. The use of manual configuration and
   installation of static keys are acceptable in this instance because
   relay agents and the server will belong to the same administrative
   domain and the relay agents will require other specific configuration
   (for example, configuration of the DHCP server address) as well as
   the IPSec configuration.

| Use of manually configured preshared keys for IPsec
| between relay agents and servers does not defend against
| replayed DHCP messages. Replayed messages can
| represent a DOS attack through exhaustion of
| processing resources, but not through mis-configuration
| or exhaustion of other resources such as assignable addresses.
--=====================_17384597==_.ALT-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Wed Dec 11 20:49:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28812 for ; Wed, 11 Dec 2002 20:49:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBC1piv03973 for dhcwg-archive@odin.ietf.org; Wed, 11 Dec 2002 20:51:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC1piv03970 for ; Wed, 11 Dec 2002 20:51:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28797 for ; Wed, 11 Dec 2002 20:48:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC1mwv03850; Wed, 11 Dec 2002 20:48:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC1lIv03791 for ; Wed, 11 Dec 2002 20:47:18 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28628 for ; Wed, 11 Dec 2002 20:44:13 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gBC1l6qW026160; Wed, 11 Dec 2002 18:47:06 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2A180.602B29C4" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 11 Dec 2002 18:47:06 -0700 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-ietf-dhc-suboptions-kdc-serveraddress-02 Thread-Index: AcKhgF+TrdwkvkokTN+08+yIxx6qLg== From: "Kevin Luehrs" To: Cc: "John Bevilacqua" , X-Approved: ondar Subject: [dhcwg] draft-ietf-dhc-suboptions-kdc-serveraddress-02 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2A180.602B29C4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C2A180.602B29C4" ------_=_NextPart_002_01C2A180.602B29C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A revision to the 'KDC Server Address sub-option' of the CableLabs Client Configuration (CCC) Option is attached, hereby submitted to update draft-ietf-dhc-suboptions-kdc-serveraddress-01. The attached version updates the reference to the 'DHCP Option for CableLabs Client Configuration' i-d. <>=20 Regards, Kevin Luehrs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kevin Luehrs Project Director, CableHome Engineering CableLabs 400 Centennial Parkway Louisville, CO 80027 303 661 9100 fax 303 661 9199 k.luehrs@cablelabs.com ------_=_NextPart_002_01C2A180.602B29C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-dhc-suboptions-kdc-serveraddress-02

A revision to the 'KDC Server Address = sub-option' of the CableLabs Client Configuration (CCC) Option is = attached, hereby submitted to update = draft-ietf-dhc-suboptions-kdc-serveraddress-01. The attached version = updates the reference to the 'DHCP Option for CableLabs Client = Configuration' i-d.

= <<draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt>> =

Regards,

Kevin Luehrs

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Luehrs
Project Director, CableHome = Engineering
CableLabs
400 Centennial Parkway
Louisville, CO 80027
303 661 9100
fax 303 661 9199
k.luehrs@cablelabs.com

------_=_NextPart_002_01C2A180.602B29C4-- ------_=_NextPart_001_01C2A180.602B29C4 Content-Type: text/plain; name="draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt Content-Disposition: attachment; filename="draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSy4gTHVlaHJzDQpEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdy b3VwICAgICAgICAgICAgICAgIENhYmxlTGFicw0KRXhwaXJlcyBKdW5lIDIwMDMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBXb3VuZHkNCgkJCQkJCQlBVCZUIEJyb2Fk YmFuZA0KCQkJCQkJCUouIEJldmlsYWNxdWEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFlBUyBDb3Jwb3JhdGlvbiAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAy MDAyDQoNCg0KCQlLREMgU2VydmVyIEFkZHJlc3MgU3ViLW9wdGlvbiANCiAgICAgICAgIDxkcmFm dC1pZXRmLWRoYy1zdWJvcHRpb25zLWtkYy1zZXJ2ZXJhZGRyZXNzLTAyLnR4dD4NCg0KU3RhdHVz IG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFu ZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgNCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rp b24gMTAgb2YgUkZDMjAyNi4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdy b3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0K ICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCANCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzDQogICBhdCBhbnkgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVy ZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBh Y2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCkNv cHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwMikuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIG5ldyBzdWItb3B0aW9uIGZvciB0aGUgQ2FibGVMYWJzIENsaWVudA0KICAg Q29uZmlndXJhdGlvbiAoQ0NDKSBESENQIG9wdGlvbiBjb2RlIGZvciBjb252ZXlpbmcgdGhlIG5l dHdvcmsgDQogICBhZGRyZXNzZXMgb2YgS2V5IERpc3RyaWJ1dGlvbiBDZW50ZXIgKEtEQykgc2Vy dmVycy4NCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBUaGUgbmVlZCBmb3IgYSBDQ0MgREhDUCBP cHRpb24gY29kZSBpcyBkZXNjcmliZWQgaW4gWzFdLiBUaGUgQ0NDIA0KICAgREhDUCBvcHRpb24g Y29kZSB3aWxsIGJlIHVzZWQgdG8gYWRkcmVzcyBzcGVjaWZpYyBuZWVkcyBvZiBDYWJsZUxhYnMN CiAgIGNsaWVudCBkZXZpY2VzIGR1cmluZyB0aGVpciBjb25maWd1cmF0aW9uIHByb2Nlc3Nlcy4g VGhpcyBkb2N1bWVudCANCiAgIHByb3Bvc2VzIGEgc3ViLW9wdGlvbiBmb3IgdGhlIENDQyBESENQ IG9wdGlvbi4NCiAgIA0KICAgDQogICANCiAgIA0KICAgDQogICANCiAgIEx1ZWhycywgV291bmR5 LCAmIEJldmlsYWNxdWEgICAgICAgIEV4cGlyZXMgSnVuZSAyMDAzICAgICAgICAgW1BhZ2UgMV0M ICAgSW50ZXJuZXQgRHJhZnQJICBLREMgU2VydmVyIEFkZHJlc3MgU3ViLW9wdGlvbiAgICAgICBE ZWNlbWJlciAyMDAyDQogICANCiAgIA0KICAgQ29uZmlndXJhdGlvbiBvZiBhIGNsYXNzIG9mIENh YmxlTGFicyBjbGllbnQgZGV2aWNlcyBkZXNjcmliZWQgaW4gDQogICBbMl0gcmVxdWlyZXMgYSBE SENQIHN1Yi1vcHRpb24gdG8gcHJvdmlkZSB0aGUgY2xpZW50IHdpdGggdGhlIA0KICAgbmV0d29y ayBhZGRyZXNzIG9mIGEgS0RDIHNlcnZlciBpbiB0aGUgY2FibGUgb3BlcmF0b3IncyBkYXRhIA0K ICAgbmV0d29yay4gVGhlIGNsYXNzIG9mIGRldmljZXMgYXNzdW1lZCBpbiBbMl0gaXMgdW5saWtl IHRoZSBjbGFzcw0KICAgb2YgZGV2aWNlcyBjb25zaWRlcmVkIGluIFsxXSwgd2hpY2ggcGVyZm9y bSBhIEROUyBsb29rdXAgb2YgdGhlIA0KICAgS2VyYmVyb3MgUmVhbG0gbmFtZSB0byBmaW5kIHRo ZSBLREMgc2VydmVyIG5ldHdvcmsgYWRkcmVzcy4gDQogICANCiAgIFRoaXMgZG9jdW1lbnQgcHJv cG9zZXMgYSBzdWItb3B0aW9uIG9mIHRoZSBDQ0MgREhDUCBvcHRpb24NCiAgIGNvZGUgZm9yIHVz ZSB3aXRoIENhYmxlTGFicyBjbGllbnQgZGV2aWNlcy4gVGhlIHByb3Bvc2VkIHN1Yi1vcHRpb24N CiAgIGVuY29kZXMgYW4gaWRlbnRpZmllciBmb3IgdGhlIG5ldHdvcmsgYWRkcmVzcyBvZiBlYWNo IG9mIG9uZSBvciBtb3JlDQogICBLZXkgRGlzdHJpYnV0aW9uIENlbnRlciBzZXJ2ZXJzIHdpdGgg d2hpY2ggdGhlIENhYmxlTGFicyBjbGllbnQgDQogICBkZXZpY2UgZXhjaGFuZ2VzIHNlY3VyaXR5 IGluZm9ybWF0aW9uLiANCg0KICAgQ2FibGVMYWJzIHBsYW5zIHRvIGFzc2lnbiBzdWItb3B0aW9u IGNvZGUgcmFuZ2VzIGZvciB0aGUgQ0NDIG9wdGlvbiANCiAgIGFjY29yZGluZyB0byBDYWJsZUxh YnMgcHJvamVjdHMuIFRoZSByYW5nZSAoNTEgLSAxMDApIGlzIGFzc2lnbmVkIA0KICAgdG8gdGhl IENhYmxlSG9tZSBwcm9qZWN0LiBVc2Ugb2YgdGhlIGluaXRpYWwgdmFsdWUgb2YgdGhpcyByYW5n ZSBpcw0KICAgc3BlY2lmaWVkIGluIFsyXS4NCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIgYW5kICJNQVkiIA0KICAgaW4gdGhpcyBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFsz XS4NCg0KDQoyLiAgS2V5IERpc3RyaWJ1dGlvbiBDZW50ZXIgSVAgQWRkcmVzcyBTdWItb3B0aW9u DQoNCiAgIFRoZSBDYWJsZUhvbWUgMS4wIHNwZWNpZmljYXRpb24gWzJdIHNwZWNpZmllcyB0aGUg S2V5IERpc3RyaWJ1dGlvbiANCiAgIENlbnRlciBuZXR3b3JrIGFkZHJlc3MgZW5jb2RpbmcgYXMg YSBzdWItb3B0aW9uIG9mIHRoZSBDQ0MgREhDUCANCiAgIE9wdGlvbiBjb2RlLiBUaGlzIGZpZWxk IGlzIHVzZWQgdG8gaW5mb3JtIHRoZSBjbGllbnQgZGV2aWNlIG9mIHRoZQ0KICAgbmV0d29yayBh ZGRyZXNzIG9mIG9uZSBvciBtb3JlIEtleSBEaXN0cmlidXRpb24gQ2VudGVyIHNlcnZlcnMuIA0K DQogICBUaGUgZW5jb2Rpbmcgb2YgdGhlIEtEQyBTZXJ2ZXIgQWRkcmVzcyBzdWItb3B0aW9uIHdp bGwgYWRoZXJlIHRvIHRoZSANCiAgIGZvcm1hdCBvZiBhbiBJUHY0IGFkZHJlc3MgdXNpbmcgdGhl IGRlZmF1bHQgcG9ydC4gVGhlIG1pbmltdW0gbGVuZ3RoDQogICBmb3IgdGhpcyBvcHRpb24gaXMg NCBvY3RldHMsIGFuZCB0aGUgbGVuZ3RoIE1VU1QgYWx3YXlzIGJlIGEgDQogICBtdWx0aXBsZSBv ZiA0LiBJZiBtdWx0aXBsZSBLREMgU2VydmVycyBhcmUgbGlzdGVkLCB0aGV5IE1VU1QgYmUNCiAg IGxpc3RlZCBpbiBkZWNyZWFzaW5nIG9yZGVyIG9mIHByaW9yaXR5LiBUaGUgZm9ybWF0IG9mIHRo ZSBLREMgU2VydmVyDQogICBBZGRyZXNzIHN1Yi1vcHRpb24gb2YgdGhlIENDQyBvcHRpb24gY29k ZSBpcyBhcyBzaG93biBiZWxvdzoNCg0KICAgIFN1Yk9wdCAgTGVuICAgICAgQWRkcmVzcyAxICAg ICAgICAgICAgICAgQWRkcmVzcyAyDQogICArLS0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0t Ky0tLS0tKy0tLS0tKy0tLS0tKy0tDQogICB8ICA1MSAgfCAgbiAgfCAgYTEgfCAgYTIgfCAgYTMg fCAgYTQgfCAgYTEgfCAgYTIgfCAgLi4uDQogICArLS0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0t LS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tDQoNCg0KMy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z DQoNCiAgIFRoaXMgZG9jdW1lbnQgcmVsaWVzIHVwb24gdGhlIERIQ1AgcHJvdG9jb2wgWzRdIGZv ciBhdXRoZW50aWNhdGlvbg0KICAgYW5kIHNlY3VyaXR5LCBpLmUuLCBpdCBkb2VzIG5vdCBwcm92 aWRlIHNlY3VyaXR5IGluIGV4Y2VzcyBvZiB3aGF0DQogICBESENQIGlzIChvciB3aWxsIGJlKSBw cm92aWRpbmcuIEl0IGRvZXMgbm90IGV4cG9zZSBhbnkgc2VjdXJpdHkNCiAgIHRocmVhdHMgYmV5 b25kIHdoYXQgaXMgY3VycmVudGx5IGV4cG9zZWQgYnkgb3RoZXIgREhDUCBvcHRpb25zLg0KDQog ICANCg0KDQoNCiAgIA0KTHVlaHJzLCBXb3VuZHksICYgQmV2aWxhY3F1YSAgICAgICAgRXhwaXJl cyBKdW5lIDIwMDMgICAgICAgICBbUGFnZSAyXQ0KDEludGVybmV0IERyYWZ0CSAgS0RDIFNlcnZl ciBBZGRyZXNzIFN1Yi1vcHRpb24gICAgICAgRGVjZW1iZXIgMjAwMg0KDQoNCjQuICBJQU5BIENv bnNpZGVyYXRpb25zDQoNCiAgIFRoZSBLREMgU2VydmVyIEFkZHJlc3Mgc3ViLW9wdGlvbiBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBpcyANCiAgIGludGVuZGVkIHRvIGJlIGEgc3ViLW9wdGlv biBvZiB0aGUgQ2FibGVMYWJzIENsaWVudCBDb25maWd1cmF0aW9uDQogICAoQ0NDKSBvcHRpb24g ZGVzY3JpYmVkIGluIFsxXS4gSUFOQSB3aWxsIGJlIHJlcXVlc3RlZCB0byByZWdpc3Rlcg0KICAg c3ViLW9wdGlvbiBjb2RlIDUxIG9mIHRoZSBDQ0Mgb3B0aW9uIHRvIHRoZSBLREMgU2VydmVyIEFk ZHJlc3MgICAgDQogICBzdWItb3B0aW9uLg0KDQo1LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0K DQogICBbMV0gIkRIQ1AgT3B0aW9uIGZvciBDYWJsZUxhYnMgQ2xpZW50IENvbmZpZ3VyYXRpb24g IGRyYWZ0LWlldGYtZGhjLQ0KICAgICAgICBwYWNrZXRjYWJsZS0wNSIsIElFVEYsIERlY2VtYmVy IDIwMDIuDQoNCiAgIFsyXSAiQ2FibGVIb21lIDEuMCBTcGVjaWZpY2F0aW9uIFNQLUNIMS4wLUkw Mi0wMjA5MjAiLCBDYWJsZUxhYnMsDQogICAgICAJU2VwdGVtYmVyIDIwMDIsIGh0dHA6Ly93d3cu Y2FibGVsYWJzLmNvbS9wcm9qZWN0cy9jYWJsZWhvbWUvDQoJc3BlY2lmaWNhdGlvbnMvLg0KDQog ICBbM10gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRl IFJlcXVpcmVtZW50DQogICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5 Ny4NCg0KICAgWzRdIERyb21zLCBSLiwgIkR5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3Rv Y29sIiwgUkZDIDIxMzEsIE1hcmNoDQogICAgICAgMTk5Ny4NCg0KNi4gIEF1dGhvcnMnIEFkZHJl c3Nlcw0KDQoJS2V2aW4gTHVlaHJzDQoJQ2FibGVMYWJzDQoJNDAwIENlbnRlbm5pYWwgUGFya3dh eQ0KCUxvdWlzdmlsbGUsIENPIDgwMDI3DQoJUGhvbmU6ICAoMzAzKSA2NjEtOTEwMA0KCUVNYWls OiAgay5sdWVocnNAY2FibGVsYWJzLmNvbQ0KDQoJUmljaGFyZCBXb3VuZHkNCglBVCZUIEJyb2Fk YmFuZA0KCTI3IEluZHVzdHJpYWwgRHJpdmUNCglDaGVsbXNmb3JkLCBNQSAwMTgyNA0KCVBob25l OiAoOTc4KSAyNDQtNDAxMA0KCUVNYWlsOiByd291bmR5QGJyb2FkYmFuZC5hdHQuY29tDQoNCiAg ICAgICAgSm9obiBCZXZpbGFjcXVhDQogICAgICAgIFlBUyBDb3Jwb3JhdGlvbg0KICAgICAgICAz MDAgQnJpY2tzdG9uZSBTcXVhcmUNCiAgICAgICAgQW5kb3ZlciwgTUEgMDE4MTANCiAgICAgICAg UGhvbmU6ICg5NzgpIDc0OS05OTk5DQogICAgICAgIEVNYWlsOiBqb2huQHlhcy5jb20NCg0KDQoN Cg0KDQoNCg0KDQoNCkx1ZWhycywgV291bmR5LCAmIEJldmlsYWNxdWEgICAgICAgIEV4cGlyZXMg SnVuZSAyMDAzICAgICAgICAgW1BhZ2UgM10NCgxJbnRlcm5ldCBEcmFmdAkgIEtEQyBTZXJ2ZXIg QWRkcmVzcyBTdWItb3B0aW9uICAgICAgIERlY2VtYmVyIDIwMDINCg0KDQo3LiAgRnVsbCBDb3B5 cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDIpLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFu c2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvDQogICBvdGhlcnMs IGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFp biBpdA0KICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQs IGNvcGllZCwgcHVibGlzaGVkDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55DQogICBraW5kLCBwcm92aWRlZCB0aGF0IHRo ZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCANCiAgIGFyZSBpbmNs dWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0 aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBz dWNoIGFzIGJ5IHJlbW92aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2Vz IHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdhbml6YXRp b25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiBkZXZlbG9wLQ0KICAgaW5n IEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5 cmlnaHRzDQogICBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0 IGJlIGZvbGxvd2VkLCBvciBhcw0KICAgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFu Z3VhZ2VzIG90aGVyIHRoYW4gRW5nbGlzaC4NCg0KICAgVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMg Z3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZQ0KICAgcmV2b2tlZCBi eSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25zLg0KDQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlz IHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVU WSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBB TEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJVVCBOT1Qg TElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0K ICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FS UkFOVElFUyBPRiANCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkx1ZWhycywgV291bmR5LCAmIEJldmlsYWNxdWEgICAgICAgIEV4cGlyZXMgSnVu ZSAyMDAzICAgICAgICAgW1BhZ2UgNF0NCg== ------_=_NextPart_001_01C2A180.602B29C4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Thu Dec 12 07:52:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21165 for ; Thu, 12 Dec 2002 07:52:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCCspd16617 for dhcwg-archive@odin.ietf.org; Thu, 12 Dec 2002 07:54:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCspv16614 for ; Thu, 12 Dec 2002 07:54:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21162 for ; Thu, 12 Dec 2002 07:51:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCjov16367; Thu, 12 Dec 2002 07:45:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCiWv16314 for ; Thu, 12 Dec 2002 07:44:32 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20999 for ; Thu, 12 Dec 2002 07:41:34 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCCiwOw001563 for ; Thu, 12 Dec 2002 07:44:59 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-660.cisco.com [10.82.226.148]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA07762 for ; Thu, 12 Dec 2002 07:44:27 -0500 (EST) Message-Id: <4.3.2.7.2.20021212074227.037b7080@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Dec 2002 07:44:22 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Draft minutes from Atlanta Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DHC WG Meeting minutes (Draft, 12/12/2002) IETF 55, Atlanta, 11/2002 ========================= Administrivia, agenda bashing, Ralph Droms ------------------------------------------ CableLabs Client Configuration option draft is in IETF last call. So far, the last call has elicited comments requiring some editorial and minor specification changes. DHCPv6 specification has been reviewed by IESG, and requires small edits to text describing relay agent security. Droms will post summary of changes to WG mailing list. Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and Servers, Ralph Droms ----------------------------------------------------------------- draft-droms-dhcp-relay-agent-ipsec-00.txt describes use of IPsec for securing messages between relay agents and servers. Carl Smith asked if it is different than the mechanism in the DHCPv6 draft; answer: no. Narten asked for comparison with Stapp's draft-ietf-dhc-auth-suboption-01.txt. Droms noted IPsec mechanism is hop-by-hop while authentication options covers entire path; IPsec mechanism incurs extra complexity if there are multiple relay agents in the path to the server. The WG agreed to take the document on as a WG document. The Authentication Suboption for the DHCP Relay Agent Option, Mark Stapp ------------------------------------------------------------------ draft-ietf-dhc-auth-suboption-01.txt specifies a DHCP-specific mechanism, based on a relay agent suboption that contains a message digest for checking message integrity. This mechanism uses shared keys and includes an identifier mechanism to accommodate edge devices that don't use giaddr. With additional changes, this mechanism can accommodate multiple, nested relay agents. The WG was asked what to do with the two proposals: advance both, adopt one? Does the WG have a clear understanding of the two proposals? Ted Lemon asked how we might weight the pros and cons. Thomas Narten and Stuart Cheshie asked if there is any data on whether IPsec implementations are available to relay agents today. Mark Stapp asked about potential computational complexity issues. Stapp, Lemon and John Schnizlein all asked what the perceived customer requirements are. Droms expressed concern about interoperability if both proposals are advanced. Erik Nordmark asked how relay agents would be configured to use IPsec or with the keys for the relay agent option. Droms pointed out that reuse of IPsec technology implies the availability of future IPsec enhancements. Schnizlein volunteered to organize discussion of pros and cons of both proposals on the WG mailing list. DHCP Option for SNMP Notifications, Mark Bakke ---------------------------------------------- draft-bakke-dhc-snmp-trap-01.txt was developed to address requirements for systems using diskless boot to obtain a list of IP addresses to which to send SNMP traps. Narten asked which WG is best for discussion of this option - in theory, details should be discussed in an SNMP WG with final review of syntax and compatibility in the dhc WG. Narten will coordinate review of the document with MIB groups in the IETF, and the document will ultimately be a dhc WG work item, as there are no appropriate active SNMP WGs. There was a question about whether the option should be expanded with multiple sub-options for different trap types. Subnet Allocation using DHCP, Richard Johnson --------------------------------------------- This proposal describes a mechanism through which a DHCP server can delegate a block of addresses (IPv4), collect usage data on the delegated addresses and deprecate use of addresses. It is similar to the prefix delegation mechanism for DHCPv6. Ted Lemon pointed out that this proposal would require a major revision to existing server, and he suggested that the authors review previous, related work by Walt Lazear. The WG agreed to take on this document as a WG work item. DHCP Server-ID Override Suboption, Richard Johnson -------------------------------------------------- Some DHCP client messages, such as DHCPRENEW, are unicast directly to the DHCP server and not received by a relay agent. Thus, relay agents are unable to add relay agent options to those messages. This proposal provides a mechanism through which the DHCP server can configure the client to respond to the relay agent rather than directly to the server. Narten asked if continued expansion of relay agent options is a good thing. WG consensus is that relay agent options have been found to provide function that cannot be provided in other ways, and the full range of application for relay agent options is still being explored. Stapp suggested revisiting the relay agent option specification, RFC3046, as a WG charter item. The WG agreed to take on this document as a WG work item. Considerations for the use of the Host Name option, Carl Smith -------------------------------------------------------------- Carl had one question for the WG: how can a client request that its name/address association be removed from DNS? Can we use the FQDN to accomplish this result? Kim Kinnear and Ted Lemon asked what customer requires this result. Bernie Volz suggested revisiting this question after the DHCPv6 FQDN model is completed. Load Balancing for DHCPv6, Bernie Volz -------------------------------------- Any more changes needed in this draft? No; so this document is ready for WG last call after DHCPv6 spec has advanced. Other DHCPv6 options, Ralph Droms --------------------------------- draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt has folded prefix delegation into identity associations; the document is also under discussion in the ipv6 WG. draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt, draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt, draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt are all ready for WG last call as soon as DHCPv6 advances. draft-ietf-dhc-dhcpv6-opt-dstm-01.txt and draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt are to be synced up with v6ops work. Lemon, Volz and Narten all asked about the requirement for the mechanism proposed in draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt. A K Vijayabhaskar (author) to clarify motivation and requirements in the specification. A Guide to Implementing Stateless DHCPv6 Service, Ralph Droms ------------------------------------------------------------- Droms asked the WG about the best way to specify the parts of DHCPv6 required for stateless DHCPv6 operation ("DHCPv6-lite") - for example, for providing DNS server configuration without address assignment. Stuart Cheshire asked if the document should be informational or standards-track. Another possibility would be BCP. The WG asked that the Reconfigure message be added to draft-droms-dhcpv6-stateless-guide-01.txt and accepted the document as a dhc WG work item. Revised DHC WG charter and milestones, Ralph Droms -------------------------------------------------- Droms reported that the revised charter and milestones have been submitted to the IESG. The IESG suggested adding a separate charter item to develop a mechanism through which a client can authenticate a server without authentication of the client by the server. Droms will add the relay agent charter item suggested by Stapp (see above). Carl Smith, Bernie Volz and Barr Hibbs volunteered to be a design team that will follow up on the charter item to review RFC3118; they will develop a threat model and analysis of the authentication provided by RFC3118. Barr Hibbs volunteered to coordinate and act as editor for a review of the DHCPv4 specification. Recycling option codes, Ralph Droms ----------------------------------- There are more than 15 options codes that have been assigned but never used. Droms will publish an Internet Draft identifying these option codes and asking for feedback from the Internet community about whether these option codes can be returned to IANA for reassignment. After the Internet Draft has been reviewed by the dhc WG and by the IESG, it will be submitted to IANA. DHCP Lease Query, Kim Kinnear ----------------------------- The WG last call on draft-ietf-dhc-leasequery-05.txt has completed. Based on input from the last call, Kinnear has changed the draft to use a new option rather than overloading the requested address option, and has made other editorial changes. The document is now ready for submission to the IESG. Link Selection sub-option for the Relay Agent Information Option, Kim Kinnear ----------------------------------------------------------------- Last call on draft-ietf-dhc-agent-subnet-selection-04.txt has completed. This document is waiting for authentication of relay agent messages to be resolved. DHCP Subscriber ID Suboption for the DHCP Relay Agent Option, Richard Johnson ------------------------------------------------------------- This option, in draft-johnson-dhc-subscriber-id-00.txt, is motivated by a requirement to identify a subscriber in a relay agent option, regardless of the port to which the subscriber is attached. The WG agreed to take on this document as a WG work item. DHCP Option for Geographic Location, John Schnizlein ---------------------------------------------------- This option, in draft-polk-dhcp-geo-loc-option-00.txt, passes location information about a DHCP client from the server to the client. The immediate purpose is to provide location information to IP phones. The geopriv WG will own the semantics, while the dhc WG will own the protocol and the syntax of the option. The DHCP Client FQDN Option, Mark Stapp DDNS-DHCP conflict resolution, Mark Stapp ----------------------------------------- Stapp reported on draft-ietf-dhc-fqdn-option-05.txt, draft-ietf-dhc-ddns-resolution-05.txt, draft-ietf-dnsext-dhcid-rr-05.txt. There are no deployed implementations of these drafts. Cisco and two others have (non-interoperable) implementation that use TXT RRs, waiting for approval of DHCID RR. Droms asked for a summary of changes to the current drafts. Stapp will post summaries to WG mailing list. Gudmundsson asked if the DHSID RR should become a more general RR type. WG consensus was no, as that would delay progress of these drafts and there is no specific requirement for other, similar RR types. Gudmundsson and Droms agreed documents are ready for dnsext and dhc WG last call. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Thu Dec 12 22:22:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22482 for ; Thu, 12 Dec 2002 22:22:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD3PHU06670 for dhcwg-archive@odin.ietf.org; Thu, 12 Dec 2002 22:25:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3PHv06667 for ; Thu, 12 Dec 2002 22:25:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22464 for ; Thu, 12 Dec 2002 22:22:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3Mev06543; Thu, 12 Dec 2002 22:22:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC9MXv05047 for ; Thu, 12 Dec 2002 04:22:33 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17493 for ; Thu, 12 Dec 2002 04:19:26 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Dec 2002 01:22:22 -0800 X-Originating-IP: [194.237.142.24] From: "tm" To: Date: Thu, 12 Dec 2002 10:21:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C2A1C8.3CF73400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 12 Dec 2002 09:22:22.0007 (UTC) FILETIME=[F9B5EC70:01C2A1BF] Subject: [dhcwg] FORCE RENEW questions Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C2A1C8.3CF73400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Two questions: A) Is DHCP FORCE RENEW supported by any operating system today? Or are = there any known plans for it at Microsoft, Linux, BSD, etc.? B) Is it possible to send a FORCE RENEW to a NIC that has not yet been = configured with an IP address, that is, a NIC that never received a DHCP = reply after reboot? (With the result that the host will do a DHCP = request). /TM ------=_NextPart_000_0035_01C2A1C8.3CF73400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Two questions:

A) Is DHCP FORCE RENEW supported by any = operating=20 system today? Or are there any known plans for it at Microsoft, Linux, = BSD,=20 etc.?

B) Is it possible to send a FORCE RENEW = to a NIC=20 that has not yet been configured with an IP address, that is, a NIC that = never=20 received a DHCP reply after reboot? (With the result that the host will = do a=20 DHCP request).

/TM

------=_NextPart_000_0035_01C2A1C8.3CF73400-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Thu Dec 12 22:25:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22639 for ; Thu, 12 Dec 2002 22:25:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD3RbX06935 for dhcwg-archive@odin.ietf.org; Thu, 12 Dec 2002 22:27:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3Rbv06932 for ; Thu, 12 Dec 2002 22:27:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22617 for ; Thu, 12 Dec 2002 22:24:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3PPv06695; Thu, 12 Dec 2002 22:25:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD2f1v04135 for ; Thu, 12 Dec 2002 21:41:01 -0500 Received: from web12406.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21395 for ; Thu, 12 Dec 2002 21:37:56 -0500 (EST) Message-ID: <20021213024052.62501.qmail@web12406.mail.yahoo.com> Received: from [67.82.134.6] by web12406.mail.yahoo.com via HTTP; Thu, 12 Dec 2002 18:40:52 PST Date: Thu, 12 Dec 2002 18:40:52 -0800 (PST) From: Timir Naik To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] dhcp solaris client error Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I got myself a cable modem and a wireless router D-Link 614+. The route is capable to run dhcp client to get the internet IP address and dhcp server for the clients inside the network. The dhcp server is working great with my windows' client but is giving me this error, "no valid OFFER/BOOTP reply" when I try running dhcp client on my Solaris 8 box. I received the above error message when I ran the following commands: 1. blank hostname.hme0 2. blank dhcp.hme0 3. /sbin/dhcpagent -d 1 -f 1 & 4. ifconfig hme0 dhcp start and this is when I the error "no valid OFFER/BOOTP reply". I was hoping someone can help me out with this problem. Thank you, Tim __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Fri Dec 13 00:11:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03619 for ; Fri, 13 Dec 2002 00:11:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD5E5812727 for dhcwg-archive@odin.ietf.org; Fri, 13 Dec 2002 00:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5E5v12724 for ; Fri, 13 Dec 2002 00:14:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03597 for ; Fri, 13 Dec 2002 00:10:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5BZv12614; Fri, 13 Dec 2002 00:11:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD58fv12448 for ; Fri, 13 Dec 2002 00:08:41 -0500 Received: from lapop.smtp.stsn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03443 for ; Fri, 13 Dec 2002 00:05:34 -0500 (EST) Received: from Barr1LKL501 ([10.0.51.52]) by lapop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Dec 2002 22:16:25 -0700 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] FORCE RENEW questions Date: Thu, 12 Dec 2002 21:09:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C2A222.C77497D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 13 Dec 2002 05:16:26.0015 (UTC) FILETIME=[C8DDFAF0:01C2A266] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2A222.C77497D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I'm also interested in the answer to question (A) in the original message, so would any responders please post their replies to the DHCWG mailing list.... As an additional point, do the implementations of FORCERENEW also implement DHCP Authentication [RFC 3118] as required by RFC 3203? As to question (B), the NIC is not the DHCP client, so let me restate the question and then answer it: "Is it possible to send a FORCERENEW message to an unconfigured client?" As this message is unicast to a DHCP client, and the client is directed to silently discard multicast messages, it is not possible for an unconfigured client to receive a FORCERENEW message. The DHCP protocol [RFC 2131] describes how a DHCP client may continue broadcasting DHCPDISCOVER messages if a DHCP server has not answered. An unconfigured client must not begin the protocol exchange with a DHCPREQUEST message. RFC 2131 also describes how a previously configured client may recover from loss of contact with the server, but that is a different case than you asked about. --Barr Hibbs -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of tm Sent: Thursday, December 12, 2002 01:22 To: dhcwg@ietf.org Subject: [dhcwg] FORCE RENEW questions Two questions: A) Is DHCP FORCE RENEW supported by any operating system today? Or are there any known plans for it at Microsoft, Linux, BSD, etc.? B) Is it possible to send a FORCE RENEW to a NIC that has not yet been configured with an IP address, that is, a NIC that never received a DHCP reply after reboot? (With the result that the host will do a DHCP request). /TM ------=_NextPart_000_0010_01C2A222.C77497D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm=20 also interested in the answer to question (A) in the original message, = so would=20 any responders please post their replies to the DHCWG mailing = list.... As=20 an additional point, do the implementations of FORCERENEW also implement = DHCP=20 Authentication [RFC 3118] as required by RFC 3203?

As to=20 question (B), the NIC is not the DHCP client, so let me restate the = question and=20 then answer it: "Is it possible to send a FORCERENEW message to an = unconfigured client?" As this message is unicast to a DHCP client, = and the=20 client is directed to silently discard multicast messages, it is not = possible=20 for an unconfigured client to receive a FORCERENEW message. The = DHCP=20 protocol [RFC 2131] describes how a DHCP client may continue = broadcasting=20 DHCPDISCOVER messages if a DHCP server has not answered. An = unconfigured=20 client must not begin the protocol exchange with a DHCPREQUEST = message. =20 RFC 2131 also describes how a previously configured client may recover = from loss=20 of contact with the server, but that is a different case than you asked=20 about.

--Barr=20 Hibbs

-----Original Message-----
From: = dhcwg-admin@ietf.org=20 [mailto:dhcwg-admin@ietf.org]On Behalf Of tm
Sent: = Thursday,=20 December 12, 2002 01:22
To: = dhcwg@ietf.org
Subject:=20 [dhcwg] FORCE RENEW questions

Two questions:

A) Is DHCP FORCE RENEW supported by = any operating=20 system today? Or are there any known plans for it at Microsoft, Linux, = BSD,=20 etc.?

B) Is it possible to send a FORCE = RENEW to a NIC=20 that has not yet been configured with an IP address, that is, a NIC = that never=20 received a DHCP reply after reboot? (With the result that the host = will do a=20 DHCP request).

/TM

------=_NextPart_000_0010_01C2A222.C77497D0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Fri Dec 13 20:20:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12293 for ; Fri, 13 Dec 2002 20:20:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBE1Mqx26629 for dhcwg-archive@odin.ietf.org; Fri, 13 Dec 2002 20:22:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE1Mqv26626 for ; Fri, 13 Dec 2002 20:22:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12287 for ; Fri, 13 Dec 2002 20:19:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE1KZv26559; Fri, 13 Dec 2002 20:20:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE1Jxv26478 for ; Fri, 13 Dec 2002 20:19:59 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12190; Fri, 13 Dec 2002 20:16:54 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gBE1JoD29750; Fri, 13 Dec 2002 17:19:50 -0800 (PST) Message-Id: <200212140119.gBE1JoD29750@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 13 Dec 2002 17:19:50 -0800 Subject: [dhcwg] RFC 3442 on The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3442 Title: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 Author(s): T. Lemon, S. Cheshire, B. Volz Status: Standards Track Date: December 2002 Mailbox: Ted.Lemon@nominum.com, rfc@stuartcheshire.org, bernie.volz@ericsson.com Pages: 9 Characters: 19370 Updates: 2132 I-D Tag: draft-ietf-dhc-csr-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3442.txt This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Working Group of the IETF. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <021213171741.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3442 --OtherAccess Content-Type: Message/External-body; name="rfc3442.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021213171741.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Mon Dec 16 13:49:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13900 for ; Mon, 16 Dec 2002 13:49:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGIppC07038 for dhcwg-archive@odin.ietf.org; Mon, 16 Dec 2002 13:51:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGIppv07035 for ; Mon, 16 Dec 2002 13:51:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13895 for ; Mon, 16 Dec 2002 13:48:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGIiHv06844; Mon, 16 Dec 2002 13:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGIgBv06787 for ; Mon, 16 Dec 2002 13:42:11 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13629 for ; Mon, 16 Dec 2002 13:39:03 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18O0Bm-00080k-00 for ; Mon, 16 Dec 2002 10:42:02 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Dec 2002 10:46:07 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A677F8@homer.incognito.com.> From: "Kostur, Andre" To: "'dhcwg@ietf.org'" Date: Mon, 16 Dec 2002 10:46:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A533.632FB020" Subject: [dhcwg] LeaseQuery draft Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2A533.632FB020 Content-Type: text/plain; charset="iso-8859-1" The draft Atlanta minutes make reference to a draft-ietf-dhc-leasequery-05.txt, but the latest version I can find is -04. Any idea where -05 is? ------_=_NextPart_001_01C2A533.632FB020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LeaseQuery draft

The draft Atlanta minutes make reference to a = draft-ietf-dhc-leasequery-05.txt, but the latest version I can find is = -04. Any idea where -05 is?

------_=_NextPart_001_01C2A533.632FB020-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Tue Dec 17 08:19:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13340 for ; Tue, 17 Dec 2002 08:19:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHDM6c09996 for dhcwg-archive@odin.ietf.org; Tue, 17 Dec 2002 08:22:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHDM5v09993 for ; Tue, 17 Dec 2002 08:22:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13316 for ; Tue, 17 Dec 2002 08:19:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHDJov09891; Tue, 17 Dec 2002 08:19:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHDIPv09860 for ; Tue, 17 Dec 2002 08:18:25 -0500 Received: from localhost.prospeed.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13269 for ; Tue, 17 Dec 2002 08:15:24 -0500 (EST) From: rdroms@prospeed.net Received: from Debug (ns2 [63.84.180.20] (may be forged)) by localhost.prospeed.net (8.11.6/8.9.3) with SMTP id gBHDHtX21676; Tue, 17 Dec 2002 08:17:59 -0500 Message-Id: <200212171317.gBHDHtX21676@localhost.prospeed.net> To: , Subject: Re: [dhcwg] LeaseQuery draft Date: Tue, 17 Dec 2002 13:17:59 GMT X-Mailer: Endymion MailMan Professional Edition v3.0.35 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sorry, that's my mistake. There was confusion about the numbering for that Internet Draft. The latest version is -04. - Ralph > The draft Atlanta minutes make reference to a > draft-ietf-dhc-leasequery-05.txt, but the latest version I can find is -04. > Any idea where -05 is? > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Tue Dec 17 14:58:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21790 for ; Tue, 17 Dec 2002 14:58:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHK0jM32571 for dhcwg-archive@odin.ietf.org; Tue, 17 Dec 2002 15:00:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHK0iv32568 for ; Tue, 17 Dec 2002 15:00:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21786 for ; Tue, 17 Dec 2002 14:57:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHJvRv32429; Tue, 17 Dec 2002 14:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHJtav32361 for ; Tue, 17 Dec 2002 14:55:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21624; Tue, 17 Dec 2002 14:52:29 -0500 (EST) Message-Id: <200212171952.OAA21624@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , dhcwg@ietf.org From: The IESG Date: Tue, 17 Dec 2002 14:52:29 -0500 Subject: [dhcwg] Protocol Action: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Dynamic Host Configuration Protocol for IPv6 (DHCPv6)' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC2462) and can be used separately or concurrently with the latter to obtain configuration parameters. DHCPv6 offers two modes of operation. In stateful mode, the DHC server maintains per-client configuration information (e.g., addresses). In stateless mode, the DHC server stores no per-client information. Stateless mode is used when the information provided is the same regardless of who asks for it, or because the appropriate configuration information to be returned to a client can be determined idempotently based on the information on the request (e.g., all clients connected to particular links are to use the same set of DNS servers). Working Group Summary There was consensus for this in the WG and no significant issues were raised during the IETF Last Call. Protocol Quality This protocol has been reviewed for the IESG by Thomas Narten. RFC Editor Note: In Section 21.1, delete the following sentence from the first paragraph: > Relay agents and servers MUST support manual configuration and > installation of static keys. In Section 21.1, change the item: > Key management Because the relay agents and servers must be > manually configured, no automated key management > is required. to Key management Because the relay agents and servers are used within an organization, public key schemes are not necessary. Because the relay agents and servers must be manually configured, manually configured key management may suffice, but doesn't provide defense against replayed messages. Accordingly, IKE with preshared secrets SHOULD be supported. IKE with public keys MAY be supported. In Section 23, Security Considerations, add the following new second paragraph, immediately after the first one: Use of manually configured preshared keys for IPsec between relay agents and servers does not defend against replayed DHCP messages. Replayed messages can represent a DOS attack through exhaustion of processing resources, but not through mis-configuration or exhaustion of other resources such as assignable addresses. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Tue Dec 17 15:35:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23049 for ; Tue, 17 Dec 2002 15:35:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHKcVG02838 for dhcwg-archive@odin.ietf.org; Tue, 17 Dec 2002 15:38:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKcVv02835 for ; Tue, 17 Dec 2002 15:38:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23032 for ; Tue, 17 Dec 2002 15:35:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKaAv02113; Tue, 17 Dec 2002 15:36:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKZ4v02030 for ; Tue, 17 Dec 2002 15:35:04 -0500 Received: from e6.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22815 for ; Tue, 17 Dec 2002 15:31:58 -0500 (EST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBHKYwYA013022 for ; Tue, 17 Dec 2002 15:34:58 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBHKYul8027694 for ; Tue, 17 Dec 2002 15:34:56 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gBHKWBH20740 for ; Tue, 17 Dec 2002 15:32:11 -0500 Message-Id: <200212172032.gBHKWBH20740@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Tue, 17 Dec 2002 15:32:11 -0500 From: Thomas Narten Subject: [dhcwg] FWD: Re: IESG draft-cheshire-ipv4-acd-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Anyone care to comment on the assertion below regarding a typo in 2131? Thomas - ------- Forwarded Message From: Stuart Cheshire To: "Erik Nordmark" Cc: Date: Fri, 13 Dec 2002 18:45:26 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt At last, a reply that actually relates to the subject line. >> > But the ongoing conflict detection (causing >> > IP address change when a conflict appears) and broadcast replies looks >> > more like a useful experiment to me. >> >> It has been a five-year experiment by Apple. > >Do you have a pointer to the data that has been collected as part of >that experiment? There is no data. That's the point. After shipping millions of machines per year for five years, the number of reported problems is zero. >How about adding > This document updates RFC 826 and RFC 2132. I added a header line that says "Updates: 826, 2132" >RFC 2131 actually talks about an ARP reply and not the ARP request >with sender=target. See section 4.4.1 in RFC 2131. >So you don't seem to be consistent with RFC 2131. Stevens describes using ARP request. BSD broadcasts an ARP request to announce its address. Mac OS 9 broadcasts an ARP request to announce its address. Mac OS X broadcasts an ARP request to announce its address. Windows broadcasts an ARP request to announce its address. RFC 2131 describes broadcasting an ARP reply, but like many things in RFC 2131, this is probably a typo. As has been pointed out many times by many people, broadcasting an ARP reply is unconventional, and best avoided where not necessary. Therefore I avoided it and followed the behaviour described by Stevens (and implemented on Mac, Windows, Unix, etc.) instead. In any case, the "Packet Reception" rules of RFC 826 are exceedingly clear that checking the packet opcode is the *last* check that is done, after all other packet processing has been completed. Do you have a technical opinion to offer about which you think is best? >I wasn't suggesting a normative reference; that isn't needed since the >document is self-contained. But pointing out the relationship using a >non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be >useful for the implementors that are going to implement both. There is already a non-normative reference to the v4ll draft. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> At any time, if a host >> receives an ARP packet (request *or* reply) where the 'sender IP >> address' is the host's own IP address, but the 'sender hardware >> address' does not match any of the host's own interface addresses, >> then this is a conflicting ARP packet > >I fail to find the word "multihoming" or any explicit mention of >multiple interfaces in the above text. The phrase, "any of the host's own interface addresses" is a mention of multiple interfaces. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> > I would assume that ACD can >> > operate independently for each interface even though v4LL has some >> > extra stuff related to multi-interface nodes. >> >> No, the specification needs to deal with the case when a host has two >> interfaces (say wireless and Ethernet) on the same link. > >And you claim you can't do that by having the interfaces be configured >independently of eachother? If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >I think my conclusion was that the time should be shorter >than 8 seconds and not longer. 8 seconds is a useless compromise >as far as I can tell since it is unecessarily long when STP isn't triggered >and too short when STP is triggered (with out of the box bridge >configurations.) Thus 2 or 3 seconds should be fine. The document already has specific text allowing shorter timeouts in cases where the implementer has reason to believe that is a wise design choice. The document already has specific text describing how the individual choice of timeout doesn't have any impact on interoperability with other devices. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> Most network operators today, with good reason, set their port blocking >> time to five seconds. > >Doesn't match my experience. And doesn't match the IEEE 802.1D >recommendation. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >Is there a way for the host to reliably detect whether the switches run >RSTP instead of STP? Quoting from Mick Seaman: "Yes, the driver can easily tell the difference between an RSTP and an STP BPDU, they are different 'BPDU types', a type field being defined in the BPDU format." If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> A Zero Configuration device may want to make use of address conflict >> detection. If address conflict detection requires a mandatory >> user-configuration option, then that means that Zero Configuration >> devices require mandatory user-configuration options, a >> self-contradiction. > >I'd understand that comment if it was about >draft-ietf-zeroconf-ipv4-link-local >but not about the ACD document. Since the addresses are configured either >manually or by DHCP (or some other provisioning protocol) it is possible to >add a knob in the manual config or in DHCP, respectively. So I don't >understand the issue your are concerned about. I don't understand why you think there is a problem. DHCP clients have done address conflict detection for years, and no one has asked for an option to disable address conflict detection there. Macs have done address conflict detection for manual addresses for years, and no one has asked for an option to disable that either. Even Windows tells you if you manually set your IP address to an address that's already in use. If you've ever struggled with a network where two machines were set to the same IP address, you'd think it insane to ever think you'd NOT want to get all the help you can to diagnose and fix that problem. I don't understand why now, after all these years of successful address conflict detection that no one ever complained about, there's suddenly a feeling that we need manual configuration options to disable it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org - ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailnull@www1.ietf.org Tue Dec 17 16:32:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24470 for ; Tue, 17 Dec 2002 16:32:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHLZBT05941 for dhcwg-archive@odin.ietf.org; Tue, 17 Dec 2002 16:35:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLZBv05938 for ; Tue, 17 Dec 2002 16:35:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24465 for ; Tue, 17 Dec 2002 16:32:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLWUv05782; Tue, 17 Dec 2002 16:32:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLV9v05714 for ; Tue, 17 Dec 2002 16:31:09 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24345 for ; Tue, 17 Dec 2002 16:28:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id gBHLV0W19418; Tue, 17 Dec 2002 15:31:00 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gBHLV0010757; Tue, 17 Dec 2002 15:31:00 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Dec 2002 15:31:00 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Date: Tue, 17 Dec 2002 15:29:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A612.A4D50EE6" Subject: [dhcwg] Is RFC 2131 Correct? ARP Request or ARP Reply ... IT IS CORRECT - BOTH ARE SENT!! Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2A612.A4D50EE6 Content-Type: text/plain; charset="ISO-8859-1" RFC 2131 is CORRECT as it is!!! See the text below. The first part talks about an ARP Request. This is used to solicit an ARP reply from another host that might be using that address. If no reply is received, then the client uses the address and THEN sends an ARP reply. The ARP reply causes the caches in all other systems on the LAN to be updated SHOULD THEY have an old mapping for the address (for example, from the previous client that released the address). Perhaps the error in RFC 2131 is that it doesn't make that fully clear. In the last sentence of the text from 2131 below, it should have said that if the client does not receive a reply to ARP request, it uses the address and the client SHOULD broadcast an ARP reply ... If the parameters are acceptable, the client records the address of the server that supplied the parameters from the 'server identifier' field and sends that address in the 'server identifier' field of a DHCPREQUEST broadcast message. Once the DHCPACK message from the server arrives, the client is initialized and moves to BOUND state. The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER message. The client records the lease expiration time as the sum of the time at which the original request was sent and the duration of the lease from the DHCPACK message. The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the Droms Standards Track [Page 38] RFC 2131 Dynamic Host Configuration Protocol March 1997 network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet. -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Tuesday, December 17, 2002 3:32 PM To: dhcwg@ietf.org Subject: [dhcwg] FWD: Re: IESG draft-cheshire-ipv4-acd-02.txt Anyone care to comment on the assertion below regarding a typo in 2131? Thomas - ------- Forwarded Message From: Stuart Cheshire To: "Erik Nordmark" Cc: Date: Fri, 13 Dec 2002 18:45:26 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt At last, a reply that actually relates to the subject line. >> > But the ongoing conflict detection (causing >> > IP address change when a conflict appears) and broadcast replies looks >> > more like a useful experiment to me. >> >> It has been a five-year experiment by Apple. > >Do you have a pointer to the data that has been collected as part of >that experiment? There is no data. That's the point. After shipping millions of machines per year for five years, the number of reported problems is zero. >How about adding > This document updates RFC 826 and RFC 2132. I added a header line that says "Updates: 826, 2132" >RFC 2131 actually talks about an ARP reply and not the ARP request >with sender=target. See section 4.4.1 in RFC 2131. >So you don't seem to be consistent with RFC 2131. Stevens describes using ARP request. BSD broadcasts an ARP request to announce its address. Mac OS 9 broadcasts an ARP request to announce its address. Mac OS X broadcasts an ARP request to announce its address. Windows broadcasts an ARP request to announce its address. RFC 2131 describes broadcasting an ARP reply, but like many things in RFC 2131, this is probably a typo. As has been pointed out many times by many people, broadcasting an ARP reply is unconventional, and best avoided where not necessary. Therefore I avoided it and followed the behaviour described by Stevens (and implemented on Mac, Windows, Unix, etc.) instead. In any case, the "Packet Reception" rules of RFC 826 are exceedingly clear that checking the packet opcode is the *last* check that is done, after all other packet processing has been completed. Do you have a technical opinion to offer about which you think is best? >I wasn't suggesting a normative reference; that isn't needed since the >document is self-contained. But pointing out the relationship using a >non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be >useful for the implementors that are going to implement both. There is already a non-normative reference to the v4ll draft. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> At any time, if a host >> receives an ARP packet (request *or* reply) where the 'sender IP >> address' is the host's own IP address, but the 'sender hardware >> address' does not match any of the host's own interface addresses, >> then this is a conflicting ARP packet > >I fail to find the word "multihoming" or any explicit mention of >multiple interfaces in the above text. The phrase, "any of the host's own interface addresses" is a mention of multiple interfaces. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> > I would assume that ACD can >> > operate independently for each interface even though v4LL has some >> > extra stuff related to multi-interface nodes. >> >> No, the specification needs to deal with the case when a host has two >> interfaces (say wireless and Ethernet) on the same link. > >And you claim you can't do that by having the interfaces be configured >independently of eachother? If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >I think my conclusion was that the time should be shorter >than 8 seconds and not longer. 8 seconds is a useless compromise >as far as I can tell since it is unecessarily long when STP isn't triggered >and too short when STP is triggered (with out of the box bridge >configurations.) Thus 2 or 3 seconds should be fine. The document already has specific text allowing shorter timeouts in cases where the implementer has reason to believe that is a wise design choice. The document already has specific text describing how the individual choice of timeout doesn't have any impact on interoperability with other devices. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> Most network operators today, with good reason, set their port blocking >> time to five seconds. > >Doesn't match my experience. And doesn't match the IEEE 802.1D >recommendation. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >Is there a way for the host to reliably detect whether the switches run >RSTP instead of STP? Quoting from Mick Seaman: "Yes, the driver can easily tell the difference between an RSTP and an STP BPDU, they are different 'BPDU types', a type field being defined in the BPDU format." If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> A Zero Configuration device may want to make use of address conflict >> detection. If address conflict detection requires a mandatory >> user-configuration option, then that means that Zero Configuration >> devices require mandatory user-configuration options, a >> self-contradiction. > >I'd understand that comment if it was about >draft-ietf-zeroconf-ipv4-link-local >but not about the ACD document. Since the addresses are configured either >manually or by DHCP (or some other provisioning protocol) it is possible to >add a knob in the manual config or in DHCP, respectively. So I don't >understand the issue your are concerned about. I don't understand why you think there is a problem. DHCP clients have done address conflict detection for years, and no one has asked for an option to disable address conflict detection there. Macs have done address conflict detection for manual addresses for years, and no one has asked for an option to disable that either. Even Windows tells you if you manually set your IP address to an address that's already in use. If you've ever struggled with a network where two machines were set to the same IP address, you'd think it insane to ever think you'd NOT want to get all the help you can to diagnose and fix that problem. I don't understand why now, after all these years of successful address conflict detection that no one ever complained about, there's suddenly a feeling that we need manual configuration options to disable it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org - ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2A612.A4D50EE6 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Is RFC 2131 Correct? ARP Request or ARP Reply ... IT IS CORRECT = - BOTH ARE SENT!!

RFC 2131 is CORRECT as it is!!! See the text = below.

The first part talks about an ARP Request. This is = used to solicit an
ARP reply from another host that might be using that = address. If no
reply is received, then the client uses the address = and THEN sends an
ARP reply. The ARP reply causes the caches in all = other systems on the
LAN to be updated SHOULD THEY have an old mapping = for the address (for
example, from the previous client that released the = address).

Perhaps the error in RFC 2131 is that it doesn't make = that fully clear.
In the last sentence of the text from 2131 below, it = should have said
that if the client does not receive a reply to ARP = request, it uses
the address and the client SHOULD broadcast an ARP = reply ...

   If the parameters are acceptable, the = client records the address of
   the server that supplied the parameters = from the 'server identifier'
   field and sends that address in the = 'server identifier' field of a
   DHCPREQUEST broadcast message. = Once the DHCPACK message from the
   server arrives, the client is = initialized and moves to BOUND state.
   The DHCPREQUEST message contains the = same 'xid' as the DHCPOFFER
   message. The client records the = lease expiration time as the sum of
   the time at which the original request = was sent and the duration of
   the lease from the DHCPACK = message.    The client SHOULD perform a
   check on the suggested address to = ensure that the address is not
   already in use. For example, if = the client is on a network that
   supports ARP, the client may issue an = ARP request for the suggested
   request. When broadcasting an ARP = request for the suggested address,
   the client must fill in its own = hardware address as the sender's
   hardware address, and 0 as the sender's = IP address, to avoid
   confusing ARP caches in other hosts on = the same subnet. If the

Droms &nbs= p; &nbs= p; Standards = Track &= nbsp; [Page 38]
=0C
RFC = 2131 Dynamic Host = Configuration Protocol = March 1997

   network address appears to be in use, = the client MUST send a
   DHCPDECLINE message to the server. The = client SHOULD broadcast an ARP
   reply to announce the client's new IP = address and clear any outdated
   ARP cache entries in hosts on the = client's subnet.

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Tuesday, December 17, 2002 3:32 PM
To: dhcwg@ietf.org
Subject: [dhcwg] FWD: Re: IESG = draft-cheshire-ipv4-acd-02.txt

Anyone care to comment on the assertion below = regarding a typo in 2131?

Thomas
- ------- Forwarded Message

From: Stuart Cheshire = <cheshire@apple.com>
To: "Erik Nordmark" = <Erik.Nordmark@sun.com>
Cc: <zeroconf@merit.edu>
Date: Fri, 13 Dec 2002 18:45:26 -0800
Subject: Re: IESG = draft-cheshire-ipv4-acd-02.txt

At last, a reply that actually relates to the subject = line.

>> > But the ongoing conflict detection = (causing
>> > IP address change when a conflict = appears) and broadcast replies looks
>> > more like a useful experiment to = me.
>>
>> It has been a five-year experiment by = Apple.
>
>Do you have a pointer to the data that has been = collected as part of
>that experiment?

There is no data. That's the point. After shipping = millions of machines
per year for five years, the number of reported = problems is zero.

>How about adding
> This = document updates RFC 826 and RFC 2132.

I added a header line that says "Updates: 826, = 2132"

>RFC 2131 actually talks about an ARP reply and = not the ARP request
>with sender=3Dtarget. See section 4.4.1 in RFC = 2131.
>So you don't seem to be consistent with RFC = 2131.

Stevens describes using ARP request.
BSD broadcasts an ARP request to announce its = address.
Mac OS 9 broadcasts an ARP request to announce its = address.
Mac OS X broadcasts an ARP request to announce its = address.
Windows broadcasts an ARP request to announce its = address.

RFC 2131 describes broadcasting an ARP reply, but = like many things in RFC
2131, this is probably a typo. As has been pointed = out many times by many
people, broadcasting an ARP reply is unconventional, = and best avoided
where not necessary. Therefore I avoided it and = followed the behaviour
described by Stevens (and implemented on Mac, = Windows, Unix, etc.)
instead.

In any case, the "Packet Reception" rules = of RFC 826 are exceedingly
clear that checking the packet opcode is the *last* = check that is done,
after all other packet processing has been = completed.

Do you have a technical opinion to offer about which = you think is best?

>I wasn't suggesting a normative reference; that = isn't needed since the
>document is self-contained. But pointing out the = relationship using a
>non-normative reference to draft-ietf-zeroconf-ip= v6-link-local would be
>useful for the implementors that are going to = implement both.

There is already a non-normative reference to the = v4ll draft.