doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc4942.txt b/doc/rfc/rfc4942.txt
new file mode 100644
index 0000000..e5a9221
--- /dev/null
+++ b/doc/rfc/rfc4942.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                          E. Davies
+Request for Comments: 4942                                    Consultant
+Category: Informational                                      S. Krishnan
+                                                                Ericsson
+                                                               P. Savola
+                                                               CSC/Funet
+                                                          September 2007
+
+
+          IPv6 Transition/Coexistence Security Considerations
+
+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 transition from a pure IPv4 network to a network where IPv4 and
+   IPv6 coexist brings a number of extra security considerations that
+   need to be taken into account when deploying IPv6 and operating the
+   dual-protocol network and the associated transition mechanisms.  This
+   document attempts to give an overview of the various issues grouped
+   into three categories:
+   o  issues due to the IPv6 protocol itself,
+   o  issues due to transition mechanisms, and
+   o  issues due to IPv6 deployment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davies, et al.               Informational                      [Page 1]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Issues Due to IPv6 Protocol  . . . . . . . . . . . . . . . . .  4
+     2.1.  IPv6 Protocol-Specific Issues  . . . . . . . . . . . . . .  5
+       2.1.1.  Routing Headers and Hosts  . . . . . . . . . . . . . .  5
+       2.1.2.  Routing Headers for Mobile IPv6 and Other Purposes . .  6
+       2.1.3.  Site-Scope Multicast Addresses . . . . . . . . . . . .  7
+       2.1.4.  ICMPv6 and Multicast . . . . . . . . . . . . . . . . .  7
+       2.1.5.  Bogus Errored Packets in ICMPv6 Error Messages . . . .  8
+       2.1.6.  Anycast Traffic Identification and Security  . . . . .  9
+       2.1.7.  Address Privacy Extensions Interact with DDoS
+               Defenses . . . . . . . . . . . . . . . . . . . . . . . 10
+       2.1.8.  Dynamic DNS: Stateless Address Autoconfiguration,
+               Privacy Extensions, and SEND . . . . . . . . . . . . . 10
+       2.1.9.  Extension Headers  . . . . . . . . . . . . . . . . . . 11
+       2.1.10. Fragmentation: Reassembly and Deep Packet
+               Inspection . . . . . . . . . . . . . . . . . . . . . . 14
+       2.1.11. Fragmentation Related DoS Attacks  . . . . . . . . . . 15
+       2.1.12. Link-Local Addresses and Securing Neighbor
+               Discovery  . . . . . . . . . . . . . . . . . . . . . . 16
+       2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17
+       2.1.14. Host-to-Router Load Sharing  . . . . . . . . . . . . . 18
+       2.1.15. Mobile IPv6  . . . . . . . . . . . . . . . . . . . . . 18
+     2.2.  IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . 19
+     2.3.  Increased End-to-End Transparency  . . . . . . . . . . . . 20
+       2.3.1.  IPv6 Networks without NATs . . . . . . . . . . . . . . 20
+       2.3.2.  Enterprise Network Security Model for IPv6 . . . . . . 21
+     2.4.  IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22
+   3.  Issues Due to Transition Mechanisms  . . . . . . . . . . . . . 23
+     3.1.  IPv6 Transition/Coexistence Mechanism-Specific Issues  . . 23
+     3.2.  Automatic Tunneling and Relays . . . . . . . . . . . . . . 23
+     3.3.  Tunneling IPv6 through IPv4 Networks May Break IPv4
+           Network Security Assumptions . . . . . . . . . . . . . . . 24
+   4.  Issues Due to IPv6 Deployment  . . . . . . . . . . . . . . . . 26
+     4.1.  Avoiding the Trap of Insecure IPv6 Service Piloting  . . . 26
+     4.2.  DNS Server Problems  . . . . . . . . . . . . . . . . . . . 28
+     4.3.  Addressing Schemes and Securing Routers  . . . . . . . . . 28
+     4.4.  Consequences of Multiple Addresses in IPv6 . . . . . . . . 28
+     4.5.  Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 29
+       4.5.1.  Problems Resulting from ICMPv6 Transparency  . . . . . 30
+     4.6.  IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 30
+     4.7.  Reduced Functionality Devices  . . . . . . . . . . . . . . 31
+     4.8.  Operational Factors when Enabling IPv6 in the Network  . . 31
+     4.9.  Security Issues Due to Neighbor Discovery Proxies  . . . . 32
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
+
+
+
+Davies, et al.               Informational                      [Page 2]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 34
+   Appendix A.  IPv6 Probing/Mapping Considerations . . . . . . . . . 37
+   Appendix B.  IPv6 Privacy Considerations . . . . . . . . . . . . . 38
+     B.1.  Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 38
+     B.2.  Exposing Multiple Devices  . . . . . . . . . . . . . . . . 39
+     B.3.  Exposing the Site by a Stable Prefix . . . . . . . . . . . 39
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davies, et al.               Informational                      [Page 3]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+1.  Introduction
+
+   The transition from a pure IPv4 network to a network where IPv4 and
+   IPv6 coexist brings a number of extra security considerations that
+   need to be taken into account when deploying IPv6 and operating the
+   dual-protocol network with its associated transition mechanisms.
+   This document attempts to give an overview of the various issues
+   grouped into three categories:
+   o  issues due to the IPv6 protocol itself,
+   o  issues due to transition mechanisms, and
+   o  issues due to IPv6 deployment.
+
+   It is important to understand that deployments are unlikely to be
+   replacing IPv4 with IPv6 (in the short term), but rather will be
+   adding IPv6 to be operated in parallel with IPv4 over a considerable
+   period, so that security issues with transition mechanisms and dual
+   stack networks will be of ongoing concern.  This extended transition
+   and coexistence period stems primarily from the scale of the current
+   IPv4 network.  It is unreasonable to expect that the many millions of
+   IPv4 nodes will be converted overnight.  It is more likely that it
+   will take two or three capital equipment replacement cycles (between
+   nine and 15 years) for IPv6 capabilities to spread through the
+   network, and many services will remain available over IPv4 only for a
+   significant period whilst others will be offered either just on IPv6
+   or on both protocols.  To maintain current levels of service,
+   enterprises and service providers will need to support IPv4 and IPv6
+   in parallel for some time.
+
+   This document also describes two matters that have been wrongly
+   identified as potential security concerns for IPv6 in the past and
+   explains why they are unlikely to cause problems: considerations
+   about probing/mapping IPv6 addresses (Appendix A) and considerations
+   with respect to privacy in IPv6 (Appendix B).
+
+2.  Issues Due to IPv6 Protocol
+
+   Administrators should be aware that some of the rules suggested in
+   this section could potentially lead to a small amount of legitimate
+   traffic being dropped because the source has made unusual and
+   arguably unreasonable choices when generating the packet.  The IPv6
+   specification [RFC2460] contains a number of areas where choices are
+   available to packet originators that will result in packets that
+   conform to the specification but are unlikely to be the result of a
+   rational packet generation policy for legitimate traffic (e.g.,
+   sending a fragmented packet in a much larger than necessary number of
+   small segments).  This document highlights choices that could be made
+   by malicious sources with the intention of damaging the target host
+   or network, and suggests rules that try to differentiate
+
+
+
+Davies, et al.               Informational                      [Page 4]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   specification-conforming packets that are legitimate traffic from
+   conforming packets that may be trying to subvert the specification to
+   cause damage.  The differentiation tries to offer a reasonable
+   compromise between securing the network and passing every possible
+   conforming packet.  To avoid loss of important traffic,
+   administrators are advised to log packets dropped according to these
+   rules and examine these logs periodically to ensure that they are
+   having the desired effect, and are not excluding traffic
+   inappropriately.
+
+   The built-in flexibility of the IPv6 protocol may also lead to
+   changes in the boundaries between legitimate and malicious traffic as
+   identified by these rules.  New options may be introduced in the
+   future, and rules may need to be altered to allow the new
+   capabilities to be (legitimately) exploited by applications.  The
+   document therefore recommends that filtering needs to be configurable
+   to allow administrators the flexibility to update rules as new pieces
+   of IPv6 specification are standardized.
+
+2.1.  IPv6 Protocol-Specific Issues
+
+   There are significant differences between the features of IPv6 and
+   IPv4: some of these specification changes may result in potential
+   security issues.  Several of these issues have been discussed in
+   separate documents but are summarized here to avoid normative
+   references that may not become RFCs.  The following specification-
+   related problems have been identified, but this is not necessarily a
+   complete list.
+
+2.1.1.  Routing Headers and Hosts
+
+   All IPv6 nodes must be able to process routing headers [RFC2460].
+   This RFC can be interpreted, although it is not explicitly stated, to
+   mean that all nodes (including hosts) must have this processing
+   enabled.  The "Requirements for Internet Hosts" [RFC1122] permits
+   implementations to perform "local source routing", that is,
+   forwarding a packet with a routing header through the same interface
+   on which it was received: no restrictions are placed on this
+   operation even on hosts.  In combination, these rules can result in
+   hosts forwarding received traffic to another node if there are
+   segments left in the Routing Header when it arrives at the host.
+
+   A number of potential security issues associated with this behavior
+   have been identified.  Some of these issues have been resolved (a
+   separate routing header (Type 2) has been standardized for Mobile
+   IPv6 [RFC3775], and ICMP Traceback has not been standardized), but
+   two issues remain:
+
+
+
+
+Davies, et al.               Informational                      [Page 5]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   o  Both existing types of routing header can be used to evade access
+      controls based on destination addresses.  This could be achieved
+      by sending a packet ostensibly to a publicly accessible host
+      address but with a routing header containing a 'forbidden'
+      address.  If the publicly accessible host is processing routing
+      headers, it will forward the packet to the destination address in
+      the routing header that would have been forbidden by the packet
+      filters if the address had been in the destination field when the
+      packet was checked.
+
+   o  If the packet source address can be spoofed when using a Type 0
+      routing header, the mechanism described in the previous bullet
+      could be used with any host to mediate an anonymous reflection
+      denial-of-service attack by having any publicly accessible host
+      redirect the attack packets.  (This attack cannot use Type 2
+      routing headers because the packet cannot be forwarded outside the
+      host that processes the routing header, i.e., the original
+      destination of the packet.)
+
+   To counteract these threats, if a device is enforcing access controls
+   based on destination addresses, it needs to examine both the
+   destination address in the base IPv6 header and any waypoint
+   destinations in a routing header that have not yet been reached by
+   the packet at the point where it is being checked.
+
+   Various forms of amplification attack on routers and firewalls using
+   the routing header could be envisaged.  A simple form involves
+   repeating the address of a waypoint several times in the routing
+   header.  More complex forms could involve alternating waypoint
+   addresses that would result in the packet re-transiting the router or
+   firewall.  These attacks can be counteracted by ensuring that routing
+   headers do not contain the same waypoint address more than once, and
+   performing ingress/egress filtering to check that the source address
+   is appropriate to the destination: packets made to reverse their path
+   will fail this test.
+
+2.1.2.  Routing Headers for Mobile IPv6 and Other Purposes
+
+   In addition to the basic Routing Header (Type 0), which is intended
+   to influence the trajectory of a packet through a network by
+   specifying a sequence of router waypoints, Routing Header (Type 2)
+   has been defined as part of the Mobile IPv6 specifications in
+   [RFC3775].  The Type 2 Routing Header is intended for use by hosts to
+   handle 'interface local' forwarding needed when packets are sent to
+   the care-of address of a mobile node that is away from its home
+   address.
+
+
+
+
+
+Davies, et al.               Informational                      [Page 6]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   It is important that nodes treat the different types of routing
+   header appropriately.  It should be possible to apply separate
+   filtering rules to the different types of Routing Header.  By design,
+   hosts must process Type 2 Routing Headers to support Mobile IPv6 but
+   routers should not: to avoid the issues in Section 2.1.1, it may be
+   desirable to forbid or limit the processing of Type 0 Routing Headers
+   in hosts and some routers.
+
+   Routing Headers are an extremely powerful and general capability.
+   Alternative future uses of Routing Headers need to be carefully
+   assessed to ensure that they do not open new avenues of attack that
+   can be exploited.
+
+2.1.3.  Site-Scope Multicast Addresses
+
+   IPv6 supports multicast addresses with site scope that can
+   potentially allow an attacker to identify certain important resources
+   on the site if misused.
+
+   Particular examples are the 'all routers' (FF05::2) and 'all Dynamic
+   Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses
+   defined in [RFC2375].  An attacker that is able to infiltrate a
+   message destined for these addresses on to the site will potentially
+   receive in return information identifying key resources on the site.
+   This information can then be the target of directed attacks ranging
+   from simple flooding to more specific mechanisms designed to subvert
+   the device.
+
+   Some of these addresses have current legitimate uses within a site.
+   The risk can be minimized by ensuring that all firewalls and site
+   boundary routers are configured to drop packets with site-scope
+   destination addresses.  Also, nodes should not join multicast groups
+   for which there is no legitimate use on the site, and site routers
+   should be configured to drop packets directed to these unused
+   addresses.
+
+2.1.4.  ICMPv6 and Multicast
+
+   It is possible to launch a Denial-of-Service (DoS) attack using IPv6
+   that could be amplified by the multicast infrastructure.
+
+   Unlike ICMP for IPv4, ICMPv6 [RFC4443] allows error notification
+   responses to be sent when certain unprocessable packets are sent to
+   multicast addresses.
+
+
+
+
+
+
+
+Davies, et al.               Informational                      [Page 7]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   The cases in which responses are sent are:
+
+   o  The received packet is longer than the next link Maximum
+      Transmission Unit (MTU): 'Packet Too Big' responses are needed to
+      support Path MTU Discovery for multicast traffic.
+
+   o  The received packet contains an unrecognized option in a hop-by-
+      hop or destination options extension header with the first two
+      bits of the option type set to binary '10': 'Parameter Problem'
+      responses are intended to inform the source that some or all of
+      the recipients cannot handle the option in question.
+
+   If an attacker can craft a suitable packet sent to a multicast
+   destination, it may be possible to elicit multiple responses directed
+   at the victim (the spoofed source of the multicast packet).  On the
+   other hand, the use of 'reverse path forwarding' checks (to eliminate
+   loops in multicast forwarding) automatically limits the range of
+   addresses that can be spoofed.
+
+   In practice, an attack using oversize packets is unlikely to cause
+   much amplification unless the attacker is able to carefully tune the
+   packet size to exploit a network with smaller MTU in the edge than
+   the core.  Similarly, a packet with an unrecognized hop-by-hop option
+   would be dropped by the first router without resulting in multiple
+   responses.  However, a packet with an unrecognized destination option
+   could generate multiple responses.
+
+   In addition to amplification, this kind of attack would potentially
+   consume large amounts of forwarding state resources in routers on
+   multicast-enabled networks.
+
+2.1.5.  Bogus Errored Packets in ICMPv6 Error Messages
+
+   Apart from the spurious load on the network, routers, and hosts,
+   bogus ICMPv6 error messages (types 0 to 127) containing a spoofed
+   errored packet can impact higher-layer protocols when the alleged
+   errored packet is referred to the higher layer at the destination of
+   the ICMPv6 packet [RFC4443].  The potentially damaging effects on TCP
+   connections, and some ways to mitigate the threats, are documented in
+   [ICMP-ATT].
+
+   Specific countermeasures for particular higher-layer protocols are
+   beyond the scope of this document, but firewalls may be able to help
+   counter the threat by inspecting the alleged errored packet embedded
+   in the ICMPv6 error message.  Measures to mitigate the threat
+   include:
+
+
+
+
+
+Davies, et al.               Informational                      [Page 8]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   o  The receiving host should test that the embedded packet is all or
+      part of a packet that was transmitted by the host.
+
+   o  The firewall may be able to test that the embedded packet contains
+      addresses that would have been legitimate (i.e., would have passed
+      ingress/egress filtering) for a packet sent from the receiving
+      host, but the possibility of asymmetric routing of the outgoing
+      and returning packets may prevent this sort of test depending on
+      the topology of the network, the location of the firewall, and
+      whether state synchronization between firewalls is in use.
+
+   o  If the firewall is stateful and the test is not prevented by
+      asymmetric routing, the firewall may also be able to check that
+      the embedded packet is all or part of a packet that recently
+      transited the firewall in the opposite direction.
+
+   o  Firewalls and destination hosts should be suspicious of ICMPv6
+      error messages with unnecessarily truncated errored packets (e.g.,
+      those that only carry the address fields of the IPv6 base header).
+      The specification of ICMPv6 requires that error messages carry as
+      much of the errored packet as possible (unlike ICMP for IPv4 which
+      requires only a minimum amount of the errored packet) and IPv6
+      networks must have a guaranteed minimum MTU of 1280 octets.
+      Accordingly, the ICMPv6 message should normally carry all the
+      header fields of the errored packet, together with a significant
+      amount of the payload, in order to allow robust comparison against
+      the outgoing packet.
+
+2.1.6.  Anycast Traffic Identification and Security
+
+   IPv6 introduces the notion of anycast addresses and services.
+   Originally the IPv6 standards disallowed using an anycast address as
+   the source address of a packet.  Responses from an anycast server
+   would therefore supply a unicast address for the responding server.
+   To avoid exposing knowledge about the internal structure of the
+   network, it is recommended that anycast servers now take advantage of
+   the ability to return responses with the anycast address as the
+   source address if possible.
+
+   If the server needs to use a unicast address for any reason, it may
+   be desirable to consider using specialized addresses for anycast
+   servers, which are not used for any other part of the network, to
+   restrict the information exposed.  Alternatively, operators may wish
+   to restrict the use of anycast services from outside the domain, thus
+   requiring firewalls to filter anycast requests.  For this purpose,
+   firewalls need to know which addresses are being used for anycast
+   services: these addresses are arbitrary and not distinguishable from
+   any other IPv6 unicast address by structure or pattern.
+
+
+
+Davies, et al.               Informational                      [Page 9]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   One particular class of anycast addresses that should be given
+   special attention is the set of Subnet-Router anycast addresses
+   defined in "IP Version 6 Addressing Architecture" [RFC4291].  All
+   routers are required to support these addresses for all subnets for
+   which they have interfaces.  For most subnets using global unicast
+   addresses, filtering anycast requests to these addresses can be
+   achieved by dropping packets with the lower 64 bits (the Interface
+   Identifier) set to all zeros.
+
+2.1.7.  Address Privacy Extensions Interact with DDoS Defenses
+
+   The purpose of the privacy extensions for stateless address
+   autoconfiguration [RFC4941] is to change the interface identifier
+   (and hence the global scope addresses generated from it) from time to
+   time.  By varying the addresses used, eavesdroppers and other
+   information collectors find it more difficult to identify which
+   transactions actually relate to a specific node.
+
+   A security issue may result from this if the frequency of node
+   address change is sufficiently great to achieve the intended aim of
+   the privacy extensions: with a relatively high rate of change, the
+   observed behavior has some characteristics of a node or nodes
+   involved in a Distributed Denial-of-Service (DDoS) attack.  It should
+   be noted, however, that addresses created in this way are
+   topologically correct and that the other characteristics of the
+   traffic may reveal that there is no malicious intent.
+
+   This issue can be addressed in most cases by tuning the rate of
+   change in an appropriate manner.
+
+   Note that even if a node is well behaved, a change in the address
+   could make it harder for a security administrator to define an
+   address-based policy rule (e.g., access control list).  However,
+   nodes that employ privacy addresses do not have to use them for all
+   communications.
+
+2.1.8.  Dynamic DNS: Stateless Address Autoconfiguration, Privacy
+        Extensions, and SEND
+
+   The introduction of Stateless Address Autoconfiguration (SLAAC)
+   [RFC2462] with IPv6 provides an additional challenge to the security
+   of Dynamic Domain Name System (DDNS).  With manual addressing or the
+   use of DHCP, the number of security associations that need to be
+   maintained to secure access to the Domain Name Service (DNS) server
+   is limited, assuming any necessary updates are carried out by the
+   DHCP server.  This is true equally for IPv4 and IPv6.
+
+
+
+
+
+Davies, et al.               Informational                     [Page 10]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   Since SLAAC does not make use of a single and potentially trusted
+   DHCP server, but depends on the node obtaining the address, securing
+   the insertion of updates into DDNS may need a security association
+   between each node and the DDNS server.  This is discussed further in
+   [RFC4472].
+
+   Using the Privacy Extensions to SLAAC [RFC4941] may significantly
+   increase the rate of updates of DDNS.  Even if a node using the
+   Privacy Extensions does not publish its address for 'forward' lookup
+   (as that would effectively compromise the privacy that it is
+   seeking), it may still need to update the reverse DNS records.  If
+   the reverse DNS records are not updated, servers that perform reverse
+   DNS checks will not accept connections from the node and it will not
+   be possible to gain access to IP Security (IPsec) keying material
+   stored in DNS [RFC4025].  If the rate of change needed to achieve
+   real privacy has to be increased (see Section 2.1.7), the update rate
+   for DDNS may be excessive.
+
+   Similarly, the cryptographically generated addresses used by SEND
+   [RFC3971] are expected to be periodically regenerated in line with
+   recommendations for maximum key lifetimes.  This regeneration could
+   also impose a significant extra load on DDNS.
+
+2.1.9.  Extension Headers
+
+   A number of security issues relating to IPv6 Extension headers have
+   been identified.  Several of these are a result of ambiguous or
+   incomplete specification in the base IPv6 specification [RFC2460].
+
+2.1.9.1.  Processing Extension Headers in Middleboxes
+
+   In IPv4, deep packet inspection techniques are used to implement
+   policing and filtering both as part of routers and in middleboxes
+   such as firewalls.  Fully extending these techniques to IPv6 would
+   require inspection of all the extension headers in a packet.  This is
+   essential to ensure that policy constraints on the use of certain
+   headers and options are enforced and to remove, at the earliest
+   opportunity, packets containing potentially damaging unknown options.
+
+   This requirement appears to conflict with Section 4 of the IPv6
+   specification in [RFC2460] which requires that only hop-by-hop
+   options are processed at any node through which the packet passes
+   until the packet reaches the appropriate destination (either the
+   final destination or a routing header waypoint).
+
+   Also, [RFC2460] forbids processing the headers other than in the
+   order in which they appear in the packet.
+
+
+
+
+Davies, et al.               Informational                     [Page 11]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   A further ambiguity relates to whether an intermediate node should
+   discard a packet that contains a header or destination option which
+   it does not recognize.  If the rules above are followed slavishly, it
+   is not (or may not be) legitimate for the intermediate node to
+   discard the packet because it should not be processing those headers
+   or options.
+
+   Therefore, [RFC2460] does not appear to take account of the behavior
+   of middleboxes and other non-final destinations that may be
+   inspecting the packet, and thereby potentially limits the security
+   protection of these boxes.  Firewall vendors and administrators may
+   choose to ignore these rules in order to provide enhanced security as
+   this does not appear to have any serious consequences with the
+   currently defined set of extensions.  However, administrators should
+   be aware that future extensions might require different treatment.
+
+2.1.9.2.  Processing Extension Header Chains
+
+   There is a further problem for middleboxes that want to examine the
+   transport headers that are located at the end of the IPv6 header
+   chain.  In order to locate the transport header or other protocol
+   data unit, the node has to parse the header chain.
+
+   The IPv6 specification [RFC2460] does not mandate the use of the
+   Type-Length-Value (TLV) format with a fixed layout for the start of
+   each header although it is used for the majority of headers currently
+   defined.  (Only the Type field is guaranteed in size and offset.)
+
+   Therefore, a middlebox cannot guarantee to be able to process header
+   chains that may contain headers defined after the box was
+   manufactured.  As discussed further in Section 2.1.9.3, middleboxes
+   ought not to have to know the detailed layout of all header types in
+   use but still need to be able to skip over such headers to find the
+   transport payload start.  If this is not possible, it either limits
+   the security policy that can be applied in firewalls or makes it
+   difficult to deploy new extension header types.
+
+   At the time of writing, only the Fragment Header does not fully
+   conform to the TLV format used for other extension headers.  In
+   practice, many firewalls reconstruct fragmented packets before
+   performing deep packet inspection, so this divergence is less
+   problematic than it might have been, and is at least partially
+   justified because the full header chain is not present in all
+   fragments.
+
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 12]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   Hop-by-hop and destination options may also contain unknown options.
+   However, the options are required to be encoded in TLV format so that
+   intermediate nodes can skip over them during processing, unlike the
+   enclosing extension headers.
+
+2.1.9.3.  Unknown Headers/Destination Options and Security Policy
+
+   A strict security policy might dictate that packets containing either
+   unknown headers or destination options are discarded by firewalls or
+   other filters.  This requires the firewall to process the whole
+   extension header chain, which may be currently in conflict with the
+   IPv6 specification as discussed in Section 2.1.9.1.
+
+   Even if the firewall does inspect the whole header chain, it may not
+   be sensible to discard packets with items unrecognized by the
+   firewall: the intermediate node has no knowledge of which options and
+   headers are implemented in the destination node and IPv6 has been
+   deliberately designed to be extensible through adding new header
+   options.  This poses a dilemma for firewall administrators.  On the
+   one hand, admitting packets with 'unknown' options is a security
+   risk, but dropping them may disable a useful new extension.  The best
+   compromise appears to be to select firewalls that provide a
+   configurable discard policy based on the types of the extensions.
+   Then, if a new extension is standardized, administrators can
+   reconfigure firewalls to pass packets with legitimate items that they
+   would otherwise not recognize because their hardware or software is
+   not aware of a new definition.  Provided that the new extensions
+   conform to the TLV layout followed by current extensions, the
+   firewall would not need detailed knowledge of the function or layout
+   of the extension header.
+
+2.1.9.4.  Excessive Hop-by-Hop Options
+
+   IPv6 does not limit the number of hop-by-hop options that can be
+   present in a hop-by-hop option header, and any option can appear
+   multiple times.  The lack of a limit and the provision of
+   extensibility bits that force nodes to ignore classes of options that
+   they do not understand can be used to mount denial-of-service attacks
+   affecting all nodes on a path.  A packet with large numbers of
+   unknown hop-by-hop options will be processed at every node through
+   which it is forwarded, consuming significant resources to determine
+   what action should be taken for each option.  Current options with
+   the exception of Pad1 and PadN should not appear more than once so
+   that packets with inappropriately repeated options can be dropped.
+   However, keeping track of which options have been seen adds
+   complexity to firewalls and may not apply to future extensions.  See
+   Section 2.1.9.3 for a discussion of the advisability of dropping
+   packets with unknown options in firewalls.
+
+
+
+Davies, et al.               Informational                     [Page 13]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+2.1.9.5.  Misuse of Pad1 and PadN Options
+
+   IPv6 allows multiple padding options of arbitrary sizes to be placed
+   in both Hop-by-Hop and Destination option headers.
+
+   PadN options are required to contain zero octets as 'payload'; there
+   is, however, no incentive for receivers to check this.  It may
+   therefore be possible to use the 'payload' of padding options as a
+   covert channel.  Firewalls and receiving hosts should actively check
+   that PadN only has zero octets in its 'payload'.
+
+   There is no legitimate reason for padding beyond the next eight octet
+   boundary since the whole option header is aligned on an eight-octet
+   boundary but cannot be guaranteed to be on a 16 (or higher power of
+   two)-octet boundary.  The IPv6 specification allows multiple Pad1 and
+   PadN options to be combined in any way that the source chooses to
+   make up the required padding.  Reasonable design choices would appear
+   to be using however many Pad1 options (i.e., zero octets) are needed
+   or using a single PadN option of the required size (from two up to
+   seven octets).  Administrators should consider at least logging
+   unusual padding patterns, and may consider dropping packets that
+   contain unusual patterns if they are certain of expected source
+   behavior.
+
+2.1.9.6.  Overuse of Router Alert Option
+
+   The IPv6 router alert option specifies a hop-by-hop option that, if
+   present, signals the router to take a closer look at the packet.
+   This can be used for denial-of-service attacks.  By sending a large
+   number of packets containing a router alert option, an attacker can
+   deplete the processor cycles on the routers available to legitimate
+   traffic.
+
+2.1.10.  Fragmentation: Reassembly and Deep Packet Inspection
+
+   The current specifications of IPv6 in [RFC2460] do not mandate any
+   minimum packet size for the fragments of a packet before the last
+   one, except for the need to carry the unfragmentable part in all
+   fragments.
+
+   The unfragmentable part does not include the transport port numbers,
+   so it is possible that the first fragment does not contain sufficient
+   information to carry out deep packet inspection involving the port
+   numbers.
+
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 14]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   Packets with overlapping fragments are considered to be a major
+   security risk, but the reassembly rules for fragmented packets in
+   [RFC2460] do not mandate behavior that would minimize the effects of
+   overlapping fragments.
+
+   In order to ensure that deep packet inspection can be carried out
+   correctly on fragmented packets, many firewalls and other nodes that
+   use deep packet inspection will collect the fragments and reassemble
+   the packet before examining it.  Depending on the implementation of
+   packet reassembly and the treatment of packet fragments in these
+   nodes, the specification issues mentioned potentially leave IPv6 open
+   to the sort of attacks described in [RFC1858] and [RFC3128] for IPv4.
+
+   The following steps can be taken to mitigate these threats:
+
+   o  Although permitted in [RFC2460], there is no reason for a source
+      to generate overlapping packet fragments, and overlaps could be
+      prohibited in a future revision of the protocol specification.
+      Firewalls should drop all packets with overlapped fragments:
+      certain implementations both in firewalls and other nodes already
+      drop such packets.
+
+   o  Specifying a minimum size for packet fragments does not help in
+      the same way as it does for IPv4 because IPv6 extension headers
+      can be made to appear very long: an attacker could insert one or
+      more undefined destination options with long lengths and the
+      'ignore if unknown' bit set.  Given the guaranteed minimum MTU of
+      IPv6, it seems reasonable that hosts should be able to ensure that
+      the transport port numbers are in the first fragment in almost all
+      cases and that deep packet inspection should be very suspicious of
+      first fragments that do not contain them (see also the discussion
+      of fragment sizes in Section 2.1.11).
+
+2.1.11.  Fragmentation Related DoS Attacks
+
+   Packet reassembly in IPv6 hosts also opens up the possibility of
+   various fragment-related security attacks.  Some of these are
+   analogous to attacks identified for IPv4.  Of particular concern is a
+   DoS attack based on sending large numbers of small fragments without
+   a terminating last fragment that would potentially overload the
+   reconstruction buffers and consume large amounts of CPU resources.
+
+   Mandating the size of packet fragments could reduce the impact of
+   this kind of attack by limiting the rate at which fragments could
+   arrive and limiting the number of fragments that need to be
+   processed, but this is not currently specified by the IPv6 standard.
+   In practice, reasonable design choices in protocol stacks are likely
+   to either maximize the size of all fragments except the final one
+
+
+
+Davies, et al.               Informational                     [Page 15]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   using the path MTU (most likely choice), or distribute the data
+   evenly in the required minimum number of fragments.  In either case,
+   the smallest non-final fragment would be at least half the guaranteed
+   minimum MTU (640 octets) -- the worst case arises when a payload is
+   just too large for a single packet and is divided approximately
+   equally between two packets.  Administrators should consider
+   configuring firewalls and hosts to drop non-final fragments smaller
+   than 640 octets.
+
+2.1.12.  Link-Local Addresses and Securing Neighbor Discovery
+
+   All IPv6 nodes are required to configure a link-local address on each
+   interface.  This address is used to communicate with other nodes
+   directly connected to the link accessed via the interface, especially
+   during the neighbor discovery and autoconfiguration processes.  Link-
+   local addresses are fundamental to the operation of the Neighbor
+   Discovery Protocol (NDP) [RFC2461] and Stateless Address
+   Autoconfiguration (SLAAC) [RFC2462].  NDP also provides the
+   functionality of associating link-layer and IP addresses provided by
+   the Address Resolution Protocol (ARP) in IPv4 networks.
+
+   The standard version of NDP is subject to a number of security
+   threats related to ARP spoofing attacks on IPv4.  These threats are
+   documented in [RFC3756], and mechanisms to combat them are specified
+   in SEcure Neighbor Discovery (SEND) [RFC3971].  SEND is an optional
+   mechanism that is particularly applicable to wireless and other
+   environments where it is difficult to physically secure the link.
+
+   Because the link-local address can, by default, be acquired without
+   external intervention or control, it allows an attacker to commence
+   communication on the link without needing to acquire information
+   about the address prefixes in use or communicate with any authorities
+   on the link.  This feature gives a malicious node the opportunity to
+   mount an attack on any other node that is attached to this link; this
+   vulnerability exists in addition to possible direct attacks on NDP.
+   Link-local addresses may also facilitate the unauthorized use of the
+   link bandwidth ('bandwidth theft') to communicate with another
+   unauthorized node on the same link.
+
+   The vulnerabilities of IPv6 link-local addresses in NDP can be
+   mitigated in several ways.  A general solution will require
+
+   o  authenticating the link-layer connectivity, for example, by using
+      IEEE 802.1X functionality [IEEE.802-1X] or physical security, and
+
+   o  using SEcure Neighbor Discovery (SEND) to create a
+      cryptographically generated link-local address (as described in
+      [RFC3971]) that is tied to the authenticated link-layer address.
+
+
+
+Davies, et al.               Informational                     [Page 16]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   This solution would be particularly appropriate in wireless LAN
+   deployments where it is difficult to physically secure the
+   infrastructure, but it may not be considered necessary in wired
+   environments where the physical infrastructure can be kept secure by
+   other means.
+
+   Limiting the potentiality for abuse of link-local addresses in
+   general packet exchanges is more problematic because there may be
+   circumstances, such as isolated networks, where usage is appropriate
+   and discrimination between use and abuse requires complex filtering
+   rules which have to be implemented on hosts.  The risk of misuse may
+   be deemed too small compared with the effort needed to control it,
+   but special attention should be paid to tunnel end-points (see 2.4,
+   3.2, and 3.3).
+
+   Any filtering has to be provided by a host-based or bridging
+   firewall.  In general, link-local addresses are expected to be used
+   by applications that are written to deal with specific interfaces and
+   links.  Typically these applications are used for control and
+   management.  A node which is attached to multiple links has to deal
+   with the potentially overlapping link-local address spaces associated
+   with these links.  IPv6 provides for this through zone identifiers
+   that are used to discriminate between the different address scopes
+   [RFC4007] and the scope identifier that can be associated with a
+   socket address structure [RFC3493].  Most users are unfamiliar with
+   these issues and general purpose applications are not intended to
+   handle this kind of discrimination. link-local addresses are not
+   normally used with the Domain Name System (DNS), and DNS cannot
+   supply zone identifiers.  If it is considered necessary to prevent
+   the use of link-local addresses by means other than control and
+   management protocols, administrators may wish to consider limiting
+   the protocols that can be used with link-local addresses.  At a
+   minimum, ICMPv6 and any intra-domain routing protocol in use (such as
+   Open Shortest Path First (OSPF) or Routing Information Protocol
+   (RIP)) need to be allowed, but other protocols may also be needed.
+   RIP illustrates the complexity of the filtering problem: its messages
+   are encapsulated as User Datagram Protocol (UDP) payloads, and
+   filtering needs to distinguish RIP messages addressed to UDP port 521
+   from other UDP messages.
+
+2.1.13.  Securing Router Advertisements
+
+   As part of the Neighbor Discovery process, routers on a link
+   advertise their capabilities in Router Advertisement messages.  The
+   version of NDP defined in [RFC2461] does not protect the integrity of
+   these messages or validate the assertions made in the messages with
+   the result that any node that connects to the link can maliciously
+   claim to offer routing services that it will not fulfill, and
+
+
+
+Davies, et al.               Informational                     [Page 17]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   advertise inappropriate prefixes and parameters.  These threats have
+   been documented in [RFC3756].
+
+   A malicious node may also be able to carry out a DoS attack by
+   deprecating an established valid prefix (by advertising it with a
+   zero lifetime).  Similar DoS attacks are possible if the optional
+   Router Selection mechanism is implemented as described in the
+   security considerations of [RFC4191].
+
+   SEND [RFC3971] can be used to provide verification that routers are
+   authorized to provide the services they advertise through a
+   certificate-based mechanism.  This capability of SEND is also
+   particularly appropriate for wireless environments where clients are
+   reliant on the assertions of the routers rather than a physically
+   secured connection.
+
+2.1.14.  Host-to-Router Load Sharing
+
+   If a host deploys the optional host-to-router load-sharing mechanism
+   [RFC4311], a malicious application could carry out a DoS attack on
+   one or more of the load-sharing routers if the application is able to
+   use knowledge of the load-sharing algorithm to synthesize traffic
+   that subverts the load-sharing algorithm and directs a large volume
+   of bogus traffic towards a subset of the routers.  The likelihood of
+   such an attack can be reduced if the implementation uses a
+   sufficiently sophisticated load sharing algorithm as described in the
+   security considerations of [RFC4311].
+
+2.1.15.  Mobile IPv6
+
+   Mobile IPv6 offers significantly enhanced security compared with
+   Mobile IPv4 especially when using optimized routing and care-of
+   addresses.  Return routability checks are used to provide relatively
+   robust assurance that the different addresses that a mobile node uses
+   as it moves through the network do indeed all refer to the same node.
+   The threats and solutions are described in [RFC3775], and a more
+   extensive discussion of the security aspects of the design can be
+   found in [RFC4225].
+
+2.1.15.1.  Obsolete Home Address Option in Mobile IPv6
+
+   The Home Address option specified in early versions of Mobile IPv6
+   would have allowed a trivial source spoofing attack: hosts were
+   required to substitute the source address of incoming packets with
+   the address in the option, thereby potentially evading checks on the
+   packet source address.  The version of Mobile IPv6 as standardized in
+
+
+
+
+
+Davies, et al.               Informational                     [Page 18]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   [RFC3775] has removed this issue by ensuring that the Home Address
+   destination option is only processed if there is a corresponding
+   binding cache entry and securing Binding Update messages.
+
+   A number of pre-standard implementations of Mobile IPv6 were
+   available that implemented this obsolete and insecure option: care
+   should be taken to avoid running such obsolete systems.
+
+2.2.  IPv4-Mapped IPv6 Addresses
+
+   Overloaded functionality is always a double-edged sword: it may yield
+   some deployment benefits, but often also incurs the price that comes
+   with ambiguity.
+
+   One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a
+   representation of an IPv4 address as an IPv6 address inside an
+   operating system as defined in [RFC3493].  Since the original
+   specification, the use of IPv4-mapped addresses has been extended to
+   a transition mechanism, Stateless IP/ICMP Translation algorithm
+   (SIIT) [RFC2765], where they are potentially used in the addresses of
+   packets on the wire.
+
+   Therefore, it becomes difficult to unambiguously discern whether an
+   IPv4 mapped address is really an IPv4 address represented in the IPv6
+   address format (basic API behavior) *or* an IPv6 address received
+   from the wire (which may be subject to address forgery, etc.).  (SIIT
+   behavior).  The security issues that arise from the ambiguous
+   behavior when IPv4-mapped addresses are used on the wire include:
+
+   o  If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in
+      the IPv6 source address field, he might be able to bypass a node's
+      access controls by deceiving applications into believing that the
+      packet is from the node itself (specifically, the IPv4 loopback
+      address, 127.0.0.1).  The same attack might be performed using the
+      node's IPv4 interface address instead.
+
+   o  If an attacker transmits an IPv6 packet with IPv4-mapped addresses
+      in the IPv6 destination address field corresponding to IPv4
+      addresses inside a site's security perimeter (e.g., ::ffff:
+      10.1.1.1), he might be able to bypass IPv4 packet filtering rules
+      and traverse a site's firewall.
+
+   o  If an attacker transmits an IPv6 packet with IPv4-mapped addresses
+      in the IPv6 source and destination fields to a protocol that swaps
+      IPv6 source and destination addresses, he might be able to use a
+      node as a proxy for certain types of attacks.  For example, this
+      might be used to construct broadcast multiplication and proxy TCP
+      port scan attacks.
+
+
+
+Davies, et al.               Informational                     [Page 19]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   In addition, special cases like these, while giving deployment
+   benefits in some areas, require a considerable amount of code
+   complexity (e.g., in the implementations of bind() system calls and
+   reverse DNS lookups) that is probably undesirable but can be managed
+   in this case.
+
+   In practice, although the packet translation mechanisms of SIIT are
+   specified for use in "Network Address Translator - Protocol
+   Translator (NAT-PT)" [RFC2766], NAT-PT uses a mechanism different
+   from IPv4-mapped IPv6 addresses for communicating embedded IPv4
+   addresses in IPv6 addresses.  Also, SIIT is not recommended for use
+   as a standalone transition mechanism.  Given the issues that have
+   been identified, it seems appropriate that mapped addresses should
+   not be used on the wire.  However, changing application behavior by
+   deprecating the use of mapped addresses in the operating system
+   interface would have significant impact on application porting
+   methods as described in [RFC4038], and it is expected that IPv4-
+   mapped IPv6 addresses will continue to be used within the API to aid
+   application portability.
+
+   Using the basic API behavior has some security implications in that
+   it adds additional complexity to address-based access controls.  The
+   main issue that arises is that an IPv6 (AF_INET6) socket will accept
+   IPv4 packets even if the node has no IPv4 (AF_INET) sockets open.
+   This has to be taken into account by application developers and may
+   allow a malicious IPv4 peer to access a service even if there are no
+   open IPv4 sockets.  This violates the security principle of "least
+   surprise".
+
+2.3.  Increased End-to-End Transparency
+
+   One of the major design aims of IPv6 has been to maintain the
+   original IP architectural concept of end-to-end transparency.
+   Transparency can help foster technological innovation in areas such
+   as peer-to-peer communication, but maintaining the security of the
+   network at the same time requires some modifications in the network
+   architecture.  Ultimately, it is also likely to need changes in the
+   security model as compared with the norms for IPv4 networks.
+
+2.3.1.  IPv6 Networks without NATs
+
+   The necessity of introducing Network Address Translators (NATs) into
+   IPv4 networks, resulting from a shortage of IPv4 addresses, has
+   removed the end-to-end transparency of most IPv4 connections: the use
+   of IPv6 would restore this transparency.  However, the use of NATs,
+   and the associated private addressing schemes, has become
+   inappropriately linked to the provision of security in enterprise
+   networks.  The restored end-to-end transparency of IPv6 networks can
+
+
+
+Davies, et al.               Informational                     [Page 20]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   therefore be seen as a threat by poorly informed enterprise network
+   managers.  Some seem to want to limit the end-to-end capabilities of
+   IPv6, for example by deploying private, local addressing and
+   translators, even when it is not necessary because of the abundance
+   of IPv6 addresses.
+
+   Recommendations for designing an IPv6 network to meet the perceived
+   security and connectivity requirements implicit in the current usage
+   of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end
+   transparency are described in "IP Version 6 Network Architecture
+   Protection" [RFC4864].
+
+2.3.2.  Enterprise Network Security Model for IPv6
+
+   The favored model for enterprise network security in IPv4 stresses
+   the use of a security perimeter policed by autonomous firewalls and
+   incorporating the NATs.  Both perimeter firewalls and NATs introduce
+   asymmetry and reduce the transparency of communications through these
+   perimeters.  The symmetric bidirectionality and transparency that are
+   extolled as virtues of IPv6 may seem to be at odds with this model.
+   Consequently, network managers may even see them as undesirable
+   attributes, in conflict with their need to control threats to and
+   attacks on the networks they administer.
+
+   It is worth noting that IPv6 does not *require* end-to-end
+   connectivity.  It merely provides end-to-end addressability; the
+   connectivity can still be controlled using firewalls (or other
+   mechanisms), and it is indeed wise to do so.
+
+   A number of matters indicate that IPv6 networks should migrate
+   towards an improved security model, which will increase the overall
+   security of the network while at the same time facilitating end-to-
+   end communication:
+
+   o  Increased usage of end-to-end security especially at the network
+      layer.  IPv6 mandates the provision of IPsec capability in all
+      nodes, and increasing usage of end-to-end security is a challenge
+      to current autonomous firewalls that are unable to perform deep
+      packet inspection on encrypted packets.  It is also incompatible
+      with NATs because they modify the packets, even when packets are
+      only authenticated rather than encrypted.
+
+   o  Acknowledgement that over-reliance on the perimeter model is
+      potentially dangerous.  An attacker who can penetrate today's
+      perimeters will have free rein within the perimeter, in many
+      cases.  Also a successful attack will generally allow the attacker
+      to capture information or resources and make use of them.
+
+
+
+
+Davies, et al.               Informational                     [Page 21]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   o  Development of mechanisms such as 'Trusted Computing' [TCGARCH]
+      that will increase the level of trust that network managers are
+      able to place on hosts.
+
+   o  Development of centralized security policy repositories and secure
+      distribution mechanisms that, in conjunction with trusted hosts,
+      will allow network managers to place more reliance on security
+      mechanisms at the end-points.  The mechanisms are likely to
+      include end-node firewalling and intrusion detection systems as
+      well as secure protocols that allow end-points to influence the
+      behavior of perimeter security devices.
+
+   o  Review of the role of perimeter devices with increased emphasis on
+      intrusion detection, and network resource protection and
+      coordination to thwart distributed denial-of-service attacks.
+
+   Several of the technologies required to support an enhanced security
+   model are still under development, including secure protocols to
+   allow end-points to control firewalls: the complete security model
+   utilizing these technologies is now emerging but still requires some
+   development.
+
+   In the meantime, initial deployments will need to make use of similar
+   firewalling and intrusion detection techniques to IPv4 that may limit
+   end-to-end transparency temporarily, but should be prepared to use
+   the new security model as it develops and avoid the use of NATs by
+   the use of the architectural techniques described in [RFC4864].  In
+   particular, using NAT-PT [RFC2766] as a general purpose transition
+   mechanism should be avoided as it is likely to limit the exploitation
+   of end-to-end security and other IPv6 capabilities in the future as
+   explained in [RFC4966].
+
+2.4.  IPv6 in IPv6 Tunnels
+
+   IPv6 in IPv6 tunnels can be used to circumvent security checks, so it
+   is essential to filter packets both at tunnel ingress and egress
+   points (the encapsulator and decapsulator) to ensure that both the
+   inner and outer addresses are acceptable, and the tunnel is not being
+   used to carry inappropriate traffic.  [RFC3964], which is primarily
+   about the 6to4 transition tunneling mechanism (see Section 3.1),
+   contains useful discussions of possible attacks and ways to
+   counteract these threats.
+
+
+
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 22]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+3.  Issues Due to Transition Mechanisms
+
+3.1.  IPv6 Transition/Coexistence Mechanism-Specific Issues
+
+   The more complicated the IPv6 transition/coexistence becomes, the
+   greater the danger that security issues will be introduced either
+
+   o  in the mechanisms themselves,
+
+   o  in the interaction between mechanisms, or
+
+   o  by introducing unsecured paths through multiple mechanisms.
+
+   These issues may or may not be readily apparent.  Hence, it would be
+   desirable to keep the mechanisms simple (as few in number as possible
+   and built from pieces as small as possible) to simplify analysis.
+
+   One case where such security issues have been analyzed in detail is
+   the 6to4 tunneling mechanism [RFC3964].
+
+   As tunneling has been proposed as a model for several more cases than
+   are currently being used, its security properties should be analyzed
+   in more detail.  There are some generic dangers to tunneling:
+
+   o  It may be easier to avoid ingress filtering checks.
+
+   o  It is possible to attack the tunnel interface: several IPv6
+      security mechanisms depend on checking that Hop Limit equals 255
+      on receipt and that link-local addresses are used.  Sending such
+      packets to the tunnel interface is much easier than gaining access
+      to a physical segment and sending them there.
+
+   o  Automatic tunneling mechanisms are typically particularly
+      dangerous as there is no pre-configured association between end
+      points.  Accordingly, at the receiving end of the tunnel, packets
+      have to be accepted and decapsulated from any source.
+      Consequently, special care should be taken when specifying
+      automatic tunneling techniques.
+
+3.2.  Automatic Tunneling and Relays
+
+   Two mechanisms have been specified that use automatic tunneling and
+   are intended for use outside a single domain.  These mechanisms
+   encapsulate the IPv6 packet directly in an IPv4 packet in the case of
+   6to4 [RFC3056] or in an IPv4 UDP packet in the case of Teredo
+   [RFC4380].  In each case, packets can be sent and received by any
+   similarly equipped nodes in the IPv4 Internet.
+
+
+
+
+Davies, et al.               Informational                     [Page 23]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   As mentioned in Section 3.1, a major vulnerability in such approaches
+   is that receiving nodes must allow decapsulation of traffic sourced
+   from anywhere in the Internet.  This kind of decapsulation function
+   must be extremely well secured because of the wide range of potential
+   sources.
+
+   An even more difficult problem is how these mechanisms are able to
+   establish communication with native IPv6 nodes or between the
+   automatic tunneling mechanisms: such connectivity requires the use of
+   some kind of "relay".  These relays could be deployed in various
+   locations such as:
+
+   o  all native IPv6 nodes,
+
+   o  native IPv6 sites,
+
+   o  in IPv6-enabled ISPs, or
+
+   o  just somewhere in the Internet.
+
+   Given that a relay needs to trust all the sources (e.g., in the 6to4
+   case, all 6to4 routers) that are sending it traffic, there are issues
+   in achieving this trust and at the same time scaling the relay system
+   to avoid overloading a small number of relays.
+
+   As authentication of such a relay service is very difficult to
+   achieve, and particularly so in some of the possible deployment
+   models, relays provide a potential vehicle for address spoofing,
+   (reflected) denial-of-service attacks, and other threats.
+
+   Threats related to 6to4 and measures to combat them are discussed in
+   [RFC3964].  [RFC4380] incorporates extensive discussion of the
+   threats to Teredo and measures to combat them.
+
+3.3.  Tunneling IPv6 through IPv4 Networks May Break IPv4 Network
+      Security Assumptions
+
+   NATs and firewalls have been deployed extensively in the IPv4
+   Internet, as discussed in Section 2.3.  Operators who deploy them
+   typically have some security/operational requirements in mind (e.g.,
+   a desire to block inbound connection attempts), which may or may not
+   be misguided.
+
+   The addition of tunneling can change the security model that such
+   deployments are seeking to enforce.  IPv6-over-IPv4 tunneling using
+   protocol 41 is typically either explicitly allowed, or disallowed
+   implicitly.  Tunneling IPv6 over IPv4 encapsulated in UDP constitutes
+   a more difficult problem as UDP must usually be allowed to pass
+
+
+
+Davies, et al.               Informational                     [Page 24]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   through NATs and firewalls.  Consequently, using UDP implies the
+   ability to punch holes in NATs and firewalls although, depending on
+   the implementation, this ability may be limited or only achieved in a
+   stateful manner.  In practice, the mechanisms have been explicitly
+   designed to traverse both NATs and firewalls in a similar fashion.
+
+   One possible view is that the use of tunneling is especially
+   questionable in home and SOHO (small office/home office) environments
+   where the level of expertise in network administration is typically
+   not very high; in these environments, the hosts may not be as tightly
+   managed as in others (e.g., network services might be enabled
+   unnecessarily), leading to possible security break-ins or other
+   vulnerabilities.
+
+   Holes allowing tunneled traffic through NATs and firewalls can be
+   punched both intentionally and unintentionally.  In cases where the
+   administrator or user makes an explicit decision to create the hole,
+   this is less of a problem, although (for example) some enterprises
+   might want to block IPv6 tunneling explicitly if employees were able
+   to create such holes without reference to administrators.  On the
+   other hand, if a hole is punched transparently, it is likely that a
+   proportion of users will not understand the consequences: this will
+   very probably result in a serious threat sooner or later.
+
+   When deploying tunneling solutions, especially tunneling solutions
+   that are automatic and/or can be enabled easily by users who do not
+   understand the consequences, care should be taken not to compromise
+   the security assumptions held by the users.
+
+   For example, NAT traversal should not be performed by default unless
+   there is a firewall producing a similar by-default security policy to
+   that provided by IPv4 NAT.  IPv6-in-IPv4 (protocol 41) tunneling is
+   less of a problem, as it is easier to block if necessary; however, if
+   the host is protected in IPv4, the IPv6 side should be protected as
+   well.
+
+   As is shown in Appendix A, it is relatively easy to determine the
+   IPv6 address corresponding to an IPv4 address in tunneling
+   deployments.  It is therefore vital NOT to rely on "security by
+   obscurity", i.e., assuming that nobody is able to guess or determine
+   the IPv6 address of the host especially when using automatic
+   tunneling transition mechanisms.
+
+   The network architecture must provide separate IPv4 and IPv6
+   firewalls with tunneled IPv6 traffic arriving encapsulated in IPv4
+   packets routed through the IPv4 firewall before being decapsulated,
+   and then through the IPv6 firewall as shown in Figure 1.
+
+
+
+
+Davies, et al.               Informational                     [Page 25]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+                +--------+      +--------+      +--------+
+      Site      | Native | IPv6 |v6 in v4| IPv4 | Native |      Public
+   Network <--->|  IPv6  |<---->| Tunnel |<---->|  IPv4  |<---> Internet
+                |Firewall|      |Endpoint|      |Firewall|
+                +--------+      +--------+      +--------+
+
+                 Figure 1: Tunneled Traffic and Firewalls
+
+4.  Issues Due to IPv6 Deployment
+
+4.1.  Avoiding the Trap of Insecure IPv6 Service Piloting
+
+   Because IPv6 is a new service for many networks, network managers
+   will often opt to make a pilot deployment in a part of the network to
+   gain experience and understand the problems as well as the benefits
+   that may result from a full production quality IPv6 service.
+
+   Unless IPv6 service piloting is done in a manner that is as secure as
+   possible, there is a risk that if security in the pilot does not
+   match up to what is achievable with current IPv4 production service,
+   the comparison can adversely impact the overall assessment of the
+   IPv6 pilot deployment.  This may result in a decision to delay or
+   even avoid deploying an IPv6 production service.  For example, hosts
+   and routers might not be protected by IPv6 firewalls, even if the
+   corresponding IPv4 service is fully protected by firewalls.  The use
+   of tunneling transition mechanisms (see Section 3.3) and the
+   interaction with virtual private networks also need careful attention
+   to ensure that site security is maintained.  This is particularly
+   critical where IPv6 capabilities are turned on by default in new
+   equipment or new releases of operating systems: network managers may
+   not be fully aware of the security exposure that this creates.
+
+   In some cases, a perceived lack of availability of IPv6 firewalls and
+   other security capabilities, such as intrusion detection systems may
+   have led network managers to resist any kind of IPv6 service
+   deployment.  These problems may be partly due to the relatively slow
+   development and deployment of IPv6-capable security equipment, but
+   the major problems appear to have been a lack of information, and
+   more importantly a lack of documented operational experience on which
+   managers can draw.  In actual fact, at the time of writing, there are
+   a significant number of alternative IPv6 packet filters and firewalls
+   already in existence that could be used to provide sufficient access
+   controls.
+
+   However, there are a small number of areas where the available
+   equipment and capabilities may still be a barrier to secure
+   deployment as of the time of writing:
+
+
+
+
+Davies, et al.               Informational                     [Page 26]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   o  'Personal firewalls' with support for IPv6 and intended for use on
+      hosts are not yet widely available.
+
+   o  Enterprise firewalls are at an early stage of development and may
+      not provide the full range of capabilities needed to implement the
+      necessary IPv6 filtering rules.  Network managers often expect the
+      same devices that support and are used for IPv4 today to also
+      become IPv6-capable -- even though this is not really required and
+      the equipment may not have the requisite hardware capabilities to
+      support fast packet filtering for IPv6.  Suggestions for the
+      appropriate deployment of firewalls are given in Section 3.3 -- as
+      will be seen from this section, it is usually desirable that the
+      firewalls are in separate boxes, and there is no necessity for
+      them to be same the model of equipment.
+
+   o  A lesser factor may be that some design decisions in the IPv6
+      protocol make it more difficult for firewalls to be implemented
+      and work in all cases, and to be fully future-proof (e.g., when
+      new extension headers are used) as discussed in Section 2.1.9.  It
+      is significantly more difficult for intermediate nodes to process
+      the IPv6 header chains than IPv4 packets.
+
+   o  Adequate Intrusion Detection Systems (IDS) are more difficult to
+      construct for IPv6.  IDSs are now beginning to become available
+      but the pattern-based mechanisms used for IPv4 may not be the most
+      appropriate for long-term development of these systems as end-to-
+      end encryption becomes more prevalent.  Future systems may be more
+      reliant on traffic flow pattern recognition.
+
+   o  Implementations of high availability capabilities supporting IPv6
+      are also in short supply.  In particular, development of the IPv6
+      version of the Virtual Router Redundancy Protocol (VRRP) [VRRP]
+      has lagged the development of the main IPv6 protocol although
+      alternatives may be available for some environments.
+
+   In all these areas, developments are ongoing and they should not be
+   considered a long-term bar to the deployment of IPv6 either as a
+   pilot or production service.  The necessary tools are now available
+   to make a secure IPv6 deployment, and with careful selection of
+   components and design of the network architecture, a successful pilot
+   or production IPv6 service can be deployed.  Recommendations for
+   secure deployment and appropriate management of IPv6 networks can be
+   found in the documentation archives of the European Union 6net
+   project [SIXNET] and in the Deployment Guide published by the IPv6
+   Promotion Council of Japan [JpIPv6DC].
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 27]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+4.2.  DNS Server Problems
+
+   Some DNS server implementations have flaws that severely affect DNS
+   queries for IPv6 addresses as discussed in [RFC4074].  These flaws
+   can be used for DoS attacks affecting both IPv4 and IPv6 by inducing
+   caching DNS servers to believe that a domain is broken and causing
+   the server to block access to all requests for the domain for a
+   precautionary period.
+
+4.3.  Addressing Schemes and Securing Routers
+
+   Whilst in general terms brute force scanning of IPv6 subnets is
+   essentially impossible due to the enormously larger address space of
+   IPv6 and the 64-bit interface identifiers (see Appendix A), this will
+   be obviated if administrators do not take advantage of the large
+   space to use unguessable interface identifiers.
+
+   Because of the unmemorability of complete IPv6 addresses, there is a
+   temptation for administrators to use small integers as interface
+   identifiers when manually configuring them, as might happen on point-
+   to-point links or when provisioning complete addresses from a DHCPv6
+   server.  Such allocations make it easy for an attacker to find active
+   nodes that they can then port scan.
+
+   To make use of the larger address space properly, administrators
+   should be very careful when entering IPv6 addresses in their
+   configurations (e.g., access control lists), since numerical IPv6
+   addresses are more prone to human error than IPv4 due to their length
+   and unmemorability.
+
+   It is also essential to ensure that the management interfaces of
+   routers are well secured (e.g., allowing remote access using Secure
+   Shell (SSH) only and ensuring that local craft interfaces have non-
+   default passwords) as the router will usually contain a significant
+   cache of neighbor addresses in its neighbor cache.
+
+4.4.  Consequences of Multiple Addresses in IPv6
+
+   One positive consequence of IPv6 is that nodes that do not require
+   global access can communicate locally just by the use of a link-local
+   address (if very local access is sufficient) or across the site by
+   using a Unique Local Address (ULA).  In either case it is easy to
+   ensure that access outside the assigned domain of activity can be
+   controlled by simple filters (which should be the default for link-
+   locals).  However, the security hazards of using link-local addresses
+   for general purposes, as documented in Section 2.1.12, should be
+   borne in mind.
+
+
+
+
+Davies, et al.               Informational                     [Page 28]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   On the other hand, the possibility that a node or interface can have
+   multiple global scope addresses makes access control filtering (both
+   on ingress and egress) more complex and requires higher maintenance
+   levels.  Vendors and network administrators need to be aware that
+   multiple addresses are the norm rather than the exception in IPv6:
+   when building and selecting tools for security and management, a
+   highly desirable feature is the ability to be able to 'tokenize'
+   access control lists and configurations in general to cater for
+   multiple addresses and/or address prefixes.
+
+   The addresses could be from the same network prefix (for example,
+   privacy mechanisms [RFC4941] will periodically create new addresses
+   taken from the same prefix, and two or more of these may be active at
+   the same time), or from different prefixes (for example, when a
+   network is multihomed, when for management purposes a node belongs to
+   several subnets on the same link or is implementing anycast
+   services).  In all these cases, it is possible that a single host
+   could be using several different addresses with different prefixes
+   and/or different interface identifiers.  It is desirable that the
+   security administrator be able to identify that the same host is
+   behind all these addresses.
+
+   Some network administrators may find the mutability of addresses when
+   privacy mechanisms are used in their network to be undesirable
+   because of the current difficulties in maintaining access control
+   lists and knowing the origin of traffic.  In general, disabling the
+   use of privacy addresses is only possible if the full stateful DHCPv6
+   mechanism [RFC3315] is used to allocate IPv6 addresses and DHCPv6
+   requests for privacy addresses are not honored.
+
+4.5.  Deploying ICMPv6
+
+   In IPv4 it is commonly accepted that some filtering of ICMP packets
+   by firewalls is essential to maintain security.  Because of the
+   extended use that is made of ICMPv6 [RFC2461] with a multitude of
+   functions, the simple set of dropping rules that are usually applied
+   in IPv4 need to be significantly developed for IPv6.  The blanket
+   dropping of all ICMP messages that is used in some very strict
+   environments is simply not possible for IPv6.
+
+   In an IPv6 firewall, policy needs to allow some messages through the
+   firewall but also has to permit certain messages to and from the
+   firewall, especially those with link-local sources on links to which
+   the firewall is attached.  These messages must be permitted to ensure
+   that Neighbor Discovery [RFC2462], Multicast Listener Discovery
+   ([RFC2710], [RFC3810]), and Stateless Address Configuration [RFC4443]
+   work as expected.
+
+
+
+
+Davies, et al.               Informational                     [Page 29]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   Recommendations for filtering ICMPv6 messages can be found in
+   [RFC4890].
+
+4.5.1.  Problems Resulting from ICMPv6 Transparency
+
+   As described in Section 4.5, certain ICMPv6 error packets need to be
+   passed through a firewall in both directions.  This means that some
+   ICMPv6 error packets can be exchanged between inside and outside
+   without any filtering.
+
+   Using this feature, malicious users can communicate between the
+   inside and outside of a firewall, thus bypassing the administrator's
+   inspection (proxy, firewall, etc.).  For example, it might be
+   possible to carry out a covert conversation through the payload of
+   ICMPv6 error messages or to tunnel inappropriate encapsulated IP
+   packets in ICMPv6 error messages.  This problem can be alleviated by
+   filtering ICMPv6 errors using a stateful packet inspection mechanism
+   to ensure that the packet carried as a payload is associated with
+   legitimate traffic to or from the protected network.
+
+4.6.  IPsec Transport Mode
+
+   IPsec provides security to end-to-end communications at the network
+   layer (layer 3).  The security features available include access
+   control, connectionless integrity, data origin authentication,
+   protection against replay attacks, confidentiality, and limited
+   traffic flow confidentiality (see [RFC4301] Section 2.1).  IPv6
+   mandates the implementation of IPsec in all conforming nodes, making
+   the usage of IPsec to secure end-to-end communication possible in a
+   way that is generally not available to IPv4.
+
+   To secure IPv6 end-to-end communications, IPsec transport mode would
+   generally be the solution of choice.  However, use of these IPsec
+   security features can result in novel problems for network
+   administrators and decrease the effectiveness of perimeter firewalls
+   because of the increased prevalence of encrypted packets on which the
+   firewalls cannot perform deep packet inspection and filtering.
+
+   One example of such problems is the lack of security solutions in the
+   middlebox, including effective content-filtering, ability to provide
+   DoS prevention based on the expected TCP protocol behavior, and
+   intrusion detection.  Future solutions to this problem are discussed
+   in Section 2.3.2.  Another example is an IPsec-based DoS (e.g.,
+   sending malformed ESP/AH packets) that can be especially detrimental
+   to software-based IPsec implementations.
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 30]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+4.7.  Reduced Functionality Devices
+
+   With the deployment of IPv6 we can expect the attachment of a very
+   large number of new IPv6-enabled devices with scarce resources and
+   low computing capacity.  The resource limitations are generally
+   because of a market requirement for cost reduction.  Although the
+   [RFC4294] specifies some mandatory security capabilities for every
+   conformant node, these do not include functions required for a node
+   to be able to protect itself.  Accordingly, some such devices may not
+   be able even to perform the minimum set of functions required to
+   protect themselves (e.g., 'personal' firewall, automatic firmware
+   update, enough CPU power to endure DoS attacks).  This means a
+   different security scheme may be necessary for such reduced
+   functionality devices.
+
+4.8.  Operational Factors when Enabling IPv6 in the Network
+
+   There are a number of reasons that make it essential to take
+   particular care when enabling IPv6 in the network equipment:
+
+   Initially, IPv6-enabled router software may be less mature than
+   current IPv4-only implementations, and there is less experience with
+   configuring IPv6 routing, which can result in disruptions to the IPv6
+   routing environment and (IPv6) network outages.
+
+   IPv6 processing may not happen at (near) line speed (or at a
+   comparable performance level to IPv4 in the same equipment).  A high
+   level of IPv6 traffic (even legitimate, e.g., Network News Transport
+   Protocol, NNTP) could easily overload IPv6 processing especially when
+   it is software-based without the hardware support typical in high-end
+   routers.  This may potentially have deleterious knock-on effects on
+   IPv4 processing, affecting availability of both services.
+   Accordingly, if people don't feel confident enough in the IPv6
+   capabilities of their equipment, they will be reluctant to enable it
+   in their "production" networks.
+
+   Sometimes essential features may be missing from early releases of
+   vendors' software; an example is provision of software enabling IPv6
+   telnet/SSH access (e.g., to the configuration application of a
+   router), but without the ability to turn it off or limit access to
+   it!
+
+   Sometimes the default IPv6 configuration is insecure.  For example,
+   in one vendor's implementation, if you have restricted IPv4 telnet to
+   only a few hosts in the configuration, you need to be aware that IPv6
+   telnet will be automatically enabled, that the configuration commands
+
+
+
+
+
+Davies, et al.               Informational                     [Page 31]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   used previously do not block IPv6 telnet, that IPv6 telnet is open to
+   the world by default, and that you have to use a separate command to
+   also lock down the IPv6 telnet access.
+
+   Many operator networks have to run interior routing protocols for
+   both IPv4 and IPv6.  It is possible to run them both in one routing
+   protocol, or have two separate routing protocols; either approach has
+   its tradeoffs [RFC4029].  If multiple routing protocols are used, one
+   should note that this causes double the amount of processing when
+   links flap or recalculation is otherwise needed -- which might more
+   easily overload the router's CPU, causing slightly slower convergence
+   time.
+
+4.9.  Security Issues Due to Neighbor Discovery Proxies
+
+   In order to span a single subnet over multiple physical links, a new
+   experimental capability is being trialed in IPv6 to proxy Neighbor
+   Discovery messages.  A node with this capability will be called an
+   NDProxy (see [RFC4389]).  NDProxies are susceptible to the same
+   security issues as those faced by hosts using unsecured Neighbor
+   Discovery or ARP.  These proxies may process unsecured messages, and
+   update the neighbor cache as a result of such processing, thus
+   allowing a malicious node to divert or hijack traffic.  This may
+   undermine the advantages of using SEND [RFC3971].
+
+   If a form of NDProxy is standardized, SEND will need to be extended
+   to support this capability.
+
+5.  Security Considerations
+
+   This memo attempts to give an overview of security considerations of
+   the different aspects of IPv6, particularly as they relate to the
+   transition to a network in which IPv4- and IPv6-based communications
+   need to coexist.
+
+6.  Acknowledgements
+
+   This document draws together the work of many people who have
+   contributed security-related documents to the IPV6 and V6OPS working
+   groups.  Alain Durand, Alain Baudot, Luc Beloeil, Sharon Chisholm,
+   Tim Chown, Lars Eggert, Andras Kis-Szabo, Vishwas Manral, Janos
+   Mohacsi, Mark Smith, Alvaro Vives, and Margaret Wassermann provided
+   feedback to improve this document.  Satoshi Kondo, Shinsuke Suzuki,
+   and Alvaro Vives provided additional inputs in cooperation with the
+   Deployment Working Group of the Japanese IPv6 Promotion Council and
+   the Euro6IX IST co-funded project, together with inputs from Jordi
+   Palet, Brian Carpenter, and Peter Bieringer.  Michael Wittsend and
+   Michael Cole discussed issues relating to probing/mapping and
+
+
+
+Davies, et al.               Informational                     [Page 32]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   privacy.  Craig Metz and Jun-ichiro itojun Hagino did the original
+   work identifying the problems of using IPv4-mapped IPv6 addresses on
+   the wire.  Vishwas Manral made further investigations of the impact
+   of tiny fragments on IPv6 security.  Francis Dupont raised the issues
+   relating to IPv6 Privacy Addresses.  Finally, Pekka Savola wrote a
+   number of documents on aspects IPv6 security which have been subsumed
+   into this work.  His document on "Firewalling Considerations for
+   IPv6" (October 2003) originally identified many of the issues with
+   the base IPv6 specification which are documented here.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1122]      Braden, R., "Requirements for Internet Hosts -
+                  Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC2375]      Hinden, R. and S. Deering, "IPv6 Multicast Address
+                  Assignments", RFC 2375, July 1998.
+
+   [RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
+                  6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2461]      Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+                  Discovery for IP Version 6 (IPv6)", RFC 2461,
+                  December 1998.
+
+   [RFC2462]      Thomson, S. and T. Narten, "IPv6 Stateless Address
+                  Autoconfiguration", RFC 2462, December 1998.
+
+   [RFC2710]      Deering, S., Fenner, W., and B. Haberman, "Multicast
+                  Listener Discovery (MLD) for IPv6", RFC 2710,
+                  October 1999.
+
+   [RFC3056]      Carpenter, B. and K. Moore, "Connection of IPv6
+                  Domains via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3775]      Johnson, D., Perkins, C., and J. Arkko, "Mobility
+                  Support in IPv6", RFC 3775, June 2004.
+
+   [RFC3810]      Vida, R. and L. Costa, "Multicast Listener Discovery
+                  Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+   [RFC3964]      Savola, P. and C. Patel, "Security Considerations for
+                  6to4", RFC 3964, December 2004.
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 33]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   [RFC4007]      Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
+                  and B. Zill, "IPv6 Scoped Address Architecture",
+                  RFC 4007, March 2005.
+
+   [RFC4291]      Hinden, R. and S. Deering, "IP Version 6 Addressing
+                  Architecture", RFC 4291, February 2006.
+
+   [RFC4380]      Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+                  Network Address Translations (NATs)", RFC 4380,
+                  February 2006.
+
+   [RFC4443]      Conta, A., Deering, S., and M. Gupta, "Internet
+                  Control Message Protocol (ICMPv6) for the Internet
+                  Protocol Version 6 (IPv6) Specification", RFC 4443,
+                  March 2006.
+
+   [RFC4941]      Narten, T., Draves, R., and S. Krishnan, "Privacy
+                  Extensions for Stateless Address Autoconfiguration in
+                  IPv6", RFC 4941, September 2007.
+
+7.2.  Informative References
+
+   [FNAT]         Bellovin, S., "Technique for Counting NATted Hosts",
+                  Proc. Second Internet Measurement Workshop ,
+                  November 2002,
+                  <http://www.research.att.com/~smb/papers/fnat.pdf>.
+
+   [ICMP-ATT]     Gont, F., "ICMP attacks against TCP", Work
+                  in Progress, May 2007.
+
+   [IEEE.802-1X]  Institute of Electrical and Electronics Engineers,
+                  "Port-Based Network Access Control", IEEE Standard for
+                  Local and Metropolitan Area Networks 802.1X-2004,
+                  December 2004.
+
+   [JpIPv6DC]     Deployment WG, "IPv6 Deployment Guideline (2005
+                  Edition)", IPv6 Promotion Council (Japan) Deployment
+                  Working Group, 2005, <http://www.v6pc.jp/>.
+
+   [RFC1858]      Ziemba, G., Reed, D., and P. Traina, "Security
+                  Considerations for IP Fragment Filtering", RFC 1858,
+                  October 1995.
+
+   [RFC2765]      Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+                  (SIIT)", RFC 2765, February 2000.
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 34]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   [RFC2766]      Tsirtsis, G. and P. Srisuresh, "Network Address
+                  Translation - Protocol Translation (NAT-PT)",
+                  RFC 2766, February 2000.
+
+   [RFC3128]      Miller, I., "Protection Against a Variant of the Tiny
+                  Fragment Attack (RFC 1858)", RFC 3128, June 2001.
+
+   [RFC3315]      Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+                  C., and M. Carney, "Dynamic Host Configuration
+                  Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3493]      Gilligan, R., Thomson, S., Bound, J., McCann, J., and
+                  W. Stevens, "Basic Socket Interface Extensions for
+                  IPv6", RFC 3493, February 2003.
+
+   [RFC3756]      Nikander, P., Kempf, J., and E. Nordmark, "IPv6
+                  Neighbor Discovery (ND) Trust Models and Threats",
+                  RFC 3756, May 2004.
+
+   [RFC3971]      Arkko, J., Kempf, J., Zill, B., and P. Nikander,
+                  "SEcure Neighbor Discovery (SEND)", RFC 3971,
+                  March 2005.
+
+   [RFC4025]      Richardson, M., "A Method for Storing IPsec Keying
+                  Material in DNS", RFC 4025, March 2005.
+
+   [RFC4029]      Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
+                  Savola, "Scenarios and Analysis for Introducing IPv6
+                  into ISP Networks", RFC 4029, March 2005.
+
+   [RFC4038]      Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+                  Castro, "Application Aspects of IPv6 Transition",
+                  RFC 4038, March 2005.
+
+   [RFC4074]      Morishita, Y. and T. Jinmei, "Common Misbehavior
+                  Against DNS Queries for IPv6 Addresses", RFC 4074,
+                  May 2005.
+
+   [RFC4191]      Draves, R. and D. Thaler, "Default Router Preferences
+                  and More-Specific Routes", RFC 4191, November 2005.
+
+   [RFC4225]      Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
+                  E. Nordmark, "Mobile IP Version 6 Route Optimization
+                  Security Design Background", RFC 4225, December 2005.
+
+   [RFC4294]      Loughney, J., "IPv6 Node Requirements", RFC 4294,
+                  April 2006.
+
+
+
+
+Davies, et al.               Informational                     [Page 35]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   [RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
+                  Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4311]      Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
+                  Sharing", RFC 4311, November 2005.
+
+   [RFC4389]      Thaler, D., Talwar, M., and C. Patel, "Neighbor
+                  Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
+
+   [RFC4472]      Durand, A., Ihren, J., and P. Savola, "Operational
+                  Considerations and Issues with IPv6 DNS", RFC 4472,
+                  April 2006.
+
+   [RFC4864]      Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
+                  and E. Klein, "Local Network Protection for IPv6",
+                  RFC 4864, May 2007.
+
+   [RFC4890]      Davies, E. and J. Mohacsi, "Recommendations for
+                  Filtering ICMPv6 Messages in Firewalls", RFC 4890,
+                  May 2007.
+
+   [RFC4966]      Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
+                  Historic Status", RFC 4966, July 2007.
+
+   [SCAN-IMP]     Chown, T., "IPv6 Implications for Network Scanning",
+                  Work in Progress, March 2007.
+
+   [SIXNET]       6Net, "Large Scale International IPv6 Pilot Network",
+                  EU Information Society Technologies Project , 2005,
+                  <http://www.6net.org/>.
+
+   [TCGARCH]      The Trusted Computing Group, "TCG Specification
+                  Architecture Overview", April 2004, <https://
+                  www.trustedcomputinggroup.org/groups/
+                  TCG_1_0_Architecture_Overview.pdf>.
+
+   [VRRP]         Hinden, R. and J. Cruz, "Virtual Router Redundancy
+                  Protocol for IPv6", Work in Progress, March 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 36]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+Appendix A.  IPv6 Probing/Mapping Considerations
+
+   One school of thought wanted the IPv6 numbering topology (either at
+   network or node level) to match IPv4 as exactly as possible, whereas
+   others see IPv6 as giving more flexibility to the address plans, not
+   wanting to constrain the design of IPv6 addressing.  Mirroring the
+   address plans is now generally seen as a security threat because an
+   IPv6 deployment may have different security properties from IPv4.
+
+   Given the relatively immature state of IPv6 network security, if an
+   attacker knows the IPv4 address of the node and believes it to be
+   dual-stacked with IPv4 and IPv6, he might want to try to probe the
+   corresponding IPv6 address, based on the assumption that the security
+   defenses might be lower.  This might be the case particularly for
+   nodes which are behind a NAT in IPv4, but globally addressable in
+   IPv6.  Naturally, this is not a concern if similar and adequate
+   security policies are in place.
+
+   On the other hand, brute-force scanning or probing of addresses is
+   computationally infeasible due to the large search space of interface
+   identifiers on most IPv6 subnets (somewhat less than 64 bits wide,
+   depending on how identifiers are chosen), always provided that
+   identifiers are chosen at random out of the available space, as
+   discussed in [SCAN-IMP].
+
+   For example, automatic tunneling mechanisms typically use
+   deterministic methods for generating IPv6 addresses, so probing/
+   port-scanning an IPv6 node is simplified.  The IPv4 address is
+   embedded at least in 6to4, Teredo, and ISATAP addresses.
+   Additionally, it is possible (in the case of 6to4 in particular) to
+   learn the address behind the prefix; for example, Microsoft 6to4
+   implementation uses the address 2002:V4ADDR::V4ADDR while older Linux
+   and FreeBSD implementations default to 2002:V4ADDR::1.  This could
+   also be used as one way to identify an implementation and hence
+   target any specific weaknesses.
+
+   One proposal has been to randomize the addresses or subnet identifier
+   in the address of the 6to4 router.  This does not really help, as the
+   6to4 router (whether a host or a router) will return an ICMPv6 Hop
+   Limit Exceeded message, revealing the IP address.  Hosts behind the
+   6to4 router can use methods such as privacy addresses [RFC4941] to
+   conceal themselves, provided that they are not meant to be reachable
+   by sessions started from elsewhere; they would still require a
+   globally accessible static address if they wish to receive
+   communications initiated elsewhere.
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 37]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+   To conclude, it seems that when an automatic tunneling mechanism is
+   being used, given an IPv4 address, the corresponding IPv6 address
+   could possibly be guessed with relative ease.  This has significant
+   implications if the IPv6 security policy is less adequate than that
+   for IPv4.
+
+Appendix B.  IPv6 Privacy Considerations
+
+   The generation of IPv6 addresses from MAC addresses potentially
+   allows the behavior of users to be tracked in a way which may
+   infringe their privacy.  [RFC4941] specifies mechanisms which can be
+   used to reduce the risk of infringement.  It has also been claimed
+   that IPv6 harms the privacy of the user, either by exposing the MAC
+   address, or by exposing the number of nodes connected to a site.
+
+   Additional discussion of privacy issues can be found in [RFC4864].
+
+B.1.  Exposing MAC Addresses
+
+   Using stateless address autoconfiguration results in the MAC address
+   being incorporated in an EUI64 that exposes the model of network
+   card.  The concern has been that a user might not want to expose the
+   details of the system to outsiders, e.g., fearing a resulting
+   burglary if a thief identifies expensive equipment from the vendor
+   identifier embedded in MAC addresses, or allowing the type of
+   equipment in use to be identified, thus facilitating an attack on
+   specific security weaknesses.
+
+   In most cases, this seems completely unfounded.  First, such an
+   address must be learned somehow -- this is a non-trivial process; the
+   addresses are visible, e.g., in Web site access logs, but the chances
+   that a random Web site owner is collecting this kind of information
+   (or whether it would be of any use) are quite slim.  Being able to
+   eavesdrop the traffic to learn such addresses (e.g., by the
+   compromise of DSL (Digital Subscriber Line) or Cable modem physical
+   media) seems also quite far-fetched.  Further, using statically
+   configured interface identifiers or privacy addresses [RFC4941] for
+   such purposes is straightforward if worried about the risk.  Second,
+   the burglar would have to be able to map the IP address to the
+   physical location; typically this would only be possible with
+   information from the private customer database of the Internet
+   Service Provider (ISP) and, for large sites, the administrative
+   records of the site, although some physical address information may
+   be available from the WHOIS database of Internet registries.
+
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 38]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+B.2.  Exposing Multiple Devices
+
+   Another concern that has been aired involves the user wanting to
+   conceal the presence of a large number of computers or other devices
+   connected to a network; NAT can "hide" all this equipment behind a
+   single address, but it is not perfect either [FNAT].
+
+   One practical reason why some administrators may find this desirable
+   is being able to thwart certain ISPs' business models.  These models
+   require payment based on the number of connected computers, rather
+   than the connectivity as a whole.
+
+   Similar feasibility issues as described above apply.  To a degree,
+   the number of machines present could be obscured by the sufficiently
+   frequent reuse of privacy addresses [RFC4941] -- that is, if during a
+   short period, dozens of generated addresses seem to be in use, it's
+   difficult to estimate whether they are generated by just one host or
+   multiple hosts.
+
+B.3.  Exposing the Site by a Stable Prefix
+
+   When an ISP provides IPv6 connectivity to its customers, including
+   home or consumer users, it delegates a fixed global routing prefix
+   (usually a /48) to them.  This is in contrast to the typical IPv4
+   situation where home users typically receive a dynamically allocated
+   address that may be stable only for a period of hours.
+
+   Due to this fixed allocation, it is easier to correlate the global
+   routing prefix to a network site.  With consumer users, this
+   correlation leads to a privacy issue, since a site is often
+   equivalent to an individual or a family in such a case.  Consequently
+   some users might be concerned about being able to be tracked based on
+   their /48 allocation if it is static [RFC4941].  On the other hand,
+   many users may find having a static allocation desirable as it allows
+   them to offer services hosted in their network more easily.
+
+   This situation is not affected even if a user changes his/her
+   interface ID or subnet ID, because malicious users can still discover
+   this binding.  On larger sites, the situation can be mitigated by
+   using "untraceable" IPv6 addresses as described in [RFC4864], and it
+   is possible that in the future ISPs might be prepared to offer
+   untraceable addresses to their consumer customers to minimize the
+   privacy issues.
+
+   This privacy issue is common to both IPv4 and IPv6 and is inherent in
+   the use of IP addresses as both identifiers for node interfaces and
+   locators for the nodes.
+
+
+
+
+Davies, et al.               Informational                     [Page 39]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+Authors' Addresses
+
+   Elwyn B. Davies
+   Consultant
+   Soham, Cambs
+   UK
+
+   Phone: +44 7889 488 335
+   EMail: elwynd@dial.pipex.com
+
+
+   Suresh Krishnan
+   Ericsson
+   8400 Decarie Blvd.
+   Town of Mount Royal, QC  H4P 2N2
+   Canada
+
+   Phone: +1 514-345-7900
+   EMail: suresh.krishnan@ericsson.com
+
+
+   Pekka Savola
+   CSC/Funet
+
+   EMail: psavola@funet.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 40]
+
+RFC 4942                 IPv6 Security Overview           September 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Davies, et al.               Informational                     [Page 41]
+