Subject: Re: Routing Header Type 0 way forward

From: "Ebalard, Arnaud" <[email-masked]>
Date: Wed, 16 May 2007 10:05:55 +0200

Hi,

Le 14 mai 07 à 22:12, Brian Haberman a écrit :

>      Please make any issues/problems you may have with this approach
> known to either the mailing list or the chairs directly.

The following point is being discussed off-list and there is  
certainly interest in having a clear statement on the topic in the  
deprecation document.

In current IPv6 stacks, RH0 deprecation can be made by progressively  
removing the code for processing it or by simply deactivating it.  
Some systems currently keep the ability to activate it again (through  
sysctl or equivalent).

Should (can) something like the following be added to the draft ?:  
"Conformant implementations of IPv6 hosts and routers MUST not  
provide a way to activate RH0 processing on the system."

Cheers,

a+

-- Arnaud Ebalard
EADS Innovation Works - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 May 2007 12:51:21 +0200

> provide a way to activate RH0 processing on the system."

This is a very bad idea for two reasons:

1. The IPv6 spec says that you MUST implement it, then having  
something else say you MUST NOT actually use it is just bad standards  
making

2. Maybe someone has a legitimate use for this, they should be able  
to do so if they want

This whole issue is blown WAY out of proportion: the BSD guys should  
not forward when forwarding is disabled, the router guys should  
disable source routing by default (for IPv4, too, please). Problem  
solved, bring on the next one.

If, at some later date, it turns out nobody uses this feature, rip it  
out of the next iteration of the IPv6 spec. But please, let's not  
overreact. Compared to what we had to go through with directed  
broadcast amplification (smurf attack), this isn't much of an issue  
at all, even if you ignore that IPv6 uptake isn't above 0 in a  
statistically significant way yet.

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Wed, 16 May 2007 20:01:39 +0900 (JST)

> 2. Maybe someone has a legitimate use for this, they should be able  

	how many times do i have to post this: there's ZERO RFCs that use
	rthdr0.  nuke it immediately for the sake of world peace.

	as the firm believer of running code (not the spec), i urge you to
	look at http://www.kame.net/newsletter/20070502/rthdr0.diff.txt
	and check out the comments.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Wed, 16 May 2007 20:06:15 +0900 (JST)

> 	and check out the comments.

	as posted earlier, i cannot really sleep tight until the very last
	machine on the planet get patched.  root DNS servers as well as all
	trans-ocean links (both IPv4 and IPv6) are at stake.  if this does not
	scare you enough, quit your job immediately.

itojun
PS: no need for "go to bed" DoS.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 May 2007 13:22:57 +0200

> 	rthdr0.

Since when is it required to write an RFC before you get to use a  
feature? Arnaud's little test program certainly used this feature and  
I haven't seen an RFC for it.

> 	and check out the comments.

I still don't get the point of what you're trying to say.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 May 2007 13:29:58 +0200

> 	scare you enough, quit your job immediately.

Well, obviously you can't be serious, but I also don't get the joke.

The whole root server thing is nonsense. The only thing you can do is  
address your packet at an anycast instance other than the one you  
would normally be able to reach. Big deal. And oh, wait... the root  
servers aren't available over IPv6 yet! I know some have IPv6  
addresses but those can't be used for production queries until IPv6  
addresses are added to "the dot".

As for intercontinental links: as an ISP, I wouldn't mind my  
customers ping-ponging the same packet back and forth: this uses more  
bandwidth, so I make more money.

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Wed, 16 May 2007 20:32:08 +0900 (JST)

> Well, obviously you can't be serious, but I also don't get the joke.

	i'm not joking.

itojun

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 May 2007 12:49:12 +0100

> 2. Maybe someone has a legitimate use for this, they should be able to
> do so if they want
>

I'm with Iljitsch on this one.

this thread has provided high "entertainment value", but I think the
IPv6 list has had enough of this now.

/ot

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 May 2007 12:59:01 +0000

> > This is a very bad idea for two reasons:

i disagree with both, as shown below.

> > 1. The IPv6 spec says that you MUST implement it, then having something
> > else say you MUST NOT actually use it is just bad standards making

we're going to have to amend the standard, to deprecate this feature.  the
bit pattern should be treated as unrecognized by all conformant 
implementations of the amended specification.  there is no conflict here.

> > 2. Maybe someone has a legitimate use for this, they should be able to

then let's define a new bit pattern that means what RH0 used to mean, make
it experimental, and require that it be off by default on all conformant
implementations of the new specification.

> > solved, bring on the next one.

that won't solve this problem.  (and those are not the problems with RH0.)

> > out of the next iteration of the IPv6 spec.

this is the next iteration of the IPv6 spec.  we're ripping it out $now.

> > But please, let's not overreact. Compared to what we had to go through
> > with directed broadcast amplification (smurf attack), this isn't much of
> > an issue at all, even if you ignore that IPv6 uptake isn't above 0 in a

current deployment is only a percentile or so of what i'm worried about.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 May 2007 15:49:17 +0200

> that won't solve this problem.  (and those are not the problems  

Why not and what are the problems with RH0 then?

> current deployment is only a percentile or so of what i'm worried  

What are you worried about?

---

From: Joe Abley <[email-masked]>
Date: Wed, 16 May 2007 10:38:09 -0400

> provide a way to activate RH0 processing on the system."

I think this is inherent in the whole concept of deprecation, and the  
normative MUST NOT with respect to originating or processing packets  
with RH0. I do not propose to add this text to the draft before I  
submit it (although if the working group demonstrates consensus that  
such text should be added, I will not stand in its way).

Joe