From dhcwg-admin@ietf.org Thu May 1 10:43:41 2003 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 KAA14522; Thu, 1 May 2003 10:43:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EnV814970; Thu, 1 May 2003 10:49:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EfD812612 for ; Thu, 1 May 2003 10:41:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13913 for ; Thu, 1 May 2003 10:34:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFB3-00020g-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:49 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BFAy-00020O-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:44 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41EahWS018366 for ; Thu, 1 May 2003 10:36:44 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-797.cisco.com [10.82.243.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01095 for ; Thu, 1 May 2003 10:36:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501094136.00b8f828@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 May 2003 09:52:19 -0400 To: dhcwg@ietf.org From: Ralph Droms In-Reply-To: References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Address selection for Information-request/Reply messages 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: , At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >1. address selection of Information-request/Reply exchanges > >According to the DHCPv6 base spec, the client should send Information >Request messages to the All_DHCP_Relay_Agents_and_Servers multicast >address (FF02::1:2). However, doesn't it make much sense to allow the >client to send the requests to the All_DHCP_Servers multicast address >FF05::1:3? Since the stateless usage assumes the client has obtained >its IPv6 addresses through some other mechanism, I don't see a reason >that the client cannot do so. If we allow this, the client can access >an off-link server without relying on a relay agent, which would help >the deployment. On the other hand, we don't want to require deployment of multicast to enable stateless DHCPv6. One possibility would be to allow the use of All_DHCP_Servers, with an explicit warning that a site that doesn't implement multicast MUST use relay agents AND the relay agents must listen to All_DHCP_Servers (which is a change from the current spec). In fact, it would be important to note that a site MUST NOT both implement multicast and configure relay agents to listen on All_DHCP_Servers, as such a configuration would result in the servers receiving multiple copies of client messages. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 10:45:48 2003 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 KAA14685; Thu, 1 May 2003 10:45:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Epd815415; Thu, 1 May 2003 10:51:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EfE812616 for ; Thu, 1 May 2003 10:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13916 for ; Thu, 1 May 2003 10:34:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFB4-00020j-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:50 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BFAy-00020P-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:44 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41EaiWS018374 for ; Thu, 1 May 2003 10:36:44 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-797.cisco.com [10.82.243.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01102 for ; Thu, 1 May 2003 10:36:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501095224.00b99538@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 May 2003 09:55:35 -0400 To: dhcwg@ietf.org From: Ralph Droms In-Reply-To: References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Update of parameters supplied through stateless DHCPv6 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: , At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >2. how to invalidate stale configuration parameters > >The stateless usage does not have the notion of Renew or Rebind. So, >how the client can purge configuration parameters (e.g. DNS addresses) >when they become invalidated? I guess we need a some kind of >"timeout" parameter, which suggests to the client that it refresh the >parameters in a certain period. Bernie responded to this issue: >There are three mechanisms available: > >a. Whenever the client would normally determine that its stateless addresses >are suspect, after confirming them or obtaining new addresses, it can use >Information-Request to obtain new parameters. Note that a client may also >use triggers such as existing address lifetimes expiring (if a prefix is >has expired, it likely means some changes to the networks configuration and >hence doing an Information-Request to obtain updated parameters may be in >order). > >b. The server can send a Reconfigure provided the client has communicated it >is able/willing to support this in the Information-Request. > >c. The client is free to do Information-Requests at times of its choosing >(there is no prohibition against doing this). Of course, the client >should not do this too frequently. > >If someone feels these mechanisms are insufficient, they could always write >a draft that specifies an "Information Lifetime" or "Information Renewal Time" >at which point the client could refresh the information. This option could >specify T1 and T2 times - at T1 the client renews by including the server >identifier option of the server that gave it the configuration parameters, at >T2 it removes this option and any server may respond to the Information-Request. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 10:47:56 2003 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 KAA14837; Thu, 1 May 2003 10:47:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Err815928; Thu, 1 May 2003 10:53:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EfG812620 for ; Thu, 1 May 2003 10:41:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13920 for ; Thu, 1 May 2003 10:34:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFB6-00020m-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:52 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BFB0-00020Q-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:46 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41EajWS018390 for ; Thu, 1 May 2003 10:36:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-797.cisco.com [10.82.243.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01114 for ; Thu, 1 May 2003 10:36:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501095650.00b9b090@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 May 2003 09:58:56 -0400 To: dhcwg@ietf.org From: Ralph Droms In-Reply-To: References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] When to invoke the stateless DHCPv6 message exchange 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: , At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >3. how to restart the stateless procedure > >It would be useful if we had a guideline where the client should >restart the Information-request/Reply exchanges, particularly when the >client is a nomadic host moving link to link. Section 18.1.2 of the >base specification can be a good example of this. Good point. I'll add text based on the text from 18.1.2 in dhcpv6-28. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 10:50:01 2003 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 KAA14936; Thu, 1 May 2003 10:50:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Etu816049; Thu, 1 May 2003 10:55:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EfH812624 for ; Thu, 1 May 2003 10:41:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13923 for ; Thu, 1 May 2003 10:34:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFB7-00020p-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:53 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BFB1-00020R-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:47 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41EakWS018401; Thu, 1 May 2003 10:36:47 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-797.cisco.com [10.82.243.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01118; Thu, 1 May 2003 10:36:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501095907.00b99538@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 May 2003 10:07:10 -0400 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms In-Reply-To: References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Stateless DHCPv6 == "Other stateful configuration"? 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 following comment was posted to the dhcwg mailing list during the WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt Because the issue touches on RFC 2461 and RFC 2462, I've cross-posted to both the ipv6 and dhc WG mailing lists. Please respond to the dhcwg@ietf.org mailing list - RD At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >4. interaction/consistency with RFC 246[12] > >How the stateless usage is related to the "Other stateful >configuration" of router advertisements defined in RFC 2461 and 2462? >Is the client (host) expected to start the stateless DHCPv6 when it >receives a router advertisement with the "Other stateful >configuration" flag being set? If so, how can we interpret the >"inconsistency" between the "stateless" DHCPv6 usage and the >"stateful" router advertisement flag? Perhaps this is just a matter >of wording. But, if RFC 2461 really intended a "stateful" protocol >(i.e., where a server maintains lease state for the other >configuration parameters), we may need to consider the gap as a >fundamental architecture issue. Well, I guess we first need to agree that draft-ietf-dhc-dhcpv6-stateless-00.txt meets the expectation of "Other stateful configuration" in RFC 2461. I intended draft-ietf-dhc-dhcpv6-stateless-00.txt to be the configuration protocol used when the "Other stateful configuration" flag is set. Is there any objection to explicitly specifying draft-ietf-dhc-dhcpv6-stateless-00.txt for this use? If there is no objection, we'll need to adjust the words to make the connection explicit and avoid confusion... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 10:52:03 2003 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 KAA15044; Thu, 1 May 2003 10:52:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Ew0816295; Thu, 1 May 2003 10:58:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Eff812642 for ; Thu, 1 May 2003 10:41:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13938 for ; Thu, 1 May 2003 10:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFBW-00021B-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:37:18 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19BFBQ-00020N-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:37:12 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41Eah4c000491 for ; Thu, 1 May 2003 10:36:43 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-797.cisco.com [10.82.243.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01092 for ; Thu, 1 May 2003 10:36:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030430185732.044dbaf0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 May 2003 09:40:17 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Results of recent WG last calls 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: , Here are the results of some recent last WG last calls: draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt See http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01968.html for a comment. No other comments about this draft were received during the last call. This draft did not receive enough positive support to be submitted to the IESG. ===== draft-ietf-dhc-dhcpv6-loadb-02.txt No comments about this document were received during the last call. This draft did not receive enough positive support to be submitted to the IESG. ===== draft-ietf-dhc-dhcpv6-interop-01.txt Jinmei-san responded that this draft is ready for submission to the IESG. No other comments about this draft were received during the last call. Although this draft only received one comment during WG last call, it is important to move the draft forward because it should be published before the DHCPv6 specification is published as an RFC. Also, this draft will be published as Informational, rather than as an Internet Standard. Therefore, I will submit the draft to the IESG. ===== draft-ietf-dhc-dhcpv6-stateless-00.txt Jinmei-san posted a comment about the draft that started a discussion thread on the mailing list (see http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01999.html) There were several comments suggesting that stateless DHCPv6 should not be limited to just the DNS configuration options. I will revise this draft in response to the comments about future extensibility to include other options. The WG should discuss Jinmei-san's other issues before the draft is submitted to the IESG. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 12:18:24 2003 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 MAA20291; Thu, 1 May 2003 12:18:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GOB806674; Thu, 1 May 2003 12:24:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GCR803786 for ; Thu, 1 May 2003 12:12:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19650 for ; Thu, 1 May 2003 12:05:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGbJ-0003K9-00 for dhcwg@ietf.org; Thu, 01 May 2003 12:08:01 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19BGbD-0003Ih-00 for dhcwg@ietf.org; Thu, 01 May 2003 12:07:56 -0400 Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h41G7LnZ027852; Thu, 1 May 2003 11:07:21 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h41G7LOV012211; Thu, 1 May 2003 11:07:21 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 1 May 2003 11:07:21 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Results of recent WG last calls Date: Thu, 1 May 2003 11:05:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C30FFB.31293D20" 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_01C30FFB.31293D20 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30FFB.31293D20" ------_=_NextPart_001_01C30FFB.31293D20 Content-Type: text/plain; charset="ISO-8859-1" Ralph: I support draft-ietf-dhc-dhcpv6-interop-01.txt as I indicated to you in a private email to get an understanding on one issue before posting public support. Don't know if this changes the outcome of the Last-Call, but as I don't think you ever responded to the issue, I forgot to submit my public support. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, May 01, 2003 9:40 AM To: dhcwg@ietf.org Subject: [dhcwg] Results of recent WG last calls Here are the results of some recent last WG last calls: draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt See http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01968.html for a comment. No other comments about this draft were received during the last call. This draft did not receive enough positive support to be submitted to the IESG. ===== draft-ietf-dhc-dhcpv6-loadb-02.txt No comments about this document were received during the last call. This draft did not receive enough positive support to be submitted to the IESG. ===== draft-ietf-dhc-dhcpv6-interop-01.txt Jinmei-san responded that this draft is ready for submission to the IESG. No other comments about this draft were received during the last call. Although this draft only received one comment during WG last call, it is important to move the draft forward because it should be published before the DHCPv6 specification is published as an RFC. Also, this draft will be published as Informational, rather than as an Internet Standard. Therefore, I will submit the draft to the IESG. ===== draft-ietf-dhc-dhcpv6-stateless-00.txt Jinmei-san posted a comment about the draft that started a discussion thread on the mailing list (see http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01999.html) There were several comments suggesting that stateless DHCPv6 should not be limited to just the DNS configuration options. I will revise this draft in response to the comments about future extensibility to include other options. The WG should discuss Jinmei-san's other issues before the draft is submitted to the IESG. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C30FFB.31293D20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Results of recent WG last calls

Ralph:

I support draft-ietf-dhc-dhcpv6-interop-01.txt as I = indicated to you in a private
email to get an understanding on one issue before = posting public support. Don't know
if this changes the outcome of the Last-Call, but as = I don't think you ever responded
to the issue, I forgot to submit my public = support.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, May 01, 2003 9:40 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Results of recent WG last = calls


Here are the results of some recent last WG last = calls:

draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt

  See
  http://www1.ietf.org/mail-archive/working-groups/dhcwg= /current/msg01968.html
  for a comment.  No other comments about = this draft
  were received during the last call.

  This draft did not receive enough positive = support
  to be submitted to the IESG.
=3D=3D=3D=3D=3D

draft-ietf-dhc-dhcpv6-loadb-02.txt

  No comments about this document were received = during the last call.

  This draft did not receive enough positive = support
  to be submitted to the IESG.
=3D=3D=3D=3D=3D

draft-ietf-dhc-dhcpv6-interop-01.txt

  Jinmei-san responded that this draft is ready = for submission
  to the IESG.  No other comments about = this draft
  were received during the last call.

  Although this draft only received one comment = during WG
  last call, it is important to move the draft = forward because
  it should be published before the DHCPv6 = specification is
  published as an RFC.  Also, this draft = will be published
  as Informational, rather than as an Internet = Standard.
  Therefore, I will submit the draft to the = IESG.
=3D=3D=3D=3D=3D

draft-ietf-dhc-dhcpv6-stateless-00.txt

  Jinmei-san posted a comment about the draft = that started
  a discussion thread on the mailing list (see = http://www1.ietf.org/mail-archive/working-groups/dhcwg= /current/msg01999.html)

  There were several comments suggesting that = stateless DHCPv6
  should not be limited to just the DNS = configuration
  options.

  I will revise this draft in response to the = comments about
  future extensibility to include other = options.  The WG
  should discuss Jinmei-san's other issues = before the draft
  is submitted to the IESG.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

  ------_=_NextPart_001_01C30FFB.31293D20-- ------_=_NextPart_000_01C30FFB.31293D20 Content-Type: message/rfc822 Content-Description: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-interop-01.txt Message-ID: From: "Bernie Volz (EUD)" To: 'Ralph Droms' Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-interop-01.txt Date: Sun, 13 Apr 2003 22:54:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C30FFB.31293D20" ------_=_NextPart_003_01C30FFB.31293D20 Content-Type: text/plain; charset="ISO-8859-1" Ralph: (I did not CC the DHC WG Mailing List.) For issue 1, what happened to the concept of making this similar to a CONFIRM and sending a Not-on-Link? Note that the Reply with IAs with 0 for lifetimes is a rather strong statement for the client to stop using the addresses. Practically, I'm not sure sending a Not-On-Link would be that different. Other than this issue (where it would be good to know that it was considered and rejected), I will support the document. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, April 11, 2003 11:19 AM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-interop-01.txt This message announces a WG last call on "Results from Interoperability Tests of DHCPv6 Implementations" . The last call will conclude on Friday, April 25. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-dhcpv6-interop-01.txt provides a published record of issues discovered through interoperability testing of independent implementations of DHCPv6 , for review and discussion by the appropriate IETF working groups. This document is being considered for Informational status, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-interop-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_003_01C30FFB.31293D20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-interop-01.txt

Ralph:

(I did not CC the DHC WG Mailing List.)

For issue 1, what happened to the concept of making = this similar to a
CONFIRM and sending a Not-on-Link? Note that the = Reply with IAs with 0
for lifetimes is a rather strong statement for the = client to stop using
the addresses. Practically, I'm not sure sending a = Not-On-Link would be
that different.

Other than this issue (where it would be good to know = that it was
considered and rejected), I will support the = document.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, April 11, 2003 11:19 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-interop-01.txt


This message announces a WG last call on = "Results from
Interoperability Tests of DHCPv6 = Implementations"
<draft-ietf-dhc-dhcpv6-interop-01.txt>.  = The last call will conclude
on Friday, April 25.

Please respond to this WG last call.  If you = support acceptance of the
document without change, respond with a simple = acknowledgment, so that
support for the document can be assessed.

draft-ietf-dhc-dhcpv6-interop-01.txt provides a = published record of
issues discovered through interoperability testing = of independent
implementations of DHCPv6 = <draft-ietf-dhc-dhcpv6-28.txt>, for review
and discussion by the appropriate IETF working = groups.  This document
is being considered for Informational status, and is = available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhc= pv6-interop-01.txt

- Ralph Droms

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_003_01C30FFB.31293D20-- ------_=_NextPart_000_01C30FFB.31293D20-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailman-admin@ietf.org Thu May 1 12:42:04 2003 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 MAA21440 for ; Thu, 1 May 2003 12:42:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GmB811043 for ; Thu, 1 May 2003 12:48:11 -0400 Date: Thu, 01 May 2003 12:48:11 -0400 Message-ID: <20030501164811.17986.78424.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Thu May 1 15:25:09 2003 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 PAA02554; Thu, 1 May 2003 15:25:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JVE818193; Thu, 1 May 2003 15:31:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JPW816652 for ; Thu, 1 May 2003 15:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01910 for ; Thu, 1 May 2003 15:18:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BJc6-0005Yr-00 for dhcwg@ietf.org; Thu, 01 May 2003 15:21:02 -0400 Received: from ip26.coe.tnet.co.th ([203.146.155.26] helo=fuchsia.home) by ietf-mx with esmtp (Exim 4.12) id 19BJbz-0005Xz-00 for dhcwg@ietf.org; Thu, 01 May 2003 15:20:56 -0400 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h41JIohX003528; Fri, 2 May 2003 02:18:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h41JH9J20091; Fri, 2 May 2003 02:17:11 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] Address selection for Information-request/Reply messages In-Reply-To: <4.3.2.7.2.20030501094136.00b8f828@funnel.cisco.com> References: <4.3.2.7.2.20030501094136.00b8f828@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 May 2003 02:17:09 +0700 Message-ID: <20089.1051816629@munnari.OZ.AU> 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: , Date: Thu, 01 May 2003 09:52:19 -0400 From: Ralph Droms Message-ID: <4.3.2.7.2.20030501094136.00b8f828@funnel.cisco.com> | Infact, it would be important to note that a site MUST NOT both | implement multicast and configure relay agents to listen on | All_DHCP_Servers, as such a configuration would result in the | servers receiving multiple copies of client messages. Surely that happens with relay agents anyway? Any site with half a brain, or more, configures multiple relay agents for redundancy (assuming it also has multiple routers for redundancy of course). If the protocol can't handle multiple copies of messages being delivered to the servers, it badly needs fixing (but I actually doubt it has that defect). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 16:00:44 2003 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 QAA05724; Thu, 1 May 2003 16:00:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41K6o829885; Thu, 1 May 2003 16:06:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41K0Z828312 for ; Thu, 1 May 2003 16:00:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05269 for ; Thu, 1 May 2003 15:53:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BKA0-0005w4-00 for dhcwg@ietf.org; Thu, 01 May 2003 15:56:04 -0400 Received: from imr1.ericy.com ([208.237.135.240]) by ietf-mx with esmtp (Exim 4.12) id 19BK9u-0005u3-00 for dhcwg@ietf.org; Thu, 01 May 2003 15:55:59 -0400 Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h41Jqrat005272; Thu, 1 May 2003 14:52:53 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h41JqrNe011136; Thu, 1 May 2003 14:52:53 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 1 May 2003 14:52:52 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Robert Elz'" , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Address selection for Information-request/Reply messa ges Date: Thu, 1 May 2003 14:50:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3101A.65602620" 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_01C3101A.65602620 Content-Type: text/plain; charset="iso-8859-1" The problem comes about if we change All_DHCP_Servers to include relays to listen for messages on this address. Because now both the relays and the routers would forward messages, and the relays may forward messages forwarded by routers, you could (depending on the number of relays and routers), get a fairly large packet storm. The DHCPv6 protocol will work fine and doesn't break. Though the load placed on the servers and network may not be desireable. That is the point. Bottom line, IMHO, this is a bad idea. We shouldn't have relays listening for All_DHCP_Servers traffic. And, if we don't do that, allowing Information-Request sent directly to All_DHCP_Servers would require site multicast to work and if it doesn't or is disabled, these clients would fail to receive the requested information if the server isn't local. - Bernie -----Original Message----- From: Robert Elz [mailto:kre@munnari.oz.au] Sent: Thursday, May 01, 2003 3:17 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Address selection for Information-request/Reply messages Date: Thu, 01 May 2003 09:52:19 -0400 From: Ralph Droms Message-ID: <4.3.2.7.2.20030501094136.00b8f828@funnel.cisco.com> | Infact, it would be important to note that a site MUST NOT both | implement multicast and configure relay agents to listen on | All_DHCP_Servers, as such a configuration would result in the | servers receiving multiple copies of client messages. Surely that happens with relay agents anyway? Any site with half a brain, or more, configures multiple relay agents for redundancy (assuming it also has multiple routers for redundancy of course). If the protocol can't handle multiple copies of messages being delivered to the servers, it badly needs fixing (but I actually doubt it has that defect). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C3101A.65602620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Address selection for Information-request/Reply = messages

The problem comes about if we change All_DHCP_Servers = to include relays to
listen for messages on this address.

Because now both the relays and the routers would = forward messages, and the
relays may forward messages forwarded by routers, = you could (depending on
the number of relays and routers), get a fairly = large packet storm.

The DHCPv6 protocol will work fine and doesn't break. = Though the load placed
on the servers and network may not be desireable. = That is the point.

Bottom line, IMHO, this is a bad idea. We shouldn't = have relays listening
for All_DHCP_Servers traffic. And, if we don't do = that, allowing Information-Request
sent directly to All_DHCP_Servers would require site = multicast to work and if
it doesn't or is disabled, these clients would fail = to receive the requested
information if the server isn't local.

- Bernie

-----Original Message-----
From: Robert Elz [mailto:kre@munnari.oz.au]
Sent: Thursday, May 01, 2003 3:17 PM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Address selection for = Information-request/Reply
messages


    = Date:        Thu, 01 May 2003 = 09:52:19 -0400
    = From:        Ralph Droms = <rdroms@cisco.com>
    Message-ID:  = <4.3.2.7.2.20030501094136.00b8f828@funnel.cisco.com>

  | Infact, it would be important to note that a = site MUST NOT both
  | implement multicast and configure relay = agents to listen on
  | All_DHCP_Servers, as such a configuration = would result in the
  | servers receiving multiple copies of client = messages.

Surely that happens with relay agents = anyway?   Any site with half a brain,
or more, configures multiple relay agents for = redundancy (assuming it also
has multiple routers for redundancy of = course).   If the protocol can't
handle multiple copies of messages being delivered = to the servers, it badly
needs fixing (but I actually doubt it has that = defect).

kre

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C3101A.65602620-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 22:14:27 2003 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 WAA22097; Thu, 1 May 2003 22:14:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h422KY829797; Thu, 1 May 2003 22:20:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h422HM829678 for ; Thu, 1 May 2003 22:17:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21969 for ; Thu, 1 May 2003 22:10:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BQ2H-0001H7-00 for dhcwg@ietf.org; Thu, 01 May 2003 22:12:29 -0400 Received: from fep03-mail.bloor.is.net.cable.rogers.com ([66.185.86.73]) by ietf-mx with esmtp (Exim 4.12) id 19BQ2B-0001Gv-00 for dhcwg@ietf.org; Thu, 01 May 2003 22:12:23 -0400 Received: from arthur ([65.50.135.44]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030502021240.OXDJ6654.fep03-mail.bloor.is.net.cable.rogers.com@arthur> for ; Thu, 1 May 2003 22:12:40 -0400 Message-ID: <001901c31050$50c5e340$2c873241@arthur> From: "Artybuck" To: Date: Thu, 1 May 2003 22:12:42 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0015_01C3102E.C9326910" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [65.50.135.44] using ID at Thu, 1 May 2003 22:12:29 -0400 Subject: [dhcwg] Remove 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_0015_01C3102E.C9326910 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0016_01C3102E.C9326910" ------=_NextPart_001_0016_01C3102E.C9326910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0016_01C3102E.C9326910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_001_0016_01C3102E.C9326910-- ------=_NextPart_000_0015_01C3102E.C9326910 Content-Type: text/x-vcard; name="Jump On The Buck Wagon.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Jump On The Buck Wagon.vcf" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:;Jump On The Buck Wagon FN:Jump On The Buck Wagon EMAIL;PREF;INTERNET:artybuck@rogers.com REV:20030502T021242Z END:VCARD ------=_NextPart_000_0015_01C3102E.C9326910-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 1 22:45:51 2003 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 WAA22743; Thu, 1 May 2003 22:45:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h422pv831888; Thu, 1 May 2003 22:51:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h422nA831784 for ; Thu, 1 May 2003 22:49:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22655 for ; Thu, 1 May 2003 22:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BQX2-0001RX-00 for dhcwg@ietf.org; Thu, 01 May 2003 22:44:16 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19BQWw-0001Qr-00 for dhcwg@ietf.org; Thu, 01 May 2003 22:44:10 -0400 Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h41G3pnZ026949; Thu, 1 May 2003 11:03:51 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h41G3pOV011279; Thu, 1 May 2003 11:03:51 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 1 May 2003 11:03:51 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Address selection for Information-request/Reply messa ges Date: Thu, 1 May 2003 11:01:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30FFA.F8BB7502" 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_01C30FFA.F8BB7502 Content-Type: text/plain; charset="ISO-8859-1" Personally, I would prefer we leave this as it is. I think there is too great a danger for problems with allowing this because of the risk of misconfiguration. Also, if you allow this for Information-Request, why not allow it also in cases where a client has obtained some addresses from stateless and is using stateful for others. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, May 01, 2003 9:52 AM To: dhcwg@ietf.org Subject: [dhcwg] Address selection for Information-request/Reply messages At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >1. address selection of Information-request/Reply exchanges > >According to the DHCPv6 base spec, the client should send Information >Request messages to the All_DHCP_Relay_Agents_and_Servers multicast >address (FF02::1:2). However, doesn't it make much sense to allow the >client to send the requests to the All_DHCP_Servers multicast address >FF05::1:3? Since the stateless usage assumes the client has obtained >its IPv6 addresses through some other mechanism, I don't see a reason >that the client cannot do so. If we allow this, the client can access >an off-link server without relying on a relay agent, which would help >the deployment. On the other hand, we don't want to require deployment of multicast to enable stateless DHCPv6. One possibility would be to allow the use of All_DHCP_Servers, with an explicit warning that a site that doesn't implement multicast MUST use relay agents AND the relay agents must listen to All_DHCP_Servers (which is a change from the current spec). In fact, it would be important to note that a site MUST NOT both implement multicast and configure relay agents to listen on All_DHCP_Servers, as such a configuration would result in the servers receiving multiple copies of client messages. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C30FFA.F8BB7502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Address selection for Information-request/Reply = messages

Personally, I would prefer we leave this as it is. I = think there is too great
a danger for problems with allowing this because of = the risk of misconfiguration.
Also, if you allow this for Information-Request, why = not allow it also in cases
where a client has obtained some addresses from = stateless and is using stateful
for others.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, May 01, 2003 9:52 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Address selection for = Information-request/Reply
messages


At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / = =3D?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=3D?=3D wrote:

>1. address selection of Information-request/Reply = exchanges
>
>According to the DHCPv6 base spec, the client = should send Information
>Request messages to the = All_DHCP_Relay_Agents_and_Servers multicast
>address (FF02::1:2).  However, doesn't it = make much sense to allow the
>client to send the requests to the = All_DHCP_Servers multicast address
>FF05::1:3?  Since the stateless usage = assumes the client has obtained
>its IPv6 addresses through some other mechanism, = I don't see a reason
>that the client cannot do so.  If we allow = this, the client can access
>an off-link server without relying on a relay = agent, which would help
>the deployment.

On the other hand, we don't want to require = deployment of multicast
to enable stateless DHCPv6.

One possibility would be to allow the use of = All_DHCP_Servers, with
an explicit warning that a site that doesn't = implement multicast
MUST use relay agents AND the relay agents must = listen to
All_DHCP_Servers (which is a change from the current = spec).  In
fact, it would be important to note that a site MUST = NOT both
implement multicast and configure relay agents to = listen on
All_DHCP_Servers, as such a configuration would = result in the
servers receiving multiple copies of client = messages.

- Ralph



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C30FFA.F8BB7502-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 2 11:16:13 2003 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 LAA17558; Fri, 2 May 2003 11:16:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42FMY830132; Fri, 2 May 2003 11:22:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42FIQ829919 for ; Fri, 2 May 2003 11:18:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17497 for ; Fri, 2 May 2003 11:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BcDs-0004t0-00 for dhcwg@ietf.org; Fri, 02 May 2003 11:13:16 -0400 Received: from igor.alcpress.com ([208.151.249.202]) by ietf-mx with esmtp (Exim 4.12) id 19BcDn-0004sd-00 for dhcwg@ietf.org; Fri, 02 May 2003 11:13:11 -0400 Received: from db.panug.org (db.panug.org [208.151.249.203]) by igor.alcpress.com (Postfix) with ESMTP id A0A5F1B18E2 for ; Fri, 2 May 2003 08:11:43 -0700 (PDT) From: Ed Sawicki To: dhcwg@ietf.org Content-Type: text/plain Organization: ALC Message-Id: <1051888376.1161.63.camel@red> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 May 2003 08:12:56 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Option 33 - static routes 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: , Content-Transfer-Encoding: 7bit I'm wondering whether I understand DHCP option 33 correctly. If I configure ISC's DHCP server so that network 192.168.0.0 is to have a static route of 192.168.0.1, for example, a DHCP client then has this network in it's routing table: 192.168.0.0 255.255.255.255 instead of this: 192.168.0.0 255.255.255.0 Is this proper operation? -- Ed Sawicki ALC _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 2 18:39:43 2003 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 SAA05966; Fri, 2 May 2003 18:39:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42MkK802902; Fri, 2 May 2003 18:46:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Mft802667 for ; Fri, 2 May 2003 18:41:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05838 for ; Fri, 2 May 2003 18:33:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bj85-0000eR-00 for dhcwg@ietf.org; Fri, 02 May 2003 18:35:45 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19Bj7z-0000e2-00 for dhcwg@ietf.org; Fri, 02 May 2003 18:35:40 -0400 Date: Fri, 02 May 2003 15:36:40 -0700 From: Alper Yegin To: , pana Message-ID: In-Reply-To: <4.3.2.7.2.20030404054730.042dc4c0@funnel.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Bootstraping RFC3118 using PANA 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: , Content-Transfer-Encoding: 7bit Hello, [sorry about possible duplicates as this message is cross-posted on two mailing lists..] Assuming the major (or, one of the) problem of RFC3118 is lack of roaming and bootstraping support, we thought PANA could be useful here. http://ietf.org/html.charters/pana-charter.html One idea is to use PANA prior to DHCP to bootstrap a trust relation between the host and the network. Note that PANA can be used even when the host does not have an IP address. Client and network can use any authentication method to authenticate each other. Assuming they use one that generates keying material, this would result in a newly generated trust relation (i.e., PANA SA) between the host and an access network entity (PANA authentication agent - PAA). This would be a by-product of "network access authentication." PANA SA can be used to derive a DHCP SA to be used with RFC3118. This can be accomplished by a mutually-agreed PRF. In its simplest form, DHCP server/agent/proxy can be co-located with PAA, hence keying material is internally made available to DHCP module. This way, RFC3118 can be used as is (unless there are some other problems with it..) Comments? Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 5 18:33:15 2003 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 SAA20028; Mon, 5 May 2003 18:33:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Mf9810208; Mon, 5 May 2003 18:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45MT6808618 for ; Mon, 5 May 2003 18:29:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18932 for ; Mon, 5 May 2003 18:20:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CoLf-0001Ni-00 for dhcwg@ietf.org; Mon, 05 May 2003 18:22:15 -0400 Received: from smtp013.mail.yahoo.com ([216.136.173.57]) by ietf-mx with smtp (Exim 4.12) id 19CoKq-0001NC-00 for dhcwg@ietf.org; Mon, 05 May 2003 18:21:24 -0400 Received: from adsl-64-169-89-159.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 May 2003 22:20:28 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-unused-optioncodes-02 Date: Mon, 5 May 2003 15:10:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20030430110023.03f6c840@funnel.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit I've reviewed the draft and concur with its proposals. --Barr Hibbs > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Wednesday, April 30, 2003 08:04 > To: dhcwg@ietf.org > Subject: [dhcwg] WG last call on draft-ietf-dhc-unused-optioncodes-02 > > > This message announces a WG last call on "Unused DHCP Option > Codes" . The last call > will conclude on Friday, May 16. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. > > Prior to the publication of RFC2489 (which was updated by RFC2939), > several option codes were assigned to proposed DHCP options that > were subsequently never used. This document lists those unused > option codes and will be used to confirm that these option codes > can be reused for other DHCP options in the future. This document > is being considered for publication as Informational, and is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optionco des-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 6 03:39:08 2003 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 DAA10727; Tue, 6 May 2003 03:39:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467lJ824060; Tue, 6 May 2003 03:47:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467b5822811 for ; Tue, 6 May 2003 03:37:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10471 for ; Tue, 6 May 2003 03:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cwtn-0003wl-00 for dhcwg@ietf.org; Tue, 06 May 2003 03:30:03 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19Cwth-0003wE-00 for dhcwg@ietf.org; Tue, 06 May 2003 03:29:57 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h467ThVI072535 for ; Tue, 6 May 2003 09:29:43 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E5D7FA2488 for ; Tue, 6 May 2003 09:22:20 +0200 (CEST) Message-ID: <3EB76468.8050205@ccrle.nec.de> Date: Tue, 06 May 2003 09:29:44 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Interop tests at IETF 57 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: , Content-Transfer-Encoding: 7bit Hi, somebody here interested in some interop tests of DHCPv6 at the upcoming IETF-75 in Vienna? We are interested in doing interoperability testing between different DHCPv6 clients and servers. Cheers Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 6 18:05:07 2003 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 SAA10892; Tue, 6 May 2003 18:05:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46MDa802222; Tue, 6 May 2003 18:13:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46MAY802119 for ; Tue, 6 May 2003 18:10:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10613 for ; Tue, 6 May 2003 18:01:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAX3-0002vE-00 for dhcwg@ietf.org; Tue, 06 May 2003 18:03:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19DAX2-0002v9-00 for dhcwg@ietf.org; Tue, 06 May 2003 18:03:28 -0400 Received: from jschnizl-w2k.cisco.com (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h46M3mmb028944; Tue, 6 May 2003 18:03:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20030506172239.02212aa0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 May 2003 18:03:44 -0400 To: Michael Richardson From: John Schnizlein Subject: Re: [dhcwg] DHCP over IKE Cc: dhcwg@ietf.org In-Reply-To: <200304281751.h3SHpqbn006061@marajade.sandelman.ottawa.on.c a> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 see nothing in these drafts to indicate that the proposal accommodates DHCP relay agents in any way. In particular, tunneling DHCP within IKE messages would seem to disable this. Since RFC 3456 does not seem to have the same problem, it seems better to me. John At 01:51 PM 4/28/2003, Michael Richardson wrote: >A number of documents are being proposed in the IPSEC WG. The IPSRA >WG produced a protocol that runs DHCP over an IPsec tunnel, RFC 3456. >Other vendors used a protocol called "Configuration Payload" > >There is a third option being discussed, called "DHCP-over-IKE". > >The documents are draft-ietf-ipsec-dhcp-over-ike-00, as well >as dhcp-over-ike-dhcpd-00.txt and dhcp-over-ike-radius-00.txt > >A discussion thread: >http://www.sandelman.ottawa.on.ca/ipsec/2003/04/msg00053.html _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 7 07:17:34 2003 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 HAA23873; Wed, 7 May 2003 07:17:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BQR805190; Wed, 7 May 2003 07:26:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BNS805041 for ; Wed, 7 May 2003 07:23:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23565; Wed, 7 May 2003 07:14:01 -0400 (EDT) Message-Id: <200305071114.HAA23565@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org, ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 May 2003 07:14:00 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-06.txt,.pdf 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 : The IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-06.txt,.pdf Pages : 13 Date : 2003-5-6 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-06.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-isnsoption-06.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-isnsoption-06.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: <2003-5-6153220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153220.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 8 16:58:59 2003 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 QAA10988; Thu, 8 May 2003 16:58:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48L6i818855; Thu, 8 May 2003 17:06:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48L1F818322 for ; Thu, 8 May 2003 17:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10587 for ; Thu, 8 May 2003 16:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DsO6-0006St-00 for dhcwg@ietf.org; Thu, 08 May 2003 16:53:10 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19DsO5-0006SL-00 for dhcwg@ietf.org; Thu, 08 May 2003 16:53:09 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48Kr7V25409; Thu, 8 May 2003 15:53:08 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 May 2003 15:53:08 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B38AD@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'juha.wiljakka@nokia.com'" , rdroms@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Stateless DHCPv6 service Date: Thu, 8 May 2003 15:53:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C315A3.D25A1A5E" 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_01C315A3.D25A1A5E Content-Type: text/plain; charset="iso-8859-1" Hi, A question: If a DHCPV6 client sends an Information-Request message containing, for example, the DNS resolver option, SIP server option, and NTP server option and the DHCPv6 server can only return 2 of the 3 configuration options (due to policy reasons, administrative reasons, etc.), does the DHCPv6 spec (and the stateless DHCPv6 spec) allow the DHCPv6 server to send a Reply message with 2 of the 3? Or does it have to send a Reply with the status code "UnspecFail"? If so, this means that the DHCPv6 client should send 3 separate Information-Request messages? Thanks. Regards, Pete -----Original Message----- From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] Sent: Monday, April 14, 2003 6:41 AM To: rdroms@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Stateless DHCPv6 service Hi, Ralph! This document looks good, I personally support starting wglc for it. By the way, are you going to mention other options than DNS and Time Configuration Options? I think this would also be useful: http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-01.txt Best Regards, -Juha W.- -----Original Message----- From: ext Ralph Droms [mailto:rdroms@cisco.com] Sent: 06 April, 2003 16:07 To: dhcwg@ietf.org Subject: [dhcwg] Stateless DHCPv6 service Now that the DHCPv6 base specification is at PS, and the DNS and time configuration option specs have passed WG last call, I have published "A Guide to Implementing Stateless DHCPv6 Service" as a dhc WG document, draft-ietf-dhc-dhcpv6-stateless-00.txt. This revision of the document has been reviewed by Pekka Savola and Christian Huitema, and includes changes based on their input. Based on the interest in this specification, I would like to progress it quickly. Unless there are objections, I will start a WG last call for the specification in a week or so. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C315A3.D25A1A5E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Stateless DHCPv6 service

Hi,

A question: If a DHCPV6 client sends an = Information-Request message containing, for example, the DNS resolver = option, SIP server option, and NTP server option and the DHCPv6 server = can only return 2 of the 3 configuration options (due to policy = reasons, administrative reasons, etc.), does the DHCPv6 spec (and the = stateless DHCPv6 spec) allow the DHCPv6 server to send a Reply message = with 2 of the 3? Or does it have to send a Reply with the status code = "UnspecFail"? If so, this means that the DHCPv6 client should = send 3 separate Information-Request messages? Thanks.

Regards,

Pete

-----Original Message-----
From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com]
Sent: Monday, April 14, 2003 6:41 AM
To: rdroms@cisco.com
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Stateless DHCPv6 service


Hi, Ralph!

This document looks good, I personally support = starting wglc for it.

By the way, are you going to mention other options = than DNS and Time Configuration Options? I think this would also be = useful:

http://www.ietf.org/internet-drafts/draft-ietf-sip-dhc= pv6-01.txt

Best Regards,
                  -Juha = W.-

-----Original Message-----
From: ext Ralph Droms [mailto:rdroms@cisco.com]
Sent: 06 April, 2003 16:07
To: dhcwg@ietf.org
Subject: [dhcwg] Stateless DHCPv6 service


Now that the DHCPv6 base specification is at PS, and = the DNS and time configuration option specs have passed WG last call, I = have published "A Guide to Implementing Stateless DHCPv6 = Service" as a dhc WG document, = draft-ietf-dhc-dhcpv6-stateless-00.txt.

This revision of the document has been reviewed by = Pekka Savola and Christian Huitema, and includes changes based on their = input.  Based on the interest in this specification, I would like = to progress it quickly.  Unless there are objections, I will start = a WG last call for the specification in a week or so.

- Ralph

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C315A3.D25A1A5E-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 11 22:46:48 2003 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 WAA17776; Sun, 11 May 2003 22:46:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C2BvB04335; Sun, 11 May 2003 22:11:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C28eB04256 for ; Sun, 11 May 2003 22:08:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17738 for ; Sun, 11 May 2003 22:42:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19F3J3-00049L-00 for dhcwg@ietf.org; Sun, 11 May 2003 22:44:49 -0400 Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com) by ietf-mx with esmtp (Exim 4.12) id 19F3J2-00049E-00 for dhcwg@ietf.org; Sun, 11 May 2003 22:44:48 -0400 Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by peacock.tci.com (8.12.9/8.12.9) with ESMTP id h4C2jDPa018111; Sun, 11 May 2003 20:45:13 -0600 (MDT) Received: from 147.191.90.10 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Sun, 11 May 2003 20:45:02 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Sun, 11 May 2003 20:43:04 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC0855141C@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "Ralph Droms" cc: dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-relay-agent-auth-00 Date: Sun, 11 May 2003 20:44:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12A1D5244750458-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Ralph, I generally support this document. But here are some specific comments on the current draft. - The Abstract should refer to IPsec per RFC 2401, not RFC 2041. Also, shouldn't RFC 2401 be included as a normative reference? - Section 5 explains the use of IPsec ESP. It would seems that a normative reference to RFC 2406, "IP Encapsulating Security Payload (ESP)", would be in order. That means that this draft's requirement that "Packet authentication MUST be applied" implies a requirement to support "HMAC with MD5" and "HMAC with SHA-1" per section 5 of RFC 2406. Is that intended? - Some updates may be needed in the "Authors' Addresses" section. ;^) - This might not be a critical flaw, but... only the HMAC-MD5 algorithm is defined for the Relay Agent Option Authentication Sub-option. I notice that in several other IETF contexts (IPsec AH, RFC 2402; IPsec ESP, RFC 2406; SNMPv3 USM, RFC 3414; TLS, RFC 2246), the HMAC-SHA1 keyed hash is also leveraged. The following text from RFC 2104 may help explain why: Note: To the date of writing of this document MD5 and SHA-1 are the most widely used cryptographic hash functions. MD5 has been recently shown to be vulnerable to collision search attacks [Dobb]. This attack and other currently known weaknesses of MD5 do not compromise the use of MD5 within HMAC as specified in this document (see [Dobb]); however, SHA-1 appears to be a cryptographically stronger function. To this date, MD5 can be considered for use in HMAC for applications where the superior performance of MD5 is critical. Note that RFC 2747, "RSVP Cryptographic Authentication", is a good counter-example in that it only defines HMAC-MD5 for the INTEGRITY object, but explains its rationale in section 1 if its RFC. Another counter-example is RFC 2845, "Secret Key Transaction Authentication for DNS (TSIG)" -- but also see . -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, April 30, 2003 12:03 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-relay-agent-auth-00 This message announces a WG last call on "The Authentication Suboption for the DHCP Relay Agent Option" . The last call will conclude on Friday, May 16. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. This specification defines two mechanisms for securing the messages exchanged between a relay agent and a server. The first mechanism defines a new authentication suboption for the Relay Agent Information Option that supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in a payload derived from the option used in DHCP Authentication (RFC 3118). The second mechanism uses IPsec (RFC 2041) to protect messages exchanged between relay agents and servers. This document is being considered for publication as Informational, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-auth-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 13 06:55:35 2003 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 GAA03382; Tue, 13 May 2003 06:55:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DAKxB07601; Tue, 13 May 2003 06:20:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DAHqB07476 for ; Tue, 13 May 2003 06:17:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03276 for ; Tue, 13 May 2003 06:51:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FXPL-0001ar-00 for dhcwg@ietf.org; Tue, 13 May 2003 06:53:19 -0400 Received: from proxy.force.de ([158.116.254.130]) by ietf-mx with esmtp (Exim 4.12) id 19FXPK-0001ao-00 for dhcwg@ietf.org; Tue, 13 May 2003 06:53:18 -0400 Received: from ex-deu-munich02.force.de (ex-deu-munich02.force.de [10.254.2.10]) by proxy.force.de (8.11.4/8.11.4) with ESMTP id h4DAsPw20000 for ; Tue, 13 May 2003 12:54:26 +0200 (MEST) Received: by ex-deu-munich02.force.de with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 12:55:05 +0200 Message-ID: <9CFB9DA5261CD611A29B00508B7890484A113B@ex-deu-munich02.force.de> From: "Kholodnyi, Andrei" To: "'dhcwg@ietf.org'" Cc: "Kholodnyi, Andrei" Date: Tue, 13 May 2003 12:55:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] What OID to use before it is officially assigned by IANA? 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 All, Are there any rules what OID to use in Internet-Draft MIBs before it is assigned by IANA? I've implemented dhcp server MIB that is defined in http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-08.txt and want to use it. In draft is written: DESCRIPTION "Initial Version, published as RFC xxxx." -- RFC Editor assigns xxxx and removes this comment ::= { mib-2 TBD } -- IANA will make official assignment What OID should I use?? Regards, Andrei. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 13 14:45:09 2003 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 OAA24047; Tue, 13 May 2003 14:45:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DIB3B17982; Tue, 13 May 2003 14:11:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DHtHB16271 for ; Tue, 13 May 2003 13:55:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23551 for ; Tue, 13 May 2003 14:28:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FeXq-0006bv-00 for dhcwg@ietf.org; Tue, 13 May 2003 14:30:34 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19FeXp-0006bm-00 for dhcwg@ietf.org; Tue, 13 May 2003 14:30:33 -0400 Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h4DIUlnS001272; Tue, 13 May 2003 13:30:47 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h4DIUl2V009103; Tue, 13 May 2003 13:30:47 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 13 May 2003 13:30:47 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Peter Barany'" , "'juha.wiljakka@nokia.com'" , rdroms@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Stateless DHCPv6 service Date: Tue, 13 May 2003 13:28:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3197D.7A94D90C" 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_01C3197D.7A94D90C Content-Type: text/plain; charset="iso-8859-1" It can send a single Reply with the 2 options. -----Original Message----- From: Peter Barany [mailto:pbarany@nortelnetworks.com] Sent: Thursday, May 08, 2003 4:53 PM To: 'juha.wiljakka@nokia.com'; rdroms@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Stateless DHCPv6 service Hi, A question: If a DHCPV6 client sends an Information-Request message containing, for example, the DNS resolver option, SIP server option, and NTP server option and the DHCPv6 server can only return 2 of the 3 configuration options (due to policy reasons, administrative reasons, etc.), does the DHCPv6 spec (and the stateless DHCPv6 spec) allow the DHCPv6 server to send a Reply message with 2 of the 3? Or does it have to send a Reply with the status code "UnspecFail"? If so, this means that the DHCPv6 client should send 3 separate Information-Request messages? Thanks. Regards, Pete -----Original Message----- From: juha.wiljakka@nokia.com [ mailto:juha.wiljakka@nokia.com ] Sent: Monday, April 14, 2003 6:41 AM To: rdroms@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Stateless DHCPv6 service Hi, Ralph! This document looks good, I personally support starting wglc for it. By the way, are you going to mention other options than DNS and Time Configuration Options? I think this would also be useful: http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-01.txt Best Regards, -Juha W.- -----Original Message----- From: ext Ralph Droms [ mailto:rdroms@cisco.com ] Sent: 06 April, 2003 16:07 To: dhcwg@ietf.org Subject: [dhcwg] Stateless DHCPv6 service Now that the DHCPv6 base specification is at PS, and the DNS and time configuration option specs have passed WG last call, I have published "A Guide to Implementing Stateless DHCPv6 Service" as a dhc WG document, draft-ietf-dhc-dhcpv6-stateless-00.txt. This revision of the document has been reviewed by Pekka Savola and Christian Huitema, and includes changes based on their input. Based on the interest in this specification, I would like to progress it quickly. Unless there are objections, I will start a WG last call for the specification in a week or so. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C3197D.7A94D90C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Stateless DHCPv6 service
It can=20 send a single Reply with the 2 options.
-----Original Message-----
From: Peter Barany=20 [mailto:pbarany@nortelnetworks.com]
Sent: Thursday, May 08, = 2003=20 4:53 PM
To: 'juha.wiljakka@nokia.com';=20 rdroms@cisco.com
Cc: dhcwg@ietf.org
Subject: RE: = [dhcwg]=20 Stateless DHCPv6 service

