IPv6 Type 0 Routing Header issues
alh-ietf at tndh.net
Fri Apr 27 00:44:50 CEST 2007
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
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.
> -----Original Message-----
> From: owner-v6ops at ops.ietf.org [mailto:owner-v6ops at ops.ietf.org] On
> Behalf Of Ed Jankiewicz
> Sent: Wednesday, April 25, 2007 8:13 AM
> To: v6ops at ops.ietf.org
> Cc: Rob Austein; ipv6 at ietf.org; ipv6-ops at lists.cluenet.de;
> nav6tf at ipv6forum.com
> 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 ed.jankiewicz at sri.com and avoid cluttering
> up the lists with specific objections and suggestions. I will summarize
> back to the lists.
> 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 ed.jankiewicz at sri.com
More information about the ipv6-ops