Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <> Thu, 09 February 2017 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02C6A129B2E for <>; Thu, 9 Feb 2017 08:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b5WGOPWpjNHb for <>; Thu, 9 Feb 2017 08:06:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 257E7129B28 for <>; Thu, 9 Feb 2017 08:06:22 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ESAQAGk5xY/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBgWoHjVqSCpMngg+CDIYiAoJqPxgBAgEBAQEBAQEDXyiEaQE?= =?us-ascii?q?BAQEDEig/DAQCAQgNAQMEAQEBChQJBzIUCQgCBA4FCBqJUgGlJ40HJgKLJQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhiDMoIxBZtwAZxnhi+TEx85fk8?= =?us-ascii?q?VhHuCA3WHcgGBCwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208";a="214672811"
Received: from unknown (HELO ([]) by with ESMTP; 09 Feb 2017 11:06:12 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:06:13 -0500
Received: from ([fe80::a5d3:ad50:5be9:1922]) by ([]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:06:11 -0500
From: "Mudric, Dusan (Dusan)" <>
To: Ted Lemon <>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Date: Thu, 9 Feb 2017 16:06:08 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: dhcwg <>, Bernie Volz <>
Subject: Re: [dhcwg] RFC3315 DECLINE definition
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Feb 2017 16:06:23 -0000

Let's say there is a deployment within an enterprise of 20 000 devices, each with DHCPv6 enabled. They are on different locations and use different DHCPv6 servers. One server is configured to statically assign IPv6 addresses (based on the client MAC) or with a pool of IPv6 addresses for the local link. If a client on that location assigns the misconfigured address it becomes unreachable. A user does not even know how to spell DHCPv6 and all he/she experiences is that the device is unusable. The network operator does not get any indication that the device is out of service.

If the client is able to tell the server that the address cannot be used, the administrator should be able to get some notification about the problem (e.g. an alarm), and find in the server log there was the configuration problem. The server might be able to automatically solve the issue. For example, the server can be configured with different address pools (e.g. using different address types) and the server can offer the address from a different address pool.


-----Original Message-----
From: Ted Lemon [] 
Sent: Thursday, February 09, 2017 10:48 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On 9 Feb 2017, at 10:46, Mudric, Dusan (Dusan) wrote:
> The first problem statement is about the server misconfiguration. 
> Instead of client silently ignoring the offered address, or even 
> worse, assigning the misconfigured address, the server (and
> administrator) should be informed about the misconfiguration.

How does this make things better?