[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The argument for writing a general purpose NAT for IPv6
On 17-apr-2007, at 21:33, james woodyatt wrote:
No. I'm just trying to get active mode FTP clients and Quicktime/
RealPlayer streaming clients, which use RTCP/RTP transports, to
communicate properly from the local network with servers on the
IPv6 WAN the way they do today with servers on the IPv4 WAN. Maybe
next month, I'll try to get more esoteric applications to work.
The end-to-end connectivity of IPv6 IS ALREADY BROKEN-- by the
insistence that stateful packet filters block inbound flow
initiations in factory default configurations of residential IPv6
gateways. This is *exactly* how the end-to-end connectivity of
IPv4 got broken. We are all now merrily marching off to do it
again to IPv6, and I'M NOT IN A POSITION TO STOP IT.
I feel slightly responsible here after writing this:
The problem is that people are now getting IPv6 connectivity without
realizing it, and having everything open over v6 despite filtering
efforts (yes, NAT isn't a firewall, but these people don't really
know what either of these words mean anyway) is can only end badly.
However, let me propose a different direction for solving this:
rather than waiting until a port number is selected, put into a
control stream, then intercept that control stream, recover the port
number and open up the firewall, why not simply set aside a range of
port numbers for these types of purposes and let those through the
With IPv4 this wouldn't work because there has to be a mapping
between an private and a public address, but with IPv6 that's not
I can see how someone may be uncomfortable with this because it means
it's still possible for packets to come in from the outside to hosts
on the inside, but as long as no services are present on the ports in
question, that's not really an issue, except for possible IP layer
exploits, but I'm pretty sure that's a thing of the '90s.
Iljitsch van Beijnum