Re: [dhcwg] RFC3315 DECLINE definition

Simon Hobson <dhcp1@thehobsons.co.uk> Mon, 13 February 2017 14:57 UTC

Return-Path: <dhcp1@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 BD244129698 for <dhcwg@ietfa.amsl.com>; Mon, 13 Feb 2017 06:57:26 -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 AOtMfhxjhaXU for <dhcwg@ietfa.amsl.com>; Mon, 13 Feb 2017 06:57:24 -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 664071295B2 for <dhcwg@ietf.org>; Mon, 13 Feb 2017 06:57:24 -0800 (PST)
X-Quarantine-ID: <9OcAHIiNVQx9>
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 8CE701BC91 for <dhcwg@ietf.org>; Mon, 13 Feb 2017 14:57:18 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson <dhcp1@thehobsons.co.uk>
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com>
Date: Mon, 13 Feb 2017 14:57:17 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <C51D2F05-A721-4629-844C-4B6227F138A0@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> <9142206A0C5BF24CB22755C8EC422E457A A189F9@AZ-US1EXMB03.global.avaya.com> <A3AFA8FF-FDEF-4058-814A-E687D5CC2969@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <A023117A-2B06-4660-88B9-9AB183F05B66@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <B2511278-5D7A-40E0-AC4A-60784C101A80@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <CAL10_BqFTSbhe6krvTUz1VnLw0pQGodPRrt8c39sNcMhRUqvQw@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <CAL10_BorkqQXZUOFWarj_+275u1z9L9Xtkse=RQjGnOeFveNJg@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> <CAL10_Bpy+4Eb4wUwuy5YkKaOO+69o0Ombej7n_ApCg1Gw-r0QQ@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457AA1924E@AZ-US1EXMB03.global.avaya.com> <CAL10_Bpb2eXAmnAnGpAeURMuqxBE=G+zYN+n 1b1xk0qamtaU+Q@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457AA194E5@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/MCg7dZw9GwFnjwZNNusZ9tU9SUI>
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: Mon, 13 Feb 2017 14:57:27 -0000

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

> PROBLEM STATEMENTS:
> - A network operator can set client IPv6 addresses on DHCPv6 server.

That is the primary function of the DHCP server ! I don't see that as a problem.

> An address can be invalid or make a client unreachable.

There are a lot of other ways to bo**ox up a network !
Such configurations may be deliberate. Until recently I did in fact run a network with unroutable (as in valid IP, but no router for that subnet) addresses because there was a policy decision that this particular network would be isolated - it was a backend network to carry traffic independently of the traffic on the public facing front end network.

> - A network operator can change an address prefix on a router. A client address can become unreachable

Ditto.
This is simply failing to co-ordinate network changes. Before removing/changing the prefix, the DHCP admin should have removed the pool IFF it is desired that the addresses be usable for external connectivity. As previously mentioned, this may be deliberate on the part of the Admin.

> - A default router offering a prefix to a client can become unreachable.

"Sh*t happens". Not only that, but what happens if the server hands out a load of IPv6 addresses which are all valid AT THE TIME OF ALLOCATION ? Even if your proposal were implemented, these addresses would be accepted and configured because they would be valid AT THE TIME OF ALLOCATION. The DHCP server and client cannot do anything about it if, say, 5 seconds into a 60 day lease, a router stops advertising a prefix appropriate to that address.

It would be for the OS to detect that situation, and simply stop using that address for outbound connections. IMO it would be inappropriate for all the clients to somehow tell the server that all these addresses are bad - only to have 20,000 clients all contact the server again a few minutes later when the router comes back up and the prefix becomes valid again. That would be designing in network instability.

> A client address can become unreachable on a local link 

?

> - A client does not release unused addresses

So ? There's 2^64 addresses in a minimal IPv6 prefix. How many billion addresses do you intend using for each client ? Even if your 20,000 clients all took and held onto 1000 addresses each, that's still a tiny tiny fraction of the available addresses.



> - A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems

HOW ?
You will need to define the algorithm for validating addresses. So far you've only come up with "isn't on any prefix advertised by a router" (as above, not a valid test) and "in a deprecated prefix" (as mentioned in an earlier message, not a valid test).

You will also need to define a mechanism whereby all clients can have the algorithm updated as policies change - eg prefixes get deprecated (as previously discussed), new prefixes come into use (eg I assume you would expect currently unused prefixes to be rejected, but they could come into use at any time when it's considered that they are needed).
You will also need to define a mechanism for the local admins to over-ride the stock algorithm - eg where the admins have made a policy decision to run isolated networks. This introduces a catch-22 situation where new devices might not be configurable (they won't attach to the network) until they have been configured (policy edited to allow them to connect).

This is critical to your proposal - until you can come up with an easily defined, and robust, algorithm then your proposal CANNOT work. Worse, it may cause far more problems than it is supposed to solve.


> - A client returns unused addresses
> - DHCPv6 server:
>  -- logs error messages (invalid & unreachable addresses with device IDs)
>  -- does not assign the invalid addresses
>  -- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again

Define "valid" and "reachable" here ?
The implication from this and your earlier emails is that you define "reachable" as "has an IP which is routable to/from 'the internet'". See my comment above about running isolated networks, that backend isolated network runs a DHCP service - so the addresses on it are "reachable" in terms of "the DHCP server can reach them", but they aren't globally routable (they are actually RFC1918 IPv4 addresses, but the argument stands).
With a previous hat on, I had 2 Class C public IPv4 allocations which weren't globally routable.

There is also the issue that the server (in the general case) CANNOT determine the reachability/routability of any prefix. There are plenty of network topologies where the server may lose connectivity to "something" while clients don't, or vice-versa, while connectivity between server and client network is still working. Similarly, there are topologies while server-client comms could be lost, while both still have connectivity to "something". This is the reason that, out of the box, DHCP4 servers in failover do NOT automatically go into partner-down state when they lose connectivity between them.

> - An operator
> -- checks if there are unreachable devices and the reason codes

An alternative: The site/organisation admins take care to co-ordinate changes, and test changes in configuration. They should employ monitoring to detect issues, and respond appropriately to helpdesk tickets.
Configuration management (and especially automation) will detect many of the issues you've raised.