RE: dhcp-users Digest, Vol 100, Issue 8

[Mudric, Dusan (Dusan)]

I am trying to find a way to detect which devices are using "invalid" or "unreachable" or "not-working" IPv6 addresses. Since DHCPv6 client sends messages to DHCPv6 server with the Client Identifier that has MAC address, and can send the list of addresses that it needs to RELEASE, the server can know which devices (MACs) use 'invalid' or 'unreachable' addresses. I believe this can be helpful for DHCPv6 users.

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

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.

I expect there will be other use cases where IPv6 address becomes "unreachable". From DHCPv6 client perspective, it is only important to be able to convey that information to DHCPv6 server.

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

Open for further suggestions.

Regards,
Dusan.

-----Original Message-----
From: dhcp-users [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, February 14, 2017 7:00 AM
To: [hidden email]
Subject: dhcp-users Digest, Vol 100, Issue 8

Send dhcp-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.isc.org_mailman_listinfo_dhcp-2Dusers&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=8f7FPYbWLdzj657tbAb0dUjXjTbaaeeUltB5xeU7CyA&s=GDrr2pUxe9nqGKxWDQGUPAOL55_RWu6UlO_nPqNeZiE&e=
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcp-users digest..."


Today's Topics:

   1. Re: [dhcwg] RFC3315 DECLINE definition (Simon Hobson)
   2. Re: [dhcwg] RFC3315 DECLINE definition (Simon Hobson)


----------------------------------------------------------------------

Message: 1
Date: Mon, 13 Feb 2017 21:42:15 +0000
From: Simon Hobson <[hidden email]>
To: "[hidden email] ISC DHCP" <[hidden email]>
Subject: Re: [dhcwg] RFC3315 DECLINE definition
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii


On 13 Feb 2017, at 21:26, "Mudric, Dusan (Dusan)" <[hidden email]> wrote:

> Anyone else that would benefit from a list of devices (their MAC addresses) with assigned IPv6 addresses that are not valid or are unreachable?

Dropping the DHCWG list ...

As before, define "not valid" and "unreachable".
As do you want a list of devices with those addresses, or a list of devices with those address which don't also have a "working"* address ?

* For whatever definition of working you come up with.



------------------------------

Message: 2
Date: Tue, 14 Feb 2017 08:00:10 +0000
From: Simon Hobson <[hidden email]>
To: [hidden email]
Subject: Re: [dhcwg] RFC3315 DECLINE definition
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=KS_C_5601-1987

???(Network Innovation Projec) <[hidden email]> wrote:

> I think IPv6 is co-existed with IPv4 for a while.
> Devices have dual stack with IPv4 and IPv6 address.
> And there are cases that traces the problem with IPv4 & IPv6 address information.
> But, now there have no common key between them.
> So, I think IPv6 information is included with device mac address for tracing IPv4.

If I understand you correctly, you are describing a completely separate issue - that of identifying the MAC-IP pairing for IPv6 because your IPv4 workflow is based on that.
That too has been done to death in the DHC WG list - to the extent that (IIRC) there is now a MAC address option defined that clients may send, or was it that relay agents could add ? I think it might have been the latter since it's easier to upgrade a few relay agents rather than every client.
For devices not using a relay agent, the MAC address is in the packet.
Also, there's been quite firm statements that the wording of the RFCs that prohibits "looking inside" the client identifier does not in fact prohibit that, although since on a multi-homed device that may not be based on the same interface, it's not necessarily all that useful anyway.

------------------------------

Subject: Digest Footer

_______________________________________________
dhcp-users mailing list
[hidden email]
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.isc.org_mailman_listinfo_dhcp-2Dusers&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=8f7FPYbWLdzj657tbAb0dUjXjTbaaeeUltB5xeU7CyA&s=GDrr2pUxe9nqGKxWDQGUPAOL55_RWu6UlO_nPqNeZiE&e= 

------------------------------

End of dhcp-users Digest, Vol 100, Issue 8
******************************************
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ted Lemon]

