Solved - Identifying IPv6 devices with DHCP leases

stan-qaz · Apr 5, 2018, 7:43 AM

I have several devices showing up in my IP v6 DHCP leases table that I'm having a hard time identifying. None show a MAC but do have DUIDs and IAIDs, is there some method I'm missing to figure out what these devices are?

I've tried nmap and looking to see if the DUID matches a MAC I know but neither seems to help.

![dhcp6 leases.png](/public/imported_attachments/1/dhcp6 leases.png)
![dhcp6 leases.png_thumb](/public/imported_attachments/1/dhcp6 leases.png_thumb)

NogBadTheBad · Apr 1, 2018, 10:09 PM

Look at the last couple of the DUID octets then look at your IPv4 leases and their MAC addresses.

https://en.m.wikipedia.org/wiki/DHCPv6

Maybe do a packet capture and examine it with wireshark.

MikeV7896 · Apr 2, 2018, 12:34 AM

The IPv6 address ending in ::17f1 you won't be able to use NogBadTheBad's tip for… that DUID appears to not be related to the MAC address. The one ending in ::1778 might also not be related to a MAC address.

What I would do is go to Diagnostics > Ping and ping those addresses... that should get them added to the NDP table, assuming you got ping replies, then you can go back to the DHCPv6 leases and hopefully MAC addresses will show for them now.

stan-qaz · Apr 2, 2018, 4:09 AM

I've tried to force a response from these hosts using nmap and get nowhere, ping6 gets no response either. The nmap OS guess is likely wrong as we have no Apple gear here.

These devices are not showing up in the NDP table or in the pfSense DHCP log either.

