Subject: Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt

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

Oy,

Le 10 mai 07 à 09:00, Pekka Savola a écrit :
> In order to kickstart some discussion, here are two comments:

Good idea.

> 3.  Implementation
>
>    Compliant IPv6 hosts and routers MUST NOT transmit IPv6 datagrams
>    containing RH0.
>
> ==> does 'transmit' include both 'originate' and 'forward' or just the
> former?

I hope it is 'originate' (resulting from processing of a routing header
addressed to the router).

> I'd be interested in seeing comments from router vendors on the
> feasibility of the blocking forwarding for type 0 routing headers (but
> not other types).

Me too, but just for fun. This would imply possible processing of the
whole extension headers chain. Even if it was possible from a
performance standpoint, does anyone want that kind of filtering in the
core ?

> Would that include packets where the routing header wouldn't be the
> immediate next-header (e.g., you'd put a hop-by-hop header or
> something like that first, only then routing headers)?  That's even
> more difficult as the implementation would need to skip through all of
> them, possibly with a 'lookup depth' of the maximum packet size.
>
> AFAIK, usually the amount of bytes of the header available to ACLs is
> limited, unless you punt the whole packet to the control processor
> which is probably a treatment worse than the disease.

And this goes against one of the aim of IPv6 : limiting the work
performed by routers.

The sentence could be modified in :

"Compliant IPv6 hosts and routers MUST NOT process RH0 in packets
  addressed to them. Those packets MUST be dropped without further
  processing. In particular, the value of the Segments Left field
  MUST not be considered."

Some comments on that :

- This prevents routers and host to automatically process packets with
   RH0 and forward traffic to another waypoints.

- This prevents blindly source-routed packets to be processed by the
   final destination (null value for Segments Left field), i.e. this
   prevents an attacker to target an instance of a service after having
   escaped the natural path (DMZ concern, Anycast service).

- This part is an obvious update to Section 4.4 of RFC 2460: IMHO, final
   destination should only accept source-routed traffic when the
   associated RH type is configured, activated and guarantied to have no
   impact. The sentence is in sync with MIPv6.

- This also prevents the packet to be "locally" forwarded, between the
   addresses of the host/router.

- IMHO, emission of ICMPv6 message should not be done (this is implicit
   in the 'no further processing'). This could be added in an explicit
   fashion at the end of the paragraph, if unclear. RH0 being deprecated
   in the context of the draft, I think it's fair that this kind of
   traffic is not worth a reply.

Comments welcome !

> 4.  Operations
>
>    Compliant IPv6 hosts and routers which receive IPv6 datagrams
>    containing RH0 MUST silently discard those datagrams without
>    further processing.
>
> ==> is this really 'Operations' or is it really implementation?  I.e.,
> are you requiring the network or host operators to do something or the
> implementations?

"receive" is unclear, like "transmit" in previous section. I think what
is implied here is covered by my previous proposal.

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: Brian Haberman <[email-masked]>
Date: Thu, 10 May 2007 09:50:01 -0400

>> feasibility of the blocking forwarding for type 0 routing headers (but

Does a former router vendor count? :)

One problem I see with this is that there could be some confusion with
the word "forward".  That is, does it mean forward if the node receives
it as an arbitrary router along the path?  Or does it mean forward it
since it received it via one of its addresses being in the destination
address field?

> performance standpoint, does anyone want that kind of filtering in the

RFC 2460 explicitly states that intermediate routers do not examine or
process extension headers while the packet is in transit.

What happens if the packet is encrypted?

>   processing. In particular, the value of the Segments Left field

This is much clearer and easier to implement.

Regards,
Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 May 2007 17:31:01 +0300

Brian,

> This is much clearer and easier to implement.

I agree.

Jari

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 10 May 2007 15:42:07 +0100

Brian Haberman wrote:
[..]
> This is much clearer and easier to implement.

It is indeed.

But there is a big BUT. Existing code is already deployed. When these
installations don't get updated to fix this problem they remain
vulnerable and can be used for this attack, as such packet-ping-ponging
between the vulnerable hosts.

