Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm
"Bernie Volz (volz)" <volz@cisco.com> Thu, 16 February 2012 05:13 UTC
Return-Path: <volz@cisco.com>
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 <dhcwg@ietfa.amsl.com>; 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 <dhcwg@ietfa.amsl.com>; 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 <dhcwg@ietf.org>; 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: <D9B5773329187548A0189ED6503667890AEA2B1A@XMB-RCD-101.cisco.com>
In-Reply-To: <D0CF8F08-1A8F-4671-AE97-D4A8EEE23814@iol.unh.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm
Thread-Index: AczsZur1iI9DsMUFTcCY5z83kpMNswAAR+qQ
References: <CAByx+R0h5VFROEVfHG12eAN9gHefDp4P4yK_m=UNQSZ_R7YQcQ@mail.gmail.com><3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> <CAByx+R0ua0D_o4CgDD21A-ZUJh2JQHqLYrW935s7tZnesmrzVA@mail.gmail.com> <D9B5773329187548A0189ED6503667890AEA2AEC@XMB-RCD-101.cisco.com> <D0CF8F08-1A8F-4671-AE97-D4A8EEE23814@iol.unh.edu>
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Timothy Winters <twinters@iol.unh.edu>
X-OriginalArrivalTime: 16 Feb 2012 05:13:38.0815 (UTC) FILETIME=[BDDF48F0:01CCEC69]
Cc: dhcwg@ietf.org, Huan Huan <shawngespan@gmail.com>
Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 05:13:45 -0000
> 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 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.) > 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, 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 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.) - 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="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.t xt 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.tx t ------------------------------ 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 -- Huan Huan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Timothy Winters
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Huan Huan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Huan Huan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Bernie Volz (volz)
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Timothy Winters
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Bernie Volz (volz)
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Huan Huan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Ole Trøan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Bernie Volz (volz)
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Ole Trøan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Jean-Francois.TremblayING
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Bernie Volz (volz)
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Ole Trøan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Huan Huan
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Ted Lemon
- Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm Bernie Volz (volz)
- [dhcwg] 答复: Re: dhcwg Digest, DHCP Renew vs Confi… shawngespan
- Re: [dhcwg] 答复: Re: dhcwg Digest, DHCP Renew vs C… Ted Lemon