summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5157.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5157.txt')
-rw-r--r--doc/rfc/rfc5157.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc5157.txt b/doc/rfc/rfc5157.txt
new file mode 100644
index 0000000..4bbd1ce
--- /dev/null
+++ b/doc/rfc/rfc5157.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group T. Chown
+Request for Comments: 5157 University of Southampton
+Category: Informational March 2008
+
+
+ IPv6 Implications for Network Scanning
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Abstract
+
+ The much larger default 64-bit subnet address space of IPv6 should in
+ principle make traditional network (port) scanning techniques used by
+ certain network worms or scanning tools less effective. While
+ traditional network scanning probes (whether by individuals or
+ automated via network worms) may become less common, administrators
+ should be aware that attackers may use other techniques to discover
+ IPv6 addresses on a target network, and thus they should also be
+ aware of measures that are available to mitigate them. This
+ informational document discusses approaches that administrators could
+ take when planning their site address allocation and management
+ strategies as part of a defence-in-depth approach to network
+ security.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown Informational [Page 1]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Target Address Space for Network Scanning . . . . . . . . . . 4
+ 2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.3. Reducing the IPv6 Search Space . . . . . . . . . . . . . . 4
+ 2.4. Dual-Stack Networks . . . . . . . . . . . . . . . . . . . 5
+ 2.5. Defensive Scanning . . . . . . . . . . . . . . . . . . . . 5
+ 3. Alternatives for Attackers: Off-Link . . . . . . . . . . . . . 5
+ 3.1. Gleaning IPv6 Prefix Information . . . . . . . . . . . . . 5
+ 3.2. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 6
+ 3.3. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 6
+ 3.4. Log File Analysis . . . . . . . . . . . . . . . . . . . . 6
+ 3.5. Application Participation . . . . . . . . . . . . . . . . 6
+ 3.6. Multicast Group Addresses . . . . . . . . . . . . . . . . 7
+ 3.7. Transition Methods . . . . . . . . . . . . . . . . . . . . 7
+ 4. Alternatives for Attackers: On-Link . . . . . . . . . . . . . 7
+ 4.1. General On-Link Methods . . . . . . . . . . . . . . . . . 7
+ 4.2. Intra-Site Multicast or Other Service Discovery . . . . . 8
+ 5. Tools to Mitigate Scanning Attacks . . . . . . . . . . . . . . 8
+ 5.1. IPv6 Privacy Addresses . . . . . . . . . . . . . . . . . . 9
+ 5.2. Cryptographically Generated Addresses (CGAs) . . . . . . . 9
+ 5.3. Non-Use of MAC Addresses in EUI-64 Format . . . . . . . . 10
+ 5.4. DHCP Service Configuration Options . . . . . . . . . . . . 10
+ 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+ 9. Informative References . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown Informational [Page 2]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+1. Introduction
+
+ One of the key differences between IPv4 and IPv6 is the much larger
+ address space for IPv6, which also goes hand-in-hand with much larger
+ subnet sizes. This change has a significant impact on the
+ feasibility of TCP and UDP network scanning, whereby an automated
+ process is run to detect open ports (services) on systems that may
+ then be subject to a subsequent attack. Today many IPv4 sites are
+ subjected to such probing on a recurring basis. Such probing is
+ common in part due to the relatively dense population of active hosts
+ in any given chunk of IPv4 address space.
+
+ The 128 bits of IPv6 [1] address space is considerably bigger than
+ the 32 bits of address space in IPv4. In particular, the IPv6
+ subnets to which hosts attach will by default have 64 bits of host
+ address space [2]. As a result, traditional methods of remote TCP or
+ UDP network scanning to discover open or running services on a host
+ will potentially become less feasible, due to the larger search space
+ in the subnet. Similarly, worms that rely on off-link network
+ scanning to propagate may also potentially be more limited in impact.
+ This document discusses this property of IPv6 and describes related
+ issues for IPv6 site network administrators to consider, which may be
+ useful when planning site address allocation and management
+ strategies.
+
+ For example, many worms, like Slammer, rely on such address scanning
+ methods to propagate, whether they pick subnets numerically (and thus
+ probably topologically) close to the current victim, or subnets in
+ random remote networks. The nature of these worms may change, if
+ detection of target hosts between sites or subnets is harder to
+ achieve by traditional methods. However, there are other worms that
+ propagate via methods such as email, for which the methods discussed
+ in this text are not relevant.
+
+ It must be remembered that the defence of a network must not rely
+ solely on the unpredictable sparseness of the host addresses on that
+ network. Such a feature or property is only one measure in a set of
+ measures that may be applied. This document discusses various
+ measures that can be used by a site to mitigate attacks as part of an
+ overall strategy. Some of these have a lower cost to deploy than
+ others. For example, if numbering hosts on a subnet, it may be as
+ cheap to number hosts without any predictable pattern as it is to
+ number them sequentially. In contrast, use of IPv6 privacy
+ extensions [3] may complicate network management (identifying which
+ hosts use which addresses).
+
+
+
+
+
+
+Chown Informational [Page 3]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+ This document complements the transition-centric discussion of the
+ issues that can be found in Appendix A of "IPv6 Transition/
+ Co-existence Security Considerations" [12], which takes a broad view
+ of security issues for transitioning networks. The reader is also
+ referred to a recent paper by Bellovin on network worm propagation
+ strategies in IPv6 networks [13]. This paper discusses some of the
+ issues included in this document, from a slightly different
+ perspective.
+
+2. Target Address Space for Network Scanning
+
+ There are significantly different considerations for the feasibility
+ of plain, brute-force IPv4 and IPv6 address scanning.
+
+2.1. IPv4
+
+ A typical IPv4 subnet may have 8 bits reserved for host addressing.
+ In such a case, a remote attacker need only probe at most 256
+ addresses to determine if a particular service is running publicly on
+ a host in that subnet. Even at only one probe per second, such a
+ scan would take under 5 minutes to complete.
+
+2.2. IPv6
+
+ A typical IPv6 subnet will have 64 bits reserved for host addressing.
+ In such a case, a remote attacker in principle needs to probe 2^64
+ addresses to determine if a particular open service is running on a
+ host in that subnet. At a very conservative one probe per second,
+ such a scan may take some 5 billion years to complete. A more rapid
+ probe will still be limited to (effectively) infinite time for the
+ whole address space. However, there are ways for the attacker to
+ reduce the address search space to scan against within the target
+ subnet, as we discuss below.
+
+2.3. Reducing the IPv6 Search Space
+
+ The IPv6 host address space through which an attacker may search can
+ be reduced in at least two ways.
+
+ First, the attacker may rely on the administrator conveniently
+ numbering their hosts from [prefix]::1 upward. This makes scanning
+ trivial, and thus should be avoided unless the host's address is
+ readily obtainable from other sources (for example, it is the site's
+ published primary DNS or email Mail Exchange (MX) server).
+ Alternatively, if hosts are numbered sequentially, or using any
+ regular scheme, knowledge of one address may expose other available
+ addresses to scan.
+
+
+
+
+Chown Informational [Page 4]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+ Second, in the case of statelessly autoconfiguring [1] hosts, the
+ host part of the address will usually take a well-known format that
+ includes the Ethernet vendor prefix and the "fffe" stuffing. For
+ such hosts, the search space can be reduced to 48 bits. Further, if
+ the Ethernet vendor is also known, the search space may be reduced to
+ 24 bits, with a one probe per second scan then taking a less daunting
+ 194 days. Even where the exact vendor is not known, using a set of
+ common vendor prefixes can reduce the search. In addition, many
+ nodes in a site network may be procured in batches, and thus have
+ sequential or near sequential Media Access Control (MAC) addresses;
+ if one node's autoconfigured address is known, scanning around that
+ address may yield results for the attacker. Again, any form of
+ sequential host addressing should be avoided if possible.
+
+2.4. Dual-Stack Networks
+
+ Full advantage of the increased IPv6 address space in terms of
+ resilience to network scanning may not be gained until IPv6-only
+ networks and devices become more commonplace, given that most IPv6
+ hosts are currently dual stack, with (more readily scannable) IPv4
+ connectivity. However, many applications or services (e.g., new
+ peer-to-peer applications) on the (dual-stack) hosts may emerge that
+ are only accessible over IPv6, and that thus can only be discovered
+ by IPv6 address scanning.
+
+2.5. Defensive Scanning
+
+ The problem faced by the attacker for an IPv6 network is also faced
+ by a site administrator looking for vulnerabilities in their own
+ network's systems. The administrator should have the advantage of
+ being on-link for scanning purposes though.
+
+3. Alternatives for Attackers: Off-Link
+
+ If IPv6 hosts in subnets are allocated addresses 'randomly', and as a
+ result IPv6 network scanning becomes relatively infeasible, attackers
+ will need to find new methods to identify IPv6 addresses for
+ subsequent scanning. In this section, we discuss some possible paths
+ attackers may take. In these cases, the attacker will attempt to
+ identify specific IPv6 addresses for subsequent targeted probes.
+
+3.1. Gleaning IPv6 Prefix Information
+
+ Note that in IPv6, an attacker would not be able to search across the
+ entire IPv6 address space as they might in IPv4. An attacker may
+ learn general prefixes to focus their efforts on by observing route
+ view information (e.g., from public looking-glass services) or
+ information on allocated address space from Regional Internet
+
+
+
+Chown Informational [Page 5]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+ Registries (RIRs). In general, this would only yield information at
+ most at the /48 prefix granularity, though some specific /64 prefixes
+ may be observed from route views on some parts of some networks.
+
+3.2. DNS Advertised Hosts
+
+ Any servers that are DNS listed, e.g., MX mail relays, or web
+ servers, will remain open to probing from the very fact that their
+ IPv6 addresses will be published in the DNS.
+
+ While servers are relatively easy to find because they are DNS-
+ published, any systems that are not DNS-published will be much harder
+ to locate via traditional scanning than is the case for IPv4
+ networks. It is worth noting that where a site uses sequential host
+ numbering, publishing just one address may lead to a threat upon the
+ other hosts.
+
+3.3. DNS Zone Transfers
+
+ In the IPv6 world, a DNS zone transfer is much more likely to narrow
+ the number of hosts an attacker needs to target. This implies that
+ restricting zone transfers is (more) important for IPv6, even if it
+ is already good practice to restrict them in the IPv4 world.
+
+ There are some projects that provide Internet mapping data from
+ access to such transfers. Administrators may of course agree to
+ provide such transfers where they choose to do so.
+
+3.4. Log File Analysis
+
+ IPv6 addresses may be harvested from recorded logs, such as web site
+ logs. Anywhere else where IPv6 addresses are explicitly recorded may
+ prove a useful channel for an attacker, e.g., by inspection of the
+ (many) Received from: or other header lines in archived email or
+ Usenet news messages.
+
+3.5. Application Participation
+
+ More recent peer-to-peer applications often include some centralised
+ server that coordinates the transfer of data between peers. The
+ BitTorrent application 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 IP addresses to probe.
+
+
+
+
+
+
+
+Chown Informational [Page 6]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+3.6. Multicast Group Addresses
+
+ Where an Embedded Rendezvous Point (RP) [7] multicast group address
+ is known, the unicast address of the RP is implied by the group
+ address. Where unicast-prefix-based multicast group addresses [5]
+ are used, specific /64 link prefixes may also be disclosed in traffic
+ that goes off-site. An administrator may thus choose to put aside
+ /64 bit prefixes for multicast group addresses that are not in use
+ for normal unicast routing and addressing. Alternatively, a site may
+ simply use their non-specific /48 site prefix allocation to generate
+ RFC3306 multicast group addresses.
+
+3.7. Transition Methods
+
+ Specific knowledge of the target network may be gleaned if that
+ attacker knows it is using 6to4 [4], ISATAP [10], Teredo [11], or
+ other techniques that derive low-order bits from IPv4 addresses
+ (though in this case, unless they are using IPv4 NAT, the IPv4
+ addresses may be probed anyway).
+
+ For example, the current Microsoft 6to4 implementation uses the
+ address 2002:V4ADDR::V4ADDR while older Linux and FreeBSD
+ implementations default to 2002:V4ADDR::1. This leads to specific
+ knowledge of specific hosts in the network. Given one host in the
+ network is observed as using a given transition technique, it is
+ likely that there are more.
+
+ In the case of Teredo, the 64-bit node identifier is generated from
+ the IPv4 address observed at a Teredo server along with a UDP port
+ number. The Teredo specification also allows for discovery of other
+ Teredo clients on the same IPv4 subnet via a well-known IPv4
+ multicast address (see Section 2.17 of RFC 4380 [11]).
+
+4. Alternatives for Attackers: On-Link
+
+ The main thrust of this text is considerations for off-link attackers
+ or probing of a network. In general, once one host on a link is
+ compromised, others on the link can be very readily discovered.
+
+4.1. General On-Link Methods
+
+ If the attacker already has access to a system on the current subnet,
+ then traffic on that subnet, be it Neighbour Discovery or
+ application-based traffic, can invariably be observed, and active
+ node addresses within the local subnet learnt.
+
+
+
+
+
+
+Chown Informational [Page 7]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+ In addition to making observations of traffic on the link, IPv6-
+ enabled hosts on local subnets may be discovered through probing the
+ "all hosts" link-local multicast address. Likewise, any routers on
+ the subnet may be found via the "all routers" link-local multicast
+ address. An attacker may choose to probe in a slightly more
+ obfuscated way by probing the solicited node multicast address of a
+ potential target host.
+
+ Where a host has already been compromised, its Neighbour Discovery
+ cache is also likely to include information about active nodes on the
+ current subnet, just as an ARP cache would do for IPv4.
+
+ Also, depending on the node, traffic to or from other nodes (in
+ particular, server systems) is likely to show up if an attacker can
+ gain a presence on a node in any one subnet in a site's network.
+
+4.2. Intra-Site Multicast or Other Service Discovery
+
+ A site may also have site- or organisational-scope multicast
+ configured, in which case application traffic, or service discovery,
+ may be exposed site wide. An attacker may also choose to use any
+ other service discovery methods supported by the site.
+
+5. Tools to Mitigate Scanning Attacks
+
+ There are some tools that site administrators can apply to make the
+ task for IPv6 network scanning attackers harder. These methods arise
+ from the considerations in the previous section.
+
+ The author notes that at his current (university) site, there is no
+ evidence of general network scanning running across subnets.
+ However, there is network scanning over IPv6 connections to systems
+ whose IPv6 addresses are advertised (DNS servers, MX relays, web
+ servers, etc.), which are presumably looking for other open ports on
+ these hosts to probe further. At the time of writing, DHCPv6 [6] is
+ not yet in use at the author's site, and clients use stateless
+ autoconfiguration. Therefore, the author's site does not yet have
+ sequentially numbered client hosts deployed as may typically be seen
+ in today's IPv4 DHCP-served networks.
+
+
+
+
+
+
+
+
+
+
+
+
+Chown Informational [Page 8]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+5.1. IPv6 Privacy Addresses
+
+ Hosts in a network using IPv6 privacy extensions [3] will typically
+ only connect to external systems using their current (temporary)
+ privacy address. The precise behaviour of a host with a stable
+ global address and one or more dynamic privacy address(es) when
+ selecting a source address to use may be operating-system-specific,
+ or configurable, but typical behaviour when initiating a connection
+ is use of a privacy address when available.
+
+ While an attacker may be able to port scan a privacy address, if they
+ do so quickly upon observing or otherwise learning of the address,
+ the threat or risk is reduced due to the time-constrained value of
+ the address. One implementation of RFC 4941 already deployed has
+ privacy addresses active (used by the node) for one day, with such
+ addresses reachable for seven days.
+
+ Note that an RFC 4941 host will usually also have a separate static
+ global IPv6 address by which it can also be reached, and that may be
+ DNS-advertised if an externally reachable service is running on it.
+ DHCPv6 can be used to serve normal global addresses and IPv6 privacy
+ addresses.
+
+ The implication is that while privacy addresses can mitigate the
+ long-term value of harvested addresses, an attacker creating an IPv6
+ application server to which clients connect will still be able to
+ probe the clients by their privacy address when they visit that
+ server. The duration for which privacy addresses are valid will
+ impact the usefulness of such observed addresses to an external
+ attacker. For example, a worm that may spread using such observed
+ addresses may be less effective if it relies on harvested privacy
+ addresses. The frequency with which such address get recycled could
+ be increased, though this may increase the complexity of local
+ network management for the administrator, since doing so will cause
+ more addresses to be used over time in the site.
+
+ A further option here may be to consider using different addresses
+ for specific applications, or even each new application instance,
+ which may reduce exposure to other services running on the same host
+ when such an address is observed externally.
+
+5.2. Cryptographically Generated Addresses (CGAs)
+
+ The use of Cryptographically Generated Addresses (CGAs) [9] may also
+ cause the search space to be increased from that presented by default
+ use of stateless autoconfiguration. Such addresses would be seen
+ where Secure Neighbour Discovery (SEND) [8] is in use.
+
+
+
+
+Chown Informational [Page 9]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+5.3. Non-Use of MAC Addresses in EUI-64 Format
+
+ The EUI-64 identifier format does not require the use of MAC
+ addresses for identifier construction. At least one well known
+ operating system currently defaults to generation of the 64-bit
+ interface identifier by use of random bits, and thus does not embed
+ the MAC address. Where such a method exists, an administrator may
+ wish to consider using that option.
+
+5.4. DHCP Service Configuration Options
+
+ One option open to an administrator is to configure DHCPv6, if
+ possible, so that the first addresses allocated from the pool begins
+ much higher in the address space than at [prefix]::1. Further, it is
+ desirable that allocated addresses are not sequential and do not have
+ any predictable pattern to them. Unpredictable sparseness in the
+ allocated addresses is a desirable property. DHCPv6 implementers
+ could reduce the cost for administrators to deploy such 'random'
+ addressing by supporting configuration options to allow such
+ behaviour.
+
+ DHCPv6 also includes an option to use privacy extension [3]
+ addresses, i.e., temporary addresses, as described in Section 12 of
+ the DHCPv6 [6] specification.
+
+6. Conclusions
+
+ Due to the much larger size of IPv6 subnets in comparison to IPv4, it
+ will become less feasible for traditional network scanning methods to
+ detect open services for subsequent attacks, assuming the attackers
+ are off-site and services are not listed in the DNS. If
+ administrators number their IPv6 subnets in 'random', non-predictable
+ ways, attackers, whether they be in the form of automated network
+ scanners or dynamic worm propagation, will need to make wider use of
+ new methods to determine IPv6 host addresses to target (e.g., looking
+ to obtain logs of activity from a site and scanning addresses around
+ the ones observed). Such numbering schemes may be very low cost to
+ deploy in comparison to conventional sequential numbering, and thus,
+ a useful part of an overall defence-in-depth strategy. Of course, if
+ those systems are dual-stack, and have open IPv4 services running,
+ they will remain exposed to traditional probes over IPv4 transport.
+
+7. Security Considerations
+
+ There are no specific security considerations in this document
+ outside of the topic of discussion itself. However, it must be noted
+ that the 'security through obscurity' discussions and commentary
+ within this text must be noted in their proper context. Relying
+
+
+
+Chown Informational [Page 10]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+ purely on obscurity of a node address is not prudent, rather the
+ advice here should be considered as part of a 'defence-in-depth'
+ approach to security for a site or network. This also implies that
+ these measures require coordination between network administrators
+ and those who maintain DNS services, though this is common in most
+ scenarios.
+
+8. Acknowledgements
+
+ Thanks are due to people in the 6NET project (www.6net.org) for
+ discussion of this topic, including Pekka Savola, Christian Strauf,
+ and Martin Dunmore, as well as other contributors from the IETF v6ops
+ and other mailing lists, including Tony Finch, David Malone, Bernie
+ Volz, Fred Baker, Andrew Sullivan, Tony Hain, Dave Thaler, and Alex
+ Petrescu. Thanks are also due for editorial feedback from Brian
+ Carpenter, Lars Eggert, and Jonne Soininen amongst others.
+
+9. Informative References
+
+ [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 2460, December 1998.
+
+ [2] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
+ Autoconfiguration", RFC 4862, September 2007.
+
+ [3] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
+ for Stateless Address Autoconfiguration in IPv6", RFC 4941,
+ September 2007.
+
+ [4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
+ IPv4 Clouds", RFC 3056, February 2001.
+
+ [5] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
+ Multicast Addresses", RFC 3306, August 2002.
+
+ [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+ Carney, "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 3315, July 2003.
+
+ [7] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
+ (RP) Address in an IPv6 Multicast Address", RFC 3956,
+ November 2004.
+
+ [8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+ Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+ [9] Aura, T., "Cryptographically Generated Addresses (CGA)",
+ RFC 3972, March 2005.
+
+
+
+Chown Informational [Page 11]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+ [10] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
+ Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,
+ October 2005.
+
+ [11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
+ Address Translations (NATs)", RFC 4380, February 2006.
+
+ [12] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+ Co-existence Security Considerations", RFC 4942,
+ September 2007.
+
+ [13] Bellovin, S., et al, "Worm Propagation Strategies in an IPv6
+ Internet", as published in ;login:, February 2006,
+ <http://www.cs.columbia.edu/~smb/papers/v6worms.pdf>.
+
+Author's Address
+
+ Tim Chown
+ University of Southampton
+ Southampton, Hampshire SO17 1BJ
+ United Kingdom
+
+ EMail: tjc@ecs.soton.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown Informational [Page 12]
+
+RFC 5157 IPv6 Network Scanning March 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Chown Informational [Page 13]
+