As such, when you are a transit provider, and you have on the edges of
your network some vulnerable hosts, those hosts can be used to apply
this attack to your network.

The documentation should thus specify that, where possible, RH0 should
be filtered at customer borders.

(And there should thus be a harakiri-penalty for folks who do not
upgrade their nodes imho...) of course that can also be solved by
publicly shaming those people and more direct: disconnecting them till
they fix their networks.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 May 2007 17:49:14 +0300 (EEST)

> be filtered at customer borders.

Well, IMHO that's a bit unnecessary.

If you see packet ping-pong on the Internet, it's an indication that 
ingress and egress filters haven't been adequately set up.  Adding 
those will stop your network's bandwidth being wasted.

Maybe this RH0 vulnerability will turn out for the good after all if 
it means better BCP38/84 deployment :-)

-- 
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: Jeroen Massar <[email-masked]>
Date: Thu, 10 May 2007 15:56:58 +0100

Pekka Savola wrote:
> ingress and egress filters haven't been adequately set up.  Adding those
> will stop your network's bandwidth being wasted.
> 
> Maybe this RH0 vulnerability will turn out for the good after all if it
> means better BCP38/84 deployment :-)

Oops, forgot about that indeed. uRPF resolves that concern already :)

I do also have it noted here that folks should do BCP38 properly:
 http://www.sixxs.net/faq/connectivity/?faq=filters

As such, maybe include an extra reference and heavy lined note to BCP38?

Also, maybe force vendors to enable BCP38 per default by making it a MUST?

Greets,
 Jeroen

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Thu, 10 May 2007 08:38:42 -0700

At Thu, 10 May 2007 09:50:01 -0400,
> This is much clearer and easier to implement.

Though I am not a router vendor I am the person who has to handle this
on FreeBSD.  I like the above sentence as well.  I think inspecting
the packet contents when a packet passes through any sort of
forwarding path is not what we want.  If someone wants to actively
filter these types of packet from their network that's what a firewall
or packet filter is for.

Best,
George

---

From: David Malone <[email-masked]>
Date: Thu, 10 May 2007 20:46:11 +0100

> Well, IMHO that's a bit unnecessary.

I think this worse than unnecessary - it is probably harmful. If
filtering is recommended then some proportion of people will filter
all routing headers and use this recommendation as a justification
for it. Then we'll be backed into a corner where we can't replace
RH0 with something safe and we we also break the mobility stuff.

> it means better BCP38/84 deployment :-)

Indeed - ISPs would be much better implementing BCP38/84.

	David.

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 May 2007 17:09:31 -0400

On 10-May-2007, at 11:38, George V. Neville-Neil wrote:

> on FreeBSD.  I like the above sentence as well.

The above sentences far more closely resemble what I meant to write,  
compared to the text that actually appeared in the draft :-)

I note that KAME's response to this is similar, but it's not clear to  
me that it's precisely identical: a patched KAME implementation  
treats the type 0 routing header as an unknown routing header  
(according to <http://www.kame.net/newsletter/20070502/>). This  
suggests to me that a patched KAME implementation will process a  
datagram containing RH0, but that RH0 header(s) in the datagram will  
not be acted upon. I would welcome corrections to my feeble  
assumptions in this area (I have done no tests, nor read any source  
code to confirm).

A packet containing RH0 presumably is intended not to be processed on  
the system identified by the destination address field; if it was, no  
RH0 would be present. This suggests to me that "MUST drop" is the  
right thing, rather than "process as if RH0 was not there"; in  
addition, if we assume that today any packet with RH0 is likely to be  
malicious, any processing of a packet containing RH0 which has the  
potential to result in backscatter seems like it should properly be  
avoided.

Joe

---

From: [email-masked]
Date: Thu, 10 May 2007 16:30:44 -0700

At Thu, 10 May 2007 17:09:31 -0400,
Joe Abley wrote:
> I note that KAME's response to this is similar, but it's not clear
> to me that it's precisely identical: a patched KAME implementation
> A packet containing RH0 presumably is intended not to be processed
> on the system identified by the destination address field; if it
> was, no RH0 would be present. This suggests to me that "MUST drop"
> is the right thing, rather than "process as if RH0 was not there";
> in addition, if we assume that today any packet with RH0 is likely
> to be malicious, any processing of a packet containing RH0 which has
> the potential to result in backscatter seems like it should properly
> be avoided.

The Kame folks can comment on the current state of their change, they
made a couple of them.  In FreeBSD 6 an 5 (the stable branches) we
have a sysctl to turn processing on and off.  In 7 (aka HEAD or
CURRENT) we treat the RH0 as unknown.  Code diffs can be seen here:

HEAD:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/route6.c.diff?r1=1.12;r2=1.13;f=h

STABLE:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/route6.c.diff?r1=1.11.2.1;r2=1.11.2.2;f=h

Best,
George

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 11 May 2007 11:16:49 +0900

> compared to the text that actually appeared in the draft :-)

