Before you kill this off too quickly, James Woodyatt's proxy redirection is a perfect example of a 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.
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. Tony > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ed Jankiewicz > Sent: Wednesday, April 25, 2007 8:13 AM > To: [EMAIL PROTECTED] > Cc: Rob Austein; [email protected]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: IPv6 Type 0 Routing Header issues > > I am facing a similar dilemma. Currently editing version 2.0 draft of > the US DoD "DISR Product Profiles for IPv6" and considering adding a > THOU SHALT NOT or at least "it would be a great idea if you didn't" > forward based on RH0 due to this vulnerability. At the very least I > will note this risk, suggesting that vendors SHOULD provide a means of > disabling RH0, and also consider disabling by default. > > Especially interested in strong opinions from vendors about difficulty > in complying if that were the case. Cross posting to NAv6TF as well, > but please reply directly to [EMAIL PROTECTED] and avoid cluttering > up the lists with specific objections and suggestions. I will summarize > back to the lists. > > Thanks > Ed J. > > Rob Austein wrote: > > At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: > > > >> The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 > >> implemenation non-conformant to standard. > >> > > > > Sometimes violating the standard is the only reasonable thing for an > > implementor to do. The (IPv4) stack I worked on back in the '90s > > shipped with forwarding of directed broadcast disabled by default, > > long before anybody had heard of a "smurf attack". The stack had a > > compile-time option to enable forwarding of directed broadcast; from > > memory, the documentation for that option went something like this: > > > > "This option exists solely to allow this software to comply with RFC > > 1812. Directed broadcast is dangerous, no matter what RFC 1812 > > says. Never enable this option under any circumstances." > > > > Eventually the IETF gathered the collective will to update the > > standard, but as implementors we would have been derelict in our duty > > to our customers had we waited for the IETF. > > > > > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research > Supporting DISA Standards Engineering Branch > 732-389-1003 or [EMAIL PROTECTED] > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
