One of the exercises I keep recommending is to take 5 minutes of traffic form your own network (any network...), and try to explain each packet. Being an "eat your own dogfood" kind of guy, I try to do this myself every so often, and yesterday, after setting up a new IPv6 connection, I came across this neat packet:

IP6 2601:aaaa:bbbb:cccc:1122:33ff:fe44:5566 > 2601:aaaa:bbbb:xxxx:1122:3344:5566:7788: 
    ICMP6, destination unreachable, unknown unreach code (5)
                      

If tcpdump calls an ICMP type "Unknown", things certainly get interesting. If it is IPv6, then that becomes outright exciting and makes you dive for the RFCs. So what's is happening here?

In the end, it is a simple invalid configuration, but something you may find in IPv6 quite commonly. My ISP assigns me an IPv6 prefix via DHCPv6. DHCPv6 has a special feature to do so: "Prefix Delegation" (often abbreviated PD). In my case, my DHCP client "died". Turns out, that as soon as I no longer request the particular prefix, my modem decided that the prefix is no longer mine, and it no longer routed it. Now in IPv4, there is no well defined ICMP message that is sent back if you essentially try to spoof a source IP that doesn't belong to you. Maybe an admin prohibited? In IPv6, we got a specific ICMPv6 code, "5", to indicate what is happening.

Type 1  is used for "unreachable", similar to "3" in ICMPv4. Code 5 is defined in RFC 4443 as "Source address failed ingress/egress policy". This certainly helped me figure out what is going on here.

Here is a quick list of the codes defined for type 1 in RFC 4443:

Again, this is all for type 1. Code 5 and 6 are described as subtypes of 1 (Admin Prohibited)

As a quick tcpdump filter, you have to use "icmp6 and ip[40:2]=0x0105'. tcpdump does not support icmp6 offsets at this point.

[1] https://tools.ietf.org/html/rfc4443

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn