dhcp-users RFC3315 DECLINE definition

[Simon Hobson]

FFS, please learn how to quote properly and trim properly. Also, don't leave the subject line as "Digest ..." - FIX IT.


On 14 Feb 2017, at 15:46, "Mudric, Dusan (Dusan)" <dmudric at avaya.com> wrote:

> Let's define "invalid", "unreachable" and "not-working" addresses.
> 
> - "Invalid" address is one that cannot pass the semantic check, or a deprecated address (e.g.	Site-Local Unicast Address (FEC0::/10))
> 
> - "Unreachable" address, IPv6_UNCREACHABLE, is the one that cannot be reached by another host. For example, when a host H1 on the same link needs to reach host H2 that was assigned IPv6 address via DHCPv6 client, that address becomes IPv6_UNCREACHABLE when a router (R1) removes the prefix used by that address. H1 does not have the prefix any more, thinks H2 is not the neighbor, and sends a packet to a router R1. A router does not forward the packet to H2.
> https://tools.ietf.org/html/rfc4291#section-2.5

There's more to "is this host reachable" that just that.

Also, in a situation where the router disappears, then the last thing I'd want as the network admin is a flood of completely unnecessary and irrelevant warnings. The network management/monitoring systems will tell me that the router is down - one message, with a meaningful content.

Analogy:
If you are travelling, would you rather have ONE alert telling you that "road X is closed due to an accident", or several thousand messages from various cars telling you that "we can't get anywhere".

Put another way, this bit of the proposal is actually counter productive in any well managed network.


>   "A slightly sophisticated host (but still rather simple) may
>   additionally be aware of subnet prefix(es) for the link(s) it is
>   attached to"
> If H2 is the host of this kind, it can find the address has the prefix that is removed, and can know that it became unreachable. H2 can report that to DHCPv6 server saying I (my MAC) now have IPv6_UNCREACHABLE address.

As above, you do **NOT** want that. Your network monitoring will tell you *ONCE* that the router is down, that is far more useful than flooding your ticketing system with thousands of alerts which **CANNOT** tell you that the router is down (there may be another reason).

> The address can be globally unreachable. For example, if DHCPv6 client assigns:
> -	Unspecified (::/128)
> -	Loopback (::1/128)
> -	LL (fe80::/10)
> -	Multicast (FF00::/8)
> -	Unique Local Address, ULA (FC00::/7) (
> a host becomes globally unreachable. The host can be slightly sophisticated and detect it. The host can send a message to DHCPv6 server and report this case.

OK, see http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
Do you propose to accept only those prefixes that are currently allocated ? If so, then you **MUST** also expect **ALL** clients to get upgraded **EVERY** time that list changes. I can tell you that it's bad enough managing IT kit that's been abandoned by the vendor and things have moved on - a favourite trick is having an UI that uses Java, but current implementations simply refuse to run the old code. Having "older" kit simply refuse to work on the network because the manufacturer has stopped updating the client with new prefixes isn't my idea of "progress" !

If you are going to accept all prefixes, then there's an awful lot of address space that's currently unallocated (and hence addresses that "don't work"*).

* To some level of "doesn't work"


> Both "invalid" or "unreachable" addresses will make the client "not-working".

WRONG
It **MAY** make the client "not working", and that may or may not be significant.

For example, in a situation where there is more than one router capable of handling traffic to "the internet", and one fails, then losing addresses on one prefix because a router is down does not prevent the client working. There may be operational issues - eg inbound connections to certain addresses will fail.

If there is only one router, and that fails, then really I just don't GAS whether the clients now have globally unreachable addresses. The router is down, connectivity is down, I don't want thousands of alerts getting in the way of dealing with it.


There are good reasons for NOT creating a flood of alerts for a simple event. It's well known by those in the business of designing safety critical systems that overloading the operators is a serious problem. In fact, there have been some serious accidents over the years where a simple fault has led to a flood of alerts that's overwhelmed the operators such that they then couldn't see what the simple problem was.

It isn't the one I was looking for, but I quickly came across this :
http://www.conyte.cl/archivos/LONGFORD_BFMA_2006b.pdf
> Ignoring alarms
> Whenever something went wrong in the Longford plant, an alarm would sound. In the case of one incident Esso investigators found that there were an average of 12 alarms every minute during a 12-hour shift. With so many alarms going off, they were ignored.

Put simply, you are proposing a system that will generate a LOT of alerts - that will be simply ignored. If I had clients designed to generate all those alerts every time a router went offline, then I;d quickly filter them out altogether. Thus, your proposal does nothing positive, but creates a new workload in eliminating the messages you are keen to generate.