RE: The argument for writing a general purpose NAT for IPv6

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

james woodyatt wrote:
> I'm splitting up my replies to this to keep two different conceptual
> threads of discussion separate.
> 
> On Apr 26, 2007, at 14:35, Tony Hain wrote:
> >
> > First thing we need to do is agree on terminology, not that I know the
> > answer, but it appears that your definition of an ALG & mine are
> > different.
> >
> > To start with I would differentiate a signaling proxy from an ALG,
> > where the
> > former may be required for rendezvous but does nothing with the
> > content
> > stream, and the latter intercepts the content stream and in the
> > case of nat
> > modifies it to deal with embedded addresses.
> 
> I don't see any need for an IPv6 filtering ALG to modify the
> application content, even in the presence of the NAT function I'm
> talking about.  There is no need for more than one IPv6 address realm.

So essentially you are not really talking about an ALG or NAT at all. What
you have defined is a firewall rule that rather than just forward/drop adds
a state 'route via', then overwrites & restores the packet between the
firewall & the proxy. 

While that is a simple hack that would work within a single administrative
domain, I am not sure we want to standardize that as such. If it turns out
that the firewall can insert a routing header and push the real dst there
when overwriting with the proxy, then the proxy only has to do standard
extension header parsing.

> ...........
> 
> > This description screams out for use of the routing extension
> > header. Off
> > the top of my head it is not clear to me that the firewall could
> > insert one
> > without breaking something else, but if you don't want to write
> > decapsulation code at the receiver, the routing extension header
> > would allow
> > diverting traffic to it while maintaining the original destination.
> > Since
> > this is assumed to be 'transparent' the origin of the packet would
> > not know
> > the diversion destination, but if it were defined that RTSP always
> > carried
> > at least an empty routing header, then the firewall could move the
> > original
> > destination there and forward to the proxy. The extension header
> > parser in
> > the proxy would already know how to swap those back before
> > forwarding on.
> 
> I don't think the routing extension header is sufficient to solve the
> problem.  An application layer proxy has to be inserted into the
> transparently for the signaling of the filter to work properly.  I
> don't see how the routing extension header alone can be made to do that.

If the firewall inserts that extension, then pushes the original dst there,
that frees up the base header field for the proxy and results in 'standard'
extension header processing at the route-via point.


> 
> I'm prepared to admit that using the phrase "Network Address
> Translation" is a bit overloaded here, since we are just talking
> about diversion within the single, global IPv6 address realm, but the
> mechanism is basically the same.  The only difference is that it
> complicates the process of overwriting the IPv6 destination address
> by the need to also push a routing extension header.

Doing protocol design based on the ability to reuse existing code is not the
best practice. In any case the complexity is simply being moved around here.
If you take the nat approach, the proxy has to maintain state to restore the
packet. If you take the encapsulation approach, the proxy's stack will hand
up an intact packet ready to forward, rather than just the content so the
proxy parser would need to deal with that. If you take the extension header
approach the firewall has to move the original destination there before
overwriting the base with the address of the proxy. The lowest overhead
'stateless' of those is the last one, but I don't know if it breaks
anything, and I don't know if the proposed use would run into fragmentation
issues. As long as the end to end perceives that the packet sent was the
same as the packet received, if middle boxes mangle & restore it there is no
real problem. 


> 
> I'll agree, though, that defining a way to use routing extension
> headers for this purpose would be a very good idea, since that's
> necessary to make path MTU discovery in the presence of transparent
> application proxies not resident with filtering firewalls work properly.


I am buried right now, but in the next couple of months if you want to work
on an ID I would be happy to start one.

Tony