RE: IPv6 Type 0 Routing Header issues

["Tony Hain" <alh-ietf@tndh.net>]

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: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Ed Jankiewicz
> Sent: Wednesday, April 25, 2007 8:13 AM
> To: v6ops@ops.ietf.org
> Cc: Rob Austein; ipv6@ietf.org; ipv6-ops@lists.cluenet.de;
> nav6tf@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@sri.com 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  ed.jankiewicz@sri.com
>