dhcp-users Digest, Vol 100, Issue 8

Mudric, Dusan (Dusan) dmudric at avaya.com
Tue Feb 14 15:46:40 UTC 2017

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


-----Original Message-----
From: dhcp-users [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of dhcp-users-request at lists.isc.org
Sent: Tuesday, February 14, 2017 7:00 AM
To: dhcp-users at lists.isc.org
Subject: dhcp-users Digest, Vol 100, Issue 8

Send dhcp-users mailing list submissions to
	dhcp-users at lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
	dhcp-users-request at lists.isc.org

You can reach the person managing the list at
	dhcp-users-owner at lists.isc.org

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 <dhcp1 at thehobsons.co.uk>
To: "dhcp-users at lists.isc.org ISC DHCP" <dhcp-users at lists.isc.org>
Subject: Re: [dhcwg] RFC3315 DECLINE definition
Message-ID: <C72D66A0-3D3F-4FD8-82BF-1371C6620AB5 at thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii

On 13 Feb 2017, at 21:26, "Mudric, Dusan (Dusan)" <dmudric at avaya.com> 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 <dhcp1 at thehobsons.co.uk>
To: dhcp-users at lists.isc.org
Subject: Re: [dhcwg] RFC3315 DECLINE definition
Message-ID: <4F03BB89-82B3-4146-A00C-B1096E02CB33 at thehobsons.co.uk>
Content-Type: text/plain; charset=KS_C_5601-1987

???(Network Innovation Projec) <utae.kim at kt.com> 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
dhcp-users at lists.isc.org


End of dhcp-users Digest, Vol 100, Issue 8

More information about the dhcp-users mailing list