Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm

"Bernie Volz (volz)" <volz@cisco.com> Thu, 16 February 2012 03:29 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 F1A2121F856F for <dhcwg@ietfa.amsl.com>; 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 <dhcwg@ietfa.amsl.com>; 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 <dhcwg@ietf.org>; 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: <D9B5773329187548A0189ED6503667890AEA2AEC@XMB-RCD-101.cisco.com>
In-Reply-To: <CAByx+R0ua0D_o4CgDD21A-ZUJh2JQHqLYrW935s7tZnesmrzVA@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm
Thread-Index: AczsTh5w/jDKqkQmRUGXbqTC63DDVwAEy/fA
References: <CAByx+R0h5VFROEVfHG12eAN9gHefDp4P4yK_m=UNQSZ_R7YQcQ@mail.gmail.com><3044811E-D5D2-44D0-AFC4-DE1514CC6A38@iol.unh.edu> <CAByx+R0ua0D_o4CgDD21A-ZUJh2JQHqLYrW935s7tZnesmrzVA@mail.gmail.com>
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Huan Huan <shawngespan@gmail.com>, Timothy Winters <twinters@iol.unh.edu>
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: <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 03:29:52 -0000

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