RFCs

General IPv6 RFC links

These are more generic links to both IPv6 security specific RFCs and IPv6
RFCs in general.

  • The Swiss Education and Research Network have a very comprehensive list of all RFCs and IETF Internet-Drafts that are are IPv6 related.
  • Pekka Savola’s site has a listing of a number of security related RFCs and IETF Internet-Drafts that he’s worked on.
  • Jun-ichiro "itojun" Hagino site has a listing of a number of security related RFCs and IETF Internet-Drafts that he’s worked on.

Security Specific RFCs

The following list of RFCs deal specifically with IPv6 technology and related security risks. Some describe specific threat scenarios while others document
technologies that can be used to mitigate risk(s).

  • RFC0760
    DoD standard Internet Protocol
    [J. Postel] (January 1980)

    Obsoletes: IEN123
    Obsoleted by: RFC0791
    Updated by: RFC0777
  • RFC0777
    Internet Control Message Protocol
    [J. Postel] (April 1981)

    Obsoleted by: RFC0792
    Updates: RFC0760
  • RFC0791
    Internet Protocol
    [J. Postel] (September 1981)

    Obsoletes: RFC0760
    Updated by: RFC1349 RFC2474 RFC6864
  • RFC0792
    Internet Control Message Protocol
    [J. Postel] (September 1981)

    Obsoletes: RFC0777
    Updated by: RFC0950 RFC4884 RFC6633 RFC6918
  • RFC0950
    Internet Standard Subnetting Procedure
    [J.C. Mogul,J. Postel] (August 1985)
    This memo discusses the utility of “subnets” of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed.
    Updates: RFC0792
    Updated by: RFC6918
  • RFC1248
    OSPF Version 2 Management Information Base
    [F. Baker,R. Coltun] (July 1991)
    This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]
    Obsoleted by: RFC1252
    Updated by: RFC1349
  • RFC1252
    OSPF Version 2 Management Information Base
    [F. Baker,R. Coltun] (August 1991)
    This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]
    Obsoletes: RFC1248
    Obsoleted by: RFC1253
  • RFC1253
    OSPF Version 2 Management Information Base
    [F. Baker,R. Coltun] (August 1991)
    This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]
    Obsoletes: RFC1252
    Obsoleted by: RFC1850
  • RFC1349
    Type of Service in the Internet Protocol Suite
    [P. Almquist] (July 1992)
    This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]
    Obsoleted by: RFC2474
    Updates: RFC1248 RFC1247 RFC1195 RFC1123 RFC1122 RFC1060 RFC0791
  • RFC1455
    Physical Link Security Type of Service
    [D. Eastlake 3rd] (May 1993)
    This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community.
    Obsoleted by: RFC2474
  • RFC1788
    ICMP Domain Name Messages
    [W. Simpson] (April 1995)
    This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
    Obsoleted by: RFC6918
  • RFC1825
    Security Architecture for the Internet Protocol
    [R. Atkinson] (August 1995)
    This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]
    Obsoleted by: RFC2401
  • RFC1850
    OSPF Version 2 Management Information Base
    [F. Baker,R. Coltun] (November 1995)
    This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]
    Obsoletes: RFC1253
    Obsoleted by: RFC4750
  • RFC1883
    Internet Protocol, Version 6 (IPv6) Specification
    [S. Deering,R. Hinden] (December 1995)
    This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]
    Obsoleted by: RFC2460
  • RFC1884
    IP Version 6 Addressing Architecture
    [R. Hinden,S. Deering] (December 1995)
    This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]
    Obsoleted by: RFC2373
  • RFC1885
    Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
    [A. Conta,S. Deering] (December 1995)
    This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]
    Obsoleted by: RFC2463
  • RFC1886
    DNS Extensions to support IP version 6
    [S. Thomson,C. Huitema] (December 1995)
    This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK]
    Obsoleted by: RFC3596
    Updated by: RFC2874 RFC3152
  • RFC1933
    Transition Mechanisms for IPv6 Hosts and Routers
    [R. Gilligan,E. Nordmark] (April 1996)
    This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]
    Obsoleted by: RFC2893
  • RFC1970
    Neighbor Discovery for IP Version 6 (IPv6)
    [T. Narten,E. Nordmark,W. Simpson] (August 1996)
    This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]
    Obsoleted by: RFC2461
  • RFC1971
    IPv6 Stateless Address Autoconfiguration
    [S. Thomson,T. Narten] (August 1996)
    This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]
    Obsoleted by: RFC2462
  • RFC2003
    IP Encapsulation within IP
    [C. Perkins] (October 1996)
    This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]
    Updated by: RFC3168 RFC6864
  • RFC2113
    IP Router Alert Option
    [D. Katz] (February 1997)
    This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]
    Updated by: RFC5350 RFC6398
  • RFC2133
    Basic Socket Interface Extensions for IPv6
    [R. Gilligan,S. Thomson,J. Bound,W. Stevens] (April 1997)
    This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
    Obsoleted by: RFC2553
  • RFC2292
    Advanced Sockets API for IPv6
    [W. Stevens,M. Thomas] (February 1998)
    The current document defines some the “advanced” features of the sockets API that are required for applications to take advantage of additional features of IPv6. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
    Obsoleted by: RFC3542
  • RFC2373
    IP Version 6 Addressing Architecture
    [R. Hinden,S. Deering] (July 1998)
    This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]
    Obsoletes: RFC1884
    Obsoleted by: RFC3513
  • RFC2401
    Security Architecture for the Internet Protocol
    [S. Kent,R. Atkinson] (November 1998)
    This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]
    Obsoletes: RFC1825
    Obsoleted by: RFC4301
    Updated by: RFC3168
  • RFC2411
    IP Security Document Roadmap
    [R. Thayer,N. Doraswamy,R. Glenn] (November 1998)
    This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol. This memo provides information for the Internet community.
    Obsoleted by: RFC6071
  • RFC2460
    Internet Protocol, Version 6 (IPv6) Specification
    [S. Deering,R. Hinden] (December 1998)
    This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]
    Obsoletes: RFC1883
    Obsoleted by: RFC8200
    Updated by: RFC5095 RFC5722 RFC5871 RFC6437 RFC6564 RFC6935 RFC6946 RFC7045 RFC7112
  • RFC2461
    Neighbor Discovery for IP Version 6 (IPv6)
    [T. Narten,E. Nordmark,W. Simpson] (December 1998)
    This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]
    Obsoletes: RFC1970
    Obsoleted by: RFC4861
    Updated by: RFC4311
  • RFC2462
    IPv6 Stateless Address Autoconfiguration
    [S. Thomson,T. Narten] (December 1998)
    This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]
    Obsoletes: RFC1971
    Obsoleted by: RFC4862
  • RFC2463
    Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
    [A. Conta,S. Deering] (December 1998)
    This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]
    Obsoletes: RFC1885
    Obsoleted by: RFC4443
  • RFC2474
    Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
    [K. Nichols,S. Blake,F. Baker,D. Black] (December 1998)
    This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]
    Obsoletes: RFC1455 RFC1349
    Updates: RFC0791
    Updated by: RFC3168 RFC3260
  • RFC2481
    A Proposal to add Explicit Congestion Notification (ECN) to IP
    [K. Ramakrishnan,S. Floyd] (January 1999)
    This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community.
    Obsoleted by: RFC3168
  • RFC2529
    Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
    [B. Carpenter,C. Jung] (March 1999)
    This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]
  • RFC2553
    Basic Socket Interface Extensions for IPv6
    [R. Gilligan,S. Thomson,J. Bound,W. Stevens] (March 1999)
    TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. This memo provides information for the Internet community.
    Obsoletes: RFC2133
    Obsoleted by: RFC3493
    Updated by: RFC3152
  • RFC2780
    IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers
    [S. Bradner,V. Paxson] (March 2000)
    This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
    Updated by: RFC4443 RFC5237 RFC5771 RFC6335 RFC7045
  • RFC2874
    DNS Extensions to Support IPv6 Address Aggregation and Renumbering
    [M. Crawford,C. Huitema] (July 2000)
    This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]
    Updates: RFC1886
    Updated by: RFC3152 RFC3226 RFC3363 RFC3364
  • RFC2893
    Transition Mechanisms for IPv6 Hosts and Routers
    [R. Gilligan,E. Nordmark] (August 2000)
    This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]
    Obsoletes: RFC1933
    Obsoleted by: RFC4213
  • RFC3041
    Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    [T. Narten,R. Draves] (January 2001)
    This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]
    Obsoleted by: RFC4941
  • RFC3053
    IPv6 Tunnel Broker
    [A. Durand,P. Fasano,I. Guardini,D. Lento] (January 2001)
    The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando’s IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999. This memo provides information for the Internet community.
  • RFC3056
    Connection of IPv6 Domains via IPv4 Clouds
    [B. Carpenter,K. Moore] (February 2001)
    This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]
  • RFC3152
    Delegation of IP6.ARPA
    [R. Bush] (August 2001)
    This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
    Obsoleted by: RFC3596
    Updates: RFC2874 RFC2772 RFC2766 RFC2553 RFC1886
  • RFC3168
    The Addition of Explicit Congestion Notification (ECN) to IP
    [K. Ramakrishnan,S. Floyd,D. Black] (September 2001)
    This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN’s use of two bits in the IP header. [STANDARDS-TRACK]
    Obsoletes: RFC2481
    Updates: RFC2003 RFC2474 RFC2401 RFC0793
    Updated by: RFC4301 RFC6040
  • RFC3493
    Basic Socket Interface Extensions for IPv6
    [R. Gilligan,S. Thomson,J. Bound,J. McCann,W. Stevens] (February 2003)
    The de facto standard Application Program Interface (API) for TCP/IP applications is the “sockets” interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.
    Obsoletes: RFC2553
  • RFC3513
    Internet Protocol Version 6 (IPv6) Addressing Architecture
    [R. Hinden,S. Deering] (April 2003)
    This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node’s required addresses. [STANDARDS-TRACK]
    Obsoletes: RFC2373
    Obsoleted by: RFC4291
  • RFC3542
    Advanced Sockets Application Program Interface (API) for IPv6
    [W. Stevens,M. Thomas,E. Nordmark,T. Jinmei] (May 2003)
    This document provides sockets Application Program Interface (API) to support “advanced” IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the “r” commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community.
    Obsoletes: RFC2292
  • RFC3596
    DNS Extensions to Support IP Version 6
    [S. Thomson,C. Huitema,V. Ksinant,M. Souissi] (October 2003)
    This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]
    Obsoletes: RFC3152 RFC1886
  • RFC3756
    IPv6 Neighbor Discovery (ND) Trust Models and Threats
    [P. Nikander,J. Kempf,E. Nordmark] (May 2004)
    The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.
  • RFC3964
    Security Considerations for 6to4
    [P. Savola,C. Patel] (December 2004)
    The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 (“IPv6-in-IPv4”) traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community.
  • RFC3971
    SEcure Neighbor Discovery (SEND)
    [J. Arkko,J. Kempf,B. Zill,P. Nikander] (March 2005)
    IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]
    Updated by: RFC6494 RFC6495 RFC6980
  • RFC3972
    Cryptographically Generated Addresses (CGA)
    [T. Aura] (March 2005)
    This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK]
    Updated by: RFC4581 RFC4982
  • RFC4038
    Application Aspects of IPv6 Transition
    [M-K. Shin,Y-G. Hong,J. Hagino,P. Savola,E. M. Castro] (March 2005)
    As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. This memo provides information for the Internet community.
  • RFC4213
    Basic Transition Mechanisms for IPv6 Hosts and Routers
    [E. Nordmark,R. Gilligan] (October 2005)
    This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.
    Obsoletes: RFC2893
  • RFC4218
    Threats Relating to IPv6 Multihoming Solutions
    [E. Nordmark,T. Li] (October 2005)
    This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
  • RFC4291
    IP Version 6 Addressing Architecture
    [R. Hinden,S. Deering] (February 2006)
    This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node’s required addresses.
    Obsoletes: RFC3513
    Updated by: RFC5952 RFC6052 RFC7136 RFC7346 RFC7371 RFC8064
  • RFC4294
    IPv6 Node Requirements
    [J. Loughney] (April 2006)
    This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This memo provides information for the Internet community.
    Obsoleted by: RFC6434
    Updated by: RFC5095
  • RFC4301
    Security Architecture for the Internet Protocol
    [S. Kent,K. Seo] (December 2005)
    This document describes an updated version of the “Security Architecture for IP”, which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]
    Obsoletes: RFC2401
    Updates: RFC3168
    Updated by: RFC6040 RFC7619
  • RFC4311
    IPv6 Host-to-Router Load Sharing
    [R. Hinden,D. Thaler] (November 2005)
    The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]
    Updates: RFC2461
  • RFC4429
    Optimistic Duplicate Address Detection (DAD) for IPv6
    [N. Moore] (April 2006)
    Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]
    Updated by: RFC7527
  • RFC4443
    Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
    [A. Conta,S. Deering,M. Gupta] (March 2006)
    This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]
    Obsoletes: RFC2463
    Updates: RFC2780
    Updated by: RFC4884
  • RFC4487
    Mobile IPv6 and Firewalls: Problem Statement
    [F. Le,S. Faccin,B. Patil,H. Tschofenig] (May 2006)
    This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.
  • RFC4581
    Cryptographically Generated Addresses (CGA) Extension Field Format
    [M. Bagnulo,J. Arkko] (October 2006)
    This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS-TRACK]
    Updates: RFC3972
  • RFC4732
    Internet Denial-of-Service Considerations
    [M. Handley,E. Rescorla,IAB] (December 2006)
    This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.
  • RFC4750
    OSPF Version 2 Management Information Base
    [D. Joyal,P. Galecki,S. Giacalone,R. Coltun,F. Baker] (December 2006)
    This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family.
    Obsoletes: RFC1850
  • RFC4773
    Administration of the IANA Special Purpose IPv6 Address Block
    [G. Huston] (December 2006)
    This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. This memo provides information for the Internet community.
    Obsoleted by: RFC6890
  • RFC4843
    An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
    [P. Nikander,J. Laganier,F. Dupont] (April 2007)
    This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
    Obsoleted by: RFC7343
  • RFC4852
    IPv6 Enterprise Network Analysis – IP Layer 3 Focus
    [J. Bound,Y. Pouffary,S. Klynsma,T. Chown,D. Green] (April 2007)
    This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. This memo provides information for the Internet community.
  • RFC4861
    Neighbor Discovery for IP version 6 (IPv6)
    [T. Narten,E. Nordmark,W. Simpson,H. Soliman] (September 2007)
    This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other’s presence, to determine each other’s link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]
    Obsoletes: RFC2461
    Updated by: RFC5942 RFC6980 RFC7048 RFC7527 RFC7559 RFC8028
  • RFC4862
    IPv6 Stateless Address Autoconfiguration
    [S. Thomson,T. Narten,T. Jinmei] (September 2007)
    This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]
    Obsoletes: RFC2462
    Updated by: RFC7527
  • RFC4863
    Wildcard Pseudowire Type
    [L. Martini,G. Swallow] (May 2007)
    Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need. [STANDARDS-TRACK]
  • RFC4864
    Local Network Protection for IPv6
    [G. Van de Velde,T. Hain,R. Droms,B. Carpenter,E. Klein] (May 2007)
    Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of “amplifying” available address space is not needed in IPv6. In addition to NAT’s many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. This memo provides information for the Internet community.
  • RFC4882
    IP Address Location Privacy and Mobile IPv6: Problem Statement
    [R. Koodli] (May 2007)
    In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. This memo provides information for the Internet community.
  • RFC4884
    Extended ICMP to Support Multi-Part Messages
    [R. Bonica,D. Gan,D. Tappan,C. Pignataro] (April 2007)
    This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
    Updates: RFC0792 RFC4443
  • RFC4890
    Recommendations for Filtering ICMPv6 Messages in Firewalls
    [E. Davies,J. Mohacsi] (May 2007)
    In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.
  • RFC4891
    Using IPsec to Secure IPv6-in-IPv4 Tunnels
    [R. Graveman,M. Parthasarathy,P. Savola,H. Tschofenig] (May 2007)
    This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework. This memo provides information for the Internet community.
  • RFC4941
    Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    [T. Narten,R. Draves,S. Krishnan] (September 2007)
    Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]
    Obsoletes: RFC3041
  • RFC4942
    IPv6 Transition/Co-existence Security Considerations
    [E. Davies,S. Krishnan,P. Savola] (September 2007)
    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:
  • RFC4943
    IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
    [S. Roy,A. Durand,J. Paugh] (September 2007)
    This document describes the historical and background information behind the removal of the “on-link assumption” from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host’s default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm. This memo provides information for the Internet community.
  • RFC5095
    Deprecation of Type 0 Routing Headers in IPv6
    [J. Abley,P. Savola,G. Neville-Neil] (December 2007)
    The functionality provided by IPv6’s Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]
    Updates: RFC2460 RFC4294
  • RFC5156
    Special-Use IPv6 Addresses
    [M. Blanchet] (April 2008)
    This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. This memo provides information for the Internet community.
    Obsoleted by: RFC6890
  • RFC5157
    IPv6 Implications for Network Scanning
    [T. Chown] (March 2008)
    The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. This memo provides information for the Internet community.
    Obsoleted by: RFC7707
  • RFC5350
    IANA Considerations for the IPv4 and IPv6 Router Alert Options
    [J. Manner,A. McDonald] (September 2008)
    This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]
    Updates: RFC2113 RFC3175
  • RFC5514
    IPv6 over Social Networks
    [E. Vyncke] (April 2009)
    There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks. This will immediately add millions of IPv6 hosts to the existing IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. This memo defines an Experimental Protocol for the Internet community.
  • RFC5570
    Common Architecture Label IPv6 Security Option (CALIPSO)
    [M. StJohns,R. Atkinson,G. Thomas] (July 2009)
    This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community.
  • RFC5722
    Handling of Overlapping IPv6 Fragments
    [S. Krishnan] (December 2009)
    The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]
    Updates: RFC2460
    Updated by: RFC6946
  • RFC5739
    IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
    [P. Eronen,J. Laganier,C. Madson] (February 2010)
    When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway “virtual link”. This document defines an Experimental Protocol for the Internet community.
  • RFC5871
    IANA Allocation Guidelines for the IPv6 Routing Header
    [J. Arkko,S. Bradner] (May 2010)
    This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]
    Updates: RFC2460
  • RFC5902
    IAB Thoughts on IPv6 Network Address Translation
    [D. Thaler,L. Zhang,G. Lebovitz] (July 2010)
    There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB’s thoughts on the current open issues and the solution space. This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC5942
    IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
    [H. Singh,W. Beebee,E. Nordmark] (July 2010)
    IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn’t automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of “on-link” from RFC 4861. [STANDARDS-TRACK]
    Updates: RFC4861
  • RFC5952
    A Recommendation for IPv6 Address Text Representation
    [S. Kawamura,M. Kawashima] (August 2010)
    As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]
    Updates: RFC4291
  • RFC6040
    Tunnelling of Explicit Congestion Notification
    [B. Briscoe] (November 2010)
    This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification — PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]
    Updates: RFC3168 RFC4301 RFC4774
  • RFC6052
    IPv6 Addressing of IPv4/IPv6 Translators
    [C. Bao,C. Huitema,M. Bagnulo,M. Boucadair,X. Li] (October 2010)
    This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]
    Updates: RFC4291
  • RFC6059
    Simple Procedures for Detecting Network Attachment in IPv6
    [S. Krishnan,G. Daley] (November 2010)
    Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]
  • RFC6071
    IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
    [S. Frankel,S. Krishnan] (February 2011)
    Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols’ traffic.
    Obsoletes: RFC2411
  • RFC6092
    Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
    [J. Woodyatt] (January 2011)
    This document identifies a set of recommendations for the makers of devices and describes how to provide for “simple security” capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC6104
    Rogue IPv6 Router Advertisement Problem Statement
    [T. Chown,S. Venaas] (February 2011)
    When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC6105
    IPv6 Router Advertisement Guard
    [E. Levy-Abegnoli,G. Van de Velde,C. Popoviciu,J. Mohacsi] (February 2011)
    Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes.
    Updated by: RFC7113
  • RFC6147
    DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
    [M. Bagnulo,A. Sullivan,P. Matthews,I. van Beijnum] (April 2011)
    DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]
  • RFC6169
    Security Concerns with IP Tunneling
    [S. Krishnan,D. Thaler,J. Hoagland] (April 2011)
    A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]
  • RFC6180
    Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
    [J. Arkko,F. Baker] (May 2011)
    The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC6204
    Basic Requirements for IPv6 Customer Edge Routers
    [H. Singh,W. Beebee,C. Donley,B. Stark,O. Troan] (April 2011)
    This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. This document is not an Internet Standards Track specification; it is published for informational purposes.
    Obsoleted by: RFC7084
  • RFC6273
    The Secure Neighbor Discovery (SEND) Hash Threat Analysis
    [A. Kukec,S. Krishnan,S. Jiang] (June 2011)
    This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC6274
    Security Assessment of the Internet Protocol Version 4
    [F. Gont] (July 2011)
    This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK’s Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC6324
    Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations
    [G. Nakibly,F. Templin] (August 2011)
    This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC6434
    IPv6 Node Requirements
    [E. Jankiewicz,J. Loughney,T. Narten] (December 2011)
    This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document is not an Internet Standards Track specification; it is published for informational purposes.
    Obsoletes: RFC4294
  • RFC6494
    Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)
    [R. Gagliano,S. Krishnan,A. Kukec] (February 2012)
    SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. [STANDARDS-TRACK]
    Updates: RFC3971
  • RFC6666
    A Discard Prefix for IPv6
    [N. Hilliard,D. Freedman] (August 2012)
    Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the “IPv6 Special Purpose Address Registry” by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. This document is not an Internet Standards Track specification; it is published for informational purposes.
  • RFC6890
    Special-Purpose IP Address Registries
    [M. Cotton,L. Vegoda,R. Bonica,B. Haberman] (April 2013)
    This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.
    Obsoletes: RFC4773 RFC5156 RFC5735 RFC5736
    Updated by: RFC8190
  • RFC6918
    Formally Deprecating Some ICMPv4 Message Types
    [F. Gont,C. Pignataro] (April 2013)
    A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.
    Obsoletes: RFC1788
    Updates: RFC0792 RFC0950
  • RFC6946
    Processing of IPv6 “Atomic” Fragments
    [F. Gont] (May 2013)
    The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as “atomic fragments”). Such packets are typically sent by hosts that have received an ICMPv6 “Packet Too Big” error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal “fragmented traffic” (i.e., they are “reassembled” with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 “Packet Too Big” error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.
    Updates: RFC2460 RFC5722
  • RFC6964
    Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
    [F. Templin] (May 2013)
    Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
  • RFC7084
    Basic Requirements for IPv6 Customer Edge Routers
    [H. Singh,W. Beebee,C. Donley,B. Stark] (November 2013)
    This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969’s IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333’s Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.
    Obsoletes: RFC6204
  • RFC7113
    Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
    [F. Gont] (February 2014)
    The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.
    Updates: RFC6105
  • RFC7123
    Security Implications of IPv6 on IPv4 Networks
    [F. Gont,W. Liu] (February 2014)
    This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on “IPv4-only” networks and describes possible mitigations for the aforementioned issues.
  • RFC7219
    SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)
    [M. Bagnulo,A. Garcia-Martinez] (May 2014)
    This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.
  • RFC7343
    An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
    [J. Laganier,F. Dupont] (September 2014)
    This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
    Obsoletes: RFC4843
  • RFC7381
    Enterprise IPv6 Deployment Guidelines
    [K. Chittimaneni,T. Chown,L. Howard,V. Kuarsingh,Y. Pouffary,E. Vyncke] (October 2014)
    Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.
  • RFC7527
    Enhanced Duplicate Address Detection
    [R. Asati,H. Singh,W. Beebee,C. Pignataro,E. Dart,W. George] (April 2015)
    IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.
    Updates: RFC4429 RFC4861 RFC4862
  • RFC7610
    DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
    [F. Gont,W. Liu,G. Van de Velde] (August 2015)
    This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks (‘DHCP snooping’); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.
  • RFC7707
    Network Reconnaissance in IPv6 Networks
    [F. Gont,T. Chown] (March 2016)
    IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.
    Obsoletes: RFC5157
  • RFC7721
    Security and Privacy Considerations for IPv6 Address Generation Mechanisms
    [A. Cooper,F. Gont,D. Thaler] (March 2016)
    This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.
  • RFC7739
    Security Implications of Predictable Fragment Identification Values
    [F. Gont] (February 2016)
    IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an “Identification” field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.