IETF Logo Mail Archive

Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Thu, 09 February 2017 16:06 UTC

Return-Path: <dmudric@avaya.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 02C6A129B2E for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5WGOPWpjNHb for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:06:22 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257E7129B28 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 08:06:22 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2ESAQAGk5xY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxBBgWoHjVqSCpMngg+CDIYiAoJqPxgBAgEBAQEBAQEDXyiEaQEBAQEDEig/DAQCAQgNAQMEAQEBChQJBzIUCQgCBA4FCBqJUgGlJ40HJgKLJQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhiDMoIxBZtwAZxnhi+TEx85fk8VhHuCA3WHcgGBCwEBAQ
X-IPAS-Result: A2ESAQAGk5xY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxBBgWoHjVqSCpMngg+CDIYiAoJqPxgBAgEBAQEBAQEDXyiEaQEBAQEDEig/DAQCAQgNAQMEAQEBChQJBzIUCQgCBA4FCBqJUgGlJ40HJgKLJQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhiDMoIxBZtwAZxnhi+TEx85fk8VhHuCA3WHcgGBCwEBAQ
X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208";a="214672811"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Feb 2017 11:06:12 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:06:13 -0500
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:06:11 -0500
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ
Date: Thu, 09 Feb 2017 16:06:08 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com>
References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <fd3365190bd445b1ad00a7d8043530dd@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <C16D3614-AD9E-4AB3-915B-5288DB0EB239@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com>
In-Reply-To: <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.11.85.50]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/wj76-C3EIDdEVVlrob7zMwWav_I>
Cc: dhcwg <dhcwg@ietf.org>, Bernie Volz <volz@cisco.com>
Subject: Re: [dhcwg] RFC3315 DECLINE definition
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 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.

Regards,
Dusan.

-----Original Message-----
From: Ted Lemon [mailto:mellon@fugue.com] 
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?

v2.23.0 | Report a Bug | By Email