Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

in Index   Prev   Next
in Index   Prev   None  Group: OPSEC

RFC 7707

Network Reconnaissance in IPv6 Networks

Pages: 38
Obsoletes:  5157
Part 2 of 2 – Pages 23 to 38
First   Prev   None

Top   ToC   Page 23   prevText
5.  Alternative Methods to Glean IPv6 Addresses

   The following subsections describe alternative methods by which an
   attacker might attempt to glean IPv6 addresses for subsequent

5.1.  Leveraging the Domain Name System (DNS) for Network Reconnaissance

5.1.1.  DNS Advertised Hosts

   Any systems that are "published" in the DNS, e.g., Mail Exchange (MX)
   relays or web servers, will remain open to probing from the very fact
   that their IPv6 addresses are publicly available.  It is worth noting
   that where the addresses used at a site follow specific patterns,
   publishing just one address may lead to an attack upon the other

   Additionally, we note that publication of IPv6 addresses in the DNS
   should not discourage the elimination of IPv6 address patterns: if
   any address patterns are eliminated from addresses published in the
   DNS, an attacker may have to rely on performing dictionary-based DNS
   lookups in order to find all systems in a target network (which is
   generally less reliable and more time/traffic consuming than mapping
   nodes with predictable IPv6 addresses).

5.1.2.  DNS Zone Transfers

   A DNS zone transfer (DNS query type "AXFR") [RFC1034] [RFC1035] can
   readily provide information about potential attack targets.
   Restricting zone transfers is thus probably more important for IPv6,
   even if it is already good practice to restrict them in the IPv4

5.1.3.  DNS Brute Forcing

   Attackers may employ DNS brute-forcing techniques by testing for the
   presence of DNS AAAA records against commonly used host names.
Top   ToC   Page 24
5.1.4.  DNS Reverse Mappings

   [van-Dijk] describes an interesting technique that employs DNS
   reverse mappings for network reconnaissance.  Essentially, the
   attacker walks through the "" zone looking up PTR records, in
   the hopes of learning the IPv6 addresses of hosts in a given target
   network (assuming that the reverse mappings have been configured, of
   course).  What is most interesting about this technique is that it
   can greatly reduce the IPv6 address search space.

   Basically, an attacker would walk the zone corresponding to
   a target network (e.g., "" for
   "2001:db8:80::/48"), issuing queries for PTR records corresponding to
   the domain names "",
   "", etc.  If, say, there were PTR
   records for any hosts "starting" with the domain name
   "" (e.g., the domain name
   corresponding to the IPv6 address 2001:db8:80::1), the response would
   contain an RCODE of 0 (no error).  Otherwise, the response would
   contain an RCODE of 4 (NXDOMAIN).  As noted in [van-Dijk], this
   technique allows for a tremendous reduction in the "IPv6 address"
   search space.

      Some name servers, incorrectly implementing the DNS protocol,
      reply NXDOMAIN instead of NODATA (NOERROR=0 and ANSWER=0) when
      encountering a domain without any resource records but that has
      child domains, something that is very common in (these
      domains are called ENT for Empty Non-Terminals; see [RFC7719]).
      When scanning, this behavior may slow down or completely
      prevent the exploration of  Nevertheless, since such
      behavior is wrong (see [NXDOMAIN-DEF]), one cannot rely on it to
      "secure" against tree walking.

      [IPv6-RDNS] analyzes different approaches and considerations for
      ISPs in managing the zone for IPv6 address space assigned
      to many customers, which may affect the technique described in
      this section.

5.2.  Leveraging Local Name Resolution and Service Discovery Services

   A number of protocols allow for unmanaged local name resolution and
   service.  For example, mDNS [RFC6762] and DNS Service Discovery (DNS-
   SD) [RFC6763], or Link-Local Multicast Name Resolution (LLMNR)
   [RFC4795], are examples of such protocols.
Top   ToC   Page 25
      Besides the Graphical User Interfaces (GUIs) included in products
      supporting such protocols, command-line tools such as mdns-scan
      [mdns-scan] and mzclient [mzclient] can help discover IPv6 hosts
      employing mDNS/DNS-SD.

5.3.  Public Archives

   Public mailing-list archives or Usenet news messages archives may
   prove to be a useful channel for an attacker, since hostnames and/or
   IPv6 addresses could be easily obtained by inspection of the (many)
   "Received from:" or other header lines in the archived email or
   Usenet news messages.

