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 [Expired]
    [Tuomas Aura <tuomaura@microsoft.com>, Jari Arkko <jari.arkko@piuha.net>] (2002-03-04)

  • 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 [Expired]
    [Steven Blake <sblake@extremenetworks.com>] (2009-10-26)
    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-port-scanning-implications-02
    IPv6 Implications for TCP/UDP Port Scanning [Expired]
    [Tim Chown <tjc@ecs.soton.ac.uk>] (2005-10-27)
    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 [Expired]
    [Christopher Metz <cmetz@vnet.ibm.com>, Jun-ichiro Itoh <itojun@iijlab.net>] (2003-10-23)

  • draft-dupont-ipv6-cgpref-01
    An IPv6 Prefix for Cryptographically Generated IDs [Expired]
    [Francis Dupont <Francis.Dupont@point6.net>] (2005-06-23)
    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 [Expired]
    [Francis Dupont <Francis.Dupont@enst-bretagne.fr>, Pekka Savola <psavola@funet.fi>] (2004-06-25)
    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] attacks employ forged source addresses which can also be in the same prefixes than the real addresses of the compromised nodes used for attacks. Indeed, network ingress filtering defeats DDoS using 'random' forged source addresses.
  • draft-dupont-mip6-privacyext-04
    A Simple Privacy Extension for Mobile IPv6 [Expired]
    [Francis Dupont <Francis.Dupont@point6.net>] (2006-07-20)
    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 [Expired]
    [Wesley Eddy <weddy@grc.nasa.gov>, Joseph Ishac <jishac@grc.nasa.gov>] (2006-05-10)
    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 [Expired]
    [Wesley Eddy <weddy@grc.nasa.gov>, William Ivancic <wivancic@lerc.nasa.gov>] (2006-05-08)
    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 [Expired]
    [Wesley Eddy <weddy@grc.nasa.gov>] (2006-05-08)
    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 [Expired]
    [Fernando Gont <fernando@gont.com.ar>] (2012-03-12)
    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-opsec-ipv6-nd-shield-00
    Neighbor Discovery Shield (ND-Shield): Protecting against Neighbor Discovery Attacks [Expired]
    [Fernando Gont <fgont@si6networks.com>] (2012-06-05)
    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-gont-tcpm-icmp-attacks-05
    ICMP attacks against TCP [Expired]
    [Fernando Gont <fernando@gont.com.ar>] (2005-10-27)
    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-hain-ipv6-fwrh-03
    IPv6 Firewall Routing Header [Expired]
    [Tony Hain <alh-ietf@tndh.net>] (2010-07-10)
    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 [Expired]
    [Suresh Krishnan <suresh.krishnan@ericsson.com>, James Hoagland <Jim_Hoagland@symantec.com>] (2007-07-12)
    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-ietf-dhc-secure-dhcpv6-07
    Secure DHCPv6 Using CGAs [Expired]
    [Sheng Jiang <jiangsheng@huawei.com>, Sean Shen <shenshuo@cnnic.cn>] (2012-09-14)
    The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs.
  • draft-ietf-mext-firewall-admin-05
    Guidelines for firewall administrators regarding MIPv6 traffic [Expired]
    [Suresh Krishnan <suresh.krishnan@ericsson.com>, Ying Qiu <qiuying@i2r.a-star.edu.sg>, Niklas Steinleitner <steinleitner@cs.uni-goettingen.de>, Gabor Bajko <Gabor.Bajko@nokia.com>] (2011-10-17)
    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 [Expired]
    [Suresh Krishnan <suresh.krishnan@ericsson.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Niklas Steinleitner <steinleitner@cs.uni-goettingen.de>, Gabor Bajko <Gabor.Bajko@nokia.com>] (2011-10-17)
    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-mobileip-mipv6-scrty-reqts-02
    Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6 [Expired]
    [Pekka Nikander <Pekka.Nikander@nomadiclab.com>] (2001-11-06)

  • draft-ietf-v6ops-balanced-ipv6-security-01
    Balanced Security for IPv6 Residential CPE [Expired]
    [Martin Gysi <martin.gysi@swisscom.com>, Guillaume Leclanche <guillaume.leclanche@viagenie.ca>, Éric Vyncke <evyncke@cisco.com>, Ragnar Anfinsen <ragnar.anfinsen@altibox.no>] (2013-12-06)
    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 documenting an existing IPv6 deployment by Swisscom and allows all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known. The policy is a proposed set of rules that can be used as a default setting. The set of blocked inbound and outbound ports is expected to be updated as threats come and go.
  • draft-ietf-v6ops-routing-guidelines-01
    IPv6 Routing Policies Guidelines [Expired]
    [Marc Blanchet <Marc.Blanchet@viagenie.ca>] (2007-02-27)
    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-v6onbydefault-03
    Issues with Dual Stack IPv6 on by Default [Expired]
    [Sebastien Roy <Sebastien.Roy@Eng.Sun.COM>, Alain Durand <Alain.Durand@sun.com>, James Paugh <james.paugh@eng.sun.com>] (2004-07-20)
    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-ietf-vrrp-ipv6-spec-08
    Virtual Router Redundancy Protocol for IPv6 [Expired]
    [Bob Hinden <bob.hinden@nokia.com>, John Cruz <johcruz@cisco.com>] (2007-03-05)
    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-itojun-v6ops-v4mapped-harmful-02
    IPv4-Mapped Addresses on the Wire Considered Harmful [Expired]
    [Christopher Metz <cmetz@vnet.ibm.com>, Jun-ichiro Itoh <itojun@iijlab.net>] (2003-10-23)

  • draft-jabley-ipv6-rh0-is-evil-00
    Deprecation of Type 0 Routing Headers in IPv6 [Expired]
    [Joe Abley <jabley@ca.afilias.info>] (2007-05-07)
    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 [Expired]
    [Sheng Jiang <shengjiang@huawei.com>] (2009-09-18)
    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-krishnan-ipv6-exthdr-08
    An uniform format for IPv6 extension headers [Expired]
    [Suresh Krishnan <suresh.krishnan@ericsson.com>, james woodyatt <jhw@apple.com>, Erik Kline <ek@google.com>, James Hoagland <Jim_Hoagland@symantec.com>] (2010-03-08)
    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 [Expired]
    [Suresh Krishnan <suresh.krishnan@ericsson.com>, Niklas Steinleitner <steinleitner@cs.uni-goettingen.de>, Ying Qiu <qiuying@i2r.a-star.edu.sg>, Gabor Bajko <Gabor.Bajko@nokia.com>] (2008-04-30)
    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 [Expired]
    [Suresh Krishnan <suresh.krishnan@ericsson.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Niklas Steinleitner <steinleitner@cs.uni-goettingen.de>, Gabor Bajko <Gabor.Bajko@nokia.com>] (2008-04-30)
    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-le-mip6-firewalls-01
    Mobile IPv6 and Firewalls [Expired]
    [Franck Le <franckle@cmu.edu>] (2004-07-20)
    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-macaulay-6man-packet-stain-01
    IPv6 packet staining [Expired]
    [Tyson Macaulay <tyson_macaulay@mcafee.com>] (2012-08-17)
    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 [Expired]
    [Jianying Zhou <jyzhou@i2r.a-star.edu.sg>, Ying Qiu <qiuying@i2r.a-star.edu.sg>] (2009-03-12)
    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 [Expired]
    [Pekka Savola <psavola@funet.fi>, George Neville-Neil <gnn@wrs.com>] (2007-05-08)
    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-savola-v6ops-firewalling-02
    Firewalling Considerations for IPv6 [Expired]
    [Pekka Savola <psavola@funet.fi>] (2003-10-10)

  • draft-savola-v6ops-tunneling-01
    Evaluation of v6ops Tunneling Scenarios and Mechanisms [Expired]
    [Pekka Savola <psavola@funet.fi>, Jonne Soininen <jonne.soininen@renesasmobile.com>] (2004-04-20)
    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-vandevelde-v6ops-harmful-tunnels-01
    Non-Managed IPv6 Tunnels considered Harmful [Expired]
    [Gunter Van de Velde <gvandeve@cisco.com>, Ole Trøan <ot@cisco.com>, Tim Chown <tjc@ecs.soton.ac.uk>] (2010-08-31)
    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] ). While native IPv6 deployments will keep growing it is uncertain or even expected that non-managed IPv6 tunnels will be providing the same user experience and operational quality as managed tunnels or native IPv6 connectivity. This paper will detail some considerations around non-managed tunnels and will document the harmful element of these for the future growth of networks and the Internet.
  • draft-vives-distsec-framework-00
    Distributed Security Framework [Expired]
    [Alvaro Vives <alvaro.vives@consulintel.es>] (2005-08-26)
    Over the years, it has been noticed that network firewalls are an inadequeate mechanism in most cases for protecting the hosts, especially from internal attacks. This document analyzes two security paradigms, the network-based and the host-based (distributed), and in consequence outlines a problem statement and framework for distributed security.
  • draft-vyncke-advanced-ipv6-security-03
    Advanced Security for IPv6 CPE [Expired]
    [Éric Vyncke <evyncke@cisco.com>, Andrew Yourtchenko <ayourtch@cisco.com>, Mark Townsley <mark@townsley.net>] (2011-10-31)
    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.