Hi,

A question: If a DHCPV6 client sends an = Information-Request=20 message containing, for example, the DNS resolver option, SIP server = option,=20 and NTP server option and the DHCPv6 server can only return 2 of the = 3=20 configuration options (due to policy reasons, administrative reasons, = etc.),=20 does the DHCPv6 spec (and the stateless DHCPv6 spec) allow the DHCPv6 = server=20 to send a Reply message with 2 of the 3? Or does it have to send a = Reply with=20 the status code "UnspecFail"? If so, this means that the DHCPv6 = client should=20 send 3 separate Information-Request messages? Thanks.

Regards,

Pete

-----Original Message-----
From:=20 juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com]=20
Sent: Monday, April 14, 2003 6:41 AM =
To: rdroms@cisco.com
Cc: = dhcwg@ietf.org=20
Subject: RE: [dhcwg] Stateless DHCPv6 = service


Hi, Ralph!

This document looks good, I personally support = starting wglc=20 for it.

By the way, are you going to mention other options = than DNS=20 and Time Configuration Options? I think this would also be = useful:

http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-01.txt=20

Best Regards,=20
                  -Juha = W.-=20

-----Original Message-----
From: ext=20 Ralph Droms [mailto:rdroms@cisco.com] =
Sent: 06 April, 2003 16:07
To:=20 dhcwg@ietf.org
Subject: [dhcwg] Stateless = DHCPv6=20 service


Now that the DHCPv6 base specification is at PS, = and the DNS=20 and time configuration option specs have passed WG last call, I have = published=20 "A Guide to Implementing Stateless DHCPv6 Service" as a dhc WG = document,=20 draft-ietf-dhc-dhcpv6-stateless-00.txt.

This revision of the document has been reviewed by = Pekka=20 Savola and Christian Huitema, and includes changes based on their = input. =20 Based on the interest in this specification, I would like to progress = it=20 quickly.  Unless there are objections, I will start a WG last = call for=20 the specification in a week or so.

- Ralph

_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.= org/mailman/listinfo/dhcwg=20
_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.= org/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C3197D.7A94D90C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 13 17:39:07 2003 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 RAA29983; Tue, 13 May 2003 17:39:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DL5FB31190; Tue, 13 May 2003 17:05:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DL0wB30802 for ; Tue, 13 May 2003 17:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29922 for ; Tue, 13 May 2003 17:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FhRT-00002o-00 for dhcwg@ietf.org; Tue, 13 May 2003 17:36:11 -0400 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 19FhRS-00002l-00 for dhcwg@ietf.org; Tue, 13 May 2003 17:36:11 -0400 Received: from adsl-64-169-89-159.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 May 2003 21:37:15 -0000 Reply-To: From: "Barr Hibbs" To: "Kholodnyi, Andrei" , Subject: RE: [dhcwg] What OID to use before it is officially assigned by IANA? Date: Tue, 13 May 2003 14:36:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <9CFB9DA5261CD611A29B00508B7890484A113B@ex-deu-munich02.force.de> Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit if you choose an OID prior to IANA assignment, you will have to change it later, possibly under awkward circumstances. If you can wait, you should, as the Working Group Last Call period just ended this past Friday, so progress towards becoming an RFC should be relatively quick now. --Barr Hibbs > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Kholodnyi, Andrei > Sent: Tuesday, May 13, 2003 03:55 > To: 'dhcwg@ietf.org' > Cc: Kholodnyi, Andrei > Subject: [dhcwg] What OID to use before it is officially assigned by > IANA? > > > Hi All, > > Are there any rules what OID to use in > Internet-Draft MIBs before it is assigned by IANA? > > I've implemented dhcp server MIB that is defined in > http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-08.txt > and want to use it. > > In draft is written: > DESCRIPTION "Initial Version, published as RFC xxxx." > -- RFC Editor assigns xxxx and removes this comment > ::= { mib-2 TBD } -- IANA will make official assignment > > What OID should I use?? > > Regards, > Andrei. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 01:57:00 2003 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 BAA10648; Wed, 14 May 2003 01:57:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5NBB00457; Wed, 14 May 2003 01:23:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E5KjB00373 for ; Wed, 14 May 2003 01:20:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10617 for ; Wed, 14 May 2003 01:53:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FpEy-0002ax-00 for dhcwg@ietf.org; Wed, 14 May 2003 01:55:48 -0400 Received: from web11705.mail.yahoo.com ([216.136.172.71]) by ietf-mx with smtp (Exim 4.12) id 19FpEx-0002au-00 for dhcwg@ietf.org; Wed, 14 May 2003 01:55:48 -0400 Message-ID: <20030514055654.86303.qmail@web11705.mail.yahoo.com> Received: from [194.138.39.53] by web11705.mail.yahoo.com via HTTP; Wed, 14 May 2003 07:56:54 CEST Date: Wed, 14 May 2003 07:56:54 +0200 (CEST) From: =?iso-8859-1?q?fabien=20passilly?= Subject: [dhcwg] un-subscribe To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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: , Content-Transfer-Encoding: 8bit Please remove my mail id from the list. Thanks in advance ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 11:19:00 2003 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 LAA21323; Wed, 14 May 2003 11:19:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EEjRB21618; Wed, 14 May 2003 10:45:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EEgGB21490 for ; Wed, 14 May 2003 10:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21215 for ; Wed, 14 May 2003 11:15:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fy0B-0006d1-00 for dhcwg@ietf.org; Wed, 14 May 2003 11:17:07 -0400 Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx with esmtp (Exim 4.12) id 19Fy0B-0006cR-00 for dhcwg@ietf.org; Wed, 14 May 2003 11:17:07 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EFHbX11635 for ; Wed, 14 May 2003 17:17:38 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 May 2003 17:17:35 +0200 Message-ID: <4D7E22E99594D5119C950002A52C62E005E41EF2@zctfc006.europe.nortel.com> From: "Philippe Ragon" To: "'dhcwg@ietf.org'" Date: Wed, 14 May 2003 17:17:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31A2B.F3F619F6" Subject: [dhcwg] Relationship between DHCP hardware type and SNMP interface type 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_01C31A2B.F3F619F6 Content-Type: text/plain Hi, I have just noticed that the list of values for DHCP hardware type and the one for ifType in SNMP Interface MIB are not at all synchronized. For example an Ethernet 10 Mbs CSMA-CD interface is designated by : - htype = 1 in DHCP messages - ifType = 6 in MIB-II Both set of values being under IANA control, such a situation is curious and prevents from using the following pseudo-code in a DHCP client to fill up a Discover message : // X is the identifier of the interface we want to configure IP-wise Get ifType for interface X htype = ifType Get ifPhysAddress for interface X hlen = strlen(ifPhysAddress) strncpy (chaddr, ifPhysAddress, hlen-1) I also have one additional question : ifType = 1 (= other) allows to specify an interface whose type is not in the defined list AND there is no htype value available to specify the same thing ifPhysAddress = Null string allows to specify an interface for which physical address is meaningless AND I am not sure that it is legal to set hlen to 0 (and chaddr to 0 ?) to specify the same thing This would be useful to handle an interface attached to a point to point link (at least logically) towards a relay agent. This would be the case for example of an interface mapped to a permanent ATM VCC. In such a case, the identification of the path that must be used to return responses from server is left to the relay (e.g. as described by RFC 3046) and thus the content of chaddr is not used, and more it is meaningless (no 'physical' address is actually assigned to the interface). Any comment / explanation will be welcome. Philippe Ragon ------_=_NextPart_001_01C31A2B.F3F619F6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Relationship between DHCP hardware type and SNMP interface = type

