RFC4942 日本語訳

4942 IPv6 Transition/Co-existence Security Considerations. E. Davies,S. Krishnan, P. Savola. September 2007. (Format: TXT=102878 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          E. Davies
Request for Comments: 4942                                    Consultant
Category: Informational                                      S. Krishnan
                                                                Ericsson
                                                               P. Savola
                                                               CSC/Funet
                                                          September 2007

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

IPv6 Transition/Coexistence Security Considerations

Status of This Memo

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.

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

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.

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

Davies, et al. Informational [Page 1] RFC 4942 IPv6 Security Overview September 2007

Table of Contents

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

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

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

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

Davies, et al. Informational [Page 3] RFC 4942 IPv6 Security Overview September 2007

1.  Introduction

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.

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.

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).

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

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

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

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.

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.

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

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.

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

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.

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:

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

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 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.)

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.

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.

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

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.

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

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.

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.

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

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.

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.

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.

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

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.

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.

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

Davies, et al. Informational [Page 7] RFC 4942 IPv6 Security Overview September 2007

   The cases in which responses are sent are:

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 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.

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.

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 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.

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

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].

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:

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

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 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 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 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.

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

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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

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].

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.

SLAAC[RFC4941]にPrivacy Extensionsを使用すると、DDNSのアップデートの速度はかなり増強されるかもしれません。 Privacy Extensionsを使用するノードが'前進'のルックアップのためのアドレスを発表しないでも(それが事実上、それが求めているプライバシーに感染するだろうというとき)、それは、まだ逆のDNS記録をアップデートする必要があるかもしれません。 逆のDNS記録をアップデートしないと、逆のDNSチェックを実行するサーバがノードから接続を受け入れないでしょう、そして、IP Security(IPsec)へのアクセスを得るのは可能であっても、DNS[RFC4025]に保存された材料を合わせないでしょう。 本当のプライバシーを達成するのに必要である増減率が増強されなければならないなら(セクション2.1.7を見てください)、DDNSのアップデート率は過度であるかもしれません。

   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.

同様である、暗号で、最大の主要な生涯の推薦に沿ってSEND[RFC3971]によって使用された生成アドレスが定期的に作り直されると予想されます。 また、この再生はかなりの上積みされた荷物をDDNSに課すかもしれません。

2.1.9.  Extension Headers

2.1.9. 拡張ヘッダー

   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].

IPv6 Extensionヘッダーに関連する多くの安全保障問題が特定されました。 ベースIPv6仕様[RFC2460]でこれらの数個があいまいであるか不完全な仕様の結果です。

2.1.9.1.  Processing Extension Headers in Middleboxes

2.1.9.1. 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.

IPv4では、深いパケット点検テクニックはルータの一部とファイアウォールなどのmiddleboxesで両方を取り締まって、フィルターにかけるのにおいて実装するのにおいて使用されています。 IPv6へのこれらのテクニックを完全に広げるのはパケットでのすべての拡張ヘッダーの点検を必要とするでしょう。 これは、確信しているヘッダーとオプションの使用の方針規制が励行されるのを保証して、取り外すのに最も早い機会(潜在的にダメージが大きい未知のオプションを含むパケット)で不可欠です。

   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).

この要件はホップごとのオプションだけがパケットが適切な目的地(最終的な目的地かルーティングヘッダー中間点のどちらか)に達するまでパケットが通るどんなノードでも処理されるのを必要とする[RFC2460]のIPv6仕様のセクション4と衝突するように見えます。

   Also, [RFC2460] forbids processing the headers other than in the
   order in which they appear in the packet.

また、[RFC2460]は彼らがパケットに現れるオーダー以外のヘッダーを処理に禁じます。

Davies, et al.               Informational                     [Page 11]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [11ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

したがって、[RFC2460]は、パケットを点検しているかもしれなくて、その結果潜在的にこれらの箱の機密保持を制限するmiddleboxesと他の非最終的な目的地の振舞いを考慮に入れるように見えません。 ファイアウォールベンダーと管理者は、これが現在定義されたセットの拡大を伴うどんな深刻な結果も持っているように見えないとき警備の強化を提供するためにこれらの規則を無視するのを選ぶかもしれません。 しかしながら、管理者は将来の拡張子が異なった処理を必要とするかもしれないのを意識しているべきです。

2.1.9.2.  Processing Extension Header Chains

2.1.9.2. 処理拡張ヘッダーチェインズ

   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.

IPv6ヘッダーチェーンの端に位置している輸送ヘッダーを調べたがっているmiddleboxesのためのさらなる問題があります。 輸送ヘッダーか他のプロトコルデータ単位の場所を見つけるように、ノードはヘッダーチェーンを分析しなければなりません。

   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.)

それは現在定義されているヘッダーの大部分に使用されますが、IPv6仕様[RFC2460]は固定レイアウトによるType長さの価値(TLV)の形式のそれぞれのヘッダーの始まりの使用を強制しません。 (Type分野だけが、サイズで保証されて、相殺されます。)

   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.

したがって、middleboxは、箱が製造された後に定義されたヘッダーを含むかもしれないヘッダーチェーンを処理できるのを保証できません。 すべてのヘッダーの詳細なレイアウトが使用しますが、輸送ペイロードがまだ見つけるそのようなヘッダーを飛ばすことができるのが必要であると.3、middleboxesが、知るべきである必要はないタイプするセクション2.1.9で、より詳しく議論するように、始まってください。 これが可能でないなら、それで、ファイアウォールで適用できる安全保障政策を制限するか、または新しい拡張ヘッダーがタイプであると配布するのが難しくなります。

   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.

Fragment Headerだけが完全に他の拡張ヘッダーに使用されるTLV形式に従うというわけではありません。 深いパケット点検を実行する前に実際には、多くのファイアウォールが断片化しているパケットを再建するので、この分岐は、それであるかもしれないほど問題が多くなく、完全なヘッダーチェーンがすべての断片に存在していないので、少なくとも部分的に正当化されます。

Davies, et al.               Informational                     [Page 12]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [12ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

ホップで跳んでください。そうすれば、また、目的地オプションは未知のオプションを含んでもよいです。 しかしながら、オプションが中間的ノードが処理の間、それらを飛ばすことができるようにTLV形式でコード化されるのに必要です、同封の拡張ヘッダーと異なって。

2.1.9.3.  Unknown Headers/Destination Options and Security Policy

2.1.9.3. 未知のヘッダー/目的地オプションと安全保障政策

   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.

厳しい安全保障政策は、未知のヘッダーか目的地オプションのどちらかを含むパケットがファイアウォールか他のフィルタによって捨てられると決めるかもしれません。 これは、全体の拡張ヘッダーチェーンを処理するためにファイアウォールを必要とします。(チェーンは現在、IPv6仕様との闘争セクション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.

ファイアウォールが全体のヘッダーチェーンを点検しても、項目が認識されていない状態でファイアウォールのそばでパケットを捨てるのは分別がないかもしれません: 中間的ノードには、オプションとヘッダーが目的地ノードを実装されて、IPv6が新しいヘッダーオプションを加えることで広げることができるように故意に設計されている知識が全くありません。 これはファイアウォール管理者のためにジレンマを引き起こします。 一方では、'未知'のオプションがあるパケットを認めるのは、セキュリティリスクですが、それらを下げるのは役に立つ新しい拡大を無効にするかもしれません。 最も良い感染は拡大のタイプで方針に基づいている構成可能な破棄を提供するファイアウォールを選択することになっているように見えます。 そして、新しい拡大が標準化されるなら、管理者は、それらのハードウェアかソフトウェアが新しい定義を意識していないので彼らが別の方法で認識しない正統の項目でパケットを通過するためにファイアウォールを再構成できます。 新しい拡大が現在の拡大があとに続いたTLVレイアウトに従えば、ファイアウォールは機能に関する詳細な知識か拡張ヘッダーのレイアウトを必要としないでしょう。

2.1.9.4.  Excessive Hop-by-Hop Options

2.1.9.4. ホップごとの過度のオプション

   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.

IPv6はホップごとのオプションヘッダーでホップごとの存在する場合があるオプションの数を制限しません、そして、どんなオプションも複数の回現れることができます。 無視するそれらがするオプションのクラスが使用できるのを理解していないノードがやむを得ず経路のすべてのノードに影響するサービス不能攻撃を仕掛ける限界の不足と伸展性ビットの設備。 ホップごとの多くの未知のオプションがあるパケットはそれが進められるあらゆるノードで処理されるでしょう、どんな行動が各オプションに取られるべきであるかを決定するために重要なリソースを消費して。 Pad1とPadN以外の現在のオプションは、不適当に繰り返されたオプションがあるパケットを下げることができるように一度より多く見えるべきではありません。 しかしながら、オプションを見てある動向をおさえるのは、複雑さをファイアウォールに追加して、今後の拡大に適用されないかもしれません。 未知との滴下パケットの得策の議論のための.3がファイアウォールでゆだねるセクション2.1.9を見てください。

Davies, et al.               Informational                     [Page 13]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [13ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

2.1.9.5.  Misuse of Pad1 and PadN Options

2.1.9.5. Pad1とPadNオプションの誤用

   IPv6 allows multiple padding options of arbitrary sizes to be placed
   in both Hop-by-Hop and Destination option headers.

IPv6は、任意のサイズの複数の詰め物オプションがホップによるHopとDestinationオプションヘッダーの両方に置かれるのを許容します。

   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'.

PadNオプションが'ペイロード'として八重奏を全く含まないように必要です。 しかしながら、受信機がこれをチェックする誘因が全くありません。 したがって、ひそかなチャンネルとして詰め物オプションの'ペイロード'を使用するのは可能であるかもしれません。 ファイアウォールと受信ホストは、PadNには'ペイロード'における八重奏が全くあるだけではないのを活発にチェックするべきです。

   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.

全体のオプションヘッダーを8八重奏の境界で並べられますが、16(または、2の、より高いパワー)八重奏境界にあるように保証できないで以来の次の8八重奏境界を超えてそっと歩くもっともな理由が全くありません。 IPv6仕様で、複数のPad1とPadNオプションはソースが必要な詰め物を作るのを選ぶどんな方法でも結合します。 合理的なデザイン選択はしかしながら、必要である、または必要なサイズ(2上から7つの八重奏までの)のただ一つのPadNオプションを使用することで多くのPad1オプション(すなわち、八重奏がない)を使用しているように見えるでしょう。 管理者は、珍しい詰め物パターンを少なくとも登録すると考えるべきであり、それらが予想されたソースの振舞いが確かであるなら異常パターンを含むパケットを下げると考えるかもしれません。

2.1.9.6.  Overuse of Router Alert Option

2.1.9.6. ルータ警戒オプションの酷使

   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.

IPv6ルータ警戒オプションはホップごとの存在しているならパケットへの、より近い一見を取るようにルータに示すオプションを指定します。 サービス不能攻撃にこれを使用できます。 ルータ警戒オプションを含む多くのパケットを送ることによって、攻撃者は正統のトラフィックに利用可能なルータのプロセッササイクルを使い果たすことができます。

2.1.10.  Fragmentation: Reassembly and Deep Packet Inspection

2.1.10. 断片化: Reassemblyであって深いパケット点検

   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.

[RFC2460]のIPv6の現在の仕様は最後のものの前のパケットの断片のために少しの最小のパケットサイズも強制しません、すべての断片で「非-断片-可能」部分を運ぶ必要性を除いて。

   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

デイヴィース、他 [14ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

断片を重ね合わせるパケットは主要なセキュリティリスクであると考えられますが、[RFC2460]の断片化しているパケットのための再アセンブリ規則は断片を重ね合わせるという効果を最小にする振舞いを強制しません。

   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.

断片化しているパケットの上で正しく深いパケット点検を行うことができるのを確実にするために、深いパケット点検を使用する多くのファイアウォールと他のノードは、断片を集めて、それを調べる前に、パケットを組み立て直すでしょう。 パケット再アセンブリの実装とこれらのノードにおける、パケット断片の処理によって、潜在的に参照された仕様問題はIPv6をIPv4のために[RFC1858]と[RFC3128]で説明された攻撃の種類に開かれているままにします。

   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 [RFC2460]で受入れられますが、ソースがパケット断片を重なるのに生成する理由が全くありません、そして、プロトコル仕様の今後の改正でオーバラップは禁止できました。 ファイアウォールは重ね合わせられた断片ですべてのパケットを下げるはずです: ファイアウォールと他のノードのある実装は既にそのようなパケットを下げます。

   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).

o IPv6拡張ヘッダーを作ることができるのでIPv4のためにするのと同様に、パケット断片に最小規模を指定するのは、非常に長い間現れるのを助けません: そして、攻撃者が長い長さで1つ以上の未定義の目的地オプションを挿入できた、'未知の'ビットがセットしたなら、無視します。 IPv6の最低保証額MTUを考えて、ホストが、輸送ポートナンバーが最初の断片にほとんどすべての場合あるのを保証できるべきであって、深いパケット点検が最初に、それらを含まない断片で非常に疑わしげであるはずであることは(また、セクション2.1.11における、断片サイズの議論を見てください)妥当に思えます。

2.1.11.  Fragmentation Related DoS Attacks

2.1.11. 断片化はDoS攻撃を関係づけました。

   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.

また、IPv6ホストのパケット再アセンブリは様々な断片関連のセキュリティー攻撃の可能性を開けます。 これらの或るものはIPv4のために特定された攻撃に類似しています。 特定では、潜在的に再建バッファを積みすぎて、多量のCPUリソースを消費する最後の終わっている断片なしで多くの小さい破片を送ることに基づいた関心はDoS攻撃です。

   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

パケット断片のサイズを強制すると、この種類の攻撃の影響は断片が達することができたレートを制限して、処理される必要がある断片の数を制限することによって、減少するかもしれませんが、これは現在、IPv6規格によって指定されません。 実際には、プロトコル・スタックでの合理的なデザイン選択は最終的なもの以外のすべての断片のサイズを最大にしそうです。

Davies, et al.               Informational                     [Page 15]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [15ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

経路MTU(たぶん選択)を使用するか、または必要な最小の数の断片で均等にデータを分配します。 どちらかの場合では、最も小さい非最終的な断片は少なくとも最低保証額MTU(640の八重奏)の半分でしょう--ペイロードが単一のパケットにはただ大き過ぎ、2つのパケットの間で等しくほとんど分割されるとき、最悪の場合は起こります。 管理者は、非最終的な断片を下げるためにファイアウォールとホストを構成するのが640の八重奏より小さいと考えるべきです。

2.1.12.  Link-Local Addresses and Securing Neighbor Discovery

2.1.12. リンクローカルのアドレスと隣人ディスカバリーを保証すること。

   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.

すべてのIPv6ノードが、各インタフェースでリンクローカルアドレスを構成するのに必要です。 このアドレスは直接インタフェースを通してアクセスされたリンクに接続された他のノードとコミュニケートするのに使用されます、特に隣人発見と自動構成プロセスの間。 リンクのローカルのアドレスはNeighborディスカバリープロトコル(NDP)[RFC2461]とStateless Address Autoconfiguration(SLAAC)[RFC2462]の操作に基本的です。 また、NDPはリンクレイヤとAddress Resolutionプロトコルによって提供されたIPアドレスを関連づける機能性(ARP)をIPv4ネットワークに提供します。

   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.

NDPの標準版はIPv4に対するARPスプーフィング攻撃に関連する多くの軍事的脅威を受けることがあります。 これらの脅威は[RFC3756]に記録されます、そして、それらと戦うメカニズムはSEcure Neighborディスカバリー(SEND)[RFC3971]で指定されます。 SENDは特に物理的にリンクを固定するのが難しいワイヤレスの、そして、他の環境に適切な任意のメカニズムです。

   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.

デフォルトで外部の介入もコントロールなしでリンクローカルアドレスを取得できるので、それで、アドレス接頭語に関して情報を使用中に取得するか、またはリンクの上にどんな当局ともコミュニケートする必要はなくて、攻撃者はリンクに関するコミュニケーションを始めることができます。 この特徴はこのリンクに添付されるいかなる他のノードでも攻撃を開始する機会を悪意があるノードに与えます。 この脆弱性はNDPにおける可能な直接攻撃に加えて存在しています。 また、リンクローカルのアドレスは、同じリンクの上の別の権限のないノードとコミュニケートするためにリンク帯域幅('帯域幅窃盗')の無断使用を容易にするかもしれません。

   The vulnerabilities of IPv6 link-local addresses in NDP can be
   mitigated in several ways.  A general solution will require

いくつかの方法でNDPにおけるIPv6のリンクローカルのアドレスの脆弱性を緩和できます。 一般解は前提となるでしょう。

   o  authenticating the link-layer connectivity, for example, by using
      IEEE 802.1X functionality [IEEE.802-1X] or physical security, and

o そして例えば、IEEE 802.1Xの機能性[IEEE.802-1X]か物理的なセキュリティを使用することによってリンクレイヤの接続性を認証する。

   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.

o aを作成するのに、SEcure Neighborディスカバリー(SEND)を使用すると、認証されたリンクレイヤアドレスに結ばれるリンクローカルアドレス([RFC3971]で説明されるように)は暗号で生成しました。

Davies, et al.               Informational                     [Page 16]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [16ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

このソリューションは物理的にインフラストラクチャを保証するのが難しいところで無線LAN展開で特に適切でしょうが、それは他の手段で物的なインフラを安全に保つことができるところでワイヤードな環境で必要であると考えられないかもしれません。

   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).

一般に、リンク地方の乱用がパケット交換を扱って、事情があるかもしれないので、可能性を制限するのは、より問題が多いです、孤立しているネットワークなどのように。そこでは、用法が適切であり、使用と乱用の間の区別はホストの上で実装されなければならない複雑なフィルタリング規則を必要とします。 それを制御するのに必要である取り組みと比べて、小さ過ぎると誤用の危険を考えるかもしれませんが、特別な注意をエンドポイントにトンネルを堀るのに向けるべきです(2.4、3.2、および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.

ホストベースの、または、ブリッジしているファイアウォールはどんなフィルタリングも提供しなければなりません。 一般に、特定のインタフェースとリンクに対処するために書かれているアプリケーションでリンクローカルのアドレスが使用されると予想されます。 通常、これらのアプリケーションはコントロールと管理に使用されます。 複数のリンクに添付されるノードはこれらのリンクに関連している潜在的に重なっているリンクローカルアドレス空間に対処しなければなりません。 IPv6は異なったアドレスの範囲を区別するのに使用されるゾーン識別子[RFC4007]とソケットアドレス構造に関連づけることができる範囲識別子[RFC3493]を通してこれに備えます。 ほとんどのユーザがこれらの問題になじみがありません、そして、汎用のアプリケーションはこの種類の区別を扱わないつもりです。通常、リンクローカルのアドレスはドメインネームシステム(DNS)と共に使用されません、そして、DNSはゾーン識別子を提供できません。 それがコントロール以外の手段と管理プロトコルでリンクローカルのアドレスの使用を防ぐのに必要であると考えられるなら、管理者は、リンクローカルのアドレスと共に使用できるプロトコルを制限すると考えたがっているかもしれません。 最小限では、ICMPv6と使用中のどんなイントラドメインルーティング・プロトコル(オープンShortest Path First(OSPF)かルーティング情報プロトコル(RIP)などの)も、許容される必要がありますが、また、他のプロトコルが必要であるかもしれません。 RIPはフィルタリング問題の複雑さを例証します: メッセージはユーザー・データグラム・プロトコル(UDP)ペイロードとしてカプセル化されました、そして、RIPメッセージを区別する必要性をフィルターにかけると、ポート521は他のUDPメッセージからUDPに扱われました。

2.1.13.  Securing Router Advertisements

2.1.13. ルータ通知を保証します。

   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

Neighborディスカバリープロセスの一部として、リンクの上のルータはRouter Advertisementメッセージの彼らの能力の広告を出します。 そして[RFC2461]で定義されたNDPのバージョンがこれらのメッセージの保全を保護もしませんし、メッセージでされた主張を有効にもしないで、その結果、リンクに接続するどんなノードも、それが実現させないルーティングサービスを提供すると陰湿に主張できる。

Davies, et al.               Informational                     [Page 17]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [17ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   advertise inappropriate prefixes and parameters.  These threats have
   been documented in [RFC3756].

不適当な接頭語とパラメタの広告を出してください。 これらの脅威は[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].

また、悪意があるノードは、確立した有効な接頭語を非難することによって、DoS攻撃を行うことができるかもしれません(aでそれの広告を出すことによって、生涯のゼロを合わせてください)。 任意のRouter Selectionメカニズムが[RFC4191]のセキュリティ問題で説明されるように実装されるなら、同様のDoS攻撃は可能です。

   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.

それらが証明書ベースのメカニズムを通して広告を出すサービスをルータが提供するのが認可される検証に提供するのに、SEND[RFC3971]を使用できます。 また、ワイヤレスの環境には、SENDのこの能力もクライアントが物理的に機密保護している接続よりむしろルータの主張に頼っているところで特に適切です。

2.1.14.  Host-to-Router Load Sharing

2.1.14. ホストからルータへの負荷分割法

   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].

ホストが、任意のホストからルータが負荷分割法メカニズム[RFC4311]であると配布するなら、アプリケーションがルータの部分集合に負荷分割法アルゴリズムを打倒して、多くのにせのトラフィックを向けるトラフィックを統合するのに負荷分割法アルゴリズムに関する知識を使用できるなら、悪意があるアプリケーションは負荷分割法ルータの1つ以上に対するDoS攻撃を行うかもしれません。 実装が[RFC4311]のセキュリティ問題で説明されるように十分高度な負荷分割法アルゴリズムを使用するなら、そのような攻撃の見込みは減少できます。

2.1.15.  Mobile IPv6

2.1.15. モバイル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].

そして、特に最適化されたルーティングを使用するとき、モバイルIPv6申し出がモバイルIPv4と比べてセキュリティをかなり高めた、注意、-、アドレス。 リターンroutabilityチェックは、本当に、モバイルノードが使用する異なったアドレスがすべて、ネットワークを通して移行すると同じノードを呼ぶという比較的体力を要している保証を提供するのに使用されます。 [RFC3775]で脅威と解答について説明します、そして、[RFC4225]でデザインのセキュリティ局面の、より大規模な議論を見つけることができます。

2.1.15.1.  Obsolete Home Address Option in Mobile IPv6

2.1.15.1. モバイル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

モバイルIPv6の早めのバージョンで指定されたホームAddressオプションは些細なソーススプーフィング攻撃を許したでしょう: ホストはオプションにおけるアドレスで入って来るパケットのソースアドレスを代入しなければなりませんでした、その結果、潜在的に、パケットソースアドレスのチェックを回避します。 中で標準化されるとしてのモバイルIPv6のバージョン

Davies, et al.               Informational                     [Page 18]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [18ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   [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.

[RFC3775]は、対応する拘束力があるキャッシュエントリーがある場合にだけホームAddress目的地オプションが処理されるのを確実にして、Binding Updateにメッセージを保証することによって、この問題を取り除きました。

   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.

モバイルIPv6の多くのプレ標準の実装が利用可能なそんなに実装しているこれほど時代遅れの、そして、不安定なオプションでした: そのような時代遅れのシステムを動かすのを避けるために注意するべきです。

2.2.  IPv4-Mapped IPv6 Addresses

2.2. IPv4によって写像されたIPv6アドレス

   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.

そのようなものに関する1つの例がIPv4によって写像されたIPv6アドレス(: : ffff/96)です: [RFC3493]で定義されるオペレーティングシステムにおけるIPv6アドレスとしてのIPv4アドレスの表現。 正式仕様書以来、IPv4によって写像されたアドレスの使用は変遷メカニズムに広げられています、Stateless IP/ICMP Translationアルゴリズム(SIIT)[RFC2765]、彼らがワイヤの上にパケットのアドレスで潜在的に使用されるところで。

   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:

*したがって、IPv4がアドレスを写像したかどうかが、本当にIPv6アドレス形式(基本的なAPIの振舞い)*に表されたIPv4アドレスであることを明白に明察するのが難しくなったか、またはIPv6アドレスはワイヤ(偽造などを扱うためになることがあるかもしれない)から受信されました。 (SIITの振舞い。) IPv4によって写像されたアドレスがワイヤの上に使用されるときあいまいな振舞いから起こる安全保障問題は:

   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 攻撃者が以下でIPv6パケットを伝えるなら:ffff: 127.0に、IPv6の.1が出典を明示する.0が分野を扱って、彼がパケットがノード自体から来ていると信じているのにアプリケーションをごまかすことによってノードのアクセス制御を迂回させることができるかもしれない、(IPv4ループバックアドレス、明確に127.0、.0 .1)。 同じ攻撃は、代わりにノードのIPv4インターフェース・アドレスを使用することで実行されるかもしれません。

   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 サイトのセキュリティ周辺の中のIPv4によって写像されたアドレスがIPv4アドレスに対応するIPv6目的地アドレス・フィールドにある状態で攻撃者がIPv6パケットを伝える、(例えば、: : ffff: 10.1 .1 .1) 彼は、IPv4パケットフィルタリング規則を迂回させて、サイトのファイアウォールを横断できるかもしれません。

   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.

o IPv6ソースと送付先アドレスを交換するプロトコルへのIPv4によって写像されたアドレスがIPv6ソースとあて先フィールドにある状態で攻撃者がIPv6パケットを伝えるなら、彼はあるタイプの攻撃にプロキシとしてノードを使用できるかもしれません。 例えば、これは、放送乗法とプロキシTCPポート・スキャン攻撃を構成するのに使用されるかもしれません。

Davies, et al.               Informational                     [Page 19]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [19ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

さらに、特別なケースにこれらがいくつかの領域で展開利益を与えている間好きですが、かなりの量のたぶん望ましくないコードの複雑さ(例えば、ひもの()システムコールと逆のDNSルックアップの実装における)を必要としますが、この場合対処できます。

   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.

SIITのパケット変換メカニズムは「アドレス翻訳者をネットワークでつないでください--翻訳者(太平洋標準時のNAT)について議定書の中で述べる」[RFC2766]における使用に指定されますが、実際には、太平洋標準時のNATは、埋め込まれたIPv4アドレスを伝えるのにIPv6アドレスでIPv4によって写像されたIPv6アドレスと異なったメカニズムを使用します。 また、SIITは使用のためにスタンドアロン変遷メカニズムとして推薦されません。 特定された問題を考えて、ワイヤの上に写像しているアドレスを使用するべきでないのは適切に見えます。 しかしながら、オペレーティングシステムインタフェースでの写像しているアドレスの使用を非難することによってアプリケーションの振舞いを変えると、[RFC4038]で説明されるように申込み次第メソッドを移植する重要な影響が与えられるでしょう、そして、IPv4の写像しているIPv6アドレスが、アプリケーションの移植性を支援するのにAPIの中で使用され続けると予想されます。

   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".

基本的なAPIの振舞いを使用するのにおいて、アドレスベースのアクセス制御に追加複雑さを加えるので、いくつかのセキュリティ意味があります。 起こる本題はIPv4(AF_INET)ソケットが全くノードで開かないでもIPv6(AF_INET6)ソケットがIPv4パケットを受け入れるということです。 どんな開いているIPv4ソケットもなくても、これは、アプリケーション開発者によって考慮に入れられなければならなくて、悪意があるIPv4同輩がサービスにアクセスするのを許容するかもしれません。 これは「少しの驚き」のセキュリティ原則に違反します。

2.3.  Increased End-to-End Transparency

2.3. 終わりから終わりへの増強された透明

   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.

IPv6の主要なデザイン目的の1つは終わりから終わりへの透明のオリジナルのIPアーキテクチャ概念を維持することです。 透明は、ピアツーピアコミュニケーションなどの領域の技術革新を伸ばすのを助けることができますが、同時にネットワークのセキュリティを維持するのはネットワークアーキテクチャにおけるいくつかの変更を必要とします。 結局..また..ありそう..必要..変化..機密保護モデル..標準..ネットワーク

2.3.1.  IPv6 Networks without NATs

2.3.1. NATsのないIPv6ネットワーク

   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

IPv4アドレスの不足から生じて、Network Address Translators(NATs)をIPv4ネットワークに取り入れるという必要性はほとんどのIPv4接続の終わりから終わりへの透明を取り除きました: IPv6の使用はこの透明を回復するでしょう。 しかしながら、NATsの使用、および関連個人的なアドレシング体系は不適当に企業網へのセキュリティの支給に繋がるようになりました。 終わりから終わりへのIPv6ネットワークの回復している透明はそうすることができます。

Davies, et al.               Informational                     [Page 20]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [20ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

したがって、不十分に知識がある企業ネットワークマネージャによって脅威と考えられてください。 或るものは終わりから終わりへのIPv6の能力を制限したいように思えます、例えば、個人的で、ローカルのアドレシングと翻訳者を配布することによって、それはIPv6アドレスの豊富のために必要でないときにさえ。

   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].

IPv6終わりから終わりへの透明の利点を維持している間、IPv4 NATsの現在の使用法による暗黙の知覚されたセキュリティと接続性必要条件を満たすようにIPv6ネットワークを設計するための推薦は「IPバージョン6ネットワークアーキテクチャ保護」[RFC4864]で説明されます。

2.3.2.  Enterprise Network Security Model for IPv6

2.3.2. 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.

IPv4の企業網セキュリティのための好評なモデルは自治のファイアウォールによって取り締まられて、NATsを組み込むセキュリティ周辺の使用を強調します。 周辺ファイアウォールとNATsの両方が、非対称を紹介して、これらの周辺を通ってコミュニケーションの透明を減少させます。 左右対称である、双方向性である、そして、IPv6の美徳がこのモデルと仲たがいしてあるように思えるかもしれないように持てはやされる透明。 その結果、ネットワークマネージャは望ましくない属性であるとそれらをみなしさえするかもしれません、それらが管理するネットワークで脅威を制御して、攻撃する彼らの必要性との闘争で。

   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.

IPv6がどんな*もしないことに注意する価値が*終わりから終わりへの接続性を必要とするということです。 それは単に終わりから終わりへのアドレス指定能力を提供します。 ファイアウォール(または、他のメカニズム)を使用することでまだ接続性を制御できます、そして、本当に、そうするのは賢明です。

   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:

多くの件が、IPv6ネットワークが同時に終わりから終わりへのコミュニケーションを容易にしている間、ネットワークの総合的なセキュリティを増強する改良された機密保護モデルに向かって移行するべきであるのを示します:

   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 特にネットワーク層における終わりから終わりへのセキュリティの用法を増強しました。 IPv6はすべてのノードへのIPsec能力の支給を強制します、そして、終わりから終わりへのセキュリティの増加する用法は深いパケット点検を暗号化されたパケットに実行できない現在の自治のファイアウォールへの挑戦です。 また、彼らがパケットを変更するので、パケットが暗号化されるよりむしろ認証さえされるだけであるとき、それもNATsと非互換です。

   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.

o 周辺の甘えがモデル化されるという承認は潜在的に危険です。 今日の周辺に入り込むことができる攻撃者は多くの場合における周辺の中に行動の自由を持つでしょう。 また、うまくいっている攻撃で、攻撃者は、情報かリソースを得て、一般に、それらを利用するでしょう。

Davies, et al.               Informational                     [Page 21]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [21ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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 ネットワークマネージャがホストに置くことができる信頼のレベルを増強する'信じられたComputing'[TCGARCH]などのメカニズムの開発。

   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 ネットワークマネージャが信じられたホストに関連してセキュリティー対策への、より多くの信用をエンドポイントにみなすことができる集結された安全保障政策倉庫と安全な分配メカニズムの開発。 メカニズムは、エンドノードfirewallingと侵入検知システムを含んで、エンドポイントが国境保障デバイスの働きに影響を及ぼすことができるプロトコルを保証しそうです。

   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.

o 分配されたサービス不能攻撃を阻む侵入検出、ネットワーク資源保護、およびコーディネートへの増強された強調による周辺デバイスの役割のレビュー。

   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].

差し当たり、初期の展開は、一時終わりから終わりへの透明を制限するかもしれないIPv4への同様のfirewallingと侵入検出のテクニックを利用するのが必要ですが、[RFC4864]で説明された建築テクニックの使用で展開するとき新しい機密保護モデルを使用して、NATsの使用を避けるように準備されるべきです。 それが将来[RFC4966]で説明されるように終わりから終わりへのセキュリティと他のIPv6能力の攻略を制限しそうなように特に、汎用の変遷メカニズムとして太平洋標準時のNAT[RFC2766]を使用するのは避けられるべきです。

2.4.  IPv6 in IPv6 Tunnels

2.4. IPv6TunnelsのIPv6

   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.

セキュリティチェックを回避するのにIPv6トンネルのIPv6を使用できます、そして、したがって、両方の内側の、そして、外側のアドレスが許容できるのを保証するためにトンネルイングレスと出口ポイント(encapsulatorとdecapsulator)でパケットをフィルターにかけるのが不可欠であり、トンネルは、不適当なトラフィックを運ぶのに使用されていません。 [RFC3964](主として6to4変遷トンネリングメカニズム(セクション3.1を見る)に関するものである)は可能な攻撃とこれらの脅威を打ち消す方法の役に立つ議論を含んでいます。

Davies, et al.               Informational                     [Page 22]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [22ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

3.  Issues Due to Transition Mechanisms

3. 変遷メカニズムによる問題

3.1.  IPv6 Transition/Coexistence Mechanism-Specific Issues

3.1. IPv6変遷/共存のメカニズム特有の問題

   The more complicated the IPv6 transition/coexistence becomes, the
   greater the danger that security issues will be introduced either

IPv6変遷/共存が複雑であれば複雑であるほど、安全保障問題が紹介されるという危険は、より重大です。

   o  in the mechanisms themselves,

o メカニズム自体で

   o  in the interaction between mechanisms, or

o またはメカニズムの間の相互作用で。

   o  by introducing unsecured paths through multiple mechanisms.

o 複数のメカニズムを通して非機密保護している経路を導入することによって。

   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].

そのような安全保障問題が詳細に分析された1つのケースが6to4トンネリングメカニズム[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 チェックをフィルターにかけるイングレスを避けるのは、より簡単であるかもしれません。

   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 トンネルのインタフェースを攻撃するのは可能です: 数個のIPv6セキュリティー対策がHop Limitが領収書の上で255と等しく、リンクローカルのアドレスが使用されているのをチェックするのによります。 そのようなパケットをトンネルのインタフェースに送るのは物理的なセグメントへのアクセスを得て、それらをそこに送るよりはるかに簡単です。

   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.

o エンドポイントの間にあらかじめ設定された協会が全くないとき、自動トンネリングメカニズムは特に通常危険です。 それに従って、パケットは、トンネルの犠牲者では、どんなソースからも受け入れられて、decapsulatedされなければなりません。 自動トンネリングのテクニックを指定するとき、その結果、特別な注意は払われるべきです。

3.2.  Automatic Tunneling and Relays

3.2. 自動トンネリングとリレー

   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.

自動トンネリングを使用して、単一領域の外での使用のために意図する2つのメカニズムが、指定されました。 これらのメカニズムは直接6to4の場合におけるIPv4パケット[RFC3056]かTeredoの場合におけるIPv4 UDPパケット[RFC4380]でIPv6パケットをカプセルに入れります。 その都度、どんな同様に備えられているノードも、IPv4インターネットにパケットを送って、受け取ることができます。

Davies, et al.               Informational                     [Page 23]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [23ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

セクション3.1で言及されるように、そのようなアプローチにおける主要な脆弱性はノードを受け取るとインターネットでどこからでも出典を明示されたトラフィックの被膜剥離術が許容されなければならないということです。 広範囲の可能な源のためにこの種類の被膜剥離術関数を非常によく保証しなければなりません。

   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:

さらに難しい問題はこれらのメカニズムがどのようにコミュニケーションを確立できるかという固有のIPv6ノード、または、自動トンネリングメカニズムの間のことです: そのような接続性はある種の「リレー」の使用を必要とします。 各地で以下のようにこれらのリレーを配布することができました。

   o  all native IPv6 nodes,

o すべての固有のIPv6ノード

   o  native IPv6 sites,

o 固有のIPv6サイト

   o  in IPv6-enabled ISPs, or

o またはIPv6によって可能にされたISPで。

   o  just somewhere in the Internet.

o ちょうどインターネットのどこか。

   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.

リレーが、トラフィックをそれに送るすべてのソース(例えば、6to4場合におけるすべての6to4ルータ)を信じる必要があるなら、この信頼を達成して、同時に少ない数のリレーを積みすぎるのを避けるためにリレー方式をスケーリングするのにおいて問題があります。

   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.

[RFC3964]で6to4に関連する脅威とそれらと戦う測定について議論します。 [RFC4380]はTeredoへの脅威とそれらと戦う測定の大規模な議論を取り入れます。

3.3.  Tunneling IPv6 through IPv4 Networks May Break IPv4 Network
      Security Assumptions

3.3. IPv4ネットワークを通してIPv6にトンネルを堀ると、IPv4ネットワークセキュリティ仮定は破られるかもしれません。

   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.

NATsとファイアウォールはセクション2.3で議論するようにIPv4インターネットで手広く配布されました。 彼らを配布するオペレータがいくつかのセキュリティ/操作上の要件を通常考えています(指導を誤られるかもしれません)(例えば、本国行きの接続試みを妨げる願望)。

   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

トンネリングの追加はそのような展開が実施しようとしている機密保護モデルを変えることができます。 プロトコル41を使用することでトンネルを堀るIPv6過剰IPv4が通常明らかに許容されているか、またはそれとなく禁じられます。 UDPでカプセル化されたIPv4の上でIPv6にトンネルを堀ると、UDPを通常通らせなければならないとき、より難しい問題は構成されます。

Davies, et al.               Informational                     [Page 24]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [24ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

NATsとファイアウォールを通して。 その結果、実装によって、この能力は、制限されるか、またはstateful方法で達成されるだけであるかもしれませんが、UDPを使用すると、NATsとファイアウォールの穴をパンチする能力は含意されます。 実際には、メカニズムは、同様にNATsとファイアウォールの両方を横断するように明らかに設計されています。

   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.

1つの可能な視点はトンネリングの使用が通常、ネットワーク管理における、専門的技術のレベルがそれほど高くないホームとソーホー(小さいオフィス/ホームオフィス)環境で特に疑わしいということです。 これらの環境には、他のもののようにしっかり管理されているとしてホストがいないかもしれません(例えばネットワーク・サービスは不必要に可能にされるかもしれません)、可能なセキュリティ不法侵入か他の脆弱性に通じて。

   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.

NATsとファイアウォールにトンネルを堀られたトラフィックの通ることを許す穴は故意に、そして何気なくパンチできます。 管理者かユーザが穴を作成するという明白な決定をする場合では、問題ではこれは、より少ないです、従業員が管理者についての言及なしでそのような穴を作成できるなら、(例えば)いくつかの企業が明らかにIPv6トンネリングを妨げたがっていますが。 他方では、穴が透過的にパンチされると、ユーザのプロポーションは結果を理解しそうにないでしょう: これは遅かれ早かれ、非常にたぶん重大な脅威をもたらすでしょう。

   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.

例えば、NAT縦断は同様のファイアウォール生産aがデフォルトでない場合デフォルトで実行されて、それへの安全保障政策がNATをIPv4に供給したということであるべきではありません。 必要なら、妨げるのが、より簡単であるのに従って、問題ではIPv4のIPv6(プロトコル41)トンネリングは、より少ないです。 しかしながら、ホストがIPv4に保護されるなら、また、IPv6側は保護されるべきです。

   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.

Appendix Aに示されて、そのままで、展開にトンネルを堀る際にIPv4アドレスに対応するIPv6アドレスを決定するのは比較的簡単です。 特に自動トンネリング変遷メカニズムを使用するとき、したがって、すなわち、だれも推測できないと仮定しながら「不鮮明によるセキュリティ」を当てにするか、またはホストのIPv6アドレスを決定するのが、重大なNOTです。

   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.

ネットワークアーキテクチャは図1に示されるようにdecapsulatedされる前にIPv4ファイアウォールを通して発送されたIPv4パケットと、そして、IPv6ファイアウォールを通してカプセル化されたトンネルを堀られたIPv6トラフィック到着を別々のIPv4とIPv6ファイアウォールに提供しなければなりません。

Davies, et al.               Informational                     [Page 25]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [25ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

                +--------+      +--------+      +--------+
      Site      | Native | IPv6 |v6 in v4| IPv4 | Native |      Public
   Network <--->|  IPv6  |<---->| Tunnel |<---->|  IPv4  |<---> Internet
                |Firewall|      |Endpoint|      |Firewall|
                +--------+      +--------+      +--------+

+--------+ +--------+ +--------+ サイト| ネイティブ| IPv6|v4のv6| IPv4| ネイティブ| 公衆通信回線<。--->| IPv6| <、-、-、--、>| トンネル| <、-、-、--、>| IPv4| <、-、-->インターネット|ファイアウォール| |終点| |ファイアウォール| +--------+ +--------+ +--------+

                 Figure 1: Tunneled Traffic and Firewalls

図1: トンネルを堀られたトラフィックとファイアウォール

4.  Issues Due to IPv6 Deployment

4. IPv6展開による問題

4.1.  Avoiding the Trap of Insecure IPv6 Service Piloting

4.1. 不安定なIPv6サービス操縦の罠を避けます。

   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.

IPv6が多くのネットワークのための新しいサービスであるので、ネットワークマネージャは生産の完全な品質IPv6サービスから生じるかもしれない利益と同様に経験を積んで、問題を理解するためにネットワークの一部でパイロット展開をするようにしばしば選ばれるでしょう。

   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.

操縦ができるだけ安全であることで、パイロットのセキュリティが何まで合っていないかなら現在のIPv4生産サービスで達成可能なリスクがあります、比較ということである方法で行われるIPv6サービスが逆にIPv6の基調判断に影響を与えることができないなら、展開を操縦してください。 これは延着するか、またはIPv6生産がサービスであると配布するのを避けるのさえ決定をもたらすかもしれません。 例えば、ホストとルータはIPv6ファイアウォールによって保護されないかもしれません、対応するIPv4サービスがファイアウォールによって完全に保護されても。 また、トンネリング変遷メカニズム(セクション3.3を見る)の使用と仮想私設網との相互作用は、サイトセキュリティが維持されるのを保証するために慎重な注意を必要とします。 これはIPv6能力がデフォルトでオペレーティングシステムの新しい設備か新版でつけられているところで特に重要です: ネットワークマネージャはこれが作成するセキュリティ暴露を百も承知していないかもしれません。

   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.

いくつかの場合、IPv6ファイアウォールの有用性の知覚された不足と侵入検知システムなどの他のセキュリティ能力は、ネットワークマネージャがどんな種類のIPv6サービス展開にも抵抗するように導いたかもしれません。 大した問題は資料不足であったように見えます、そして、これらの問題は一部IPv6できる防犯設備の比較的遅い開発と展開のためであるかもしれませんが、より重要に、記録された運用経験の不足にどのマネージャで描かれることができるか。 実際に、これを書いている時点で、十分なアクセス制御を提供するのに使用できた多くの代替のIPv6パケットフィルタと既に現存するファイアウォールがあります。

   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

デイヴィース、他 [26ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   o  'Personal firewalls' with support for IPv6 and intended for use on
      hosts are not yet widely available.

o そして、IPv6のサポートがある'パーソナルファイアウォール'、ホストにおける使用がまだ広く利用可能でないので、意図します。

   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 エンタープライズファイアウォールは、初期のときに、開発があって、規則をフィルターにかける必要なIPv6を実装するのに必要である最大限の範囲の能力を提供しないかもしれません。 これは本当に必要ではありません、そして、設備には、IPv6のために速いパケットフィルタリングをサポートする必要なハードウェア能力がないかもしれませんが、ネットワークマネージャは、しばしばまた、IPv4において、今日サポートしている、使用されたのと同じデバイスがIPv6できるようになると予想します。 通常、別々の箱の中にファイアウォールがあって、それらの必要は全くないのが望ましい状態で同じことが設備のモデルであったならこのセクションから目にふれて、それがあるということであるために望んでいるようにセクション3.3でファイアウォールの適切な展開のための提案を与えます。

   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 より少ない要素はIPv6プロトコルにおけるいくつかのデザイン決定でファイアウォールが実装されて、すべての場合で働いて、セクション2.1.9で議論するように完全に未来の耐であることが(例えば、新しい拡張ヘッダーはいつ使用されていますか)より難しくなるということであるかもしれません。 中間的ノードがIPv6ヘッダーチェーンを処理するのは、IPv4パケットよりかなり難しいです。

   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 適切なIntrusion Detection Systems(IDS)はIPv6のために組み立てるのが、より難しいです。 IDSsは現在、利用可能になり始めていますが、終わりから終わりへの暗号化が、より一般的になるので、IPv4に使用される中でこれらのシステムの長期開発には、パターンベースのメカニズムは最も適切でないかもしれません。 将来のシステムは交通の流れパターン認識により頼っているかもしれません。

   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.

o 供給不足にはIPv6をサポートする高可用性能力の実装があります。 代替手段はいくつかの環境に利用可能であるかもしれませんが、特に、Virtual Router Redundancyプロトコル(VRRP)[VRRP]のIPv6バージョンの開発は主なIPv6プロトコルの開発を遅れさせました。

   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].

これらのすべての領域では、開発が進行中です、そして、パイロットか生産サービスとしてのIPv6の展開への長期のバーであるとそれらを考えるべきではありません。 必要なツールは現在安全なIPv6展開をするように利用可能です、そして、コンポーネントの厳選とネットワークアーキテクチャのデザインで、うまくいっているパイロットか生産IPv6サービスは配布することができます。 ヨーロッパ連合6netプロジェクトのドキュメンテーションアーカイブ[SIXNET]と日本のIPv6 Promotion Councilによって発表されたDeploymentガイド[JpIPv6DC]でIPv6ネットワークの安全な展開と適切な経営のための推薦を見つけることができます。

Davies, et al.               Informational                     [Page 27]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [27ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

4.2.  DNS Server Problems

4.2. DNSサーバ問題

   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.

いくつかのDNSサーバ実装には、[RFC4074]で議論するように厳しくIPv6アドレスのためのDNS質問に影響する欠点があります。 DNSサーバをキャッシュするのが、ドメインが起伏が多いと信じているのを引き起こすことによってIPv4とIPv6の両方のふりをして、サーバが予防の期間、ドメインを求めるすべての要求へのアクセスを妨げるDoS攻撃にこれらの欠点を使用できます。

4.3.  Addressing Schemes and Securing Routers

4.3. 体系を扱って、ルータを保証します。

   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.

IPv6サブネットのあいまいな言葉で力任せのスキャンがIPv6の途方もないほど大きいアドレス空間と64ビットのインタフェース識別子のために本質的には不可能である間(Appendix Aを見てください)、管理者が「蹄-可能」インタフェース識別子を使用するのに大きいスペースを利用しないと、これを取り除くでしょう。

   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.

完全なIPv6アドレスの「非-想起性」のために、手動でそれらを構成するとき管理者がインタフェース識別子としてわずかな整数を使用する誘惑がポイントへのポイントリンクの上に起こるかもしれないか、またはDHCPv6サーバから完全なアドレスに食糧を供給する時あります。そのような配分で、攻撃者が、次にそれらが移植できる活動ノードがスキャンするのがわかるのが簡単になります。

   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.

それらの構成(例えば、アクセスコントロールリスト)にIPv6アドレスを入れるとき、適切により大きいアドレス空間を利用するために、管理者は非常に慎重であるはずです、数字のIPv6アドレスがそれらの長さと「非-想起性」のためにIPv4より人為ミスに傾向があるので。

   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.

また、ルータが通常隣人キャッシュにおける隣人アドレスの重要なキャッシュを含むときルータの管理インタフェースがよく確保されるのを(例えば、Secureシェル(SSH)だけを使用することで遠隔アクセスを許容して、地元工芸品インタフェースには非デフォルトのパスワードがあるのを確実にします)保証するのも不可欠です。

4.4.  Consequences of Multiple Addresses in IPv6

4.4. 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.

IPv6の1つの肯定的結果はグローバルなアクセスを必要としないノードがリンクローカルアドレス(非常に地方のアクセスが十分であるなら)の使用のすぐ近く、または、サイトの向こう側にUnique Local Address(ULA)を使用することによって局所的に交信できるということです。 どちらかの場合では、簡単なフィルタ(リンクローカルのためのデフォルトであるべきである)から活動の割り当てられたドメインの外でのアクセスを制御できるのを保証するのは簡単です。 しかしながら、セクション2.1.12に記録されるように一般用にリンクローカルのアドレスを使用するセキュリティ危険は覚えておかれるべきです。

Davies, et al.               Informational                     [Page 28]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [28ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

他方では、ノードかインタフェースが複数のグローバルな範囲アドレスを持つことができる可能性は、(イングレスと出口の両方)をフィルターにかけるアクセスコントロールをより複雑にして、より高いメインテナンスレベルを必要とします。 ベンダーとネットワーク管理者は、複数のアドレスが例外よりむしろIPv6の標準であることを意識している必要があります: セキュリティと管理のためにツールを築き上げて、選択するとき、非常に望ましい特徴は複数のアドレス、そして/または、アドレス接頭語を満たすためにアクセスコントロールリストと一般に、構成を'tokenizeすることができる'能力です。

   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.

アドレスが同じネットワーク接頭語(例えば、プライバシーメカニズム[RFC4941]は定期的に同じ接頭語から取られた新しいアドレスを作成するでしょう、そして、これらの2以上は同時に、アクティブであるかもしれない)か、異なった接頭語からあるかもしれません(ネットワークが例えばノードが管理目的のために同じリンクの上のいくつかのサブネットに属すと「マルチ-家へ帰」るか、またはanycastサービスを実装しているとき)。 これらのすべての場合では、独身のホストが異なった接頭語、そして/または、異なったインタフェース識別子があるいくつかの異なったアドレスを使用できたのは、可能です。 セキュリティ管理者が、同じホストがこれらのすべてのアドレスの後ろにいるのを特定できるのは、望ましいです。

   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.

ネットワーク管理者の中にはプライバシーメカニズムがアクセスコントロールリストを維持して、トラフィックの発生源を知ることにおける現下の難局のために望ましくなくなるのにそれらのネットワークに使用されるときアドレスの無常を見つける人もいるかもしれません。 一般に、完全なstateful DHCPv6メカニズム[RFC3315]がアドレスをIPv6に割り当てるのに使用される場合にだけ、プライバシーアドレスの使用を無効にするのは可能です、そして、プライバシーアドレスを求めるDHCPv6要求は光栄に思っていません。

4.5.  Deploying ICMPv6

4.5. 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.

IPv4では、ファイアウォールのそばのICMPパケットの何らかのフィルタリングが警備を維持するのに不可欠であると一般的に受け入れます。 拡張使用のために、それは機能(IPv4がIPv6のためにかなり開発されている必要がある通常、適用される規則をちょっと立ち寄らせる簡単なセット)の多数と共にICMPv6[RFC2461]で作られています。 IPv6には、いくつかの非常に厳しい環境で使用されるすべてのICMPメッセージの毛布低下は絶対に可能ではありません。

   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.

IPv6ファイアウォールでは、方針は、いくつかのメッセージのファイアウォールに通ることを許すのが必要ですが、ファイアウォールとファイアウォール(特にリンク地元筋がファイアウォールが付けているリンクの上にいるそれら)からのあるメッセージをまた可能にしなければなりません。 Neighborディスカバリー[RFC2462]、Multicast Listenerディスカバリー[RFC2710]、[RFC3810)、およびStateless Address Configuration[RFC4443]が予想されるように働いているのを保証することをこれらのメッセージを許可しなければなりません。

Davies, et al.               Informational                     [Page 29]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [29ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   Recommendations for filtering ICMPv6 messages can be found in
   [RFC4890].

[RFC4890]でICMPv6メッセージをフィルターにかけるための推薦を見つけることができます。

4.5.1.  Problems Resulting from ICMPv6 Transparency

4.5.1. ICMPv6透明から生じることにおける問題

   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.

セクション4.5で説明されるように、あるICMPv6誤りパケットは、両方の方向のファイアウォールを通り抜ける必要があります。 これは、内部と外部の間で少しもフィルタリングなしでいくつかのICMPv6誤りパケットを交換できることを意味します。

   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.

この特徴を使用して、悪意あるユーザーはファイアウォールの内部と外部の間で交信できます、その結果、アドミニストレータの点検(プロキシ、ファイアウォールなど)を迂回させます。 例えば、ICMPv6エラーメッセージのペイロードを通してひそかな会話を行うか、またはICMPv6エラーメッセージで不適当なカプセル化されたIPパケットにトンネルを堀るのが可能であるかもしれません。 ネットワーク、または、保護されたネットワークからペイロードが正統のトラフィックに関連しているのでパケットが運ばれたのを保証するのにステートフルパケットインスペクションメカニズムを使用することでICMPv6誤りをフィルターにかけることによって、この問題を軽減できます。

4.6.  IPsec Transport Mode

4.6. IPsec交通機関

   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.

IPsecはネットワーク層(層3)でセキュリティをエンド・ツー・エンド通信に提供します。 利用可能なセキュリティ機能はアクセスコントロール、コネクションレスな保全、データ発生源認証、反射攻撃に対する保護、秘密性、および限られた交通の流れ秘密性を含んでいます([RFC4301]セクション2.1を見てください)。 IPv6はノードを従わせながら、すべてでIPsecの実装を強制します、ある意味で可能な一般に、IPv4に利用可能でないエンド・ツー・エンド通信を保証するためにIPsecの使用法を作って。

   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.

一般に、エンド・ツー・エンド通信、IPsec交通機関をIPv6に保証するのは、選択の解決でしょう。 しかしながら、これらのIPsecセキュリティ機能の使用は、ファイアウォールが深いパケット点検とフィルタリングを実行できない暗号化されたパケットの増強された普及のためにネットワーク管理者のための目新しい問題をもたらして、周辺ファイアウォールの有効性を減少させることができます。

   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.

そのような問題に関する1つの例がmiddleboxのセキュリティソリューションの不足です、有効なコンテントのフィルタリング(予想されたTCPプロトコルの振舞い、および侵入検出に基づく防止をDoSに供給する能力)を含んでいて セクション2.3.2でこの問題への今後の解決について議論します。 別の例はソフトウェアベースのIPsec実装に特に有害である場合があるIPsecベースのDoS(例えば、送付の奇形の超能力/AHパケット)です。

Davies, et al.               Informational                     [Page 30]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [30ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

4.7.  Reduced Functionality Devices

4.7. 減少している機能性デバイス

   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.

IPv6の展開で、私たちは希少資源と低コンピュータ能力がある非常に多くの新しいIPv6によって可能にされたデバイスの付属を予想できます。 リソース制限が一般にコスト削減のための市場要件のためにあります。 [RFC4294]はいくつかの義務的なセキュリティ能力をあらゆるconformantノードに指定しますが、これらはノードが我が身をかばうことができるように必要である機能を含んでいません。 それに従って、そのようないくつかのデバイスは我が身をかばわなければならなかった最小の関数群を実行さえできないかもしれません(例えば、'個人的な'ファイアウォール、自動ファームウェアのアップデート、DoSに耐えることができるくらいのCPUパワーは攻撃されます)。 これは、異なったセキュリティ体系がそのような減少している機能性デバイスに必要であるかもしれないことを意味します。

4.8.  Operational Factors when Enabling IPv6 in the Network

4.8. 操作上のFactors、NetworkのEnabling IPv6です。

   There are a number of reasons that make it essential to take
   particular care when enabling IPv6 in the network equipment:

ネットワーク装置でIPv6を有効にするとき特定の注意を払うのを不可欠にする多くの理由があります:

   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によって可能にされたルータソフトウェアは現在のIPv4だけ実装ほど熟さないかもしれません、そして、IPv6ルーティング環境と(IPv6)ネットワーク供給停止の分裂をもたらすことができるIPv6ルーティングを構成するより少ない経験があります。

   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.

IPv6処理は(近い)のライン・スピード(または同じ設備のIPv4への匹敵する性能レベルで)で起こらないかもしれません。 高いレベルのIPv6トラフィックは特にそれがハイエンドルータの典型のハードウェアサポートのないソフトウェアベースであることの容易にオーバーロードIPv6処理をそうすることができました(認知さえしてください、例えば、ネットワークニューストランスポートプロトコル、NNTP)。 両方のサービスの有用性に影響して、これは潜在的にIPv4処理に有害な波及効果を持っているかもしれません。 それに従って、人々がそれらの設備のIPv6能力に十分自信があるように感じないと、彼らはそれらの「生産」ネットワークでそれを可能にするのに気が重いでしょう。

   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!

時々、基本的な特徴はベンダーのソフトウェアの早めのリリースによってなくなっているかもしれません。 例はしかし可能なIPv6telnet/SSHがそれをオフにするか、またはアクセスをそれに制限する能力なしでアクセスする(例えば、ルータの構成アプリケーションに)ソフトウェアの設備です!

   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

時々、デフォルトIPv6構成は不安定です。 例えば、1つのベンダーの実装では、構成でIPv4telnetをほんの数人のホストに制限したなら、あなたは、IPv6telnetが自動的に可能にされて、構成が命令するのを意識している必要があります。

Davies, et al.               Informational                     [Page 31]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [31ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

以前に使用されて、IPv6telnetを妨げないでください、そして、IPv6telnetがデフォルトで世界に開くことであり、それがあなたであることはまた、IPv6telnetアクセサリーの下側にロックする別々のコマンドを使用しなければなりません。

   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.

多くのオペレータネットワークがIPv4とIPv6の両方のために内部のルーティング・プロトコルを実行しなければなりません。 1つのルーティング・プロトコルでそれらの両方を実行するか、または2つの別々のルーティング・プロトコルを持っているのが可能です。 アプローチには、見返り[RFC4029]があります。 複数のルーティング・プロトコルが使用されているなら、これがリンクがばたつくか、または再計算が別の方法で必要であるときに処理より容易に(ルータのCPUを積みすぎるかもしれない)の量の二重を引き起こすことに注意するべきです、わずかに遅い集合時間を引き起こして。

4.9.  Security Issues Due to Neighbor Discovery Proxies

4.9. 隣人発見プロキシによる安全保障問題

   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].

複数の物理的なリンクの上にただ一つのサブネットにかかるために、新しい実験的な能力はプロキシNeighborディスカバリーメッセージへのIPv6でtrialedされています。 この能力があるノードはNDProxyと呼ばれるでしょう([RFC4389]を見てください)。 NDProxiesはunsecured NeighborディスカバリーかARPを使用することでホストによって面していたものと同じ安全保障問題に影響されやすいです。 これらのプロキシは、そのような処理の結果、非機密保護しているメッセージを処理して、隣人キャッシュをアップデートするかもしれません、その結果、悪意があるノードがトラフィックを紛らすか、またはハイジャックするのを許容します。 これはSEND[RFC3971]を使用する利点を弱体化させるかもしれません。

   If a form of NDProxy is standardized, SEND will need to be extended
   to support this capability.

NDProxyのフォームが標準化されると、SENDは、この能力をサポートするために広げられる必要があるでしょう。

5.  Security Considerations

5. セキュリティ問題

   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.

このメモは、IPv6の異なった局面のセキュリティ問題の概要を与えるのを試みます、特にIPv4とIPv6ベースのコミュニケーションが共存する必要があるネットワークへの変遷に関連するとき。

6.  Acknowledgements

6. 承認

   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

このドキュメントはセキュリティ関連のドキュメントをIPV6に寄付した多くの人々とV6OPSワーキンググループの仕事を接近させます。 アラン・ジュランド、アランBaudot、リュックBeloeil、シャロン・チスホルム、ティムChown、ラース・エッゲルト、Andrasキシュ-スザボ、Vishwas Manral、ジェイノスMohacsi、マーク・スミス、アルバロ・ビベス、およびマーガレット・ワッセルマンは、このドキュメントを改良するためにフィードバックを提供しました。 Satoshiコンドー、Shinsuke鈴木、およびアルバロ・ビベスは日本のIPv6 Promotion CouncilのDeployment作業部会と提携して追加入力を提供しました、そして、Euro6IX ISTはプロジェクトに共同資金を供給しました、ジョルディPaletからの入力、ブライアンCarpenter、およびピーターBieringerと共に。 そしてマイケルWittsendとマイケル・コールが調べ/マッピングに関連する問題について議論した。

Davies, et al.               Informational                     [Page 32]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [32ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

プライバシー。 クレイグ・メスと6月-ichiro itojun HaginoはワイヤでIPv4によって写像されたIPv6アドレスを使用するという問題を特定するオリジナルの仕事をしました。 Vishwas ManralはさらにIPv6における小さい断片の影響の調査をセキュリティにしました。 フランシス・デュポンはIPv6 Privacy Addressesに関連する問題を提起しました。 最終的に、ペッカSavolaはこの仕事に包括された局面のIPv6セキュリティの多くのドキュメントを書きました。 「IPv6"(2003年10月)のためのFirewalling問題は元々、ここに記録されるベースIPv6仕様の問題の多くを特定したところ」の彼のドキュメント。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC1122]      Braden, R., "Requirements for Internet Hosts -
                  Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日

   [RFC2375]      Hinden, R. and S. Deering, "IPv6 Multicast Address
                  Assignments", RFC 2375, July 1998.

[RFC2375] HindenとR.とS.デアリング、「IPv6マルチキャストアドレス課題」、RFC2375、1998年7月。

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

[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

   [RFC2461]      Narten, T., Nordmark, E., and W. Simpson, "Neighbor
                  Discovery for IP Version 6 (IPv6)", RFC 2461,
                  December 1998.

[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。

   [RFC2462]      Thomson, S. and T. Narten, "IPv6 Stateless Address
                  Autoconfiguration", RFC 2462, December 1998.

[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。

   [RFC2710]      Deering, S., Fenner, W., and B. Haberman, "Multicast
                  Listener Discovery (MLD) for IPv6", RFC 2710,
                  October 1999.

[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」

   [RFC3056]      Carpenter, B. and K. Moore, "Connection of IPv6
                  Domains via IPv4 Clouds", RFC 3056, February 2001.

[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。

   [RFC3775]      Johnson, D., Perkins, C., and J. Arkko, "Mobility
                  Support in IPv6", RFC 3775, June 2004.

[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」

   [RFC3810]      Vida, R. and L. Costa, "Multicast Listener Discovery
                  Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」

   [RFC3964]      Savola, P. and C. Patel, "Security Considerations for
                  6to4", RFC 3964, December 2004.

[RFC3964] SavolaとP.とC.パテル、「6to4"、RFC3964、2004年12月のためのセキュリティ問題。」

Davies, et al.               Informational                     [Page 33]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [33ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   [RFC4007]      Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
                  and B. Zill, "IPv6 Scoped Address Architecture",
                  RFC 4007, March 2005.

[RFC4007] デアリングとS.とハーバーマンとB.とJinmeiとT.とNordmark、E.とB.Zill、「IPv6はアドレス体系を見た」RFC4007、2005年3月。

   [RFC4291]      Hinden, R. and S. Deering, "IP Version 6 Addressing
                  Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。

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

[RFC4380]Huitema、C.、「船食虫:」 「ネットワークアドレス変換(NATs)でUDPの上でIPv6にトンネルを堀る」RFC4380、2006年2月。

   [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.

[RFC4443] コンタ、A.、デアリング、S.、およびM.グプタ、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。

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

[RFC4941] Narten、T.、Draves、R.、およびS.クリシュナン、「IPv6"、RFC4941、2007年9月の状態がないアドレス自動構成のためのプライバシー拡大。」

7.2.  Informative References

7.2. 有益な参照

   [FNAT]         Bellovin, S., "Technique for Counting NATted Hosts",
                  Proc. Second Internet Measurement Workshop ,
                  November 2002,
                  <http://www.research.att.com/~smb/papers/fnat.pdf>.

[FNAT] Bellovin、S.、「NATtedホストを数えるためのテクニック」、Proc。 第2インターネット測定ワークショップ、2002年11月、<http://www.research.att.com/~smb/書類/fnat.pdf>。

   [ICMP-ATT]     Gont, F., "ICMP attacks against TCP", Work
                  in Progress, May 2007.

[ICMP-ATT] Gont、F.、「TCPに対するICMP攻撃」、Progress、2007年5月のWork。

   [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.

[IEEE.802-1X]米国電気電子技術者学会、「ポートベースのネットワークアクセスコントロール」、地方とメトロポリタンエリアネットワーク802.1X-2004(2004年12月)のIEEE規格。

   [JpIPv6DC]     Deployment WG, "IPv6 Deployment Guideline (2005
                  Edition)", IPv6 Promotion Council (Japan) Deployment
                  Working Group, 2005, <http://www.v6pc.jp/>.

[JpIPv6DC]展開WG、「IPv6展開ガイドライン(2005年の版)、」、IPv6販売促進協議会(日本)展開作業部会、2005、<http://www.v6pc.jp/>。

   [RFC1858]      Ziemba, G., Reed, D., and P. Traina, "Security
                  Considerations for IP Fragment Filtering", RFC 1858,
                  October 1995.

1995年10月の[RFC1858]ZiembaとG.とリード、D.とP.Traina、「IP断片フィルタリングのためのセキュリティ問題」RFC1858。

   [RFC2765]      Nordmark, E., "Stateless IP/ICMP Translation Algorithm
                  (SIIT)", RFC 2765, February 2000.

[RFC2765] Nordmark、E.、「状態がないIP/ICMP変換アルゴリズム(SIIT)」、RFC2765、2000年2月。

Davies, et al.               Informational                     [Page 34]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [34ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   [RFC2766]      Tsirtsis, G. and P. Srisuresh, "Network Address
                  Translation - Protocol Translation (NAT-PT)",
                  RFC 2766, February 2000.

[RFC2766] TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べてください」、RFC2766、2000年2月。

   [RFC3128]      Miller, I., "Protection Against a Variant of the Tiny
                  Fragment Attack (RFC 1858)", RFC 3128, June 2001.

[RFC3128]ミラー、I.、「小さい断片攻撃の異形に対する保護、(RFC1858)、」、RFC3128、6月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.

[RFC3315]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。

   [RFC3493]      Gilligan, R., Thomson, S., Bound, J., McCann, J., and
                  W. Stevens, "Basic Socket Interface Extensions for
                  IPv6", RFC 3493, February 2003.

[RFC3493] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャン、J.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」

   [RFC3756]      Nikander, P., Kempf, J., and E. Nordmark, "IPv6
                  Neighbor Discovery (ND) Trust Models and Threats",
                  RFC 3756, May 2004.

[RFC3756] Nikander、P.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。

   [RFC3971]      Arkko, J., Kempf, J., Zill, B., and P. Nikander,
                  "SEcure Neighbor Discovery (SEND)", RFC 3971,
                  March 2005.

[RFC3971] ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。

   [RFC4025]      Richardson, M., "A Method for Storing IPsec Keying
                  Material in DNS", RFC 4025, March 2005.

[RFC4025]リチャードソン、M.、「DNSで材料を合わせるIPsecを保存するためのメソッド」、RFC4025、2005年3月。

   [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.

[RFC4029]のリンド、M.、Ksinant、V.、公園、S.、Baudot、A.、およびP.Savola、「ISPネットワークにIPv6を取り入れるためのシナリオと分析」(RFC4029)は2005を行進させます。

   [RFC4038]      Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
                  Castro, "Application Aspects of IPv6 Transition",
                  RFC 4038, March 2005.

[RFC4038]はよじ登ります、M K.、商館、Y-G.、Hagino、J.、Savola、P.とE.カストロ、「IPv6変遷のアプリケーション局面」RFC4038、2005年3月。

   [RFC4074]      Morishita, Y. and T. Jinmei, "Common Misbehavior
                  Against DNS Queries for IPv6 Addresses", RFC 4074,
                  May 2005.

[RFC4074] 森下、Y.、およびT.Jinmei(「IPv6アドレスのためのDNS質問に対する一般的な不正行為」、RFC4074)は2005がそうするかもしれません。

   [RFC4191]      Draves, R. and D. Thaler, "Default Router Preferences
                  and More-Specific Routes", RFC 4191, November 2005.

[RFC4191]Draves、研究開発ターレル、「デフォルトルータ好みの、そして、より特定のルート」、RFC4191、2005年11月。

   [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.

[RFC4225] Nikander、P.、Arkko、J.、香気、T.、モンテネグロ、G.、およびE.Nordmark、「モバイルIPバージョン6経路最適化セキュリティはバックグラウンドを設計します」、RFC4225、2005年12月。

   [RFC4294]      Loughney, J., "IPv6 Node Requirements", RFC 4294,
                  April 2006.

[RFC4294] Loughney、J.、「IPv6ノード要件」、RFC4294、2006年4月。

Davies, et al.               Informational                     [Page 35]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [35ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   [RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
                  Internet Protocol", RFC 4301, December 2005.

[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。

   [RFC4311]      Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
                  Sharing", RFC 4311, November 2005.

[RFC4311]Hinden、研究開発ターレル、「IPv6ホストからルータへの負荷分割法」、RFC4311、2005年11月。

   [RFC4389]      Thaler, D., Talwar, M., and C. Patel, "Neighbor
                  Discovery Proxies (ND Proxy)", RFC 4389, April 2006.

[RFC4389] ターレル、D.、Talwar、M.、およびC.パテル、「隣人発見プロキシ(第プロキシ)」、RFC4389、2006年4月。

   [RFC4472]      Durand, A., Ihren, J., and P. Savola, "Operational
                  Considerations and Issues with IPv6 DNS", RFC 4472,
                  April 2006.

[RFC4472] ジュランド、A.、Ihren、J.、P.Savola、および「IPv6 DNSの操作上の問題と問題」、RFC4472、4月2006日

   [RFC4864]      Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
                  and E. Klein, "Local Network Protection for IPv6",
                  RFC 4864, May 2007.

[RFC4864] バン・デ・ベルデとG.とハインとT.とDromsとR.とCarpenter、B.とE.クライン、「IPv6"、RFC4864、2007年5月のための企業内情報通信網保護。」

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

[RFC4890] デイヴィース、E.、およびJ.Mohacsi(「ファイアウォールでICMPv6メッセージをフィルターにかけるための推薦」、RFC4890)は2007がそうするかもしれません。

   [RFC4966]      Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
                  Historic Status", RFC 4966, July 2007.

2007年7月の[RFC4966]Aoun、C.とE.デイヴィース、「太平洋標準時のNATを歴史的な状態に動かす理由」RFC4966。

   [SCAN-IMP]     Chown, T., "IPv6 Implications for Network Scanning",
                  Work in Progress, March 2007.

T.、「ネットワークスキャンのためのIPv6含意」という[スキャン悪童]Chownは進歩、2007年3月に働いています。

   [SIXNET]       6Net, "Large Scale International IPv6 Pilot Network",
                  EU Information Society Technologies Project , 2005,
                  <http://www.6net.org/>.

[SIXNET]6Net、「大規模国際IPv6パイロットネットワーク」、技術が映し出すEU情報社会、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>.

[TCGARCH] Trusted Computing Group、「TCG仕様アーキテクチャ概要」、2004年4月、<https://www.trustedcomputinggroup.org/は_1_の/TCG0_Architecture_Overview.pdf>を分類します。

   [VRRP]         Hinden, R. and J. Cruz, "Virtual Router Redundancy
                  Protocol for IPv6", Work in Progress, March 2007.

[VRRP] HindenとR.とJ.クルス、「IPv6"のための仮想のルータ冗長プロトコル、進行中の仕事、2007年3月。」

Davies, et al.               Informational                     [Page 36]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [36ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

Appendix A.  IPv6 Probing/Mapping Considerations

問題を調べるか、または写像する付録A.IPv6

   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.

1つの学派が、IPv6付番トポロジー(ネットワークかノードレベルにおける)にできるだけまさにIPv4に合って欲しかったのですが、他のものは、より多くの柔軟性をアドレスプランに与えるとIPv6をみなします、IPv6アドレシングのデザインを抑制したくなくて。 IPv6展開には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.

IPv6ネットワークセキュリティの比較的未熟な状態に考えて、攻撃者が、ノードのIPv4アドレスを知っていて、それがIPv4とIPv6と共に二元的に積み重ねられると信じているなら、彼は対応するIPv6アドレスを調べようとしたいかもしれません、セキュリティディフェンスが低いかもしれないという仮定に基づいて。 これは特にIPv6でIPv4、しかし、グローバルにアドレス可能なNATの後ろにあるノードのためのそうであるかもしれません。 当然、同様の、そして、適切な安全保障政策が適所にあるなら、これは関心ではありません。

   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].

他方では、アドレスをスキャンするか、または調べるブルートフォースはほとんどのIPv6サブネットに関するインタフェース識別子の大きい検索スペースのためにいつも識別子が利用可能なスペースから無作為に選ばれている議論として[SCAN-IMP]で計算上実行不可能です(幅64ビットであって、よるよりいくらか識別子がどう選ばれているかに関して少ない)。

   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.

例えば、自動トンネリングメカニズムはIPv6にアドレスを作るのに確定論的手法を通常使用します、ポートを非常に調べ/スキャンしているので、IPv6ノードは簡易型です。 IPv4アドレスは少なくとも6to4、Teredo、およびISATAPアドレスに埋め込まれています。 さらに、接頭語の後ろでアドレスを学ぶのは可能です(特に6to4の場合における)。 例えば、マイクロソフト6to4実装はアドレス2002: V4ADDRを使用します:、:V4ADDRは2002への、より古いリナックスと無料OSの一つ実装デフォルト: V4ADDRをゆったり過ごします:、:1. また、実装を特定して、したがって、どんな特定の弱点も狙うことにおける一方通行としてこれを使用できました。

   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.

1つの提案は6to4ルータのアドレスのアドレスかサブネット識別子をランダマイズすることです。 これは本当に助けません、6to4ルータ(ホストかルータであることにかかわらず)がICMPv6 Hop Limit Exceededメッセージを返すとき、IPアドレスを明らかにして。 6to4ルータの後ろのホストは身を潜めるプライバシーアドレス[RFC4941]などのメソッドを使用できます、ほかの場所から始められたセッションで届くことは意味されなければ。 ほかの場所で開始されたコミュニケーションを受け取りたいなら、彼らはまだグローバルに理解できる静的なアドレスを必要としているでしょう。

Davies, et al.               Informational                     [Page 37]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [37ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

   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.

結論すると、、IPv4アドレスを考えて、自動トンネリングメカニズムが使用されているとき、相対的な容易さで対応するIPv6アドレスを推測できたように思えます。 これには、IPv6安全保障政策がIPv4のためのそれほど適切でないなら、重要な意味があります。

Appendix B.  IPv6 Privacy Considerations

付録B.IPv6プライバシー問題

   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.

MACアドレスからのIPv6アドレスの世代は、ユーザの振舞いがプライバシーを侵害するかもしれない方法で追跡されるのを潜在的に許容します。 [RFC4941]は侵害の危険を減少させるのに使用できるメカニズムを指定します。 また、MACアドレスを暴露するか、またはサイトに接続されたノードの数を暴露することによってIPv6がユーザのプライバシーに害を及ぼすと主張されました。

   Additional discussion of privacy issues can be found in [RFC4864].

[RFC4864]でプライバシーの問題の追加議論を見つけることができます。

B.1.  Exposing MAC Addresses

B.1。 MACにアドレスを暴露します。

   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.

ネットワークカードのモデルをさらすEUI64に組み込むので、MACアドレスで状態がないアドレス自動構成結果を使用します。 関心はユーザが部外者にシステム詳細を暴露したがっていないかもしれないということです、例えば、泥棒がMACアドレスに埋め込まれたベンダー識別子から金のかかる装置を特定するなら結果として起こる強盗を恐れるか、または設備のタイプに使用中に与えるのが特定されて、その結果、特定のセキュリティ弱点に対する攻撃を容易にします。

   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.

多くの場合、これは完全に無根拠に見えます。 まず最初に、どうにかそのようなアドレスについて学習しなければなりません--これは重要なプロセスです。 アドレスは例えば、ウェブサイトアクセスログで目に見えますが、無作為のウェブサイト所有者がこの種類の情報を集めているという(それがいずれ役に立つだろうか否かに関係なく)可能性はかなりスリムです。 そのようなアドレス(例えば、DSL(デジタルSubscriber線)かCableのモデムの物理的なメディアの感染による)を学ぶためにトラフィックを盗み聞くことができるようにまた、かなりこじつけに思えます。 さらに、リスクを心配するなら、そのような目的に、静的に構成されたインタフェース識別子かプライバシーアドレス[RFC4941]を使用するのは簡単です。 2番目に、強盗はIPアドレスを物理的な位置に写像できなければならないでしょう。 これはインターネットサービスプロバイダ(ISP)の個人的な顧客データベースと大きいサイトへのサイトの管理記録からの情報で通常、可能であるだけでしょう、何らかの物理アドレス情報がインターネット登録に関するWHOISデータベースから利用可能であるかもしれませんが。

Davies, et al.               Informational                     [Page 38]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [38ページ]情報のRFC4942IPv6セキュリティ概要2007年9月

B.2.  Exposing Multiple Devices

B.2。 複数のデバイスを暴露します。

   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].

放送された別の関心は多くのコンピュータかネットワークに接続された対向機器の存在を隠したがっているユーザにかかわります。 NATはこのすべての設備をただ一つのアドレスの後ろに「隠すことができます」が、それは完全のどちらか[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.

何人かの管理者がこれが望ましいのがわかるかもしれない1つの実際的な理由が、あるISPのビジネスモデルを阻むことができます。 これらのモデルは全体で接続性よりむしろ接続コンピュータの数に基づく支払いを必要とします。

   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.

上で説明される同様の実行可能性問題は適用されます。 非常に、プライバシーアドレス[RFC4941]の十分頻繁な再利用でマシンの現在の数をあいまいにすることができるでしょう--すなわち、何十もの生成アドレスが短期の間、使用中であるように思えるなら、それらがちょうど1人のホストか複数のホストによって生成されるか否かに関係なく、見積もっているのは難しいです。

B.3.  Exposing the Site by a Stable Prefix

B.3。 安定した接頭語はサイトを暴露します。

   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.

ISPが家か消費者ユーザを含む顧客にIPv6の接続性を提供するとき、それは固定グローバルなルーティング接頭語(通常a/48)を彼らへ代表として派遣します。 これは典型的なIPv4状況と対照的になった家庭でのユーザがしばらくだけ安定するかもしれないダイナミックに割り当てられたアドレスを通常受け取るところの何時間ものものです。

   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.

この固定配分のために、グローバルなルーティング接頭語をネットワークサイトに関連させるのは、より簡単です。 消費者ユーザと共に、この相関関係はプライバシーの問題につながります、個人か家族には、サイトがしばしばこのような場合には同等であるので。 その結果何人かのユーザがそれが静的であるなら彼らの/48配分に基づいて追跡できることに関して[RFC4941]心配するかもしれません。 他方では、彼らがそれでそれらのネットワークで、より容易に主催されたサービスを提供できて、多くのユーザが、静的割り付けを持っているのが望ましいのがわかるかもしれません。

   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.

ユーザがその人のインタフェースIDかサブネットIDを変えても、この状況は影響を受けません、悪意あるユーザーがまだこの結合を発見できるので。 より大きいサイトでは、[RFC4864]で説明されるように「追跡不可能な」IPv6アドレスを使用することによって、状況を緩和できて、将来のISPにおけるそれがプライバシーの問題を最小にするために彼らの消費者顧客に追跡不可能なアドレスを提供するように準備されるのは、可能です。

   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.

このプライバシーの問題は、IPv4とIPv6の両方に共通であり、IPアドレスの使用はノードインタフェースのための識別子とノードのためのロケータの両方として固有です。

Davies, et al.               Informational                     [Page 39]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [39ページ]情報のRFC4942IPv6セキュリティ概観2007年9月

Authors' Addresses

作者のアドレス

   Elwyn B. Davies
   Consultant
   Soham, Cambs
   UK

CambsイギリスのElwyn B.デイヴィースコンサルタントSoham

   Phone: +44 7889 488 335
   EMail: elwynd@dial.pipex.com

以下に電話をしてください。 +44 7889 488 335はメールされます: elwynd@dial.pipex.com

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC  H4P 2N2
   Canada

Sureshクリシュナンエリクソン8400Decarie Blvd. 王立のQC H4P 2N2カナダ山の町

   Phone: +1 514-345-7900
   EMail: suresh.krishnan@ericsson.com

以下に電話をしてください。 +1 514-345-7900 メールしてください: suresh.krishnan@ericsson.com

   Pekka Savola
   CSC/Funet

ペッカSavola CSC/Funet

   EMail: psavola@funet.fi

メール: psavola@funet.fi

Davies, et al.               Informational                     [Page 40]

RFC 4942                 IPv6 Security Overview           September 2007

デイヴィース、他 [40ページ]情報のRFC4942IPv6セキュリティ概観2007年9月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

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.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Davies, et al.               Informational                     [Page 41]

デイヴィース、他 情報[41ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<=演算子 より小さい

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る