5.4.  Application Participation

   Peer-to-peer applications often include some centralized server that
   coordinates the transfer of data between peers.  For example,
   BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks
   of files, with a tracker passing information about peers with
   available chunks of data between the peers.  Such applications may
   offer an attacker a source of peer addresses to probe.

5.5.  Inspection of the IPv6 Neighbor Cache and Routing Table

   Information about other systems connected to the local network might
   be readily available from the Neighbor Cache [RFC4861] and/or the
   routing table of any system connected to such network.  Source
   Address Validation Improvement (SAVI) [RFC6620] also builds a cache
   of IPv6 and link-layer addresses (without actively participating in
   the Neighbor Discovery packet exchange) and hence is another source
   of similar information.

   These data structures could be inspected via either "login" access or
   SNMP.  While this requirement may limit the applicability of this
   technique, there are a number of scenarios in which this technique
   might be of use.  For example, security audit tools might be provided
   with the necessary credentials such that the Neighbor Cache and the
   routing table of all systems for which the tool has "login" or SNMP
   access can be automatically gleaned.  On the other hand, IPv6 worms
   [V6-WORMS] could leverage this technique for the purpose of spreading
   on the local network, since they will typically have access to the
   Neighbor Cache and routing table of an infected system.

   Section of [OPSEC-IPv6] discusses additional considerations
   for the inspection of the IPv6 Neighbor Cache.
Top   ToC   Page 26
5.6.  Inspection of System Configuration and Log Files

   Nodes are generally configured with the addresses of other important
   local computers, such as email servers, local file servers, web proxy
   servers, recursive DNS servers, etc.  The /etc/hosts file in UNIX-
   like systems, Secure Shell (SSH) known_hosts files, or the Microsoft
   Windows registry are just some examples of places where interesting
   information about such systems might be found.

   Additionally, system log files (including web server logs, etc.) may
   also prove to be a useful source for an attacker.

   While the required credentials to access the aforementioned
   configuration and log files may limit the applicability of this
   technique, there are a number of scenarios in which this technique
   might be of use.  For example, security audit tools might be provided
   with the necessary credentials such that these files can be
   automatically accessed.  On the other hand, IPv6 worms could leverage
   this technique for the purpose of spreading on the local network,
   since they will typically have access to these files on an infected
   system [V6-WORMS].

5.7.  Gleaning Information from Routing Protocols

   Some organizational IPv6 networks employ routing protocols to
   dynamically maintain routing information.  In such an environment, a
   local attacker could become a passive listener of the routing
   protocol, to determine other valid subnets/prefixes and some router
   addresses within that organization [V6-WORMS].

5.8.  Gleaning Information from IP Flow Information Export (IPFIX)

   IPFIX [RFC7012] can aggregate the flows by source addresses and hence
   may be leveraged for obtaining a list of "active" IPv6 addresses.
   Additional discussion of IPFIX can be found in Section of

5.9.  Obtaining Network Information with traceroute6

   IPv6 traceroute [traceroute6] and similar tools (such as path6 from
   [IPv6-Toolkit]) can be employed to find router addresses and valid
   network prefixes.
Top   ToC   Page 27
5.10.  Gleaning Information from Network Devices Using SNMP

   SNMP can be leveraged to obtain information from a number of data
   structures such as the Neighbor Cache [RFC4861], the routing table,
   and the SAVI [RFC6620] cache of IPv6 and link-layer addresses.  SNMP
   access should be secured, such that unauthorized access to the
   aforementioned information is prevented.

5.11.  Obtaining Network Information via Traffic Snooping

   Snooping network traffic can help in discovering active nodes in a
   number of ways.  Firstly, each captured packet will reveal the source
   and destination of the packet.  Secondly, the captured traffic may
   correspond to network protocols that transfer information such as
   host or router addresses, network topology information, etc.

6.  Conclusions

   This document explores the topic of network reconnaissance in IPv6
   networks.  It analyzes the feasibility of address-scanning attacks in
   IPv6 networks and shows that the search space for such attacks is
   typically much smaller than the one traditionally assumed (64 bits).

   Additionally, this document explores a plethora of other network
   reconnaissance techniques, ranging from inspecting the IPv6 Network
   Cache of an attacker-controlled system to gleaning information about
   IPv6 addresses from public mailing-list archives or Peer-to-Peer
   (P2P) protocols.

   We expect traditional address-scanning attacks to become more and
   more elaborated (i.e., less "brute force"), and other network
   reconnaissance techniques to be actively explored, as global
   deployment of IPv6 increases and, more specifically, as more
   IPv6-only devices are deployed.