"packets addressed to them" still sounds a little ambiguous to me; it
could be interpreted as including intermediate hops specified in the
routing header or as only meaning the final destination.  The intent
should obviously be the former, so I'd rephrase it further:

 "Compliant IPv6 hosts and routers MUST NOT process RH0 in packets
  whose destination address in the IPv6 header is an address
  assigned to them."

BTW, I agree we shouldn't require routers to inspect every IPv6 packet
and drop it when it contains RH0 (even if whose IPv6 dst is NOT a
routers' address).  It should leave to FWs, not ordinary routers.

> assumptions in this area (I have done no tests, nor read any source  

I guess you're talking about whether the node returns an ICMPv6 error
when receiving a packet that contains an RH0 whose IPv6 dst is one of
its own addresses.  KAME's implementation treats it as an "unknown
type" of routing header as you guessed and it returns an ICMPv6
parameter problem error as a result.  This is an intentional behavior:

http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/route6.c.diff?r1=1.62;r2=1.63

(Which type of error is appropriate is a different question)

> potential to result in backscatter seems like it should properly be  

I believe we should rather return an ICMPv6 error.  Even if we decide
to deprecate type0 RH, there will be many non-updated systems for a
certain period of time.  Since there is at least one know popular (but
non-attacking) usage of RH0, i.e., probing 'return path' by
traceroute, we'll still see non-attacking packets containing RH0.  It
would be better to notice such innocent but not just well-informed
users explicitly, rather than simply dropping the packet.  Regarding
'backscatter', if you mean a DoS for the ICMPv6 recipient with a
source-spoofed packets containing RH0, I don't think it's a big
concern in this context; that's not different from other type of
backscatter' attacks with a forged source address, so simply
prohibiting this case wouldn't help much; and I believe returning an
error is actually helpful as I stated above.  Also, ICMPv6 errors are
rate limited, so the backscatter effect is limited accordingly.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 11 May 2007 11:24:03 +0900

At Thu, 10 May 2007 10:11:16 +0200,

>    impact. The sentence is in sync with MIPv6.

Are you suggesting the following part should apply regardless of the
type of routing header?

  In particular, the value of the Segments Left field
  MUST not be considered.

If so, I don't think the current rh0 draft could be interpreted that
way (aside from whether we'd agree it in the first place).

					JINMEI, Tatuya

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 11 May 2007 11:34:45 +0900 (JST)

sorry, with flood of emails and phonecalls i really cannot keep up.
	it could be duplicate of comments that were made by various people.

	i'm calm as stillwater now, so it is PG13 rating :-)

> > the potential to result in backscatter seems like it should properly

	there were several points joe (jabley) made during our private
	conversation:
	- should we drop a packet silently - without returning ICMPv6 parameter
	  problem (jabley's suggestion), or should we return ICMPv6 so that
	  innocent user of rthdr0 would be notified (kame's latest tree).
	  since there's no amplification and ICMPv6 errors are rate-limited,
	  returning ICMPv6 parameter problem would not harm that much (even
	  under DDoS condition - depending on how your implementation do
	  rate-limit).
	- should we filter more drastically like openbsd does - see May 8 entry
	  at http://opengrok.creo.hu/openbsd/history/src/sys/netinet6/?
	  or it is ok to be conservative like kame tree?
	- packet filters MUST have filtering language/syntax/whatever that
	  supports rthdr0.  openbsd guys are working on it - PF syntax will be
	  annotated with new rule.  see May 8 entry by mcbride@openbsd at
	  http://opengrok.creo.hu/openbsd/history/src/sys/net/.  more to come.
	- # of permitted routing headers has to be less than 2 (no more than 1).
	  there is no need for the source to transmit a packet with multiple
	  routing headers, as they can put a lot of routing header type X.
	- should we mention/suggest filtering at the edge? (ISP customer edge
	  and/or ISP peering edge) 
	  yes, it sounds hairy, but it was done in practice with IPv4 - IPv4
	  packet with IP(v4) option were filtered at US-JP border, so we could
	  not enjoy mobile-ip4-ish "home address" by first 2 revision (or so)
	  of Teraoka-san's VIP, Virtual Internet Protocol.
	  customer edge filtering would be performed with consent of customers.
	  but it comes with no cost: (1) operators MUST run SNMP/whatever on
	  the edge routers (both edges) to watch rthdr0 traffic anyways
	  (2) packets with routing header go into slow path anyway.
	  (we need SNMP mib extension?  yeah, that would be nice)
	- there are two stopgap measure: (1) max hoplimit =  255, (2) packets
	  with routing headergo nito slow path so the attack using rthdr0
	  wouldn't fill up 10G link.
	  about point (2), IIJ guys are making quantitative analysis on our
	  routers, juniper - sorry cisco guys:-) - and i bcc'ed it to them
	  so you might hear from them.
 
> CURRENT) we treat the RH0 as unknown.  Code diffs can be seen here:

	as i repeatedly mentioned, there's NO NEED AT ALL for such sysctl.
	there are ZERO RFCs that use rthdr0, thanks to efforts in MIP6
	arena (if MIP6 were to use rthdr0 for its source-routing, MIP6 would
	have been dead together with rthdr0).  if it were to be turned on,
	it would be just like giving atomic bomb to script kiddies.
	so please, remove that sysctl knob, at once.  Apple MacOS X guys got it
	right.  no wonder, i gave serious IPv6 tutorial in Apple HQ!
	i won't hack on BSDs that do not randomize PIDs. (i would need to do
	something about Apple MacOS X, yeah)

itojun2.0
Hannibal Lecter in calm mode

---

From: David Malone <[email-masked]>
Date: Fri, 11 May 2007 06:52:56 +0100

On Fri, May 11, 2007 at 11:16:49AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> users explicitly, rather than simply dropping the packet.

I buy this argument in favour of returning an error. I guess that
means we should select an error type which is usefully displayed
by (some/most/all?) versions of traceroute6?

	David.

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 11 May 2007 17:16:29 +0900 (JST)

> 	  http://opengrok.creo.hu/openbsd/history/src/sys/net/.  more to come.

	mcbride@openbsd suggested that the above URL is rather misleading/
	broken/not up-to-date enough.

	see Revision 1.528 and 1.529 of pf.c:
	http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c

itojun

---

From: Guillaume Valadon / ギョーム バラドン<[email-masked]>
Date: Fri, 11 May 2007 14:16:41 +0200

Hi,

> Since there is at least one know popular (but
> traceroute, we'll still see non-attacking packets containing RH0.

Except some custom-made traceroute6 and KAME's implementation, I am  
not aware of such usage of RH0. What I mean here, is that deprecating  
RH0 won't harm anyone (except some reasearchers).
Discovering the 'return path' is a really cool feature, but the  
discussions during the last weeks proved that RH0 is not the right  
solution. Its benefit is too small comparing to the problem related  
to RH0.

Deprecating RH0 seems to be the only reasonable choice. I do not get  
why some people want a 'disable by default' solution to this problem.  
Do we need to explain one more time why RH0 MUST NOT be turned on ?

Guillaume

--
Guillaume Valadon / ギョーム バラドン
[email-masked]

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 11 May 2007 21:20:59 +0900 (JST)

> Do we need to explain one more time why RH0 MUST NOT be turned on ?

	cannot agree more.  you helped me sleep tight.

itojun

---

From: Guillaume Valadon / ギョーム バラドン<[email-masked]>
Date: Fri, 11 May 2007 14:51:54 +0200

Hi again,

> 	  under DDoS condition - depending on how your implementation do

If RH0 is deprecated, the processing of this extension falls back to  
RFC 4443:

    If an IPv6 node processing a packet finds a problem with a field in
    the IPv6 header or extension headers such that it cannot complete
    processing the packet, it MUST discard the packet and SHOULD
    originate an ICMPv6 Parameter Problem message to the packet's  
source,
    indicating the type and location of the problem.

> 	  http://opengrok.creo.hu/openbsd/history/src/sys/net/.  more to  

The wise choice is that packet filters must *support* RH2.
I am really scared that these discussions about RH0 also kill RH2 and  
Mobile IPv6. That will probably lead to another endless discussions  
to decide how the same feature as RH2 could be re-added to Mobile  
IPv6 (i.e. a specific Home Address Extension that do not share the  
same next header value as RH0). Shisa's people might be useful here.

A last comment on the two drafts, I think that they need to be merged  
(and draft-jabley-ipv6-rh0-is-evil stopped). The discussion about  
IPv4 should be removed. Some sentences in the introduction explaining  
that SR processing is disable are enough.

Guillaume

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 11 May 2007 21:55:06 +0900

At Fri, 11 May 2007 14:16:41 +0200,

> Do we need to explain one more time why RH0 MUST NOT be turned on ?

You missed my point (I didn't advocate not deprecating RH0).  Please
reread my message.

					JINMEI, Tatuya

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Fri, 11 May 2007 13:54:51 -0700

At Fri, 11 May 2007 11:16:49 +0900,
> rate limited, so the backscatter effect is limited accordingly.

I agree with what Jinmei is saying here and this is how the HEAD of
FreeBSD works currently, while it is only STABLE (5 and 6) that have
the sysctl.  If the final decision is to go this way then I can
backport a patch to 5 and 6 so that all FreeBSD's work this way.  As
I've said before I am waiting for a decision before I go patching the
code again.

Best,
George

---

From: David Malone <[email-masked]>
Date: Fri, 11 May 2007 22:18:27 +0100

> solution. Its benefit is too small comparing to the problem related  

IMHO, the existance of so many traceroute looking glasses is
significant evidence that operators (not just researchers) need
intermediate point traceroute. It is used by people to find routes
external to their network and to explore routes within their networks
(say big datacentre operators or big corporate networks). This
feature should be implementable in traceroute (where it seems to
belong) and not as a web/telnet application, which requires you to
have a cooperating server in each network you might want to trace
through.

This is why I think someone might want to turn RH0 back on again
(to get this feature on their own network). They can filter at the
border to prevent external abuse, and use the usual procedures to
deal with internal abuse. This is also the sort of feature that
ordinary users are not likely to use, which is why I think it is
reasonable to have it off by default.

I understand Itojun's suggestion that we can have a RH7 that will
allow useful source routing without the danger associated with RH0.
This sounds like a very good idea.  However, realistically, I suspect
that even if the RH7 standard was fully specified tomorrow, we would
be waiting more than two years to have it implemented in production
versions of software that operators are likely to be using.

	David.

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Sat, 12 May 2007 06:38:25 +0900 (JST)

> versions of software that operators are likely to be using.

	Do not worry, we apply "Code then spec" basis (as seen on KAME T-shirt
	page - have you checked it out?).  we contact vendors of KAME directly
	with patch, after careful tests and analyzations.  then someone can
	write up a specification.

itojun

---

From: Joe Abley <[email-masked]>
Date: Mon, 14 May 2007 08:22:38 -0400

> reasonable to have it off by default.

There seem to be many daily examples of very large numbers of client  
machines being controlled remotely to participate in activities that  
the owner/operators of those machines aren't aware of. If there's a  
hook available to turn RH0 processing back on, and RH0 is useful to  
the kind of people who control botnets today, then I think it's a  
fair bet that RH0 will be turned back on regardless of the default  
setting is.

If RH0 is not a useful mechanism to facilitate wide-scale network  
abuse, then I would not expect this to happen (but then, if RH0 is so  
benign, why are we talking? :-)

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 14 May 2007 08:24:36 -0400

On 11-May-2007, at 08:51, Guillaume Valadon / ギョーム バラド 
ン wrote:

> A last comment on the two drafts, I think that they need to be  
> merged (and draft-jabley-ipv6-rh0-is-evil stopped). The discussion  
> about IPv4 should be removed. Some sentences in the introduction  
> explaining that SR processing is disable are enough.

I have no problem reducing the number of drafts on the table to one,  
by any mechanism that the chairs think would best promote progress.

Personally, however, I still think deprecation is the correct option.

Joe

---

From: David Malone <[email-masked]>
Date: Mon, 14 May 2007 14:56:26 +0100

> fair bet that RH0 will be turned back on regardless of the default  

If you want to bounce packets around, it would seem far simpler to
turn on a UDP echo service - it doesn't have to have an 80 bounce
limit.  Or, if it is firewall evasion you're after, configure a
tunnel and turn on forwarding - it could even hide your real source
address.

If you've access to someone's machine and can twiddle parameters
of their IP stack, then RH0 isn't a big deal.

	David.

---

From: Guillaume Valadon / ギョーム バラドン<[email-masked]>
Date: Mon, 14 May 2007 16:20:54 +0200

Hi,

> of their IP stack, then RH0 isn't a big deal.

I did not understand your point here.
Are you trying to justify that RH0 are harmless regarding other kind  
of attacks ?

Guillaume

---

From: David Malone <[email-masked]>
Date: Mon, 14 May 2007 15:38:44 +0100

> Are you trying to justify that RH0 are harmless regarding other kind

I think Joe was suggesting that if RH0 was useful to attackers, and
we suggested a knob to allow it to be turned on/off, then malware
would just turn it back on again. I was just pointing out that there
already are things that malware can do which produce nastier attacks
than RH0 permits.

(I'm not quite sure if I understood your question correctly.)

	David.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 14 May 2007 16:12:04 -0400

IPv6 WG,
     The chairs have reviewed all the comments and feedback on the
Routing Header Type 0 vulnerability.  The consensus of the working group
is seen as:

     - Deprecate the Type 0 Routing Header
     - Provide guidance to operators to disable RH0 where possible

As a part of the deprecation, implementations should return an ICMP
parameter problem message to the packet source.

     The chairs request that the authors of the two two drafts currently
published discussing the RH0 issue (draft-jabley-ipv6-rh0-is-evil-00.txt
and draft-savola-ipv6-rtheader-00.txt) combine them and publish a single
draft as an IPv6 w.g. document.

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

Regards,
Bob and Brian
IPv6 WG co-chairs

---

From: Brian Haberman <[email-masked]>
Date: Mon, 14 May 2007 10:17:17 -0400

IPv6 WG,

Regards,
Bob and Brian
IPv6 WG co-chairs

---

From: Brian Haberman <[email-masked]>
Date: Mon, 14 May 2007 10:17:17 -0400

> Personally, however, I still think deprecation is the correct option.

Speaking strictly as a work group participant, I agree with Joe that the
best way forward is to deprecate the Type 0 Routing Header.

Regards,
Brian

[email-masked]>
Subject: Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt

> Personally, however, I still think deprecation is the correct option.

Speaking strictly as a work group participant, I agree with Joe that the
best way forward is to deprecate the Type 0 Routing Header.

Regards,
Brian

---

From: Joe Abley <[email-masked]>
Date: Wed, 16 May 2007 11:17:03 -0400

> draft as an IPv6 w.g. document.

Our initial merge has been completed, and the resulting document has  
been submitted. The document should appear in the I-D repository in  
due course.

Those who would like a sneak preview can look here:

   http://www.flapdoodle.org/draft-ietf-ipv6-deprecate-rh0-00.txt

Joe

---

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

>   http://www.flapdoodle.org/draft-ietf-ipv6-deprecate-rh0-00.txt

I object to the use of the word "security". More later.