dhcp-users RFC3315 DECLINE definition

Mudric, Dusan (Dusan) dmudric at avaya.com
Sat Feb 18 00:25:21 UTC 2017


>From: Ted Lemon <ted.lemon at nominum.com>
>> I am trying to find a way to detect which devices are using "invalid" or "unreachable" or "not-working" IPv6 addresses.
>
>But they are using the address either because they got an RA that advertised the prefix they used to generate the >address, or because a DHCP server gave it to them.   In either case, the problem can be addressed by fixing the DHCP >server or the router.  And it would be really surprising for a router to advertise an invalid prefix.   Furthermore, tracking >this stuff down with regular network management tools isn't difficult.   So it's difficult to understand why you would >want to involve the DHCP server or client in this process.

It is more about assigning IPv6 address over DHCPv6 and the address prefix does not match the router prefix. For example DHCPv6 server can be configured to assign a specific IPv6 address to a client. If the address does not match the routing prefix on the link, the client becomes unreachable. I saw this happening.

In order to fix the problem, an operator first needs to find the problem. If the client is intelligent enough to tell the server what the problem is about, it becomes easy for the operator to fix the problem by reconfiguring the server. Without this mechanism everybody is lost: a user does not know why his device does not work, an operator does not know how to help the user. I saw this happening.

So, a protocol X, performing operation Y, is responsible to evaluate the operation it does. DHCPv6, assigning addresses, is responsible to evaluate address assignments. Benefits are clear.

>From: Simon Hobson <simon at thehobsons.co.uk>
>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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
>> ml_rfc4291-23section-2D2.5&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9c
>> bLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=d0l8zwxb0943rX-9bzDKE8RLjbQ5JG1
>> WTnEWMdEe_3c&s=RtVC26XGpwXc1Q1ilsVK22V-FDp7N-LFEC_2Ctlnqic&e=
>
>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).

This is not the point. It is not about finding the router problem. It is about finding a client that becomes unreachable and the reason why. 

>> 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iana.org_assignments_ipv6-2Dunicast-2Daddress->2Dassignments_ipv6-2Dunicast-2Daddress->2Dassignments.xhtml&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2k>Y&m=d0l8zwxb0943rX-9bzDKE8RLjbQ5JG1WTnEWMdEe_3c&s=sqjpDUJQE1gLGLqjtE4MH_TKhnxKQfJtsXT3bJRVpl4&e=
>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"

If you are looking only for the ways to misconfigure proposed options, I agree, you will always find a way to do it. With that approach, you can also find quite a few areas where you will break DHCPv6. This is still not the reason not to use DHCPv6. From my perspective, I am looking for the improvements only.

This is about the intelligent device helping identify which address is not useable for a device or application operation. As you can see, I did not list quite a few address types that some applications would never use. It is to the operators discretion to configure the address list. It would be unwise to allow to assign a multicast address to a device, or LL if the devices has to be globally reachable (device would already have one LL and does not need another one). That is why I gave examples above.


More information about the dhcp-users mailing list