7.  Security Considerations

   This document reviews methods by which addresses of hosts within IPv6
   subnets can be determined.  As such, it raises no new security
Top   ToC   Page 28
8.  References

8.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <>.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              DOI 10.17487/RFC4380, February 2006,

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              DOI 10.17487/RFC5214, March 2008,
Top   ToC   Page 29
   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
              SAVI: First-Come, First-Served Source Address Validation
              Improvement for Locally Assigned IPv6 Addresses",
              RFC 6620, DOI 10.17487/RFC6620, May 2012,

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,

   [RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
              for IP Flow Information Export (IPFIX)", RFC 7012,
              DOI 10.17487/RFC7012, September 2013,

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,

8.2.  Informative References

              Plonka, D. and A. Berger, "Temporal and Spatial
              Classification of Active IPv6 Addresses", ACM Internet
              Measurement Conference (IMC), Tokyo, Japan, Pages 509-522,
              DOI 10.1145/2815675.2815678, October 2015,

              Wikipedia, "BitTorrent", November 2015,

              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)", UK Centre for the Protection of
              National Infrastructure, (available on request).
Top   ToC   Page 30
              Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              Work in Progress, draft-ietf-6man-default-iids-10,
              February 2016.

   [Ford2013] Ford, M., "IPv6 Address Analysis - Privacy In, Transition
              Out", May 2013,

              Gont, F., "Results of a Security Assessment of the
              Internet Protocol version 6 (IPv6)", DEEPSEC
              Conference, Vienna, Austria, November 2011,

              Gont, F., "IPv6 Network Reconnaissance: Theory &
              Practice", LACSEC Conference, Medellin, Colombia, May
              2013, <

              Gont, F. and W. Liu, "A Method for Generating Semantically
              Opaque Interface Identifiers with Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", Work in
              Progress, draft-ietf-dhc-stable-privacy-addresses-02,
              April 2015.

              Gont, F., Linkova, J., Chown, T., and W. Liu,
              "Observations on the Dropping of Packets with IPv6
              Extension Headers in the Real World", Work in Progress,
              draft-ietf-v6ops-ipv6-ehs-in-real-world-02, December 2015.

              Howard, L., "Reverse DNS in IPv6 for Internet Service
              Providers", Work in Progress, draft-ietf-dnsop-isp-
              ip6rdns-00, October 2015.

              SI6 Networks, "SI6 Networks' IPv6 Toolkit",
