Re: [dhcwg] RFC3315 DECLINE definition

Simon Hobson <linux@thehobsons.co.uk> Thu, 09 February 2017 16:46 UTC

Return-Path: <linux@thehobsons.co.uk>
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 3CC28129BA8 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 IbBlTBXDb6-T for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:46:26 -0800 (PST)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BB8129421 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 08:46:26 -0800 (PST)
X-Quarantine-ID: <jqAwuAykl-Fb>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...]
Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 41CF31A071 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 16:46:22 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com>
Date: Thu, 9 Feb 2017 16:46:21 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4F9FD26-ECE0-4FE8-AACD-ED0EA79BCC2D@thehobsons.co.uk>
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-81599408C8 F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com>
To: dhcwg <dhcwg@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/mx7zIQoIdRM5RgBRd-_WKGM4ER4>
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:46:28 -0000

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> wrote:

> 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.

And just how does the client differentiate between that being a deliberate policy choice by the admin (perhaps that location is not supposed to have outside IPv6 connectivity) and a server misconfiguration ?
Besides, just how is that different from other (eg DHCP4) setups ? If I configure the HCP server to give the wrong router address then clients get broken network configs.

At the end of the day, unless you are going to build an all-knowing, globe spanning, AI service that auto-configures everything - then you have to allow for admins to have some intelligence and some competency in their work. So far I've seen nothing in your suggestions that goes beyond "the admin may make a mistake and then things are broken". yes we can make mistakes - but finding and dealing them is part of the job.

So, other than "the admin may make a mistake", what use cases do you have ?



"Mudric, Dusan (Dusan)" <dmudric@avaya.com> wrote:

> The application does the semantic check for the address and, if the address is semantically correct, checks if the device using the offered address can be reached within the domain the in which device has to communicate. If, for example, the device has to be globally reachable, the address has to be an unreserved, or not deprecated, global address.

You have **NOT** described anything related to whether the address issued is usable at the network level, basically at the level DHCP is working at. By your own admission, the device **DOES** have a valid working address, but for some reason the **APPLICATION** cannot use it. The **APPLICATION** should report that there is a communications problem - this is how it works normally. The address may well be perfectly usable for other traffic.

Part of troubleshooting such an issue is to look at the network connectivity and the requirements of the application. This sounds very much like the refrain you hear from users who declare "the internet is down" because the web page they are trying to reach isn't working.