draft-ietf-opsec-ipv6-host-scanning-05.txt   draft-ietf-opsec-ipv6-host-scanning-06.txt 
opsec F. Gont opsec F. Gont
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 5157 (if approved) T. Chown Obsoletes: 5157 (if approved) T. Chown
Intended status: Informational University of Southampton Intended status: Informational University of Southampton
Expires: July 23, 2015 January 19, 2015 Expires: August 9, 2015 February 5, 2015
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-05 draft-ietf-opsec-ipv6-host-scanning-06
Abstract Abstract
IPv6 offers a much larger address space than that of its IPv4 IPv6 offers a much larger address space than that of its IPv4
counterpart. An IPv6 subnet of size /64 can (in theory) accommodate counterpart. An IPv6 subnet of size /64 can (in theory) accommodate
approximately 1.844 * 10^19 hosts, thus resulting in a much lower approximately 1.844 * 10^19 hosts, thus resulting in a much lower
host density (#hosts/#addresses) than is typical in IPv4 networks, host density (#hosts/#addresses) than is typical in IPv4 networks,
where a site typically has 65,000 or less unique addresses. As a where a site typically has 65,000 or less unique addresses. As a
result, it is widely assumed that it would take a tremendous effort result, it is widely assumed that it would take a tremendous effort
to perform address scanning attacks against IPv6 networks, and to perform address scanning attacks against IPv6 networks, and
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2015. This Internet-Draft will expire on August 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5
3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6
3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6
3.1.2. Dynamic Host Configuration Protocol version 6 3.1.2. Dynamic Host Configuration Protocol version 6
(DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10 (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10
3.1.4. IPv6 Addresses Corresponding to Transition/Co- 3.1.4. IPv6 Addresses Corresponding to Transition/Co-
existence Technologies . . . . . . . . . . . . . . . 12 existence Technologies . . . . . . . . . . . . . . . 12
3.1.5. IPv6 Address Assignment in Real-world Network 3.1.5. IPv6 Address Assignment in Real-world Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 13 Scenarios . . . . . . . . . . . . . . . . . . . . . . 13
3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 15 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 16
3.2.1. Reducing the subnet ID search space . . . . . . . . . 16 3.2.1. Reducing the subnet ID search space . . . . . . . . . 16
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 16 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 17
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 17 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 18
3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 17 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 18
3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 18 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 19
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19
4. Leveraging the Domain Name System (DNS) for Network 4. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 20 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 21
4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 20 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 21
4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21
5. Leveraging Local Name Resolution and Service Discovery 5. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 22
7. Application Participation . . . . . . . . . . . . . . . . . . 21 7. Application Participation . . . . . . . . . . . . . . . . . . 22
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22
9. Inspection of System Configuration and Log Files . . . . . . 22 9. Inspection of System Configuration and Log Files . . . . . . 23
10. Gleaning Information from Routing Protocols . . . . . . . . . 23 10. Gleaning Information from Routing Protocols . . . . . . . . . 23
11. Gleaning Information from IP Flow Information Export (IPFIX) 23 11. Gleaning Information from IP Flow Information Export (IPFIX) 23
12. Obtaining Network Information with traceroute6 . . . . . . . 23 12. Obtaining Network Information with traceroute6 . . . . . . . 23
13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Gleaning Information from Network Devices Using SNMP . . . . 23
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 14. Obtaining Network Information via Traffic Snooping . . . . . 24
15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 17. Security Considerations . . . . . . . . . . . . . . . . . . . 24
17.1. Normative References . . . . . . . . . . . . . . . . . . 24 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
17.2. Informative References . . . . . . . . . . . . . . . . . 25 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.1. Normative References . . . . . . . . . . . . . . . . . . 25
19.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Implementation of a full-fledged IPv6 address- Appendix A. Implementation of a full-fledged IPv6 address-
scanning tool . . . . . . . . . . . . . . . . . . . 28 scanning tool . . . . . . . . . . . . . . . . . . . 29
A.1. Host-probing considerations . . . . . . . . . . . . . . . 28 A.1. Host-probing considerations . . . . . . . . . . . . . . . 29
A.2. Implementation of an IPv6 local address-scanning tool . . 30 A.2. Implementation of an IPv6 local address-scanning tool . . 31
A.3. Implementation of a IPv6 remote address-scanning tool . . 31 A.3. Implementation of a IPv6 remote address-scanning tool . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The main driver for IPv6 [RFC2460] deployment is its larger address The main driver for IPv6 [RFC2460] deployment is its larger address
space [CPNI-IPv6]. This larger address space not only allows for an space [CPNI-IPv6]. This larger address space not only allows for an
increased number of connected devices, but also introduces a number increased number of connected devices, but also introduces a number
of subtle changes in several aspects of the resulting networks. One of subtle changes in several aspects of the resulting networks. One
of these changes is the reduced host density (the number of hosts of these changes is the reduced host density (the number of hosts
divided by the number of addresses) of typical IPv6 subnetworks: with divided by the number of addresses) of typical IPv6 subnetworks: with
default IPv6 subnets of /64, each subnet comprises more than 1.844 * default IPv6 subnets of /64, each subnet comprises more than 1.844 *
skipping to change at page 5, line 38 skipping to change at page 5, line 38
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning information from Routing Protocols | Yes | No | | Gleaning information from Routing Protocols | Yes | No |
| (Section 10) | | | | (Section 10) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning Information from IP Flow | No | Yes | | Gleaning Information from IP Flow | No | Yes |
| Information Export (IPFIX) (Section 11) | | | | Information Export (IPFIX) (Section 11) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Obtaining Network Information with | No | No | | Obtaining Network Information with | No | No |
| traceroute6 (Section 12) | | | | traceroute6 (Section 12) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning Information from Network Devices | No | Yes |
| Using SNMP | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information via Traffic | Yes | No |
| Snooping | | |
+---------------------------------------------+----------+----------+
Table 1: Requirements for the Applicability of Network Reconnaissance Table 1: Requirements for the Applicability of Network Reconnaissance
Techniques Techniques
3. IPv6 Address Scanning 3. IPv6 Address Scanning
This section discusses how traditional address scanning techniques This section discusses how traditional address scanning techniques
(e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an (e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an
essential analysis of how address configuration is performed in IPv6, essential analysis of how address configuration is performed in IPv6,
identifying patterns in IPv6 addresses that can be leveraged to identifying patterns in IPv6 addresses that can be leveraged to
skipping to change at page 16, line 24 skipping to change at page 16, line 43
When scanning a remote network, consideration is required to select When scanning a remote network, consideration is required to select
which subnet IDs to choose. A typical site might have a /48 which subnet IDs to choose. A typical site might have a /48
allocation, which would mean up to 65,000 or so host /64 subnets to allocation, which would mean up to 65,000 or so host /64 subnets to
be scanned. be scanned.
However, in the same way the search space for the IID can be reduced, However, in the same way the search space for the IID can be reduced,
we may also be able to reduce the subnet ID space in a number of we may also be able to reduce the subnet ID space in a number of
ways, by guessing likely address plan schemes, or using any ways, by guessing likely address plan schemes, or using any
complementary clues that might exist from other sources or complementary clues that might exist from other sources or
observations. observations. For example there are a number of documents available
online (e.g. [RFC5375]) that provide recommendations for allocation
of address space, which address various operational considerations,
including: RIR assignment policy, ability to delegate reverse DNS
zones to different servers, ability to aggregate routes efficiently,
address space preservation, ability to delegate address assignment
within the organization, ability to add allocate new sites/prefixes
to existing entities without updating ACLs, and ability to de-
aggregate and advertise sub-spaces via various AS interfaces.
Address plans might include use of subnets which: Address plans might include use of subnets which:
o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64, o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64,
etc. etc.
o Use building numbers, in hex or decimal form. o Use building numbers, in hex or decimal form.
o Use VLAN numbers. o Use VLAN numbers.
o Use IPv4 subnet number in a dual-stack target, e.g. a site with a o Use IPv4 subnet number in a dual-stack target, e.g. a site with a
/16 for IPv4 might use /24 subnets, and the IPv6 address plan may /16 for IPv4 might use /24 subnets, and the IPv6 address plan may
re-use the third byte as the IPv6 subnet ID. re-use the third byte as the IPv6 subnet ID.
o Use the service "colour", as defined for service-based prefix o Use the service "colour", as defined for service-based prefix
colouring, or semantic prefixes. For example, a site using a colouring, or semantic prefixes. For example, a site using a
specific colouring for a specific service such as VoIP may reduce specific colouring for a specific service such as VoIP may reduce
the subnet ID search space for those devices. the subnet ID search space for those devices.
The net effect is that the address space of an organization may be
highly structured, and allocations of individual elements within this
structure may be predictable once other elements are known.
In general, any subnet ID address plan may convey information, or be In general, any subnet ID address plan may convey information, or be
based on known information, which may in turn be of advantage to an based on known information, which may in turn be of advantage to an
attacker. attacker.
3.3. IPv6 Address Scanning of Local Networks 3.3. IPv6 Address Scanning of Local Networks
IPv6 address scanning in Local Area Networks could be considered, to IPv6 address scanning in Local Area Networks could be considered, to
some extent, a completely different problem than that of scanning a some extent, a completely different problem than that of scanning a
remote IPv6 network. The main difference is that use of link-local remote IPv6 network. The main difference is that use of link-local
multicast addresses can relieve the attacker of searching for unicast multicast addresses can relieve the attacker of searching for unicast
skipping to change at page 18, line 16 skipping to change at page 18, line 47
the incremental addresses resulting from some DHCPv6 setups. the incremental addresses resulting from some DHCPv6 setups.
Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address
ranges, and can also leverage all the address patterns described in ranges, and can also leverage all the address patterns described in
Section 3.1 of this document. Section 3.1 of this document.
Clearly, a limitation of many of the currently-available tools for Clearly, a limitation of many of the currently-available tools for
IPv6 address scanning is that they lack of an appropriately tuned IPv6 address scanning is that they lack of an appropriately tuned
"heuristics engine" that can help reduce the search space, such that "heuristics engine" that can help reduce the search space, such that
the problem of IPv6 address scanning becomes tractable. the problem of IPv6 address scanning becomes tractable.
The most "advanced" IPv6 scanning technique that has been found in
the wild (and publicly reported) is described in [Ybema2010] (the
attacker seemed to be scanning specific IPv6 addresses based on some
specific patterns). However, the aforementioned attempt probably
still falls into the category of "rudimentary".
It should be noted that IPv6 network monitoring and management tools It should be noted that IPv6 network monitoring and management tools
also need to build and maintain information about the hosts in their also need to build and maintain information about the hosts in their
network. Such systems can no longer scan internal systems in a network. Such systems can no longer scan internal systems in a
reasonable time to build a database of connected systems. Rather, reasonable time to build a database of connected systems. Rather,
such systems will need more efficient approaches, e.g. by polling such systems will need more efficient approaches, e.g. by polling
network devices for data held about observed IP addresses, MAC network devices for data held about observed IP addresses, MAC
addresses, physical ports used, etc. Such an approach can also addresses, physical ports used, etc. Such an approach can also
enhance address accountability, by mapping IPv4 and IPv6 addresses to enhance address accountability, by mapping IPv4 and IPv6 addresses to
observed MAC addresses. This of course implies that any access observed MAC addresses. This of course implies that any access
control mechanisms for querying such network devices, e.g. community control mechanisms for querying such network devices, e.g. community
skipping to change at page 23, line 25 skipping to change at page 23, line 47
IPFIX [RFC7012] can aggregate the flows by source addresses, and IPFIX [RFC7012] can aggregate the flows by source addresses, and
hence may be leveraged for obtaining a list of "active" IPv6 hence may be leveraged for obtaining a list of "active" IPv6
addresses. Additional discussion of IPFIX can be found in addresses. Additional discussion of IPFIX can be found in
Section 2.5.1.2 of [I-D.ietf-opsec-v6]. Section 2.5.1.2 of [I-D.ietf-opsec-v6].
12. Obtaining Network Information with traceroute6 12. Obtaining Network Information with traceroute6
IPv6 traceroute [traceroute6] can be employed to find router IPv6 traceroute [traceroute6] can be employed to find router
addresses and valid network prefixes. addresses and valid network prefixes.
13. Conclusions 13. 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.
14. 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.
15. Conclusions
In this document we have discussed issues around host-based scanning In this document we have discussed issues around host-based scanning
of IPv6 networks. We have shown why a /64 host subnet may be more of IPv6 networks. We have shown why a /64 host subnet may be more
vulnerable to address-based scanning that might intuitively be vulnerable to address-based scanning that might intuitively be
thought, and how an attacker might reduce the target search space thought, and how an attacker might reduce the target search space
when scanning. when scanning.
We have described a number of mitigations against host-based We have described a number of mitigations against host-based
scanning, including the replacement of traditional SLAAC with stable scanning, including the replacement of traditional SLAAC with stable
privacy-enhanced IIDs (which will require support from system privacy-enhanced IIDs (which will require support from system
skipping to change at page 24, line 5 skipping to change at page 24, line 41
While most early IPv6-enabled networks remain dual-stack, they are While most early IPv6-enabled networks remain dual-stack, they are
more likely to be scanned and attacked over IPv4 transport, and one more likely to be scanned and attacked over IPv4 transport, and one
may argue that the IPv6-specific considerations discussed here are may argue that the IPv6-specific considerations discussed here are
not of an immediate concern. However, an early IPv6 deployment not of an immediate concern. However, an early IPv6 deployment
within a dual-stack network may be seen by an attacker as a within a dual-stack network may be seen by an attacker as a
potentially "easier" target, if the implementation of security potentially "easier" target, if the implementation of security
policies are not as strict for IPv6 (for whatever reason). As and policies are not as strict for IPv6 (for whatever reason). As and
when IPv6-only networks become more common, the considerations in when IPv6-only networks become more common, the considerations in
this document will be of much greater importance. this document will be of much greater importance.
14. IANA Considerations 16. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
15. Security Considerations 17. Security Considerations
This document explores the topic of Network Reconnaissance in IPv6 This document explores the topic of Network Reconnaissance in IPv6
networks. It analyzes the feasibility of address-scan attacks in networks. It analyzes the feasibility of address-scan attacks in
IPv6 networks, and showing that the search space for such attacks is IPv6 networks, and showing that the search space for such attacks is
typically much smaller than the one traditionally assumed (64 bits). typically much smaller than the one traditionally assumed (64 bits).
Additionally, it explores a plethora of other network reconnaissance Additionally, it explores a plethora of other network reconnaissance
techniques, ranging from inspecting the IPv6 Network Cache of an techniques, ranging from inspecting the IPv6 Network Cache of an
attacker-controlled system, to gleaning information about IPv6 attacker-controlled system, to gleaning information about IPv6
addresses from public mailing-list archives or Peer-To-Peer (P2P) addresses from public mailing-list archives or Peer-To-Peer (P2P)
protocols. protocols.
We expect traditional address-scanning attacks to become more and We expect traditional address-scanning attacks to become more and
more elaborated (i.e., less "brute force"), and other network more elaborated (i.e., less "brute force"), and other network
reconnaissance techniques to be actively explored, as global reconnaissance techniques to be actively explored, as global
deployment of IPv6 increases and. more specifically, as more deployment of IPv6 increases and. more specifically, as more
IPv6-only devices are deployed. IPv6-only devices are deployed.
16. Acknowledgements 18. Acknowledgements
The authors would like to thank Ray Hunter, who provided valuable
text that was readily incorporated into Section 3.2.1 of this
document.
The authors would like to thank (in alphabetical order) Marc Heuse, The authors would like to thank (in alphabetical order) Marc Heuse,
Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric
Vyncke, for providing valuable comments on earlier versions of this Vyncke, for providing valuable comments on earlier versions of this
document. document.
Part of the contents of this document are based on the results of the Part of the contents of this document are based on the results of the
project "Security Assessment of the Internet Protocol version 6 project "Security Assessment of the Internet Protocol version 6
(IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK
Centre for the Protection of National Infrastructure (CPNI). Centre for the Protection of National Infrastructure (CPNI).
Fernando Gont would like to thank the UK CPNI for their continued Fernando Gont would like to thank the UK CPNI for their continued
support. support.
17. References 19. References
17.1. Normative References 19.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation SAVI: First-Come, First-Served Source Address Validation
skipping to change at page 25, line 39 skipping to change at page 26, line 34
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
Information Export (IPFIX)", RFC 7012, September 2013. Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014. Interface Identifiers", RFC 7136, February 2014.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014. Autoconfiguration (SLAAC)", RFC 7217, April 2014.
17.2. Informative References 19.2. Informative References
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, January Multicast Name Resolution (LLMNR)", RFC 4795, January
2007. 2007.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC
5157, March 2008. 5157, March 2008.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
[I-D.gont-6man-ipv6-smurf-amplifier] [I-D.gont-6man-ipv6-smurf-amplifier]
skipping to change at page 26, line 23 skipping to change at page 27, line 23
Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf-
amplifier-03 (work in progress), March 2013. amplifier-03 (work in progress), March 2013.
[RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
in IPv6 Addressing", RFC 7421, January 2015. in IPv6 Addressing", RFC 7421, January 2015.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will, Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-01 (work in progress), draft-ietf-6man-default-iids-02 (work in progress),
October 2014. January 2015.
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-03 (work draft-ietf-6man-ipv6-address-generation-privacy-03 (work
in progress), January 2015. in progress), January 2015.
[I-D.ietf-dhc-stable-privacy-addresses] [I-D.ietf-dhc-stable-privacy-addresses]
Gont, F. and W. Will, "A Method for Generating Gont, F. and W. Will, "A Method for Generating
Semantically Opaque Interface Identifiers with Dynamic Semantically Opaque Interface Identifiers with Dynamic
skipping to change at page 27, line 41 skipping to change at page 28, line 41
vmware, , "Setting a static MAC address for a virtual vmware, , "Setting a static MAC address for a virtual
NIC", vmware Knowledge Base, August 2011, NIC", vmware Knowledge Base, August 2011,
<http://kb.vmware.com/selfservice/microsites/ <http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=219>. search.do?language=en_US&cmd=displayKC&externalId=219>.
[traceroute6] [traceroute6]
FreeBSD, , "FreeBSD System Manager's Manual: FreeBSD, , "FreeBSD System Manager's Manual:
traceroute6(8) manual page", 2009, traceroute6(8) manual page", 2009,
<https://www.freebsd.org/cgi/man.cgi?query=traceroute6>. <https://www.freebsd.org/cgi/man.cgi?query=traceroute6>.
[Ybema2010]
Ybema, I., "just seen my first IPv6 network abuse scan, is
this the start for more?", Post to the NANOG mailing-list,
2010, <http://mailman.nanog.org/pipermail/
nanog/2010-September/025049.html>.
[Gont-DEEPSEC2011] [Gont-DEEPSEC2011]
Gont, F., "Results of a Security Assessment of the Gont, F., "Results of a Security Assessment of the
Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Internet Protocol version 6 (IPv6)", DEEPSEC 2011
Conference, Vienna, Austria, November 2011, 2011, Conference, Vienna, Austria, November 2011, 2011,
<http://www.si6networks.com/presentations/deepsec2011/ <http://www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>. fgont-deepsec2011-ipv6-security.pdf>.
[Gont-LACSEC2013] [Gont-LACSEC2013]
Gont, F., "IPv6 Network Reconnaissance: Theory & Gont, F., "IPv6 Network Reconnaissance: Theory &
Practice", LACSEC 2013 Conference, Medellin, Colombia, May Practice", LACSEC 2013 Conference, Medellin, Colombia, May
 End of changes. 24 change blocks. 
47 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/