dell-3620:/home/stan # nmap -d -Pn -A -6 2600:8800:2d82:b01::2000
Starting Nmap 7.70 ( https://nmap.org ) at 2018-04-01 20:35 MST
PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0)
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
NSE: Using Lua 5.3.
NSE: Arguments from CLI: 
NSE: Loaded 148 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 20:35
Completed NSE at 20:35, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 20:35
Completed NSE at 20:35, 0.00s elapsed
mass_rdns: Using DNS server 172.16.0.1
mass_rdns: Using DNS server 2600:8800:2d82:b00:208:a2ff:fe0a:6b62
Initiating Parallel DNS resolution of 1 host. at 20:35
mass_rdns: 0.07s 0/1 [#: 2, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1]
Completed Parallel DNS resolution of 1 host. at 20:35, 0.07s elapsed
DNS resolution of 1 IPs took 0.07s. Mode: Async [#: 2, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating SYN Stealth Scan at 20:35
Scanning 2600:8800:2d82:b01::2000 [1000 ports]
Packet capture filter (device eth0): dst host 2600:8800:2d82:b00:1a66:daff:fe29:6fd0 and (icmp or icmp6 or ((tcp or udp or sctp) and (src host 2600:8800:2d82:b01::2000)))
Completed SYN Stealth Scan at 20:36, 12.36s elapsed (1000 total ports)
Overall sending rates: 161.47 packets / s, 10333.82 bytes / s.
Initiating Service scan at 20:36
Starting IPv6 OS Scan...
[FPEngine] Interface=eth0 BPF:dst host 2600:8800:2d82:b00:1a66:daff:fe29:6fd0 and (src host 2600:8800:2d82:b01::2000)
Novelty of closest match is 36.573 > 15.000; ignoring.
IPv6 OS Scan completed.
Packet capture filter (device eth0): (ip or ip6) and dst host 2600:8800:2d82:b00:1a66:daff:fe29:6fd0                                           
Initiating Traceroute at 20:36                                                                                                                 
Completed Traceroute at 20:36, 9.07s elapsed                                                                                                   
Initiating Parallel DNS resolution of 1 host. at 20:36                                                                                         
mass_rdns: 0.00s 0/1 [#: 2, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1]                                                                                 
Completed Parallel DNS resolution of 1 host. at 20:36, 0.00s elapsed                                                                           
DNS resolution of 1 IPs took 0.00s. Mode: Async [#: 2, OK: 1, NX: 0, DR: 0, SF: 0, TR: 1, CN: 0]                                               
NSE: Script scanning 2600:8800:2d82:b01::2000.                                                                                                 
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 20:36
NSE: Starting address-info against 2600:8800:2d82:b01::2000.
NSE: Finished address-info against 2600:8800:2d82:b01::2000.
NSE: Starting ipv6-node-info against 2600:8800:2d82:b01::2000.
NSE: Finished ipv6-node-info against 2600:8800:2d82:b01::2000.
Completed NSE at 20:36, 2.39s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 20:36
Completed NSE at 20:36, 0.00s elapsed
Nmap scan report for 2600:8800:2d82:b01::2000
Host is up, received user-set (0.068s latency).
All 1000 scanned ports on 2600:8800:2d82:b01::2000 are filtered because of 996 no-responses and 4 host-unreaches
Device type: general purpose|phone
Running (JUST GUESSING): Apple Mac OS X 10.6.X|10.7.X (71%), Apple iOS 4.X (71%)
OS CPE: cpe:/o:apple:mac_os_x:10.6.8 cpe:/o:apple:mac_os_x:10.7 cpe:/o:apple:ios:4.3.3
OS fingerprint not ideal because: Missing a closed or open TCP port so results incomplete
No OS matches for host
TCP/IP fingerprint:
SCAN(V=7.70%E=6%D=4/1%OT=%CT=%CU=%PV=N%G=N%TM=5AC1A546%P=x86_64-redhat-linux-gnu)
EXTRA(FL=12345)

TRACEROUTE (using proto 58/ipv6-icmp)
HOP RTT        ADDRESS
1   0.16 ms    pfSense.home (2600:8800:2d82:b00:208:a2ff:fe0a:6b62)
2   ...
3   ...
4   ...
5   ...
6   ...
7   ...
8   ...
9   ...
10  ...
11  996.47 ms  pfSense.home (2600:8800:2d82:b00:208:a2ff:fe0a:6b62)
12  ...
13  ...
14  ...
15  ...
16  ...
17  ...
18  ...
19  ...
20  ...
21  998.97 ms  pfSense.home (2600:8800:2d82:b00:208:a2ff:fe0a:6b62)
22  ...
23  ...
24  ...
25  ...
26  ...
27  ...
28  ...
29  ...
30  1008.27 ms pfSense.home (2600:8800:2d82:b00:208:a2ff:fe0a:6b62)
Final times for host: srtt: 67603 rttvar: 41268  to: 232675

NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 20:36
Completed NSE at 20:36, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 20:36
Completed NSE at 20:36, 0.00s elapsed
Read from /usr/bin/../share/nmap: nmap-payloads nmap-protocols nmap-service-probes nmap-services.
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 42.74 seconds
           Raw packets sent: 2105 (135.808KB) | Rcvd: 11 (1.057KB)

Looking at the DUIDs and trying to decode them isn't helping much either, as they appear to be types 2 and 4.

Type 2 – https://tools.ietf.org/html/rfc3315#page-19

9.3\. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]

   This form of DUID is assigned by the vendor to the device.  It
   consists of the vendor's registered Private Enterprise Number as
   maintained by IANA [6] followed by a unique identifier assigned by
   the vendor.  The following diagram summarizes the structure of a
   DUID-EN:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               2               |       enterprise-number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   enterprise-number (contd)   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    .                           identifier                          .
    .                       (variable length)                       .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The source of the identifier is left up to the vendor defining it,
   but each identifier part of each DUID-EN MUST be unique to the device
   that is using it, and MUST be assigned to the device at the time it
   is manufactured and stored in some form of non-volatile storage.  The
   generated DUID SHOULD be recorded in non-erasable storage.  The
   enterprise-number is the vendor's registered Private Enterprise
   Number as maintained by IANA [6].  The enterprise-number is stored as
   an unsigned 32 bit number.

   An example DUID of this type might look like this:

    +---+---+---+---+---+---+---+---+
    | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
    +---+---+---+---+---+---+---+---+
    |132|221| 3 | 0 | 9 | 18|
    +---+---+---+---+---+---+

   This example includes the two-octet type of 2, the Enterprise Number
   (9), followed by eight octets of identifier data
   (0x0CC084D303000912).

Enterprise ID nNumber – https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

ab:11 hex is 43793

PRIVATE ENTERPRISE NUMBERS

(last updated 2018-04-02)

SMI Network Management Private Enterprise Codes:

Prefix: iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)

This file is http://www.iana.org/assignments/enterprise-numbers

Decimal
| Organization
| | Contact
| | | Email
| | | |
0
  Reserved
    Internet Assigned Numbers Authority
      iana&iana.org

 <snip>43793
  Tom Gundersen (systemd)
    Tom Gundersen
      teg&jklm.no</snip>

Type 4 == https://tools.ietf.org/html/rfc6355#section-4

4.  DUID-UUID Format

   The DUID-UUID is carried within Client Identifier or Server
   Identifier options.  It has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          DUID-Type (4)        |    UUID (128 bits)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                                                               |
   |                                -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

                        Figure 1: DUID-UUID Format

   DUID-Type -  DUID-UUID (4) - (16 bits)

   UUID -  An [RFC4122] UUID (128 bits)

Type 4 details – https://tools.ietf.org/html/rfc4122#section-4.4

4.4.  Algorithms for Creating a UUID from Truly Random or
      Pseudo-Random Numbers

   The version 4 UUID is meant for generating UUIDs from truly-random or
   pseudo-random numbers.

   The algorithm is as follows:

   o  Set the two most significant bits (bits 6 and 7) of the
      clock_seq_hi_and_reserved to zero and one, respectively.

   o  Set the four most significant bits (bits 12 through 15) of the
      time_hi_and_version field to the 4-bit version number from
      Section 4.1.3.

   o  Set all the other bits to randomly (or pseudo-randomly) chosen
      values.

This IPv6 stuff is very strange to me and what I have read isn't proving helpful to me beyond the basics of getting it up and running.

I foresee some boring time spent in front of my switches moving wires to my testing LAN one at a time and waiting to see if I get a new lease there. I'll shorten the DHCP lease times before I do that and see what happens.

NogBadTheBad · Apr 2, 2018, 12:27 PM

Do a packet capture IPv6 on port 546, you'll see the Link-layer address in the Ethernet II Src & Client Identifer :-

Frame 1: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Apple_a2:e0:7e (40:9c:28:a2:e0:7e), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Destination: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Source: Apple_a2:e0:7e (40:9c:28:a2:e0:7e)
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::1083:ac17:43b3:afd6 (fe80::1083:ac17:43b3:afd6), Dst: ff02::1:2 (ff02::1:2)
0110 …. = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... .... .... 1011 1100 0110 1001 1100 = Flow Label: 0xbc69c
Payload Length: 60
Next Header: UDP (17)
Hop Limit: 1
Source: fe80::1083:ac17:43b3:afd6 (fe80::1083:ac17:43b3:afd6)
Destination: ff02::1:2 (ff02::1:2)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: dhcpv6-client (546), Dst Port: dhcpv6-server (547)
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x5f79df
Client Identifier
Option: Client Identifier (1)
Length: 14
Value: 0001000121a83316409c28a2e07e
DUID: 0001000121a83316409c28a2e07e
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: Nov 22, 2017 13:07:34.000000000 GMT
Link-layer address: 40:9c:28:a2:e0:7e
Option Request
Option: Option Request (6)
Length: 4
Value: 00170018
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Elapsed time
Option: Elapsed time (7)
Length: 2
Value: 0000
Elapsed time: 0ms
Identity Association for Non-temporary Address
Option: Identity Association for Non-temporary Address (3)
Length: 12
Value: 000000000000000000000000
IAID: 00000000
T1: 0
T2: 0

You could even use the following as a display filter in Wireshark :-

dhcpv6.duid.bytes == 00:01:00:01:21:a8:33:16:40:9c:28:a2:e0:7e

stan-qaz · Apr 5, 2018, 7:42 AM

NogBadTheBad, Well I learned how to install Wireshark and get the basics working so I could try your suggestion and I'm fooling with different filters now.

I've identified several of my unidentified IP address owners and am busily plugging them into the static leases settings.

Thanks!