Subject: I-D ACTION:draft-ietf-ipv6-deprecate-rh0-00.txt

From: [email-masked]
Date: Wed, 16 May 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: Deprecation of Type 0 Routing Headers in IPv6
	Author(s)	: J. Abley, et al.
	Filename	: draft-ietf-ipv6-deprecate-rh0-00.txt
	Pages		: 7
	Date		: 2007-5-16

   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.

   This document updates RFC 2460.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipv6-deprecate-rh0-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipv6-deprecate-rh0-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Wed, 16 May 2007 14:01:35 -0700

Not sure why this hasn't gotten to the list yet, but here it is again.

Bob

Begin forwarded message:

> From: "ext [email-masked]" <i-d-announce- 
> [email-masked]>
> Date: May 16, 2007 12:50:02 PM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-ipv6-deprecate-rh0-00.txt
> Reply-To: [email-masked]
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 16 May 2007 17:03:45 -0400

As part of the deprecation effort, does it also make sense to
update RFC 3542 (Advanced API) to remove the references to Type 0
routing header?

Thanks
-vlad

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Thu, 17 May 2007 09:30:40 +0900 (JST)

> > 	Filename	: draft-ietf-ipv6-deprecate-rh0-00.txt

	it is a good one.  it would be a "successful failure" of IPv6 just like
	Apollo 13.  comments:
	- on filtering you may want to talk about tunnelling and stuff
	  (yes, i know it would cost A LOT).
	- if script kiddies have a good idea about MIP6, they could workaround
	  ingress filtering by spoofing souce addr - ISP core routers really
	  cannot perform ingress filtering due to the frequent updates in BGP
	  routing table at the peering routers.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Thu, 17 May 2007 16:46:01 +0900 (JST)

> update RFC 3542 (Advanced API) to remove the references to Type 0

	we may want to remove references to rthdr0, but section 7 (Routing
	Header) may be useful for rthdr7 (non-disturbing version of source
	routing header), so i would say we may want to keep inet6_rth_blah.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 May 2007 16:02:03 +0300 (EEST)

> update RFC 3542 (Advanced API) to remove the references to Type 0

Dunno about that, but I guess an Updates: 4294 (IPv6 Node 
Requirements) would be in order.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 17 May 2007 09:33:01 -0400

Brian Haberman wrote:
> While it would be useful to update 3542, I don't think it is necessary.
>  It is out-of-date given that it says the Type 0 routing header is the
> only one defined (it isn't).  However, I don't see the benefit of
> revising that spec *just* for this.
> 
> Perhaps we should simply add a statement to the errata page for 3542
> pointing to the deprecation document.

That's fine.   Just trying to cover all the cases.

Thanks
-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 17 May 2007 11:04:24 -0400

> 	routing header), so i would say we may want to keep inet6_rth_blah.

Yes, the functions are still valid.  To bad the spec was written with Type 0
as example.

-vlad

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 17 May 2007 18:22:20 +0300

> update RFC 3542 (Advanced API) to remove the references to Type 0

And then:
1/ Are inet6_rth_space() and inet6_rth_init() supposed to fail with 
type 0?
2/ What is setsockopt(IPV6_RTHDR) supposed to return for type 0?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 May 2007 09:28:10 -0400

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 May 2007 09:28:10 -0400

Regards,
Brian

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 May 2007 15:24:55 +0300

Pekka,

> Requirements) would be in order.

Yes, that would be good.

Jari

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 23 May 2007 18:14:13 +0900

At Thu, 17 May 2007 09:28:10 -0400,

> revising that spec *just* for this.

I agree...

> pointing to the deprecation document.

...but I don't think the errata page is the right place to note this
update either, since this is actually not an error of RFC3542 per se.
(Or can we use the errata page as a placeholder for possible updates
in the future?)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Wed, 23 May 2007 08:17:28 -0400

> (Or can we use the errata page as a placeholder for possible updates

I agree that it is not an error in 3542, but it is something that needs
fixing in 3542 (along with other items).

In many instances the errata serves as a placeholder for update topics.
 I see no problem with doing that in this instance.

Regards,
Brian