A document with the said title, aimed at specific environments (with high security requirements) which are willing to spend significant resources for hardening.
Details can be found at http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/.

> I took a look at the tracepath information you sent for these nodes,
> which showed a bunch of unresponsive nodes but no information that
> might be useful for assigning blame.  It’d be cool to see these paths
> with scamper’s pmtud traceroute, which tries to find out the MTU for
> the hops that aren’t sending a PTB.
>
> with that list of IP addresses:
> scamper -c “trace -P udp-paris -M” -f <file>

though I used:

(for i in `cat f`; do echo “==================== $i”; tracepath6 -n $i; scamper -I “trace -P udp-paris -M $i”; done) >>f.out

This to show the difference between tracepath6 and scamper output, there are some to be seen, some quite scary (eg the 1455 change).
Could be that one just gets through the ICMP ratelimits in one run and not the other.

Those nodes are just blackholes it seems. Only the operators of that network will know what is going on.

I am always surprised to see networks filtering out packets, and especially wonder what they are trying to achieve with such a filter.

> http://www.caida.org/tools/measurement/scamper/
> http://www.caida.org/~mjl/pubs/debugging-pmtud.imc2005.pdf
>
> Happy to help anyway I can (I wrote scamper)

I am quite aware. Great tool, but not very verbose unfortunately. Hence, typically it just does/outputs nothing.

Greets,
Jeroen

MAC bindings

In the IPv4 world, the DHCP server allocates IPv4 addresses and thereby stores the MAC addresses of the clients. In the IPv6 world, if SLAAC (autoconfiguration) is used, no network or security device per se stores the binding between the MAC (layer 2) and the IPv6 (layer 3) addresses from the clients. That is, a subsequent analysis of network behaviour corresponding to concrete IPv6 addresses and their client machines is not possible anymore.

6MoN

is a network monitoring software developed to detect the behavior of hosts on big LANs. By its nature can be an aid for the network administrator to identify anomalies on a LAN. The tool is able to identify the presence of a node indicating the association between MAC, IPv4 and IPv6 address, maintains an history of network access and any changes in presence of mechanisms for automatic address assignment (DHCP, SLAAC ).

ipv6mon

is a tool meant for monitoring IPv6 address usage on a local network. It is meant to be particularly useful in networks that employ IPv6 Stateless Address Auto-Configuration (as opposed to DHCPv6), where address assignment is decentralized and there is no central server that records which IPv6 addresses have been assigned to which nodes during which period of time.

ipv6mon employs active probing to discover IPv6 addresses in use, and determine whether such addresses remain active.

NAV

is an acronym for Network Administration Visualized. It is an advanced software suite to monitor large computer networks. It automatically discovers network topology, monitors network load and outages, and can send alerts on network events by e-mail and SMS, allowing for flexible configuration of alert profiles.

NDPmon

 is a diagnostic software application used by Internet Protocol version 6 network administrators for monitoring ICMPv6 packets. NDPMon observes the local network for anomalies in the function of nodes using Neighbor Discovery Protocol (NDP) messages, especially during the Stateless Address Autoconfiguration. When an NDP message is flagged, it notifies the administrator by writing to the syslog or by sending an email report. It may also execute a user-defined script. For IPv6, NDPMon is an equivalent of Arpwatch for IPv4, and has similar basic features with added attacks detection.