IETF Internet-Drafts

General IPv6 IETF Internet-Draft links

  • The Swiss Education and Research Network have a very comprehensive list of all RFCs and IETF Internet-Drafts that are are IPv6 related.
  • The IETF also have the "Internet-Drafts Database Interface" page that you can use to search and lookup expired IETF Internet-Drafts.
  • 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.

Specific IETF Internet-Drafts

  • draft-itojun-ipv6-transition-abuse-01
    Possible abuse against IPv6 transition technologies
    [Jun-ichiro itojun Hagino] (10 July 2000)
    The document talks about possible abuse of IPv6 transition technologies, which may lead to denial-of-service (DoS) attacks and other problems. IPv6 transition technologies, namely IPv6 over IPv4 tunnelling specifications and some others, have room for abuse by malicious parties. Detailed descriptions and possible workarounds are supplied.
  • draft-aura-mipv6-bu-attacks-01
    MIPv6 BU Attacks and Defenses
    [Tuomas Aura, Jari Arkko] (4 March 2002)
  • draft-chown-v6ops-port-scanning-implications-02
    IPv6 Implications for TCP/UDP Port Scanning
    [Tim Chown] (27 October 2005)
    The 128 bits of IPv6 address space is considerably bigger than the 32 bits of address space in IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space. As a result, traditional methods of remote TCP or UDP port scanning to discover open or running services on a host will potentially become far less computationally feasible, due to the larger search space in the subnet. This document discusses that property of IPv6 subnets, and describes related issues for site administrators of IPv6 networks to consider, which may be of importance when planning site address allocation and management strategies.
  • draft-cmetz-v6ops-v4mapped-api-harmful-01
    IPv4-Mapped Address API Considered Harmful
    [Christopher Metz, Jun-ichiro Hagino] (23 October 2003)
  • draft-bagnulo-cga-ext-02
    Cryptographically Generated Addresses (CGA) Extension Field Format
    [Marcelo Bagnulo, Jari Arkko] (23 March 2006)
    This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972.
  • draft-bagnulo-savi-send-00
    SeND-based Source-Address Validation Implementation
    [Marcelo Bagnulo] (26 October 2008)
    This memo describes SeND SAVI, a mechanism to provide source address validation using the SeND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used.
  • draft-blake-ipv6-flow-label-nonce-02
    Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks
    [Steven Blake] (26 October 2009)
    TCP and other transport-layer protocols are vulnerable to spoofing attacks from off-path hosts. These attacks can be prevented through the use of cryptographic authentication. However, it is difficult to use cryptographic authentication in all circumstances. A variety of obfuscation techniques — such as initial sequence number randomization and source port randomization — increase the effort required of an attacker to successfully guess the packet header fields which uniquely identify a transport connection. This memo proposes the use of the IPv6 Flow Label field as a random, per- connection nonce value, to add entropy to the set of packet header fields used to identify a transport connection. This mechanism is easily implementable, allows for incremental deployment, and is fully compliant with the rules for Flow Label use defined in RFC 3697.
  • draft-chown-v6ops-rogue-ra-03
    Rogue IPv6 Router Advertisement Problem Statement
    [Tim Chown, Stig Venaas] (9 March 2009)
    When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements 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 Router Advertisement (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 draft 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.
  • draft-dupont-mip6-privacyext-04
    A Simple Privacy Extension for Mobile IPv6
    [Francis Dupont] (20 July 2006)
    This draft presents a simple privacy extension for Mobile IPv6 that prevents eavesdroppers from identifying the packets sent or received from a particular mobile node. This extension also allows a mobile node to hide its identity from correspondent nodes when the mobile node initiates the communication.
  • draft-eddy-ipv6-ip4-comparison-00
    Comparison of IPv6 and IPv4 Features
    [Wesley Eddy, Joseph Ishac] (10 May 2006)
    This document collects and comments on several aspects IPv6 that differ from IPv4, and what practical impacts these differences might have to an organization. This data can be used in decision-making processes where the business case for deploying IPv6 is under consideration.
  • draft-eddy-ipv6-maturity-00
    Assessment of IPv6 Maturity
    [Wesley Eddy, William Ivancic] (8 May 2006)
    This document collects and comments on several indicators of IPv6’s maturity level as a technology. This data can be used in decision- making processes where many myths regarding IPv6 completeness and deployability persist.
  • draft-eddy-ipv6-overhead-00
    Comparison of IPv4 and IPv6 Header Overhead
    [Wesley Eddy] (8 May 2006)
    This document provides an analysis and comparison of IPv4 and IPv6 header sizes under various circumstances. The goal of this document is to provide hard evidence for use in frequent discussions regarding transition, where header overhead comes up as an issue used to portray IPv6 depolyment as untenable. The results show that for links that are not fully utilized, the IPv6 overhead would only add a few percent to their load over what IPv4 implies, while for congested links, we note that header compression techniques for IPv6 are at least as effective as those for IPv4. This demonstrates that the header overhead argument against IPv6 is misinformed.
  • draft-gont-6man-flowlabel-security-03
    Security Assessment of the IPv6 Flow Label
    [Fernando Gont] (12 March 2012)
    This document discusses the security implications of the IPv6 “Flow Label” header field, and analyzes possible schemes for selecting the Flow Label value of IPv6 packets.
  • draft-gont-6man-nd-extension-headers-03
    Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery
    [Fernando Gont] (13 June 2012)
    This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and provides advice such that the aforementioned security implications are mitigated.
  • draft-gont-6man-oversized-header-chain-02
    Security and Interoperability Implications of Oversized IPv6 Header Chains
    [Fernando Gont, Vishwas Manral] (13 June 2012)
    The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain.
  • draft-gont-6man-predictable-fragment-id-03
    Security Implications of Predictable Fragment Identification Values
    [Fernando Gont] (9 January 2013)
    IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an “Identification” field which, together with the IPv6 Source Address and the IPv6 Destination Address of the packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together at the receiving host. The only requirement for setting the “Identification” value is that it must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations simply use a global counter for setting the Fragment Identification field, thus leading to predictable values. This document analyzes the security implications of predictable Identification values, and updates RFC 2460 specifying additional requirements for setting the Fragment Identification, such that the aforementioned security implications are mitigated.
  • draft-gont-opsec-ipv6-host-scanning-02
    Network Reconnaissance in IPv6 Networks
    [Fernando Gont, Tim Chown] (22 October 2012)
    IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore IPv6 address scanning attacks have long been considered unfeasible. This document analyzes how traditional address scanning techniques apply to IPv6 networks, and also explores a number of techniques that can be employed for IPv6 network reconnaissance.
  • draft-gont-opsec-ipv6-implications-on-ipv4-nets-02
    Security Implications of IPv6 on IPv4 Networks
    [Fernando Gont] (21 August 2012)
    This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on “IPv4-only” networks, and describes possible mitigations for the aforementioned issues.
  • draft-gont-opsec-ipv6-nd-shield-00
    Neighbor Discovery Shield (ND-Shield): Protecting against Neighbor Discovery Attacks
    [Fernando Gont] (5 June 2012)
    This document specifies a mechanism that can be implemented in layer-2 devices to mitigate attack vectors based on Neighbor Discovery messages. It is meant to complement other mechanisms implemented in layer-2 devices such as Router Advertisement Guard (RA-Guard) and DHCPv6-Shield, with the goal of achieving a comprehensive IPv6 First Hop Security solution. This document is motivated by the desire to achieve feature parity with IPv4 with respect to First Hop Security mechanisms.
  • draft-hain-ipv6-fwrh-03
    IPv6 Firewall Routing Header
    [Tony Hain] (10 July 2010)
    This document specifies a routing header for use by firewalls to enforce routing symmetry. The draft is being discussed on the ipv6@ietf.org list. Legal This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  • draft-hoagland-v6ops-teredosecconcerns-01
    Teredo Security Concerns Beyond What Is In RFC 4380
    [Suresh Krishnan, James Hoagland] (12 July 2007)
    Additional security concerns with Teredo are documented, beyond what is in RFC 4380. This is based on an independent analysis of Teredo’s security implications. The primary intent of this document is to provide information and recommendations to the IETF that can be used in any updated Teredo specification. The second intended audience is anyone that can help improve security in Teredo as deployed, so they will be aware of these concerns.
  • draft-iab-ipv6-nat-03
    IAB Thoughts on IPv6 Network Address Translation
    [Dave Thaler, Lixia Zhang, Gregory Lebovitz] (8 March 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.
  • draft-ietf-6man-oversized-header-chain-09
    Implications of Oversized IPv6 Header Chains
    [Fernando Gont, Vishwas Manral, Ron Bonica] (26 November 2013)
    The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain.
  • draft-ietf-behave-v6v4-framework-10
    Framework for IPv4/IPv6 Translation
    [Fred Baker, Xing Li, Congxiao Bao, Kevin Yin] (17 August 2010)
    This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.
  • draft-ietf-behave-v6v4-xlate-stateful-12
    Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
    [Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum] (12 July 2010)
    This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. The public IPv4 address can be shared among several IPv6-only clients. When the stateful NAT64 is used in conjunction with DNS64 no changes are usually required in the IPv6 client or the IPv4 server.
  • draft-ietf-csi-hash-threat-12
    SEND Hash Threat Analysis
    [Ana Kukec, Suresh Krishnan, Sheng Jiang] (7 March 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 [SHA1] 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.
  • draft-ietf-ipv6-2461bis-11
    Neighbor Discovery for IP version 6 (IPv6)
    [Thomas Narten] (9 March 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.
  • draft-ietf-ipv6-deprecate-rh0-01
    Deprecation of Type 0 Routing Headers in IPv6
    [Joe Abley] (28 June 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.
  • draft-ietf-ipv6-privacy-addrs-v2-05
    Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    [Thomas Narten] (9 October 2006)
    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 interfaces that contain embedded IEEE Identifiers, 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.
  • draft-ietf-ipv6-rfc2462bis-08
    IPv6 Stateless Address Autoconfiguration
    [Susan Thomson] (12 May 2005)
    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.
  • draft-ietf-mext-firewall-admin-05
    Guidelines for firewall administrators regarding MIPv6 traffic
    [Suresh Krishnan, Ying Qiu, Niklas Steinleitner, Gabor Bajko] (17 October 2011)
    This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability.
  • draft-ietf-mext-firewall-vendor-05
    Guidelines for firewall vendors regarding MIPv6 traffic
    [Suresh Krishnan, Yaron Sheffer, Niklas Steinleitner, Gabor Bajko] (17 October 2011)
    This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6 and DSMIPv6.
  • draft-ietf-mip6-precfgkbm-04
    Securing Mobile IPv6 Route Optimization Using a Static Shared Key
    [Charles Perkins] (2 December 2005)
    A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates.
  • draft-ietf-opsec-current-practices-07
    Operational Security Current Practices
    [Merike Kaeo] (30 August 2006)
    This document is a survey of the current practices used in today’s large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments.
  • draft-ietf-opsec-ip-security-07
    Security Assessment of the Internet Protocol version 4
    [Fernando Gont] (8 April 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).
  • draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07
    Security Implications of IPv6 on IPv4 Networks
    [Fernando Gont, Will] (6 December 2013)
    This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on “IPv4-only” networks, and describes possible mitigations for the aforementioned issues.
  • draft-ietf-softwire-security-requirements-09
    Softwire Security Analysis and Requirements
    [Shu Yamamoto, Carl Williams, Florent Parent, Hidetoshi Yokota] (11 June 2009)
    This document describes the security guidelines for the softwire “Hubs and Spokes” and “Mesh” solutions. Together with the discussion of the softwire deployment scenarios, the vulnerability to the security attacks is analyzed to provide the security protection mechanism such as authentication, integrity and confidentiality to the softwire control and data packets.
  • draft-ietf-tcpm-icmp-attacks-12
    ICMP attacks against TCP
    [Fernando Gont] (30 March 2010)
    This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, describes a number of widely implemented modifications to TCP’s handling of ICMP error messages that help to mitigate these issues.
  • draft-ietf-tcpm-tcp-antispoof-06
    Defending TCP Against Spoofing Attacks
    [Joseph Touch] (26 February 2007)
    Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.
  • draft-ietf-tsvwg-port-randomization-09
    Transport Protocol Port Randomization Recommendations
    [Michael Larsen, Fernando Gont] (15 August 2010)
    During the last few years, awareness has been raised about a number of “blind” attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or data corruption. These attacks rely on the attacker’s ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the described port number obfuscation algorithms provide improved security/ obfuscation with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed, and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP (provided the RTP application explicitly signals the RTP and RTCP port numbers).
  • draft-ietf-v6ops-addcon-10
    IPv6 Unicast Address Assignment Considerations
    [Gunter Van de Velde, Chip Popoviciu, Tim Chown, Olaf Bonness, Christian Hahn] (22 September 2008)
    One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network.
  • draft-ietf-v6ops-cpe-simple-security-16
    Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service
    [James Woodyatt] (21 October 2010)
    This document identifies a set of recommendations for the makers of devices describing how to provide for “simple security” capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.
  • draft-ietf-v6ops-icmpv6-filtering-bcp-01
    Best Current Practice for Filtering ICMPv6 Messages in Firewalls
    [Elwyn Davies, Janos Mohacsi] (9 March 2006)
    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. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks.
  • draft-ietf-v6ops-icmpv6-filtering-recs-03
    Recommendations for Filtering ICMPv6 Messages in Firewalls
    [Elwyn Davies, Janos Mohacsi] (14 February 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. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks.
  • draft-ietf-v6ops-ipsec-tunnels-05
    Using IPsec to Secure IPv6-in-IPv4 Tunnels
    [Pekka Savola] (17 January 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.
  • draft-ietf-v6ops-nap-06
    Local Network Protection for IPv6
    [Gunter Van de Velde] (11 January 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.
  • draft-ietf-v6ops-onlinkassumption-04
    IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
    [Sebastien Roy] (17 January 2006)
    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 describes how these problems outweigh the benefits of this part of the conceptual sending algorithm.
  • draft-ietf-v6ops-ra-guard-08
    IPv6 Router Advertisement Guard
    [Eric Levy-Abegnoli, Gunter Van de Velde, Chip Popoviciu, Janos Mohacsi] (2 September 2010)
    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.
  • draft-ietf-v6ops-ra-guard-implementation-07
    Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
    [Fernando Gont] (14 November 2012)
    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.
  • draft-ietf-v6ops-rfc3330-for-ipv6-04
    Special-Use IPv6 Addresses
    [Marc Blanchet] (15 January 2008)
    This document describes the global and other specialized IPv6 address blocks. It does not address IPv6 address space assigned to operators and users through the Regional Internet Registries. These descriptions are useful for route and IP filtering, for documentation and other purposes.
  • draft-ietf-v6ops-routing-guidelines-01
    IPv6 Routing Policies Guidelines
    [Marc Blanchet] (27 February 2007)
    Guidelines on how to manage and filter IPv6 routes are needed for operators of networks, either providers or enterprises. It describes IPv6 routes from the protocol point of view. It does not discuss operational or policy issues such as the maximum length of prefixes to filter. This document is a followup on RFC2772 work but for the production IPv6 Internet. RFC2772 is obsoleted.
  • draft-ietf-v6ops-scanning-implications-04
    IPv6 Implications for Network Scanning
    [Tim Chown] (19 November 2007)
    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 against 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.
  • draft-ietf-v6ops-security-overview-06
    IPv6 Transition/Co-existence Security Considerations
    [Elwyn Davies] (27 October 2006)
    The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist 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.
  • draft-ietf-v6ops-teredo-security-concerns-02
    Teredo Security Concerns
    [James Hoagland, Suresh Krishnan] (25 February 2008)
    Additional security concerns with Teredo are documented, beyond what is in RFC 4380. This is based on an independent analysis of Teredo’s security implications. The primary intent of this document is to raise the awareness regarding the security issues in Teredo as deployed today.
  • draft-ietf-v6ops-tunnel-security-concerns-04
    Security Concerns With IP Tunneling
    [Suresh Krishnan, Dave Thaler, James Hoagland] (25 October 2010)
    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 today.
  • draft-ietf-vrrp-ipv6-spec-08
    Virtual Router Redundancy Protocol for IPv6
    [Robert Hinden, John Cruz] (5 March 2007)
    This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv6. It is version three (3) of the protocol. It is based on the original version of VRRP (version 2) for IPv4 that is defined in RFC2338. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discovery [ND] mechanisms.
  • draft-irtf-mobopts-location-privacy-solutions-16
    Mobile IPv6 Location Privacy Solutions
    [QIU Ying, Fan Zhao, Rajeev Koodli] (8 July 2009)
    Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
  • draft-jabley-ipv6-rh0-is-evil-00
    Deprecation of Type 0 Routing Headers in IPv6
    [Joe Abley] (7 May 2007)
    The functionality provided by IPv6’s Type 0 Routing Header can be exploited in order to perform remote network discovery, to bypass firewalls and to achieve packet amplification 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 the light of these security concerns.
  • draft-jiang-csi-dhcpv6-cga-ps-03
    DHCPv6 and CGA Interaction: Problem Statement
    [Sheng Jiang] (18 September 2009)
    This document describes potential issues in the interaction between DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may have mutual benefits for each other, including using CGAs in DHCPv6 operations to enhance its security features and using DHCPv6 to provide the CGA generation function.
  • draft-jiang-dhc-secure-dhcpv6-03
    Secure DHCPv6 Using CGAs
    [Sheng Jiang] (4 February 2010)
    The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs.
  • draft-krishnan-ipv6-exthdr-08
    An uniform format for IPv6 extension headers
    [Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland] (8 March 2010)
    In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining a new family of IPv6 extension headers.
  • draft-krishnan-mip6-firewall-admin-04
    Guidelines for firewall administrators regarding MIPv6 traffic
    [Suresh Krishnan, Niklas Steinleitner, QIU Ying, Gabor Bajko] (30 April 2008)
    This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability.
  • draft-krishnan-mip6-firewall-vendor-04
    Guidelines for firewall vendors regarding MIPv6 traffic
    [Suresh Krishnan, Yaron Sheffer, Niklas Steinleitner, Gabor Bajko] (30 April 2008)
    This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6.
  • draft-krishnan-v6ops-teredo-update-10
    Teredo Security Updates
    [Dave Thaler, Suresh Krishnan, James Hoagland] (3 June 2010)
    The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible.
  • draft-laganier-ipv6-khi-07
    An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
    [Pekka Nikander] (14 February 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 end- point 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 as 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. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2027, continued use requiring IETF consensus.
  • draft-macaulay-6man-packet-stain-01
    IPv6 packet staining
    [Tyson Macaulay] (17 August 2012)
    This document specifies the application of security staining on an IPv6 datagrams and the minimum requirements for IPv6 nodes staining flows, IPv6 nodes forwarding stained packets within a given domain of control, and nodes interpreting stains on flows. The usage of the packet staining destination option enables proactive delivery of security intelligence to IPv6 nodes such as firewalls and intrusion prevention systems, and end-points such servers, workstations, mobile and smart devices and an infinite array of as- yet-to-be-invented sensors and controllers. The usage of packet staining is not intended for use across the open internet, where fragmentation issues associated with increased header size may induce service degradation; packet staining is intended as a security adjunct within a given doamin of control such as an carrier or enterprise network.
  • draft-qiu-mext-mn-ha-secure-01
    Authentication Between Mobile Node and Home Agent
    [Ying Qiu, Jianying Zhou] (10 March 2009)
    Mobile IPv6 relies on IPsec for securing the signaling between the MN and HA. However, the tight coupling of the mobility protocol with IPsec is detrimental to broader implementation and deployment. This document proposes a scheme based on Identity-Based Cryptography mechanism to authenticate the mobile node and signaling of home biding update to home agent. Hence, the use of IPsec could be avoided.
  • draft-savola-ipv6-rtheader-00
    IPv6 Type 0 Routing Header Processing
    [Pekka Savola, George Neville-Neil] (8 May 2007)
    IPv6 type 0 routing header has been demonstrated to be a very powerful mechanism as currently specified in RFC 2460. This memo refers to description of problems associated with the use of type 0 routing header and specifies that implementations should disable type 0 routing header processing by default.
  • draft-stjohns-sipso-11
    Common Architecture Label IPv6 Security Option (CALIPSO)
    [Michael StJohns] (6 March 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.
  • draft-v6ops-vyncke-balanced-ipv6-security-01
    Balanced Security for IPv6 CPE
    [Martin Gysi, Guillaume Leclanche, Eric Vyncke, Ragnar Anfinsen] (15 July 2013)
    This document describes how an IPv6 residential Customer Premise Equipment (CPE) can have a balanced security policy that allows for a mostly end-to-end connectivity while keeping the major threats outside of the home. It is based on an actual IPv6 deployment by Swisscom and proposes to allow all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known.
  • draft-vandevelde-v6ops-harmful-tunnels-01
    Non-Managed IPv6 Tunnels considered Harmful
    [Gunter Van de Velde, Ole Troan, Tim Chown] (31 August 2010)
    IPv6 is ongoing and natively being deployed by a growing community and it is important that the quality perception and traffic flows are as optimal as possible. Ideally it would be as good as the IPv4 perceptive experience. This paper looks into a set of transitional technologies where the actual user has IPv6 connectivity through the means of IPv6-in-IPv4 tunnels. A subset of the available tunnels has the property of being non-managed (i.e. 6to4 [RFC3056] and Teredo [RFC4380]
  • draft-vyncke-advanced-ipv6-security-03
    Advanced Security for IPv6 CPE
    [Eric Vyncke, Andrew Yourtchenko, Mark Townsley] (31 October 2011)
    This document describes how an IPv6 residential Customer Premise Equipment (CPE) can leverage modern security techniques to have strong security, while retaining as much of the end-to-end reachability of IPv6 as possible. It is a re-submission in the framework of the HOMENET working group. The reputation part of this document should leverage the work done in the REPUTE working group of the Application are.
  • draft-vyncke-opsec-v6-01
    Operational Security Considerations for IPv6 Networks
    [KK Chittimaneni, Merike Kaeo, Eric Vyncke] (16 July 2012)
    Network managers know how to operate securely IPv4 network: whether it is the Internet or an enterprise internal network. IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers need also a more practical, operation-minded best common practices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques.
  • draft-wing-v6ops-happy-eyeballs-ipv6-01
    Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts
    [Dan Wing, Andrew Yourtchenko] (25 October 2010)
    This document describes how a dual-stack client can determine the functioning path to a dual-stack server. This provides a seemless user experience during initial deployment of dual-stack networks and during outages of IPv4 or outages of IPv6.
  • draft-dupont-ipv6-cgpref-01
    An IPv6 Prefix for Cryptographically Generated IDs
    [Francis Dupont] (23 June 2005)
    This document proposes the allocation of a dedicated prefix for Cryptographically Generated IDs (CGIDs). This prefix makes the distinction between a CGID and a real IPv6 global address trivial.
  • draft-dupont-ipv6-rfc3041harmful-05
    RFC 3041 Considered Harmful
    [Francis Dupont, Pekka Savola] (25 June 2004)
    The purpose of the privacy extensions for stateless address autoconfiguration [1] is to change the interface identifier (and the global-scope addresses generated from it) over time in order to make it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. Current Distributed Denial of Service (DDoS) [2]
  • draft-gont-tcpm-icmp-attacks-05
    ICMP attacks against TCP
    [Fernando Gont] (27 October 2005)
    This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes several counter-measures to eliminate or minimize the impact of these attacks.
  • draft-ietf-dhc-dual-stack-04
    DHCP: IPv4 and IPv6 Dual-Stack Issues
    [Tim Chown] (27 October 2005)
    A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4]
  • draft-ietf-ipngwg-icmp-v3-07
    Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
    [Alex Conta] (14 July 2005)
    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).
  • draft-ietf-ipv6-router-selection-07
    Default Router Preferences and More-Specific Routes
    [Richard Draves, Dave Thaler] (19 January 2005)
    This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables.
  • draft-ietf-mip6-firewalls-04
    Mobile IPv6 and Firewalls: Problem statement
    [Franck Le] (26 January 2006)
    Network elements such as firewalls are an integral aspect of a majority of IP networks today, given the state of security in the Internet, threats, and vulnerabilities to data networks. Current IP networks are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development. Mobility support for IPv6 has been standardized as specified in RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere in the smooth operation of the protocol and can be a detriment to deployment. 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 GPRS/ UMTS and CDMA 2000 networks. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG.
  • draft-ietf-mobileip-mipv6-scrty-reqts-02
    Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6
    [P Nikander] (6 November 2001)
  • draft-ietf-multi6-multihoming-threats-03
    Threats relating to IPv6 multihoming solutions
    [Erik Nordmark] (7 January 2005)
    This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.
  • draft-ietf-v6ops-v6onbydefault-03
    Issues with Dual Stack IPv6 on by Default
    [Sebastien Roy, Alain Durand, James Paugh] (20 July 2004)
    This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network insecurity. The purpose of this memo is to raise awareness of these problems so that they can be fixed or worked around, not to try to specify whether IPv6 should be enabled by default or not.
  • draft-itojun-v6ops-v4mapped-harmful-02
    IPv4-Mapped Addresses on the Wire Considered Harmful
    [Christopher Metz, Jun-ichiro Hagino] (23 October 2003)
  • draft-le-mip6-firewalls-01
    Mobile IPv6 and Firewalls
    [Franck Le] (20 July 2004)
    Firewalls are an integral aspect of a majority of IP networks today given the state of security issues, threats and vulnerabilities to data networks. IP networks today are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. IPv6 networks are growing at a slow rate. Firewalls for IPv6 networks are still maturing and in development. The IETF has recently standardized Mobile IPv6 which adds mobility support to IPv6. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks today do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will hamper large-scale deployment of the protocol. This document presents in detail some of the issues that people deploying IPv6 networks which include firewalls should consider when expanding the scope to support Mobile IPv6 as well. The issues are not only applicable to firewalls protecting corporate networks, but are also applicable in 3G mobile networks such as GPRS/UMTS and cdma2000 networks where packet filters are implemented in the GGSN in GPRS/UMTS networks and the PDSN in cdma2000 networks. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG.
  • draft-palet-v6ops-ipv6security-02
    IPv6 distributed security requirements
    [Jordi Palet, Alvaro Vives, G Martinez, A Gomez] (21 February 2005)
    The security policies currently applied in Internet with IPv4, doesn�t longer apply for end-to-end security models which IPv6 will enable. Today, each network is often secured by a unique device (i.e. security gateway or firewall), that becomes a bottleneck for the end- to-end security model with IPv6. In addition, users and devices start to be nomadic, moving between different networks that could have different security policies. A distributed and dynamic approach is consequently required, as already described by [1].
  • draft-savola-v6ops-firewalling-02
    Firewalling Considerations for IPv6
    [Pekka Savola] (10 October 2003)
  • draft-savola-v6ops-tunneling-01
    Evaluation of v6ops Tunneling Scenarios and Mechanisms
    [Pekka Savola, Jonne Soininen] (20 April 2004)
    This memo analyses the v6ops scenarios/analysis work (Unmanaged, 3GPP, ISP and Enterprise) for their requirements for tunneling solutions, and analyses the proposed mechanisms on how they might fit in these requirements, and discusses possibilities for choosing solution(s).
  • draft-vives-v6ops-ipv6-security-ps-03
    IPv6 Security Problem Statement
    [Alvaro Vives] (21 February 2005)
    Today, each network is often secured by a unique device (i.e. security gateway or firewall) that becomes a bottleneck for the end-to-end security model with IPv6. The deployment of IPv6 enabled devices and networks bring some issues, which must be addressed by security administrators in order to guarantee at least the same level of security that is obtained nowadays with IPv4 and network-based (including perimetral-based) security schemes, allowing at the same time all the IPv6 advantages.