From dhcwg-bounces@ietf.org Mon Jan 5 08:17:54 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DFE3A6935; Mon, 5 Jan 2009 08:17:54 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80AC33A68EF for ; Mon, 5 Jan 2009 08:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GImISKizluiZ for ; Mon, 5 Jan 2009 08:17:52 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EC3143A6935 for ; Mon, 5 Jan 2009 08:17:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,332,1228089600"; d="scan'208";a="32728766" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2009 16:17:18 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n05GHIAW004768; Mon, 5 Jan 2009 11:17:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n05GHILN025068; Mon, 5 Jan 2009 16:17:18 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 11:17:17 -0500 Received: from kkinnear-wxp01.cisco.com ([161.44.65.108]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 11:17:17 -0500 Message-Id: <4.3.2.7.2.20090105110608.032a7a90@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jan 2009 11:17:40 -0500 To: "David W. Hankins" , DHC WG From: Kim Kinnear In-Reply-To: <20081218175232.GA3310@isc.org> References: <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> <20081217195129.GA6362@isc.org> <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2009 16:17:17.0388 (UTC) FILETIME=[13E998C0:01C96F51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3586; t=1231172238; x=1232036238; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20*REMINDER*=3A=20dhc=20WG=20la st=20call=20on=0A=20=20draft-ietf-dhc-vpn-option-09.txt |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20 ,=20DHC=20WG=20; bh=YdGIf/IInBV6rccSGeE6sncgA6xgI/oFixdCAZpy3LE=; b=X8m/EmOilsAE6gVN1a1gEPDxoQYSCYtKbiqsqwzExI+bKS6UqbRT4llOoW prGh52jqvRgQHvj9c+W2nK4jG7HQuvwJ6VfpZkUTwKgmkTFTMP+fOb1lvLTa UaYPaSFRUW; Authentication-Results: rtp-dkim-1; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: volz@cisco.com, kkinnear@cisco.com Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org David, Bernie, I'd like to try to wrap up this discussion about the use of ERO/ORO for DHCPv6 VSS options. I'm very uneasy with the concept of using the ORO or ERO to specify which entity takes the lead with regard to assigning a VPN to a particular client, as was suggested in the thread below. In addition, the current VSS draft has specific language surrounding the returning of the VSS option: >7.1. Returning the DHCPv4 or DHCPv6 Option > > DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option > processing, see below) MUST return an instance of this option in the > reply packet or message if the server successfully uses this option > to allocate an IP address, and it MUST NOT include an instance of > this option if the server was unable to or not configured to support > the requested VPN. In addition, the server may spontaneously return the VSS option in cases where it is taking the lead on assigning the VPN. My point: the appearance or lack thereof of the VSS option in a reply packet communicates important information well beyond the scope of a "normal" configuration options (e.g., DNS server addresses). In particular, it may communicate information about whether or not the server could satisfy a particular request made by a client. Moreover, this has been specified clearly in the current draft. Thus, I think that the only thing I'd add to the current draft would be to say that the appearance of the VSS option in the ORO or ERO should not change the processing that is otherwise specified by the draft. Can you both agree to that? Thanks -- Kim At 12:52 PM 12/18/2008, David W. Hankins wrote: >On Wed, Dec 17, 2008 at 11:55:26PM -0500, Bernie Volz (volz) wrote: >> I think ORO, if anything, is appropriate. ERO requests the option to be >> echoed back, which is different, as the VPN can change. I don't think >> the complexity of allow either ORO or ERO (and the subtle meaning >> difference) is worth it. >> >> Also, we have both the client and relay agent which could supply the >> option; ERO is only for relays, as clients are stateful and thus there's >> no reason they'd need something they sent in echoed. > >Yes; but the draft describes several different scenarios, some of >which the relay would expect its transmitted value returned, and in >others would expect an assignment by the server. > >> I don't have strong feelings either way. I lean towards considering this >> option a "core" protocol option and thus does not require ORO - if a >> server supports it, it must do processing to do so and hence there's >> really little need to include it in the ORO. > >I don't think processing is required in all of the scenarios the draft >supposes. > >So I'd lean towards putting the option on ORO; older servers with no >support can still mimic sufficient support with manually or scripted >values, but they won't send the value unless it's on ORO. > >This also simplifies DHCPv6 packet creation routines by treating more >options consistently the same. > >-- >Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. >Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ >-- >David W. Hankins "If you don't do it right the first time, >Software Engineer you'll just have to do it again." >Internet Systems Consortium, Inc. -- Jack T. Hankins > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 5 08:47:47 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3764E28C0E0; Mon, 5 Jan 2009 08:47:47 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8949228C0E0 for ; Mon, 5 Jan 2009 08:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCFnrDP+OvOP for ; Mon, 5 Jan 2009 08:47:45 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0C84E3A689E for ; Mon, 5 Jan 2009 08:47:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,332,1228089600"; d="scan'208";a="32695994" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2009 16:47:31 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n05GlVcB027687; Mon, 5 Jan 2009 11:47:31 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n05GlVd4016184; Mon, 5 Jan 2009 16:47:32 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 11:47:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jan 2009 11:47:30 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210A163209@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <4.3.2.7.2.20090105110608.032a7a90@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt Thread-Index: AclvURQdfkX9lMZ0SjaOrKvHqyB6PAAA3acg References: <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> <20081217195129.GA6362@isc.org> <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> <4.3.2.7.2.20090105110608.032a7a90@email.cisco.com> From: "Bernie Volz (volz)" To: "Kim Kinnear Jr. (kkinnear)" , "David W. Hankins" , "DHC WG" X-OriginalArrivalTime: 05 Jan 2009 16:47:31.0668 (UTC) FILETIME=[4D4EC140:01C96F55] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4804; t=1231174052; x=1232038052; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20*REMINDER*=3A=20dhc=20WG=20la st=20call=20on=20=20draft-ietf-dhc-vpn-option-09.txt |Sender:=20 |To:=20=22Kim=20Kinnear=20Jr.=20(kkinnear)=22=20,=0A=20=20=20=20=20=20=20=20=22David=20W.=20Hankins =22=20,=20=22DHC=20WG=22=20; bh=kjCU+pQ/5CY6U4YilL8Azpra30i4/t4CHidL3Tb9JU8=; b=NWJujoeNyTPSrOkASWXbqEIB/aBJAdXNXR+wKp3v9E7ZGWKPRIZGD0qk9+ b+BJSOVDDc2OB5HOs2AQffZp/akHxzxB8GcNiQSg06oRFlwiQR9OeZz0DYVz bGO5FhCBnB; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I fully agree that ERO should not come into play here. That would be the wrong place for this. I also view this as a "core" DHCPv6 protocol option (such as Server ID, Client ID, IA_NA, ...) and thus agree that there is no need for this to be in the ORO. I do think the document should be clear on this. >Thus, I think that the only thing I'd add to the current draft >would be to say that the appearance of the VSS option in the ORO >or ERO should not change the processing that is otherwise >specified by the draft. I would not mention the ERO option. Note also that if a relay agent were to include this in the ERO option, the ERO processing would likely result in the proper action: - If the server did not include the VPN option, the received option would be echoed. - If the server did include the VPN option, the ERO would do nothing (as the option is already present in the response). - Bernie -----Original Message----- From: Kim Kinnear Jr. (kkinnear) Sent: Monday, January 05, 2009 11:18 AM To: David W. Hankins; DHC WG Cc: Bernie Volz (volz); Kim Kinnear Jr. (kkinnear) Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt David, Bernie, I'd like to try to wrap up this discussion about the use of ERO/ORO for DHCPv6 VSS options. I'm very uneasy with the concept of using the ORO or ERO to specify which entity takes the lead with regard to assigning a VPN to a particular client, as was suggested in the thread below. In addition, the current VSS draft has specific language surrounding the returning of the VSS option: >7.1. Returning the DHCPv4 or DHCPv6 Option > > DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option > processing, see below) MUST return an instance of this option in the > reply packet or message if the server successfully uses this option > to allocate an IP address, and it MUST NOT include an instance of > this option if the server was unable to or not configured to support > the requested VPN. In addition, the server may spontaneously return the VSS option in cases where it is taking the lead on assigning the VPN. My point: the appearance or lack thereof of the VSS option in a reply packet communicates important information well beyond the scope of a "normal" configuration options (e.g., DNS server addresses). In particular, it may communicate information about whether or not the server could satisfy a particular request made by a client. Moreover, this has been specified clearly in the current draft. Thus, I think that the only thing I'd add to the current draft would be to say that the appearance of the VSS option in the ORO or ERO should not change the processing that is otherwise specified by the draft. Can you both agree to that? Thanks -- Kim At 12:52 PM 12/18/2008, David W. Hankins wrote: >On Wed, Dec 17, 2008 at 11:55:26PM -0500, Bernie Volz (volz) wrote: >> I think ORO, if anything, is appropriate. ERO requests the option to be >> echoed back, which is different, as the VPN can change. I don't think >> the complexity of allow either ORO or ERO (and the subtle meaning >> difference) is worth it. >> >> Also, we have both the client and relay agent which could supply the >> option; ERO is only for relays, as clients are stateful and thus there's >> no reason they'd need something they sent in echoed. > >Yes; but the draft describes several different scenarios, some of >which the relay would expect its transmitted value returned, and in >others would expect an assignment by the server. > >> I don't have strong feelings either way. I lean towards considering this >> option a "core" protocol option and thus does not require ORO - if a >> server supports it, it must do processing to do so and hence there's >> really little need to include it in the ORO. > >I don't think processing is required in all of the scenarios the draft >supposes. > >So I'd lean towards putting the option on ORO; older servers with no >support can still mimic sufficient support with manually or scripted >values, but they won't send the value unless it's on ORO. > >This also simplifies DHCPv6 packet creation routines by treating more >options consistently the same. > >-- >Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. >Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ >-- >David W. Hankins "If you don't do it right the first time, >Software Engineer you'll just have to do it again." >Internet Systems Consortium, Inc. -- Jack T. Hankins > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From k.szwalni@aida.net.pl Mon Jan 5 12:11:05 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1311F3A6A12 for ; Mon, 5 Jan 2009 12:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.975 X-Spam-Level: X-Spam-Status: No, score=-7.975 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E9frsXcuLe2 for ; Mon, 5 Jan 2009 12:11:03 -0800 (PST) Received: from 189-31-89-15.ccoce700.dsl.brasiltelecom.net.br (189-31-89-15.ccoce700.dsl.brasiltelecom.net.br [189.31.89.15]) by core3.amsl.com (Postfix) with SMTP id 6079E3A66B4 for ; Mon, 5 Jan 2009 12:11:01 -0800 (PST) To: Subject: RE: Message 51134 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105201102.6079E3A66B4@core3.amsl.com> Date: Mon, 5 Jan 2009 12:11:01 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 83356
From dhcwg-bounces@ietf.org Mon Jan 5 14:10:07 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768853A6A43; Mon, 5 Jan 2009 14:10:07 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372EE3A6A43 for ; Mon, 5 Jan 2009 14:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-6yzuBL4HNS for ; Mon, 5 Jan 2009 14:10:03 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 572D23A68B9 for ; Mon, 5 Jan 2009 14:10:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,334,1228089600"; d="scan'208";a="224187673" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2009 22:09:50 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n05M9oVN029087; Mon, 5 Jan 2009 17:09:50 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n05M9oCA010267; Mon, 5 Jan 2009 22:09:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 17:09:49 -0500 Received: from kkinnear-wxp01.cisco.com ([10.86.250.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 17:09:49 -0500 Message-Id: <4.3.2.7.2.20090105170754.035e03e0@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jan 2009 17:10:12 -0500 To: Kim Kinnear , "David W. Hankins" , DHC WG From: Kim Kinnear In-Reply-To: <4.3.2.7.2.20090105110608.032a7a90@email.cisco.com> References: <20081218175232.GA3310@isc.org> <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> <20081217195129.GA6362@isc.org> <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2009 22:09:49.0521 (UTC) FILETIME=[5390F410:01C96F82] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3977; t=1231193390; x=1232057390; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20*REMINDER*=3A=20dhc=20WG=20la st=20call=20on=0A=20=20draft-ietf-dhc-vpn-option-09.txt |Sender:=20 |To:=20Kim=20Kinnear=20,=0A=20=20=20=20 =20=20=20=20=22David=20W.=20Hankins=22=20,=20DHC=20WG=20; bh=MzMTt9amdGLAX+oDY/pT1UVClAkdjvoWVZNDCqmfN48=; b=Wm5DSnNRNU5sEWlFWYTWDUmwAKRAfDev1uWzLyryCwnLDWC18g7hq30Z0V BzTBFvWpiZ/XBuANalpX+htk0LQB1utDy+NBKGKhMh4Pl9IOFSpG+R4ZJKHe enLj4a1pa0; Authentication-Results: rtp-dkim-1; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: volz@cisco.com Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Folks, I was just reminded of the email on Dec 23 by Alfred Hoenes where he proposes a rather more dramatic solution to this issue. I had missed that email, and will read it in detail and respond to the list concerning that proposal tomorrow. Kim At 11:17 AM 1/5/2009, Kim Kinnear wrote: >David, Bernie, > >I'd like to try to wrap up this discussion about the use of >ERO/ORO for DHCPv6 VSS options. > >I'm very uneasy with the concept of using the ORO or ERO to >specify which entity takes the lead with regard to assigning a >VPN to a particular client, as was suggested in the thread below. > >In addition, the current VSS draft has specific language surrounding >the returning of the VSS option: > >>7.1. Returning the DHCPv4 or DHCPv6 Option >> >> DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option >> processing, see below) MUST return an instance of this option in the >> reply packet or message if the server successfully uses this option >> to allocate an IP address, and it MUST NOT include an instance of >> this option if the server was unable to or not configured to support >> the requested VPN. > >In addition, the server may spontaneously return the VSS option >in cases where it is taking the lead on assigning the VPN. > >My point: the appearance or lack thereof of the VSS option in a >reply packet communicates important information well beyond the >scope of a "normal" configuration options (e.g., DNS server >addresses). In particular, it may communicate information about >whether or not the server could satisfy a particular request made >by a client. Moreover, this has been specified clearly in the >current draft. > >Thus, I think that the only thing I'd add to the current draft >would be to say that the appearance of the VSS option in the ORO >or ERO should not change the processing that is otherwise >specified by the draft. > >Can you both agree to that? > >Thanks -- Kim > > >At 12:52 PM 12/18/2008, David W. Hankins wrote: >>On Wed, Dec 17, 2008 at 11:55:26PM -0500, Bernie Volz (volz) wrote: >>> I think ORO, if anything, is appropriate. ERO requests the option to be >>> echoed back, which is different, as the VPN can change. I don't think >>> the complexity of allow either ORO or ERO (and the subtle meaning >>> difference) is worth it. >>> >>> Also, we have both the client and relay agent which could supply the >>> option; ERO is only for relays, as clients are stateful and thus there's >>> no reason they'd need something they sent in echoed. >> >>Yes; but the draft describes several different scenarios, some of >>which the relay would expect its transmitted value returned, and in >>others would expect an assignment by the server. >> >>> I don't have strong feelings either way. I lean towards considering this >>> option a "core" protocol option and thus does not require ORO - if a >>> server supports it, it must do processing to do so and hence there's >>> really little need to include it in the ORO. >> >>I don't think processing is required in all of the scenarios the draft >>supposes. >> >>So I'd lean towards putting the option on ORO; older servers with no >>support can still mimic sufficient support with manually or scripted >>values, but they won't send the value unless it's on ORO. >> >>This also simplifies DHCPv6 packet creation routines by treating more >>options consistently the same. >> >>-- >>Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. >>Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ >>-- >>David W. Hankins "If you don't do it right the first time, >>Software Engineer you'll just have to do it again." >>Internet Systems Consortium, Inc. -- Jack T. Hankins >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhc@westin.com Mon Jan 5 16:36:02 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F2B3A67D4 for ; Mon, 5 Jan 2009 16:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.226 X-Spam-Level: X-Spam-Status: No, score=-44.226 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_EQ_PL=1.95, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_MULTIPLE_AT=1.449, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_UN7=0.917, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11IIr47mPqmJ for ; Mon, 5 Jan 2009 16:36:01 -0800 (PST) Received: from viagra.com.com (dak39.neoplus.adsl.tpnet.pl [83.23.10.39]) by core3.amsl.com (Postfix) with SMTP id 7BB383A677E for ; Mon, 5 Jan 2009 16:35:59 -0800 (PST) List-Unsubscribe: Message-ID: DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=2008; d=foodnewsletters.com; h=from; b=wNN6nk6fUAGUBAbIUP3lKlCgqk5zVmTQVMeARFqChiuGcWxbK/emIzfSwyaXzzoru5ZTgJOA 0MO07yoDA9ZEHw== From: "0nline Viagra" To: dhcwg-archive@ietf.org Subject: etolq dhcwg-archive@ietf.org; Get Ready for the New Year jrmj Date: Tue, 6 Jan 2009 01:35:34 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Food Network Newsletter
This message contains images. If you don't see images, click here to view.
Food Network
December 30, 2008
Home |
New Year's Open House

HAPPY CHRISTMAS CLICK HERE