Top   ToC   Page 31
              Malone, D., "Observations of IPv6 Addresses", Passive and
              Active Network Measurement (PAM 2008, LNCS 4979),
              DOI 10.1007/978-3-540-79232-1_3, April 2008,

              Poettering, L., "mdns-scan(1) Manual Page",

   [mzclient] Bockover, A., "Mono Zeroconf Project -- mzclient command-
              line tool",

   [nmap2015] Lyon, Gordon "Fyodor", "Nmap 7.00", November 2015,

              Bortzmeyer, S. and S. Huque, "NXDOMAIN really means there
              is nothing underneath", Work in Progress, draft-ietf-
              dnsop-nxdomain-cut-00, December 2015.

              Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
              Security Considerations for IPv6 Networks", Work in
              Progress, draft-ietf-opsec-v6-07, September 2015.

   [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local
              Multicast Name Resolution (LLMNR)", RFC 4795,
              DOI 10.17487/RFC4795, January 2007,

   [RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
              ICMPv6 Messages in Firewalls", RFC 4890,
              DOI 10.17487/RFC4890, May 2007,

   [RFC5157]  Chown, T., "IPv6 Implications for Network Scanning",
              RFC 5157, DOI 10.17487/RFC5157, March 2008,

   [RFC5375]  Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
              and C. Hahn, "IPv6 Unicast Address Assignment
              Considerations", RFC 5375, DOI 10.17487/RFC5375, December
              2008, <>.
Top   ToC   Page 32
   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583,
              DOI 10.17487/RFC6583, March 2012,

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

   [RFC7421]  Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
              Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
              Boundary in IPv6 Addressing", RFC 7421,
              DOI 10.17487/RFC7421, January 2015,

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,

              Gont, F. and W. Liu, "Security Implications of IPv6
              Options of Type 10xxxxxx", Work in Progress, draft-gont-
              6man-ipv6-smurf-amplifier-03, March 2013.

   [THC-IPV6] "THC-IPV6", <>.

              FreeBSD, "FreeBSD System Manager's Manual: traceroute6(8)
              manual page", August 2009, <

   [V6-WORMS] Bellovin, S., Cheswick, B., and A. Keromytis, "Worm
              propagation strategies in an IPv6 Internet", Vol. 31, No.
              1, pp. 70-76, February 2006,

   [van-Dijk] van Dijk, P., "Finding v6 hosts by efficiently mapping
    ", March 2012, <
Top   ToC   Page 33
   [VBox2011] VirtualBox, "Oracle VM VirtualBox User Manual",
              Version 4.1.2, August 2011, <>.

              VMware, "Setting a static MAC address for a virtual NIC
              (219)", VMware Knowledge Base, August 2011,

   [vSphere]  VMware, "vSphere Networking", vSphere 5.5, Update 2,
              September 2014, <
Top   ToC   Page 34
Appendix A.  Implementation of a Full-Fledged IPv6 Address-Scanning Tool

   This section describes the implementation of a full-fledged IPv6
   address-scanning tool.  Appendix A.1 discusses the selection of host
   probes.  Appendix A.2 describes the implementation of an IPv6 address
   scanner for local area networks.  Appendix A.3 outlines the
   implementation of a general (i.e., non-local) IPv6 address scanner.

A.1.  Host-Probing Considerations

   A number of factors should be considered when selecting the probe
   packet types and the probing rate for an IPv6 address-scanning tool.

   Firstly, some hosts (or border firewalls) might be configured to
   block or rate limit some specific packet types.  For example, it is
   usual for host and router implementations to rate-limit ICMPv6 error
   traffic.  Additionally, some firewalls might be configured to block
   or rate limit incoming ICMPv6 echo request packets (see, e.g.,

      As noted earlier in this document, Windows systems simply do not
      respond to ICMPv6 echo requests sent to multicast IPv6 addresses.

   Among the possible probe types are:

   o  ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies),

   o  TCP SYN segments (meant to elicit SYN/ACK or RST segments),

   o  TCP segments that do not contain the ACK bit set (meant to elicit
      RST segments),

   o  UDP datagrams (meant to elicit a UDP application response or an
      ICMPv6 Port Unreachable),

   o  IPv6 packets containing any suitable payload and an unrecognized
      extension header (meant to elicit ICMPv6 Parameter Problem error
      messages), or

   o  IPv6 packets containing any suitable payload and an unrecognized
      option of type 10xxxxxx (meant to elicit an ICMPv6 Parameter
      Problem error message).

   Selecting an appropriate probe packet might help conceal the ongoing
   attack, but it may also be actually necessary if host or network
   configuration causes certain probe packets to be dropped.
Top   ToC   Page 35
   Some address-scanning tools (such as scan6 of [IPv6-Toolkit])
   incorporate support for IPv6 extension headers.  In some cases,
   inserting some IPv6 extension headers in the probe packet may allow
   some filtering policies or monitoring devices to be circumvented.
   However, it may also result in the probe packets being dropped, as a
   result of the widespread dropping of IPv6 packets that employ IPv6
   extension headers (see [IPV6-EXT-HEADERS]).

   Another factor to consider is the address-probing rate.  Clearly, the
   higher the rate, the smaller the amount of time required to perform
   the attack.  However, the probing rate should not be too high, or

   1.  the attack might cause network congestion, thus resulting in
       packet loss.

   2.  the attack might hit rate limiting, thus resulting in packet

   3.  the attack might reveal underlying problems in Neighbor Discovery
       implementations, thus leading to packet loss and possibly even
       Denial of Service.

   Packet loss is undesirable, since it would mean that an "alive" node
   might remain undetected as a result of a lost probe or response.
   Such losses could be the result of congestion (in case the attacker
   is scanning a target network at a rate higher than the target network
   can handle) or may be the result of rate limiting (as it would be
   typically the case if ICMPv6 is employed for the probe packets).
   Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router
   implementations have been found to be unable to perform decent
   resource management when faced with Neighbor Discovery traffic
   involving a large number of local nodes.  This essentially means that
   regardless of the type of probe packets, an address-scanning attack
   might result in a DoS of the target network, with the same (or worse)
   effects as that of network congestion or rate limiting.

   The specific rates at which each of these issues may come into play
   vary from one scenario to another and depend on the type of deployed
   routers/firewalls, configuration parameters, etc.

A.2.  Implementation of an IPv6 Local Address-Scanning Tool

   scan6 [IPv6-Toolkit] is a full-fledged IPv6 local address-scanning
   tool, which has proven to be effective and efficient for the
   discovery of IPv6 hosts on a local network.
Top   ToC   Page 36
   The scan6 tool operates (roughly) as follows:

   1.  The tool learns the local prefixes used for autoconfiguration and
       generates/configures one address for each local prefix (in
       addition to a link-local address).

   2.  An ICMPv6 Echo Request message destined to the all-nodes on-link
       multicast address (ff02::1) is sent from each of the addresses
       "configured" in the previous step.  Because of the different
       source addresses, each probe packet causes the victim nodes to
       use different source addresses for the response packets (this
       allows the tool to learn virtually all the addresses in use in
       the local network segment).

   3.  The same procedure of the previous bullet is performed, but this
       time with ICMPv6 packets that contain an unrecognized option of
       type 10xxxxxx, such that ICMPv6 Parameter Problem error messages
       are elicited.  This allows the tool to discover, e.g., Windows
       nodes, which otherwise do not respond to multicasted ICMPv6 Echo
       Request messages.

   4.  Each time a new "alive" address is discovered, the corresponding
       IID is combined with all the local prefixes, and the resulting
       addresses are probed (with unicasted packets).  This can help to
       discover other addresses in use on the local network segment,
       since the same IID is typically used with all the available
       prefixes for the local network.

      The aforementioned scheme can fail to discover some addresses for
      some implementations.  For example, Mac OS X employs IPv6
      addresses embedding IEEE identifiers (rather than "temporary
      addresses") when responding to packets destined to a link-local
      multicast address, sourced from an on-link prefix.

A.3.  Implementation of an IPv6 Remote Address-Scanning Tool

   An IPv6 remote address-scanning tool could be implemented with the
   following features:

   o  The tool can be instructed to target specific address ranges
      (e.g., 2001:db8::0-10:0-1000).

   o  The tool can be instructed to scan for SLAAC addresses of a
      specific vendor, such that only addresses embedding the
      corresponding IEEE OUIs are probed.
Top   ToC   Page 37
   o  The tool can be instructed to scan for SLAAC addresses that employ
      a specific IEEE OUI or set of OUIs corresponding to a specific

   o  The tool can be instructed to discover virtual machines, such that
      a given IPv6 prefix is only scanned for the address patterns
      resulting from virtual machines.

   o  The tool can be instructed to scan for low-byte addresses.

   o  The tool can be instructed to scan for wordy addresses, in which
      case the tool selects addresses based on a local dictionary.

   o  The tool can be instructed to scan for IPv6 addresses embedding
      TCP/UDP service ports, in which case the tool selects addresses
      based on a list of well-known service ports.

   o  The tool can be specified to scan an IPv4 address range in use at
      the target network, such that only IPv4-based IPv6 addresses are

   The scan6 tool of [IPv6-Toolkit] implements all these techniques/
   features.  Furthermore, when given a target domain name or sample
   IPv6 address for a given prefix, the tool will try to infer the
   address pattern in use at the target network, and reduce the address
   search space accordingly.


   The authors would like to thank Ray Hunter, who provided valuable
   text that was readily incorporated into Section 4.2.1 of this

   The authors would like to thank (in alphabetical order) Ivan Arce,
   Alissa Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc
   Heuse, Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki
   Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke for providing
   valuable comments on earlier draft versions of this document.

   Fernando Gont would like to thank Jan Zorz of Go6 Lab
   <> and Jared Mauch of NTT America for providing
   access to systems and networks that were employed to perform
   experiments and measurements that helped to improve this document.
   Additionally, he would like to thank SixXS <>
   for providing IPv6 connectivity.
Top   ToC   Page 38
   Part of the contents of this document are based on the results of the
   project "Security Assessment of the Internet Protocol version 6
   (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK
   Centre for the Protection of National Infrastructure (CPNI).

   Fernando Gont would like to thank Daniel Bellomo (UNRC) for his
   continued support.

Authors' Addresses

   Fernando Gont
   Huawei Technologies
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706

   Phone: +54 11 4650 8472

   Tim Chown
   Lumen House, Library Avenue
   Harwell Oxford, Didcot. OX11 0SG
   United Kingdom