[dhcwg] DHCPv4 INFORM Refresh Time Option

"Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com> Mon, 10 September 2012 01:43 UTC

Return-Path: <ghalwasi@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 800DC21F84E4 for <dhcwg@ietfa.amsl.com>; Sun, 9 Sep 2012 18:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.489
X-Spam-Level:
X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGXZUEAst4Ku for <dhcwg@ietfa.amsl.com>; Sun, 9 Sep 2012 18:43:18 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F56C21F84D7 for <dhcwg@ietf.org>; Sun, 9 Sep 2012 18:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1154; q=dns/txt; s=iport; t=1347241397; x=1348450997; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=3rcEFpWL5EMLJ1+M8NUDR0+0qybfIyTJorhVDaPutC8=; b=JGRIeqfqs05JU7kyUzZP/yNxhiOrE9V/8m3NEMeo0zUnHn9NOnm1AJUc oEM2/JzOlavE7uaz0zC4hqZEFd/kmd7fAMplvW6eZIfAdnFfQRhYQYFOb cLR97U3TrL5NpYVkpcSpnG6mx9NXJWplSHYVA77GPiv/o5cNpRMHfOdlB w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFABNFTVCtJV2d/2dsb2JhbABFhUBHtEx8gQeCIgEEEgEQEVcBIgIGIAIEMBURAQQbARmHbguZVIEojRmSA4EhjxYyYAOkE4FngmY
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="119858980"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2012 01:43:17 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8A1hGV5028969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dhcwg@ietf.org>; Mon, 10 Sep 2012 01:43:16 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Sun, 9 Sep 2012 20:43:16 -0500
From: "Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: DHCPv4 INFORM Refresh Time Option
Thread-Index: Ac2O9aIJmSIHA7SwRXiFsB02PKBpNA==
Date: Mon, 10 Sep 2012 01:43:15 +0000
Message-ID: <90903C21C73202418A48BFBE80AEE5EB102CE5@xmb-aln-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.70.241]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19172.004
x-tm-as-result: No--28.338200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [dhcwg] DHCPv4 INFORM Refresh Time Option
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: Mon, 10 Sep 2012 01:43:19 -0000

Hi Team,

We have submitted a new I-D for including Refresh Time option in INFORM message, similar to what DHCPv6 has.

The draft is available at:
http://www.ietf.org/internet-drafts/draft-halwasia-dhc-inform-refresh-time-opt-00.txt

Abstract:
   This document describes a Dynamic Host Configuration Protocol for
   IPv4 (DHCPv4) [RFC2131] option for specifying an upper bound for how
   long a client should wait before refreshing information retrieved
   from DHCPv4 Server by using DHCP INFORM message.  It is used with
   stateless DHCPv4 as there are no addresses or other entities with
   lifetimes that can tell the client when to contact the DHCPv4 server
   to refresh its configuration.

Appreciate your comments and suggestions.   We are also looking to have the WG take this on as a work item.

Thanks,
Gaurav