Copyright © 2008 Television Food Network, G.P., All Rights Reserved.
© 2008 Scripps Networks Interactive, 9721 Sherrill Blvd., Knoxville, TN 37932
From dhcwg-bounces@ietf.org Mon Jan 5 17:40:15 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0DD3A68F3; Mon, 5 Jan 2009 17:40:15 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800803A68F3 for ; Mon, 5 Jan 2009 17:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3WN1R71LRIe for ; Mon, 5 Jan 2009 17:40:13 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 8F7AE3A63D2 for ; Mon, 5 Jan 2009 17:40:13 -0800 (PST) Received: from david.isc.org (c-67-161-50-42.hsd1.ca.comcast.net [67.161.50.42]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n061dx0E024349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jan 2009 17:40:00 -0800 Received: by david.isc.org (Postfix, from userid 10200) id 9B0FD16E1B3; Mon, 5 Jan 2009 17:39:59 -0800 (PST) Date: Mon, 5 Jan 2009 17:39:59 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20090106013959.GG9517@isc.org> References: <20081218175232.GA3310@isc.org> <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> <20081217195129.GA6362@isc.org> <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> <4.3.2.7.2.20090105170754.035e03e0@email.cisco.com> MIME-Version: 1.0 In-Reply-To: <4.3.2.7.2.20090105170754.035e03e0@email.cisco.com> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1810938606==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1810938606== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E7i4zwmWs5DOuDSH" Content-Disposition: inline --E7i4zwmWs5DOuDSH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 05, 2009 at 05:10:12PM -0500, Kim Kinnear wrote: > I was just reminded of the email on Dec 23 by Alfred Hoenes > where he proposes a rather more dramatic solution to this issue. I haven't taken a close enough look yet. My inclination is that a DHCPv6 relay has no just cause to believe it will receive the option unless it is on a request option of some sort. DHCPv4 relays obviously live in a stranger world. I think in DHCPv4 it's highly unlikely a server would appropriately support these options without some extensive changes in source in other areas; permitting address ranges in different VPN's to overlap as being separate 'DHCP views'. But I suspect that requirement is much more lax in DHCPv6 use cases, so I think it's much more reasonable to expect to see any-old-DHCPv6 server used to assign VPN's, without necessarily needing to be able to see them as overlapping 'views'. I admit I hadn't thought a relay could use the ORO at all, something we might want to address in future versions of our software, but that at least allows an admin to potentially use this option even without explicit support, so this is something our server doesn't even do currently. Certainly, however, in our DHCPv6 server today, we're not going to echo the relay-assigned VPN, if we're being used in a relay-assigns situation, unless it's on the ERO. Point being, it's not a real 'existing software' compatibility issue. It's a more fuzzy future tense. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --E7i4zwmWs5DOuDSH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFJYrZvcXeLeWu2vmoRAn+gAJ9+6m61SniEh1Efk7c3DhBWfi+mlwCffI8P Nlq72U88gl4GEJqQF/CbnEo= =3q79 -----END PGP SIGNATURE----- --E7i4zwmWs5DOuDSH-- --===============1810938606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1810938606==-- From majordomo@alalam-tower.com Tue Jan 6 05:45:16 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400C23A6970 for ; Tue, 6 Jan 2009 05:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.935 X-Spam-Level: X-Spam-Status: No, score=-43.935 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx8UOh0InN7A for ; Tue, 6 Jan 2009 05:45:10 -0800 (PST) Received: from dly183.neoplus.adsl.tpnet.pl (dly183.neoplus.adsl.tpnet.pl [83.24.54.183]) by core3.amsl.com (Postfix) with SMTP id CED2F28C0E6 for ; Tue, 6 Jan 2009 05:45:05 -0800 (PST) To: Subject: RE: Message 44326 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106134506.CED2F28C0E6@core3.amsl.com> Date: Tue, 6 Jan 2009 05:45:05 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 99254
From lem@altel.kz Tue Jan 6 11:50:15 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135883A69B3 for ; Tue, 6 Jan 2009 11:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.12 X-Spam-Level: X-Spam-Status: No, score=-24.12 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y73LK8+AUtCA for ; Tue, 6 Jan 2009 11:50:14 -0800 (PST) Received: from abreu.eti.br (unknown [201.80.250.248]) by core3.amsl.com (Postfix) with SMTP id 5FDFB3A6872 for ; Tue, 6 Jan 2009 11:50:11 -0800 (PST) To: Subject: Your order 79900 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106195013.5FDFB3A6872@core3.amsl.com> Date: Tue, 6 Jan 2009 11:50:11 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 96121
From dhcwg-bounces@ietf.org Tue Jan 6 19:00:50 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F7E3A6943; Tue, 6 Jan 2009 19:00:50 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CD43A6943 for ; Tue, 6 Jan 2009 19:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0KiXI4euddl for ; Tue, 6 Jan 2009 19:00:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 869183A692E for ; Tue, 6 Jan 2009 19:00:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,223,1231113600"; d="scan'208";a="32925143" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2009 03:00:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0730YMA015713; Tue, 6 Jan 2009 22:00:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0730YQt016135; Wed, 7 Jan 2009 03:00:34 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 22:00:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2009 22:00:32 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210A16392B@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <20090106013959.GG9517@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt Thread-Index: Aclvn8SI1Hrt3bo1STCtw2FCSW5HQQA0ghRQ References: <20081218175232.GA3310@isc.org><8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com><20081217195129.GA6362@isc.org><8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com><4.3.2.7.2.20090105170754.035e03e0@email.cisco.com> <20090106013959.GG9517@isc.org> From: "Bernie Volz (volz)" To: "David W. Hankins" , "DHC WG" X-OriginalArrivalTime: 07 Jan 2009 03:00:33.0998 (UTC) FILETIME=[1BB2A6E0:01C97074] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3262; t=1231297234; x=1232161234; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20*REMINDER*=3A=20dhc=20WG=20la st=20callon=09draft-ietf-dhc-vpn-option-09.txt |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20 ,=20=22DHC=20WG=22=20; bh=3OqkAs3PQ6NSAbKNGpeiWIfBVConN09QbP+dWulY9vw=; b=HsiK6fcH6FXy9t7GtpS3+28N+ZRAeG/IncQQxfGQauyEeN3XSZkJoLk93W IQ0aDlMgXBqHWISzy6R7YLLTg1FPLs5QSGXZpuTbOYsnjkxn47zvlB19AZIG k4kUD2B5VW; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org David: If the DHCPv6 server doesn't process (support/understand) the option, it should NOT return it. At least, to me that's the implication of the text in 7.2 with respect to DHCPv4 where the relay agent's data is echoed and hence a DHCPv4 relay can't tell whether the data was echoed or actually used. 7.1. Returning the DHCPv4 or DHCPv6 Option DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option processing, see below) MUST return an instance of this option in the reply packet or message if the server successfully uses this option -> to allocate an IP address, and it MUST NOT include an instance of -> this option if the server was unable to or not configured to support -> the requested VPN. Perhaps we need to extend this to include does not support the option. A DHCPv6 server that doesn't support/understand the option will just do what it does today. The Client or Relay Agent can know this because it won't get the option back in the Reply. If ERO was used, the Relay Agent couldn't tell this. The ORO is also kind of useless because this isn't a "other configuration" data item, but a core protocol issue. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of David W. Hankins Sent: Monday, January 05, 2009 8:40 PM To: DHC WG Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt On Mon, Jan 05, 2009 at 05:10:12PM -0500, Kim Kinnear wrote: > I was just reminded of the email on Dec 23 by Alfred Hoenes > where he proposes a rather more dramatic solution to this issue. I haven't taken a close enough look yet. My inclination is that a DHCPv6 relay has no just cause to believe it will receive the option unless it is on a request option of some sort. DHCPv4 relays obviously live in a stranger world. I think in DHCPv4 it's highly unlikely a server would appropriately support these options without some extensive changes in source in other areas; permitting address ranges in different VPN's to overlap as being separate 'DHCP views'. But I suspect that requirement is much more lax in DHCPv6 use cases, so I think it's much more reasonable to expect to see any-old-DHCPv6 server used to assign VPN's, without necessarily needing to be able to see them as overlapping 'views'. I admit I hadn't thought a relay could use the ORO at all, something we might want to address in future versions of our software, but that at least allows an admin to potentially use this option even without explicit support, so this is something our server doesn't even do currently. Certainly, however, in our DHCPv6 server today, we're not going to echo the relay-assigned VPN, if we're being used in a relay-assigns situation, unless it's on the ERO. Point being, it's not a real 'existing software' compatibility issue. It's a more fuzzy future tense. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 7 08:06:24 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9233A6A3C; Wed, 7 Jan 2009 08:06:23 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB933A677D for ; Sat, 3 Jan 2009 00:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.644 X-Spam-Level: * X-Spam-Status: No, score=1.644 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqgrlm1FdcBU for ; Sat, 3 Jan 2009 00:19:13 -0800 (PST) Received: from web30405.mail.mud.yahoo.com (web30405.mail.mud.yahoo.com [68.142.200.108]) by core3.amsl.com (Postfix) with SMTP id 2C6B33A68B8 for ; Sat, 3 Jan 2009 00:19:13 -0800 (PST) Received: (qmail 55973 invoked by uid 60001); 3 Jan 2009 08:19:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=2yipjeVMkzkZEFDLqjBlOUQyRcl+ky5ssDDEQXgA1hBXgqqqoO8P3x/zZAMOjrzciUYRxU8nzCOExAx/3VYI9BqeRDPNkUoc/S+hrr4tG8XosphcmP3r7zp4k3svfEJbR0LvMPwD/oOqu/KSqFVGR+VG1obYbyeiN3SFN+k6XhU=; X-YMail-OSG: YTaMnkAVM1mwT5nnKqvp1VPCfVNP54A3jFmxTSSHh85XHXvFSnoltEod1gQJj.dA8j_cX9zF5cefFQGC2ZuxdpIY3TFXERZl4kIA.tSYG7TuOGonIHjwg91pTA_BNan2wVw5gbRJEXN1oDtmvkUF5_mdVxQb2FrSFUhVKBU8Rz0ZWG6OCXsMPqGSk7v3yMq5l.u2xmF1NNqt4n3MZZuof6RvjpnGXUV852HCxytHwHQ- Received: from [59.161.0.223] by web30405.mail.mud.yahoo.com via HTTP; Sat, 03 Jan 2009 00:19:00 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Sat, 3 Jan 2009 00:19:00 -0800 (PST) From: Sangita Rajankar To: dhcwg@ietf.org MIME-Version: 1.0 Message-ID: <509685.55915.qm@web30405.mail.mud.yahoo.com> X-Mailman-Approved-At: Wed, 07 Jan 2009 08:06:23 -0800 Subject: [dhcwg] jdhcp coding X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: san_prash@yahoo.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I'm trying to complete DHCP client using JDHCP . i am not able to bind the physical address with the yiaddress(your ip address) that can be set by the client. Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 7 09:24:38 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA3E28C119; Wed, 7 Jan 2009 09:24:38 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F4D28C125 for ; Wed, 7 Jan 2009 09:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUChpZMh265b for ; Wed, 7 Jan 2009 09:24:36 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id A097E28C0F4 for ; Wed, 7 Jan 2009 09:24:36 -0800 (PST) Received: from david.isc.org (c-67-161-50-42.hsd1.ca.comcast.net [67.161.50.42]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n07HOMuj029489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Jan 2009 09:24:23 -0800 Received: by david.isc.org (Postfix, from userid 10200) id C6A2016E1B3; Wed, 7 Jan 2009 09:24:21 -0800 (PST) Date: Wed, 7 Jan 2009 09:24:21 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20090107172421.GB5330@isc.org> References: <20090106013959.GG9517@isc.org> <8E296595B6471A4689555D5D725EBB210A16392B@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB210A16392B@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1470485323==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1470485323== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 06, 2009 at 10:00:32PM -0500, Bernie Volz (volz) wrote: > DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option > processing, see below) MUST return an instance of this option in the > reply packet or message if the server successfully uses this option > -> to allocate an IP address, and it MUST NOT include an instance of > -> this option if the server was unable to or not configured to support > -> the requested VPN. Hmm, I think you're right. The relay does need a positive indication that the server is on the same page, otherwise you run the risk of putting the client in an inappropriate VLAN, potentially a security issue. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD4DBQFJZOVFcXeLeWu2vmoRAo1ZAJQMj+LP8ttmvK3TXiFHwGhydawTAJ9P0ogx E48mlO5fXqHOG5lvm6G58g== =lJH3 -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- --===============1470485323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1470485323==-- From dhcwg-bounces@ietf.org Wed Jan 7 18:08:34 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66653A69A9; Wed, 7 Jan 2009 18:08:34 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795133A69A9 for ; Wed, 7 Jan 2009 18:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9LR-ITCvrXn for ; Wed, 7 Jan 2009 18:08:32 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BA6903A6924 for ; Wed, 7 Jan 2009 18:08:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,230,1231113600"; d="scan'208";a="33121146" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Jan 2009 02:08:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0828D0B027778; Wed, 7 Jan 2009 21:08:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0828D2T003424; Thu, 8 Jan 2009 02:08:13 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 21:08:13 -0500 Received: from kkinnear-wxp01.cisco.com ([10.86.243.191]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 21:08:12 -0500 Message-Id: <4.3.2.7.2.20090107132315.0361da68@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jan 2009 21:08:33 -0500 To: Alfred =?hp-roman8?B?SM5uZXM=?= , raj@cisco.com, mjs@cisco.com, jayk@cisco.com From: Kim Kinnear In-Reply-To: <200812232102.WAA15459@TR-Sys.de> Mime-Version: 1.0 X-OriginalArrivalTime: 08 Jan 2009 02:08:12.0743 (UTC) FILETIME=[F5C6ED70:01C97135] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8258; t=1231380493; x=1232244493; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-vpn-option-09= 20issue=20with=20sub-option=0A=20=20bouncing |Sender:=20 |To:=20Alfred=20=3D?hp-roman8?B?SM5uZXM=3D?=3D=20,=20raj@cisco.com,=0A=20=20=20=20=20=20=20=20mjs@cisco.c om,=20jayk@cisco.com; bh=/Z41cnqsDhh6esNRNzQncNmh5+Z/+Pd63pnIJIbuDbM=; b=zIRcPYD3s3cswSiQLs1lvJ5IPztyL4fRpWq0J0kDH7CMBtE3UtSV2yV6NC inAUrEefzeXF9anXkRgXCgzuijYtCyafa/FCN3N2xsMlrYoIAqLNMYkmS+OJ MhUkOysNCT; Authentication-Results: rtp-dkim-2; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhcwg@ietf.org, kkinnear@cisco.com Subject: Re: [dhcwg] draft-ietf-dhc-vpn-option-09 issue with sub-option bouncing X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 04:02 PM 12/23/2008, Alfred =3D?hp-roman8?B?SM5uZXM=3D?=3D wrote: >I have reviewed draft-ietf-dhc-vpn-option-09 and already sent >off-list a couple of editorial notes. Yes, thank you for those. When I next revise the draft, I'll include these editorial changes. >However, I see one significant issue not satisfactorily resolved >in the current draft version. >Below, I recall the problem and propose a mechanism to mitigate it. > >As explained in various places in the draft (in particular >Section 7.2), in the DHPCv4 case the utility of the VSS sub-option >suffers from the default behavior of the server (per RFC 3046) of >blindly bouncing unknown sub-options of the Realy-Agent-Information >option. This way, the DHCP relay originally sending the sub-option >in the request can not conclude from the sub-option in the reply >whether the server has not understood the VSS sub-option and simply >bounced it or it has understood the VSS sub-option and confirmed >the value sent in the request by echoing the unchanged VSS sub- >option. > >That seems to be a significant drawback. Yes and no. The case that is hard to distinguish is the case where the DHCP server doesn't support the VSS option but the relay agent expects that it does. As stated in the draft: > The current use of the VSS option and sub-option require that each > entity knows the part that it plays in dealing with VPN data. Each > entity -- client, relay agent or agents, and server -- SHOULD know > through some policy or configuration beyond the scope of this > document whether it is responsible for specifying VPN information > using the VSS option or sub-option or responsible for responding to > VSS information specified by another entity, or simply ignoring any > VSS information which it might see. Perhaps we could extend this to include a statement that not only SHOULD the entities know their respective roles regarding the VSS option/information, but that they SHOULD also be capable of supporting the processing required by the role they are playing. I'd be up for that, though I think it is kind of implied. The case that for which you have proposed a solution is one where the DHCP server doesn't understand the VSS option and therefore doesn't process it at all. This is a total configuration screwup, not something that can happen on one packet and not happen on the next packet. This will never work. So, "yes", it is a drawback that the relay agent can't tell if the server supports VSS processing from the contents of one packet. But it is important to understand that the entire processing of these options/sub-options requires configuration correspondence well outside of the bounds of what is documented in this draft (and the draft make that point more than once). Having a DHCP server that supports the VSS option installed if you are going to configure your relay agents to support VSS processing is just one more part of the configuration correspondence that is required, and not the largest part by any means. My point is that I believe the particular issue which you have focused looks like it is significant if you look just at this one issue, but if you stand back a bit I think that it isn't actually an operational problem of significance given the other things you have to get right to put together a working system which incorporates VSS option processing. Another way to put this is to say that solving this one problem will make it only fractionally easier in the field to configure these systems. So, personally, I believe that the draft is acceptable as it stands. Although I'd gladly add words about this issue and the requirement to have a DHCP server that supports VSS option processing if you are going to configure such processing on your relay agents. This would be easy, but not what you are advocating. That said, what you have proposed below would indeed solve this problem. I feel it is a relatively large amount of mechanism given the scope of the problem it is designed to solve. However, it would work and could be included into the draft if there is a general consensus that this is the right approach. I'll be looking for input from other folks to see if we have that general consensus for the changes that you have proposed. A number of other folks have found the draft to be acceptable as-is, and indeed this particular problem was brought up by David Hankins in the past and the solution that is embodied in the draft at this point satisfied his previous objections. Not least, this draft has been through last call after last call, and if we make this change we may need to go through yet another last call. This prospect leaves me less than thrilled, as I'm sure you can understand, but getting it right (or at least right enough) is certainly more important. Thanks for reading the draft. Regards -- Kim >After some consideration of the problem, it becomes apparent that >it depends on the VSS type whether or not this is a real issue. >In the "global/default VPN" case (VSS type 255), it looks like >the realy agent would not gain anything from being able to >distinguish the two cases; that apparently only matters for the >VSS types 0 and 1 (or any possible future 'concrete' values). > >This has guided me to envision modified encoding and processing >rules of the VSS type -- see below. > >Due to lack of time, I have not tried to discover if this idea >already has been considered in the past. If so, and it has been >rejected, I apologize for bringing it up again. > >a) Encoding: > > VSS types 127..254 are permanently forbidden for VSS information > in the DHVPv4/v6 VSS options and the v4 VSS sub-option in a > message to the server. > > For the VSS sub-option in a response, the following additional > values are defined: > > 128 same as 0, but "confirmed by server" > 129 same as 1, but "confirmed by server" > >b) Server Processing > >A DHCPv4 server that understands the VSS sub-option (and supports >this advanced encoding) sets the MSB in the VSS type when it copies >the sub-option to the response "unchanged" per the current draft. >Note that this is an idempotent operation on the 'global' VSS type >value, leaving it unchanged for improved interoperability with >existing implementations. > >TBD: It needs to be figured out whether it might be preferable > (yet less backwards compatible) to also set the MSB when the > server *changes* the VS type in the VSS sub-option to be sent > back to one of the 'concrete' values (currently 0 or 1). > >Note: This revised server behavior SHOULD be subject to activation > per configuration, with defaults to 'off'. > >c) Relay Agent Processing > >A DHCPv4 Relay Agent receiving one of the new VSS types in the >VSS sub-option strips the MSB of the VSS type and performs the >processing currently described in the draft, but it also notes that >the server has confirmed the (proposed) value it had sent in the >request, and can hence exclude all considerations and cautionary >processing related to lack of distinction between the two cases. > > >Kind regards, > Alfred H=CEnes. > >-- = > >+------------------------ +--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: = >-18 | >| D-71254 Ditzingen | E-Mail: ah@TR- Sys.de | >+------------------------ +--------------------------------------------+ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 8 08:01:14 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C95F3A6A88; Thu, 8 Jan 2009 08:01:14 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154B43A67A7 for ; Wed, 7 Jan 2009 23:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN3AkxRIQnMH for ; Wed, 7 Jan 2009 23:40:55 -0800 (PST) Received: from mail-bw0-f25.google.com (mail-bw0-f25.google.com [209.85.218.25]) by core3.amsl.com (Postfix) with ESMTP id E57373A6837 for ; Wed, 7 Jan 2009 23:40:54 -0800 (PST) Received: by bwz6 with SMTP id 6so6771341bwz.16 for ; Wed, 07 Jan 2009 23:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=HQxnIJswW5urfKuyEGfelVfSBpGh0wSIcQ7wob7BrYg=; b=ejpVoLQL1ilcX7BbGmy57/iQCTyUMk/TUDzXWfb6fahNvsTU2imxmUp/9xMumkPj3c hoL2zRUGPJUmwrZcWbSlQdGchjIbRHp9rD17woAvNlYZxVJqAE52RUv+Bh/d/h4ZkiyS OjUMCyBL9k1hEQbOX0Fh5BaYY5isJo1MdvzOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=XVHsTsPh4z2BRtyoBrko1Bsd3lg4DzjlDnnyGYOiHOyUVtpfJOfHz1RqaphpP03LiE QlciP3tnPTzsuDZdL2vxgRMqGWhVh46PQOyObkXvFZ/mXd/T7a3iA8a+J0YpUjd11s5R /+Ib8A04GU4xOX72QJ21WBBIvipQzzCE5eXQw= Received: by 10.181.55.2 with SMTP id h2mr9231314bkk.52.1231400440198; Wed, 07 Jan 2009 23:40:40 -0800 (PST) Received: by 10.181.204.13 with HTTP; Wed, 7 Jan 2009 23:40:40 -0800 (PST) Message-ID: <2853c5340901072340y60b6c0dcra878d9b576e64cd1@mail.gmail.com> Date: Thu, 8 Jan 2009 13:10:40 +0530 From: "Sangita Rajankar" To: dhcwg@core3.amsl.com MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Jan 2009 08:01:13 -0800 Subject: [dhcwg] query for JDHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1196097411==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1196097411== Content-Type: multipart/alternative; boundary="----=_Part_14710_15719924.1231400440192" ------=_Part_14710_15719924.1231400440192 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm trying to complete DHCP client using JDHCP . i am not able to bind the physical address with the yiaddress(your ip address) that can be set by the client. i am trying to use the *setYiaddr* (byte[] inYiaddr) method to to Set 'your' (client) IP address, but it's not working. Cna any body suggest solution for this ? sangita rajankar ------=_Part_14710_15719924.1231400440192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I'm trying to complete DHCP client using JDHCP . i am not able to bind the physical address with the yiaddress(your ip address) that can be set by the client.   i am trying to use the
setYiaddr(byte[] inYiaddr) method to to Set 'your' (client) IP address, but it's not working. Cna any body suggest solution for this ?
 
sangita rajankar

------=_Part_14710_15719924.1231400440192-- --===============1196097411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1196097411==-- From jorge93@aandco.com Sat Jan 10 05:53:10 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E353A67DA for ; Sat, 10 Jan 2009 05:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.072 X-Spam-Level: X-Spam-Status: No, score=-29.072 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAVrk7M5YrON for ; Sat, 10 Jan 2009 05:53:09 -0800 (PST) Received: from adsl-46-106-192-81.adsl2.iam.net.ma (adsl-46-106-192-81.adsl2.iam.net.ma [81.192.106.46]) by core3.amsl.com (Postfix) with SMTP id C84AC3A67D7 for ; Sat, 10 Jan 2009 05:53:05 -0800 (PST) To: Subject: RE: Message 89668 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110135306.C84AC3A67D7@core3.amsl.com> Date: Sat, 10 Jan 2009 05:53:05 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 15345
From jewnastb@anacnv.com Sun Jan 11 04:07:30 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13133A699A for ; Sun, 11 Jan 2009 04:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8MJXfWxWlNp for ; Sun, 11 Jan 2009 04:07:30 -0800 (PST) Received: from cpc1-walt3-0-0-cust359.popl.cable.ntl.com (cpc1-walt3-0-0-cust359.popl.cable.ntl.com [82.10.205.104]) by core3.amsl.com (Postfix) with SMTP id 420833A680B for ; Sun, 11 Jan 2009 04:07:23 -0800 (PST) To: Subject: Re: Order status 40907 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090111120725.420833A680B@core3.amsl.com> Date: Sun, 11 Jan 2009 04:07:23 -0800 (PST)

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 95875
From nuezxqb@alfyinc2.b.tep1.com Sun Jan 11 05:50:01 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376D13A6A00 for ; Sun, 11 Jan 2009 05:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.673 X-Spam-Level: X-Spam-Status: No, score=-24.673 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16jsbqCI7MAu for ; Sun, 11 Jan 2009 05:50:00 -0800 (PST) Received: from 173-16-207-228.client.mchsi.com (173-16-207-228.client.mchsi.com [173.16.207.228]) by core3.amsl.com (Postfix) with SMTP id C26FB3A69FE for ; Sun, 11 Jan 2009 05:49:59 -0800 (PST) To: Subject: Your order 78888 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090111134959.C26FB3A69FE@core3.amsl.com> Date: Sun, 11 Jan 2009 05:49:59 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 07488
From littlemksb@amnetmortgage.com Mon Jan 12 01:27:46 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06B63A67D8 for ; Mon, 12 Jan 2009 01:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.129 X-Spam-Level: X-Spam-Status: No, score=-7.129 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkDO4BAC+j8j for ; Mon, 12 Jan 2009 01:27:46 -0800 (PST) Received: from algorithmics.com (unknown [125.22.105.85]) by core3.amsl.com (Postfix) with SMTP id 565C73A6407 for ; Mon, 12 Jan 2009 01:27:43 -0800 (PST) To: Subject: Re: Order status 24736 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112092744.565C73A6407@core3.amsl.com> Date: Mon, 12 Jan 2009 01:27:43 -0800 (PST)

Health Monthly

Drug Factsheets | Condition Factsheets | Ask an Expert | Community Support

Go to Site Now!

© 1996 - 2009 MeDResource Inc. - MeDResource reaches millions of Canadians each month.

From kaya@agcomm.com Mon Jan 12 04:20:49 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C8928C120 for ; Mon, 12 Jan 2009 04:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.339 X-Spam-Level: X-Spam-Status: No, score=-47.339 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOZcNjuLci-1 for ; Mon, 12 Jan 2009 04:20:48 -0800 (PST) Received: from accurohealth.com (unknown [125.164.114.26]) by core3.amsl.com (Postfix) with SMTP id F22CE3A6A17 for ; Mon, 12 Jan 2009 04:20:40 -0800 (PST) To: Subject: RE: mail 18062 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112122040.F22CE3A6A17@core3.amsl.com> Date: Mon, 12 Jan 2009 04:20:40 -0800 (PST)
Microsoft respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive promotional offers or research emails from MSN or Windows Live, please click to "unsubscribe" or reply to this message with "UNSUBSCRIBE" in the subject line. To set your contact preferences for other Microsoft communications, see the communications preferences section of the Privacy Statement.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation One Microsoft Way Redmond, WA 33584
From kharshman@adbhomes.com Tue Jan 13 06:18:39 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D71E3A67DA for ; Tue, 13 Jan 2009 06:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+TQMQOGDGyI for ; Tue, 13 Jan 2009 06:18:38 -0800 (PST) Received: from 74-210-241-121.ri.cgocable.ca (74-210-241-121.ri.cgocable.ca [74.210.241.121]) by core3.amsl.com (Postfix) with SMTP id 6ABC13A6943 for ; Tue, 13 Jan 2009 06:18:37 -0800 (PST) To: Subject: Up to 20% cashback on every purchase? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113141837.6ABC13A6943@core3.amsl.com> Date: Tue, 13 Jan 2009 06:18:37 -0800 (PST)
Microsoft respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive promotional offers or research emails from MSN or Windows Live, please click to "unsubscribe" or reply to this message with "UNSUBSCRIBE" in the subject line. To set your contact preferences for other Microsoft communications, see the communications preferences section of the Privacy Statement.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation One Microsoft Way Redmond, WA 75615
From dhcwg-bounces@ietf.org Tue Jan 13 12:33:34 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759F028C145; Tue, 13 Jan 2009 12:33:34 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1522128C146 for ; Tue, 13 Jan 2009 12:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GQDeWBbDbk4 for ; Tue, 13 Jan 2009 12:33:32 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 27AE628C145 for ; Tue, 13 Jan 2009 12:33:32 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 1E36B19871D; Tue, 13 Jan 2009 22:33:17 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 6A632198714; Tue, 13 Jan 2009 22:33:16 +0200 (EET) Message-ID: <496CFA55.8020904@piuha.net> Date: Tue, 13 Jan 2009 22:32:21 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Subir Das , "David W. Hankins" References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> In-Reply-To: <49519EC3.3060007@research.telcordia.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , Dhc Chairs , Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The new version of this draft addressed the issues that I found in my AD review. However, I'd like to have positive confirmation from the DHC WG that they are fine with the syntax. I can see that the bit pattern mechanism was simplified, but "enc" still remains, and I think David complained about that in particular. If existing DHCP server software cannot deal with a conditional encoding of attributes, I'd recommend simplifying further. You do NOT want to upgrade client and server code just to transport one additional piece of config data. Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 13 13:18:35 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4FC3A6B23; Tue, 13 Jan 2009 13:18:35 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7504A3A6B23 for ; Tue, 13 Jan 2009 13:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QojHbxlxLcK9 for ; Tue, 13 Jan 2009 13:18:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 546913A67DF for ; Tue, 13 Jan 2009 13:18:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,261,1231113600"; d="scan'208";a="33651193" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2009 21:18:17 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0DLIHRZ025429; Tue, 13 Jan 2009 16:18:17 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0DLIHwT005393; Tue, 13 Jan 2009 21:18:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jan 2009 16:18:17 -0500 Received: from [161.44.113.171] ([161.44.113.171]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jan 2009 16:18:16 -0500 Message-ID: <496D0518.1060307@cisco.com> Date: Tue, 13 Jan 2009 16:18:16 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: dhcwg References: <20081221091940.72D263A680D@core3.amsl.com> In-Reply-To: <20081221091940.72D263A680D@core3.amsl.com> X-OriginalArrivalTime: 13 Jan 2009 21:18:16.0680 (UTC) FILETIME=[7364DE80:01C975C4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=430; t=1231881497; x=1232745497; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20ID=20Tracker=20State=20Update=20Notice= 3A=20draft-ietf-dhc-dhcpv6-bulk-leasequery |Sender:=20 |To:=20dhcwg=20; bh=//FZcytf2RiMvsEq2h2ymqTR5xbciF/OroW75eR9tr4=; b=dOIS2SwHV7TvzWJsdMCPZb4s37ND1BFgNfrgepVJaH5J69u77/2AmcU9In Syfsn2TJedxuBmAP51IGNiPw4ylTJ/98N+VRRRdV7DbmhImGfAY+pHAN6p2p wKFpm091M0; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [dhcwg] ID Tracker State Update Notice: draft-ietf-dhc-dhcpv6-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I've submitted a new revision to try to address the issues raised about the text about the TCP connection management. The notification should pop out ... any time. Thanks, Mark The IESG wrote: > 'State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko' > ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16934&rfc_flag=0 > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 13 13:30:03 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD76C3A6B3B; Tue, 13 Jan 2009 13:30:03 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A67CA3A6B33; Tue, 13 Jan 2009 13:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090113213001.A67CA3A6B33@core3.amsl.com> Date: Tue, 13 Jan 2009 13:30:01 -0800 (PST) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv6 Bulk Leasequery Author(s) : M. Stapp Filename : draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt Pages : 18 Date : 2009-01-13 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-13131517.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Jan 13 13:41:12 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93F028C199; Tue, 13 Jan 2009 13:41:12 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D16828C178; Tue, 13 Jan 2009 13:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=1.933, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQJYL8Cq60A6; Tue, 13 Jan 2009 13:41:04 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5AE6A28C190; Tue, 13 Jan 2009 13:41:04 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDF00BFGIVXOQ@szxga04-in.huawei.com>; Wed, 14 Jan 2009 05:40:45 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDF0067IIVXR9@szxga04-in.huawei.com>; Wed, 14 Jan 2009 05:40:45 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [212.147.29.179]) by szxmc04-in.huawei.com (mshttpd); Wed, 14 Jan 2009 05:40:45 +0800 Date: Wed, 14 Jan 2009 05:40:45 +0800 From: JiangSheng 66104 To: cga-ext@ietf.org, dhcwg@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal Subject: [dhcwg] Update verion draft-jiang-csi-dhcpv6-cga-ps-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org According to the IETF73 discussion, the authors have modified the draft. Since early collaboration is requested for this CGA and DHCP interaction work, this update message is sent to both CSI WG and DHC WG. Best regards, Sheng A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCPv6 and CGA Interaction: Problem Statement Author(s) : S. Jiang, S. Shen Filename : draft-jiang-csi-dhcpv6-cga-ps-01.txt Pages : 8 Date : 2009-1-12 This document presents a problem statement for the possible interactions between DHCPv6 and CGA. Firstly, in order to support the co-existing scenarios of DHCPv6 and CGA, Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. Then, some extended scenarios are also discussed in this document, including using CGAs in DHCPv6 operations to enhance the security features and using DHCPv6 to serve the CGA generation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jiang-csi-dhcpv6-cga-ps-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 13 13:43:16 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F34F28C1A5; Tue, 13 Jan 2009 13:43:16 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55C828C178; Tue, 13 Jan 2009 13:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.43 X-Spam-Level: X-Spam-Status: No, score=-0.43 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muVxe7-agwYw; Tue, 13 Jan 2009 13:43:08 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 14BCD28C190; Tue, 13 Jan 2009 13:43:08 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDF0095DIZ6R2@szxga03-in.huawei.com>; Wed, 14 Jan 2009 05:42:43 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDF00BSUIZ6OE@szxga03-in.huawei.com>; Wed, 14 Jan 2009 05:42:42 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [212.147.29.179]) by szxmc04-in.huawei.com (mshttpd); Wed, 14 Jan 2009 05:42:42 +0800 Date: Wed, 14 Jan 2009 05:42:42 +0800 From: JiangSheng 66104 To: cga-ext@ietf.org, dhcwg@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal Subject: [dhcwg] =?windows-1252?q?_=93Secure_DHCPv6_Using_CGAs=94_draft-ji?= =?windows-1252?q?ang-dhc-secure-dhcpv6-01?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The below =93Secure DHCPv6 Using CGAs=94 has been updated, according to com= ments that have been discussed in dhc maillist and IETF meeting. Since earl= y collaboration is requested for this CGA and DHCP interaction work, this u= pdate message is sent to both CSI WG and DHC WG. Best regards, Sheng A New Internet-Draft is available from the on-line Internet-Drafts = directories. = Title : Secure DHCPv6 Using CGAs = Author(s) : S. Jiang, S. Shen = Filename : draft-jiang-dhc-secure-dhcpv6-01.txt = Pages : 14 = Date : 2009-1-8 = = The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables = DHCP servers to pass configuration parameters. It offers = configuration flexibility. If not secured, DHCPv6 is vulnerable to = various attacks, particularly fake attack. This document analyzes the = security issues of DHCPv6 and specifies security mechanisms, mainly = using CGAs. = A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 14 10:00:02 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB193A682C; Wed, 14 Jan 2009 10:00:02 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B72F33A682C; Wed, 14 Jan 2009 10:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090114180001.B72F33A682C@core3.amsl.com> Date: Wed, 14 Jan 2009 10:00:01 -0800 (PST) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-by-remote-id-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 Leasequery by relay agent remote ID Author(s) : P. Kurapati, D. Rao, B. Joshi Filename : draft-ietf-dhc-leasequery-by-remote-id-01.txt Pages : 27 Date : 2009-1-14 Some Relay Agents extract lease information from the DHCP message exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing, prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost. Existing leasequery mechanism is data driven which means that a relay agent can initiate the leasequery only when it starts receiving data from/to the clients. In certain scenarios, this model is not scalable. This document first looks at issues in existing mechanism and then proposes a new query type, query by remote ID, to address these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-by-remote-id-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dhc-leasequery-by-remote-id-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-1-14095900.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Jan 14 10:15:02 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373203A69C2; Wed, 14 Jan 2009 10:15:02 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8D4353A69C2; Wed, 14 Jan 2009 10:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090114181501.8D4353A69C2@core3.amsl.com> Date: Wed, 14 Jan 2009 10:15:01 -0800 (PST) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-l2ra-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Layer 2 Relay Agent Information Author(s) : B. Joshi, P. Kurapati Filename : draft-ietf-dhc-l2ra-03.txt Pages : 18 Date : 2009-1-14 In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append a Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where a Layer 2 Relay Agent is in use and also how it handles DHCP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dhc-l2ra-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-1-14100134.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --NextPart-- From jerald323@adwani.net Wed Jan 14 13:40:47 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E941F28C1E6 for ; Wed, 14 Jan 2009 13:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.839 X-Spam-Level: X-Spam-Status: No, score=-11.839 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xATkS7fg-UMK for ; Wed, 14 Jan 2009 13:40:47 -0800 (PST) Received: from alkhorayef.com (unknown [201.53.131.167]) by core3.amsl.com (Postfix) with SMTP id 4F1D028C1C4 for ; Wed, 14 Jan 2009 13:40:45 -0800 (PST) To: Subject: RE: Message 42219 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114214046.4F1D028C1C4@core3.amsl.com> Date: Wed, 14 Jan 2009 13:40:45 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 28415
From dhcwg-bounces@ietf.org Wed Jan 14 19:53:22 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBB73A6AC1; Wed, 14 Jan 2009 19:53:22 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6621C3A6AC1 for ; Wed, 14 Jan 2009 19:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACc-9YoFrBu5 for ; Wed, 14 Jan 2009 19:53:20 -0800 (PST) Received: from kecgate06.infosys.com (kecgate06.infosys.com [61.95.162.82]) by core3.amsl.com (Postfix) with ESMTP id E63B53A6ABB for ; Wed, 14 Jan 2009 19:53:19 -0800 (PST) X-TM-IMSS-Message-ID: <31d60ce90006b5a6@kecgate06.infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by kecgate06.infosys.com ([61.95.162.82]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 31d60ce90006b5a6 ; Thu, 15 Jan 2009 09:23:12 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Thu, 15 Jan 2009 09:22:55 +0530 From: Bharat Joshi To: "dhcwg@ietf.org" Date: Thu, 15 Jan 2009 09:22:37 +0530 Thread-Topic: New revision of Layer 2 Relay Agent Information draft Thread-Index: AQHJdsS+pW9vyDtz9Uy+JKNTx5phIg== Message-ID: <31D55C4D55BEED48A4459EB64567589A0CD8909599@BLRKECMBX02.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [dhcwg] New revision of Layer 2 Relay Agent Information draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi All, We have submitted a new revision of Layer 2 Relay Agent Information draft with changes suggested by Alfred Hoenes and Boilerplate changes. Please review the same and let us know your comments. Draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-03.txt Regards, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 14 19:54:47 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B0B28C1CC; Wed, 14 Jan 2009 19:54:47 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D619728C1CC for ; Wed, 14 Jan 2009 19:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7WVflJDjX92 for ; Wed, 14 Jan 2009 19:54:45 -0800 (PST) Received: from kecgate06.infosys.com (kecgate06.infosysconsulting.com [61.95.162.82]) by core3.amsl.com (Postfix) with ESMTP id 60A8E28C1B1 for ; Wed, 14 Jan 2009 19:54:44 -0800 (PST) X-TM-IMSS-Message-ID: <31d774970006b5f5@kecgate06.infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by kecgate06.infosys.com ([61.95.162.82]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 31d774970006b5f5 ; Thu, 15 Jan 2009 09:24:44 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Thu, 15 Jan 2009 09:24:27 +0530 From: Bharat Joshi To: "dhcwg@ietf.org" Date: Thu, 15 Jan 2009 09:24:26 +0530 Thread-Topic: New revision of Lease query by remote-id Thread-Index: AQHJdsT1uhQIBfgiKkOsXTiXOSj4DA== Message-ID: <31D55C4D55BEED48A4459EB64567589A0CD890959A@BLRKECMBX02.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [dhcwg] New revision of Lease query by remote-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi All, We have submitted a new revision of 'lease query by remote-id' draft. This revision takes care of comments from Kim. We have also updated the boilerplate text. Please review the same and let us know your comments. Draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-by-remote-id-01.txt Thanks, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ncraig@3vb.com Thu Jan 15 04:22:31 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF5A28C101 for ; Thu, 15 Jan 2009 04:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l7BcSffdH4h for ; Thu, 15 Jan 2009 04:22:24 -0800 (PST) Received: from 167.85-86-240.dynamic.clientes.euskaltel.es (167.85-86-240.dynamic.clientes.euskaltel.es [85.86.240.167]) by core3.amsl.com (Postfix) with SMTP id 4F70028C10B for ; Thu, 15 Jan 2009 04:22:19 -0800 (PST) To: Subject: RE: Message 54039 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115122221.4F70028C10B@core3.amsl.com> Date: Thu, 15 Jan 2009 04:22:19 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 90244
From juk@aeat-qsa.com Thu Jan 15 07:17:57 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FB63A69E0 for ; Thu, 15 Jan 2009 07:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+ts4gDOU6tZ for ; Thu, 15 Jan 2009 07:17:51 -0800 (PST) Received: from 78-134-3-157.static.ngi.it (78-134-3-157.static.ngi.it [78.134.3.157]) by core3.amsl.com (Postfix) with SMTP id 4663D28C25D for ; Thu, 15 Jan 2009 07:17:49 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115151750.4663D28C25D@core3.amsl.com> Date: Thu, 15 Jan 2009 07:17:49 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 01433
From dhcwg-bounces@ietf.org Thu Jan 15 15:52:19 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2073A3A6946; Thu, 15 Jan 2009 15:52:19 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8AC3A68D0 for ; Thu, 15 Jan 2009 15:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpsD5BEpGeo2 for ; Thu, 15 Jan 2009 15:52:16 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 8EDFD3A685E for ; Thu, 15 Jan 2009 15:52:16 -0800 (PST) Received: from hcf.isc.org (dhcp-221.sql1.isc.org [204.152.187.221]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n0FNq0hO015585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 15:52:00 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 10CF457340; Thu, 15 Jan 2009 15:53:34 -0800 (PST) Date: Thu, 15 Jan 2009 15:53:33 -0800 From: "David W. Hankins" To: Jari Arkko Message-ID: <20090115235333.GD3263@isc.org> References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> MIME-Version: 1.0 In-Reply-To: <496CFA55.8020904@piuha.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Dhcwg , Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0343522183==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0343522183== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bjuZg6miEcdLYP6q" Content-Disposition: inline --bjuZg6miEcdLYP6q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 13, 2009 at 10:32:21PM +0200, Jari Arkko wrote: > review. However, I'd like to have positive confirmation from the DHC WG= =20 > that they are fine with the syntax. I can see that the bit pattern=20 > mechanism was simplified, but "enc" still remains, and I think David=20 > complained about that in particular. If existing DHCP server software=20 > cannot deal with a conditional encoding of attributes, I'd recommend=20 > simplifying further. You do NOT want to upgrade client and server code ju= st=20 > to transport one additional piece of config data. I've reviewed the changes in this draft. This protocol as currently written is not adoptable by existing DHCPv4 software on the Internet. To use this protocol, the administrator of a DHCP server must become intimately familiar with the wire format, and author the wire format directly in contrived and complicated configuration syntax (often, hexadecimal). Comfortable use of the protocol, converting presentation input to wire format, will require source code changes. It is my opinion that you can expect to wait until at least 2016 with fair winds (high user demand) before this protocol can reasonably be used on the Internet. Never at worst. For most protocols, this is a "non-starter" adoption problem. The core reason for my opinion as stated above is the 'enc' byte in the sub-option syntax. I strongly recommend that MIPSHOP come to consensus on whether this configuration value can be configured by IPv4 address on the wire (and FQDN in DHCP server config, resolved on demand for clients as is done today), or if an FQDN is truly mandatory, and choose only one of these two formats. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --bjuZg6miEcdLYP6q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklvzH0ACgkQcXeLeWu2vmrjdgCfVxBF7BKT0ffbvre8FuxrTYEt CyoAn0CfSXCe/pC+AR9z31cS5C2l7aw4 =RV42 -----END PGP SIGNATURE----- --bjuZg6miEcdLYP6q-- --===============0343522183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0343522183==-- From dhcwg-bounces@ietf.org Thu Jan 15 16:58:06 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83EC33A681D; Thu, 15 Jan 2009 16:58:06 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022FD3A681D for ; Thu, 15 Jan 2009 16:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24bJTCrlAxpM for ; Thu, 15 Jan 2009 16:58:04 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 245463A63EC for ; Thu, 15 Jan 2009 16:58:04 -0800 (PST) Received: from hcf.isc.org (dhcp-221.sql1.isc.org [204.152.187.221]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n0G0vmQ3017879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jan 2009 16:57:48 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 12E2D57340; Thu, 15 Jan 2009 16:59:22 -0800 (PST) Date: Thu, 15 Jan 2009 16:59:22 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20090116005921.GE3263@isc.org> MIME-Version: 1.0 User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [dhcwg] "the relay agent reliability problem" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1878017043==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1878017043== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KuLpqunXa7jZSBt+" Content-Disposition: inline --KuLpqunXa7jZSBt+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In several different places, the most important of which was Bernie's trials at exploring the Prefix Delegation space, we've found that we can't quite do what we need to because DHCPv4 and DHCPv6 relay agents do not receive DHCP configuration reliably in a server/client exchange. Additionally, external 'routing protocols' are also deselected for (network-local) political, religious, or administrative reasons. With the new year, I realized we stopped talking about this at some point. I think I found a way to very simply sum up my position on how I would like this area of work to proceed. I would like for the DHCP client state engine to remain the only state engine within the DHCP message exchange framework. So, in the frame of picture that ignores the server lease states. This implies to me going about solving the relay agent consistency problem in one of two ways, but I hope there are more, and I'm not crazy about either of them (they both have difficult challenges, so I don't think they're good ideas as I describe them, but I think it has potential to develop); 1) Cause the relay agent to also be a client (on its 'upstream' interface, for example). This supposes the relay agent will have an IA, so that renew and rebind timers can be tuned and used to ensure the relay gets 'up to date enough' information, according to local policy. The server would select renew and rebind timers so that the relay would receive updated configuration tearing down expired prefix delegations' routes on schedule with those prefix's lifetimes. As part of the configuration following the IA, the server would deliver a set of static route options, directing prefixes to delegated clients. The client would redistribute these routes as locally configured. There are two more different ways to interpret this class of design; a) The admin preallocates and pre-statically-routes prefixes to pre-designated global IPv6 addresses behind the relay. The relay may receive these routes via DHCPv6 options as a client, and may also be informed what prefixes to configure on downstream interfaces. The server allocates IA_NA/IA_PD's in matching pairs. Note this requires PD clients to receive NA addresses, whether they also participate in RTsol stateless global addresses or not. b) A different method would be for the server to initiate and potentially complete a "reconfigure" operation with the Relay Agent before each new prefix delegation. The new configuration map for the relay agent would be updated. This presumes a rather quiet and unassuming client base; that prefixes will be announced and withdrawn rarely, and that renews are far more common. In a way "something like this", the device overcomes the problem of reliability by engaging in a state engine that guarantees convergence of what is essentially configuration state. One downside is that the relay's client may have to engage in multiple client state engines in order to provide subdivision. A single static route map may exceed the 64KB UDP payload limit. 2) Make what is today a relay agent to instead be a 'delegated server,' becoming a DHCPv6 client 'upstream' which configures its own internal DHCPv6 server 'downstream'. In a design of this sort, we would suppose a superset of Ralph Drom's container option; "basic DHCPv6 server configuration," obtained from its DHCPv6 client scope. The agent would also receive delegated prefixes, which it would subdivide and use to address its downstream interfaces, and allocate to its own clients. In this way, the device overcomes the problem of reliable communications with the server by becoming the server in the equation. It can emit or revoke routes according to the policies it sets itself. One downside is the reliance upon local non-volatile storage. It may be that a solution in this area would need to be hybrid with some means for the agent to access an external database to request storage of new bindings as well as checking for existing bindings. It may be easier simply to let clients with such limits solve this problem separately (e.g., with SQL or LDAP or what have you). Some mechanism for automated reporting of usage upstream might also be required. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --KuLpqunXa7jZSBt+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklv2+kACgkQcXeLeWu2vmp/mwCdHLt/PVMB7fqxxJixhkASMOO2 TroAoKV28VXjMuNcAdVmTGR4oQ4UZoXO =3RiW -----END PGP SIGNATURE----- --KuLpqunXa7jZSBt+-- --===============1878017043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1878017043==-- From dhcwg-bounces@ietf.org Thu Jan 15 18:44:12 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0973A67F1; Thu, 15 Jan 2009 18:44:12 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF033A67F1 for ; Thu, 15 Jan 2009 18:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp4R7ByQmQmM for ; Thu, 15 Jan 2009 18:44:11 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id D7ED33A63EC for ; Thu, 15 Jan 2009 18:44:10 -0800 (PST) Received: from mailee.research.telcordia.com (mailee.research.telcordia.com [192.4.16.29]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n0G2i0Nj028349; Thu, 15 Jan 2009 21:44:01 -0500 (EST) Received: from [127.0.0.1] (vpntnlBw107 [128.96.59.107]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id VAA23376; Thu, 15 Jan 2009 21:43:54 -0500 (EST) Message-ID: <496FF469.7030709@research.telcordia.com> Date: Thu, 15 Jan 2009 21:43:53 -0500 From: Subir Das User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "David W. Hankins" References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> In-Reply-To: <20090115235333.GD3263@isc.org> Cc: Dhcwg , Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org David, Thanks for another review. We can certainly go with your proposal but our understanding is that there are existing RFCs (e.g., RFC 3361, RFC 3495) that support similar 'enc' byte and these options are adopted. regards, -Subir David W. Hankins wrote: > On Tue, Jan 13, 2009 at 10:32:21PM +0200, Jari Arkko wrote: > >> review. However, I'd like to have positive confirmation from the DHC WG >> that they are fine with the syntax. I can see that the bit pattern >> mechanism was simplified, but "enc" still remains, and I think David >> complained about that in particular. If existing DHCP server software >> cannot deal with a conditional encoding of attributes, I'd recommend >> simplifying further. You do NOT want to upgrade client and server code just >> to transport one additional piece of config data. >> > > I've reviewed the changes in this draft. > > This protocol as currently written is not adoptable by existing DHCPv4 > software on the Internet. To use this protocol, the administrator of > a DHCP server must become intimately familiar with the wire format, > and author the wire format directly in contrived and complicated > configuration syntax (often, hexadecimal). Comfortable use of the > protocol, converting presentation input to wire format, will require > source code changes. > > It is my opinion that you can expect to wait until at least 2016 with > fair winds (high user demand) before this protocol can reasonably be > used on the Internet. Never at worst. > > For most protocols, this is a "non-starter" adoption problem. > > > The core reason for my opinion as stated above is the 'enc' byte in > the sub-option syntax. I strongly recommend that MIPSHOP come to > consensus on whether this configuration value can be configured by > IPv4 address on the wire (and FQDN in DHCP server config, resolved > on demand for clients as is done today), or if an FQDN is truly > mandatory, and choose only one of these two formats. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jeroldjeon@ahkonline.com Thu Jan 15 21:11:12 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F122D3A685E for ; Thu, 15 Jan 2009 21:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.148 X-Spam-Level: X-Spam-Status: No, score=-11.148 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq0-ELAnATqM for ; Thu, 15 Jan 2009 21:11:12 -0800 (PST) Received: from amc.toshiba.co.jp (unknown [200.89.117.139]) by core3.amsl.com (Postfix) with SMTP id 0265F3A690A for ; Thu, 15 Jan 2009 21:10:08 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090116051010.0265F3A690A@core3.amsl.com> Date: Thu, 15 Jan 2009 21:10:08 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 31356
From dhcwg-bounces@ietf.org Fri Jan 16 00:50:20 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DED63A69B4; Fri, 16 Jan 2009 00:50:20 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573BD3A69B1 for ; Fri, 16 Jan 2009 00:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id looQeuowCimX for ; Fri, 16 Jan 2009 00:50:18 -0800 (PST) Received: from cl35.gs02.gridserver.com (cl35.gs02.gridserver.com [64.13.232.44]) by core3.amsl.com (Postfix) with ESMTP id 74CA53A6985 for ; Fri, 16 Jan 2009 00:50:18 -0800 (PST) Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:53506 helo=offset.weird.se) by cl35.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from ) id 1LNkOx-0001xh-0z for dhcwg@ietf.org; Fri, 16 Jan 2009 00:50:03 -0800 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Date: Fri, 16 Jan 2009 09:45:37 +0100 User-Agent: KMail/1.9.9 References: <494E1621.3020405@piuha.net> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> In-Reply-To: <20090115235333.GD3263@isc.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901160945.37418.budm@weird-solutions.com> X-Authenticated-User: 39280 budm@broadbandprovisioner.com Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Bud Millwood List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Friday 16 January 2009, David W. Hankins wrote: > On Tue, Jan 13, 2009 at 10:32:21PM +0200, Jari Arkko wrote: > > review. However, I'd like to have positive confirmation from the DHC WG > > that they are fine with the syntax. I can see that the bit pattern > > mechanism was simplified, but "enc" still remains, and I think David > > complained about that in particular. If existing DHCP server software > > cannot deal with a conditional encoding of attributes, I'd recommend > > simplifying further. You do NOT want to upgrade client and server code > > just to transport one additional piece of config data. > > I've reviewed the changes in this draft. > > This protocol as currently written is not adoptable by existing DHCPv4 > software on the Internet. To use this protocol, the administrator of > a DHCP server must become intimately familiar with the wire format, > and author the wire format directly in contrived and complicated > configuration syntax (often, hexadecimal). Comfortable use of the > protocol, converting presentation input to wire format, will require > source code changes. David: I think the cat's out of the bag on this one. (We just bit the bullet and decided to support an 'encoding' field generically.) Subir: There's probably no technical argument against this format, but David's point about the number of existing DHCPv4 servers that can natively handle the format is a good point. There are many existing installations that will have to resort to hex presentation. My own feeling is that the 'encoding' field is a de-facto standard, and we should fully support it. - Bud > It is my opinion that you can expect to wait until at least 2016 with > fair winds (high user demand) before this protocol can reasonably be > used on the Internet. Never at worst. > > For most protocols, this is a "non-starter" adoption problem. > > > The core reason for my opinion as stated above is the 'enc' byte in > the sub-option syntax. I strongly recommend that MIPSHOP come to > consensus on whether this configuration value can be configured by > IPv4 address on the wire (and FQDN in DHCP server config, resolved > on demand for clients as is done today), or if an FQDN is truly > mandatory, and choose only one of these two formats. -- Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From karakedd@alink.co.th Fri Jan 16 07:18:44 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28FA3A67B1 for ; Fri, 16 Jan 2009 07:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.296 X-Spam-Level: X-Spam-Status: No, score=-29.296 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXJDUb29NfOS for ; Fri, 16 Jan 2009 07:18:41 -0800 (PST) Received: from 82-168-79-14.ip.telfort.nl (82-168-79-14.ip.telfort.nl [82.168.79.14]) by core3.amsl.com (Postfix) with SMTP id D57E33A6774 for ; Fri, 16 Jan 2009 07:18:39 -0800 (PST) To: Subject: RE: Message 34330 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090116151840.D57E33A6774@core3.amsl.com> Date: Fri, 16 Jan 2009 07:18:39 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 24153
From dhcwg-bounces@ietf.org Fri Jan 16 09:38:37 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335F028C2A4; Fri, 16 Jan 2009 09:38:37 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E0628C2A7 for ; Fri, 16 Jan 2009 09:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THocJfoOl8ZQ for ; Fri, 16 Jan 2009 09:38:35 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 2010928C2A5 for ; Fri, 16 Jan 2009 09:38:35 -0800 (PST) Received: from david.isc.org (c-67-161-51-194.hsd1.ca.comcast.net [67.161.51.194]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n0GHcGaD024128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 09:38:17 -0800 Received: by david.isc.org (Postfix, from userid 10200) id 43D5C16E1B3; Fri, 16 Jan 2009 09:38:16 -0800 (PST) Date: Fri, 16 Jan 2009 09:38:15 -0800 From: "David W. Hankins" To: Subir Das Message-ID: <20090116173815.GA5060@isc.org> References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> MIME-Version: 1.0 In-Reply-To: <496FF469.7030709@research.telcordia.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Dhcwg , Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360232080==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1360232080== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2009 at 09:43:53PM -0500, Subir Das wrote: > Thanks for another review. We can certainly go with your proposal but ou= r=20 > understanding > is that there are existing RFCs (e.g., RFC 3361, RFC 3495) that support= =20 > similar 'enc' byte > and these options are adopted. I would not describe either option as well deployed. It's my view that both possess the same limitations I've warned against. The only 'enc byte option' I'm immediately aware of that I'd describe as well deployed today also requires other server-side special case code (the processing of dynamic updates), and so must be written by new machine language. The demand for dynamic updates was sufficient to cause the new code to start appearing in multiple DHCP software suites relatively quickly (a mere few years). Even in this case, the approach used was to deprecate all but one encoding (although there were only two). The reason for the deprecated format's inclusion was that implementations already existed. I'm unconvinced the demand for these options is sufficient for good deployment, and I haven't heard of existing implementations, so I am not changing my guidance. I think MIPSHOP should pick one encoding and stick with it. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFJcMYHcXeLeWu2vmoRAoLVAJwLrqkGRmL+UG5Qw44D8CnjJBqscgCffs3Q +L0/vm841Dgy8oqWKTcSvp8= =GFQv -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- --===============1360232080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1360232080==-- From dhcwg-bounces@ietf.org Fri Jan 16 10:25:11 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA0828C18F; Fri, 16 Jan 2009 10:25:11 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E4D28C18F for ; Fri, 16 Jan 2009 10:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rarZJcrDfpzu for ; Fri, 16 Jan 2009 10:25:06 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id CE2C828C13E for ; Fri, 16 Jan 2009 10:24:59 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSXDQ62sDmHcr1W+5OeHHZ9yLZA/2WJi9@postini.com; Fri, 16 Jan 2009 10:24:51 PST Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CAE3D1B82B5; Fri, 16 Jan 2009 10:24:55 -0800 (PST) Received: from [64.89.227.148] (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 16 Jan 2009 10:24:43 -0800 Message-ID: <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> From: Ted Lemon To: David W.Hankins In-Reply-To: <20090116173815.GA5060@isc.org> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 16 Jan 2009 10:24:41 -0800 References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> X-Mailer: Apple Mail (2.930.3) Cc: Dhcwg , Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" , Mipshop@core3.amsl.com Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 16, 2009, at 9:38 AM, David W. Hankins wrote: > I'm unconvinced the demand for these options is sufficient for good > deployment, and I haven't heard of existing implementations, so I am > not changing my guidance. I think MIPSHOP should pick one encoding > and stick with it. I have to side with David here. I was very much against the encoding options in the other two RFCs as well, for two reasons: 1. As David says, it's extra code, which nobody is going to implement if they don't have to. 2. It's an additional knob to turn, and chances are that it will always be turned the same way. And so the other way won't get tested (I wish it were not so, but client testing has historically been very, very spotty). And then when someone does use it, it will break. If there were some value being added, it would be one thing, but there's no value added here - it's just a decision the protocol designer is deciding not to make. My advice is to make the decision, and make it the way everyone else does: send an IP address. If you don't agree with this decision, please state a use case for the FQDN encoding. Not "someone might want to do FQDN encoding for some reason" but rather "in this case (provide a case here) it will be necessary to do FQDN encoding because IP-address encoding won't work or has the following severe disadvantage (explain disadvantage)." If you can't come up with one, then the conditional flag here is not only unnecessary, but harmful. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 16 12:16:53 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FB03A6903; Fri, 16 Jan 2009 12:16:53 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545A13A684A for ; Fri, 16 Jan 2009 12:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnvnMMX58hRp for ; Fri, 16 Jan 2009 12:16:50 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 78F343A6903 for ; Fri, 16 Jan 2009 12:16:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,278,1231113600"; d="scan'208";a="34054775" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2009 20:16:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0GKGY4m002784; Fri, 16 Jan 2009 15:16:34 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0GKGYK2008313; Fri, 16 Jan 2009 20:16:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 15:16:34 -0500 Received: from [161.44.65.126] ([161.44.65.126]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 15:16:33 -0500 Message-Id: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> From: Ralph Droms To: Dhcwg WG Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 16 Jan 2009 15:16:34 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Jan 2009 20:16:33.0867 (UTC) FILETIME=[5395B1B0:01C97817] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=396; t=1232136994; x=1233000994; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20review=20of=20draft-ietf-geopriv-lis -discovery-05 |Sender:=20 |To:=20Dhcwg=20WG=20; bh=iqxWkzs+cNv/JmrD+eWHf/XG1/el3vDJfEFf/AuBHps=; b=bmC1BJbROfgVA0Xu/O5AazAItneo1u4o9KGAySJmYBTsZv1jtpc56qgyUW 25u6FDbFAr+lVgnexIVK7Kzp7Ori9dswJkCQrcZaFhTJQ0AVleFDWK8TpTOz Ngsee5OHWn; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Richard Barnes , "Winterbottom, James" , "Thomson, Martin" Subject: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org "Discovering the Local Location Information Server (LIS)," http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-05 , defines DHCPv[46] options to carry the address of a LIS to a host. The geopriv WG would like to get dhc WG review and feedback on the syntax and use of these options. Please review the draft and reply to the mailing list with comments. Thanks... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 16 15:11:46 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06F83A6888; Fri, 16 Jan 2009 15:11:46 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466363A682D for ; Fri, 16 Jan 2009 15:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPkOC4DSlhgv for ; Fri, 16 Jan 2009 15:11:44 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 50AFA3A6768 for ; Fri, 16 Jan 2009 15:11:44 -0800 (PST) Received: from mailee.research.telcordia.com (mailee.research.telcordia.com [192.4.16.29]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n0GNBZRw016822; Fri, 16 Jan 2009 18:11:35 -0500 (EST) Received: from [127.0.0.1] (vpntnlBw107 [128.96.59.107]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA09613; Fri, 16 Jan 2009 18:11:27 -0500 (EST) Message-ID: <49711423.4080702@research.telcordia.com> Date: Fri, 16 Jan 2009 18:11:31 -0500 From: Subir Das User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "David W. Hankins" References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> In-Reply-To: <20090116173815.GA5060@isc.org> Cc: Dhcwg , Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > On Thu, Jan 15, 2009 at 09:43:53PM -0500, Subir Das wrote: > >> Thanks for another review. We can certainly go with your proposal but our >> understanding >> is that there are existing RFCs (e.g., RFC 3361, RFC 3495) that support >> similar 'enc' byte >> and these options are adopted. >> > > I would not describe either option as well deployed. It's my view > that both possess the same limitations I've warned against. > > The only 'enc byte option' I'm immediately aware of that I'd describe > as well deployed today also requires other server-side special case > code (the processing of dynamic updates), and so must be written by > new machine language. The demand for dynamic updates was sufficient > to cause the new code to start appearing in multiple DHCP software > suites relatively quickly (a mere few years). Even in this case, the > approach used was to deprecate all but one encoding (although there > were only two). The reason for the deprecated format's inclusion was > that implementations already existed. > > I'm unconvinced the demand for these options is sufficient for good > deployment, and I haven't heard of existing implementations, so I am > not changing my guidance. I think MIPSHOP should pick one encoding > and stick with it. > Does this mean we can define two separate options: one for IP address and other one for FQDN without using 'enc' byte? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 16 15:26:03 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3EA3A6888; Fri, 16 Jan 2009 15:26:03 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AA93A6888 for ; Fri, 16 Jan 2009 15:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxzYUSi+DLaw for ; Fri, 16 Jan 2009 15:26:01 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 0FAAD3A6768 for ; Fri, 16 Jan 2009 15:25:57 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSXEXds+XEoC1gfGOGhZKAIL97q5kDJ+I@postini.com; Fri, 16 Jan 2009 15:25:46 PST Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 19FE91B82B9; Fri, 16 Jan 2009 15:25:54 -0800 (PST) Received: from [64.89.227.148] (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 16 Jan 2009 15:25:41 -0800 Message-ID: <3F320C4F-49B9-47F1-A9C8-EB3BE9443E7C@nominum.com> From: Ted Lemon To: Subir Das In-Reply-To: <49711423.4080702@research.telcordia.com> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 16 Jan 2009 15:25:40 -0800 References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <49711423.4080702@research.telcordia.com> X-Mailer: Apple Mail (2.930.3) Cc: Mipshop Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" , Dhcwg Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 16, 2009, at 3:11 PM, Subir Das wrote: > Does this mean we can define two separate options: one for IP > address > and other one for FQDN > without using 'enc' byte? Subir, can you answer the question as to why you want both options? Having a second option still creates a situation where the implementor will probably prefer one code path over the other, and we'll wind up with lots of implementations that support one path well and fail when operator chooses the other path. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 16 15:36:08 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE2A3A694F; Fri, 16 Jan 2009 15:36:08 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E243A689D for ; Fri, 16 Jan 2009 15:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0DvZ5tea9LH for ; Fri, 16 Jan 2009 15:36:07 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 285BC3A694F for ; Fri, 16 Jan 2009 15:36:07 -0800 (PST) Received: from mailee.research.telcordia.com (mailee.research.telcordia.com [192.4.16.29]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n0GNZwX5019884; Fri, 16 Jan 2009 18:35:58 -0500 (EST) Received: from [127.0.0.1] (vpntnlBw107 [128.96.59.107]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA13016; Fri, 16 Jan 2009 18:35:51 -0500 (EST) Message-ID: <497119DA.80207@research.telcordia.com> Date: Fri, 16 Jan 2009 18:35:54 -0500 From: Subir Das User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ted Lemon References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> In-Reply-To: <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> Cc: Mipshop Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" , Dhcwg Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Jan 16, 2009, at 9:38 AM, David W. Hankins wrote: >> I'm unconvinced the demand for these options is sufficient for good >> deployment, and I haven't heard of existing implementations, so I am >> not changing my guidance. I think MIPSHOP should pick one encoding >> and stick with it. > > I have to side with David here. I was very much against the encoding > options in the other two RFCs as well, for two reasons: > > 1. As David says, it's extra code, which nobody is going to implement > if they don't have to. > 2. It's an additional knob to turn, and chances are that it will > always be turned the same way. And so the other way won't get tested > (I wish it were not so, but client testing has historically been very, > very spotty). And then when someone does use it, it will break. If > there were some value being added, it would be one thing, but there's > no value added here - it's just a decision the protocol designer is > deciding not to make. > > My advice is to make the decision, and make it the way everyone else > does: send an IP address. If you don't agree with this decision, > please state a use case for the FQDN encoding. Not "someone might > want to do FQDN encoding for some reason" but rather "in this case > (provide a case here) it will be necessary to do FQDN encoding because > IP-address encoding won't work or has the following severe > disadvantage (explain disadvantage)." If you can't come up with one, > then the conditional flag here is not only unnecessary, but harmful. We have few scenarios for which we proposed both IP address and FQDN. For example, when mobile node is in home network, DHCP server will know the IP address and sending an IP address is sufficient. In roaming case, visited network may not have the service available and therefore DHCP server can not be configured with the correct MOS IP address. On the other hand, visited network may know the domain name where service is available. In such cases, DHCP server can be configured with the domain name. If MN obtains such domain name it can make appropriate DNS query for the MoS address. Now if the current 'enc' byte in the sub-option is not the correct way to go, can we propose two separate options? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 16 15:46:36 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C603A6872; Fri, 16 Jan 2009 15:46:36 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DA03A694F for ; Fri, 16 Jan 2009 15:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AHhtfmGl7Gd for ; Fri, 16 Jan 2009 15:46:34 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id F12FC3A6872 for ; Fri, 16 Jan 2009 15:46:30 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSXEcR1Jb3liKKW1uWSTEd84bZdSmUopP@postini.com; Fri, 16 Jan 2009 15:46:19 PST Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 06E7D1B82B9; Fri, 16 Jan 2009 15:46:28 -0800 (PST) Received: from [64.89.227.148] (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 16 Jan 2009 15:46:15 -0800 Message-ID: From: Ted Lemon To: Subir Das In-Reply-To: <497119DA.80207@research.telcordia.com> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 16 Jan 2009 15:46:14 -0800 References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> X-Mailer: Apple Mail (2.930.3) Cc: Dhcwg , Mipshop Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 16, 2009, at 3:35 PM, Subir Das wrote: > We have few scenarios for which we proposed both IP address and > FQDN. For example, when mobile node is in home network, DHCP server > will know the IP address and sending an IP address is sufficient. Okay. > In roaming case, visited network may not have the service available > and > therefore DHCP server can not be configured with the correct MOS IP > address. On the other hand, visited network may know the domain name > where service is available. In such cases, DHCP server can be > configured with the > domain name. If MN obtains such domain name it can make appropriate > DNS > query for the MoS address. I do not understand the data flow here. Can you explain which device does what in this situation? If the DHCP server doesn't know the IP address, how does it know the FQDN? > Now if the current 'enc' byte in the sub-option is not the correct > way to go, can we propose two separate options? That's not really the issue. Let's resolve the technical details first, and then talk about how to implement it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 16 15:59:22 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022723A696D; Fri, 16 Jan 2009 15:59:22 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8B93A696D for ; Fri, 16 Jan 2009 15:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPV1U8EWyPIQ for ; Fri, 16 Jan 2009 15:59:20 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 0CD6C3A6768 for ; Fri, 16 Jan 2009 15:59:19 -0800 (PST) Received: from mailee.research.telcordia.com (mailee.research.telcordia.com [192.4.16.29]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n0GNxBng022355; Fri, 16 Jan 2009 18:59:11 -0500 (EST) Received: from [127.0.0.1] (vpntnlBw107 [128.96.59.107]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA15690; Fri, 16 Jan 2009 18:59:04 -0500 (EST) Message-ID: <49711F4B.8000801@research.telcordia.com> Date: Fri, 16 Jan 2009 18:59:07 -0500 From: Subir Das User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ted Lemon References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> In-Reply-To: Cc: Dhcwg , Mipshop Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Jan 16, 2009, at 3:35 PM, Subir Das wrote: >> We have few scenarios for which we proposed both IP address and >> FQDN. For example, when mobile node is in home network, DHCP server >> will know the IP address and sending an IP address is sufficient. > > Okay. > >> In roaming case, visited network may not have the service available and >> therefore DHCP server can not be configured with the correct MOS IP >> address. On the other hand, visited network may know the domain name >> where service is available. In such cases, DHCP server can be >> configured with the >> domain name. If MN obtains such domain name it can make appropriate DNS >> query for the MoS address. > > I do not understand the data flow here. Can you explain which device > does what in this situation? If the DHCP server doesn't know the IP > address, how does it know the FQDN? DHCP Server in the visited network is configured with the FQDN of the provider that provides the mobility service. When MN arrives to this visited network, it sends the MoS option to the DHCP Server and receives the FQDN of the provider. MN then sends the DNS query to the provider and obtains the address of the Mobility Server (MoS). The FQDN of the service provider may be known via roaming agreement. > >> Now if the current 'enc' byte in the sub-option is not the correct >> way to go, can we propose two separate options? > > That's not really the issue. Let's resolve the technical details > first, and then talk about how to implement it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 16 16:15:00 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9533A6A3E; Fri, 16 Jan 2009 16:15:00 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7745D3A6A3E for ; Fri, 16 Jan 2009 16:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgvvUeiuUmnb for ; Fri, 16 Jan 2009 16:14:57 -0800 (PST) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id AF82A3A6A24 for ; Fri, 16 Jan 2009 16:14:57 -0800 (PST) Received: (qmail 393 invoked from network); 17 Jan 2009 00:14:41 -0000 Received: from unknown (67.160.38.190) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 17 Jan 2009 00:14:41 -0000 From: "Glen Zorn" To: "'Subir Das'" , "'Ted Lemon'" References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> In-Reply-To: <49711F4B.8000801@research.telcordia.com> Date: Fri, 16 Jan 2009 16:13:54 -0800 Organization: Network Zen Message-ID: <005201c97838$7c5dbef0$75193cd0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl4NmvdHfpeDh3AT2WQBm4mZWzlJAAAMLYg Content-Language: en-us Cc: 'Dhcwg' , 'Mipshop Chairs' , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Subir Das [mailto:subir@research@telecordia.com] writes: > Ted Lemon wrote: > > On Jan 16, 2009, at 3:35 PM, Subir Das wrote: > >> We have few scenarios for which we proposed both IP address and > >> FQDN. For example, when mobile node is in home network, DHCP server > >> will know the IP address and sending an IP address is sufficient. > > > > Okay. > > > >> In roaming case, visited network may not have the service available and > >> therefore DHCP server can not be configured with the correct MOS IP > >> address. On the other hand, visited network may know the domain name > >> where service is available. In such cases, DHCP server can be > >> configured with the > >> domain name. If MN obtains such domain name it can make appropriate DNS > >> query for the MoS address. > > > > I do not understand the data flow here. Can you explain which > device > > does what in this situation? If the DHCP server doesn't know the IP > > address, how does it know the FQDN? > DHCP Server in the visited network is configured with the FQDN of > the provider that provides the mobility service. When MN arrives to > this > visited network, it sends the MoS option to the DHCP Server and > receives the FQDN of the provider. MN then sends the DNS query to > the provider and obtains the address of the Mobility Server (MoS). The > FQDN of the service provider may be known > via roaming agreement. Why can't the DHCP server resolve the FQDN itself and return the IP address(es) to the DHCP client? It seems to me that the scenarios above may make a case for the server being configured with both IP address and FQDN but that's all. > > > >> Now if the current 'enc' byte in the sub-option is not the correct > >> way to go, can we propose two separate options? > > > > That's not really the issue. Let's resolve the technical details > > first, and then talk about how to implement it. What a concept! ;-) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 17 08:15:57 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF3A28B797; Sat, 17 Jan 2009 08:15:57 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC173A6B3D; Sat, 17 Jan 2009 08:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-yb8wtEZEp9; Sat, 17 Jan 2009 08:15:55 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 625973A6B3A; Sat, 17 Jan 2009 08:15:55 -0800 (PST) Received: from mailee.research.telcordia.com (mailee.research.telcordia.com [192.4.16.29]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n0HGFjrb008492; Sat, 17 Jan 2009 11:15:45 -0500 (EST) Received: from [127.0.0.1] (vpntnlBw107 [128.96.59.107]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA23421; Sat, 17 Jan 2009 11:15:39 -0500 (EST) Message-ID: <4972042E.9080405@research.telcordia.com> Date: Sat, 17 Jan 2009 11:15:42 -0500 From: Subir Das User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Bud Millwood References: <494E1621.3020405@piuha.net> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <200901160945.37418.budm@weird-solutions.com> In-Reply-To: <200901160945.37418.budm@weird-solutions.com> Cc: dhcwg@ietf.org, Mipshop Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bud Millwood wrote: > On Friday 16 January 2009, David W. Hankins wrote: > >> On Tue, Jan 13, 2009 at 10:32:21PM +0200, Jari Arkko wrote: >> >>> review. However, I'd like to have positive confirmation from the DHC WG >>> that they are fine with the syntax. I can see that the bit pattern >>> mechanism was simplified, but "enc" still remains, and I think David >>> complained about that in particular. If existing DHCP server software >>> cannot deal with a conditional encoding of attributes, I'd recommend >>> simplifying further. You do NOT want to upgrade client and server code >>> just to transport one additional piece of config data. >>> >> I've reviewed the changes in this draft. >> >> This protocol as currently written is not adoptable by existing DHCPv4 >> software on the Internet. To use this protocol, the administrator of >> a DHCP server must become intimately familiar with the wire format, >> and author the wire format directly in contrived and complicated >> configuration syntax (often, hexadecimal). Comfortable use of the >> protocol, converting presentation input to wire format, will require >> source code changes. >> > > David: I think the cat's out of the bag on this one. (We just bit the bullet > and decided to support an 'encoding' field generically.) > > Subir: There's probably no technical argument against this format, but David's > point about the number of existing DHCPv4 servers that can natively handle > the format is a good point. There are many existing installations that will > have to resort to hex presentation. > Thanks and I understand David and Ted's concerns. Hopefully we will be able to resolve this soon. > My own feeling is that the 'encoding' field is a de-facto standard, and we > should fully support it. > I would wait for David or Ted to comment on this. > - Bud > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 17 19:37:13 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725D628C125; Sat, 17 Jan 2009 19:37:13 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAC528C125 for ; Sat, 17 Jan 2009 19:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou0pEn7tUjEO for ; Sat, 17 Jan 2009 19:37:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C4AC33A677D for ; Sat, 17 Jan 2009 19:37:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,282,1231113600"; d="scan'208";a="34089221" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2009 03:35:53 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0I3ZrbL013044; Sat, 17 Jan 2009 22:35:53 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0I3Zr2J028995; Sun, 18 Jan 2009 03:35:53 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jan 2009 22:35:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Jan 2009 22:35:51 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACA7F3@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Status of draft-ietf-mos-dhcp-options Thread-Index: Acl4B71M7UenPUW3SCWyEA6t1QDLeABFJcog References: <494E1621.3020405@piuha.net><49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net><20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com><20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> From: "Bernie Volz (volz)" To: "Ted Lemon" , "David W.Hankins" X-OriginalArrivalTime: 18 Jan 2009 03:35:53.0176 (UTC) FILETIME=[DD5ECD80:01C9791D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2408; t=1232249753; x=1233113753; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Status=20of=20draft-ietf-mos- dhcp-options |Sender:=20 |To:=20=22Ted=20Lemon=22=20,=0A=20=2 0=20=20=20=20=20=20=22David=20W.Hankins=22=20; bh=uvS01QIILgPMvsiEMSGYHPq6Co7kMz9LI6vBASPBa8Y=; b=FuLWN0rnlsJ7j06hMWD68UYzE8yTUNNMdKkrJLMmTtqEyEGVrz+NoNjlCe 3jHvhDekD5n2dlZckbutbnRy2/cOP6r+LbR/E3aeeIJHsTOMRqNEoPVCgeaB lsg/bafzRw; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Mipshop@core3.amsl.com, Dhcwg , Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Just for the record, there are DHCP server implementations that do support this encoding-byte + data (depending on encoding-byte) format. And, the RFC 3495 (CableLabs Client Configuration Option) is used by lots of devices. As it is used in several places, I do think the cat is out of the bag and I think it should be usable by new options. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Friday, January 16, 2009 1:25 PM To: David W.Hankins Cc: Dhcwg; Chairs; draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org; Mipshop@core3.amsl.com Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options On Jan 16, 2009, at 9:38 AM, David W. Hankins wrote: > I'm unconvinced the demand for these options is sufficient for good > deployment, and I haven't heard of existing implementations, so I am > not changing my guidance. I think MIPSHOP should pick one encoding > and stick with it. I have to side with David here. I was very much against the encoding options in the other two RFCs as well, for two reasons: 1. As David says, it's extra code, which nobody is going to implement if they don't have to. 2. It's an additional knob to turn, and chances are that it will always be turned the same way. And so the other way won't get tested (I wish it were not so, but client testing has historically been very, very spotty). And then when someone does use it, it will break. If there were some value being added, it would be one thing, but there's no value added here - it's just a decision the protocol designer is deciding not to make. My advice is to make the decision, and make it the way everyone else does: send an IP address. If you don't agree with this decision, please state a use case for the FQDN encoding. Not "someone might want to do FQDN encoding for some reason" but rather "in this case (provide a case here) it will be necessary to do FQDN encoding because IP-address encoding won't work or has the following severe disadvantage (explain disadvantage)." If you can't come up with one, then the conditional flag here is not only unnecessary, but harmful. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 17 19:38:12 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B704C3A6AB7; Sat, 17 Jan 2009 19:38:12 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8BD28C16E for ; Sat, 17 Jan 2009 19:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7uxarD712e8 for ; Sat, 17 Jan 2009 19:38:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 216963A677D for ; Sat, 17 Jan 2009 19:38:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,282,1231113600"; d="scan'208";a="34127471" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2009 03:37:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0I3bs2q003995; Sat, 17 Jan 2009 22:37:54 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0I3bsOP029184; Sun, 18 Jan 2009 03:37:54 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jan 2009 22:37:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Jan 2009 22:37:52 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACA7F4@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <005201c97838$7c5dbef0$75193cd0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Status of draft-ietf-mos-dhcp-options Thread-Index: Acl4NmvdHfpeDh3AT2WQBm4mZWzlJAAAMLYgADmu7UA= References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> <005201c97838$7c5dbef0$75193cd0$@net> From: "Bernie Volz (volz)" To: "Glen Zorn" , "Subir Das" , "Ted Lemon" X-OriginalArrivalTime: 18 Jan 2009 03:37:53.0898 (UTC) FILETIME=[255384A0:01C9791E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2907; t=1232249874; x=1233113874; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Status=20of=20draft-ietf-mos- dhcp-options |Sender:=20 |To:=20=22Glen=20Zorn=22=20,=20=22Subir=20 Das=22=20,=0A=20=20=20=20=20=2 0=20=20=22Ted=20Lemon=22=20; bh=ABP11i7YYuSP6EtGLQBpWJTdQh5YItMTjsx+no+9IJ4=; b=mb5ngZqPVzdeShP4qU0UaNEU9V9DM1Rpxp0kzbm/raHAU5d2oO/hMnAtXD vuNs8dfd8PRkbFlBGVOyGiPO77Ng1NRgoGgdlQTv3mcCoawx3Ew48/j5lkCJ 6bwDmKtbwx; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg , Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org While a DHCP server could do that, it would provide the answers at whatever time the server resolved it (sure, I suppose it could honor the TTL on the data and only cache it for that long). But, that doesn't solve the problem of why a FQDN was desired -- the option might not be used for hours or days and by then the addresses could have changed. Once the client is given the lease and options, it won't get new ones until it renews. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Friday, January 16, 2009 7:14 PM To: 'Subir Das'; 'Ted Lemon' Cc: 'Dhcwg'; 'Mipshop Chairs'; draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options Subir Das [mailto:subir@research@telecordia.com] writes: > Ted Lemon wrote: > > On Jan 16, 2009, at 3:35 PM, Subir Das wrote: > >> We have few scenarios for which we proposed both IP address and > >> FQDN. For example, when mobile node is in home network, DHCP server > >> will know the IP address and sending an IP address is sufficient. > > > > Okay. > > > >> In roaming case, visited network may not have the service available and > >> therefore DHCP server can not be configured with the correct MOS IP > >> address. On the other hand, visited network may know the domain name > >> where service is available. In such cases, DHCP server can be > >> configured with the > >> domain name. If MN obtains such domain name it can make appropriate DNS > >> query for the MoS address. > > > > I do not understand the data flow here. Can you explain which > device > > does what in this situation? If the DHCP server doesn't know the IP > > address, how does it know the FQDN? > DHCP Server in the visited network is configured with the FQDN of > the provider that provides the mobility service. When MN arrives to > this > visited network, it sends the MoS option to the DHCP Server and > receives the FQDN of the provider. MN then sends the DNS query to > the provider and obtains the address of the Mobility Server (MoS). The > FQDN of the service provider may be known > via roaming agreement. Why can't the DHCP server resolve the FQDN itself and return the IP address(es) to the DHCP client? It seems to me that the scenarios above may make a case for the server being configured with both IP address and FQDN but that's all. > > > >> Now if the current 'enc' byte in the sub-option is not the correct > >> way to go, can we propose two separate options? > > > > That's not really the issue. Let's resolve the technical details > > first, and then talk about how to implement it. What a concept! ;-) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jan 17 20:03:28 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A413A6824; Sat, 17 Jan 2009 20:03:28 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1ED73A677D; Sat, 17 Jan 2009 20:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8u9ho68ivty; Sat, 17 Jan 2009 20:03:26 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6E2673A6824; Sat, 17 Jan 2009 20:03:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,282,1231113600"; d="scan'208";a="34089768" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2009 04:03:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0I43Av6007940; Sat, 17 Jan 2009 23:03:10 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0I43ArF027660; Sun, 18 Jan 2009 04:03:10 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jan 2009 23:03:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Jan 2009 23:03:08 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 Thread-Index: Acl1x+tQgIoihd8dRC+WvuyQafnDmgDVvoDQ References: From: "Bernie Volz (volz)" To: "JiangSheng 66104" , , X-OriginalArrivalTime: 18 Jan 2009 04:03:10.0273 (UTC) FILETIME=[AD27FB10:01C97921] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3901; t=1232251390; x=1233115390; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20=20=22Secure=20DHCPv6=20Using =20CGAs=22=20draft-jiang-dhc-secure-dhcpv6-01 |Sender:=20 |To:=20=22JiangSheng=2066104=22=20,= 20,=0A=20=20=20=20=20=20=20=20; bh=+q+G9habWhY8RFaHY9Yh4r6FiAYuGTT/vI+KrBhBD7A=; b=C5ViVV5U0HB6ZZB50z1KVGKWFJxnCnmwOSerr/aWMA9f2kej5eSVx7MNWP RhGYVJhlD06ZDZJHTEjoc/w46FQqrEfQV9CXHLOMoMQPYGv5Sk0VpzVoCsjW 6hMbCUfcEW; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I'm (still) a bit concerned about: 5.2. Signature Option The Signature option allows public key-based signatures to be attached to a DHCPv6 message. The Signature option COULD be any place within the DHCPv6 message. It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option. The format of the Signature option is described as follows: Why is this protection positional? Can you explain why you think this is useful? Why not secure the entire message with this? The only interesting issue is if a client's message includes both a SIGNATURE and AUTH (RFC 3315) option -- since in this case, two different hashes over the entire message would need to be run and that doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH option. (The AUTH option would include the SIGNATURE option as RFC 3315 already requires that it cover the entire client message.) I wonder whether this positional text is a hold over from DHCPv4 to handle the Relay Agent Option (82) - which is added at the end? Relaying in DHCPv6 is done far differently. If there's a reason why the SIGNATURE needs to be positional, we still have the AUTH option conflict that would need to be discussed (if the AUTH option isn't excluded from coverage regardless of where it appeared in the message, it would require the AUTH to follow the SIGNATURE). --- The draft allows a node to be a DHCPv6 relay agent. I think more text is required to detail this. Suppose you have: Client --> Relay 1 --> Relay 2 --> Server If Relay 1 includes a SIGNATURE option, and relay 2 does not support this, what should the server do? How does the server know whether relay 2 validated the SIGNATURE of Relay 1 or not (is there a requirement for the relay to validate -- it is after all a "node")? Should the server validate all SIGNATURE options (as in this case, there could be 3 - one in the Client message, one in the Relay 1 message (which encapsulates the client's message), and one in the Relay 2 message (which encapsulates Relay 1's message (which encapsulates the client's message))? Perhaps the ability for a relay to be a node should be removed? It keeps it simpler. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of JiangSheng 66104 Sent: Tuesday, January 13, 2009 4:43 PM To: cga-ext@ietf.org; dhcwg@ietf.org Subject: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 The below "Secure DHCPv6 Using CGAs" has been updated, according to comments that have been discussed in dhc maillist and IETF meeting. Since early collaboration is requested for this CGA and DHCP interaction work, this update message is sent to both CSI WG and DHC WG. Best regards, Sheng A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure DHCPv6 Using CGAs Author(s) : S. Jiang, S. Shen Filename : draft-jiang-dhc-secure-dhcpv6-01.txt Pages : 14 Date : 2009-1-8 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From krispytrea@aeconcepts.com Sun Jan 18 08:58:27 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA033A67CF for ; Sun, 18 Jan 2009 08:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.349 X-Spam-Level: X-Spam-Status: No, score=-21.349 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, RELAY_IS_222=2.179, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9-WCHSuD1VV for ; Sun, 18 Jan 2009 08:58:27 -0800 (PST) Received: from cm130.theta10.maxonline.com.sg (cm130.theta10.maxonline.com.sg [222.165.10.130]) by core3.amsl.com (Postfix) with SMTP id CFB7A3A67AF for ; Sun, 18 Jan 2009 08:58:24 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090118165825.CFB7A3A67AF@core3.amsl.com> Date: Sun, 18 Jan 2009 08:58:24 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 77625
From dhcwg-bounces@ietf.org Sun Jan 18 09:22:21 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1073A6925; Sun, 18 Jan 2009 09:22:21 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE773A6925; Sun, 18 Jan 2009 09:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eD4TpINBV9W; Sun, 18 Jan 2009 09:22:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B7EC73A67FA; Sun, 18 Jan 2009 09:22:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,284,1231113600"; d="scan'208";a="34150103" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2009 17:21:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0IHLluL009574; Sun, 18 Jan 2009 12:21:47 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0IHLlHG024734; Sun, 18 Jan 2009 17:21:47 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Jan 2009 12:21:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Jan 2009 12:21:46 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACA80A@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 Thread-Index: Acl1x+tQgIoihd8dRC+WvuyQafnDmgDVvoDQABr4C8A= References: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> From: "Bernie Volz (volz)" To: "JiangSheng 66104" , , X-OriginalArrivalTime: 18 Jan 2009 17:21:47.0063 (UTC) FILETIME=[3DC9E470:01C97991] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8356; t=1232299307; x=1233163307; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20=22Secure=20DHCPv6=20Using=20 CGAs=22draft-jiang-dhc-secure-dhcpv6-01 |Sender:=20 |To:=20=22JiangSheng=2066104=22=20,= 20,=0A=20=20=20=20=20=20=20=20; bh=Kh+9iKyy4OdSCJ7+vyeOKhq5eshiNF6KLYXnRLVS18g=; b=qnKFbE4uIq3GtQP0htJTLYA9xkd9YE4v7t/jV54QfXWox35Qm2UcJ6ykTg oTJpew9jnUspBhmaD1FWnEhds/54WTfKyG8wYmZL2zI3lNkv43I9TJxmO5Lu vKsd1wUAnf; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I noticed that the draft is actually self conflicting in terms of the Signature option: 5.2. Signature Option ... The Signature option COULD be any place within the DHCPv6 message. It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option. ... 6.1. Processing Rules of Sender ... The Signature option MUST be constructed as explained in Section 5.2 and be the last DHCPv6 option. Again, per my earlier comments I think its position should not matter. --- In 6.2. Processing Rules of Receiver: The receiving node MUST verify the Signature option as follows: the receiver MUST ignore any options that come after the Signature option. What about the contents of the Signature option itself? The document needs to indicate which, if any, portion of the Signature option is included in the signature hashing. (The SEND RFC (3791) excludes the signature option.) Note that earlier in section 5.2. Signature Option is written: 6. The content between the option-len field and the signature field in this Signature option, in the format described above. Might be best to just refer to section 5.2 instead of duplicating the information (less chance for it to conflict)? --- This probably exposes my ignorance of CGAs, but is the intent in this draft that the CGA source address used by the client remains the (CGA) link-local address? If this is the case (client uses CGA link-local as IPv6 source address), all is well. If the CGA address is not the link-local, then there is a conflict with RFC 3315: 16. Client Source Address and Interface Selection When a client sends a DHCP message to the All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message through the interface for which configuration information is being requested. However, the client MAY send the message through another interface attached to the same link, if and only if the client is -> certain the two interfaces are attached to the same link. The client -> MUST use a link-local address assigned to the interface for which it -> is requesting configuration information as the source address in the -> header of the IP datagram. When a client sends a DHCP message directly to a server using unicast (after receiving the Server Unicast option from that server), the source address in the header of the IP datagram MUST be an address assigned to the interface for which the client is interested in obtaining configuration and which is suitable for use by the server in responding to the client. A non-link-local address is only allowed if the server previously provided the client with the Server Unicast option. --- The following text is rather odd: If a node has been configured to use Secure DHCPv6, the node MUST send a message using a CGA, which be constructed as specified in Section 4 of [RFC3972], as the source address unless they are sent -> with the unspecified source address. In the message, both the CGA option and the Signature option MUST be present in all DHCPv6 messages. The CGA Parameter field in the CGA option is filled according to the rules presented above and in [RFC3972]. The public key in the field is taken from the configuration used to generate the CGA, typically from a data structure associated with the source address. The Signature option MUST be constructed as explained in Section 5.2 and be the last DHCPv6 option. DHCPv6 never uses an unspecified source address. Also be good to use "CGA Parameter option" instead of "CGA option", as that is what the option is called. This is an issue throughout the document. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Saturday, January 17, 2009 11:03 PM To: JiangSheng 66104; cga-ext@ietf.org; dhcwg@ietf.org Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 I'm (still) a bit concerned about: 5.2. Signature Option The Signature option allows public key-based signatures to be attached to a DHCPv6 message. The Signature option COULD be any place within the DHCPv6 message. It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option. The format of the Signature option is described as follows: Why is this protection positional? Can you explain why you think this is useful? Why not secure the entire message with this? The only interesting issue is if a client's message includes both a SIGNATURE and AUTH (RFC 3315) option -- since in this case, two different hashes over the entire message would need to be run and that doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH option. (The AUTH option would include the SIGNATURE option as RFC 3315 already requires that it cover the entire client message.) I wonder whether this positional text is a hold over from DHCPv4 to handle the Relay Agent Option (82) - which is added at the end? Relaying in DHCPv6 is done far differently. If there's a reason why the SIGNATURE needs to be positional, we still have the AUTH option conflict that would need to be discussed (if the AUTH option isn't excluded from coverage regardless of where it appeared in the message, it would require the AUTH to follow the SIGNATURE). --- The draft allows a node to be a DHCPv6 relay agent. I think more text is required to detail this. Suppose you have: Client --> Relay 1 --> Relay 2 --> Server If Relay 1 includes a SIGNATURE option, and relay 2 does not support this, what should the server do? How does the server know whether relay 2 validated the SIGNATURE of Relay 1 or not (is there a requirement for the relay to validate -- it is after all a "node")? Should the server validate all SIGNATURE options (as in this case, there could be 3 - one in the Client message, one in the Relay 1 message (which encapsulates the client's message), and one in the Relay 2 message (which encapsulates Relay 1's message (which encapsulates the client's message))? Perhaps the ability for a relay to be a node should be removed? It keeps it simpler. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of JiangSheng 66104 Sent: Tuesday, January 13, 2009 4:43 PM To: cga-ext@ietf.org; dhcwg@ietf.org Subject: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 The below "Secure DHCPv6 Using CGAs" has been updated, according to comments that have been discussed in dhc maillist and IETF meeting. Since early collaboration is requested for this CGA and DHCP interaction work, this update message is sent to both CSI WG and DHC WG. Best regards, Sheng A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure DHCPv6 Using CGAs Author(s) : S. Jiang, S. Shen Filename : draft-jiang-dhc-secure-dhcpv6-01.txt Pages : 14 Date : 2009-1-8 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Jan 18 14:54:22 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522F628C120; Sun, 18 Jan 2009 14:54:22 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2523A6959 for ; Sun, 18 Jan 2009 14:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQOECXdDLpcX for ; Sun, 18 Jan 2009 14:54:20 -0800 (PST) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id DC78A3A6B61 for ; Sun, 18 Jan 2009 14:54:19 -0800 (PST) Received: (qmail 14224 invoked from network); 18 Jan 2009 22:54:03 -0000 Received: from unknown (67.160.38.190) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 18 Jan 2009 22:54:03 -0000 From: "Glen Zorn" To: "'Bernie Volz \(volz\)'" , "'Subir Das'" , "'Ted Lemon'" References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> <005201c97838$7c5dbef0$75193cd0$@net> <8E296595B6471A4689555D5D725EBB210AACA7F4@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210AACA7F4@xmb-rtp-20a.amer.cisco.com> Date: Sun, 18 Jan 2009 14:53:58 -0800 Organization: Network Zen Message-ID: <001001c979bf$a706b980$f5142c80$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl4NmvdHfpeDh3AT2WQBm4mZWzlJAAAMLYgADmu7UAAKD3RMA== Content-Language: en-us Cc: 'Dhcwg' , 'Mipshop Chairs' , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie Volz (volz) [mailto:volz@cisco.com] writes: > While a DHCP server could do that, it would provide the answers at > whatever time the server resolved it (sure, I suppose it could honor > the > TTL on the data and only cache it for that long). But, that doesn't > solve the problem of why a FQDN was desired -- the option might not be > used for hours or days and by then the addresses could have changed. OK, so why the option for IP addresses? I what you say is true for the roaming case, why isn't it also true for the home network? One way or the other, it seems like one of these options make no sense... ... Play assigns meaning to human activity -- work erases it. -- P.L. Wilson _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Jan 18 17:24:47 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E803A6B75; Sun, 18 Jan 2009 17:24:47 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1429928C0F5 for ; Sun, 18 Jan 2009 17:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJXy5lDj6lbW for ; Sun, 18 Jan 2009 17:24:46 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E23BB3A6B74 for ; Sun, 18 Jan 2009 17:24:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,285,1231113600"; d="scan'208";a="34125133" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2009 01:24:29 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0J1OTEt021590; Sun, 18 Jan 2009 20:24:29 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0J1OT4N005297; Mon, 19 Jan 2009 01:24:29 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Jan 2009 20:24:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Jan 2009 20:24:28 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACA83C@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <001001c979bf$a706b980$f5142c80$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Status of draft-ietf-mos-dhcp-options Thread-Index: Acl4NmvdHfpeDh3AT2WQBm4mZWzlJAAAMLYgADmu7UAAKD3RMAAFJCQA References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> <005201c97838$7c5dbef0$75193cd0$@net> <8E296595B6471A4689555D5D725EBB210AACA7F4@xmb-rtp-20a.amer.cisco.com> <001001c979bf$a706b980$f5142c80$@net> From: "Bernie Volz (volz)" To: "Glen Zorn" , "Subir Das" , "Ted Lemon" X-OriginalArrivalTime: 19 Jan 2009 01:24:29.0660 (UTC) FILETIME=[ACD779C0:01C979D4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1607; t=1232328269; x=1233192269; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Status=20of=20draft-ietf-mos- dhcp-options |Sender:=20 |To:=20=22Glen=20Zorn=22=20,=20=22Subir=20 Das=22=20,=0A=20=20=20=20=20=2 0=20=20=22Ted=20Lemon=22=20; bh=tE6ZqpxSsgNoL+AE7126Ekr0S0Hia++p4d7qBqTpZAA=; b=jbpZQRWxIyZzuDSpa9LgD+Vrxe+T5AkX8yg1gptqMNwpAR7ckR1MVtUXMd 4dgPqXGaCLHTDMvrToOKaYXJBfODGuilYmaGEecacifBniTW3+c24CR0K5pG rqEpamGUTE; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg , Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I wasn't answering with respect to this draft, but the general case for why a FQDN may not always be 'best'. The reason why address was used in other cases was because the DHCP client might have limited capabilities at the time the option is needed and not have a DNS 'client'. Or, there may be cases where the target ("server") does not have a FQDN. I don't know if either of these are an issue in this particular case - if these devices are assumed to always have a DNS resolver and the target a FQDN, then just providing the FQDN would be the best. - Bernie -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Sunday, January 18, 2009 5:54 PM To: Bernie Volz (volz); 'Subir Das'; 'Ted Lemon' Cc: 'Dhcwg'; 'Mipshop Chairs'; draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: RE: [dhcwg] Status of draft-ietf-mos-dhcp-options Bernie Volz (volz) [mailto:volz@cisco.com] writes: > While a DHCP server could do that, it would provide the answers at > whatever time the server resolved it (sure, I suppose it could honor > the > TTL on the data and only cache it for that long). But, that doesn't > solve the problem of why a FQDN was desired -- the option might not be > used for hours or days and by then the addresses could have changed. OK, so why the option for IP addresses? I what you say is true for the roaming case, why isn't it also true for the home network? One way or the other, it seems like one of these options make no sense... ... Play assigns meaning to human activity -- work erases it. -- P.L. Wilson _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Jan 18 21:00:22 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D653A681C; Sun, 18 Jan 2009 21:00:22 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D283A681C for ; Sun, 18 Jan 2009 21:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyaqV0VRVD-l for ; Sun, 18 Jan 2009 21:00:20 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id C8CA53A6801 for ; Sun, 18 Jan 2009 21:00:20 -0800 (PST) Received: from mailee.research.telcordia.com (mailee.research.telcordia.com [192.4.16.29]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n0J4tpmS011165; Sun, 18 Jan 2009 23:55:51 -0500 (EST) Received: from [127.0.0.1] (vpntnlBw107 [128.96.59.107]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id XAA18889; Sun, 18 Jan 2009 23:55:43 -0500 (EST) Message-ID: <497407D3.8020609@research.telcordia.com> Date: Sun, 18 Jan 2009 23:55:47 -0500 From: Subir Das User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <494E1621.3020405@piuha.net><49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net><20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com><20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <8E296595B6471A4689555D5D725EBB210AACA7F3@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210AACA7F3@xmb-rtp-20a.amer.cisco.com> Cc: draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org, Chairs , Mipshop@core3.amsl.com, Ted Lemon , Dhcwg Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie Volz (volz) wrote: > Just for the record, there are DHCP server implementations that do > support this encoding-byte + data (depending on encoding-byte) format. > > And, the RFC 3495 (CableLabs Client Configuration Option) is used by > lots of devices. > That was my understanding too. Also RFC 3361 is accepted by 3GPP IMS. > As it is used in several places, I do think the cat is out of the bag > and I think it should be usable by new options. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ted Lemon > Sent: Friday, January 16, 2009 1:25 PM > To: David W.Hankins > Cc: Dhcwg; Chairs; draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org; > Mipshop@core3.amsl.com > Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options > > On Jan 16, 2009, at 9:38 AM, David W. Hankins wrote: > >> I'm unconvinced the demand for these options is sufficient for good >> deployment, and I haven't heard of existing implementations, so I am >> not changing my guidance. I think MIPSHOP should pick one encoding >> and stick with it. >> > > I have to side with David here. I was very much against the encoding > options in the other two RFCs as well, for two reasons: > > 1. As David says, it's extra code, which nobody is going to implement > if they don't have to. > 2. It's an additional knob to turn, and chances are that it will > always be turned the same way. And so the other way won't get tested > (I wish it were not so, but client testing has historically been very, > very spotty). And then when someone does use it, it will break. If > there were some value being added, it would be one thing, but there's > no value added here - it's just a decision the protocol designer is > deciding not to make. > > My advice is to make the decision, and make it the way everyone else > does: send an IP address. If you don't agree with this decision, > please state a use case for the FQDN encoding. Not "someone might > want to do FQDN encoding for some reason" but rather "in this case > (provide a case here) it will be necessary to do FQDN encoding because > IP-address encoding won't work or has the following severe > disadvantage (explain disadvantage)." If you can't come up with one, > then the conditional flag here is not only unnecessary, but harmful. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 19 00:34:40 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88183A6B7A; Mon, 19 Jan 2009 00:34:40 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB1A3A6B7A for ; Mon, 19 Jan 2009 00:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEkCnxNWPFLy for ; Mon, 19 Jan 2009 00:34:38 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id E93BF3A6B70 for ; Mon, 19 Jan 2009 00:34:32 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSXQ69G4YA35GWnAIX2/FmE0rrFGmm6CD@postini.com; Mon, 19 Jan 2009 00:34:23 PST Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B75991B8297; Mon, 19 Jan 2009 00:34:08 -0800 (PST) Received: from [10.0.0.254] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 19 Jan 2009 00:33:56 -0800 Message-ID: <781121A5-B306-402E-B960-C6BE9F4FB9C2@nominum.com> From: Ted Lemon To: Subir Das In-Reply-To: <49711F4B.8000801@research.telcordia.com> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 01:33:53 -0700 References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> X-Mailer: Apple Mail (2.930.3) Cc: Dhcwg , Mipshop Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 16, 2009, at 4:59 PM, Subir Das wrote: > DHCP Server in the visited network is configured with the FQDN of > the provider that provides the mobility service. When MN arrives to > this > visited network, it sends the MoS option to the DHCP Server and > receives the FQDN of the provider. MN then sends the DNS query to > the provider and obtains the address of the Mobility Server (MoS). > The > FQDN of the service provider may be known > via roaming agreement. Subir and I wound up talking about this a bit offline. It appears to be the case that what is being proposed here is that in some cases it will be necessary to send the FQDN rather than the IP address because the DNS server would provide a different answer to a query coming from a mobile host than it would to the DHCP server. So essentially the motivation for the strangeness of this DHCP option is to provide a platform for standardizing incorrect behavior on the part of DNS servers. So what I suggested to Subir is that perhaps he should make a presentation explaining what he intends to the DNSOP working group and see what kind of reaction he gets to this proposal. On the surface, it seems like this is simply the wrong solution to the problem, and that perhaps a deeper rethink of the whole spec is called for. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From kane@aha.com Mon Jan 19 04:36:08 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027AF28C1AF for ; Mon, 19 Jan 2009 04:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.222 X-Spam-Level: X-Spam-Status: No, score=-11.222 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfSNPzPscIfU for ; Mon, 19 Jan 2009 04:36:07 -0800 (PST) Received: from alfainfo.fr (unknown [88.238.117.238]) by core3.amsl.com (Postfix) with SMTP id 12B2128C1AA for ; Mon, 19 Jan 2009 04:36:05 -0800 (PST) To: Subject: Re: Pfizer Company From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090119123606.12B2128C1AA@core3.amsl.com> Date: Mon, 19 Jan 2009 04:36:05 -0800 (PST)
January 16, 2009 | "SPECIAL OFFERS"-Pfizer Company!




Contact: Email Administrator, Pfizer World Headquarters 121 E. 42nd Street New York, NY 88433
® 2001-2009 Pfizer Inc. All rights reserved!
Pfizer is a licensee of the TRUSTe Privacy Program!, click here.

» Help  »Advertise  »Terms of Service  »Privacy Policy
From kaluckis@alternativesinc.org Mon Jan 19 04:50:20 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263DD28C1D0 for ; Mon, 19 Jan 2009 04:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.328 X-Spam-Level: X-Spam-Status: No, score=-30.328 tagged_above=-999 required=5 tests=[AWL=17.669, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw2TYs4pnRr4 for ; Mon, 19 Jan 2009 04:50:19 -0800 (PST) Received: from 189-015-73-013.xd-dynamic.ctbcnetsuper.com.br (189-015-73-013.xd-dynamic.ctbcnetsuper.com.br [189.15.73.13]) by core3.amsl.com (Postfix) with SMTP id 2C18C28C1C4 for ; Mon, 19 Jan 2009 04:50:17 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090119125018.2C18C28C1C4@core3.amsl.com> Date: Mon, 19 Jan 2009 04:50:17 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 14060
From kkpainsworth@7223.net Mon Jan 19 06:49:38 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637443A67DD for ; Mon, 19 Jan 2009 06:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.604 X-Spam-Level: X-Spam-Status: No, score=-7.604 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MX=0.535, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj7TLdXNJEmm for ; Mon, 19 Jan 2009 06:49:37 -0800 (PST) Received: from host-200-52-112-190.block.alestra.net.mx (host-200-52-112-190.block.alestra.net.mx [200.52.112.190]) by core3.amsl.com (Postfix) with SMTP id F2DDE3A6B98 for ; Mon, 19 Jan 2009 06:49:12 -0800 (PST) To: Subject: Re: Order status 84252 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090119144921.F2DDE3A6B98@core3.amsl.com> Date: Mon, 19 Jan 2009 06:49:12 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 65266
From jirka@air-show.cz Mon Jan 19 07:23:04 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FE63A6A05 for ; Mon, 19 Jan 2009 07:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.832 X-Spam-Level: X-Spam-Status: No, score=-26.832 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfSXgzHMz0+n for ; Mon, 19 Jan 2009 07:23:00 -0800 (PST) Received: from accenture.com (unknown [190.49.127.208]) by core3.amsl.com (Postfix) with SMTP id 2736A3A684F for ; Mon, 19 Jan 2009 07:22:58 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090119152259.2736A3A684F@core3.amsl.com> Date: Mon, 19 Jan 2009 07:22:58 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 34166
From dhcwg-bounces@ietf.org Mon Jan 19 12:43:47 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D66428C19F; Mon, 19 Jan 2009 12:43:47 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF32E28C19F for ; Mon, 19 Jan 2009 12:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aLRYLMJzflI for ; Mon, 19 Jan 2009 12:43:45 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 2509128C19E for ; Mon, 19 Jan 2009 12:43:45 -0800 (PST) Received: from david.isc.org (c-67-161-51-194.hsd1.ca.comcast.net [67.161.51.194]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n0JKhRpR019263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 12:43:28 -0800 Received: by david.isc.org (Postfix, from userid 10200) id 1FE2316E1B3; Mon, 19 Jan 2009 12:43:27 -0800 (PST) Date: Mon, 19 Jan 2009 12:43:27 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20090119204326.GB5103@isc.org> References: <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <005201c97838$7c5dbef0$75193cd0$@net> <8E296595B6471A4689555D5D725EBB210AACA7F4@xmb-rtp-20a.amer.cisco.com> <001001c979bf$a706b980$f5142c80$@net> <8E296595B6471A4689555D5D725EBB210AACA83C@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB210AACA83C@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Mipshop Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1645890905==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1645890905== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 18, 2009 at 08:24:28PM -0500, Bernie Volz (volz) wrote: > The reason why address was used in other cases was because the DHCP > client might have limited capabilities at the time the option is needed > and not have a DNS 'client'. Or, there may be cases where the target > ("server") does not have a FQDN. I wouldn't have thought so. I would say addresses are the most simple answer to the question posed by configuration, and consequently our most frequent (Keep It Simple) candidate. When I look at drafts such as these, I try to ask myself 'what benefit does the protocol gain by having the client perform DNS queries to resolve the name'? Most frequently, I find to my own inspection that there either is no benefit, or that the DNS is not unique in requirements to solve it (it can usually be solved trivially with existing tools of DHCP server configuration). I don't trust my own inspections, as I do not follow the work of other WG's closely. Back to this case's FQDN usage model to illustrate... I believe the draft currently suggests the client is expected to find NAPTR and SRV records, to my inspection providing client-based load balancing and port number assignments as benefits to the protocol. DHCP server configuration provides load balancing, and the port number assignment can be fulfilled by using a 6-octet IPv4-address-plus-port for the option formats (18-octet for v6). So one way to look at it is to ask what benefit is required that only the DNS can provide, thus providing a technical answer to why the DNS must be included as an additional moving part in this picture. Having done so, use the FQDN format as the single format for the options. Having not done so, stick with binary representations. > I don't know if either of these are an issue in this particular case - > if these devices are assumed to always have a DNS resolver and the > target a FQDN, then just providing the FQDN would be the best. Unless of course you were concerned about resource or time costs associated with the extra packet exchanges to finally result in a configured client, or the extra burden placed upon a client to make intelligent decisions (such as honoring client-based load balance methods). --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --l76fUT7nc3MelDdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFJdOXucXeLeWu2vmoRArO6AJ9XCIROekiW9uJrOG/GXX9ozWIshwCcD+C6 8q5BNUvGTp+xd87ZLp5RalU= =fzhq -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- --===============1645890905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1645890905==-- From dhcwg-bounces@ietf.org Mon Jan 19 14:07:47 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97363A6944; Mon, 19 Jan 2009 14:07:47 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FEC3A6944; Mon, 19 Jan 2009 14:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk47Todtrdg8; Mon, 19 Jan 2009 14:07:46 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 988443A6852; Mon, 19 Jan 2009 14:07:45 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDQ008NEO4705@szxga04-in.huawei.com>; Tue, 20 Jan 2009 06:07:19 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDQ0032PO47S9@szxga04-in.huawei.com>; Tue, 20 Jan 2009 06:07:19 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [212.147.29.179]) by szxmc04-in.huawei.com (mshttpd); Tue, 20 Jan 2009 06:07:19 +0800 Date: Tue, 20 Jan 2009 06:07:19 +0800 From: JiangSheng 66104 In-reply-to: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> To: "Bernie Volz (volz)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie, Thanks so much for your comments. This really helps our work become better. Our design/solution is still remaining open for better. So do comment/discuss further. Please see my reply in lines. Best regards, Sheng > I'm (still) a bit concerned about: > > 5.2. Signature Option > > The Signature option allows public key-based signatures to be > attached to a DHCPv6 message. The Signature option COULD be any place > > within the DHCPv6 message. It protects all the DHCPv6 header and > options before it. Any options after the Signature option can be > processed, but it should be noticed that they are not protected by > this Signature option. The format of the Signature option is > described as follows: > > Why is this protection positional? Can you explain why you think this is > useful? Why not secure the entire message with this? We are thinking how the receiver side is able to decide the protected part of a DHCP message in order to get the right input for verification computing. There are three possible solutions in our minds: 1, the signature option is the last-generated option, it protects all options, including itself; 2, the signature option has a set of sub-options to clear indicate which options are protected; 3, the position of the signature indicates its protected range. The first design is the best solution except for two scenarios: a, there are some options, such as the AUTH option you mentioned, request to be last generated too; b, some options may added at the end of a DHCP message after signature options has been generated. We don't have a clear example for this. But we cannot rule out the possibility. The second design is too complicated giving the fact we cannot limit the number of options. Then, the third design becomes the most reasonable one for us. > The only interesting issue is if a client's message includes both a > SIGNATURE and AUTH (RFC 3315) option -- since in this case, two > different hashes over the entire message would need to be run and that > doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH > option. (The AUTH option would include the SIGNATURE option as RFC 3315 > already requires that it cover the entire client message.) En... This is interesting. The AUTH option has already taken the last-generated position. And I assume by the time of design this, the designers already rule out the possibility that some option may request to be generated/added after AUTH option. Now, we have one, at least, it is equally to be last generated comparing the AUTH option. > I wonder whether this positional text is a hold over from DHCPv4 to > handle the Relay Agent Option (82) - which is added at the end? Relaying > in DHCPv6 is done far differently. > > If there's a reason why the SIGNATURE needs to be positional, we still > have the AUTH option conflict that would need to be discussed (if the > AUTH option isn't excluded from coverage regardless of where it appeared > in the message, it would require the AUTH to follow the SIGNATURE). En... this could be a possible answer, I guess. Both AUTH and SIGNATURE are only protects what in front of them. So, there would have no fixed order for both their positions and generation order. AUTH can be behind SIGNATURE, vice verse. This may also release the restriction "Any DHCP message MUST NOT include more than one Authentication option." [21.2, RFC 3315] > --- > > The draft allows a node to be a DHCPv6 relay agent. I think more text is > required to detail this. Suppose you have: > Client --> Relay 1 --> Relay 2 --> Server > > If Relay 1 includes a SIGNATURE option, and relay 2 does not support > this, what should the server do? How does the server know whether relay > 2 validated the SIGNATURE of Relay 1 or not (is there a requirement for > the relay to validate -- it is after all a "node")? Should the server > validate all SIGNATURE options (as in this case, there could be 3 - one > in the Client message, one in the Relay 1 message (which encapsulates > the client's message), and one in the Relay 2 message (which > encapsulates Relay 1's message (which encapsulates the client's > message))? > > Perhaps the ability for a relay to be a node should be removed? It keeps > it simpler. I agree that we should put more text to explain the process for relaying if we get sure relaying need to be protected. In the above scenario, I don't think reply agent needs to validate the SIGNATURE option unless it uses some information from its received DHCP message. The server, in this case, needs to validate all 3 SIGNATURE options. However, if relay agent does not add its only options, the signature option from it may not be very useful and the SIGNATURE options from relay agent are optional. Best regards, Sheng > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of JiangSheng 66104 > Sent: Tuesday, January 13, 2009 4:43 PM > To: cga-ext@ietf.org; dhcwg@ietf.org > Subject: [dhcwg] "Secure DHCPv6 Using CGAs" > draft-jiang-dhc-secure-dhcpv6-01 > > The below "Secure DHCPv6 Using CGAs" has been updated, according to > comments that have been discussed in dhc maillist and IETF meeting. > Since early collaboration is requested for this CGA and DHCP interaction > work, this update message is sent to both CSI WG and DHC WG. > > Best regards, > > Sheng > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Secure DHCPv6 Using CGAs > Author(s) : S. Jiang, S. Shen > Filename : draft-jiang-dhc-secure-dhcpv6-01.txt > Pages : 14 > Date : 2009-1-8 > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > DHCP servers to pass configuration parameters. It offers > configuration flexibility. If not secured, DHCPv6 is vulnerable to > various attacks, particularly fake attack. This document analyzes the > > security issues of DHCPv6 and specifies security mechanisms, mainly > using CGAs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 19 14:08:13 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1273A69E3; Mon, 19 Jan 2009 14:08:13 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702723A69CA; Mon, 19 Jan 2009 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkkMNMqO5L4b; Mon, 19 Jan 2009 14:08:10 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id DB30C3A693D; Mon, 19 Jan 2009 14:08:09 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDQ00MQSO4VYA@szxga02-in.huawei.com>; Tue, 20 Jan 2009 06:07:43 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDQ009J0O4V5P@szxga02-in.huawei.com>; Tue, 20 Jan 2009 06:07:43 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [212.147.29.179]) by szxmc04-in.huawei.com (mshttpd); Tue, 20 Jan 2009 06:07:43 +0800 Date: Tue, 20 Jan 2009 06:07:43 +0800 From: JiangSheng 66104 In-reply-to: <8E296595B6471A4689555D5D725EBB210AACA80A@xmb-rtp-20a.amer.cisco.com> To: "Bernie Volz (volz)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB210AACA80A@xmb-rtp-20a.amer.cisco.com> Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org HI, Bernie, Thanks again. Please see my reply in lines. Best regards, Sheng > I noticed that the draft is actually self conflicting in terms of the > Signature option: > > 5.2. Signature Option > > ... The Signature option COULD be any place > within the DHCPv6 message. It protects all the DHCPv6 header and > options before it. Any options after the Signature option can be > processed, but it should be noticed that they are not protected by > this Signature option. ... > > 6.1. Processing Rules of Sender > > ... The Signature option MUST be constructed as explained in > Section 5.2 and be the last DHCPv6 option. > > Again, per my earlier comments I think its position should not matter. This text in 6.1 is a careless mistake. It remains unchanged from 00 version. It will be fixed in the future version. > --- > > In 6.2. Processing Rules of Receiver: > > The receiving node MUST verify the Signature option as follows: the > receiver MUST ignore any options that come after the Signature > option. > > What about the contents of the Signature option itself? The document > needs to indicate which, if any, portion of the Signature option is > included in the signature hashing. (The SEND RFC (3791) excludes the > signature option.) Yes, this Signature option protects its own header. We describe this in the signature field of Signature option, section 5.2 > Note that earlier in section 5.2. Signature Option is written: > > 6. The content between the option-len field and > the signature field in this Signature option, in > the format described above. > > Might be best to just refer to section 5.2 instead of duplicating the > information (less chance for it to conflict)? Ok, we will add quotation there to make it clearer. > --- > > This probably exposes my ignorance of CGAs, but is the intent in this > draft that the CGA source address used by the client remains the (CGA) > link-local address? > > If this is the case (client uses CGA link-local as IPv6 source address), > all is well. > > If the CGA address is not the link-local, then there is a conflict with > RFC 3315: > > 16. Client Source Address and Interface Selection > > When a client sends a DHCP message to the > All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message > through the interface for which configuration information is being > requested. However, the client MAY send the message through another > interface attached to the same link, if and only if the client is > -> certain the two interfaces are attached to the same link. The client > -> MUST use a link-local address assigned to the interface for which it > -> is requesting configuration information as the source address in the > -> header of the IP datagram. > > When a client sends a DHCP message directly to a server using unicast > (after receiving the Server Unicast option from that server), the > source address in the header of the IP datagram MUST be an address > assigned to the interface for which the client is interested in > obtaining configuration and which is suitable for use by the server > in responding to the client. > > A non-link-local address is only allowed if the server previously > provided the client with the Server Unicast option. I believe we are talking about link-local CGAs here. However, "link-local (CGA) addresses are vulnerable because the same prefix is used by all IPv6 node", [section 7.2, rfc 3972]. Fortunately, the same section provides a hash extension mechanism to protect link-local address. > --- > > The following text is rather odd: > > If a node has been configured to use Secure DHCPv6, the node MUST > send a message using a CGA, which be constructed as specified in > Section 4 of [RFC3972], as the source address unless they are sent > -> with the unspecified source address. In the message, both the CGA > option and the Signature option MUST be present in all DHCPv6 > messages. The CGA Parameter field in the CGA option is filled > according to the rules presented above and in [RFC3972]. The public > key in the field is taken from the configuration used to generate the > > CGA, typically from a data structure associated with the source > address. The Signature option MUST be constructed as explained in > Section 5.2 and be the last DHCPv6 option. > > DHCPv6 never uses an unspecified source address. This came from the similar claim in SEND. Ok, "unless they are sent > -> with the unspecified source address" will be revomed. > Also be good to use "CGA Parameter option" instead of "CGA option", as > that is what the option is called. This is an issue throughout the > document. Will change it. "CGA Parameter option" is the name to be. My thanks, again. Best regards, Sheng > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bernie Volz (volz) > Sent: Saturday, January 17, 2009 11:03 PM > To: JiangSheng 66104; cga-ext@ietf.org; dhcwg@ietf.org > Subject: Re: [dhcwg] "Secure DHCPv6 Using > CGAs"draft-jiang-dhc-secure-dhcpv6-01 > > I'm (still) a bit concerned about: > > 5.2. Signature Option > > The Signature option allows public key-based signatures to be > attached to a DHCPv6 message. The Signature option COULD be any place > > within the DHCPv6 message. It protects all the DHCPv6 header and > options before it. Any options after the Signature option can be > processed, but it should be noticed that they are not protected by > this Signature option. The format of the Signature option is > described as follows: > > Why is this protection positional? Can you explain why you think this is > useful? Why not secure the entire message with this? > > The only interesting issue is if a client's message includes both a > SIGNATURE and AUTH (RFC 3315) option -- since in this case, two > different hashes over the entire message would need to be run and that > doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH > option. (The AUTH option would include the SIGNATURE option as RFC 3315 > already requires that it cover the entire client message.) > > I wonder whether this positional text is a hold over from DHCPv4 to > handle the Relay Agent Option (82) - which is added at the end? Relaying > in DHCPv6 is done far differently. > > If there's a reason why the SIGNATURE needs to be positional, we still > have the AUTH option conflict that would need to be discussed (if the > AUTH option isn't excluded from coverage regardless of where it appeared > in the message, it would require the AUTH to follow the SIGNATURE). > > --- > > The draft allows a node to be a DHCPv6 relay agent. I think more text is > required to detail this. Suppose you have: > Client --> Relay 1 --> Relay 2 --> Server > > If Relay 1 includes a SIGNATURE option, and relay 2 does not support > this, what should the server do? How does the server know whether relay > 2 validated the SIGNATURE of Relay 1 or not (is there a requirement for > the relay to validate -- it is after all a "node")? Should the server > validate all SIGNATURE options (as in this case, there could be 3 - one > in the Client message, one in the Relay 1 message (which encapsulates > the client's message), and one in the Relay 2 message (which > encapsulates Relay 1's message (which encapsulates the client's > message))? > > Perhaps the ability for a relay to be a node should be removed? It keeps > it simpler. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of JiangSheng 66104 > Sent: Tuesday, January 13, 2009 4:43 PM > To: cga-ext@ietf.org; dhcwg@ietf.org > Subject: [dhcwg] "Secure DHCPv6 Using CGAs" > draft-jiang-dhc-secure-dhcpv6-01 > > The below "Secure DHCPv6 Using CGAs" has been updated, according to > comments that have been discussed in dhc maillist and IETF meeting. > Since early collaboration is requested for this CGA and DHCP interaction > work, this update message is sent to both CSI WG and DHC WG. > > Best regards, > > Sheng > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Secure DHCPv6 Using CGAs > Author(s) : S. Jiang, S. Shen > Filename : draft-jiang-dhc-secure-dhcpv6-01.txt > Pages : 14 > Date : 2009-1-8 > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > DHCP servers to pass configuration parameters. It offers > configuration flexibility. If not secured, DHCPv6 is vulnerable to > various attacks, particularly fake attack. This document analyzes the > > security issues of DHCPv6 and specifies security mechanisms, mainly > using CGAs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 19 14:32:54 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550123A6934; Mon, 19 Jan 2009 14:32:54 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BE93A6806; Mon, 19 Jan 2009 14:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAOLxqU+iq45; Mon, 19 Jan 2009 14:32:47 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E95093A6934; Mon, 19 Jan 2009 14:32:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,291,1231113600"; d="scan'208";a="34208106" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2009 22:32:30 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0JMWUjG027175; Mon, 19 Jan 2009 17:32:30 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0JMWUd8003445; Mon, 19 Jan 2009 22:32:30 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 17:32:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 17:32:29 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACA94F@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 Thread-Index: Acl6gl+2oBUVWFEUTlC4s9U9vvFhtQAAQFPQ References: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> From: "Bernie Volz (volz)" To: "JiangSheng 66104" X-OriginalArrivalTime: 19 Jan 2009 22:32:30.0495 (UTC) FILETIME=[D08D9AF0:01C97A85] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9543; t=1232404350; x=1233268350; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20RE=3A=20[dhcwg]=20=20=22Secure=20DHCPv6 =20Using=20CGAs=22=20draft-jiang-dhc-secure-dhcpv6-01 |Sender:=20 |To:=20=22JiangSheng=2066104=22=20; bh=uIr6iJfiJu3nQCqsJDe/dehGHd2bl3LYhDBOqFXFs34=; b=oCn+4iIjDgvvKOTlLMw7kSWq6peuDb9tshaIsNPJURyc/j54/OqmUmgju4 6Sfc8faWa3QSC454hQGeTCQijuxlovQnGvcaDZfP73ugtvJ3o0sB95VQw/D3 inQCVzzAuS; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Note that while the AUTH option needs to be generated last (since it covers the entire message), it does not have to be the LAST option in the message. In DHCPv6, no entity (relay agent or server) adds options to the messages while it is 'in-flight' as is done for the DHCPv4 relay agent option. Once the message is formed, a relay may encapsulate it in a Relay Message option in its own message, but that does NOT alter the original message. I think: - CGA Signature can be anywhere in the message. - CGA Signature covers the ENTIRE message EXCEPT for some of its own fields and the AUTH option. - The AUTH option covers the ENTIRE message, including the CGA Signature option. This way, the AUTH gives complete protection of the entire message as it was intended to. I'm not sure if it will be common for the SIGNATURE and AUTH to be used together, as it seems to me that using the AUTH message gives the better protection to begin with. But, if they are used together, it works. I'd also highly recommend the CGA stuff be limited to clients and servers (a client can add/server validate). Note that a server can NOT use this for to provide proof of a CGA (the server's source address) because this ONLY works when the client and server are on the same link. If a relay agent is involved, the source address of the packet sent to the client is a relay agent address and thus the Signature would never validate. This I think makes this much simpler (though perhaps it defeats some of the purpose). --- I also haven't yet figured out (again, perhaps due to my lack of fully understanding all of this CGA stuff) what the benefit of this is. It seems to me that if a client needs a public and private key, and the server needs the public key, that using the AUTH option could be possible and would be far better? Perhaps all you need here is a mechanism for the key to be communicated -- which might mean new values of the AUTH Option protocol and algorithm fields and a definition for what is in the "authentication information". Also, this might then allow client-to-server and server-to-client authentication since the "CGA" is itself not involved. And, perhaps this works better to match the SEND model which is (if I recall correctly) where the router is using a CGA and wants to prove that it is a valid router to the client -- so, you ideally want the DHCPv6 server to prove that is a valid DHCPv6 server to the client (and the client only needs the public key -- not a private key). Thus, the server-to-client authentication is really of the most interest? And, this would now work (whereas it does not using the original design). - Bernie -----Original Message----- From: JiangSheng 66104 [mailto:shengjiang@huawei.com] Sent: Monday, January 19, 2009 5:07 PM To: Bernie Volz (volz) Cc: cga-ext@ietf.org; dhcwg@ietf.org; shengjiang@huawei.com Subject: Re: RE: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 Bernie, Thanks so much for your comments. This really helps our work become better. Our design/solution is still remaining open for better. So do comment/discuss further. Please see my reply in lines. Best regards, Sheng > I'm (still) a bit concerned about: > > 5.2. Signature Option > > The Signature option allows public key-based signatures to be > attached to a DHCPv6 message. The Signature option COULD be any place > > within the DHCPv6 message. It protects all the DHCPv6 header and > options before it. Any options after the Signature option can be > processed, but it should be noticed that they are not protected by > this Signature option. The format of the Signature option is > described as follows: > > Why is this protection positional? Can you explain why you think this is > useful? Why not secure the entire message with this? We are thinking how the receiver side is able to decide the protected part of a DHCP message in order to get the right input for verification computing. There are three possible solutions in our minds: 1, the signature option is the last-generated option, it protects all options, including itself; 2, the signature option has a set of sub-options to clear indicate which options are protected; 3, the position of the signature indicates its protected range. The first design is the best solution except for two scenarios: a, there are some options, such as the AUTH option you mentioned, request to be last generated too; b, some options may added at the end of a DHCP message after signature options has been generated. We don't have a clear example for this. But we cannot rule out the possibility. The second design is too complicated giving the fact we cannot limit the number of options. Then, the third design becomes the most reasonable one for us. > The only interesting issue is if a client's message includes both a > SIGNATURE and AUTH (RFC 3315) option -- since in this case, two > different hashes over the entire message would need to be run and that > doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH > option. (The AUTH option would include the SIGNATURE option as RFC 3315 > already requires that it cover the entire client message.) En... This is interesting. The AUTH option has already taken the last-generated position. And I assume by the time of design this, the designers already rule out the possibility that some option may request to be generated/added after AUTH option. Now, we have one, at least, it is equally to be last generated comparing the AUTH option. > I wonder whether this positional text is a hold over from DHCPv4 to > handle the Relay Agent Option (82) - which is added at the end? Relaying > in DHCPv6 is done far differently. > > If there's a reason why the SIGNATURE needs to be positional, we still > have the AUTH option conflict that would need to be discussed (if the > AUTH option isn't excluded from coverage regardless of where it appeared > in the message, it would require the AUTH to follow the SIGNATURE). En... this could be a possible answer, I guess. Both AUTH and SIGNATURE are only protects what in front of them. So, there would have no fixed order for both their positions and generation order. AUTH can be behind SIGNATURE, vice verse. This may also release the restriction "Any DHCP message MUST NOT include more than one Authentication option." [21.2, RFC 3315] > --- > > The draft allows a node to be a DHCPv6 relay agent. I think more text is > required to detail this. Suppose you have: > Client --> Relay 1 --> Relay 2 --> Server > > If Relay 1 includes a SIGNATURE option, and relay 2 does not support > this, what should the server do? How does the server know whether relay > 2 validated the SIGNATURE of Relay 1 or not (is there a requirement for > the relay to validate -- it is after all a "node")? Should the server > validate all SIGNATURE options (as in this case, there could be 3 - one > in the Client message, one in the Relay 1 message (which encapsulates > the client's message), and one in the Relay 2 message (which > encapsulates Relay 1's message (which encapsulates the client's > message))? > > Perhaps the ability for a relay to be a node should be removed? It keeps > it simpler. I agree that we should put more text to explain the process for relaying if we get sure relaying need to be protected. In the above scenario, I don't think reply agent needs to validate the SIGNATURE option unless it uses some information from its received DHCP message. The server, in this case, needs to validate all 3 SIGNATURE options. However, if relay agent does not add its only options, the signature option from it may not be very useful and the SIGNATURE options from relay agent are optional. Best regards, Sheng > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of JiangSheng 66104 > Sent: Tuesday, January 13, 2009 4:43 PM > To: cga-ext@ietf.org; dhcwg@ietf.org > Subject: [dhcwg] "Secure DHCPv6 Using CGAs" > draft-jiang-dhc-secure-dhcpv6-01 > > The below "Secure DHCPv6 Using CGAs" has been updated, according to > comments that have been discussed in dhc maillist and IETF meeting. > Since early collaboration is requested for this CGA and DHCP interaction > work, this update message is sent to both CSI WG and DHC WG. > > Best regards, > > Sheng > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Secure DHCPv6 Using CGAs > Author(s) : S. Jiang, S. Shen > Filename : draft-jiang-dhc-secure-dhcpv6-01.txt > Pages : 14 > Date : 2009-1-8 > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > DHCP servers to pass configuration parameters. It offers > configuration flexibility. If not secured, DHCPv6 is vulnerable to > various attacks, particularly fake attack. This document analyzes the > > security issues of DHCPv6 and specifies security mechanisms, mainly > using CGAs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 19 21:55:28 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D31F3A6A25; Mon, 19 Jan 2009 21:55:28 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502A43A6A25 for ; Mon, 19 Jan 2009 21:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar-dQtc-b8UM for ; Mon, 19 Jan 2009 21:55:25 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 5F2CA3A6846 for ; Mon, 19 Jan 2009 21:55:18 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSXVnNMLRYrsi0bemAwfEqWvBl2FDs5ib@postini.com; Mon, 19 Jan 2009 21:55:09 PST Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ECE9E1B8247; Mon, 19 Jan 2009 21:55:12 -0800 (PST) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 19 Jan 2009 21:55:00 -0800 Message-ID: <1BDFDA15-98AC-4DC1-8DCC-53DE6CB6C0CE@nominum.com> From: Ted Lemon To: Vijay Devarapalli In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 22:54:58 -0700 References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <8E296595B6471A4689555D5D725EBB210AACA7F3@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" , "Bernie Volz \(volz\)" , Chairs , Dhcwg Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 19, 2009, at 6:02 PM, Vijay Devarapalli wrote: > It is not clear to me why the DHC WG is discussing the scenarios for > MIH server discovery. Because we would like to understand the requirement for the complex option you have proposed, and specifically why the simpler version we have suggested is not acceptable. > For more information on the scenarios, see > http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-11.txt > . > This document is also currently with the IESG. Right, it appears that the two scenarios you are trying to address are the ones in sections 5.1 and 5.2. Neither of these appears to require that the DHCP server send an FQDN to the client. > For those who are not familiar with how DNS is used in cellular > networks, the FQDN can change quite a bit based on the roaming > scenarios. If the FQDN is what is varying, then there is no need to send the FQDN, since it doesn't matter where the resolution happens. As a matter of practice, DHCP servers are normally configured with FQDNs, and resolve them on demand, before responding to DHCP clients. So in the cases you've described, the only avenue whereby the FQDN can be communicated to the DHCP client is through the DHCP server, and since the DHCP server can resolve the FQDN itself, there is no need for the option to support the added complexity of being able to send either an IP address or an FQDN - the IP address is completely sufficient. > Please be assured that we do need the capability to convey either the > IP address or the FQDN of the MIH server to the mobile node via DHCP. The point of us (the DHC working group) reviewing these drafts is that we have a lot of knowledge about best practices for DHCP. Based on the draft you've asked us to review, and the draft you suggested we look at just now, there appears to be no such requirement. I'm sorry to be pushing back like this - I know you have work to do and would like this to proceed with as few roadblocks as possible. The reason I'm advising you to make the change I've suggested (sending only the IP address) is that I think that in the long run this will get you to reliable, widely deployed, interoperable running code sooner. If you do have a real requirement for the ability to switch between FQDNs and IP addresses in the option, then you don't have a choice. But as far as I can tell you do have a choice, and I'd really encourage you to consider taking the easier option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 19 22:20:07 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0473A6941; Mon, 19 Jan 2009 22:20:07 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7413A6941 for ; Mon, 19 Jan 2009 22:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJWrwAwY4OGa for ; Mon, 19 Jan 2009 22:20:05 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 494913A67FB for ; Mon, 19 Jan 2009 22:20:05 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 955B6198753; Tue, 20 Jan 2009 08:19:48 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 3567519871F; Tue, 20 Jan 2009 08:19:48 +0200 (EET) Message-ID: <49756CC7.8020606@piuha.net> Date: Tue, 20 Jan 2009 08:18:47 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ted Lemon References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> <781121A5-B306-402E-B960-C6BE9F4FB9C2@nominum.com> In-Reply-To: <781121A5-B306-402E-B960-C6BE9F4FB9C2@nominum.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , Mipshop Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I don't think we have the non-standard DNS behaviour in any of the IETF specifications around this functionality. Of course, I cannot guarantee that people are not doing it in their specific deployments, nor have I read the IEEE 802.21 spec in its entirety. Let me know if I have missed something... In any case, my preliminary conclusion from the earlier part of this thread is that conditional formats in DHCP options are not necessarily a good idea. That still leaves it possible for us to do both an address based option and a FQDN based option, if we really need them. But I agree with Ted that this is a good time to re-evaluate whether both are actually needed. If you read mipshop-mos-dns-discovery and mipshop-mstp-solution, you'll see that there's quite a bit of SRV, NAPTR etc machinery* around this as well. I don't think we have all the mechanisms in the DHCP option to replace these (e.g., choice between TCP and UDP, port numbers). But I have not seen a convincing argument why an FQDN-only DHCP option would be problematic. Even in situations where you will be delivering the address of a local server, presumably that local server is also in the DNS, so passing a FQDN would also be fine. Jari *) Not all of it is yet in shape to move forward. Ignore those details for the purposes of this discussion. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 20 01:06:15 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C573A6BA8; Tue, 20 Jan 2009 01:06:15 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3CA28C139 for ; Tue, 20 Jan 2009 01:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmc4KHU5GpFy for ; Tue, 20 Jan 2009 01:06:10 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 7C36928C126 for ; Tue, 20 Jan 2009 01:06:00 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSXWT5mM5Az2HEGaGwws3ZMXyzAHwp0Wi@postini.com; Tue, 20 Jan 2009 01:05:54 PST Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1AB271B8248; Tue, 20 Jan 2009 01:05:55 -0800 (PST) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Tue, 20 Jan 2009 01:05:42 -0800 Message-ID: From: Ted Lemon To: Jari Arkko In-Reply-To: <49756CC7.8020606@piuha.net> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 02:05:40 -0700 References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> <781121A5-B306-402E-B960-C6BE9F4FB9C2@nominum.com> <49756CC7.8020606@piuha.net> X-Mailer: Apple Mail (2.930.3) Cc: Dhcwg , Chairs , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" , Mipshop@core3.amsl.com Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 19, 2009, at 11:18 PM, Jari Arkko wrote: > But I have not seen a convincing argument why an FQDN-only DHCP option > would be problematic. Even in situations where you will be delivering > the address of a local server, presumably that local server is also in > the DNS, so passing a FQDN would also be fine. The only reasons to avoid FQDN-only are that it takes more space in the packet (possibly not an issue here, but I don't have a clear picture) and that it requires the client to do name resolution (obviously not a problem here). I tend to recommend the IP-address mechanism because of packet space and ease of implementation on the client, but you're right that there's no strong reason to choose one over the other. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 20 02:40:36 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E0C28C137; Tue, 20 Jan 2009 02:40:36 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8069F3A6BBA; Tue, 20 Jan 2009 02:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krRhhHtYdTzB; Tue, 20 Jan 2009 02:40:34 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BD16A3A698D; Tue, 20 Jan 2009 02:40:33 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDR00AJBMYVQI@szxga04-in.huawei.com>; Tue, 20 Jan 2009 18:40:07 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDR00JBXMYUUV@szxga04-in.huawei.com>; Tue, 20 Jan 2009 18:40:07 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [212.147.29.179]) by szxmc04-in.huawei.com (mshttpd); Tue, 20 Jan 2009 18:40:06 +0800 Date: Tue, 20 Jan 2009 18:40:06 +0800 From: JiangSheng 66104 In-reply-to: <8E296595B6471A4689555D5D725EBB210AACA94F@xmb-rtp-20a.amer.cisco.com> To: "Bernie Volz (volz)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB210AACA94F@xmb-rtp-20a.amer.cisco.com> Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org See my reply in lines. Cheers, Sheng > Note that while the AUTH option needs to be generated last (since it > covers the entire message), it does not have to be the LAST option in > the message. I understand this. Now, the problem is, for the same reason =96 to protect = all DHCP message, including AUTH option, the Signature option wants to be g= enerated after AUTH option. > In DHCPv6, no entity (relay agent or server) adds options to the > messages while it is 'in-flight' as is done for the DHCPv4 relay agent > option. Once the message is formed, a relay may encapsulate it in a > Relay Message option in its own message, but that does NOT alter the > original message. This is fine. I knew it. Again, the point is two options both want to be ge= nerated after another one. > I think: > - CGA Signature can be anywhere in the message. > - CGA Signature covers the ENTIRE message EXCEPT for some of its own > fields and the AUTH option. > - The AUTH option covers the ENTIRE message, including the CGA Signature > option. > = > This way, the AUTH gives complete protection of the entire message as it > was intended to. Yes, this can work. But one assumption you take here is AUTH provide more p= rotection. I am not convinced yet. For me, AUTH and Signature have differen= t purposes and it is not suitable to say one is safer than another one. The= y should be equal. Only one reason I can think out: AUTH has been clearly d= efined to be last-generated and we don=92t want change the existing. If so,= I am fine with above design. > I'm not sure if it will be common for the SIGNATURE and AUTH to be used > together, as it seems to me that using the AUTH message gives the better > protection to begin with. But, if they are used together, it works. > = > I'd also highly recommend the CGA stuff be limited to clients and > servers (a client can add/server validate). Note that a server can NOT > use this for to provide proof of a CGA (the server's source address) > because this ONLY works when the client and server are on the same link. > If a relay agent is involved, the source address of the packet sent to > the client is a relay agent address and thus the Signature would never > validate. Are you suggestion to disable signature option to be used in relay message?= This is fine, if the relay agent does not add its own options. However, if= the relay agent does add some options, these options need to be protected = too. In this case, the client has two signature options to be validated: fi= rst one from the relay agent, the second one is from the server within the = encapsulated server message. However, I noticed that even the first one fai= led, the second one might success. This is something I am not very sure yet= . For me, it seems mean options from relay agent are unsecure, but the opti= ons from server are secure. > This I think makes this much simpler (though perhaps it defeats some of > the purpose). > = > --- > = > I also haven't yet figured out (again, perhaps due to my lack of fully > understanding all of this CGA stuff) what the benefit of this is. It > seems to me that if a client needs a public and private key, and the > server needs the public key, that using the AUTH option could be > possible and would be far better? Perhaps all you need here is a > mechanism for the key to be communicated -- which might mean new values > of the AUTH Option protocol and algorithm fields and a definition for > what is in the "authentication information". Also, this might then allow > client-to-server and server-to-client authentication since the "CGA" is > itself not involved. This is not about public key provision or distribution. It is after key has= been configured. Servers and clients can validate the identity of message = sender and the integrity of the message. > And, perhaps this works better to match the SEND model which is (if I > recall correctly) where the router is using a CGA and wants to prove > that it is a valid router to the client -- so, you ideally want the > DHCPv6 server to prove that is a valid DHCPv6 server to the client (and > the client only needs the public key -- not a private key). Thus, the > server-to-client authentication is really of the most interest? And, > this would now work (whereas it does not using the original design). Yes, this is one of the major scenarios. Also the client-to-server authenti= cation is also important, to verify the client has the right to access and = receive the service from the network/DHCP server. Regards, Sheng > -----Original Message----- > From: JiangSheng 66104 [mailto:shengjiang@huawei.com] > Sent: Monday, January 19, 2009 5:07 PM > To: Bernie Volz (volz) > Cc: cga-ext@ietf.org; dhcwg@ietf.org; shengjiang@huawei.com > Subject: Re: RE: [dhcwg] "Secure DHCPv6 Using CGAs" > draft-jiang-dhc-secure-dhcpv6-01 > = > Bernie, > = > Thanks so much for your comments. This really helps our work become > better. Our design/solution is still remaining open for better. So do > comment/discuss further. Please see my reply in lines. > = > Best regards, > = > Sheng > = > > I'm (still) a bit concerned about: > > > > 5.2. Signature Option > > > > The Signature option allows public key-based signatures to be > > attached to a DHCPv6 message. The Signature option COULD be any > place > > > > within the DHCPv6 message. It protects all the DHCPv6 header and > > options before it. Any options after the Signature option can be > > processed, but it should be noticed that they are not protected by > > this Signature option. The format of the Signature option is > > described as follows: > > > > Why is this protection positional? Can you explain why you think this > is > > useful? Why not secure the entire message with this? > = > We are thinking how the receiver side is able to decide the protected > part of a DHCP message in order to get the right input for verification > computing. There are three possible solutions in our minds: 1, the > signature option is the last-generated option, it protects all options, > including itself; 2, the signature option has a set of sub-options to > clear indicate which options are protected; 3, the position of the > signature indicates its protected range. > = > The first design is the best solution except for two scenarios: a, there > are some options, such as the AUTH option you mentioned, request to be > last generated too; b, some options may added at the end of a DHCP > message after signature options has been generated. We don't have a > clear example for this. But we cannot rule out the possibility. The > second design is too complicated giving the fact we cannot limit the > number of options. Then, the third design becomes the most reasonable > one for us. > = > > The only interesting issue is if a client's message includes both a > > SIGNATURE and AUTH (RFC 3315) option -- since in this case, two > > different hashes over the entire message would need to be run and that > > doesn't work. So, I think the SIGNATURE option MUST NOT include the > AUTH > > option. (The AUTH option would include the SIGNATURE option as RFC > 3315 > > already requires that it cover the entire client message.) > = > En... This is interesting. The AUTH option has already taken the > last-generated position. And I assume by the time of design this, the > designers already rule out the possibility that some option may request > to be generated/added after AUTH option. Now, we have one, at least, it > is equally to be last generated comparing the AUTH option. > = > > I wonder whether this positional text is a hold over from DHCPv4 to > > handle the Relay Agent Option (82) - which is added at the end? > Relaying > > in DHCPv6 is done far differently. > > > > If there's a reason why the SIGNATURE needs to be positional, we still > > have the AUTH option conflict that would need to be discussed (if the > > AUTH option isn't excluded from coverage regardless of where it > appeared > > in the message, it would require the AUTH to follow the SIGNATURE). > = > En... this could be a possible answer, I guess. Both AUTH and SIGNATURE > are only protects what in front of them. So, there would have no fixed > order for both their positions and generation order. AUTH can be behind > SIGNATURE, vice verse. This may also release the restriction "Any DHCP > message MUST NOT include more than one Authentication option." [21.2, > RFC 3315] > = > > --- > > > > The draft allows a node to be a DHCPv6 relay agent. I think more text > is > > required to detail this. Suppose you have: > > Client --> Relay 1 --> Relay 2 --> Server > > > > If Relay 1 includes a SIGNATURE option, and relay 2 does not support > > this, what should the server do? How does the server know whether > relay > > 2 validated the SIGNATURE of Relay 1 or not (is there a requirement > for > > the relay to validate -- it is after all a "node")? Should the server > > validate all SIGNATURE options (as in this case, there could be 3 - > one > > in the Client message, one in the Relay 1 message (which encapsulates > > the client's message), and one in the Relay 2 message (which > > encapsulates Relay 1's message (which encapsulates the client's > > message))? > > > > Perhaps the ability for a relay to be a node should be removed? It > keeps > > it simpler. > = > I agree that we should put more text to explain the process for relaying > if we get sure relaying need to be protected. In the above scenario, I > don't think reply agent needs to validate the SIGNATURE option unless it > uses some information from its received DHCP message. The server, in > this case, needs to validate all 3 SIGNATURE options. However, if relay > agent does not add its only options, the signature option from it may > not be very useful and the SIGNATURE options from relay agent are > optional. > = > Best regards, > = > Sheng > = > > - Bernie > > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > > Of JiangSheng 66104 > > Sent: Tuesday, January 13, 2009 4:43 PM > > To: cga-ext@ietf.org; dhcwg@ietf.org > > Subject: [dhcwg] "Secure DHCPv6 Using CGAs" > > draft-jiang-dhc-secure-dhcpv6-01 > > > > The below "Secure DHCPv6 Using CGAs" has been updated, according to > > comments that have been discussed in dhc maillist and IETF meeting. > > Since early collaboration is requested for this CGA and DHCP > interaction > > work, this update message is sent to both CSI WG and DHC WG. > > > > Best regards, > > > > Sheng > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Secure DHCPv6 Using CGAs > > Author(s) : S. Jiang, S. Shen > > Filename : draft-jiang-dhc-secure-dhcpv6-01.txt > > Pages : 14 > > Date : 2009-1-8 > > > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > > DHCP servers to pass configuration parameters. It offers > > configuration flexibility. If not secured, DHCPv6 is vulnerable to > > various attacks, particularly fake attack. This document analyzes > the > > > > security issues of DHCPv6 and specifies security mechanisms, mainly > > using CGAs. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 20 11:37:31 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA8A3A6BC6; Tue, 20 Jan 2009 11:37:31 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8246D3A69CF; Tue, 20 Jan 2009 11:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.306 X-Spam-Level: X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF1pw-p7t4rr; Tue, 20 Jan 2009 11:37:28 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7214D28C0E9; Tue, 20 Jan 2009 11:37:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,296,1231113600"; d="scan'208";a="34307364" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Jan 2009 19:37:11 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0KJbBLa000853; Tue, 20 Jan 2009 14:37:11 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0KJbB3I026385; Tue, 20 Jan 2009 19:37:11 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 14:37:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 14:37:10 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACACCD@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: RE: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 Thread-Index: Acl6633gmd5syA3xR7iVg5fxJWmChAASa86w References: <8E296595B6471A4689555D5D725EBB210AACA7F5@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB210AACA94F@xmb-rtp-20a.amer.cisco.com> From: "Bernie Volz (volz)" To: "JiangSheng 66104" X-OriginalArrivalTime: 20 Jan 2009 19:37:11.0151 (UTC) FILETIME=[7CF2D7F0:01C97B36] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13730; t=1232480231; x=1233344231; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20RE=3A=20RE=3A=20[dhcwg]=20=20=22Secure= 20DHCPv6=20Using=20CGAs=22=20draft-jiang-dhc-secure-dhcpv6-0 1 |Sender:=20 |To:=20=22JiangSheng=2066104=22=20; bh=rgXYSmNcvLA4Hki8nZFgPtqNKFHD4ScIlIvizHd/K4Y=; b=NbM5U1C51dll0FYuun54ChOnqvNLbpSwB+yd2tKcRwbm0NHNdFOx+qjOv1 Vzz5VwWjnbyRUm1iM8FWn1J4ZdepfnoCDL4EknIyvj78BP3gdOj/tRF5VzVk LpTrVQpC5i; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org See below (BV>). - Bernie -----Original Message----- From: JiangSheng 66104 [mailto:shengjiang@huawei.com] Sent: Tuesday, January 20, 2009 5:40 AM To: Bernie Volz (volz) Cc: cga-ext@ietf.org; dhcwg@ietf.org; shengjiang@huawei.com Subject: Re: RE: RE: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 See my reply in lines. Cheers, Sheng > Note that while the AUTH option needs to be generated last (since it > covers the entire message), it does not have to be the LAST option in > the message. I understand this. Now, the problem is, for the same reason - to protect all DHCP message, including AUTH option, the Signature option wants to be generated after AUTH option. BV> One of the has to go last. I think the AUTH should - period. > In DHCPv6, no entity (relay agent or server) adds options to the > messages while it is 'in-flight' as is done for the DHCPv4 relay agent > option. Once the message is formed, a relay may encapsulate it in a > Relay Message option in its own message, but that does NOT alter the > original message. This is fine. I knew it. Again, the point is two options both want to be generated after another one. > I think: > - CGA Signature can be anywhere in the message. > - CGA Signature covers the ENTIRE message EXCEPT for some of its own > fields and the AUTH option. > - The AUTH option covers the ENTIRE message, including the CGA Signature > option. > > This way, the AUTH gives complete protection of the entire message as it > was intended to. Yes, this can work. But one assumption you take here is AUTH provide more protection. I am not convinced yet. For me, AUTH and Signature have different purposes and it is not suitable to say one is safer than another one. They should be equal. Only one reason I can think out: AUTH has been clearly defined to be last-generated and we don't want change the existing. If so, I am fine with above design. > I'm not sure if it will be common for the SIGNATURE and AUTH to be used > together, as it seems to me that using the AUTH message gives the better > protection to begin with. But, if they are used together, it works. > > I'd also highly recommend the CGA stuff be limited to clients and > servers (a client can add/server validate). Note that a server can NOT > use this for to provide proof of a CGA (the server's source address) > because this ONLY works when the client and server are on the same link. > If a relay agent is involved, the source address of the packet sent to > the client is a relay agent address and thus the Signature would never > validate. Are you suggestion to disable signature option to be used in relay message? This is fine, if the relay agent does not add its own options. However, if the relay agent does add some options, these options need to be protected too. In this case, the client has two signature options to be validated: first one from the relay agent, the second one is from the server within the encapsulated server message. However, I noticed that even the first one failed, the second one might success. This is something I am not very sure yet. For me, it seems mean options from relay agent are unsecure, but the options from server are secure. BV> No, I am not suggesting double signature. I'm suggesting that CGA from *SERVER* to *CLIENT* will not work if a relay agent is involved as you have defined the Signature to include: 2. The 128-bit Source Address field from the IP header. BV> And, while the server can generate the signature using its source address, the client will NOT receive the server's source address (if relayed) and hence can never validate the signature option. So, this is seriously flawed. BV> Review the DHCPv6 protocol document (RFC 3315), especially section 20. Relay Agent Behavior. Even if this were DHCPv4, this would not work when relay agents are involved. > This I think makes this much simpler (though perhaps it defeats some of > the purpose). > > --- > > I also haven't yet figured out (again, perhaps due to my lack of fully > understanding all of this CGA stuff) what the benefit of this is. It > seems to me that if a client needs a public and private key, and the > server needs the public key, that using the AUTH option could be > possible and would be far better? Perhaps all you need here is a > mechanism for the key to be communicated -- which might mean new values > of the AUTH Option protocol and algorithm fields and a definition for > what is in the "authentication information". Also, this might then allow > client-to-server and server-to-client authentication since the "CGA" is > itself not involved. This is not about public key provision or distribution. It is after key has been configured. Servers and clients can validate the identity of message sender and the integrity of the message. BV> Exactly ... The problem with the RFC 3315 AUTH Option is the key distribution problem. With CGA, you assume that they keys are already distributed. So, bingo -- use these keys with the AUTH option (forget about validating the CGA -- validate the client/server interaction, either in one direction or both). If keys are already available to do CGA, let's use them for DHCPv6 AUTH and we avoid yet another key distribution requirement and can bootstrap DHCPv6 AUTH to get it more widely deployed. This also matches one of the key requirements in networks where clients need correct ROUTING and ADDRESSING information. SEND can distribute routing information and then DHCPv6 (with the keys used for CGA used by the server/client) to validate DHCPv6 messages (from server to client or client to server or both). > And, perhaps this works better to match the SEND model which is (if I > recall correctly) where the router is using a CGA and wants to prove > that it is a valid router to the client -- so, you ideally want the > DHCPv6 server to prove that is a valid DHCPv6 server to the client (and > the client only needs the public key -- not a private key). Thus, the > server-to-client authentication is really of the most interest? And, > this would now work (whereas it does not using the original design). Yes, this is one of the major scenarios. Also the client-to-server authentication is also important, to verify the client has the right to access and receive the service from the network/DHCP server. Regards, Sheng > -----Original Message----- > From: JiangSheng 66104 [mailto:shengjiang@huawei.com] > Sent: Monday, January 19, 2009 5:07 PM > To: Bernie Volz (volz) > Cc: cga-ext@ietf.org; dhcwg@ietf.org; shengjiang@huawei.com > Subject: Re: RE: [dhcwg] "Secure DHCPv6 Using CGAs" > draft-jiang-dhc-secure-dhcpv6-01 > > Bernie, > > Thanks so much for your comments. This really helps our work become > better. Our design/solution is still remaining open for better. So do > comment/discuss further. Please see my reply in lines. > > Best regards, > > Sheng > > > I'm (still) a bit concerned about: > > > > 5.2. Signature Option > > > > The Signature option allows public key-based signatures to be > > attached to a DHCPv6 message. The Signature option COULD be any > place > > > > within the DHCPv6 message. It protects all the DHCPv6 header and > > options before it. Any options after the Signature option can be > > processed, but it should be noticed that they are not protected by > > this Signature option. The format of the Signature option is > > described as follows: > > > > Why is this protection positional? Can you explain why you think this > is > > useful? Why not secure the entire message with this? > > We are thinking how the receiver side is able to decide the protected > part of a DHCP message in order to get the right input for verification > computing. There are three possible solutions in our minds: 1, the > signature option is the last-generated option, it protects all options, > including itself; 2, the signature option has a set of sub-options to > clear indicate which options are protected; 3, the position of the > signature indicates its protected range. > > The first design is the best solution except for two scenarios: a, there > are some options, such as the AUTH option you mentioned, request to be > last generated too; b, some options may added at the end of a DHCP > message after signature options has been generated. We don't have a > clear example for this. But we cannot rule out the possibility. The > second design is too complicated giving the fact we cannot limit the > number of options. Then, the third design becomes the most reasonable > one for us. > > > The only interesting issue is if a client's message includes both a > > SIGNATURE and AUTH (RFC 3315) option -- since in this case, two > > different hashes over the entire message would need to be run and that > > doesn't work. So, I think the SIGNATURE option MUST NOT include the > AUTH > > option. (The AUTH option would include the SIGNATURE option as RFC > 3315 > > already requires that it cover the entire client message.) > > En... This is interesting. The AUTH option has already taken the > last-generated position. And I assume by the time of design this, the > designers already rule out the possibility that some option may request > to be generated/added after AUTH option. Now, we have one, at least, it > is equally to be last generated comparing the AUTH option. > > > I wonder whether this positional text is a hold over from DHCPv4 to > > handle the Relay Agent Option (82) - which is added at the end? > Relaying > > in DHCPv6 is done far differently. > > > > If there's a reason why the SIGNATURE needs to be positional, we still > > have the AUTH option conflict that would need to be discussed (if the > > AUTH option isn't excluded from coverage regardless of where it > appeared > > in the message, it would require the AUTH to follow the SIGNATURE). > > En... this could be a possible answer, I guess. Both AUTH and SIGNATURE > are only protects what in front of them. So, there would have no fixed > order for both their positions and generation order. AUTH can be behind > SIGNATURE, vice verse. This may also release the restriction "Any DHCP > message MUST NOT include more than one Authentication option." [21.2, > RFC 3315] > > > --- > > > > The draft allows a node to be a DHCPv6 relay agent. I think more text > is > > required to detail this. Suppose you have: > > Client --> Relay 1 --> Relay 2 --> Server > > > > If Relay 1 includes a SIGNATURE option, and relay 2 does not support > > this, what should the server do? How does the server know whether > relay > > 2 validated the SIGNATURE of Relay 1 or not (is there a requirement > for > > the relay to validate -- it is after all a "node")? Should the server > > validate all SIGNATURE options (as in this case, there could be 3 - > one > > in the Client message, one in the Relay 1 message (which encapsulates > > the client's message), and one in the Relay 2 message (which > > encapsulates Relay 1's message (which encapsulates the client's > > message))? > > > > Perhaps the ability for a relay to be a node should be removed? It > keeps > > it simpler. > > I agree that we should put more text to explain the process for relaying > if we get sure relaying need to be protected. In the above scenario, I > don't think reply agent needs to validate the SIGNATURE option unless it > uses some information from its received DHCP message. The server, in > this case, needs to validate all 3 SIGNATURE options. However, if relay > agent does not add its only options, the signature option from it may > not be very useful and the SIGNATURE options from relay agent are > optional. > > Best regards, > > Sheng > > > - Bernie > > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > > Of JiangSheng 66104 > > Sent: Tuesday, January 13, 2009 4:43 PM > > To: cga-ext@ietf.org; dhcwg@ietf.org > > Subject: [dhcwg] "Secure DHCPv6 Using CGAs" > > draft-jiang-dhc-secure-dhcpv6-01 > > > > The below "Secure DHCPv6 Using CGAs" has been updated, according to > > comments that have been discussed in dhc maillist and IETF meeting. > > Since early collaboration is requested for this CGA and DHCP > interaction > > work, this update message is sent to both CSI WG and DHC WG. > > > > Best regards, > > > > Sheng > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Secure DHCPv6 Using CGAs > > Author(s) : S. Jiang, S. Shen > > Filename : draft-jiang-dhc-secure-dhcpv6-01.txt > > Pages : 14 > > Date : 2009-1-8 > > > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > > DHCP servers to pass configuration parameters. It offers > > configuration flexibility. If not secured, DHCPv6 is vulnerable to > > various attacks, particularly fake attack. This document analyzes > the > > > > security issues of DHCPv6 and specifies security mechanisms, mainly > > using CGAs. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From najib.raie@afghan-wireless.com Tue Jan 20 14:23:15 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F503A69EC for ; Tue, 20 Jan 2009 14:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FzLU3Bm4gBG for ; Tue, 20 Jan 2009 14:23:15 -0800 (PST) Received: from 201-25-168-245.ctame704.dsl.brasiltelecom.net.br (201-25-168-245.ctame704.dsl.brasiltelecom.net.br [201.25.168.245]) by core3.amsl.com (Postfix) with SMTP id 0401F3A657C for ; Tue, 20 Jan 2009 14:23:10 -0800 (PST) To: Subject: Re: BRANDKEYWORD, Ltd From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120222312.0401F3A657C@core3.amsl.com> Date: Tue, 20 Jan 2009 14:23:10 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Dont see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.independencewash.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://independencewash.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 4, B412. 779 Clements Road. London. SE54 5DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From jveledian@alps-aquaservice.com Tue Jan 20 15:23:28 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FFE3A6A7C for ; Tue, 20 Jan 2009 15:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.899 X-Spam-Level: X-Spam-Status: No, score=-12.899 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64qdyR6No5VI for ; Tue, 20 Jan 2009 15:23:27 -0800 (PST) Received: from 212.168.broadband4.iol.cz (212.168.broadband4.iol.cz [85.71.168.212]) by core3.amsl.com (Postfix) with SMTP id 9F4B63A6A33 for ; Tue, 20 Jan 2009 15:23:26 -0800 (PST) To: Subject: RE: Administrator From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120232326.9F4B63A6A33@core3.amsl.com> Date: Tue, 20 Jan 2009 15:23:26 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Dont see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.positionthough.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://positionthough.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B059. 408 Clements Road. London. SE54 2DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From dhcwg-bounces@ietf.org Wed Jan 21 01:55:58 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFA23A68CC; Wed, 21 Jan 2009 01:55:58 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B3E3A68CC; Wed, 21 Jan 2009 01:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGTgSlx7jGaG; Wed, 21 Jan 2009 01:55:56 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7FDDE3A684C; Wed, 21 Jan 2009 01:55:56 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDT00EV9FF2N0@szxga04-in.huawei.com>; Wed, 21 Jan 2009 17:52:14 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDT004BWFF2AE@szxga04-in.huawei.com>; Wed, 21 Jan 2009 17:52:14 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDT00IHLFF1MA@szxml05-in.huawei.com>; Wed, 21 Jan 2009 17:52:14 +0800 (CST) Date: Wed, 21 Jan 2009 17:52:13 +0800 From: Sean Shen In-reply-to: <8E296595B6471A4689555D5D725EBB210AACA94F@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz (volz)'" , 'JiangSheng 66104' Message-id: <005001c97bad$f008b170$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl6gl+2oBUVWFEUTlC4s9U9vvFhtQAAQFPQAEf/9tA= Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] [CGA-EXT] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, Bernie, Thank you for the detailed review. I was not able to access email regularly recently and the situation will remain for another week or 10 days, but I will try to reply as fast as I can. Please see comments in lines: >Note that while the AUTH option needs to be generated last >(since it covers the entire message), it does not have to be >the LAST option in the message. > >In DHCPv6, no entity (relay agent or server) adds options to >the messages while it is 'in-flight' as is done for the DHCPv4 >relay agent option. Once the message is formed, a relay may >encapsulate it in a Relay Message option in its own message, >but that does NOT alter the original message. > >I think: >- CGA Signature can be anywhere in the message. >- CGA Signature covers the ENTIRE message EXCEPT for some of >its own fields and the AUTH option. >- The AUTH option covers the ENTIRE message, including the CGA >Signature option. > >This way, the AUTH gives complete protection of the entire >message as it was intended to. It works. >I'm not sure if it will be common for the SIGNATURE and AUTH >to be used together, as it seems to me that using the AUTH >message gives the better protection to begin with. But, if >they are used together, it works. Sure they can be used together. The good part of SIGNATURE is that it can be used in relay senarios, thus we don't need to rely on IPSEC for protection. (for the issue you found in relay scenario, please see the following comments) >I'd also highly recommend the CGA stuff be limited to clients >and servers (a client can add/server validate). Note that a >server can NOT use this for to provide proof of a CGA (the >server's source address) because this ONLY works when the >client and server are on the same link. >If a relay agent is involved, the source address of the packet >sent to the client is a relay agent address and thus the >Signature would never validate. Thanks for the issue you found, it's very important. The souce address lost problem happened only for SERVER-->Relay-->Client. For Client-->Relay-->Server, the souce address is kept in "link-address" field of relay messages. Comparing AUTH and SIGNATURE, we have the situation: No Relay C-->R-->S S-->R-->C AUTH yes no no SIGNATURE yes yes yes with proper solution* Possbile solutions*: Server's DHCP message (in relay senario) carry source address of server. For example, this can be done by defining new option to carry server's source address; or simply use the Server Identifier Option, define a new "link address plus time" type for DUID content. SIGNATURE is good for Relay scenarios where AUTH does not work. Entities along the route can sign messages as long as have the ability and are configured to do so. Receiver's can tell which signature belongs to whom. There are no pair-wise configurations of symmetric keys. For the questions whether all relay nodes should sign the message or whether the server/client should verify all the signatures, personally I think we can leave the decision for implementations or policys. Of course it's worth discussion whether we should enforce it in protocol. BW, Sean _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 21 02:41:26 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414183A6AB4; Wed, 21 Jan 2009 02:41:26 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849E13A6AB4 for ; Wed, 21 Jan 2009 02:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrDGAYpAcYdN for ; Wed, 21 Jan 2009 02:41:24 -0800 (PST) Received: from zns001-0m9004.yokogawa.co.jp (zns001-0m9004.yokogawa.co.jp [203.174.79.162]) by core3.amsl.com (Postfix) with ESMTP id 931763A67A4 for ; Wed, 21 Jan 2009 02:41:24 -0800 (PST) Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n0LAf7se014416 for ; Wed, 21 Jan 2009 19:41:07 +0900 (JST) Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.jp.ykgw.net [10.0.11.45]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n0LAf7At014413 for ; Wed, 21 Jan 2009 19:41:07 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.45]) with mapi; Wed, 21 Jan 2009 19:41:06 +0900 From: To: Date: Wed, 21 Jan 2009 19:41:05 +0900 Thread-Topic: question about server behaivor responding to request message Thread-Index: Acl7tMNt/uHSVyFWQ+24MkjN7Vuu7Q== Message-ID: <44C6761D700E0F459CEB255EF80380D80120CCF58722@EXMAIL01.jp.ykgw.net> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP MIME-Version: 1.0 Subject: [dhcwg] question about server behaivor responding to request message X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi all, I have a question about the following. Q1. Does the server include Status Code option with the value NotOnLink in the IA option? Or don't include Status Code option in the IA option? RFC3315 Section 18.2.1. line 2731: If the server finds that the prefix on one or more IP addresses in any IA in the message from the client is not appropriate for the link to which the client is connected, the server MUST return the IA to the client with a Status Code option with the value NotOnLink. Q2. Where the client sends a Request without any IA address (see below), how the server process its message? I think the server side process is not explicitly stated in RFC. RFC3315 Section 18.1.8. line 2646: When the client receives a NotOnLink status from the server in response to a Request, the client can either re-issue the Request without specifying any addresses or restart the DHCP server discovery process (see section 17). Best regards, -- Nobumichi Ozoe Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corporation Tel: +81-422-52-5544 Fax: +81-422-52-2561 http://www.yokogawa.com/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 21 05:23:35 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89943A6A08; Wed, 21 Jan 2009 05:23:35 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C448B3A6A08; Wed, 21 Jan 2009 05:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuAqBR+SS2vb; Wed, 21 Jan 2009 05:23:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 72F433A677E; Wed, 21 Jan 2009 05:23:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,300,1231113600"; d="scan'208";a="34386227" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2009 13:23:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0LDNFtY019544; Wed, 21 Jan 2009 08:23:15 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0LDNFwR010943; Wed, 21 Jan 2009 13:23:15 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 08:23:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 08:22:50 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACAF58@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <005001c97bad$f008b170$800c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CGA-EXT] [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 Thread-Index: Acl6gl+2oBUVWFEUTlC4s9U9vvFhtQAAQFPQAEf/9tAACcSkoA== References: <8E296595B6471A4689555D5D725EBB210AACA94F@xmb-rtp-20a.amer.cisco.com> <005001c97bad$f008b170$800c6f0a@china.huawei.com> From: "Bernie Volz (volz)" To: "Sean Shen" , "JiangSheng 66104" X-OriginalArrivalTime: 21 Jan 2009 13:23:15.0389 (UTC) FILETIME=[6A9AFED0:01C97BCB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4432; t=1232544195; x=1233408195; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[CGA-EXT]=20[dhcwg]=20=22Secure=20DHCPv 6=20Using=20CGAs=22draft-jiang-dhc-secure-dhcpv6-01 |Sender:=20 |To:=20=22Sean=20Shen=22=20,=20=22JiangSh eng=2066104=22=20; bh=y0gXwD7je/H60CJ14yFAwF1uEnrKih3NZOspJXXTLbg=; b=HdmGRLFxn2Q9yXUxAjjhhSToJ6eZHC1NS0QMvJnx3nwhuavwMmGcG/JIxL MGqMeV+BFeq33bcNm3Zyke0Zk7Cee5u5NOj8LwH/zIS90UgHZmAIcx7kN6Rj 13S7rqrt5p; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] [CGA-EXT] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org If we want to replace IPSec with something else for relay to relay/relay to server communication, we could always just allow use of the AUTH option. There's little need for CGA. However, I don't believe there's a need to find an alternative to IPSec. I think you need to step back and figure out exactly what problem you're trying to solve by adding this capability. Just beause we could do something, doesn't mean we should. Personally, I still find that using the keys used by SEND (CGA) with the AUTH option to authentication servers (and possibly clients to servers) is the most interesting beause if you've already distributed those keys, it avoids having to distribute yet another set of keys. And, the folks that manage the routers often manage the DHCPv6 servers as well. - Bernie -----Original Message----- From: Sean Shen [mailto:sshen@huawei.com] Sent: Wednesday, January 21, 2009 4:52 AM To: Bernie Volz (volz); 'JiangSheng 66104' Cc: dhcwg@ietf.org; cga-ext@ietf.org Subject: RE: [CGA-EXT] [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 Hi, Bernie, Thank you for the detailed review. I was not able to access email regularly recently and the situation will remain for another week or 10 days, but I will try to reply as fast as I can. Please see comments in lines: >Note that while the AUTH option needs to be generated last >(since it covers the entire message), it does not have to be >the LAST option in the message. > >In DHCPv6, no entity (relay agent or server) adds options to >the messages while it is 'in-flight' as is done for the DHCPv4 >relay agent option. Once the message is formed, a relay may >encapsulate it in a Relay Message option in its own message, >but that does NOT alter the original message. > >I think: >- CGA Signature can be anywhere in the message. >- CGA Signature covers the ENTIRE message EXCEPT for some of >its own fields and the AUTH option. >- The AUTH option covers the ENTIRE message, including the CGA >Signature option. > >This way, the AUTH gives complete protection of the entire >message as it was intended to. It works. >I'm not sure if it will be common for the SIGNATURE and AUTH >to be used together, as it seems to me that using the AUTH >message gives the better protection to begin with. But, if >they are used together, it works. Sure they can be used together. The good part of SIGNATURE is that it can be used in relay senarios, thus we don't need to rely on IPSEC for protection. (for the issue you found in relay scenario, please see the following comments) >I'd also highly recommend the CGA stuff be limited to clients >and servers (a client can add/server validate). Note that a >server can NOT use this for to provide proof of a CGA (the >server's source address) because this ONLY works when the >client and server are on the same link. >If a relay agent is involved, the source address of the packet >sent to the client is a relay agent address and thus the >Signature would never validate. Thanks for the issue you found, it's very important. The souce address lost problem happened only for SERVER-->Relay-->Client. For Client-->Relay-->Server, the souce address is kept in "link-address" field of relay messages. Comparing AUTH and SIGNATURE, we have the situation: No Relay C-->R-->S S-->R-->C AUTH yes no no SIGNATURE yes yes yes with proper solution* Possbile solutions*: Server's DHCP message (in relay senario) carry source address of server. For example, this can be done by defining new option to carry server's source address; or simply use the Server Identifier Option, define a new "link address plus time" type for DUID content. SIGNATURE is good for Relay scenarios where AUTH does not work. Entities along the route can sign messages as long as have the ability and are configured to do so. Receiver's can tell which signature belongs to whom. There are no pair-wise configurations of symmetric keys. For the questions whether all relay nodes should sign the message or whether the server/client should verify all the signatures, personally I think we can leave the decision for implementations or policys. Of course it's worth discussion whether we should enforce it in protocol. BW, Sean _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 21 05:50:04 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D90F3A6B39; Wed, 21 Jan 2009 05:50:04 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8D2D23A6AC5; Wed, 21 Jan 2009 05:50:03 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090121135003.8D2D23A6AC5@core3.amsl.com> Date: Wed, 21 Jan 2009 05:50:03 -0800 (PST) Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'DHCPv6 Bulk Leasequery' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'DHCPv6 Bulk Leasequery ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt Technical Summary DHCPv6 "leasequery" allows a DHCPv6 server to be queried for information about DHCPv6 bindings. As an example, a network element may use leasequery to recover state derived from DHCP message exchanges. The existing leasequery mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. DHCPv6 bulk leasequery expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. Working Group Summary The dhc WG reviewed this document and raised several issues during the WG last call. All of the issues have been resolved or addressed in this revision of the draft. One set of issues was raised in http://www.ietf.org/mail-archive/web/dhcwg/current/msg08468.html; the issues were resolved in a revision to the draft. Document Quality DHCPv6 bulk leasequery was originally developed as a simple extension to DHCPv6 leasequery, carried over UDP. Because of the possible effect on the network of a bulk data transfer over UDP, DHCPv6 bulk leasequery was re-architected to use TCP. The specification for the resulting protocol has been reviewed by both dhc WG members and external transport experts. DHCPv6 bulk leasequery was originally developed at the request of a large ISP, in anticipation of IPv6 service deployment. At least one DHCPv6 server vendor plans to implement DHCPv6 bulk leasequery. Personnel Jari Arkko has reviewed this specification for the IESG. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 21 05:53:54 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BAB53A6B44; Wed, 21 Jan 2009 05:53:54 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAC63A6B44 for ; Wed, 21 Jan 2009 05:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6J93TSWlpxs for ; Wed, 21 Jan 2009 05:53:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 246383A69C9 for ; Wed, 21 Jan 2009 05:53:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,300,1231113600"; d="scan'208";a="34389346" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2009 13:53:33 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0LDrXjN001292; Wed, 21 Jan 2009 08:53:33 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0LDrXBN020025; Wed, 21 Jan 2009 13:53:33 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 08:53:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 08:53:23 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210AACAF73@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <44C6761D700E0F459CEB255EF80380D80120CCF58722@EXMAIL01.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] question about server behaivor responding to request message Thread-Index: Acl7tMNt/uHSVyFWQ+24MkjN7Vuu7QAGexEQ References: <44C6761D700E0F459CEB255EF80380D80120CCF58722@EXMAIL01.jp.ykgw.net> From: "Bernie Volz (volz)" To: , X-OriginalArrivalTime: 21 Jan 2009 13:53:33.0312 (UTC) FILETIME=[A62C0800:01C97BCF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3036; t=1232546013; x=1233410013; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20question=20about=20server=20b ehaivor=20responding=20to=20request=20message |Sender:=20 |To:=20,=20; bh=1ehVlIdUjHf+qMyr/6N/LLh5QAxo6wW4uYYyaMGVMXM=; b=tl7sElKriPYfcHzM/vBHCk5NN/kljiShLQC3LT98GBfQFITuQO/zMuznCM pViCcpX8eprmAWZfxgLCSC8IOP6uVb2nCtplW55DnsIlc6r4yA+NaDiaHOdJ BA16330IJc; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] question about server behaivor responding to request message X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Regarding Q1, I thought this had come up before and was discussed, but alas I can not find it. If the server finds that the prefix on one or more IP addresses in any IA in the message from the client is not appropriate for the link to which the client is connected, the server MUST return the IA to the client with a Status Code option with the value NotOnLink. The server I work on returns it in the IA_* option as that's the way I interpreted it - "MUST return the IA to the client with a Status Code option with the value NotOnLink". The TAHI conformance test suite, see http://www.tahi.org/logo/dhcpv6/result/dibbler/DHCPv6_Self_Test_P2_1_0_1 5.server/rfc3315/S_RFC3315_18.2.1_ReceiptRequestMsgWithStatusCodeOPNotOn Link.seq, appears to check for it in the IA_* option as well (perhaps because of earlier discussions as an earlier version of the test checked for this status in the message itself, not in the IA_* option). Regarding Q2, the server allocates new addresses for the client if there are no addresses in an IA_* option. That just means that the client is not explicitly requesting any particular addresses and will take what the server assigns to it. Why would this be any different than a Solicit with an IA_* option but no addresses in those options? Note that a Solicit w/Rapid Commit is just like a Request and likely would not specify any addresses. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Nobumichi.Ozoe@jp.yokogawa.com Sent: Wednesday, January 21, 2009 5:41 AM To: dhcwg@ietf.org Subject: [dhcwg] question about server behaivor responding to request message Hi all, I have a question about the following. Q1. Does the server include Status Code option with the value NotOnLink in the IA option? Or don't include Status Code option in the IA option? RFC3315 Section 18.2.1. line 2731: If the server finds that the prefix on one or more IP addresses in any IA in the message from the client is not appropriate for the link to which the client is connected, the server MUST return the IA to the client with a Status Code option with the value NotOnLink. Q2. Where the client sends a Request without any IA address (see below), how the server process its message? I think the server side process is not explicitly stated in RFC. RFC3315 Section 18.1.8. line 2646: When the client receives a NotOnLink status from the server in response to a Request, the client can either re-issue the Request without specifying any addresses or restart the DHCP server discovery process (see section 17). Best regards, -- Nobumichi Ozoe Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corporation Tel: +81-422-52-5544 Fax: +81-422-52-2561 http://www.yokogawa.com/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From lkhars@anb.com.sa Wed Jan 21 08:42:04 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179943A6990 for ; Wed, 21 Jan 2009 08:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.463 X-Spam-Level: X-Spam-Status: No, score=-26.463 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNA=1.231, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WhR+-pzvr3S for ; Wed, 21 Jan 2009 08:42:02 -0800 (PST) Received: from 213-138-254-79.cpe.netmadeira.com (213-138-254-79.cpe.netmadeira.com [213.138.254.79]) by core3.amsl.com (Postfix) with SMTP id 229EB3A67D8 for ; Wed, 21 Jan 2009 08:41:59 -0800 (PST) To: Subject: For Our Users: Exclusive Jan Offer From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121164201.229EB3A67D8@core3.amsl.com> Date: Wed, 21 Jan 2009 08:41:59 -0800 (PST)

Do not see a picture? Visit our site now!

*Offer expires January 31, 2009.

As a valued Windows Live Hotmail customer, we hope you find this Windows Vista Ultimate offer valuable. If you would prefer to no longer receive promotional offers about Windows Vista Ultimate please click here.

For general information about how to manage your Communication Preferences with Microsoft please click here.

If you have questions about Microsoft privacy policies, please read our online Privacy Statement.

Opting out of Microsoft e-mail offers will not affect any newsletters you have requested nor restrict important customer communications concerning your Microsoft products.

Microsoft Corporation
One Microsoft Way
Redmond, WA 39899

..
Message-Id: <20090902209739.6F1D.92158524-0544@cimail14.msn.com>
From kortrijk.interimd@accent.be Wed Jan 21 13:17:40 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6F63A679C for ; Wed, 21 Jan 2009 13:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.172 X-Spam-Level: X-Spam-Status: No, score=-17.172 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN+JreF8g3Zs for ; Wed, 21 Jan 2009 13:17:39 -0800 (PST) Received: from 33.asp070.com (unknown [189.81.235.77]) by core3.amsl.com (Postfix) with SMTP id 396E23A6951 for ; Wed, 21 Jan 2009 13:17:33 -0800 (PST) To: Subject: Your Payment Has Been Initiated From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121211735.396E23A6951@core3.amsl.com> Date: Wed, 21 Jan 2009 13:17:33 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.harmonydrive.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://harmonydrive.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 6, B423. 177 Clements Road. London. SE26 3DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From dhcwg-bounces@ietf.org Wed Jan 21 13:29:02 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F913A69EC; Wed, 21 Jan 2009 13:29:02 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F343A69EC for ; Wed, 21 Jan 2009 13:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6skLZ0fDejL for ; Wed, 21 Jan 2009 13:28:59 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 1675E3A68B6 for ; Wed, 21 Jan 2009 13:28:58 -0800 (PST) Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSXeTiXlcPrI19cmW4GILN92XqNXek4L2@postini.com; Wed, 21 Jan 2009 13:28:43 PST Received: from kamas.ddns.nominum.com (kamas.ddns.nominum.com [64.89.224.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 699C81A8205; Wed, 21 Jan 2009 13:28:41 -0800 (PST) (envelope-from neild@nominum.com) Message-Id: <69A05B29-88BC-4C15-BBD4-E8F7545EEDAE@nominum.com> From: Damien Neil To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB210AACAF73@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 21 Jan 2009 13:28:41 -0800 References: <44C6761D700E0F459CEB255EF80380D80120CCF58722@EXMAIL01.jp.ykgw.net> <8E296595B6471A4689555D5D725EBB210AACAF73@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] question about server behaivor responding to request message X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 21, 2009, at 5:53 AM, Bernie Volz (volz) wrote: > The server I work on returns it in the IA_* option as that's the way I > interpreted it - "MUST return the IA to the client with a Status Code > option with the value NotOnLink". I agree with this interpretation. The server I work on does the same. - Damien _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 21 17:31:56 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6CD3A69EC; Wed, 21 Jan 2009 17:31:56 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B0E3A699E for ; Wed, 21 Jan 2009 17:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNBiuqu0Dg+q for ; Wed, 21 Jan 2009 17:31:54 -0800 (PST) Received: from mail2.ntp.org (mail2.ntp.org [204.152.184.138]) by core3.amsl.com (Postfix) with ESMTP id 56BF03A67C0 for ; Wed, 21 Jan 2009 17:31:54 -0800 (PST) Received: from mail.antoniuk.md (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 8B5F1398FF; Thu, 22 Jan 2009 01:31:35 +0000 (UTC) (envelope-from mayer@ntp.org) Received: from cust-63-209-224-151.bos-dynamic.gis.net ([63.209.224.151] helo=[10.10.10.101]) by mail.antoniuk.md with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LPoNi-0002OQ-5l; Wed, 21 Jan 2009 20:29:18 -0500 Message-ID: <4977CBE5.7070405@ntp.org> Date: Wed, 21 Jan 2009 20:29:09 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@ntp.org Cc: namedroppers@ops.ietf.org, DHCP Working Group Subject: Re: [dhcwg] [dnsext] Re: DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: >> Has anyone thought to forward this to the DHCP Working Group for their >> input? You are ascribing a great deal to DHCP requirements, so they >> should also comment on this draft. > > The draft itself makes no recommendations about the protocol. > That wasn't the point. People here are making plenty of statements about what DHCP needs and wants but noone seems to be asking them for what their requirements really are and they can add a lot to the discussion. They are an active group and are not shy about discussing issues! > The only recommendations are about what features the DHCP server that's > found alongside the DNS proxy in broadband gateways should support. > For which their opinion should be sought. > That said, ISTR that Olafur said that he would liaise with the DHC WG if > necessary. > Well I copied the DHCP WG on this message. Danny > Ray _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 21 18:04:25 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAA23A6B5D; Wed, 21 Jan 2009 18:04:25 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF823A6B5D; Wed, 21 Jan 2009 18:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E47zpqp4655d; Wed, 21 Jan 2009 18:04:23 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9902F3A67C0; Wed, 21 Jan 2009 18:04:23 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDU00GTHOETOC@szxga04-in.huawei.com>; Thu, 22 Jan 2009 10:04:05 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDU0033TOETG4@szxga04-in.huawei.com>; Thu, 22 Jan 2009 10:04:05 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDU00739OESED@szxml06-in.huawei.com>; Thu, 22 Jan 2009 10:04:05 +0800 (CST) Date: Thu, 22 Jan 2009 10:04:04 +0800 From: Sean Shen In-reply-to: <8E296595B6471A4689555D5D725EBB210AACAF58@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz (volz)'" , 'JiangSheng 66104' Message-id: <007101c97c35$b4376550$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl6gl+2oBUVWFEUTlC4s9U9vvFhtQAAQFPQAEf/9tAACcSkoAAYkdvg Cc: dhcwg@ietf.org, cga-ext@ietf.org Subject: Re: [dhcwg] [CGA-EXT] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org hi, Bernie, Please see in lines. >If we want to replace IPSec with something else for relay to >relay/relay to server communication, we could always just >allow use of the AUTH option. There's little need for CGA. It can be a try if you want to use AUTH for relay-->relay/relay-->server, but I doubt it can fit the scenario well. AUTH is basicly symmetric crypto, good for two parties. It's rare to use it for 3 or more parties because you don't want to manage keys for each pair of parties. Also if you want your AUTH be checked by all the nodes on the route, you have to calculate and carry multiple AUTHs for all of them, while RFC3315 clearly defined that only one AUTH can be used, not mentioing that a client may not even know which router will check the AUTH (hence don't know which key to use). Since I am not an author of RFC3315, I don' t know other reasons (besides what I just said above) that AUTH is not simply used in relay scenarios. If you think it's doable, more discussion of its feasibility will be interesting. >However, I don't believe there's a need to find an alternative >to IPSec. The reason is simple: NOT all routers can and like to use IPsec. >I think you need to step back and figure out exactly what >problem you're trying to solve by adding this capability. Just >beause we could do something, doesn't mean we should. The motivation and benefit (including advantages in relay scenarios and IP binding) is described in section 3 of the draft. >Personally, I still find that using the keys used by SEND >(CGA) with the AUTH option to authentication servers (and >possibly clients to servers) is the most interesting beause if >you've already distributed those keys, it avoids having to >distribute yet another set of keys. And, the folks that manage >the routers often manage the DHCPv6 servers as well. Generally using same key for multiple purposes should be avoided in crypto (unless good hash processing involved), just like you don't want to use a same key for both encryption and authentication. Again we said before, the reason is not only about key management. Best, Sean _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 21 20:51:16 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853893A68E3; Wed, 21 Jan 2009 20:51:16 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249DD3A67BD for ; Wed, 21 Jan 2009 20:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_43=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrCjJdzY6V8c for ; Wed, 21 Jan 2009 20:51:08 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by core3.amsl.com (Postfix) with ESMTP id C18633A672E for ; Wed, 21 Jan 2009 20:51:07 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n0M4oIDF006280; Thu, 22 Jan 2009 13:50:18 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n0M4o8ri006209; Thu, 22 Jan 2009 13:50:08 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Thu, 22 Jan 2009 13:50:01 +0900 From: To: , Date: Thu, 22 Jan 2009 13:49:59 +0900 Thread-Topic: [dhcwg] question about server behaivor responding to request message Thread-Index: Acl7tMNt/uHSVyFWQ+24MkjN7Vuu7QAGexEQAB876CA= Message-ID: <44C6761D700E0F459CEB255EF80380D80120CCF58755@EXMAIL01.jp.ykgw.net> References: <44C6761D700E0F459CEB255EF80380D80120CCF58722@EXMAIL01.jp.ykgw.net> <8E296595B6471A4689555D5D725EBB210AACAF73@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210AACAF73@xmb-rtp-20a.amer.cisco.com> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP MIME-Version: 1.0 Subject: Re: [dhcwg] question about server behaivor responding to request message X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Bernie, Thanks, it makes sense to me. > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Wednesday, January 21, 2009 10:53 PM > To: Ozoe, Nobumichi (Nobumichi.Ozoe@jp.yokogawa.com); dhcwg@ietf.org > Subject: RE: [dhcwg] question about server behaivor > responding to request message > > Regarding Q1, I thought this had come up before and was > discussed, but alas I can not find it. > > If the server finds that the prefix on one or more IP addresses in > any IA in the message from the client is not appropriate > for the link > to which the client is connected, the server MUST return the IA to > the client with a Status Code option with the value NotOnLink. > > The server I work on returns it in the IA_* option as that's > the way I interpreted it - "MUST return the IA to the client > with a Status Code option with the value NotOnLink". > > The TAHI conformance test suite, see > http://www.tahi.org/logo/dhcpv6/result/dibbler/DHCPv6_Self_Tes > t_P2_1_0_1 > 5.server/rfc3315/S_RFC3315_18.2.1_ReceiptRequestMsgWithStatusC > odeOPNotOn > Link.seq, appears to check for it in the IA_* option as well > (perhaps because of earlier discussions as an earlier version > of the test checked for this status in the message itself, > not in the IA_* option). > > Regarding Q2, the server allocates new addresses for the > client if there are no addresses in an IA_* option. That just > means that the client is not explicitly requesting any > particular addresses and will take what the server assigns to > it. Why would this be any different than a Solicit with an > IA_* option but no addresses in those options? Note that a > Solicit w/Rapid Commit is just like a Request and likely > would not specify any addresses. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Nobumichi.Ozoe@jp.yokogawa.com > Sent: Wednesday, January 21, 2009 5:41 AM > To: dhcwg@ietf.org > Subject: [dhcwg] question about server behaivor responding to > request message > > Hi all, > > I have a question about the following. > > Q1. Does the server include Status Code option with the value > NotOnLink in the IA option? > Or don't include Status Code option in the IA option? > > RFC3315 Section 18.2.1. line 2731: > If the server finds that the prefix on one or more IP addresses in > any IA in the message from the client is not appropriate > for the link > to which the client is connected, the server MUST return the IA to > the client with a Status Code option with the value NotOnLink. > > Q2. Where the client sends a Request without any IA address > (see below), how the server process its message? > I think the server side process is not explicitly stated in RFC. > > RFC3315 Section 18.1.8. line 2646: > When the client receives a NotOnLink status from the server in > response to a Request, the client can either re-issue the Request > without specifying any addresses or restart the DHCP > server discovery > process (see section 17). > > Best regards, > > -- > Nobumichi Ozoe > Ubiquitous Field Computing Research Center, Corporate R&D > Headquaters, Yokogawa Electric Corporation > Tel: +81-422-52-5544 Fax: +81-422-52-2561 > http://www.yokogawa.com/ > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jan 22 00:27:03 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02AB728C11A; Thu, 22 Jan 2009 00:27:03 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC50128C11A; Thu, 22 Jan 2009 00:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FISt8fVlvSv; Thu, 22 Jan 2009 00:26:55 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id D84B628C112; Thu, 22 Jan 2009 00:26:54 -0800 (PST) Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSXgtvsSHNKDVZg0FpO6GKRdCYMpsSbkq@postini.com; Thu, 22 Jan 2009 00:26:38 PST Received: from [192.168.1.75] (dsl092-048-218.sfo4.dsl.speakeasy.net [66.92.48.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 9D9F81A8206; Thu, 22 Jan 2009 00:26:37 -0800 (PST) (envelope-from neild@nominum.com) Message-Id: From: Damien Neil To: DHC-WG WG , cga-ext@ietf.org In-Reply-To: <007101c97c35$b4376550$800c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 00:26:35 -0800 References: <007101c97c35$b4376550$800c6f0a@china.huawei.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [dhcwg] [CGA-EXT] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 21, 2009, at 6:04 PM, Sean Shen wrote: >> I think you need to step back and figure out exactly what >> problem you're trying to solve by adding this capability. Just >> beause we could do something, doesn't mean we should. > The motivation and benefit (including advantages in relay scenarios > and IP > binding) is described in section 3 of the draft. It's possible that this is just my lack of experience with CGAs speaking, but section 3 hasn't enlightened me on the benefit of this proposal. My understanding is that CGA authentication will permit a client to verify that a DHCP message received from a server with a given address was, in fact, sent by the server with that address. Is there a mechanism, however, which permits the client to verify that this server is authorized to act as a DHCP server? If not, what security is added by signing the message? What prevents a malicious DHCP server from generating a new CGA, using it to sign its messages, and serving addresses to clients? It might help me understand the benefits of this proposal if you could describe a specific attack which it can defend against. - Damien _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From k_hase@aichi-med-u.ac.jp Thu Jan 22 02:29:45 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203DA3A6A4A for ; Thu, 22 Jan 2009 02:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.179 X-Spam-Level: X-Spam-Status: No, score=-32.179 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9NBouFhNC9k for ; Thu, 22 Jan 2009 02:29:44 -0800 (PST) Received: from aktesa.com (unknown [89.36.219.83]) by core3.amsl.com (Postfix) with SMTP id 5C91A3A68BA for ; Thu, 22 Jan 2009 02:29:42 -0800 (PST) To: Subject: Your Payment Has Been Initiated From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090122102943.5C91A3A68BA@core3.amsl.com> Date: Thu, 22 Jan 2009 02:29:42 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.aspirationdry.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://aspirationdry.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B402. 564 Clements Road. London. SE11 1DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From dhcwg-bounces@ietf.org Thu Jan 22 04:45:04 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B0D28C185; Thu, 22 Jan 2009 04:45:04 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F056128C15B; Thu, 22 Jan 2009 04:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090122124501.F056128C15B@core3.amsl.com> Date: Thu, 22 Jan 2009 04:45:01 -0800 (PST) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-vendor-message-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv6 Vendor-specific Message Author(s) : B. Volz Filename : draft-ietf-dhc-dhcpv6-vendor-message-00.txt Pages : 6 Date : 2009-01-12 This document requests a vendor-specific DHCPv6 message assignment. This message can be used for vendor specific and experimental purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-vendor-message-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dhc-dhcpv6-vendor-message-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22044319.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Jan 22 04:45:05 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D9228C194; Thu, 22 Jan 2009 04:45:05 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F318C3A6B72; Thu, 22 Jan 2009 04:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090122124501.F318C3A6B72@core3.amsl.com> Date: Thu, 22 Jan 2009 04:45:01 -0800 (PST) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv4-vendor-message-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 Vendor-specific Message Author(s) : B. Volz Filename : draft-ietf-dhc-dhcpv4-vendor-message-00.txt Pages : 7 Date : 2009-01-12 This document requests a vendor-specific DHCPv4 message assignment. This message can be used for vendor specific and experimental purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-vendor-message-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dhc-dhcpv4-vendor-message-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22044338.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Jan 22 05:41:44 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105383A6946; Thu, 22 Jan 2009 05:41:44 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CC93A6886 for ; Thu, 22 Jan 2009 05:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmwT1+5bZsS8 for ; Thu, 22 Jan 2009 05:41:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 463B43A6946 for ; Thu, 22 Jan 2009 05:41:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,306,1231113600"; d="scan'208";a="34519811" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2009 13:41:19 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0MDfIWM000775; Thu, 22 Jan 2009 08:41:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0MDfI1B029994; Thu, 22 Jan 2009 13:41:18 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 08:41:17 -0500 Received: from bxb-rdroms-8711.cisco.com ([10.98.10.82]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 08:41:16 -0500 Message-Id: From: Ralph Droms To: Danny Mayer , DHCP Working Group In-Reply-To: <4977CBE5.7070405@ntp.org> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 08:41:16 -0500 References: <4977CBE5.7070405@ntp.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Jan 2009 13:41:16.0913 (UTC) FILETIME=[19A83610:01C97C97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1830; t=1232631679; x=1233495679; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dnsext]=20Re=3A=20DNS=20Proxy=20Implem entation=20Guidelines=20-=20draft-ietf-dnsext-dnsproxy-01 |Sender:=20 |To:=20Danny=20Mayer=20,=20DHCP=20Working=20 Group=20; bh=drWzGttgJW/ovumv0BL11Ra9lTftq2ea7ptucQGu1ZY=; b=MKSg3YrGQJkkcxRamleIiP9OayR8BSgbatXFcgPX3PQS1+s2FQe+sbXEjY RR0pO91mmxkc7HwMKfQ/biXSCAnt8rGbYStWUF8ctTGXO3FaGpdMZtTksrRw QQA2nalE+g; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Ralph Droms Subject: Re: [dhcwg] [dnsext] Re: DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I suggest interested dhc WG members contribute to the thread on the namedroppers@ops.ietf.org mailing list (that's where I'm going) so we get all the discussion in one archive and avoid burdening subscribers to both lists with duplicate traffic... - Ralph On Jan 21, 2009, at 8:29 PM 1/21/09, Danny Mayer wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > Ray.Bellis@nominet.org.uk wrote: >>> Has anyone thought to forward this to the DHCP Working Group for >>> their >>> input? You are ascribing a great deal to DHCP requirements, so they >>> should also comment on this draft. >> >> The draft itself makes no recommendations about the protocol. >> > > That wasn't the point. People here are making plenty of statements > about > what DHCP needs and wants but noone seems to be asking them for what > their requirements really are and they can add a lot to the > discussion. > They are an active group and are not shy about discussing issues! > >> The only recommendations are about what features the DHCP server >> that's >> found alongside the DNS proxy in broadband gateways should support. >> > > For which their opinion should be sought. > >> That said, ISTR that Olafur said that he would liaise with the DHC >> WG if >> necessary. >> > > Well I copied the DHCP WG on this message. > > Danny >> Ray > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From o.pereira@abxlogistics.pt Thu Jan 22 18:07:50 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58AD28C0F3 for ; Thu, 22 Jan 2009 18:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.21 X-Spam-Level: X-Spam-Status: No, score=-26.21 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFBYQU4EMtNm for ; Thu, 22 Jan 2009 18:07:50 -0800 (PST) Received: from adsl190-28-201-108.epm.net.co (adsl190-28-201-108.epm.net.co [190.28.201.108]) by core3.amsl.com (Postfix) with SMTP id 520193A67B1 for ; Thu, 22 Jan 2009 18:07:48 -0800 (PST) To: Subject: RECOVERY: Z27077 is OK From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090123020749.520193A67B1@core3.amsl.com> Date: Thu, 22 Jan 2009 18:07:48 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Click Here!

To unsubscribe from this mailing list, please log in to www.grouptheir.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://grouptheir.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B366. 067 Clements Road. London. SE94 4DG

© 2006-2009 BRANDKEYWORD, Ltd. All Rights Reserved

From longnn@advancedfluids.com Fri Jan 23 03:14:15 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A2E3A69DE for ; Fri, 23 Jan 2009 03:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.732 X-Spam-Level: X-Spam-Status: No, score=-22.732 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDmeg6xEAIAg for ; Fri, 23 Jan 2009 03:14:15 -0800 (PST) Received: from alpopular.com.co (unknown [88.247.40.93]) by core3.amsl.com (Postfix) with SMTP id 227683A6A9F for ; Fri, 23 Jan 2009 03:14:12 -0800 (PST) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090123111413.227683A6A9F@core3.amsl.com> Date: Fri, 23 Jan 2009 03:14:12 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.majorrose.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://majorrose.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B188. 024 Clements Road. London. SE18 9DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From dhcwg-bounces@ietf.org Fri Jan 23 04:54:43 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD2C28C0DB; Fri, 23 Jan 2009 04:54:42 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834CA3A6867 for ; Fri, 23 Jan 2009 04:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKCZldiRZIAd for ; Fri, 23 Jan 2009 04:54:40 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 18F5D3A68BC for ; Fri, 23 Jan 2009 04:54:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,312,1231113600"; d="scan'208";a="34637373" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2009 12:54:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0NCsMkf003757 for ; Fri, 23 Jan 2009 07:54:22 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0NCsMSI017159 for ; Fri, 23 Jan 2009 12:54:22 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 07:54:22 -0500 Received: from bxb-rdroms-8711.cisco.com ([10.98.10.82]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 07:54:22 -0500 Message-Id: <1127C1EE-5803-4393-B18F-F1AE6E7EF7F6@cisco.com> From: Ralph Droms To: DHCP Working Group Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 07:54:21 -0500 References: <74CA549E-0F7F-4575-BFB7-DE1D85AC8BEE@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Jan 2009 12:54:22.0702 (UTC) FILETIME=[B6AB70E0:01C97D59] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5897; t=1232715262; x=1233579262; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Fwd=3A=20[dnsext]=20Re=3A=20DNS=20Proxy=20Imple mentation=20Guidelines=20-=20draft-ietf-dnsext-dnsproxy-01 |Sender:=20 |To:=20DHCP=20Working=20Group=20; bh=+j7yyGJIncX29BNE1TitREZ7dT2hQwnoBzzu+Xqndr8=; b=cWDhwhCMA4NBkwAnovlqRbSxlvD5KZ/+mh4I0biFgPGeKIL5OUX6iRbrQb Ddj7gWs9Otl5FKVgRqVa41Ym3HNKkQg4dHARR+osBavl56InvF+wenG9TdRY +3SiE5pTP1; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [dhcwg] Fwd: [dnsext] Re: DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I sent the following message to the namedroppers mailing list as part of the discussion of the DNS proxy discussion. It wouldn't hurt to get more dhc WG opinion on the draft - please follow up on the namedroppers list. - Ralph Begin forwarded message: > From: Ralph Droms > Date: January 22, 2009 11:35:48 AM EST > To: namedroppers@ops.ietf.org > Cc: Ralph Droms , Ray.Bellis@nominet.org.uk, Danny > Mayer > Subject: Re: [dnsext] Re: DNS Proxy Implementation Guidelines - > draft-ietf-dnsext-dnsproxy-01 > > (replying just to namedroppers; I asked interested dhc WG members to > contribute here) > > So, I read the draft and then traced the thread in the namedroppers > archive. > > I came up with a couple of questions when I read the draft, some of > which seemed to be answered in the discussion thread. > > * Why DNS proxies? > > So the DHCP server can send a consistent DNS recursive resolver > address to clients ... which seemed to me to be a pretty cart-before- > the-horse reason to go through this whole proxy exercise. I know > "something" has to be done, but my intuition is that the problems > with proxies should encourage us to find a better solution. This > line of thought lead to my next couple of questions: > > * How does the DNS proxy respond if there is no WAN connection? > > ...because once the WAN connection is in place, the BGW (broadband > gateway) SHOULD default to sending the DNS recursive resolver it > learned from the WAN DHCP server, and SHOULD allow the home network > admin to override that setting. So, the only time sending the BGW > address as the DNS recursive resolver, employing a proxy, is when > the WAN connection is not yet in place, but, if the WAN connection > isn't in place, the DNS proxy has nowhere to proxy to, anyway. The > client doesn't get any additional function out of this proxy, right? > > * Under what circumstances is there really a problem? > > How often is it the case that the BGW doesn't have the address of a > DNS recursive resolver to send via DHCP to hosts on the LAN? In my > opinion, the BGW SHOULD use the address of the resolver associated > with the address it obtained through DHCP on its WAN connection. > Even if the WAN connection is down, the BGW SHOULD send that > resolver address as long as the lease on the WAN address hasn't > expired. > > And, if the lease has expired, is there harm in sending the most > recently obtained resolver address, anyway? The BGW is still in the > state, presumably, where the WAN connection is down, so there won't > be any DNS resolution anyway. > > Conversely, what happens to hosts if the DHCP server supplies no DNS > resolver? > > * Suppose the BGW doesn't have the address of a resolver > > Well, as has been discussed in this thread, the problem is in the > transition when the BGW is finally configured with the address of a > resolver. Prior to the WAN connection coming up, it doesn't much > matter what address the BGW hands to hosts on the LAN; DNS > resolution isn't going to work. So, (and, again, I think this > solution is hinted at in this thread and the draft) the BGW SHOULD > use a short DHCP lease time until it can supply the hosts on the LAN > with the address of a good resolver. > > I recognize the impact of short DHCP leases on BGW performance. It > would be interesting to test the DHCP servers in these BGW with, > say, 20 hosts and a lease time of 1 minute. > > Note that all of this discussion is aimed at solving the proxy > problem by avoiding proxies. I don't know if that goal is in scope > of this draft. Another solution, of course, would be to put a real > recursive resolver in the BGW, which might have other advantages for > DNSSEC. > > Finally, after asking all this, I wondered... > > * What do we want to get out of this recommendation? > > Are we trying to change the future behavior of BGWs in some way? If > we're going to try to change the behavior of BGWs regarding DNS > proxies, can we take a bigger step and try to get rid of them > altogether? > > - Ralph > > On Jan 21, 2009, at 8:29 PM 1/21/09, Danny Mayer wrote: > >> [ Moderators note: Post was moderated, either because it was posted >> by >> a non-subscriber, or because it was over 20K. >> With the massive amount of spam, it is easy to miss and therefore >> delete relevant posts by non-subscribers. >> Please fix your subscription addresses. ] >> >> Ray.Bellis@nominet.org.uk wrote: >>>> Has anyone thought to forward this to the DHCP Working Group for >>>> their >>>> input? You are ascribing a great deal to DHCP requirements, so they >>>> should also comment on this draft. >>> >>> The draft itself makes no recommendations about the protocol. >>> >> >> That wasn't the point. People here are making plenty of statements >> about >> what DHCP needs and wants but noone seems to be asking them for what >> their requirements really are and they can add a lot to the >> discussion. >> They are an active group and are not shy about discussing issues! >> >>> The only recommendations are about what features the DHCP server >>> that's >>> found alongside the DNS proxy in broadband gateways should support. >>> >> >> For which their opinion should be sought. >> >>> That said, ISTR that Olafur said that he would liaise with the DHC >>> WG if >>> necessary. >>> >> >> Well I copied the DHCP WG on this message. >> >> Danny >>> Ray >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org >> with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jan 23 09:11:15 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1663A6A61; Fri, 23 Jan 2009 09:11:15 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A633A6A61 for ; Fri, 23 Jan 2009 09:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFc84LUOzuXp for ; Fri, 23 Jan 2009 09:11:12 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id AAF823A67F2 for ; Fri, 23 Jan 2009 09:11:12 -0800 (PST) Received: from david.isc.org (c-67-161-51-194.hsd1.ca.comcast.net [67.161.51.194]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n0NHArik008087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jan 2009 09:10:54 -0800 Received: by david.isc.org (Postfix, from userid 10200) id 17FD916E1B3; Wed, 21 Jan 2009 10:02:40 -0800 (PST) Date: Wed, 21 Jan 2009 10:02:40 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20090121180240.GA6032@isc.org> References: <44C6761D700E0F459CEB255EF80380D80120CCF58722@EXMAIL01.jp.ykgw.net> MIME-Version: 1.0 In-Reply-To: <44C6761D700E0F459CEB255EF80380D80120CCF58722@EXMAIL01.jp.ykgw.net> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: [dhcwg] question about server behaivor responding to request message X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0645330562==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0645330562== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 07:41:05PM +0900, Nobumichi.Ozoe@jp.yokogawa.com wr= ote: > Q1. Does the server include Status Code option with the value NotOnLink i= n the IA option? > Or don't include Status Code option in the IA option? It is different for different messages. For Solicit, obviously you don't do this in Advertise, you just Advertise what you are likely to supply on subsequent Requests. For Request, yes, you send NotOnLink within the IA if the address the client requests is not appropriate for the link they are attached to. This causes a client to re-Solicit and tries again. It is not very common to happen in the real world (the client would have to migrate links inbetween Solicit and Request, this is a corner case). For Renew and Rebind, again if the addresses are not appropriate for the link the client is attached to, the server is expected to include the invalid addresses in the Reply, with zeroed lifetimes, in addition to any valid addresses the server is able to supply (with nonzero lifetimes). If the server isn't able to send valid addresses for that link, the client detects it has zero addresses and returns to Solicit. This is a slightly more common scenario, because a client might switch networks on an active binding without realization (e.g. if the switch they are attached to is moved, the client does not receive a change in link state). And of course there is Confirm, where the server sends the NotOnLink status in the root options space. It does not include the client's IA's, much less status codes within them. > Q2. Where the client sends a Request without any IA address (see below), = how the server process its message? The client supplies IAADDR's as hints to what it would like to see in reply only. A server that encounters a client packet that contains no IAADDRs is merely given no hints and is free to supply whatever configuration it likes. Even with hints, the server is still free to supply whatever configuration it likes (with the noted exception you quoted, where the server is required to emit NotOnLink, possibly others I'm not remembering). Note that the all-zeroes address ("::") is probably not "an appropriate address for the link the client is attached to," for most link prefixes. :) By convention, an exception is made to the NotOnLink direction here, so that the client can supply hints for valid and preferred lifetimes when it has no preference for leased address. The address is simply ignored, and the lifetime fields are consumed as client hints. One DHCPv6 client is known to do this. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFJd2NAcXeLeWu2vmoRAtwLAJ4u0ZhNc8RttGvii3dBl88rYYJ7jwCgti5n Z0cAr7QGCjk/yLGzeAWlKQY= =MHKZ -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- --===============0645330562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0645330562==-- From dhcwg-bounces@ietf.org Fri Jan 23 10:07:47 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A063A69F5; Fri, 23 Jan 2009 10:07:47 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EF63A69AB for ; Fri, 23 Jan 2009 10:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYqEnp5ryKEu for ; Fri, 23 Jan 2009 10:07:45 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 9726E3A691A for ; Fri, 23 Jan 2009 10:07:45 -0800 (PST) Received: (qmail 21000 invoked from network); 23 Jan 2009 18:07:25 -0000 Received: from unknown (67.160.38.190) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 23 Jan 2009 18:07:25 -0000 From: "Glen Zorn" To: "'Ralph Droms'" References: <74CA549E-0F7F-4575-BFB7-DE1D85AC8BEE@cisco.com> <1127C1EE-5803-4393-B18F-F1AE6E7EF7F6@cisco.com> In-Reply-To: <1127C1EE-5803-4393-B18F-F1AE6E7EF7F6@cisco.com> Date: Fri, 23 Jan 2009 10:06:40 -0800 Organization: Network Zen Message-ID: <001b01c97d85$5824d120$086e7360$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl9WcBidAUypBxVQ2e0/hKnzw+bxgAKszMg Content-Language: en-us Cc: 'DHCP Working Group' Subject: Re: [dhcwg] Fwd: [dnsext] Re: DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph Droms [mailto:rdroms@cisco.com] writes: > I sent the following message to the namedroppers mailing list as part > of the discussion of the DNS proxy discussion. It wouldn't hurt to > get more dhc WG opinion on the draft - please follow up on the > namedroppers list. I, for one, don't really need to belong to YAML, so is there any way that we can simply include dhc in the discussion (it seems only polite to do so ;-). ... ~gwz --------------------------- Today in History 2002: 55 arrested at the UN for protesting the US war in Afghanistan & the "War on Terror" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From mlevine@accredhome.com Fri Jan 23 13:52:52 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7966E3A6B38 for ; Fri, 23 Jan 2009 13:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.37 X-Spam-Level: X-Spam-Status: No, score=-14.37 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW2lWKYMRO5V for ; Fri, 23 Jan 2009 13:52:51 -0800 (PST) Received: from alcoa.com.br (unknown [189.104.205.166]) by core3.amsl.com (Postfix) with SMTP id 708F13A6B32 for ; Fri, 23 Jan 2009 13:52:49 -0800 (PST) To: Subject: PayPal - Email Handling Opinion Needed From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090123215250.708F13A6B32@core3.amsl.com> Date: Fri, 23 Jan 2009 13:52:49 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.practicekind.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://practicekind.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B848. 735 Clements Road. London. SE95 3DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From pace@advancedmailing.com Sat Jan 24 02:16:16 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F693A68E0 for ; Sat, 24 Jan 2009 02:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.839 X-Spam-Level: X-Spam-Status: No, score=-43.839 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u95pBCPR157 for ; Sat, 24 Jan 2009 02:16:16 -0800 (PST) Received: from gw.zsustadionu.chrudim.cz (gw.zsustadionu.chrudim.cz [213.226.209.138]) by core3.amsl.com (Postfix) with SMTP id 279473A67B6 for ; Sat, 24 Jan 2009 02:16:14 -0800 (PST) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124101615.279473A67B6@core3.amsl.com> Date: Sat, 24 Jan 2009 02:16:14 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.rockintuition.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://rockintuition.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B649. 499 Clements Road. London. SE73 9DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From dhcwg-bounces@ietf.org Sat Jan 24 08:30:34 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BB528C150; Sat, 24 Jan 2009 08:30:34 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610CF28C0EA for ; Mon, 19 Jan 2009 17:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a7HEYevYDOf for ; Mon, 19 Jan 2009 17:03:11 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 6E3803A6A24 for ; Mon, 19 Jan 2009 17:03:11 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3414292wfd.31 for ; Mon, 19 Jan 2009 17:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jzgvCKc+dcwUseh5DJT+5tBlw7Sm+hFWmOm6KTzVoJw=; b=THloEpWJac1Ddb8b3HyDGCSqnHPeMSIqFhEvm6VyM2VaGIyZrnfvWKQP3liI98Lgjt xSMfQoJE07lK4HYsU0hlLC43XgNisC/a8TnmwoEUbYznANes5s/9lZp6H1oOLRiiaa6s NNONrMc3eZ3m0i2YXE1v48xLyZqYHvuCZsIow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jucC0fzN3akFUH+/ATEAcJLw7gm1G+LhdyDMp+sPpu3xp5axljXl7l4czcSi1G+e7T Z+mnrjMAJ7iRG9vT7cz33ZE65D0lKZKVC1eYZA8bVmric6RtIg2hGWOtiAj5plbWIMju W5b9uW/iBGhmSCKWZecpaUlJ8JKCxLvr8B5l4= Received: by 10.142.125.9 with SMTP id x9mr2606177wfc.85.1232413374339; Mon, 19 Jan 2009 17:02:54 -0800 (PST) Received: by 10.142.141.12 with HTTP; Mon, 19 Jan 2009 17:02:54 -0800 (PST) Message-ID: Date: Mon, 19 Jan 2009 17:02:54 -0800 From: "Vijay Devarapalli" To: "Bernie Volz (volz)" , "Ted Lemon" , "David W.Hankins" In-Reply-To: <8E296595B6471A4689555D5D725EBB210AACA7F3@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <8E296595B6471A4689555D5D725EBB210AACA7F3@xmb-rtp-20a.amer.cisco.com> X-Mailman-Approved-At: Sat, 24 Jan 2009 08:30:33 -0800 Cc: Dhcwg , Chairs , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org It is not clear to me why the DHC WG is discussing the scenarios for MIH server discovery. For more information on the scenarios, see http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-11.txt. This document is also currently with the IESG. For those who are not familiar with how DNS is used in cellular networks, the FQDN can change quite a bit based on the roaming scenarios. Sometimes the operator code and the country code are embedded in the DNS string. Sometimes the type of mobility anchor, GTP-based or Mobile IP-based is also encoded in the FQDN. In the MIH scenarios, the type of MoS server is encoded in the FQDN. The DHCP server would be dumb. Some network element would tell the DHCP server what to convey to the mobile node. Please be assured that we do need the capability to convey either the IP address or the FQDN of the MIH server to the mobile node via DHCP. draft-ietf-mipshop-mos-dhcp-options only provides a part of the solution, i.e, define the DHCP options for carrying the MIH server information. Vijay On Sat, Jan 17, 2009 at 7:35 PM, Bernie Volz (volz) wrote: > Just for the record, there are DHCP server implementations that do > support this encoding-byte + data (depending on encoding-byte) format. > > And, the RFC 3495 (CableLabs Client Configuration Option) is used by > lots of devices. > > As it is used in several places, I do think the cat is out of the bag > and I think it should be usable by new options. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ted Lemon > Sent: Friday, January 16, 2009 1:25 PM > To: David W.Hankins > Cc: Dhcwg; Chairs; draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org; > Mipshop@core3.amsl.com > Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options > > On Jan 16, 2009, at 9:38 AM, David W. Hankins wrote: >> I'm unconvinced the demand for these options is sufficient for good >> deployment, and I haven't heard of existing implementations, so I am >> not changing my guidance. I think MIPSHOP should pick one encoding >> and stick with it. > > I have to side with David here. I was very much against the encoding > options in the other two RFCs as well, for two reasons: > > 1. As David says, it's extra code, which nobody is going to implement > if they don't have to. > 2. It's an additional knob to turn, and chances are that it will > always be turned the same way. And so the other way won't get tested > (I wish it were not so, but client testing has historically been very, > very spotty). And then when someone does use it, it will break. If > there were some value being added, it would be one thing, but there's > no value added here - it's just a decision the protocol designer is > deciding not to make. > > My advice is to make the decision, and make it the way everyone else > does: send an IP address. If you don't agree with this decision, > please state a use case for the FQDN encoding. Not "someone might > want to do FQDN encoding for some reason" but rather "in this case > (provide a case here) it will be necessary to do FQDN encoding because > IP-address encoding won't work or has the following severe > disadvantage (explain disadvantage)." If you can't come up with one, > then the conditional flag here is not only unnecessary, but harmful. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jan 26 06:19:42 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAE528C173; Mon, 26 Jan 2009 06:19:42 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CF428C173 for ; Mon, 26 Jan 2009 06:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qtf-6jn82Eh for ; Mon, 26 Jan 2009 06:19:40 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 925553A6BA3 for ; Mon, 26 Jan 2009 06:19:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,325,1231113600"; d="scan'208";a="34871407" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2009 14:19:22 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0QEJMHd018036; Mon, 26 Jan 2009 09:19:22 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0QEJLdG019704; Mon, 26 Jan 2009 14:19:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 09:19:21 -0500 Received: from dhcp-161-44-114-52.cisco.com ([161.44.114.52]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 09:19:21 -0500 Message-Id: <56C09462-CB08-4F95-9585-A7727B57D018@cisco.com> From: Ralph Droms To: Glen Zorn In-Reply-To: <001b01c97d85$5824d120$086e7360$@net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 09:19:24 -0500 References: <74CA549E-0F7F-4575-BFB7-DE1D85AC8BEE@cisco.com> <1127C1EE-5803-4393-B18F-F1AE6E7EF7F6@cisco.com> <001b01c97d85$5824d120$086e7360$@net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 14:19:21.0522 (UTC) FILETIME=[150AE120:01C97FC1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1073; t=1232979562; x=1233843562; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Fwd=3A=20[dnsext]=20Re=3A=20D NS=20Proxy=20Implementation=20Guidelines=20-=09draft-ietf-dn sext-dnsproxy-01 |Sender:=20 |To:=20Glen=20Zorn=20; bh=KKt5BQgBXBMlTy9awPiLrNK7uB1MqQ5FnjAttIaOSSE=; b=ifg+DGbVB/wdFnwzCIx+pnA4AddkViZZONlMS/X0qNVm25o8s4QnW1uJ4y KLUvdu24fikNoT6IrtG5JnoT2n7bYqZTr5XDFHLT7ic+kOlY2j9z9uhAU0BB tHgltko9Vh; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: DHCP Working Group Subject: Re: [dhcwg] Fwd: [dnsext] Re: DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I figured most everyone interested would already be subscribed to namedroppers. Turns out the re wasn't much response to my post. The entire thread starts here: http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00004.html and my response thread starts here: http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00116.html - Ralph On Jan 23, 2009, at 1:06 PM 1/23/09, Glen Zorn wrote: > Ralph Droms [mailto:rdroms@cisco.com] writes: > >> I sent the following message to the namedroppers mailing list as part >> of the discussion of the DNS proxy discussion. It wouldn't hurt to >> get more dhc WG opinion on the draft - please follow up on the >> namedroppers list. > > I, for one, don't really need to belong to YAML, so is there any way > that we > can simply include dhc in the discussion (it seems only polite to do > so ;-). > > ... > > ~gwz > --------------------------- > Today in History > 2002: 55 arrested at the UN for protesting the US war in Afghanistan > & the > "War on Terror" > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From mikebecker@alrinc.com Mon Jan 26 10:52:04 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3F53A68E6 for ; Mon, 26 Jan 2009 10:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.972 X-Spam-Level: X-Spam-Status: No, score=-7.972 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MX=0.535, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HIfzWEG4+Om for ; Mon, 26 Jan 2009 10:52:01 -0800 (PST) Received: from host-200-94-111-147.block.alestra.net.mx (host-200-94-111-147.block.alestra.net.mx [200.94.111.147]) by core3.amsl.com (Postfix) with SMTP id 8E23A3A683D for ; Mon, 26 Jan 2009 10:51:56 -0800 (PST) To: Subject: Welcome to eBay! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126185158.8E23A3A683D@core3.amsl.com> Date: Mon, 26 Jan 2009 10:51:56 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.electricallow.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://electricallow.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B507. 894 Clements Road. London. SE55 0DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From ne_enrollment@adp.com Mon Jan 26 16:26:28 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABFA63A6833 for ; Mon, 26 Jan 2009 16:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.016 X-Spam-Level: X-Spam-Status: No, score=-27.016 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e213JtyEral4 for ; Mon, 26 Jan 2009 16:26:28 -0800 (PST) Received: from 189-69-44-89.dsl.telesp.net.br (189-69-44-89.dsl.telesp.net.br [189.69.44.89]) by core3.amsl.com (Postfix) with SMTP id B53313A6841 for ; Mon, 26 Jan 2009 16:26:26 -0800 (PST) To: Subject: Receipt for Your Payment From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 080723-1, 23/07/2008), Outbound message X-Antivirus-Status: Clean Message-Id: <20090127002626.B53313A6841@core3.amsl.com> Date: Mon, 26 Jan 2009 16:26:26 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.tubeshell.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://tubeshell.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 8, B760. 439 Clements Road. London. SE10 7DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From j.bermudez@airpma.net Tue Jan 27 01:03:12 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8073F3A6BCA for ; Tue, 27 Jan 2009 01:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.512 X-Spam-Level: X-Spam-Status: No, score=-31.512 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0Op5mHXWYvs for ; Tue, 27 Jan 2009 01:03:09 -0800 (PST) Received: from host81-152-142-157.range81-152.btcentralplus.com (host81-152-142-157.range81-152.btcentralplus.com [81.152.142.157]) by core3.amsl.com (Postfix) with SMTP id C4F603A6BC6 for ; Tue, 27 Jan 2009 01:03:07 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127090307.C4F603A6BC6@core3.amsl.com> Date: Tue, 27 Jan 2009 01:03:07 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.tubeshell.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://tubeshell.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 6, B656. 692 Clements Road. London. SE85 1DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From dhcwg-bounces@ietf.org Tue Jan 27 03:41:28 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0588F3A6A46; Tue, 27 Jan 2009 03:41:28 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9133A6A46 for ; Tue, 27 Jan 2009 03:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMxGhLFoobrx for ; Tue, 27 Jan 2009 03:41:25 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C7DE43A6861 for ; Tue, 27 Jan 2009 03:41:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,332,1231113600"; d="scan'208";a="61139912" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2009 11:41:08 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0RBf87m027375; Tue, 27 Jan 2009 03:41:08 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0RBf6PB017161; Tue, 27 Jan 2009 11:41:08 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 06:41:07 -0500 Received: from bxb-rdroms-8711.cisco.com ([10.98.10.82]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 06:41:06 -0500 Message-Id: <3B47C198-A077-4864-858D-AF0061FBC5B4@cisco.com> From: Ralph Droms To: Ralph Droms In-Reply-To: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 27 Jan 2009 06:41:06 -0500 References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 27 Jan 2009 11:41:07.0232 (UTC) FILETIME=[246AF200:01C98074] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1566; t=1233056468; x=1233920468; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20review=20of=20draf t-ietf-geopriv-lis-discovery-05 |Sender:=20; bh=XmQcFPkXI7P3aSP5+FsmnEPP0AQH/m+HzFfNBgaai90=; b=M8wO9ukYOmz7OgpJYSBzp4t/QnjiFHQ5IiDQqZDaxAj/ot9XKr+Pn0IjWK Dzj+bHn/GUPuY7F5BoIHMd9VaUZc76G49rDw8oDkFMGlt6CtSx1vdZ3YUxHS mzoc1cHl4wmce2PvavguL5S4RGmdv812aVf8ptXCIo9Bzn0ELb7JI=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Dhcwg WG , "Winterbottom, James" , "Thomson, Martin" , Richard Barnes Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I have a few comments about the details of the DHCPv4 and DHCPv6 option syntax in this draft. Can there be more than one fingerprint and more than one URI carried in the LIS-URI option? I don't think the draft explicitly restricts the option. Because the URI does not include a length field, it would seem to limit the option to one URI, and the fingerprint MUST come before the URI. I think the text should be explicit on this point. If I understand this restriction correctly, it may be possible to simplify the option syntax by assuming the order and number of fields in the option. I'll defer to dhc WG members for opinions on whether there might be a modification to the syntax that would be more in line with existing options and implementations. The DHCPv6 option doesn't have the 253 byte length restriction. It would be good to mention that difference between the two option versions. - Ralph On Jan 16, 2009, at 3:16 PM 1/16/09, Ralph Droms wrote: > "Discovering the Local Location Information Server (LIS)," http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-05 > , defines DHCPv[46] options to carry the address of a LIS to a > host. The geopriv WG would like to get dhc WG review and feedback > on the syntax and use of these options. Please review the draft and > reply to the mailing list with comments. Thanks... > > - Ralph > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From lmena@alaparrilla.com Tue Jan 27 08:33:56 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C97B3A68CC for ; Tue, 27 Jan 2009 08:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.424 X-Spam-Level: X-Spam-Status: No, score=-15.424 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60otKOw5QbdU for ; Tue, 27 Jan 2009 08:33:55 -0800 (PST) Received: from aacps.org (unknown [200.121.17.26]) by core3.amsl.com (Postfix) with SMTP id A395F3A6986 for ; Tue, 27 Jan 2009 08:33:53 -0800 (PST) To: Subject: New products everyday at our chemists. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127163354.A395F3A6986@core3.amsl.com> Date: Tue, 27 Jan 2009 08:33:53 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello dhcwg-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L6796.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From mechamdd@allied-brokers.com Tue Jan 27 09:40:47 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79AC13A68F3 for ; Tue, 27 Jan 2009 09:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HELO_DYNAMIC_SPLIT_IP=3.493, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHXIQh1eLOFC for ; Tue, 27 Jan 2009 09:40:39 -0800 (PST) Received: from 13.Red-80-39-80.staticIP.rima-tde.net (13.Red-80-39-80.staticIP.rima-tde.net [80.39.80.13]) by core3.amsl.com (Postfix) with SMTP id 0119F3A6AB6 for ; Tue, 27 Jan 2009 09:40:37 -0800 (PST) To: Subject: Fwd: Finest products From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127174038.0119F3A6AB6@core3.amsl.com> Date: Tue, 27 Jan 2009 09:40:37 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello dhcwg-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L9832.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From dhcwg-bounces@ietf.org Tue Jan 27 11:38:37 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027003A696A; Tue, 27 Jan 2009 11:38:37 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F613A696A for ; Tue, 27 Jan 2009 11:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfs5+Jtx0kDl for ; Tue, 27 Jan 2009 11:38:35 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 408873A6825 for ; Tue, 27 Jan 2009 11:38:34 -0800 (PST) Received: from hcf.isc.org (dhcp-232.sql1.isc.org [204.152.187.232]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n0RJc5mg025823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 11:38:05 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 0C1A557342; Tue, 27 Jan 2009 11:39:47 -0800 (PST) Date: Tue, 27 Jan 2009 11:39:47 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20090127193947.GC3215@isc.org> References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> <3B47C198-A077-4864-858D-AF0061FBC5B4@cisco.com> MIME-Version: 1.0 In-Reply-To: <3B47C198-A077-4864-858D-AF0061FBC5B4@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Richard Barnes , "Winterbottom, James" , "Thomson, Martin" Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1973845028==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1973845028== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lCAWRPmW1mITcIfM" Content-Disposition: inline --lCAWRPmW1mITcIfM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote: > Can there be more than one fingerprint and more than one URI carried in t= he=20 > LIS-URI option? I don't think the draft explicitly restricts the option.= =20 > Because the URI does not include a length field, it would seem to limit t= he=20 > option to one URI, and the fingerprint MUST come before the URI. I think= =20 > the text should be explicit on this point. >=20 > If I understand this restriction correctly, it may be possible to simplif= y=20 > the option syntax by assuming the order and number of fields in the optio= n.=20 > I'll defer to dhc WG members for opinions on whether there might be a=20 > modification to the syntax that would be more in line with existing optio= ns=20 > and implementations. I presumed the intent was to provide only one URI. I think that if you squint and turn your head sideways, the 'f-code, f-length' looks like a suboption (except that the URI's f-code implies no length octet, evidently a format size optimization). I want to ask if the idea is to intentionally make a distinction between 'f-code's and suboptions, such as in order to support multiple instances of one f-code (and not provoke option concatenation as would happen with multiple sub-option codes of the same value). If they can be suboptions, then why not multiple regular options? I think the answer is that the certificate is useless without the URI, and vice versa, so if a DHCP server omitted one due to running out of space it is better to omit both. Containering them together solves this neatly. > The DHCPv6 option doesn't have the 253 byte length restriction. It would= =20 > be good to mention that difference between the two option versions. I was curious what you meant (253, not 255?), so went back to re-read the draft. I don't see the number 253 mentioned, nor 255! It /does/ mention '225'. This appears to be a typo? My only suggestion for the mention of the option size is to refer specifically to the 'length field value', and not to terms like 'URI length' or 'option length', which can be misinterpreted from different starting positions. Otherwise I like this approach of referring to the extension of option space as a DHCPv4 protocol feature, and not trying to reinvent its specification. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --lCAWRPmW1mITcIfM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl/YwMACgkQcXeLeWu2vmo3/wCdFKJhNyxRQSx4anvGn3chejvJ ctEAnRvFodeW2G5F7tmRTX9M5R147i/L =m/4F -----END PGP SIGNATURE----- --lCAWRPmW1mITcIfM-- --===============1973845028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1973845028==-- From dhcwg-bounces@ietf.org Tue Jan 27 12:02:45 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D326A28C193; Tue, 27 Jan 2009 12:02:45 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E87E28C193 for ; Tue, 27 Jan 2009 12:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBa8nUBc-bn4 for ; Tue, 27 Jan 2009 12:02:43 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1435528C153 for ; Tue, 27 Jan 2009 12:02:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,334,1231113600"; d="scan'208";a="134193485" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2009 20:02:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0RK2P6E019172; Tue, 27 Jan 2009 12:02:25 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0RK2FwZ027012; Tue, 27 Jan 2009 20:02:25 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 15:02:17 -0500 Received: from kkinnear-wxp01.cisco.com ([161.44.65.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 15:02:16 -0500 Message-Id: <4.3.2.7.2.20090127144649.03068840@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Jan 2009 15:02:28 -0500 To: Kim Kinnear , Alfred =?hp-roman8?B?SM5uZXM=?= , raj@cisco.com, mjs@cisco.com, jayk@cisco.com From: Kim Kinnear In-Reply-To: <4.3.2.7.2.20090107132315.0361da68@email.cisco.com> References: <200812232102.WAA15459@TR-Sys.de> Mime-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2009 20:02:17.0015 (UTC) FILETIME=[2767B470:01C980BA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10304; t=1233086545; x=1233950545; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-vpn-option-09= 20issue=20with=20sub-option=0A=20=20bouncing |Sender:=20; bh=jJ2uDMWB/juPaxLT1MBqX0gF5HuYAvg1yuB0dlEyLiY=; b=b8ITV4+BXV7zgGBymvp5+LfgJYMlrfco6e9znpC4OjMfYy0L9TzmoaZ6iu lZTop1zt0oKFogw4CZTb7VmfFiWoo9aqIPiu+pCaZonnb8+tvwUCoPRSQ1XA LfjEzQOVmy; Authentication-Results: sj-dkim-2; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-vpn-option-09 issue with sub-option bouncing X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Alfred, others on the dhcwg list, Alfred, I have responded to your substantive (as opposed to editorial) concern about the current version of the vpn-option draft (09). See below for details. The short story is that I believe the draft is acceptable as it stands, particularly since David Hankins raised an issue very similar if not identical to this in the past and we revised to draft to acceptably meet his objections. However, I have agreed to put some words into the draft to ensure that people understand the need to have a server which supports the VSS option if they configure their relay agents to use the VSS option. This might help mitigate the concern you have, though it is less than you proposed. As your proposal includes a considerable addition to the mechanism of the VSS option, I was looking for other support for your proposal from the list. I have not heard anyone who agreed that what you propose is necessary, nor anyone who suggested that it was not necessary. I have also not heard back from you concerning your reaction to my explanations and proposals, though it is possible that I have missed your email, and if so, I certainly apologize. So, I'm trying a second time to elicit some response from the list as well as feedback from you. Options: (a) Draft is acceptable as is. (b) Add more words to ensure that people know that they = need to use a DHCP server which supports VSS options if they configure VSS options in a relay agent. (c) Implement Alfred's proposal to define a new range of type bytes and specify how they are used so that a relay agent knows for sure whether a DHCP server supports the VSS option when it is used. Thanks all -- Kim At 09:08 PM 1/7/2009, Kim Kinnear wrote: >At 04:02 PM 12/23/2008, Alfred =3D?hp-roman8?B?SM5uZXM=3D?=3D wrote: > >>I have reviewed draft-ietf-dhc-vpn-option-09 and already sent >>off-list a couple of editorial notes. > > Yes, thank you for those. When I next revise the draft, > I'll include these editorial changes. > > >>However, I see one significant issue not satisfactorily resolved >>in the current draft version. >>Below, I recall the problem and propose a mechanism to mitigate it. >> >>As explained in various places in the draft (in particular >>Section 7.2), in the DHPCv4 case the utility of the VSS sub-option >>suffers from the default behavior of the server (per RFC 3046) of >>blindly bouncing unknown sub-options of the Realy-Agent-Information >>option. This way, the DHCP relay originally sending the sub-option >>in the request can not conclude from the sub-option in the reply >>whether the server has not understood the VSS sub-option and simply >>bounced it or it has understood the VSS sub-option and confirmed >>the value sent in the request by echoing the unchanged VSS sub- >>option. >> >>That seems to be a significant drawback. > > Yes and no. The case that is hard to distinguish is the > case where the DHCP server doesn't support the VSS option > but the relay agent expects that it does. > > As stated in the draft: > >> The current use of the VSS option and sub-option require that each >> entity knows the part that it plays in dealing with VPN data. Each >> entity -- client, relay agent or agents, and server -- SHOULD know >> through some policy or configuration beyond the scope of this >> document whether it is responsible for specifying VPN information >> using the VSS option or sub-option or responsible for responding to >> VSS information specified by another entity, or simply ignoring any >> VSS information which it might see. > > Perhaps we could extend this to include a statement that > not only SHOULD the entities know their respective roles > regarding the VSS option/information, but that they > SHOULD also be capable of supporting the processing > required by the role they are playing. I'd be up for > that, though I think it is kind of implied. > > The case that for which you have proposed a solution is > one where the DHCP server doesn't understand the VSS > option and therefore doesn't process it at all. This is > a total configuration screwup, not something that can > happen on one packet and not happen on the next packet. > This will never work. > > So, "yes", it is a drawback that the relay agent can't > tell if the server supports VSS processing from the > contents of one packet. But it is important to > understand that the entire processing of these > options/sub-options requires configuration correspondence > well outside of the bounds of what is documented in this > draft (and the draft make that point more than once). > > Having a DHCP server that supports the VSS option > installed if you are going to configure your relay agents > to support VSS processing is just one more part of the > configuration correspondence that is required, and not > the largest part by any means. > > My point is that I believe the particular issue which you > have focused looks like it is significant if you look > just at this one issue, but if you stand back a bit I > think that it isn't actually an operational problem of > significance given the other things you have to get right > to put together a working system which incorporates VSS > option processing. Another way to put this is to say > that solving this one problem will make it only > fractionally easier in the field to configure these > systems. > > So, personally, I believe that the draft is acceptable as > it stands. Although I'd gladly add words about this > issue and the requirement to have a DHCP server that > supports VSS option processing if you are going to > configure such processing on your relay agents. This > would be easy, but not what you are advocating. > > That said, what you have proposed below would indeed > solve this problem. I feel it is a relatively large > amount of mechanism given the scope of the problem it is > designed to solve. However, it would work and could be > included into the draft if there is a general consensus > that this is the right approach. > > I'll be looking for input from other folks to see if we > have that general consensus for the changes that you have > proposed. > > A number of other folks have found the draft to be > acceptable as-is, and indeed this particular problem was > brought up by David Hankins in the past and the solution > that is embodied in the draft at this point satisfied his > previous objections. > > Not least, this draft has been through last call after > last call, and if we make this change we may need to go > through yet another last call. This prospect leaves me > less than thrilled, as I'm sure you can understand, but > getting it right (or at least right enough) is certainly > more important. > > Thanks for reading the draft. > > Regards -- Kim > >>After some consideration of the problem, it becomes apparent that >>it depends on the VSS type whether or not this is a real issue. >>In the "global/default VPN" case (VSS type 255), it looks like >>the realy agent would not gain anything from being able to >>distinguish the two cases; that apparently only matters for the >>VSS types 0 and 1 (or any possible future 'concrete' values). >> >>This has guided me to envision modified encoding and processing >>rules of the VSS type -- see below. >> >>Due to lack of time, I have not tried to discover if this idea >>already has been considered in the past. If so, and it has been >>rejected, I apologize for bringing it up again. >> >>a) Encoding: >> >> VSS types 127..254 are permanently forbidden for VSS information >> in the DHVPv4/v6 VSS options and the v4 VSS sub-option in a >> message to the server. >> >> For the VSS sub-option in a response, the following additional >> values are defined: >> >> 128 same as 0, but "confirmed by server" >> 129 same as 1, but "confirmed by server" >> >>b) Server Processing >> >>A DHCPv4 server that understands the VSS sub-option (and supports >>this advanced encoding) sets the MSB in the VSS type when it copies >>the sub-option to the response "unchanged" per the current draft. >>Note that this is an idempotent operation on the 'global' VSS type >>value, leaving it unchanged for improved interoperability with >>existing implementations. >> >>TBD: It needs to be figured out whether it might be preferable >> (yet less backwards compatible) to also set the MSB when the >> server *changes* the VS type in the VSS sub-option to be sent >> back to one of the 'concrete' values (currently 0 or 1). >> >>Note: This revised server behavior SHOULD be subject to activation >> per configuration, with defaults to 'off'. >> >>c) Relay Agent Processing >> >>A DHCPv4 Relay Agent receiving one of the new VSS types in the >>VSS sub-option strips the MSB of the VSS type and performs the >>processing currently described in the draft, but it also notes that >>the server has confirmed the (proposed) value it had sent in the >>request, and can hence exclude all considerations and cautionary >>processing related to lack of distinction between the two cases. >> >> >>Kind regards, >> Alfred H=CEnes. >> >>-- = >> >>+------------------------ +--------------------------------------------+ >>| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- Phys. | >>| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: = >>-18 | >>| D-71254 Ditzingen | E-Mail: ah@TR- Sys.de | >>+------------------------ +--------------------------------------------+ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jan 27 12:06:50 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6C53A6B09; Tue, 27 Jan 2009 12:06:50 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CDD28C153 for ; Tue, 27 Jan 2009 12:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHZcuCxaiCtk for ; Tue, 27 Jan 2009 12:06:48 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9EBC43A687D for ; Tue, 27 Jan 2009 12:06:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,334,1231113600"; d="scan'208";a="34997503" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2009 20:06:30 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0RK6UXv010823; Tue, 27 Jan 2009 15:06:30 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0RK6UQr018231; Tue, 27 Jan 2009 20:06:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 15:06:30 -0500 Received: from bxb-rdroms-8711.cisco.com ([10.98.10.82]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 15:06:29 -0500 Message-Id: From: Ralph Droms To: "David W. Hankins" In-Reply-To: <20090127193947.GC3215@isc.org> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 27 Jan 2009 15:06:28 -0500 References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> <3B47C198-A077-4864-858D-AF0061FBC5B4@cisco.com> <20090127193947.GC3215@isc.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 27 Jan 2009 20:06:29.0795 (UTC) FILETIME=[BE12DF30:01C980BA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4014; t=1233086790; x=1233950790; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20review=20of=20draf t-ietf-geopriv-lis-discovery-05 |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20; bh=1DBIDWLAmcx3s0TlV3N7M6quRLaMPVlEWljHEkbAHz4=; b=Fd+glT8YPLVbfQd0aQaN0qUPYu/EYyX89gqYtX+YXvtQGeJqHwfs2CnyBV R/JHs0QOXLQ38FZupwPLqQzpyJwjOwzf8EvhhlfA6oobaJfUOFDnQZ162ya5 8py1N1VzKv; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: DHC WG , Richard Barnes , "Winterbottom, James" , "Thomson, Martin" , Ralph Droms Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org David - if, indeed, the idea is for one URI, with an optional fingerprint, would the following format be sensible and simpler to parse? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LIS_URI | Length | Hash-Type-Len | Hash-Type ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash-Type (cont.) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fprint-Len | Fingerprint-Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI (cont.) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Hash-Type-Len and Fprint-Len are both either zero (no fingerprint) or greater than 0 (fingerprint included). - Ralph On Jan 27, 2009, at 2:39 PM 1/27/09, David W. Hankins wrote: > On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote: >> Can there be more than one fingerprint and more than one URI >> carried in the >> LIS-URI option? I don't think the draft explicitly restricts the >> option. >> Because the URI does not include a length field, it would seem to >> limit the >> option to one URI, and the fingerprint MUST come before the URI. I >> think >> the text should be explicit on this point. >> >> If I understand this restriction correctly, it may be possible to >> simplify >> the option syntax by assuming the order and number of fields in the >> option. >> I'll defer to dhc WG members for opinions on whether there might be a >> modification to the syntax that would be more in line with existing >> options >> and implementations. > > I presumed the intent was to provide only one URI. > > I think that if you squint and turn your head sideways, the 'f-code, > f-length' looks like a suboption (except that the URI's f-code implies > no length octet, evidently a format size optimization). > > I want to ask if the idea is to intentionally make a distinction > between 'f-code's and suboptions, such as in order to support multiple > instances of one f-code (and not provoke option concatenation as would > happen with multiple sub-option codes of the same value). > > If they can be suboptions, then why not multiple regular options? > I think the answer is that the certificate is useless without the URI, > and vice versa, so if a DHCP server omitted one due to running out of > space it is better to omit both. Containering them together solves > this neatly. > >> The DHCPv6 option doesn't have the 253 byte length restriction. It >> would >> be good to mention that difference between the two option versions. > > I was curious what you meant (253, not 255?), so went back to re-read > the draft. I don't see the number 253 mentioned, nor 255! > > It /does/ mention '225'. This appears to be a typo? > > My only suggestion for the mention of the option size is to refer > specifically to the 'length field value', and not to terms like 'URI > length' or 'option length', which can be misinterpreted from different > starting positions. > > Otherwise I like this approach of referring to the extension of option > space as a DHCPv4 protocol feature, and not trying to reinvent its > specification. > > -- > David W. Hankins "If you don't do it right the first time, > Software Engineer you'll just have to do it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From oconnor@altmancos.com Tue Jan 27 13:03:23 2009 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BE628C1C6 for ; Tue, 27 Jan 2009 13:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.051 X-Spam-Level: X-Spam-Status: No, score=-22.051 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arEiUDPnH4tr for ; Tue, 27 Jan 2009 13:03:20 -0800 (PST) Received: from 200-171-91-142.dsl.telesp.net.br (200-171-91-142.dsl.telesp.net.br [200.171.91.142]) by core3.amsl.com (Postfix) with SMTP id BDCC03A67F8 for ; Tue, 27 Jan 2009 13:03:18 -0800 (PST) To: Subject: Payment Accepted! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127210319.BDCC03A67F8@core3.amsl.com> Date: Tue, 27 Jan 2009 13:03:18 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.termexercise.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://termexercise.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 7, B650. 998 Clements Road. London. SE67 4DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From dhcwg-bounces@ietf.org Wed Jan 28 00:59:04 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813EC28C10D; Wed, 28 Jan 2009 00:59:04 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9757F28C18B for ; Wed, 28 Jan 2009 00:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qr14nxznV5G for ; Wed, 28 Jan 2009 00:59:01 -0800 (PST) Received: from cl40.gs02.gridserver.com (cl40.gs02.gridserver.com [64.13.232.49]) by core3.amsl.com (Postfix) with ESMTP id 87E0728C10D for ; Wed, 28 Jan 2009 00:59:01 -0800 (PST) Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:37763 helo=offset.weird.se) by cl40.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from ) id 1LS6Fv-0001wq-Fv for dhcwg@ietf.org; Wed, 28 Jan 2009 00:58:43 -0800 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Date: Wed, 28 Jan 2009 09:52:19 +0100 User-Agent: KMail/1.9.9 References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> <20090127193947.GC3215@isc.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901280952.19470.budm@weird-solutions.com> X-Authenticated-User: 39280 budm@broadbandprovisioner.com Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Bud Millwood List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tuesday 27 January 2009, Ralph Droms wrote: > David - if, indeed, the idea is for one URI, with an optional > fingerprint, would the following format be sensible and simpler to > parse? This option would be much better served as a subencoded option IMO. It's going through terrible contortions to encode both fixed-field settings and variable length settings. I think a better approach would be to encode everything as suboptions, and then to simply dictate which options should be present under the different circumstances. - Bud > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LIS_URI | Length | Hash-Type-Len | Hash-Type ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash-Type (cont.) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fprint-Len | Fingerprint-Value ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | URI ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | URI (cont.) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where Hash-Type-Len and Fprint-Len are both either zero (no > fingerprint) or greater than 0 (fingerprint included). > > - Ralph > > On Jan 27, 2009, at 2:39 PM 1/27/09, David W. Hankins wrote: > > On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote: > >> Can there be more than one fingerprint and more than one URI > >> carried in the > >> LIS-URI option? I don't think the draft explicitly restricts the > >> option. > >> Because the URI does not include a length field, it would seem to > >> limit the > >> option to one URI, and the fingerprint MUST come before the URI. I > >> think > >> the text should be explicit on this point. > >> > >> If I understand this restriction correctly, it may be possible to > >> simplify > >> the option syntax by assuming the order and number of fields in the > >> option. > >> I'll defer to dhc WG members for opinions on whether there might be a > >> modification to the syntax that would be more in line with existing > >> options > >> and implementations. > > > > I presumed the intent was to provide only one URI. > > > > I think that if you squint and turn your head sideways, the 'f-code, > > f-length' looks like a suboption (except that the URI's f-code implies > > no length octet, evidently a format size optimization). > > > > I want to ask if the idea is to intentionally make a distinction > > between 'f-code's and suboptions, such as in order to support multiple > > instances of one f-code (and not provoke option concatenation as would > > happen with multiple sub-option codes of the same value). > > > > If they can be suboptions, then why not multiple regular options? > > I think the answer is that the certificate is useless without the URI, > > and vice versa, so if a DHCP server omitted one due to running out of > > space it is better to omit both. Containering them together solves > > this neatly. > > > >> The DHCPv6 option doesn't have the 253 byte length restriction. It > >> would > >> be good to mention that difference between the two option versions. > > > > I was curious what you meant (253, not 255?), so went back to re-read > > the draft. I don't see the number 253 mentioned, nor 255! > > > > It /does/ mention '225'. This appears to be a typo? > > > > My only suggestion for the mention of the option size is to refer > > specifically to the 'length field value', and not to terms like 'URI > > length' or 'option length', which can be misinterpreted from different > > starting positions. > > > > Otherwise I like this approach of referring to the extension of option > > space as a DHCPv4 protocol feature, and not trying to reinvent its > > specification. > > > > -- > > David W. Hankins "If you don't do it right the first time, > > Software Engineer you'll just have to do it again." > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 28 02:20:06 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6736728C267; Wed, 28 Jan 2009 02:20:06 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9EC28C264 for ; Wed, 28 Jan 2009 02:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dEISjqbPdIC for ; Wed, 28 Jan 2009 02:20:04 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7F0FA28C0CF for ; Wed, 28 Jan 2009 02:20:04 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A6A6A198670; Wed, 28 Jan 2009 12:19:45 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 33A8119866C; Wed, 28 Jan 2009 12:19:45 +0200 (EET) Message-ID: <498030FE.9030302@piuha.net> Date: Wed, 28 Jan 2009 12:18:38 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Subir Das References: <494E1621.3020405@piuha.net> <49519EC3.3060007@research.telcordia.com> <496CFA55.8020904@piuha.net> <20090115235333.GD3263@isc.org> <496FF469.7030709@research.telcordia.com> <20090116173815.GA5060@isc.org> <0F29AFEB-0178-47AC-9C3F-D13BC805C7E7@nominum.com> <497119DA.80207@research.telcordia.com> <49711F4B.8000801@research.telcordia.com> <781121A5-B306-402E-B960-C6BE9F4FB9C2@nominum.com> <49756CC7.8020606@piuha.net> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , Mipshop Chairs , Ted Lemon , "draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org" Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Lets try to conclude this thread. I was under the impression that avoiding the "enc" field was acceptable to everyone, if we can still do what we need to do with other option(s). What I have not heard enough about yet is whether the two options are actually needed. Subir, I proposed simply transporting the FQDNs, and I though that would actually avoid all the issues raised so far. Can you see any problems with that? Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 28 09:53:10 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710603A69BC; Wed, 28 Jan 2009 09:53:10 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601193A69BC for ; Wed, 28 Jan 2009 09:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD9MAiOtwR0V for ; Wed, 28 Jan 2009 09:53:08 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 4BB7B3A6818 for ; Wed, 28 Jan 2009 09:53:08 -0800 (PST) Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSYCbbQASPQoQjS0/i6phNAlUrH5R4LAr@postini.com; Wed, 28 Jan 2009 09:52:51 PST Received: from kamas.ddns.nominum.com (kamas.ddns.nominum.com [64.89.224.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id E23761A8206; Wed, 28 Jan 2009 09:52:44 -0800 (PST) (envelope-from neild@nominum.com) Message-Id: From: Damien Neil To: Bud Millwood In-Reply-To: <200901280952.19470.budm@weird-solutions.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 28 Jan 2009 09:52:44 -0800 References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> <20090127193947.GC3215@isc.org> <200901280952.19470.budm@weird-solutions.com> X-Mailer: Apple Mail (2.930.3) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Jan 28, 2009, at 12:52 AM, Bud Millwood wrote: > I think a better approach would be to encode everything as > suboptions, and > then to simply dictate which options should be present under the > different > circumstances. I strongly agree with this. Suboptions are a much simpler and more flexible way of encoding this data. - Damien _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 28 19:02:53 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8C53A687F; Wed, 28 Jan 2009 19:02:53 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E99B3A687F for ; Wed, 28 Jan 2009 19:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAAdtxjX1jqt for ; Wed, 28 Jan 2009 19:02:51 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1AF503A6872 for ; Wed, 28 Jan 2009 19:02:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,341,1231113600"; d="scan'208";a="35217463" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2009 03:02:32 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0T32WKU010922; Wed, 28 Jan 2009 22:02:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0T32W9D018634; Thu, 29 Jan 2009 03:02:32 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 22:02:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jan 2009 22:02:05 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210ADE76BC@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <200901280952.19470.budm@weird-solutions.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 Thread-Index: AcmBJrXjzAZo4QUaTFSUiwnyQQkTsgAlpnbg References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com><20090127193947.GC3215@isc.org> <200901280952.19470.budm@weird-solutions.com> From: "Bernie Volz (volz)" To: "Bud Millwood" , X-OriginalArrivalTime: 29 Jan 2009 03:02:32.0468 (UTC) FILETIME=[07663D40:01C981BE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6020; t=1233198152; x=1234062152; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20review=20of=20draf t-ietf-geopriv-lis-discovery-05 |Sender:=20 |To:=20=22Bud=20Millwood=22=20,=2 0; bh=WBNMJDXDVDzPB3P+9YgdpM9TF6/0NKXcJCFT2YtQoMM=; b=xBjnoDope0rnAHvwrmLOvXPqcPuqCDEEms1/2Sk0LqD9krI+mrHamJHUhg QUsVyjNg6I2lWWuMgsNsy2OhtaRWIwSZUS3TXE/Q5CgxsNOV9y6ZyYfV5Ofw ++F+Ek4qJm; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I agree with Bud and Damien (and David) ... Defining suboptions would be far better way to go. Suboption 1 - URI Suboption 2 - Fingerprint (You could start with suboption 0, but as most sub-option users avoid suboption 0, I would not recommend it.) Now, if the intent is to allow multiple URI instances ... That should be OK as I don't recall that option concatentation extends to suboptions. Therefore, two instances of the same suboption are technically possible. Though hopefully that is not the case as it complicates servers (and clients) and is likely not supported by most servers today? The same should be done for DHCPv6 (though of course the suboptions are 16-bit sub-option code and length fields). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Wednesday, January 28, 2009 3:52 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 On Tuesday 27 January 2009, Ralph Droms wrote: > David - if, indeed, the idea is for one URI, with an optional > fingerprint, would the following format be sensible and simpler to > parse? This option would be much better served as a subencoded option IMO. It's going through terrible contortions to encode both fixed-field settings and variable length settings. I think a better approach would be to encode everything as suboptions, and then to simply dictate which options should be present under the different circumstances. - Bud > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LIS_URI | Length | Hash-Type-Len | Hash-Type ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash-Type (cont.) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fprint-Len | Fingerprint-Value ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | URI ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | URI (cont.) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where Hash-Type-Len and Fprint-Len are both either zero (no > fingerprint) or greater than 0 (fingerprint included). > > - Ralph > > On Jan 27, 2009, at 2:39 PM 1/27/09, David W. Hankins wrote: > > On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote: > >> Can there be more than one fingerprint and more than one URI > >> carried in the > >> LIS-URI option? I don't think the draft explicitly restricts the > >> option. > >> Because the URI does not include a length field, it would seem to > >> limit the > >> option to one URI, and the fingerprint MUST come before the URI. I > >> think > >> the text should be explicit on this point. > >> > >> If I understand this restriction correctly, it may be possible to > >> simplify > >> the option syntax by assuming the order and number of fields in the > >> option. > >> I'll defer to dhc WG members for opinions on whether there might be a > >> modification to the syntax that would be more in line with existing > >> options > >> and implementations. > > > > I presumed the intent was to provide only one URI. > > > > I think that if you squint and turn your head sideways, the 'f-code, > > f-length' looks like a suboption (except that the URI's f-code implies > > no length octet, evidently a format size optimization). > > > > I want to ask if the idea is to intentionally make a distinction > > between 'f-code's and suboptions, such as in order to support multiple > > instances of one f-code (and not provoke option concatenation as would > > happen with multiple sub-option codes of the same value). > > > > If they can be suboptions, then why not multiple regular options? > > I think the answer is that the certificate is useless without the URI, > > and vice versa, so if a DHCP server omitted one due to running out of > > space it is better to omit both. Containering them together solves > > this neatly. > > > >> The DHCPv6 option doesn't have the 253 byte length restriction. It > >> would > >> be good to mention that difference between the two option versions. > > > > I was curious what you meant (253, not 255?), so went back to re-read > > the draft. I don't see the number 253 mentioned, nor 255! > > > > It /does/ mention '225'. This appears to be a typo? > > > > My only suggestion for the mention of the option size is to refer > > specifically to the 'length field value', and not to terms like 'URI > > length' or 'option length', which can be misinterpreted from different > > starting positions. > > > > Otherwise I like this approach of referring to the extension of option > > space as a DHCPv4 protocol feature, and not trying to reinvent its > > specification. > > > > -- > > David W. Hankins "If you don't do it right the first time, > > Software Engineer you'll just have to do it again." > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 28 19:05:33 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0B43A691E; Wed, 28 Jan 2009 19:05:33 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC473A691E for ; Wed, 28 Jan 2009 19:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ2YkgcqjUuq for ; Wed, 28 Jan 2009 19:05:32 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C88953A6872 for ; Wed, 28 Jan 2009 19:05:31 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_01_28_21_24_14 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 28 Jan 2009 21:24:14 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 21:05:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jan 2009 21:05:10 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 Thread-Index: AcmAusBcNbI5l/rVRZiU7XFlhWMVKAADb9JAAD10pZA= References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com> <3B47C198-A077-4864-858D-AF0061FBC5B4@cisco.com> <20090127193947.GC3215@isc.org> From: "Thomson, Martin" To: "Ralph Droms" , "David W. Hankins" X-OriginalArrivalTime: 29 Jan 2009 03:05:12.0893 (UTC) FILETIME=[670526D0:01C981BE] Cc: DHC WG , "Winterbottom, James" , Richard Barnes Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org My earlier mail was bounced (forgot to subscribe). Apologies to the moderators if this is a double-up. > -----Original Message----- > From: Thomson, Martin > Sent: Wednesday, 28 January 2009 9:06 AM > To: 'Ralph Droms'; David W. Hankins > Cc: DHC WG; Richard Barnes; Winterbottom, James > Subject: RE: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery- > 05 > > Hi Ralph, David, > > Thanks both for your feedback. > > Obviously, I missed a critical piece of text on cardinality. The > intent is to convey one URI with one or more fingerprints. The URI is > the point of the exercise, and the fingerprints describe a property of > that URI. A fingerprint without a URI would be pointless, so I wanted > a format that would inherently enforce the restriction. What Ralph > proposes is almost identical to what is in the current draft with the > limitation of one (or no) fingerprints. It would also be possible to > overload the meaning of hash-type-len so that a zero length means that > there are no more fingerprints, which would allow for multiple > fingerprints. > > Allowing for multiple fingerprints ensures that new hash functions can > be invented and actually used without breaking backward compatibility. > That's the idea at least--I'm sure that our security expert friends > would be happy to tell me otherwise if this were a bad or unworkable > idea. > > For David's benefit, concatenation would only be useful in providing > for a longer URI. I'll take the suggestion on restricting the total > option length to 253 and I'll be clearer on the lack of the same > restriction in v6. As an aside, 225 happens to be the length to the > URI after a SHA-1 fingerprint is included...I think :) 253 - f- > code(1)x2 - hashlen(1) - 'sha-1'(5) -fprint-len(1) - fprint(20) = > 224... oh well. > > Cheers, > Martin > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Wednesday, 28 January 2009 7:06 AM > > To: David W. Hankins > > Cc: Ralph Droms; DHC WG; Richard Barnes; Winterbottom, James; > Thomson, > > Martin > > Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis- > discovery- > > 05 > > > > David - if, indeed, the idea is for one URI, with an optional > > fingerprint, would the following format be sensible and simpler to > > parse? > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LIS_URI | Length | Hash-Type-Len | Hash-Type ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hash-Type (cont.) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fprint-Len | Fingerprint-Value ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | URI ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | URI (cont.) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > where Hash-Type-Len and Fprint-Len are both either zero (no > > fingerprint) or greater than 0 (fingerprint included). > > > > - Ralph > > > > On Jan 27, 2009, at 2:39 PM 1/27/09, David W. Hankins wrote: > > > > > On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote: > > >> Can there be more than one fingerprint and more than one URI > > >> carried in the > > >> LIS-URI option? I don't think the draft explicitly restricts the > > >> option. > > >> Because the URI does not include a length field, it would seem to > > >> limit the > > >> option to one URI, and the fingerprint MUST come before the URI. > I > > >> think > > >> the text should be explicit on this point. > > >> > > >> If I understand this restriction correctly, it may be possible to > > >> simplify > > >> the option syntax by assuming the order and number of fields in > the > > >> option. > > >> I'll defer to dhc WG members for opinions on whether there might > be > > a > > >> modification to the syntax that would be more in line with > existing > > >> options > > >> and implementations. > > > > > > I presumed the intent was to provide only one URI. > > > > > > I think that if you squint and turn your head sideways, the 'f- > code, > > > f-length' looks like a suboption (except that the URI's f-code > > implies > > > no length octet, evidently a format size optimization). > > > > > > I want to ask if the idea is to intentionally make a distinction > > > between 'f-code's and suboptions, such as in order to support > > multiple > > > instances of one f-code (and not provoke option concatenation as > > would > > > happen with multiple sub-option codes of the same value). > > > > > > If they can be suboptions, then why not multiple regular options? > > > I think the answer is that the certificate is useless without the > > URI, > > > and vice versa, so if a DHCP server omitted one due to running out > of > > > space it is better to omit both. Containering them together solves > > > this neatly. > > > > > >> The DHCPv6 option doesn't have the 253 byte length restriction. > It > > >> would > > >> be good to mention that difference between the two option > versions. > > > > > > I was curious what you meant (253, not 255?), so went back to re- > read > > > the draft. I don't see the number 253 mentioned, nor 255! > > > > > > It /does/ mention '225'. This appears to be a typo? > > > > > > My only suggestion for the mention of the option size is to refer > > > specifically to the 'length field value', and not to terms like > 'URI > > > length' or 'option length', which can be misinterpreted from > > different > > > starting positions. > > > > > > Otherwise I like this approach of referring to the extension of > > option > > > space as a DHCPv4 protocol feature, and not trying to reinvent its > > > specification. > > > > > > -- > > > David W. Hankins "If you don't do it right the first time, > > > Software Engineer you'll just have to do it again." > > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/dhcwg > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 28 19:21:30 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2BA83A68C8; Wed, 28 Jan 2009 19:21:30 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B7C3A68C8 for ; Wed, 28 Jan 2009 19:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER2fY3te3BYw for ; Wed, 28 Jan 2009 19:21:28 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E51683A687F for ; Wed, 28 Jan 2009 19:21:27 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_01_28_21_40_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 28 Jan 2009 21:40:11 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 21:21:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jan 2009 21:21:07 -0600 Message-ID: In-Reply-To: <8E296595B6471A4689555D5D725EBB210ADE76BC@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 Thread-Index: AcmBJrXjzAZo4QUaTFSUiwnyQQkTsgAlpnbgAAA7BvA= References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com><20090127193947.GC3215@isc.org><200901280952.19470.budm@weird-solutions.com> <8E296595B6471A4689555D5D725EBB210ADE76BC@xmb-rtp-20a.amer.cisco.com> From: "Thomson, Martin" To: "Bernie Volz (volz)" , "Bud Millwood" , X-OriginalArrivalTime: 29 Jan 2009 03:21:09.0996 (UTC) FILETIME=[A17F7AC0:01C981C0] Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The intent is to have one (only) URI, and 0..n fingerprints. I didn't choose suboptions originally because I didn't want to have to deal with the case that the client receives multiple URIs. I really don't want to deal with the problem of working out which fingerprint goes with which URI. If there is a feeling that this can be addressed by the judicious application of the "MUST"-hammer, then I'm more than happy to go with suboptions. Cheers, Martin > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bernie Volz (volz) > Sent: Thursday, 29 January 2009 2:02 PM > To: Bud Millwood; dhcwg@ietf.org > Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery- > 05 > > I agree with Bud and Damien (and David) ... Defining suboptions would > be > far better way to go. > > Suboption 1 - URI > Suboption 2 - Fingerprint > > (You could start with suboption 0, but as most sub-option users avoid > suboption 0, I would not recommend it.) > > Now, if the intent is to allow multiple URI instances ... That should > be > OK as I don't recall that option concatentation extends to suboptions. > Therefore, two instances of the same suboption are technically > possible. > Though hopefully that is not the case as it complicates servers (and > clients) and is likely not supported by most servers today? > > The same should be done for DHCPv6 (though of course the suboptions are > 16-bit sub-option code and length fields). > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bud Millwood > Sent: Wednesday, January 28, 2009 3:52 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] dhc WG review of > draft-ietf-geopriv-lis-discovery-05 > > On Tuesday 27 January 2009, Ralph Droms wrote: > > David - if, indeed, the idea is for one URI, with an optional > > fingerprint, would the following format be sensible and simpler to > > parse? > > This option would be much better served as a subencoded option IMO. > It's > going > through terrible contortions to encode both fixed-field settings and > variable > length settings. > > I think a better approach would be to encode everything as suboptions, > and > then to simply dictate which options should be present under the > different > circumstances. > > - Bud > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | LIS_URI | Length | Hash-Type-Len | Hash-Type ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Hash-Type (cont.) ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Fprint-Len | Fingerprint-Value ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | URI ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | URI (cont.) ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > where Hash-Type-Len and Fprint-Len are both either zero (no > > fingerprint) or greater than 0 (fingerprint included). > > > > - Ralph > > > > On Jan 27, 2009, at 2:39 PM 1/27/09, David W. Hankins wrote: > > > On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote: > > >> Can there be more than one fingerprint and more than one URI > > >> carried in the > > >> LIS-URI option? I don't think the draft explicitly restricts the > > >> option. > > >> Because the URI does not include a length field, it would seem to > > >> limit the > > >> option to one URI, and the fingerprint MUST come before the URI. > I > > >> think > > >> the text should be explicit on this point. > > >> > > >> If I understand this restriction correctly, it may be possible to > > >> simplify > > >> the option syntax by assuming the order and number of fields in > the > > >> option. > > >> I'll defer to dhc WG members for opinions on whether there might > be > a > > >> modification to the syntax that would be more in line with > existing > > >> options > > >> and implementations. > > > > > > I presumed the intent was to provide only one URI. > > > > > > I think that if you squint and turn your head sideways, the 'f- > code, > > > f-length' looks like a suboption (except that the URI's f-code > implies > > > no length octet, evidently a format size optimization). > > > > > > I want to ask if the idea is to intentionally make a distinction > > > between 'f-code's and suboptions, such as in order to support > multiple > > > instances of one f-code (and not provoke option concatenation as > would > > > happen with multiple sub-option codes of the same value). > > > > > > If they can be suboptions, then why not multiple regular options? > > > I think the answer is that the certificate is useless without the > URI, > > > and vice versa, so if a DHCP server omitted one due to running out > of > > > space it is better to omit both. Containering them together solves > > > this neatly. > > > > > >> The DHCPv6 option doesn't have the 253 byte length restriction. > It > > >> would > > >> be good to mention that difference between the two option > versions. > > > > > > I was curious what you meant (253, not 255?), so went back to > re-read > > > the draft. I don't see the number 253 mentioned, nor 255! > > > > > > It /does/ mention '225'. This appears to be a typo? > > > > > > My only suggestion for the mention of the option size is to refer > > > specifically to the 'length field value', and not to terms like > 'URI > > > length' or 'option length', which can be misinterpreted from > different > > > starting positions. > > > > > > Otherwise I like this approach of referring to the extension of > option > > > space as a DHCPv4 protocol feature, and not trying to reinvent its > > > specification. > > > > > > -- > > > David W. Hankins "If you don't do it right the first time, > > > Software Engineer you'll just have to do it again." > > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > -- > Bud Millwood > Weird Solutions, Inc. > http://www.weird-solutions.com > tel: +46 8 758 3700 > fax: +46 8 758 3687 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jan 28 19:41:09 2009 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA7428C194; Wed, 28 Jan 2009 19:41:08 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F54A28C194 for ; Wed, 28 Jan 2009 19:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICiPzcH40MVY for ; Wed, 28 Jan 2009 19:41:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C8DB93A6872 for ; Wed, 28 Jan 2009 19:41:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,341,1231113600"; d="scan'208";a="35218980" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2009 03:40:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0T3elt5019548; Wed, 28 Jan 2009 22:40:47 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0T3el3e024864; Thu, 29 Jan 2009 03:40:47 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 22:40:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jan 2009 22:40:36 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210ADE76CB@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 Thread-Index: AcmBJrXjzAZo4QUaTFSUiwnyQQkTsgAlpnbgAAA7BvAAAPk84A== References: <0B27CAD9-2FEA-4688-B096-8667F35A460B@cisco.com><20090127193947.GC3215@isc.org><200901280952.19470.budm@weird-solutions.com><8E296595B6471A4689555D5D725EBB210ADE76BC@xmb-rtp-20a.amer.cisco.com> From: "Bernie Volz (volz)" To: "Thomson, Martin" , "Bud Millwood" , X-OriginalArrivalTime: 29 Jan 2009 03:40:47.0050 (UTC) FILETIME=[5F13AAA0:01C981C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8707; t=1233200447; x=1234064447; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20review=20of=20draf t-ietf-geopriv-lis-discovery-05 |Sender:=20 |To:=20=22Thomson,=20Martin=22=20,=0A=20=20=20=20=20=20=20=20=22Bud=20Millwood=22=20,=20; bh=afQsG4+XGxW6ScxcgaQLkFigDIjc0VfFG3UASd2Nui8=; b=su/RQ8Rb9wMm1fiqqIu27O3OvRNMkYn8j0T2E/w2u/69pUdMT4a2do27kT TyEKpxpSw7RutZ84Aj6qgTf1Z2+v3lhpGrx5jbH6Y/vOwcVwj7sb9tlHwA1U GtjJ98yr9I; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org So, perhaps best to have two options ... One for the URI. One for the fingerprints. The fingerprints option would be formatted something like: