[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
We should also come to some agreement about cause & effect. I don't believe that the existence of an ALG creates a need for nat, but the existence of it does allow for the 'opportunity'. SOCKS proxies existed long before nat, and 
fill one aspect of a perceived need for a managed boundary.


I'm in complete agreement with this.
I am willing to be open minded here, but that last point is hard to follow. Very few organizations want an abundance of firewalls, so a vastly reduced number of RTSP proxies sounds like a stretch. Typically the goal is to have as few places where policy needs to be enforced as possible, just to make 
sure it is being enforced consistently.
As I said, my RTSP example was meant to illustrate the general case that has me concerned. It's possible that network operators know more about the practical considerations in this space than I do, and they can speak with authority about whether my concerns are overblown.
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.
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.
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. 


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