On Feb 14, 2017, at 10:46 AM, Mudric, Dusan (Dusan) <[hidden email]> wrote:

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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson-2]

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)" <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mudric, Dusan (Dusan)]

>From: Ted Lemon <[hidden email]>
>> 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 <[hidden email]>
>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)" <[hidden email]> 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.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

"Mudric, Dusan (Dusan)" <[hidden email]> wrote:

> Benefits are clear.

It would appear that you are in a inority of one on that.

>> 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 ONLY reasons you have come up with are :
1) A router goes away - so it **IS** about finding the router problem and network monitoring tools will do that for you.
2) The admin misconfigured the network - and as has already been said, checking/testing your config after config changes is part of the admin's role. As an admin, I can tell you that having tools that try and second guess what you are trying to do and complain about stuff you know is actually what you want to do is a real PITA, more so than not spotting errors.

Example - at one time, some Netgear routers would not accept any address ending in .0 as bing a valid address - this was for setting the addresses from which admin was allowed. Once you get to a network of at least /23 size, then that test is simply not valid, and for networks smaller than /24, then other addresses are (in theory) not valid.
But the router CANNOT know anything about those other addresses - so the test was meaningless, but simply got in the way of valid configs.


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

I think you've just proved my point there.
If the admin has to configure the client with a list of what is considered "valid" (for whatever definition of valid is decided on) then what's the point ? You have a catch 22 where you have to configure the client before you can automatically configure the client. If the defaults change (a prefix is brought into use or deprecated) then you really can get a situation where a device cannot be configured before it's been configured.
And that's leaving aside the "creative" way vendors can find to interpret standards !

By way of example, many years ago I had a printer that just wouldn't configure via DHCP. I checked and checked, but it just wouldn't accept a lease. In the end I had to manually configure it - so that a nuisance having to manually configure it, and an ongoing management issue in that it needs further manual intervention if the network changes (and that network did get renumbered).
Some time later, quite by accident while I was looking for something else, I found a comment to the effect that it would only accept a lease with a lease time over 2 years - I bet someone somewhere had a burning sensation in his ears as I questioned his (or her) parentage.

I don't want random problems like that - and you are proposing to build into the standard that the client, in the absence of any knowledge about what the admin intends, makes decisions about what it acceptable.


And you have still not defined what is considered acceptable. Forget the wooly talk of "unroutable" - you need to come up with an exact specification that says : apply test X where X is a clearly defined set of conditions.


And, you are concentrating on "when a client gets an address". So what if the router is there, and is advertising a prefix, AT THE TIME THE CLIENT IS CONFIGURED ? It'll accept the address.
The router now goes away - now what ? The time for sending a DHCP Decline message is long gone - it could have been weeks ago. So your proposal does nothing UNLESS at least one client tried to get/renew a lease during the time that router is down. So as a means of alerting to the router going down, on a stable network it has "limited" use - it could be hours or even days before it gets reported.
Network monitoring tools are there for that - and will report in whatever timescale the tool has been configured to act.

You also haven't addressed the case of the router being required in order to get requests to the server. So router down, client tried to get an address, but can't. Client is just as unreachable as in your scenarios, but cannot report anything. Again, properly setup networking tools will.


And (from memory) you also haven't said what the server should do with this information other than just logging it (something I'd just redirect to /dev/null). Should it flag the address as "unusable" so it doesn't get handed out to the next client asking for an address ? If so, then a temporary router issue could well poison the address pool, requiring manual cleanup, and until cleaned up, promoting more client address churn (that's what happens when the ISC DHCP4 server gets a reply when it does it's "ping before offer" check).

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Ted Lemon]

On Feb 17, 2017, at 7:25 PM, Mudric, Dusan (Dusan) <[hidden email]> wrote:

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.

This is most likely a situation where you should not be using DHCPv6 for address assignment.

If you want signaling for this particular problem, why do you want it in the client?   It makes more sense to put it in the relay agent.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users