Protocol Action: 'Deprecation of Type 0 Routing Headers in IPv6' to Proposed Standard

The IESG <> Mon, 08 October 2007 17:26 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IewN0-0001C4-5h; Mon, 08 Oct 2007 13:26:18 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IewMy-0001Bt-Qj for; Mon, 08 Oct 2007 13:26:16 -0400
Received: from ([2001:503:c779:1a::9c9a:108a]) by with esmtp (Exim 4.43) id 1IewMx-0006g9-OP for; Mon, 08 Oct 2007 13:26:16 -0400
Received: from ( []) by (Postfix) with ESMTP id 9D3A826EE0; Mon, 8 Oct 2007 17:26:10 +0000 (GMT)
Received: from ietf by with local (Exim 4.43) id 1IewMs-00042z-Hp; Mon, 08 Oct 2007 13:26:10 -0400
X-test-idtracker: no
From: The IESG <>
To: IETF-Announce <>
Message-Id: <>
Date: Mon, 08 Oct 2007 13:26:10 -0400
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: Internet Architecture Board <>, RFC Editor <>
Subject: Protocol Action: 'Deprecation of Type 0 Routing Headers in IPv6' to Proposed Standard
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

The IESG has approved the following document:

- 'Deprecation of Type 0 Routing Headers in IPv6 '
   <draft-ietf-ipv6-deprecate-rh0-01.txt> as a Proposed Standard

This document is the product of the IP Version 6 Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:

Technical Summary
  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.
Working Group Summary
  This document is a product of the IPv6 WG. Considerable
  discussion of the impacts of the Type 0 processing
  has happened over the course of the last few months.
  The document, as it currently stands, has the backing
  of the (rough) consensus of the group. However, the
  topic has generated a lot heated discussion, and this
  action is not unanimously supported by everyone in the
  group. Counter arguments against deprecation have
  raised potential (but so far unused) applications,
  difficulty of introducing new similar functionality
  once the feature has been disabled, ability to
  deal with this issue in an operational manner,
  the difference to the IPv4 situation (where source
  routing is still a part of the specifications), etc.

  The authors, chairs, and the AD believe, however, that
  the current contents of the document have the backing
  of the majority of the group, and that the recommendation
  is a valid one. In particular, new RH types can and
  have been defined for more specialized uses safely,
  and it would be hard to depend on RH0 in new applications,
  given that it has legitimate security issues and
  that irrespective of IETF's documents, this feature
  is largely disabled in many IPv6 implementations.
Protocol Quality
  Jari Arkko has reviewed this document for the IESG. Several
  implementations of IPv6 have for a long time not allowed
  Type 0 Routing Header processing by default; recently
  a number of implementations (BSD, for instance) have
  disabled it in accordance with this document's

  Call for input also in NANOG list was made.

Note to RFC Editor
  Please change:

  IPv6 nodes MUST NOT process RH0 in packets whose
  destination address in the IPv6 header is an address assigned to them.
  Such packets...
  An IPv6 node that receives a packet with a 
  destination address assigned to it and containing an RH0 extension
  header MUST NOT execute the algorithm specified in the latter part
  of Section 4.4 of [RFC2460] for RH0. Instead such packets...

  type-2 RH
  type 2 Routing Header

IETF-Announce mailing list