10. Security Considerations

  o  Assigned Internet Protocol Numbers [IANA-PN]







  o  ONC RPC Network Identifiers (netids) [IANA-NI]

  o  Network Layer Protocol Identifiers (NLPIDs) of Interest
     [IANA-NL]

  o  Protocol Registries [IANA-PR]

The IANA has updated these references to point to this document.

10. Security Considerations

IPv6, from the viewpoint of the basic format and transmission of packets, has security properties that are similar to IPv4. These security issues include:

  o  Eavesdropping, where on-path elements can observe the whole
     packet (including both contents and metadata) of each IPv6
     datagram.
  o  Replay, where the attacker records a sequence of packets off of
     the wire and plays them back to the party that originally
     received them.
  o  Packet insertion, where the attacker forges a packet with some
     chosen set of properties and injects it into the network.
  o  Packet deletion, where the attacker removes a packet from the
     wire.
  o  Packet modification, where the attacker removes a packet from
     the wire, modifies it, and reinjects it into the network.
  o  Man-in-the-middle (MITM) attacks, where the attacker subverts
     the communication stream in order to pose as the sender to
     receiver and the receiver to the sender.
  o  Denial-of-service (DoS) attacks, where the attacker sends large
     amounts of legitimate traffic to a destination to overwhelm it.

IPv6 packets can be protected from eavesdropping, replay, packet insertion, packet modification, and MITM attacks by use of the "Security Architecture for the Internet Protocol" [RFC4301]. In addition, upper-layer protocols such as Transport Layer Security (TLS) or Secure Shell (SSH) can be used to protect the application- layer traffic running on top of IPv6.

There is not any mechanism to protect against DoS attacks. Defending against these type of attacks is outside the scope of this specification.

IPv6 addresses are significantly larger than IPv4 addresses making it much harder to scan the address space across the Internet and even on a single network link (e.g., Local Area Network). See [RFC7707] for more information.

IPv6 addresses of nodes are expected to be more visible on the Internet as compared with IPv4 since the use of address translation technology is reduced. This creates some additional privacy issues such as making it easier to distinguish endpoints. See [RFC7721] for more information.

The design of IPv6 extension header architecture, while adding a lot of flexibility, also creates new security challenges. As noted below, issues relating to the Fragment extension header have been resolved, but it's clear that for any new extension header designed in the future, the security implications need to be examined thoroughly, and this needs to include how the new extension header works with existing extension headers. See [RFC7045] for more information.

This version of the IPv6 specification resolves a number of security issues that were found with the previous version [RFC2460] of the IPv6 specification. These include:

  o  Revised the text to handle the case of fragments that are whole
     datagrams (i.e., both the Fragment Offset field and the M flag
     are zero).  If received, they should be processed as a
     reassembled packet.  Any other fragments that match should be
     processed independently.  The Fragment creation process was
     modified to not create whole datagram fragments (Fragment
     Offset field and the M flag are zero).  See [RFC6946] and
     [RFC8021] for more information.

  o  Removed the paragraph in Section 5 that required including a
     Fragment header to outgoing packets if an ICMP Packet Too Big
     message reporting a Next-Hop MTU is less than 1280.  See
     [RFC6946] for more information.

  o  Changed the text to require that IPv6 nodes must not create
     overlapping fragments.  Also, when reassembling an IPv6
     datagram, if one or more of its constituent fragments is
     determined to be an overlapping fragment, the entire datagram
     (and any constituent fragments) must be silently discarded.
     This includes clarification that no ICMP error message should
     be sent if overlapping fragments are received.  See [RFC5722]
     for more information.

  o  Revised the text to require that all headers through the first
     upper-layer header are in the first fragment.  See [RFC7112]
     for more information.

  o  Incorporated the updates from [RFC5095] and [RFC5871] to
     remove the description of the Routing Header type 0 (RH0),
     state that allocation guidelines for Routing headers are
     specified in RFC 5871, and remove RH0 from the list of
     required extension headers.

Security issues relating to other parts of IPv6 including addressing, ICMPv6, Path MTU Discovery, etc., are discussed in the appropriate specifications.

---