Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]

On Apr 26, 2007, at 15:58, Tony Hain wrote:
>
> 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.

I should make clear that I'm not persuaded that use of the routing  
extension header gives me a way to do what I've been talking about in  
both V6OPS and BEHAVE.  Moreover, I *really* don't think RH type code  
**ZERO** is a better hammer than simple IPv6 NAT.  (Oh boy... I've  
just whacked another beehive, haven't I?)

For my immediate purposes, where I only need to redirect inside the  
routing node between the packet filter and the node's own stack, I  
can probably define my own internal routing extension header type  
code.  In fact, since the packets aren't going anywhere on the wire,  
I could just dispense with the extension header altogether and just  
overwrite the destination address in the IPv6 header while inserting  
an appropriate state record into the packet filter for the proxy to  
find.  This will be functionally equivalent to using IPv6 NAT, and  
I'll be doing this in the code that implements the IPv4 NAT and SPI  
filter, but if it makes everyone feel more warm and fuzzy that no  
actual NAT is going on, I'll use another word for it.  I wouldn't  
want anybody to lose more sleep.

Where the situation gets a lot more interesting is when the  
transparent application proxy is not resident on the same node as the  
filter where the diversion happens.  That's where the routing  
extension header could be necessary.  In that case, I still don't  
think type code *ZERO* is the wrong choice, because something must  
*remove* the extension header on the return path for the proxy to  
remain transparent.

--
j h woodyatt <jhw@apple.com>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------