I thought we already limited to 1 RH0 per packet, but I will have to go back and take a closer look.
As I said on V6ops, before you kill this off too quickly, James Woodyatt's proxy redirection is a perfect example of a valid use for Type 0 Routing Headers. He wants the firewall to redirect traffic through a designated point (what this header was designed to do), and the only hammer at his immediate disposal was IPv6/IPv6 nat. What I don't know is if the firewall can insert one that did not exist, because the source wouldn't know about his 'transparent' proxy. It is certainly reasonable to have a BCP that says 'these should be filtered at policy boundaries unless there is a good reason to do otherwise', but they are a tool to solve some very specific corner cases. I would say that firewalls should drop these by default, but the rest of the system should recognize them as normal. Tony > -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 26, 2007 3:17 AM > To: IETF IPv6 Mailing List > Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header > issues] > > On 2007-04-26 02:39, Bob Hinden wrote: > > [trimming this to just the IPv6 w.g.] > > > > We think the question for the IPv6 working group on this topic is does > > the working group want to do anything to address the issues raised > about > > the Type 0 routing header. Possible actions include: > > > > 1) Deprecate all usage of RH0 > > 2) Recommend that RH0 support be off by default in hosts and routers > > 3) Recommend that RH0 support be off by default in hosts > > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of > > addresses in one RH0. > > Excuse my ignorance, but have the following three rules ever been > considered? > > 1. The list of addresses in an RH0 MUST NOT include the packet's source > address. > 2. The same address MUST NOT occur more than once in an RH0. > 3. A node processing an RH0 MUST discard any packet breaking these two > rules. > > I'd be interested in whether this would eliminate the various attacks. > > (I'm not really advocating this, since it is added complexity for > a feature that we don't obviously need anyway. But if we don't deprecate > it, all the other options seem to leave the threats in place.) > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
