From bharat_joshi@infosys.com Thu Feb 2 00:57:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9C221F87A3 for ; Thu, 2 Feb 2012 00:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccwSqsgzTSWF for ; Thu, 2 Feb 2012 00:57:44 -0800 (PST) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCD221F87A0 for ; Thu, 2 Feb 2012 00:57:43 -0800 (PST) X-TM-IMSS-Message-ID: <1a584f360004a94e@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 1a584f360004a94e ; Thu, 2 Feb 2012 14:27:51 +0530 Received: from blrkechub12.ad.infosys.com (10.66.236.47) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 2 Feb 2012 14:27:41 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.25]) by blrkechub12.ad.infosys.com ([10.66.236.47]) with mapi; Thu, 2 Feb 2012 14:27:40 +0530 From: Bharat Joshi To: Shankari Vaidyalingam , "dhcwg@ietf.org" Date: Thu, 2 Feb 2012 14:24:37 +0530 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-relay-id-suboption-09.txt Thread-Index: Aczgogji3IFa1+nqS1KRRCijC1JHWAA5kGRW Message-ID: <31D55C4D55BEED48A4459EB64567589A118C41DA25@BLRKECMBX02.ad.infosys.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-relay-id-suboption-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 08:57:45 -0000 Hi Shankari, Thanks a lot for reviewing the draft and your comments. Please see= my response in line. Regards, Bharat > Please find below some queries on the relay-id draft: > (1) When the relay-id is not configured by the user then can you please= let me know what would be the behavior in the event of relay-agent crash= ? If the relay agent is not configured by the administrator then relay agen= t will not be able to use bulk-lease query in the case of crash. It may s= till use lease query by remote-id to retrieve address bindings. > (2) Can you let me know how the relay-id is maintained unique across th= e relay agents connected to a particular server. A network administrator will have to ensure the uniqueness of the relay-i= d across the network. > (3) When the relay-agent recovers from crash and sends a "bulk-lease-qu= ery" with the relay-id to restore the previous configuration/mappings, wh= at would be the approx amount of recovery time allowed for full functiona= lity of relay agent to resume. > It might depend on the number of active leases that were allocated throug= h this relay agent when it went down. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease 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 h= as 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 reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From roberta.maglione@telecomitalia.it Fri Feb 3 07:27:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1113221F8552 for ; Fri, 3 Feb 2012 07:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.176 X-Spam-Level: ** X-Spam-Status: No, score=2.176 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYaajEjPk-ep for ; Fri, 3 Feb 2012 07:27:17 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 226EC21F8540 for ; Fri, 3 Feb 2012 07:27:13 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 3 Feb 2012 16:26:58 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 3 Feb 2012 16:26:58 +0100 From: Maglione Roberta To: 'Matthew Ryan' , dhc WG Date: Fri, 3 Feb 2012 16:26:57 +0100 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt Thread-Index: AczKand5otdX9vhLSdewMSaKn95GywYHLhCw Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> References: <20111221164220.13693.80809.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'david.miles@alcatel-lucent.com'" , "Wojciech Dec \(wdec\)" , "'James.Bristow@swisscom.com'" , 'Ted Lemon' , Ullio Mario Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 15:27:18 -0000 Hello Matt, Sorry for my late reply. Please see answers inline [RM] Thanks, Best regards, Roberta -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of M= atthew Ryan Sent: marted=EC 3 gennaio 2012 23.53 To: dhc WG Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt First, a couple of typos: Section 3.1.3, 4th paragraph: easily be predicted. The nonce is imbedded as a 128-bit value of the 'imbedded' should be 'embedded', or 'included' [RM] ok I'll fix it thanks. Section 3.1.4, 2nd paragraph: A DHCP server has indicates its support through the inclusion of the remove the 'has'. [RM] ok I'll fix it thanks. I think some clarifications are needed on renew behavior, and server support advertisement. Section 3.1.4 states: The client will receive a Forcerenew Nonce from the server in the initial DHCP Ack message from the server. which could be construed to imply that the nonce is only chosen during the initial 4-way handshake. However, the protocol interaction diagram in section 3.1.1 seems to indicate that, during a renew, the server may/must (unclear) create a new nonce. [RM] The idea is that the nonce is selected and sent by the server in the i= nitial DHCP exchange, then later on when the DHCP server needs to send a Fo= rcerenew message it includes the nonce previously created in the message se= nt to the client. In this way the client can verify that the Forcerenew mes= sage comes from a trusted DHCP server. Please let me know if you think this= behavior should better explained in the document In addition, sections 3.1.3 (server considerations) and 3.1.4 (client considerations) seem to state different things as to how a server advertises its support for forcerenew-nonce. Both sections mention that the server indicates support by including the FORCERENEW_NONCE_CAPABLE option in OFFERs, but 3.1.4 also mentions that the server MUST include a forcerenew-nonce authentication option with type set to zero. It seems to me that if a server MUST emit both the FORCERENEW_NONCE_CAPABLE option and the authentication option, it should explicitly state so in the server considerations section (3.1.3). Also, since 3.1.3 states that the server chooses a nonce only in response to a REQUEST, what should the value in the OFFER be? However, I'm not sure I see the need for a server to return BOTH the FORCERENEW_NONCE_CAPABLE option, and the authentication type 0 in the OFFER, in order to advertise that it is capable of forcerenew-nonce. [RM] The purpose of FORCERENEW_NONCE_CAPABLE option is to allow backward co= mpatibility with legacy DHCP client and server. The FORCERENEW_NONCE_CAPABL= E is sent by the client to tell the server that is able support this functi= onality and then the server replies with both the FORCERENEW_NONCE_CAPABLE = and the nonce. Do you think the Server should just send the nonce in this c= ase? I'm open to that behavior too, I would like to ask the other co-author= s if they have an opinion on this point. Roberta - Matt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Ted.Lemon@nominum.com Fri Feb 3 08:27:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CFB21F848A for ; Fri, 3 Feb 2012 08:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOEvSKaAGOV2 for ; Fri, 3 Feb 2012 08:27:34 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 496BE21F84B4 for ; Fri, 3 Feb 2012 08:27:34 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTywK9TT3YGVpBg7SZOdUuMp7JCVlLt1p@postini.com; Fri, 03 Feb 2012 08:27:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 36EB81B8267 for ; Fri, 3 Feb 2012 08:27:33 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2374F190052; Fri, 3 Feb 2012 08:27:33 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Fri, 3 Feb 2012 08:27:33 -0800 From: Ted Lemon To: Maglione Roberta Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt Thread-Index: AQHMv/+hIhpGJQI3m0eDot7buwZ7q5X72uwAgDA7uICAABDsgA== Date: Fri, 3 Feb 2012 16:27:33 +0000 Message-ID: References: <20111221164220.13693.80809.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <551646A41D1008409A488235FA03DDFF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "david.miles@alcatel-lucent.com" , "James.Bristow@swisscom.com" , Ullio Mario , dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 16:27:35 -0000 On Feb 3, 2012, at 10:26 AM, Maglione Roberta wrote: > [RM] The purpose of FORCERENEW_NONCE_CAPABLE option is to allow backward = compatibility with legacy DHCP client and server. The FORCERENEW_NONCE_CAPA= BLE is sent by the client to tell the server that is able support this func= tionality and then the server replies with both the FORCERENEW_NONCE_CAPABL= E and the nonce. Do you think the Server should just send the nonce in this= case? I'm open to that behavior too, I would like to ask the other co-auth= ors if they have an opinion on this point. There is some cost associated with generating a secure nonce, so requiring = the server to send one to all clients is probably not the right tradeoff. = It's unfortunate that the decision whether or not to send a nonce will req= uire an extra decision path, but I think it's a better tradeoff. From Matt.Ryan@nominum.com Fri Feb 3 14:19:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7887D1F0C3E for ; Fri, 3 Feb 2012 14:19:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSj2p8J62gsJ for ; Fri, 3 Feb 2012 14:19:33 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 60A1821F8530 for ; Fri, 3 Feb 2012 14:19:24 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTyxdahBeywjo09tikianoC0JgFCPGSyb@postini.com; Fri, 03 Feb 2012 14:19:33 PST Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 94E991B8563; Fri, 3 Feb 2012 14:19:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Ryan In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> Date: Fri, 3 Feb 2012 14:19:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <82B4F550-9202-4EA2-87ED-93BF78C5D0C5@nominum.com> References: <20111221164220.13693.80809.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> To: Maglione Roberta X-Mailer: Apple Mail (2.1084) Cc: "'david.miles@alcatel-lucent.com'" , "'James.Bristow@swisscom.com'" , Ullio Mario , 'Ted Lemon' , dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 22:19:34 -0000 On Feb 3, 2012, at 07:26 , Maglione Roberta wrote: >=20 > Section 3.1.4 states: > The client will receive a Forcerenew Nonce from the server in the > initial DHCP Ack message from the server. > which could be construed to imply that the nonce is only chosen > during the initial 4-way handshake. >=20 > However, the protocol interaction diagram in section 3.1.1 > seems to indicate that, during a renew, the server may/must > (unclear) create a new nonce. >=20 > [RM] The idea is that the nonce is selected and sent by the server in = the initial DHCP exchange, then later on when the DHCP server needs to = send a Forcerenew message it includes the nonce previously created in = the message sent to the client. In this way the client can verify that = the Forcerenew message comes from a trusted DHCP server. Please let me = know if you think this behavior should better explained in the document I believe it's clear that a nonce should be returned in each ACK message. However, I think the document needs to be clarified as to which REQUEST messages (init-reboot, select, renew, rebind) or conditions should cause a server to generate a /new/ nonce. Specifically, when the server MUST generate a nonce, and when it MAY generate (or change) the nonce. Does the server ONLY generate a nonce the first time it sees the client? Is the server ONLY allowed to generate a nonce (even if it has no previous recorded) in response to a select, or can it do so for rebind and init-reboot as well? Can the server (perhaps on a timer or by admin instruction) choose to generate a new nonce for a client in response to a renew? In addition, it should be clarified when a client should update its record of the nonce. The draft currently states this is done in response to the "initial DHCP Ack message". Depending on the answers to the server behavior question above, this may not be sufficient. If the server is allowed to generate a new nonce on rebind (which may need to happen in environments that have multiple DHCP servers that don't do failover), the client should probably update itself then as well. Also, what should happen in the case where the client indicates in a renew that it is capable, and the server is capable, but the server has no recollection of a nonce for the client? This condition can happen if the server support is enabled and the client already possesses an active lease from the server. I would probably recommend at the following: 1) The client MUST record the nonce from any valid ACK it receives, if the ACK contains one. 2) If a capable server receives a DISCOVER or REQUEST (any type) that indicates the client is capable, and the server has no previous nonce recorded, it MUST generate a nonce and include it in the ACK. 3) The server SHOULD NOT include the nonce in an ACK when responding to a renew unless a nonce was generated. This minimizes the number of times the nonce is sent over the wire. That leaves open the question of whether a server MAY change an existing nonce, but that becomes a non-issue due to (1). > [RM] The purpose of FORCERENEW_NONCE_CAPABLE option is to allow = backward compatibility with legacy DHCP client and server. The = FORCERENEW_NONCE_CAPABLE is sent by the client to tell the server that = is able support this functionality and then the server replies with both = the FORCERENEW_NONCE_CAPABLE and the nonce. Do you think the Server = should just send the nonce in this case? I'm open to that behavior too, = I would like to ask the other co-authors if they have an opinion on this = point. My reading of the draft indicated that the server would send a nonce of type 0 in an OFFER (type 0 is not covered in section 3.1.2) - but there was no indication of what the value should be. I think, that, in the OFFER message, it is sufficient for the server to simply send the FORCERENEW_NONCE_CAPABLE, and omit the authentication option. So, I would change section 3.1.4 from: The client MUST indicate Forcerenew nonce Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all DHCP Discover and Request messages. DHCP servers that support Forcerenew nonce Protocol authentication MUST include the DHCP Forcerenew Nonce protocol authentication option in DHCP Offers with type set to zero(0), allowing the client to use this capability in selecting DHCP servers should multiple Offers arrive. A DHCP server has indicates its support through the inclusion of the FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client MUST validate the DHCP Ack message contains a Forcerenew Nonce in a DHCP authentication option. If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. to (changed lines marked, no rewrapping done for clarity): The client MUST indicate Forcerenew nonce Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all DHCP Discover and Request messages. DHCP servers that support * Forcerenew nonce Protocol authentication MUST include the * FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all * DHCP Offers, allowing the client to use this capability in selecting DHCP servers should multiple Offers arrive. * The client MUST validate the DHCP Ack message contains a Forcerenew Nonce in a DHCP authentication option. If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. - Matt= From roberta.maglione@telecomitalia.it Tue Feb 7 00:29:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0290921F86C4 for ; Tue, 7 Feb 2012 00:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[AWL=1.528, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXm8DWUeHHAc for ; Tue, 7 Feb 2012 00:29:33 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD2C21F858F for ; Tue, 7 Feb 2012 00:29:31 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 7 Feb 2012 09:29:26 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 7 Feb 2012 09:29:27 +0100 From: Maglione Roberta To: 'Matthew Ryan' Date: Tue, 7 Feb 2012 09:29:26 +0100 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt Thread-Index: AcziwejofOmKtphZTxe8UzzTmzMXPwCsLBcg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F87@GRFMBX704BA020.griffon.local> References: <20111221164220.13693.80809.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> <82B4F550-9202-4EA2-87ED-93BF78C5D0C5@nominum.com> In-Reply-To: <82B4F550-9202-4EA2-87ED-93BF78C5D0C5@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'david.miles@alcatel-lucent.com'" , "'James.Bristow@swisscom.com'" , Ullio Mario , 'Ted Lemon' , dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 08:29:34 -0000 Hi Matt, Thanks for providing valuable inputs in order to clarify the document. I'm going to discuss your proposal with the other co-authors and I get back= to you Best regards, Roberta -----Original Message----- From: Matthew Ryan [mailto:Matt.Ryan@nominum.com] Sent: venerd=EC 3 febbraio 2012 23.19 To: Maglione Roberta Cc: dhc WG; 'david.miles@alcatel-lucent.com'; Wojciech Dec (wdec); 'James.B= ristow@swisscom.com'; Ullio Mario; 'Ted Lemon' Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt On Feb 3, 2012, at 07:26 , Maglione Roberta wrote: > > Section 3.1.4 states: > The client will receive a Forcerenew Nonce from the server in the > initial DHCP Ack message from the server. > which could be construed to imply that the nonce is only chosen > during the initial 4-way handshake. > > However, the protocol interaction diagram in section 3.1.1 > seems to indicate that, during a renew, the server may/must > (unclear) create a new nonce. > > [RM] The idea is that the nonce is selected and sent by the server in the= initial DHCP exchange, then later on when the DHCP server needs to send a = Forcerenew message it includes the nonce previously created in the message = sent to the client. In this way the client can verify that the Forcerenew m= essage comes from a trusted DHCP server. Please let me know if you think th= is behavior should better explained in the document I believe it's clear that a nonce should be returned in each ACK message. However, I think the document needs to be clarified as to which REQUEST messages (init-reboot, select, renew, rebind) or conditions should cause a server to generate a /new/ nonce. Specifically, when the server MUST generate a nonce, and when it MAY generate (or change) the nonce. Does the server ONLY generate a nonce the first time it sees the client? Is the server ONLY allowed to generate a nonce (even if it has no previous recorded) in response to a select, or can it do so for rebind and init-reboot as well? Can the server (perhaps on a timer or by admin instruction) choose to generate a new nonce for a client in response to a renew? In addition, it should be clarified when a client should update its record of the nonce. The draft currently states this is done in response to the "initial DHCP Ack message". Depending on the answers to the server behavior question above, this may not be sufficient. If the server is allowed to generate a new nonce on rebind (which may need to happen in environments that have multiple DHCP servers that don't do failover), the client should probably update itself then as well. Also, what should happen in the case where the client indicates in a renew that it is capable, and the server is capable, but the server has no recollection of a nonce for the client? This condition can happen if the server support is enabled and the client already possesses an active lease from the server. I would probably recommend at the following: 1) The client MUST record the nonce from any valid ACK it receives, if the ACK contains one. 2) If a capable server receives a DISCOVER or REQUEST (any type) that indicates the client is capable, and the server has no previous nonce recorded, it MUST generate a nonce and include it in the ACK. 3) The server SHOULD NOT include the nonce in an ACK when responding to a renew unless a nonce was generated. This minimizes the number of times the nonce is sent over the wire. That leaves open the question of whether a server MAY change an existing nonce, but that becomes a non-issue due to (1). > [RM] The purpose of FORCERENEW_NONCE_CAPABLE option is to allow backward = compatibility with legacy DHCP client and server. The FORCERENEW_NONCE_CAPA= BLE is sent by the client to tell the server that is able support this func= tionality and then the server replies with both the FORCERENEW_NONCE_CAPABL= E and the nonce. Do you think the Server should just send the nonce in this= case? I'm open to that behavior too, I would like to ask the other co-auth= ors if they have an opinion on this point. My reading of the draft indicated that the server would send a nonce of type 0 in an OFFER (type 0 is not covered in section 3.1.2) - but there was no indication of what the value should be. I think, that, in the OFFER message, it is sufficient for the server to simply send the FORCERENEW_NONCE_CAPABLE, and omit the authentication option. So, I would change section 3.1.4 from: The client MUST indicate Forcerenew nonce Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all DHCP Discover and Request messages. DHCP servers that support Forcerenew nonce Protocol authentication MUST include the DHCP Forcerenew Nonce protocol authentication option in DHCP Offers with type set to zero(0), allowing the client to use this capability in selecting DHCP servers should multiple Offers arrive. A DHCP server has indicates its support through the inclusion of the FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client MUST validate the DHCP Ack message contains a Forcerenew Nonce in a DHCP authentication option. If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. to (changed lines marked, no rewrapping done for clarity): The client MUST indicate Forcerenew nonce Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all DHCP Discover and Request messages. DHCP servers that support * Forcerenew nonce Protocol authentication MUST include the * FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all * DHCP Offers, allowing the client to use this capability in selecting DHCP servers should multiple Offers arrive. * The client MUST validate the DHCP Ack message contains a Forcerenew Nonce in a DHCP authentication option. If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. - Matt Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From dankney@network1.net Tue Feb 7 05:56:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7E21F87D2 for ; Tue, 7 Feb 2012 05:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR4iUHQOXRGA for ; Tue, 7 Feb 2012 05:56:50 -0800 (PST) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id AA4B321F877F for ; Tue, 7 Feb 2012 05:56:50 -0800 (PST) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 82F41542464 for ; Tue, 7 Feb 2012 08:56:49 -0500 (EST) Date: Tue, 07 Feb 2012 08:56:49 -0500 (EST) From: perl-list To: dhcwg@ietf.org Message-ID: <616bf181-db31-46e3-8df4-27b119112810@zimbra.network1.net> In-Reply-To: Content-Type: multipart/alternative; boundary="=_4825a4b9-312c-4e98-a4e7-68806e05c385" MIME-Version: 1.0 X-Originating-IP: [74.115.181.97] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:56:52 -0000 --=_4825a4b9-312c-4e98-a4e7-68806e05c385 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Can a community leader comment? Is http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt being considered as requested by Shwetha? ----- Original Message ----- > From: "Shwetha" > To: "Jarrod Johnson" , "perl-list" > > Cc: dhcwg@ietf.org > Sent: Sunday, January 29, 2012 11:13:20 PM > Subject: Re: [dhcwg] DHCPv6 Hardware Option > Re: [dhcwg] DHCPv6 Hardware Option Regarding: > > I do see it as a challenge since the horse is already out of the > > barn. Don't know how you would theoretically deal with that > > > reality other than hoping one day the current implementations > > would just age out. > draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00 allows for the first > hop DHCPv6-Relay agent to insert client hardware address option as > it is able to gather that information from the client frame > received. This flexibility in how this options can be learnt and > inserted not only by the client but also by a Relay agent should > make it easier to adopt. Also this draft does not propose the new > option as mandatory, but in deployments that use client hardware > address as an identifier this can be readily used. > Again, since there seems to be interest and considerable benefit in > adopting the approach detailed in: > http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt > , would request for review and this to be considered as a dhc work > group draft. > Thanks, > Shwetha > On 1/27/12 5:39 PM, "Jarrod Johnson" < > jarrod.b.johnson+dhcwg@gmail.com > wrote: > > I agree that it would be much much more straightforward for a lot > > of > > people if DHCPv6 were extended to allow BOOTP-like behavior. DUID > > and IAID are just not particularly ideal identifiers for some > > applications (they are too open ended and it's difficult to predict > > the behavior of an arbitrary client). IAIDs are not things that > > can, > > for example, be trivially correlated to a mac forwarding database > > entry on a switch. IAIDs are pretty much completely at the whim of > > the client implementation. DUIDs can select a number of valid forms > > and are almost always DUID-LLT, but LL may have nothing to do with > > the link layer address used on the network (it may use another nic > > or one that was replaced) and the timestamp is not predictable. > > Reload of OS or removal of a settings file completely changes a > > clients DUID. > > > I do see it as a challenge since the horse is already out of the > > barn. Don't know how you would theoretically deal with that reality > > other than hoping one day the current implementations would just > > age > > out. > > > FWIW, I proposed DUID-UUID as it fixed my specific problem. Since I > > was specifically concerned with OS deployment case, I had the > > freedom to pre-empt default OS DHCPv6 behavior and force usage of > > the predictable and consistent UUID. I think in many enterprise > > circumstances, this is actually a serviceable workaround to the > > limitation that manages to play within the rules of DHCPv6 > > as-written. I still need to check UEFI implementations for > > conformance to the 2.3.1 UEFI spec in terms of DUID-UUID > > recommendation... > > > On Thu, Jan 26, 2012 at 3:34 PM, perl-list < perl-list@network1.net > > > > > wrote: > > > > Hello, > > > > > > New to the list. Inquiring as to the current status of this > > > document: > > > http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt > > > > > > I am quite interested in seeing the hardware option make a return > > > in > > > DHCPv6. The reasons for this are summed up quite well in this > > > post: > > > https://lists.isc.org/pipermail/dhcp-users/2009-March/008317.html > > > > > > Any information anyone can provide? > > > > > > Thank you! > > > > > > _______________________________________________ > > > > > > 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 > --=_4825a4b9-312c-4e98-a4e7-68806e05c385 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>Can= a community leader comment?  Is http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.tx= t being considered as requested by Shwetha?


=
From: "Shwetha" <shwethab@cisco.com>
To: "= Jarrod Johnson" <jarrod.b.johnson+dhcwg@gmail.com>, "perl-list" <p= erl-list@network1.net>
Cc: dhcwg@ietf.org
Sent: Sund= ay, January 29, 2012 11:13:20 PM
Subject: Re: [dhcwg] DHCPv6 Hard= ware Option

Re: [dhcwg] DHCPv6 Hardware Option Regarding:
> I do see it as a challenge since the horse is = already out of the barn.  Don't know how you would theoretically deal = with that > reality other than hoping one day the current implementation= s would just age out.
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00 allows for the first = hop DHCPv6-Relay agent to insert client hardware address option as it is ab= le to gather that information from the client frame received. This flexibil= ity in how this options can be learnt and inserted not only by the client b= ut also by a Relay agent should make it easier to adopt. Also this draft do= es not propose the new option as mandatory, but in deployments that use cli= ent hardware address as an identifier this can be readily used.

Again, since there seems to be interest  and  considerable benefi= t in adopting the approach detailed in:
http://tools.ietf.org/id/draft-halwasia-dhc-= dhcpv6-hardware-addr-opt-00.txt, would request for review and this to b= e considered as a dhc work group draft.

Thanks,
Shwetha

On 1/27/12 5:39 PM, "Jarrod Johnson" <jarrod.b.johnson+dhcwg@gmail.co= m> wrote:

I agree that it would be much much more str= aightforward for a lot of people if DHCPv6 were extended to allow BOOTP-lik= e behavior.  DUID and IAID are just not particularly ideal identifiers= for some applications (they are too open ended and it's difficult to predi= ct the behavior of an arbitrary client).  IAIDs are not things that ca= n, for example, be trivially correlated to a mac forwarding database entry = on a switch.  IAIDs are pretty much completely at the whim of the clie= nt implementation.  DUIDs can select a number of valid forms and are a= lmost always DUID-LLT, but LL may have nothing to do with the link layer ad= dress used on the network (it may use another nic or one that was replaced)= and the timestamp is not predictable.  Reload of OS or removal of a s= ettings file completely changes a clients DUID.

I do see it as a challenge since the horse is already out of the barn. = ; Don't know how you would theoretically deal with that reality other than = hoping one day the current implementations would just age out.

FWIW, I proposed DUID-UUID as it fixed my specific problem.  Since I w= as specifically concerned with OS deployment case, I had the freedom to pre= -empt default OS DHCPv6 behavior and force usage of the predictable and con= sistent UUID.  I think in many enterprise circumstances, this is actua= lly a serviceable workaround to the limitation that manages to play within = the rules of DHCPv6 as-written.  I still need to check UEFI implementa= tions for conformance to the 2.3.1 UEFI spec in terms of DUID-UUID recommen= dation...



On Thu, Jan 26, 2012 at 3:34 PM, perl-list <perl-list@network1.net> wrote:
Hello,

New to the list.  Inquiring as to the current status of this document:=  http://tools.ietf.org/id/draft-halwasi= a-dhc-dhcpv6-hardware-addr-opt-00.txt

I am quite interested in seeing the hardware option make a return in DHCPv6= .  The reasons for this are summed up quite well in this post: https://lists.isc.org/pipermail/dhcp-users/2009-March/00= 8317.html

Any information anyone can provide?

Thank you!



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--=_4825a4b9-312c-4e98-a4e7-68806e05c385-- From volz@cisco.com Thu Feb 9 11:26:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7395221E8042 for ; Thu, 9 Feb 2012 11:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f+FBjD0McQ4 for ; Thu, 9 Feb 2012 11:25:57 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30321E8051 for ; Thu, 9 Feb 2012 11:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=21174; q=dns/txt; s=iport; t=1328815550; x=1330025150; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ougjmyUue6NttB1JFLrDwdPjDyTdSqCDCm4hHrlZIoI=; b=gYtFN5kSbxtVorFVaq3FC5u56ZlSz2OqCWesxMn0gcvIos6iMdZ7r13x zhvOqXtjCtefy74j4yY7YvJ8IPG4p0m06XwvVWIWVqISDeDu7X8nvbR8u 7IbnytuQ7M0sY/dUNMS4/6As9SeHxvT10f2reCaQUa4o1IA/fdH0CIcUZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAEAcNE+tJXHB/2dsb2JhbABEgk2kTgGIQIEHgXIBAQEEAQEBDwEJEQM+CxACAQgRBAEBCwYXAQYBIAYBHgkIAQEEARIIGodjmjMBnxeINoMiAQQEBQEHCAYOAwUEAQUDOoNZBRsOX4JgYwSISIpAjTeHcg X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208,217";a="57712596" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 09 Feb 2012 19:25:17 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q19JPHlv006325; Thu, 9 Feb 2012 19:25:17 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 13:25:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCE760.8DE786CA" Date: Thu, 9 Feb 2012 13:25:16 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCPv6 Hardware Option Thread-Index: AczfBX/eFzvbVy3jAUaBYARbJ6Gr7gIWPJWQ References: From: "Bernie Volz (volz)" To: "Shwetha Bhandari (shwethab)" , "Jarrod Johnson" , "perl-list" X-OriginalArrivalTime: 09 Feb 2012 19:25:17.0001 (UTC) FILETIME=[8DDF7390:01CCE760] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:26:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCE760.8DE786CA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Here are some comments on the draft itself: =20 I don't understand why the RFC 3315 DUID-LL type format isn't used here. Let's not use DHCPv4-isms. So, this draft should be updated to use the format of the DUID-LL (section 9.4 of RFC 3315). Basically, the hardware type is 16-bits, not 8. And "chtype"?? In DHCPv4, the field is "htype". I'd drop "[c]htype" and "chaddr" (except when mentioning the DHCPv4 equivalents). These are not really used in DHCPv6 (where we use hardware address and link-layer address). =20 A more minor nit, perhaps call the option OPTION_CLIENT_LLA? (Draft might be called Client Link-Layer Address Option). =20 I'd be much happier if this was ONLY a Relay Agent option. That really as a higher level of 'trust' to the data (as that is the link-layer address being used by the device to communicate with the relay). And, a client might get this wrong if it is multihomed. But, I guess for things like PXE booting, there might be reasons to have the client provide it. In any case, servers should always prefer the Relay information over any client provided information, so I think the following is bad and backwards: =20 If DHCPv6 Server is configured to store or use client hardware address, it MUST first look for the client hardware address option in the client DHCP message. In case it is not found, Server SHOULD look for client hardware option in the RELAY-FORW message of the DHCPv6 Relay agent closest to the client. =20 In section 4, I would NOT list the messages. There is little 'harm' in a client in providing this even in an Information-Request or some future messages. Best to not list things that are not needed and are not exhaustive. =20 - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Shwetha Bhandari (shwethab) Sent: Sunday, January 29, 2012 11:13 PM To: Jarrod Johnson; perl-list Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option =20 Regarding: > I do see it as a challenge since the horse is already out of the barn. Don't know how you would theoretically deal with that > reality other than hoping one day the current implementations would just age out. draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00 allows for the first hop DHCPv6-Relay agent to insert client hardware address option as it is able to gather that information from the client frame received. This flexibility in how this options can be learnt and inserted not only by the client but also by a Relay agent should make it easier to adopt. Also this draft does not propose the new option as mandatory, but in deployments that use client hardware address as an identifier this can be readily used. Again, since there seems to be interest and considerable benefit in adopting the approach detailed in: http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00. txt, would request for review and this to be considered as a dhc work group draft. Thanks, Shwetha On 1/27/12 5:39 PM, "Jarrod Johnson" wrote: I agree that it would be much much more straightforward for a lot of people if DHCPv6 were extended to allow BOOTP-like behavior. DUID and IAID are just not particularly ideal identifiers for some applications (they are too open ended and it's difficult to predict the behavior of an arbitrary client). IAIDs are not things that can, for example, be trivially correlated to a mac forwarding database entry on a switch. IAIDs are pretty much completely at the whim of the client implementation. DUIDs can select a number of valid forms and are almost always DUID-LLT, but LL may have nothing to do with the link layer address used on the network (it may use another nic or one that was replaced) and the timestamp is not predictable. Reload of OS or removal of a settings file completely changes a clients DUID. I do see it as a challenge since the horse is already out of the barn. Don't know how you would theoretically deal with that reality other than hoping one day the current implementations would just age out. FWIW, I proposed DUID-UUID as it fixed my specific problem. Since I was specifically concerned with OS deployment case, I had the freedom to pre-empt default OS DHCPv6 behavior and force usage of the predictable and consistent UUID. I think in many enterprise circumstances, this is actually a serviceable workaround to the limitation that manages to play within the rules of DHCPv6 as-written. I still need to check UEFI implementations for conformance to the 2.3.1 UEFI spec in terms of DUID-UUID recommendation... On Thu, Jan 26, 2012 at 3:34 PM, perl-list wrote: Hello, New to the list. Inquiring as to the current status of this document: http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00. txt I am quite interested in seeing the hardware option make a return in DHCPv6. The reasons for this are summed up quite well in this post: https://lists.isc.org/pipermail/dhcp-users/2009-March/008317.html Any information anyone can provide? Thank you! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =20 ________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01CCE760.8DE786CA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [dhcwg] DHCPv6 Hardware = Option

Here are some comments on the draft itself:

 

I don’t understand why the RFC 3315 DUID-LL type format = isn’t used here. Let’s not use DHCPv4-isms. So, this draft = should be updated to use the format of the DUID-LL (section 9.4 of RFC = 3315). Basically, the hardware type is 16-bits, not 8. And = “chtype”?? In DHCPv4, the field is “htype”. = I’d drop “[c]htype” and “chaddr” (except = when mentioning the DHCPv4 equivalents). These are not really used in = DHCPv6 (where we use hardware address and link-layer = address).

 

A more minor nit, perhaps call the option OPTION_CLIENT_LLA? (Draft = might be called Client Link-Layer Address = Option).

 

I’d be much happier if this was ONLY a Relay Agent option. That = really as a higher level of ‘trust’ to the data (as that is = the link-layer address being used by the device to communicate with the = relay). And, a client might get this wrong if it is multihomed. But, I = guess for things like PXE booting, there might be reasons to have the = client provide it. In any case, servers should always prefer the Relay = information over any client provided information, so I think the = following is bad and backwards:

 

   If DHCPv6 Server is configured to store = or use client hardware

   address, it MUST first look for the = client hardware address option in

   the client DHCP message.  In case it = is not found, Server SHOULD look

   for client hardware option in the = RELAY-FORW message of the DHCPv6

   Relay agent closest to the = client.

 

In section 4, I would NOT list the messages. There is little = ‘harm’ in a client in providing this even in an = Information-Request or some future messages. Best to not list things = that are not needed and are not exhaustive.

 

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Shwetha Bhandari (shwethab)
Sent: Sunday, January 29, 2012 = 11:13 PM
To: Jarrod Johnson; perl-list
Cc: = dhcwg@ietf.org
Subject: Re: [dhcwg] DHCPv6 Hardware = Option

 

Regarding:<= br>> I do see it as a challenge since the = horse is already out of the barn.  Don't know how you would = theoretically deal with that > reality other than hoping one day the = current implementations would just age = out.
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00 allows for = the first hop DHCPv6-Relay agent to insert client hardware address = option as it is able to gather that information from the client frame = received. This flexibility in how this options can be learnt and = inserted not only by the client but also by a Relay agent should make it = easier to adopt. Also this draft does not propose the new option as = mandatory, but in deployments that use client hardware address as an = identifier this can be readily used.

Again, since there seems to = be interest  and  considerable benefit in adopting the = approach detailed in:
http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-a= ddr-opt-00.txt, would request for review and this to be considered = as a dhc work group draft.

Thanks,
Shwetha

On 1/27/12 = 5:39 PM, "Jarrod Johnson" <jarrod.b.johnson+dhcwg@gmail.co= m> wrote:

I agree = that it would be much much more straightforward for a lot of people if = DHCPv6 were extended to allow BOOTP-like behavior.  DUID and IAID = are just not particularly ideal identifiers for some applications (they = are too open ended and it's difficult to predict the behavior of an = arbitrary client).  IAIDs are not things that can, for example, be = trivially correlated to a mac forwarding database entry on a = switch.  IAIDs are pretty much completely at the whim of the client = implementation.  DUIDs can select a number of valid forms and are = almost always DUID-LLT, but LL may have nothing to do with the link = layer address used on the network (it may use another nic or one that = was replaced) and the timestamp is not predictable.  Reload of OS = or removal of a settings file completely changes a clients = DUID.

I do see it as a challenge since the horse is already out = of the barn.  Don't know how you would theoretically deal with that = reality other than hoping one day the current implementations would just = age out.

FWIW, I proposed DUID-UUID as it fixed my specific = problem.  Since I was specifically concerned with OS deployment = case, I had the freedom to pre-empt default OS DHCPv6 behavior and force = usage of the predictable and consistent UUID.  I think in many = enterprise circumstances, this is actually a serviceable workaround to = the limitation that manages to play within the rules of DHCPv6 = as-written.  I still need to check UEFI implementations for = conformance to the 2.3.1 UEFI spec in terms of DUID-UUID = recommendation...



On Thu, Jan 26, 2012 at 3:34 PM, = perl-list <perl-list@network1.net> = wrote:

Hello,

New to the list.  Inquiring as to the = current status of this document: http://tools.ietf.org/id/draft-halwasia-dhc-dhcpv6-hardware-a= ddr-opt-00.txt

I am quite interested in seeing the hardware = option make a return in DHCPv6.  The reasons for this are summed up = quite well in this post: https://lists.isc.org/pipermail/dhcp-users/2009-March/008317.html
Any information anyone can provide?

Thank = you!



_______= ________________________________________
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

------_=_NextPart_001_01CCE760.8DE786CA-- From sthaug@nethelp.no Thu Feb 9 11:52:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C64521F8738 for ; Thu, 9 Feb 2012 11:52:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaAIfzlPiCVA for ; Thu, 9 Feb 2012 11:52:48 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id DD05321F8730 for ; Thu, 9 Feb 2012 11:52:46 -0800 (PST) Received: (qmail 22427 invoked from network); 9 Feb 2012 19:52:40 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Feb 2012 19:52:40 -0000 Date: Thu, 09 Feb 2012 20:52:40 +0100 (CET) Message-Id: <20120209.205240.78726629.sthaug@nethelp.no> To: volz@cisco.com From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:52:50 -0000 > I don't understand why the RFC 3315 DUID-LL type format isn't used here. Maybe because 3315 contains very explicit language prohibiting servers from peeking inside the DUID in any way? For the Client Hardware Address Option we *want* the server to be able to look at the address, obviously. > I'd be much happier if this was ONLY a Relay Agent option. That really > as a higher level of 'trust' to the data (as that is the link-layer > address being used by the device to communicate with the relay). Agree that the relay agent has a higher level of trust. Disagree that the option should *only* be a relay agent option - that requires relay agent implementation, which takes time. A client side implementation, for instance if it came as part of ISC DHCP, might be quicker. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From volz@cisco.com Thu Feb 9 11:55:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC0D21E8051 for ; Thu, 9 Feb 2012 11:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.265 X-Spam-Level: X-Spam-Status: No, score=-9.265 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY4Jh4rbYN4T for ; Thu, 9 Feb 2012 11:55:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EAD8221E804F for ; Thu, 9 Feb 2012 11:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1435; q=dns/txt; s=iport; t=1328817315; x=1330026915; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BgEO0BGZednH1NJDPEot0/8s3tN+9WVK3daZ/rwjcMs=; b=FbPswZP9FAaaUiO/T9aYmS14mgFi0At1FkBMnr68TkHWzLKyZSH8YYB1 0HjTq/5MajV1GFUmtRwuNjdPrqHpA/erFnZfvGPjJowwJp7x6f1tLToAp GXcEOt6VOqwIXWj8QGT/fslDqUP3klN4TeJkSN1br1EMQ1gdH+VoQBSmz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGskNE+tJV2Z/2dsb2JhbABEr1yBB4FyAQEBAwESAR0KLRIFBwQCAQgRBAEBCwYXAQYBICUJCAEBBBMIGodamjYBnxKINoMnCh0OBQUGNy2EMwErgjpjBIhIl3eHcg X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="57725387" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 09 Feb 2012 19:55:14 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q19JtECJ004585; Thu, 9 Feb 2012 19:55:14 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 13:55:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Feb 2012 13:55:11 -0600 Message-ID: In-Reply-To: <20120209.205240.78726629.sthaug@nethelp.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCPv6 Hardware Option Thread-Index: AcznZGM2RK1tb5TfTemmvURx2teuEQAAClSA References: <20120209.205240.78726629.sthaug@nethelp.no> From: "Bernie Volz (volz)" To: X-OriginalArrivalTime: 09 Feb 2012 19:55:14.0374 (UTC) FILETIME=[BD30CE60:01CCE764] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:55:19 -0000 You misunderstood. I was NOT suggesting that anyone 'look' inside the DUID. I was saying we should use DHCPv6 terminology and formats for the data carried in your option. That means use a 16-bit hardware type field and a link-layer address field in the NEW option. -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no]=20 Sent: Thursday, February 09, 2012 2:53 PM To: Bernie Volz (volz) Cc: Shwetha Bhandari (shwethab); jarrod.b.johnson+dhcwg@gmail.com; perl-list@network1.net; dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option > I don't understand why the RFC 3315 DUID-LL type format isn't used here. Maybe because 3315 contains very explicit language prohibiting servers from peeking inside the DUID in any way? For the Client Hardware Address Option we *want* the server to be able to look at the address, obviously. > I'd be much happier if this was ONLY a Relay Agent option. That really > as a higher level of 'trust' to the data (as that is the link-layer=20 > address being used by the device to communicate with the relay). Agree that the relay agent has a higher level of trust. Disagree that the option should *only* be a relay agent option - that requires relay agent implementation, which takes time. A client side implementation, for instance if it came as part of ISC DHCP, might be quicker. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From akostur@incognito.com Thu Feb 9 11:59:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9F21E8058 for ; Thu, 9 Feb 2012 11:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raQ-L6TcC81E for ; Thu, 9 Feb 2012 11:59:13 -0800 (PST) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 2CD1D21E8056 for ; Thu, 9 Feb 2012 11:59:13 -0800 (PST) Received: from mail-lpp01m010-f43.google.com ([209.85.215.43]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKTzQlkKTN42biIUi8WRrI6uXki5osdtX7@postini.com; Thu, 09 Feb 2012 11:59:13 PST Received: by mail-lpp01m010-f43.google.com with SMTP id p5so3298724lag.16 for ; Thu, 09 Feb 2012 11:59:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.30.73 with SMTP id q9mr1151380lbh.30.1328817550971; Thu, 09 Feb 2012 11:59:10 -0800 (PST) Received: by 10.112.56.161 with HTTP; Thu, 9 Feb 2012 11:59:10 -0800 (PST) In-Reply-To: <20120209.205240.78726629.sthaug@nethelp.no> References: <20120209.205240.78726629.sthaug@nethelp.no> Date: Thu, 9 Feb 2012 11:59:10 -0800 Message-ID: From: Andre Kostur To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=bcaec554d98618d3ae04b88d72a1 X-Gm-Message-State: ALoCoQl0K4twhV5ynXPXikEuNFgXXvUwQtY/46DFaF41aOnTk5/6Y1L+5/4JJYDOA0SmQYyTov3p Cc: dhcwg@ietf.org, volz@cisco.com Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:59:14 -0000 --bcaec554d98618d3ae04b88d72a1 Content-Type: text/plain; charset=ISO-8859-1 I think Bernie is suggesting that you take the format of DUID-LL and use it for this option, and not to specifically peer into the actual DUID option to find the MAC address. I disagree with Bernie where I think the client should be able to supply its own MAC address, but I agree with him that if this is also supplied by the Relay Agent, the server should prefer the Relay Agent's version of the MAC address. The client may be operating in an environment where there are no Relay Agents, and the server is hearing the client's multicasts directly. On Thu, Feb 9, 2012 at 11:52, wrote: > > I don't understand why the RFC 3315 DUID-LL type format isn't used here. > > Maybe because 3315 contains very explicit language prohibiting servers > from peeking inside the DUID in any way? For the Client Hardware > Address Option we *want* the server to be able to look at the address, > obviously. > > > I'd be much happier if this was ONLY a Relay Agent option. That really > > as a higher level of 'trust' to the data (as that is the link-layer > > address being used by the device to communicate with the relay). > > Agree that the relay agent has a higher level of trust. Disagree that > the option should *only* be a relay agent option - that requires relay > agent implementation, which takes time. A client side implementation, > for instance if it came as part of ISC DHCP, might be quicker. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- *Andre Kostur* Senior Product Design Engineer *P:* 604-678-2864 *E:* akostur@incognito.com *Toll-Free:* 1-800-877-1856 *F:* 604-678-2864 *VoIP:* sip:864@sip.incognito.com [image: Incognito Software Inc.] --bcaec554d98618d3ae04b88d72a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think Bernie is suggesting that you take the format of D= UID-LL and use it for this option, and not to specifically peer into the ac= tual DUID option to find the MAC address.

I disagree wit= h Bernie where I think the client should be able to supply its own MAC addr= ess, but I agree with him that if this is also supplied by the Relay Agent,= the server should prefer the Relay Agent's version of the MAC address.= =A0The client may be operating in an environment where there are no Relay = Agents, and the server is hearing the client's multicasts directly.


On Thu, Feb 9, 2012 at 11:52, <sthaug@nethelp.no> wrote:
> I don't understand why the RFC 3315 DUID-LL type= format isn't used here.

Maybe because 3315 contains very explicit language prohibiting server= s
from peeking inside the DUID in any way? For the Client Hardware
Address Option we *want* the server to be able to look at the address,
obviously.

> I'd be much happier if this was ONLY a Relay Agent option. That re= ally
> as a higher level of 'trust' to the data (as that is the link-= layer
> address being used by the device to communicate with the relay).

Agree that the relay agent has a higher level of trust. Disagree that=
the option should *only* be a relay agent option - that requires relay
agent implementation, which takes time. A client side implementation,
for instance if it came as part of ISC DHCP, might be quicker.

Steinar Haug, Nethelp consulting, stha= ug@nethelp.no
___________________________________= ____________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



--
=
Andre= Kostur
Senior Product Design Engineer
P: 604-678-2864
E: akostur@incognito.= com
Toll-Free: 1-800-877-1856

F:= 604-678-2864
VoIP: sip:864@sip.incognito.com

3D"Incognito


--bcaec554d98618d3ae04b88d72a1-- From sthaug@nethelp.no Thu Feb 9 12:32:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5C321F861B for ; Thu, 9 Feb 2012 12:32:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dasB7TqQb55Y for ; Thu, 9 Feb 2012 12:32:10 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id B8DF521F85BE for ; Thu, 9 Feb 2012 12:32:09 -0800 (PST) Received: (qmail 24058 invoked from network); 9 Feb 2012 20:32:08 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Feb 2012 20:32:08 -0000 Date: Thu, 09 Feb 2012 21:32:08 +0100 (CET) Message-Id: <20120209.213208.112607813.sthaug@nethelp.no> To: volz@cisco.com From: sthaug@nethelp.no In-Reply-To: References: <20120209.205240.78726629.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 20:32:11 -0000 > You misunderstood. I was NOT suggesting that anyone 'look' inside the > DUID. I was saying we should use DHCPv6 terminology and formats for the > data carried in your option. I see I wasn't clear enough. I didn't think peeking inside the DUID was suggested. I think that if the *language* from the DUID-LL section of 3315 is used, and a reference to same section is included, some people might think that we don't really want them to be able to get to the hardware address after all. Should be easy enough to fix (we *really really* want to let you look at the hardware address now :-) Steinar Haug, Nethelp consulting, sthaug@nethelp.no From linux@thehobsons.co.uk Thu Feb 9 13:50:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C0221F8699 for ; Thu, 9 Feb 2012 13:50:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUGOBtStDKch for ; Thu, 9 Feb 2012 13:50:23 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 125CE21F8697 for ; Thu, 9 Feb 2012 13:50:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id A6BE610401A for ; Thu, 9 Feb 2012 21:50:14 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWlkDlbYWPSD for ; Thu, 9 Feb 2012 21:50:14 +0000 (GMT) Received: from simon.thehobsons.co.uk (simons-macbookpro.thehobsons.co.uk [192.168.0.202]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 4013529EDE for ; Thu, 9 Feb 2012 21:50:14 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120209.205240.78726629.sthaug@nethelp.no> Date: Thu, 9 Feb 2012 21:50:06 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 21:50:24 -0000 Andre Kostur wrote: >I disagree with Bernie where I think the client should be able to >supply its own MAC address, but I agree with him that if this is >also supplied by the Relay Agent, the server should prefer the Relay >Agent's version of the MAC address. If you go down that route, then the client doesn't need to provide it at all - either the server (if on the same link) or the relay agent (for remote clients) would be able to extract the hardware address from the packet - at least for ethernet like network types. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From akostur@incognito.com Thu Feb 9 14:05:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D0621F8758 for ; Thu, 9 Feb 2012 14:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.088 X-Spam-Level: X-Spam-Status: No, score=-5.088 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLg8fj466t-P for ; Thu, 9 Feb 2012 14:05:04 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id 0925F21F8757 for ; Thu, 9 Feb 2012 14:05:03 -0800 (PST) Received: from mail-lpp01m020-f176.google.com ([209.85.217.176]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKTzRDDq5ktlLrhYOmJMoxcZ/M6iXPhy2w@postini.com; Thu, 09 Feb 2012 14:05:04 PST Received: by lboi15 with SMTP id i15so1063143lbo.7 for ; Thu, 09 Feb 2012 14:05:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.130.167 with SMTP id of7mr2349852lab.36.1328825100857; Thu, 09 Feb 2012 14:05:00 -0800 (PST) Received: by 10.112.56.161 with HTTP; Thu, 9 Feb 2012 14:05:00 -0800 (PST) In-Reply-To: References: <20120209.205240.78726629.sthaug@nethelp.no> Date: Thu, 9 Feb 2012 14:05:00 -0800 Message-ID: From: Andre Kostur To: Simon Hobson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQldHw7GZRBpL2UlR01sPyKN8BI3uz6Vv7qIpIYeyGuonDI6tkHoUOoSa0ErSUQwSek/adBy Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:05:05 -0000 What about a relay agent which doesn't know about this option? On Thu, Feb 9, 2012 at 13:50, Simon Hobson wrote: > > Andre Kostur wrote: > >> I disagree with Bernie where I think the client should be able to supply= its own MAC address, but I agree with him that if this is also supplied by= the Relay Agent, the server should prefer the Relay Agent's version of the= MAC address. > > > If you go down that route, then the client doesn't need to provide it at = all - either the server (if on the same link) or the relay agent (for remot= e clients) would be able to extract the hardware address from the packet - = at least for ethernet like network types. > > -- > Simon Hobson > > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur From Tina.Tsou.Zouting@huawei.com Thu Feb 9 14:52:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3397121E8044 for ; Thu, 9 Feb 2012 14:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNUaw3nhYlMT for ; Thu, 9 Feb 2012 14:52:04 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4194F11E8073 for ; Thu, 9 Feb 2012 14:52:04 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500EAME6KJ2@szxga05-in.huawei.com> for dhcwg@ietf.org; Fri, 10 Feb 2012 06:51:57 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500LEFE6KIT@szxga05-in.huawei.com> for dhcwg@ietf.org; Fri, 10 Feb 2012 06:51:56 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ83186; Fri, 10 Feb 2012 06:51:52 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 06:51:41 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 10 Feb 2012 06:51:35 +0800 Date: Thu, 09 Feb 2012 22:51:34 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.156] To: Andre Kostur , Simon Hobson Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [dhcwg] DHCPv6 Hardware Option Thread-index: AczfBX/eIjGrqmFtt0ukiIPbHFvXMQIWPJWQ//+FwQCAAAHRAIAAHv8AgAAEKQD//2zy4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120209.205240.78726629.sthaug@nethelp.no> Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:52:05 -0000 Tina > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Andre Kostur > Sent: Thursday, February 09, 2012 2:05 PM > To: Simon Hobson > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 Hardware Option > > What about a relay agent which doesn't know about this option? Then it will be dropped. > > On Thu, Feb 9, 2012 at 13:50, Simon Hobson wrote: > > > > Andre Kostur wrote: > > > >> I disagree with Bernie where I think the client should be able to > supply its own MAC address, but I agree with him that if this is also > supplied by the Relay Agent, the server should prefer the Relay Agent's > version of the MAC address. > > > > > > If you go down that route, then the client doesn't need to provide it at > all - either the server (if on the same link) or the relay agent (for > remote clients) would be able to extract the hardware address from the > packet - at least for ethernet like network types. > > > > -- > > Simon Hobson > > > > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > > author Gladys Hobson. Novels - poetry - short stories - ideal as > > Christmas stocking fillers. Some available as e-books. > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From linux@thehobsons.co.uk Thu Feb 9 15:28:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40E121E805F for ; Thu, 9 Feb 2012 15:28:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe7UUqx7kuZr for ; Thu, 9 Feb 2012 15:28:14 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 6B60821E805E for ; Thu, 9 Feb 2012 15:28:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 7812A10401A for ; Thu, 9 Feb 2012 23:28:05 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1smNGCSX7p5a for ; Thu, 9 Feb 2012 23:28:05 +0000 (GMT) Received: from simon.thehobsons.co.uk (simons-macbookpro.thehobsons.co.uk [192.168.0.202]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 0C4D929EDE for ; Thu, 9 Feb 2012 23:28:04 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120209.205240.78726629.sthaug@nethelp.no> Date: Thu, 9 Feb 2012 23:28:00 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:28:14 -0000 Andre Kostur wrote: >>If you go down that route, then the client doesn't need to provide >>it at all - either the server (if on the same link) or the relay >>agent (for remote clients) would be able to extract the hardware >>address from the packet - at least for ethernet like network types. >What about a relay agent which doesn't know about this option? In some respects it's the same problem as making clients do something new - if you want to use that option in your config then all the clients need to provide it, or all the relay agents and/or the server need to provide it. Either way, code needs to change - and in the general case that means multiple vendors changing stuff. The question was raised of "do you trust the client to supply this ?" The answer is probably that you have to - since the client can spoof any MAC address anyway if it wants to do bad things. So it's probably not an issue. As I see it, you can either let the client provide it as an option - so relay agents and servers don't need changes Or you can leave the client alone and let the server/relay agent determine it. It wouldn't make sense to have the client do it under some circumstances, and the relay agent under other circumstances. There is the other issue of doing it in the relay agent - and that's much like the problems with Option 82 in the IPv4 world, where it's added by the relay agent for broadcast requests, but not to unicast packets sent directly from the client to the server (unless the relay agent is in the packet path and modifies unicast packets as well). I'm thinking it's probably easiest to implement as a client adding it as another option. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From cra@WPI.EDU Thu Feb 9 15:34:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB63111E808F for ; Thu, 9 Feb 2012 15:34:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4t805skyGsy for ; Thu, 9 Feb 2012 15:34:33 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id E300B11E8080 for ; Thu, 9 Feb 2012 15:34:20 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q19NYKVH023333 for ; Thu, 9 Feb 2012 18:34:20 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q19NYKVH023333 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1328830460; bh=NadDt8t10PwzI1fpJvJqhGkC9ZjwRSLNisD75cZf9fM=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=p5IaAU++4c/evR04bBAAmAWDksPDtCzJM3VVl6lQI83wwdrwZv4ORuN5olluOVGC4 yL6bohlyvbl21Jyz6p2egqcsGZXDFmBnu5Fhc8ubEdGyZw7UurQiOD1zfkwUrv9Ruj kMHq31VyIlVHoIflkHKz1rMOi+yXvPzBznBCENhI= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q19NYKv3023330 for ; Thu, 9 Feb 2012 18:34:20 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q19NYIUi004132 for ; Thu, 9 Feb 2012 18:34:19 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id q19NYIdq005665 for ; Thu, 9 Feb 2012 18:34:18 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id q19NYIEe005663 for dhcwg@ietf.org; Thu, 9 Feb 2012 18:34:18 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 9 Feb 2012 18:34:18 -0500 From: Chuck Anderson To: dhcwg@ietf.org Message-ID: <20120209233418.GU5968@angus.ind.WPI.EDU> Mail-Followup-To: dhcwg@ietf.org References: <20120209.205240.78726629.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:34:34 -0000 On Thu, Feb 09, 2012 at 09:50:06PM +0000, Simon Hobson wrote: > Andre Kostur wrote: > >> I disagree with Bernie where I think the client should be able to >> supply its own MAC address, but I agree with him that if this is also >> supplied by the Relay Agent, the server should prefer the Relay >> Agent's version of the MAC address. > > If you go down that route, then the client doesn't need to provide it at > all - either the server (if on the same link) or the relay agent (for > remote clients) would be able to extract the hardware address from the > packet - at least for ethernet like network types. We implemented a proof of concept of this approach using ISC dhcrelay, although we extracted the Ethernet address from the ND table on the Relay Agent and then put it into a Relay option. It is quite a pain for the server (or relay for that matter) to have to peek into L2 headers in many implementations, but I'll take that over nothing. The ND table approach may be a better one, but that is an implementation detail. From cra@WPI.EDU Thu Feb 9 15:36:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879D011E808A for ; Thu, 9 Feb 2012 15:36:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8CzFcS49oxp for ; Thu, 9 Feb 2012 15:36:50 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id EF74A11E8080 for ; Thu, 9 Feb 2012 15:36:49 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q19NanQe024137 for ; Thu, 9 Feb 2012 18:36:49 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q19NanQe024137 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1328830609; bh=O8SfbxleODBMVc2PmfRi4gzSoCmEuMNjVD0q8Ow0lbM=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=qJYbeGqO8ckpmRD0E4PZdZImCZlLzV6Qa3U74ZZO4tnxekExc9OM7kbsg8D09J6up NBp3Myx18NZFcDDkiKOUPDvE0onvgvDtZRYVAiI4ba4wb0DU4fjPjgakxwD4K4QueB YUqPKk8Y1BZZEuwf6t9zWFKV2X+lW1ph5lFNXpCM= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q19NanMk024134 for ; Thu, 9 Feb 2012 18:36:49 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q19Namgm005983 for ; Thu, 9 Feb 2012 18:36:48 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id q19NalhH005704 for ; Thu, 9 Feb 2012 18:36:48 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id q19NalQ9005703 for dhcwg@ietf.org; Thu, 9 Feb 2012 18:36:47 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 9 Feb 2012 18:36:47 -0500 From: Chuck Anderson To: dhcwg@ietf.org Message-ID: <20120209233647.GV5968@angus.ind.WPI.EDU> Mail-Followup-To: dhcwg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:36:50 -0000 On Thu, Feb 09, 2012 at 01:25:16PM -0600, Bernie Volz (volz) wrote: > I don't understand why the RFC 3315 DUID-LL type format isn't used here. > Let's not use DHCPv4-isms. So, this draft should be updated to use the > format of the DUID-LL (section 9.4 of RFC 3315). Basically, the hardware > type is 16-bits, not 8. And "chtype"?? In DHCPv4, the field is "htype". > I'd drop "[c]htype" and "chaddr" (except when mentioning the DHCPv4 > equivalents). These are not really used in DHCPv6 (where we use hardware > address and link-layer address). Agree. > A more minor nit, perhaps call the option OPTION_CLIENT_LLA? (Draft > might be called Client Link-Layer Address Option). Agree. > I'd be much happier if this was ONLY a Relay Agent option. That really > as a higher level of 'trust' to the data (as that is the link-layer > address being used by the device to communicate with the relay). And, a > client might get this wrong if it is multihomed. But, I guess for things > like PXE booting, there might be reasons to have the client provide it. Disagree, I would like to allow a client or relay to use this because they can be useful in different cases. > In any case, servers should always prefer the Relay information over any > client provided information, so I think the following is bad and > backwards: Agree. > In section 4, I would NOT list the messages. There is little 'harm' in a > client in providing this even in an Information-Request or some future > messages. Best to not list things that are not needed and are not > exhaustive. Agree. From volz@cisco.com Thu Feb 9 16:49:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1848C21E8081 for ; Thu, 9 Feb 2012 16:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=-2.731, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GIho1A9lx7O for ; Thu, 9 Feb 2012 16:49:14 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 41BB121E808B for ; Thu, 9 Feb 2012 16:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=457; q=dns/txt; s=iport; t=1328834954; x=1330044554; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=cduQqkM+wsfDxpZPXyDk9uJQ6FEpsv8xvM+LZ3wmXB0=; b=Snb+p5y/QaVLHsINHGycvG7cfAXw859QZqhU/fPx/V5hKUOhlXGKgivi r+tWG7eoLHCbFKpeUsI2u03CnnUdotmYHjn/KbqM754ml8Twc4eazUR32 zSfxynRAu8D/Rc+H+skW1UqTIuqSmBlxGP2ETTZiDOWcb2jit5JRJGjlO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQJAH1oNE+tJXHB/2dsb2JhbABDiVemBAKBB4FyAQEBAwESASc/BQsCAQgOOFcBAQQTIodamgIBnwqLejcfCwECAYMXBQaBHIJaYwSISIxnkwA X-IronPort-AV: E=Sophos;i="4.73,392,1325462400"; d="scan'208";a="55168472" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 10 Feb 2012 00:49:13 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q1A0nD0p009070; Fri, 10 Feb 2012 00:49:13 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 18:49:13 -0600 Received: from 72.163.63.12 ([72.163.63.12]) by XMB-RCD-101.cisco.com ([72.163.62.143]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Feb 2012 00:49:13 +0000 References: <20120209.205240.78726629.sthaug@nethelp.no> Content-Transfer-Encoding: quoted-printable From: "Bernie Volz (volz)" Thread-Topic: [dhcwg] DHCPv6 Hardware Option Thread-Index: Acznjc64LOecdXoqTgaCKsnz5H329g== Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: <6DB3E2D1-45E9-4109-AB4D-AD41E7715EA4@cisco.com> Date: Thu, 9 Feb 2012 19:49:09 -0500 To: "Simon Hobson" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 10 Feb 2012 00:49:13.0679 (UTC) FILETIME=[CF0925F0:01CCE78D] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 00:49:15 -0000 skipping relay is not an issue - in v6 clients multicast ALL packets unless s= erver tells them via option they can unicast. Sent from my iPhone On Feb 9, 2012, at 6:28 PM, "Simon Hobson" wrote: > There is the other issue of doing it in the relay agent - and that's much l= ike the problems with Option 82 in the IPv4 world, where it's added by the r= elay agent for broadcast requests, but not to unicast packets sent From ghalwasi@cisco.com Thu Feb 9 18:17:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D529B11E8076 for ; Thu, 9 Feb 2012 18:17:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP2E8foIuiFj for ; Thu, 9 Feb 2012 18:17:13 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id D106F11E8075 for ; Thu, 9 Feb 2012 18:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=987; q=dns/txt; s=iport; t=1328840233; x=1330049833; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/oiBMtE4PHEGPH9ftJTExQWrIzKR9AjyFVoZuLn8CYQ=; b=MgbLTf9OTitJyJy7Hzgtm6vqVabtAoubCN/YsPISw64fxMRiSBu8d3s5 ah8SdfrGsKatnGgiJvyuNGjFnsVUWg++dId0rb2nFcvfb0GGMgknD5tTX BXGhwi1Vn5l9BK3gaWdmALTcbLQ32ZqZ6PanhyvppAot+Kp33F6DNiCeE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAIt9NE9Io8UY/2dsb2JhbABDsGaBcgEBAQMBAQEBDwEdCjQLBQcEAgEIEQQBAQsGFwEGASYfCQgBAQQBCggIGodaCZl3AZ8KBIs3Ig8LBzgFASMDg2NWBoJaYwSIRp9T X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="5220545" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 10 Feb 2012 02:17:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1A2HAUm029430; Fri, 10 Feb 2012 02:17:10 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 07:47:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2012 07:47:09 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B81056EBA4E@XMB-BGL-41E.cisco.com> In-Reply-To: <6DB3E2D1-45E9-4109-AB4D-AD41E7715EA4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCPv6 Hardware Option Thread-Index: Acznjc64LOecdXoqTgaCKsnz5H329gADBKxw References: <20120209.205240.78726629.sthaug@nethelp.no> <6DB3E2D1-45E9-4109-AB4D-AD41E7715EA4@cisco.com> From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , "Simon Hobson" X-OriginalArrivalTime: 10 Feb 2012 02:17:09.0643 (UTC) FILETIME=[17C15DB0:01CCE79A] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 02:17:15 -0000 Thanks for the discussion and review guys. We will take care of these review comments in the next revision which will be out soon. Regards, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Friday, February 10, 2012 6:19 AM To: Simon Hobson Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Hardware Option skipping relay is not an issue - in v6 clients multicast ALL packets unless server tells them via option they can unicast. Sent from my iPhone On Feb 9, 2012, at 6:28 PM, "Simon Hobson" wrote: > There is the other issue of doing it in the relay agent - and that's much like the problems with Option 82 in the IPv4 world, where it's added by the relay agent for broadcast requests, but not to unicast packets sent _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From roberta.maglione@telecomitalia.it Fri Feb 10 03:52:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6A521F875A for ; Fri, 10 Feb 2012 03:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.349 X-Spam-Level: *** X-Spam-Status: No, score=3.349 tagged_above=-999 required=5 tests=[AWL=-2.235, BAYES_00=-2.599, FR_DOT_FEVER_5=3.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_15=0.6, LONGWORDS=1.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J84bRjQpO3h for ; Fri, 10 Feb 2012 03:52:15 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id EDF9D21F8741 for ; Fri, 10 Feb 2012 03:52:14 -0800 (PST) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Feb 2012 12:52:09 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Fri, 10 Feb 2012 12:52:09 +0100 From: Maglione Roberta To: 'Matthew Ryan' , 'Menachem Dodge' Date: Fri, 10 Feb 2012 12:52:09 +0100 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt Thread-Index: AcziwejofOmKtphZTxe8UzzTmzMXPwFJwIMA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1@GRFMBX704BA020.griffon.local> References: <20111221164220.13693.80809.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> <82B4F550-9202-4EA2-87ED-93BF78C5D0C5@nominum.com> In-Reply-To: <82B4F550-9202-4EA2-87ED-93BF78C5D0C5@nominum.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: multipart/mixed; boundary="_002_282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1GRFMBX704BA02_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Feb 2012 06:51:23 -0800 Cc: "'James.Bristow@swisscom.com'" , Ullio Mario , 'Ted Lemon' , dhc WG , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 11:52:17 -0000 --_002_282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Matt, Menachem and All, I made some changes to the document in order to address your comments. Please see answers inline [RM]. I attached a new version of the document I haven't posted it yet, please le= t me know if the new version covers your points and if you have additional = comments. Thanks, Best regards, Roberta -----Original Message----- From: Matthew Ryan [mailto:Matt.Ryan@nominum.com] Sent: venerd=EC 3 febbraio 2012 23.19 To: Maglione Roberta Cc: dhc WG; 'david.miles@alcatel-lucent.com'; Wojciech Dec (wdec); 'James.B= ristow@swisscom.com'; Ullio Mario; 'Ted Lemon' Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt On Feb 3, 2012, at 07:26 , Maglione Roberta wrote: > > Section 3.1.4 states: > The client will receive a Forcerenew Nonce from the server in the > initial DHCP Ack message from the server. > which could be construed to imply that the nonce is only chosen > during the initial 4-way handshake. > > However, the protocol interaction diagram in section 3.1.1 > seems to indicate that, during a renew, the server may/must > (unclear) create a new nonce. > > [RM] The idea is that the nonce is selected and sent by the server in the= initial DHCP exchange, then later on when the DHCP server needs to send a = Forcerenew message it includes the nonce previously created in the message = sent to the client. In this way the client can verify that the Forcerenew m= essage comes from a trusted DHCP server. Please let me know if you think th= is behavior should better explained in the document I believe it's clear that a nonce should be returned in each ACK message. However, I think the document needs to be clarified as to which REQUEST messages (init-reboot, select, renew, rebind) or conditions should cause a server to generate a /new/ nonce. Specifically, when the server MUST generate a nonce, and when it MAY generate (or change) the nonce. [RM] I clarified this by adding the following sentences: The server SHOULD NOT include the nonce in an ACK when responding to a renew unless a nonce was generated. This minimizes the number of times the nonce is sent over the wire. (as per your proposal) If the server to which the DHCP Request message was sent at time T1 has not responded, the client enters the REBINDING state and attempts to contact any server. The new Server receiving the DHCP message MUST generate a new nonce. Does the server ONLY generate a nonce the first time it sees the client? Is the server ONLY allowed to generate a nonce (even if it has no previous recorded) in response to a select, or can it do so for rebind and init-reboot as well? Can the server (perhaps on a timer or by admin instruction) choose to generate a new nonce for a client in response to a renew? [RM] In case of rebind the Server MUST generates a new nonce In addition, it should be clarified when a client should update its record of the nonce. The draft currently states this is done in response to the "initial DHCP Ack message". Depending on the answers to the server behavior question above, this may not be sufficient. If the server is allowed to generate a new nonce on rebind (which may need to happen in environments that have multiple DHCP servers that don't do failover), the client should probably update itself then as well. Also, what should happen in the case where the client indicates in a renew that it is capable, and the server is capable, but the server has no recollection of a nonce for the client? This condition can happen if the server support is enabled and the client already possesses an active lease from the server. [RM] Good points, I think the 3 points you propose below take care of these= cases. I would probably recommend at the following: 1) The client MUST record the nonce from any valid ACK it receives, if the ACK contains one. 2) If a capable server receives a DISCOVER or REQUEST (any type) that indicates the client is capable, and the server has no previous nonce recorded, it MUST generate a nonce and include it in the ACK. 3) The server SHOULD NOT include the nonce in an ACK when responding to a renew unless a nonce was generated. This minimizes the number of times the nonce is sent over the wire. [RM] I added the 3 points you suggested That leaves open the question of whether a server MAY change an existing nonce, but that becomes a non-issue due to (1). My reading of the draft indicated that the server would send a nonce of type 0 in an OFFER (type 0 is not covered in section 3.1.2) - but there was no indication of what the value should be. I think, that, in the OFFER message, it is sufficient for the server to simply send the FORCERENEW_NONCE_CAPABLE, and omit the authentication option. So, I would change section 3.1.4 from: The client MUST indicate Forcerenew nonce Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all DHCP Discover and Request messages. DHCP servers that support Forcerenew nonce Protocol authentication MUST include the DHCP Forcerenew Nonce protocol authentication option in DHCP Offers with type set to zero(0), allowing the client to use this capability in selecting DHCP servers should multiple Offers arrive. A DHCP server has indicates its support through the inclusion of the FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client MUST validate the DHCP Ack message contains a Forcerenew Nonce in a DHCP authentication option. If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. to (changed lines marked, no rewrapping done for clarity): The client MUST indicate Forcerenew nonce Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all DHCP Discover and Request messages. DHCP servers that support * Forcerenew nonce Protocol authentication MUST include the * FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all * DHCP Offers, allowing the client to use this capability in selecting DHCP servers should multiple Offers arrive. * The client MUST validate the DHCP Ack message contains a Forcerenew Nonce in a DHCP authentication option. If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. [RM] I modified the text as per your proposal - Matt Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. --_002_282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1GRFMBX704BA02_ Content-Type: text/plain; name="draft-ietf-dhc-forcerenew-nonce-04.txt" Content-Description: draft-ietf-dhc-forcerenew-nonce-04.txt Content-Disposition: attachment; filename="draft-ietf-dhc-forcerenew-nonce-04.txt"; size=25350; creation-date="Fri, 10 Feb 2012 10:17:30 GMT"; modification-date="Fri, 10 Feb 2012 12:29:58 GMT" Content-Transfer-Encoding: base64 CgoKc29mdHdpcmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIE1pbGVzCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdvb2dsZQpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBEZWMKRXhwaXJl czogQXVndXN0IDEzLCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNj byBTeXN0ZW1zCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSi4gQnJpc3RvdwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFN3aXNzY29tIFNjaHdlaXogQUcKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIE1hZ2xpb25l CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUZWxlY29tIEl0YWxpYQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRmVicnVhcnkgMTAsIDIwMTIKCgogICAgICAgICAgICAgICAgICAgIEZv cmNlcmVuZXcgTm9uY2UgQXV0aGVudGljYXRpb24KICAgICAgICAgICAgICAgICAgIGRyYWZ0LWll dGYtZGhjLWZvcmNlcmVuZXctbm9uY2UtMDQKCkFic3RyYWN0CgogICBEeW5hbWljIEhvc3QgQ29u ZmlndXJhdGlvbiBQcm90b2NvbCAoREhDUCkgRm9yY2VyZW5ldyBhbGxvd3MgZm9yIHRoZQogICBy ZWNvbmZpZ3VyYXRpb24gb2YgYSBzaW5nbGUgaG9zdCBieSBmb3JjaW5nIHRoZSBESENQIGNsaWVu dCBpbnRvIGEKICAgUmVuZXcgc3RhdGUgb24gYSB0cmlnZ2VyIGZyb20gdGhlIERIQ1Agc2VydmVy LiAgSW4gRm9yY2VyZW5ldyBOb25jZQogICBBdXRoZW50aWNhdGlvbiB0aGUgc2VydmVyIHNlbmRz IGEgbm9uY2Ugd2l0aCB0aGUgY2xpZW50IG9uIHRoZQogICBpbml0aWFsIERIQ1AgQUNLIHRoYXQg aXMgdXNlZCBmb3Igc3Vic2VxdWVudCB2YWxpZGF0aW9uIG9mIGEKICAgRm9yY2VyZW5ldyBtZXNz YWdlLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJt aXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRo YXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMg YXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJh ZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVt IG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRl cm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBdWd1c3QgMTMsIDIwMTIuCgpDb3B5cmlnaHQgTm90 aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRl bnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQu CgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVz dCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0 dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRl IG9mCgoKCk1pbGVzLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxMywgMjAxMiAg ICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBGb3Jj ZXJlbmV3IE5vbmNlICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMgoKCiAgIHB1YmxpY2F0aW9u IG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJl ZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRo IHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQg ZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNl IHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQ cm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmli ZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKVGFibGUgb2YgQ29udGVudHMKCiAg IDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMwogICAyLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgMy4gIE1lc3NhZ2UgYXV0aGVudGljYXRp b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMy4xLiAg Rm9yY2VyZW5ldyBOb25jZSBBdXRoZW50aWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMwogICAgICAgMy4xLjEuICBGb3JjZXJlbmV3IE5vbmNlIFByb3RvY29sIENhcGFiaWxpdHkg T3B0aW9uICAuIC4gLiAuIC4gIDQKICAgICAgIDMuMS4yLiAgRm9yY2VyZW5ldyBOb25jZSBQcm90 b2NvbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgICAgICAzLjEuMy4gIFNlcnZl ciBjb25zaWRlcmF0aW9ucyBmb3IgRm9yY2VyZW5ldyBOb25jZQogICAgICAgICAgICAgICBBdXRo ZW50aWNhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAg ICAgIDMuMS40LiAgQ2xpZW50IGNvbnNpZGVyYXRpb25zIGZvciBGb3JjZXJlbmV3IE5vbmNlCiAg ICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgOQogICA0LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgIDYuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMAogICAgIDYuMS4gIFByb3RvY29sIHZ1bG5lcmFiaWxpdGllcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgNy4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgNy4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAg IDcuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTEKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTWlsZXMs IGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEzLCAyMDEyICAgICAgICAgICAgICAg IFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIEZvcmNlcmVuZXcgTm9uY2Ug ICAgICAgICAgICAgICBGZWJydWFyeSAyMDEyCgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhlIERI Q1AgUmVjb25maWd1cmUgRXh0ZW5zaW9uIGRlZmluZWQgaW4gW1JGQzMyMDNdIGlzIGEgdXNlZnVs CiAgIG1lY2hhbmlzbSBhbGxvd2luZyBkeW5hbWljIHJlY29uZmlndXJhdGlvbiBvZiBhIHNpbmds ZSBob3N0IHRyaWdnZXJlZAogICBieSB0aGUgREhDUCBzZXJ2ZXIuICBJdHMgYXBwbGljYXRpb24g aXMgY3VycmVudGx5IGxpbWl0ZWQgYnkgYQogICByZXF1aXJlbWVudCB0aGF0IEZPUkNFUkVORVcg bWVzc2FnZSBpcyBhbHdheXMgYXV0aGVudGljYXRlZCB1c2luZwogICBwcm9jZWR1cmVzIGFzIGRl c2NyaWJlZCBpbiBbUkZDMzExOF0uICBBdXRoZW50aWNhdGlvbiBmb3IgREhDUAogICBbUkZDMzEx OF0gaXMgbWFuZGF0b3J5IGZvciBGb3JjZXJlbmV3LCBob3dldmVyIGFzIGl0IGlzIGN1cnJlbnRs eQogICBkZWZpbmVkIFtSRkMzMTE4XSByZXF1aXJlcyBkaXN0cmlidXRpb24gb2YgY29uc3RhbnQg dG9rZW4gb3Igc2hhcmVkLQogICBzZWNyZXQgb3V0LW9mLWJhbmQgdG8gREhDUCBjbGllbnRzLiAg VGhlIG1hbmRhdG9yeSBhdXRoZW50aWNhdGlvbiB3YXMKICAgb3JpZ2luYWxseSBtb3RpdmF0ZWQg YnkgYSBsZWdpdGltYXRlIHNlY3VyaXR5IGNvbmNlcm4gd2hlcmVieSBpbiBzb21lCiAgIG5ldHdv cmsgZW52aXJvbm1lbnRzIGEgRk9SQ0VSRU5FVyBtZXNzYWdlIGNhbiBiZSBzcG9vZmVkLiAgSG93 ZXZlciwKICAgaW4gc29tZSBuZXR3b3JrcyBuYXRpdmUgc2VjdXJpdHkgbWVjaGFuaXNtcyBhbHJl YWR5IHByb3ZpZGUKICAgc3VmZmljaWVudCBwcm90ZWN0aW9uIGFnYWluc3Qgc3Bvb2Zpbmcgb2Yg REhDUCB0cmFmZmljLiAgQW4gZXhhbXBsZQogICBvZiBzdWNoIG5ldHdvcmsgaXMgYSBCcm9hZGJh bmQgRm9ydW0gVFItMTAxIFtUUi0xMDFpMl0gY29tcGxpYW50CiAgIGFjY2VzcyBuZXR3b3JrLiAg SW4gc3VjaCBlbnZpcm9ubWVudHMgdGhlIG1hbmRhdG9yeSBjb3VwbGluZyBiZXR3ZWVuCiAgIEZP UkNFUkVORVcgYW5kIERIQ1AgQXV0aGVudGljYXRpb24gW1JGQzMxMThdIGNhbiBiZSByZWxheGVk LiAgVGhpcwogICBkb2N1bWVudCBkZWZpbmVzIGV4dGVuc2lvbnMgdG8gQXV0aGVudGljYXRpb24g Zm9yIERIQ1AodjQpIE1lc3NhZ2VzCiAgIFtSRkMzMTE4XSB0byBjcmVhdGUgYSBuZXcgYXV0aGVu dGljYXRpb24gcHJvdG9jb2wgZm9yIERIQ1B2NAogICBGb3JjZXJlbmV3IFtSRkMzMjAzXSBtZXNz YWdlczsgdGhpcyBtZXRob2QgZG9lcyBub3QgcmVxdWlyZSBvdXQtb2YtCiAgIGJhbmQga2V5IGRp c3RyaWJ1dGlvbiB0byBESENQIGNsaWVudHMuICBUaGUgRm9yY2VyZW5ldyBOb25jZSBpcwogICBl eGNoYW5nZWQgYmV0d2VlbiBzZXJ2ZXIgYW5kIGNsaWVudCBvbiBpbml0aWFsIERIQ1AgQUNLIGFu ZCBpcyB1c2VkCiAgIGZvciB2ZXJpZmljYXRpb24gb2YgYW55IHN1YnNlcXVlbnQgRm9yY2VyZW5l dyBtZXNzYWdlLiAgVGhpcwogICBtZWNoYW5pc20gaXMgaW50ZW5kZWQgdG8gYmUgdXNlIGluIG5l dHdvcmtzIHRoYXQgYWxyZWFkeSBoYXZlIG5hdGl2ZQogICBzZWN1cml0eSBtZWNoYW5pc21zIHRo YXQgcHJvdmlkZSBzdWZmaWNpZW50IHByb3RlY3Rpb24gYWdhaW5zdAogICBzcG9vZmluZyBvZiBE SENQIHRyYWZmaWMuCgoKMi4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAog ICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJ T05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3Jp YmVkIGluIFtSRkMyMTE5XS4KCgozLiAgTWVzc2FnZSBhdXRoZW50aWNhdGlvbgoKICAgVGhlIEZP UkNFUkVORVcgbWVzc2FnZSBtdXN0IGJlIGF1dGhlbnRpY2F0ZWQgdXNpbmcgZWl0aGVyIFtSRkMz MTE4XQogICBvciB0aGUgcHJvcG9zZWQgRm9yY2VyZW5ldyBOb25jZSBBdXRoZW50aWNhdGlvbiBw cm90b2NvbC4KCjMuMS4gIEZvcmNlcmVuZXcgTm9uY2UgQXV0aGVudGljYXRpb24KCiAgIFRoZSBG b3JjZXJlbmV3IG5vbmNlIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIHByb3ZpZGVzIHByb3RlY3Rp b24KICAgYWdhaW5zdCBtaXNjb25maWd1cmF0aW9uIG9mIGEgY2xpZW50IGNhdXNlZCBieSBhIEZv cmNlcmVuZXcgbWVzc2FnZQogICBzZW50IGJ5IGEgbWFsaWNpb3VzIERIQ1Agc2VydmVyLiAgSW4g dGhpcyBwcm90b2NvbCwgYSBESENQIHNlcnZlcgogICBzZW5kcyBhIEZvcmNlcmVuZXcgbm9uY2Ug dG8gdGhlIGNsaWVudCBpbiB0aGUgaW5pdGlhbCBleGNoYW5nZSBvZgogICBESENQIG1lc3NhZ2Vz LiAgVGhlIGNsaWVudCByZWNvcmRzIHRoZSBGb3JjZXJlbmV3IG5vbmNlIGZvciB1c2UgaW4KICAg YXV0aGVudGljYXRpbmcgc3Vic2VxdWVudCBGb3JjZXJlbmV3IG1lc3NhZ2VzIGZyb20gdGhhdCBz ZXJ2ZXIuICBUaGUKCgoKTWlsZXMsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEz LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIEZvcmNlcmVuZXcgTm9uY2UgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEyCgoKICAgc2Vy dmVyIHRoZW4gaW5jbHVkZXMgYW4gSE1BQyBjb21wdXRlZCBmcm9tIHRoZSBGb3JjZXJlbmV3IG5v bmNlIGluCiAgIHN1YnNlcXVlbnQgRm9yY2VyZW5ldyBtZXNzYWdlcy4KCiAgIEJvdGggdGhlIEZv cmNlcmVuZXcgbm9uY2Ugc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCBhbmQgdGhl CiAgIEhNQUMgaW4gc3Vic2VxdWVudCBGb3JjZXJlbmV3IG1lc3NhZ2VzIGFyZSBjYXJyaWVkIGFz IHRoZQogICBBdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBpbiBhIERIQ1AgQXV0aGVudGljYXRp b24gb3B0aW9uLiAgVGhlCiAgIGZvcm1hdCBvZiB0aGUgQXV0aGVudGljYXRpb24gaW5mb3JtYXRp b24gaXMgZGVmaW5lZCBpbiB0aGUgZm9sbG93aW5nCiAgIHNlY3Rpb24uCgogICBUaGUgRm9yY2Vy ZW5ldyBub25jZSBwcm90b2NvbCBpcyB1c2VkIChpbml0aWF0ZWQgYnkgdGhlIHNlcnZlcikgb25s eQogICBpZiB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgYXJlIG5vdCB1c2luZyBhbnkgb3RoZXIgYXV0 aGVudGljYXRpb24KICAgcHJvdG9jb2wgYW5kIHRoZSBjbGllbnQgYW5kIHNlcnZlciBoYXZlIG5l Z290aWF0ZWQgdG8gdXNlIHRoZQogICBGb3JjZXJlbmV3IE5vbmNlIEF1dGhlbnRpY2F0aW9uIHBy b3RvY29sLgoKMy4xLjEuICBGb3JjZXJlbmV3IE5vbmNlIFByb3RvY29sIENhcGFiaWxpdHkgT3B0 aW9uCgogICBBIERIQ1AgY2xpZW50IGluZGljYXRlcyBESENQIEZvcmNlcmVuZXcgTm9uY2UgUHJv dG9jb2wgY2FwYWJpbGl0eSBieQogICBpbmNsdWRpbmcgYSBGT1JDRVJFTkVXX05PTkNFX0NBUEFC TEUoPFRCRD4pIG9wdGlvbiBpbiBESENQIERpc2NvdmVyCiAgIGFuZCBSZXF1ZXN0IG1lc3NhZ2Vz IHNlbnQgdG8gdGhlIHNlcnZlci4KCiAgIEEgREhDUCBzZXJ2ZXIgdGhhdCBkb2VzIG5vdCBzdXBw b3J0IEZvcmNlcmVuZXcgTm9uY2UgUHJvdG9jb2wKICAgYXV0aGVudGljYXRpb24gc2hvdWxkIGln bm9yZSB0aGUgRk9SQ0VSRU5FV19OT05DRV9DQVBBQkxFKDxUQkQ+KQogICBvcHRpb24uICBBIERI Q1Agc2VydmVyIGluZGljYXRlcyBESENQIEZvcmNlcmVuZXcgTm9uY2UgUHJvdG9jb2wKICAgcHJl ZmVyZW5jZSBieSBpbmNsdWRpbmcgYSBGT1JDRVJFTkVXX05PTkNFX0NBUEFCTEUoPFRCRD4pIG9w dGlvbiBpbgogICBhbnkgREhDUCBPZmZlciBtZXNzYWdlcyBzZW50IHRvIHRoZSBjbGllbnQuCgog ICBBIERIQ1AgY2xpZW50IE1VU1QgTk9UIHNlbmQgREhDUCBtZXNzYWdlcyB3aXRoIGF1dGhlbnRp Y2F0aW9uIG9wdGlvbnMKICAgd2hlcmUgdGhlIHByb3RvY29sIHZhbHVlIGlzIEZvcmNlcmVuZXcg Tm9uY2UgQXV0aGVudGljYXRpb24oPFRCRD4pLgoKICAgVGhlIEZPUkNFUkVORVdfTk9OQ0VfQ0FQ QUJMRSBvcHRpb24gaXMgYSB6ZXJvIGxlbmd0aCBvcHRpb24gd2l0aCBjb2RlCiAgIG9mIDxUREI+ IGFuZCBmb3JtYXQgYXMgZm9sbG93czoKCiAgICAgICAgICAgICBDb2RlICAgTGVuCiAgICAgICAg ICAgICstLS0tLSstLS0tLSsKICAgICAgICAgICAgfCBUQkQgfCAgMCAgfAogICAgICAgICAgICAr LS0tLS0rLS0tLS0rCgogICBUaGUgY2xpZW50IHdvdWxkIGluZGljYXRlIHRoYXQgaXQgc3VwcG9y dHMgdGhlIGZ1bmN0aW9uYWxpdHkgYnkKICAgaW5zZXJ0aW5nIHRoZSBGT1JDRVJFTkVXX05PTkNF X0NBUEFCTEUgb3B0aW9uIGluIHRoZSBESENQIERpc2NvdmVyCiAgIGFuZCBSZXF1ZXN0IG1lc3Nh Z2VzLiAgSWYgdGhlIHNlcnZlciBzdXBwb3J0cyBGb3JjZXJlbmV3IG5vbmNlCiAgIGF1dGhlbnRp Y2F0aW9uIGFuZCBpcyBjb25maWd1cmVkIHRvIHJlcXVpcmUgRm9yY2VyZW5ldyBub25jZQogICBh dXRoZW50aWNhdGlvbiwgaXQgd2lsbCBpbnNlcnQgdGhlIEZPUkNFUkVORVdfTk9OQ0VfQ0FQQUJM RSBvcHRpb24gaW4KICAgdGhlIERIQ1AgT2ZmZXIgbWVzc2FnZS4KCiAgICAgICAgICAgICAgICAg ICAgIFNlcnZlciAgICAgICAgICBDbGllbnQgICAgICAgICAgU2VydmVyCiAgICAgICAgICAgICAg ICAgKG5vdCBzZWxlY3RlZCkgICAgICAgICAgICAgICAgICAgIChzZWxlY3RlZCkKCiAgICAgICAg ICAgICAgICAgICAgICAgdiAgICAgICAgICAgICAgIHYgICAgICAgICAgICAgICB2CgoKCk1pbGVz LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxMywgMjAxMiAgICAgICAgICAgICAg ICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBGb3JjZXJlbmV3IE5vbmNl ICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMgoKCiAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgQmVnaW5zIGluaXRpYWxpemF0aW9uICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCBf X19fX19fX19fX19fL3xcX19fX19fX19fX19fICB8CiAgICAgICAgICAgICAgICAgICAgICAgfC9E SENQRElTQ09WRVIgIHwgREhDUERJU0NPVkVSIFx8CiAgICAgICAgICAgICAgICAgICAgICAgfCB3 L0ZvcmNlcmVuZXctIHwgdy9Gb3JjZXJlbmV3LSB8CiAgICAgICAgICAgICAgICAgICAgICAgfCBO b25jZS1DYXBhYmxlIHwgTm9uY2UtQ2FwYWJsZSB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICBEZXRlcm1p bmVzICAgICAgICAgIHwgICAgICAgICAgRGV0ZXJtaW5lcwogICAgICAgICAgICAgICAgICBjb25m aWd1cmF0aW9uICAgICAgICB8ICAgICAgICAgY29uZmlndXJhdGlvbgogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgIHxcICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAvfAogICAgICAgICAgICAgICAg ICAgICAgIHwgXF9fX19fX19fX18gICB8ICAgIF9fX19fX19fXy8gfAogICAgICAgICAgICAgICAg ICAgICAgIHwgIERIQ1BPRkZFUiBcICB8ICAgL0RIQ1BPRkZFUiAgfAogICAgICAgICAgICAgICAg ICAgICAgIHx3L0ZvcmNlcmVuZXcgXCB8ICAvdy9Gb3JjZXJlbmV3fAogICAgICAgICAgICAgICAg ICAgICAgIHxOb25jZS1DYXBhYmxlIFx8IC9Ob25jZS1DYXBhYmxlfAogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgQ29sbGVjdHMgcmVwbGllcyAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgIFNlbGVjdHMgY29uZmlndXJhdGlvbiAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgX19fX19fX19fX19fXy98XF9fX19fX19fX19fXyAgfAogICAgICAgICAgICAgICAg ICAgICAgIHwvIERIQ1BSRVFVRVNUICB8ICBESENQUkVRVUVTVFwgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgdy9Gb3JjZXJlbmV3LSB8IHcvRm9yY2VyZW5ldy0gfAogICAgICAgICAgICAgICAg ICAgICAgIHwgTm9uY2UtQ2FwYWJsZSB8IE5vbmNlLUNhcGFibGUgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICBDb21taXRzIGNvbmZpZ3VyYXRpb24KICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfENyZWF0ZXMgMTI4LWJpdCBGb3JjZXJl bmV3IE5vbmNlCiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgX19fX19f X19fX19fXy98CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwvIERIQ1BB Q0sgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgdy9BdXRo LVByb3RvPSB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgRm9yY2Vy ZW5ldy0gICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg IE5vbmNlICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfENsaWVudCBzdG9yZXMgRm9yY2VyZW5l dyBOb25jZSB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICBJbml0aWFsaXphdGlvbiBjb21w bGV0ZSAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgLiAgICAgICAgICAgICAgIC4gICAgICAg ICAgICAgICAuCiAgICAgICAgICAgICAgICAgICAgICAgLiAgICAgICAgICAgICAgIC4gICAgICAg ICAgICAgICAuCiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBGb3JjZXJlbmV3ICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgX19fX19f X19fX19fXy98CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwvIERIQ1BG T1JDRSAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgdy9BdXRo LVByb3RvPSB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgRm9yY2Vy ZW5ldy0gICB8CgoKCk1pbGVzLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxMywg MjAxMiAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBGb3JjZXJlbmV3IE5vbmNlICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMgoKCiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICBEaWdlc3QoSE1BQyl8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCBDbGllbnQgY2hlY2tzIEhNQUMgZGlnZXN0ICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCB1c2luZyBzdG9yZWQgRm9yY2VyZW5ldyBOb25jZSB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHxcX19fX19fX19fX19fICB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgIERIQ1BSRVFVRVNUXCB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgdy9Gb3JjZXJlbmV3LSB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgTm9uY2UtQ2FwYWJsZSB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgIENvbW1pdHMgY29uZmlndXJhdGlv bgogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8Q3JlYXRlcyAxMjgtYml0 IEZvcmNlcmVuZXcgTm9uY2UKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCBfX19fX19fX19fX19fL3wKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fC8gREhDUEFDSyAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCB3L0F1dGgtUHJvdG89IHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgIEZvcmNlcmVuZXctIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgIE5vbmNlIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAuICAgICAgICAgICAgICAg LiAgICAgICAgICAgICAgIC4KICAgICAgICAgICAgICAgICAgICAgICAuICAgICAgICAgICAgICAg LiAgICAgICAgICAgICAgIC4KICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgR3JhY2VmdWwg c2h1dGRvd24gICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fFwgX19fX19fX19fX19fIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCBESENQUkVMRUFTRSAgXHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgRGlzY2FyZHMgbGVhc2UKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB2ICAgICAgICAg ICAgICAgdiAgICAgICAgICAgICAgIHYKCgozLjEuMi4gIEZvcmNlcmVuZXcgTm9uY2UgUHJvdG9j b2wKCiAgIFRoZSBGb3JjZXJlbmV3IE5vbmNlIFByb3RvY29sIG1ha2VzIHVzZSBvZiBib3RoIHRo ZSBESENQCiAgIGF1dGhlbnRpY2F0aW9uIG9wdGlvbiBkZWZpbmVkIGluIFtSRkMzMTE4XSByZS11 c2luZyB0aGUgb3B0aW9uIGZvcm1hdAogICBhbmQgb2YgdGhlIFJlY29uZmlndXJlIEtleSBBdXRo ZW50aWNhdGlvbiBQcm90b2NvbCBkZWZpbmVkIGluCiAgIFtSRkMzMzE1XS4KCiAgIFRoZSBmb2xs b3dpbmcgZGlhZ3JhbSBkZWZpbmVzIHRoZSBmb3JtYXQgb2YgdGhlIERIQ1AgYXV0aGVudGljYXRp b24KICAgb3B0aW9uOgoKCgoKCgoKTWlsZXMsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDEzLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIEZvcmNlcmVuZXcgTm9uY2UgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEyCgoK ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMwoKICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxCgogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICBDb2RlICAg ICAgfCAgICBMZW5ndGggICAgIHwgIFByb3RvY29sICAgICB8ICAgQWxnb3JpdGhtICAgfAogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICAgICB8ICAgICBSRE0gICAgICAgfCBSZXBsYXkgRGV0ZWN0aW9uICg2NCBi aXRzKSAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICBSZXBsYXkg Y29udC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwogICAgICB8ICBSZXBsYXkgY29udC4gfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICB8ICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBJbmZvcm1hdGlvbiAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCgoKICAgVGhl IGZvbGxvd2luZyBmaWVsZHMgYXJlIHNldCBpbiBhbiBESENQIGF1dGhlbnRpY2F0aW9uIG9wdGlv biBmb3IgdGhlCiAgIEZvcmNlcmVuZXcgTm9uY2UgQXV0aGVudGljYXRpb24gUHJvdG9jb2w6Cgog ICAgICAgIGNvZGUgOTAKCiAgICAgICAgbGVuZ3RoIGZpZWxkIGNvbnRhaW5zIHRoZSBsZW5ndGgg b2YgdGhlIHByb3RvY29sCgogICAgICAgIHByb3RvY29sIDMKCiAgICAgICAgYWxnb3JpdGhtIDEK CiAgICAgICAgUmVwbGF5IERldGVjdGlvbiBmaWVsZCBpcyBwZXIgdGhlIFJlcGxheSBEZXRlY3Rp b24gTWV0aG9kIChSRE0pCgogICAgICAgIFJlcGxheSBEZXRlY3Rpb24gTWV0aG9kIChSRE0pIDAK CiAgICAgICAgQXV0aGVudGljYXRpb24gSW5mb3JtYXRpb246IHNwZWNpZmllZCBiZWxvdwoKICAg VGhlIGZvcm1hdCBvZiB0aGUgQXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBGb3Jj ZXJlbmV3IE5vbmNlCiAgIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIGlzOgoKCgoKCgoKCgoKCk1p bGVzLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxMywgMjAxMiAgICAgICAgICAg ICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBGb3JjZXJlbmV3IE5v bmNlICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMgoKCiAgICAgICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgIHwgICAgIFR5cGUgICAgICB8ICAgICAgICAgICAg ICAgICBWYWx1ZSAoMTI4IGJpdHMpICAgICAgICAgICAgICB8CiAgICAgICArLSstKy0rLSstKy0r LSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4KICAgICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuCiAgICAgICAuICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKwogICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgVHlwZSBUeXBl IG9mIGRhdGEgaW4gVmFsdWUgZmllbGQgY2FycmllZCBpbiB0aGlzIG9wdGlvbjoKCiAgICAgICAg MSBGb3JjZXJlbmV3IG5vbmNlIFZhbHVlICh1c2VkIGluIEFDSyBtZXNzYWdlKQoKICAgICAgICAy IEhNQUMtTUQ1IGRpZ2VzdCBvZiB0aGUgbWVzc2FnZSAoRk9SQ0VSRU5FVyBtZXNzYWdlKQoKICAg VmFsdWUgIERhdGEgYXMgZGVmaW5lZCBieSBmaWVsZAoKMy4xLjMuICBTZXJ2ZXIgY29uc2lkZXJh dGlvbnMgZm9yIEZvcmNlcmVuZXcgTm9uY2UgQXV0aGVudGljYXRpb24KCiAgIFRoZSB1c2Ugb2Yg Rm9yY2VyZW5ldyBOb25jZSBQcm90b2NvbCBpcyBkZXBlbmRlbnQgb24gdGhlIGNsaWVudAogICBp bmRpY2F0aW5nIGl0cyBjYXBhYmlsaXR5IHRocm91Z2ggdGhlIEZPUkNFUkVORVdfTk9OQ0VfQ0FQ QUJMRSg8VEJEPikKICAgREhDUCBvcHRpb24gaW4gYW55IERIQ1AgRGlzY292ZXIgb3IgUmVxdWVz dCBtZXNzYWdlcy4gIFRoZSBESENQCiAgIERpc2NvdmVyeSBvciBSZXF1ZXN0IG1lc3NhZ2UgZnJv bSB0aGUgY2xpZW50IE1VU1QgY29udGFpbiB0aGUKICAgRk9SQ0VSRU5FV19OT05DRV9DQVBBQkxF KDxUQkQ+KSBvcHRpb24gaWYgdGhlIEZvcmNlcmVuZXcgTm9uY2UKICAgUHJvdG9jb2wgaXMgdG8g YmUgdXNlZCBieSB0aGUgc2VydmVyLiAgVGhlIGFic2VuY2Ugb2YgdGhlCiAgIEZPUkNFUkVORVdf Tk9OQ0VfQ0FQQUJMRSg8VEJEPikgb3B0aW9uIGluZGljYXRlcyB0byB0aGUgc2VydmVyIHRoYXQK ICAgdGhlIEZvcmNlcmVuZXcgTm9uY2UgQXV0aGVudGljYXRpb24gcHJvdG9jb2wgaXMgbm90IHN1 cHBvcnRlZCBhbmQKICAgdGh1cyB0aGUgc2VydmVyIE1VU1QgTk9UIGluY2x1ZGUgYSBGb3JjZXJl bmV3IE5vbmNlIFByb3RvY29sCiAgIEF1dGhlbnRpY2F0aW9uIG9wdGlvbiBpbiB0aGUgREhDUCBB Y2suCgogICBUaGUgc2VydmVyIGluZGljYXRlcyBpdHMgc3VwcG9ydCBvZiB0aGUgRm9yY2VyZW5l dyBOb25jZSBQcm90b2NvbAogICBhdXRoZW50aWNhdGlvbiBieSBpbmNsdWRpbmcgdGhlIERIQ1Ag Rk9SQ0VSRU5FV19OT05DRV9DQVBBQkxFKDxUQkQ+KQogICBvcHRpb24gaW4gdGhlIERIQ1AgT2Zm ZXIgbWVzc2FnZS4gIFRoZSBzZXJ2ZXIgU0hPVUxEIE5PVCBpbmNsdWRlIHRoaXMKICAgb3B0aW9u IHVubGVzcyB0aGUgY2xpZW50IGhhcyBpbmRpY2F0ZWQgaXRzIGNhcGFiaWxpdHkgaW4gYSBESENQ CiAgIERpc2NvdmVyeSBtZXNzYWdlIC4gIFRoZSBwcmVzZW5jZSBvZiB0aGUKICAgRk9SQ0VSRU5F V19OT05DRV9DQVBBQkxFKDxUREI+KSBvcHRpb24gaW4gdGhlIERIQ1Agb2ZmZXIgbWF5IGJlIHVz ZWQKICAgYnkgY2xpZW50cyB0byBwcmVmZXIgRm9yY2VyZW5ldyBub25jZSBQcm90b2NvbCBhdXRo ZW50aWNhdGlvbi1jYXBhYmxlCiAgIERIQ1Agc2VydmVycyBvdmVyIHRob3NlIHNlcnZlcnMgd2hp Y2ggZG8gbm90IHN1cHBvcnQgc3VjaCBjYXBhYmlsaXR5LgoKICAgSWYgYSBjYXBhYmxlIHNlcnZl ciByZWNlaXZlcyBhIERJU0NPVkVSIG9yIFJFUVVFU1QgKGFueSB0eXBlKSB0aGF0CiAgIGluZGlj YXRlcyB0aGUgY2xpZW50IGlzIGNhcGFibGUsIGFuZCB0aGUgc2VydmVyIGhhcyBubyBwcmV2aW91 cyBub25jZQogICByZWNvcmRlZCwgaXQgTVVTVCBnZW5lcmF0ZSBhIG5vbmNlIGFuZCBpbmNsdWRl IGl0IGluIHRoZSBBQ0suCgogICBUaGUgc2VydmVyIHNlbGVjdHMgYSBGb3JjZXJlbmV3IG5vbmNl IGZvciBhIGNsaWVudCBvbmx5IGR1cmluZwogICBSZXF1ZXN0L0FjayBtZXNzYWdlIGV4Y2hhbmdl LiAgVGhlIHNlcnZlciByZWNvcmRzIHRoZSBGb3JjZXJlbmV3CiAgIG5vbmNlIGFuZCB0cmFuc21p dHMgdGhhdCBub25jZSB0byB0aGUgY2xpZW50IGluIGFuIEF1dGhlbnRpY2F0aW9uCgoKCk1pbGVz LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxMywgMjAxMiAgICAgICAgICAgICAg ICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBGb3JjZXJlbmV3IE5vbmNl ICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMgoKCiAgIG9wdGlvbiBpbiB0aGUgREhDUCBBY2sg bWVzc2FnZS4KCiAgIFRoZSBzZXJ2ZXIgU0hPVUxEIE5PVCBpbmNsdWRlIHRoZSBub25jZSBpbiBh biBBQ0sgd2hlbiByZXNwb25kaW5nIHRvCiAgIGEgcmVuZXcgdW5sZXNzIGEgbm9uY2Ugd2FzIGdl bmVyYXRlZC4gIFRoaXMgbWluaW1pemVzIHRoZSBudW1iZXIgb2YKICAgdGltZXMgdGhlIG5vbmNl IGlzIHNlbnQgb3ZlciB0aGUgd2lyZS4KCiAgIElmIHRoZSBzZXJ2ZXIgdG8gd2hpY2ggdGhlIERI Q1AgUmVxdWVzdCBtZXNzYWdlIHdhcyBzZW50IGF0IHRpbWUgVDEKICAgaGFzIG5vdCByZXNwb25k ZWQsIHRoZSBjbGllbnQgZW50ZXJzIHRoZSBSRUJJTkRJTkcgc3RhdGUgYW5kIGF0dGVtcHRzCiAg IHRvIGNvbnRhY3QgYW55IHNlcnZlci4gIFRoZSBuZXcgU2VydmVyIHJlY2VpdmluZyB0aGUgREhD UCBtZXNzYWdlCiAgIE1VU1QgZ2VuZXJhdGUgYSBuZXcgbm9uY2UuCgogICBUaGUgRm9yY2VyZW5l dyBub25jZSBpcyAxMjggYml0cyBsb25nLCBhbmQgTVVTVCBiZSBhCiAgIGNyeXB0b2dyYXBoaWNh bGx5IHN0cm9uZyByYW5kb20gb3IgcHNldWRvLXJhbmRvbSBudW1iZXIgdGhhdCBjYW5ub3QKICAg ZWFzaWx5IGJlIHByZWRpY3RlZC4gIFRoZSBub25jZSBpcyBpbWJlZGRlZCBhcyBhIDEyOC1iaXQg dmFsdWUgb2YgdGhlCiAgIEF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIHdoZXJlIHR5cGUgaXMg c2V0IHRvIDEgKEZvcmNlcmVuZXcgbm9uY2UKICAgVmFsdWUpLgoKICAgVG8gcHJvdmlkZSBhdXRo ZW50aWNhdGlvbiBmb3IgYSBGb3JjZXJlbmV3IG1lc3NhZ2UsIHRoZSBzZXJ2ZXIKICAgc2VsZWN0 cyBhIHJlcGxheSBkZXRlY3Rpb24gdmFsdWUgYWNjb3JkaW5nIHRvIHRoZSBSRE0gc2VsZWN0ZWQg YnkgdGhlCiAgIHNlcnZlciwgYW5kIGNvbXB1dGVzIGFuIEhNQUMtTUQ1IG9mIHRoZSBGb3JjZXJl bmV3IG1lc3NhZ2UgdXNpbmcgdGhlCiAgIEZvcmNlcmVuZXcgbm9uY2UgZm9yIHRoZSBjbGllbnQu ICBUaGUgc2VydmVyIGNvbXB1dGVzIHRoZSBITUFDLU1ENQogICBvdmVyIHRoZSBlbnRpcmUgREhD UCBGb3JjZXJlbmV3IG1lc3NhZ2UsIGluY2x1ZGluZyB0aGUgQXV0aGVudGljYXRpb24KICAgb3B0 aW9uOyB0aGUgSE1BQy1NRDUgZmllbGQgaW4gdGhlIEF1dGhlbnRpY2F0aW9uIG9wdGlvbiBpcyBz ZXQgdG8KICAgemVybyBmb3IgdGhlIEhNQUMtTUQ1IGNvbXB1dGF0aW9uLiAgVGhlIHNlcnZlciBp bmNsdWRlcyB0aGUgSE1BQy1NRDUKICAgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9u IGZpZWxkIGluIGFuIEF1dGhlbnRpY2F0aW9uIG9wdGlvbgogICBpbmNsdWRlZCBpbiB0aGUgRm9y Y2VyZW5ldyBtZXNzYWdlIHNlbnQgdG8gdGhlIGNsaWVudCB3aXRoIHR5cGUgc2V0CiAgIHRvIDIg KEhNQUMtTUQ1IGRpZ2VzdCkuCgozLjEuNC4gIENsaWVudCBjb25zaWRlcmF0aW9ucyBmb3IgRm9y Y2VyZW5ldyBOb25jZSBBdXRoZW50aWNhdGlvbgoKICAgVGhlIGNsaWVudCBNVVNUIGluZGljYXRl IEZvcmNlcmVuZXcgbm9uY2UgQ2FwYWJpbGl0eSBieSBpbmNsdWRpbmcgdGhlCiAgIEZPUkNFUkVO RVdfTk9OQ0VfQ0FQQUJMRSg8VEJEPikgREhDUCBvcHRpb24gKFNlY3Rpb24gMy4xLjEpIGluIGFs bAogICBESENQIERpc2NvdmVyIGFuZCBSZXF1ZXN0IG1lc3NhZ2VzLiAgREhDUCBzZXJ2ZXJzIHRo YXQgc3VwcG9ydAogICBGb3JjZXJlbmV3IG5vbmNlIFByb3RvY29sIGF1dGhlbnRpY2F0aW9uIE1V U1QgaW5jbHVkZSB0aGUKICAgRk9SQ0VSRU5FV19OT05DRV9DQVBBQkxFKDxUQkQ+KSBESENQIG9w dGlvbiAoU2VjdGlvbiAzLjEuMSkgaW4gYWxsCiAgIERIQ1AgT2ZmZXJzLCBhbGxvd2luZyB0aGUg Y2xpZW50IHRvIHVzZSB0aGlzIGNhcGFiaWxpdHkgaW4gc2VsZWN0aW5nCiAgIERIQ1Agc2VydmVy cyBzaG91bGQgbXVsdGlwbGUgT2ZmZXJzIGFycml2ZS4KCiAgIFRoZSBjbGllbnQgTVVTVCB2YWxp ZGF0ZSB0aGUgREhDUCBBY2sgbWVzc2FnZSBjb250YWlucyBhIEZvcmNlcmVuZXcKICAgTm9uY2Ug aW4gYSBESENQIGF1dGhlbnRpY2F0aW9uIG9wdGlvbi4gIElmIHRoZSBzZXJ2ZXIgaGFzIGluZGlj YXRlZAogICBjYXBhYmlsaXR5IGZvciBGb3JjZXJlbmV3IE5vbmNlIFByb3RvY29sIGF1dGhlbnRp Y2F0aW9uIGluIHRoZSBESENQCiAgIE9mZmVyIGFuZCBhIHN1YnNlcXVlbnQgQWNrIG9taXRzIGEg dmFsaWQgREhDUCBhdXRoZW50aWNhdGlvbiBvcHRpb24KICAgZm9yIHRoZSBGb3JjZXJlbmV3IE5v bmNlIFByb3RvY29sLCB0aGUgY2xpZW50IE1VU1Qgc2VuZCBhIERIQ1AKICAgRGVjbGluZSBtZXNz YWdlIGFuZCByZXR1cm4gdG8gdGhlIERIQ1AgSW5pdCBzdGF0ZS4KCiAgIFRoZSBjbGllbnQgTVVT VCByZWNvcmQgdGhlIEZvcmNlcmVuZXcgTm9uY2UgZnJvbSBhbnkgdmFsaWQgQUNLIGl0CiAgIHJl Y2VpdmVzLCBpZiB0aGUgQUNLIGNvbnRhaW5zIG9uZS4KCgoKCk1pbGVzLCBldCBhbC4gICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAxMywgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBGb3JjZXJlbmV3IE5vbmNlICAgICAgICAgICAgICAg RmVicnVhcnkgMjAxMgoKCiAgIFRvIGF1dGhlbnRpY2F0ZSBhIEZvcmNlcmVuZXcgbWVzc2FnZSwg dGhlIGNsaWVudCBjb21wdXRlcyBhbiBITUFDLU1ENQogICBvdmVyIHRoZSBESENQIEZvcmNlcmVu ZXcgbWVzc2FnZSwgdXNpbmcgdGhlIEZvcmNlcmVuZXcgTm9uY2UgcmVjZWl2ZWQKICAgZnJvbSB0 aGUgc2VydmVyLiAgSWYgdGhpcyBjb21wdXRlZCBITUFDLU1ENSBtYXRjaGVzIHRoZSB2YWx1ZSBp biB0aGUKICAgQXV0aGVudGljYXRpb24gb3B0aW9uLCB0aGUgY2xpZW50IGFjY2VwdHMgdGhlIEZv cmNlcmVuZXcgbWVzc2FnZS4KCgo0LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgQ29tbWVudHMgYXJl IHNvbGljaXRlZCBhbmQgc2hvdWxkIGJlIGFkZHJlc3NlZCB0byB0aGUgREhDIFdHIG1haWxpbmcK ICAgbGlzdCAoZGhjd2dAaWV0Zi5vcmcpIGFuZC9vciB0aGUgYXV0aG9ycy4gIFRoaXMgY29udHJp YnV0aW9uIGlzIGJhc2VkCiAgIG9uIHdvcmsgYnkgVml0YWxpIFZpbm9rb3VyLiAgTWFqb3Igc2Vj dGlvbnMgb2YgdGhpcyBkcmFmdCB1c2UKICAgbW9kaWZpZWQgdGV4dCBmcm9tIFtSRkMzMzE1XS4g IFRoZSBhdXRob3JzIHdpc2ggdG8gdGhhbmsgVGVkIExlbW9uCiAgIGFuZCBCZXJuaWUgVm9seiBm b3IgdGhlaXIgc3VwcG9ydC4KCgo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1 bWVudCByZXF1ZXN0cyBJQU5BIHRvIGFzc2lnbiB0aGUgZm9sbG93aW5nIG5ldyBESENQdjQgb3B0 aW9uCiAgIGNvZGUgZnJvbSB0aGUgcmVnaXN0cnkgIkJPT1RQIFZlbmRvciBFeHRlbnNpb25zIGFu ZCBESENQIE9wdGlvbnMiCiAgIG1haW50YWluZWQgYXQgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9ib290cC1kaGNwLXBhcmFtZXRlcnM6CgogICBhbiBvcHRpb24gY29kZSBvZiBUQkQg Zm9yIEZPUkNFUkVORVdfTk9OQ0VfQ0FQQUJBTEUKCgo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMKCiAgIEFzIGluIHNvbWUgbmV0d29yayBlbnZpcm9ubWVudHMgRk9SQ0VSRU5FVyBjYW4gYmUg dXNlZCB0byBzbm9vcCBhbmQKICAgc3Bvb2YgdHJhZmZpYywgdGhlIEZPUkNFUkVORVcgbWVzc2Fn ZSBNVVNUIGJlIGF1dGhlbnRpY2F0ZWQgdXNpbmcgdGhlCiAgIHByb2NlZHVyZXMgYXMgZGVzY3Jp YmVkIGluIFtSRkMzMTE4XSBvciB0aGlzIHByb3Bvc2FsLiAgSW4gdGhpcwogICBwcm9wb3NhbCBh bnkgcGFydHkgYWJsZSB0byBpbnRlcmNlcHQgdGhlIG5vbmNlIGV4Y2hhbmdlIGNvdWxkCiAgIGlt cGVyc29uYXRlIGEgc2VydmVyIGFuZCB0aHVzIG9mZmVycyBubyBwcm90ZWN0aW9uIGZyb20gbWFu LWluLXRoZS0KICAgbWlkZGxlIGF0dGFja3MuICBGT1JDRVJFTkVXIG1lc3NhZ2VzIGZhaWxpbmcg dGhlIGF1dGhlbnRpY2F0aW9uCiAgIHNob3VsZCBiZSBzaWxlbnRseSBkaXNjYXJkZWQgYnkgdGhl IGNsaWVudC4KCjYuMS4gIFByb3RvY29sIHZ1bG5lcmFiaWxpdGllcwoKICAgVGhlIG1lY2hhbmlz bSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBpcyB2dWxuZXJhYmxlIHRvIGEgZGVuaWFsIG9m CiAgIHNlcnZpY2UgYXR0YWNrIHRocm91Z2ggZmxvb2RpbmcgYSBjbGllbnQgd2l0aCBib2d1cyBG T1JDRVJFTkVXCiAgIG1lc3NhZ2VzLiAgVGhlIGNhbGN1bGF0aW9ucyBpbnZvbHZlZCBpbiBhdXRo ZW50aWNhdGluZyB0aGUgYm9ndXMKICAgRk9SRUNFUkVORVcgbWVzc2FnZXMgbWF5IG92ZXJ3aGVs bSB0aGUgZGV2aWNlIG9uIHdoaWNoIHRoZSBjbGllbnQgaXMKICAgcnVubmluZy4KCiAgIFRoZSBt ZWNoYW5pc20gZGVzY3JpYmVkIHByb3ZpZGVzIHByb3RlY3Rpb24gYWdhaW5zdCB0aGUgdXNlIG9m IGEKICAgRk9SQ0VSRU5FVyBtZXNzYWdlIGJ5IGEgbWFsaWNpb3VzIERIQ1Agc2VydmVyIHRvIG1v dW50IGEgZGVuaWFsIG9mCiAgIHNlcnZpY2Ugb3IgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrIG9u IGEgY2xpZW50LiAgVGhpcyBwcm90b2NvbCBjYW4KICAgYmUgY29tcHJvbWlzZWQgYnkgYW4gYXR0 YWNrZXIgdGhhdCBjYW4gaW50ZXJjZXB0IHRoZSBpbml0aWFsIG1lc3NhZ2UKICAgaW4gd2hpY2gg dGhlIERIQ1Agc2VydmVyIHNlbmRzIHRoZSBub25jZSB0byB0aGUgY2xpZW50LgoKCgoKTWlsZXMs IGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEzLCAyMDEyICAgICAgICAgICAgICAg W1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIEZvcmNlcmVuZXcgTm9uY2Ug ICAgICAgICAgICAgICBGZWJydWFyeSAyMDEyCgoKNy4gIFJlZmVyZW5jZXMKCjcuMS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMzExOF0gIERyb21zLCBS LiBhbmQgVy4gQXJiYXVnaCwgIkF1dGhlbnRpY2F0aW9uIGZvciBESENQCiAgICAgICAgICAgICAg TWVzc2FnZXMiLCBSRkMgMzExOCwgSnVuZSAyMDAxLgoKICAgW1JGQzMyMDNdICBUJ0pvZW5zLCBZ LiwgSHVibGV0LCBDLiwgYW5kIFAuIERlIFNjaHJpanZlciwgIkRIQ1AKICAgICAgICAgICAgICBy ZWNvbmZpZ3VyZSBleHRlbnNpb24iLCBSRkMgMzIwMywgRGVjZW1iZXIgMjAwMS4KCiAgIFtSRkMz MzE1XSAgRHJvbXMsIFIuLCBCb3VuZCwgSi4sIFZvbHosIEIuLCBMZW1vbiwgVC4sIFBlcmtpbnMs IEMuLAogICAgICAgICAgICAgIGFuZCBNLiBDYXJuZXksICJEeW5hbWljIEhvc3QgQ29uZmlndXJh dGlvbiBQcm90b2NvbCBmb3IKICAgICAgICAgICAgICBJUHY2IChESENQdjYpIiwgUkZDIDMzMTUs IEp1bHkgMjAwMy4KCjcuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtUUi0xMDFpMl0K ICAgICAgICAgICAgICBBbnNjaHV0eiwgVC4sICJNaWdyYXRpb24gdG8gRXRoZXJuZXQtQmFzZWQg QnJvYWRiYW5kCiAgICAgICAgICAgICAgQWdncmVnYXRpb24gQnJvYWRiYW5kIEZvcnVtIFRSLTEw MSBJc3N1ZSAyIiwgSnVseSAyMDExLgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgRGF2aWQgTWls ZXMKICAgR29vZ2xlCgoKICAgUGhvbmU6CiAgIEZheDoKICAgRW1haWw6CiAgIFVSSToKCgogICBX b2pjaWVjaCBEZWMKICAgQ2lzY28gU3lzdGVtcwogICBIYWFybGVyYmVyZ3BhcmsgSGFhcmxlcmJl cmd3ZWcgMTMtMTkKICAgQW1zdGVyZGFtLCBOT09SRC1IT0xMQU5EICAxMTAxIENICiAgIE5ldGhl cmxhbmRzCgogICBQaG9uZToKICAgRmF4OgogICBFbWFpbDogd2RlY0BjaXNjby5jb20KICAgVVJJ OgoKCgoKCk1pbGVzLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxMywgMjAxMiAg ICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBGb3Jj ZXJlbmV3IE5vbmNlICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMgoKCiAgIEphbWVzIEJyaXN0 b3cKICAgU3dpc3Njb20gU2Nod2VpeiBBRwogICBaZW50d2VnIDkKICAgQmVybiwgMzA1MCwKICAg U3dpdHplcmxhbmQKCiAgIFBob25lOgogICBGYXg6CiAgIEVtYWlsOiBKYW1lcy5CcmlzdG93QHN3 aXNzY29tLmNvbQogICBVUkk6CgoKICAgUm9iZXJ0YSBNYWdsaW9uZQogICBUZWxlY29tIEl0YWxp YQogICBWaWEgUmVpc3MgUm9tb2xpIDI3NAogICBUb3Jpbm8gIDEwMTQ4CiAgIEl0YWx5CgogICBQ aG9uZToKICAgRW1haWw6IHJvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdAoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTWlsZXMsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg QXVndXN0IDEzLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwK --_002_282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1GRFMBX704BA02_-- From wdec@cisco.com Fri Feb 10 06:12:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5621F84AA for ; Fri, 10 Feb 2012 06:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.025 X-Spam-Level: X-Spam-Status: No, score=-110.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW92GtWAvKT7 for ; Fri, 10 Feb 2012 06:12:43 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 71AA121F84FD for ; Fri, 10 Feb 2012 06:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=8246; q=dns/txt; s=iport; t=1328883158; x=1330092758; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Y30P5fv+nq8AtUB86wYvWLC4ScjpoV79OKBH48ErroM=; b=Ptw2UL8Tl58Zeub4iFxC4gXtgep7NerMDYycyvK1gw1qUpdGMxgT98kc Is5ij23xfjonDzSAJ+rjAW4Xo20l5LMELgxoUnO1jbEOgXFmWNFuEoUGW 6i1bCyzm9cFJz/wcxEczioGdlxfV7h7dqLxrAsPadCQhrjqOzvULtk5RN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHUlNU+Q/khN/2dsb2JhbABEr1yBB4FyAQEBAwESASkBPAUHBgEIEQQBAQEnTQkIAQEEAQ0FIodaml4BnmWLPwQEFgMGAwMCBQQBBj0BDQEKiAoEiBaNGpJl X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="65858951" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Feb 2012 14:12:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1AECbNr004830; Fri, 10 Feb 2012 14:12:37 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 15:12:36 +0100 Received: from 10.61.98.219 ([10.61.98.219]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Feb 2012 14:12:36 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 10 Feb 2012 15:12:31 +0100 From: Wojciech Dec To: Maglione Roberta , "'Matthew Ryan'" , "'Menachem Dodge'" Message-ID: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt Thread-Index: AcziwejofOmKtphZTxe8UzzTmzMXPwFJwIMAAAVG+yQ= In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1@GRFMBX704BA020.griffon.local> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 10 Feb 2012 14:12:36.0703 (UTC) FILETIME=[0A46E6F0:01CCE7FE] X-Mailman-Approved-At: Fri, 10 Feb 2012 06:51:23 -0800 Cc: dhc WG , "'James.Bristow@swisscom.com'" , 'Ted Lemon' , Ullio Mario Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:12:46 -0000 Hello Roberta, Looks good to me. Regards, Woj. On 10/02/2012 12:52, "Maglione Roberta" wrote: > Hello Matt, Menachem and All, > I made some changes to the document in order to address your comments. > Please see answers inline [RM]. > I attached a new version of the document I haven't posted it yet, please = let > me know if the new version covers your points and if you have additional > comments. > Thanks, > Best regards, > Roberta >=20 > -----Original Message----- > From: Matthew Ryan [mailto:Matt.Ryan@nominum.com] > Sent: venerd=EC 3 febbraio 2012 23.19 > To: Maglione Roberta > Cc: dhc WG; 'david.miles@alcatel-lucent.com'; Wojciech Dec (wdec); > 'James.Bristow@swisscom.com'; Ullio Mario; 'Ted Lemon' > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt >=20 >=20 > On Feb 3, 2012, at 07:26 , Maglione Roberta wrote: >>=20 >> Section 3.1.4 states: >> The client will receive a Forcerenew Nonce from the server in the >> initial DHCP Ack message from the server. >> which could be construed to imply that the nonce is only chosen >> during the initial 4-way handshake. >>=20 >> However, the protocol interaction diagram in section 3.1.1 >> seems to indicate that, during a renew, the server may/must >> (unclear) create a new nonce. >>=20 >> [RM] The idea is that the nonce is selected and sent by the server in th= e >> initial DHCP exchange, then later on when the DHCP server needs to send = a >> Forcerenew message it includes the nonce previously created in the messa= ge >> sent to the client. In this way the client can verify that the Forcerene= w >> message comes from a trusted DHCP server. Please let me know if you thin= k >> this behavior should better explained in the document >=20 > I believe it's clear that a nonce should be returned in each > ACK message. However, I think the document needs to be clarified > as to which REQUEST messages (init-reboot, select, renew, rebind) > or conditions should cause a server to generate a /new/ nonce. > Specifically, when the server MUST generate a nonce, and when > it MAY generate (or change) the nonce. >=20 > [RM] I clarified this by adding the following sentences: >=20 > The server SHOULD NOT include the nonce in an ACK when responding to > a renew unless a nonce was generated. This minimizes the number of > times the nonce is sent over the wire. (as per your proposal) >=20 > If the server to which the DHCP Request message was sent at time T1 > has not responded, the client enters the REBINDING state and attempts > to contact any server. The new Server receiving the DHCP message > MUST generate a new nonce. >=20 >=20 >=20 > Does the server ONLY generate a nonce the first time it sees the > client? Is the server ONLY allowed to generate a nonce (even if > it has no previous recorded) in response to a select, or can it do > so for rebind and init-reboot as well? Can the server (perhaps on > a timer or by admin instruction) choose to generate a new nonce for > a client in response to a renew? >=20 > [RM] In case of rebind the Server MUST generates a new nonce >=20 > In addition, it should be clarified when a client should update > its record of the nonce. The draft currently states this is done > in response to the "initial DHCP Ack message". Depending on the > answers to the server behavior question above, this may not be > sufficient. If the server is allowed to generate a new nonce > on rebind (which may need to happen in environments that have > multiple DHCP servers that don't do failover), the client should > probably update itself then as well. >=20 > Also, what should happen in the case where the client indicates > in a renew that it is capable, and the server is capable, but the > server has no recollection of a nonce for the client? This condition > can happen if the server support is enabled and the client already > possesses an active lease from the server. >=20 > [RM] Good points, I think the 3 points you propose below take care of the= se > cases. >=20 > I would probably recommend at the following: > 1) The client MUST record the nonce from any valid ACK it receives, > if the ACK contains one. > 2) If a capable server receives a DISCOVER or REQUEST (any type) > that indicates the client is capable, and the server has no > previous nonce recorded, it MUST generate a nonce and include > it in the ACK. > 3) The server SHOULD NOT include the nonce in an ACK when responding > to a renew unless a nonce was generated. This minimizes the > number of times the nonce is sent over the wire. >=20 > [RM] I added the 3 points you suggested >=20 > That leaves open the question of whether a server MAY change > an existing nonce, but that becomes a non-issue due to (1). >=20 >=20 >=20 >=20 > My reading of the draft indicated that the server would send > a nonce of type 0 in an OFFER (type 0 is not covered in section > 3.1.2) - but there was no indication of what the value should be. >=20 > I think, that, in the OFFER message, it is sufficient for the > server to simply send the FORCERENEW_NONCE_CAPABLE, and omit > the authentication option. So, I would change section 3.1.4 > from: > The client MUST indicate Forcerenew nonce Capability by including the > FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > DHCP Discover and Request messages. DHCP servers that support > Forcerenew nonce Protocol authentication MUST include the DHCP > Forcerenew Nonce protocol authentication option in DHCP Offers with > type set to zero(0), allowing the client to use this capability in > selecting DHCP servers should multiple Offers arrive. >=20 > A DHCP server has indicates its support through the inclusion of the > FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client > MUST validate the DHCP Ack message contains a Forcerenew Nonce in a > DHCP authentication option. If the server has indicated capability > for Forcerenew Nonce Protocol authentication in the DHCP Offer and a > subsequent Ack omits a valid DHCP authentication option for the > Forcerenew Nonce Protocol, the client MUST send a DHCP Decline > message and return to the DHCP Init state. > to (changed lines marked, no rewrapping done for clarity): > The client MUST indicate Forcerenew nonce Capability by including the > FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > DHCP Discover and Request messages. DHCP servers that support > * Forcerenew nonce Protocol authentication MUST include the > * FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > * DHCP Offers, allowing the client to use this capability in > selecting DHCP servers should multiple Offers arrive. >=20 > * The client > MUST validate the DHCP Ack message contains a Forcerenew Nonce in a > DHCP authentication option. If the server has indicated capability > for Forcerenew Nonce Protocol authentication in the DHCP Offer and a > subsequent Ack omits a valid DHCP authentication option for the > Forcerenew Nonce Protocol, the client MUST send a DHCP Decline > message and return to the DHCP Init state. >=20 > [RM] I modified the text as per your proposal >=20 >=20 > - Matt >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. >=20 From Matt.Ryan@nominum.com Mon Feb 13 10:57:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0ABA21F8496 for ; Mon, 13 Feb 2012 10:57: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLeS6e6S1d0X for ; Mon, 13 Feb 2012 10:57:36 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B8C3721F853A for ; Mon, 13 Feb 2012 10:57:21 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTzldDclJxCmt3ettSVzVnrdsEUDNMbNs@postini.com; Mon, 13 Feb 2012 10:57:36 PST Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 1ECF11B82C2; Mon, 13 Feb 2012 10:57:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Matthew Ryan In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1@GRFMBX704BA020.griffon.local> Date: Mon, 13 Feb 2012 10:57:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111221164220.13693.80809.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> <82B4F550-9202-4EA2-87ED-93BF78C5D0C5@nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1@GRFMBX704BA020.griffon.local> To: Maglione Roberta X-Mailer: Apple Mail (2.1084) Cc: "Wojciech Dec \(wdec\)" , "'James.Bristow@swisscom.com'" , Ullio Mario , 'Ted Lemon' , dhc WG , 'Menachem Dodge' Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:57:37 -0000 Minor item: The 'imbedded' typo in section 3.1.3 is still present. While reviewing this, I noticed something I had missed before. Section 3.1.4 indicates: If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. The client MUST record the Forcerenew Nonce from any valid ACK it receives, if the ACK contains one. There are two problems here. First, the two paragraphs are = contradictory with respect to the client's behavior when receiving an ACK without an auth option. One says it is an error, and the other implies that it's possible and valid. Second, the DECLINE message is used by clients to indicate that an address is already in use, and servers respond by marking the address as unavailable. As such, I don't believe it's safe behavior to require clients to respond to an unauthenticated ACK with a DHCPDECLINE, especially given the contradiction above. I reviewed RFC-3118; it dictates that that a client "SHOULD be = configured by default to decline unauthenticated messages." Given that it refers to other DHCP messages in all-caps form DHCP, I read that to mean 'discard', and not "respond with a DHCPDECLINE". This is = in-line with RFC-3315 (DHCPv6) behavior. Perhaps someone who is more familiar with the intent of RFC-3118 could confirm or deny that interpretation? Assuming my read of RFC-3118 is correct, I would suggest the following replacement text which should resolve both of those issues: If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP OFFER and the subsequent ACK received by the client while in the SELECTING state omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST discard the message and return to the INIT state. The client MUST record the Forcerenew Nonce from any valid ACK it receives, if the ACK contains one. - Matt On Feb 10, 2012, at 03:52 , Maglione Roberta wrote: > Hello Matt, Menachem and All, > I made some changes to the document in order to address your comments. > Please see answers inline [RM]. > I attached a new version of the document I haven't posted it yet, = please let me know if the new version covers your points and if you have = additional comments. > Thanks, > Best regards, > Roberta >=20 > -----Original Message----- > From: Matthew Ryan [mailto:Matt.Ryan@nominum.com] > Sent: venerd=EC 3 febbraio 2012 23.19 > To: Maglione Roberta > Cc: dhc WG; 'david.miles@alcatel-lucent.com'; Wojciech Dec (wdec); = 'James.Bristow@swisscom.com'; Ullio Mario; 'Ted Lemon' > Subject: Re: [dhcwg] I-D Action: = draft-ietf-dhc-forcerenew-nonce-03.txt >=20 >=20 > On Feb 3, 2012, at 07:26 , Maglione Roberta wrote: >>=20 >> Section 3.1.4 states: >> The client will receive a Forcerenew Nonce from the server in the >> initial DHCP Ack message from the server. >> which could be construed to imply that the nonce is only chosen >> during the initial 4-way handshake. >>=20 >> However, the protocol interaction diagram in section 3.1.1 >> seems to indicate that, during a renew, the server may/must >> (unclear) create a new nonce. >>=20 >> [RM] The idea is that the nonce is selected and sent by the server in = the initial DHCP exchange, then later on when the DHCP server needs to = send a Forcerenew message it includes the nonce previously created in = the message sent to the client. In this way the client can verify that = the Forcerenew message comes from a trusted DHCP server. Please let me = know if you think this behavior should better explained in the document >=20 > I believe it's clear that a nonce should be returned in each > ACK message. However, I think the document needs to be clarified > as to which REQUEST messages (init-reboot, select, renew, rebind) > or conditions should cause a server to generate a /new/ nonce. > Specifically, when the server MUST generate a nonce, and when > it MAY generate (or change) the nonce. >=20 > [RM] I clarified this by adding the following sentences: >=20 > The server SHOULD NOT include the nonce in an ACK when responding to > a renew unless a nonce was generated. This minimizes the number of > times the nonce is sent over the wire. (as per your proposal) >=20 > If the server to which the DHCP Request message was sent at time T1 > has not responded, the client enters the REBINDING state and = attempts > to contact any server. The new Server receiving the DHCP message > MUST generate a new nonce. >=20 >=20 >=20 > Does the server ONLY generate a nonce the first time it sees the > client? Is the server ONLY allowed to generate a nonce (even if > it has no previous recorded) in response to a select, or can it do > so for rebind and init-reboot as well? Can the server (perhaps on > a timer or by admin instruction) choose to generate a new nonce for > a client in response to a renew? >=20 > [RM] In case of rebind the Server MUST generates a new nonce >=20 > In addition, it should be clarified when a client should update > its record of the nonce. The draft currently states this is done > in response to the "initial DHCP Ack message". Depending on the > answers to the server behavior question above, this may not be > sufficient. If the server is allowed to generate a new nonce > on rebind (which may need to happen in environments that have > multiple DHCP servers that don't do failover), the client should > probably update itself then as well. >=20 > Also, what should happen in the case where the client indicates > in a renew that it is capable, and the server is capable, but the > server has no recollection of a nonce for the client? This condition > can happen if the server support is enabled and the client already > possesses an active lease from the server. >=20 > [RM] Good points, I think the 3 points you propose below take care of = these cases. >=20 > I would probably recommend at the following: > 1) The client MUST record the nonce from any valid ACK it receives, > if the ACK contains one. > 2) If a capable server receives a DISCOVER or REQUEST (any type) > that indicates the client is capable, and the server has no > previous nonce recorded, it MUST generate a nonce and include > it in the ACK. > 3) The server SHOULD NOT include the nonce in an ACK when responding > to a renew unless a nonce was generated. This minimizes the > number of times the nonce is sent over the wire. >=20 > [RM] I added the 3 points you suggested >=20 > That leaves open the question of whether a server MAY change > an existing nonce, but that becomes a non-issue due to (1). >=20 >=20 >=20 >=20 > My reading of the draft indicated that the server would send > a nonce of type 0 in an OFFER (type 0 is not covered in section > 3.1.2) - but there was no indication of what the value should be. >=20 > I think, that, in the OFFER message, it is sufficient for the > server to simply send the FORCERENEW_NONCE_CAPABLE, and omit > the authentication option. So, I would change section 3.1.4 > from: > The client MUST indicate Forcerenew nonce Capability by including = the > FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > DHCP Discover and Request messages. DHCP servers that support > Forcerenew nonce Protocol authentication MUST include the DHCP > Forcerenew Nonce protocol authentication option in DHCP Offers with > type set to zero(0), allowing the client to use this capability in > selecting DHCP servers should multiple Offers arrive. >=20 > A DHCP server has indicates its support through the inclusion of the > FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The = client > MUST validate the DHCP Ack message contains a Forcerenew Nonce in a > DHCP authentication option. If the server has indicated capability > for Forcerenew Nonce Protocol authentication in the DHCP Offer and a > subsequent Ack omits a valid DHCP authentication option for the > Forcerenew Nonce Protocol, the client MUST send a DHCP Decline > message and return to the DHCP Init state. > to (changed lines marked, no rewrapping done for clarity): > The client MUST indicate Forcerenew nonce Capability by including = the > FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > DHCP Discover and Request messages. DHCP servers that support > * Forcerenew nonce Protocol authentication MUST include the > * FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > * DHCP Offers, allowing the client to use this capability in > selecting DHCP servers should multiple Offers arrive. >=20 > * The client > MUST validate the DHCP Ack message contains a Forcerenew Nonce in a > DHCP authentication option. If the server has indicated capability > for Forcerenew Nonce Protocol authentication in the DHCP Offer and a > subsequent Ack omits a valid DHCP authentication option for the > Forcerenew Nonce Protocol, the client MUST send a DHCP Decline > message and return to the DHCP Init state. >=20 > [RM] I modified the text as per your proposal >=20 >=20 > - Matt >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 > From touch@isi.edu Mon Feb 13 14:00:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AFF21E8024; Mon, 13 Feb 2012 14:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.97 X-Spam-Level: X-Spam-Status: No, score=-102.97 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oabNdD4Da4YD; Mon, 13 Feb 2012 14:00:34 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1997521E801E; Mon, 13 Feb 2012 14:00:31 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1DM0GPO008149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Feb 2012 14:00:16 -0800 (PST) Message-ID: <4F3987F0.5050000@isi.edu> Date: Mon, 13 Feb 2012 14:00:16 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, "tsv-ads@tools.ietf.org" , IETF discussion list , dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 13 Feb 2012 15:51:25 -0800 Cc: TSV Dir Subject: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 22:00:35 -0000 Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This request was received Feb. 2, 2012. This document describes an extension to DHCPv4 for the bulk query and transfer of current lease status over TCP. The following transport issues were noted, and are significant: UPDATES- The document updates DHCP with support for TCP, and as such this document seems like it should UPDATE RFC2131 PORT USE- Although DHCPv4 has an assigned TCP port, this document should clearly indicate that there is no other specified use of that port other than the bulk lease query described in this document It should further explain why no other existing DHCP exchanges are not valid on the TCP port. CONNECTION MANAGEMENT- The document describes the use of TCP connections for bulk transfer, but needs to be more specific about which side (relay client or server) closes the connection, under what circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793) sec 7.3 indicates some conditions for terminating connections; this section should indicate which side performs this, and by what method (CLOSE, ABORT) this sec also allows connections to stay open after all pending transactions are complete (MAY); the rationale for this should be given, or the connection MUST be closed. the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is particularly problematic on this issue because it discusses aborting a request using in-band data, which may not be available if the connection is closed using ABORT. the state of other pending connection shsould be discussed too. TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this intended to supercede any TCP timeout? or is it intended to be the min of the TCP timeout and the specified one? This section should more carefully explain behavior when a connection is dropped and the reason - e.g., timeout, abort, close. INTERLEAVING- sec 7.7 says that the server MUST interleave replies; there doesn't seem a valid reason for this requirement. clearly the receiver MUST tolerate interleaved replies. having the server interleave replies is relevant only if each request/reply has its own timeout -- which should be overridden if there is another response in progress anyway. This issue should be more clearly explained and motivated. There were some other issues noted in this document. These comments appear below, and although not focused on transport issues, they represent significant issues that IMO should be addressed as well. NOTE - regarding some terminology issues, I did not survey current DHCP RFCs for consistency, but IMO these terms should be corrected even if they are then inconsistent with existing specs. Joe ----------- Major non-transport issues: - In many places the doc allows inaction to substitute for either positive or negative confirmation. IMO, this invites implementation errors, and should be avoided. E.g., status return codes, data source option missing, query-for-all-configured-IPs, etc. - the data source option reserved codes need more detailed specification. if these are intended for future use, then they MUST be ignored by the receiver (at least). if they are to mean anything at all, at least one bit (typically all of them) MUST be set to zero by the transmitter for implementations that do not support any of the component fields. further, the length of this option MUST be 1 - The protocol supports bulk transfer that is not data driven. This could represent a security vulnerability by exposing information that may not be on the data path (and thus already accessible) to a relay agent. This should be discussed in the security considerations section. - Integer quantities should be referred to as "unsigned 32-bit integers" throughout. - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a VPN is not just private addressing. - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used throughout without context. Any time SHOULD is used instead of MUST (or SHOULD NOT rather than MUST NOT), it is useful to explain a viable exception. If no such exception exists, the rationale for selecting SHOULD over MUST should be included. - It would be useful to explain why STATUS-CODE strings MUST NOT be null-terminated; is that a protocol violation, or are you just saying that NULLs are valid in these strings? the description should be clear that the string field describes the string length without any termination characters. - start-time-of-state is expressed as an offset from base-time; this appears to be the only time indicated as an offset rather than as an absolute. That inconsistency invites implementation errors; IMO, this should be absolute too. - option lengths: throughout, the doc refers to option lengths as being "an octet"; they are *indicated* in one octet. Some are constant (e.g., DCHP-STATE), some allow the contents of the octet to vary. Again, this is an *unsigned integer* octet. - some of the information provided (in DHCP-STATE) goes beyond that of DHCP. It would be useful to motivate the need for this information in a bulk query, and why it is not similarly available for nodes using UDP (e.g., as an extension to DHCPv4, not just to the bulk transfer command). again, absence of state information should not indicate state. State should always be expressed explicitly. these states are further meaningless without a state diagram explaining them. if such a diagram is not possible (as noted at end of sec 6.2.7), then the states are irrelevant and the option should not be included. - in sec 6.2.9 the term "not allowed" should be explained - are they reserved for future use and thus ignored? or are they "not allowed" - in which case the doc should indicate handling if they appear. - sec 7.4 states that the clock skew of zero is desired; this assumes E2E delays under 1sec. An explanation of why this is desired should be given, as well as the consequences of it not. Other non-transport issues: - The document includes definitions and references to irrelevant deployment and implementation issues, notably DSLAMs, concentrators, and access concentrators. These should not appear formally; they should be used only to usefully illustrate currently intended uses. - The doc refers to "real-time", which could imply requirements not supported. This should be replaced with "rapid". - "absolute time" *indicates* (rather than contains) the number of seconds... - "third party agent" should be explained, i.e., neither DHCP client nor DHCP server. - "downstream" and "upstream" should be defined as both away from the server *and towards the client* ("away from the server" has two directions). - sec 3 should refer to relays, and returning the entire set or individual bindings; there is no reason to explain the goals in terms of access concentrators. - sec 3.2 appears to provide contradictory advice - caching is required, but should be avoided? it would be useful to resolve this inconsistency. - sec 3.3 refers to 'fast path', but this term doesn't make sense in this context because fast-path is a forwarding issue. it would be useful to explain what you mean, and pick a different term ---- From touch@isi.edu Mon Feb 13 14:16:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1821E8012; Mon, 13 Feb 2012 14:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SeVSuJxW9t0; Mon, 13 Feb 2012 14:16:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3CA21E8044; Mon, 13 Feb 2012 14:16:31 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1DMG4GT010816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Feb 2012 14:16:04 -0800 (PST) Message-ID: <4F398BA4.3010400@isi.edu> Date: Mon, 13 Feb 2012 14:16:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, "tsv-ads@tools.ietf.org" , IETF discussion list , dhcwg@ietf.org References: <4F3987F0.5050000@isi.edu> In-Reply-To: <4F3987F0.5050000@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 13 Feb 2012 15:51:27 -0800 Cc: TSV Dir Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 22:16:32 -0000 Hi, all, One additional transport suggestion: - it would be useful to include recommended configurations for TCP connections. Given these are multi-byte request/response exchanges, Nagle should be disabled, e.g. Joe On 2/13/2012 2:00 PM, Joe Touch wrote: > Hi, all, > > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address > any issues raised. The authors should consider this review together with > any other last-call comments they receive. Please always CC > tsv-dir@ietf.org if you reply to or forward this review. > > This request was received Feb. 2, 2012. > > This document describes an extension to DHCPv4 for the bulk query and > transfer of current lease status over TCP. > > The following transport issues were noted, and are significant: > > UPDATES- The document updates DHCP with support for TCP, and as such > this document seems like it should UPDATE RFC2131 > > PORT USE- Although DHCPv4 has an assigned TCP port, this document should > clearly indicate that there is no other specified use of that port other > than the bulk lease query described in this document > > It should further explain why no other existing DHCP exchanges are not > valid on the TCP port. > > CONNECTION MANAGEMENT- The document describes the use of TCP connections > for bulk transfer, but needs to be more specific about which side (relay > client or server) closes the connection, under what circumstances, and > with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793) > > sec 7.3 indicates some conditions for terminating connections; this > section should indicate which side performs this, and by what method > (CLOSE, ABORT) > > this sec also allows connections to stay open after all pending > transactions are complete (MAY); the rationale for this should be given, > or the connection MUST be closed. > > the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is > particularly problematic on this issue because it discusses aborting a > request using in-band data, which may not be available if the connection > is closed using ABORT. the state of other pending connection shsould be > discussed too. > > TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this > intended to supercede any TCP timeout? or is it intended to be the min > of the TCP timeout and the specified one? > > This section should more carefully explain behavior when a connection is > dropped and the reason - e.g., timeout, abort, close. > > INTERLEAVING- sec 7.7 says that the server MUST interleave replies; > there doesn't seem a valid reason for this requirement. clearly the > receiver MUST tolerate interleaved replies. having the server interleave > replies is relevant only if each request/reply has its own timeout -- > which should be overridden if there is another response in progress > anyway. This issue should be more clearly explained and motivated. > > There were some other issues noted in this document. These comments > appear below, and although not focused on transport issues, they > represent significant issues that IMO should be addressed as well. > > NOTE - regarding some terminology issues, I did not survey current DHCP > RFCs for consistency, but IMO these terms should be corrected even if > they are then inconsistent with existing specs. > > Joe > > ----------- > > Major non-transport issues: > > - In many places the doc allows inaction to substitute for either > positive or negative confirmation. IMO, this invites implementation > errors, and should be avoided. E.g., status return codes, data source > option missing, query-for-all-configured-IPs, etc. > > - the data source option reserved codes need more detailed > specification. if these are intended for future use, then they MUST be > ignored by the receiver (at least). if they are to mean anything at all, > at least one bit (typically all of them) MUST be set to zero by the > transmitter for implementations that do not support any of the component > fields. > > further, the length of this option MUST be 1 > > - The protocol supports bulk transfer that is not data driven. This > could represent a security vulnerability by exposing information that > may not be on the data path (and thus already accessible) to a relay > agent. This should be discussed in the security considerations section. > > - Integer quantities should be referred to as "unsigned 32-bit integers" > throughout. > > - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a > VPN is not just private addressing. > > - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used > throughout without context. Any time SHOULD is used instead of MUST (or > SHOULD NOT rather than MUST NOT), it is useful to explain a viable > exception. If no such exception exists, the rationale for selecting > SHOULD over MUST should be included. > > - It would be useful to explain why STATUS-CODE strings MUST NOT be > null-terminated; is that a protocol violation, or are you just saying > that NULLs are valid in these strings? the description should be clear > that the string field describes the string length without any > termination characters. > > - start-time-of-state is expressed as an offset from base-time; this > appears to be the only time indicated as an offset rather than as an > absolute. That inconsistency invites implementation errors; IMO, this > should be absolute too. > > - option lengths: throughout, the doc refers to option lengths as being > "an octet"; they are *indicated* in one octet. Some are constant (e.g., > DCHP-STATE), some allow the contents of the octet to vary. Again, this > is an *unsigned integer* octet. > > - some of the information provided (in DHCP-STATE) goes beyond that of > DHCP. It would be useful to motivate the need for this information in a > bulk query, and why it is not similarly available for nodes using UDP > (e.g., as an extension to DHCPv4, not just to the bulk transfer > command). again, absence of state information should not indicate state. > State should always be expressed explicitly. these states are further > meaningless without a state diagram explaining them. if such a diagram > is not possible (as noted at end of sec 6.2.7), then the states are > irrelevant and the option should not be included. > > - in sec 6.2.9 the term "not allowed" should be explained - are they > reserved for future use and thus ignored? or are they "not allowed" - in > which case the doc should indicate handling if they appear. > > - sec 7.4 states that the clock skew of zero is desired; this assumes > E2E delays under 1sec. An explanation of why this is desired should be > given, as well as the consequences of it not. > > Other non-transport issues: > > - The document includes definitions and references to irrelevant > deployment and implementation issues, notably DSLAMs, concentrators, and > access concentrators. These should not appear formally; they should be > used only to usefully illustrate currently intended uses. > > - The doc refers to "real-time", which could imply requirements not > supported. This should be replaced with "rapid". > > - "absolute time" *indicates* (rather than contains) the number of > seconds... > > - "third party agent" should be explained, i.e., neither DHCP client nor > DHCP server. > > - "downstream" and "upstream" should be defined as both away from the > server *and towards the client* ("away from the server" has two > directions). > > - sec 3 should refer to relays, and returning the entire set or > individual bindings; there is no reason to explain the goals in terms of > access concentrators. > > - sec 3.2 appears to provide contradictory advice - caching is required, > but should be avoided? it would be useful to resolve this inconsistency. > > - sec 3.3 refers to 'fast path', but this term doesn't make sense in > this context because fast-path is a forwarding issue. it would be useful > to explain what you mean, and pick a different term > > ---- > > > From roberta.maglione@telecomitalia.it Tue Feb 14 02:00:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B233A21F879A for ; Tue, 14 Feb 2012 02:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.386 X-Spam-Level: X-Spam-Status: No, score=0.386 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZy9pa8DfESD for ; Tue, 14 Feb 2012 02:00:22 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3F99F21F8743 for ; Tue, 14 Feb 2012 02:00:21 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 14 Feb 2012 11:00:19 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 14 Feb 2012 11:00:18 +0100 From: Maglione Roberta To: 'Matthew Ryan' Date: Tue, 14 Feb 2012 11:00:18 +0100 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt Thread-Index: AczqgVrE3Pg+2JjgR+OjtPI6EAi2EAAfhHYw Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FC4@GRFMBX704BA020.griffon.local> References: <20111221164220.13693.80809.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467F7E@GRFMBX704BA020.griffon.local> <82B4F550-9202-4EA2-87ED-93BF78C5D0C5@nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB1@GRFMBX704BA020.griffon.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Wojciech Dec \(wdec\)" , "'James.Bristow@swisscom.com'" , 'Ted Lemon' , dhc WG , 'Menachem Dodge' Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 10:00:23 -0000 Please see answers inline. Thanks, Roberta -----Original Message----- From: Matthew Ryan [mailto:Matt.Ryan@nominum.com] Sent: luned=EC 13 febbraio 2012 19.57 To: Maglione Roberta Cc: 'Menachem Dodge'; dhc WG; Wojciech Dec (wdec); 'James.Bristow@swisscom.= com'; Ullio Mario; 'Ted Lemon'; 'Henderickx, Wim (Wim)' Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt Minor item: The 'imbedded' typo in section 3.1.3 is still present. [RM] sorry about that I'll correct the typo While reviewing this, I noticed something I had missed before. Section 3.1.4 indicates: If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP Offer and a subsequent Ack omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST send a DHCP Decline message and return to the DHCP Init state. The client MUST record the Forcerenew Nonce from any valid ACK it receives, if the ACK contains one. There are two problems here. [...] This is in-line with RFC-3315 (DHCPv6) behavior. Perhaps someone who is more familiar with the intent of RFC-3118 could confirm or deny that interpretation? Assuming my read of RFC-3118 is correct, I would suggest the following replacement text which should resolve both of those issues: If the server has indicated capability for Forcerenew Nonce Protocol authentication in the DHCP OFFER and the subsequent ACK received by the client while in the SELECTING state omits a valid DHCP authentication option for the Forcerenew Nonce Protocol, the client MUST discard the message and return to the INIT state. The client MUST record the Forcerenew Nonce from any valid ACK it receives, if the ACK contains one. [RM] ok, I modify the text based on your proposal. Roberta - Matt On Feb 10, 2012, at 03:52 , Maglione Roberta wrote: > Hello Matt, Menachem and All, > I made some changes to the document in order to address your comments. > Please see answers inline [RM]. > I attached a new version of the document I haven't posted it yet, please = let me know if the new version covers your points and if you have additiona= l comments. > Thanks, > Best regards, > Roberta > > -----Original Message----- > From: Matthew Ryan [mailto:Matt.Ryan@nominum.com] > Sent: venerd=EC 3 febbraio 2012 23.19 > To: Maglione Roberta > Cc: dhc WG; 'david.miles@alcatel-lucent.com'; Wojciech Dec (wdec); 'James= .Bristow@swisscom.com'; Ullio Mario; 'Ted Lemon' > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt > > > On Feb 3, 2012, at 07:26 , Maglione Roberta wrote: >> >> Section 3.1.4 states: >> The client will receive a Forcerenew Nonce from the server in the >> initial DHCP Ack message from the server. >> which could be construed to imply that the nonce is only chosen >> during the initial 4-way handshake. >> >> However, the protocol interaction diagram in section 3.1.1 >> seems to indicate that, during a renew, the server may/must >> (unclear) create a new nonce. >> >> [RM] The idea is that the nonce is selected and sent by the server in th= e initial DHCP exchange, then later on when the DHCP server needs to send a= Forcerenew message it includes the nonce previously created in the message= sent to the client. In this way the client can verify that the Forcerenew = message comes from a trusted DHCP server. Please let me know if you think t= his behavior should better explained in the document > > I believe it's clear that a nonce should be returned in each > ACK message. However, I think the document needs to be clarified > as to which REQUEST messages (init-reboot, select, renew, rebind) > or conditions should cause a server to generate a /new/ nonce. > Specifically, when the server MUST generate a nonce, and when > it MAY generate (or change) the nonce. > > [RM] I clarified this by adding the following sentences: > > The server SHOULD NOT include the nonce in an ACK when responding to > a renew unless a nonce was generated. This minimizes the number of > times the nonce is sent over the wire. (as per your proposal) > > If the server to which the DHCP Request message was sent at time T1 > has not responded, the client enters the REBINDING state and attempts > to contact any server. The new Server receiving the DHCP message > MUST generate a new nonce. > > > > Does the server ONLY generate a nonce the first time it sees the > client? Is the server ONLY allowed to generate a nonce (even if > it has no previous recorded) in response to a select, or can it do > so for rebind and init-reboot as well? Can the server (perhaps on > a timer or by admin instruction) choose to generate a new nonce for > a client in response to a renew? > > [RM] In case of rebind the Server MUST generates a new nonce > > In addition, it should be clarified when a client should update > its record of the nonce. The draft currently states this is done > in response to the "initial DHCP Ack message". Depending on the > answers to the server behavior question above, this may not be > sufficient. If the server is allowed to generate a new nonce > on rebind (which may need to happen in environments that have > multiple DHCP servers that don't do failover), the client should > probably update itself then as well. > > Also, what should happen in the case where the client indicates > in a renew that it is capable, and the server is capable, but the > server has no recollection of a nonce for the client? This condition > can happen if the server support is enabled and the client already > possesses an active lease from the server. > > [RM] Good points, I think the 3 points you propose below take care of the= se cases. > > I would probably recommend at the following: > 1) The client MUST record the nonce from any valid ACK it receives, > if the ACK contains one. > 2) If a capable server receives a DISCOVER or REQUEST (any type) > that indicates the client is capable, and the server has no > previous nonce recorded, it MUST generate a nonce and include > it in the ACK. > 3) The server SHOULD NOT include the nonce in an ACK when responding > to a renew unless a nonce was generated. This minimizes the > number of times the nonce is sent over the wire. > > [RM] I added the 3 points you suggested > > That leaves open the question of whether a server MAY change > an existing nonce, but that becomes a non-issue due to (1). > > > > > My reading of the draft indicated that the server would send > a nonce of type 0 in an OFFER (type 0 is not covered in section > 3.1.2) - but there was no indication of what the value should be. > > I think, that, in the OFFER message, it is sufficient for the > server to simply send the FORCERENEW_NONCE_CAPABLE, and omit > the authentication option. So, I would change section 3.1.4 > from: > The client MUST indicate Forcerenew nonce Capability by including the > FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > DHCP Discover and Request messages. DHCP servers that support > Forcerenew nonce Protocol authentication MUST include the DHCP > Forcerenew Nonce protocol authentication option in DHCP Offers with > type set to zero(0), allowing the client to use this capability in > selecting DHCP servers should multiple Offers arrive. > > A DHCP server has indicates its support through the inclusion of the > FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client > MUST validate the DHCP Ack message contains a Forcerenew Nonce in a > DHCP authentication option. If the server has indicated capability > for Forcerenew Nonce Protocol authentication in the DHCP Offer and a > subsequent Ack omits a valid DHCP authentication option for the > Forcerenew Nonce Protocol, the client MUST send a DHCP Decline > message and return to the DHCP Init state. > to (changed lines marked, no rewrapping done for clarity): > The client MUST indicate Forcerenew nonce Capability by including the > FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > DHCP Discover and Request messages. DHCP servers that support > * Forcerenew nonce Protocol authentication MUST include the > * FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all > * DHCP Offers, allowing the client to use this capability in > selecting DHCP servers should multiple Offers arrive. > > * The client > MUST validate the DHCP Ack message contains a Forcerenew Nonce in a > DHCP authentication option. If the server has indicated capability > for Forcerenew Nonce Protocol authentication in the DHCP Offer and a > subsequent Ack omits a valid DHCP authentication option for the > Forcerenew Nonce Protocol, the client MUST send a DHCP Decline > message and return to the DHCP Init state. > > [RM] I modified the text as per your proposal > > > - Matt > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle p= ersone indicate. La diffusione, copia o qualsiasi altra azione derivante da= lla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di d= arne immediata comunicazione al mittente e di provvedere alla sua distruzio= ne, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d information intended for the addressee(s) only. Dissemination, copying, p= rinting or use by anybody else is unauthorised. If you are not the intended= recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks. > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From internet-drafts@ietf.org Tue Feb 14 02:40:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B479721F87B8; Tue, 14 Feb 2012 02:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkLNEAIOcmx7; Tue, 14 Feb 2012 02:40:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4C421F87B6; Tue, 14 Feb 2012 02:40:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 02:40:41 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 10:40:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Forcerenew Nonce Authentication Author(s) : David Miles Wojciech Dec James Bristow Roberta Maglione Filename : draft-ietf-dhc-forcerenew-nonce-04.txt Pages : 12 Date : 2012-02-14 Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server sends a nonce to the client on the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt From twinters@iol.unh.edu Tue Feb 14 05:43:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1233121F8770 for ; Tue, 14 Feb 2012 05:43:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJPL2c7XB4Jf for ; Tue, 14 Feb 2012 05:43:54 -0800 (PST) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by ietfa.amsl.com (Postfix) with SMTP id BD9DD21F876D for ; Tue, 14 Feb 2012 05:43:53 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKTzplFm1M4mcgYqSoJ94N66pQg22JTSc8@postini.com; Tue, 14 Feb 2012 05:43:53 PST Received: from openvpn-client28.iol.unh.edu (openvpn-client28.iol.unh.edu [132.177.124.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 3FF218F0075 for ; Tue, 14 Feb 2012 08:43:50 -0500 (EST) From: Timothy Winters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 08:43:50 -0500 Message-Id: To: dhcwg@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dhcwg] DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 13:43:56 -0000 Hello, While testing some CE Router implementations we have noticed a = interesting behavior that is within the specifications but not clearly = documented. I wanted to get the working group thoughts on this. Currently when a CE Router acting as a DHCP client, assigned = both IA_NA and IA_PD, is unplugged from the network. When reattached to = the link the DHCP client transmits a DHCP Renew containing both the = IA_NA and the IA_PD. 3315 Section 18.1.2 says that when link goes down a DHCP client = implementation should transmit a DHCP Confirm message containing the = assigned IA_NA. 3633 Section 12.1 doesn't allow the use of the Confirm message. = It states that DHCP Renew message, containing the assigned IA_PD, should = be used when the link goes down. =20 According to the specifications a DHCP client should retransmit = DHCP Confirm and DHCP Renew when link goes up. The behavior we are = seeing is the DHCP client transmits a DHCP renew containing both the = IA_NA and IA_PD. =20 This behavior isn't causing interoperability issues as all the = servers we have tried still respond properly to the DHCP Renew messages. Is it ok when a DHCP client loses link for it to transmit one = DHCP Renew message? Regards, Tim UNH-IOL From shawngespan@gmail.com Tue Feb 14 17:12:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0EA21F8673 for ; Tue, 14 Feb 2012 17:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEMpEs3V+0Jb for ; Tue, 14 Feb 2012 17:12:42 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1532421F8671 for ; Tue, 14 Feb 2012 17:12:40 -0800 (PST) Received: by bkuw12 with SMTP id w12so549157bku.31 for ; Tue, 14 Feb 2012 17:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=RmINf0ntWm35IBYap8zlVPiO/GaY4fzAzKtrQeRn3M8=; b=WH7DTDipczDHeVhylV0IlVvjC3EBa9W6xj0ObaYFI7YypzxWRKti+zviFiibU4RkU7 z5EExXD9dRAzsx5LhLQEgZ5Ec/J8CTdawfMrktQo2bQbiNwGs+VGuBxI6PQIZe3coT/4 h5mbwiuzw6bBob1YY0haPMso11ejVIBRPoCZk= MIME-Version: 1.0 Received: by 10.204.129.208 with SMTP id p16mr10697410bks.131.1329268360166; Tue, 14 Feb 2012 17:12:40 -0800 (PST) Received: by 10.205.81.8 with HTTP; Tue, 14 Feb 2012 17:12:40 -0800 (PST) Date: Wed, 15 Feb 2012 09:12:40 +0800 Message-ID: From: Huan Huan To: dhcwg@ietf.org, twinters@iol.unh.edu Content-Type: multipart/alternative; boundary=00151747ba066b3b6604b8f668ab Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:12:44 -0000 --00151747ba066b3b6604b8f668ab Content-Type: text/plain; charset=ISO-8859-1 Hi Tim, I think CE Router may transmit Confirm msg containing the assigned IA_NA and Renew msg containing the assigned IA_PD separately. BR, Huan 2012/2/15 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/dhcwg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send dhcwg mailing list submissions to > dhcwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dhcwg > or, via email, send a message with subject or body 'help' to > dhcwg-request@ietf.org > > You can reach the person managing the list at > dhcwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." > > > Today's Topics: > > 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > (internet-drafts@ietf.org) > 2. DHCP Renew vs Confirm (Timothy Winters) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Feb 2012 02:40:41 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > 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 : Forcerenew Nonce Authentication > Author(s) : David Miles > Wojciech Dec > James Bristow > Roberta Maglione > Filename : draft-ietf-dhc-forcerenew-nonce-04.txt > Pages : 12 > Date : 2012-02-14 > > Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the > reconfiguration of a single host by forcing the DHCP client into a > Renew state on a trigger from the DHCP server. In Forcerenew Nonce > Authentication the server sends a nonce to the client on the initial > DHCP ACK that is used for subsequent validation of a FORCERENEW > message. This document updates RFC 3203. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt > > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Feb 2012 08:43:50 -0500 > From: Timothy Winters > To: dhcwg@ietf.org > Subject: [dhcwg] DHCP Renew vs Confirm > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Hello, > While testing some CE Router implementations we have noticed a > interesting behavior that is within the specifications but not clearly > documented. I wanted to get the working group thoughts on this. > > Currently when a CE Router acting as a DHCP client, assigned both > IA_NA and IA_PD, is unplugged from the network. When reattached to the > link the DHCP client transmits a DHCP Renew containing both the IA_NA and > the IA_PD. > > 3315 Section 18.1.2 says that when link goes down a DHCP client > implementation should transmit a DHCP Confirm message containing the > assigned IA_NA. > > 3633 Section 12.1 doesn't allow the use of the Confirm message. It > states that DHCP Renew message, containing the assigned IA_PD, should be > used when the link goes down. > > According to the specifications a DHCP client should retransmit > DHCP Confirm and DHCP Renew when link goes up. The behavior we are seeing > is the DHCP client transmits a DHCP renew containing both the IA_NA and > IA_PD. > > This behavior isn't causing interoperability issues as all the > servers we have tried still respond properly to the DHCP Renew messages. > > Is it ok when a DHCP client loses link for it to transmit one DHCP > Renew message? > > Regards, > Tim > UNH-IOL > > > > ------------------------------ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > End of dhcwg Digest, Vol 94, Issue 13 > ************************************* > -- Huan Huan --00151747ba066b3b6604b8f668ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tim,

I think CE Router may transmit Confirm msg= =A0containing the assigned IA_NA and Renew msg=A0containing the assigned IA= _PD separately.

BR,
Huan=A0

2012/2/15 <= dhcwg-request@ietf.org>
If = you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

h= ttps://www.ietf.org/mailman/listinfo/dhcwg

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send dhcwg mailing list submissions to
=A0 =A0 =A0 =A0dhcwg@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0dhcwg-request@iet= f.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0dhcwg-owner@ietf.or= g

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcwg digest..."


Today's Topics:

=A0 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
=A0 =A0 =A0(internet-drafts@ie= tf.org)
=A0 2. DHCP Renew vs Confirm (Timothy Winters)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Feb 2012 02:40:41 -0800
From: internet-drafts@ietf.org<= /a>
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"


A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Forcerenew Nonce Authentication=
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : David Miles
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wojciech Dec
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Bristow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Roberta Maglione
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-forcerenew-nonce-0= 4.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-14

=A0 Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the =A0 reconfiguration of a single host by forcing the DHCP client into a
=A0 Renew state on a trigger from the DHCP server. =A0In Forcerenew Nonce<= br> =A0 Authentication the server sends a nonce to the client on the initial =A0 DHCP ACK that is used for subsequent validation of a FORCERENEW
=A0 message. =A0This document updates RFC 3203.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iet= f-dhc-forcerenew-nonce-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-= dhc-forcerenew-nonce-04.txt



------------------------------

Message: 2
Date: Tue, 14 Feb 2012 08:43:50 -0500
From: Timothy Winters <twinters@= iol.unh.edu>
To: dhcwg@ietf.org
Subject: [dhcwg] DHCP Renew vs Confirm
Message-ID: <C0CA95B6-1743-4D37-9BCC-D104453EBF9A@iol.unh.edu>
Content-Type: text/plain; charset=3Dus-ascii

Hello,
=A0 =A0 =A0 =A0While testing some CE Router implementations we have notice= d a interesting behavior that is within the specifications but not clearly = documented. =A0I wanted to get the working group thoughts on this.

=A0 =A0 =A0 =A0Currently when a CE Router acting as a DHCP client, assigne= d both IA_NA and IA_PD, is unplugged from the network. =A0When reattached t= o the link the DHCP client transmits a DHCP Renew containing both the IA_NA= and the IA_PD.

=A0 =A0 =A0 =A03315 Section 18.1.2 says that when link goes down a DHCP cl= ient implementation should transmit a DHCP Confirm message containing the a= ssigned IA_NA.

=A0 =A0 =A0 =A03633 Section 12.1 doesn't allow the use of the Confirm = message. =A0It states that DHCP Renew message, containing the assigned IA_P= D, should be used when the link goes down.

=A0 =A0 =A0 =A0According to the specifications a DHCP client should retran= smit DHCP Confirm and DHCP Renew when link goes up. =A0 The behavior we are= seeing is the DHCP client transmits a DHCP renew containing both the IA_NA= and IA_PD.

=A0 =A0 =A0 =A0This behavior isn't causing interoperability issues as = all the servers we have tried still respond properly to the DHCP Renew mess= ages.

=A0 =A0 =A0 =A0Is it ok when a DHCP client loses link for it to transmit o= ne DHCP Renew message?

Regards,
Tim
UNH-IOL



------------------------------

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


End of dhcwg Digest, Vol 94, Issue 13
*************************************



--
Huan Huan
--00151747ba066b3b6604b8f668ab-- From twinters@iol.unh.edu Tue Feb 14 17:19:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0564821E8045 for ; Tue, 14 Feb 2012 17:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2k8kAf6sHGn for ; Tue, 14 Feb 2012 17:19:45 -0800 (PST) Received: from exprod5og114.obsmtp.com (exprod5og114.obsmtp.com [64.18.0.28]) by ietfa.amsl.com (Postfix) with SMTP id 478C621F87EA for ; Tue, 14 Feb 2012 17:19:44 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob114.postini.com ([64.18.4.12]) with SMTP ID DSNKTzsILnrICpdRsxQoAv7Ar/6VnNz92Lf6@postini.com; Tue, 14 Feb 2012 17:19:44 PST Received: from [10.0.1.4] (c-24-63-15-128.hsd1.nh.comcast.net [24.63.15.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 605538F0067; Tue, 14 Feb 2012 20:19:42 -0500 (EST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-D66467D5-FBA1-4994-98B9-675A15B4C88D Message-Id: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> X-Mailer: iPad Mail (9A405) From: Timothy Winters Date: Tue, 14 Feb 2012 20:19:41 -0500 To: Huan Huan Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:19:46 -0000 --Apple-Mail-D66467D5-FBA1-4994-98B9-675A15B4C88D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Huan, Is it ok to transmit just a Renew message containing both the IA_NA an= d IA_PD when the link goes down? Regards, Tim On Feb 14, 2012, at 8:12 PM, Huan Huan wrote: > Hi Tim, >=20 > I think CE Router may transmit Confirm msg containing the assigned IA_NA a= nd Renew msg containing the assigned IA_PD separately. >=20 > BR, > Huan=20 >=20 > 2012/2/15 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send dhcwg mailing list submissions to > dhcwg@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dhcwg > or, via email, send a message with subject or body 'help' to > dhcwg-request@ietf.org >=20 > You can reach the person managing the list at > dhcwg-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." >=20 >=20 > Today's Topics: >=20 > 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > (internet-drafts@ietf.org) > 2. DHCP Renew vs Confirm (Timothy Winters) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 14 Feb 2012 02:40:41 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. >=20 > Title : Forcerenew Nonce Authentication > Author(s) : David Miles > Wojciech Dec > James Bristow > Roberta Maglione > Filename : draft-ietf-dhc-forcerenew-nonce-04.txt > Pages : 12 > Date : 2012-02-14 >=20 > Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the > reconfiguration of a single host by forcing the DHCP client into a > Renew state on a trigger from the DHCP server. In Forcerenew Nonce > Authentication the server sends a nonce to the client on the initial > DHCP ACK that is used for subsequent validation of a FORCERENEW > message. This document updates RFC 3203. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 14 Feb 2012 08:43:50 -0500 > From: Timothy Winters > To: dhcwg@ietf.org > Subject: [dhcwg] DHCP Renew vs Confirm > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii >=20 > Hello, > While testing some CE Router implementations we have noticed a inte= resting behavior that is within the specifications but not clearly documente= d. I wanted to get the working group thoughts on this. >=20 > Currently when a CE Router acting as a DHCP client, assigned both I= A_NA and IA_PD, is unplugged from the network. When reattached to the link t= he DHCP client transmits a DHCP Renew containing both the IA_NA and the IA_P= D. >=20 > 3315 Section 18.1.2 says that when link goes down a DHCP client imp= lementation should transmit a DHCP Confirm message containing the assigned I= A_NA. >=20 > 3633 Section 12.1 doesn't allow the use of the Confirm message. It= states that DHCP Renew message, containing the assigned IA_PD, should be us= ed when the link goes down. >=20 > According to the specifications a DHCP client should retransmit DHC= P Confirm and DHCP Renew when link goes up. The behavior we are seeing is t= he DHCP client transmits a DHCP renew containing both the IA_NA and IA_PD. >=20 > This behavior isn't causing interoperability issues as all the serv= ers we have tried still respond properly to the DHCP Renew messages. >=20 > Is it ok when a DHCP client loses link for it to transmit one DHCP R= enew message? >=20 > Regards, > Tim > UNH-IOL >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > End of dhcwg Digest, Vol 94, Issue 13 > ************************************* >=20 >=20 >=20 > --=20 > Huan Huan --Apple-Mail-D66467D5-FBA1-4994-98B9-675A15B4C88D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Hi Huan,
      Is it ok to transmit just a Renew message containing both the IA_NA and IA_PD when the link goes down?

Regards,
Tim

On Feb 14, 2012, at 8:12 PM, Huan Huan <shawngespan@gmail.com> wrote:

Hi Tim,

I think CE Router may transmit Confirm msg containing the assigned IA_NA and Renew msg containing the assigned IA_PD separately.

BR,
Huan 

2012/2/15 <dhcwg-request@ietf.org>
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/dhcwg

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send dhcwg mailing list submissions to
       dhcwg@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
       https://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
       dhcwg-request@ietf.org

You can reach the person managing the list at
       dhcwg-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcwg digest..."


Today's Topics:

  1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
     (internet-drafts@ietf.org)
  2. DHCP Renew vs Confirm (Timothy Winters)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Feb 2012 02:40:41 -0800
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"


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           : Forcerenew Nonce Authentication
       Author(s)       : David Miles
                         Wojciech Dec
                         James Bristow
                         Roberta Maglione
       Filename        : draft-ietf-dhc-forcerenew-nonce-04.txt
       Pages           : 12
       Date            : 2012-02-14

  Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the
  reconfiguration of a single host by forcing the DHCP client into a
  Renew state on a trigger from the DHCP server.  In Forcerenew Nonce
  Authentication the server sends a nonce to the client on the initial
  DHCP ACK that is used for subsequent validation of a FORCERENEW
  message.  This document updates RFC 3203.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt



------------------------------

Message: 2
Date: Tue, 14 Feb 2012 08:43:50 -0500
From: Timothy Winters <twinters@iol.unh.edu>
To: dhcwg@ietf.org
Subject: [dhcwg] DHCP Renew vs Confirm
Message-ID: <C0CA95B6-1743-4D37-9BCC-D104453EBF9A@iol.unh.edu>
Content-Type: text/plain; charset=us-ascii

Hello,
       While testing some CE Router implementations we have noticed a interesting behavior that is within the specifications but not clearly documented.  I wanted to get the working group thoughts on this.

       Currently when a CE Router acting as a DHCP client, assigned both IA_NA and IA_PD, is unplugged from the network.  When reattached to the link the DHCP client transmits a DHCP Renew containing both the IA_NA and the IA_PD.

       3315 Section 18.1.2 says that when link goes down a DHCP client implementation should transmit a DHCP Confirm message containing the assigned IA_NA.

       3633 Section 12.1 doesn't allow the use of the Confirm message.  It states that DHCP Renew message, containing the assigned IA_PD, should be used when the link goes down.

       According to the specifications a DHCP client should retransmit DHCP Confirm and DHCP Renew when link goes up.   The behavior we are seeing is the DHCP client transmits a DHCP renew containing both the IA_NA and IA_PD.

       This behavior isn't causing interoperability issues as all the servers we have tried still respond properly to the DHCP Renew messages.

       Is it ok when a DHCP client loses link for it to transmit one DHCP Renew message?

Regards,
Tim
UNH-IOL



------------------------------

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


End of dhcwg Digest, Vol 94, Issue 13
*************************************



--
Huan Huan
--Apple-Mail-D66467D5-FBA1-4994-98B9-675A15B4C88D-- From arifumi@nttv6.net Wed Feb 15 04:00:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0321F87BA for ; Wed, 15 Feb 2012 04:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.684 X-Spam-Level: X-Spam-Status: No, score=-101.684 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afcXgbpEo5nU for ; Wed, 15 Feb 2012 04:00:26 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3252F21F8776 for ; Wed, 15 Feb 2012 04:00:26 -0800 (PST) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1FC1Nrj047520; Wed, 15 Feb 2012 21:01:23 +0900 (JST) (envelope-from arifumi@nttv6.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Arifumi Matsumoto In-Reply-To: Date: Wed, 15 Feb 2012 20:59:04 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0D8D7331-3524-422D-9B48-82D5C3C47D44@nttv6.net> References: To: jouni korhonen X-Mailer: Apple Mail (2.1257) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Review of draft-ietf-6man-addr-select-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:00:31 -0000 Hi, I'm sorry for replying late. I compiled the revision of this document. This version hopefully captures the comments from two reviewers in = dhcwg. You can find it here. http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-02 On 2011/12/02, at 1:29, jouni korhonen wrote: >=20 > Hi, >=20 > I promised to make a review of this I-D. My comments can be found = here: > http://deadcoderssociety.net/6man.pdf >=20 > There are two main things: > 1) I suggest to remove all text that references into the future = regarding ongoing work etc. That will look a bit weird when actual RFCs = come out etc. About this point, I see several RFCs that refer to internet drafts. Do we really need to remove all the refereces for i-ds ? Thanks ! > 2) It is not clear what happens when DASP_OPTION is received from = multiple sources and in all cases Section 4.2. "trust" requirements are = met. Will the last received policy overwrite all previously learned? >=20 > Also I did not quite get the "leak of privacy information". Could you = elaborate that a bit further in the I-D. And finally, regarding the = prefix encoding in the option I would myself prefer 1 octet granularity = over 4.. or is there a specific reason for selecting 4? (DHCPv6 options = do not have alignment requirements) >=20 > - Jouni >=20 > On Nov 9, 2011, at 10:21 AM, Arifumi Matsumoto wrote: >=20 >> All, >>=20 >> at Quebec, Tim Chown presented about address selection documents >> discussed in 6man WG, and requested reviewers for the draft >> draft-ietf-6man-addr-select-opt-01. >> slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf >>=20 >> IIRC, one reviewer was chosen at that time, and the other was left >> undecided. >>=20 >> So, my questions are >> the review was submitted somewhere ? >> the other reviewer was chosen ? >>=20 >> -- >> Arifumi Matsumoto >> NGN System Architecture Project >> NTT Service Integration Laboratories >> E-mail: arifumi@nttv6.net >> TEL +81-422-59-3334 FAX +81-422-59-6364 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 -- =E6=9D=BE=E6=9C=AC =E5=AD=98=E5=8F=B2 NTT=E3=82=B5=E3=83=BC=E3=83=93=E3=82=B9=E3=82=A4=E3=83=B3=E3=83=86=E3=82=B0= =E3=83=AC=E3=83=BC=E3=82=B7=E3=83=A7=E3=83=B3=E5=9F=BA=E7=9B=A4=E7=A0=94=E7= =A9=B6=E6=89=80 =E6=AC=A1=E4=B8=96=E4=BB=A3=E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3= =82=AF=E6=96=B9=E5=BC=8FSE=E3=83=97=E3=83=AD=E3=82=B8=E3=82=A7=E3=82=AF=E3= =83=88 =E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3=82=AF=E3=82=A2=E3=83=BC= =E3=82=AD=E3=83=86=E3=82=AF=E3=83=81=E3=83=A3=E3=82=B0=E3=83=AB=E3=83=BC=E3= =83=97 TEL 0422-59-3334 FAX 0422-59-6364 From Matt.Ryan@nominum.com Wed Feb 15 10:38:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47B721E804E for ; Wed, 15 Feb 2012 10:38:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfwEziP3qM0c for ; Wed, 15 Feb 2012 10:38:38 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1910E21E805B for ; Wed, 15 Feb 2012 10:38:33 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTzv7pWilEE5KxAMgjrpxIC7aDNz3tyk1@postini.com; Wed, 15 Feb 2012 10:38:35 PST Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 80AE01B8237; Wed, 15 Feb 2012 10:38:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Ryan In-Reply-To: Date: Wed, 15 Feb 2012 10:38:29 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: Arifumi Matsumoto X-Mailer: Apple Mail (2.1084) Cc: dhc WG Subject: Re: [dhcwg] reviews of draft-ietf-6man-addr-select-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 18:38:42 -0000 I note that the descriptions for the 'suboption-zone-index' and 'z-bit' in Section 2 say that if the z bit is present, the zone-index field is inserted between prefix-len and prefix. This does not appear to be borne out by the diagram. I assume the text was not updated when the format was changed. Also, the 'suboption-len' field "specifies the length of the suboption fields in bytes". If there is the desire to potentially include multiple suboptions, this will not be sufficient, because you have no way of telling them apart. If this option is to have sub-options, then they should be formatted as in other options that have sub-options: each sub-option prefixed by a code and a length. As for the prefix, I think it should follow the same form as in the IA_PD Prefix option [RFC-3633 section 10]. That is, a single octet indicating prefix length in bits, followed by a fixed-length 16 octet address. Having a variable-length address complicates implementation, especially when the length field unit is bits, not octets. It would require server implementers to write custom code simply to handle the option usefully, where there already exists code to handle the form used in the IA_PD Prefix option. Finally, I'm not sure I see the need for the "z-bit", since the zone-index is at the end. You don't need it to indicate the presence of zone-index, since you easily see if zone-index is present while parsing the packet, regardless of whether it is a sub-option, or just an optional 32-bit value at the end (and there are no other sub-options). - Matt On Nov 9, 2011, at 00:21 , Arifumi Matsumoto wrote: > All, > > at Quebec, Tim Chown presented about address selection documents > discussed in 6man WG, and requested reviewers for the draft > draft-ietf-6man-addr-select-opt-01. > slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf > > IIRC, one reviewer was chosen at that time, and the other was left > undecided. > > So, my questions are > the review was submitted somewhere ? > the other reviewer was chosen ? > > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arifumi@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jouni.nospam@gmail.com Wed Feb 15 12:45:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157A321E80A8 for ; Wed, 15 Feb 2012 12:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zdcmd9Fu0dXz for ; Wed, 15 Feb 2012 12:45:02 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05E2F21E80A4 for ; Wed, 15 Feb 2012 12:44:55 -0800 (PST) Received: by lahl5 with SMTP id l5so1690247lah.31 for ; Wed, 15 Feb 2012 12:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CVifIfYlrrZHff7cAmEgAkSoznvtVKUwWAB3l9Rvz+E=; b=PfmlsdGbEhcVJ6RwF6vALx/s1YhyFE9Jb6yvMOk5AWVBHnzuYUrof9fVq+PZp7Di9a O9W3QC6YAx6YiY5i5YoSJg5YtNHasYEJEBZbE5+V/CIBcnatqRnjsJu7Ya0HGc9iwhAe VVHFnLOV/e3USqlq/c+CWF3/ExW0oMNzL0liQ= Received: by 10.112.84.170 with SMTP id a10mr9558154lbz.22.1329338694997; Wed, 15 Feb 2012 12:44:54 -0800 (PST) Received: from a83-245-213-3.elisa-laajakaista.fi (a83-245-213-3.elisa-laajakaista.fi. [83.245.213.3]) by mx.google.com with ESMTPS id pd3sm3710556lab.14.2012.02.15.12.44.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 12:44:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: jouni korhonen In-Reply-To: <0D8D7331-3524-422D-9B48-82D5C3C47D44@nttv6.net> Date: Wed, 15 Feb 2012 22:44:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8D7331-3524-422D-9B48-82D5C3C47D44@nttv6.net> To: Arifumi Matsumoto X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Review of draft-ietf-6man-addr-select-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:45:07 -0000 Hi, On Feb 15, 2012, at 1:59 PM, Arifumi Matsumoto wrote: > Hi, >=20 > I'm sorry for replying late. >=20 > I compiled the revision of this document. > This version hopefully captures the comments from two reviewers in = dhcwg. >=20 > You can find it here. > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-02 >=20 > On 2011/12/02, at 1:29, jouni korhonen wrote: >=20 >>=20 >> Hi, >>=20 >> I promised to make a review of this I-D. My comments can be found = here: >> http://deadcoderssociety.net/6man.pdf >>=20 >> There are two main things: >> 1) I suggest to remove all text that references into the future = regarding ongoing work etc. That will look a bit weird when actual RFCs = come out etc. >=20 > About this point, I see several RFCs that refer to internet drafts. > Do we really need to remove all the refereces for i-ds ? I mainly mean text formulation such in abstract that says: "While RFC 3484 is in the process of being updated, .." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You still can have references to in progress work, no problem with that.=20= - Jouni >=20 > Thanks ! >=20 >=20 >> 2) It is not clear what happens when DASP_OPTION is received from = multiple sources and in all cases Section 4.2. "trust" requirements are = met. Will the last received policy overwrite all previously learned? >>=20 >> Also I did not quite get the "leak of privacy information". Could you = elaborate that a bit further in the I-D. And finally, regarding the = prefix encoding in the option I would myself prefer 1 octet granularity = over 4.. or is there a specific reason for selecting 4? (DHCPv6 options = do not have alignment requirements) >>=20 >> - Jouni >>=20 >> On Nov 9, 2011, at 10:21 AM, Arifumi Matsumoto wrote: >>=20 >>> All, >>>=20 >>> at Quebec, Tim Chown presented about address selection documents >>> discussed in 6man WG, and requested reviewers for the draft >>> draft-ietf-6man-addr-select-opt-01. >>> slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf >>>=20 >>> IIRC, one reviewer was chosen at that time, and the other was left >>> undecided. >>>=20 >>> So, my questions are >>> the review was submitted somewhere ? >>> the other reviewer was chosen ? >>>=20 >>> -- >>> Arifumi Matsumoto >>> NGN System Architecture Project >>> NTT Service Integration Laboratories >>> E-mail: arifumi@nttv6.net >>> TEL +81-422-59-3334 FAX +81-422-59-6364 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 >=20 > -- > =E6=9D=BE=E6=9C=AC =E5=AD=98=E5=8F=B2 > NTT=E3=82=B5=E3=83=BC=E3=83=93=E3=82=B9=E3=82=A4=E3=83=B3=E3=83=86=E3=82= =B0=E3=83=AC=E3=83=BC=E3=82=B7=E3=83=A7=E3=83=B3=E5=9F=BA=E7=9B=A4=E7=A0=94= =E7=A9=B6=E6=89=80 > =E6=AC=A1=E4=B8=96=E4=BB=A3=E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC= =E3=82=AF=E6=96=B9=E5=BC=8FSE=E3=83=97=E3=83=AD=E3=82=B8=E3=82=A7=E3=82=AF= =E3=83=88 > =E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3=82=AF=E3=82=A2=E3=83=BC= =E3=82=AD=E3=83=86=E3=82=AF=E3=83=81=E3=83=A3=E3=82=B0=E3=83=AB=E3=83=BC=E3= =83=97 > TEL 0422-59-3334 FAX 0422-59-6364 >=20 From shawngespan@gmail.com Wed Feb 15 17:55:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0092021E803E for ; Wed, 15 Feb 2012 17:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lirUxRzyyYEE for ; Wed, 15 Feb 2012 17:55:46 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6735F21E800E for ; Wed, 15 Feb 2012 17:55:46 -0800 (PST) Received: by bkuw12 with SMTP id w12so1692625bku.31 for ; Wed, 15 Feb 2012 17:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B4qVX4ZMHs0YkdNJUWYTA5yw0xugEYS3ZlzQxJtgxI8=; b=SjBFpAlQc9Nwsipu6wz03DNSz9UK1s3zyjm8culBOMttIdUpAtiJ2q3aobUtEnloes DFmEvyVw4cUSsM2Vv713Fgs7GpXRY95Trz80hgikMcA+z165eUrOCVPu6fvSyrEkJUVd FOmgc7so54UEB306hLQuhOqDmfgfKDBL82SsI= MIME-Version: 1.0 Received: by 10.204.129.208 with SMTP id p16mr187678bks.131.1329357345462; Wed, 15 Feb 2012 17:55:45 -0800 (PST) Received: by 10.205.81.8 with HTTP; Wed, 15 Feb 2012 17:55:45 -0800 (PST) In-Reply-To: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> Date: Thu, 16 Feb 2012 09:55:45 +0800 Message-ID: From: Huan Huan To: Timothy Winters Content-Type: multipart/alternative; boundary=00151747ba065b1b5104b90b2073 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 01:55:50 -0000 --00151747ba065b1b5104b90b2073 Content-Type: text/plain; charset=ISO-8859-1 I don't think so. 2012/2/15 Timothy Winters > Hi Huan, > Is it ok to transmit just a Renew message containing both the IA_NA > and IA_PD when the link goes down? > > Regards, > Tim > > > On Feb 14, 2012, at 8:12 PM, Huan Huan wrote: > > Hi Tim, > > I think CE Router may transmit Confirm msg containing the assigned IA_NA > and Renew msg containing the assigned IA_PD separately. > > BR, > Huan > > 2012/2/15 > >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/dhcwg >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send dhcwg mailing list submissions to >> dhcwg@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/dhcwg >> or, via email, send a message with subject or body 'help' to >> dhcwg-request@ietf.org >> >> You can reach the person managing the list at >> dhcwg-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of dhcwg digest..." >> >> >> Today's Topics: >> >> 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt >> (internet-drafts@ietf.org) >> 2. DHCP Renew vs Confirm (Timothy Winters) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 14 Feb 2012 02:40:41 -0800 >> From: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> Cc: dhcwg@ietf.org >> Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt >> Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> >> Content-Type: text/plain; charset="utf-8" >> >> >> 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 : Forcerenew Nonce Authentication >> Author(s) : David Miles >> Wojciech Dec >> James Bristow >> Roberta Maglione >> Filename : draft-ietf-dhc-forcerenew-nonce-04.txt >> Pages : 12 >> Date : 2012-02-14 >> >> Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the >> reconfiguration of a single host by forcing the DHCP client into a >> Renew state on a trigger from the DHCP server. In Forcerenew Nonce >> Authentication the server sends a nonce to the client on the initial >> DHCP ACK that is used for subsequent validation of a FORCERENEW >> message. This document updates RFC 3203. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 14 Feb 2012 08:43:50 -0500 >> From: Timothy Winters >> To: dhcwg@ietf.org >> Subject: [dhcwg] DHCP Renew vs Confirm >> Message-ID: >> Content-Type: text/plain; charset=us-ascii >> >> Hello, >> While testing some CE Router implementations we have noticed a >> interesting behavior that is within the specifications but not clearly >> documented. I wanted to get the working group thoughts on this. >> >> Currently when a CE Router acting as a DHCP client, assigned both >> IA_NA and IA_PD, is unplugged from the network. When reattached to the >> link the DHCP client transmits a DHCP Renew containing both the IA_NA and >> the IA_PD. >> >> 3315 Section 18.1.2 says that when link goes down a DHCP client >> implementation should transmit a DHCP Confirm message containing the >> assigned IA_NA. >> >> 3633 Section 12.1 doesn't allow the use of the Confirm message. >> It states that DHCP Renew message, containing the assigned IA_PD, should >> be used when the link goes down. >> >> According to the specifications a DHCP client should retransmit >> DHCP Confirm and DHCP Renew when link goes up. The behavior we are seeing >> is the DHCP client transmits a DHCP renew containing both the IA_NA and >> IA_PD. >> >> This behavior isn't causing interoperability issues as all the >> servers we have tried still respond properly to the DHCP Renew messages. >> >> Is it ok when a DHCP client loses link for it to transmit one DHCP >> Renew message? >> >> Regards, >> Tim >> UNH-IOL >> >> >> >> ------------------------------ >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> >> >> End of dhcwg Digest, Vol 94, Issue 13 >> ************************************* >> > > > > -- > Huan Huan > > -- Huan Huan --00151747ba065b1b5104b90b2073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think so.

2012/2/15 Timothy = Winters <twint= ers@iol.unh.edu>
Hi Huan,
=A0 =A0 =A0 Is it ok to tr= ansmit just a Renew message containing both the IA_NA and IA_PD when the li= nk goes down?

Regards,
Tim


On Feb 14, 2012, at 8:12 PM, Huan Huan <shawngespan@gmail.com> wrote:
=
Hi Tim,

I think CE Router may transmit Confir= m msg=A0containing the assigned IA_NA and Renew msg=A0containing the assign= ed IA_PD separately.

BR,
Huan=A0

2012/2/15 <dhcwg-request@ietf.org>
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

h= ttps://www.ietf.org/mailman/listinfo/dhcwg

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send dhcwg mailing list submissions to
=A0 =A0 =A0 =A0dhcwg@i= etf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0dhcwg-request@ietf.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0d= hcwg-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcwg digest..."


Today's Topics:

=A0 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
=A0 =A0 =A0(= internet-drafts@ietf.org)
=A0 2. DHCP Renew vs Confirm (Timothy Winters)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Feb 2012 02:40:41 -0800
From: interne= t-drafts@ietf.org
To: i-d-announce= @ietf.org
Cc: dhcwg@ietf.org<= br> Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
Message-ID: <20120214104041.23040.30559.idtracker@ietfa.am= sl.com>
Content-Type: text/plain; charset=3D"utf-8"


A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Forcerenew Nonce Authentication=
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : David Miles
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wojciech Dec
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Bristow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Roberta Maglione
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-forcerenew-nonce-0= 4.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-14

=A0 Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the =A0 reconfiguration of a single host by forcing the DHCP client into a
=A0 Renew state on a trigger from the DHCP server. =A0In Forcerenew Nonce<= br> =A0 Authentication the server sends a nonce to the client on the initial =A0 DHCP ACK that is used for subsequent validation of a FORCERENEW
=A0 message. =A0This document updates RFC 3203.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iet= f-dhc-forcerenew-nonce-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-= dhc-forcerenew-nonce-04.txt



------------------------------

Message: 2
Date: Tue, 14 Feb 2012 08:43:50 -0500
From: Timothy Winters <twinters@iol.unh.edu>
To: dhcwg@ietf.org<= br> Subject: [dhcwg] DHCP Renew vs Confirm
Message-ID: <C0CA95B6-1743-4D37-9BCC-D104453EBF9A@iol.unh.edu= >
Content-Type: text/plain; charset=3Dus-ascii

Hello,
=A0 =A0 =A0 =A0While testing some CE Router implementations we have notice= d a interesting behavior that is within the specifications but not clearly = documented. =A0I wanted to get the working group thoughts on this.

=A0 =A0 =A0 =A0Currently when a CE Router acting as a DHCP client, assigne= d both IA_NA and IA_PD, is unplugged from the network. =A0When reattached t= o the link the DHCP client transmits a DHCP Renew containing both the IA_NA= and the IA_PD.

=A0 =A0 =A0 =A03315 Section 18.1.2 says that when link goes down a DHCP cl= ient implementation should transmit a DHCP Confirm message containing the a= ssigned IA_NA.

=A0 =A0 =A0 =A03633 Section 12.1 doesn't allow the use of the Confirm = message. =A0It states that DHCP Renew message, containing the assigned IA_P= D, should be used when the link goes down.

=A0 =A0 =A0 =A0According to the specifications a DHCP client should retran= smit DHCP Confirm and DHCP Renew when link goes up. =A0 The behavior we are= seeing is the DHCP client transmits a DHCP renew containing both the IA_NA= and IA_PD.

=A0 =A0 =A0 =A0This behavior isn't causing interoperability issues as = all the servers we have tried still respond properly to the DHCP Renew mess= ages.

=A0 =A0 =A0 =A0Is it ok when a DHCP client loses link for it to transmit o= ne DHCP Renew message?

Regards,
Tim
UNH-IOL



------------------------------

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


End of dhcwg Digest, Vol 94, Issue 13
*************************************



--
Huan Huan



--
Huan Huan
--00151747ba065b1b5104b90b2073-- From arifumi@nttv6.net Wed Feb 15 18:33:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879FF21F84E1 for ; Wed, 15 Feb 2012 18:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.616 X-Spam-Level: X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUSgCuy9NyBr for ; Wed, 15 Feb 2012 18:33:39 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id B5EE921F84DA for ; Wed, 15 Feb 2012 18:33:38 -0800 (PST) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1G2YTKp032428; Thu, 16 Feb 2012 11:34:29 +0900 (JST) (envelope-from arifumi@nttv6.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Arifumi Matsumoto In-Reply-To: Date: Thu, 16 Feb 2012 11:32:10 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2E3381C4-4E24-4D6A-A7E5-4620F2124F3D@nttv6.net> References: <0D8D7331-3524-422D-9B48-82D5C3C47D44@nttv6.net> To: jouni korhonen X-Mailer: Apple Mail (2.1257) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Review of draft-ietf-6man-addr-select-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 02:33:43 -0000 Jouni, I got it. Thanks ! On 2012/02/16, at 5:44, jouni korhonen wrote: > Hi, >=20 > On Feb 15, 2012, at 1:59 PM, Arifumi Matsumoto wrote: >=20 >> Hi, >>=20 >> I'm sorry for replying late. >>=20 >> I compiled the revision of this document. >> This version hopefully captures the comments from two reviewers in = dhcwg. >>=20 >> You can find it here. >> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-02 >>=20 >> On 2011/12/02, at 1:29, jouni korhonen wrote: >>=20 >>>=20 >>> Hi, >>>=20 >>> I promised to make a review of this I-D. My comments can be found = here: >>> http://deadcoderssociety.net/6man.pdf >>>=20 >>> There are two main things: >>> 1) I suggest to remove all text that references into the future = regarding ongoing work etc. That will look a bit weird when actual RFCs = come out etc. >>=20 >> About this point, I see several RFCs that refer to internet drafts. >> Do we really need to remove all the refereces for i-ds ? >=20 > I mainly mean text formulation such in abstract that says: > "While RFC 3484 is in the process of being updated, .." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > You still can have references to in progress work, no problem with = that.=20 >=20 > - Jouni >=20 >=20 >=20 >>=20 >> Thanks ! >>=20 >>=20 >>> 2) It is not clear what happens when DASP_OPTION is received from = multiple sources and in all cases Section 4.2. "trust" requirements are = met. Will the last received policy overwrite all previously learned? >>>=20 >>> Also I did not quite get the "leak of privacy information". Could = you elaborate that a bit further in the I-D. And finally, regarding the = prefix encoding in the option I would myself prefer 1 octet granularity = over 4.. or is there a specific reason for selecting 4? (DHCPv6 options = do not have alignment requirements) >>>=20 >>> - Jouni >>>=20 >>> On Nov 9, 2011, at 10:21 AM, Arifumi Matsumoto wrote: >>>=20 >>>> All, >>>>=20 >>>> at Quebec, Tim Chown presented about address selection documents >>>> discussed in 6man WG, and requested reviewers for the draft >>>> draft-ietf-6man-addr-select-opt-01. >>>> slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf >>>>=20 >>>> IIRC, one reviewer was chosen at that time, and the other was left >>>> undecided. >>>>=20 >>>> So, my questions are >>>> the review was submitted somewhere ? >>>> the other reviewer was chosen ? >>>>=20 >>>> -- >>>> Arifumi Matsumoto >>>> NGN System Architecture Project >>>> NTT Service Integration Laboratories >>>> E-mail: arifumi@nttv6.net >>>> TEL +81-422-59-3334 FAX +81-422-59-6364 >>>>=20 >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>>=20 >>=20 >>=20 >> -- >> =E6=9D=BE=E6=9C=AC =E5=AD=98=E5=8F=B2 >> NTT=E3=82=B5=E3=83=BC=E3=83=93=E3=82=B9=E3=82=A4=E3=83=B3=E3=83=86=E3=82= =B0=E3=83=AC=E3=83=BC=E3=82=B7=E3=83=A7=E3=83=B3=E5=9F=BA=E7=9B=A4=E7=A0=94= =E7=A9=B6=E6=89=80 >> =E6=AC=A1=E4=B8=96=E4=BB=A3=E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC= =E3=82=AF=E6=96=B9=E5=BC=8FSE=E3=83=97=E3=83=AD=E3=82=B8=E3=82=A7=E3=82=AF= =E3=83=88 >> =E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3=82=AF=E3=82=A2=E3=83=BC= =E3=82=AD=E3=83=86=E3=82=AF=E3=83=81=E3=83=A3=E3=82=B0=E3=83=AB=E3=83=BC=E3= =83=97 >> TEL 0422-59-3334 FAX 0422-59-6364 >>=20 >=20 >=20 -- =E6=9D=BE=E6=9C=AC =E5=AD=98=E5=8F=B2 NTT=E3=82=B5=E3=83=BC=E3=83=93=E3=82=B9=E3=82=A4=E3=83=B3=E3=83=86=E3=82=B0= =E3=83=AC=E3=83=BC=E3=82=B7=E3=83=A7=E3=83=B3=E5=9F=BA=E7=9B=A4=E7=A0=94=E7= =A9=B6=E6=89=80 =E6=AC=A1=E4=B8=96=E4=BB=A3=E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3= =82=AF=E6=96=B9=E5=BC=8FSE=E3=83=97=E3=83=AD=E3=82=B8=E3=82=A7=E3=82=AF=E3= =83=88 =E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3=82=AF=E3=82=A2=E3=83=BC= =E3=82=AD=E3=83=86=E3=82=AF=E3=83=81=E3=83=A3=E3=82=B0=E3=83=AB=E3=83=BC=E3= =83=97 TEL 0422-59-3334 FAX 0422-59-6364 From arifumi@nttv6.net Wed Feb 15 18:36:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393AE21F84DF for ; Wed, 15 Feb 2012 18:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.564 X-Spam-Level: X-Spam-Status: No, score=-101.564 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb2+4XsKUzm8 for ; Wed, 15 Feb 2012 18:36:53 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7389721F84E1 for ; Wed, 15 Feb 2012 18:36:53 -0800 (PST) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1G2brad032444 for ; Thu, 16 Feb 2012 11:37:53 +0900 (JST) (envelope-from arifumi@nttv6.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: Arifumi Matsumoto In-Reply-To: <0D8D7331-3524-422D-9B48-82D5C3C47D44@nttv6.net> Date: Thu, 16 Feb 2012 11:35:34 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8D7331-3524-422D-9B48-82D5C3C47D44@nttv6.net> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1257) Subject: Re: [dhcwg] Review of draft-ietf-6man-addr-select-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 02:36:58 -0000 All, I failed to mention that I hope this version will be used for WGLC at dhcwg from the dhcwg perspective, followed by WGLC at 6man. Thanks. On 2012/02/15, at 20:59, Arifumi Matsumoto wrote: > Hi, >=20 > I'm sorry for replying late. >=20 > I compiled the revision of this document. > This version hopefully captures the comments from two reviewers in = dhcwg. >=20 > You can find it here. > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-02 >=20 > On 2011/12/02, at 1:29, jouni korhonen wrote: >=20 >>=20 >> Hi, >>=20 >> I promised to make a review of this I-D. My comments can be found = here: >> http://deadcoderssociety.net/6man.pdf >>=20 >> There are two main things: >> 1) I suggest to remove all text that references into the future = regarding ongoing work etc. That will look a bit weird when actual RFCs = come out etc. >=20 > About this point, I see several RFCs that refer to internet drafts. > Do we really need to remove all the refereces for i-ds ? >=20 > Thanks ! >=20 >=20 >> 2) It is not clear what happens when DASP_OPTION is received from = multiple sources and in all cases Section 4.2. "trust" requirements are = met. Will the last received policy overwrite all previously learned? >>=20 >> Also I did not quite get the "leak of privacy information". Could you = elaborate that a bit further in the I-D. And finally, regarding the = prefix encoding in the option I would myself prefer 1 octet granularity = over 4.. or is there a specific reason for selecting 4? (DHCPv6 options = do not have alignment requirements) >>=20 >> - Jouni >>=20 >> On Nov 9, 2011, at 10:21 AM, Arifumi Matsumoto wrote: >>=20 >>> All, >>>=20 >>> at Quebec, Tim Chown presented about address selection documents >>> discussed in 6man WG, and requested reviewers for the draft >>> draft-ietf-6man-addr-select-opt-01. >>> slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf >>>=20 >>> IIRC, one reviewer was chosen at that time, and the other was left >>> undecided. >>>=20 >>> So, my questions are >>> the review was submitted somewhere ? >>> the other reviewer was chosen ? >>>=20 >>> -- >>> Arifumi Matsumoto >>> NGN System Architecture Project >>> NTT Service Integration Laboratories >>> E-mail: arifumi@nttv6.net >>> TEL +81-422-59-3334 FAX +81-422-59-6364 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 >=20 > -- > =E6=9D=BE=E6=9C=AC =E5=AD=98=E5=8F=B2 > NTT=E3=82=B5=E3=83=BC=E3=83=93=E3=82=B9=E3=82=A4=E3=83=B3=E3=83=86=E3=82= =B0=E3=83=AC=E3=83=BC=E3=82=B7=E3=83=A7=E3=83=B3=E5=9F=BA=E7=9B=A4=E7=A0=94= =E7=A9=B6=E6=89=80 > =E6=AC=A1=E4=B8=96=E4=BB=A3=E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC= =E3=82=AF=E6=96=B9=E5=BC=8FSE=E3=83=97=E3=83=AD=E3=82=B8=E3=82=A7=E3=82=AF= =E3=83=88 > =E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3=82=AF=E3=82=A2=E3=83=BC= =E3=82=AD=E3=83=86=E3=82=AF=E3=83=81=E3=83=A3=E3=82=B0=E3=83=AB=E3=83=BC=E3= =83=97 > TEL 0422-59-3334 FAX 0422-59-6364 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 -- =E6=9D=BE=E6=9C=AC =E5=AD=98=E5=8F=B2 NTT=E3=82=B5=E3=83=BC=E3=83=93=E3=82=B9=E3=82=A4=E3=83=B3=E3=83=86=E3=82=B0= =E3=83=AC=E3=83=BC=E3=82=B7=E3=83=A7=E3=83=B3=E5=9F=BA=E7=9B=A4=E7=A0=94=E7= =A9=B6=E6=89=80 =E6=AC=A1=E4=B8=96=E4=BB=A3=E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3= =82=AF=E6=96=B9=E5=BC=8FSE=E3=83=97=E3=83=AD=E3=82=B8=E3=82=A7=E3=82=AF=E3= =83=88 =E3=83=8D=E3=83=83=E3=83=88=E3=83=AF=E3=83=BC=E3=82=AF=E3=82=A2=E3=83=BC= =E3=82=AD=E3=83=86=E3=82=AF=E3=83=81=E3=83=A3=E3=82=B0=E3=83=AB=E3=83=BC=E3= =83=97 TEL 0422-59-3334 FAX 0422-59-6364 From volz@cisco.com Wed Feb 15 19:29:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A2121F856F for ; Wed, 15 Feb 2012 19:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.052 X-Spam-Level: X-Spam-Status: No, score=-9.052 tagged_above=-999 required=5 tests=[AWL=1.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op3O97+LjS1s for ; Wed, 15 Feb 2012 19:29:47 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77021F8550 for ; Wed, 15 Feb 2012 19:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=23812; q=dns/txt; s=iport; t=1329362987; x=1330572587; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=NiH0xqBwtFt+dWGDmfPbP3FDvbORWGsLlLi6pcO+1q4=; b=XUqAizLgB1IBvK0r/QXs5KVJb3JbV566jIM1wyVTQxV57AL4WoNboGiq c0DdZsVCLmdtX+FGqpBaCpzistg+a4kiEr5NXuB+c8FTY5IURSSkDWo0t RqNTWZek+lD/iBiVwciykpPDk3Kdg69roDJdERb/m93kiCJ35cXDv0aXC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACd3PE+tJXHA/2dsb2JhbABDDoI/rh2BB4FyAQEBBAEBAQ8BCREDHiALEAIBCA4DAwEBAQsCAQMQBwEGASAGChUJCAEBBAESCAEUBAGHZppxAZ5PiESDBQEBAQMIAQEBBQ0IAgIKCAQDAgQyg2FZCgIDAgEIAgqCTWMEiE2XfIceVg X-IronPort-AV: E=Sophos;i="4.73,426,1325462400"; d="scan'208,217";a="59320472" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 16 Feb 2012 03:29:46 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q1G3TkNc006429; Thu, 16 Feb 2012 03:29:46 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 21:29:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCEC5B.3B13642A" Date: Wed, 15 Feb 2012 21:29:46 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Thread-Index: AczsTh5w/jDKqkQmRUGXbqTC63DDVwAEy/fA References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> From: "Bernie Volz (volz)" To: "Huan Huan" , "Timothy Winters" X-OriginalArrivalTime: 16 Feb 2012 03:29:46.0433 (UTC) FILETIME=[3B154310:01CCEC5B] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 03:29:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEC5B.3B13642A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I don't really see what's wrong with EITHER a REBIND or CONFIRM (or even both, one for IA_PD and one for address). Not really sure why RFC 3633 didn't permit a Confirm. =20 However, if one does a strict read of the standards, the two (Confirm for address, Renew for PD) is what a client SHOULD do. =20 But, there's no reason a prefix can't be confirmed just as easily as an address. =20 Perhaps Ole had a reason for this in RFC 3633, but alas it is not documented (at least that I could see). =20 And, a Rebind (for an address) at any time isn't really "wrong". =20 For a compliance test, you are probably forced to follow the standards as that is the only thing that you can assure (a server may be strict in following RFC 3633 and consider a Confirm with prefixes "wrong"). (Cisco Network Registrar will deal with all of the possibilities.) - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Huan Huan Sent: Wednesday, February 15, 2012 8:56 PM To: Timothy Winters Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm =20 I don't think so. =20 2012/2/15 Timothy Winters Hi Huan, Is it ok to transmit just a Renew message containing both the IA_NA and IA_PD when the link goes down? =20 Regards, Tim On Feb 14, 2012, at 8:12 PM, Huan Huan wrote: Hi Tim, =20 I think CE Router may transmit Confirm msg containing the assigned IA_NA and Renew msg containing the assigned IA_PD separately. =20 BR, Huan=20 2012/2/15 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to =09 https://www.ietf.org/mailman/listinfo/dhcwg =09 Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. =09 =09 =09 Send dhcwg mailing list submissions to dhcwg@ietf.org =09 To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org =09 You can reach the person managing the list at dhcwg-owner@ietf.org =09 When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." =09 =09 Today's Topics: =09 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt (internet-drafts@ietf.org) 2. DHCP Renew vs Confirm (Timothy Winters) =09 =09 =09 ---------------------------------------------------------------------- =09 Message: 1 Date: Tue, 14 Feb 2012 02:40:41 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" =09 =09 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. =09 Title : Forcerenew Nonce Authentication Author(s) : David Miles Wojciech Dec James Bristow Roberta Maglione Filename : draft-ietf-dhc-forcerenew-nonce-04.txt Pages : 12 Date : 2012-02-14 =09 Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server sends a nonce to the client on the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. =09 =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.t xt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 This Internet-Draft can be retrieved at: =09 ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.tx t =09 =09 =09 ------------------------------ =09 Message: 2 Date: Tue, 14 Feb 2012 08:43:50 -0500 From: Timothy Winters To: dhcwg@ietf.org Subject: [dhcwg] DHCP Renew vs Confirm Message-ID: Content-Type: text/plain; charset=3Dus-ascii =09 Hello, While testing some CE Router implementations we have noticed a interesting behavior that is within the specifications but not clearly documented. I wanted to get the working group thoughts on this. =09 Currently when a CE Router acting as a DHCP client, assigned both IA_NA and IA_PD, is unplugged from the network. When reattached to the link the DHCP client transmits a DHCP Renew containing both the IA_NA and the IA_PD. =09 3315 Section 18.1.2 says that when link goes down a DHCP client implementation should transmit a DHCP Confirm message containing the assigned IA_NA. =09 3633 Section 12.1 doesn't allow the use of the Confirm message. It states that DHCP Renew message, containing the assigned IA_PD, should be used when the link goes down. =09 According to the specifications a DHCP client should retransmit DHCP Confirm and DHCP Renew when link goes up. The behavior we are seeing is the DHCP client transmits a DHCP renew containing both the IA_NA and IA_PD. =09 This behavior isn't causing interoperability issues as all the servers we have tried still respond properly to the DHCP Renew messages. =09 Is it ok when a DHCP client loses link for it to transmit one DHCP Renew message? =09 Regards, Tim UNH-IOL =09 =09 =09 ------------------------------ =09 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =09 =09 End of dhcwg Digest, Vol 94, Issue 13 ************************************* =09 =09 =09 =20 --=20 Huan Huan =20 --=20 Huan Huan ------_=_NextPart_001_01CCEC5B.3B13642A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I don’t really see what’s wrong with EITHER a REBIND or = CONFIRM (or even both, one for IA_PD and one for address). Not really = sure why RFC 3633 didn’t permit a Confirm.

 

However, if one does a strict read of the standards, the two (Confirm = for address, Renew for PD) is what a  client SHOULD = do.

 

But, there’s no reason a prefix can’t be confirmed just = as easily as an address.

 

Perhaps Ole had a reason for this in RFC 3633, but alas it is not = documented (at least that I could see).

 

And, a Rebind (for an address) at any time isn’t really = “wrong”.

 

For a compliance test, you are probably forced to follow the = standards as that is the only thing that you can assure (a server may be = strict in following RFC 3633 and consider a Confirm with prefixes = “wrong”). (Cisco Network Registrar will deal with all of the = possibilities.)

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Huan Huan
Sent: Wednesday, February 15, 2012 8:56 = PM
To: Timothy Winters
Cc: = dhcwg@ietf.org
Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew = vs Confirm

 

I don't = think so.

 

2012/2/15 Timothy Winters <twinters@iol.unh.edu>

Hi = Huan,

      = Is it ok to transmit just a Renew message containing both the IA_NA and = IA_PD when the link goes down?

 

Regards,

Tim



On Feb 14, 2012, at 8:12 PM, Huan = Huan <shawngespan@gmail.com> = wrote:

Hi Tim,

 

I = think CE Router may transmit Confirm msg containing the assigned = IA_NA and Renew msg containing the assigned IA_PD = separately.

 

BR,

Huan 

2012/2/15 <dhcwg-request@ietf.org>

If you have received this digest without all the = individual message
attachments you will need to update your digest = options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/dhcwg

= Click the 'Unsubscribe or edit options' button, log in, and set = "Get
MIME or Plain Text Digests?" to MIME.  You can = set this option
globally for all the list digests you receive at this = point.



Send dhcwg mailing list submissions to
  =      dhcwg@ietf.org

To subscribe or unsubscribe = via the World Wide Web, visit
       https://www.ietf.org/mailman/listinfo/dhcwg
or, = via email, send a message with subject or body 'help' to
  =      dhcwg-request@ietf.org

You can reach the = person managing the list at
       dhcwg-owner@ietf.org

When replying, please = edit your Subject line so it is more specific
than "Re: Contents = of dhcwg digest..."


Today's Topics:

  1. I-D = Action: draft-ietf-dhc-forcerenew-nonce-04.txt
    =  (internet-drafts@ietf.org)
  2. DHCP Renew = vs Confirm (Timothy = Winters)


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

Message: 1
Date: Tue, 14 Feb 2012 02:40:41 = -0800
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: = draft-ietf-dhc-forcerenew-nonce-04.txt
Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com= >
Content-Type: text/plain; = charset=3D"utf-8"


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       =     : Forcerenew Nonce Authentication
      =  Author(s)       : David Miles
    =                     =  Wojciech Dec
              =            James Bristow
    =                     =  Roberta Maglione
       Filename   =      : draft-ietf-dhc-forcerenew-nonce-04.txt
  =      Pages           : = 12
       Date           =  : 2012-02-14

  Dynamic Host Configuration Protocol = (DHCP) FORCERENEW allows for the
  reconfiguration of a single = host by forcing the DHCP client into a
  Renew state on a = trigger from the DHCP server.  In Forcerenew Nonce
  = Authentication the server sends a nonce to the client on the = initial
  DHCP ACK that is used for subsequent validation of a = FORCERENEW
  message.  This document updates RFC = 3203.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-forc= erenew-nonce-04.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This = Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-force= renew-nonce-04.txt



------------------------------
<= br>Message: 2
Date: Tue, 14 Feb 2012 08:43:50 -0500
From: Timothy = Winters <twinters@iol.unh.edu>
To: dhcwg@ietf.org
Subject: [dhcwg] DHCP Renew vs = Confirm
Message-ID: <C0CA95B6-1743-4D37-9BCC-D104453EBF9A@iol.unh.edu>= ;
Content-Type: text/plain; = charset=3Dus-ascii

Hello,
       While = testing some CE Router implementations we have noticed a interesting = behavior that is within the specifications but not clearly documented. =  I wanted to get the working group thoughts on this.

  =      Currently when a CE Router acting as a DHCP client, = assigned both IA_NA and IA_PD, is unplugged from the network.  When = reattached to the link the DHCP client transmits a DHCP Renew containing = both the IA_NA and the IA_PD.

       3315 = Section 18.1.2 says that when link goes down a DHCP client = implementation should transmit a DHCP Confirm message containing the = assigned IA_NA.

       3633 Section 12.1 = doesn't allow the use of the Confirm message.  It states that DHCP = Renew message, containing the assigned IA_PD, should be used when the = link goes down.

       According to the = specifications a DHCP client should retransmit DHCP Confirm and DHCP = Renew when link goes up.   The behavior we are seeing is the DHCP = client transmits a DHCP renew containing both the IA_NA and = IA_PD.

       This behavior isn't causing = interoperability issues as all the servers we have tried still respond = properly to the DHCP Renew messages.

      =  Is it ok when a DHCP client loses link for it to transmit one DHCP = Renew = message?

Regards,
Tim
UNH-IOL



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

_______________________________________________dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

=
End of dhcwg Digest, Vol 94, Issue = 13
*************************************



 

-- =
Huan = Huan



 

-- =
Huan Huan

------_=_NextPart_001_01CCEC5B.3B13642A-- From twinters@iol.unh.edu Wed Feb 15 20:53:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D4421E801A for ; Wed, 15 Feb 2012 20:53:29 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+xHrMyeHp99 for ; Wed, 15 Feb 2012 20:53:25 -0800 (PST) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with SMTP id 51D9921E8011 for ; Wed, 15 Feb 2012 20:53:24 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKTzyLwsW0rE+k9h/a551+U1ZECP1uA+pB@postini.com; Wed, 15 Feb 2012 20:53:24 PST Received: from openvpn-client28.iol.unh.edu (openvpn-client28.iol.unh.edu [132.177.124.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 4B68C8F0067; Wed, 15 Feb 2012 23:53:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_79C89CC5-E643-4119-95EA-6385858D6D0E" From: Timothy Winters In-Reply-To: Date: Wed, 15 Feb 2012 23:53:19 -0500 Message-Id: References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1257) Cc: dhcwg@ietf.org, Huan Huan Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 04:53:29 -0000 --Apple-Mail=_79C89CC5-E643-4119-95EA-6385858D6D0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Bernie, I asked Ole about this at V6 World Congress last week, and he = mentioned that it wasn't in RFC 3633 because Confirm is for detecting = on-link confirmation. It's possible I misunderstood him, if so he can = feel free to jump in. As you point out RFC 3315 doesn't prevent an implementation from = transmitting a Renew message when this happens. So they are within the = specification for transmitting the Renew message. The missing piece is = that we have DHCP clients, in this case CE Routers, that don't transmit = Confirm messages. RFC 3315 states a Confirm message should happen when a = device may have moved to another link, so unplugging the physical link = should cause a DHCP Confirm message when plugged back in. =20 Is a DHCP Client not following RFC 3315 if they don't transmit a = DHCP Confirm message?=20 Regards, Tim On Feb 15, 2012, at 10:29 PM, Bernie Volz (volz) wrote: > I don=92t really see what=92s wrong with EITHER a REBIND or CONFIRM = (or even both, one for IA_PD and one for address). Not really sure why = RFC 3633 didn=92t permit a Confirm. > =20 > However, if one does a strict read of the standards, the two (Confirm = for address, Renew for PD) is what a client SHOULD do. > =20 > But, there=92s no reason a prefix can=92t be confirmed just as easily = as an address. > =20 > Perhaps Ole had a reason for this in RFC 3633, but alas it is not = documented (at least that I could see). > =20 > And, a Rebind (for an address) at any time isn=92t really =93wrong=94. > =20 > For a compliance test, you are probably forced to follow the standards = as that is the only thing that you can assure (a server may be strict in = following RFC 3633 and consider a Confirm with prefixes =93wrong=94). = (Cisco Network Registrar will deal with all of the possibilities.) > - Bernie > =20 > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Huan Huan > Sent: Wednesday, February 15, 2012 8:56 PM > To: Timothy Winters > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm > =20 > I don't think so. > =20 > 2012/2/15 Timothy Winters > Hi Huan, > Is it ok to transmit just a Renew message containing both the = IA_NA and IA_PD when the link goes down? > =20 > Regards, > Tim >=20 >=20 > On Feb 14, 2012, at 8:12 PM, Huan Huan wrote: >=20 > Hi Tim, > =20 > I think CE Router may transmit Confirm msg containing the assigned = IA_NA and Renew msg containing the assigned IA_PD separately. > =20 > BR, > Huan=20 >=20 > 2012/2/15 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send dhcwg mailing list submissions to > dhcwg@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dhcwg > or, via email, send a message with subject or body 'help' to > dhcwg-request@ietf.org >=20 > You can reach the person managing the list at > dhcwg-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." >=20 >=20 > Today's Topics: >=20 > 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > (internet-drafts@ietf.org) > 2. DHCP Renew vs Confirm (Timothy Winters) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 14 Feb 2012 02:40:41 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" >=20 >=20 > 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. >=20 > Title : Forcerenew Nonce Authentication > Author(s) : David Miles > Wojciech Dec > James Bristow > Roberta Maglione > Filename : draft-ietf-dhc-forcerenew-nonce-04.txt > Pages : 12 > Date : 2012-02-14 >=20 > Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the > reconfiguration of a single host by forcing the DHCP client into a > Renew state on a trigger from the DHCP server. In Forcerenew Nonce > Authentication the server sends a nonce to the client on the initial > DHCP ACK that is used for subsequent validation of a FORCERENEW > message. This document updates RFC 3203. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 14 Feb 2012 08:43:50 -0500 > From: Timothy Winters > To: dhcwg@ietf.org > Subject: [dhcwg] DHCP Renew vs Confirm > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii >=20 > Hello, > While testing some CE Router implementations we have noticed a = interesting behavior that is within the specifications but not clearly = documented. I wanted to get the working group thoughts on this. >=20 > Currently when a CE Router acting as a DHCP client, assigned = both IA_NA and IA_PD, is unplugged from the network. When reattached to = the link the DHCP client transmits a DHCP Renew containing both the = IA_NA and the IA_PD. >=20 > 3315 Section 18.1.2 says that when link goes down a DHCP client = implementation should transmit a DHCP Confirm message containing the = assigned IA_NA. >=20 > 3633 Section 12.1 doesn't allow the use of the Confirm message. = It states that DHCP Renew message, containing the assigned IA_PD, = should be used when the link goes down. >=20 > According to the specifications a DHCP client should retransmit = DHCP Confirm and DHCP Renew when link goes up. The behavior we are = seeing is the DHCP client transmits a DHCP renew containing both the = IA_NA and IA_PD. >=20 > This behavior isn't causing interoperability issues as all the = servers we have tried still respond properly to the DHCP Renew messages. >=20 > Is it ok when a DHCP client loses link for it to transmit one = DHCP Renew message? >=20 > Regards, > Tim > UNH-IOL >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > End of dhcwg Digest, Vol 94, Issue 13 > ************************************* >=20 >=20 > =20 > --=20 > Huan Huan >=20 >=20 > =20 > --=20 > Huan Huan --Apple-Mail=_79C89CC5-E643-4119-95EA-6385858D6D0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Bernie,
I asked Ole about this at V6 = World Congress last week, and he mentioned that it wasn't in RFC 3633 = because Confirm is for detecting on-link confirmation.   It's = possible I misunderstood him, if so he can feel free to jump = in.

As you point out RFC 3315 = doesn't prevent an implementation from transmitting a Renew message when = this happens.   So they are within the specification for = transmitting the Renew message.  The missing piece is that we have = DHCP clients, in this case CE Routers, that don't transmit Confirm = messages. RFC 3315 states a Confirm message should happen when a device = may have moved to another link, so unplugging the physical link should = cause a DHCP Confirm message when plugged back in. =  

Is a DHCP Client not following = RFC 3315 if they don't transmit a DHCP Confirm = message? 

Regards,
Tim
<= br>
On Feb 15, 2012, at 10:29 PM, Bernie Volz (volz) = wrote:

I = don=92t really see what=92s wrong with EITHER a REBIND or CONFIRM (or = even both, one for IA_PD and one for address). Not really sure why RFC = 3633 didn=92t permit a Confirm.
But, = there=92s no reason a prefix can=92t be confirmed just as easily as an = address.
And, = a Rebind (for an address) at any time isn=92t really = =93wrong=94.
For a = compliance test, you are probably forced to follow the standards as that = is the only thing that you can assure (a server may be strict in = following RFC 3633 and consider a Confirm with prefixes =93wrong=94). = (Cisco Network Registrar will deal with all of the = possibilities.)
- Bernie
 dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On Behalf Of Huan = Huan
Sent: Wednesday, February 15, = 2012 8:56 PM
To: Timothy = Winters
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcwg Digest, = DHCP Renew vs Confirm
I don't think = so.
2012/2/15 Timothy Winters = <Hi Huan,
Hi Tim,
 
I think CE = Router may transmit Confirm msg containing the assigned IA_NA and = Renew msg containing the assigned IA_PD = separately.
Huan 

2012/2/15 <If you have = received this digest without all the individual message
attachments = you will need to update your digest options in your = list
subscription.  To do so, go to

MIME or = Plain Text Digests?" to MIME.  You can set this option
globally = for all the list digests you receive at this point.



Send = dhcwg mailing list submissions to
       dhcwg@ietf.org

To subscribe or = unsubscribe via the World Wide Web, visit
      =  dhcwg-owner@ietf.org

When = replying, please edit your Subject line so it is more specific
than = "Re: Contents of dhcwg digest..."


Today's = Topics:

  1. I-D Action: = draft-ietf-dhc-forcerenew-nonce-04.txt
     (   dhcwg@ietf.org
Subject: [dhcwg] I-D = Action: draft-ietf-dhc-forcerenew-nonce-04.txt
Message-ID: <

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       =     : Forcerenew Nonce Authentication
      =  Author(s)       : David Miles
    =                     =  Wojciech Dec
              =            James Bristow
    =                     =  Roberta Maglione
       Filename   =      : draft-ietf-dhc-forcerenew-nonce-04.txt
  =      Pages           : = 12
       Date           =  : 2012-02-14

  Dynamic Host Configuration Protocol = (DHCP) FORCERENEW allows for the
  reconfiguration of a single = host by forcing the DHCP client into a
  Renew state on a = trigger from the DHCP server.  In Forcerenew Nonce
  = Authentication the server sends a nonce to the client on the = initial
  DHCP ACK that is used for subsequent validation of a = FORCERENEW
  message.  This document updates RFC = 3203.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.t= xt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.tx= t



------------------------------

Message: = 2
Date: Tue, 14 Feb 2012 08:43:50 -0500
From: Timothy Winters = < dhcwg@ietf.org
Subject: [dhcwg] = DHCP Renew vs Confirm
Message-ID: <




= --Apple-Mail=_79C89CC5-E643-4119-95EA-6385858D6D0E-- From volz@cisco.com Wed Feb 15 21:13:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D5121F850F for ; Wed, 15 Feb 2012 21:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.31 X-Spam-Level: X-Spam-Status: No, score=-9.31 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSXyY0Bt1IuK for ; Wed, 15 Feb 2012 21:13:40 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 12FAD21F8525 for ; Wed, 15 Feb 2012 21:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=37780; q=dns/txt; s=iport; t=1329369220; x=1330578820; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ZOndQksb+Dd2E+5WxUfFaXSdclLNXAQMuO/S6LZDdTU=; b=LsydonJkXGNAA1YwYWYJssIFjimBRYpH38NWASfJIPxn3JBp25PVT3+u 0LlikwZXFCpLIytN0bOw2sbKY+TmuNhXnYuwgBfr0rhEmzB4Py2+rrUVk igAGWWKauM1IcAjFT0W9N/5+3MFsUsXplIz4fMqqLMH/E7TK7p6YwjkuS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEuQPE+tJV2Y/2dsb2JhbABDDoI/rh2BB4FyAQEBAwEBAQEPAQkRAx4gCwULAgEIDgMDAQEBCwIBAxABBgEGASAGChUJCAEBBBMIARQEAYddCZpmAZ5RiESDBQEBAQMGAgEBAQEBAQIMAQgCAgIIBAQEAwIEMoNhWQoCAwIBCAIKgk1jBIhNl3yHHlY X-IronPort-AV: E=Sophos;i="4.73,427,1325462400"; d="scan'208,217";a="59335865" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 16 Feb 2012 05:13:39 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1G5DcJA011639; Thu, 16 Feb 2012 05:13:38 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 23:13:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCEC69.BDCAD76F" Date: Wed, 15 Feb 2012 23:13:37 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Thread-Index: AczsZur1iI9DsMUFTcCY5z83kpMNswAAR+qQ References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> From: "Bernie Volz (volz)" To: "Timothy Winters" X-OriginalArrivalTime: 16 Feb 2012 05:13:38.0815 (UTC) FILETIME=[BDDF48F0:01CCEC69] Cc: dhcwg@ietf.org, Huan Huan Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 05:13:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEC69.BDCAD76F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > I asked Ole about this at V6 World Congress last week, and he mentioned that it wasn't in RFC 3633 because Confirm is for detecting on-link confirmation. It's possible I misunderstood him, if so he can feel free to jump in. =20 Any responding servers will indicate whether those addresses are appropriate for the link to which the client is attached with the status in the Reply message it returns to the client. =20 ... =20 NotOnLink 4 The prefix for the address is not appropriate for the link to which the client is attached. =20 I disagree as the RFC 3315 text never says "on-link" in the strict sense of what "on-link" means for IPv6. It says "appropriate for the link". The status code is "NotOnLink" but that is something that is definitive in the case when a delegate prefix is not 'appropriate' for the link. I believe Ralph was purposely careful in the language used in RFC 3315 that we didn't imply that an address was "on-link" in the sense of the L bit for ND. =20 I don't remember the timing of the documents and work on RFC 3633 might have started before RFC 3315 was finalized and perhaps an earlier 3315 draft had some different terminology which was more directly tied to "on-link". (Given that the RFC publication dates are only 6 months apart, I suspect they were worked on in parallel. While the IETF process was faster back then, it was never that fast.) =20 > Is a DHCP Client not following RFC 3315 if they don't transmit a DHCP Confirm message?=20 =20 In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. =20 =20 Thus, a strict read of RFC 3315 says it is required (MUST - not SHOULD). =20 Perhaps the above are items for -bis documents if they are ever done. Or, a new draft might want to propose a reconsidering of these issues? =20 - Bernie =20 From: Timothy Winters [mailto:twinters@iol.unh.edu]=20 Sent: Wednesday, February 15, 2012 11:53 PM To: Bernie Volz (volz) Cc: Huan Huan; dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm =20 Hi Bernie, I asked Ole about this at V6 World Congress last week, and he mentioned that it wasn't in RFC 3633 because Confirm is for detecting on-link confirmation. It's possible I misunderstood him, if so he can feel free to jump in. =20 As you point out RFC 3315 doesn't prevent an implementation from transmitting a Renew message when this happens. So they are within the specification for transmitting the Renew message. The missing piece is that we have DHCP clients, in this case CE Routers, that don't transmit Confirm messages. RFC 3315 states a Confirm message should happen when a device may have moved to another link, so unplugging the physical link should cause a DHCP Confirm message when plugged back in. =20 =20 Is a DHCP Client not following RFC 3315 if they don't transmit a DHCP Confirm message?=20 =20 Regards, Tim =20 On Feb 15, 2012, at 10:29 PM, Bernie Volz (volz) wrote: I don't really see what's wrong with EITHER a REBIND or CONFIRM (or even both, one for IA_PD and one for address). Not really sure why RFC 3633 didn't permit a Confirm. =20 However, if one does a strict read of the standards, the two (Confirm for address, Renew for PD) is what a client SHOULD do. =20 But, there's no reason a prefix can't be confirmed just as easily as an address. =20 Perhaps Ole had a reason for this in RFC 3633, but alas it is not documented (at least that I could see). =20 And, a Rebind (for an address) at any time isn't really "wrong". =20 For a compliance test, you are probably forced to follow the standards as that is the only thing that you can assure (a server may be strict in following RFC 3633 and consider a Confirm with prefixes "wrong"). (Cisco Network Registrar will deal with all of the possibilities.) - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Huan Huan Sent: Wednesday, February 15, 2012 8:56 PM To: Timothy Winters Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm =20 I don't think so. =20 2012/2/15 Timothy Winters Hi Huan, Is it ok to transmit just a Renew message containing both the IA_NA and IA_PD when the link goes down? =20 Regards, Tim On Feb 14, 2012, at 8:12 PM, Huan Huan wrote: Hi Tim, =20 I think CE Router may transmit Confirm msg containing the assigned IA_NA and Renew msg containing the assigned IA_PD separately. =20 BR, Huan=20 2012/2/15 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to =09 https://www.ietf.org/mailman/listinfo/dhcwg =09 Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. =09 =09 =09 Send dhcwg mailing list submissions to dhcwg@ietf.org =09 To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org =09 You can reach the person managing the list at dhcwg-owner@ietf.org =09 When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." =09 =09 Today's Topics: =09 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt (internet-drafts@ietf.org) 2. DHCP Renew vs Confirm (Timothy Winters) =09 =09 =09 ---------------------------------------------------------------------- =09 Message: 1 Date: Tue, 14 Feb 2012 02:40:41 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" =09 =09 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. =09 Title : Forcerenew Nonce Authentication Author(s) : David Miles Wojciech Dec James Bristow Roberta Maglione Filename : draft-ietf-dhc-forcerenew-nonce-04.txt Pages : 12 Date : 2012-02-14 =09 Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server sends a nonce to the client on the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. =09 =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.t xt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 This Internet-Draft can be retrieved at: =09 ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.tx t =09 =09 =09 ------------------------------ =09 Message: 2 Date: Tue, 14 Feb 2012 08:43:50 -0500 From: Timothy Winters To: dhcwg@ietf.org Subject: [dhcwg] DHCP Renew vs Confirm Message-ID: Content-Type: text/plain; charset=3Dus-ascii =09 Hello, While testing some CE Router implementations we have noticed a interesting behavior that is within the specifications but not clearly documented. I wanted to get the working group thoughts on this. =09 Currently when a CE Router acting as a DHCP client, assigned both IA_NA and IA_PD, is unplugged from the network. When reattached to the link the DHCP client transmits a DHCP Renew containing both the IA_NA and the IA_PD. =09 3315 Section 18.1.2 says that when link goes down a DHCP client implementation should transmit a DHCP Confirm message containing the assigned IA_NA. =09 3633 Section 12.1 doesn't allow the use of the Confirm message. It states that DHCP Renew message, containing the assigned IA_PD, should be used when the link goes down. =09 According to the specifications a DHCP client should retransmit DHCP Confirm and DHCP Renew when link goes up. The behavior we are seeing is the DHCP client transmits a DHCP renew containing both the IA_NA and IA_PD. =09 This behavior isn't causing interoperability issues as all the servers we have tried still respond properly to the DHCP Renew messages. =09 Is it ok when a DHCP client loses link for it to transmit one DHCP Renew message? =09 Regards, Tim UNH-IOL =09 =09 =09 ------------------------------ =09 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =09 =09 End of dhcwg Digest, Vol 94, Issue 13 ************************************* =09 =09 =09 =20 --=20 Huan Huan =20 --=20 Huan Huan =20 ------_=_NextPart_001_01CCEC69.BDCAD76F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

>       &nbs= p;  I asked Ole about this at V6 World Congress last week, = and he mentioned that it wasn't in RFC 3633 because Confirm is for = detecting on-link confirmation.   It's possible I misunderstood = him, if so he can feel free to jump in.

 

   Any = responding servers will indicate whether those

   = addresses are appropriate for the link to which the client = is

   = attached with the status in the Reply message it returns to = the

   = client.

 

…

 

   = NotOnLink       4 The prefix for the = address is not appropriate for

           &= nbsp;         the link to which = the client is attached.

 

I disagree as the RFC 3315 text never says “on-link” in = the strict sense of what “on-link” means for IPv6. It says = “appropriate for the link”. The status code is = “NotOnLink” but that is something that is definitive in the = case when a delegate prefix is not ‘appropriate’ for the = link. I believe Ralph was purposely careful in the language used in RFC = 3315 that we didn’t imply that an address was = “on-link” in the sense of the L bit for = ND.

 

I don’t remember the timing of the documents and work on RFC = 3633 might have started before RFC 3315 was finalized and perhaps an = earlier 3315 draft had some different terminology which was more = directly tied to “on-link”. (Given that the RFC publication = dates are only 6 months apart, I suspect they were worked on in = parallel. While the IETF process was faster back then, it was never that = fast.)

 

>       &nbs= p;  Is a DHCP Client not following RFC 3315 if they don't = transmit a DHCP Confirm message? 

 

   In any = situation when a client may have moved to a new link, = the

   client = MUST initiate a Confirm/Reply message exchange. 

 

Thus, a strict read of RFC 3315 says it is required (MUST – not = SHOULD).

 

Perhaps the above are items for -bis documents if they are ever done. = Or, a new draft might want to propose a reconsidering of these = issues?

 

-          = Bernie

 

From:= = Timothy Winters [mailto:twinters@iol.unh.edu]
Sent: = Wednesday, February 15, 2012 11:53 PM
To: Bernie Volz = (volz)
Cc: Huan Huan; dhcwg@ietf.org
Subject: Re: = [dhcwg] dhcwg Digest, DHCP Renew vs = Confirm

 

Hi = Bernie,

        &n= bsp;   I asked Ole about this at V6 World Congress last = week, and he mentioned that it wasn't in RFC 3633 because Confirm is for = detecting on-link confirmation.   It's possible I misunderstood = him, if so he can feel free to jump in.

 

        &n= bsp;   As you point out RFC 3315 doesn't prevent = an implementation from transmitting a Renew message when this happens. =   So they are within the specification for transmitting the Renew = message.  The missing piece is that we have DHCP clients, in this = case CE Routers, that don't transmit Confirm messages. RFC 3315 states a = Confirm message should happen when a device may have moved to another = link, so unplugging the physical link should cause a DHCP Confirm = message when plugged back in.  

 

        &n= bsp;   Is a DHCP Client not following RFC 3315 if they = don't transmit a DHCP Confirm message? 

 

Regards,

Tim

 

On = Feb 15, 2012, at 10:29 PM, Bernie Volz (volz) = wrote:



I don’t really see what’s wrong with EITHER a REBIND or = CONFIRM (or even both, one for IA_PD and one for address). Not really = sure why RFC 3633 didn’t permit a = Confirm.

 

However, if one does a strict read of the standards, the two (Confirm = for address, Renew for PD) is what a  client SHOULD = do.

 

But, there’s no reason a prefix can’t be confirmed just = as easily as an address.

 

Perhaps Ole had a reason for this in RFC 3633, but alas it is not = documented (at least that I could = see).

 

And, a Rebind (for an address) at any time isn’t really = “wrong”.

 

For a compliance test, you are probably forced to follow the = standards as that is the only thing that you can assure (a server may be = strict in following RFC 3633 and consider a Confirm with prefixes = “wrong”). (Cisco Network Registrar will deal with all of the = possibilities.)

-     &nb= sp;    Bernie

 

From:=  dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@iet= f.org] On Behalf = Of Huan = Huan
Sent: Wednesday, February 15, 2012 = 8:56 PM
To: Timothy = Winters
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcwg Digest, = DHCP Renew vs Confirm

 

I = don't think so.

 

2012/2/15 Timothy Winters <twinters@iol.unh.edu>

Hi = Huan,

  =     Is it ok to transmit just a Renew message containing both = the IA_NA and IA_PD when the link goes = down?

 

Regards,

Tim



On Feb 14, 2012, at 8:12 PM, Huan = Huan <shawngespan@gmail.com> = wrote:

Hi Tim,

 

I think CE Router may transmit Confirm = msg containing the assigned IA_NA and Renew msg containing the = assigned IA_PD separately.

 

BR,

Huan 

If you have received this digest without all the = individual message
attachments you will need to update your digest = options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/dhcwg

= Click the 'Unsubscribe or edit options' button, log in, and set = "Get
MIME or Plain Text Digests?" to MIME.  You can = set this option
globally for all the list digests you receive at this = point.



Send dhcwg mailing list submissions to
  =      dhcwg@ietf.org

To subscribe or unsubscribe = via the World Wide Web, visit
       https://www.ietf.org/mailman/listinfo/dhcwg
or, = via email, send a message with subject or body 'help' to
  =      dhcwg-request@ietf.org

You can reach the = person managing the list at
       dhcwg-owner@ietf.org

When replying, please = edit your Subject line so it is more specific
than "Re: Contents = of dhcwg digest..."


Today's Topics:

  1. I-D = Action: draft-ietf-dhc-forcerenew-nonce-04.txt
    =  (internet-drafts@ietf.org)
  2. DHCP Renew = vs Confirm (Timothy = Winters)


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

Message: 1
Date: Tue, 14 Feb 2012 02:40:41 = -0800
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: = draft-ietf-dhc-forcerenew-nonce-04.txt
Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com= >
Content-Type: text/plain; = charset=3D"utf-8"


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       =     : Forcerenew Nonce Authentication
      =  Author(s)       : David Miles
    =                     =  Wojciech Dec
              =            James Bristow
    =                     =  Roberta Maglione
       Filename   =      : draft-ietf-dhc-forcerenew-nonce-04.txt
  =      Pages           : = 12
       Date           =  : 2012-02-14

  Dynamic Host Configuration Protocol = (DHCP) FORCERENEW allows for the
  reconfiguration of a single = host by forcing the DHCP client into a
  Renew state on a = trigger from the DHCP server.  In Forcerenew Nonce
  = Authentication the server sends a nonce to the client on the = initial
  DHCP ACK that is used for subsequent validation of a = FORCERENEW
  message.  This document updates RFC = 3203.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-forc= erenew-nonce-04.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This = Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-force= renew-nonce-04.txt



------------------------------
<= br>Message: 2
Date: Tue, 14 Feb 2012 08:43:50 -0500
From: Timothy = Winters <twinters@iol.unh.edu>
To: dhcwg@ietf.org
Subject: [dhcwg] DHCP Renew vs = Confirm
Message-ID: <C0CA95B6-1743-4D37-9BCC-D104453EBF9A@iol.unh.edu>= ;
Content-Type: text/plain; = charset=3Dus-ascii

Hello,
       While = testing some CE Router implementations we have noticed a interesting = behavior that is within the specifications but not clearly documented. =  I wanted to get the working group thoughts on this.

  =      Currently when a CE Router acting as a DHCP client, = assigned both IA_NA and IA_PD, is unplugged from the network.  When = reattached to the link the DHCP client transmits a DHCP Renew containing = both the IA_NA and the IA_PD.

       3315 = Section 18.1.2 says that when link goes down a DHCP client = implementation should transmit a DHCP Confirm message containing the = assigned IA_NA.

       3633 Section 12.1 = doesn't allow the use of the Confirm message.  It states that DHCP = Renew message, containing the assigned IA_PD, should be used when the = link goes down.

       According to the = specifications a DHCP client should retransmit DHCP Confirm and DHCP = Renew when link goes up.   The behavior we are seeing is the DHCP = client transmits a DHCP renew containing both the IA_NA and = IA_PD.

       This behavior isn't causing = interoperability issues as all the servers we have tried still respond = properly to the DHCP Renew messages.

      =  Is it ok when a DHCP client loses link for it to transmit one DHCP = Renew = message?

Regards,
Tim
UNH-IOL



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

_______________________________________________dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

=
End of dhcwg Digest, Vol 94, Issue = 13
*************************************



 

-- 
Huan = Huan



 

-- 
Huan = Huan

 

------_=_NextPart_001_01CCEC69.BDCAD76F-- From shawngespan@gmail.com Wed Feb 15 21:41:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A9C21E803C for ; Wed, 15 Feb 2012 21:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18bIXbN9KDKx for ; Wed, 15 Feb 2012 21:41:51 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13921E804D for ; Wed, 15 Feb 2012 21:41:39 -0800 (PST) Received: by bkuw12 with SMTP id w12so1794030bku.31 for ; Wed, 15 Feb 2012 21:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d63UAIpVdzCFaSCuVFLOAak6rhFyTYpMeg9W0oVkvhg=; b=IeUrdVVcCVGuvFlmaO+cSaRKfKvLMZ9OkzmmCfmgZlXKEFLZbv7yxlQMPiTCbXmKv3 xZpK5i5cIEE8GuUZsWNmbea+UyI6wCqRCSZ9puUMj2d7mkq2KJvnH8FFWKmiZSv8KfCO jVnRxGC4JQ7x+0oV5guqkegDsGl00a75Cq0UY= MIME-Version: 1.0 Received: by 10.204.128.211 with SMTP id l19mr472180bks.59.1329370896781; Wed, 15 Feb 2012 21:41:36 -0800 (PST) Received: by 10.205.81.8 with HTTP; Wed, 15 Feb 2012 21:41:36 -0800 (PST) In-Reply-To: References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> Date: Thu, 16 Feb 2012 13:41:36 +0800 Message-ID: From: Huan Huan To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=0015173ff3e213d32c04b90e48d6 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 05:41:58 -0000 --0015173ff3e213d32c04b90e48d6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Bernie's option "a server may be strict in following RFC 3633 and consider a Confirm with prefixes =93wrong=94", maybe this either Renew = or Confirm causing an interoperability issue. 2012/2/16 Bernie Volz (volz) > I don=92t really see what=92s wrong with EITHER a REBIND or CONFIRM (or e= ven > both, one for IA_PD and one for address). Not really sure why RFC 3633 > didn=92t permit a Confirm.**** > > ** ** > > However, if one does a strict read of the standards, the two (Confirm for > ayinqiddress, Renew for PD) is what a client SHOULD do.**** > > ** ** > > But, there=92s no reason a prefix can=92t be confirmed just as easily as = an > address.**** > > ** ** > > Perhaps Ole had a reason for this in RFC 3633, but alas it is not > documented (at least that I could see).**** > > ** ** > > And, a Rebind (for an address) at any time isn=92t really =93wrong=94.***= * > > ** ** > > For a compliance test, you are probably forced to follow the standards as > that is the only thing that you can assure (a server may be strict in > following RFC 3633 and consider a Confirm with prefixes =93wrong=94). (Ci= sco > Network Registrar will deal with all of the possibilities.)**** > > **** > > **- **Bernie**** > > ** ** > > *From:* dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] *On Behalf > Of *Huan Huan > *Sent:* Wednesday, February 15, 2012 8:56 PM > *To:* Timothy Winters > *Cc:* dhcwg@ietf.org > *Subject:* Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm**** > > ** ** > > I don't think so.**** > > ** ** > > 2012/2/15 Timothy Winters **** > > Hi Huan,**** > > Is it ok to transmit just a Renew message containing both the IA_NA > and IA_PD when the link goes down?**** > > ** ** > > Regards,**** > > Tim**** > > > > On Feb 14, 2012, at 8:12 PM, Huan Huan wrote:**** > > Hi Tim,**** > > ** ** > > I think CE Router may transmit Confirm msg containing the assigned IA_NA > and Renew msg containing the assigned IA_PD separately.**** > > ** ** > > BR,**** > > Huan **** > > 2012/2/15 **** > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/dhcwg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send dhcwg mailing list submissions to > dhcwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dhcwg > or, via email, send a message with subject or body 'help' to > dhcwg-request@ietf.org > > You can reach the person managing the list at > dhcwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." > > > Today's Topics: > > 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > (internet-drafts@ietf.org) > 2. DHCP Renew vs Confirm (Timothy Winters) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Feb 2012 02:40:41 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt > Message-ID: <20120214104041.23040.30559.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" > > > 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 : Forcerenew Nonce Authentication > Author(s) : David Miles > Wojciech Dec > James Bristow > Roberta Maglione > Filename : draft-ietf-dhc-forcerenew-nonce-04.txt > Pages : 12 > Date : 2012-02-14 > > Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the > reconfiguration of a single host by forcing the DHCP client into a > Renew state on a trigger from the DHCP server. In Forcerenew Nonce > Authentication the server sends a nonce to the client on the initial > DHCP ACK that is used for subsequent validation of a FORCERENEW > message. This document updates RFC 3203. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.tx= t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt > > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Feb 2012 08:43:50 -0500 > From: Timothy Winters > To: dhcwg@ietf.org > Subject: [dhcwg] DHCP Renew vs Confirm > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii > > Hello, > While testing some CE Router implementations we have noticed a > interesting behavior that is within the specifications but not clearly > documented. I wanted to get the working group thoughts on this. > > Currently when a CE Router acting as a DHCP client, assigned both > IA_NA and IA_PD, is unplugged from the network. When reattached to the > link the DHCP client transmits a DHCP Renew containing both the IA_NA and > the IA_PD. > > 3315 Section 18.1.2 says that when link goes down a DHCP client > implementation should transmit a DHCP Confirm message containing the > assigned IA_NA. > > 3633 Section 12.1 doesn't allow the use of the Confirm message. I= t > states that DHCP Renew message, containing the assigned IA_PD, should be > used when the link goes down. > > According to the specifications a DHCP client should retransmit > DHCP Confirm and DHCP Renew when link goes up. The behavior we are seei= ng > is the DHCP client transmits a DHCP renew containing both the IA_NA and > IA_PD. > > This behavior isn't causing interoperability issues as all the > servers we have tried still respond properly to the DHCP Renew messages. > > Is it ok when a DHCP client loses link for it to transmit one DHCP > Renew message? > > Regards, > Tim > UNH-IOL > > > > ------------------------------ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > End of dhcwg Digest, Vol 94, Issue 13 > ***************************************** > > > > **** > > ** ** > > -- > Huan Huan**** > > > > **** > > ** ** > > -- > Huan Huan**** > --=20 Huan Huan --0015173ff3e213d32c04b90e48d6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Bernie's option "a server may be strict in fo= llowing RFC 3633 and consider a Confirm with prefixes =93wrong=94&qu= ot;, maybe this either Renew or Confirm=A0causing=A0an=A0interoperability=A0issue.

2012/2/16 Bernie Volz (volz) <volz@cisco.com>

I don=92t really see what=92s wrong with EIT= HER a REBIND or CONFIRM (or even both, one for IA_PD and one for address). = Not really sure why RFC 3633 didn=92t permit a Confirm.

=A0<= /p>

However, if one does a= strict read of the standards, the two (Confirm for ayinqiddress, Renew for= PD) is what a =A0client SHOULD do.

=A0<= /p>

But, there=92s no reas= on a prefix can=92t be confirmed just as easily as an address.

=A0<= /p>

Perhaps Ole had a reas= on for this in RFC 3633, but alas it is not documented (at least that I cou= ld see).

=A0<= /p>

And, a Rebind (for an = address) at any time isn=92t really =93wrong=94.

=A0<= /p>

For a compliance test,= you are probably forced to follow the standards as that is the only thing = that you can assure (a server may be strict in following RFC 3633 and consi= der a Confirm with prefixes =93wrong=94). (Cisco Network Registrar will dea= l with all of the possibilities.)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= u>Bernie

=A0<= /p>

From: dhcwg-bounces@ietf.o= rg [mailto:= dhcwg-bounces@ietf.org] On Behalf Of Huan Huan
Sent: Wednesday, February 15, 2012 8:56 PM
To: Timothy Win= ters
Cc: dhcw= g@ietf.org
Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs C= onfirm

=A0

I don't think so.

=A0

2012/2/15 Timothy W= inters <twinte= rs@iol.unh.edu>

Hi Huan,

=A0 =A0 =A0 Is it ok to transmit just a Renew message con= taining both the IA_NA and IA_PD when the link goes down?

=

=A0

Regards,

Tim<= /u>



On Feb 14, 2012, at 8:12 PM, Huan Huan <shawngespan@gmail.com> wrote:

Hi Tim,

=A0

I think = CE Router may transmit Confirm msg=A0containing the assigned IA_NA and Rene= w msg=A0containing the assigned IA_PD separately.

=A0

BR,

Huan=A0

201= 2/2/15 <dhcw= g-request@ietf.org>

If you have received this digest without all the ind= ividual message
attachments you will need to update your digest options = in your list
subscription. =A0To do so, go to

https://www.ietf.org= /mailman/listinfo/dhcwg

Click the 'Unsubscribe or edit options' button, log in, and set= "Get
MIME or Plain Text Digests?" to MIME. =A0You can set thi= s option
globally for all the list digests you receive at this point.


Send dhcwg mailing list submissions to
=A0 =A0 =A0 =A0dhcwg@ietf.org

To = subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0htt= ps://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
=A0= =A0 =A0 =A0dhc= wg-request@ietf.org

You can reach the person managing the list a= t
=A0 =A0 =A0 =A0dhcwg-owner@ietf.org

When replying, please edit your Subject line so it is more specific
= than "Re: Contents of dhcwg digest..."


Today's Top= ics:

=A0 1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
=A0 =A0 =A0(i= nternet-drafts@ietf.org)
=A0 2. DHCP Renew vs Confirm (Timothy Winte= rs)


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

Message: 1
Date: Tue, 14 Feb 2012 02:40:41 -0800
From: internet-drafts@ietf.or= g
To: i-d= -announce@ietf.org
Cc: dhcwg@ietf.org<= br>Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
M= essage-ID: <20120214104041.23040.30559.idtracker@ietfa.ams= l.com>
Content-Type: text/plain; charset=3D"utf-8"


A New Inte= rnet-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.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Forcerenew Nonce Authenticat= ion
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : David Miles
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wojciech Dec
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0James Bristow
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0Roberta Maglione
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-forcerenew-nonce-04= .txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0Dat= e =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-14

=A0 Dynamic Host Configuration= Protocol (DHCP) FORCERENEW allows for the
=A0 reconfiguration of a sing= le host by forcing the DHCP client into a
=A0 Renew state on a trigger from the DHCP server. =A0In Forcerenew Nonce=A0 Authentication the server sends a nonce to the client on the initial<= br>=A0 DHCP ACK that is used for subsequent validation of a FORCERENEW
= =A0 message. =A0This document updates RFC 3203.


A URL for this Internet-Draft is:
= http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt<= /a>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/in= ternet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-f= orcerenew-nonce-04.txt



------------------------------

Message: 2
Date: Tue, = 14 Feb 2012 08:43:50 -0500
From: Timothy Winters <twinters@iol.unh.edu>
To: = dhcwg@ietf.org
Subject: [dhcwg] DHCP Renew vs Confirm
Message-ID: <C0CA95= B6-1743-4D37-9BCC-D104453EBF9A@iol.unh.edu>
Content-Type: text/pl= ain; charset=3Dus-ascii

Hello,
=A0 =A0 =A0 =A0While testing some CE Router implementations w= e have noticed a interesting behavior that is within the specifications but= not clearly documented. =A0I wanted to get the working group thoughts on t= his.

=A0 =A0 =A0 =A0Currently when a CE Router acting as a DHCP client, assi= gned both IA_NA and IA_PD, is unplugged from the network. =A0When reattache= d to the link the DHCP client transmits a DHCP Renew containing both the IA= _NA and the IA_PD.

=A0 =A0 =A0 =A03315 Section 18.1.2 says that when link goes down a DHCP= client implementation should transmit a DHCP Confirm message containing th= e assigned IA_NA.

=A0 =A0 =A0 =A03633 Section 12.1 doesn't allow= the use of the Confirm message. =A0It states that DHCP Renew message, cont= aining the assigned IA_PD, should be used when the link goes down.

=A0 =A0 =A0 =A0According to the specifications a DHCP client should ret= ransmit DHCP Confirm and DHCP Renew when link goes up. =A0 The behavior we = are seeing is the DHCP client transmits a DHCP renew containing both the IA= _NA and IA_PD.

=A0 =A0 =A0 =A0This behavior isn't causing interoperability issues = as all the servers we have tried still respond properly to the DHCP Renew m= essages.

=A0 =A0 =A0 =A0Is it ok when a DHCP client loses link for i= t to transmit one DHCP Renew message?

Regards,
Tim
UNH-IOL



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

_______________________________________________
dhcwg mailing l= ist
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


End of dhcwg Dige= st, Vol 94, Issue 13
*************************************=



<= p class=3D"MsoNormal">=A0

-- =
Huan Huan

<= /div>



= =A0

--
Huan Huan




--
Huan Huan
--0015173ff3e213d32c04b90e48d6-- From ichiroumakino@gmail.com Wed Feb 15 23:46:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6A721F85E1 for ; Wed, 15 Feb 2012 23:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGTmZ+j+24qn for ; Wed, 15 Feb 2012 23:46:00 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A621F85F6 for ; Wed, 15 Feb 2012 23:45:58 -0800 (PST) Received: by wibhm9 with SMTP id hm9so1278140wib.31 for ; Wed, 15 Feb 2012 23:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=F2zMiLWyRINq0QKm1gvMVRNYrKAl3Haf6K7gDPKgcrw=; b=ld+F4w0Ak4K3UU19C/ohNsGqPNcOijS5Oxptzs+13fJ7H+arj4fBdmyvwFUfQGP+/O 6SRh4a6o5gBNrdCSoh/QbaqqRm1Iczx8XqWx8/unQqLMAAwvmUT7JCZ42UA+Cf7iC78/ Y9Eni5mHaI7sTiR1iK7RJ2dSMGugVlka9a0uE= Received: by 10.180.89.71 with SMTP id bm7mr13300446wib.20.1329378353531; Wed, 15 Feb 2012 23:45:53 -0800 (PST) Received: from [10.147.11.77] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id s2sm22523999wix.3.2012.02.15.23.45.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 23:45:52 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 16 Feb 2012 08:45:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1257) Cc: dhcwg@ietf.org, Huan Huan Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 07:46:01 -0000 Bernie, Tim, > > I asked Ole about this at V6 World Congress last week, and = he mentioned that it wasn't in RFC 3633 because Confirm is for detecting = on-link confirmation. It's possible I misunderstood him, if so he can = feel free to jump in. > =20 > Any responding servers will indicate whether those > addresses are appropriate for the link to which the client is > attached with the status in the Reply message it returns to the > client. > =20 > =85 > =20 > NotOnLink 4 The prefix for the address is not appropriate for > the link to which the client is attached. > =20 > I disagree as the RFC 3315 text never says =93on-link=94 in the strict = sense of what =93on-link=94 means for IPv6. It says =93appropriate for = the link=94. The status code is =93NotOnLink=94 but that is something = that is definitive in the case when a delegate prefix is not = =91appropriate=92 for the link. I believe Ralph was purposely careful in = the language used in RFC 3315 that we didn=92t imply that an address was = =93on-link=94 in the sense of the L bit for ND. > =20 > I don=92t remember the timing of the documents and work on RFC 3633 = might have started before RFC 3315 was finalized and perhaps an earlier = 3315 draft had some different terminology which was more directly tied = to =93on-link=94. (Given that the RFC publication dates are only 6 = months apart, I suspect they were worked on in parallel. While the IETF = process was faster back then, it was never that fast.) let me see if I can recall the rationale. CONFIRM (4) A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected. 1) minor point on CONFIRM wording. CONFIRM specifically refers to = addresses and appropriateness to a link. delegated prefixes are never = appropriate to the link between client and server. 2) a confirm message can be replied to by _any_ DHCP server, regardless = of that server having the binding or not. as there is no way for a = server without a binding to know if a prefix is "appropriate" or not, we = wanted to ensure that only the server with the binding would reply. thus = we had to use RENEW. cheers, Ole= From volz@cisco.com Thu Feb 16 04:27:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DCC21F87C7 for ; Thu, 16 Feb 2012 04:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.311 X-Spam-Level: X-Spam-Status: No, score=-8.311 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhB2fWHYmGrZ for ; Thu, 16 Feb 2012 04:27:29 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 602FB21F87B7 for ; Thu, 16 Feb 2012 04:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=4164; q=dns/txt; s=iport; t=1329395249; x=1330604849; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=xbSxSUaUrtxQXfXdZF8al3ziAsGzf2nJNikOs5XqxWI=; b=EYTCrByuqbzg9rh/8sVb/iZsedIHydcX53bYWg+ceCIy95C8sqteGGlH 1f5oKmtM8SdaE/1pqLjth1NHRQlM9JhEGnKEjYQpuAq3svBSY9Rcw6t/o F2TudNoL6CwkJc+/caJCNQn3PKaKTrzs3vNFxzvNSyrj6fUbeJLUmUsjk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEKAKz1PE+tJV2Y/2dsb2JhbABDhRWqX20CgQeBcgEBAQMBEgEQEUUFCwIBCBoCJgICAlUBAQQTIoddnyQBjGWJe4EvijcEBAEGAwMGAQIEAggCAwk/CQKGQzNjBIhOjGmTBg X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208";a="59416320" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 16 Feb 2012 12:27:28 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1GCRSiw003500; Thu, 16 Feb 2012 12:27:28 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 06:27:28 -0600 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-RCD-101.cisco.com ([72.163.62.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Feb 2012 12:27:28 +0000 References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> Content-Transfer-Encoding: base64 From: "Bernie Volz (volz)" Content-Type: text/plain; charset="utf-8" Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Thread-Index: AczspliqNW7Gm10YThCDjgj+mMujdA== In-Reply-To: Message-ID: <7EDA08F5-F94C-4B7F-977F-78620DB8DC63@cisco.com> Date: Thu, 16 Feb 2012 07:27:29 -0500 To: =?UTF-8?B?T2xlIFRyw7hhbg==?= MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 16 Feb 2012 12:27:28.0644 (UTC) FILETIME=[58DBFC40:01CCECA6] Cc: dhcwg@ietf.org, Huan Huan Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:27:33 -0000 T2xlOg0KDQozMzE1IG9ubHkgaGFuZGxlcyBhZGRyZXNzIHNvIG5vdCBzdXJwcmlzZSBhYm91dCBp dHMgd29yZGluZy4NCg0KQ29uZmlybSBzdXBwb3J0cyB0aHJlZSBwb3NzYWJpbGl0aWVzIC0gb2ss IG5vdCBvaywgY2FuJ3Qgc2F5LiBBbmQgUEQgaXMgdXN1YWxseSBkb25lIGJ5IGRlbGVnYXRpbmcg ZnJvbSBhIHNob3J0ZXIgcHJlZml4IHNvIHRoZSBhcHByb3ByaWF0ZSB0ZXN0IGNhbiBiZSBhcHBs aWVkIHRoZW4uIFllcywgdGhlcmUgbWF5IGJlIHNpdHVhdGlvbnMgd2hlcmUgdGhhdCBpcyBub3Qg ZG9uZSBhbmQgdGhlbiBhIHNlcnZlciBtaWdodCBub3QgYmUgYWJsZSB0byBwcm92aWRlIGFuIGFu c3dlci4NCg0KQWdyZWUgdGhhdCBDb25maXJtIGlzIHdlYWtlciBhcyBpdCBwcm92aWRlcyBubyBh bnN3ZXIgYXMgdG8gd2hldGhlciB0aGUgaW5mb3JtYXRpb24gaXMgdmFsaWQgZm9yICJ0aGF0IiBj bGllbnQgLSBqdXN0IHRoYXQgdGhlIGNsaWVudCBpcyBtb3N0IGxpa2VseSBzdGlsbCBjb25uZWN0 ZWQgdG8gd2hlcmUgaXQgd2FzIHByZXZpb3VzbHkuDQoNCi0gQmVybmllDQoNClNlbnQgZnJvbSBt eSBpUGFkDQoNCk9uIEZlYiAxNiwgMjAxMiwgYXQgMjo0NSBBTSwgT2xlIFRyw7hhbiA8b3Ryb2Fu QGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KDQo+IEJlcm5pZSwgVGltLA0KPiANCj4+PiAgICAgICAg IEkgYXNrZWQgT2xlIGFib3V0IHRoaXMgYXQgVjYgV29ybGQgQ29uZ3Jlc3MgbGFzdCB3ZWVrLCBh bmQgaGUgbWVudGlvbmVkIHRoYXQgaXQgd2Fzbid0IGluIFJGQyAzNjMzIGJlY2F1c2UgQ29uZmly bSBpcyBmb3IgZGV0ZWN0aW5nIG9uLWxpbmsgY29uZmlybWF0aW9uLiAgIEl0J3MgcG9zc2libGUg SSBtaXN1bmRlcnN0b29kIGhpbSwgaWYgc28gaGUgY2FuIGZlZWwgZnJlZSB0byBqdW1wIGluLg0K Pj4gDQo+PiAgIEFueSByZXNwb25kaW5nIHNlcnZlcnMgd2lsbCBpbmRpY2F0ZSB3aGV0aGVyIHRo b3NlDQo+PiAgIGFkZHJlc3NlcyBhcmUgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaW5rIHRvIHdoaWNo IHRoZSBjbGllbnQgaXMNCj4+ICAgYXR0YWNoZWQgd2l0aCB0aGUgc3RhdHVzIGluIHRoZSBSZXBs eSBtZXNzYWdlIGl0IHJldHVybnMgdG8gdGhlDQo+PiAgIGNsaWVudC4NCj4+IA0KPj4g4oCmDQo+ PiANCj4+ICAgTm90T25MaW5rICAgICAgIDQgVGhlIHByZWZpeCBmb3IgdGhlIGFkZHJlc3MgaXMg bm90IGFwcHJvcHJpYXRlIGZvcg0KPj4gICAgICAgICAgICAgICAgICAgICB0aGUgbGluayB0byB3 aGljaCB0aGUgY2xpZW50IGlzIGF0dGFjaGVkLg0KPj4gDQo+PiBJIGRpc2FncmVlIGFzIHRoZSBS RkMgMzMxNSB0ZXh0IG5ldmVyIHNheXMg4oCcb24tbGlua+KAnSBpbiB0aGUgc3RyaWN0IHNlbnNl IG9mIHdoYXQg4oCcb24tbGlua+KAnSBtZWFucyBmb3IgSVB2Ni4gSXQgc2F5cyDigJxhcHByb3By aWF0ZSBmb3IgdGhlIGxpbmvigJ0uIFRoZSBzdGF0dXMgY29kZSBpcyDigJxOb3RPbkxpbmvigJ0g YnV0IHRoYXQgaXMgc29tZXRoaW5nIHRoYXQgaXMgZGVmaW5pdGl2ZSBpbiB0aGUgY2FzZSB3aGVu IGEgZGVsZWdhdGUgcHJlZml4IGlzIG5vdCDigJhhcHByb3ByaWF0ZeKAmSBmb3IgdGhlIGxpbmsu IEkgYmVsaWV2ZSBSYWxwaCB3YXMgcHVycG9zZWx5IGNhcmVmdWwgaW4gdGhlIGxhbmd1YWdlIHVz ZWQgaW4gUkZDIDMzMTUgdGhhdCB3ZSBkaWRu4oCZdCBpbXBseSB0aGF0IGFuIGFkZHJlc3Mgd2Fz IOKAnG9uLWxpbmvigJ0gaW4gdGhlIHNlbnNlIG9mIHRoZSBMIGJpdCBmb3IgTkQuDQo+PiANCj4+ IEkgZG9u4oCZdCByZW1lbWJlciB0aGUgdGltaW5nIG9mIHRoZSBkb2N1bWVudHMgYW5kIHdvcmsg b24gUkZDIDM2MzMgbWlnaHQgaGF2ZSBzdGFydGVkIGJlZm9yZSBSRkMgMzMxNSB3YXMgZmluYWxp emVkIGFuZCBwZXJoYXBzIGFuIGVhcmxpZXIgMzMxNSBkcmFmdCBoYWQgc29tZSBkaWZmZXJlbnQg dGVybWlub2xvZ3kgd2hpY2ggd2FzIG1vcmUgZGlyZWN0bHkgdGllZCB0byDigJxvbi1saW5r4oCd LiAoR2l2ZW4gdGhhdCB0aGUgUkZDIHB1YmxpY2F0aW9uIGRhdGVzIGFyZSBvbmx5IDYgbW9udGhz IGFwYXJ0LCBJIHN1c3BlY3QgdGhleSB3ZXJlIHdvcmtlZCBvbiBpbiBwYXJhbGxlbC4gV2hpbGUg dGhlIElFVEYgcHJvY2VzcyB3YXMgZmFzdGVyIGJhY2sgdGhlbiwgaXQgd2FzIG5ldmVyIHRoYXQg ZmFzdC4pDQo+IA0KPiBsZXQgbWUgc2VlIGlmIEkgY2FuIHJlY2FsbCB0aGUgcmF0aW9uYWxlLg0K PiANCj4gICAgICBDT05GSVJNICg0KSAgICAgICAgQSBjbGllbnQgc2VuZHMgYSBDb25maXJtIG1l c3NhZ2UgdG8gYW55DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGF2YWlsYWJsZSBzZXJ2ZXIg dG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJl c3NlcyBpdCB3YXMgYXNzaWduZWQgYXJlIHN0aWxsIGFwcHJvcHJpYXRlDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgIHRvIHRoZSBsaW5rIHRvIHdoaWNoIHRoZSBjbGllbnQgaXMgY29ubmVjdGVk Lg0KPiANCj4gMSkgbWlub3IgcG9pbnQgb24gQ09ORklSTSB3b3JkaW5nLiBDT05GSVJNIHNwZWNp ZmljYWxseSByZWZlcnMgdG8gYWRkcmVzc2VzIGFuZCBhcHByb3ByaWF0ZW5lc3MgdG8gYSBsaW5r LiBkZWxlZ2F0ZWQgcHJlZml4ZXMgYXJlIG5ldmVyIGFwcHJvcHJpYXRlIHRvIHRoZSBsaW5rIGJl dHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIuDQo+IA0KPiAyKSBhIGNvbmZpcm0gbWVzc2FnZSBjYW4g YmUgcmVwbGllZCB0byBieSBfYW55XyBESENQIHNlcnZlciwgcmVnYXJkbGVzcyBvZiB0aGF0IHNl cnZlciBoYXZpbmcgdGhlIGJpbmRpbmcgb3Igbm90LiBhcyB0aGVyZSBpcyBubyB3YXkgZm9yIGEg c2VydmVyIHdpdGhvdXQgYSBiaW5kaW5nIHRvIGtub3cgaWYgYSBwcmVmaXggaXMgImFwcHJvcHJp YXRlIiBvciBub3QsIHdlIHdhbnRlZCB0byBlbnN1cmUgdGhhdCBvbmx5IHRoZSBzZXJ2ZXIgd2l0 aCB0aGUgYmluZGluZyB3b3VsZCByZXBseS4gdGh1cyB3ZSBoYWQgdG8gdXNlIFJFTkVXLg0KPiAN Cj4gY2hlZXJzLA0KPiBPbGUNCg== From ichiroumakino@gmail.com Thu Feb 16 04:40:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10C21F87CB for ; Thu, 16 Feb 2012 04:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfJgOKF1d8oB for ; Thu, 16 Feb 2012 04:40:52 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7778A21F87C5 for ; Thu, 16 Feb 2012 04:40:52 -0800 (PST) Received: by wibhm9 with SMTP id hm9so1478537wib.31 for ; Thu, 16 Feb 2012 04:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SOfHB/XbS1kBtTinzhM/MvkyzGADm1NVsCerxEF8zEY=; b=nQaMBxpUgjAML8RKMK837UXDQXLkvxrKFB8SnQdLOYeG4IesdrKmw2daBon51kzj+5 TfeGMv03pfcCYKqyFpLuNYoBC/Z0Qitues46UDj2BHOWD4aAwoN5L77EUy0sYePYI3FF x7k/KppyyJycLoRJGV78YlE+XqpeTJkgode5s= Received: by 10.216.145.207 with SMTP id p57mr1074657wej.29.1329396051625; Thu, 16 Feb 2012 04:40:51 -0800 (PST) Received: from [10.147.11.77] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y1sm25731272wiw.6.2012.02.16.04.40.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 04:40:50 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <7EDA08F5-F94C-4B7F-977F-78620DB8DC63@cisco.com> Date: Thu, 16 Feb 2012 13:40:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D8D9F7F-B577-478E-B15B-7CA742B38784@employees.org> References: <3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> <7EDA08F5-F94C-4B7F-977F-78620DB8DC63@cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1257) Cc: dhcwg@ietf.org, Huan Huan Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:40:53 -0000 Bernie, > 3315 only handles address so not surprise about its wording. the unfortunate artifact of 3315 is that the message types are also very = specific to handing out addresses. being a "prefix man" I feel discriminated against. ;-) > Confirm supports three possabilities - ok, not ok, can't say. And PD = is usually done by delegating from a shorter prefix so the appropriate = test can be applied then. Yes, there may be situations where that is not = done and then a server might not be able to provide an answer. >=20 > Agree that Confirm is weaker as it provides no answer as to whether = the information is valid for "that" client - just that the client is = most likely still connected to where it was previously. with only an IA_PD I don't see any way that a server without the binding = can give even a guess. just because the delegated prefix comes out of a = /32 for that ISP, that the DHCP server knows about, says nothing if it = has moved or not. DHCP PD depends on route injection of the first-hop router, and most = implementations depends on DHCP for that to work. we're really back to how should DHC handle multiple stateful options. = fix the message types and text to be more general. or threat multiple = stateful options as separate protocol instances. cheers, Ole= From Jean-Francois.TremblayING@videotron.com Thu Feb 16 12:31:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F15B21F86E4; Thu, 16 Feb 2012 12:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Mh2wfRsEPse; Thu, 16 Feb 2012 12:30:59 -0800 (PST) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id B0E1221F86E0; Thu, 16 Feb 2012 12:30:59 -0800 (PST) In-Reply-To: <4D8D9F7F-B577-478E-B15B-7CA742B38784@employees.org> To: otroan@employees.org MIME-Version: 1.0 X-KeepSent: 3CE12CFF:6C18D7F0-852579A6:006CE171; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 16 Feb 2012 15:30:47 -0500 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 02/16/2012 15:30:49, Serialize complete at 02/16/2012 15:30:49 Content-Type: multipart/alternative; boundary="=_alternative 0070AEEF852579A6_=" Cc: dhcwg@ietf.org, dhcwg-bounces@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:31:00 -0000 Message en plusieurs parties au format MIME --=_alternative 0070AEEF852579A6_= Content-Type: text/plain; charset="US-ASCII" I'm glad Timothy raised this point. We've hit this exact same issue in our lab, along with other issues (I'll send them in a separate thread). Ole wrote: > we're really back to how should DHC handle multiple stateful options. > fix the message types and text to be more general. > or threat multiple stateful options as separate protocol instances. Ole, what do you suggest we do exactly? Change both 3633 to make it clearer? How exactly? The way I see this, in order for an implementation to be compliant on the short term, it would have to do first a Confirm with the IA_NA, then if it has a valid IA_PD, initiate a Renew with at least the IA_PD and possibly the IA_NA too. Would this make sense? JF Tremblay --=_alternative 0070AEEF852579A6_= Content-Type: text/html; charset="US-ASCII"
I'm glad Timothy raised this point. We've hit this exact same issue in our lab, along with other issues (I'll send them in a separate thread).

Ole wrote:
> we're really back to how should DHC handle multiple stateful options.
> fix the message types and text to be more general.
> or threat multiple stateful options as separate protocol instances.

Ole, what do you suggest we do exactly? Change both 3633 to make it clearer? How exactly?

The way I see this, in order for an implementation to be compliant on the short term,
it would have to do first a Confirm with the IA_NA, then if it has a valid IA_PD,
initiate a Renew with at least the IA_PD and possibly the IA_NA too.

Would this make sense?

JF Tremblay
 --=_alternative 0070AEEF852579A6_=-- From Jean-Francois.TremblayING@videotron.com Thu Feb 16 12:34:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2849411E8072 for ; Thu, 16 Feb 2012 12:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d+MkBTWh1Gb for ; Thu, 16 Feb 2012 12:34:38 -0800 (PST) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6AF11E8099 for ; Thu, 16 Feb 2012 12:34:38 -0800 (PST) To: dhcwg@ietf.org MIME-Version: 1.0 X-KeepSent: A8103210:E7C6B2A6-852579A6:006D891E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 16 Feb 2012 15:34:36 -0500 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 02/16/2012 15:34:37, Serialize complete at 02/16/2012 15:34:37 Content-Type: multipart/alternative; boundary="=_alternative 00710860852579A6_=" Subject: [dhcwg] DHCPv6 server/client Confirm behavior after Release X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:34:39 -0000 Message en plusieurs parties au format MIME --=_alternative 00710860852579A6_= Content-Type: text/plain; charset="US-ASCII" On a different but related note, we'd seen in our lab a DHCPv6 client implementation perform 2 releases (IA_NA and then IA_PD), both acknowledged by the server, followed by a Confirm on the IA_NA. At that point the server answered with a Success Reply and the client resumed using its IA_NA (even after the release). Question #1 to the group: is this the correct server behavior after a release? I understand the Confirm was only meant to verify the link is still suitable, but if the lease has been released, shouldn't a NoBinding answer be expected? Question #2: In the scenario above, it looks like the client didn't express a proper behavior. The correct client behavior would be to initiate a Solicit after a successful Release. Is this correct? /JF --=_alternative 00710860852579A6_= Content-Type: text/html; charset="US-ASCII"
On a different but related note, we'd seen in our lab a DHCPv6 client implementation perform 2 releases (IA_NA and then IA_PD), both acknowledged by the server, followed by a Confirm on the IA_NA. At that point the server answered with a Success Reply and the client resumed using its IA_NA (even after the release).

Question #1 to the group: is this the correct server behavior after a release?
I understand the Confirm was only meant to verify the link is still suitable, but if the lease has been released, shouldn't a NoBinding answer be expected?

Question #2: In the scenario above, it looks like the client didn't express a proper behavior. The correct client behavior would be to initiate a Solicit after a successful Release. Is this correct?

/JF

--=_alternative 00710860852579A6_=-- From Ted.Lemon@nominum.com Thu Feb 16 12:37:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC1321F85DA for ; Thu, 16 Feb 2012 12:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iohj6ACE04mg for ; Thu, 16 Feb 2012 12:37:39 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id AD7C911E8072 for ; Thu, 16 Feb 2012 12:37:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTz1pEKQoyVinM7ByMx4EzUGzsIUpHfsw@postini.com; Thu, 16 Feb 2012 12:37:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 140BF1B8590 for ; Thu, 16 Feb 2012 12:37:36 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EE1C619005D; Thu, 16 Feb 2012 12:37:35 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Thu, 16 Feb 2012 12:37:36 -0800 From: Ted Lemon To: " " Thread-Topic: [dhcwg] DHCPv6 server/client Confirm behavior after Release Thread-Index: AQHM7Opqc4UrTmwN8UaWz1B4nu+FypZAgecA Date: Thu, 16 Feb 2012 20:37:34 +0000 Message-ID: <2C43266F-02D7-477C-BDFB-73006D6142B2@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_2C43266F02D7477CBDFB73006D6142B2nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] DHCPv6 server/client Confirm behavior after Release X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:37:40 -0000 --_000_2C43266F02D7477CBDFB73006D6142B2nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 16, 2012, at 3:34 PM, > wrote: Question #1 to the group: is this the correct server behavior after a relea= se? I understand the Confirm was only meant to verify the link is still suitabl= e, but if the lease has been released, shouldn't a NoBinding answer be expe= cted? Strictly speaking, the server isn't checking to see whether a binding exist= s for the address, but rather whether the address in the IA_NA is valid on = the link. So the server behavior here is probably okay. Question #2: In the scenario above, it looks like the client didn't express= a proper behavior. The correct client behavior would be to initiate a Soli= cit after a successful Release. Is this correct? Correct. The client is clearly broken. --_000_2C43266F02D7477CBDFB73006D6142B2nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <60FA70FAD79AE649A9CBDD235FFC8F6A@nominum.com> Content-Transfer-Encoding: quoted-printable

On Feb 16, 2012, at 3:34 PM, <Jean-Francois.TremblayING@videotron.com>
 wrote:
Question #1 to the group: is this the correct server behavior after a release? 
I understand the Confirm was only meant to verify the = link is still suitable, but if the lease has been released, shouldn't a NoB= inding answer be expected? 

Strictly speaking, the server isn't checking to see whether a binding exist= s for the address, but rather whether the address in the IA_NA is valid on = the link.   So the server behavior here is probably okay.

Question #2: In the scenario above, it looks like the client didn't express a prope= r behavior. The correct client behavior would be to initiate a Solicit afte= r a successful Release. Is this correct? 

Correct.   The client is clearly broken.

--_000_2C43266F02D7477CBDFB73006D6142B2nominumcom_-- From volz@cisco.com Thu Feb 16 13:17:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5399C21E8064; Thu, 16 Feb 2012 13:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.864 X-Spam-Level: X-Spam-Status: No, score=-8.864 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkkiqmbNagc6; Thu, 16 Feb 2012 13:17:40 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F18A921E8051; Thu, 16 Feb 2012 13:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=17349; q=dns/txt; s=iport; t=1329427060; x=1330636660; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=+VK/oizsHHBBraEi/AoymQu+rp8OXcCgNsTdl46oOwQ=; b=duUbisgCWzPoWQD9TGCMlnPlr84+6oQlL4WFXhZpm8FaylyFMw8FqfHH XMJNMcgWu5/aVkx4z0GJDBPAKb9hD7H6Y724m/HWbjQpdkibBxAp83tTx NQuSezoMDHyuF/9CA1JL0L1Cxja6AwNUdss75a4RKxIkJuijKlqd+GWeD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAG1xPU+tJXG+/2dsb2JhbABEgk2uG4EHgXIBAQEEEgEJEQNJEAIBCBEEAQEBCgYXAQYBRQkIAQEEARIIGqIzAZ5Ki2YBAwQDAQECAQYEAhIFAjEThwFjBIhOn3A X-IronPort-AV: E=Sophos;i="4.73,431,1325462400"; d="scan'208,217";a="59594688" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 16 Feb 2012 21:17:39 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1GLHdwO014022; Thu, 16 Feb 2012 21:17:39 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 15:17:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECF0.69602FE4" Date: Thu, 16 Feb 2012 15:17:35 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Thread-Index: Aczs6edblHhi3hK/SkKAipDopSg6ngAA4ITA References: <4D8D9F7F-B577-478E-B15B-7CA742B38784@employees.org> From: "Bernie Volz (volz)" To: , X-OriginalArrivalTime: 16 Feb 2012 21:17:39.0291 (UTC) FILETIME=[697B82B0:01CCECF0] Cc: dhcwg@ietf.org, dhcwg-bounces@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:17:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECF0.69602FE4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This issue is tied to the question of what a client that wants IA_NA and IA_PD should do for the Solicit and all other messages (and what it should do if it only gets one, not both, requests in that single message exchange). =20 RFC 3633 (and RFC 3315) were never written with this clearly defined or in mind? =20 It was my fault that Hemant put in the requirement to have the eRouter do ONE request for both. I regret having suggested this, and will go back to saying that separate requests are far better. =20 Someone raised the issue of Option integration in that case. But I would argue that there is NO option integration issue. The address (IA_NA) and its options are for ONE usage (communication via the address out the interface on which the IA_NA was obtained) whereas the prefix (IA_PD) and its options are for the devices that will be getting prefixes (or addresses) from the IAPREFIX and thus have NOTHING to do with the IA_NA request. And, putting all into one exchange really prevents that meaningful communication (the container option is there to help with this but it technically could be deemed unnecessary if the requests were separate). =20 Someone raised the issue that this adds complexity in the implementation? Really? Seems that this is already complex and more so since there are many more twisty little paths to explore and test. Two much more simple and mostly independent state machines seems far easier to me (though I am not a client implementer - other than test ones). Nothing requires these to be separate processes or separate threads - just two state machines however you want to implement them. =20 Ralph and Ole have asked me to consider writing a problem statement I-D for this issue and I haven't yet decided if I will - as it seems clear to me that while the extra exchange costs some additional bits on the wire and perhaps some added latency, I still think that separate is the better way to go. =20 Then the issue of whether Confirm is allowed for PD (or Renew instead of Confirm for IA) goes away [follow the RFCs] and we can also clean up our implementations over time to be compliant. The documents are clear on these issue in the single type context. =20 Future IA_* types will need to be clear about whether they are or are not allowed with other IA_* types in a single message. =20 =20 The way I see this, in order for an implementation to be compliant on the short term,=20 it would have to do first a Confirm with the IA_NA, then if it has a valid IA_PD,=20 initiate a Renew with at least the IA_PD and possibly the IA_NA too. =20 Probably if we don't recommend splitting things up (or to make smaller fixes to current implementations), that would be the way to go (not sure why there would need to be a delay on the Renew). Confirm might come back with Success and Renew might fail (since another server handled the Confirm and Renewing server was no up). This would give the device an indication that it is probably still on the same link. =20 - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Jean-Francois.TremblayING@videotron.com Sent: Thursday, February 16, 2012 3:31 PM To: otroan@employees.org Cc: dhcwg@ietf.org; dhcwg-bounces@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm =20 I'm glad Timothy raised this point. We've hit this exact same issue in our lab, along with other issues (I'll send them in a separate thread).=20 Ole wrote:=20 > we're really back to how should DHC handle multiple stateful options.=20 > fix the message types and text to be more general.=20 > or threat multiple stateful options as separate protocol instances.=20 Ole, what do you suggest we do exactly? Change both 3633 to make it clearer? How exactly?=20 The way I see this, in order for an implementation to be compliant on the short term,=20 it would have to do first a Confirm with the IA_NA, then if it has a valid IA_PD,=20 initiate a Renew with at least the IA_PD and possibly the IA_NA too.=20 Would this make sense?=20 JF Tremblay ------_=_NextPart_001_01CCECF0.69602FE4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

This issue is tied to the question of what a client that wants IA_NA = and IA_PD should do for the Solicit and all other messages (and what it = should do if it only gets one, not both, requests in that single message = exchange).

 

RFC 3633 (and RFC 3315) were never written with this clearly defined = or in mind?

 

It was my fault that Hemant put in the requirement to have the = eRouter do ONE request for both. I regret having suggested this, and = will go back to saying that separate requests are far = better.

 

Someone raised the issue of Option integration in that case. But I = would argue that there is NO option integration issue. The address = (IA_NA) and its options are for ONE usage (communication via the address = out the interface on which the IA_NA was obtained) whereas the prefix = (IA_PD) and its options are for the devices that will be getting = prefixes (or addresses) from the IAPREFIX and thus have NOTHING to do = with the IA_NA request. And, putting all into one exchange really = prevents that meaningful communication (the container option is there to = help with this but it technically could be deemed unnecessary if the = requests were separate).

 

Someone raised the issue that this adds complexity in the = implementation? Really? Seems that this is already complex and more so = since there are many more twisty little paths to explore and test. Two = much more simple and mostly independent state machines seems far easier = to me (though I am not a client implementer – other than test = ones). Nothing requires these to be separate processes or separate = threads – just two state machines however you want to implement = them.

 

Ralph and Ole have asked me to consider writing a problem statement = I-D for this issue and I haven’t yet decided if I will – as = it seems clear to me that while the extra exchange costs some additional = bits on the wire and perhaps some added latency, I still think that = separate is the better way to go.

 

Then the issue of whether Confirm is allowed for PD (or Renew instead = of Confirm for IA) goes away [follow the RFCs] and we can also clean up = our implementations over time to be compliant. The documents are clear = on these issue in the single type context.

 

Future IA_* types will need to be clear about whether they are or are = not allowed with other IA_* types in a single = message.

 

 

The way I see this, in order for an = implementation to be compliant on the short term, =
it would have to do = first a Confirm with the IA_NA, then if it has a valid IA_PD, =
initiate a Renew = with at least the IA_PD and possibly the IA_NA = too.

 

Probably if we don’t recommend splitting things up (or to make = smaller fixes to current implementations), that would be the way to go = (not sure why there would need to be a delay on the Renew). Confirm = might come back with Success and Renew might fail (since another server = handled the Confirm and Renewing server was no up). This would give the = device an indication that it is probably still on the same = link.

 

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Jean-Francois.TremblayING@videotron.com
Sent: Thursday, = February 16, 2012 3:31 PM
To: = otroan@employees.org
Cc: dhcwg@ietf.org; = dhcwg-bounces@ietf.org
Subject: Re: [dhcwg] dhcwg Digest, DHCP = Renew vs Confirm

 


I'm glad = Timothy raised this point. We've hit this exact same issue in our lab, = along with other issues (I'll send them in a separate thread). =

Ole wrote: =
> we're really = back to how should DHC handle multiple stateful options. =
> fix the = message types and text to be more general.
> or threat multiple stateful options as = separate protocol instances.

Ole, what do you suggest we do exactly? = Change both 3633 to make it clearer? How exactly? =

The way I see this, in = order for an implementation to be compliant on the short term, =
it would have to do = first a Confirm with the IA_NA, then if it has a valid IA_PD, =
initiate a Renew = with at least the IA_PD and possibly the IA_NA too. =

Would this make = sense?

JF = Tremblay

------_=_NextPart_001_01CCECF0.69602FE4-- From ichiroumakino@gmail.com Fri Feb 17 03:02:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2421F84AE; Fri, 17 Feb 2012 03:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAu1xaSZ9moa; Fri, 17 Feb 2012 03:02:58 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2DD21F8878; Fri, 17 Feb 2012 03:02:42 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so1841721wgb.13 for ; Fri, 17 Feb 2012 03:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=iJPhfZXHl78hIuX7iHcWaunV61q7SQhlkSx5CW2txmg=; b=i0RW9eddhIBt+BQLR8TWOBSJFvROYfDolxxy6K0+AL4wkeux1Tdu3Z4JM3fJcJe6/V CGUePC/l90AdYPlgPYONWSmCXNkAzrR6QBnz2QhLwWaLuU/IsCM0vH0Koft/L3obRi4X HnhmM8iTlcG86aTnY7uyxXGzGSPCW1Q6CeQVM= Received: by 10.180.100.33 with SMTP id ev1mr3511187wib.3.1329476560361; Fri, 17 Feb 2012 03:02:40 -0800 (PST) Received: from [10.147.11.77] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id dr5sm33676393wib.0.2012.02.17.03.02.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 03:02:39 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 17 Feb 2012 12:02:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D8D9F7F-B577-478E-B15B-7CA742B38784@employees.org> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1257) Cc: dhcwg@ietf.org, Jean-Francois.TremblayING@videotron.com, dhcwg-bounces@ietf.org Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:02:59 -0000 Bernie, 1. Single session - assumes a link is connected to a single "provisioning domain". all = servers should have the same policy, and if not it is a configuration error. - implies that 3315/3633 is rewritten so that DHCP message types are = made independent of stateful option type (e.g. CONFIRM only applying to addresses) 2. One session per stateful option - how does a client merge the redundant / conflicting stateless = options? e.g if only PD + stateless options, is that going to be used also = for the "host" functions? given that the PD also is used to configure addresses on the device. - where both IA_NA and IA_PD is requested but only PD given, will result in clients soliciting forever what if client also wants IA_TA? - allows different "provisioning domains" per stateful option? - results in multiple bindings per client, and presumably multiple = RECONFIGURE messages per session doesn't (2) encourage not only separate instances of the state machine, = but different state machines altogether? with different T1/T2 timers and different meaning of message types, = we're there already? argh, I don't think we intended to create a = different flavour of DHCP with RFC3633. cheers, Ole On Feb 16, 2012, at 22:17 , Bernie Volz (volz) wrote: > This issue is tied to the question of what a client that wants IA_NA = and IA_PD should do for the Solicit and all other messages (and what it = should do if it only gets one, not both, requests in that single message = exchange). > =20 > RFC 3633 (and RFC 3315) were never written with this clearly defined = or in mind? > =20 > It was my fault that Hemant put in the requirement to have the eRouter = do ONE request for both. I regret having suggested this, and will go = back to saying that separate requests are far better. > =20 > Someone raised the issue of Option integration in that case. But I = would argue that there is NO option integration issue. The address = (IA_NA) and its options are for ONE usage (communication via the address = out the interface on which the IA_NA was obtained) whereas the prefix = (IA_PD) and its options are for the devices that will be getting = prefixes (or addresses) from the IAPREFIX and thus have NOTHING to do = with the IA_NA request. And, putting all into one exchange really = prevents that meaningful communication (the container option is there to = help with this but it technically could be deemed unnecessary if the = requests were separate). > =20 > Someone raised the issue that this adds complexity in the = implementation? Really? Seems that this is already complex and more so = since there are many more twisty little paths to explore and test. Two = much more simple and mostly independent state machines seems far easier = to me (though I am not a client implementer =96 other than test ones). = Nothing requires these to be separate processes or separate threads =96 = just two state machines however you want to implement them. > =20 > Ralph and Ole have asked me to consider writing a problem statement = I-D for this issue and I haven=92t yet decided if I will =96 as it seems = clear to me that while the extra exchange costs some additional bits on = the wire and perhaps some added latency, I still think that separate is = the better way to go. > =20 > Then the issue of whether Confirm is allowed for PD (or Renew instead = of Confirm for IA) goes away [follow the RFCs] and we can also clean up = our implementations over time to be compliant. The documents are clear = on these issue in the single type context. > =20 > Future IA_* types will need to be clear about whether they are or are = not allowed with other IA_* types in a single message. > =20 > =20 > The way I see this, in order for an implementation to be compliant on = the short term,=20 > it would have to do first a Confirm with the IA_NA, then if it has a = valid IA_PD,=20 > initiate a Renew with at least the IA_PD and possibly the IA_NA too. > =20 > Probably if we don=92t recommend splitting things up (or to make = smaller fixes to current implementations), that would be the way to go = (not sure why there would need to be a delay on the Renew). Confirm = might come back with Success and Renew might fail (since another server = handled the Confirm and Renewing server was no up). This would give the = device an indication that it is probably still on the same link. > =20 > - Bernie > =20 > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Jean-Francois.TremblayING@videotron.com > Sent: Thursday, February 16, 2012 3:31 PM > To: otroan@employees.org > Cc: dhcwg@ietf.org; dhcwg-bounces@ietf.org > Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm > =20 >=20 > I'm glad Timothy raised this point. We've hit this exact same issue in = our lab, along with other issues (I'll send them in a separate thread).=20= >=20 > Ole wrote:=20 > > we're really back to how should DHC handle multiple stateful = options.=20 > > fix the message types and text to be more general.=20 > > or threat multiple stateful options as separate protocol instances.=20= >=20 > Ole, what do you suggest we do exactly? Change both 3633 to make it = clearer? How exactly?=20 >=20 > The way I see this, in order for an implementation to be compliant on = the short term,=20 > it would have to do first a Confirm with the IA_NA, then if it has a = valid IA_PD,=20 > initiate a Renew with at least the IA_PD and possibly the IA_NA too.=20= >=20 > Would this make sense?=20 >=20 > JF Tremblay From twinters@iol.unh.edu Fri Feb 17 10:49:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B2F21F86AA for ; Fri, 17 Feb 2012 10:49:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDeGY-t+O4Bp for ; Fri, 17 Feb 2012 10:49:42 -0800 (PST) Received: from exprod5og113.obsmtp.com (exprod5og113.obsmtp.com [64.18.0.26]) by ietfa.amsl.com (Postfix) with SMTP id 3A14B21F86A7 for ; Fri, 17 Feb 2012 10:49:42 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob113.postini.com ([64.18.4.12]) with SMTP ID DSNKTz6hRXIt0woAwxOAp241mutmz2y0tal0@postini.com; Fri, 17 Feb 2012 10:49:42 PST Received: from openvpn-client28.iol.unh.edu (openvpn-client28.iol.unh.edu [132.177.124.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id DEC228F0067 for ; Fri, 17 Feb 2012 13:49:40 -0500 (EST) From: Timothy Winters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2012 13:49:40 -0500 Message-Id: To: dhcwg@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dhcwg] Question for SOL_MAX_RT draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:49:43 -0000 Hello, While implementing some testing around = draft-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an = implementation that viewed the draft differently then I did. I'm = including the statement from an implementation that we encountered when = developing test cases. "RFC 3315, it allows a DHCPv6 client to try another server and = our DHCPv6 client does it by initiating another DHCPv6 Solicitation with = a new transcation ID. In terms, there may be an environment with several = DHCPv6 servers. If a client gets a NoAddrsAvail in DHCPv6 = Advertisement, it can try another server immediately by initiating a new = DHCPv6 Solicitation with a new Transaction ID. I think SOL_MAX_RT = counts only within the same session, in terms of the same Transaction = ID.=20 In the other words, RFC leaves the flexibility for an = environment with multiple DHCPv6 Servers and clients can send a new = DHCPv6 Solicitation message with a new Transaction ID if there is no = address available. Client doesn't need to assume there is only one = DHCPv6 Server, and an DHCPv6 Advertisement with NoAddrsAvail doesn't = necessarily mean that the client need to wait SOL_MAX_RT. The Client = can try another DHCPv6 server." I thought the spirit of the draft was to limit the the amount of = DHCP Solicits. If a DHCP client applies the SOL_MAX_RT to only one = session, the Client will continuously transmit DHCP solicits looking for = another DHCP Server. Therefore the SOL_MAX_RT should applies to all = session and is not limited to one. What other think about this? Regards, Tim From akostur@incognito.com Fri Feb 17 11:01:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89021E80BB for ; Fri, 17 Feb 2012 11:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqNk0Wpt3It9 for ; Fri, 17 Feb 2012 11:01:03 -0800 (PST) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 2967921E80B9 for ; Fri, 17 Feb 2012 11:01:02 -0800 (PST) Received: from mail-lpp01m010-f41.google.com ([209.85.215.41]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKTz6j7ioCQqRs6V2XHaezJqoQlZjbGKpr@postini.com; Fri, 17 Feb 2012 11:01:03 PST Received: by mail-lpp01m010-f41.google.com with SMTP id f4so4915420lam.0 for ; Fri, 17 Feb 2012 11:01:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.113.136 with SMTP id iy8mr5899224lab.50.1329505260926; Fri, 17 Feb 2012 11:01:00 -0800 (PST) Received: by 10.112.56.161 with HTTP; Fri, 17 Feb 2012 11:01:00 -0800 (PST) In-Reply-To: References: Date: Fri, 17 Feb 2012 11:01:00 -0800 Message-ID: From: Andre Kostur To: Timothy Winters Content-Type: multipart/alternative; boundary=f46d04083b05cdf79f04b92d908d X-Gm-Message-State: ALoCoQnQhgvq+25UHjYYXPKNvy97FGXMH3zQgieLHJ21XZrubRAuBJcep/Ze6jiAdLNlVxwUnbhD Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question for SOL_MAX_RT draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:01:04 -0000 --f46d04083b05cdf79f04b92d908d Content-Type: text/plain; charset=ISO-8859-1 I would argue it should be for all sessions. The client isn't supposed to assume that there is only one DHCP server, that's why the client is supposed to be collecting Advertisements from (potentially) multiple DHCP servers (RFC 3315, section 17.1.2: "...Rather, the client collects Advertise messages until the first RT has elapsed."). So why isn't it examining the 4 Advertisements to find the one that doesn't claim "NoAddrsAvail"? Why would the client expect a different answer if it immediately Solicited again? You're going to hit all of the same servers again (probably), and get nearly the same answers again. On Fri, Feb 17, 2012 at 10:49, Timothy Winters wrote: > Hello, > While implementing some testing around > draft-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an > implementation that viewed the draft differently then I did. I'm including > the statement from an implementation that we encountered when developing > test cases. > > "RFC 3315, it allows a DHCPv6 client to try another server and our > DHCPv6 client does it by initiating another DHCPv6 Solicitation with a new > transcation ID. In terms, there may be an environment with several DHCPv6 > servers. If a client gets a NoAddrsAvail in DHCPv6 Advertisement, it can > try another server immediately by initiating a new DHCPv6 Solicitation with > a new Transaction ID. I think SOL_MAX_RT counts only within the same > session, in terms of the same Transaction ID. > > In the other words, RFC leaves the flexibility for an environment > with multiple DHCPv6 Servers and clients can send a new DHCPv6 Solicitation > message with a new Transaction ID if there is no address available. Client > doesn't need to assume there is only one DHCPv6 Server, and an DHCPv6 > Advertisement with NoAddrsAvail doesn't necessarily mean that the client > need to wait SOL_MAX_RT. The Client can try another DHCPv6 server." > > I thought the spirit of the draft was to limit the the amount of > DHCP Solicits. If a DHCP client applies the SOL_MAX_RT to only one > session, the Client will continuously transmit DHCP solicits looking for > another DHCP Server. Therefore the SOL_MAX_RT should applies to all > session and is not limited to one. > > What other think about this? > > Regards, > Tim > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- *Andre Kostur* Senior Product Design Engineer *P:* 604-678-2864 *E:* akostur@incognito.com *Toll-Free:* 1-800-877-1856 *F:* 604-678-2864 *VoIP:* sip:864@sip.incognito.com [image: Incognito Software Inc.] --f46d04083b05cdf79f04b92d908d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would argue it should be for all sessions. =A0 The clien= t isn't supposed to assume that there is only one DHCP server, that'= ;s why the client is supposed to be collecting Advertisements from (potenti= ally) multiple DHCP servers (RFC 3315, section 17.1.2: "...Rather, the=A0client collects Advertise messages until t= he first RT has elapsed."). =A0So why isn't it examining th= e 4=A0Advertisements=A0to find the one that doesn't claim "NoAddrs= Avail"? =A0Why would the client expect a different answer if it immedi= ately Solicited again? =A0You're going to hit all of the same servers a= gain (probably), and get nearly the same answers again.


On Fri, Feb 17, 2012 at 10:49, Timothy W= inters <twinte= rs@iol.unh.edu> wrote:
Hello,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0While implementing some testing around draf= t-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an imp= lementation that viewed the draft differently then I did. =A0I'm includ= ing the statement from an implementation that we encountered when developin= g test cases.

=A0 =A0 =A0 =A0"RFC 3315, it allows a DHCPv6 client to try another se= rver and our DHCPv6 client does it by initiating another DHCPv6 Solicitatio= n with a new transcation ID. In terms, there may be an environment with sev= eral DHCPv6 servers. =A0If a client gets a NoAddrsAvail in DHCPv6 Advertise= ment, it can try another server immediately by initiating a new DHCPv6 Soli= citation with a new Transaction ID. =A0I think SOL_MAX_RT counts only withi= n the same session, in terms of the same Transaction ID.

=A0 =A0 =A0 =A0In the other words, RFC leaves the flexibility for an envir= onment with multiple DHCPv6 Servers and clients can send a new DHCPv6 Solic= itation message with a new Transaction ID if there is no address available.= Client doesn't need to assume there is only one DHCPv6 Server, and an = DHCPv6 Advertisement with NoAddrsAvail doesn't necessarily mean that th= e client need to wait SOL_MAX_RT. =A0The Client can try another DHCPv6 serv= er."

=A0 =A0 =A0 =A0I thought the spirit of the draft was to limit the the amou= nt of DHCP Solicits. =A0If a DHCP client applies the SOL_MAX_RT to only one= session, the Client will continuously transmit DHCP solicits looking for a= nother DHCP Server. =A0Therefore the SOL_MAX_RT should applies to all sessi= on and is not limited to one.

=A0 =A0 =A0 =A0What other think about this?

Regards,
Tim

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



--
Andre Kostur =
Senior Product Design Engineer
P: 604-678-2864
E: akostur@incognito.com
Toll-Free: 1-800= -877-1856

F: 604-678-2864
VoIP: = sip:864@sip.incognito.com

3D"Incognito


--f46d04083b05cdf79f04b92d908d-- From kkinnear@cisco.com Fri Feb 17 12:09:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93821F8532; Fri, 17 Feb 2012 12:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id benCEYQovy4h; Fri, 17 Feb 2012 12:09:16 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C721F852F; Fri, 17 Feb 2012 12:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=20951; q=dns/txt; s=iport; t=1329509356; x=1330718956; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lWj6YbbdBYvb7Tqc/iutQdy5Sofl7uewZ4IUbiDcOPw=; b=GcaR+tofADHIvndICPEwuLRlBmEnIO41pzs76GnWaeQE5oTIGdsNGL1R Gz7+RaPeAJNnVtKKmFZ7zYBiWjVcijPAbtScvxb5SW8A4pizfmrnJXi5V L/ou8esmOiWzgnCkmJ1FyUFLw38yweW28VoNcaqNz8zBY+ZvTEcwBBb1A M=; X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="59866612" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 17 Feb 2012 20:09:15 +0000 Received: from bxb-vpn3-383.cisco.com (bxb-vpn3-383.cisco.com [10.86.249.127]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1HK9EjC024859; Fri, 17 Feb 2012 20:09:14 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <4F3987F0.5050000@isi.edu> Date: Fri, 17 Feb 2012 15:09:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3987F0.5050000@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, TSV Dir , dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:09:19 -0000 Joe, Thank you for your review. My responses are indented, below... On Feb 13, 2012, at 5:00 PM, Joe Touch wrote: > Hi, all, >=20 > I've reviewed this document as part of the transport area = directorate's ongoing effort to review key IETF documents. These = comments were written primarily for the transport area directors, but = are copied to the document's authors for their information and to allow = them to address any issues raised. The authors should consider this = review together with any other last-call comments they receive. Please = always CC tsv-dir@ietf.org if you reply to or forward this review. >=20 > This request was received Feb. 2, 2012. >=20 > This document describes an extension to DHCPv4 for the bulk query and = transfer of current lease status over TCP. >=20 > The following transport issues were noted, and are significant: >=20 > UPDATES- The document updates DHCP with support for TCP, and as such = this document seems like it should UPDATE RFC2131 While this document clearly builds on RFC 2131, it doesn't actually change anything that anyone is doing that is currently based on RFC 2131. My understanding of "updates" is that, in order to understand the first RFC (in this case, RFC 2131), you need to read all of the RFC's that "update" it. That isn't the case here -- you can be very happy reading and implementing DHCPv4 by reading RFC 2131 and never have to know that DHCPv4 Bulk Leasequery exists. In general, in the DHC WG, we seem to set a pretty high bar for what "udpates" another RFC. I don't see that this document has met those requirements. But this isn't really my call. I'll let Ralph Droms and the DHC WG chairs decide on this one, and I'll do whatever they tell me to do. >=20 >=20 > PORT USE- Although DHCPv4 has an assigned TCP port, this document = should clearly indicate that there is no other specified use of that = port other than the bulk lease query described in this document Sure. >=20 > It should further explain why no other existing DHCP exchanges are not = valid on the TCP port. I've been taken to task by various IETF folks at varying levels of seniority for explaining too *much* of the "why". My understanding is that this is a protocol specification and not a design document, and as such it is not only not necessary but frequently counter-productive to give lots of justifications for the decisions made when constructing the protocol. In this case, I can't speak for the wG at large, because we never proposed anything else. The reason we didn't propose anything else was that we didn't want to "update" RFC 2131 with a new way to do DHCPv4 in general. But that all kind of comes down to "because we said so". We were trying to keep this draft focused. But if I put words in the document which say that, someone in the WG would tell me to take them out. I have no problem motivating the "interesting" decisions we've made, or perhaps the contentious ones, but this one was a no-brainer that never even came up (to the best of my memory). Having said all of that, I'll put something in that says that we were trying to keep it simple. >=20 >=20 > CONNECTION MANAGEMENT- The document describes the use of TCP = connections for bulk transfer, but needs to be more specific about which = side (relay client or server) closes the connection, under what = circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT, = as per RFC 793) Here is what we have now, 7.8 is for clients, 8.5 is for servers: > 7.8. Closing Connections [Client Section] >=20 > The requestor SHOULD close the connection after the > DHCPLEASEQUERYDONE message is received for the last outstanding = query > that it has sent, if it has no more queries to send. >=20 > 8.5. Closing Connections [Server Section] >=20 > The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT > seconds for a particular connection after it sends a > DHCPLEASEQUERYDONE message over that connection and if there is no > current query outstanding for that connection. It should clear = this > timer if a query arrives over that connection. If the timer = expires, > the DHCPv4 server should close the connection. >=20 > The server MUST close its end of the TCP connection if it = encounters > an error sending data on the connection. The server MUST close its > end of the TCP connection if it finds that it has to abort an in- > process request. A server aborting an in-process request SHOULD > attempt to signal that to its requestors by using the = QueryTerminated > status code in the status-code option in a DHCPLEASEQUERYDONE > message, including a message string indicating details of the = reason > for the abort. If the server detects that the requesting end of = the > connection has been closed, the server MUST close its end of the > connection. All connections are closed with a graceful CLOSE, and not with an ABORT. I'll add that to the document. I'm at a loss to know how to be more specific about which side of the connection closes the connection. There are rules for the client in 7.8, and rules for the server in 8.5. > sec 7.3 indicates some conditions for terminating connections; this = section should indicate which side performs this, and by what method = (CLOSE, ABORT) Section 7.3 discusses in two places where the "requestor" may drop the connection. The term "requestor" is used to indicate which "side" performs the actions. All of Section 7 is about "Requestor Behavior", and the specific details of section 7.3 in all cases indicate that the instructions for dealing with the connection concern the "requestor" explicitly. I'll enhance the explanation to include that CLOSE should be used. If there is a specific set of instructions that are unclear, I don't see them, so it would help me if you could give me more detailed guidance than "Section 7.3". =20 Thanks. >=20 > this sec also allows connections to stay open after all pending = transactions are complete (MAY); the rationale for this should be given, = or the connection MUST be closed. I will add some words which clarify the reasons why you might want to leave the connection open after all pending transactions are complete. >=20 > the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is = particularly problematic on this issue because it discusses aborting a = request using in-band data, which may not be available if the connection = is closed using ABORT. the state of other pending connection shsould be = discussed too. The in-band data is not required for proper protocol operation, it is valuable because it can limit the amount of data required when and if the connection is reestablished. All connections are closed by CLOSE. I assume that, in your comment, "other pending connection[s]" means other data flows that might exist on the TCP connection that is coming down. I will add some words that say that those Bulk Leasequery data flows will also be stopped. >=20 > TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this = intended to supercede any TCP timeout? or is it intended to be the min = of the TCP timeout and the specified one? The BULK_LQ_DATA_TIMEOUT is completely application specific and essentially independent of the underlying connection timeout. I will add words to that effect in the document. >=20 > This section should more carefully explain behavior when a connection = is dropped and the reason - e.g., timeout, abort, close. =09 The application employing Bulk Leasequery doesn't care about *why* the connection went away. It doesn't have to know if it was abort, close, or timeout. I will say that in this section. >=20 > INTERLEAVING- sec 7.7 says that the server MUST interleave replies; = there doesn't seem a valid reason for this requirement. clearly the = receiver MUST tolerate interleaved replies. having the server interleave = replies is relevant only if each request/reply has its own timeout -- = which should be overridden if there is another response in progress = anyway. This issue should be more clearly explained and motivated. Robert Sparks offered clarification, which I like a lot and have already agreed to use: >=20 > Is the requirement you are really trying to capture "MUST > NOT block sending replies on new queries until all > replies for the existing query are complete."? >=20 > There were some other issues noted in this document. These comments = appear below, and although not focused on transport issues, they = represent significant issues that IMO should be addressed as well. >=20 > NOTE - regarding some terminology issues, I did not survey current = DHCP RFCs for consistency, but IMO these terms should be corrected even = if they are then inconsistent with existing specs. >=20 > Joe >=20 > ----------- >=20 > Major non-transport issues: >=20 > - In many places the doc allows inaction to substitute for either = positive or negative confirmation. IMO, this invites implementation = errors, and should be avoided. E.g., status return codes, data source = option missing, query-for-all-configured-IPs, etc. =09 While I personally tend to agree with you on this one, I have clear direction from the DHC WG that this is *not* the approach that the WG wants to take. Here is the status code text: > A status-code option MAY appear in the options field of a DHCPv4 > message. If the status-code option does not appear, it is assumed > that the operation was successful. The status-code option SHOULD = NOT > appear in a message which is successful unless there is some text > string that needs to be communicated to the requestor. This was wrangled over at some length in the DHC WG, and this was the way that it needed to be to pass last call. I don't feel that I can change it at this time. =09 >=20 > - the data source option reserved codes need more detailed = specification. if these are intended for future use, then they MUST be = ignored by the receiver (at least). if they are to mean anything at all, = at least one bit (typically all of them) MUST be set to zero by the = transmitter for implementations that do not support any of the component = fields. >=20 > further, the length of this option MUST be 1 Yes, subsequent to the creation of this section, Amanda Baber of IANA enlightened me regarding the different between RESERVED and UNASSIGNED. These should be UNASSIGNED, and I will add words that say that a receiver should ignore the bits that are unassigned. >=20 > - The protocol supports bulk transfer that is not data driven. This = could represent a security vulnerability by exposing information that = may not be on the data path (and thus already accessible) to a relay = agent. This should be discussed in the security considerations section. All data that is exposed has already been exposed using UDP to regular DHCP port. But please see my response to Stephen Farrell (which is too long to include here) to see if it covers the issues about which you have concerns. >=20 > - Integer quantities should be referred to as "unsigned 32-bit = integers" throughout. Good point (though some are 16 bits). The signed-ness is not specified and should be. I'll make sure that it is. >=20 > - "VPN" is used throughout to refer to "private" addresses (RFC 1918); = a VPN is not just private addressing. Hmm. Actually, VPN in this document does not refer to RFC 1918 private addressing. If this is important to you, could you be more specific as to your concern? >=20 > - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used = throughout without context. Any time SHOULD is used instead of MUST (or = SHOULD NOT rather than MUST NOT), it is useful to explain a viable = exception. If no such exception exists, the rationale for selecting = SHOULD over MUST should be included. This is an interesting approach, which is new to me. I can see the value in looking for viable exceptions. I think justifying SHOULD and not MUST is a bit much, and wouldn't make it through the "keep it short and simple" filters that the DHC WG seems to place on DHC drafts. But as I said, I'll look at every SHOULD (NOT) and see if I can find concise examples of reasons. But I'm concerned that this will greatly lengthen the draft. >=20 > - It would be useful to explain why STATUS-CODE strings MUST NOT be = null-terminated; is that a protocol violation, or are you just saying = that NULLs are valid in these strings? the description should be clear = that the string field describes the string length without any = termination characters. I will clarify this. Nulls are not allowed in the strings. DHCP options have an unfortunate history where some large vendors null terminated their strings even though they were not supposed to, so now we always make a big deal out of it so it doesn't happen again. >=20 > - start-time-of-state is expressed as an offset from base-time; this = appears to be the only time indicated as an offset rather than as an = absolute. That inconsistency invites implementation errors; IMO, this = should be absolute too. There are two kinds of time options here, input options and output options. The input options are all absolute times. The output options are all offset times from the base time (which by design is the only absolute time in the output packets). There are several input options defined in this document. The start-time-of-state is the only output option defined in this draft. It is defined as a offset to the base time in large part because the *other* output options that are used in the DHCP packet are *also* offsets to the base time. These options are not new, but are options that already exist in other RFC's. So, while it looks like the state-time-of-state is the odd man out at first glance, it actually is an offset time because the *other* options with which it will appear are also offset times. >=20 >=20 > - option lengths: throughout, the doc refers to option lengths as = being "an octet"; they are *indicated* in one octet. Some are constant = (e.g., DCHP-STATE), some allow the contents of the octet to vary. Again, = this is an *unsigned integer* octet. Yes, the size of an option is stored in one octet. So, yes, the length is *indicated* by the value in that one octet. But the length may be 1 octet, it may be 5 octets, it may vary between 8 and 10 octets. I don't understand your concern. Are you=09 saying that the length should not be stated to be "1 octet" or "5 octets"? I will fix the integer to be specifically unsigned (as previously indicated).=20 >=20 > - some of the information provided (in DHCP-STATE) goes beyond that of = DHCP. It would be useful to motivate the need for this information in a = bulk query, and why it is not similarly available for nodes using UDP = (e.g., as an extension to DHCPv4, not just to the bulk transfer = command). again, absence of state information should not indicate state. = State should always be expressed explicitly. these states are further = meaningless without a state diagram explaining them. if such a diagram = is not possible (as noted at end of sec 6.2.7), then the states are = irrelevant and the option should not be included. The state transition diagram can certainly be drawn, but as it is fully connected, such a picture conveys no useful information. The transitions are not themselves useful in any case, as the the Bulk Leasequery is a snapshot of information at one instant of time. There is every reason to assume that as the state moves from one value to another that an external entity would not see all (or even many) of these transitions. This is a snapshot of the DHCP state, and could be nothing else in the environment of Bulk Leasequery. The reason why the state transition graph is fully connected is due to the common practice in DHCPv4 of having two servers running in a failover relationship. There are then two state machines for the lease state, and at times one "leads" and the other "follows", and at other times the other "leads" and its partner "follows". So, examined individually, the state machines for each individual failover partner is fully connected because at any time it may receive an update from its partner that it decides to accept that will simply "set" the state to the value supplied by the partner. All of this is orthogonal to the Bulk Leasequery protocol -- except that we want the user of the Bulk Leasequery protocol to be able to make sense out of information supplied by each of the failover partners. Or any partners running any increased availability solution. So, that is the reason why the dhcp-state option exists at all -- to allow the user of Bulk Leasequery to make sense out of the results of sending a Bulk Leasequery to two different (but cooperating) DHCPv4 servers. The DHC WG felt that this information was worthwhile to have in this document, and I agree (or we wouldn't have put it in). >=20 > - in sec 6.2.9 the term "not allowed" should be explained - are they = reserved for future use and thus ignored? or are they "not allowed" - in = which case the doc should indicate handling if they appear. Ah, good catch. The "not allowed" will become UNASSIGNED, based on my conversation with Amanda Baber of IANA. I will add words that suggest that they should be ignored. The point of this table is, actually, not how to handle them (that is the up to the vpn-option draft/RFC), but rather to define a single new value. >=20 > - sec 7.4 states that the clock skew of zero is desired; this assumes = E2E delays under 1sec. An explanation of why this is desired should be = given, as well as the consequences of it not. I have given specific instructions on how to handle non-zero clock skews. There are no "consequences". You code it so that it works with non-zero clock skew. Period. It is desired because it is less confusing to humans. >=20 > Other non-transport issues: >=20 > - The document includes definitions and references to irrelevant = deployment and implementation issues, notably DSLAMs, concentrators, and = access concentrators. These should not appear formally; they should be = used only to usefully illustrate currently intended uses. These appear in the text in order to give=20 the otherwise abstract design goals some concrete examples. We already removed a lot of the design goals, are you suggesting that they all be removed? >=20 > - The doc refers to "real-time", which could imply requirements not = supported. This should be replaced with "rapid". I'll fix this. >=20 > - "absolute time" *indicates* (rather than contains) the number of = seconds... I'll fix this. >=20 > - "third party agent" should be explained, i.e., neither DHCP client = nor DHCP server. I will fix this. >=20 > - "downstream" and "upstream" should be defined as both away from the = server *and towards the client* ("away from the server" has two = directions). Sure, I'll add these words. >=20 > - sec 3 should refer to relays, and returning the entire set or = individual bindings; there is no reason to explain the goals in terms of = access concentrators. I don't know about this. I could certainly change it, but is this really important to you? There was quite a bit of negotiation in the WG about these examples. I don't want to restart that discussion and have it all over again. Does this really matter that much to you? >=20 >=20 > - sec 3.2 appears to provide contradictory advice - caching is = required, but should be avoided? it would be useful to resolve this = inconsistency. Use of Bulk Leasequery is designed to help you avoid caching. >=20 > - sec 3.3 refers to 'fast path', but this term doesn't make sense in = this context because fast-path is a forwarding issue. it would be useful = to explain what you mean, and pick a different term Yes, it is a forwarding issue, and many devices will not forward unless they know that they are forwarding to a device that has received a valid DHCPv4 address. The point (well, one point) of Bulk Leasequery is to allow these forwarders to gather data so that they can make the correct decision in the fast path. ------------ Regards -- Kim From kkinnear@cisco.com Fri Feb 17 12:22:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894D921F86DF; Fri, 17 Feb 2012 12:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiIwTZNyL6uq; Fri, 17 Feb 2012 12:21:59 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0F921F86DC; Fri, 17 Feb 2012 12:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=9842; q=dns/txt; s=iport; t=1329510118; x=1330719718; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gf0mH1lLrcWJvWuvKT9col+C5uZVvCxsYC75xxU/cVw=; b=JAH9NpeBxszqiiI1lpKXWDuBz+USFiWQ3R24CaLTYsE1mOPOnJ/4S5DT RyT6HM0Ymg69uhMN3GDoTrU8vLqNEyQXd2+5ykA+IYXgW1E5srjY0GGVY VhW5XN6Fhxm/DNfCZi8ywS/R2yoMMNoeqPfvrt5nzK3lwk8sTX67cVZtN g=; X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="29371038" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Feb 2012 20:21:58 +0000 Received: from bxb-vpn3-383.cisco.com (bxb-vpn3-383.cisco.com [10.86.249.127]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1HKLvlx015547; Fri, 17 Feb 2012 20:21:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <4F398BA4.3010400@isi.edu> Date: Fri, 17 Feb 2012 15:22:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3987F0.5050000@isi.edu> <4F398BA4.3010400@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, TSV Dir , dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:22:00 -0000 On Feb 13, 2012, at 5:16 PM, Joe Touch wrote: > Hi, all, >=20 > One additional transport suggestion: >=20 > - it would be useful to include recommended configurations for TCP = connections. Given these are multi-byte request/response exchanges, = Nagle should be disabled, e.g. One of the co-authors had this to say: >=20 > A bone headed implementation (either client or server) might send > bits and pieces of a message (for example, it would be easy for > an implementation to send the 2 bytes for the length of the > message in one request and then the message in a second). This is > exactly what you want the TCP protections for. So, I think we > should be silent on this issue. I also can't see how there is > any harm in leaving it enabled (even in a 'clean' > implementation). >=20 I tend to agree with him -- I don't see that this =09 is going to cause a problem if we don't disable it. But maybe I'm missing something. Is there an important problem if we don't specify this one way or another? Thanks -- Kim >=20 > Joe >=20 > On 2/13/2012 2:00 PM, Joe Touch wrote: >> Hi, all, >>=20 >> I've reviewed this document as part of the transport area = directorate's >> ongoing effort to review key IETF documents. These comments were = written >> primarily for the transport area directors, but are copied to the >> document's authors for their information and to allow them to address >> any issues raised. The authors should consider this review together = with >> any other last-call comments they receive. Please always CC >> tsv-dir@ietf.org if you reply to or forward this review. >>=20 >> This request was received Feb. 2, 2012. >>=20 >> This document describes an extension to DHCPv4 for the bulk query and >> transfer of current lease status over TCP. >>=20 >> The following transport issues were noted, and are significant: >>=20 >> UPDATES- The document updates DHCP with support for TCP, and as such >> this document seems like it should UPDATE RFC2131 >>=20 >> PORT USE- Although DHCPv4 has an assigned TCP port, this document = should >> clearly indicate that there is no other specified use of that port = other >> than the bulk lease query described in this document >>=20 >> It should further explain why no other existing DHCP exchanges are = not >> valid on the TCP port. >>=20 >> CONNECTION MANAGEMENT- The document describes the use of TCP = connections >> for bulk transfer, but needs to be more specific about which side = (relay >> client or server) closes the connection, under what circumstances, = and >> with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793) >>=20 >> sec 7.3 indicates some conditions for terminating connections; this >> section should indicate which side performs this, and by what method >> (CLOSE, ABORT) >>=20 >> this sec also allows connections to stay open after all pending >> transactions are complete (MAY); the rationale for this should be = given, >> or the connection MUST be closed. >>=20 >> the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is >> particularly problematic on this issue because it discusses aborting = a >> request using in-band data, which may not be available if the = connection >> is closed using ABORT. the state of other pending connection shsould = be >> discussed too. >>=20 >> TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this >> intended to supercede any TCP timeout? or is it intended to be the = min >> of the TCP timeout and the specified one? >>=20 >> This section should more carefully explain behavior when a connection = is >> dropped and the reason - e.g., timeout, abort, close. >>=20 >> INTERLEAVING- sec 7.7 says that the server MUST interleave replies; >> there doesn't seem a valid reason for this requirement. clearly the >> receiver MUST tolerate interleaved replies. having the server = interleave >> replies is relevant only if each request/reply has its own timeout -- >> which should be overridden if there is another response in progress >> anyway. This issue should be more clearly explained and motivated. >>=20 >> There were some other issues noted in this document. These comments >> appear below, and although not focused on transport issues, they >> represent significant issues that IMO should be addressed as well. >>=20 >> NOTE - regarding some terminology issues, I did not survey current = DHCP >> RFCs for consistency, but IMO these terms should be corrected even if >> they are then inconsistent with existing specs. >>=20 >> Joe >>=20 >> ----------- >>=20 >> Major non-transport issues: >>=20 >> - In many places the doc allows inaction to substitute for either >> positive or negative confirmation. IMO, this invites implementation >> errors, and should be avoided. E.g., status return codes, data source >> option missing, query-for-all-configured-IPs, etc. >>=20 >> - the data source option reserved codes need more detailed >> specification. if these are intended for future use, then they MUST = be >> ignored by the receiver (at least). if they are to mean anything at = all, >> at least one bit (typically all of them) MUST be set to zero by the >> transmitter for implementations that do not support any of the = component >> fields. >>=20 >> further, the length of this option MUST be 1 >>=20 >> - The protocol supports bulk transfer that is not data driven. This >> could represent a security vulnerability by exposing information that >> may not be on the data path (and thus already accessible) to a relay >> agent. This should be discussed in the security considerations = section. >>=20 >> - Integer quantities should be referred to as "unsigned 32-bit = integers" >> throughout. >>=20 >> - "VPN" is used throughout to refer to "private" addresses (RFC = 1918); a >> VPN is not just private addressing. >>=20 >> - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used >> throughout without context. Any time SHOULD is used instead of MUST = (or >> SHOULD NOT rather than MUST NOT), it is useful to explain a viable >> exception. If no such exception exists, the rationale for selecting >> SHOULD over MUST should be included. >>=20 >> - It would be useful to explain why STATUS-CODE strings MUST NOT be >> null-terminated; is that a protocol violation, or are you just saying >> that NULLs are valid in these strings? the description should be = clear >> that the string field describes the string length without any >> termination characters. >>=20 >> - start-time-of-state is expressed as an offset from base-time; this >> appears to be the only time indicated as an offset rather than as an >> absolute. That inconsistency invites implementation errors; IMO, this >> should be absolute too. >>=20 >> - option lengths: throughout, the doc refers to option lengths as = being >> "an octet"; they are *indicated* in one octet. Some are constant = (e.g., >> DCHP-STATE), some allow the contents of the octet to vary. Again, = this >> is an *unsigned integer* octet. >>=20 >> - some of the information provided (in DHCP-STATE) goes beyond that = of >> DHCP. It would be useful to motivate the need for this information in = a >> bulk query, and why it is not similarly available for nodes using UDP >> (e.g., as an extension to DHCPv4, not just to the bulk transfer >> command). again, absence of state information should not indicate = state. >> State should always be expressed explicitly. these states are further >> meaningless without a state diagram explaining them. if such a = diagram >> is not possible (as noted at end of sec 6.2.7), then the states are >> irrelevant and the option should not be included. >>=20 >> - in sec 6.2.9 the term "not allowed" should be explained - are they >> reserved for future use and thus ignored? or are they "not allowed" - = in >> which case the doc should indicate handling if they appear. >>=20 >> - sec 7.4 states that the clock skew of zero is desired; this assumes >> E2E delays under 1sec. An explanation of why this is desired should = be >> given, as well as the consequences of it not. >>=20 >> Other non-transport issues: >>=20 >> - The document includes definitions and references to irrelevant >> deployment and implementation issues, notably DSLAMs, concentrators, = and >> access concentrators. These should not appear formally; they should = be >> used only to usefully illustrate currently intended uses. >>=20 >> - The doc refers to "real-time", which could imply requirements not >> supported. This should be replaced with "rapid". >>=20 >> - "absolute time" *indicates* (rather than contains) the number of >> seconds... >>=20 >> - "third party agent" should be explained, i.e., neither DHCP client = nor >> DHCP server. >>=20 >> - "downstream" and "upstream" should be defined as both away from the >> server *and towards the client* ("away from the server" has two >> directions). >>=20 >> - sec 3 should refer to relays, and returning the entire set or >> individual bindings; there is no reason to explain the goals in terms = of >> access concentrators. >>=20 >> - sec 3.2 appears to provide contradictory advice - caching is = required, >> but should be avoided? it would be useful to resolve this = inconsistency. >>=20 >> - sec 3.3 refers to 'fast path', but this term doesn't make sense in >> this context because fast-path is a forwarding issue. it would be = useful >> to explain what you mean, and pick a different term >>=20 >> ---- >>=20 >>=20 >>=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Feb 17 15:00:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708A911E80AF for ; Fri, 17 Feb 2012 15:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.039 X-Spam-Level: X-Spam-Status: No, score=-9.039 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+AaF9fGT01M for ; Fri, 17 Feb 2012 15:00:08 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 532B511E80B5 for ; Fri, 17 Feb 2012 15:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=27155; q=dns/txt; s=iport; t=1329519607; x=1330729207; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=bjdJj998UQgzJ9ofUiupqKf346ZEOOXH/3nVkDd36eI=; b=H3TbKuyzO/isi9Q2sd4CwOCgaYQyK1vfZxgt30plKVjjFsO9WstgZPKP ZJv4iJZ42LQOSH52wt0SDiYyusuB5Avk8L7WSDa4U/szGLlvPu1f24TcY j2sej5jrYtcgaLd7V3MajdrcGdq3731YNdGcR1YO3/PaJnSk+dVbWTsdw c=; X-Files: ~WRD000.jpg, image001.jpg : 823, 458 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAHfbPk+tJV2d/2dsb2JhbABBAw4IgjeofoZWgQeBFGEBAQEEAQEBAg0BCQkIAQI+CxACAQgHBwMEAQEGAQEBAgYCAgwHAQYBAQUQDQIBHwkHAQEBAQMBEQEIGodnmhMBnleJOwENgicCBAgYCAMGAQKDbkADAQcHBgEEAwmCQGMEiE6HHFcIiCaFf4hqEFaBNAEE X-IronPort-AV: E=Sophos;i="4.73,440,1325462400"; d="jpg'145?scan'145,208,217,145";a="59896240" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 17 Feb 2012 23:00:06 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q1HN06o2026335; Fri, 17 Feb 2012 23:00:06 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 17:00:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CCEDC7.E3BA764C"; type="multipart/alternative" Date: Fri, 17 Feb 2012 17:00:03 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Question for SOL_MAX_RT draft Thread-Index: AcztpopV7Zrc+d9ZQAyXzS8LQyCqFQAHtPzw References: From: "Bernie Volz (volz)" To: "Andre Kostur" , "Timothy Winters" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 17 Feb 2012 23:00:06.0445 (UTC) FILETIME=[E3E285D0:01CCEDC7] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question for SOL_MAX_RT draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:00:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEDC7.E3BA764C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CCEDC7.E3BA764C" ------_=_NextPart_002_01CCEDC7.E3BA764C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yes, this violates the intent of this change. =20 Perhaps the problem is that the draft needs to clearly indicate that (at least) the following RFC 3315 behavior is changed, as the section indicated in the draft is LATER (17.1.3): =20 17.1.2. Transmission of Solicit Messages =20 ... =20 A client MUST collect Advertise messages for the first RT seconds, unless it receives an Advertise message with a preference value of 255. ... If the client receives an Advertise message that does not include a Preference option with a preference value of 255, the client continues to wait until the first RT elapses. If the first RT elapses and the client has received an Advertise message, the client SHOULD continue with a client-initiated message exchange by sending a Request message. =20 ... =20 If the client does not receive any Advertise messages before the first RT has elapsed, it begins the retransmission mechanism described in section 14. The client terminates the retransmission process as soon as it receives any Advertise message, and the client acts on the received Advertise message without waiting for any additional Advertise messages. =20 The intent is NOT to terminate the retransmission process as soon as ANY Advertise message is received, instead this needs to be modified to indicate only if the Advertise can be used to Request (a NoAddrsAvail Advertise is not a useful one to Request). Section 17.1.3 starts out with saying "The client MUST ignore any Advertise ... the NoAddrsAvail". =20 So, I think the draft needs to be expanded as to what is in section 4. Updates to RFC 3315? =20 BTW: The ordering of the original text might also have led to this problem to begin with? If RFC 3315 simply had said earlier (in 17.1.2): =20 The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. =20 (Of course the next text in the draft Section 4 is also needed to cause the client to pick up the SOL_MAX_RT option.) =20 - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Andre Kostur Sent: Friday, February 17, 2012 2:01 PM To: Timothy Winters Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question for SOL_MAX_RT draft =20 I would argue it should be for all sessions. The client isn't supposed to assume that there is only one DHCP server, that's why the client is supposed to be collecting Advertisements from (potentially) multiple DHCP servers (RFC 3315, section 17.1.2: "...Rather, the client collects Advertise messages until the first RT has elapsed."). So why isn't it examining the 4 Advertisements to find the one that doesn't claim "NoAddrsAvail"? Why would the client expect a different answer if it immediately Solicited again? You're going to hit all of the same servers again (probably), and get nearly the same answers again. =20 On Fri, Feb 17, 2012 at 10:49, Timothy Winters wrote: Hello, While implementing some testing around draft-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an implementation that viewed the draft differently then I did. I'm including the statement from an implementation that we encountered when developing test cases. "RFC 3315, it allows a DHCPv6 client to try another server and our DHCPv6 client does it by initiating another DHCPv6 Solicitation with a new transcation ID. In terms, there may be an environment with several DHCPv6 servers. If a client gets a NoAddrsAvail in DHCPv6 Advertisement, it can try another server immediately by initiating a new DHCPv6 Solicitation with a new Transaction ID. I think SOL_MAX_RT counts only within the same session, in terms of the same Transaction ID. In the other words, RFC leaves the flexibility for an environment with multiple DHCPv6 Servers and clients can send a new DHCPv6 Solicitation message with a new Transaction ID if there is no address available. Client doesn't need to assume there is only one DHCPv6 Server, and an DHCPv6 Advertisement with NoAddrsAvail doesn't necessarily mean that the client need to wait SOL_MAX_RT. The Client can try another DHCPv6 server." I thought the spirit of the draft was to limit the the amount of DHCP Solicits. If a DHCP client applies the SOL_MAX_RT to only one session, the Client will continuously transmit DHCP solicits looking for another DHCP Server. Therefore the SOL_MAX_RT should applies to all session and is not limited to one. What other think about this? Regards, Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =20 --=20 Andre Kostur=20 Senior Product Design Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com =20 =20 =20 ------_=_NextPart_002_01CCEDC7.E3BA764C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Yes, this violates the intent of this change.

 

Perhaps the problem is that the draft needs to clearly indicate that = (at least) the following RFC 3315 behavior is changed, as the section = indicated in the draft is LATER (17.1.3):

 

17.1.2. = Transmission of Solicit Messages

 

…

 

   A = client MUST collect Advertise messages for the first RT = seconds,

   unless = it receives an Advertise message with a preference value = of

   255. = … If the client receives an Advertise message that does = not

   = include a Preference option with a preference value of 255, = the

   client = continues to wait until the first RT elapses.  If the first = RT

   = elapses and the client has received an Advertise message, the = client

   SHOULD = continue with a client-initiated message exchange by sending = a

   = Request message.

 

…

 

   If the = client does not receive any Advertise messages before = the

   first = RT has elapsed, it begins the retransmission = mechanism

   = described in section 14.  The client terminates the = retransmission

   = process as soon as it receives any Advertise message, and the = client

   acts = on the received Advertise message without waiting for = any

   = additional Advertise messages.

 

The intent is NOT to terminate the retransmission process as soon as = ANY Advertise message is received, instead this needs to be modified to = indicate only if the Advertise can be used to Request (a NoAddrsAvail = Advertise is not a useful one to Request). Section 17.1.3 starts out = with saying “The client MUST ignore any Advertise … the = NoAddrsAvail”.

 

So, I think the draft needs to be expanded as to what is in section = 4.  Updates to RFC 3315?

 

BTW: The ordering of the original text might also have led to this = problem to begin with? If RFC 3315 simply had said earlier (in = 17.1.2):

 

   The = client MUST ignore any Advertise message that includes a = Status

   Code = option containing the value NoAddrsAvail, with the = exception

   that = the client MAY display the associated status message to = the

   = user.

 

(Of course the next text in the draft Section 4 is also needed to = cause the client to pick up the SOL_MAX_RT = option.)

 

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Andre Kostur
Sent: Friday, February 17, 2012 2:01 = PM
To: Timothy Winters
Cc: = dhcwg@ietf.org
Subject: Re: [dhcwg] Question for SOL_MAX_RT = draft

 

I would = argue it should be for all sessions.   The client isn't supposed to = assume that there is only one DHCP server, that's why the client is = supposed to be collecting Advertisements from (potentially) multiple = DHCP servers (RFC 3315, section 17.1.2: "...Rather, the client collects Advertise = messages until the first RT has elapsed.").  So why = isn't it examining the 4 Advertisements to find the one that = doesn't claim "NoAddrsAvail"?  Why would the client = expect a different answer if it immediately Solicited again? =  You're going to hit all of the same servers again (probably), and = get nearly the same answers again.

 

On Fri, Feb 17, 2012 at 10:49, Timothy Winters <twinters@iol.unh.edu> = wrote:

Hello,
      =          While implementing some testing around = draft-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an = implementation that viewed the draft differently then I did.  I'm = including the statement from an implementation that we encountered when = developing test cases.

       "RFC 3315, = it allows a DHCPv6 client to try another server and our DHCPv6 client = does it by initiating another DHCPv6 Solicitation with a new transcation = ID. In terms, there may be an environment with several DHCPv6 servers. =  If a client gets a NoAddrsAvail in DHCPv6 Advertisement, it can = try another server immediately by initiating a new DHCPv6 Solicitation = with a new Transaction ID.  I think SOL_MAX_RT counts only within = the same session, in terms of the same Transaction ID.

  =      In the other words, RFC leaves the flexibility for = an environment with multiple DHCPv6 Servers and clients can send a new = DHCPv6 Solicitation message with a new Transaction ID if there is no = address available. Client doesn't need to assume there is only one = DHCPv6 Server, and an DHCPv6 Advertisement with NoAddrsAvail doesn't = necessarily mean that the client need to wait SOL_MAX_RT.  The = Client can try another DHCPv6 server."

      =  I thought the spirit of the draft was to limit the the amount of = DHCP Solicits.  If a DHCP client applies the SOL_MAX_RT to only one = session, the Client will continuously transmit DHCP solicits looking for = another DHCP Server.  Therefore the SOL_MAX_RT should applies to = all session and is not limited to one.

      =  What other think about = this?

Regards,
Tim

_____________________________________= __________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg



 

-- =

Andre = Kostur
Senior Product = Design Engineer
P: 604-678-2864
E: akostur@incognito.com
Toll-Free: = 1-800-877-1856



F: 604-678-2864
VoIP: = sip:864@sip.incognito.com


3D"Description:


3D"Description:

 

------_=_NextPart_002_01CCEDC7.E3BA764C-- ------_=_NextPart_001_01CCEDC7.E3BA764C Content-Type: image/jpeg; name="~WRD000.jpg" Content-Transfer-Encoding: base64 Content-ID: <~WRD000.jpg> Content-Description: ~WRD000.jpg Content-Location: %7EWRD000.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== ------_=_NextPart_001_01CCEDC7.E3BA764C Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAA0AL4BAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK/ /9k= ------_=_NextPart_001_01CCEDC7.E3BA764C-- From rdroms.ietf@gmail.com Sat Feb 18 04:39:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514EB21F84E2; Sat, 18 Feb 2012 04:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GebVYFaplKM3; Sat, 18 Feb 2012 04:39:30 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6502821F84E0; Sat, 18 Feb 2012 04:39:30 -0800 (PST) Received: by qan41 with SMTP id 41so4479209qan.10 for ; Sat, 18 Feb 2012 04:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7KIYHoOY9UUUKl1bMMQjArWgQNTzvmGfnSo85uPJ9Og=; b=v2Bbg8XHeiPSJk/K6KbKCTMHuCF5E5v6s3iPmmyXJeonGeP/i4bVKoSLvIKoEjQwd1 MyWlC+xd97ScO6H76N98S6IdC0mtzwA78FntTo6NG1hKZveOX0WotPH7EkI1GkW2ecDu SpxDa740Ccgnm1A9QbxTwF3S1CtQPZFgu3W7E= Received: by 10.229.136.199 with SMTP id s7mr7663590qct.145.1329568767811; Sat, 18 Feb 2012 04:39:27 -0800 (PST) Received: from rtp-rdroms-8916.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id o8sm32990678qan.11.2012.02.18.04.39.25 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 04:39:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4F3ED8FC.6020400@isi.edu> Date: Sat, 18 Feb 2012 07:39:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1251.1) Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, TSV Dir , dhcwg@ietf.org, Kim Kinnear , Ralph Droms Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 12:39:31 -0000 Joe, Kim... On Feb 17, 2012, at 5:47 PM 2/17/12, Joe Touch wrote: > Hi, Kim, >=20 > First, thank you for your detailed response to my quite lengthy = review. >=20 > Some further clarifications and confirmations appear below. >=20 > Joe >=20 > On 2/17/2012 12:09 PM, Kim Kinnear wrote: >>=20 >> Joe, >>=20 >> Thank you for your review. >>=20 >> My responses are indented, below... >>=20 >> On Feb 13, 2012, at 5:00 PM, Joe Touch wrote: >>=20 >>> Hi, all, >>>=20 >> > I've reviewed this document as part of the transport area >>> directorate's ongoing effort to review key IETF documents. These >>> comments were written primarily for the transport area directors, >>> but are copied to the document's authors for their information and >>> to allow them to address any issues raised. The authors should >>> consider this review together with any other last-call comments >>> they receive. Please always CC tsv-dir@ietf.org if you reply to or >>> forward this review. >>>=20 >>> This request was received Feb. 2, 2012. >>>=20 >>> This document describes an extension to DHCPv4 for the bulk query >>> andtransfer of current lease status over TCP. >>>=20 >>> The following transport issues were noted, and are significant: >>>=20 >>> UPDATES- The document updates DHCP with support for TCP, and as >>> suchthis document seems like it should UPDATE RFC2131 >>=20 >> While this document clearly builds on RFC 2131, it >> doesn't actually change anything that anyone is doing >> that is currently based on RFC 2131. My understanding of >> "updates" is that, in order to understand the first RFC >> (in this case, RFC 2131), you need to read all of the >> RFC's that "update" it. That isn't the case here -- you >> can be very happy reading and implementing DHCPv4 by >> reading RFC 2131 and never have to know that DHCPv4 Bulk >> Leasequery exists. In general, in the DHC WG, we seem to >> set a pretty high bar for what "udpates" another RFC. I >> don't see that this document has met those requirements. >> But this isn't really my call. I'll let Ralph Droms and >> the DHC WG chairs decide on this one, and I'll do >> whatever they tell me to do. >=20 > Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as per = RFC 2131 is changed by this doc. If DHCP fundamentally starts requiring = TCP port support, then this doc then changes the spec as described in = 2131 IMO. Joe - I don't see that this document fundamentally requires TCP port = support for DHCP operation as described in RFC 2131. This document = describes a protocol that is closely related to but independent of RFC = 2131, and a server based on RFC 2131 can perform all the DHCP functions = in RFC 2131 without considering this document. So, I can see your point = but I disagree that this document updates RFC 2131. > Here are the reasons I think it DOES modify DHCP: >=20 > - Sec 10 requests option codes that extend the tables defined > in the original RFC >=20 > I couldn't locate a recommendation on whether DHCP servers MAY = implement this extension, SHOULD, or MUST (did I miss it? if not, it = should be added). Regardless, that too would be a reason for this as an = update to 2131. It's only NOT an update if this service is independent, = IMO, and it doesn't read that way to me. There are other RFCs that add new, independent functions to DHCP without = making changes to RFC 2131 (e.g., RFC 4388), which are not listed as = updating RFC 2131. - Ralph >=20 From touch@isi.edu Fri Feb 17 14:47:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20D11E808D; Fri, 17 Feb 2012 14:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys3F7jkPHeFk; Fri, 17 Feb 2012 14:47:33 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 41A8F11E80A1; Fri, 17 Feb 2012 14:47:33 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1HMlPXL021294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Feb 2012 14:47:25 -0800 (PST) Message-ID: <4F3ED8FC.6020400@isi.edu> Date: Fri, 17 Feb 2012 14:47:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Kim Kinnear References: <4F3987F0.5050000@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 18 Feb 2012 07:22:21 -0800 Cc: "tsv-ads@tools.ietf.org" , TSV Dir , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, dhcwg@ietf.org, IETF discussion list Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 22:47:35 -0000 Hi, Kim, First, thank you for your detailed response to my quite lengthy review. Some further clarifications and confirmations appear below. Joe On 2/17/2012 12:09 PM, Kim Kinnear wrote: > > Joe, > > Thank you for your review. > > My responses are indented, below... > > On Feb 13, 2012, at 5:00 PM, Joe Touch wrote: > >> Hi, all, >> > > I've reviewed this document as part of the transport area >> directorate's ongoing effort to review key IETF documents. These >> comments were written primarily for the transport area directors, >> but are copied to the document's authors for their information and >> to allow them to address any issues raised. The authors should >> consider this review together with any other last-call comments >> they receive. Please always CC tsv-dir@ietf.org if you reply to or >> forward this review. >> >> This request was received Feb. 2, 2012. >> >> This document describes an extension to DHCPv4 for the bulk query >> andtransfer of current lease status over TCP. >> >> The following transport issues were noted, and are significant: >> >> UPDATES- The document updates DHCP with support for TCP, and as >> suchthis document seems like it should UPDATE RFC2131 > > While this document clearly builds on RFC 2131, it > doesn't actually change anything that anyone is doing > that is currently based on RFC 2131. My understanding of > "updates" is that, in order to understand the first RFC > (in this case, RFC 2131), you need to read all of the > RFC's that "update" it. That isn't the case here -- you > can be very happy reading and implementing DHCPv4 by > reading RFC 2131 and never have to know that DHCPv4 Bulk > Leasequery exists. In general, in the DHC WG, we seem to > set a pretty high bar for what "udpates" another RFC. I > don't see that this document has met those requirements. > But this isn't really my call. I'll let Ralph Droms and > the DHC WG chairs decide on this one, and I'll do > whatever they tell me to do. Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as per RFC 2131 is changed by this doc. If DHCP fundamentally starts requiring TCP port support, then this doc then changes the spec as described in 2131 IMO. Here are the reasons I think it DOES modify DHCP: - Sec 10 requests option codes that extend the tables defined in the original RFC I couldn't locate a recommendation on whether DHCP servers MAY implement this extension, SHOULD, or MUST (did I miss it? if not, it should be added). Regardless, that too would be a reason for this as an update to 2131. It's only NOT an update if this service is independent, IMO, and it doesn't read that way to me. >> PORT USE- Although DHCPv4 has an assigned TCP port, this document >> should clearly indicate that there is no other specified use of that >>. port other than the bulk lease query described in this document > > Sure. >> >> It should further explain why no other existing DHCP exchanges are >> not valid on the TCP port. > > I've been taken to task by various IETF folks at > varying levels of seniority for explaining too *much* of > the "why". My understanding is that this is a protocol > specification and not a design document, and as such it > is not only not necessary but frequently > counter-productive to give lots of justifications for the > decisions made when constructing the protocol. > > In this case, I can't speak for the wG at large, because > we never proposed anything else. The reason we didn't > propose anything else was that we didn't want to "update" > RFC 2131 with a new way to do DHCPv4 in general. But > that all kind of comes down to "because we said so". We > were trying to keep this draft focused. But if I put > words in the document which say that, someone in the WG > would tell me to take them out. > > I have no problem motivating the "interesting" decisions > we've made, or perhaps the contentious ones, but this one > was a no-brainer that never even came up (to the best of > my memory). > > Having said all of that, I'll put something in that says > that we were trying to keep it simple. Thanks. In this case, it's important to suggest why others should not add conventional DHCP query support to the TCP port. >> CONNECTION MANAGEMENT- The document describes the use of TCP >> connections for bulk transfer, but needs to be more specific about which >> side (relay client or server) closes the connection, under what >> circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT, >> as per RFC 793) > > Here is what we have now, 7.8 is for clients, 8.5 is for > servers: > >> 7.8. Closing Connections [Client Section] >> >> The requestor SHOULD close the connection after the >> DHCPLEASEQUERYDONE message is received for the last outstanding query >> that it has sent, if it has no more queries to send. Under what conditions is it useful to not close at this time, and if so, when/why is it eventually closed? In this case it's also useful to explain what "no more queries to send" means - are clients encouraged to keep the connection open in case there are more to send, or do you expect that the client knows when it opens the connection whether it has more to send - and if so, shouldn't it have already sent them? >> >> 8.5. Closing Connections [Server Section] >> >> The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT >> seconds for a particular connection after it sends a >> DHCPLEASEQUERYDONE message over that connection and if there is no >> current query outstanding for that connection. It should clear this Is this a SHOULD? And should the timer be cleared or restarted? Under what conditions is it useful to not close at this time, and if so, when/why is it closed? >> timer if a query arrives over that connection. If the timer expires, >> the DHCPv4 server should close the connection. Is this a SHOULD, as well? Again, under what conditions is it useful to not close at this time, and if so, when/why is it closed? >> The server MUST close its end of the TCP connection if it encounters >> an error sending data on the connection. The server MUST close its >> end of the TCP connection if it finds that it has to abort an in- >> process request. A server aborting an in-process request SHOULD >> attempt to signal that to its requestors by using the QueryTerminated >> status code in the status-code option in a DHCPLEASEQUERYDONE >> message, including a message string indicating details of the reason >> for the abort. If the server detects that the requesting end of the >> connection has been closed, the server MUST close its end of the >> connection. OK. I found it a bit confusing to have this in separate places, but I viewed this from the transport perspective. This is fine. > All connections are closed with a graceful CLOSE, and not > with an ABORT. I'll add that to the document. > > I'm at a loss to know how to be more specific about which > side of the connection closes the connection. There are > rules for the client in 7.8, and rules for the server in > 8.5. Somewhere you should state that the protocol exchange typically involves the client closing the connection, and that the server closes only under exceptions. >> sec 7.3 indicates some conditions for terminating connections; this >> section should indicate which side performs this, and by what >> method(CLOSE, ABORT) > > Section 7.3 discusses in two places where the "requestor" may > drop the connection. The term "requestor" is used to > indicate which "side" performs the actions. All of > Section 7 is about "Requestor Behavior", and the specific > details of section 7.3 in all cases indicate that the > instructions for dealing with the connection concern the > "requestor" explicitly. > > I'll enhance the explanation to include that CLOSE should > be used. > > If there is a specific set of instructions that are > unclear, I don't see them, so it would help me if you > could give me more detailed guidance than "Section 7.3". > Thanks. It's probably sufficient to replace "requestor" with "client" to be consistent. However, this section then supercedes the description in 7.8 and 8.5 above - i.e., you are handling exceptions on the client side as well. I.e., 7.8 needs to include the exception cases listed in 7.3, or they should just be moved there. >>> this sec also allows connections to stay open after all pending >>> transactions are complete (MAY); the rationale for this should be >>> given, or the connection MUST be closed. > > I will add some words which clarify the reasons why you > might want to leave the connection open after all pending > transactions are complete. FWIW, again this contradicts 7.8 which says the client SHOULD close after the response is received if it has no more queries to send. This says "MAY" leave open. That's not the complement to SHOULD close. >> the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is >> particularly problematic on this issue because it discusses aborting a >> request using in-band data, which may not be available if the connection >> is closed using ABORT. the state of other pending connection shsould be >> discussed too. > > The in-band data is not required for proper protocol > operation, it is valuable because it can limit the amount > of data required when and if the connection is > reestablished. All connections are closed by CLOSE. I > assume that, in your comment, "other pending > connection[s]" means other data flows that might exist on > the TCP connection that is coming down. I will add some > words that say that those Bulk Leasequery data flows will > also be stopped. OK. >> TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is >> this intended to supercede any TCP timeout? or is it intended to be >> the min of the TCP timeout and the specified one? > > The BULK_LQ_DATA_TIMEOUT is completely application > specific and essentially independent of the underlying > connection timeout. I will add words to that effect > in the document. OK. >> This section should more carefully explain behavior when a >> connection is dropped and the reason - e.g., timeout, abort, >> close. > > The application employing Bulk Leasequery doesn't > care about *why* the connection went away. It > doesn't have to know if it was abort, close, or > timeout. I will say that in this section. Hmm. I would think that this information would be passed up to the application. >> INTERLEAVING- sec 7.7 says that the server MUST interleave >> replies; >> there doesn't seem a valid reason for this requirement. clearly the >> receiver MUST tolerate interleaved replies. having the server interleave >> replies is relevant only if each request/reply has its own timeout -- >> which should be overridden if there is another response in progress >> anyway. This issue should be more clearly explained and motivated. > > Robert Sparks offered clarification, which I like > a lot and have already agreed to use: I didn't see that; can you send that to tsv-dir@ietf.org and me? >> Is the requirement you are really trying to capture "MUST >> NOT block sending replies on new queries until all >> replies for the existing query are complete."? >> >> There were some other issues noted in this document. These >> comments appear below, and although not focused on transport >> issues, they represent significant issues that IMO should be >> addressed as well. >> >> NOTE - regarding some terminology issues, I did not survey current >> DHCP RFCs for consistency, but IMO these terms should be corrected >> even if they are then inconsistent with existing specs. >> Joe >> >> ----------- >> >> Major non-transport issues: >> >> - In many places the doc allows inaction to substitute for either >> positive or negative confirmation. IMO, this invites implementation >> errors, and should be avoided. E.g., status return codes, data source >> option missing, query-for-all-configured-IPs, etc. > > While I personally tend to agree with you on this one, I > have clear direction from the DHC WG that this is *not* > the approach that the WG wants to take. Here is the > status code text: > >> A status-code option MAY appear in the options field of a DHCPv4 >> message. If the status-code option does not appear, it is assumed >> that the operation was successful. The status-code option SHOULD NOT >> appear in a message which is successful unless there is some text >> string that needs to be communicated to the requestor. > > This was wrangled over at some length in the DHC WG, > and this was the way that it needed to be to pass > last call. I don't feel that I can change it > at this time. AOK. I'll go down on the record as noting this as a bad idea that invites erroneous implementations, and the IESG can decide what it wants to recommend. >> >> - the data source option reserved codes need more detailed >> specification. if these are intended for future use, then they MUST be >> ignored by the receiver (at least). if they are to mean anything at all, >> at least one bit (typically all of them) MUST be set to zero by the >> transmitter for implementations that do not support any of the component >> fields. >> >> further, the length of this option MUST be 1 > > Yes, subsequent to the creation of this section, > Amanda Baber of IANA enlightened me regarding > the different between RESERVED and UNASSIGNED. > These should be UNASSIGNED, and I will add words > that say that a receiver should ignore the > bits that are unassigned. Good. >> >> - The protocol supports bulk transfer that is not data driven. >> This could represent a security vulnerability by exposing >> information that may not be on the data path (and thus already >> accessible) to a relay agent. This should be discussed in the >> security considerations section. > > All data that is exposed has already been > exposed using UDP to regular DHCP port. But please see > my response to Stephen Farrell (which is too long to include > here) to see if it covers the issues about which you > have concerns. Again, I didn't see it; please send a copy to tsv-dir@ietf.org >> >> - Integer quantities should be referred to as "unsigned 32-bit integers" throughout. > > Good point (though some are 16 bits). The signed-ness is not > specified and should be. I'll make sure that it is. AOK. >> >> - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a VPN is not just private addressing. > > Hmm. Actually, VPN in this document does not refer to RFC 1918 > private addressing. If this is important to you, could you > be more specific as to your concern? OK. I don't understand how it's being used, but if it's consistent with the rest of DHCP, that's fine. However, I got thrown off by your use of 10.x.x.x. There are appropriate addresses to use as examples in RFCs - see RFC 5737, and please change this example accordingly. >> - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are >> used throughout without context. Any time SHOULD is used instead of >> MUST (or SHOULD NOT rather than MUST NOT), it is useful to explain >> a viable exception. If no such exception exists, the rationale for >> selecting SHOULD over MUST should be included. > > This is an interesting approach, which is new to me. I > can see the value in looking for viable exceptions. I > think justifying SHOULD and not MUST is a bit much, and > wouldn't make it through the "keep it short and simple" > filters that the DHC WG seems to place on DHC drafts. > But as I said, I'll look at every SHOULD (NOT) and see if > I can find concise examples of reasons. But I'm > concerned that this will greatly lengthen the draft. I would argue that any SHOULD that cannot be justified ought to be converted to a MUST ;-) That still keeps it short. >> - It would be useful to explain why STATUS-CODE strings MUST NOT >> be null-terminated; is that a protocol violation, or are you just >> saying that NULLs are valid in these strings? the description >> should be clear that the string field describes the string length >> without any termination characters. > > I will clarify this. Nulls are not allowed in the strings. > DHCP options have an unfortunate history where some > large vendors null terminated their strings even though > they were not supposed to, so now we always make a big > deal out of it so it doesn't happen again. Good. >> - start-time-of-state is expressed as an offset from base-time; >> this appears to be the only time indicated as an offset rather than >> as an absolute. That inconsistency invites implementation errors; >> IMO, this should be absolute too. > > There are two kinds of time options here, input options > and output options. The input options are all absolute > times. The output options are all offset times from the > base time (which by design is the only absolute time in > the output packets). That'd be very useful to explain this way. Is this typical for DHCP? It's quite confusing IMO. > ...There are several input options > defined in this document. The start-time-of-state is the > only output option defined in this draft. It is defined > as a offset to the base time in large part because the > *other* output options that are used in the DHCP packet > are *also* offsets to the base time. These options are > not new, but are options that already exist in other > RFC's. So, while it looks like the state-time-of-state > is the odd man out at first glance, it actually is an > offset time because the *other* options with which it > will appear are also offset times. > >> >> - option lengths: throughout, the doc refers to option lengths as >> being "an octet"; they are *indicated* in one octet. Some are constant >> (e.g., DCHP-STATE), some allow the contents of the octet to vary. Again, >> this is an *unsigned integer* octet. > > Yes, the size of an option is stored in > one octet. So, yes, the length is *indicated* > by the value in that one octet. > > But the length may be 1 octet, it may be > 5 octets, it may vary between 8 and 10 octets. > > I don't understand your concern. Are you > saying that the length should not be > stated to be "1 octet" or "5 octets"? The length should be "indicated in 1 octet". I'm just suggesting a change to the way it's described. When you say "the length is an octet", that is ambiguous and can mean that the length value is 1, not just that this value is stored in one octet. > I will fix the integer to be specifically > unsigned (as previously indicated). >> >> - some of the information provided (in DHCP-STATE) goes beyond >> that of DHCP. It would be useful to motivate the need for this >> information in a bulk query, and why it is not similarly available >> for nodes using UDP (e.g., as an extension to DHCPv4, not just to >> the bulk transfer command). again, absence of state information >> should not indicate state. State should always be expressed >> explicitly. these states are further meaningless without a state >> diagram explaining them. if such a diagram is not possible (as >> noted at end of sec 6.2.7), then the states are irrelevant and the >> option should not be included. > > The state transition diagram can certainly be drawn, but > as it is fully connected, such a picture conveys no > useful information. It's sufficient to indicate this then. > ... The transitions are not themselves > useful in any case, as the the Bulk Leasequery is a > snapshot of information at one instant of time. There is > every reason to assume that as the state moves from one > value to another that an external entity would not see > all (or even many) of these transitions. This is a > snapshot of the DHCP state, and could be nothing else in > the environment of Bulk Leasequery. > > The reason why the state transition graph is fully > connected is due to the common practice in DHCPv4 of > having two servers running in a failover relationship. > There are then two state machines for the lease state, > and at times one "leads" and the other "follows", and at > other times the other "leads" and its partner "follows". > So, examined individually, the state machines for each > individual failover partner is fully connected because at > any time it may receive an update from its partner that > it decides to accept that will simply "set" the state to > the value supplied by the partner. > > All of this is orthogonal to the Bulk Leasequery protocol > -- except that we want the user of the Bulk Leasequery > protocol to be able to make sense out of information > supplied by each of the failover partners. Or any > partners running any increased availability solution. > > So, that is the reason why the dhcp-state option exists > at all -- to allow the user of Bulk Leasequery to make > sense out of the results of sending a Bulk Leasequery to > two different (but cooperating) DHCPv4 servers. > > The DHC WG felt that this information was worthwhile to > have in this document, and I agree (or we wouldn't have > put it in). Using the failover case as a justification would be helpful. > > - in sec 6.2.9 the term "not allowed" should be explained - are >> they reserved for future use and thus ignored? or are they "not >> allowed" - in which case the doc should indicate handling if they >> appear. > > Ah, good catch. The "not allowed" will become UNASSIGNED, > based on my conversation with Amanda Baber of IANA. > I will add words that suggest that they should be > ignored. > > The point of this table is, actually, not how to > handle them (that is the up to the vpn-option draft/RFC), > but rather to define a single new value. AOK. >> - sec 7.4 states that the clock skew of zero is desired; this >> assumes E2E delays under 1sec. An explanation of why this is >> desired should be given, as well as the consequences of it not. > > I have given specific instructions on how to handle non-zero > clock skews. There are no "consequences". You code it > so that it works with non-zero clock skew. Period. > > It is desired because it is less confusing to humans. I would argue that this then irrelevant, and there should be no statement about a skew of zero being preferred, since it could drive implementations that way unnecessarily. >> Other non-transport issues: >> >> - The document includes definitions and references to irrelevant >> deployment and implementation issues, notably DSLAMs, concentrators, and >> access concentrators. These should not appear formally; they should be >> used only to usefully illustrate currently intended uses. > > These appear in the text in order to give > the otherwise abstract design goals some concrete > examples. We already removed a lot of the design > goals, are you suggesting that they all be removed? Actually, yes, except as examples in the intro/motivation. Elsewhere they are IMO distracting. >> - The doc refers to "real-time", which could imply requirements not supported. This should be replaced with "rapid". > > I'll fix this. >> >> - "absolute time" *indicates* (rather than contains) the number of seconds... > > I'll fix this. >> >> - "third party agent" should be explained, i.e., neither DHCP client nor DHCP server. > > I will fix this. >> >> - "downstream" and "upstream" should be defined as both away from the server *and towards the client* ("away from the server" has two directions). > > Sure, I'll add these words. AOK to all above. >> - sec 3 should refer to relays, and returning the entire set or >> individual bindings; there is no reason to explain the goals in terms of >> access concentrators. > > I don't know about this. I could certainly change it, > but is this really important to you? There was quite a > bit of negotiation in the WG about these examples. I > don't want to restart that discussion and have it all > over again. Does this really matter that much to you? The examples should focus on client/server/relay terminology. If other example terms are used, they should be parenthetical examples: relay (e.g., at a concentrator) The point is that this is relevant without the concentrator. A concentrator is just one current example of where a relay exists, not the only one. >> - sec 3.2 appears to provide contradictory advice - caching is required, but should be avoided? it would be useful to resolve this inconsistency. > > Use of Bulk Leasequery is designed to help you avoid > caching. OK - it'd be useful to be clear on that in sec 3.2. >> - sec 3.3 refers to 'fast path', but this term doesn't make sense in this context because fast-path is a forwarding issue. it would be useful to explain what you mean, and pick a different term > > Yes, it is a forwarding issue, and many devices > will not forward unless they know that they are forwarding > to a device that has received a valid DHCPv4 address. > The point (well, one point) of Bulk Leasequery is to > allow these forwarders to gather data so that they > can make the correct decision in the fast path. Per-IP validation of that sort of permission isn't a fast-path decision. Fast-path involves forwarding and policy decisions (which are not typically /32 decisions). It would be useful to say this information is useful so such routers can make the appropriate decision, but the path (fast or slow) is irrelevant IMO. > ------------ > > Regards -- Kim > > From touch@isi.edu Fri Feb 17 22:50:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608D121E8021; Fri, 17 Feb 2012 22:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itzW6+9d6I6e; Fri, 17 Feb 2012 22:50:23 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1821E8014; Fri, 17 Feb 2012 22:50:19 -0800 (PST) Received: from [192.168.1.100] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1I6napv021472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Feb 2012 22:49:46 -0800 (PST) Message-ID: <4F3F4A00.1010508@isi.edu> Date: Fri, 17 Feb 2012 22:49:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Kim Kinnear References: <4F3987F0.5050000@isi.edu> <4F398BA4.3010400@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 18 Feb 2012 07:22:21 -0800 Cc: "tsv-ads@tools.ietf.org" , TSV Dir , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, dhcwg@ietf.org, IETF discussion list Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 06:50:29 -0000 Hi, Kim, On 2/17/2012 12:22 PM, Kim Kinnear wrote: > > On Feb 13, 2012, at 5:16 PM, Joe Touch wrote: > >> Hi, all, >> >> One additional transport suggestion: >> >> - it would be useful to include recommended configurations for TCP >> connections. Given these are multi-byte request/response exchanges, >> Nagle should be disabled, e.g. > > One of the co-authors had this to > say: >> >> A bone headed implementation (either client or server) might send >> bits and pieces of a message (for example, it would be easy for >> an implementation to send the 2 bytes for the length of the >> message in one request and then the message in a second). This is >> exactly what you want the TCP protections for. So, I think we >> should be silent on this issue. I also can't see how there is >> any harm in leaving it enabled (even in a 'clean' >> implementation). The harm is that Nagle will then eat into your own specifications (in this document) for minimums for timeouts. This is exactly where a protocol document should be specific - interactions between the transport and other layers (and is one of the key reasons for transport directorate review). Joe > I tend to agree with him -- I don't see that this > is going to cause a problem if we don't disable > it. But maybe I'm missing something. Is there > an important problem if we don't specify this one > way or another? > > Thanks -- Kim > > >> >> Joe >> >> On 2/13/2012 2:00 PM, Joe Touch wrote: >>> Hi, all, >>> >>> I've reviewed this document as part of the transport area directorate's >>> ongoing effort to review key IETF documents. These comments were written >>> primarily for the transport area directors, but are copied to the >>> document's authors for their information and to allow them to address >>> any issues raised. The authors should consider this review together with >>> any other last-call comments they receive. Please always CC >>> tsv-dir@ietf.org if you reply to or forward this review. >>> >>> This request was received Feb. 2, 2012. >>> >>> This document describes an extension to DHCPv4 for the bulk query and >>> transfer of current lease status over TCP. >>> >>> The following transport issues were noted, and are significant: >>> >>> UPDATES- The document updates DHCP with support for TCP, and as such >>> this document seems like it should UPDATE RFC2131 >>> >>> PORT USE- Although DHCPv4 has an assigned TCP port, this document should >>> clearly indicate that there is no other specified use of that port other >>> than the bulk lease query described in this document >>> >>> It should further explain why no other existing DHCP exchanges are not >>> valid on the TCP port. >>> >>> CONNECTION MANAGEMENT- The document describes the use of TCP connections >>> for bulk transfer, but needs to be more specific about which side (relay >>> client or server) closes the connection, under what circumstances, and >>> with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793) >>> >>> sec 7.3 indicates some conditions for terminating connections; this >>> section should indicate which side performs this, and by what method >>> (CLOSE, ABORT) >>> >>> this sec also allows connections to stay open after all pending >>> transactions are complete (MAY); the rationale for this should be given, >>> or the connection MUST be closed. >>> >>> the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is >>> particularly problematic on this issue because it discusses aborting a >>> request using in-band data, which may not be available if the connection >>> is closed using ABORT. the state of other pending connection shsould be >>> discussed too. >>> >>> TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this >>> intended to supercede any TCP timeout? or is it intended to be the min >>> of the TCP timeout and the specified one? >>> >>> This section should more carefully explain behavior when a connection is >>> dropped and the reason - e.g., timeout, abort, close. >>> >>> INTERLEAVING- sec 7.7 says that the server MUST interleave replies; >>> there doesn't seem a valid reason for this requirement. clearly the >>> receiver MUST tolerate interleaved replies. having the server interleave >>> replies is relevant only if each request/reply has its own timeout -- >>> which should be overridden if there is another response in progress >>> anyway. This issue should be more clearly explained and motivated. >>> >>> There were some other issues noted in this document. These comments >>> appear below, and although not focused on transport issues, they >>> represent significant issues that IMO should be addressed as well. >>> >>> NOTE - regarding some terminology issues, I did not survey current DHCP >>> RFCs for consistency, but IMO these terms should be corrected even if >>> they are then inconsistent with existing specs. >>> >>> Joe >>> >>> ----------- >>> >>> Major non-transport issues: >>> >>> - In many places the doc allows inaction to substitute for either >>> positive or negative confirmation. IMO, this invites implementation >>> errors, and should be avoided. E.g., status return codes, data source >>> option missing, query-for-all-configured-IPs, etc. >>> >>> - the data source option reserved codes need more detailed >>> specification. if these are intended for future use, then they MUST be >>> ignored by the receiver (at least). if they are to mean anything at all, >>> at least one bit (typically all of them) MUST be set to zero by the >>> transmitter for implementations that do not support any of the component >>> fields. >>> >>> further, the length of this option MUST be 1 >>> >>> - The protocol supports bulk transfer that is not data driven. This >>> could represent a security vulnerability by exposing information that >>> may not be on the data path (and thus already accessible) to a relay >>> agent. This should be discussed in the security considerations section. >>> >>> - Integer quantities should be referred to as "unsigned 32-bit integers" >>> throughout. >>> >>> - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a >>> VPN is not just private addressing. >>> >>> - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used >>> throughout without context. Any time SHOULD is used instead of MUST (or >>> SHOULD NOT rather than MUST NOT), it is useful to explain a viable >>> exception. If no such exception exists, the rationale for selecting >>> SHOULD over MUST should be included. >>> >>> - It would be useful to explain why STATUS-CODE strings MUST NOT be >>> null-terminated; is that a protocol violation, or are you just saying >>> that NULLs are valid in these strings? the description should be clear >>> that the string field describes the string length without any >>> termination characters. >>> >>> - start-time-of-state is expressed as an offset from base-time; this >>> appears to be the only time indicated as an offset rather than as an >>> absolute. That inconsistency invites implementation errors; IMO, this >>> should be absolute too. >>> >>> - option lengths: throughout, the doc refers to option lengths as being >>> "an octet"; they are *indicated* in one octet. Some are constant (e.g., >>> DCHP-STATE), some allow the contents of the octet to vary. Again, this >>> is an *unsigned integer* octet. >>> >>> - some of the information provided (in DHCP-STATE) goes beyond that of >>> DHCP. It would be useful to motivate the need for this information in a >>> bulk query, and why it is not similarly available for nodes using UDP >>> (e.g., as an extension to DHCPv4, not just to the bulk transfer >>> command). again, absence of state information should not indicate state. >>> State should always be expressed explicitly. these states are further >>> meaningless without a state diagram explaining them. if such a diagram >>> is not possible (as noted at end of sec 6.2.7), then the states are >>> irrelevant and the option should not be included. >>> >>> - in sec 6.2.9 the term "not allowed" should be explained - are they >>> reserved for future use and thus ignored? or are they "not allowed" - in >>> which case the doc should indicate handling if they appear. >>> >>> - sec 7.4 states that the clock skew of zero is desired; this assumes >>> E2E delays under 1sec. An explanation of why this is desired should be >>> given, as well as the consequences of it not. >>> >>> Other non-transport issues: >>> >>> - The document includes definitions and references to irrelevant >>> deployment and implementation issues, notably DSLAMs, concentrators, and >>> access concentrators. These should not appear formally; they should be >>> used only to usefully illustrate currently intended uses. >>> >>> - The doc refers to "real-time", which could imply requirements not >>> supported. This should be replaced with "rapid". >>> >>> - "absolute time" *indicates* (rather than contains) the number of >>> seconds... >>> >>> - "third party agent" should be explained, i.e., neither DHCP client nor >>> DHCP server. >>> >>> - "downstream" and "upstream" should be defined as both away from the >>> server *and towards the client* ("away from the server" has two >>> directions). >>> >>> - sec 3 should refer to relays, and returning the entire set or >>> individual bindings; there is no reason to explain the goals in terms of >>> access concentrators. >>> >>> - sec 3.2 appears to provide contradictory advice - caching is required, >>> but should be avoided? it would be useful to resolve this inconsistency. >>> >>> - sec 3.3 refers to 'fast path', but this term doesn't make sense in >>> this context because fast-path is a forwarding issue. it would be useful >>> to explain what you mean, and pick a different term >>> >>> ---- >>> >>> >>> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > From Ted.Lemon@nominum.com Sat Feb 18 07:29:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F121F8559; Sat, 18 Feb 2012 07:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEzSzkEXPqOq; Sat, 18 Feb 2012 07:29:43 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 586F121F84D3; Sat, 18 Feb 2012 07:29:43 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTz/D5pI3Txhl7KHoVHwiLE8YXOsghj0R@postini.com; Sat, 18 Feb 2012 07:29:43 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4E04A1B85E2; Sat, 18 Feb 2012 07:29:42 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 42A49190083; Sat, 18 Feb 2012 07:29:42 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 18 Feb 2012 07:29:42 -0800 From: Ted Lemon To: Joe Touch Thread-Topic: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery Thread-Index: AQHM6qpvAqOZiGrj4kydaKDtgkZBbZZCENSAgAAsLgCAARgHAA== Date: Sat, 18 Feb 2012 15:29:41 +0000 Message-ID: References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> In-Reply-To: <4F3ED8FC.6020400@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_C84410EE1D8C494B8BEA030C6CBCABC1nominumcom_" MIME-Version: 1.0 Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , "" , TSV Dir , "" , Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 15:29:44 -0000 --_000_C84410EE1D8C494B8BEA030C6CBCABC1nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 17, 2012, at 5:47 PM, Joe Touch wrote: Thanks. In this case, it's important to suggest why others should not add c= onventional DHCP query support to the TCP port. The idea of doing DHCP stateful autoconfiguration over TCP is nonsensical: = DHCP clients start out with no IP address, so it is not possible for them t= o do TCP. The reason for sharing option codes is to avoid confusion: since existing D= HCPLEASEQUERY option codes come out of the same namespace as DHCP options, = if we were to propose that options in this documentation come out of a diff= erent namespace, we would have to declare that new namespace, which would h= ave some options and option codes in common with the existing namespace. = This doesn't add value. Historically, we have never said that when an option code is added, that up= dates RFC2131 (really, it would make more sense to say it updated RFC2132 i= f we were to go there, since RFC2132 is the document that describes DHCP op= tions). So it would be surprising and unconventional if this document wer= e said to update either RFC2131 or RFC2132 simply because it defined one or= more new option codes. --_000_C84410EE1D8C494B8BEA030C6CBCABC1nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
Thanks. In this case, it's important to suggest why others should not add conventi= onal DHCP query support to the TCP port.

The idea of doing DHCP stateful autoconfiguration over TCP is nonsensi= cal: DHCP clients start out with no IP address, so it is not possible for t= hem to do TCP.

The reason for sharing option codes is to avoid confusion: since exist= ing DHCPLEASEQUERY option codes come out of the same namespace as DHCP opti= ons, if we were to propose that options in this documentation come out of a= different namespace, we would have to declare that new namespace, which would have some options and option co= des in common with the existing namespace.   This doesn't add value.

Historically, we have never said that when an option code is added, th= at updates RFC2131 (really, it would make more sense to say it updated RFC2= 132 if we were to go there, since RFC2132 is the document that describes DH= CP options).   So it would be surprising and unconventional if this document were said to update either RFC2131 or = RFC2132 simply because it defined one or more new option codes.

--_000_C84410EE1D8C494B8BEA030C6CBCABC1nominumcom_-- From arifumi@nttv6.net Mon Feb 20 18:22:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4594D21E8028 for ; Mon, 20 Feb 2012 18:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR3B5+0XmTFO for ; Mon, 20 Feb 2012 18:22:16 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 76B2321E8026 for ; Mon, 20 Feb 2012 18:22:16 -0800 (PST) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1L2N9B1049286; Tue, 21 Feb 2012 11:23:09 +0900 (JST) (envelope-from arifumi@nttv6.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: Date: Tue, 21 Feb 2012 11:20:53 +0900 Content-Transfer-Encoding: 7bit Message-Id: <0810BAD7-ED25-4494-8841-5432B7E02C7B@nttv6.net> References: To: Matthew Ryan X-Mailer: Apple Mail (2.1257) Cc: dhc WG Subject: Re: [dhcwg] reviews of draft-ietf-6man-addr-select-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:22:17 -0000 Matthew, thank you for looking at it. On 2012/02/16, at 3:38, Matthew Ryan wrote: > > I note that the descriptions for the 'suboption-zone-index' > and 'z-bit' in Section 2 say that if the z bit is present, > the zone-index field is inserted between prefix-len and prefix. > This does not appear to be borne out by the diagram. I assume > the text was not updated when the format was changed. Ops. Thank you for pointing out. > > Also, the 'suboption-len' field "specifies the length of > the suboption fields in bytes". If there is the desire to > potentially include multiple suboptions, this will not be > sufficient, because you have no way of telling them apart. > If this option is to have sub-options, then they should be > formatted as in other options that have sub-options: each > sub-option prefixed by a code and a length. This was intended to be skipped when a new option was defined other than the suboption-zone-index and an old implementation does not know how to deal with it. I agree that normal suboption style should be better. I'll change it that way, if we agree on it. > As for the prefix, I think it should follow the same form as > in the IA_PD Prefix option [RFC-3633 section 10]. That is, a > single octet indicating prefix length in bits, followed by a > fixed-length 16 octet address. Having a variable-length address > complicates implementation, especially when the length field > unit is bits, not octets. It would require server implementers > to write custom code simply to handle the option usefully, > where there already exists code to handle the form used in > the IA_PD Prefix option. hmmmm, it is clearly trade-off. We do not expect a lot of prefixes for IA_PD option, but we can expect more than ten options are included to deliver the policy table. > Finally, I'm not sure I see the need for the "z-bit", since > the zone-index is at the end. You don't need it to indicate > the presence of zone-index, since you easily see if zone-index > is present while parsing the packet, regardless of whether > it is a sub-option, or just an optional 32-bit value at the > end (and there are no other sub-options). I understand. As far as the z-bit is the only bit, we do not need it. Kindest regards, > > - Matt > > On Nov 9, 2011, at 00:21 , Arifumi Matsumoto wrote: > >> All, >> >> at Quebec, Tim Chown presented about address selection documents >> discussed in 6man WG, and requested reviewers for the draft >> draft-ietf-6man-addr-select-opt-01. >> slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf >> >> IIRC, one reviewer was chosen at that time, and the other was left >> undecided. >> >> So, my questions are >> the review was submitted somewhere ? >> the other reviewer was chosen ? >> >> -- >> Arifumi Matsumoto >> NGN System Architecture Project >> NTT Service Integration Laboratories >> E-mail: arifumi@nttv6.net >> TEL +81-422-59-3334 FAX +81-422-59-6364 >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From arifumi@nttv6.net Tue Feb 21 02:39:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8379A21F85AD for ; Tue, 21 Feb 2012 02:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Haa0HkRWyV1H for ; Tue, 21 Feb 2012 02:39:44 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id C770B21F851E for ; Tue, 21 Feb 2012 02:39:40 -0800 (PST) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1LAec8w053502 for ; Tue, 21 Feb 2012 19:40:38 +0900 (JST) (envelope-from arifumi@nttv6.net) From: Arifumi Matsumoto Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 19:38:22 +0900 References: <20120221103458.16891.70317.idtracker@ietfa.amsl.com> To: dhc WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dhcwg] Fwd: New Version Notification for draft-ietf-6man-addr-select-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:39:45 -0000 Hi, I hope this version resolves the points raised here in dhcwg. Best, Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-6man-addr-select-opt-03.txt > Date: 2012=E5=B9=B42=E6=9C=8821=E6=97=A5 19:34:58 JST >=20 > A new version of I-D, draft-ietf-6man-addr-select-opt-03.txt has been = successfully submitted by Arifumi Matsumoto and posted to the IETF = repository. >=20 > Filename: draft-ietf-6man-addr-select-opt > Revision: 03 > Title: Distributing Address Selection Policy using = DHCPv6 > Creation date: 2012-02-21 > WG ID: 6man > Number of pages: 10 >=20 > Abstract: > RFC 3484 defines default address selection mechanisms for IPv6 that > allow nodes to select appropriate address when faced with multiple > source and/or destination addresses to choose between. The RFC 3484 > allowed for the future definition of methods to administratively > configure the address selection policy information. This document > defines a new DHCPv6 option for such configuration, allowing a site > administrator to distribute address selection policy overriding the > default address selection policy table, and thus control the address > selection behavior of nodes in their site. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From iesg-secretary@ietf.org Tue Feb 21 14:26:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C32A21F88EA; Tue, 21 Feb 2012 14:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZqEr-+k0gRm; Tue, 21 Feb 2012 14:26:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5310721F88ED; Tue, 21 Feb 2012 14:26:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221222622.25374.70663.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 14:26:22 -0800 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Prefix Exclude Option for DHCPv6-based Prefix Delegation' to Proposed Standard (draft-ietf-dhc-pd-exclude-04.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 22:26:23 -0000 The IESG has approved the following document: - 'Prefix Exclude Option for DHCPv6-based Prefix Delegation' (draft-ietf-dhc-pd-exclude-04.txt) as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ Technical Summary This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation. The new mechanism updates RFC 3633. Working Group Summary This document received a thorough review by the WG. Many comments were made, and several revisions done. The process was amicable and seems to have satisfied all participants. Document Quality The protocol is required by the latest 3GPP GPRS specification, but the authors are not aware of any specific implementations yet. We would expect to see these implementations appearing in cellular data devices that do IPv6 tethering, which is a relatively new sort of application. Personnel Ted Lemon is the Document Shepherd. Ralph Droms is the Responsible AD. From jason.weil@twcable.com Wed Feb 22 11:14:27 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A937921F8674 for ; Wed, 22 Feb 2012 11:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5gYBSoRVhAf for ; Wed, 22 Feb 2012 11:14:27 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id F265521F8670 for ; Wed, 22 Feb 2012 11:14:26 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,465,1325480400"; d="scan'208";a="342893924" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Feb 2012 14:14:07 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 22 Feb 2012 14:14:26 -0500 From: "Weil, Jason" To: "dhcwg@ietf.org" Date: Wed, 22 Feb 2012 14:14:25 -0500 Thread-Topic: RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:14:27 -0000 I posted this question on the v6ops list, but it is more pertinent to this = list so I will repost here. Side Question: Is the expected negative response to a Requesting Router Reb= ind event on link bounce for the Server to respond with NotOnLink status as per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but since Confirm is not supported in RFC3633 it is a bit unclear what the Requesting Router is expected to do next, but I personally would expect a new SOLICIT. Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Ted.Lemon@nominum.com Wed Feb 22 11:23:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8D721F8639 for ; Wed, 22 Feb 2012 11:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLOct49uVQ1q for ; Wed, 22 Feb 2012 11:23:01 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id BFDDC21F85B4 for ; Wed, 22 Feb 2012 11:23:00 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT0VAlA2cOpPwYYF9dL9DyuNdVhh1+MFd@postini.com; Wed, 22 Feb 2012 11:23:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A16B11B8341 for ; Wed, 22 Feb 2012 11:22:59 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9A622190097; Wed, 22 Feb 2012 11:22:59 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 11:22:59 -0800 From: Ted Lemon To: "Weil, Jason" Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZgARD9oA Date: Wed, 22 Feb 2012 19:22:59 +0000 Message-ID: <964500A7-842A-43A8-B065-756094232E1B@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_964500A7842A43A8B065756094232E1Bnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:23:02 -0000 --_000_964500A7842A43A8B065756094232E1Bnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 22, 2012, at 2:14 PM, "Weil, Jason" > wrote: Side Question: Is the expected negative response to a Requesting Router Reb= ind event on link bounce for the Server to respond with NotOnLink status as per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but since Confirm is not supported in RFC3633 it is a bit unclear what the Requesting Router is expected to do next, but I personally would expect a new SOLICIT. I'm not entirely clear on what question you are asking. I think you have= n't fully described the scenario that you have in mind. --_000_964500A7842A43A8B065756094232E1Bnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <57E02F0C08BC354184505E81F0484592@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 22, 2012, at 2:14 PM, "Weil, Jason" <jason.weil@twcable.com> wrote:
S= ide Question: Is the expected negative response to a Requesting Router Rebind<= /span>
event on link bounce for the Server to respond with NotOnLink status asper 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but
since Confirm is not supported in RFC3633 it is a bit unclear what theRequesting Router is expected to do next, but I personally would expect a
new SOLICIT.

I'm not entirely clear on what question you are asking.    I= think you haven't fully described the scenario that you have in mind.

--_000_964500A7842A43A8B065756094232E1Bnominumcom_-- From jason.weil@twcable.com Wed Feb 22 14:52:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD69021F85F0 for ; Wed, 22 Feb 2012 14:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMqPCiU5FU5U for ; Wed, 22 Feb 2012 14:52:49 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFC721F85F3 for ; Wed, 22 Feb 2012 14:52:48 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,466,1325480400"; d="scan'208";a="343030271" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Feb 2012 17:52:28 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 22 Feb 2012 17:52:48 -0500 From: "Weil, Jason" To: Ted Lemon Date: Wed, 22 Feb 2012 17:52:47 -0500 Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxtLKLWS4wZaFBTh+LuqKFjVxg/A== Message-ID: In-Reply-To: <964500A7-842A-43A8-B065-756094232E1B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:52:49 -0000 I may have answered my own question but just in case: Use Case: A Requesting Router sends a Rebind for a prefix in an IA-PD after= an interface transition event takes place. The Delegating Router determine= s that the prefix included in the IA_PD option is no longer usable for this= link. Based on Section 12.2 of RFC3633 what is the correct response by the= Delegating Router? My read is that the Delegating Router could respond in one of two ways: 1. Generate a REPLY containing the IA_PD sent by the requesting router an= d include the prefix with lifetimes set to 0 and a Status code of NoBinding= or NotOnLink. 2. Ignore the REBIND and silently discard the REBIND with no response at = which point it is up to client to take further action. Thanks, Jason The 2nd Paragraph of Section 12.2 of RFC3633 contains this sentence: If the delegating router finds that any of the prefixes are not in the requesting router's binding entry, the delegating router returns the prefix to the requesting router with lifetimes of 0. It goes on to state: The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD: Renew message: If the delegating router cannot find a binding for the requesting router's IA_PD the delegating router returns the IA_PD containing no prefixes with a Status Code option set to NoBinding in the Reply message. Rebind message: If the delegating router cannot find a binding for the requesting router's IA_PD and the delegating router determines that the prefixes in the IA_PD are not appropriate for the link to which the requesting router's interface is attached according to the delegating routers explicit configuration, the delegating router MAY send a Reply message to the requesting router containing the IA_PD with the lifetimes of the prefixes in the IA_PD set to zero. This Reply constitutes an explicit notification to the requesting router that the prefixes in the IA_PD are no longer valid. If the delegating router is unable to determine if the prefix is not appropriate for the link, the Rebind message is discarded. From: Ted Lemon > Date: Wed, 22 Feb 2012 14:22:59 -0500 To: jason weil > Cc: "dhcwg@ietf.org" > Subject: Re: [dhcwg] RFC3633 Clarification On Feb 22, 2012, at 2:14 PM, "Weil, Jason" > wrote: Side Question: Is the expected negative response to a Requesting Router Reb= ind event on link bounce for the Server to respond with NotOnLink status as per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but since Confirm is not supported in RFC3633 it is a bit unclear what the Requesting Router is expected to do next, but I personally would expect a new SOLICIT. I'm not entirely clear on what question you are asking. I think you have= n't fully described the scenario that you have in mind. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Ted.Lemon@nominum.com Wed Feb 22 18:06:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBF421E8016 for ; Wed, 22 Feb 2012 18:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1uP8EJEW50M for ; Wed, 22 Feb 2012 18:06:44 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2B07E11E8072 for ; Wed, 22 Feb 2012 18:06:41 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT0WfMIQOeVdqJsHlxphLyDCRXOAPxLoV@postini.com; Wed, 22 Feb 2012 18:06:41 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E48A21B839E for ; Wed, 22 Feb 2012 18:06:39 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D49A019005D; Wed, 22 Feb 2012 18:06:39 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 22 Feb 2012 18:06:39 -0800 From: Ted Lemon To: "Weil, Jason" Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZgARD9oAAAdT6YAABsUnAA== Date: Thu, 23 Feb 2012 02:06:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_A259F61F35034A8A87DF2F45F226D985nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 02:06:46 -0000 --_000_A259F61F35034A8A87DF2F45F226D985nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 22, 2012, at 5:52 PM, "Weil, Jason" > wrote: My read is that the Delegating Router could respond in one of two ways: 1. Generate a REPLY containing the IA_PD sent by the requesting router and= include the prefix with lifetimes set to 0 and a Status code of NoBinding = or NotOnLink. 2. Ignore the REBIND and silently discard the REBIND with no response at w= hich point it is up to client to take further action. This is a really interesting question. In order to answer it, it might be= worth contemplating what exactly it means for a prefix to be delegated. = Does RFC3633 allow a delegating router to revoke a prefix when its lifetime= is still valid? To me that seems like an invalid operation: once the pre= fix has been delegated, the requesting router should have it until it expir= es. If the delegating router wants to renumber the requesting router, it = should do so by renewing the old prefix with a preferred lifetime of zero. = But I haven't read RFC3633 closely to see if this is in fact what it reco= mmends. --_000_A259F61F35034A8A87DF2F45F226D985nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3AC3B5FF2AC73242900BF12AB316288E@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 22, 2012, at 5:52 PM, "Weil, Jason" <jason.weil@twcable.com> wrote:
M= y read is that the Delegating Router could respond in one of two ways:

1.  Generate a REPLY containing the IA_PD sent by the requesting router = and include the prefix with lifetimes set to 0 and a Status code of NoBindi= ng or NotOnLink.
2.  Ignore the REBIND and silently discard the REBIND with no response a= t which point it is up to client to take further action.

This is a really interesting question.   In order to answer it, i= t might be worth contemplating what exactly it means for a prefix to be del= egated.   Does RFC3633 allow a delegating router to revoke a prefix wh= en its lifetime is still valid?   To me that seems like an invalid operation: once the prefix has been delegated, the r= equesting router should have it until it expires.   If the delegating = router wants to renumber the requesting router, it should do so by renewing= the old prefix with a preferred lifetime of zero.   But I haven't read RFC3633 closely to see if this is in fa= ct what it recommends.

--_000_A259F61F35034A8A87DF2F45F226D985nominumcom_-- From ichiroumakino@gmail.com Thu Feb 23 01:06:27 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6002621F862A for ; Thu, 23 Feb 2012 01:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8-whK6DC0sU for ; Thu, 23 Feb 2012 01:06:26 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8014D21F8564 for ; Thu, 23 Feb 2012 01:06:24 -0800 (PST) Received: by wibhm9 with SMTP id hm9so724116wib.31 for ; Thu, 23 Feb 2012 01:06:23 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.85.105 as permitted sender) client-ip=10.180.85.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.85.105 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.85.105]) by 10.180.85.105 with SMTP id g9mr1006516wiz.12.1329987983781 (num_hops = 1); Thu, 23 Feb 2012 01:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3kTbveWAgxOrsRombNDyeysySgDAWwu2sM3POCBil68=; b=R7gTI/Bdy/KP/PDFuKqyAa1CjE4JixSazrEeHNCxPVcEJnTzehfTARGwdJ2lNjOHLs cLn6/6UgU8kNW2FINIjlMvFCoNf1ViF42N+uRrzJBlWzvI7Onck9iLkl94NeyMOvpyJS yFsCqm9gIiYZ8D4wRKWL18s4CZ4/hcpjs4A4w= Received: by 10.180.85.105 with SMTP id g9mr824766wiz.12.1329987983677; Thu, 23 Feb 2012 01:06:23 -0800 (PST) Received: from dhcp-10-61-97-223.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id dw7sm3001718wib.4.2012.02.23.01.06.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 01:06:23 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 23 Feb 2012 10:06:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1257) Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 09:06:27 -0000 Jason, > I may have answered my own question but just in case: >=20 > Use Case: A Requesting Router sends a Rebind for a prefix in an IA-PD = after an interface transition event takes place. The Delegating Router = determines that the prefix included in the IA_PD option is no longer = usable for this link. Based on Section 12.2 of RFC3633 what is the = correct response by the Delegating Router? >=20 > My read is that the Delegating Router could respond in one of two = ways: >=20 > 1. Generate a REPLY containing the IA_PD sent by the requesting = router and include the prefix with lifetimes set to 0 and a Status code = of NoBinding or NotOnLink. this behaviour is a "MAY". and only applies if the delegating router can = somehow determine if the IA_PD option is appropriate for the link or = not. I'm not quite sure how it would do that. > 2. Ignore the REBIND and silently discard the REBIND with no response = at which point it is up to client to take further action. both behaviours are allowed, but given that 1 is quite improbable... cheers, Ole > The 2nd Paragraph of Section 12.2 of RFC3633 contains this sentence: >=20 > If the delegating router finds that any > of the prefixes are not in the requesting router's binding entry, the > delegating router returns the prefix to the requesting router with > lifetimes of 0. >=20 > It goes on to state: >=20 >=20 > The delegating router behaves as follows when it cannot find a > binding for the requesting router's IA_PD: >=20 > Renew message: If the delegating router cannot find a binding > for the requesting router's IA_PD the delegating > router returns the IA_PD containing no prefixes > with a Status Code option set to NoBinding in = the > Reply message. >=20 > Rebind message: If the delegating router cannot find a binding > for the requesting router's IA_PD and the > delegating router determines that the prefixes = in > the IA_PD are not appropriate for the link to > which the requesting router's interface is > attached according to the delegating routers > explicit configuration, the delegating router = MAY > send a Reply message to the requesting router > containing the IA_PD with the lifetimes of the > prefixes in the IA_PD set to zero. This Reply > constitutes an explicit notification to the > requesting router that the prefixes in the IA_PD > are no longer valid. If the delegating router = is > unable to determine if the prefix is not > appropriate for the link, the Rebind message is > discarded. >=20 > From: Ted Lemon > > Date: Wed, 22 Feb 2012 14:22:59 -0500 > To: jason weil > > Cc: "dhcwg@ietf.org" = > > Subject: Re: [dhcwg] RFC3633 Clarification >=20 > On Feb 22, 2012, at 2:14 PM, "Weil, Jason" = > wrote: > Side Question: Is the expected negative response to a Requesting = Router Rebind > event on link bounce for the Server to respond with NotOnLink status = as > per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages = but > since Confirm is not supported in RFC3633 it is a bit unclear what the > Requesting Router is expected to do next, but I personally would = expect a > new SOLICIT. >=20 > I'm not entirely clear on what question you are asking. I think you = haven't fully described the scenario that you have in mind. >=20 >=20 > ________________________________ > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Feb 23 05:36:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A1121F8642 for ; Thu, 23 Feb 2012 05:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.445 X-Spam-Level: X-Spam-Status: No, score=-9.445 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tvmtvyteqLZ for ; Thu, 23 Feb 2012 05:36:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 70B2521F8605 for ; Thu, 23 Feb 2012 05:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=6038; q=dns/txt; s=iport; t=1330004196; x=1331213796; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CHDFfibarujkf99Y6D8HKLiJOkYqDc9dRJ3Qxcdt0bc=; b=f4YUmfBsQIAsxuRC56KqAnGL5q06aTp840eZyd0GAvBD8OKqaQtUAeBH QKZeaUyzkLhxVDIue7AMA50Zma0hNRT6Okr2JEJu/MscPOqfY9Q1KWZJP 1kxAqfoER6nUuJh9/QP6u/ha61Drf5AjUgXvSbGyZbTi0+WcYqa7eie4u c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFZARk+tJV2c/2dsb2JhbABEsl2BB4FzAQEBAwEBAQEPAR0+BAcFBwQCAQgRAwEBAQEKBhcBBgEmHwkIAQEEEwgMDodfCaAJAZcRBIlngw4ECwIDDQMIBAs+GoVeGhIMgk1jBIgcM591gT0 X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="61241023" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 23 Feb 2012 13:36:36 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q1NDaZP1017660; Thu, 23 Feb 2012 13:36:35 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 07:36:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 07:36:35 -0600 Message-ID: In-Reply-To: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczyCnD119Cn5OXFTR+RFjhNW5Q6UwAJJqnw References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> From: "Bernie Volz (volz)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Weil, Jason" X-OriginalArrivalTime: 23 Feb 2012 13:36:36.0037 (UTC) FILETIME=[29CA2F50:01CCF230] Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:36:37 -0000 I sent a query to Ole separately regarding this, but I think as it is = related to the issue of what to do about IA_NA & IA_PD in a single = request (or not), it is something for the community at large to consider = ... Given the RFC 3633 text, what is a server supposed to do if there are = TWO IA_PDs in the Rebind and it only knows about 1 and not the other? = (And let's assume it doesn't do the 'MAY' part of can't determine the = 'onlink' nature of the prefixes in the one it doesn't know about).=20 While RFC 3315 and 3633 were developed with the idea that multiple IAs = would be present, I don't think we thought about these issues clearly = enough to have correctly handled them all. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Thursday, February 23, 2012 4:06 AM To: Weil, Jason Cc: dhcwg@ietf.org; Ted Lemon Subject: Re: [dhcwg] RFC3633 Clarification Jason, > I may have answered my own question but just in case: >=20 > Use Case: A Requesting Router sends a Rebind for a prefix in an IA-PD = after an interface transition event takes place. The Delegating Router = determines that the prefix included in the IA_PD option is no longer = usable for this link. Based on Section 12.2 of RFC3633 what is the = correct response by the Delegating Router? >=20 > My read is that the Delegating Router could respond in one of two = ways: >=20 > 1. Generate a REPLY containing the IA_PD sent by the requesting = router and include the prefix with lifetimes set to 0 and a Status code = of NoBinding or NotOnLink. this behaviour is a "MAY". and only applies if the delegating router can = somehow determine if the IA_PD option is appropriate for the link or = not. I'm not quite sure how it would do that. > 2. Ignore the REBIND and silently discard the REBIND with no response = at which point it is up to client to take further action. both behaviours are allowed, but given that 1 is quite improbable... cheers, Ole > The 2nd Paragraph of Section 12.2 of RFC3633 contains this sentence: >=20 > If the delegating router finds that any of the prefixes are not in the = > requesting router's binding entry, the delegating router returns the=20 > prefix to the requesting router with lifetimes of 0. >=20 > It goes on to state: >=20 >=20 > The delegating router behaves as follows when it cannot find a > binding for the requesting router's IA_PD: >=20 > Renew message: If the delegating router cannot find a binding > for the requesting router's IA_PD the delegating > router returns the IA_PD containing no prefixes > with a Status Code option set to NoBinding in = the > Reply message. >=20 > Rebind message: If the delegating router cannot find a binding > for the requesting router's IA_PD and the > delegating router determines that the prefixes = in > the IA_PD are not appropriate for the link to > which the requesting router's interface is > attached according to the delegating routers > explicit configuration, the delegating router = MAY > send a Reply message to the requesting router > containing the IA_PD with the lifetimes of the > prefixes in the IA_PD set to zero. This Reply > constitutes an explicit notification to the > requesting router that the prefixes in the IA_PD > are no longer valid. If the delegating router = is > unable to determine if the prefix is not > appropriate for the link, the Rebind message is > discarded. >=20 > From: Ted Lemon > > Date: Wed, 22 Feb 2012 14:22:59 -0500 > To: jason weil > > Cc: "dhcwg@ietf.org"=20 > > > Subject: Re: [dhcwg] RFC3633 Clarification >=20 > On Feb 22, 2012, at 2:14 PM, "Weil, Jason" = > wrote: > Side Question: Is the expected negative response to a Requesting=20 > Router Rebind event on link bounce for the Server to respond with=20 > NotOnLink status as per 18.1.8 of RCC3315 CONFIRM process? This is for = > a Confirm messages but since Confirm is not supported in RFC3633 it is = > a bit unclear what the Requesting Router is expected to do next, but I = > personally would expect a new SOLICIT. >=20 > I'm not entirely clear on what question you are asking. I think you = haven't fully described the scenario that you have in mind. >=20 >=20 > ________________________________ > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > 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 Ted.Lemon@nominum.com Thu Feb 23 05:39:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8C821F850C for ; Thu, 23 Feb 2012 05:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ysa0uHBydb8 for ; Thu, 23 Feb 2012 05:39:37 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA6C21F84FE for ; Thu, 23 Feb 2012 05:39:36 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT0ZBmEH+c1CiWXA3TAj3L4BPvZqz/s/N@postini.com; Thu, 23 Feb 2012 05:39:36 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A876E1B83CB for ; Thu, 23 Feb 2012 05:39:35 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A24F719005D; Thu, 23 Feb 2012 05:39:35 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 23 Feb 2012 05:39:35 -0800 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZgARD9oAAAdT6YAAFW22gAAJcBOAAAAahoA= Date: Thu, 23 Feb 2012 13:39:34 +0000 Message-ID: <679CEBC0-97B7-48CE-B5A7-A1833CAF4C7A@nominum.com> References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_679CEBC097B748CEB5A7A1833CAF4C7Anominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:39:37 -0000 --_000_679CEBC097B748CEB5A7A1833CAF4C7Anominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Feb 23, 2012, at 8:36 AM, "Bernie Volz (volz)" > wrote: While RFC 3315 and 3633 were developed with the idea that multiple IAs woul= d be present, I don't think we thought about these issues clearly enough to= have correctly handled them all. That's for sure. --_000_679CEBC097B748CEB5A7A1833CAF4C7Anominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 23, 2012, at 8:36 AM, "Bernie Volz (volz)" <volz@cisco.com> wrote:
W= hile RFC 3315 and 3633 were developed with the idea that multiple IAs would be = present, I don't think we thought about these issues clearly enough to have= correctly handled them all.

That's for sure.

--_000_679CEBC097B748CEB5A7A1833CAF4C7Anominumcom_-- From Carl.Wuyts@technicolor.com Thu Feb 23 05:50:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B8221F86DE for ; Thu, 23 Feb 2012 05:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qr0cXjTmro0 for ; Thu, 23 Feb 2012 05:50:03 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 1032C21F86A2 for ; Thu, 23 Feb 2012 05:50:00 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKT0ZECAFufQigKTx9SB6OgJkRhljbQQW3@postini.com; Thu, 23 Feb 2012 05:50:03 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 23 Feb 2012 14:48:43 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Thu, 23 Feb 2012 14:48:59 +0100 From: Wuyts Carl To: Ted Lemon , "Bernie Volz (volz)" Date: Thu, 23 Feb 2012 14:48:56 +0100 Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZgARD9oAAAdT6YAAFW22gAAJcBOAAAAahoAAELoYEA== Message-ID: <867F4B6A1672E541A94676D556793ACD0E9AFBC050@MOPESMBX01.eu.thmulti.com> References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> <679CEBC0-97B7-48CE-B5A7-A1833CAF4C7A@nominum.com> In-Reply-To: <679CEBC0-97B7-48CE-B5A7-A1833CAF4C7A@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0E9AFBC050MOPESMBX01eut_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:50:05 -0000 --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC050MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Moreover. I've suggested before to include a clear state machine drawing f= or DHCPv6 RFC. This would avoid ending up with different implementations due to different = interpretation of things. Just an example: @ BBF, the DHCPv6 model has defined as such (in TR181) tha= t a DHCPv6 client can be bound to multiple DHCPv6 servers at the same time,= allowing the possibility to get options from different v6 servers. While = I would strongly doubt this to really happen in real life (yes you can have= offers from multiple servers, no you should only take them from the prefer= red one) it could have been avoided with a clear state machine (this is not= possible in v4 either). WRT the latest discussion, having multiple IA requests, but only 1 gets ser= ved, I think it is important to not start injecting too much extra intellig= ence or state into the client side, i.e. not to start having separate sessi= ons for each individual option request, this is not how DHCP was designed I= think + contradicting the other discussion on MAX RT. Different possibilities are possible: either just accept what you get, or d= eny if you don't get all you asked for. One could inject into the DHCPv6 cl= ient some optional configuration parameter to only bound in case of all req= uested stuff is received or the more liberal way (probably the default one)= to just use what you get. Problem still exist on what e.g. the renew/rebi= nd should include etc. Regs Carl From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: donderdag 23 februari 2012 14:40 To: Bernie Volz (volz) Cc: Subject: Re: [dhcwg] RFC3633 Clarification On Feb 23, 2012, at 8:36 AM, "Bernie Volz (volz)" > wrote: While RFC 3315 and 3633 were developed with the idea that multiple IAs woul= d be present, I don't think we thought about these issues clearly enough to= have correctly handled them all. That's for sure. --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC050MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

Moreover.  I’ve sugge= sted before to include a clear state machine drawing for DHCPv6 RFC.

This would avoid ending up with = different implementations due to different interpretation of things.

 

Just an example: @ BBF, the DHCPv6 model has define= d as such (in TR181) that a DHCPv6 client can be bound to multiple DHCPv6 s= ervers at the same time, allowing the possibility to get options fro= m different v6 servers.  While I would strongly doubt this to really h= appen in real life (yes you can have offers from multiple servers, no you s= hould only take them from the preferred one) it could have been avoided wit= h a clear state machine (this is not possible in v4 either).

 

WRT the latest discussion, having multiple IA requests, but= only 1 gets served, I think it is important to not start injecting too muc= h extra intelligence or state into the client side, i.e. not to start havin= g separate sessions for each individual option request, this is not how DHC= P was designed I think + contradicting the other discussion on MAX RT.=

Different possibilities are po= ssible: either just accept what you get, or deny if you don’t get all= you asked for. One could inject into the DHCPv6 client some optional confi= guration parameter to only bound in case of all requested stuff is received= or the more liberal way (probably the default one) to just use what you ge= t.  Problem still exist on what e.g. the renew/rebind should include e= tc.

 

Regs

Carl

 

 

From: dhcwg-bounces@ietf.org [= mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: donderdag 23 februari 2012 14:40
To: Bernie Volz (volz)
C= c: <dhcwg@ietf.org>
Subject: Re: [dhcwg] RFC3633 Clarif= ication

 

On Feb 23, 2012, at 8:36 AM, "B= ernie Volz (volz)" <volz@cisco.co= m> wrote:

While RFC 3315 and 36= 33 were developed with the idea that multiple IAs would be present, I don't= think we thought about these issues clearly enough to have correctly handl= ed them all.

<= o:p> 

That's for sure.

 

<= /html>= --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC050MOPESMBX01eut_-- From Jean-Francois.TremblayING@videotron.com Thu Feb 23 09:30:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026E021F87DC for ; Thu, 23 Feb 2012 09:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlNoj2Ta53Ye for ; Thu, 23 Feb 2012 09:30:39 -0800 (PST) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE1921F87BE for ; Thu, 23 Feb 2012 09:30:38 -0800 (PST) In-Reply-To: <867F4B6A1672E541A94676D556793ACD0E9AFBC050@MOPESMBX01.eu.thmulti.com> To: dhcwg@ietf.org MIME-Version: 1.0 X-KeepSent: D2E5ADA9:2CB50651-852579AD:005F7E9F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 23 Feb 2012 12:30:25 -0500 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 02/23/2012 12:30:27, Serialize complete at 02/23/2012 12:30:27 Content-Type: multipart/alternative; boundary="=_alternative 00602C1A852579AD_=" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:30:40 -0000 Message en plusieurs parties au format MIME --=_alternative 00602C1A852579AD_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiBNb3Jlb3Zlci4gIEnigJl2ZSBzdWdnZXN0ZWQgYmVmb3JlIHRvIGluY2x1ZGUgYSBjbGVhciBz dGF0ZSBtYWNoaW5lIA0KZHJhd2luZyBmb3IgREhDUHY2IFJGQy4NCg0KKzEgb24gdGhlIHN0YXRl IG1hY2hpbmUsIGl0IHdvdWxkIGhlbHAgaW1wbGVtZW50b3JzIGEgbG90LiBXZSdyZSBzZWVpbmcg DQphbGwga2luZHMgb2YgREhDUHY2IGJlaGF2aW9ycyBub3cgYW5kIGl0IGh1cnRzIGRlcGxveW1l bnQuIA0KDQpOZWVkbGVzcyB0byBzYXksIGtlZXBpbmcgdGhhdCBzdGF0ZSBtYWNoaW5lIGF3YXkg ZnJvbSB1bmR1ZSBjb21wbGV4aXR5IChhcyANCnNpbXBsZSBhcyBwb3NzaWJsZSkgd291bGQgYWxz byBoZWxwLiANCg0KL0pGDQoNCg== --=_alternative 00602C1A852579AD_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE1vcmVvdmVyLiAmbmJzcDtJ4oCZdmUgc3VnZ2Vz dGVkIGJlZm9yZSB0byBpbmNsdWRlDQphIGNsZWFyIHN0YXRlIG1hY2hpbmUgZHJhd2luZyBmb3Ig REhDUHY2IFJGQy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPisxIG9u IHRoZSBzdGF0ZSBtYWNoaW5lLCBpdCB3b3VsZCBoZWxwIGltcGxlbWVudG9ycw0KYSBsb3QuIFdl J3JlIHNlZWluZyBhbGwga2luZHMgb2YgREhDUHY2IGJlaGF2aW9ycyBub3cgYW5kIGl0IGh1cnRz IGRlcGxveW1lbnQuDQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPk5l ZWRsZXNzIHRvIHNheSwga2VlcGluZyB0aGF0IHN0YXRlIG1hY2hpbmUgYXdheSBmcm9tDQp1bmR1 ZSBjb21wbGV4aXR5IChhcyBzaW1wbGUgYXMgcG9zc2libGUpIHdvdWxkIGFsc28gaGVscC4gPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4vSkY8L2ZvbnQ+PC90dD4NCjxi cj4NCg== --=_alternative 00602C1A852579AD_=-- From Ted.Lemon@nominum.com Thu Feb 23 10:40:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4BF21F8830 for ; Thu, 23 Feb 2012 10:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-JMYQ6muCYy for ; Thu, 23 Feb 2012 10:40:07 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6C99321F863B for ; Thu, 23 Feb 2012 10:40:03 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT0aIAsLBhq5LNwkCwmv0mNg6kDuAhWEW@postini.com; Thu, 23 Feb 2012 10:40:03 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2CDB01B83B3 for ; Thu, 23 Feb 2012 10:40:02 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1884619005C; Thu, 23 Feb 2012 10:40:02 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 23 Feb 2012 10:40:02 -0800 From: Ted Lemon To: Wuyts Carl Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZgARD9oAAAdT6YAAFW22gAAJcBOAAAAahoAAELoYEP//ziKA Date: Thu, 23 Feb 2012 18:40:01 +0000 Message-ID: <217FC32E-301D-48EF-B5D1-EA86AA55F76B@nominum.com> References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> <679CEBC0-97B7-48CE-B5A7-A1833CAF4C7A@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC050@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0E9AFBC050@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_217FC32E301D48EFB5D1EA86AA55F76Bnominumcom_" MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:40:07 -0000 --_000_217FC32E301D48EFB5D1EA86AA55F76Bnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 23, 2012, at 8:48 AM, Wuyts Carl > wrote: While I would strongly doubt this to really happen in real life (yes you ca= n have offers from multiple servers, no you should only take them from the = preferred one) it could have been avoided with a clear state machine (this = is not possible in v4 either). Of course it can happen in real life if a site is multihomed. The reason = we didn't diagram a state machine is because when we did in in DHCPv4, peop= le read the state machine diagram instead of the spec. --_000_217FC32E301D48EFB5D1EA86AA55F76Bnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0D308F880CB1D44092D0535B46E0C2DC@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 23, 2012, at 8:48 AM, Wuyts Carl <Carl.Wuyts@technicolor.com> wrote:
While I would strongly doubt this to really happen in real life (yes you can hav= e offers from multiple servers, no you should only take them from the prefe= rred one) it could have been avoided with a clear state machine (this is no= t possible in v4 either).

Of course it can happen in real life if a site is multihomed.   T= he reason we didn't diagram a state machine is because when we did in in DH= CPv4, people read the state machine diagram instead of the spec.

--_000_217FC32E301D48EFB5D1EA86AA55F76Bnominumcom_-- From kkinnear@cisco.com Thu Feb 23 10:57:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F621F886E; Thu, 23 Feb 2012 10:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.811 X-Spam-Level: X-Spam-Status: No, score=-9.811 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BJynROU20KU; Thu, 23 Feb 2012 10:57:45 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 830DE21F886B; Thu, 23 Feb 2012 10:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=5791; q=dns/txt; s=iport; t=1330023465; x=1331233065; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=AtY+3SfoIG3K/vdXefATS/2aE9hk6YJ5JLwaUDy3tck=; b=HdDrllu7XDVKo/AGHkPjY0YmW/+stjAt6HaxiWLwxgP7q8MMk5lVOBHc Dm3JPuYT6qA8zKnRmPsO70Pn7YmnrEgbW7d+KEyY5x/WiezVYAF3n/X8B 1qesccP+PuaEOXkga56HeE/50XOqZSIMDyZ8d7gjxkqwOYFZsfQvq8Sw+ 0=; X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="32044454" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 18:57:45 +0000 Received: from [161.44.65.167] ([161.44.65.167]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1NIviWr031652; Thu, 23 Feb 2012 18:57:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <4F3ED8FC.6020400@isi.edu> Date: Thu, 23 Feb 2012 13:57:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, TSV Dir , dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:57:48 -0000 Joe, There were two things that I referenced in response to your initial review that you hadn't seen. More details on those below: On Feb 17, 2012, at 5:47 PM, Joe Touch wrote: -------------------------------------------- >> INTERLEAVING- sec 7.7 says that the server MUST interleave >> replies; >> there doesn't seem a valid reason for this requirement. clearly the >> receiver MUST tolerate interleaved replies. having the server = interleave >> replies is relevant only if each request/reply has its own timeout -- >> which should be overridden if there is another response in progress >> anyway. This issue should be more clearly explained and motivated. >=20 > Robert Sparks offered clarification, which I like > a lot and have already agreed to use: I didn't see that; can you send that to tsv-dir@ietf.org and me? >> Is the requirement you are really trying to capture "MUST >> NOT block sending replies on new queries until all >> replies for the existing query are complete."? I wasn't clear here -- the entire result of our discussion was captured in the text above. Note that a server does not *have* to support multiple queries on the same connection. If, however, a server chooses to do so, then the following discussion is operative: Based on my discussion with Robert Sparks, the sentence: "A server that is processing multiple queries simultaneously MUST interleave replies to the multiple queries within the stream of reply messages it sends." will be replaced by the sentence: "The server MUST NOT block sending replies on new queries until all replies for the existing query are complete." ------------------------------------------------- >>>=20 >>> - The protocol supports bulk transfer that is not data driven. >>> This could represent a security vulnerability by exposing >>> information that may not be on the data path (and thus already >>> accessible) to a relay agent. This should be discussed in the >>> security considerations section. >>=20 >> All data that is exposed has already been >> exposed using UDP to regular DHCP port. But please see >> my response to Stephen Farrell (which is too long to include >> here) to see if it covers the issues about which you >> have concerns. >=20 > Again, I didn't see it; please send a copy to tsv-dir@ietf.org >=20 There are two related posts that I will include here in order to keep this discussion in some kind of order. Here are the words that I proposed to Stephen which he accepted: There are two specific issues regarding Bulk Leasequery security that deserve explicit mention. The first is preventing information that Bulk Leasequery can provide from reaching clients who are not authorized to receive such information. The second is ensuring that authorized clients of the Bulk Leasequery capability receive accurate information from the Server (and that this information is not disrupted in transit). To prevent information leakage to unauthorized clients Servers SHOULD restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors, either through explicit configuration of the Server itself or by employing external network elements to provide such restrictions. In particular, the typical DHCPv4 client SHOULD NOT be allowed to receive a response to a Bulk Leasequery request, and some technique MUST exist to allow prevention of such access in any environment where Bulk Leasequery is deployed. Connections not from permitted requestors SHOULD be closed immediately, to avoid server connection resource exhaustion or alternatively, simply not be allowed to reach the server at all. Servers SHOULD have the capability to restrict certain requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed, or MAY simply close the connection. To prevent disruption and malicious corruption of Bulk Leasequery data flows between the server and authorized clients these data flows SHOULD transit only secured networks. These data flows are typically infrastructure oriented, and there is usually no reason to have them flowing over networks where such attacks are likely. In the rare cases where these data flows might need to be sent through unsecured networks, they MUST sent over connections secured through means external to the DHCPv4/DHCPv6 server and its client(s) (e.g., through VPN's). Here is Ted Lemon's reply to Stephen's suggestion about using SSH/TLS to secure the data flows of DHCPv4 Bulk Leasequery: =46rom Ted Lemon, Feb 22 2012, 10:37:12 EST: The main reason why TLS wasn't included is that there is zero chance of anyone using it. In practice this protocol is useful only in a very specific sort of application: communications between the core of an ISP network and the edge of the ISP network. Encrypting everything would be quite expensive; the value of the data that would be acquired in an attack is low; the risk that there could be an attacker that would do this is low, since it would require physical access. Furthermore, if someone does break in, they can just collect this data with a sniffer. Given these considerations, the additional verbiage and testing required for TLS support seemed unnecessary and potentially damaging, since untested code is vulnerable code. The working group did actually consider requesting that the authors add TLS to the document, but concluded that it was not worthwhile. ----------------------------- Regards -- Kim From volz@cisco.com Thu Feb 23 11:07:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1FA21F87B1 for ; Thu, 23 Feb 2012 11:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.672 X-Spam-Level: X-Spam-Status: No, score=-9.672 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C5reePFzfYQ for ; Thu, 23 Feb 2012 11:07:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E377E21F87AD for ; Thu, 23 Feb 2012 11:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=13187; q=dns/txt; s=iport; t=1330024043; x=1331233643; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=y3Sie5bMO1bZLB4SccSR86sGoAR+UniF1deS4OZT/Tg=; b=mXUolhZ6qnhR1dM4Y3YuLachtHCdcibGVFsPrDUKJZFzV4IZ3YUZeSsn S9i3yhlNm+YV+gxf+pzT34y1J6HWda+Uf3XFF78ndOy1qNfTTa6mn7mXr hSXyXASSYLz4KOcAQt9YMpBejltabXrc1jTGqZCV4i1Ag48jLPEIm4YIy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMWNRk+rRDoJ/2dsb2JhbABEgk2wA4EHgXMBAQEEEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgCBBMIEQmiMgGebIx1Dw0IVRoKhgAMgk1jBIhPn3U X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208,217";a="32047424" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 19:07:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1NJ7MMe001729; Thu, 23 Feb 2012 19:07:22 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 13:07:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF25E.5EBAED32" Date: Thu, 23 Feb 2012 13:07:20 -0600 Message-ID: In-Reply-To: <217FC32E-301D-48EF-B5D1-EA86AA55F76B@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZgARD9oAAAdT6YAAFW22gAAJcBOAAAAahoAAELoYEP//ziKAgACBDhA= References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> <679CEBC0-97B7-48CE-B5A7-A1833CAF4C7A@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC050@MOPESMBX01.eu.thmulti.com> <217FC32E-301D-48EF-B5D1-EA86AA55F76B@nominum.com> From: "Bernie Volz (volz)" To: "Wuyts Carl" X-OriginalArrivalTime: 23 Feb 2012 19:07:22.0088 (UTC) FILETIME=[5EF53E80:01CCF25E] Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:07:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF25E.5EBAED32 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And the recent discussions show that such a state-machine would likely have been wrong and, if correct, exceedingly complex! =20 I don't really see that a state machine adds much value and ends up, as Ted points out, just another place where there could be conflicting information. =20 The basic state machine for DHCPv6 is pretty simple. It is handling all of the edge cases that makes life hard and also would be very difficult to reflect in a state machine. And depending on the application, the state machine might be different. Showing the simple state machine would thus add little value and also misrepresent the problem. =20 Having said that ... If you feel strongly about a state machine, please feel free to generate one and publish is as an Internet-Draft - the WG can then decide whether it is something useful to adopt as a WG work item and move it forward. =20 - Bernie =20 From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, February 23, 2012 1:40 PM To: Wuyts Carl Cc: Bernie Volz (volz); Subject: Re: [dhcwg] RFC3633 Clarification =20 On Feb 23, 2012, at 8:48 AM, Wuyts Carl wrote: While I would strongly doubt this to really happen in real life (yes you can have offers from multiple servers, no you should only take them from the preferred one) it could have been avoided with a clear state machine (this is not possible in v4 either). =20 Of course it can happen in real life if a site is multihomed. The reason we didn't diagram a state machine is because when we did in in DHCPv4, people read the state machine diagram instead of the spec. =20 ------_=_NextPart_001_01CCF25E.5EBAED32 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And the recent discussions show that such a state-machine would = likely have been wrong and, if correct, exceedingly = complex!

 

I don’t really see that a state machine adds much value and = ends up, as Ted points out, just another place where there could be = conflicting information.

 

The basic state machine for DHCPv6 is pretty simple. It is handling = all of the edge cases that makes life hard and also would be very = difficult to reflect in a state machine. And depending on the = application, the state machine might be different. Showing the simple = state machine would thus add little value and also misrepresent the = problem.

 

Having said that … If you feel strongly about a state machine, = please feel free to generate one and publish is as an = Internet-Draft – the WG can then decide whether it is = something useful to adopt as a WG work item and move it = forward.

 

-          = Bernie

 

From:= = Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Thursday, = February 23, 2012 1:40 PM
To: Wuyts Carl
Cc: Bernie = Volz (volz); <dhcwg@ietf.org>
Subject: Re: [dhcwg] = RFC3633 Clarification

 

On = Feb 23, 2012, at 8:48 AM, Wuyts Carl <Carl.Wuyts@technicolor.com= > wrote:

While I would strongly doubt this to really happen in real life (yes = you can have offers from multiple servers, no you should only take them = from the preferred one) it could have been avoided with a clear state = machine (this is not possible in v4 = either).

 

Of = course it can happen in real life if a site is multihomed.   The = reason we didn't diagram a state machine is because when we did in in = DHCPv4, people read the state machine diagram instead of the = spec.

 

------_=_NextPart_001_01CCF25E.5EBAED32-- From tomasz.mrugalski@gmail.com Thu Feb 23 11:34:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A3721F87DE for ; Thu, 23 Feb 2012 11:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACkB6N5+Yo1x for ; Thu, 23 Feb 2012 11:34:33 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 711B521F8705 for ; Thu, 23 Feb 2012 11:34:31 -0800 (PST) Received: by wgbgn7 with SMTP id gn7so6158316wgb.1 for ; Thu, 23 Feb 2012 11:34:30 -0800 (PST) Received-SPF: pass (google.com: domain of tomasz.mrugalski@gmail.com designates 10.180.86.230 as permitted sender) client-ip=10.180.86.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tomasz.mrugalski@gmail.com designates 10.180.86.230 as permitted sender) smtp.mail=tomasz.mrugalski@gmail.com; dkim=pass header.i=tomasz.mrugalski@gmail.com Received: from mr.google.com ([10.180.86.230]) by 10.180.86.230 with SMTP id s6mr298910wiz.16.1330025670604 (num_hops = 1); Thu, 23 Feb 2012 11:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=RwyjlzdUTi8/C2YAWQSn5qhM+xRr3bosb/15gAJqhtg=; b=AYQHEQhuhR5Zhe+tgp0+i2qat6nCOgG92D1fhEcP9KobfNdFqZoSi3aFCI0usoAPsV xklD5CmXdCR76zpUR216W0gt/gfEW6cUiZS87n8p8iyCDMFszvehZXQWp0pvhlysbNib hzNCRDN7e2orxMDkY/G+S5TSn5GCq1c/8fcyU= Received: by 10.180.86.230 with SMTP id s6mr242373wiz.16.1330025670500; Thu, 23 Feb 2012 11:34:30 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id m8sm10846829wia.11.2012.02.23.11.34.29 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 11:34:29 -0800 (PST) Message-ID: <4F4694BD.7010500@gmail.com> Date: Thu, 23 Feb 2012 20:34:21 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "dhcwg@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:34:34 -0000 Hi, I just read this draft and have several comments. I have mixed feelings for such mechanisms, but I suppose that is a necessary evil. For that reason I support this draft. Current version of this draft omits one case that is quite important IMHO. What if I can't modify my host, e.g. because it is a device (like aforementioned blu-ray player or something much more costly, like dedicated machines e.g. high performance printers) that does not allow running third party software or its vendor is unable/unwilling to provide such update? Why CRA must be placed on the same host as client? CRA could be anywhere on the same link as hosts, right? Also, it can be shared between many clients. These are my assumptions. If they are true, something to that effect should be added to the text. Section 6 mentions that CRA is being provisioned with TSV/TRA address. Why CRA can't use normal DHCPv6 mechanism for that? I think it could use server unicast, already defined option in DHCPv6. Dual-stack (DHCPv4+DHCPv6) server could easily distinguish between regular DHCPv6 traffic and DHCPv4-encapsulated-in-IPv6 traffic as they are sent to different ports. I would rename this 6ADDR to something else. Someone (who didn't read the draft) could be mislead to think that this option allows you to configure IPv6 address using DHCPv4. Have you considered other alternative: put whole DHCPv4 into DHCPv6 option and then send it as DHCPv6 packet (possibly as relay-forw)? It would have one mayor advantage of being able to reuse existing deployed DHCPv6 relays. I haven't thought this through, so there may be pitfalls here, but regular DHCPv6 relay is not supposed to inspect packet too deeply (like dropping it because of missing client-id), so it may work. On the other hand, that would work only for dual-stacked servers, so its usability is somewhat limited. My understanding is that server basically echoes 6ADDR option back, if present. Does it differ in any way server normally processes Relay Agent Information option, as defined in RFC3046? Something to that effect should be added to Section 7. In section 8 (and many other sections) you state that packet is forwarded to IPv6 address. Please clearly specify destination port number. I assume it should be 67, but it is better to make is clear. There should probably be a statement along the lines: "TRA SHOULD (or even MUST) drop DHCPv4-over-IPv6 traffic that is not originated from configured server address". Security considerations section should discuss cases, where TRA can be exploited to forward traffic. It is probably of limited usefulness, but still I think it could allow to attack IPv4 machines from IPv6 Internet. If port restrictions are added as suggested, this potential attack vector would be limited to DHCPv4 protocol only. Security considerations should discuss that DHCPv4 traffic over IPv6 will most likely bypass existing firewalls (that can filter DHCPv4 over IPv4 and DHCPv6 over IPv6). Editorial comments: Section 4, first paragraph: shoudl => should Second paragraph: Discussion about applicability would be useful. What if the host is a device that I cannot modify to run extra software? Paragraph above Fig. 2. Since Option 82 doesn't has => Since Option 82 doesn't have Hope that helps. Tomek From kkinnear@cisco.com Thu Feb 23 13:59:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7E921E8025; Thu, 23 Feb 2012 13:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW9flqGzQ9MZ; Thu, 23 Feb 2012 13:59:53 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 943DF21E8021; Thu, 23 Feb 2012 13:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=22227; q=dns/txt; s=iport; t=1330034393; x=1331243993; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YC0faeSnfaHioawVbtTf88vj9PEe6zWQ9cNDdwKR7Yc=; b=gjVsOIXSy4FuBROjdiUdT4e9ewY2Uv3oUEJ0y2/SxyXUO7gyVEM1P9FF DHuZFBiO/Ub4Gl2b4rf/0ktvQKtXDRFKS+rc8baAAJuTXxlac7hbBe41b f/bz1In0pPvjT9RQCi2MiNyU4aacowdiuDwdV2r5DvBet8+Dqnq0XXGgN 0=; X-IronPort-AV: E=Sophos;i="4.73,472,1325462400"; d="scan'208";a="32088099" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 21:59:53 +0000 Received: from [161.44.65.167] ([161.44.65.167]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1NLxq3A013957; Thu, 23 Feb 2012 21:59:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <4F3ED8FC.6020400@isi.edu> Date: Thu, 23 Feb 2012 17:00:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, TSV Dir , dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:59:55 -0000 Joe, I've edited the the email trail to try to concentrate on the remaining open issues. I've also removed the two issues that were included in the email I sent you an hour or so ago, since I expect that they will be covered in continuations of that thread. To summarize, there are 3 issues remaining that are not included below: 1. The NAGLE issue you raised, which has its own thread. 2. The two issues: a) Interleaving b) Possible security vulnerability if data is available that wasn't already in the data path. 3. The ? issues remaining, below. I think that the number could be 0, but probably not. Regards -- Kim On Feb 17, 2012, at 5:47 PM, Joe Touch wrote: > Hi, Kim, >=20 > First, thank you for your detailed response to my quite lengthy = review. >=20 > Some further clarifications and confirmations appear below. >=20 > Joe >=20 > On 2/17/2012 12:09 PM, Kim Kinnear wrote: >>=20 >> Joe, >>=20 >> Thank you for your review. >>=20 >> My responses are indented, below... >>=20 >> On Feb 13, 2012, at 5:00 PM, Joe Touch wrote: >>=20 >>> Hi, all, >>>=20 >> > I've reviewed this document as part of the transport area >>> directorate's ongoing effort to review key IETF documents. These >>> comments were written primarily for the transport area directors, >>> but are copied to the document's authors for their information and >>> to allow them to address any issues raised. The authors should >>> consider this review together with any other last-call comments >>> they receive. Please always CC tsv-dir@ietf.org if you reply to or >>> forward this review. >>>=20 >>> This request was received Feb. 2, 2012. >>>=20 >>> This document describes an extension to DHCPv4 for the bulk query >>> andtransfer of current lease status over TCP. >>>=20 >>> The following transport issues were noted, and are significant: >=20 >>> CONNECTION MANAGEMENT- The document describes the use of TCP >>> connections for bulk transfer, but needs to be more specific about = which >>> side (relay client or server) closes the connection, under what >>> circumstances, and with what mechanism (e.g., graceful CLOSE vs. = ABORT, >>> as per RFC 793) >>=20 >> Here is what we have now, 7.8 is for clients, 8.5 is for >> servers: >>=20 >>> 7.8. Closing Connections [Client Section] >>>=20 >>> The requestor SHOULD close the connection after the >>> DHCPLEASEQUERYDONE message is received for the last outstanding = query >>> that it has sent, if it has no more queries to send. >=20 > Under what conditions is it useful to not close at this time, and if = so, when/why is it eventually closed? >=20 > In this case it's also useful to explain what "no more queries to = send" means - are clients encouraged to keep the connection open in case = there are more to send, or do you expect that the client knows when it = opens the connection whether it has more to send - and if so, shouldn't = it have already sent them? These are not uninteresting questions, but they are over the line from protocol specification and into implementation in my view. I can certainly imagine that the requestor has multiple queries to send but has chosen to send them serially instead of in parallel (on the same connection or on different connections). That would be way that the requestor might know that it had more queries to send. It might have a queue of them. I will add this to the document: "If a requestor doesn't know if it has more queries to send or not, then it SHOULD close the connection." >=20 >>>=20 >>> 8.5. Closing Connections [Server Section] >>>=20 >>> The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT >>> seconds for a particular connection after it sends a >>> DHCPLEASEQUERYDONE message over that connection and if there is = no >>> current query outstanding for that connection. It should clear = this >=20 > Is this a SHOULD? Yes, I'll change it. >=20 > And should the timer be cleared or restarted? I was thinking of them as the same thing, but restarted is probably better language. I'll change it. >=20 > Under what conditions is it useful to not close at this time, and if = so, when/why is it closed? All of these SHOULDs derive from the fundamental SHOULD about starting a timer. You don't *have* to have a timer to implement this protocol. You SHOULD use a timer, but you don't *have* to. I can imagine other ways to dealing with closing dead connections which don't involve timers. No, I really don't want to put them into the document. But the initial SHOULD says that if you don't use a timer, you can still say that you implement this capability. >=20 >>> timer if a query arrives over that connection. If the timer = expires, >>> the DHCPv4 server should close the connection. >=20 > Is this a SHOULD, as well? Yes, thanks, I'll change it. >=20 > Again, under what conditions is it useful to not close at this time, = and if so, when/why is it closed? Again, this is a SHOULD because you don't even have to have a timer. But even if you have a timer, you don't have to close it when the timer goes off. You might want to be "smarter" about something, or use some external information not represented here to make what you consider a better decision. The SHOULD allows you to do that without causing you to wonder if you really support the document. >>> The server MUST close its end of the TCP connection if it = encounters >>> an error sending data on the connection. The server MUST close = its >>> end of the TCP connection if it finds that it has to abort an in- >>> process request. A server aborting an in-process request SHOULD >>> attempt to signal that to its requestors by using the = QueryTerminated >>> status code in the status-code option in a DHCPLEASEQUERYDONE >>> message, including a message string indicating details of the = reason >>> for the abort. If the server detects that the requesting end of = the >>> connection has been closed, the server MUST close its end of the >>> connection. >=20 > OK. I found it a bit confusing to have this in separate places, but I = viewed this from the transport perspective. This is fine. >=20 >> All connections are closed with a graceful CLOSE, and not >> with an ABORT. I'll add that to the document. >>=20 >> I'm at a loss to know how to be more specific about which >> side of the connection closes the connection. There are >> rules for the client in 7.8, and rules for the server in >> 8.5. >=20 > Somewhere you should state that the protocol exchange typically = involves the client closing the connection, and that the server closes = only under exceptions. Ok. I'll do that. >=20 >>> sec 7.3 indicates some conditions for terminating connections; this >>> section should indicate which side performs this, and by what >>> method(CLOSE, ABORT) >>=20 >> Section 7.3 discusses in two places where the "requestor" may >> drop the connection. The term "requestor" is used to >> indicate which "side" performs the actions. All of >> Section 7 is about "Requestor Behavior", and the specific >> details of section 7.3 in all cases indicate that the >> instructions for dealing with the connection concern the >> "requestor" explicitly. >>=20 >> I'll enhance the explanation to include that CLOSE should >> be used. >>=20 >> If there is a specific set of instructions that are >> unclear, I don't see them, so it would help me if you >> could give me more detailed guidance than "Section 7.3". >> Thanks. >=20 > It's probably sufficient to replace "requestor" with "client" to be = consistent. Requestor is the entity sending in the DHCPv4 Bulk Leasequery. Client is the entity that has a DHCPv4 address and whose information shows up in the data part of the DHCPv4 Bulk Leasequery requests. Client would not be consistent. > However, this section then supercedes the description in 7.8 and 8.5 = above - i.e., you are handling exceptions on the client side as well. I will enhance section 7.8 to indicate that requestors have to handle exception conditions and their intended actions. >=20 > I.e., 7.8 needs to include the exception cases listed in 7.3, or they = should just be moved there. Yes. >=20 >>>> this sec also allows connections to stay open after all pending >>>> transactions are complete (MAY); the rationale for this should be >>>> given, or the connection MUST be closed. >>=20 >> I will add some words which clarify the reasons why you >> might want to leave the connection open after all pending >> transactions are complete. >=20 > FWIW, again this contradicts 7.8 which says the client SHOULD close = after the response is received if it has no more queries to send. The rationale is that you might know from information not part of this document that you had more queries to send soon, even though you don't have them now. >=20 > This says "MAY" leave open. That's not the complement to SHOULD close. We don't really care if you keep it open or not. Really. If you think that you will be happier, keep it open. If you think it is simpler to close it (as I do), then close it. Different people (different authors even!) have different ideas about how they would structure the code for this. That's ok. The point about all of this open/closed/multiple-operations stuff it to leave it up to the implementor. Period. We are not trying to tell them exactly how to implement this. We are trying to focus on the protocol aspects, and leave = understood. >>> This section should more carefully explain behavior when a >>> connection is dropped and the reason - e.g., timeout, abort, >>> close. >> =09 >> The application employing Bulk Leasequery doesn't >> care about *why* the connection went away. It >> doesn't have to know if it was abort, close, or >> timeout. I will say that in this section. >=20 > Hmm. I would think that this information would be passed up to the = application. It might, but we don't care. Do you think we should? If the connection is gone, it is gone. I don't think I care which syscall caused it. >=20 >>>=20 >>> There were some other issues noted in this document. These >>> comments appear below, and although not focused on transport >>> issues, they represent significant issues that IMO should be >>> addressed as well. >>>=20 >>> NOTE - regarding some terminology issues, I did not survey current >>> DHCP RFCs for consistency, but IMO these terms should be corrected >>> even if they are then inconsistent with existing specs. >>> Joe >>>=20 >>> ----------- >>>=20 >>> Major non-transport issues: >>>=20 >>>=20 >=20 >>>=20 >>> - "VPN" is used throughout to refer to "private" addresses (RFC = 1918); a VPN is not just private addressing. >>=20 >> Hmm. Actually, VPN in this document does not refer to RFC 1918 >> private addressing. If this is important to you, could you >> be more specific as to your concern? >=20 > OK. I don't understand how it's being used, but if it's consistent = with the rest of DHCP, that's fine. >=20 > However, I got thrown off by your use of 10.x.x.x. >=20 > There are appropriate addresses to use as examples in RFCs - see RFC = 5737, and please change this example accordingly. I will replace the reference to 10.x.x.x with a reference to RFC 1918 addresses. Which is the point that I was trying to make, not about some example address. >=20 >=20 >>>=20 >=20 >>> - start-time-of-state is expressed as an offset from base-time; >>> this appears to be the only time indicated as an offset rather than >>> as an absolute. That inconsistency invites implementation errors; >>> IMO, this should be absolute too. >>=20 >> There are two kinds of time options here, input options >> and output options. The input options are all absolute >> times. The output options are all offset times from the >> base time (which by design is the only absolute time in >> the output packets). >=20 > That'd be very useful to explain this way. Is this typical for DHCP? = It's quite confusing IMO. DHCP times are traditionally in duration from "now", to not have to deal with clock skew issues (other than ongoing drift/skew). We introduced the base-time to work with that, and we kept the query times in absolute time. I'll add words to explain that. >=20 > > ...There are several input options >> defined in this document. The start-time-of-state is the >> only output option defined in this draft. It is defined >> as a offset to the base time in large part because the >> *other* output options that are used in the DHCP packet >> are *also* offsets to the base time. These options are >> not new, but are options that already exist in other >> RFC's. So, while it looks like the state-time-of-state >> is the odd man out at first glance, it actually is an >> offset time because the *other* options with which it >> will appear are also offset times. >>=20 >>>=20 >>> - option lengths: throughout, the doc refers to option lengths as >>> being "an octet"; they are *indicated* in one octet. Some are = constant >>> (e.g., DCHP-STATE), some allow the contents of the octet to vary. = Again, >>> this is an *unsigned integer* octet. >>=20 >> Yes, the size of an option is stored in >> one octet. So, yes, the length is *indicated* >> by the value in that one octet. >>=20 >> But the length may be 1 octet, it may be >> 5 octets, it may vary between 8 and 10 octets. >>=20 >> I don't understand your concern. Are you=09 >> saying that the length should not be >> stated to be "1 octet" or "5 octets"? >=20 > The length should be "indicated in 1 octet". I'm just suggesting a = change to the way it's described. When you say "the length is an octet", = that is ambiguous and can mean that the length value is 1, not just that = this value is stored in one octet. Ok, I'll fix that. >=20 >> I will fix the integer to be specifically >> unsigned (as previously indicated). >>>=20 >>> - some of the information provided (in DHCP-STATE) goes beyond >>> that of DHCP. It would be useful to motivate the need for this >>> information in a bulk query, and why it is not similarly available >>> for nodes using UDP (e.g., as an extension to DHCPv4, not just to >>> the bulk transfer command). again, absence of state information >>> should not indicate state. State should always be expressed >>> explicitly. these states are further meaningless without a state >>> diagram explaining them. if such a diagram is not possible (as >>> noted at end of sec 6.2.7), then the states are irrelevant and the >>> option should not be included. >>=20 >> The state transition diagram can certainly be drawn, but >> as it is fully connected, such a picture conveys no >> useful information. >=20 > It's sufficient to indicate this then. >=20 > > ... The transitions are not themselves >> useful in any case, as the the Bulk Leasequery is a >> snapshot of information at one instant of time. There is >> every reason to assume that as the state moves from one >> value to another that an external entity would not see >> all (or even many) of these transitions. This is a >> snapshot of the DHCP state, and could be nothing else in >> the environment of Bulk Leasequery. >>=20 >> The reason why the state transition graph is fully >> connected is due to the common practice in DHCPv4 of >> having two servers running in a failover relationship. >> There are then two state machines for the lease state, >> and at times one "leads" and the other "follows", and at >> other times the other "leads" and its partner "follows". >> So, examined individually, the state machines for each >> individual failover partner is fully connected because at >> any time it may receive an update from its partner that >> it decides to accept that will simply "set" the state to >> the value supplied by the partner. >>=20 >> All of this is orthogonal to the Bulk Leasequery protocol >> -- except that we want the user of the Bulk Leasequery >> protocol to be able to make sense out of information >> supplied by each of the failover partners. Or any >> partners running any increased availability solution. >>=20 >> So, that is the reason why the dhcp-state option exists >> at all -- to allow the user of Bulk Leasequery to make >> sense out of the results of sending a Bulk Leasequery to >> two different (but cooperating) DHCPv4 servers. >>=20 >> The DHC WG felt that this information was worthwhile to >> have in this document, and I agree (or we wouldn't have >> put it in). >=20 > Using the failover case as a justification would be helpful. Failover isn't an IETF standard, and so we try to step carefully around it possible existence. I don't think I could get this document through back through the DHC WG if I mentioned failover, so I don't think this is going to work. >>=20 >=20 >>> - sec 7.4 states that the clock skew of zero is desired; this >>> assumes E2E delays under 1sec. An explanation of why this is >>> desired should be given, as well as the consequences of it not. >>=20 >> I have given specific instructions on how to handle non-zero >> clock skews. There are no "consequences". You code it >> so that it works with non-zero clock skew. Period. >>=20 >> It is desired because it is less confusing to humans. >=20 > I would argue that this then irrelevant, and there should be no = statement about a skew of zero being preferred, since it could drive = implementations that way unnecessarily. I believe that the other reason we like zero skew is=20 that it tends to expose fewer bugs in people's code, so keeping the admonishment that it is a better=20 answer seems to add some value. >=20 >>> Other non-transport issues: >>>=20 >>> - The document includes definitions and references to irrelevant >>> deployment and implementation issues, notably DSLAMs, concentrators, = and >>> access concentrators. These should not appear formally; they should = be >>> used only to usefully illustrate currently intended uses. >>=20 >> These appear in the text in order to give >> the otherwise abstract design goals some concrete >> examples. We already removed a lot of the design >> goals, are you suggesting that they all be removed? >=20 > Actually, yes, except as examples in the intro/motivation. Elsewhere = they are IMO distracting. DSLAM, concentrator, and access concentrator appear only in Section 3, Design Goals -- which is precisely the = intro/motivation for this document. They don't appear (at least to my text = search engine) elsewhere. So I think we have done what you want. >=20 >=20 >>> - sec 3 should refer to relays, and returning the entire set or >>> individual bindings; there is no reason to explain the goals in = terms of >>> access concentrators. >>=20 >> I don't know about this. I could certainly change it, >> but is this really important to you? There was quite a >> bit of negotiation in the WG about these examples. I >> don't want to restart that discussion and have it all >> over again. Does this really matter that much to you? >=20 > The examples should focus on client/server/relay terminology. If other = example terms are used, they should be parenthetical examples: >=20 > relay (e.g., at a concentrator) >=20 > The point is that this is relevant without the concentrator. A = concentrator is just one current example of where a relay exists, not = the only one. True, and I will say that. There was too much discussion of these examples to remove them, but while they are important to the process of getting through the DHC WG review, they are not of significant importance technically. So, I will add a sentence discussing the fact that a=20 concentrator is just an example. >=20 >>> - sec 3.2 appears to provide contradictory advice - caching is = required, but should be avoided? it would be useful to resolve this = inconsistency. >>=20 >> Use of Bulk Leasequery is designed to help you avoid >> caching. >=20 > OK - it'd be useful to be clear on that in sec 3.2. I will say that in Section 3.2. >=20 >>> - sec 3.3 refers to 'fast path', but this term doesn't make sense in = this context because fast-path is a forwarding issue. it would be useful = to explain what you mean, and pick a different term >>=20 >> Yes, it is a forwarding issue, and many devices >> will not forward unless they know that they are forwarding >> to a device that has received a valid DHCPv4 address. >> The point (well, one point) of Bulk Leasequery is to >> allow these forwarders to gather data so that they >> can make the correct decision in the fast path. >=20 > Per-IP validation of that sort of permission isn't a fast-path = decision. Fast-path involves forwarding and policy decisions (which are = not typically /32 decisions). >=20 > It would be useful to say this information is useful so such routers = can make the appropriate decision, but the path (fast or slow) is = irrelevant IMO. Yes, fast-path is a forwarding issue, and I believe the intent of this section was to mention that the information returned by Leasequery is useful when deciding to forward a packet -- and that Bulk Leasequery gives you the information you need to decide to forward or not in advance of seeing the packet (when it is too late to deal with it in the fast path). I am not convinced that this should be changed. Regards -- Kim >=20 >> ------------ >>=20 >> Regards -- Kim >>=20 >>=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jhutz@cmu.edu Thu Feb 23 14:28:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A2F21F86F2; Thu, 23 Feb 2012 14:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ826cb+VsAG; Thu, 23 Feb 2012 14:28:11 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id E500A21F86E3; Thu, 23 Feb 2012 14:28:10 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q1NMS8Gk016988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2012 17:28:08 -0500 (EST) From: Jeffrey Hutzelman To: Kim Kinnear In-Reply-To: <7489_1330034399_q1NLxvMv002895_AC54B54D-8DAA-4D98-9A1E-FDEC36612A60@cisco.com> References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> <7489_1330034399_q1NLxvMv002895_AC54B54D-8DAA-4D98-9A1E-FDEC36612A60@cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 23 Feb 2012 17:28:07 -0500 Message-ID: <1330036087.24486.25.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: IETF discussion list , Joe Touch , "tsv-ads@tools.ietf.org" , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, TSV Dir , dhcwg@ietf.org, jhutz@cmu.edu Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 22:28:11 -0000 On Thu, 2012-02-23 at 17:00 -0500, Kim Kinnear wrote: > > This says "MAY" leave open. That's not the complement to SHOULD close. > > We don't really care if you keep it open or not. Really. > If you think that you will be happier, keep it open. If > you think it is simpler to close it (as I do), then close > it. Different people (different authors even!) have different > ideas about how they would structure the code for this. That's > ok. The point about all of this open/closed/multiple-operations > stuff it to leave it up to the implementor. Period. We are > not trying to tell them exactly how to implement this. We > are trying to focus on the protocol aspects, and leave understood. That's not what SHOULD means. An RFC2119 SHOULD is very strong; if the spec doesn't care what an implementation does, don't use SHOULD. -- Jeff From Carl.Wuyts@technicolor.com Thu Feb 23 23:18:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71CB21E8023 for ; Thu, 23 Feb 2012 23:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT1Ecaim2ZVQ for ; Thu, 23 Feb 2012 23:18:35 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2595921E800C for ; Thu, 23 Feb 2012 23:18:21 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKT0c5vcBNKq5KCujgU/J88aLYG787p9gs@postini.com; Thu, 23 Feb 2012 23:18:25 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 24 Feb 2012 08:11:07 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Fri, 24 Feb 2012 08:11:14 +0100 From: Wuyts Carl To: Ted Lemon Date: Fri, 24 Feb 2012 08:11:13 +0100 Thread-Topic: [dhcwg] RFC3633 Clarification Thread-Index: AczxljEcvOCzsnEISR6k2DdBfb+SZgARD9oAAAdT6YAAFW22gAAJcBOAAAAahoAAELoYEP//ziKA//+1PUA= Message-ID: <867F4B6A1672E541A94676D556793ACD0E9AFBC179@MOPESMBX01.eu.thmulti.com> References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> <679CEBC0-97B7-48CE-B5A7-A1833CAF4C7A@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC050@MOPESMBX01.eu.thmulti.com> <217FC32E-301D-48EF-B5D1-EA86AA55F76B@nominum.com> In-Reply-To: <217FC32E-301D-48EF-B5D1-EA86AA55F76B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0E9AFBC179MOPESMBX01eut_" MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:18:37 -0000 --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC179MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interesting statement. So, your use case is multi-homed. And you're getting bound to multiple ser= vers, so getting options for different DHCpv6 servers. As far as I can see, this is NOT what I've stated. The BBF data model allo= ws for a SINGLE DHCPv6 client to get options from MULITPLE DHCPv6 servers, = hence getting bound to multiple ones. Correct me if I see this wrong, but = if you're multi-homed, you've multiple interfaces (one to each 'home"), hen= ce are running multiple dhcpv6 clients, no ?? Regs Carl From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: donderdag 23 februari 2012 19:40 To: Wuyts Carl Cc: Bernie Volz (volz); Subject: Re: [dhcwg] RFC3633 Clarification On Feb 23, 2012, at 8:48 AM, Wuyts Carl > wrote: While I would strongly doubt this to really happen in real life (yes you ca= n have offers from multiple servers, no you should only take them from the = preferred one) it could have been avoided with a clear state machine (this = is not possible in v4 either). Of course it can happen in real life if a site is multihomed. The reason = we didn't diagram a state machine is because when we did in in DHCPv4, peop= le read the state machine diagram instead of the spec. --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC179MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Interesti= ng statement.

So, your use= case is multi-homed.  And you’re getting bound to multiple serv= ers, so getting options for different DHCpv6 servers.

=

As far as I can see, this is NOT what I’v= e stated.  The BBF data model allows for a SINGLE DHCPv6 client to get= options from MULITPLE DHCPv6 servers, hence getting bound to multiple ones= .  Correct me if I see this wrong, but if you’re multi-homed, yo= u’ve multiple interfaces (one to each ‘home”), hence are = running multiple dhcpv6 clients, no ??

 

Regs=

Carl

 

From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent:<= /b> donderdag 23 februari 2012 19:40
To: Wuyts Carl
Cc:= Bernie Volz (volz); <dhcwg@ietf.org>
Subject: Re: [dhcwg] = RFC3633 Clarification

 

On Feb 23, 2012, at 8:= 48 AM, Wuyts Carl <Carl.Wu= yts@technicolor.com> wrote:

While I = would strongly doubt this to really happen in real life (yes you can have o= ffers from multiple servers, no you should only take them from the preferre= d one) it could have been avoided with a clear state machine (this is not p= ossible in v4 either).

 

Of course it can ha= ppen in real life if a site is multihomed.   The reason we didn't diag= ram a state machine is because when we did in in DHCPv4, people read the st= ate machine diagram instead of the spec.

 

= --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC179MOPESMBX01eut_-- From tomasz.mrugalski@gmail.com Fri Feb 24 01:18:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757E321F87BD for ; Fri, 24 Feb 2012 01:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl6aQoW4DpcG for ; Fri, 24 Feb 2012 01:18:06 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47AC321F8766 for ; Fri, 24 Feb 2012 01:18:01 -0800 (PST) Received: by bkwj4 with SMTP id j4so258332bkw.31 for ; Fri, 24 Feb 2012 01:18:00 -0800 (PST) Received-SPF: pass (google.com: domain of tomasz.mrugalski@gmail.com designates 10.204.151.11 as permitted sender) client-ip=10.204.151.11; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tomasz.mrugalski@gmail.com designates 10.204.151.11 as permitted sender) smtp.mail=tomasz.mrugalski@gmail.com; dkim=pass header.i=tomasz.mrugalski@gmail.com Received: from mr.google.com ([10.204.151.11]) by 10.204.151.11 with SMTP id a11mr628055bkw.134.1330075080399 (num_hops = 1); Fri, 24 Feb 2012 01:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=SX568w7oJIp/oVX1XYLXGaxc+5dVYbO5DCBZhtyuSx0=; b=GVSYOnNQXyYJmRXYslNuXiPfV5u9AuAIGYXt4poPCyvpB2ZJYnsax33jYZ+NZCRDp0 KZXyQcMm8Dxg4zoKyJLJQ7s5AMOVWbk/jPQMQRRLImNdnyBf9e2O2ylF3OKO/uQG58Pw MHi2pPE722GpLr0+v5/NMp/Ad6+UnEON5eLbc= Received: by 10.204.151.11 with SMTP id a11mr520514bkw.134.1330075080312; Fri, 24 Feb 2012 01:18:00 -0800 (PST) Received: from tomek.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id w14sm3594004bkd.15.2012.02.24.01.17.59 (version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 01:17:59 -0800 (PST) Message-ID: <4F4755C6.6010606@gmail.com> Date: Fri, 24 Feb 2012 10:17:58 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> <679CEBC0-97B7-48CE-B5A7-A1833CAF4C7A@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC050@MOPESMBX01.eu.thmulti.com> <217FC32E-301D-48EF-B5D1-EA86AA55F76B@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC179@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0E9AFBC179@MOPESMBX01.eu.thmulti.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:18:07 -0000 On 12-02-24 08:11, Wuyts Carl wrote: > Interesting statement. > > So, your use case is multi-homed. And you’re getting bound to multiple > servers, so getting options for different DHCpv6 servers. > > As far as I can see, this is NOT what I’ve stated. The BBF data model > allows for a SINGLE DHCPv6 client to get options from MULITPLE DHCPv6 > servers, hence getting bound to multiple ones. Correct me if I see this > wrong, but if you’re multi-homed, you’ve multiple interfaces (one to > each ‘home”), hence are running multiple dhcpv6 clients, no ?? Not necessarily. What happens if you have two servers from two provisioning domains, e.g. home network with two uplinks (two CPEs leading to two separate ISPs), connected to the same link. See discussion in homenet WG. BTW it's an interesting use case. It breaks things in so many unexpected ways. From purely user's perspective, that is reasonable case. I can't imagine how it could work today, but with proper protocol modifications, I hope it will work one day. Also, if you read RFC3315 closely, section 17.1.3 has this interesting sentence: "Upon receipt of one or more valid Advertise messages, the client selects one or more Advertise messages based upon the following criteria". Following criteria are about server preference values. So sending requests to more than one server at the same time is uncommon, but valid operation. Cheers, Tomek From ichiroumakino@gmail.com Fri Feb 24 05:59:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C735521F8576 for ; Fri, 24 Feb 2012 05:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYBmX4lVH8ig for ; Fri, 24 Feb 2012 05:59:26 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D40AB21F854E for ; Fri, 24 Feb 2012 05:59:23 -0800 (PST) Received: by werg1 with SMTP id g1so1918296wer.31 for ; Fri, 24 Feb 2012 05:59:23 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.79.229 as permitted sender) client-ip=10.180.79.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.79.229 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.79.229]) by 10.180.79.229 with SMTP id m5mr5428050wix.6.1330091963143 (num_hops = 1); Fri, 24 Feb 2012 05:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2OJK2u5j8MvhSvVpkUYFS1wjCXLnygS6JfNnzZd3WWM=; b=grWxbWgxtLmmlpQygXVhhMQrMttQ08SI2sabxVkke7e7E0GDmpjntb8A7ceswEg/+I sHAkB+QmynN2aF220L2/PkKPLGjONw4idwPZV0QHNtZD4xKYFU6siaIgTMl7WWoJC1q4 6T79Xoa6o7BiTy0abZsBbYEeSdHEf0jI2CVbY= Received: by 10.180.79.229 with SMTP id m5mr4371127wix.6.1330091963087; Fri, 24 Feb 2012 05:59:23 -0800 (PST) Received: from dhcp-10-61-98-136.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gf3sm3675718wib.6.2012.02.24.05.59.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 05:59:22 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 24 Feb 2012 14:59:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5613C3A4-3C37-4770-A886-1BC7B59BCF5B@employees.org> References: <23B7A44B-A207-40E9-AD17-CA5465819767@employees.org> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1257) Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] RFC3633 Clarification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 13:59:26 -0000 Bernie, > I sent a query to Ole separately regarding this, but I think as it is = related to the issue of what to do about IA_NA & IA_PD in a single = request (or not), it is something for the community at large to consider = ... >=20 > Given the RFC 3633 text, what is a server supposed to do if there are = TWO IA_PDs in the Rebind and it only knows about 1 and not the other? = (And let's assume it doesn't do the 'MAY' part of can't determine the = 'onlink' nature of the prefixes in the one it doesn't know about).=20 this is no different than if there was two IA_NA's. the 3633 section is = cut and paste from 3315 section 18.2.4. when the client and server is out of sync, presumably the correct = behaviour is to silently discard. > While RFC 3315 and 3633 were developed with the idea that multiple IAs = would be present, I don't think we thought about these issues clearly = enough to have correctly handled them all. I wouldn't go that far. I think the main issues are around multi-homing = / multiple administrative domains / policy collisions. I don't think we = have to confluence the two problems. if we: - deprecated "CONFIRM" messages - moved T1/T2 out of the IA_* container - moved address specific text out of the base protocol text then: - RFC3633 could be replaced with a simple "DHCP option for prefix = delegation" instead of a=20 new flavour of DHCP - we could handle any new stateful option - punt on solving the issues of multi-homing / multiple administrative = domains / policy collisions cheers, Ole From touch@isi.edu Fri Feb 24 16:08:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE2B21E8013; Fri, 24 Feb 2012 16:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TFNJiCzOXdw; Fri, 24 Feb 2012 16:08:54 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1037021E801A; Fri, 24 Feb 2012 16:08:54 -0800 (PST) Received: from [192.168.1.100] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1P08W1n004092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2012 16:08:35 -0800 (PST) Message-ID: <4F482681.4030607@isi.edu> Date: Fri, 24 Feb 2012 16:08:33 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Kim Kinnear References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-ads@tools.ietf.org" , TSV Dir , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, dhcwg@ietf.org, IETF discussion list Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:08:55 -0000 Hi, Kim, On 2/23/2012 10:57 AM, Kim Kinnear wrote: > > Joe, > > There were two things that I referenced in response to your initial > review that you hadn't seen. More details on those below: > > > On Feb 17, 2012, at 5:47 PM, Joe Touch wrote: > > -------------------------------------------- > >>> INTERLEAVING- sec 7.7 says that the server MUST interleave >>> replies; >>> there doesn't seem a valid reason for this requirement. clearly the >>> receiver MUST tolerate interleaved replies. having the server interleave >>> replies is relevant only if each request/reply has its own timeout -- >>> which should be overridden if there is another response in progress >>> anyway. This issue should be more clearly explained and motivated. >> >> Robert Sparks offered clarification, which I like >> a lot and have already agreed to use: > > I didn't see that; can you send that to tsv-dir@ietf.org and me? > >>> Is the requirement you are really trying to capture "MUST >>> NOT block sending replies on new queries until all >>> replies for the existing query are complete."? > > I wasn't clear here -- the entire result of our > discussion was captured in the text above. Thanks for the clarification. > Note that a server does not *have* to support multiple > queries on the same connection. If, however, a server > chooses to do so, then the following discussion is > operative: > > Based on my discussion with Robert Sparks, the sentence: > > "A server that is processing multiple queries > simultaneously MUST interleave replies to the multiple > queries within the stream of reply messages it sends." > > will be replaced by the sentence: > > "The server MUST NOT block sending replies on new > queries until all replies for the existing query are > complete." That's awkward. I know you intend this to mean "replies to new queries MUST NOT block on the current response", but it also reads as implying "the server MUST not block on the current response, but can block after that". Perhaps "the server MUST NOT allow any one response to block other pending responses; where multiple responses are pending, they MUST be interleaved (round-robin per-request? round-robin weighted by response length? other?)." > ------------------------------------------------- > >>>> >>>> - The protocol supports bulk transfer that is not data driven. >>>> This could represent a security vulnerability by exposing >>>> information that may not be on the data path (and thus already >>>> accessible) to a relay agent. This should be discussed in the >>>> security considerations section. >>> >>> All data that is exposed has already been >>> exposed using UDP to regular DHCP port. But please see >>> my response to Stephen Farrell (which is too long to include >>> here) to see if it covers the issues about which you >>> have concerns. >> >> Again, I didn't see it; please send a copy to tsv-dir@ietf.org > > There are two related posts that I will include here > in order to keep this discussion in some kind of order. > > Here are the words that I proposed to Stephen which > he accepted: > > There are two specific issues regarding Bulk Leasequery > security that deserve explicit mention. The first is > preventing information that Bulk Leasequery can provide from > reaching clients who are not authorized to receive such > information. The second is ensuring that authorized clients of > the Bulk Leasequery capability receive accurate information > from the Server (and that this information is not disrupted in > transit). > > To prevent information leakage to unauthorized clients Servers > SHOULD restrict Bulk Leasequery connections and > DHCPBULKLEASEQUERY messages to certain requestors, either > through explicit configuration of the Server itself or by > employing external network elements to provide such > restrictions. In particular, the typical DHCPv4 client SHOULD > NOT be allowed to receive a response to a Bulk Leasequery > request, and some technique MUST exist to allow prevention of > such access in any environment where Bulk Leasequery is > deployed. > > Connections not from permitted requestors SHOULD be closed > immediately, to avoid server connection resource exhaustion or > alternatively, simply not be allowed to reach the server at > all. Servers SHOULD have the capability to restrict certain > requestors to certain query types. Servers MAY reply to > queries that are not permitted with the DHCPLEASEQUERYDONE > message with a status-code option status of NotAllowed, or MAY > simply close the connection. > > To prevent disruption and malicious corruption of Bulk > Leasequery data flows between the server and authorized clients > these data flows SHOULD transit only secured networks. These > data flows are typically infrastructure oriented, and there is > usually no reason to have them flowing over networks where such > attacks are likely. In the rare cases where these data flows > might need to be sent through unsecured networks, they MUST > sent over connections secured through means external to the > DHCPv4/DHCPv6 server and its client(s) (e.g., through VPN's). > > Here is Ted Lemon's reply to Stephen's suggestion about > using SSH/TLS to secure the data flows of DHCPv4 > Bulk Leasequery: > >> From Ted Lemon, Feb 22 2012, 10:37:12 EST: > > The main reason why TLS wasn't included is that there is zero > chance of anyone using it. IMO, that's an insufficient reason; the Internet is rife with protocols that nobody would look at - until they did ;-) > ...In practice this protocol is useful > only in a very specific sort of application: communications > between the core of an ISP network and the edge of the ISP > network. Either: a) if this is true, then the protocol needs a mechanism to *enforce* its use *only* in this sort of environment or b) IMO, it *will* be used elsewhere, and such use should be anticipated in its design I favor the latter approach, but either one is a path forward. Joe >... Encrypting everything would be quite expensive; the > value of the data that would be acquired in an attack is low; the > risk that there could be an attacker that would do this is low, > since it would require physical access. Furthermore, if someone > does break in, they can just collect this data with a sniffer. > > Given these considerations, the additional verbiage and testing > required for TLS support seemed unnecessary and potentially > damaging, since untested code is vulnerable code. The working > group did actually consider requesting that the authors add TLS > to the document, but concluded that it was not worthwhile. > > ----------------------------- > > Regards -- Kim > > > > > From touch@isi.edu Fri Feb 24 16:28:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C07921E801F; Fri, 24 Feb 2012 16:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie+1wGzS7AIz; Fri, 24 Feb 2012 16:28:54 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9177021E8013; Fri, 24 Feb 2012 16:28:54 -0800 (PST) Received: from [192.168.1.100] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1P0ScKG011678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2012 16:28:41 -0800 (PST) Message-ID: <4F482B37.9060709@isi.edu> Date: Fri, 24 Feb 2012 16:28:39 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Kim Kinnear References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-ads@tools.ietf.org" , IETF discussion list , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, dhcwg@ietf.org, TSV Dir Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:28:56 -0000 Hi, Kim, On 2/23/2012 2:00 PM, Kim Kinnear wrote: > > Joe, > > I've edited the the email trail to try to concentrate on > the remaining open issues. I've also removed the two > issues that were included in the email I sent you an hour > or so ago, since I expect that they will be covered in > continuations of that thread. > > To summarize, there are 3 issues remaining that are > not included below: > > 1. The NAGLE issue you raised, which has its own thread. > > 2. The two issues: > > a) Interleaving > > b) Possible security vulnerability if data > is available that wasn't already in the data > path. > > 3. The ? issues remaining, below. I think that > the number could be 0, but probably not. > > Regards -- Kim > > > > On Feb 17, 2012, at 5:47 PM, Joe Touch wrote: > >> Hi, Kim, >> >> First, thank you for your detailed response to my quite lengthy review. >> >> Some further clarifications and confirmations appear below. >> >> Joe >> >> On 2/17/2012 12:09 PM, Kim Kinnear wrote: >>> >>> Joe, >>> >>> Thank you for your review. >>> >>> My responses are indented, below... >>> >>> On Feb 13, 2012, at 5:00 PM, Joe Touch wrote: >>> >>>> Hi, all, >>>> >>>> I've reviewed this document as part of the transport area >>>> directorate's ongoing effort to review key IETF documents. These >>>> comments were written primarily for the transport area directors, >>>> but are copied to the document's authors for their information and >>>> to allow them to address any issues raised. The authors should >>>> consider this review together with any other last-call comments >>>> they receive. Please always CC tsv-dir@ietf.org if you reply to or >>>> forward this review. >>>> >>>> This request was received Feb. 2, 2012. >>>> >>>> This document describes an extension to DHCPv4 for the bulk query >>>> andtransfer of current lease status over TCP. >>>> >>>> The following transport issues were noted, and are significant: >> >>>> CONNECTION MANAGEMENT- The document describes the use of TCP >>>> connections for bulk transfer, but needs to be more specific about which >>>> side (relay client or server) closes the connection, under what >>>> circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT, >>>> as per RFC 793) >>> >>> Here is what we have now, 7.8 is for clients, 8.5 is for >>> servers: >>> >>>> 7.8. Closing Connections [Client Section] >>>> >>>> The requestor SHOULD close the connection after the >>>> DHCPLEASEQUERYDONE message is received for the last outstanding query >>>> that it has sent, if it has no more queries to send. >> >> Under what conditions is it useful to not close at this time, and if so, when/why is it eventually closed? >> >> In this case it's also useful to explain what "no more queries to send" means - are clients encouraged to keep the connection open in case there are more to send, or do you expect that the client knows when it opens the connection whether it has more to send - and if so, shouldn't it have already sent them? > > These are not uninteresting questions, but they are over > the line from protocol specification and into > implementation in my view. While I agree, were that true then the doc would not have *any* advice on what to do in these cases. I'm suggesting that the advice should be consistent. Omitting it all would be fine too. > I can certainly imagine that > the requestor has multiple queries to send but has chosen > to send them serially instead of in parallel (on the same > connection or on different connections). That would be > way that the requestor might know that it had more > queries to send. It might have a queue of them. > > I will add this to the document: > > "If a requestor doesn't know if it has more queries to > send or not, then it SHOULD close the connection." That works. >>>> 8.5. Closing Connections [Server Section] >>>> >>>> The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT >>>> seconds for a particular connection after it sends a >>>> DHCPLEASEQUERYDONE message over that connection and if there is no >>>> current query outstanding for that connection. It should clear this >> >> Is this a SHOULD? > > Yes, I'll change it. >> >> And should the timer be cleared or restarted? > > I was thinking of them as the same thing, but restarted > is probably better language. I'll change it. AOK. "Cleared" could mean that there is no longer a timer running. >> Under what conditions is it useful to not close at this time, and if so, when/why is it closed? > > All of these SHOULDs derive from the fundamental SHOULD > about starting a timer. You don't *have* to have a timer > to implement this protocol. You SHOULD use a timer, but > you don't *have* to. I can imagine other ways to dealing > with closing dead connections which don't involve timers. > No, I really don't want to put them into the document. > But the initial SHOULD says that if you don't use a > timer, you can still say that you implement this > capability. IMO, you're using SHOULD above in non-2119 ways. SHOULD implies there's a significant issue with either the protocol or implementation that has exceptions. You're just saying "implementations will save resources by using a timer and conserving the open connections". IMO, if that's the goal, then it'd be preferable to make the recommendation that way, rather than using 2119 language. >>>> timer if a query arrives over that connection. If the timer expires, >>>> the DHCPv4 server should close the connection. >> >> Is this a SHOULD, as well? > > Yes, thanks, I'll change it. >> >> Again, under what conditions is it useful to not close at this time, and if so, when/why is it closed? > > Again, this is a SHOULD because you don't even have to > have a timer. But even if you have a timer, you don't > have to close it when the timer goes off. You might want > to be "smarter" about something, or use some external > information not represented here to make what you > consider a better decision. The SHOULD allows you to do > that without causing you to wonder if you really support > the document. Again, this is good reason to reword the timer issue as "try to conserve connections; try to reuse them for multiple requests from the same relay, and try to close them as soon as all pending queries are complete; the method for doing so is left to the implementer". Otherwise IMO you'll have people deriving correctness from whether the connection stays open or not. >>>> The server MUST close its end of the TCP connection if it encounters >>>> an error sending data on the connection. The server MUST close its >>>> end of the TCP connection if it finds that it has to abort an in- >>>> process request. A server aborting an in-process request SHOULD >>>> attempt to signal that to its requestors by using the QueryTerminated >>>> status code in the status-code option in a DHCPLEASEQUERYDONE >>>> message, including a message string indicating details of the reason >>>> for the abort. If the server detects that the requesting end of the >>>> connection has been closed, the server MUST close its end of the >>>> connection. >> >> OK. I found it a bit confusing to have this in separate places, but I viewed this from the transport perspective. This is fine. >> >>> All connections are closed with a graceful CLOSE, and not >>> with an ABORT. I'll add that to the document. >>> >>> I'm at a loss to know how to be more specific about which >>> side of the connection closes the connection. There are >>> rules for the client in 7.8, and rules for the server in >>> 8.5. >> >> Somewhere you should state that the protocol exchange typically involves the client closing the connection, and that the server closes only under exceptions. > > Ok. I'll do that. >> >>>> sec 7.3 indicates some conditions for terminating connections; this >>>> section should indicate which side performs this, and by what >>>> method(CLOSE, ABORT) >>> >>> Section 7.3 discusses in two places where the "requestor" may >>> drop the connection. The term "requestor" is used to >>> indicate which "side" performs the actions. All of >>> Section 7 is about "Requestor Behavior", and the specific >>> details of section 7.3 in all cases indicate that the >>> instructions for dealing with the connection concern the >>> "requestor" explicitly. >>> >>> I'll enhance the explanation to include that CLOSE should >>> be used. >>> >>> If there is a specific set of instructions that are >>> unclear, I don't see them, so it would help me if you >>> could give me more detailed guidance than "Section 7.3". >>> Thanks. >> >> It's probably sufficient to replace "requestor" with "client" to be consistent. > > Requestor is the entity sending in the DHCPv4 Bulk Leasequery. Then you mean relay? > Client is the entity that has a DHCPv4 address and whose > information shows up in the data part of the DHCPv4 Bulk > Leasequery requests. Client would not be consistent. AOK. (see above; then use "relay" here). >> However, this section then supercedes the description in 7.8 and 8.5 above - i.e., you are handling exceptions on the client side as well. > > I will enhance section 7.8 to indicate that requestors > have to handle exception conditions and their intended > actions. AOK. >> >> I.e., 7.8 needs to include the exception cases listed in 7.3, or they should just be moved there. > > Yes. >> >>>>> this sec also allows connections to stay open after all pending >>>>> transactions are complete (MAY); the rationale for this should be >>>>> given, or the connection MUST be closed. >>> >>> I will add some words which clarify the reasons why you >>> might want to leave the connection open after all pending >>> transactions are complete. >> >> FWIW, again this contradicts 7.8 which says the client SHOULD close after the response is received if it has no more queries to send. > > The rationale is that you might know from information not > part of this document that you had more queries to send > soon, even though you don't have them now. See discussion above about rewording this all to "conserve resources where possible", rather than making specific recommendations as to how to do so. >> This says "MAY" leave open. That's not the complement to SHOULD close. > > We don't really care if you keep it open or not. Really. > If you think that you will be happier, keep it open. If > you think it is simpler to close it (as I do), then close > it. Different people (different authors even!) have different > ideas about how they would structure the code for this. That's > ok. The point about all of this open/closed/multiple-operations > stuff it to leave it up to the implementor. Period. We are > not trying to tell them exactly how to implement this. We > are trying to focus on the protocol aspects, and leave understood. Yet further rationale to reword as above. >>>> This section should more carefully explain behavior when a >>>> connection is dropped and the reason - e.g., timeout, abort, >>>> close. >>> >>> The application employing Bulk Leasequery doesn't >>> care about *why* the connection went away. It >>> doesn't have to know if it was abort, close, or >>> timeout. I will say that in this section. >> >> Hmm. I would think that this information would be passed up to the application. > > It might, but we don't care. Do you think we should? > If the connection is gone, it is gone. I don't think > I care which syscall caused it I think that this info should be passed up to the app, as per RFC 1122. I do think that apps would do different things - log the error differently at least, or retry in some cases but not others. >>>> There were some other issues noted in this document. These >>>> comments appear below, and although not focused on transport >>>> issues, they represent significant issues that IMO should be >>>> addressed as well. >>>> >>>> NOTE - regarding some terminology issues, I did not survey current >>>> DHCP RFCs for consistency, but IMO these terms should be corrected >>>> even if they are then inconsistent with existing specs. >>>> Joe >>>> >>>> ----------- >>>> >>>> Major non-transport issues: >>>> >>>> >> >>>> >>>> - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a VPN is not just private addressing. >>> >>> Hmm. Actually, VPN in this document does not refer to RFC 1918 >>> private addressing. If this is important to you, could you >>> be more specific as to your concern? >> >> OK. I don't understand how it's being used, but if it's consistent with the rest of DHCP, that's fine. >> >> However, I got thrown off by your use of 10.x.x.x. >> >> There are appropriate addresses to use as examples in RFCs - see RFC 5737, and please change this example accordingly. > > I will replace the reference to 10.x.x.x with a reference > to RFC 1918 addresses. Which is the point that I was trying > to make, not about some example address. AOK. >> >> >>>> >> >>>> - start-time-of-state is expressed as an offset from base-time; >>>> this appears to be the only time indicated as an offset rather than >>>> as an absolute. That inconsistency invites implementation errors; >>>> IMO, this should be absolute too. >>> >>> There are two kinds of time options here, input options >>> and output options. The input options are all absolute >>> times. The output options are all offset times from the >>> base time (which by design is the only absolute time in >>> the output packets). >> >> That'd be very useful to explain this way. Is this typical for DHCP? It's quite confusing IMO. > > DHCP times are traditionally in duration from "now", to not have > to deal with clock skew issues (other than ongoing drift/skew). > > We introduced the base-time to work with that, and we kept > the query times in absolute time. I'll add words to explain > that. AOK. >> >>> ...There are several input options >>> defined in this document. The start-time-of-state is the >>> only output option defined in this draft. It is defined >>> as a offset to the base time in large part because the >>> *other* output options that are used in the DHCP packet >>> are *also* offsets to the base time. These options are >>> not new, but are options that already exist in other >>> RFC's. So, while it looks like the state-time-of-state >>> is the odd man out at first glance, it actually is an >>> offset time because the *other* options with which it >>> will appear are also offset times. >>> >>>> >>>> - option lengths: throughout, the doc refers to option lengths as >>>> being "an octet"; they are *indicated* in one octet. Some are constant >>>> (e.g., DCHP-STATE), some allow the contents of the octet to vary. Again, >>>> this is an *unsigned integer* octet. >>> >>> Yes, the size of an option is stored in >>> one octet. So, yes, the length is *indicated* >>> by the value in that one octet. >>> >>> But the length may be 1 octet, it may be >>> 5 octets, it may vary between 8 and 10 octets. >>> >>> I don't understand your concern. Are you >>> saying that the length should not be >>> stated to be "1 octet" or "5 octets"? >> >> The length should be "indicated in 1 octet". I'm just suggesting a change to the way it's described. When you say "the length is an octet", that is ambiguous and can mean that the length value is 1, not just that this value is stored in one octet. > > Ok, I'll fix that. >> >>> I will fix the integer to be specifically >>> unsigned (as previously indicated). >>>> >>>> - some of the information provided (in DHCP-STATE) goes beyond >>>> that of DHCP. It would be useful to motivate the need for this >>>> information in a bulk query, and why it is not similarly available >>>> for nodes using UDP (e.g., as an extension to DHCPv4, not just to >>>> the bulk transfer command). again, absence of state information >>>> should not indicate state. State should always be expressed >>>> explicitly. these states are further meaningless without a state >>>> diagram explaining them. if such a diagram is not possible (as >>>> noted at end of sec 6.2.7), then the states are irrelevant and the >>>> option should not be included. >>> >>> The state transition diagram can certainly be drawn, but >>> as it is fully connected, such a picture conveys no >>> useful information. >> >> It's sufficient to indicate this then. >> >>> ... The transitions are not themselves >>> useful in any case, as the the Bulk Leasequery is a >>> snapshot of information at one instant of time. There is >>> every reason to assume that as the state moves from one >>> value to another that an external entity would not see >>> all (or even many) of these transitions. This is a >>> snapshot of the DHCP state, and could be nothing else in >>> the environment of Bulk Leasequery. >>> >>> The reason why the state transition graph is fully >>> connected is due to the common practice in DHCPv4 of >>> having two servers running in a failover relationship. >>> There are then two state machines for the lease state, >>> and at times one "leads" and the other "follows", and at >>> other times the other "leads" and its partner "follows". >>> So, examined individually, the state machines for each >>> individual failover partner is fully connected because at >>> any time it may receive an update from its partner that >>> it decides to accept that will simply "set" the state to >>> the value supplied by the partner. >>> >>> All of this is orthogonal to the Bulk Leasequery protocol >>> -- except that we want the user of the Bulk Leasequery >>> protocol to be able to make sense out of information >>> supplied by each of the failover partners. Or any >>> partners running any increased availability solution. >>> >>> So, that is the reason why the dhcp-state option exists >>> at all -- to allow the user of Bulk Leasequery to make >>> sense out of the results of sending a Bulk Leasequery to >>> two different (but cooperating) DHCPv4 servers. >>> >>> The DHC WG felt that this information was worthwhile to >>> have in this document, and I agree (or we wouldn't have >>> put it in). >> >> Using the failover case as a justification would be helpful. > > Failover isn't an IETF standard, and so we try to step > carefully around it possible existence. I don't think > I could get this document through back through the DHC WG > if I mentioned failover, so I don't think this is going > to work. FWIW, I don't think that creating this level of detail about state feedback achieves the goal; it codifies support for a non-standard mechanism. IMO, that issue deserves some light, not a shadowy corner. I'll leave it to the WG to decide, though - this isn't a transport issue. >> >>>> - sec 7.4 states that the clock skew of zero is desired; this >>>> assumes E2E delays under 1sec. An explanation of why this is >>>> desired should be given, as well as the consequences of it not. >>> >>> I have given specific instructions on how to handle non-zero >>> clock skews. There are no "consequences". You code it >>> so that it works with non-zero clock skew. Period. >>> >>> It is desired because it is less confusing to humans. >> >> I would argue that this then irrelevant, and there should be no statement about a skew of zero being preferred, since it could drive implementations that way unnecessarily. > > I believe that the other reason we like zero skew is > that it tends to expose fewer bugs in people's code, > so keeping the admonishment that it is a better > answer seems to add some value. That's a good reason to avoid the admonishment, IMO. If the code breaks, it should break early and often. "Expecting" a particular skew encourages bad programming IMO. >> >>>> Other non-transport issues: >>>> >>>> - The document includes definitions and references to irrelevant >>>> deployment and implementation issues, notably DSLAMs, concentrators, and >>>> access concentrators. These should not appear formally; they should be >>>> used only to usefully illustrate currently intended uses. >>> >>> These appear in the text in order to give >>> the otherwise abstract design goals some concrete >>> examples. We already removed a lot of the design >>> goals, are you suggesting that they all be removed? >> >> Actually, yes, except as examples in the intro/motivation. Elsewhere they are IMO distracting. > > DSLAM, concentrator, and access concentrator appear only > in Section 3, Design Goals -- which is precisely the intro/motivation > for this document. They don't appear (at least to my text search > engine) elsewhere. So I think we have done what you want. Design goals is Sec 3; the intro is Sec 1. I'm saying using this terminology in the intro (sec 1) is fine, but in the design goals (sec 3) is distracting. >>>> - sec 3 should refer to relays, and returning the entire set or >>>> individual bindings; there is no reason to explain the goals in terms of >>>> access concentrators. >>> >>> I don't know about this. I could certainly change it, >>> but is this really important to you? There was quite a >>> bit of negotiation in the WG about these examples. I >>> don't want to restart that discussion and have it all >>> over again. Does this really matter that much to you? >> >> The examples should focus on client/server/relay terminology. If other example terms are used, they should be parenthetical examples: >> >> relay (e.g., at a concentrator) >> >> The point is that this is relevant without the concentrator. A concentrator is just one current example of where a relay exists, not the only one. > > True, and I will say that. There was too much discussion > of these examples to remove them, but while they are > important to the process of getting through the DHC WG > review, they are not of significant importance technically. > > So, I will add a sentence discussing the fact that a > concentrator is just an example. AOK. >> >>>> - sec 3.2 appears to provide contradictory advice - caching is required, but should be avoided? it would be useful to resolve this inconsistency. >>> >>> Use of Bulk Leasequery is designed to help you avoid >>> caching. >> >> OK - it'd be useful to be clear on that in sec 3.2. > > I will say that in Section 3.2. AOK >> >>>> - sec 3.3 refers to 'fast path', but this term doesn't make sense in this context because fast-path is a forwarding issue. it would be useful to explain what you mean, and pick a different term >>> >>> Yes, it is a forwarding issue, and many devices >>> will not forward unless they know that they are forwarding >>> to a device that has received a valid DHCPv4 address. >>> The point (well, one point) of Bulk Leasequery is to >>> allow these forwarders to gather data so that they >>> can make the correct decision in the fast path. >> >> Per-IP validation of that sort of permission isn't a fast-path decision. Fast-path involves forwarding and policy decisions (which are not typically /32 decisions). >> >> It would be useful to say this information is useful so such routers can make the appropriate decision, but the path (fast or slow) is irrelevant IMO. > > Yes, fast-path is a forwarding issue, and I believe > the intent of this section was to mention that the > information returned by Leasequery is useful when > deciding to forward a packet -- and that Bulk Leasequery > gives you the information you need to decide to forward > or not in advance of seeing the packet (when it is too > late to deal with it in the fast path). > The issue is that fast-path contrasts to slow-path. Filtering is always fast-path where supported in the hardware, and slow-path where not. The point of the bulk leasequery is to allow forwarders to filter. *where* they filter is irrelevant, and not made slower or faster solely by whether the bulk leasequery is there. "fast path" isn't relevant to the issue. > I am not convinced that this should be changed. > > > Regards -- Kim > >> >>> ------------ >>> >>> Regards -- Kim >>> >>> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > From touch@isi.edu Fri Feb 24 16:34:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD57021E8013; Fri, 24 Feb 2012 16:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSsiBi8lmh4b; Fri, 24 Feb 2012 16:34:13 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2030A21F860B; Fri, 24 Feb 2012 16:34:03 -0800 (PST) Received: from [192.168.1.100] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1P0WuLm013869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2012 16:32:59 -0800 (PST) Message-ID: <4F482C39.9020909@isi.edu> Date: Fri, 24 Feb 2012 16:32:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ralph Droms References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, TSV Dir , dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:34:14 -0000 Hi, Ralph, On 2/18/2012 4:39 AM, Ralph Droms wrote: > Joe, Kim... > > On Feb 17, 2012, at 5:47 PM 2/17/12, Joe Touch wrote: > >> Hi, Kim, >> >> First, thank you for your detailed response to my quite lengthy review. >> >> Some further clarifications and confirmations appear below. >> >> Joe >> >> On 2/17/2012 12:09 PM, Kim Kinnear wrote: >>> >>> Joe, >>> >>> Thank you for your review. >>> >>> My responses are indented, below... >>> >>> On Feb 13, 2012, at 5:00 PM, Joe Touch wrote: >>> >>>> Hi, all, >>>> >>>> I've reviewed this document as part of the transport area >>>> directorate's ongoing effort to review key IETF documents. These >>>> comments were written primarily for the transport area directors, >>>> but are copied to the document's authors for their information and >>>> to allow them to address any issues raised. The authors should >>>> consider this review together with any other last-call comments >>>> they receive. Please always CC tsv-dir@ietf.org if you reply to or >>>> forward this review. >>>> >>>> This request was received Feb. 2, 2012. >>>> >>>> This document describes an extension to DHCPv4 for the bulk query >>>> andtransfer of current lease status over TCP. >>>> >>>> The following transport issues were noted, and are significant: >>>> >>>> UPDATES- The document updates DHCP with support for TCP, and as >>>> suchthis document seems like it should UPDATE RFC2131 >>> >>> While this document clearly builds on RFC 2131, it >>> doesn't actually change anything that anyone is doing >>> that is currently based on RFC 2131. My understanding of >>> "updates" is that, in order to understand the first RFC >>> (in this case, RFC 2131), you need to read all of the >>> RFC's that "update" it. That isn't the case here -- you >>> can be very happy reading and implementing DHCPv4 by >>> reading RFC 2131 and never have to know that DHCPv4 Bulk >>> Leasequery exists. In general, in the DHC WG, we seem to >>> set a pretty high bar for what "udpates" another RFC. I >>> don't see that this document has met those requirements. >>> But this isn't really my call. I'll let Ralph Droms and >>> the DHC WG chairs decide on this one, and I'll do >>> whatever they tell me to do. >> >> Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as >> per RFC 2131 is changed by this doc. If DHCP fundamentally starts >> requiring TCP port support, then this doc then changes the spec as >> described in 2131 IMO. > > Joe - I don't see that this document fundamentally requires TCP port > support for DHCP operation as described in RFC 2131. This document > describes a protocol that is closely related to but independent of RFC > 2131, and a server based on RFC 2131 can perform all the DHCP functions > in RFC 2131 without considering this document. So, I can see your point > but I disagree that this document updates RFC 2131. Fair enough, but then I'll put on my IANA hat and note that this then is no longer the complementary TCP protocol to DHCP. By your argument, it's a new service, and should have a separate TCP port and service name. Joe From touch@isi.edu Fri Feb 24 16:40:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBC521E8021; Fri, 24 Feb 2012 16:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.853 X-Spam-Level: X-Spam-Status: No, score=-102.853 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcVj9nZM402H; Fri, 24 Feb 2012 16:40:44 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3240121E8019; Fri, 24 Feb 2012 16:40:44 -0800 (PST) Received: from [192.168.1.100] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1P0ds7v016392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2012 16:39:57 -0800 (PST) Message-ID: <4F482DDC.1020509@isi.edu> Date: Fri, 24 Feb 2012 16:39:56 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , "" , TSV Dir , "" , Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:40:45 -0000 Hi, Ted, On 2/18/2012 7:29 AM, Ted Lemon wrote: > On Feb 17, 2012, at 5:47 PM, Joe Touch wrote: >> Thanks. In this case, it's important to suggest why others should not >> add conventional DHCP query support to the TCP port. > > The idea of doing DHCP stateful autoconfiguration over TCP is > nonsensical: DHCP clients start out with no IP address, so it is not > possible for them to do TCP. That's true for the initial request, but not for lease renewal. > The reason for sharing option codes is to avoid confusion: since > existing DHCPLEASEQUERY option codes come out of the same namespace as > DHCP options, Which doesn't need to happen if this is a completely different service... > if we were to propose that options in this documentation > come out of a different namespace, we would have to declare that new > namespace, which would have some options and option codes in common with > the existing namespace. This doesn't add value. It avoids misrepresenting this as related. > Historically, we have never said that when an option code is added, that > updates RFC2131 (really, it would make more sense to say it updated > RFC2132 if we were to go there, since RFC2132 is the document that > describes DHCP options). Fair enough - 2132. > So it would be surprising and unconventional if > this document were said to update either RFC2131 or RFC2132 simply > because it defined one or more new option codes. OK, so although I disagree that this is the correct procedure, if it's typical for DHCP then that's reasonable. Joe From Ted.Lemon@nominum.com Fri Feb 24 19:35:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742AF11E8073; Fri, 24 Feb 2012 19:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojokC7JmUG7v; Fri, 24 Feb 2012 19:35:07 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2209C21E8015; Fri, 24 Feb 2012 19:35:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT0hW6YBVohHNZ3S+MrbC484sSGsJcT8+@postini.com; Fri, 24 Feb 2012 19:35:06 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1CFED1B83F4; Fri, 24 Feb 2012 19:35:05 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 11B5119005D; Fri, 24 Feb 2012 19:35:05 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 24 Feb 2012 19:35:05 -0800 From: Ted Lemon To: Joe Touch Thread-Topic: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery Thread-Index: AQHM6qpvAqOZiGrj4kydaKDtgkZBbZZCENSAgAAsLgCAARgHAIAKB7wAgAAw7gA= Date: Sat, 25 Feb 2012 03:35:04 +0000 Message-ID: <9B0B764E-6619-41F5-BCEC-12CB5CC5570C@nominum.com> References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> <4F482DDC.1020509@isi.edu> In-Reply-To: <4F482DDC.1020509@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_9B0B764E661941F5BCEC12CB5CC5570Cnominumcom_" MIME-Version: 1.0 Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , "" , TSV Dir , "" , Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 03:35:08 -0000 --_000_9B0B764E661941F5BCEC12CB5CC5570Cnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Feb 24, 2012, at 7:39 PM, Joe Touch = > wrote: OK, so although I disagree that this is the correct procedure, if it's typi= cal for DHCP then that's reasonable. So just to be clear here, it seems that you are withdrawing your request th= at we create a new IANA registry and to say that this document updates RFC2= 131 or RFC2132, right? --_000_9B0B764E661941F5BCEC12CB5CC5570Cnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5DD14084ED08444C9C55DE9B0833BD60@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 24, 2012, at 7:39 PM, Joe Touch <touch@isi.edu> wrote:
O= K, so although I disagree that this is the correct procedure, if it's typical= for DHCP then that's reasonable.

So just to be clear here, it seems that you are withdrawing your reque= st that we create a new IANA registry and to say that this document updates= RFC2131 or RFC2132, right?

--_000_9B0B764E661941F5BCEC12CB5CC5570Cnominumcom_-- From touch@isi.edu Fri Feb 24 22:01:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CFC21F8533; Fri, 24 Feb 2012 22:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.835 X-Spam-Level: X-Spam-Status: No, score=-104.835 tagged_above=-999 required=5 tests=[AWL=1.764, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDeC68OTlqFZ; Fri, 24 Feb 2012 22:01:38 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4296021F8513; Fri, 24 Feb 2012 22:01:38 -0800 (PST) Received: from [192.168.1.100] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1P60rWQ013488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2012 22:01:02 -0800 (PST) Message-ID: <4F487915.2070002@isi.edu> Date: Fri, 24 Feb 2012 22:00:53 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4F3987F0.5050000@isi.edu> <4F3ED8FC.6020400@isi.edu> <4F482DDC.1020509@isi.edu> <9B0B764E-6619-41F5-BCEC-12CB5CC5570C@nominum.com> In-Reply-To: <9B0B764E-6619-41F5-BCEC-12CB5CC5570C@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF discussion list , "tsv-ads@tools.ietf.org" , "" , TSV Dir , "" , Kim Kinnear Subject: Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 06:01:39 -0000 On 2/24/2012 7:35 PM, Ted Lemon wrote: > On Feb 24, 2012, at 7:39 PM, Joe Touch > wrote: >> OK, so although I disagree that this is the correct procedure, if it's >> typical for DHCP then that's reasonable. > > So just to be clear here, it seems that you are withdrawing your request > that we create a new IANA registry and to say that this document updates > RFC2131 or RFC2132, right? I made an observation and a suggestion about those issues. They are not transport issues, so I consider them individual position only, and defer to the WG on how to proceed. Joe