Hi,

I have just = noticed that the list of values = for DHCP hardware type and = the one for ifType in SNMP = Interface MIB are not at all synchronized. For = example an Ethernet 10 Mbs = CSMA-CD interface is designated by :

- htype =3D 1 in DHCP messages

- ifType =3D 6 in MIB-II

Both set of values being = under IANA control, such a = situation is curious = and prevents from = using the following = pseudo-code in a DHCP client to = fill up a Discover message :

// X is the identifier of = the interface we want to configure = IP-wise

Get ifType for interface X

htype =3D ifType

Get ifPhysAddress for interface X

hlen =3D = strlen(ifPhysAddress)

strncpy (chaddr, ifPhysAddress, hlen-1)

I also have one = additional question :

ifType =3D 1 (=3D other) allows to specify an interface whose type is not = in the defined list AND there is no htype value available to specify the same thing

ifPhysAddress =3D Null string = allows to specify an interface for = which physical address is meaningless AND I am not sure = that it is legal to set hlen to = 0 (and chaddr to 0 ?) = to specify the same thing

This would be = useful to handle an = interface attached to a = point to point link (at least logically) towards a relay = agent. This would be the = case for example of an interface mapped to = a permanent ATM VCC.  = In such a case, the = identification of the path = that = must be used to return responses = from server is left to the = relay (e.g. as described by RFC 3046) = and thus the content of = chaddr is not used, and more = it is meaningless (no 'physical' address is actually = assigned to the = interface).

Any comment / explanation = will be welcome.

Philippe Ragon

------_=_NextPart_001_01C31A2B.F3F619F6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 12:17:21 2003 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 MAA23336; Wed, 14 May 2003 12:17:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EFhdB26363; Wed, 14 May 2003 11:43:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EFJfB24547 for ; Wed, 14 May 2003 11:19:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22772 for ; Wed, 14 May 2003 11:52:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FyaN-0006zg-00 for dhcwg@ietf.org; Wed, 14 May 2003 11:54:31 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19FyaM-0006zE-00 for dhcwg@ietf.org; Wed, 14 May 2003 11:54:31 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EFsokc242972; Wed, 14 May 2003 11:54:50 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-249-28.mts.ibm.com [9.65.249.28]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EFsnBO033008; Wed, 14 May 2003 09:54:49 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EFsc808618; Wed, 14 May 2003 11:54:38 -0400 Message-Id: <200305141554.h4EFsc808618@cichlid.adsl.duke.edu> To: Ralph Droms , ot@cisco.com cc: dhcwg@ietf.org Date: Wed, 14 May 2003 11:54:38 -0400 From: Thomas Narten Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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: , I've completed my review AD review of this document prior to starting the IETF LC. I have one (possibly) substantative question, the rest are nits. In reading the document, there is some wording that suggests that a requesting router might ask for prefixes for each of its interfaces. E.g, if it has two internal interfaces, plus the link to the ISP, it might ask for two delegations, one for each internal interface. But this isn't what I would expect normal usage to be. Rather, I'd expect the requesting router to ask for a single delegation, based on the one interface it has to its ISP, and would itself decide how to further delegate to its internal interfaces. Is my assumption/understanding consistent with the intent of the document? If so, some of the wording below should probably be changed. I.e., it would be good for the document to focus on the normal case usage. E.g.: > Upon the receipt of a valid Reply message, for each IA_PD the > requesting router assigns a subnet from each of the delegated > prefixes to each of the links to which the associated interfaces are > attached, with the following exception: the requesting router MUST > NOT assign any delegated prefixes or subnets from the delegated > prefix(es) to the link through which it received the DHCP message > from the delegating router. do we need the above wording? I would expect that a CPE router with three interfaces will still only make one IA_PD request. Maybe this needs more discussion, i.e., as background. Nits: > for delegating long-lived prefix from a delegating router to a s/long-lived/a long-lived/ > This document describes new options for DHCP, which provide a > mechanism for the delegation of IPv6 prefixes. Through these s/which/that/ > This document describes an extension to the DHCPv6 specification [6]. I hope this option isn't "extending" the dhcpv6 spec. In general, options don't do that, they are just opaque blobs carried by DHC. Or is this one different? > IA_PD has an associated IAID. A requesting IAID used without definition/expansion. > If the delegating router cannot delegate any prefixes to an IA_PD in > the message from the requesting router, the delegating router MUST > include the IA_PD in the Advertise message with no prefixes in the > IA_PD and a Status Code option in the IA_PD containing status code > NoPrefixAvail. Is this error going to be useful enough in terms of figuring out why the request was denied? E.g, authorization failed? > If the delegating router will not assign any prefixes to any IA_PDs > in a subsequent Request from the requesting router, the delegating > router MUST send an Advertise message to the requesting router that > includes a Status Code option with code NoPrefixAvail and a status > message for the user, a Server Identifier option with the delegating > router's DUID and a Client Identifier option with the requesting > router's DUID. This seems like a more detailed repetition of an earlier paragraph: If the delegating router cannot delegate any prefixes to an IA_PD in the message from the requesting router, the delegating router MUST include the IA_PD in the Advertise message with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail. Are both really needed? > messages sent by the requesting router. The IA_PD option include all s/include/includes/ > When a requesting router subnets a delegated prefix, it must assign > additional bits to the prefix to generate unique, longer prefixes. > For example, if the requesting router in Figure 1 were delegated > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber > network. If the requesting router were delegated 3FFE:FFFF:0::/48 > and 3FFE:FFFF:1::/48, it might assign 3FFE:FFFF:0:1::/64 and > 3FFE:FFFF:1:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and > 3FFE:FFFF:1:2::/64 for assignment to the other link. Is this needed? I'm skeptical about the two (separate) delegations per above. Besides, wouldn't the ISP just delegate 3FF3:FFFF::/47? > If the requesting router assigns a delegated prefix to a link to > which the router is attached, and begins to send router > advertisements for the prefix on the link, the requesting router MUST > set the valid lifetime in those advertisements to be no later than > the valid lifetime specified in the IA_PD Prefix option. A > requesting router MAY use the preferred lifetime specified in the > IA_PD Prefix option. I wonder of more discussion about lifetimes would be appropriate. What happens if CPE router reboots and presents a different DUID? delegating router will reject that (in contrast to normal DHC). Will the right thing happen? > An intruder requesting router may be able to mount a denial of What is "intruder requesting router"? > Because a requesting router and delegating routers must each have at > least one assigned IPv6 address, the routers may be able to use IPsec > for authentication of DHCPv6 messages. The details of using IPsec > for DHCPv6 are under development. Where in the spec is this made a requirement? The mention in the security considerations is the first reference to this I recall seeing. Have someone familiar with Radius review section 5.1, especially the explicit radius example. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 14:10:50 2003 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 OAA29296; Wed, 14 May 2003 14:10:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EHbIB03357; Wed, 14 May 2003 13:37:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EHYTB02889 for ; Wed, 14 May 2003 13:34:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29246 for ; Wed, 14 May 2003 14:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G0gm-0000CI-00 for dhcwg@ietf.org; Wed, 14 May 2003 14:09:16 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19G0gl-0000CD-00 for dhcwg@ietf.org; Wed, 14 May 2003 14:09:15 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EI9lYp230832; Wed, 14 May 2003 14:09:48 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EI9kBO034234; Wed, 14 May 2003 12:09:47 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EI9Zb04477; Wed, 14 May 2003 14:09:36 -0400 Message-Id: <200305141809.h4EI9Zb04477@cichlid.adsl.duke.edu> To: vijayak@india.hp.com cc: dhcwg@ietf.org Date: Wed, 14 May 2003 14:09:35 -0400 From: Thomas Narten Subject: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-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: , substantive comments: Note, when I first reviewed this, I asked the IESG about some aspects of this, so some of my comments reflect concerns/questions that came out of that discussion. > The Timezone option is used by the server to convey client's timezone > information to the client. First, what are the actual semantics of this option? Are the semantics: - This is the timezone you are in at the time this message is sent? - this is the timezone the server is in at the time this message is sent? - or something else? What is the client expected to do with the option? > time-zone: Time zone of the client in the format as explained below. > > Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]] > > where '[' and ']' enclose optional fields, '|' indicates choice > of exactly one of the alternatives, ',' and '/' represent literal > characters present in the string. > > If "Offset" is specified, then the time-zone is represented in the > IEEE 1003.1 POSIX timezone format [3]. > > Std Three or more octets for the standard timezone (Std). > Any character (or case) except a leading colon, digits, > comma, minus or plus sign is allowed. If the time-zone > is not represented in IEEE 1003.1 POSIX timezone format [3], > then Std is treated as the index to the timezone database, > for example, a file name, from where additional information > about the timezone may be obtained. If offset is not specified, what format is the timezone in then? If POSIX format is not used, how can the client and server be sure that they agree on what the meaning of the string in the option? The above says it is just an index into some unspecified table. But in general, the client and server can't be assumed to be using the same table, unless that is specified in this document... So this sounds like an interoperability problem waiting to happen... Or asking differently, is there a particular reason for not just using the IEEE posix format exclusively? (Or, would it be better to have a separate posix format option to make clear which is in use?) Also, is DHCPv4 option 88 (IEEE 1003.1 POSIX Timezone ) documented in an RFC? I couldn't find the obvious one ... Is it used? nits: > 3. Terminology > > This document uses terminology specific to IPv6 and DHCPv6 as defined > in section "Terminology" of the DHCP specification. s/DHCP/DHCPv6/? and cite the RFC. > time-zone: Time zone of the client in the format as explained below. Is this a string? If so, what character set? security considerations probably needs to also say something about how bogus NTP servers can cause clients to set their times incorrectly, making them vulnerable to replay attacks in protocols that use timestamps to detect replays. > 8. IANA Considerations > > IANA is requested to assign an option code to these options from the > option-code space defined in section "DHCPv6 Options" of the DHCPv6 > specification [1]. More clear to say: IANA has assigned option code values out of the "DHCPv6 Options" name space for the following options: Option Name Value Described in OPTION_NTP_SERVERS tbd Section 4. OPTION_TIME_ZONE tbd Section 5. (Or something like that) Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 15:14:54 2003 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 PAA01901; Wed, 14 May 2003 15:14:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EIfHB08845; Wed, 14 May 2003 14:41:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EIc9B08659 for ; Wed, 14 May 2003 14:38:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01491 for ; Wed, 14 May 2003 15:11:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G1gN-0000WO-00 for dhcwg@ietf.org; Wed, 14 May 2003 15:12:55 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19G1gM-0000W9-00 for dhcwg@ietf.org; Wed, 14 May 2003 15:12:54 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4EJDV1M021168; Wed, 14 May 2003 15:13:31 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.65.206]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id PAA16638; Wed, 14 May 2003 15:13:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20030514150928.00bbe600@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 May 2003 15:13:30 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Cc: vijayak@india.hp.com, dhcwg@ietf.org In-Reply-To: <200305141809.h4EI9Zb04477@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 can answer the easy question ... option 88 was never documented in an RFC and is on the list of option codes to be marked by IANA for reassignment. See draft-ietf-dhc-unused-optioncodes-00 - Ralph At 02:09 PM 5/14/2003 -0400, Thomas Narten wrote: >[...] >Also, is DHCPv4 option 88 (IEEE 1003.1 POSIX Timezone ) documented in >an RFC? I couldn't find the obvious one ... Is it used? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 15:19:23 2003 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 PAA02122; Wed, 14 May 2003 15:19:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EIjpB09113; Wed, 14 May 2003 14:45:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EIh8B08934 for ; Wed, 14 May 2003 14:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02033 for ; Wed, 14 May 2003 15:15:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G1lC-0000Yx-00 for dhcwg@ietf.org; Wed, 14 May 2003 15:17:54 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19G1lB-0000Yc-00 for dhcwg@ietf.org; Wed, 14 May 2003 15:17:53 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EJICuT261218; Wed, 14 May 2003 15:18:12 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EJIBBO054510; Wed, 14 May 2003 13:18:11 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EJI0o07212; Wed, 14 May 2003 15:18:00 -0400 Message-Id: <200305141918.h4EJI0o07212@cichlid.adsl.duke.edu> To: Ralph Droms cc: dhcwg@ietf.org Date: Wed, 14 May 2003 15:18:00 -0400 From: Thomas Narten Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.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: , I don't really have any comments on this document. I've gone ahead and requested the IETF Last Call. The one comment I have is: > 4. Domain Search List option > > The Domain Search List option specifies the domain search list the > client is to use when resolving hostnames with DNS. This option does > not apply to other name resolution mechanisms. More could be said here about what the client is supposed to do. "searchlist" is assumed to be self evident. Is that the case? Maybe steal text from RFC 3397? Oops. It doesn't seem to have a much specific text on this either. For example, is the list in a particular order? (I would assume so.) Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 15:49:29 2003 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 PAA03184; Wed, 14 May 2003 15:49:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EJFvB11358; Wed, 14 May 2003 15:15:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EJD7B11278 for ; Wed, 14 May 2003 15:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03112 for ; Wed, 14 May 2003 15:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G2EC-0000mE-00 for dhcwg@ietf.org; Wed, 14 May 2003 15:47:52 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19G2EC-0000ls-00 for dhcwg@ietf.org; Wed, 14 May 2003 15:47:52 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EJmTkc249206; Wed, 14 May 2003 15:48:29 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EJmSBO012332; Wed, 14 May 2003 13:48:28 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EJmH007725; Wed, 14 May 2003 15:48:17 -0400 Message-Id: <200305141948.h4EJmH007725@cichlid.adsl.duke.edu> To: vijayak@india.hp.com cc: dhcwg@ietf.org Date: Wed, 14 May 2003 15:48:17 -0400 From: Thomas Narten Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-opt-nisconfig-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: , No big issues with this document, I went ahead and requested an IETF LC. Here are my review comments. NIS in abstract will likely need to be spelled out to satisfy rfc editor.. > This document uses terminology specific to IPv6 and DHCPv6 as defined > in section "Terminology" of the DHCP specification. would be good to cite the RFC... > The format of the Network Information Service Servers option is as > as shown below: s/as as/as/ > The Network Information Service Servers option provides a list of > one or more IP addresses of NIS servers available to the client. The > NIS servers SHOULD be listed in the order of preference. I think I understand the intent, but I think it would be more clear to write this something like: Clients MUST treat the list of servers as an ordered list. Servers (when they care) need to fill the fields in priority order (they are not required to). The above words don't really say the client MUST treat the option as an ordered list. Same wording issue appears in other places. > 8. Appearance of these option s/option/Options/ (also capitalize heading for consistency?) > 9. Security Considerations > > The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name > options may be used by an intruder DHCP server to assign invalid NIS > parameters, resulting in clients unable to use NIS. Is this really correct? it makes it sound like there is only a DOS issue. Can't this option be used to send someoneto use a spoofed server, in which case the server can provide bad responses that cause errors or security compromises, or? > 10. IANA Considerations > > IANA is requested to assign an option code to these options from the > option-code space defined in section "DHCPv6 Options" of the DHCPv6 > specification [1]. Would be good to list the options in this section together with TBDs and pointers to the sections. The way things are written now, IANA has to scan the document in more detail to figure out what it needs to do. > 12. Informative References > > [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. This references is generally considered normative. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 16:38:53 2003 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 QAA04563; Wed, 14 May 2003 16:38:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EK5QB14324; Wed, 14 May 2003 16:05:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EK2YB14194 for ; Wed, 14 May 2003 16:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04476 for ; Wed, 14 May 2003 16:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G302-00014z-00 for dhcwg@ietf.org; Wed, 14 May 2003 16:37:18 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 19G301-00014w-00 for dhcwg@ietf.org; Wed, 14 May 2003 16:37:17 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id E12F01C01728; Wed, 14 May 2003 16:38:23 -0400 (EDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28761)/8.9.3 SMKit7.02) with ESMTP id CAA13923; Thu, 15 May 2003 02:07:38 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Thomas Narten'" Cc: Subject: RE: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Date: Thu, 15 May 2003 02:07:23 +0530 Organization: HP ISO Message-ID: <000001c31a58$a030e8f0$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200305141809.h4EI9Zb04477@cichlid.adsl.duke.edu> Importance: Normal Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Hi Thomas Thanks for you comments. See my reply inline. Do get back to me, if you need any clarifications. ~Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Thomas Narten > Sent: Wednesday, May 14, 2003 11:40 PM > To: vijayak@india.hp.com > Cc: dhcwg@ietf.org > Subject: [dhcwg] AD comments on > draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt > > > substantive comments: Note, when I first reviewed this, I > asked the IESG about some aspects of this, so some of my > comments reflect concerns/questions that came out of that discussion. > > > The Timezone option is used by the server to convey > client's timezone > > information to the client. > > First, what are the actual semantics of this option? Are the > semantics: > > - This is the timezone you are in at the time this message is sent? > - this is the timezone the server is in at the time this message is > sent? > - or something else? What is the client expected to do with > the option? This is the timezone in which the client resides. The client is expected to set the timezone in its system. > > > > time-zone: Time zone of the client in the format as > explained below. > > > > Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]] > > > > where '[' and ']' enclose optional fields, '|' indicates choice > > of exactly one of the alternatives, ',' and '/' represent literal > > characters present in the string. > > > > If "Offset" is specified, then the time-zone is > represented in the > > IEEE 1003.1 POSIX timezone format [3]. > > > > Std Three or more octets for the standard timezone (Std). > > Any character (or case) except a leading > colon, digits, > > comma, minus or plus sign is allowed. If the > time-zone > > is not represented in IEEE 1003.1 POSIX > timezone format [3], > > then Std is treated as the index to the > timezone database, > > for example, a file name, from where > additional information > > about the timezone may be obtained. > > If offset is not specified, what format is the timezone in > then? If there is no offset followed by the Std, then the timezone is not represented in IEEE 1003.1 format. Its just a timezone string and the clients can interpret them in platform specific way. > If POSIX format is not used, how can the client and > server be sure that they agree on what the meaning of the > string in the option? The timezone option can be used along with the vendor/user class option to make sure that they agree upon the meaning of the string. For example, the clients running in different OS expect the string in different ways. Thus, vendor/user class option can be used to distinguish between the clients and proper string is returned by the clients. I think, I need to document it for better understanding. > The above says it is just an index into > some unspecified table. But in general, the client and server > can't be assumed to be using the same table, unless that is > specified in this document... So this sounds like an > interoperability problem waiting to happen... See the answer for prev question.... > > Or asking differently, is there a particular reason for not > just using the IEEE posix format exclusively? The main disadvantage POSIX format is its complexity. Some systems need a very simpler timezone and they can use their own mechanism to interpret and understand the underlying information. > (Or, would it > be better to have a separate posix format option to make > clear which is in use?) No, having two different option for providing the same information may lead to unnecessary complexity. What if both the options are sent to client? And they are conflicting? Which one the client has to use? > > Also, is DHCPv4 option 88 (IEEE 1003.1 POSIX Timezone ) > documented in an RFC? I couldn't find the obvious one ... Is it used? There was a draft on this for DHCPv4, but I think, its obsoleted. > > nits: > > > 3. Terminology > > > > This document uses terminology specific to IPv6 and > DHCPv6 as defined > > in section "Terminology" of the DHCP specification. > > s/DHCP/DHCPv6/? and cite the RFC. Yes, I will update. Do you have any idea about the RFC number of DHCPv6? > > > time-zone: Time zone of the client in the format as > explained below. > > Is this a string? If so, what character set? Its an NVT-ASCII string, I will document it. > > security considerations probably needs to also say something > about how bogus NTP servers can cause clients to set their > times incorrectly, making them vulnerable to replay attacks > in protocols that use timestamps to detect replays. I will update it. > > > 8. IANA Considerations > > > > IANA is requested to assign an option code to these > options from the > > option-code space defined in section "DHCPv6 Options" of > the DHCPv6 > > specification [1]. > > More clear to say: > > IANA has assigned option code values out of the "DHCPv6 > Options" name space for the following options: > > Option Name Value Described in > OPTION_NTP_SERVERS tbd Section 4. > OPTION_TIME_ZONE tbd Section 5. > > (Or something like that) Fine. I will update it. Thanks Vijay > > Thomas > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 16:52:14 2003 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 QAA04829; Wed, 14 May 2003 16:52:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EKIqB15578; Wed, 14 May 2003 16:18:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EKGxB15525 for ; Wed, 14 May 2003 16:16:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04800 for ; Wed, 14 May 2003 16:49:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G3Dz-0001AS-00 for dhcwg@ietf.org; Wed, 14 May 2003 16:51:43 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 19G3Dy-0001AP-00 for dhcwg@ietf.org; Wed, 14 May 2003 16:51:42 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id A608A1C01005; Wed, 14 May 2003 16:52:49 -0400 (EDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28761)/8.9.3 SMKit7.02) with ESMTP id CAA14679; Thu, 15 May 2003 02:22:01 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Thomas Narten'" Cc: Subject: RE: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt Date: Thu, 15 May 2003 02:21:47 +0530 Organization: HP ISO Message-ID: <000101c31a5a$a46afe40$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200305141948.h4EJmH007725@cichlid.adsl.duke.edu> Importance: Normal Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Thomas, I agree with all your comments and I will update it, But I am not sure of the case you have suggested in "Security Considerations", I couldn't imagine a scenario of security vulnerability, anyhow, I will update it with "May be" clause. Thanks for your comments Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Thomas Narten > Sent: Thursday, May 15, 2003 1:18 AM > To: vijayak@india.hp.com > Cc: dhcwg@ietf.org > Subject: [dhcwg] AD review of > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt > > > No big issues with this document, I went ahead and requested > an IETF LC. Here are my review comments. > > NIS in abstract will likely need to be spelled out to satisfy > rfc editor.. > > > This document uses terminology specific to IPv6 and > DHCPv6 as defined > > in section "Terminology" of the DHCP specification. > > would be good to cite the RFC... > > > The format of the Network Information Service Servers > option is as > > as shown below: > > s/as as/as/ > > > > The Network Information Service Servers option provides > a list of > > one or more IP addresses of NIS servers available to the > client. The > > NIS servers SHOULD be listed in the order of preference. > > I think I understand the intent, but I think it would be more > clear to write this something like: > > Clients MUST treat the list of servers as an ordered list. > Servers (when they care) need to fill the fields in priority > order (they are not required to). > > The above words don't really say the client MUST treat the > option as an ordered list. > > Same wording issue appears in other places. > > > 8. Appearance of these option > > s/option/Options/ (also capitalize heading for consistency?) > > > 9. Security Considerations > > > > The NIS servers, NIS+ servers, NIS domain name and NIS+ > domain name > > options may be used by an intruder DHCP server to assign > invalid NIS > > parameters, resulting in clients unable to use NIS. > > Is this really correct? it makes it sound like there is only > a DOS issue. Can't this option be used to send someoneto use > a spoofed server, in which case the server can provide bad > responses that cause errors or security compromises, or? > > > 10. IANA Considerations > > > > IANA is requested to assign an option code to these > options from the > > option-code space defined in section "DHCPv6 Options" of > the DHCPv6 > > specification [1]. > > Would be good to list the options in this section together > with TBDs and pointers to the sections. The way things are > written now, IANA has to scan the document in more detail to > figure out what it needs to do. > > > 12. Informative References > > > > [2] Bradner, S., "Key words for use in RFCs to Indicate > Requirement > > Levels", BCP 14, RFC 2119, March 1997. > > This references is generally considered normative. > > Thomas > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 17:13:03 2003 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 RAA05842; Wed, 14 May 2003 17:13:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EKdfB17418; Wed, 14 May 2003 16:39:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EKaoB16424 for ; Wed, 14 May 2003 16:36:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05719; Wed, 14 May 2003 17:09:38 -0400 (EDT) Message-Id: <200305142109.RAA05719@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 14 May 2003 17:09:38 -0400 Subject: [dhcwg] Last Call: DNS Configuration Options for 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 received a request from the Dynamic Host Configuration Working Group to consider DNS Configuration Options for DHCPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-28. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 17:15:17 2003 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 RAA05909; Wed, 14 May 2003 17:15:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EKfmB17584; Wed, 14 May 2003 16:41:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EKcEB17354 for ; Wed, 14 May 2003 16:38:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05751; Wed, 14 May 2003 17:11:03 -0400 (EDT) Message-Id: <200305142111.RAA05751@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 14 May 2003 17:11:02 -0400 Subject: [dhcwg] Last Call: NIS Configuration Options for 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 received a request from the Dynamic Host Configuration Working Group to consider NIS Configuration Options for DHCPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-28. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 14 23:55:32 2003 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 XAA14413; Wed, 14 May 2003 23:55:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F3MDB11873; Wed, 14 May 2003 23:22:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F0h5B01475 for ; Wed, 14 May 2003 20:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11960; Wed, 14 May 2003 21:15:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G7NP-0002qQ-00; Wed, 14 May 2003 21:17:43 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 19G7NP-0002qN-00; Wed, 14 May 2003 21:17:43 -0400 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19G7OR-0003lQ-00; Wed, 14 May 2003 18:18:47 -0700 Date: Wed, 14 May 2003 21:18:03 -0400 From: Keith Moore To: iesg@ietf.org Cc: moore@cs.utk.edu, iesg-secretary@ietf.org, dhcwg@ietf.org Message-Id: <20030514211803.0f865b7f.moore@cs.utk.edu> In-Reply-To: <200305142111.RAA05751@ietf.org> References: <200305142111.RAA05751@ietf.org> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Last Call: NIS Configuration Options for 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: , Content-Transfer-Encoding: 7bit I doubt that it's appropriate to bless this as standards-track. Informational would be okay. NIS is kind of a mess. it is neither secure nor robust. there are security problems related to using it to distribute password information, and it causes reliability problems for apps and hosts if not carefully set up and maintained. also, abliity to configure NIS seems fairly useless without also having the ability to configure which NIS services (maps) are used and which are ignored, and the relationship of NIS services to other ways of getting the same information. (e.g. the /etc/nsswitch.conf file or whatever it is on other systems) of course that facility is not specific to NIS, and so it doesn't belong in this document, but it seems like it would be an essential component of anything that was used to configure NIS. (or did I miss the DHCPv6 option that does this?) shouldn't there be at least informative references for NIS and NIS+? also unspecified: what's the interaction between this and the NIS binding discovery protocol? (forget what its called) has the use of that protocol over IPv6 ever been defined? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 15 01:59:42 2003 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 BAA16299; Thu, 15 May 2003 01:59:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F5QPB19748; Thu, 15 May 2003 01:26:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F5N8B19655 for ; Thu, 15 May 2003 01:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16264; Thu, 15 May 2003 01:55:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GBkK-00048Y-00; Thu, 15 May 2003 01:57:40 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19GBkJ-00048V-00; Thu, 15 May 2003 01:57:39 -0400 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 79B251B2092; Wed, 14 May 2003 23:57:27 -0500 (CDT) Date: Thu, 15 May 2003 00:58:47 -0500 Subject: Re: [dhcwg] Re: Last Call: NIS Configuration Options for DHCPv6 to Proposed Standard Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: iesg@ietf.org, iesg-secretary@ietf.org, dhcwg@ietf.org To: Keith Moore From: Ted Lemon In-Reply-To: <20030514211803.0f865b7f.moore@cs.utk.edu> Message-Id: <4B2D21D6-869A-11D7-9CE0-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit > I doubt that it's appropriate to bless this as standards-track. > Informational would be okay. To be clear, this draft is about how to represent NIS+ server information in a DHCPv6 packet, in cases where the application wants to represent this information in this packet. It doesn't recommend that anybody use NIS+. The nsswitch.conf issue should be handled in a separate draft, similar to RFC2937. I don't think this needs to be mentioned in this draft - RFC2937 is about how to choose between different name service classes, not about any one name service class. There is no RFC documenting an NIS binding protocol that I've been able to find - do you have a reference for that? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 15 11:23:26 2003 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 LAA12136; Thu, 15 May 2003 11:23:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEoOB07484; Thu, 15 May 2003 10:50:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FElCB07325 for ; Thu, 15 May 2003 10:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12028 for ; Thu, 15 May 2003 11:19:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GKY0-000053-00 for dhcwg@ietf.org; Thu, 15 May 2003 11:21:32 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19GKXz-00004y-00 for dhcwg@ietf.org; Thu, 15 May 2003 11:21:31 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4FFM9P9006972 for ; Thu, 15 May 2003 11:22:09 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.65.206]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA01126 for ; Thu, 15 May 2003 11:22:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20030515112113.00bb6e58@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 11:21:49 -0400 To: dhcwg@ietf.org From: Thomas Narten (by way of Ralph Droms ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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: , (Thomas, Bernard and I agreed to move this discussion to the dhc WG mailing list...RD) Hi Bernard. Could I convince you to have a look at this document (it's about ready for IETF last call), and in particular section 5.1 on radius? A more detailed review can come later, but I'd welcome a quick sanity check on the radius example (included below for ease of reference). Thanks! Thomas 5.1 Example network architecture Figure 1 illustrates a network architecture in which prefix delegation could be used. +--------+ \ | AAA | \ | server | \ +---+----+ | ___|__________________ | / \ | | ISP core network | | \__________ ___________/ | | | ISP +-------+-------+ | network | Aggregation | | | device | | | (delegating | | | router) | | +-------+-------+ | | / |DSL to subscriber / |premises / | +------+------+ \ | CPE | \ | (requesting | \ | router) | | +----+---+----+ | | | | Subscriber ---+-------------+-----+- -+-----+-------------+--- | network | | | | | +----+-----+ +-----+----+ +----+-----+ +-----+----+ | |Subscriber| |Subscriber| |Subscriber| |Subscriber| / | PC | | PC | | PC | | PC | / +----------+ +----------+ +----------+ +----------+ / Figure 1: An example of prefix delegation. In this example an AAA server is configured with a prefix assigned to the customer at the time of subscription to the ISP service. The prefix delegation process begins when the requesting router requests configuration information through DHCP. The DHCP messages from the requesting router are received by the delegating router in the aggregation device. When the delegating router receives the request, it consults the AAA server to authenticate and authorise the requesting router. The AAA server returns the subscriber's prefix(es) in a Framed-IPv6-Prefix attribute as described in RFC 3162 [7], and the delegating router returns them to the requesting router. The requesting router subnets the delegated prefix and assigns the longer prefixes to links in the subscriber's network. In a typical scenario based on the network shown in Figure 1, the requesting router subnets a single delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each of the links in the subscriber network. The prefix delegation options can be used in conjunction with other DHCP options carrying other configuration information to the requesting router. The requesting router may, in turn, then provide DHCP service to hosts attached to the internal network. For example, the requesting router may obtain the addresses of DNS and NTP servers from the ISP delegating router, and then pass that configuration information on to the subscriber hosts through a DHCP server in the requesting router. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 15 11:25:58 2003 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 LAA12244; Thu, 15 May 2003 11:25:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEr1B07689; Thu, 15 May 2003 10:53:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEnvB07446 for ; Thu, 15 May 2003 10:49:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12105 for ; Thu, 15 May 2003 11:22:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GKaf-00006S-00 for dhcwg@ietf.org; Thu, 15 May 2003 11:24:17 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19GKae-000060-00 for dhcwg@ietf.org; Thu, 15 May 2003 11:24:17 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4FFOskc277786; Thu, 15 May 2003 11:24:54 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4FFOelg155098; Thu, 15 May 2003 09:24:40 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h4FFMm15024620; Thu, 15 May 2003 11:22:48 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h4FFMmtP024616; Thu, 15 May 2003 11:22:48 -0400 Message-Id: <200305151522.h4FFMmtP024616@rotala.raleigh.ibm.com> To: vijayak@india.hp.com cc: dhcwg@ietf.org Subject: Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt In-Reply-To: Message from vijayak@india.hp.com of "Thu, 15 May 2003 02:21:47 +0530." <000101c31a5a$a46afe40$38e62a0f@nt23056> Date: Thu, 15 May 2003 11:22:48 -0400 From: Thomas Narten 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 Vijay. > I agree with all your comments and I will update it, But I am not sure > of the case you have suggested in "Security Considerations", I couldn't > imagine a scenario of security vulnerability, anyhow, I will update it > with "May be" clause. I actually don't know if there is vulnerability. But I would expect there might be. So I'm asking for someone more knowledgable than I about NIS to asssure me that there is no vulnerabilty. As I was reading the document, I found the statement: > The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name > options may be used by an intruder DHCP server to assign invalid NIS > parameters, resulting in clients unable to use NIS. hard to believe on the surface. Is the only damage that can occur a DOS attack? I would have assume that NIS provides a service, that if spoofed, can cause the wrong thing to happen (as in incorrect results), not just DOS (which is what I inerpret "unable to use NIS" to mean). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 15 11:28:58 2003 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 LAA12350; Thu, 15 May 2003 11:28:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEttB07858; Thu, 15 May 2003 10:55:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FElDB07329 for ; Thu, 15 May 2003 10:47:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12030 for ; Thu, 15 May 2003 11:19:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GKY0-000056-00 for dhcwg@ietf.org; Thu, 15 May 2003 11:21:32 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19GKXz-00004z-00 for dhcwg@ietf.org; Thu, 15 May 2003 11:21:31 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4FFM9P9006975 for ; Thu, 15 May 2003 11:22:09 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.65.206]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA01129 for ; Thu, 15 May 2003 11:22:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20030515112201.03def008@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 11:22:08 -0400 To: dhcwg@ietf.org From: Bernard Aboba (by way of Ralph Droms ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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: , > In this example an AAA server is configured with a prefix assigned to > the customer at the time of subscription to the ISP service. The Who is the "customer" in this case? Is it the subscribing PC? The requesting router? > prefix delegation process begins when the requesting router requests > configuration information through DHCP. The DHCP messages from the > requesting router are received by the delegating router in the > aggregation device. When the delegating router receives the request, > it consults the AAA server to authenticate and authorise the > requesting router. Are we saying that a DHCP request triggers a link authentication exchange? Typically it's the other way around because links are not enabled until link authentication completes, so it is not possible to have a DHCP exchange over a link that is not yet enabled. Also, I am not sure what "consults" means here. Is the delegating router just forwarding packets? Or is it acting as an authenticator of some kind with the requesting router acting as the authenticating peer? > The AAA server returns the subscriber's > prefix(es) in a Framed-IPv6-Prefix attribute as described in RFC 3162 > [7], and the delegating router returns them to the requesting router. How does the delegating router return them? Via DHCP? Via forwarding the AAA response to the requesting router? If the later, then we're assuming that the individual PCs authenticate to the delegating router? > The requesting router subnets the delegated prefix and assigns the > longer prefixes to links in the subscriber's network. In a typical > scenario based on the network shown in Figure 1, the requesting > router subnets a single delegated /48 prefix into /64 prefixes and > assigns one /64 prefix to each of the links in the subscriber > network. > > The prefix delegation options can be used in conjunction with other > DHCP options carrying other configuration information to the > requesting router. The requesting router may, in turn, then provide > DHCP service to hosts attached to the internal network. For example, > the requesting router may obtain the addresses of DNS and NTP servers > from the ISP delegating router, and then pass that configuration > information on to the subscriber hosts through a DHCP server in the > requesting router. Overall, it seems reasonable to me for the requesting router to do link authentication with an upstream device (which may or may not be a router; it could be a bridge). The AAA server can return IPv6 prefixes to the authenticator, who could plumb them. Note that depending on the authentication protocol, there may not be a way for the requesting router to know that the prefixes have been assigned. For example, IEEE 802.1X does not support any IP-layer configuration (unlike PPP IPv6CP). So the Requesting router (or PCs which attack to it) may need a DHCP exchange as well. That occurs *after* link authentication, and needs to return answers consistent with the AAA prefix assignment. This can be accomplished, for example, by having the device that received the AAA prefix assignment act as a DHCP server, subnetting the delegated prefix. In this case, I'm not clear that the requesting router is acting as an authenticator, rather than as a peer. Or is it the one that is sending the AAA requests and getting AAA responses with IPv6 prefix info? If so, then it could do the delegation -- but I'm sure what the delegating router does. I guess I'm confused, huh? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 15 11:40:56 2003 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 LAA12612; Thu, 15 May 2003 11:40:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FF7rB09304; Thu, 15 May 2003 11:07:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEq6B07633 for ; Thu, 15 May 2003 10:52:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12185; Thu, 15 May 2003 11:24:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GKcl-00007W-00; Thu, 15 May 2003 11:26:27 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19GKck-00007K-00; Thu, 15 May 2003 11:26:26 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4FFR3P9008360; Thu, 15 May 2003 11:27:04 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.65.206]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA01564; Thu, 15 May 2003 11:27:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20030515112526.03def108@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 11:27:03 -0400 To: iesg@ietf.org From: Ralph Droms Cc: IETF-Announce:;, dhcwg@ietf.org In-Reply-To: <200305142109.RAA05719@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: Last Call: DNS Configuration Options for 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: , Based on a conversation with Rob Austein, the "DNS Resolvers" option will be renamed "DNS Recursive Name Servers"; from RFC1034 (page 27): All resolvers and recursive name servers are required to at least be able to ignore the SOA RR when it is present in a response. - Ralph At 05:09 PM 5/14/2003 -0400, The IESG wrote: >The IESG has received a request from the Dynamic Host Configuration >Working Group to consider DNS Configuration Options for DHCPv6 > as a Proposed Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-28. > >Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 15 12:13:27 2003 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 MAA13949; Thu, 15 May 2003 12:13:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FFeAB12185; Thu, 15 May 2003 11:40:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FFblB12061 for ; Thu, 15 May 2003 11:37:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13872 for ; Thu, 15 May 2003 12:10:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GLKw-0000Sf-00 for dhcwg@ietf.org; Thu, 15 May 2003 12:12:06 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19GLKv-0000SX-00 for dhcwg@ietf.org; Thu, 15 May 2003 12:12:05 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4FGCd9s017009; Thu, 15 May 2003 09:12:39 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA13102; Thu, 15 May 2003 17:12:38 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Bernard Aboba (by way of Ralph Droms ) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt References: <4.3.2.7.2.20030515112201.03def008@funnel.cisco.com> From: Ole Troan Date: Thu, 15 May 2003 17:12:38 +0100 In-Reply-To: <4.3.2.7.2.20030515112201.03def008@funnel.cisco.com> (Bernard Aboba's message of "Thu, 15 May 2003 11:22:08 -0400") Message-ID: <7t5addo42a1.fsf@mrwint.cisco.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: , Bernhard, >> In this example an AAA server is configured with a prefix assigned to >> the customer at the time of subscription to the ISP service. The > > Who is the "customer" in this case? Is it the subscribing PC? The > requesting router? "customer" is the whole site behind the RR. >> prefix delegation process begins when the requesting router requests >> configuration information through DHCP. The DHCP messages from the >> requesting router are received by the delegating router in the >> aggregation device. When the delegating router receives the request, >> it consults the AAA server to authenticate and authorise the >> requesting router. > > Are we saying that a DHCP request triggers a link authentication exchange? no. > Typically it's the other way around because links are not enabled > until link authentication completes, so it is not possible to have a DHCP > exchange over a link that is not yet enabled. correct. > Also, I am not sure what "consults" means here. Is the delegating router > just forwarding packets? Or is it acting as an authenticator of some kind > with the requesting router acting as the authenticating peer? yes. >> The AAA server returns the subscriber's >> prefix(es) in a Framed-IPv6-Prefix attribute as described in RFC 3162 >> [7], and the delegating router returns them to the requesting router. > > How does the delegating router return them? Via DHCP? Via forwarding the > AAA response to the requesting router? If the later, then we're assuming > that the individual PCs authenticate to the delegating router? DHCP PD. AAA (or whatever protocol) is used in the back end. devices behind the RR is not involved in DHCP PD at all. >> The requesting router subnets the delegated prefix and assigns the >> longer prefixes to links in the subscriber's network. In a typical >> scenario based on the network shown in Figure 1, the requesting >> router subnets a single delegated /48 prefix into /64 prefixes and >> assigns one /64 prefix to each of the links in the subscriber >> network. >> >> The prefix delegation options can be used in conjunction with other >> DHCP options carrying other configuration information to the >> requesting router. The requesting router may, in turn, then provide >> DHCP service to hosts attached to the internal network. For example, >> the requesting router may obtain the addresses of DNS and NTP servers >> from the ISP delegating router, and then pass that configuration >> information on to the subscriber hosts through a DHCP server in the >> requesting router. > > Overall, it seems reasonable to me for the requesting router to do link > authentication with an upstream device (which may or may not be a router; > it could be a bridge). The AAA server can return IPv6 prefixes to the > authenticator, who could plumb them. Note that depending on the > authentication protocol, there may not be a way for the requesting router > to know that the prefixes have been assigned. For example, IEEE 802.1X > does not support any IP-layer configuration (unlike PPP IPv6CP). > > So the Requesting router (or PCs which attack to it) may need a DHCP > exchange as well. That occurs *after* link authentication, and > needs to return answers consistent with the AAA prefix assignment. This > can be accomplished, for example, by having the device that received the > AAA prefix assignment act as a DHCP server, subnetting the delegated > prefix. > > In this case, I'm not clear that the requesting router is acting as an > authenticator, rather than as a peer. Or is it the one that is sending the > AAA requests and getting AAA responses with IPv6 prefix info? If so, then > it could do the delegation -- but I'm sure what the delegating router > does. > > I guess I'm confused, huh? obviously. :-) the model for PD where AAA is involved is as follows: the link between RR and DR uses link authentication. AAA is used between the DR and the ISPs provisioning system. DHCP PD _can_ reuse the authorisation data acquired during the link authentication phase to provide DHCP prefix delegation. PD is run between the DR and RR. no device behind the RR is involved. the RR is not involved in AAA, the only way it can receive any prefixes is through DHCP PD. the link authentication protocol used does not matter as such (as long as the DR is involved in it) as we do not depend on any network layer parameters being negotiated. cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 15 13:51:31 2003 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 NAA16570; Thu, 15 May 2003 13:51:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FHIUB19866; Thu, 15 May 2003 13:18:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FGQaB15645 for ; Thu, 15 May 2003 12:26:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15111 for ; Thu, 15 May 2003 12:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GM6A-0000mP-00 for dhcwg@ietf.org; Thu, 15 May 2003 13:00:54 -0400 Received: from [64.38.134.99] (helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19GM69-0000mM-00 for dhcwg@ietf.org; Thu, 15 May 2003 13:00:54 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FGebP12910; Thu, 15 May 2003 09:40:37 -0700 Date: Thu, 15 May 2003 09:40:37 -0700 (PDT) From: Bernard Aboba To: Ole Troan cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt In-Reply-To: <7t5addo42a1.fsf@mrwint.cisco.com> Message-ID: References: <4.3.2.7.2.20030515112201.03def008@funnel.cisco.com> <7t5addo42a1.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 model for PD where AAA is involved is as follows: > > the link between RR and DR uses link authentication. AAA is used > between the DR and the ISPs provisioning system. OK. Having a diagram showing that would be helpful. > DHCP PD _can_ reuse the authorisation data acquired during the link > authentication phase to provide DHCP prefix delegation. Only the DR has the AAA authorization data since it is the one that receives the AAA response, not the RR. > PD is run between > the DR and RR. no device behind the RR is involved. OK. I assume that the DR responds based on the AAA assigned prefix (say /48)? The RR obtains this prefix from the DR, then subnets it for use with its "customers", right? > the RR is not involved in AAA, the only way it can receive any > prefixes is through DHCP PD. Right. > the link authentication protocol used does not matter as such (as long > as the DR is involved in it) as we do not depend on any network layer > parameters being negotiated. Great. This makes sense -- but I think you need some diagrams showing what protocols are spoken between what parties to make all this clear. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 16 13:51:25 2003 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 NAA04939; Fri, 16 May 2003 13:51:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GHImB29764; Fri, 16 May 2003 13:18:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GHFLB29638 for ; Fri, 16 May 2003 13:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04832 for ; Fri, 16 May 2003 13:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GjKO-0001jc-00 for dhcwg@ietf.org; Fri, 16 May 2003 13:49:08 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19GjKN-0001jT-00 for dhcwg@ietf.org; Fri, 16 May 2003 13:49:07 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4GHnmYp282698; Fri, 16 May 2003 13:49:48 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-225-22.mts.ibm.com [9.65.225.22]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4GHnlVc050758; Fri, 16 May 2003 11:49:48 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4GHnYZ03993; Fri, 16 May 2003 13:49:35 -0400 Message-Id: <200305161749.h4GHnYZ03993@cichlid.adsl.duke.edu> To: vijayak@india.hp.com cc: dhcwg@ietf.org Subject: Re: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt In-Reply-To: Message from vijayak@india.hp.com of "Thu, 15 May 2003 02:07:23 +0530." <000001c31a58$a030e8f0$38e62a0f@nt23056> Date: Fri, 16 May 2003 13:49:34 -0400 From: Thomas Narten 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 Vijay. > This is the timezone in which the client resides. The client is expected > to set the timezone in its system. OK. > > If offset is not specified, what format is the timezone in > > then? > If there is no offset followed by the Std, then the timezone is not > represented in IEEE 1003.1 format. Its just a timezone string and the > clients can interpret them in platform specific way. This will lead to interoperability problems, it seems to me. > > If POSIX format is not used, how can the client and > > server be sure that they agree on what the meaning of the > > string in the option? > The timezone option can be used along with the vendor/user class option > to make sure that they agree upon the meaning of the string. For > example, the clients running in different OS expect the string in > different ways. Thus, vendor/user class option can be used to > distinguish between the clients and proper string is returned by the > clients. I think, I need to document it for better understanding. This seems like a bad way to go. I.e., a standard DHC option that requires use of a vendor specific option at the same time in order to be used properly. Wouldn't it be better to just have a vendor-specific option that defines the timezone? > > > > Or asking differently, is there a particular reason for not > > just using the IEEE posix format exclusively? > The main disadvantage POSIX format is its complexity. Some systems need > a very simpler timezone and they can use their own mechanism to > interpret and understand the underlying information. I'd like to hear from others about this. It seems like if there is a standard format, we should use it. If we're going to define a simpler alternate, we need to be sure we define it sufficiently to get a reasonable amount of interoperability. I don't think we get that as currently defined. (I'm also leary of trying to define a simpler format, as from what I understand of timezone info, there's nothing simple about it if you want to do it correctly.) > No, having two different option for providing the same information may > lead to unnecessary complexity. What if both the options are sent to > client? And they are conflicting? Which one the client has to use? Well, what if the server sends non-POSIX format and the client doens't understand it? It might be clear what is supposed to happen, but the option isn't useful now. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 16 20:41:20 2003 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 UAA15563; Fri, 16 May 2003 20:41:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4H08pB25152; Fri, 16 May 2003 20:08:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4H05mB24232 for ; Fri, 16 May 2003 20:05:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15489 for ; Fri, 16 May 2003 20:37:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GpjS-0003mx-00 for dhcwg@ietf.org; Fri, 16 May 2003 20:39:26 -0400 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 19GpjR-0003mu-00 for dhcwg@ietf.org; Fri, 16 May 2003 20:39:25 -0400 Received: from adsl-64-169-89-159.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 May 2003 00:40:35 -0000 Reply-To: From: "Barr Hibbs" To: "Philippe Ragon" Cc: "Dhcwg" Subject: RE: [dhcwg] Relationship between DHCP hardware type and SNMP interface type Date: Fri, 16 May 2003 17:31:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C31BD0.EF6B73D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4D7E22E99594D5119C950002A52C62E005E41EF2@zctfc006.europe.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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_0006_01C31BD0.EF6B73D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Relationship between DHCP hardware type and SNMP interface typethat's because the "Interface Type (ifType)" and "Hardware Type (htype)" fields are really NOT the same thing. It's unfortunate that we have such differences sprinkled throughout the Internet protocols, but we do. Also, I'd be *very* wary of relying on the results of an "strlen()" function call to obtain or work with addresses in general, simply because they are NOT guaranteed to be null-terminated (breaking an assumption of "strlen()") and because some vendors stuff invalid strings into the 'haddr' and 'hlen' fields intentionally even when specifying 'htype' = 6. We had a long discussion thread about hlen=0, htype=0, and haddr=0 some time ago, but I've forgotten many of the details of that discussion including what was the objective, why it was being proposed for use, how to properly interpret the meanings, when it should be used, and where its use was appropriate. --Barr -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Philippe Ragon Sent: Wednesday, May 14, 2003 08:18 To: 'dhcwg@ietf.org' Subject: [dhcwg] Relationship between DHCP hardware type and SNMP interface type Hi, I have just noticed that the list of values for DHCP hardware type and the one for ifType in SNMP Interface MIB are not at all synchronized. For example an Ethernet 10 Mbs CSMA-CD interface is designated by : - htype = 1 in DHCP messages - ifType = 6 in MIB-II Both set of values being under IANA control, such a situation is curious and prevents from using the following pseudo-code in a DHCP client to fill up a Discover message : // X is the identifier of the interface we want to configure IP-wise Get ifType for interface X htype = ifType Get ifPhysAddress for interface X hlen = strlen(ifPhysAddress) strncpy (chaddr, ifPhysAddress, hlen-1) I also have one additional question : ifType = 1 (= other) allows to specify an interface whose type is not in the defined list AND there is no htype value available to specify the same thing ifPhysAddress = Null string allows to specify an interface for which physical address is meaningless AND I am not sure that it is legal to set hlen to 0 (and chaddr to 0 ?) to specify the same thing This would be useful to handle an interface attached to a point to point link (at least logically) towards a relay agent. This would be the case for example of an interface mapped to a permanent ATM VCC. In such a case, the identification of the path that must be used to return responses from server is left to the relay (e.g. as described by RFC 3046) and thus the content of chaddr is not used, and more it is meaningless (no 'physical' address is actually assigned to the interface). Any comment / explanation will be welcome. Philippe Ragon ------=_NextPart_000_0006_01C31BD0.EF6B73D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Relationship between DHCP hardware type and SNMP = interface type
that's=20 because the "Interface Type (ifType)"  and "Hardware Type (htype)" = fields=20 are really NOT the same thing.  It's unfortunate that we have such=20 differences sprinkled throughout the Internet protocols, but we = do.  Also,=20 I'd be *very* wary of relying on the results of an "strlen()" function = call to=20 obtain or work with addresses in general, simply because they are NOT = guaranteed=20 to be null-terminated (breaking an assumption of "strlen()") and because = some=20 vendors stuff invalid strings into the 'haddr' and 'hlen' fields = intentionally=20 even when specifying 'htype' =3D 6.
 
We had=20 a long discussion thread about hlen=3D0, htype=3D0, and haddr=3D0 some = time ago, but=20 I've forgotten many of the details of that discussion including what was = the=20 objective, why it was being proposed for use, how to properly interpret = the=20 meanings, when it should be used, and where its use was=20 appropriate.
 
--Barr
 
-----Original Message-----
From: = dhcwg-admin@ietf.org=20 [mailto:dhcwg-admin@ietf.org]On Behalf Of Philippe=20 Ragon
Sent: Wednesday, May 14, 2003 08:18
To:=20 'dhcwg@ietf.org'
Subject: [dhcwg] Relationship between DHCP = hardware=20 type and SNMP interface type

Hi,

I have just noticed = that the list of values for DHCP hardware = type and the one for ifType in SNMP Interface MIB are not at all synchronized. For example an Ethernet 10 Mbs CSMA-CD = interface is designated by :

- htype =3D 1=20 in DHCP messages

- ifType =3D 6 in MIB-II

Both set of values being = under IANA=20 control, such a = situation is curious and prevents from using=20 the following pseudo-code in a DHCP client to fill up=20 a Discover message :

// X is the identifier of = the interface=20 we want to configure = IP-wise

Get ifType=20 for interface X

htype =3D=20 ifType

Get ifPhysAddress for interface X

hlen =3D = strlen(ifPhysAddress)

strncpy (chaddr, ifPhysAddress,=20 hlen-1)

I also have one additional = question :

ifType =3D 1 (=3D other) allows to = specify an=20 interface whose type is not in the defined = list AND there is no htype value available to specify the same=20 thing

ifPhysAddress =3D Null=20 string allows to specify an = interface for which=20 physical address is meaningless AND I am not sure that it is=20 legal to set hlen to 0 (and chaddr to 0 ?) to=20 specify the same thing

This would be = useful to handle = an interface attached to a point to point link (at least logically) towards a relay = agent. This would be the case for = example=20 of an interface mapped to a permanent ATM VCC.  In such a = case, the = identification=20 of the path that must be used = to return responses from server is left to the relay (e.g. = as described by RFC = 3046) and = thus the content of chaddr = is=20 not used, and=20 more it is meaningless (no = 'physical' address is actually=20 assigned to the = interface).

Any comment / explanation = will be=20 welcome.

Philippe=20 Ragon

------=_NextPart_000_0006_01C31BD0.EF6B73D0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 19 02:53:41 2003 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 CAA09316; Mon, 19 May 2003 02:53:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J6MMB18826; Mon, 19 May 2003 02:22:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J6IFB18204 for ; Mon, 19 May 2003 02:18:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09085 for ; Mon, 19 May 2003 02:48:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HeTs-0000As-00 for dhcwg@ietf.org; Mon, 19 May 2003 02:50:44 -0400 Received: from [192.150.250.54] (helo=jade.coe.psu.ac.th) by ietf-mx with esmtp (Exim 4.12) id 19HeTr-0000Ap-00 for dhcwg@ietf.org; Mon, 19 May 2003 02:50:43 -0400 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4HCqoU27736; Sat, 17 May 2003 19:52:51 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: vijayak@india.hp.com, dhcwg@ietf.org Subject: Re: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt In-Reply-To: <200305161749.h4GHnYZ03993@cichlid.adsl.duke.edu> References: <200305161749.h4GHnYZ03993@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 May 2003 19:52:50 +0700 Message-ID: <27734.1053175970@munnari.OZ.AU> 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: , Date: Fri, 16 May 2003 13:49:34 -0400 From: Thomas Narten Message-ID: <200305161749.h4GHnYZ03993@cichlid.adsl.duke.edu> | This will lead to interoperability problems, it seems to me. Nonsense. | This seems like a bad way to go. I.e., a standard DHC option that | requires use of a vendor specific option at the same time in order | to be used properly. Wouldn't it be better to just have a | vendor-specific option that defines the timezone? No. DHCP servers send information tailored for a particular client. That's their role in life. How the server decides which particular client, and what particular information should be provided is up to the server. | I'd like to hear from others about this. It seems like if there is a | standard format, we should use it. POSIX format doesn't provide enough information, all it tells is the current timezone info, that is really, the UTC offset, and the dates when DST next turns on/off. There's no way from that to interpret historic dates correctly (nor would it be reasonable for a DHCP server to give out all the data that is needed for that to be done). Some systems and applications require more than the current local time, they also need to know what the local time was in the past. | Well, what if the server sends non-POSIX format and the client doens't | understand it? Then the server is mis-configured, just as if it sends any other information that the client doesn't want or cannot understand. If the client only wants posix format, and gets something which isn't that format, it ought to act just as if it didn't receive the option at all. If there's a problem with this draft, it is that there is no real way for the server to have any knowledge of the timezone where the client happens to be (a client could send a request to a particular DHCP server from anywhere on the planet, in theory). It isn't even that a particular IP address is able to tell the server the timezone - we don't map addresses into timezones, a network could easily span several (just consider a large ATM LAN). But all this means is that sometimes the server will have no information to give the client, it isn't a reason to hold up the draft. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 19 12:03:47 2003 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 MAA25384; Mon, 19 May 2003 12:03:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JFWTB27590; Mon, 19 May 2003 11:32:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JFR4B27344 for ; Mon, 19 May 2003 11:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25154 for ; Mon, 19 May 2003 11:57:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hn2Z-0004JJ-00 for dhcwg@ietf.org; Mon, 19 May 2003 11:59:07 -0400 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 19Hn2R-0004J5-00 for dhcwg@ietf.org; Mon, 19 May 2003 11:59:00 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id 3F6F71C019EA; Mon, 19 May 2003 08:59:25 -0700 (PDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28761)/8.9.3 SMKit7.02) with ESMTP id VAA27314; Mon, 19 May 2003 21:28:37 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Robert Elz'" , "'Thomas Narten'" Cc: Subject: RE: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Date: Mon, 19 May 2003 21:28:25 +0530 Organization: HP ISO Message-ID: <001901c31e1f$7b4a4430$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <27734.1053175970@munnari.OZ.AU> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Thomas, Unfortunately, there was a mailer problem here and I missed your mail, Could you please resend your mail to me. Moreover, I couldn't get the archived version of your mail in the www.dhcp.org. Admins, could you please take care of this? Robert, I totally agree with all your arguments. Adding to your point, vendor specific option is just a tool for giving different values of same options to the different clients. This is just a configuration issue, rather than protocol issue. Vijay > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Saturday, May 17, 2003 6:23 PM > To: Thomas Narten > Cc: vijayak@india.hp.com; dhcwg@ietf.org > Subject: Re: [dhcwg] AD comments on > draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt > > > Date: Fri, 16 May 2003 13:49:34 -0400 > From: Thomas Narten > Message-ID: <200305161749.h4GHnYZ03993@cichlid.adsl.duke.edu> > > | This will lead to interoperability problems, it seems to me. > > Nonsense. > > | This seems like a bad way to go. I.e., a standard DHC option that > | requires use of a vendor specific option at the same time in order > | to be used properly. Wouldn't it be better to just have a > | vendor-specific option that defines the timezone? > > > > No. > > DHCP servers send information tailored for a particular > client. That's > their role in life. How the server decides which particular > client, and > what particular information should be provided is up to the server. > > | I'd like to hear from others about this. It seems like if > there is a > | standard format, we should use it. > > POSIX format doesn't provide enough information, all it tells > is the current timezone info, that is really, the UTC offset, > and the dates > when DST next turns on/off. There's no way from that to interpret > historic dates correctly (nor would it be reasonable for a > DHCP server to give out all the data that is needed for that > to be done). > > Some systems and applications require more than the current > local time, they also need to know what the local time was in > the past. > > | Well, what if the server sends non-POSIX format and the > client doens't > | understand it? > > Then the server is mis-configured, just as if it sends any > other information that the client doesn't want or cannot > understand. If the client only wants posix format, and gets > something which isn't that format, it ought to act just as if > it didn't receive the option at all. > > If there's a problem with this draft, it is that there is no > real way for the server to have any knowledge of the timezone > where the client happens to be (a client could send a request > to a particular DHCP server > from anywhere on the planet, in theory). It isn't even that > a particular > IP address is able to tell the server the timezone - we don't > map addresses into timezones, a network could easily span > several (just consider a large ATM LAN). > > But all this means is that sometimes the server will have no > information to give the client, it isn't a reason to hold up > the draft. > > kre > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 19 15:49:28 2003 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 PAA03929; Mon, 19 May 2003 15:49:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JJIPB12241; Mon, 19 May 2003 15:18:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JJFhB12104 for ; Mon, 19 May 2003 15:15:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03536 for ; Mon, 19 May 2003 15:45:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hqbl-00068B-00 for dhcwg@ietf.org; Mon, 19 May 2003 15:47:41 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19Hqbf-00067Y-00 for dhcwg@ietf.org; Mon, 19 May 2003 15:47:36 -0400 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 190661B2003 for ; Mon, 19 May 2003 13:46:02 -0500 (CDT) Date: Mon, 19 May 2003 14:48:09 -0500 Subject: Re: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: dhcwg@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <27734.1053175970@munnari.OZ.AU> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit > Some systems and applications require more than the current local time, > they also need to know what the local time was in the past. Do we want to solve that problem, or is the POSIX solution sufficient to our needs? I would argue that there is no solution we're going to come up with here that will adequately address the problem you're describing, and I don't know of any operating system that provides the capability to address the problem in the way you suggest even if DHCP somehow were able to communicate that information to it. Certainly Unix and Linux don't. > | Well, what if the server sends non-POSIX format and the client > doens't > | understand it? > > Then the server is mis-configured, just as if it sends any other > information that the client doesn't want or cannot understand. The implication of this statement is that it's also okay to send arbitrary data in other options, even in contradiction of what the standard says the option should contain. Or, really, you're saying that standards shouldn't specify the format of option data. I don't think this is a good way to promote interoperability. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 19 20:26:19 2003 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 UAA11306; Mon, 19 May 2003 20:26:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JNtNB31465; Mon, 19 May 2003 19:55:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JNqlB31357 for ; Mon, 19 May 2003 19:52:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11268 for ; Mon, 19 May 2003 20:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Huw2-0007ng-00 for dhcwg@ietf.org; Mon, 19 May 2003 20:24:54 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19Huw2-0007nd-00 for dhcwg@ietf.org; Mon, 19 May 2003 20:24:54 -0400 Date: Mon, 19 May 2003 17:27:02 -0700 Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA From: Alper Yegin To: CC: , , , , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit >> Is there work currently in progress on such an alternative? (triggering a >> PANA transaction upon a DHCP message from the client or something similar). >> Would this be an appropriate forum to start a discussion? > > The simplest thing would be to have them operate independently > e.g. PANA authentication first then DHC address assignment etc. I agree. > That doesn't allow you to assign different addresses for different classes > of authenticated devices though. Actually, PANA session identifier can be used to link a DHCP client to Radius authorization results (e.g., IP address, etc.) received earlier. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 19 22:22:09 2003 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 WAA13305; Mon, 19 May 2003 22:22:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K1pFB06265; Mon, 19 May 2003 21:51:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K1mcB06173 for ; Mon, 19 May 2003 21:48:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13258 for ; Mon, 19 May 2003 22:18:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hwk7-0000Sm-00 for dhcwg@ietf.org; Mon, 19 May 2003 22:20:43 -0400 Received: from mailserv.ait.ac.th ([203.159.5.10]) by ietf-mx with esmtp (Exim 4.12) id 19Hwk5-0000Sd-00 for dhcwg@ietf.org; Mon, 19 May 2003 22:20:42 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailserv.ait.ac.th (Postfix) with ESMTP id 53C3132ECE; Tue, 20 May 2003 09:20:20 +0700 (ICT) Received: from mailserv.ait.ac.th ([127.0.0.1]) by localhost (mailserv.ait.ac.th [127.0.0.1:10024]) (amavisd-new) with ESMTP id 02669-01; Tue, 20 May 2003 09:20:20 +0700 (ICT) Received: from delta.cs.mu.OZ.AU (unknown [203.159.26.94]) by mailserv.ait.ac.th (Postfix) with ESMTP id 15BC932EE0; Tue, 20 May 2003 09:20:20 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4K2AIq24782; Tue, 20 May 2003 09:10:27 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 May 2003 09:10:18 +0700 Message-ID: <24780.1053396618@munnari.OZ.AU> X-Virus-Scanned: by amavisd-new 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: , Date: Mon, 19 May 2003 14:48:09 -0500 From: Ted Lemon Message-ID: | Do we want to solve that problem, or is the POSIX solution sufficient | to our needs? The draft already handles it, as much as need be handled. | and I don't know of any operating system that provides the | capability to address the problem in the way you suggest even if DHCP | somehow were able to communicate that information to it. Certainly | Unix and Linux don't. Certainly they do. You transmit America/New-York as the timezone string and Unix/Linux systems (well, many Unix, not all) will know that is a different timezone than America/Detroit - even though both would be described by an identical POSIX timestring to describe this year (or last year, or lots of other years.) Or Australia/Melbourne and Australia/Sydney just the same - this year they're identical but not always (and more recently than the NY/Detroit differences). | The implication of this statement is that it's also okay to send | arbitrary data in other options, even in contradiction of what the | standard says the option should contain. I have no idea how you read that into what I said. Thomas was complaining that sending data that the standard says the option can contain (the draft, for now), which might not be understood by the receiving host - and that that would cause interop proplems. Not so. This has nothing to do with sending data that the standard doesn't say should be there. Another example of this would be sending an address/netmask pair that aren't a natural "classful" value to a host that is so ancient that it doesn't understand classless addressing, and requires only class A/B/C addresses (identified by the first few bits of the address). Sending a classless address+mask to a classed address host would be a configuration error on the part of the DHCP server (the server's operator - the software obviously cannot know). But this doesn't mean that we outlaw sending classless address+mask just because some host might not understand it - which was the logical implication of Thomas' argument. | Or, really, you're saying that standards shouldn't specify the format | of option data. I don't think this is a good way to promote | interoperability. Not at all, which isn't what I said at all. The draft specifies what needs to be specified. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 20 05:50:09 2003 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 FAA04205; Tue, 20 May 2003 05:50:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K9JJB15972; Tue, 20 May 2003 05:19:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K9FNB15862 for ; Tue, 20 May 2003 05:15:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04084 for ; Tue, 20 May 2003 05:45:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19I3iJ-0002yt-00 for dhcwg@ietf.org; Tue, 20 May 2003 05:47:19 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19I3iI-0002yo-00 for dhcwg@ietf.org; Tue, 20 May 2003 05:47:18 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h4K9m6VI084322; Tue, 20 May 2003 11:48:06 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 808F4A623B; Tue, 20 May 2003 11:38:29 +0200 (CEST) Message-ID: <3EC9F979.0@ccrle.nec.de> Date: Tue, 20 May 2003 11:46:33 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Interop Event after IETF-57 in Vienna 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: , Content-Transfer-Encoding: 7bit Hi, I'm happy to announce the DHCPv6 Interop Event at the IETF-57 in Vienna. This DHCPv6 Interop is sponsored by NEC Network Laboratories Europe and will be held in Vienna right after the IETF-57 meeting from July 18th to July 19th. The location will be at the same place as the IETF or next to the IETF venue. Further information about the exact location, time, environment and tests will be available within the next week on this web page and will be announced separately: http://www.dhcpv6.org/ Regards Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 20 07:30:01 2003 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 HAA06481; Tue, 20 May 2003 07:30:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KAxEB22893; Tue, 20 May 2003 06:59:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KAuBB22790 for ; Tue, 20 May 2003 06:56:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06151; Tue, 20 May 2003 07:26:16 -0400 (EDT) Message-Id: <200305201126.HAA06151@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, 20 May 2003 07:26:16 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-extended-optioncodes-00.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 : Extending DHCP Options Codes Author(s) : B. Volz, R. Droms, T. Lemon Filename : draft-ietf-dhc-extended-optioncodes-00.txt Pages : 9 Date : 2003-5-19 RFC 2132 defines the DHCP for IPv4 options 1 to 127 as the DHCP public option space which is managed by IANA as documented in RFC 2939. As this public option space has few unassigned options at this time, it is prudent to define a mechanism to extend this option space before it is too late. This Internet-Draft proposes several means to extend this option space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-extended-optioncodes-00.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-extended-optioncodes-00.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-extended-optioncodes-00.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: <2003-5-19141709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-extended-optioncodes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-extended-optioncodes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19141709.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 20 18:43:12 2003 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 SAA04293; Tue, 20 May 2003 18:43:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KM9UB09818; Tue, 20 May 2003 18:09:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KM6fB08634 for ; Tue, 20 May 2003 18:06:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04115 for ; Tue, 20 May 2003 18:39:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IFkS-0001Pt-00 for dhcwg@ietf.org; Tue, 20 May 2003 18:38:20 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19IFkR-0001PN-00 for dhcwg@ietf.org; Tue, 20 May 2003 18:38:19 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4KMd8Jh011225; Tue, 20 May 2003 18:39:08 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([128.107.169.158]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id SAA04344; Tue, 20 May 2003 18:39:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20030520115234.0420e008@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 May 2003 18:39:04 -0400 To: Thomas Narten From: Ralph Droms Cc: ot@cisco.com, dhcwg@ietf.org In-Reply-To: <200305141554.h4EFsc808618@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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: , At 11:54 AM 5/14/2003 -0400, Thomas Narten wrote: > I've completed my review AD review of this document prior to starting > the IETF LC. I have one (possibly) substantative question, the rest > are nits. > > In reading the document, there is some wording that suggests that a > requesting router might ask for prefixes for each of its > interfaces. E.g, if it has two internal interfaces, plus the link to > the ISP, it might ask for two delegations, one for each internal > interface. But this isn't what I would expect normal usage to be. > Rather, I'd expect the requesting router to ask for a single > delegation, based on the one interface it has to its ISP, and would > itself decide how to further delegate to its internal interfaces. > > Is my assumption/understanding consistent with the intent of the > document? If so, some of the wording below should probably be > changed. I.e., it would be good for the document to focus on the > normal case usage. The expected use of the protocol is for the RR (requesting router) to request one delegation from the DR (delegating router). This sentence from the next-to-last paragraph in section 4 explains the expected use: In a typical scenario based on the network shown in Figure 1, the requesting router subnets a single delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each of the links in the subscriber network. Is this sentence (which comes before the following paragraph in the spec) sufficient? > E.g.: > >> Upon the receipt of a valid Reply message, for each IA_PD the >> requesting router assigns a subnet from each of the delegated >> prefixes to each of the links to which the associated interfaces are >> attached, with the following exception: the requesting router MUST >> NOT assign any delegated prefixes or subnets from the delegated >> prefix(es) to the link through which it received the DHCP message >> from the delegating router. > > do we need the above wording? I would expect that a CPE router with > three interfaces will still only make one IA_PD request. Maybe this > needs more discussion, i.e., as background. in the typical scenario, i.e ISP delegating prefixes to a customer only one IA_PD should be used. to allow for some flexibility e.g if DHCPv6 PD should be used within an administrative domain we allow for multiple IA_PDs. this is also consistent with the way IA_NA's work. > Nits: > >> for delegating long-lived prefix from a delegating router to a > > s/long-lived/a long-lived/ fixed. >> This document describes new options for DHCP, which provide a >> mechanism for the delegation of IPv6 prefixes. Through these > > s/which/that/ s/, which/that/ >> This document describes an extension to the DHCPv6 specification [6]. > > I hope this option isn't "extending" the dhcpv6 spec. In general, > options don't do that, they are just opaque blobs carried by DHC. Or > is this one different? changed to "This document describes new DHCPv6 options for IPv6 prefix delegation" >> IA_PD has an associated IAID. A requesting > > IAID used without definition/expansion. defined in the DHCPv6 specification. >> If the delegating router cannot delegate any prefixes to an IA_PD in >> the message from the requesting router, the delegating router MUST >> include the IA_PD in the Advertise message with no prefixes in the >> IA_PD and a Status Code option in the IA_PD containing status code >> NoPrefixAvail. > > Is this error going to be useful enough in terms of figuring out why > the request was denied? E.g, authorization failed? consistent with address assignment. any reason why we would need more error codes for PD and the same reasoning wouldn't apply to addresses? don't think so? >> If the delegating router will not assign any prefixes to any IA_PDs >> in a subsequent Request from the requesting router, the delegating >> router MUST send an Advertise message to the requesting router that >> includes a Status Code option with code NoPrefixAvail and a status >> message for the user, a Server Identifier option with the delegating >> router's DUID and a Client Identifier option with the requesting >> router's DUID. > > This seems like a more detailed repetition of an earlier paragraph: > > If the delegating router cannot delegate any prefixes to an IA_PD in > the message from the requesting router, the delegating router MUST > include the IA_PD in the Advertise message with no prefixes in the > IA_PD and a Status Code option in the IA_PD containing status code > NoPrefixAvail. > > Are both really needed? otherwise the requesting router cannot know which IA_PD failed. However, it does seem like the Status Code option in the first paragraph (which would not be contained in an IA_PD) is superfluous. We will combine the two paragraphs and eliminate the Status Code option from the first paragraph. >> messages sent by the requesting router. The IA_PD option include all > > s/include/includes/ fixed. >> When a requesting router subnets a delegated prefix, it must assign >> additional bits to the prefix to generate unique, longer prefixes. >> For example, if the requesting router in Figure 1 were delegated >> 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and >> 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber >> network. If the requesting router were delegated 3FFE:FFFF:0::/48 >> and 3FFE:FFFF:1::/48, it might assign 3FFE:FFFF:0:1::/64 and >> 3FFE:FFFF:1:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and >> 3FFE:FFFF:1:2::/64 for assignment to the other link. > > Is this needed? I'm skeptical about the two (separate) delegations per > above. Besides, wouldn't the ISP just delegate 3FF3:FFFF::/47? The intent here is to illustrate the delegation of two independent prefixes. The RR then assigns a /64 from each prefix to each interface. Just delegating a /47 would cause only one prefix to be assigned to each interface. In the following paragraph, I changed the example delegated prefixes so they do not both come from the same /47. Is this clearer? When a requesting router subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes. For example, if the requesting router in Figure 1 were delegated 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber network. If the requesting router were delegated 3FFE:FFFF:0::/48 and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 3FFE:FFFF:5:2::/64 for assignment to the other link. >> If the requesting router assigns a delegated prefix to a link to >> which the router is attached, and begins to send router >> advertisements for the prefix on the link, the requesting router MUST >> set the valid lifetime in those advertisements to be no later than >> the valid lifetime specified in the IA_PD Prefix option. A >> requesting router MAY use the preferred lifetime specified in the >> IA_PD Prefix option. > > I wonder of more discussion about lifetimes would be appropriate. Can you be more explicit? What part of the paragraph needs further explanation? > What happens if CPE router reboots and presents a different DUID? > delegating router will reject that (in contrast to normal DHC). Will > the right thing happen? a CPE must keep its DUID according to DHCPv6 spec. what happens if the DUID changes is dependent on delegating router policy. e.g a new prefix could be delegated. >> An intruder requesting router may be able to mount a denial of > > What is "intruder requesting router"? How about "malicious requesting router"? >> Because a requesting router and delegating routers must each have at >> least one assigned IPv6 address, the routers may be able to use IPsec >> for authentication of DHCPv6 messages. The details of using IPsec >> for DHCPv6 are under development. > > Where in the spec is this made a requirement? The mention in the > security considerations is the first reference to this I recall > seeing. The sentence you quoted is part of a paragraph in the "Security Considerations" section: To guard against attacks through prefix delegation, requesting routers and delegating routers SHOULD use DHCP authentication as described in section "Authentication of DHCP messages" in the DHCP specification [6]. For point to point links, where one trusts that there is no man in the middle, or one trusts layer two authentication, DHCP authentication or IPsec may not be necessary. Because a requesting router and delegating routers must each have at least one assigned IPv6 address, the routers may be able to use IPsec for authentication of DHCPv6 messages. The details of using IPsec for DHCPv6 are under development. We don't understand your question. Why would this security consideration be mentioned in an earlier section of the draft? What is the "this" in "...the first reference to this..." referring to? > > Have someone familiar with Radius review section 5.1, especially the > explicit radius example. Use of AAA (RADIUS) is not key to the definition of this option. We will rewrite the example to use a more generic description of the assignment of prefixes to a customer for delegation by the DR. - Ole and Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 23 11:58:10 2003 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 LAA10416; Fri, 23 May 2003 11:58:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NFvGB22965; Fri, 23 May 2003 11:57:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCoqB05450 for ; Thu, 22 May 2003 08:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12892 for ; Thu, 22 May 2003 09:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Iq0s-0001S8-00 for dhcwg@ietf.org; Thu, 22 May 2003 09:21:43 -0400 Received: from goldfisch.at ([62.99.149.138]) by ietf-mx with esmtp (Exim 4.12) id 19Iq0s-0001Ry-00 for dhcwg@ietf.org; Thu, 22 May 2003 09:21:42 -0400 Received: from goldfisch.at (localhost.localdomain [127.0.0.1]) by goldfisch.at (8.12.9/8.12.1) with ESMTP id h4MDNHwJ024300 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 22 May 2003 15:23:17 +0200 Received: (from httpd@localhost) by goldfisch.at (8.12.9/8.12.1/Submit) id h4MDNHUn024297 for dhcwg@ietf.org; Thu, 22 May 2003 15:23:17 +0200 X-Authentication-Warning: goldfisch.at: httpd set sender to pilsl@goldfisch.at using -f Received: from 62.99.146.117 ( [62.99.146.117]) as user peter@goldfisch.at by www.goldfisch.at with HTTP; Thu, 22 May 2003 15:23:17 +0200 Message-ID: <1053609797.3ecccf455f721@www.goldfisch.at> Date: Thu, 22 May 2003 15:23:17 +0200 From: peter pilsl To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 62.99.146.117 Content-Transfer-Encoding: 8bit Subject: [dhcwg] dhcp : expected behaviour of clients when server is down ? 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: , Content-Transfer-Encoding: 8bit I run a dhcp-server with loads of fixed adresses in the conf. The default-lease is 600 and the max-lease is 7200. dhcp works well, but there are two strange things happening: i) for none of the clients with a fixed adress there is an entry in dhcp.leases ii) if the server is down for maintainance the client will not remember its old adress, but simply dont have an ip-address any more (win2k-clients) Especially the second point is very irritating to me. Imho the client should remember its old adress but maybe this is a limitation in the protocol. Is there an easy possibility for a backup-dhcpd if the main-dhcpd is down ? If I need to take off the server for 10 minutes, all my clients do not have networkaccess for the same time ? thnx, peter -- IT-Consulting mag. peter pilsl tel:+43-699-1-3574035 fax:+43-699-4-3574035 pilsl@goldfisch.at http://www.goldfisch.at _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 23 14:10:21 2003 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 OAA18261; Fri, 23 May 2003 14:10:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NI9XB17164; Fri, 23 May 2003 14:09:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NI6tB16150 for ; Fri, 23 May 2003 14:06:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18010 for ; Fri, 23 May 2003 14:06:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGv2-0000hy-00 for dhcwg@ietf.org; Fri, 23 May 2003 14:05:28 -0400 Received: from imr1.ericy.com ([208.237.135.240]) by ietf-mx with esmtp (Exim 4.12) id 19JGv1-0000hv-00 for dhcwg@ietf.org; Fri, 23 May 2003 14:05:27 -0400 Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h4NI6pZd023023; Fri, 23 May 2003 13:06:51 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr6.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h4NI6prJ008173; Fri, 23 May 2003 13:06:51 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Fri, 23 May 2003 13:06:45 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'peter pilsl'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcp : expected behaviour of clients when server is d own ? Date: Fri, 23 May 2003 13:06:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32155.C2082E96" 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_01C32155.C2082E96 Content-Type: text/plain; charset="iso-8859-1" dhcp.leases doesn't need to have fixed addresses in it since they are fixed by the configuration file. You could look into running the failover protocol, but a much easier solution is to use a much longer lease time. 600 seconds isn't very long (10 minutes) and why do you use such a short lease? The two general reasons are: 1) few available addresses with fairly rapidly changing client populations (address reuse if clients don't release or otherwise "disconnect" is critical) 2) frequent changes to the configuration (such as subnet number or resources such as the DNS server). If neither of these holds, increase the default lease time. Note: Renewals start at 50% of the lease time. So, your current clients are renewing every 300 seconds (5 minutes). -----Original Message----- From: peter pilsl [mailto:pilsl@goldfisch.at] Sent: Thursday, May 22, 2003 9:23 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcp : expected behaviour of clients when server is down ? I run a dhcp-server with loads of fixed adresses in the conf. The default-lease is 600 and the max-lease is 7200. dhcp works well, but there are two strange things happening: i) for none of the clients with a fixed adress there is an entry in dhcp.leases ii) if the server is down for maintainance the client will not remember its old adress, but simply dont have an ip-address any more (win2k-clients) Especially the second point is very irritating to me. Imho the client should remember its old adress but maybe this is a limitation in the protocol. Is there an easy possibility for a backup-dhcpd if the main-dhcpd is down ? If I need to take off the server for 10 minutes, all my clients do not have networkaccess for the same time ? thnx, peter -- IT-Consulting mag. peter pilsl tel:+43-699-1-3574035 fax:+43-699-4-3574035 pilsl@goldfisch.at http://www.goldfisch.at _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C32155.C2082E96 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcp : expected behaviour of clients when server is = down ?

dhcp.leases doesn't need to have fixed addresses in = it since they are fixed by the
configuration file.

You could look into running the failover protocol, = but a much easier solution is to use
a much longer lease time. 600 seconds isn't very = long (10 minutes) and why do you use such
a short lease? The two general reasons are:

1) few available addresses with fairly rapidly = changing client populations (address reuse
if clients don't release or otherwise = "disconnect" is critical)

2) frequent changes to the configuration (such as = subnet number or resources such as the
DNS server).

If neither of these holds, increase the default lease = time.

Note: Renewals start at 50% of the lease time. So, = your current clients are renewing every
300 seconds (5 minutes).


-----Original Message-----
From: peter pilsl [mailto:pilsl@goldfisch.at]=
Sent: Thursday, May 22, 2003 9:23 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcp : expected behaviour of = clients when server is
down ?




I run a dhcp-server with loads of fixed adresses in = the conf. The default-lease
is 600 and the  max-lease is 7200.

dhcp works well, but there are two strange things = happening:

i) for none of the clients with a fixed adress there = is an entry in
dhcp.leases

ii) if the server is down for maintainance the client = will not remember its
old adress,  but simply dont have an ip-address = any more (win2k-clients)

Especially the second point is very irritating to me. = Imho the client
should remember its old adress but maybe this is a = limitation in the
protocol.

Is there an easy possibility for a backup-dhcpd if = the main-dhcpd is down ?
If I need to take off the server for 10 minutes, all = my clients do not have
networkaccess for the same time ?


thnx,
peter


--
IT-Consulting
mag. peter  pilsl
tel:+43-699-1-3574035
fax:+43-699-4-3574035
pilsl@goldfisch.at
http://www.goldfisch.at



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C32155.C2082E96-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 25 08:07:46 2003 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 IAA28596; Sun, 25 May 2003 08:07:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PC6sB29271; Sun, 25 May 2003 08:06:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFXd830158 for ; Mon, 14 Apr 2003 11:33:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09178 for ; Mon, 14 Apr 2003 11:25:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1955sF-0002wh-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 11:27:59 -0400 Received: from harris.cc.strath.ac.uk ([130.159.248.11] helo=mailrouter2.strath.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 1955sF-0002we-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 11:27:59 -0400 Received: from titan.stams.strath.ac.uk ([130.159.240.149]) by mailrouter2.strath.ac.uk with smtp (Exim 3.14 #1) id 1955sK-0007Lt-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 16:28:04 +0100 Received: (qmail 1383 invoked from network); 14 Apr 2003 16:28:03 +0100 Received: from mstera.stams.strath.ac.uk (130.159.240.237) by titan.stams.strath.ac.uk with SMTP; 14 Apr 2003 16:28:03 +0100 From: Sergei Zuyev Reply-To: sergei@stams.strath.ac.uk Organization: Strathclyde University To: dhcwg@ietf.org Date: Mon, 14 Apr 2003 16:30:11 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304141630.11588.sergei@stams.strath.ac.uk> Content-Transfer-Encoding: 7bit Subject: [dhcwg] domainname is not set 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: , Content-Transfer-Encoding: 7bit Hi, I am experiencing the following problem in Mandrake 9.1 implementation of dhcp (dhcp-client-3.0-2pl2.5mdk): The domainname command returns (none), everything else seems to work just fine. It's not the server problem as I didn't have that on my client machine before upgrading to 9.1 and also I observe this in two different LANs. Any idea how can I debug that? Thanks in advance! -- ================================================================= Dr. Sergei ZUYEV Statistics and Modelling Science dept., University of Strathclyde Livingston Tower, 26 Richmond str., Glasgow, G1 1XH, U.K. Tel.: +44 (0)141 548 3663 Fax: +44 (0)141 552 2079 E-mail: sergei@stams.strath.ac.uk http://www.stams.strath.ac.uk ================================================================= _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 25 08:09:34 2003 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 IAA28701; Sun, 25 May 2003 08:09:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PC95B30208; Sun, 25 May 2003 08:09:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O6tI815504 for ; Thu, 24 Apr 2003 02:55:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06674 for ; Thu, 24 Apr 2003 02:52:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198acv-0003VD-00 for dhcwg@ietf.org; Thu, 24 Apr 2003 02:54:37 -0400 Received: from sec-mail-out01.broadnet-mediascape.de ([62.206.1.26]) by ietf-mx with esmtp (Exim 4.12) id 198acu-0003VA-00 for dhcwg@ietf.org; Thu, 24 Apr 2003 02:54:36 -0400 Received: from Michel (pD9E75F97.dip.t-dialin.net [217.231.95.151]) by sec-mail-out01.broadnet-mediascape.de (Postfix) with ESMTP id 6AB5C10800 for ; Thu, 24 Apr 2003 08:54:58 +0200 (CEST) From: "Michel" To: Date: Thu, 24 Apr 2003 08:56:13 +0200 Message-ID: <000001c30a2e$99bb53f0$0273a8c0@Michel> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C30A3F.5D4423F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [dhcwg] DHCP Server is starting 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_0001_01C30A3F.5D4423F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C30A3F.5D473130" ------=_NextPart_001_0002_01C30A3F.5D473130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a problem with DHCP start/boot in a net without dhcp-server! =20 =20 DHCP client is connect on ETHERNET with no Servers Client is running under WINDOS (98)=20 =20 no answer(response) of DISCOVER or REQUEST is possible from any server in WIN98 the dhcp-client send only a request-msg with fix requested_IP field but no server can answer a DHCP_ACH or DHCP_NAK i.e. the client hold his old IP addr. (192.128.115.4) =20 =20 Now a DHCP-server is starting with other IP-room ( 192.168.1.xxx) =20 The clients never discover a new IP, if he have an old IP (Sometimes he send past 5 minutes a discover-msg) =20 How can the server initiated a DISCOVER or REQUEST from any connected clients. =20 Or is then only way for a new Discover the rebbot from any clients.=20 =20 Hope you understand my problem.=20 =20 Please help!=20 =20 =20 Best regards / mit freundlichen Gr=FC=DFen =20 =20 =20 =20 ------=_NextPart_001_0002_01C30A3F.5D473130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a problem with = DHCP start/boot in a net without dhcp-server! =A0

 

DHCP client is connect = on ETHERNET with no Servers

Client is running = under WINDOS (98)

 

no answer(response) of DISCOVER or REQUEST is possible from any = server

in WIN98 the = dhcp-client send only a request-msg with fix requested_IP = field

but no server can = answer a DHCP_ACH or DHCP_NAK

i.e. the client hold = his old IP addr. (192.128.115.4)

 

 

Now a DHCP-server is = starting with other IP-room ( 192.168.1.xxx)

 

The clients never = discover a new IP, if he have an old IP

(Sometimes he send = past 5 minutes a discover-msg)

 

How can the server = initiated a DISCOVER or REQUEST from any connected = clients.

 

Or is then only way = for a new Discover the rebbot from any clients.

 

Hope you understand my problem.

 

Please help! =

 

 

Best regards / mit freundlichen Gr=FC=DFen

 

 

 

 

------=_NextPart_001_0002_01C30A3F.5D473130-- ------=_NextPart_000_0001_01C30A3F.5D4423F0 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhGgGdAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAW AZkAggAAAAAAAAAA/4CAgP///wECAwECAwECAwP/CLrc8zDKSau9OOvNu/9gKG5NaZ5LRKxs675w LM90bd94ru98798RlNDxKxqPyKRyyeQNhsJHc0qtWq9Y3QNaGmS/4LB4nHtyFV6yes1uM83QtHtO r9tfcJT8zu/7wXldf4OEhUuBDHuGi4yNMluCjmoBAS+UlTKUbJo1lzuXmGqQiS2gnlOmp1eqK6ww nC6wr6FLrqyyM7g4umGjaJahvErCVbjELLzHVsa0OsqZzWIQpLG0mqAErj2ynrfXzzGq4tjZqaWV 3rqm1eTQwbDtrd3I6Nzx9G3Tv9Xn9JjgNJj9Gygv2q5u2srhA0awH7SFCnMhZOYwYrmG8KIBrKIP /4AiixY3XrwHMmS9ip/QZSspD2JFig8LGpy18uTLZu/wwXRJJshHkBlr4cxpz8c3myODAuOpbp2/ Z0dLKqXZMpWtmYCm/SzacthQndawdvrXdWqynChNzhIbsSFEY2+RxlzjkypQrCK7xi27M+DXtmb3 puU0jufSwWEFA0acTwLDdlYP27Ba7+hAuSzXWr588alnbJT9dU7Kdp3pyEk/nzInk+SXCZIMx57t B/bsvLRzS3PcyKnu33dsAx9OXBTv4siTXxGuvLlzJMyfS59e5jj169hjRBfN9tMNe5WPoD7oLK07 3JO753Ct91x4LdaRyc7yFf2rVvjL/1Cff2UuHv/8TSZfJuEMCJ8KltAEXljjDKUOPxkt+I4t7DDo X01EWVjKSP/1B1k8vs0jU1X93Qdhfu956ER8ni1EloEvbmjghSXW5J81JcZII404XqgUWjjFUqOJ N8q4I48e6kjQNQQuxSQ8TwXYwnYJqkiakFVGiaV8Kl05YotGejlTMDBuWVB6UJb52IwTEoZik529 2KWVR9pA5ZZk1jlkjmHumGd3BgU546Bq+mimjZ1kaWiHPTb6ZoEDyokkndUhyA+dOhopaJKH/klk kYP2aGaei/qJJaCKkqokpz5KqqeVkqZZaqUQ3JcOgxHmOiFgq0WV2q/Anqnll3FG1Wuvwq61pnv/ w55J2GYKlfbsSRNxh9udkGanLXDYMrTtt7l1C+64w4lL7rm0mYvuuo2oy+67hLgL77x8YGufb+tp JCUVC9JrnKWf6vdqh4ciIeWcovqbFcBCLrmnpnxxxyWO/Vala2uJzrqvwkfY22q0EnETqWBA8tne pAOfyibHvbDI5cgDqwpzljKjHOgt3zmVMMvLuZysq9nWPGahqz5c6C4r85zFnZ6CGnSkRZfaNKUm z0rwzkpTQeVECL2Kb7SX7VrtsW2WzU7ObWa9tM9qt90yw27HvXCtctc9txR2590z3Hr3nYS8fgcO BNuCF04r3oYnviLf7AV8skkfKvN1g+SISBJ4/6MpfiDdVQL6YJCkOp1yzaCShZboNX6j+eKc4ymg jI6aiLXrpiZN84aJ2ac404QGXHSg7qH6qO3EaozknKvjwDuKkwc/rTahSytr1bfzSXHKyePhc+hw FnxkwqUpinL1PIpsdPYwLM/f0OKPHz75OQoNMdXoz7B1Qo85eHafjSfL7P8YSpu1woO/+rkAcAYM HAIT2LcFMjBvDnxg3SIowbhRsIJtuyAGs3a/FF0qW/MpQsUKhqsIeS8cAlmfhtAkmuDFhmmYOSHB tpGg6KXKfMObHZFsGBCpvY5ofTIEDCFHpnQ4biOC4mHv8CK+fSkRUsDrIZx0OAjedalR3Iuief+6 57SdaZGE7ZtL8aD4wZBpJEwbc4MVRRe1PaWRNJWh3KaCmDrHSXF8+TvjHbH2NSFub2Zs9N4be6en OS7xhE4k3gwJOb/RSWJ5gQyJICWTsTDqcZJHw54PGUk77E3ti4zo4Ggq58EQgShANwub7+5RQhnu D0x+2RULMTbGUBKuOYO04wZZoMHY5DKMu1xBL4OpsGESk17GPCa8kqlMdjGzmejq4FTuMEI0CsR3 B9GVevQXSwpR0pZ82+QmaqhIcUYPLj+MpDsaCUJZ4u6Ff1TRCFUHy8yAsIv8u+eQLjlDUOrzfE1U 2SPj+TF1usl9qBQoHvX1zX2izZ/6FAk/Ubf/CBjiMGp/6uNYThM5dFqyfdsM4vr+GVHn/bInBJ2f qKYmQpIa8pBgrGTt0klHO7LPEZBUaSMztUWXHnGnhJpoO105Kk7S8abtctlV3hO5UZ4Sad7iUBOv 6byaLsuqVfXfHWnZwqSG8zknxeoGn2mIsBoVg2SF5rjSqtZvsbWt2norXLEj17lSR5q6A0M12UTV TmWzbCEF4Hk8ylVwto6dbjjjEzF1NG/KtI3KymSqugrQeP3RQUB6IxIV6sV/CjWwbqTpWfMpVsuG E2dqGuRmYadIhpYxqA/VJUgPNtW80uWyFUrMMszBmmAV8qdEpV5lH5ZQGZr1bYeFLV+/gFTS/340 plt9KRdHWycm4jSlrKIoeb7j2ckyFrr9DK7tRurd4QZHqU2hllucUdz9uYablA2WCh+0URNyN6tS ve5XnXNcTUqwrn3ob38FB2C7PqfABm4OghOcnAUzuDgO1o0AJvxgURYwqAOegQBqQGEcdHgFGwZx bj6cBBKzYYi6y3ARQuzhFrCYxTqAcYl5IGMk1PhfybUYLBOiQhpQOMQvNvGEN/xiApB4yDWGMZCV jGQjE1nETh6yj4nM5A8jucpW/jELmuxkI0NZBlIOsolfg1vIQtQuYKayl7fs4i0HGcpKdkGcn/zl Nf+YzjeOQYeB3OY615nPIAY0nNWc5zV32f/QiCbzaRHl2zP3ANBxZjMMihxlKfdZxHQOtJXh7OdK b5rTkk60pin95SuDutCRvnKhOUJQM8uWxqD+s54lvepU5xnSseYwrS+9ajv3OdW5lvOvG7PoHEq3 xz7OdaRLvWswX/rZuPZ1p4Wt7FALWtqHfrO0tV3qa6OUcb7qGrA0+toXhBnPXK60m6m8ZEt7mtmj bneXxcxhd6vbxVm297k1/W4tB1rOd473GCI84jE3odc8I7jS7G3BWz7YXwqnsaonTvGKW/ziGM+4 xjfO8Y57/OK72e/DIe7wkS+zLibnIMpTnvCVs5xjEvDIy1uulZnDPOYytzkycf4TnZNrAtRy8Pm6 gJ4CoQ+d6EU3+lopEAmlb4vpJui50xUM9RMgburOsUAcsE71Cpwhx1yHp9bP4JERmP3saE+72tfO 9rannewpcLvc5073utv97iGAuwPwzve++/3vgMeA3qMe+MIb/vCIF8Hg45D4xjv+8X8/QwIAADs= ------=_NextPart_000_0001_01C30A3F.5D4423F0 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhGgGdAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAW AZkAggAAAAAAAAAA/4CAgP///wECAwECAwECAwP/CLrc8zDKSau9OOvNu/9gKG5NaZ5LRKxs675w LM90bd94ru98798RlNDxKxqPyKRyyeQNhsJHc0qtWq9Y3QNaGmS/4LB4nHtyFV6yes1uM83QtHtO r9tfcJT8zu/7wXldf4OEhUuBDHuGi4yNMluCjmoBAS+UlTKUbJo1lzuXmGqQiS2gnlOmp1eqK6ww nC6wr6FLrqyyM7g4umGjaJahvErCVbjELLzHVsa0OsqZzWIQpLG0mqAErj2ynrfXzzGq4tjZqaWV 3rqm1eTQwbDtrd3I6Nzx9G3Tv9Xn9JjgNJj9Gygv2q5u2srhA0awH7SFCnMhZOYwYrmG8KIBrKIP /4AiixY3XrwHMmS9ip/QZSspD2JFig8LGpy18uTLZu/wwXRJJshHkBlr4cxpz8c3myODAuOpbp2/ Z0dLKqXZMpWtmYCm/SzacthQndawdvrXdWqynChNzhIbsSFEY2+RxlzjkypQrCK7xi27M+DXtmb3 puU0jufSwWEFA0acTwLDdlYP27Ba7+hAuSzXWr588alnbJT9dU7Kdp3pyEk/nzInk+SXCZIMx57t B/bsvLRzS3PcyKnu33dsAx9OXBTv4siTXxGuvLlzJMyfS59e5jj169hjRBfN9tMNe5WPoD7oLK07 3JO753Ct91x4LdaRyc7yFf2rVvjL/1Cff2UuHv/8TSZfJuEMCJ8KltAEXljjDKUOPxkt+I4t7DDo X01EWVjKSP/1B1k8vs0jU1X93Qdhfu956ER8ni1EloEvbmjghSXW5J81JcZII404XqgUWjjFUqOJ N8q4I48e6kjQNQQuxSQ8TwXYwnYJqkiakFVGiaV8Kl05YotGejlTMDBuWVB6UJb52IwTEoZik529 2KWVR9pA5ZZk1jlkjmHumGd3BgU546Bq+mimjZ1kaWiHPTb6ZoEDyokkndUhyA+dOhopaJKH/klk kYP2aGaei/qJJaCKkqokpz5KqqeVkqZZaqUQ3JcOgxHmOiFgq0WV2q/Anqnll3FG1Wuvwq61pnv/ w55J2GYKlfbsSRNxh9udkGanLXDYMrTtt7l1C+64w4lL7rm0mYvuuo2oy+67hLgL77x8YGufb+tp JCUVC9JrnKWf6vdqh4ciIeWcovqbFcBCLrmnpnxxxyWO/Vala2uJzrqvwkfY22q0EnETqWBA8tne pAOfyibHvbDI5cgDqwpzljKjHOgt3zmVMMvLuZysq9nWPGahqz5c6C4r85zFnZ6CGnSkRZfaNKUm z0rwzkpTQeVECL2Kb7SX7VrtsW2WzU7ObWa9tM9qt90yw27HvXCtctc9txR2590z3Hr3nYS8fgcO BNuCF04r3oYnviLf7AV8skkfKvN1g+SISBJ4/6MpfiDdVQL6YJCkOp1yzaCShZboNX6j+eKc4ymg jI6aiLXrpiZN84aJ2ac404QGXHSg7qH6qO3EaozknKvjwDuKkwc/rTahSytr1bfzSXHKyePhc+hw FnxkwqUpinL1PIpsdPYwLM/f0OKPHz75OQoNMdXoz7B1Qo85eHafjSfL7P8YSpu1woO/+rkAcAYM HAIT2LcFMjBvDnxg3SIowbhRsIJtuyAGs3a/FF0qW/MpQsUKhqsIeS8cAlmfhtAkmuDFhmmYOSHB tpGg6KXKfMObHZFsGBCpvY5ofTIEDCFHpnQ4biOC4mHv8CK+fSkRUsDrIZx0OAjedalR3Iuief+6 57SdaZGE7ZtL8aD4wZBpJEwbc4MVRRe1PaWRNJWh3KaCmDrHSXF8+TvjHbH2NSFub2Zs9N4be6en OS7xhE4k3gwJOb/RSWJ5gQyJICWTsTDqcZJHw54PGUk77E3ti4zo4Ggq58EQgShANwub7+5RQhnu D0x+2RULMTbGUBKuOYO04wZZoMHY5DKMu1xBL4OpsGESk17GPCa8kqlMdjGzmejq4FTuMEI0CsR3 B9GVevQXSwpR0pZ82+QmaqhIcUYPLj+MpDsaCUJZ4u6Ff1TRCFUHy8yAsIv8u+eQLjlDUOrzfE1U 2SPj+TF1usl9qBQoHvX1zX2izZ/6FAk/Ubf/CBjiMGp/6uNYThM5dFqyfdsM4vr+GVHn/bInBJ2f qKYmQpIa8pBgrGTt0klHO7LPEZBUaSMztUWXHnGnhJpoO105Kk7S8abtctlV3hO5UZ4Sad7iUBOv 6byaLsuqVfXfHWnZwqSG8zknxeoGn2mIsBoVg2SF5rjSqtZvsbWt2norXLEj17lSR5q6A0M12UTV TmWzbCEF4Hk8ylVwto6dbjjjEzF1NG/KtI3KymSqugrQeP3RQUB6IxIV6sV/CjWwbqTpWfMpVsuG E2dqGuRmYadIhpYxqA/VJUgPNtW80uWyFUrMMszBmmAV8qdEpV5lH5ZQGZr1bYeFLV+/gFTS/340 plt9KRdHWycm4jSlrKIoeb7j2ckyFrr9DK7tRurd4QZHqU2hllucUdz9uYablA2WCh+0URNyN6tS ve5XnXNcTUqwrn3ob38FB2C7PqfABm4OghOcnAUzuDgO1o0AJvxgURYwqAOegQBqQGEcdHgFGwZx bj6cBBKzYYi6y3ARQuzhFrCYxTqAcYl5IGMk1PhfybUYLBOiQhpQOMQvNvGEN/xiApB4yDWGMZCV jGQjE1nETh6yj4nM5A8jucpW/jELmuxkI0NZBlIOsolfg1vIQtQuYKayl7fs4i0HGcpKdkGcn/zl Nf+YzjeOQYeB3OY615nPIAY0nNWc5zV32f/QiCbzaRHl2zP3ANBxZjMMihxlKfdZxHQOtJXh7OdK b5rTkk60pin95SuDutCRvnKhOUJQM8uWxqD+s54lvepU5xnSseYwrS+9ajv3OdW5lvOvG7PoHEq3 xz7OdaRLvWswX/rZuPZ1p4Wt7FALWtqHfrO0tV3qa6OUcb7qGrA0+toXhBnPXK60m6m8ZEt7mtmj bneXxcxhd6vbxVm297k1/W4tB1rOd473GCI84jE3odc8I7jS7G3BWz7YXwqnsaonTvGKW/ziGM+4 xjfO8Y57/OK72e/DIe7wkS+zLibnIMpTnvCVs5xjEvDIy1uulZnDPOYytzkycf4TnZNrAtRy8Pm6 gJ4CoQ+d6EU3+lopEAmlb4vpJui50xUM9RMgburOsUAcsE71Cpwhx1yHp9bP4JERmP3saE+72tfO 9rannewpcLvc5073utv97iGAuwPwzve++/3vgMeA3qMe+MIb/vCIF8Hg45D4xjv+8X8/QwIAADs= ------=_NextPart_000_0001_01C30A3F.5D4423F0 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhGgGdAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAW AZkAggAAAAAAAAAA/4CAgP///wECAwECAwECAwP/CLrc8zDKSau9OOvNu/9gKG5NaZ5LRKxs675w LM90bd94ru98798RlNDxKxqPyKRyyeQNhsJHc0qtWq9Y3QNaGmS/4LB4nHtyFV6yes1uM83QtHtO r9tfcJT8zu/7wXldf4OEhUuBDHuGi4yNMluCjmoBAS+UlTKUbJo1lzuXmGqQiS2gnlOmp1eqK6ww nC6wr6FLrqyyM7g4umGjaJahvErCVbjELLzHVsa0OsqZzWIQpLG0mqAErj2ynrfXzzGq4tjZqaWV 3rqm1eTQwbDtrd3I6Nzx9G3Tv9Xn9JjgNJj9Gygv2q5u2srhA0awH7SFCnMhZOYwYrmG8KIBrKIP /4AiixY3XrwHMmS9ip/QZSspD2JFig8LGpy18uTLZu/wwXRJJshHkBlr4cxpz8c3myODAuOpbp2/ Z0dLKqXZMpWtmYCm/SzacthQndawdvrXdWqynChNzhIbsSFEY2+RxlzjkypQrCK7xi27M+DXtmb3 puU0jufSwWEFA0acTwLDdlYP27Ba7+hAuSzXWr588alnbJT9dU7Kdp3pyEk/nzInk+SXCZIMx57t B/bsvLRzS3PcyKnu33dsAx9OXBTv4siTXxGuvLlzJMyfS59e5jj169hjRBfN9tMNe5WPoD7oLK07 3JO753Ct91x4LdaRyc7yFf2rVvjL/1Cff2UuHv/8TSZfJuEMCJ8KltAEXljjDKUOPxkt+I4t7DDo X01EWVjKSP/1B1k8vs0jU1X93Qdhfu956ER8ni1EloEvbmjghSXW5J81JcZII404XqgUWjjFUqOJ N8q4I48e6kjQNQQuxSQ8TwXYwnYJqkiakFVGiaV8Kl05YotGejlTMDBuWVB6UJb52IwTEoZik529 2KWVR9pA5ZZk1jlkjmHumGd3BgU546Bq+mimjZ1kaWiHPTb6ZoEDyokkndUhyA+dOhopaJKH/klk kYP2aGaei/qJJaCKkqokpz5KqqeVkqZZaqUQ3JcOgxHmOiFgq0WV2q/Anqnll3FG1Wuvwq61pnv/ w55J2GYKlfbsSRNxh9udkGanLXDYMrTtt7l1C+64w4lL7rm0mYvuuo2oy+67hLgL77x8YGufb+tp JCUVC9JrnKWf6vdqh4ciIeWcovqbFcBCLrmnpnxxxyWO/Vala2uJzrqvwkfY22q0EnETqWBA8tne pAOfyibHvbDI5cgDqwpzljKjHOgt3zmVMMvLuZysq9nWPGahqz5c6C4r85zFnZ6CGnSkRZfaNKUm z0rwzkpTQeVECL2Kb7SX7VrtsW2WzU7ObWa9tM9qt90yw27HvXCtctc9txR2590z3Hr3nYS8fgcO BNuCF04r3oYnviLf7AV8skkfKvN1g+SISBJ4/6MpfiDdVQL6YJCkOp1yzaCShZboNX6j+eKc4ymg jI6aiLXrpiZN84aJ2ac404QGXHSg7qH6qO3EaozknKvjwDuKkwc/rTahSytr1bfzSXHKyePhc+hw FnxkwqUpinL1PIpsdPYwLM/f0OKPHz75OQoNMdXoz7B1Qo85eHafjSfL7P8YSpu1woO/+rkAcAYM HAIT2LcFMjBvDnxg3SIowbhRsIJtuyAGs3a/FF0qW/MpQsUKhqsIeS8cAlmfhtAkmuDFhmmYOSHB tpGg6KXKfMObHZFsGBCpvY5ofTIEDCFHpnQ4biOC4mHv8CK+fSkRUsDrIZx0OAjedalR3Iuief+6 57SdaZGE7ZtL8aD4wZBpJEwbc4MVRRe1PaWRNJWh3KaCmDrHSXF8+TvjHbH2NSFub2Zs9N4be6en OS7xhE4k3gwJOb/RSWJ5gQyJICWTsTDqcZJHw54PGUk77E3ti4zo4Ggq58EQgShANwub7+5RQhnu D0x+2RULMTbGUBKuOYO04wZZoMHY5DKMu1xBL4OpsGESk17GPCa8kqlMdjGzmejq4FTuMEI0CsR3 B9GVevQXSwpR0pZ82+QmaqhIcUYPLj+MpDsaCUJZ4u6Ff1TRCFUHy8yAsIv8u+eQLjlDUOrzfE1U 2SPj+TF1usl9qBQoHvX1zX2izZ/6FAk/Ubf/CBjiMGp/6uNYThM5dFqyfdsM4vr+GVHn/bInBJ2f qKYmQpIa8pBgrGTt0klHO7LPEZBUaSMztUWXHnGnhJpoO105Kk7S8abtctlV3hO5UZ4Sad7iUBOv 6byaLsuqVfXfHWnZwqSG8zknxeoGn2mIsBoVg2SF5rjSqtZvsbWt2norXLEj17lSR5q6A0M12UTV TmWzbCEF4Hk8ylVwto6dbjjjEzF1NG/KtI3KymSqugrQeP3RQUB6IxIV6sV/CjWwbqTpWfMpVsuG E2dqGuRmYadIhpYxqA/VJUgPNtW80uWyFUrMMszBmmAV8qdEpV5lH5ZQGZr1bYeFLV+/gFTS/340 plt9KRdHWycm4jSlrKIoeb7j2ckyFrr9DK7tRurd4QZHqU2hllucUdz9uYablA2WCh+0URNyN6tS ve5XnXNcTUqwrn3ob38FB2C7PqfABm4OghOcnAUzuDgO1o0AJvxgURYwqAOegQBqQGEcdHgFGwZx bj6cBBKzYYi6y3ARQuzhFrCYxTqAcYl5IGMk1PhfybUYLBOiQhpQOMQvNvGEN/xiApB4yDWGMZCV jGQjE1nETh6yj4nM5A8jucpW/jELmuxkI0NZBlIOsolfg1vIQtQuYKayl7fs4i0HGcpKdkGcn/zl Nf+YzjeOQYeB3OY615nPIAY0nNWc5zV32f/QiCbzaRHl2zP3ANBxZjMMihxlKfdZxHQOtJXh7OdK b5rTkk60pin95SuDutCRvnKhOUJQM8uWxqD+s54lvepU5xnSseYwrS+9ajv3OdW5lvOvG7PoHEq3 xz7OdaRLvWswX/rZuPZ1p4Wt7FALWtqHfrO0tV3qa6OUcb7qGrA0+toXhBnPXK60m6m8ZEt7mtmj bneXxcxhd6vbxVm297k1/W4tB1rOd473GCI84jE3odc8I7jS7G3BWz7YXwqnsaonTvGKW/ziGM+4 xjfO8Y57/OK72e/DIe7wkS+zLibnIMpTnvCVs5xjEvDIy1uulZnDPOYytzkycf4TnZNrAtRy8Pm6 gJ4CoQ+d6EU3+lopEAmlb4vpJui50xUM9RMgburOsUAcsE71Cpwhx1yHp9bP4JERmP3saE+72tfO 9rannewpcLvc5073utv97iGAuwPwzve++/3vgMeA3qMe+MIb/vCIF8Hg45D4xjv+8X8/QwIAADs= ------=_NextPart_000_0001_01C30A3F.5D4423F0 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhGgGdAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAW AZkAggAAAAAAAAAA/4CAgP///wECAwECAwECAwP/CLrc8zDKSau9OOvNu/9gKG5NaZ5LRKxs675w LM90bd94ru98798RlNDxKxqPyKRyyeQNhsJHc0qtWq9Y3QNaGmS/4LB4nHtyFV6yes1uM83QtHtO r9tfcJT8zu/7wXldf4OEhUuBDHuGi4yNMluCjmoBAS+UlTKUbJo1lzuXmGqQiS2gnlOmp1eqK6ww nC6wr6FLrqyyM7g4umGjaJahvErCVbjELLzHVsa0OsqZzWIQpLG0mqAErj2ynrfXzzGq4tjZqaWV 3rqm1eTQwbDtrd3I6Nzx9G3Tv9Xn9JjgNJj9Gygv2q5u2srhA0awH7SFCnMhZOYwYrmG8KIBrKIP /4AiixY3XrwHMmS9ip/QZSspD2JFig8LGpy18uTLZu/wwXRJJshHkBlr4cxpz8c3myODAuOpbp2/ Z0dLKqXZMpWtmYCm/SzacthQndawdvrXdWqynChNzhIbsSFEY2+RxlzjkypQrCK7xi27M+DXtmb3 puU0jufSwWEFA0acTwLDdlYP27Ba7+hAuSzXWr588alnbJT9dU7Kdp3pyEk/nzInk+SXCZIMx57t B/bsvLRzS3PcyKnu33dsAx9OXBTv4siTXxGuvLlzJMyfS59e5jj169hjRBfN9tMNe5WPoD7oLK07 3JO753Ct91x4LdaRyc7yFf2rVvjL/1Cff2UuHv/8TSZfJuEMCJ8KltAEXljjDKUOPxkt+I4t7DDo X01EWVjKSP/1B1k8vs0jU1X93Qdhfu956ER8ni1EloEvbmjghSXW5J81JcZII404XqgUWjjFUqOJ N8q4I48e6kjQNQQuxSQ8TwXYwnYJqkiakFVGiaV8Kl05YotGejlTMDBuWVB6UJb52IwTEoZik529 2KWVR9pA5ZZk1jlkjmHumGd3BgU546Bq+mimjZ1kaWiHPTb6ZoEDyokkndUhyA+dOhopaJKH/klk kYP2aGaei/qJJaCKkqokpz5KqqeVkqZZaqUQ3JcOgxHmOiFgq0WV2q/Anqnll3FG1Wuvwq61pnv/ w55J2GYKlfbsSRNxh9udkGanLXDYMrTtt7l1C+64w4lL7rm0mYvuuo2oy+67hLgL77x8YGufb+tp JCUVC9JrnKWf6vdqh4ciIeWcovqbFcBCLrmnpnxxxyWO/Vala2uJzrqvwkfY22q0EnETqWBA8tne pAOfyibHvbDI5cgDqwpzljKjHOgt3zmVMMvLuZysq9nWPGahqz5c6C4r85zFnZ6CGnSkRZfaNKUm z0rwzkpTQeVECL2Kb7SX7VrtsW2WzU7ObWa9tM9qt90yw27HvXCtctc9txR2590z3Hr3nYS8fgcO BNuCF04r3oYnviLf7AV8skkfKvN1g+SISBJ4/6MpfiDdVQL6YJCkOp1yzaCShZboNX6j+eKc4ymg jI6aiLXrpiZN84aJ2ac404QGXHSg7qH6qO3EaozknKvjwDuKkwc/rTahSytr1bfzSXHKyePhc+hw FnxkwqUpinL1PIpsdPYwLM/f0OKPHz75OQoNMdXoz7B1Qo85eHafjSfL7P8YSpu1woO/+rkAcAYM HAIT2LcFMjBvDnxg3SIowbhRsIJtuyAGs3a/FF0qW/MpQsUKhqsIeS8cAlmfhtAkmuDFhmmYOSHB tpGg6KXKfMObHZFsGBCpvY5ofTIEDCFHpnQ4biOC4mHv8CK+fSkRUsDrIZx0OAjedalR3Iuief+6 57SdaZGE7ZtL8aD4wZBpJEwbc4MVRRe1PaWRNJWh3KaCmDrHSXF8+TvjHbH2NSFub2Zs9N4be6en OS7xhE4k3gwJOb/RSWJ5gQyJICWTsTDqcZJHw54PGUk77E3ti4zo4Ggq58EQgShANwub7+5RQhnu D0x+2RULMTbGUBKuOYO04wZZoMHY5DKMu1xBL4OpsGESk17GPCa8kqlMdjGzmejq4FTuMEI0CsR3 B9GVevQXSwpR0pZ82+QmaqhIcUYPLj+MpDsaCUJZ4u6Ff1TRCFUHy8yAsIv8u+eQLjlDUOrzfE1U 2SPj+TF1usl9qBQoHvX1zX2izZ/6FAk/Ubf/CBjiMGp/6uNYThM5dFqyfdsM4vr+GVHn/bInBJ2f qKYmQpIa8pBgrGTt0klHO7LPEZBUaSMztUWXHnGnhJpoO105Kk7S8abtctlV3hO5UZ4Sad7iUBOv 6byaLsuqVfXfHWnZwqSG8zknxeoGn2mIsBoVg2SF5rjSqtZvsbWt2norXLEj17lSR5q6A0M12UTV TmWzbCEF4Hk8ylVwto6dbjjjEzF1NG/KtI3KymSqugrQeP3RQUB6IxIV6sV/CjWwbqTpWfMpVsuG E2dqGuRmYadIhpYxqA/VJUgPNtW80uWyFUrMMszBmmAV8qdEpV5lH5ZQGZr1bYeFLV+/gFTS/340 plt9KRdHWycm4jSlrKIoeb7j2ckyFrr9DK7tRurd4QZHqU2hllucUdz9uYablA2WCh+0URNyN6tS ve5XnXNcTUqwrn3ob38FB2C7PqfABm4OghOcnAUzuDgO1o0AJvxgURYwqAOegQBqQGEcdHgFGwZx bj6cBBKzYYi6y3ARQuzhFrCYxTqAcYl5IGMk1PhfybUYLBOiQhpQOMQvNvGEN/xiApB4yDWGMZCV jGQjE1nETh6yj4nM5A8jucpW/jELmuxkI0NZBlIOsolfg1vIQtQuYKayl7fs4i0HGcpKdkGcn/zl Nf+YzjeOQYeB3OY615nPIAY0nNWc5zV32f/QiCbzaRHl2zP3ANBxZjMMihxlKfdZxHQOtJXh7OdK b5rTkk60pin95SuDutCRvnKhOUJQM8uWxqD+s54lvepU5xnSseYwrS+9ajv3OdW5lvOvG7PoHEq3 xz7OdaRLvWswX/rZuPZ1p4Wt7FALWtqHfrO0tV3qa6OUcb7qGrA0+toXhBnPXK60m6m8ZEt7mtmj bneXxcxhd6vbxVm297k1/W4tB1rOd473GCI84jE3odc8I7jS7G3BWz7YXwqnsaonTvGKW/ziGM+4 xjfO8Y57/OK72e/DIe7wkS+zLibnIMpTnvCVs5xjEvDIy1uulZnDPOYytzkycf4TnZNrAtRy8Pm6 gJ4CoQ+d6EU3+lopEAmlb4vpJui50xUM9RMgburOsUAcsE71Cpwhx1yHp9bP4JERmP3saE+72tfO 9rannewpcLvc5073utv97iGAuwPwzve++/3vgMeA3qMe+MIb/vCIF8Hg45D4xjv+8X8/QwIAADs= ------=_NextPart_000_0001_01C30A3F.5D4423F0 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhGgGdAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAW AZkAggAAAAAAAAAA/4CAgP///wECAwECAwECAwP/CLrc8zDKSau9OOvNu/9gKG5NaZ5LRKxs675w LM90bd94ru98798RlNDxKxqPyKRyyeQNhsJHc0qtWq9Y3QNaGmS/4LB4nHtyFV6yes1uM83QtHtO r9tfcJT8zu/7wXldf4OEhUuBDHuGi4yNMluCjmoBAS+UlTKUbJo1lzuXmGqQiS2gnlOmp1eqK6ww nC6wr6FLrqyyM7g4umGjaJahvErCVbjELLzHVsa0OsqZzWIQpLG0mqAErj2ynrfXzzGq4tjZqaWV 3rqm1eTQwbDtrd3I6Nzx9G3Tv9Xn9JjgNJj9Gygv2q5u2srhA0awH7SFCnMhZOYwYrmG8KIBrKIP /4AiixY3XrwHMmS9ip/QZSspD2JFig8LGpy18uTLZu/wwXRJJshHkBlr4cxpz8c3myODAuOpbp2/ Z0dLKqXZMpWtmYCm/SzacthQndawdvrXdWqynChNzhIbsSFEY2+RxlzjkypQrCK7xi27M+DXtmb3 puU0jufSwWEFA0acTwLDdlYP27Ba7+hAuSzXWr588alnbJT9dU7Kdp3pyEk/nzInk+SXCZIMx57t B/bsvLRzS3PcyKnu33dsAx9OXBTv4siTXxGuvLlzJMyfS59e5jj169hjRBfN9tMNe5WPoD7oLK07 3JO753Ct91x4LdaRyc7yFf2rVvjL/1Cff2UuHv/8TSZfJuEMCJ8KltAEXljjDKUOPxkt+I4t7DDo X01EWVjKSP/1B1k8vs0jU1X93Qdhfu956ER8ni1EloEvbmjghSXW5J81JcZII404XqgUWjjFUqOJ N8q4I48e6kjQNQQuxSQ8TwXYwnYJqkiakFVGiaV8Kl05YotGejlTMDBuWVB6UJb52IwTEoZik529 2KWVR9pA5ZZk1jlkjmHumGd3BgU546Bq+mimjZ1kaWiHPTb6ZoEDyokkndUhyA+dOhopaJKH/klk kYP2aGaei/qJJaCKkqokpz5KqqeVkqZZaqUQ3JcOgxHmOiFgq0WV2q/Anqnll3FG1Wuvwq61pnv/ w55J2GYKlfbsSRNxh9udkGanLXDYMrTtt7l1C+64w4lL7rm0mYvuuo2oy+67hLgL77x8YGufb+tp JCUVC9JrnKWf6vdqh4ciIeWcovqbFcBCLrmnpnxxxyWO/Vala2uJzrqvwkfY22q0EnETqWBA8tne pAOfyibHvbDI5cgDqwpzljKjHOgt3zmVMMvLuZysq9nWPGahqz5c6C4r85zFnZ6CGnSkRZfaNKUm z0rwzkpTQeVECL2Kb7SX7VrtsW2WzU7ObWa9tM9qt90yw27HvXCtctc9txR2590z3Hr3nYS8fgcO BNuCF04r3oYnviLf7AV8skkfKvN1g+SISBJ4/6MpfiDdVQL6YJCkOp1yzaCShZboNX6j+eKc4ymg jI6aiLXrpiZN84aJ2ac404QGXHSg7qH6qO3EaozknKvjwDuKkwc/rTahSytr1bfzSXHKyePhc+hw FnxkwqUpinL1PIpsdPYwLM/f0OKPHz75OQoNMdXoz7B1Qo85eHafjSfL7P8YSpu1woO/+rkAcAYM HAIT2LcFMjBvDnxg3SIowbhRsIJtuyAGs3a/FF0qW/MpQsUKhqsIeS8cAlmfhtAkmuDFhmmYOSHB tpGg6KXKfMObHZFsGBCpvY5ofTIEDCFHpnQ4biOC4mHv8CK+fSkRUsDrIZx0OAjedalR3Iuief+6 57SdaZGE7ZtL8aD4wZBpJEwbc4MVRRe1PaWRNJWh3KaCmDrHSXF8+TvjHbH2NSFub2Zs9N4be6en OS7xhE4k3gwJOb/RSWJ5gQyJICWTsTDqcZJHw54PGUk77E3ti4zo4Ggq58EQgShANwub7+5RQhnu D0x+2RULMTbGUBKuOYO04wZZoMHY5DKMu1xBL4OpsGESk17GPCa8kqlMdjGzmejq4FTuMEI0CsR3 B9GVevQXSwpR0pZ82+QmaqhIcUYPLj+MpDsaCUJZ4u6Ff1TRCFUHy8yAsIv8u+eQLjlDUOrzfE1U 2SPj+TF1usl9qBQoHvX1zX2izZ/6FAk/Ubf/CBjiMGp/6uNYThM5dFqyfdsM4vr+GVHn/bInBJ2f qKYmQpIa8pBgrGTt0klHO7LPEZBUaSMztUWXHnGnhJpoO105Kk7S8abtctlV3hO5UZ4Sad7iUBOv 6byaLsuqVfXfHWnZwqSG8zknxeoGn2mIsBoVg2SF5rjSqtZvsbWt2norXLEj17lSR5q6A0M12UTV TmWzbCEF4Hk8ylVwto6dbjjjEzF1NG/KtI3KymSqugrQeP3RQUB6IxIV6sV/CjWwbqTpWfMpVsuG E2dqGuRmYadIhpYxqA/VJUgPNtW80uWyFUrMMszBmmAV8qdEpV5lH5ZQGZr1bYeFLV+/gFTS/340 plt9KRdHWycm4jSlrKIoeb7j2ckyFrr9DK7tRurd4QZHqU2hllucUdz9uYablA2WCh+0URNyN6tS ve5XnXNcTUqwrn3ob38FB2C7PqfABm4OghOcnAUzuDgO1o0AJvxgURYwqAOegQBqQGEcdHgFGwZx bj6cBBKzYYi6y3ARQuzhFrCYxTqAcYl5IGMk1PhfybUYLBOiQhpQOMQvNvGEN/xiApB4yDWGMZCV jGQjE1nETh6yj4nM5A8jucpW/jELmuxkI0NZBlIOsolfg1vIQtQuYKayl7fs4i0HGcpKdkGcn/zl Nf+YzjeOQYeB3OY615nPIAY0nNWc5zV32f/QiCbzaRHl2zP3ANBxZjMMihxlKfdZxHQOtJXh7OdK b5rTkk60pin95SuDutCRvnKhOUJQM8uWxqD+s54lvepU5xnSseYwrS+9ajv3OdW5lvOvG7PoHEq3 xz7OdaRLvWswX/rZuPZ1p4Wt7FALWtqHfrO0tV3qa6OUcb7qGrA0+toXhBnPXK60m6m8ZEt7mtmj bneXxcxhd6vbxVm297k1/W4tB1rOd473GCI84jE3odc8I7jS7G3BWz7YXwqnsaonTvGKW/ziGM+4 xjfO8Y57/OK72e/DIe7wkS+zLibnIMpTnvCVs5xjEvDIy1uulZnDPOYytzkycf4TnZNrAtRy8Pm6 gJ4CoQ+d6EU3+lopEAmlb4vpJui50xUM9RMgburOsUAcsE71Cpwhx1yHp9bP4JERmP3saE+72tfO 9rannewpcLvc5073utv97iGAuwPwzve++/3vgMeA3qMe+MIb/vCIF8Hg45D4xjv+8X8/QwIAADs= ------=_NextPart_000_0001_01C30A3F.5D4423F0 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhGgGdAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAW AZkAggAAAAAAAAAA/4CAgP///wECAwECAwECAwP/CLrc8zDKSau9OOvNu/9gKG5NaZ5LRKxs675w LM90bd94ru98798RlNDxKxqPyKRyyeQNhsJHc0qtWq9Y3QNaGmS/4LB4nHtyFV6yes1uM83QtHtO r9tfcJT8zu/7wXldf4OEhUuBDHuGi4yNMluCjmoBAS+UlTKUbJo1lzuXmGqQiS2gnlOmp1eqK6ww nC6wr6FLrqyyM7g4umGjaJahvErCVbjELLzHVsa0OsqZzWIQpLG0mqAErj2ynrfXzzGq4tjZqaWV 3rqm1eTQwbDtrd3I6Nzx9G3Tv9Xn9JjgNJj9Gygv2q5u2srhA0awH7SFCnMhZOYwYrmG8KIBrKIP /4AiixY3XrwHMmS9ip/QZSspD2JFig8LGpy18uTLZu/wwXRJJshHkBlr4cxpz8c3myODAuOpbp2/ Z0dLKqXZMpWtmYCm/SzacthQndawdvrXdWqynChNzhIbsSFEY2+RxlzjkypQrCK7xi27M+DXtmb3 puU0jufSwWEFA0acTwLDdlYP27Ba7+hAuSzXWr588alnbJT9dU7Kdp3pyEk/nzInk+SXCZIMx57t B/bsvLRzS3PcyKnu33dsAx9OXBTv4siTXxGuvLlzJMyfS59e5jj169hjRBfN9tMNe5WPoD7oLK07 3JO753Ct91x4LdaRyc7yFf2rVvjL/1Cff2UuHv/8TSZfJuEMCJ8KltAEXljjDKUOPxkt+I4t7DDo X01EWVjKSP/1B1k8vs0jU1X93Qdhfu956ER8ni1EloEvbmjghSXW5J81JcZII404XqgUWjjFUqOJ N8q4I48e6kjQNQQuxSQ8TwXYwnYJqkiakFVGiaV8Kl05YotGejlTMDBuWVB6UJb52IwTEoZik529 2KWVR9pA5ZZk1jlkjmHumGd3BgU546Bq+mimjZ1kaWiHPTb6ZoEDyokkndUhyA+dOhopaJKH/klk kYP2aGaei/qJJaCKkqokpz5KqqeVkqZZaqUQ3JcOgxHmOiFgq0WV2q/Anqnll3FG1Wuvwq61pnv/ w55J2GYKlfbsSRNxh9udkGanLXDYMrTtt7l1C+64w4lL7rm0mYvuuo2oy+67hLgL77x8YGufb+tp JCUVC9JrnKWf6vdqh4ciIeWcovqbFcBCLrmnpnxxxyWO/Vala2uJzrqvwkfY22q0EnETqWBA8tne pAOfyibHvbDI5cgDqwpzljKjHOgt3zmVMMvLuZysq9nWPGahqz5c6C4r85zFnZ6CGnSkRZfaNKUm z0rwzkpTQeVECL2Kb7SX7VrtsW2WzU7ObWa9tM9qt90yw27HvXCtctc9txR2590z3Hr3nYS8fgcO BNuCF04r3oYnviLf7AV8skkfKvN1g+SISBJ4/6MpfiDdVQL6YJCkOp1yzaCShZboNX6j+eKc4ymg jI6aiLXrpiZN84aJ2ac404QGXHSg7qH6qO3EaozknKvjwDuKkwc/rTahSytr1bfzSXHKyePhc+hw FnxkwqUpinL1PIpsdPYwLM/f0OKPHz75OQoNMdXoz7B1Qo85eHafjSfL7P8YSpu1woO/+rkAcAYM HAIT2LcFMjBvDnxg3SIowbhRsIJtuyAGs3a/FF0qW/MpQsUKhqsIeS8cAlmfhtAkmuDFhmmYOSHB tpGg6KXKfMObHZFsGBCpvY5ofTIEDCFHpnQ4biOC4mHv8CK+fSkRUsDrIZx0OAjedalR3Iuief+6 57SdaZGE7ZtL8aD4wZBpJEwbc4MVRRe1PaWRNJWh3KaCmDrHSXF8+TvjHbH2NSFub2Zs9N4be6en OS7xhE4k3gwJOb/RSWJ5gQyJICWTsTDqcZJHw54PGUk77E3ti4zo4Ggq58EQgShANwub7+5RQhnu D0x+2RULMTbGUBKuOYO04wZZoMHY5DKMu1xBL4OpsGESk17GPCa8kqlMdjGzmejq4FTuMEI0CsR3 B9GVevQXSwpR0pZ82+QmaqhIcUYPLj+MpDsaCUJZ4u6Ff1TRCFUHy8yAsIv8u+eQLjlDUOrzfE1U 2SPj+TF1usl9qBQoHvX1zX2izZ/6FAk/Ubf/CBjiMGp/6uNYThM5dFqyfdsM4vr+GVHn/bInBJ2f qKYmQpIa8pBgrGTt0klHO7LPEZBUaSMztUWXHnGnhJpoO105Kk7S8abtctlV3hO5UZ4Sad7iUBOv 6byaLsuqVfXfHWnZwqSG8zknxeoGn2mIsBoVg2SF5rjSqtZvsbWt2norXLEj17lSR5q6A0M12UTV TmWzbCEF4Hk8ylVwto6dbjjjEzF1NG/KtI3KymSqugrQeP3RQUB6IxIV6sV/CjWwbqTpWfMpVsuG E2dqGuRmYadIhpYxqA/VJUgPNtW80uWyFUrMMszBmmAV8qdEpV5lH5ZQGZr1bYeFLV+/gFTS/340 plt9KRdHWycm4jSlrKIoeb7j2ckyFrr9DK7tRurd4QZHqU2hllucUdz9uYablA2WCh+0URNyN6tS ve5XnXNcTUqwrn3ob38FB2C7PqfABm4OghOcnAUzuDgO1o0AJvxgURYwqAOegQBqQGEcdHgFGwZx bj6cBBKzYYi6y3ARQuzhFrCYxTqAcYl5IGMk1PhfybUYLBOiQhpQOMQvNvGEN/xiApB4yDWGMZCV jGQjE1nETh6yj4nM5A8jucpW/jELmuxkI0NZBlIOsolfg1vIQtQuYKayl7fs4i0HGcpKdkGcn/zl Nf+YzjeOQYeB3OY615nPIAY0nNWc5zV32f/QiCbzaRHl2zP3ANBxZjMMihxlKfdZxHQOtJXh7OdK b5rTkk60pin95SuDutCRvnKhOUJQM8uWxqD+s54lvepU5xnSseYwrS+9ajv3OdW5lvOvG7PoHEq3 xz7OdaRLvWswX/rZuPZ1p4Wt7FALWtqHfrO0tV3qa6OUcb7qGrA0+toXhBnPXK60m6m8ZEt7mtmj bneXxcxhd6vbxVm297k1/W4tB1rOd473GCI84jE3odc8I7jS7G3BWz7YXwqnsaonTvGKW/ziGM+4 xjfO8Y57/OK72e/DIe7wkS+zLibnIMpTnvCVs5xjEvDIy1uulZnDPOYytzkycf4TnZNrAtRy8Pm6 gJ4CoQ+d6EU3+lopEAmlb4vpJui50xUM9RMgburOsUAcsE71Cpwhx1yHp9bP4JERmP3saE+72tfO 9rannewpcLvc5073utv97iGAuwPwzve++/3vgMeA3qMe+MIb/vCIF8Hg45D4xjv+8X8/QwIAADs= ------=_NextPart_000_0001_01C30A3F.5D4423F0 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhGgGdAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAW AZkAggAAAAAAAAAA/4CAgP///wECAwECAwECAwP/CLrc8zDKSau9OOvNu/9gKG5NaZ5LRKxs675w LM90bd94ru98798RlNDxKxqPyKRyyeQNhsJHc0qtWq9Y3QNaGmS/4LB4nHtyFV6yes1uM83QtHtO r9tfcJT8zu/7wXldf4OEhUuBDHuGi4yNMluCjmoBAS+UlTKUbJo1lzuXmGqQiS2gnlOmp1eqK6ww nC6wr6FLrqyyM7g4umGjaJahvErCVbjELLzHVsa0OsqZzWIQpLG0mqAErj2ynrfXzzGq4tjZqaWV 3rqm1eTQwbDtrd3I6Nzx9G3Tv9Xn9JjgNJj9Gygv2q5u2srhA0awH7SFCnMhZOYwYrmG8KIBrKIP /4AiixY3XrwHMmS9ip/QZSspD2JFig8LGpy18uTLZu/wwXRJJshHkBlr4cxpz8c3myODAuOpbp2/ Z0dLKqXZMpWtmYCm/SzacthQndawdvrXdWqynChNzhIbsSFEY2+RxlzjkypQrCK7xi27M+DXtmb3 puU0jufSwWEFA0acTwLDdlYP27Ba7+hAuSzXWr588alnbJT9dU7Kdp3pyEk/nzInk+SXCZIMx57t B/bsvLRzS3PcyKnu33dsAx9OXBTv4siTXxGuvLlzJMyfS59e5jj169hjRBfN9tMNe5WPoD7oLK07 3JO753Ct91x4LdaRyc7yFf2rVvjL/1Cff2UuHv/8TSZfJuEMCJ8KltAEXljjDKUOPxkt+I4t7DDo X01EWVjKSP/1B1k8vs0jU1X93Qdhfu956ER8ni1EloEvbmjghSXW5J81JcZII404XqgUWjjFUqOJ N8q4I48e6kjQNQQuxSQ8TwXYwnYJqkiakFVGiaV8Kl05YotGejlTMDBuWVB6UJb52IwTEoZik529 2KWVR9pA5ZZk1jlkjmHumGd3BgU546Bq+mimjZ1kaWiHPTb6ZoEDyokkndUhyA+dOhopaJKH/klk kYP2aGaei/qJJaCKkqokpz5KqqeVkqZZaqUQ3JcOgxHmOiFgq0WV2q/Anqnll3FG1Wuvwq61pnv/ w55J2GYKlfbsSRNxh9udkGanLXDYMrTtt7l1C+64w4lL7rm0mYvuuo2oy+67hLgL77x8YGufb+tp JCUVC9JrnKWf6vdqh4ciIeWcovqbFcBCLrmnpnxxxyWO/Vala2uJzrqvwkfY22q0EnETqWBA8tne pAOfyibHvbDI5cgDqwpzljKjHOgt3zmVMMvLuZysq9nWPGahqz5c6C4r85zFnZ6CGnSkRZfaNKUm z0rwzkpTQeVECL2Kb7SX7VrtsW2WzU7ObWa9tM9qt90yw27HvXCtctc9txR2590z3Hr3nYS8fgcO BNuCF04r3oYnviLf7AV8skkfKvN1g+SISBJ4/6MpfiDdVQL6YJCkOp1yzaCShZboNX6j+eKc4ymg jI6aiLXrpiZN84aJ2ac404QGXHSg7qH6qO3EaozknKvjwDuKkwc/rTahSytr1bfzSXHKyePhc+hw FnxkwqUpinL1PIpsdPYwLM/f0OKPHz75OQoNMdXoz7B1Qo85eHafjSfL7P8YSpu1woO/+rkAcAYM HAIT2LcFMjBvDnxg3SIowbhRsIJtuyAGs3a/FF0qW/MpQsUKhqsIeS8cAlmfhtAkmuDFhmmYOSHB tpGg6KXKfMObHZFsGBCpvY5ofTIEDCFHpnQ4biOC4mHv8CK+fSkRUsDrIZx0OAjedalR3Iuief+6 57SdaZGE7ZtL8aD4wZBpJEwbc4MVRRe1PaWRNJWh3KaCmDrHSXF8+TvjHbH2NSFub2Zs9N4be6en OS7xhE4k3gwJOb/RSWJ5gQyJICWTsTDqcZJHw54PGUk77E3ti4zo4Ggq58EQgShANwub7+5RQhnu D0x+2RULMTbGUBKuOYO04wZZoMHY5DKMu1xBL4OpsGESk17GPCa8kqlMdjGzmejq4FTuMEI0CsR3 B9GVevQXSwpR0pZ82+QmaqhIcUYPLj+MpDsaCUJZ4u6Ff1TRCFUHy8yAsIv8u+eQLjlDUOrzfE1U 2SPj+TF1usl9qBQoHvX1zX2izZ/6FAk/Ubf/CBjiMGp/6uNYThM5dFqyfdsM4vr+GVHn/bInBJ2f qKYmQpIa8pBgrGTt0klHO7LPEZBUaSMztUWXHnGnhJpoO105Kk7S8abtctlV3hO5UZ4Sad7iUBOv 6byaLsuqVfXfHWnZwqSG8zknxeoGn2mIsBoVg2SF5rjSqtZvsbWt2norXLEj17lSR5q6A0M12UTV TmWzbCEF4Hk8ylVwto6dbjjjEzF1NG/KtI3KymSqugrQeP3RQUB6IxIV6sV/CjWwbqTpWfMpVsuG E2dqGuRmYadIhpYxqA/VJUgPNtW80uWyFUrMMszBmmAV8qdEpV5lH5ZQGZr1bYeFLV+/gFTS/340 plt9KRdHWycm4jSlrKIoeb7j2ckyFrr9DK7tRurd4QZHqU2hllucUdz9uYablA2WCh+0URNyN6tS ve5XnXNcTUqwrn3ob38FB2C7PqfABm4OghOcnAUzuDgO1o0AJvxgURYwqAOegQBqQGEcdHgFGwZx bj6cBBKzYYi6y3ARQuzhFrCYxTqAcYl5IGMk1PhfybUYLBOiQhpQOMQvNvGEN/xiApB4yDWGMZCV jGQjE1nETh6yj4nM5A8jucpW/jELmuxkI0NZBlIOsolfg1vIQtQuYKayl7fs4i0HGcpKdkGcn/zl Nf+YzjeOQYeB3OY615nPIAY0nNWc5zV32f/QiCbzaRHl2zP3ANBxZjMMihxlKfdZxHQOtJXh7OdK b5rTkk60pin95SuDutCRvnKhOUJQM8uWxqD+s54lvepU5xnSseYwrS+9ajv3OdW5lvOvG7PoHEq3 xz7OdaRLvWswX/rZuPZ1p4Wt7FALWtqHfrO0tV3qa6OUcb7qGrA0+toXhBnPXK60m6m8ZEt7mtmj bneXxcxhd6vbxVm297k1/W4tB1rOd473GCI84jE3odc8I7jS7G3BWz7YXwqnsaonTvGKW/ziGM+4 xjfO8Y57/OK72e/DIe7wkS+zLibnIMpTnvCVs5xjEvDIy1uulZnDPOYytzkycf4TnZNrAtRy8Pm6 gJ4CoQ+d6EU3+lopEAmlb4vpJui50xUM9RMgburOsUAcsE71Cpwhx1yHp9bP4JERmP3saE+72tfO 9rannewpcLvc5073utv97iGAuwPwzve++/3vgMeA3qMe+MIb/vCIF8Hg45D4xjv+8X8/QwIAADs= ------=_NextPart_000_0001_01C30A3F.5D4423F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 25 08:24:35 2003 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 IAA28977; Sun, 25 May 2003 08:24:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PCNrB30666; Sun, 25 May 2003 08:23:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Kr3826064 for ; Fri, 2 May 2003 16:53:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01936 for ; Fri, 2 May 2003 16:45:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BhRa-0007n7-00 for dhcwg@ietf.org; Fri, 02 May 2003 16:47:46 -0400 Received: from [66.187.146.131] (helo=craft97.nas.nasa.gov) by ietf-mx with esmtp (Exim 4.12) id 19BhRU-0007mv-00 for dhcwg@ietf.org; Fri, 02 May 2003 16:47:40 -0400 Received: from craft-tech.com (craft53 [192.92.187.53]) by craft97.nas.nasa.gov (8.9.3/8.9.3) with ESMTP id QAA18806 for ; Fri, 2 May 2003 16:51:39 -0400 Message-ID: <3EB2DA64.6020400@craft-tech.com> Date: Fri, 02 May 2003 16:51:48 -0400 From: Ashwin Bijur User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP clients accept IP #s from wrong subnet 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: , Content-Transfer-Encoding: 7bit Hi, I am trying to setup a DHCP server to assign IP addresses to clients on the xtreme subnetwork. When the client is booted, it's broadcasting the DHCPDISCOVER message and the xtreme server picks up the message. The server then sends out a DHCPOFFER of an IP# on the xtreme subnet. However,the client requests an IP address on a different subnet (named craft) and the DHCP server on that craft subnet then acknowledges the request while the server the xtreme subnet sends a negative acknowledgement. What's going on and how can I force the dhcp client to accept an IP # from the xtreme subnet? We are in a switched network and are using RedHat Linux as the OS. Thanks, Ashwin. If possible, please email your reply to me at abijur@craft-tech.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 25 08:26:18 2003 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 IAA29042; Sun, 25 May 2003 08:26:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PCPmB30944; Sun, 25 May 2003 08:25:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4AIHaB08379 for ; Sat, 10 May 2003 14:17:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05400 for ; Sat, 10 May 2003 14:52:26 -0400 (EDT) From: DShirleySB@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EZUI-0004lB-00 for dhcwg@ietf.org; Sat, 10 May 2003 14:54:26 -0400 Received: from imo-m05.mx.aol.com ([64.12.136.8]) by ietf-mx with esmtp (Exim 4.12) id 19EZU2-0004kV-00 for dhcwg@ietf.org; Sat, 10 May 2003 14:54:10 -0400 Received: from DShirleySB@aol.com by imo-m05.mx.aol.com (mail_out_v34.22.) id l.130.1f8d9d84 (3980) for ; Sat, 10 May 2003 14:53:47 -0400 (EDT) Message-ID: <130.1f8d9d84.2beea4ba@aol.com> Date: Sat, 10 May 2003 14:53:46 EDT To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_130.1f8d9d84.2beea4ba_boundary" X-Mailer: 7.0 for Windows sub 10638 Subject: [dhcwg] Possible DHCP problem 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: , --part1_130.1f8d9d84.2beea4ba_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, We are experiencing a situation at the school district where I work. We use both DHCP and static with our computers. Platforms are '95, '98, and 2000. No dial ups. The problem is that with static we experience no problems connecting Internet sites and or e-mail providers. With DHCP, we experience problems connecting to Internet sites and or e-mail providers. Examples. One year old computer running Windows 2000 with DHCP. Cannot access AOL mail or Hotmail. Switched from DHCP to static, problem went away. Four to 5 year old computer running Windows '98. Cannot get to Netscape site and/or AOL mail or Hotmail. Interestingly, with DHCP or static there is one local ISP/e-mail provider that we can access with no problem. Do you know of any similar problems? What are the fixes if any? Please advise. Sincerely, Daniel R. Shirley --part1_130.1f8d9d84.2beea4ba_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello,

We are experiencing a situation at the school district where I work.

We use both DHCP and static with our computers.  Platforms are '95, '98= , and 2000.  No dial ups.

The problem is that with static we experience no problems connecting Interne= t sites and or e-mail providers.

With DHCP, we experience problems connecting to Internet sites and or e-mail= providers.

Examples.  One year old computer running Windows 2000 with DHCP. =20= Cannot access AOL mail or Hotmail.  Switched from DHCP to static, probl= em went away.

Four to 5 year old computer running Windows '98.  Cannot get to Netscap= e site and/or AOL mail or Hotmail. 

Interestingly, with DHCP or static there is one local ISP/e-mail provider th= at we can access with no problem.

Do you know of any similar problems?  What are the fixes if any?

Please advise.

Sincerely,

Daniel R. Shirley

 --part1_130.1f8d9d84.2beea4ba_boundary-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 25 09:57:21 2003 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 JAA01105; Sun, 25 May 2003 09:57:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PDu5B05256; Sun, 25 May 2003 09:56:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DIu1B21652 for ; Tue, 13 May 2003 14:56:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26679 for ; Tue, 13 May 2003 15:29:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FfUb-00074E-00 for dhcwg@ietf.org; Tue, 13 May 2003 15:31:17 -0400 Received: from goliath.siemens.com ([194.138.160.6]) by ietf-mx with esmtp (Exim 4.12) id 19FfUa-00074B-00 for dhcwg@ietf.org; Tue, 13 May 2003 15:31:16 -0400 Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by goliath.siemens.com (8.11.7/8.11.7) with ESMTP id h4DJWM929148 for ; Tue, 13 May 2003 15:32:23 -0400 (EDT) Received: from yogi.inside.efficient.com ([165.218.188.2]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4DJWLF24153 for ; Tue, 13 May 2003 15:32:21 -0400 (EDT) Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 14:32:18 -0500 Message-ID: From: Doug Kehn To: "'dhcwg@ietf.org'" Date: Tue, 13 May 2003 14:32:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] Option 12 Question 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: , All, What is the recommended DHCP server response (DHCP_ACK / DHCP_NAK) when the DHCP server detects duplicate hostnames (for different client IDs)? Thanks... doug _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 25 09:59:06 2003 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 JAA01191; Sun, 25 May 2003 09:59:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PDwbB05305; Sun, 25 May 2003 09:58:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LCTAB14476 for ; Wed, 21 May 2003 08:29:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18682 for ; Wed, 21 May 2003 09:01:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ITCp-000624-00 for dhcwg@ietf.org; Wed, 21 May 2003 09:00:31 -0400 Received: from [200.152.32.154] (helo=kiwi.previdenciasocial.gov.br) by ietf-mx with esmtp (Exim 4.12) id 19ITCk-00060e-00 for dhcwg@ietf.org; Wed, 21 May 2003 09:00:31 -0400 Received: from wtrjo086.prevnet ([10.0.134.9]) by kiwi.previdenciasocial.gov.br with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 09:59:23 -0300 Received: by wtrjo086.prevnet with Internet Mail Service (5.5.2653.19) id ; Wed, 21 May 2003 10:00:27 -0300 Message-ID: <8D81D83B95637F4595FDF73D65E517E5052235EA@wtrjo099> From: Estevan Bittar Branco - DATAPREVRJ To: dhcwg@ietf.org Date: Wed, 21 May 2003 10:01:24 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 21 May 2003 12:59:23.0968 (UTC) FILETIME=[CD7F7C00:01C31F98] Subject: [dhcwg] 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: , please, i would like to configure a DHCP server over Red Hat Linux and i want to know how to set it up including exclusion range. Thank You, Estevan Bittar Branco estevan.branco@rj.previdenciasocial.gov.br DATAPREV (DOP-DERE.O-DIGR.O) TEL.: (21) 2555-6393 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 27 09:43:40 2003 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 JAA11351; Tue, 27 May 2003 09:43:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RDh5B20209; Tue, 27 May 2003 09:43:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RDdKB20044 for ; Tue, 27 May 2003 09:39:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11279 for ; Tue, 27 May 2003 09:39:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kee6-0004Ho-00 for dhcwg@ietf.org; Tue, 27 May 2003 09:37:42 -0400 Received: from webmail.mail.se.dataphone.net ([212.37.1.50] helo=intermail.se.dataphone.net) by ietf-mx with esmtp (Exim 4.12) id 19Kee5-0004Hk-00 for dhcwg@ietf.org; Tue, 27 May 2003 09:37:41 -0400 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 1323136; Tue, 27 May 2003 15:39:09 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: "'peter pilsl'" , dhcwg@ietf.org Subject: Re: [dhcwg] dhcp : expected behaviour of clients when server is d own ? Date: Tue, 27 May 2003 15:40:51 +0200 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200305271540.51704.budm@weird-solutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RDdOB20045 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: , Content-Transfer-Encoding: 8bit On Friday 23 May 2003 20.06, Bernie Volz (EUD) wrote: > You could look into running the failover protocol, but a much easier > solution is to use a much longer lease time. 600 seconds isn't very long > (10 minutes) and why do you use such a short lease? The two general reasons > are: > Note: Renewals start at 50% of the lease time. So, your current clients are > renewing every 300 seconds (5 minutes). Also, you may be able to set long lease times, but much shorter renewal times. That way your addresses stay out for a long time, but the clients are forced to renew at a short interval. I have no idea if the ISC server allows that. - Bud Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 27 16:34:56 2003 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 QAA00876; Tue, 27 May 2003 16:34:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RKYEB19068; Tue, 27 May 2003 16:34:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RCLlB13841 for ; Tue, 27 May 2003 08:21:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09696 for ; Tue, 27 May 2003 08:21:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KdR5-0003n9-00 for dhcwg@ietf.org; Tue, 27 May 2003 08:20:11 -0400 Received: from hercules.ellemedia.com ([212.205.129.4]) by ietf-mx with esmtp (Exim 4.12) id 19KdR3-0003n5-00 for dhcwg@ietf.org; Tue, 27 May 2003 08:20:11 -0400 Received: from localhost (localhost [127.0.0.1]) by hercules.ellemedia.com (Postfix) with ESMTP id 608B314F33 for ; Tue, 27 May 2003 15:17:48 +0300 (EEST) Received: from hermes.ellemedia.com (hermes.ellemedia.com [212.205.129.5]) by hercules.ellemedia.com (Postfix) with ESMTP id 82A8414F2C for ; Tue, 27 May 2003 15:17:43 +0300 (EEST) Received: from thasos.ellemedia.com (thasos.ellemedia.com [212.205.129.124]) by hermes.ellemedia.com (Postfix) with ESMTP id 001DE32A727 for ; Tue, 27 May 2003 15:36:26 +0300 (EEST) From: Arvanitis Kostas Organization: Ellemedia Technologies To: dhcwg@ietf.org Date: Tue, 27 May 2003 15:21:35 +0300 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305271521.35324.arvanit@ellemedia.com> X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhc-server-mib 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: , Content-Transfer-Encoding: 7bit I have spotted an (IMHO) omission in the MIB specification. I have noticed that the final call deadline has passed, but I was not involved with DHCP and SNMP at the time, so I have just spot it. So here come my observasions / suggestions: 1. In the MIB, two notifications are defined, namely "dhcpv4ServerFreeAddressLow" and "dhcpv4ServerFreeAddressHigh", that deal with the free address count in shared nets. However, shared nets are stated as optional in the MIB, since some DHCP servers may not implement them. Shouldn't they be named something more specific, such as "dhcpv4SharedNetFreeAddressLow" and "dhcpv4SharedNetFreeAddressHigh"? 2. There are no notifications defined for subnets, although the required fields exist and are marked as "accessible-for-notify". Shouldn't there be "dhcpv4SubnetFreeAddressLow" and "dhcpv4SubnetFreeAddressHigh" definitions? -- A: No. See http://www.netmeister.org/news/learn2quote.html Q: Should I include quotations after my reply ? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 27 16:36:49 2003 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 QAA00998; Tue, 27 May 2003 16:36:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RKaJB19177; Tue, 27 May 2003 16:36:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RIpTB11921 for ; Tue, 27 May 2003 14:51:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24494 for ; Tue, 27 May 2003 14:51:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KjW9-0007PP-00 for dhcwg@ietf.org; Tue, 27 May 2003 14:49:49 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19KjW8-0007P7-00 for dhcwg@ietf.org; Tue, 27 May 2003 14:49:48 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4RIoq4Z016818; Tue, 27 May 2003 11:50:52 -0700 (PDT) Received: from kanawha (kanawha.Eng.Sun.COM [129.146.86.81]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RIoqsX438670; Tue, 27 May 2003 11:50:52 -0700 (PDT) Message-Id: <200305271850.h4RIoqsX438670@jurassic.eng.sun.com> To: Doug Kehn cc: "'dhcwg@ietf.org'" Subject: Re: [dhcwg] Option 12 Question In-reply-to: mail from Doug Kehn dated Tue, 13 May 2003 14:32:17 CDT Date: Tue, 27 May 2003 11:50:51 -0700 From: Carl Smith 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: , > What is the recommended DHCP server response (DHCP_ACK / DHCP_NAK) when the > DHCP server detects duplicate hostnames (for different client IDs)? DHCP servers normally treat client host name options as requests for that host name, not as claims of ownership. Apart from that, behaviors vary. Servers configured to do so may attempt to proxy DNS updates on behalf of the client. In any event, failure to deliver the requested host name should not be grounds for NAKing. Other things to note: - in DHCPv4, client IDs are only guaranteed to be unique per network, so it is certainly conceivable that the same host name request might occur with differing client IDs while still representing a single client - if a server knows that a requested host name is in use by a host other than the one currently requesting it, it could either return a name corresponding to the address it leased to the client or it could return no host name option - if no host name option is returned to a client, the client should verify that it owns the IP address (if any) belonging to the requested name before using it; failing that, the client could take other steps (e.g. trying a DNS dynamic update) to accomplish its goal Carl _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 28 15:28:30 2003 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 PAA19322; Wed, 28 May 2003 15:28:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SJRoB32518; Wed, 28 May 2003 15:27:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SJO4B32382 for ; Wed, 28 May 2003 15:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19214 for ; Wed, 28 May 2003 15:24:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L6VH-0006ek-00 for dhcwg@ietf.org; Wed, 28 May 2003 15:22:27 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19L6VG-0006eB-00 for dhcwg@ietf.org; Wed, 28 May 2003 15:22:26 -0400 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4SJNVXg028239; Wed, 28 May 2003 15:23:31 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-10-86-160-46.cisco.com [10.86.160.46]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id PAA18969; Wed, 28 May 2003 15:23:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20030528152241.00b9e1a8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 May 2003 15:23:25 -0400 To: Thomas Narten From: Ralph Droms Cc: ot@cisco.com, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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: , (This is a re-send as the first posting may not have been forwarded through the dhcwg mailing list - RD) At 11:54 AM 5/14/2003 -0400, Thomas Narten wrote: > I've completed my review AD review of this document prior to starting > the IETF LC. I have one (possibly) substantative question, the rest > are nits. > > In reading the document, there is some wording that suggests that a > requesting router might ask for prefixes for each of its > interfaces. E.g, if it has two internal interfaces, plus the link to > the ISP, it might ask for two delegations, one for each internal > interface. But this isn't what I would expect normal usage to be. > Rather, I'd expect the requesting router to ask for a single > delegation, based on the one interface it has to its ISP, and would > itself decide how to further delegate to its internal interfaces. > > Is my assumption/understanding consistent with the intent of the > document? If so, some of the wording below should probably be > changed. I.e., it would be good for the document to focus on the > normal case usage. The expected use of the protocol is for the RR (requesting router) to request one delegation from the DR (delegating router). This sentence from the next-to-last paragraph in section 4 explains the expected use: In a typical scenario based on the network shown in Figure 1, the requesting router subnets a single delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each of the links in the subscriber network. Is this sentence (which comes before the following paragraph in the spec) sufficient? > E.g.: > >> Upon the receipt of a valid Reply message, for each IA_PD the >> requesting router assigns a subnet from each of the delegated >> prefixes to each of the links to which the associated interfaces are >> attached, with the following exception: the requesting router MUST >> NOT assign any delegated prefixes or subnets from the delegated >> prefix(es) to the link through which it received the DHCP message >> from the delegating router. > > do we need the above wording? I would expect that a CPE router with > three interfaces will still only make one IA_PD request. Maybe this > needs more discussion, i.e., as background. in the typical scenario, i.e ISP delegating prefixes to a customer only one IA_PD should be used. to allow for some flexibility e.g if DHCPv6 PD should be used within an administrative domain we allow for multiple IA_PDs. this is also consistent with the way IA_NA's work. > Nits: > >> for delegating long-lived prefix from a delegating router to a > > s/long-lived/a long-lived/ fixed. >> This document describes new options for DHCP, which provide a >> mechanism for the delegation of IPv6 prefixes. Through these > > s/which/that/ s/, which/that/ >> This document describes an extension to the DHCPv6 specification [6]. > > I hope this option isn't "extending" the dhcpv6 spec. In general, > options don't do that, they are just opaque blobs carried by DHC. Or > is this one different? changed to "This document describes new DHCPv6 options for IPv6 prefix delegation" >> IA_PD has an associated IAID. A requesting > > IAID used without definition/expansion. defined in the DHCPv6 specification. >> If the delegating router cannot delegate any prefixes to an IA_PD in >> the message from the requesting router, the delegating router MUST >> include the IA_PD in the Advertise message with no prefixes in the >> IA_PD and a Status Code option in the IA_PD containing status code >> NoPrefixAvail. > > Is this error going to be useful enough in terms of figuring out why > the request was denied? E.g, authorization failed? consistent with address assignment. any reason why we would need more error codes for PD and the same reasoning wouldn't apply to addresses? don't think so? >> If the delegating router will not assign any prefixes to any IA_PDs >> in a subsequent Request from the requesting router, the delegating >> router MUST send an Advertise message to the requesting router that >> includes a Status Code option with code NoPrefixAvail and a status >> message for the user, a Server Identifier option with the delegating >> router's DUID and a Client Identifier option with the requesting >> router's DUID. > > This seems like a more detailed repetition of an earlier paragraph: > > If the delegating router cannot delegate any prefixes to an IA_PD in > the message from the requesting router, the delegating router MUST > include the IA_PD in the Advertise message with no prefixes in the > IA_PD and a Status Code option in the IA_PD containing status code > NoPrefixAvail. > > Are both really needed? otherwise the requesting router cannot know which IA_PD failed. However, it does seem like the Status Code option in the first paragraph (which would not be contained in an IA_PD) is superfluous. We will combine the two paragraphs and eliminate the Status Code option from the first paragraph. >> messages sent by the requesting router. The IA_PD option include all > > s/include/includes/ fixed. >> When a requesting router subnets a delegated prefix, it must assign >> additional bits to the prefix to generate unique, longer prefixes. >> For example, if the requesting router in Figure 1 were delegated >> 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and >> 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber >> network. If the requesting router were delegated 3FFE:FFFF:0::/48 >> and 3FFE:FFFF:1::/48, it might assign 3FFE:FFFF:0:1::/64 and >> 3FFE:FFFF:1:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and >> 3FFE:FFFF:1:2::/64 for assignment to the other link. > > Is this needed? I'm skeptical about the two (separate) delegations per > above. Besides, wouldn't the ISP just delegate 3FF3:FFFF::/47? The intent here is to illustrate the delegation of two independent prefixes. The RR then assigns a /64 from each prefix to each interface. Just delegating a /47 would cause only one prefix to be assigned to each interface. In the following paragraph, I changed the example delegated prefixes so they do not both come from the same /47. Is this clearer? When a requesting router subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes. For example, if the requesting router in Figure 1 were delegated 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber network. If the requesting router were delegated 3FFE:FFFF:0::/48 and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 3FFE:FFFF:5:2::/64 for assignment to the other link. >> If the requesting router assigns a delegated prefix to a link to >> which the router is attached, and begins to send router >> advertisements for the prefix on the link, the requesting router MUST >> set the valid lifetime in those advertisements to be no later than >> the valid lifetime specified in the IA_PD Prefix option. A >> requesting router MAY use the preferred lifetime specified in the >> IA_PD Prefix option. > > I wonder of more discussion about lifetimes would be appropriate. Can you be more explicit? What part of the paragraph needs further explanation? > What happens if CPE router reboots and presents a different DUID? > delegating router will reject that (in contrast to normal DHC). Will > the right thing happen? a CPE must keep its DUID according to DHCPv6 spec. what happens if the DUID changes is dependent on delegating router policy. e.g a new prefix could be delegated. >> An intruder requesting router may be able to mount a denial of > > What is "intruder requesting router"? How about "malicious requesting router"? >> Because a requesting router and delegating routers must each have at >> least one assigned IPv6 address, the routers may be able to use IPsec >> for authentication of DHCPv6 messages. The details of using IPsec >> for DHCPv6 are under development. > > Where in the spec is this made a requirement? The mention in the > security considerations is the first reference to this I recall > seeing. The sentence you quoted is part of a paragraph in the "Security Considerations" section: To guard against attacks through prefix delegation, requesting routers and delegating routers SHOULD use DHCP authentication as described in section "Authentication of DHCP messages" in the DHCP specification [6]. For point to point links, where one trusts that there is no man in the middle, or one trusts layer two authentication, DHCP authentication or IPsec may not be necessary. Because a requesting router and delegating routers must each have at least one assigned IPv6 address, the routers may be able to use IPsec for authentication of DHCPv6 messages. The details of using IPsec for DHCPv6 are under development. We don't understand your question. Why would this security consideration be mentioned in an earlier section of the draft? What is the "this" in "...the first reference to this..." referring to? > > Have someone familiar with Radius review section 5.1, especially the > explicit radius example. Use of AAA (RADIUS) is not key to the definition of this option. We will rewrite the example to use a more generic description of the assignment of prefixes to a customer for delegation by the DR. - Ole and Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 30 07:18:04 2003 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 HAA28676; Fri, 30 May 2003 07:18:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBHMB24892; Fri, 30 May 2003 07:17:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBDDB24723 for ; Fri, 30 May 2003 07:13:13 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27984; Fri, 30 May 2003 07:13:10 -0400 (EDT) Message-Id: <200305301113.HAA27984@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: Fri, 30 May 2003 07:13:09 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-pktc-kerb-tckt-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: , --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 : PacketCable Security Ticket Control Sub-option for the CableLabs Client Configuration Option Author(s) : P. Duffy Filename : draft-ietf-dhc-pktc-kerb-tckt-02.txt Pages : 7 Date : 2003-5-29 This document defines a new sub-option for the CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate locally persisted Kerberos tickets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-02.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-pktc-kerb-tckt-02.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-pktc-kerb-tckt-02.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: <2003-5-29161325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pktc-kerb-tckt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161325.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 30 16:40:08 2003 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 QAA27080; Fri, 30 May 2003 16:40:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKdNB04187; Fri, 30 May 2003 16:39:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKa2B03181 for ; Fri, 30 May 2003 16:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26996 for ; Fri, 30 May 2003 16:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LqZu-0001EH-00 for dhcwg@ietf.org; Fri, 30 May 2003 16:34:18 -0400 Received: from smtp017.mail.yahoo.com ([216.136.174.114]) by ietf-mx with smtp (Exim 4.12) id 19LqZu-0001E7-00 for dhcwg@ietf.org; Fri, 30 May 2003 16:34:18 -0400 Received: from adsl-64-169-89-159.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 May 2003 20:35:57 -0000 Reply-To: From: "Barr Hibbs" To: "Arvanitis Kostas" , Subject: RE: [dhcwg] dhc-server-mib Date: Fri, 30 May 2003 13:27:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200305271521.35324.arvanit@ellemedia.com> Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Arvanitis Kostas > Sent: Tuesday, May 27, 2003 05:22 > *** Snip! *** > > 1. In the MIB, two notifications are defined, namely > "dhcpv4ServerFreeAddressLow" and "dhcpv4ServerFreeAddressHigh", that deal > with the free address count in shared nets. However, shared nets > are stated > as optional in the MIB, since some DHCP servers may not implement them. > Shouldn't they be named something more specific, such as > "dhcpv4SharedNetFreeAddressLow" and "dhcpv4SharedNetFreeAddressHigh"? > > 2. There are no notifications defined for subnets, although the required > fields exist and are marked as "accessible-for-notify". Shouldn't > there be > "dhcpv4SubnetFreeAddressLow" and "dhcpv4SubnetFreeAddressHigh" > definitions? > This design was based on practical experience with a widely deployed server, in particular an implementation with tens of thousands of clients on thousands of subnets. Basically, trying to track the address counts to the subnet level is both misleading and futile. Most servers of which I'm aware (and certainly the one on which this MIB design was based) do NOT allocate leases by subnet, but rather by shared network Suppose shared network A is composed of 3 subnets. Using some opaque algorithm, leases are assigned, and clients randomly return addresses, eventually leaving a configuration that is largely non-deterministic based on the starting conditions. Shared network A may have 40% free leases, although subnetwork 1 has only 3% free, while subnetwork 2 has 60% free, and subnetwork 3 has 57% free. It's important to only report counts that are significant, and the impending unavailability of free leases on subnetwork 1 does NOT affect the ability of a typical server to hand out addresses for shared network A, so I would argue that reporting counts by the subnet is misleading, as it does not reflect the ability of the server to operate correctly, and futile, because there is no control or action the administrator can take to affect the count. Hope that explanation helps. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg