[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The argument for writing a general purpose NAT for IPv6
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>