On Apr 17, 2007, at 01:32, Brian E Carpenter wrote:
On 2007-04-17 00:55, james woodyatt wrote:
...
Whether network policy permits application reachability is
independent of whether applications are addressable. I only think
NAT needs to be used to redirect application flows between
middleboxes, not between application endpoints in separate addressing
realms.
Can you explain that? Why can't you redirect packets without NAT?
The immediate visibility of the problem is as an implementation concern
for the existing AirPort Extreme base station product, where the NAT
would be used only within the router itself, though I can imagine more
complicated application level gateway deployments that might require the
NAT to redirect from the filtering router to a proxy running on another
middlebox.
Here's the current situation inside the AirPort Extreme base station:
+ We have an IPv4 packet filter with an integrated NAT. The way the FTP
and RTSP gateways are implemented is that NAT redirection rules are
applied to the local interface to translate all outbound flows from FTP
control streams and RTSP streams into a locally running proxy service.
+ The proxy service accepts these translated TCP streams and makes
outbound connections on the client's behalf to the remote server. In
the IPv4 case, it translates IP addresses in the FTP control stream. It
also inserts and removes state records for the FTP data streams it
learns about in the process. The equivalent things happens in the RTSP
proxy.
+ To make this work with IPv6, the proxies don't have to translate
anything, but they do still need to insert and remove state records for
the associated TCP and UDP flows they learn about from parsing the FTP
and RTSP streams.
+ The piece that's missing is the IPv6 NAT, to redirect FTP and RTSP
control streams into the proxies.
Can you draw the picture?
Here's a crude attempt at a picture of what's going on inside the router
for the RTSP case, which is what allows Quicktime Streaming and
RealPlayer streaming to use RTCP/RTP transports:
Outbound TCP port 7070 SYN Arrives on LAN 2001:db8:aaaa::
from 2001:db8:aaaa::1 ====> packet filter applies policy
to 2001:db8:bbbb::1 on LAN NAT redirects to 2001:db8:aaaa::
|
V
TCP negotiates thru NAT between
router at 2001:db8:aaaa:: and
client at 2001:db8:aaaa::1
Proxy accepts TCP from client
|
V
Outbound TCP port 7070 SYN NAT redirects from 2001:db8:aaaa::
from 2001:db8:aaaa::1 <==== Proxy connects TCP to server from
to 2001:db8:bbbb::1 on WAN router at 2001:db8:aaaa:: thru NAT
|
V
Proxy intercepts SETUP method
Adds state for RTP/RTCP flows
found in Transport: header
[etcetera]
Can I do this without NAT? I don't see how. I'd really like to know
how, which is why I'm spending so much of Apple's time trying to find
out if the IETF community has solved this problem already in some way I
don't yet understand.
Somehow, I've got to get my FTP and RTSP proxies to be a "man in the
middle" for IPv6 the same way they do today for IPv4, but accepting TCP
connections from clients and making TCP connections to servers, parsing
the control streams to learn about data transport flows and managing
their pinholes in the stateful packet filter.
That seems pretty easy to do by extending IPv6 NAT, and truthfully,
that's what management here seems to think is the best path forward at
this point.
You could surely redirect by encapsulation, and possibly by using a
host route.
How? The proxies bind to a local interface address to receive TCP
connections intended for other destinations. They insert themselves
into the flow explicitly to maintain the appearance of transparency at
the router. I don't see any way to do that without deploying NAT.
--
j h woodyatt <jhw@apple.com>