|=-----------------------------------------------------------------------=| |=-----------=[ Challenges for Host Discovery and Malware ]=------------=| |=-----------=[ Propagation in the IPv6 Address Space. ]=----------- =| |=-----------------------------------------------------------------------=| |=------------------------=[ Luis MartinGarcia ]=------------------------=| |=----------=[ www.aldabaknocking.com ; luis.mgarc@gmail.com ]=----------=| |=-----------------------------------------------------------------------=| --[ Contents |_ 0x01 - Introduction |_ 0x02 - Related Work |_ 0x03 - Experimental Lab |_ 0x04 - Host Discovery in IPv4 |_ 0x05 - Discovery of IPv6 Hosts On-Link |_ 0x05.1 - Multicast probes |_ 0x05.1.1 - ICMPv6 Echo messages |_ 0x05.1.2 - ICMPv6 Multicast Listener Discovery messages |_ 0x05.1.3 - Neighbor Discovery |_ 0x05.1.4 - ICMPv6 Node Information messages |_ 0x05.1.5 - Malformed IPv6 messages |_ 0x05.2 - Traffic redirection |_ 0x05.3 - Router impersonation |_ 0x05.4 - Passive eavesdropping |_ 0x06 - Discovery of IPv6 Hosts Off-Link |_ 0x06.1 - Looking glass services |_ 0x06.2 - Dual-stack devices |_ 0x06.3 - Traceroute |_ 0x07 - Other Host Discovery Techniques |_ 0x07.1 - Using DNS to gather addresses |_ 0x07.1.1 - DNS zone transfers |_ 0x07.1.2 - DNSSEC zone enumeration |_ 0x07.1.3 - Dictionary attacks |_ 0x07.1.4 - Brute-force attacks |_ 0x07.2 - Hosts configured by stateless autoconfiguration |_ 0x07.3 - Exploiting manual address assignment |_ 0x07.4 - Discovery based on local information |_ 0x08 - Conclusions |_ References --[ Abstract The shortage of IPv4 addresses has been a known problem for decades and while nobody knows when the new Internet Protocol version 6 will be completely deployed, it seems clear that, considering the actual growth rate of the Internet, most hosts will speak IPv6 at some point in the future. The new default 64-bit subnet address space introduces important challenges for the remote discovery of active network hosts as it makes it infeasible to conduct brute-force searches. While the ability to discover active hosts may be maliciously used by worms or intruders looking for potential targets, it is often used by system administrators to perform legitimate tasks like network inventory or rogue host detection. This paper will present some heuristics and techniques that may allow the discovery of active hosts in IPv6 networks, without the need to sweep enormous subnet address spaces. --[ 0x01 - Introduction The exhaustion of IPv4 addresses has been a concern for decades and while new methods and technologies like Network Address Translation (NAT) or Classless Inter-Domain Routing (CIDR), have been developed over the time to alleviate the problem, it seems clear that the IPv4 address pool will be completely exhausted soon. At time of writing, there isn't any unallocated block in the IANA IPv4 Address Space Registry [1], and some authors estimate that most Regional Internet Registries (RIRs) will exhaust their address pools by 2015. Although the IANA or the RIRs could start allocating address blocks that were initially reserved for experimental use, the IPv4 address space is very limited and the whole Internet will be forced to move to the next version of the Internet Protocol sooner or later. Among other things, the new version of IP, the Internet Protocol version 6 or IPv6, extends the available address space from 32 bits to 128, which makes it virtually impossible to run out of addresses, even with very wasteful allocation schemes [3]. IPv6 addresses are divided in two parts. The first one is called the network prefix and its purpose is to identify a particular link. The other part is called the interface identifier and its purpose is to uniquely identify a network node on the link. Although prefixes and interface identifiers may have a variable length, the current IETF addressing policy suggests allocating fixed /48 network prefixes to end sites and dividing the remaining 80 bits in a 16-bit subnet identifier and a 64-bit interface identifier. This means that while in IPv4 subnets typically had between 4 and 2^16 addresses, in IPv6, subnets will have 2^64 addresses, 2^32 times the entire IPv4 address space. The new subnet size in IPv6 introduces important challenges for the discovery of active network hosts. In the IPv4 world, Internet worms or security scanners perform host discovery by brute-forcing entire subnet address spaces, sending probes to every possible address on the subnet and considering hosts active if they reply to any of the probes. However, in IPv6, sweeping an entire /64 subnet is inherently infeasible. Assuming that a network host could actively probe 2^24 hosts per second (around 16 million), which would require a bandwidth of approximately 7.5Gbps, sweeping an entire 2^64 subnet address space would take 2^40 seconds, or about 35,000 years. Consequently, host discovery in IPv6 networks can't be performed by brute-force but using other techniques that allow to reduce the search space to something reasonable. The rest of this paper is organized as follows. Section 0x02 will review related work in the area. Section 0x03 will describe the lab that was built to conduct a few experimental tests. Section 0x04 will briefly discuss the current approach of worms and network scanners in IPv4 networks. Section 0x05 will present a few techniques that allow one host to gather IPv6 addresses of other hosts on the same link. Section 0x06 will cover techniques for the discovery of hosts that are out of the local link. Section 0x07 will present those techniques that apply regardless of the position of the hosts. Finally, section 0x08 will present some conclusions and pointers for future research. --[ 0x02 - Related Work Despite its significant importance, the discovery of hosts in IPv6 networks is a problem that has not attracted much attention from either academic researchers or the hacker community. However, there are a two main documents of interest in this direction. On one hand, [4] is an informative RFC that discusses the implications of the new version of the Internet Protocol for network scanning and the approaches that administrators could take when planning their site address allocation and management strategies as part of a defense-in-depth approach to network security. [5], on the other hand, discusses the problem of discovery from the perspective of network worms that try to find other hosts to propagate and continue their existence. It is worth noting that while regular attackers tend to choose specific networks with the intent of finding as much information as possible about them, worms usually do not care about the location of vulnerable hosts, as their only goal is to propagate and survive. There are also a few other documents worth mentioning. [6] presents a detailed study of the security problems that affect IPv6 hosts and briefly discusses IPv6 network reconnaissance. Additionally, the THC group publishes an open source set of tools to perform various attacks on IPv6 networks [7]. One of its components, alive6, provides basic IPv6 host discovery capabilities. There is a similar set of tools developed by SI6 Networks, the "IPv6 Toolkit" [25], which includes a tool named scan6 that serves the same purpose. --[ 0x03 - Experimental Lab Some of the information presented in this article was obtained through experimental testing. A virtual lab was created using VMWare Workstation 8.0. The lab is formed by seven virtual machines running different operating systems. No special configuration was performed on the machines (except for FreeBSD where IPv6 needed to be enabled explicitly). Windows boxes had the "Windows Firewall" service enabled. All machines have a single network interface. All interfaces are connected to the same virtual network. There is a DHCP service that hands out IPv4 addresses but there is no DHCPv6 service. The virtualization host runs Linux Mint (kernel 3.2.0-23, x86_64). The following diagram shows which operating systems and versions exist in the environment. +-------------+ +------------+ | FreeBSD 9.0 |---------------+ +---------------| CentOS 6.3 | +-------------+ | | +------------+ | | | | | | +------------+ +----------------------+ +-------------+ | NetBSD 5.0 |-----|VMWare Virtual Network|-----| OpenBSD 3.8 | +------------+ | 192.168.158.1/24 | +-------------+ +----------------------+ | | | | | | +-----------+ | | | +-------------------+ | Windows 8 |---------+ | +--------| Oracle Solaris 11 | +-----------+ | +-------------------+ | +--------------+ | Windows 2012 | +--------------+ == Figure 1: Logical diagram of the experimental lab. The following table shows the IPv6 addresses that all operating systems configured automatically for their network interface. [Appendix A] shows their network configuration with greater detail. == IPv6 Address ========== == OS ============== fe80::20c:29ff:fe3f:7f9a FreeBSD 9.0 fe80::20c:29ff:feed:1921 CentOS 6.3 fe80::20c:29ff:fed0:48b4 NetBSD 5.0 fe80::20c:29ff:fe13:a69b OpenBSD 3.8 fe80::20c:29ff:fec4:32d9 Oracle Solaris 11 fe80::3c3a:dde0:fcc7:71f3 Windows 8 fe80::18f5:1a6d:4a60:37a2 Windows Server 2012 === Table 1: List of IPv6 addresses --[ 0x04 - Host Discovery in IPv4 In today's IPv4 networks, worms and network scanners do not consider the size of the address space to be a limiting factor for their purpose. The IPv4 address space is 32 bits wide, this is, less than 5 billion addresses. A host like the one described in the previous section could sweep the entire Internet in less than 5 minutes. For this reason, current worms and network reconnaissance tools may not pay much attention to the efficiency of their discovery algorithms but simply attempt to detect active hosts, sending packets to all possible addresses and listening for responses. Due to their distributed nature, worms typically sweep the address space randomly [8]. This reduces the chances of two distant worms targeting the same set of addresses. Network scanners, however, are usually run one instance at a time and cover the address space sequentially. The actual detection can be performed using various types of packets. Worms looking for specific vulnerabilities are likely to use TCP packets with the SYN flag set and the destination port field set to the port number where the service to be exploited listens for connections. Network scanners may use more advanced techniques. For example, the popular Nmap Security Scanner [9] uses ARP requests when the targets are on the local Ethernet network and sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80 and an ICMP timestamp request, when the targets are more than one hop away. The following example shows how to use Nmap to perform host discovery on a network. The "-sn" parameter tells Nmap not to do a port scan after host discovery, and only print out the hosts that are up on the network. The "--reason" parameter tells Nmap to print the reason why hosts are considered to be up. luis@aberdeen ~ $ sudo nmap 192.168.158.* -sn --reason Starting Nmap 6.26SVN ( http://nmap.org ) at 2013-02-15 19:21 CET Nmap scan report for 192.168.158.1 Host is up, received localhost-response. Nmap scan report for 192.168.158.128 Host is up, received arp-response (0.00020s latency). MAC Address: 00:0C:29:13:A6:9B (VMware) Nmap scan report for 192.168.158.134 Host is up, received arp-response (0.00097s latency). MAC Address: 00:0C:29:D9:00:11 (VMware) Nmap scan report for 192.168.158.135 Host is up, received arp-response (0.00087s latency). MAC Address: 00:0C:29:D0:48:B4 (VMware) Nmap scan report for 192.168.158.137 Host is up, received arp-response (0.00079s latency). MAC Address: 00:0C:29:3F:7F:9A (VMware) Nmap scan report for 192.168.158.138 Host is up, received arp-response (0.00072s latency). MAC Address: 00:0C:29:ED:19:21 (VMware) Nmap scan report for 192.168.158.139 Host is up, received arp-response (0.0011s latency). MAC Address: 00:0C:29:C4:32:D9 (VMware) Nmap scan report for 192.168.158.254 Host is up, received arp-response (0.00078s latency). MAC Address: 00:50:56:EB:CE:0B (VMware) Nmap done: 256 IP addresses (8 hosts up) scanned in 3.43 seconds === Listing 1: Nmap performing host discovery on an IPv4 subnet. --[ 0x05 - Discovery of IPv6 Hosts On-Link As discussed above, the default 64-bit subnet space in IPv6 makes it infeasible to test every address on a given subnet. For this reason, if worms and network scanners want to survive the transition to IPv6, they'll need to use alternative techniques to detect the presence of other hosts on the network. In the IPv6 world, every address other than the unspecified address has a specific scope; that is, a topological span within which the address may be used as a unique identifier for an interface or set of interfaces [10]. For unicast addresses there are two scopes currently defined: the link-local scope, for uniquely identifying interfaces within a single link and the global scope, for uniquely identifying interfaces within the Internet. For multicast addresses, there are fourteen possible scopes, which will not be discussed in this document. This section will present a few techniques that may be used to discover hosts on the same link. Although many of the addresses discovered from the inside of the network will have a local scope, certain global scoped addresses may also be gathered from that point. ----[ 0x05.1 - Multicast probes The support for multicast is a core feature of IPv6 but it can be abused for host discovery. There are a few multicast groups standardized by the IANA, some of which are required to be joined by all IPv6-capable hosts. For example, all hosts on a link are required to join the all-nodes link-local multicast group and all routers on a link are required to join the all-routers link-local group [12]. Table 1 lists some of the link-local groups that are defined at time of writing [24]. Multicast address Description =================== ==================================== FF02:0:0:0:0:0:0:1 All Nodes Address FF02:0:0:0:0:0:0:2 All Routers Address FF02:0:0:0:0:0:0:9 ARIP Routers FF02:0:0:0:0:0:0:A EIGRP Routers FF02:0:0:0:0:0:0:16 All MLDv2-capable Routers FF02:0:0:0:0:0:0:FB Multicast DNS FF02:0:0:0:0:0:1:2 All DHCP Agents FF02:0:0:0:0:0:1:3 Link-Local Multicast Name Resolution === Table 2: Partial list of standardized IPv6 multicast addresses. An attacker may join and send traffic to these multicast groups and use the responses to determine which hosts are connected to the network. The following subsections present examples of messages that can be sent to multicast groups in order to discover active hosts on the link. ------[ 0x05.1.1 - ICMPv6 Echo messages The most straightforward option is to send ICMPv6 Echo requests to the all-nodes link-local group. Hosts on the local link will respond with ICMPv6 Echo response messages, revealing their existence to the attacker. In the lab environment, alive6 was used to send those ICMPv6 echo requests to the ff02::1 multicast address. Here's an example. The "-p" parameter tells alive6 to use ICMPv6 Echo requests for discovery. "vmnet2" is the network interface that is connected to the lab network. luis@aberdeen ~/Downloads/thc-ipv6-2.1 $ sudo ./alive6 -p vmnet2 Alive: fe80::20c:29ff:fe13:a69b [ICMP echo-reply] Alive: fe80::20c:29ff:fe3f:7f9a [ICMP echo-reply] Alive: fe80::20c:29ff:fed0:48b4 [ICMP echo-reply] Alive: fe80::20c:29ff:fec4:32d9 [ICMP echo-reply] Alive: fe80::20c:29ff:feed:1921 [ICMP echo-reply] Scanned 1 address and found 5 systems alive === Listing 2: Use of the tool alive6 to send multicast ICMPv6 Echo requests. Note that none of the Windows hosts responded to the probe, even when the Windows Firewall was turned off. Apparently Microsoft has decided to refuse answering ICMPv6 Echo requests that are targeted to multicast addresses (no responses are received even when targeting the solicited-node address). ------[ 0x05.1.2 - ICMPv6 Multicast Listener Discovery messages Multicast Listener Discovery (MLD) is a protocol used by IPv6 routers to discover which nodes wish to receive multicast packets on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes [14]. This protocol, which is implemented through a set of three ICMPv6 message types, may be used by an attacker to detect the presence of hosts subscribed to a multicast group. Only hosts on the same link can be detected using this protocol, as all nodes are required to verify that the IPv6 Source Address of all received MLD messages is a link-local address. The attacker can either send a Multicast-General-Listener Query to learn which multicast addresses have listeners on an attached link or a Multicast-Address-Specific Query to learn if a particular multicast address has any listeners. Both queries will cause at least one listener to send back a Multicast Listener Report message, whose source addresses can be gathered by the attacker. The following example shows how to use Nping(*) to issue an MLD general listener query. luis@aberdeen ~ $ sudo nping ff02::1 -e vmnet2 --dest-mac 33:33:00:00:00:01 --icmp6-type gmq --icmp6-gm-addr ::0 --icmp6-gm-delay 1000 -c1 --bpf-filter "" Starting Nping 0.6.26SVN ( http://nmap.org/nping ) at 2013-02-16 18:41 CET SENT (0.0000s) IPv6[fe80::250:56ff:fec0:1 > ff02::1 hlim=64] ICMPv6[Group membership query addr=::] RCVD (0.0260s) IPv6[fe80::20c:29ff:fe13:a69b > ff02::1:ff13:a69b hlim=1] HopByHop[58,0] ICMPv6[Group membership report addr=ff02::1:ff13:a69b] RCVD (0.2110s) IPv6[fe80::20c:29ff:feed:1921 > ff02::1:ffed:1921 hlim=1] HopByHop[58,0] ICMPv6[Group membership report addr=ff02::1:ffed:1921] RCVD (0.3110s) IPv6[fe80::20c:29ff:feed:1921 > ff02::202 hlim=1] HopByHop[58,0] ICMPv6[Group membership report addr=ff02::202] RCVD (0.6680s) IPv6[fe80::20c:29ff:fed0:48b4 > ff02::2:f736:afa7 hlim=1] HopByHop[58,0] ICMPv6[Group membership report addr=ff02::2:f736:afa7] RCVD (0.8270s) IPv6[fe80::20c:29ff:fe13:a69b > ff02::2:f9af:b378 hlim=1] HopByHop[58,0] ICMPv6[Group membership report addr=ff02::2:f9af:b378] RCVD (0.8580s) IPv6[fe80::20c:29ff:fed0:48b4 > ff02::1:ffd0:48b4 hlim=1] HopByHop[58,0] ICMPv6[Group membership report addr=ff02::1:ffd0:48b4] Raw packets sent: 1 (78B) | Rcvd: 6 (432B) | Lost: 0 (0.00%) Max rtt: 857.505ms | Min rtt: 26.089ms | Avg rtt: 483.304ms Tx time: 0.00020s | Tx bytes/s: 393939.39 | Tx pkts/s: 5050.51 Rx time: 1.00021s | Rx bytes/s: 431.91 | Rx pkts/s: 6.00 Nping done: 1 IP address pinged in 1.11 seconds === Listing 3: Use of the tool Nping to issue general MLD queries. The results show that only OpenBSD, CentOS and NetBSD responded to the probes. It must be noted that responses to the general query are not sent to the unicast address of the querier but to the multicast address of the group the hosts are listening too. For this reason, it may be difficult for an attacker to sniff the responses, unless the underlying layer-2 technology is not capable of handling multicast properly. (*) Note that, at the time of writing, the version of the Nping tool used in the example is not the latest stable release but an experimental branch available from SVN https://svn.nmap.org/nmap-exp/luis/nmap-npingchanges/ ----[ 0x05.1.3 - Neighbor Discovery IPv6 introduces a new protocol, the IPv6 Neighbor Discovery (ND) protocol which, when it operates over an Ethernet network, it could be seen as the equivalent of ARP for the IPv6 world, because it is used to map IP addresses to local link-layer addresses. However, unlike ARP, it also provides mechanisms to discover routers on the local link, detect duplicate addresses or unreachable hosts, or inform nodes when there is a better gateway to send traffic through. A large portion of Neighbor Discovery messages are sent to multicast addresses. However, very few are sent to the all-nodes group, and therefore, it may be difficult for an attacker to access those messages. One of the easiest messages to sniff are Router Solicitations, which hosts send to the all-routers multicast address, typically at startup. An attacker only needs to subscribe to that group to be able to detect those hosts that request a default router. Neighbor Solicitations, on the other hand, are usually sent to the solicited-node address so, in practical terms, only one host on the network receives the message. Responses are unicasted to the original solicitor (both at layer 2 and 3) and are also difficult to observe for the attacker. One solution would be to subscribe to every possible solicited-node address. This way one could receive a copy of any neighbor solicitation issued by a host on the same link. However, there are 2^24 possible solicited-node addresses (ff02:0:0:0:0:1:ff00::/104) so it may not be practical to subscribe to all of them. Interestingly, lab tests show that Solaris periodically sends gratuitous Neighbor Advertisements to the all-nodes group, which makes that OS clearly visible to any other host on the link. The following example shows tcpdump capturing traffic from the Solaris box. luis@aberdeen ~ $ sudo tcpdump -i vmnet2 -t "ip6 and src host fe80::20c:29ff:fec4:32d9" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vmnet2, link-type EN10MB (Ethernet), capture size 65535 bytes IP6 fe80::20c:29ff:fec4:32d9 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:fec4:32d9, length 32 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:fec4:32d9, length 32 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:fec4:32d9, length 32 === Listing 4: Unsolicited traffic generated by Oracle Solaris 11. It must be noted that although in theory multicast traffic is only visible to the hosts that are subscribed to a particular group, this may not always be the case. In order for layer-3 multicast to work, it needs layer-2 support. For example, with Ethernet, if a switch does not have MLD snooping capabilities [26], it may be forced to broadcast IPv6 multicast Ethernet frames (frames targeted to MAC addresses in the range 33:33:00:00:00:00 - 33:33:FF:FF:FF:FF) through all its ports. In this situation, an attacker may be able to access Neighbor Discovery messages, just like ARP messages or any other broadcast traffic. ------[ 0x05.1.4 - ICMPv6 Node Information messages The Node Information protocol (NI) is a mechanism for discovering information about names and addresses that also provides facilities that are not found in the DNS, like the discovery of relationships between addresses without reference to names [15]. Some of its functions overlap with the DNS but are useful in serverless environments. With this protocol, a host may learn the addresses and names of nodes on the other end of a point-to-point link or nodes on a shared-medium link such as Ethernet. The protocol is implemented through two ICMPv6 message types: Node Information Queries and Node Information Replies. The typical usage scenario is the following: two nodes, Alice and Bob are attached to the same link, and Alice wants to establish communication with Bob. Alice knows Bob's host name but not its IP address and has no DNS server configured. To resolve Bob's address, Alice sends a Node Information Query that contains Bob's host name, to the all-nodes link-local multicast address. Bib receives the query and produces a Node Information Reply that includes its IP address. An attacker may abuse the protocol to discover other hosts on the link. In theory, hosts that receive NI queries must silently discard queries for addresses or names that do not belong to them. However, there is a special query type called NOOP, which has no defined flags and no data field, to which nodes may reply to tell the querier that they are up and reachable and implement the Node Information protocol. Because of this, an attacker may issue NOOP queries destined to the all-nodes link-local multicast address and gather the addresses of other hosts on the link based on the received NI replies. luis@aberdeen ~ $ sudo nping ff02::1 -e vmnet2 --dest-mac 33:33:00:00:00:01 --icmp6-type niq --icmp6-code 1 -c1 Starting Nping 0.6.26SVN ( http://nmap.org/nping ) at 2013-02-17 11:30 CET SENT (0.0000s) IPv6[fe80::250:56ff:fec0:2 > ff02::1 hlim=64] ICMPv6[Node info query (name)] RCVD (0.0000s) IPv6[fe80::20c:29ff:fe13:a69b > fe80::250:56ff:fec0:2 hlim=64] ICMPv6[Node info reply (success)] RCVD (0.0000s) IPv6[fe80::20c:29ff:fed0:48b4 > fe80::250:56ff:fec0:2 hlim=64] ICMPv6[Node info reply (success)] RCVD (0.0000s) IPv6[fe80::20c:29ff:fe3f:7f9a > fe80::250:56ff:fec0:2 hlim=64] ICMPv6[Node info reply (success)] Raw packets sent: 1 (70B) | Rcvd: 3 (168B) | Lost: 0 (-200.00%) Max rtt: 0.537ms | Min rtt: 0.368ms | Avg rtt: 0.453ms Tx time: 0.00017s | Tx bytes/s: 400000.00 | Tx pkts/s: 5714.29 Rx time: 1.00112s | Rx bytes/s: 167.81 | Rx pkts/s: 3.00 Nping done: 1 IP address pinged in 1.12 seconds === Listing 5: Use of the tool Nping to issue NI queries. ------[ 0x05.1.5 - Malformed IPv6 messages Although hosts cannot send ICMPv6 error messages as a result of receiving packets destined to an IPv6 multicast address, there are two exceptions to this rule: the Packet Too Big Message to allow Path MTU discovery to work for IPv6 multicast, and the Parameter Problem Message which reports an unrecognized IPv6 option [16]. This means that, even if for some reason ICMPv6 Echo messages are blocked, an attacker may send IPv6 packets to the multicast address with invalid parameters that cause the nodes on the group to discard the packet and send an ICMPv6 Parameter Problem message in response. The tool alive6 can be used to send IPv6 packets with extension headers that contain incorrect options. The following examples show the effectiveness of this technique. The "-e" parameter tells alive6 to send incorrect options. In the first example, the tool is asked to produce an incorrect option in a hop-by-hop extension header. In the second example, the tool uses the Destination Options extension header. luis@aberdeen ~/Downloads/thc-ipv6-2.1 $ sudo ./alive6 -e hop vmnet2 Alive: fe80::20c:29ff:fe13:a69b [ICMP parameter problem] Alive: fe80::20c:29ff:fe3f:7f9a [ICMP parameter problem] Alive: fe80::20c:29ff:fec4:32d9 [ICMP parameter problem] Alive: fe80::20c:29ff:feed:1921 [ICMP parameter problem] Alive: fe80::20c:29ff:fed0:48b4 [ICMP parameter problem] Scanned 1 address and found 5 systems alive === Listing 6: Use of the tool alive6 to send incorrect Hop-By-Hop headers. luis@aberdeen ~/Downloads/thc-ipv6-2.1 $ sudo ./alive6 -e dst vmnet2 Alive: fe80::20c:29ff:fed0:48b4 [ICMP parameter problem] Alive: fe80::20c:29ff:fe3f:7f9a [ICMP parameter problem] Alive: fe80::20c:29ff:fe13:a69b [ICMP parameter problem] Alive: fe80::20c:29ff:feed:1921 [ICMP parameter problem] Alive: fe80::20c:29ff:fec4:32d9 [ICMP parameter problem] Scanned 1 address and found 5 systems alive === Listing 7: Use of the tool alive6 to send incorrect Destination Options headers. As usual, Windows boxes did not respond to the probes. However, if Windows Firewall is turned off, then those machines start responding: luis@aberdeen ~/Downloads/thc-ipv6-2.1 $ sudo ./alive6 -e dst vmnet2 Alive: fe80::20c:29ff:fed0:48b4 [ICMP parameter problem] Alive: fe80::20c:29ff:fe13:a69b [ICMP parameter problem] Alive: fe80::20c:29ff:fe3f:7f9a [ICMP parameter problem] Alive: fe80::20c:29ff:fec4:32d9 [ICMP parameter problem] Alive: fe80::18f5:1a6d:4a60:37a2 [ICMP parameter problem] Alive: fe80::20c:29ff:feed:1921 [ICMP parameter problem] Alive: fe80::3c3a:dde0:fcc7:71f3 [ICMP parameter problem] Scanned 1 address and found 7 systems alive === Listing 8: Use of the tool alive6 when Windows Firewall is disabled in the Windows boxes. The results clearly show that sending IPv6 packets with incorrect options in their extension headers is the best method to detect alive boxes using multicast probes. After disabling Windows Firewall, 100% of the lab machines were discovered. Unfortunately, default installations of Windows 8 and Windows Server 2012 (and probably older versions too) are configured to enable the Windows Firewall service. However, some enterprise deployments of these operating systems may use third-party firewall products that do not block incoming ICMP packets destined to multicast addresses by default . Anecdotal evidence shows that many companies choose to disable the firewall service in all or part of their Windows boxes in their intranet, using Active Directory Group Policy settings. ----[ 0x05.2 - Traffic redirection There are many attacks that can be carried out by an attacker through the Network Discovery protocol. One of them is equivalent to the classic ARP-poisoning attack. With ND, in order to determine the link-layer address of a node that is attached to the local link, the node that requires the address sends a Neighbor Solicitation message to a multicast address specified by the target address. The target node, which continuously listens to the multicast address, receives the solicitation and replies with a Neighbor Advertisement message. An attacker can get packets for legitimate nodes to be sent to his own link-layer address, sending malicious Neighbor Solicitation and Neighbor Advertisement messages. If the spoofed link-layer address is valid, as long as the attacker responds to the unicast Neighbor Solicitation messages sent as part of the Neighbor Unreachability Detection, packets will continue to be directed to him [11]. The following listing shows an example of the attack using parasite6. luis@aberdeen ~/Downloads/thc-ipv6-2.1 $ sudo ./parasite6 vmnet2 Remember to enable routing (ip_forwarding), you will denial service otherwise! => echo 1 > /proc/sys/net/ipv6/conf/all/forwarding Started ICMP6 Neighbor Solitication Interceptor (Press Control-C to end) ... Spoofed packet to fe80::20c:29ff:fe3f:7f9a as fe80::20c:29ff:feed:1921 Spoofed packet to fe80::20c:29ff:feed:1921 as fe80::20c:29ff:fe3f:7f9a Spoofed packet to fe80::20c:29ff:fe13:a69b as fe80::20c:29ff:feed:1921 Spoofed packet to fe80::20c:29ff:feed:1921 as fe80::20c:29ff:fe13:a69b === Listing 8: Use of the tool parasite6 to send spoofed neighbor advertisements ----[ 0x05.3 - Router impersonation Instead of redirecting traffic destined to a particular host, attackers may choose to impersonate the local router, multicasting legitimate-looking Router Advertisements or unicasting Router Advertisements in response to multicast Router Solicitations. If other hosts select the attacker as their default router, the attacker will be able to receive their network traffic and learn the addresses of others hosts in and outside the local link. Even if hosts already have a configured default gateway and decide to ignore new router advertisements, the ICMPv6 Redirect message may be used to alter their routing table. ICMPv6 Redirects are sent by routers when a given system is choosing a wrong local router for a packet. To prevent malicious hosts from injecting false routes, ICMPv6 Redirects are required to include as much of the offending packet as can fit without the redirect packet exceeding the minimum MTU required to support IPv6 [12]. However, an attacker may easily subvert such protection as follows [13]: 1. The attacker sends an ICMPv6 Echo request to the victim with the source address of the route he wants to redirect. 2. The attacker can easily guess the ICMPv6 Echo reply that the victim will produce in response so he crafts an ICMPv6 Redirect message with the forged source address of the victim's default router and attaches a copy of the guessed Echo reply. 3. The attacker waits enough time to allow the victim to send the Echo reply and then sends the Redirect message created in step 2. 4. When the victim receives the message, updates its local routing table with the route injected by the attacker. In the lab, the tool "redir6" was used to test the technique described above. The experiment involved the following steps: 1. A route was added to the CentOS box: 2600::0/16 via fe80::1 [root@localhost ~]# ip -6 route add 2600::0/16 via fe80::1 dev eth0 2. The fe80::1 address was added as an additional address to the network card configuration of the Windows 2012 machine. This ensures that there is one host on the network that responds to possible Neighbor Solicitations for that address. PS C:\> New-NetIPAddress -IPAddress fe80::1 -InterfaceAlias "Ethernet" 3. In the CentOS box, the ping6 tool was run to ping an IPv6 address in the 2600::0/16 subnet. [root@localhost ~]# ping6 2600:3c01::f03c:91ff:fe96:967c 4. The redir6 tool was run in the virtualization host. luis@aberdeen ~/Downloads/thc-ipv6-2.1 $ sudo ./redir6 vmnet2 fe80::20c:29ff:feed:1921 2600:3c01::f03c:91ff:fe96:967c fe80::1 fe80::250:56ff:fec0:2 00:50:56:c0:00:02 Sent ICMPv6 redirect for 2600:3c01::f03c:91ff:fe96:967c The following network capture shows the whole process (irrelevant packets omitted for convenience) luis@aberdeen ~/Desktop/ipv6-discovery/pcaps $ tcpdump -i vmnet2 -t -n -e 00:0c:29:ed:19:21 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::20c:29ff:feed:1921 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32 00:0c:29:d9:00:11 > 00:0c:29:ed:19:21, ethertype IPv6 (0x86dd), length 86: fe80::1 > fe80::20c:29ff:feed:1921: ICMP6, neighbor advertisement, tgt is fe80::1, length 32 00:0c:29:ed:19:21 > 00:0c:29:d9:00:11, ethertype IPv6 (0x86dd), length 118: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo request, seq 1, length 64 00:0c:29:ed:19:21 > 00:0c:29:d9:00:11, ethertype IPv6 (0x86dd), length 118: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo request, seq 2, length 64 00:0c:29:d9:00:11 > 00:0c:29:ed:19:21, ethertype IPv6 (0x86dd), length 86: fe80::1 > fe80::20c:29ff:feed:1921: ICMP6, neighbor solicitation, who has fe80::20c:29ff:feed:1921, length 32 00:0c:29:ed:19:21 > 00:0c:29:d9:00:11, ethertype IPv6 (0x86dd), length 78: fe80::20c:29ff:feed:1921 > fe80::1: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:feed:1921, length 24 00:0c:29:ed:19:21 > 00:0c:29:d9:00:11, ethertype IPv6 (0x86dd), length 118: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo request, seq 6, length 64 00:0c:29:ed:19:21 > 00:0c:29:d9:00:11, ethertype IPv6 (0x86dd), length 118: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo request, seq 7, length 64 00:0c:29:ed:19:21 > 00:0c:29:d9:00:11, ethertype IPv6 (0x86dd), length 118: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo request, seq 84, length 64 00:0c:29:d9:00:11 > 00:0c:29:ed:19:21, ethertype IPv6 (0x86dd), length 78: 2600:3c01::f03c:91ff:fe96:967c > fe80::20c:29ff:feed:1921: ICMP6, echo request, seq 47806, length 24 00:0c:29:ed:19:21 > 00:0c:29:d9:00:11, ethertype IPv6 (0x86dd), length 78: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo reply, seq 47806, length 24 00:0c:29:d9:00:11 > 00:0c:29:ed:19:21, ethertype IPv6 (0x86dd), length 174: fe80::1 > fe80::20c:29ff:feed:1921: ICMP6, redirect, 2600:3c01::f03c:91ff:fe96:967c to fe80::250:56ff:fec0:2, length 120 00:0c:29:ed:19:21 > 00:50:56:c0:00:02, ethertype IPv6 (0x86dd), length 118: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo request, seq 85, length 64 00:0c:29:ed:19:21 > 00:50:56:c0:00:02, ethertype IPv6 (0x86dd), length 118: fe80::20c:29ff:feed:1921 > 2600:3c01::f03c:91ff:fe96:967c: ICMP6, echo request, seq 86, length 64 === Listing 9: Network capture of the router impersonation attack. Note how the victim starts using the attacker as a default gateway. The last ICMPv6 echo request sent to the default gateway is the one with seq=84. The next ICMPv6 echo request is sent to the attacker's MAC address (00:50:56:c0:00:02) instead of to the router's address (00:0c:29:d9:00:11). ----[ 0x05.4 - Passive eavesdropping Although hub-based networks are obsolete these days, unprotected or WEP-based wireless networks have brought back the old eavesdropping problem. An attacker with the ability to capture network traffic will be able to detect active hosts by observing the source and the destination address of the captured packets. If the activity of the network is high enough, the attacker may gather a very complete list of addresses. This technique is specially valuable in the discovery of Windows boxes. Although Microsoft Windows by default does not respond to the probes sent to the all-nodes multicast address discussed earlier, it is very talkative on the network. The following capture shows some of the IPv6 packets that the Windows 8 box produces on startup, until the login screen is presented to the user. luis@aberdeen ~ $ sudo tcpdump -i vmnet2 -t "ip6 and src host fe80::3c3a:dde0:fcc7:71f3" IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 :: > ff02::1:ffc7:71f3: ICMP6, neighbor solicitation, who has fe80::3c3a:dde0:fcc7:71f3, length 24 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allrouters: ICMP6, router solicitation, length 8 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::3c3a:dde0:fcc7:71f3, length 32 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.53493 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.53493 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.57027 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.57027 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.55638 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::3c3a:dde0:fcc7:71f3.55638 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.53790 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::3c3a:dde0:fcc7:71f3.53790 > ff02::1:3.hostmon: UDP, length 22 === Listing 10: Network capture of a Windows box at startup. [Appendix C] shows equivalent packet captures for the rest of machines in the lab. --[ 0x06 - Discovery of IPv6 Hosts Off-Link This section presents some techniques for the discovery of hosts out of the local link. ----[ 0x06.1 - Looking glass services A public looking glass is a network service, typically offered either from a web page or from a telnet session, that allows users to access network's routing information from various network vantage points. Looking glass services may be used to gather BGP routing information of various Internet Autonomous Systems. This can be useful for attackers seeking to gather IPv6 prefixes. However, although some /64 prefixes may be observed occasionally, most routes use prefixes of 48 bits or less, which, in general, are too generic for host discovery. ----[ 0x06.2 - Dual-stack devices The transition from IPv4 to IPv6 will be gradual. Until IPv6 is completely deployed in the Internet, a number of transition mechanisms are needed to allow IPv6 hosts to reach IPv4 services and enable IPv6 networks to reach other IPv6 networks on the Internet over the current IPv4 infrastructure. There are a number of standardized solutions for the transition phase. Perhaps the most common approach are dual-stack devices, that is, routers or end nodes that implement both IPv4 and IPv6 an allow communication with both protocols, using IPv6 when possible and switching to IPv4 when needed. This requires applications to be version-aware: clients need to choose between IPv4 or IPv6 before initiating communications and servers need to accept both types of packets. Host discovery can be performed very easily on networks equipped with dual-stack nodes, as an attacker may detect active hosts "falling-back to IPv4", as this considerably reduces the search space. Once the attacker learns a host's IPv4 address, he may use that address to perform whatever action he needs. However, there may be services that are only accessible through IPv6. In this case the attacker would need to determine the host's IPv6 address from the IPv4 one. This process may be a bit tricky: If the attacker is on the same link as its target, he could try to use the Neighbor Discovery protocol to perform MAC-to-IPv6 address resolution. Unfortunately, the equivalent of inverse ARP is not available in IPv6, so the following protocol is proposed: 1. Use ARP to obtain the host's MAC address from its IPv4 address. 2. Create an Ethernet frame destined to the MAC address obtained in step 1. 3. Create an IPv6 header with destination address FF02::1 (the link-local all-nodes multicast address). 4. Create an ICMPv6 Echo request message. 5. Concatenate the headers created in steps 2, 3 and 4 and place them on the wire. 6. Listen for an ICMPv6 Echo response whose Ethernet source MAC address matches the address obtained in step 1. 7. Extract the source address from the received IPv6 header. Note that if Stateless Address Autoconfiguration is used, steps 2 through 7 can be skipped, as the network prefix can be determined from Router Advertisement messages and the interface identifier is easily derived from the MAC address in step 1. If the attacker is not on the same link as the host, reverse DNS lookup could be used to obtain the host name associated with the IPv4 address. Once the host name is known, the DNS system may be queried again to obtain the AAAA resource record associated with it. There is also the case where IPv6 addresses are derived from IPv4 addresses. Examples include IPv4-compatible (::a.b.c.d ) and IPv4-mapped addresses (::FFFF:a.b.c.d ) where a, b, c and d correspond to the four octets of an IPv4 address [17]. In this case, there would be no need to use the DNS system since the conversion is straightforward. ----[ 0x06.3 - Traceroute Unlike ICMP for IPv4, ICMPv6 has features that are required for the operation of IPv6 and therefore, it cannot be completely filtered by firewalls. For this reason IPv6 networks are more likely to allow inbound and outbound ICMP messages. This can be exploited by attackers to gather information about a network. For example, assuming a /48 network prefix is known, an attacker may perform traceroute using packets with increasing values for the TTL and varying the 16-bit subnet identifier of the target address. This way, once the TTL is high enough to reach the border router but not enough to traverse the subnet routers, these subnet routers will send ICMP Time Exceeded messages, which will reveal their IP addresses. Fig. 1 shows an example of a typical IPv6 network. In that scenario, the attacker is 10 hops away from the border router. An IPv6 packet with TTL=10 destined to any host on the 2001:218:2::/48 network will be dropped by that router and an ICMPv6 Time Exceeded message will be sent to the originating address. Packets with TTL=11 will be dropped by second-level routers, and so on. Unless Time Exceeded messages are blocked by some intermediate device, if the attacker sends IP packets targeted to addresses on all 2^16 possible subnet identifiers, he will be able to obtain the address of all routers on the network. 2001:218:2:6002::/64 2001:218:2:6001/64 [ROUTER] [ROUTER] \ / \ / \ / \ / [ROUTER] 2001:128:2:6000::/60 \ \ [ROUTER] 2001:218:2:1000::/64 .... \ / () ( ) \ / ( )------( INET )------[ROUTER] 2001:218:2::/48 USER ( ) '''' |<----------------------->| 10 Hops === Figure 2: Example of an IPv6 network. --[ 0x07 - Other Host Discovery Techniques This section discusses techniques that allow host discovery, regardless of the position of the attacker. ----[ 0x07.1 - Using DNS to gather addresses The DNS system is an essential part in today's networks. Although DNS is normally used for legitimate purposes, it can be used by an attacker to discover hosts on a network [4]. For this, the attacker first needs to know the address of the primary DNS server of the network he is targeting. This is trivial if a top level domain is known as the Internet public DNS infrastructure can be used to determine the authorized servers for the zone. In cases where the attacker is on-link, DNS server addresses may be gathered in any of the following ways: * Through DHCPv6 if the attacker's host is able to obtain configuration parameters from the local DCHPv6 server. * Through a currently experimental protocol defined by the IETF that allows DNS recursive server advertising in ICMPv6 Router Advertising messages [18]. Attackers may listen for RA messages to learn the address of local DNS servers. This may be useful when DHCPv6 has security restrictions in place. * Eavesdropping on the network until a DNS query is observed. Once the address of the local DNS is known, the following techniques may be used for the discovery of active hosts. ------[ 0x07.1.1 - DNS zone transfers A DNS zone transfer is a type of DNS transaction that allows easy replication of DNS databases across a set of DNS servers. Zone transfers are mainly used by administrators to keep primary and secondary DNS servers synchronized. The operation is performed in the form of a a client/server transaction in which the client requests the transmission of the DNS registry through a query operation with an special query type of value AXFR. The server responds with one or more response messages that list all of the resource records for every domain name in its zone. The DNS specification does not impose restrictions on which hosts can request and receive a full zone transfer for a domain, so in theory, any client may obtain important information about the topology of the nodes in the DNS zone, just by issuing a zone transfer request. However, the revelation of full DNS zone data is a known security issue and most DNS server implementations have mechanisms to restrict zone transfers. ------[ 0x07.1.2 - DNSSEC zone enumeration The Domain Name System Security Extensions (DNSSEC) is a suite of specifications that intend to improve the security of the DNS system. Essentially DNSSEC introduces authenticated DNS responses that clients can check to ensure they have not been forged. However, the original DNSSEC specification introduced a new problem. When a client requests the resolution of a name that is not registered in the DNS server, the server sends a reply that contains an NSEC resource record. This NSEC RR points to the next valid name in the zone file and is used to provide proof of non-existence of any name within a zone. This technique, commonly known as DNS zone walking, can be used by a malicious client to enumerate the entire DNS zone by issuing requests for non-existent names based on the names provided in the NSEC RRs. Although RFC 4470 and RFC 5155 were developed to address this issue, early implementations may be vulnerable to the attack. ------[ 0x07.1.3 - Dictionary attacks Even when it is not possible to perform a zone transfer operation, it is possible to conduct dictionary attacks against the target's DNS servers. Assuming the top-level domain name is known, sub-domains (and therefore IP addresses) may be discovered by actively interrogating the server for names of the form XXXX.YYYY where YYYY is the known top-level name and XXXX is a word, or a combination of words, extracted from a given dictionary. Dictionaries may contain regular words or may be constructed a bit more sophisticatedly, taking into account names and frequency data obtained empirically. ------[ 0x07.1.4 - Brute-force attacks Host names are rarely created randomly but usually follow certain patterns. While in certain cases those patterns may be difficult to recognize without human intervention, in other cases simple pattern recognition algorithms may be applied to detect semantically assigned names, fixed names appended with increasing numbers, etc. Even when no pattern is recognized, the search space for DNS names is likely to be shorter than the 2^64 possible addresses in a typical IPv6 subnet. If we consider the DNS search space of a particular zone to be given by the expression n^k where n is the the size of the allowed character set and k is the length of the unknown part of the longest record in the DNS registry, it is easy to determine the feasibility of the brute-force attack. Although in theory DNS names may contain any character that can be represented with an octet, in practice, there is a preferred form, the one permitted in the names of top-level domains, that consists of the ASCII alphabetic and numeric characters, plus the hyphen [19]. This, combined with the fact that DNS names are case insensitive, means that n = 37 may be enough for most cases. ----[ 0x07.2 - Hosts configured by stateless autoconfiguration IPv6 defines a mechanism that allows hosts to autoconfigure their network interfaces. This mechanism, called IPv6 Stateless Address Autoconfiguration (SLAAC), allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet associated with a link and hosts generate interface identifiers that uniquely identify an interface on the subnet. The final IPv6 address is formed by combining the two. In the absence of routers, a host only generates link-local addresses, which are sufficient for allowing communication among nodes attached to the same link [20]. End nodes derive interface identifiers from their link layer hardware addresses. In Ethernet networks, the IEEE's 64-bit Extended Unique Identifier (EUI-64) format is used. The identifier is generated from the interface's 48-bit MAC address, which is expanded to 64 bits by inserting two octets with values 0xFF and 0xFE between the Organizationally Unique Identifier (OUI) and the interface specific ID, and changing the seventh bit from the left (the universal/local bit) from a 0 to a 1. This process significantly reduces the entropy of the host identifier part of an IPv6 address, as it adds a fixed 16-bit value and narrows the first 24 bits of the host ID to the OUIs currently assigned by the IEEE. At time of writing, there are 17,032 public OUIs assigned [21], that is, about than 2^14, which, providing the prefix is known, reduces the address space to 2^38. Although brute-forcing a 2^38 space takes a considerable amount of time, it is certainly computationally feasible, just like it is to conduct an exhaustive search in the current IPv4 space 64 times. Moreover, a significant amount of those OUIs are not likely to be found on standard networks, as they may be assigned to companies that operate on very specific areas like satellite communications, aerospace engineering, surveillance systems, etc. Therefore, an attacker may reduce the vendor search space by sorting the list of assigned OUIs in descending order of importance for the network he is targeting, and conducting the brute-force search from the top of the list until the n-th item, where n is determined by the attacker, based on the time and resources that he is willing to invest. The list of vendors may be reduced using different criteria: * Some corporate networks may have very homogeneous equipment. Batches of machines from the same vendor are likely to have the same Ethernet OUIs. If the attacker already knows one autoconfigured IP address on the target network, he could set the first 104 bits and brute-force the remaining 24. * It seems reasonable to assume that the more OUIs a vendor has been assigned, the more devices it has on the market, as they are required to consume more than 90% of the available final 24 bits of MAC addresses in order to obtain a new OUI allocation [22]. Therefore, the chances of finding devices of these vendors are higher than for those with fewer OUIs. For this reason, an attacker may choose to reduce the search space to the most popular vendors, as this may increase the chances of finding active hosts. For example, discarding all vendors but the most important 10, results in a list of approximately 2^10 OUIs, which reduces the search space to 2^34. Table 2 lists the Top-10 vendors with the highest amount of OUIs assigned. * Data about the history of OUI assignments would allow attackers to narrow the OUI space if they had an approximate idea of when their target network's equipment was acquired. * Passive eavesdropping of Neighbor Advertisement messages and other types of traffic may offer link-layer addresses and, consequently, vendor OUIs to use in an exhaustive search. +-------------------+---------------+ | Vendor | OUIs assigned | +-------------------+---------------+ | Cisco | 505 | | Apple | 176 | | Samsung | 147 | | Nokia | 135 | | Motorola | 127 | | Intel | 101 | | Hewlett Packard | 79 | | Nortel Networks | 70 | | Hon Hai | 67 | | Texas Instruments | 66 | +-------------------+---------------+ === Table 2: Top 10 vendors in the IEEE list of assigned OUIs. Once the list of OUIs is determined, the attacker has to conduct a brute-force search against the remaining 24 bits of the address for each OUI on the list. Although in theory the distribution of those bits is random, vendors are likely to assign the final 24 bits sequentially and, therefore, equipment acquired in a given country or in a big batch is likely to have identifiers whose values are closer than in a truly random distribution. For this reason, instead of sweeping the whole /24 range sequentially, it may be a better idea to sweep it randomly and, whenever an active host is found, target a range of adjacent addresses. ----[ 0x07.3 - Exploiting manual address assignment Habits are hard to change and because there is no stateless address autoconfiguration in IPv4, network administrators may manage their IPv6 networks just like they did with IPv4. This means that, in certain cases, a given subnet may have all of its hosts addresses assigned manually. Administrators may chose to keep their existing addressing scheme, porting their previous IPv4 address configuration to the IPv6 address space. This way, addresses would be concentrated in a certain point of the space, leaving the rest completely empty. For this reason, attackers may choose to probe different distant parts of the available space in order to detect single hosts that belong to clusters of hosts, and then, probe a set of contiguous addresses to discover adjacent hosts. Even when no previous IPv4 network existed, for convenience, administrators may choose to configure network server addresses in the low end of the subnet range so it may be wise to start looking from there. Let f(k) be a function that checks whether the host with the k-th possible address is active, to find one host in a cluster of 2^n hosts, inside a 2^64 address space, f(k) needs to be called 2^(64-n) times (2^(64-n-1) times on average), using increasing values of k in the set (2^(n-1))g where g belongs to {0, 1, 2..., 2^(64-n)}. For example, if a given /64 subnet contains a cluster of 2^16 hosts (equivalent to a densely populated IPv4 class B network), assuming an attacker is capable of actively probing 2^24 hosts per second, it would take an average of 2^(64-16-1-24) = 2^23 seconds, or about 97 days, to find a host that belongs to the cluster. After that host is discovered, sequential search may be used to find the rest of hosts in the cluster. Manual address assignment may also be performed following certain semantic or syntactic rules. Some authors suggest that administrators are likely to use human readable addresses such as 2001:db8::cafe:babe:f00d[6]. To take an example, at time of writing, Facebook uses the address 2a03:2880:10:cf01:face:b00c:: for their IPv6 accessible site facebook.com. This behavior could be exploited, conducting dictionary attacks based on words that can be spelled with the symbols of the hexadecimal system. [Appendix B] presents a simple script to extract all the words that can be written with letters A through F from a given wordlist. A number of wordlists are freely available from [23]. ----[ 0x07.4 - Discovery based on local information The purpose of self-replicating malware is to find other hosts to infect. As opposed to network scanners, which need to discover hosts in a particular network, Internet worms don't usually care about the location of hosts or the topology of the network, and therefore, any IP address is equally valuable. Once a host has been compromised, malware may gather IP addresses silently from the information that is stored on that host. There are many places where such information can be obtained. These are a few possibilities: * The Neighbor cache is a good source of information for addresses of other hosts on the same link. The cache is organized as a set of entries about neighbors to which traffic has been sent recently. Entries contain various pieces of information about a neighbor such as its unicast IP address, its link-layer address, a flag that indicates whether it is a router or a regular host, parameters for the Neighbor Unreachability Detection algorithm, etc. * If the local system has a DNS server running on it, its registry database can be read from disk to obtain the addresses of all registered hosts. * Web browsers and mail user agents are also a good source of information. Although these are unlikely to provide IP addresses, bookmark files, cache entries, address books and configuration files may contain host names that can be resolved to IP addresses through standard DNS queries. * Some authors suggest checking the SSH known.hosts file [5], which contains a list of known SSH server host names with their public keys. However, popular implementations like OpenSSH hash the host names before their inclusion on the list so, in some cases, it's unlikely the known.hosts file yields any useful information. * The local operating system can be queried for information on active connections. * Firewall logs are also likely to contain addresses logged as a result of significant events. * If the system hosts traffic monitoring software like intrusion detection systems or sniffers, traffic capture files and incident logs may be processed for addresses. * Local routing tables contain the addresses of adjacent routers. --[ 0x08 - Conclusions It is clear that the new version of the Internet Protocol introduces important challenges for the propagation of malware and the discovery of active hosts on a network. While simple techniques like random scanning or sequential ping sweeps are successfully used in today's IPv4 world, when IPv6 is completely deployed, more sophisticate methods need to be used in order to reduce the address search space and make host discovery feasible. This paper has presented a number of techniques that future network scanning tools and self-replicating malware may use during and after the transition to IPv6. Although those techniques allow to reduce the search space by several orders of magnitude, the discovery of network hosts will be a lot harder with IPv6 and things like complete subnet sweeps or Internet-scale scanning may never be possible again. However, the situation may change over the years. It is possible that future advances in technology, the continuous increase of devices connected to the network and the development of new protocols and standards, have a positive impact on the feasibility of network scans. The list of techniques presented in this paper is incomplete, as there are several areas that have been left out of the scope of this research. Some examples are the operation of IPv6 in non-Ethernet networks, the protocols that provide Mobility for IPv6 or the different transition mechanisms other than the dual stack approach. Also, future research should undergo more rigorous testing of final implementations of the IPv6 protocol family. IPv6 is a complex protocol, defined over the time through many different RFCs, and this may cause errors and misinterpretations, as well as significant differences between early implementations and newer ones. --[ References [1] IANA. (2010). "IPv4 Address Space Registry". The Internet Assigned Numbers Authority. United States. [Available on-line] http://www.iana.org/assignments/ipv4-address-space/ ipv4-address-space.txt [2] Huston, G. (2010). "IPv4 Address Report 04-Nov-2012 08:00 UTC". Centre for Advanced Internet Architectures. United States. [Available on-line] http://www.potaroo.net/tools/ipv4/ [3] Huitema, C. (1998). "IPv6: The New Internet Protocol". Prentice Hall PTR. United States. [4] Chown, T. (2008). "IPv6 Implications for Network Scanning". RFC 5157. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc5157.txt [5] Bellovin, SM., Cheswick, B. and Keromytis AD. (2006). "Worm Propagation Strategies in an IPv6 Internet". ;login: The USENIX Magazine. February 2006, Volume 31, Number 1. The USENIX Association. United States. [Available on-line] http://www.cs.columbia.edu/~smb/papers/v6worms.pdf [6] Hogg, S. and Vyncke, E. (2009). "IPv6 Security: Protection measures for the next Internet Protocol". Cisco Press. Indianapolis, United States. [7] Van Hauser. (2011). "The Hacker's Choice IPv6 Attack Toolkit". The Hacker's Choice. [Available on-line] http://www.thc.org/thc-ipv6/ [8] Zesheng, C. and Chuanyi, J. "An Information-Theoretic View of Network-Aware Malware Attacks". Department of Electrical and Computer Engineering, Florida International University, Miami, and School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta. United States. [Available on-line] http://users.ece.gatech.edu/~jic/infoattack.pdf [9] Lyon, G. "The Nmap Security Scanner". Insecure.Com LLC. [Available on-line] http://nmap.org [10] Deering, S., Haberman, B., Jinmei, T., Nordmark, E. and Zill, B. "IPv6 Scoped Address Architecture". RFC 4007. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc4007.txt [11] Arkko, J., Aura, T., Kempf, J., Ma"ntyla", VM., Nikander, P. and Roe, M. (2002). "Securing IPv6 Neighbor and Router Discovery". WiSe '02, September 28, 2002, Atlanta, Georgia, USA. [Available on-line] http://portal.acm.org/citation.cfm?id=570690 [12] Narten, T., Nordmark, E., Simpson, W. and Soliman, H. (2007). "Neighbor Discovery for IP version 6 (IPv6)". RFC 4861. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc4861.txt [13] Hauser, V. (2008) "Attacking the IPv6 Protocol Suite". THC, The Hacker's Choice. [Available on-line] http://freeworld.thc.org/papers/vh_thc-ipv6_attack.pdf [14] Deering, S., Fenner, W. and Haberman, B. (1999) "Multicast Listener Discovery (MLD) for IPv6". RFC 2710. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc2710.txt [15] Crawford, M. and Haberman, B. (2006). "IPv6 Node Information Queries". RFC 4620. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc4620.txt [16] Conta, A. and Deerin, S. (1998) "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification". RFC 2463. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc2463.txt [17] Hinden, R. and Deering, S. (2006). "IP Version 6 Addressing Architecture". RFC 4291. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc4291.txt [18] Jeong, J., Park, S., Beloeil, L. and Madanapalli, S. (2007). "IPv6 Router Advertisement Option for DNS Configuration". RFC 5006. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc5006.txt [19] Klensin, J. (2004). "Application Techniques for Checking and Transformation of Names". RFC 3696. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc3696.txt [20] Thomson, S. and Narten T. (1998) "IPv6 Stateless Address Autoconfiguration". RFC 1971. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc1971.txt [21] IEEE. (2011). "OUI Public Listing: Public OUT and COMPANY.ID Assignments". IEEE Registration Authority, United States. [Available on-line] http://standards.ieee.org/develop/regauth/oui/oui.txt [22] IEEE. "Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48)". Institute of Electrical and Electronics Engineers, Inc. [Available on-line] http://standards.ieee.org/develop/regauth/tut/eui48.pdf [23] Atkinson, K. "Kevin's Word List Page". [Available on-line] http://wordlist.sourceforge.net/ [24] IANA. (2013). "IPv6 Multicast Address Space Registry". The Internet Assigned Numbers Authority. United States. [Available on-line] http://www.iana.org/assignments/ipv6-multicast-addresses/ ipv6-multicast-addresses.xml [25] SI6 Networks (2012). "The IPv6 Toolkit". SI6 Networks. [Available on-line] http://www.si6networks.com/tools/ipv6toolkit/ [26] Christensen, M., Kimball, K. and Solensky, F. (2006). "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches". RFC 4541. Network Working Group. Internet Engineering Task Force. [Available on-line] http://www.ietf.org/rfc/rfc4541.txt --[ Appendix A This appendix presents network configuration details for all the machines in the experimental lab. ############## #FreeBSD 9.0 # ############## # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0c:29:3f:7f:9a inet6 fe80::20c:29ff:fe3f:7f9a%em0 prefixlen 64 scopeid 0x2 inet 192.168.158.137 netmask 0xffffff00 broadcast 192.168.158.255 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active Note in FreeBSD 9, IPv6 needed to be enabled explicitely by editing rc.conf and adding the following lines: ip6addrctl_enable="YES" ip6addrctl_policy="ipv6_prefer" ifconfig_em0_ipv6="inet6 accept_rtadv" ############## # CentOS 6.3 # ############## [root@CENTOS63 ~]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0C:29:ED:19:21 inet addr:192.168.158.138 Bcast:192.168.158.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:feed:1921/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:387 errors:0 dropped:0 overruns:0 frame:0 TX packets:194 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:39186 (38.2 KiB) TX bytes:26509 (25.8 KiB) ############## # NetBSD 5.0 # ############## netbsd5# ifconfig pcn0 pcn0: flags=8843 mtu 1500 address: 00:0c:29:d0:48:b4 media: Ethernet autoselect (autoselect) inet 192.168.158.135 netmask 0xffffff00 broadcast 192.168.158.255 inet6 fe80::20c:29ff:fed0:48b4%pcn0 prefixlen 64 scopeid 0x1 ############### # OpenBSD 3.8 # ############### # ifconfig pcn0 pcn0: flags=8843 mtu 1500 lladdr 00:0c:29:13:a6:9b media: Ethernet autoselect (autoselect) inet6 fe80::20c:29ff:fe13:a69b%pcn0 prefixlen 64 scopeid 0x1 inet 192.168.158.128 netmask 0xffffff00 broadcast 192.168.158.255 ############# # Windows 8 # ############# c:\>ipconfig /all Ethernet adapter Ethernet: Connection-specific DNS Suffix . : localdomain Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection Physical Address. . . . . . . . . : 00-0C-29-08-88-D4 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::3c3a:dde0:fcc7:71f3%12(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.158.136(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Friday, February 15, 2013 10:41:43 AM Lease Expires . . . . . . . . . . : Friday, February 15, 2013 11:11:43 AM Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.158.254 DHCPv6 IAID . . . . . . . . . . . : 251661353 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-0A-8F-DE-00-0C-29-08-88-D4 DNS Servers . . . . . . . . . . . : 192.168.158.1 NetBIOS over Tcpip. . . . . . . . : Enabled ####################### # Windows Server 2012 # ####################### PS C:\> ipconfig Windows IP Configuration PS C:\Users\Administrator> ipconfig /all Ethernet adapter Ethernet: Connection-specific DNS Suffix . : localdomain Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection Physical Address. . . . . . . . . : 00-0C-29-D9-00-11 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::18f5:1a6d:4a60:37a2%12(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.158.134(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Friday, February 15, 2013 10:21:03 AM Lease Expires . . . . . . . . . . : Friday, February 15, 2013 11:06:03 AM Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.158.254 DHCPv6 IAID . . . . . . . . . . . : 251661353 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-09-05-C0-00-0C-29-D9-00-11 DNS Servers . . . . . . . . . . . : 192.168.158.1 NetBIOS over Tcpip. . . . . . . . : Enabled ##################### # Oracle Solaris 11 # ##################### luis@solaris:~$ ifconfig -a lo0: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 net0: flags=1004843 mtu 1500 index 5 inet 192.168.158.139 netmask ffffff00 broadcast 192.168.158.255 lo0: flags=2002000849 mtu 8252 index 1 inet6 ::1/128 net0: flags=20002004841 mtu 1500 index 5 inet6 fe80::20c:29ff:fec4:32d9/10 --[ Appendix B: The following script, written in Python, extracts all the words that can be written with letters A through F from a wordlist files in the current directory. ######################################################################## # This script reads any wordlist file with the extension "txt" in the # # current directory and prints out entries that only contain letters # # used in hexadecimal (A through F). It assumes that wordlists only # # contain one word per line. # # # # Written by Luis MartinGarcia (luis.mgarc@gmail.com) # # # ######################################################################## import os import glob # This function processes the supplied wordlist file and returns an # array with the words that can be written with hex characters def parse_file(wordlist_file): result = [] o = open(wordlist_file,"r") for line in o: line=line.rstrip() for i in range(0, len(line)): if line[i] not in ['a', 'b', 'c', 'd', 'e', 'f'] : break else : if i == len(line)-1: result.append(line) return result; # This function returns the list of file names in the "path" directory, # that have the "ext" extension. def get_file_names_from_dir(path, ext): myfiles=list() for myfile in glob.glob(os.path.join(path, '*'+ ext)): myfiles.append(myfile) return myfiles # Parses all wordlists (files with the "txt" extension) in the current # dir and prints the results def main(): myfiles=get_file_names_from_dir("", "txt") dictionary=[] for i in myfiles: result=parse_file(i) dictionary+=result # Remove duplicates, sort and print dictionary = set(dictionary) dictionary = list(dictionary) dictionary.sort() for word in dictionary: print word # Entry execution point main() --[ Appendix C This appendix presents network captures of all hosts in the experimental lab. Captures cover the startup process, until a login screen is presented to the user. == FREEBSD 9 == luis@aberdeen ~/Desktop/ipv6-discovery/pcaps/startup $ sudo tcpdump -t -r freebsd9.pcap ip6 reading from file freebsd9.pcap, link-type EN10MB (Ethernet) IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 :: > ff02::1:ff3f:7f9a: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fe3f:7f9a, length 24 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:fe3f:7f9a > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:fe3f:7f9a > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:fe3f:7f9a > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:fe3f:7f9a > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:fe3f:7f9a > ip6-allrouters: ICMP6, router solicitation, length 16 == CENTOS 6.3 == luis@aberdeen ~/Desktop/ipv6-discovery/pcaps/startup $ sudo tcpdump -t -r centos63.pcap ip6 reading from file centos63.pcap, link-type EN10MB (Ethernet) IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 :: > ff02::1:ffed:1921: ICMP6, neighbor solicitation, who has fe80::20c:29ff:feed:1921, length 24 IP6 fe80::20c:29ff:feed:1921 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:feed:1921 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:feed:1921 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:feed:1921 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:feed:1921 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:feed:1921 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 = NETBSD 5 == luis@aberdeen ~/Desktop/ipv6-discovery/pcaps/startup $ sudo tcpdump -t -r netbsd5.pcap ip6 reading from file netbsd5.pcap, link-type EN10MB (Ethernet) IP6 :: > ff02::1:ffd0:48b4: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ffd0:48b4, length 24 IP6 :: > ff02::1:ffd0:48b4: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ffd0:48b4, length 24 IP6 :: > ff02::1:ffd0:48b4: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fed0:48b4, length 24 IP6 :: > ff02::2:f736:afa7: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:f736:afa7, length 24 IP6 fe80::20c:29ff:fed0:48b4 > ff02::2:f736:afa7: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:f736:afa7, length 24 == OPENBSD 3.8 == luis@aberdeen ~/Desktop/ipv6-discovery/pcaps/startup $ sudo tcpdump -t -r openbsd38.pcap ip6 reading from file openbsd38.pcap, link-type EN10MB (Ethernet) IP6 :: > ff02::1:ff13:a69b: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff13:a69b, length 24 IP6 :: > ff02::2:f9af:b378: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:f9af:b378, length 24 IP6 :: > ff02::1:ff13:a69b: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fe13:a69b, length 24 IP6 fe80::20c:29ff:fe13:a69b > ff02::1:ff13:a69b: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff13:a69b, length 24 IP6 fe80::20c:29ff:fe13:a69b > ff02::2:f9af:b378: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:f9af:b378, length 24 == WINDOWS 8 == luis@aberdeen ~/Desktop/ipv6-discovery/pcaps/startup $ sudo tcpdump -t -r windows8.pcap ip6 reading from file windows8.pcap, link-type EN10MB (Ethernet) IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 :: > ff02::1:ffc7:71f3: ICMP6, neighbor solicitation, who has fe80::3c3a:dde0:fcc7:71f3, length 24 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allrouters: ICMP6, router solicitation, length 8 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::3c3a:dde0:fcc7:71f3, length 32 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::3c3a:dde0:fcc7:71f3 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.53493 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.53493 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.57027 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::3c3a:dde0:fcc7:71f3.57027 > ff02::1:3.hostmon: UDP, length 27 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.55638 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::3c3a:dde0:fcc7:71f3.55638 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::3c3a:dde0:fcc7:71f3.53790 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::3c3a:dde0:fcc7:71f3.53790 > ff02::1:3.hostmon: UDP, length 22 == WINDOWS SERVER 2012 == luis@aberdeen ~/Desktop/ipv6-discovery/pcaps/startup $ sudo tcpdump -t -r windows2012.pcap ip6 reading from file windows2012.pcap, link-type EN10MB (Ethernet) IP6 :: > ff02::1:ff60:37a2: ICMP6, neighbor solicitation, who has fe80::18f5:1a6d:4a60:37a2, length 24 IP6 fe80::18f5:1a6d:4a60:37a2 > ip6-allrouters: ICMP6, router solicitation, length 8 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::18f5:1a6d:4a60:37a2, length 32 IP6 fe80::18f5:1a6d:4a60:37a2 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::18f5:1a6d:4a60:37a2 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::18f5:1a6d:4a60:37a2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2.50623 > ff02::1:3.hostmon: UDP, length 33 IP6 fe80::18f5:1a6d:4a60:37a2.50623 > ff02::1:3.hostmon: UDP, length 33 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::18f5:1a6d:4a60:37a2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::18f5:1a6d:4a60:37a2.52351 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.52351 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.56201 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.56201 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::18f5:1a6d:4a60:37a2.59061 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.51629 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.52348 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.50941 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.64944 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.59061 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.51629 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.52348 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.50941 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.64944 > ff02::1:3.hostmon: UDP, length 24 IP6 fe80::18f5:1a6d:4a60:37a2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2.52723 > ff02::1:3.hostmon: UDP, length 33 IP6 fe80::18f5:1a6d:4a60:37a2 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::18f5:1a6d:4a60:37a2.52723 > ff02::1:3.hostmon: UDP, length 33 IP6 fe80::18f5:1a6d:4a60:37a2.61452 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.61452 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.59109 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.59109 > ff02::1:3.hostmon: UDP, length 22 IP6 fe80::18f5:1a6d:4a60:37a2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit == ORACLE SOLARIS 11 == luis@aberdeen ~/Desktop/ipv6-discovery/pcaps/startup $ sudo tcpdump -t -r oraclesolaris11.pcap ip6 reading from file oraclesolaris11.pcap, link-type EN10MB (Ethernet) IP6 :: > ff02::1:ffc4:32d9: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fec4:32d9, length 24 IP6 :: > ff02::1:ffc4:32d9: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fec4:32d9, length 24 IP6 :: > ff02::1:ffc4:32d9: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fec4:32d9, length 24 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:fec4:32d9, length 32 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:fec4:32d9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:fec4:32d9, length 32 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allnodes: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:fec4:32d9, length 32 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:fec4:32d9 > ip6-allrouters: ICMP6, router solicitation, length 16 IP6 fe80::20c:29ff:fec4:32d9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:fec4:32d9.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::20c:29ff:fec4:32d9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:fec4:32d9.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::20c:29ff:fec4:32d9.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::20c:29ff:fec4:32d9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 fe80::20c:29ff:fec4:32d9.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::20c:29ff:fec4:32d9.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::20c:29ff:fec4:32d9.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit IP6 fe80::20c:29ff:fec4:32d9.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit