Translation of IPv6/IPv4 FTP packets...

[Juan Luis Baptiste]

Hi,

As Eddie already knows, I'm designing some new click elements that will work with IPv6/IPv4 address translation. One of them is like FtpPortMapper, but instead it will translate EPSV/PASV and EPRT/PORT
commands. I was looking at FtpPortMapper code to see how it does the translation of FTP packets, and I think I understand well how it does it. I have a different and simpler approach for doing this with IPv6/IPv4 translation elements (pt64,pt46 and at), and I would like to hear comments on this befor I start doing anything.

Okay, first let me explain how I understand FtpPortMapper works and then I'll explain my approach. FtpPortMapper is connected directly to an IPClassifier, so it has to create it self new mappings for ftp packets using the IPRewriter
and TCPRewriter elements that are passed to FtpPortMapper as parameters, after it has done the corresponding translation of the PORT command and before it creates the new packet with the new PORT command.

Now, for translating IPv6/IPv4 packets in Click we can use pt64 (IPv6 -> IPv4 protocol translator), pt46 (IPv4 -> IPv6 protocol translator) and at (Address
Translator). When a packet comes from an IPv6 host and going to an IPv4 host, the packet enters at element and it'ssource address gets translated to an
IPv4-compatible IPv6 address (ej. ::172.25.0.10) (the dest address already is a IPv4-compatible IPv6 address) and sent to pt64 for translation of the headers and creation of the new IPv4 packet. In the other way (IPv4 -> IPv6) the procedure is similar, but the packet first enter to pt46 and then to at element because at only accepts IPv6 packets.

For the translation of ftp packets, I would do an element (ej. FtpPortMapper6) that recives  "translated" packets, one wich already has passed thru at and pt64 elements (in IPv6 -> IPv4 way) and is ready to be sent to the IPv4 network.

Doing it this way is more simplier (I think) becasue as the packet is already translated, FtpPortMapper6 wouldn't have to deal with mappings,it only would
have to scan the packet for EPSV/EPRT commands and translate them. In case it finds an EPSV command it only has to change it for PASV command, and if it finds an EPRT command, it would have to build the PORT command taking for the PORT command address, the source address of the packet, and for the port, the port that is contained in the EPRT command. Becasue the packet is already translated, the source address corresponds to the mapping given to the IPv6 host in at element. In the IPv4 -> IPv6 way would be the same.

The element wouldn't have any parameters, as it doesn't have any rewriter elemens nor patterns to deal with. It would have to push inputs and three push outputs. Input 0 will be for IPv4 packets, input 1 for IPv6 packets, output 0 for IPv4 translated packets, output 1 for IPv6 translated packets and output 2 for bad packets.

Well, what do you think?

--
-------------------------------
Juan Luis Baptiste M.
Linux registered user #119248
http://www.merlinux.org

"we're back to the times
 when men where men and
 wrote their own drivers"
        Linus Torvalds
-------------------------------
-- 

Get your free email from www.linuxmail.org 


Powered by Outblaze