You are here: Home Tools 46Bouncer


by Administrator last modified Nov 08, 2007 06:01 PM


46Bouncer 3.0 (18 dec 2001) is a very simple tool that is able to accept TCP/UDP connections in IPv4/6 and forward them to an application in IPv6/4. In other words, it acts as a proxy between the IPv4 and IPv6 world (and vice versa).

46Bouncer belongs to the open-source paradigm, it adopts a BSD-style license and it comes with a small User's Manual.



There are four cases in which 46Bouncer is particularly useful:

  • tightly coupled with an IPv4 application, in order to allow that application to interact with an IPv6 server
  • tightly coupled with an IPv4 server, in order to permit queries from the outside IPv6 world to the old server
  • coupled with both application and server, in order to allow a connection to be routed through a network using a different technology (for example two IPv6 applications that are talking through an IPv4-only network)
  • somewhere into the network, such as a proxy server, in order to translate data from IPv4 to IPv6 and vice versa


As an example, let's take into account the second case (IPv4 server). This is a common problem since a lot of v4 applications still needs to be ported to the v6 domain. For example, a Microsoft IIS (Internet Information Server) Web Server exists only in the IPv4 domain. How to make it ready for IPv6 clients? 46Bouncer can be launched on the same machine that hosts the web server, waiting for IPv6 connections on port 80. Then, IPv6 connections will be directed to localhost - port 80 in the IPv4 domain. The server will appear able to process IPv6 queries.

In the author's belief, the second scenario is the one in which 46Bouncer is the most appropriate. Several other tools exist to translate IPv4/IPv6 streams; however 46Bouncer is very simple and it does enable an IPv4 server to become IPv6-aware without pain.

Like any other proxy, also 46Bouncer as to be addressed explicitly. If a proxy server A.COM acts as a proxy toward the web server B.COM, the end-user will have to type in order con retrieve the content of the B.COM web server. In other words, 46Bouncer will appear such as the real web server. For this reason the fourth configuration, although possible, is discouraged: that configuration forces end-user to know the location of the proxy and type that address instead of the one of the web server.



"Proxy" behaviour

46Bouncer does not parse the content of TCP/UDP packets. It just waits for data on a specified port, then it forwards the same data to the server. Let's imagine a web server, waiting on port 80. A 46Bouncer server ( waiting at port 8000 will accept a connection requiring the document

Why is the 46Bouncer waiting on port 8000? Just because this example requires it; in general all ports are valid choices and a single 46Bouncer can act as a "proxy" for multiple web servers (so it requires binding on several ports).

Since the server foo does not have a document called "bar", it will send back a redirect message suggesting to try the same address ending with a "/" character. However, the web server does not know that 46Bouncer is waiting for connections on port 8000, so the HTTP redirect message is wrong: the client will try to contact the server on the standard port (, while the bouncer is waiting on port 8000.

The problem is due all the times an application inserts lower level parameters into the byte stream (such as the TCP port into the HTTP packet). For instance, this can be a problem for web servers that hosts several virtual sites and that use a single IP address. The http server detect which is the page required by the user (for example instead of thanks to the site name, contained into the http message. In these cases 46Bouncer will fail.

A trace showing this phenomena is available here in the libpcap format (you can use tcpdump, WinDump, Analyzer, WireShark and more to show the packets).

Packets boundaries


This is a problem that may happen on UDP packets: since the IPv6 header is 20 bytes bigger than IPv4, a maximum size (MTU) IPv4 packet does not fit into an IPv6 packet. In that case 46Bouncer uses IP fragmentation, but the final result cannot be the one's expected (depending on the application).




46Bouncer does not have many requirements, because it needs just a machine with the IPv6 stack installed.

Currently supported platforms are:

  • Windows 2000 or Windows XP with the IPv6 stack installed
  • FreeBSD 4.3+
  • Linux (2.4 kernel)

Probably 46Bouncer will work on other UNIX platforms; we didn't test it.


Release Notes


Version 3.0, 18 Sep 01

  • Bug fixing
  • Cross platform
  • It runs as a 'service' in Win32 and as a 'daemon' in UNIX
  • 'Logging on file' capabilities


Version 2.0b, 10 Sep 01

  • Bug fixing
    • UDP traffic now should work
    • Thread management


Version 2.0alpha, 15 Aug 01

  • Support for UDP traffic (not well tested)
  • Support for multiple instances (i.e. multiple bouncer processes) within the same program
  • Improved support for loading/saving configuration files
  • 46Bouncer exists also as a Win32 Service


Version 1.0alpha, 15 Jul 01

  • TCP traffic supported
  • Not much more


Known Bugs

A lot, since 46Bouncer is still in an experimental stage. Briefly:

  • Optimizations: the code is not really optimized; for example a new thread is created as soon as a new connection arrives (while a pool of waiting threads will be more efficient)
  • Detection of old connections:
    • TCP connections are much simpler; currently 46Bouncer scans all the existing thread to determine the presence of dead connections each time a new connection is accepted. Clearly, during this time the system could be busy instead of forwarding packets.
    • UDP connections are a bit more tricky. Currently, if a UDP connection is no longer transmitting from more than 3 minutes, it is probably a dead connection; the system checks for zombies each time a packet multiple of 500 hundred is received. Both methods (TCP and UDP) are not really efficient; a further "cleaning" thread will be much better.
  • Testing: not very extensive, especially on UDP flows.
  • Interface selection: currently not implemented on GUI; however it works if configured via the configuration file

I'll appreciate any bug report, but I'll be much more grateful if you send me the patch as well (since I provide you source code...).



You can download the current 46Bouncer version here. You can find the Win32 executables and the complete source code. UNIX executables are not provided (you have to compile sources).

You can find also older versions (version 1.0, version 2.0, version 2.0b).


To Compile Sources

Sources have been compiled with Microsoft Visual C++ 6.0 in Win32 and the standard gcc in UNIX. Standard project files and makefile are provided for both the environments.

46Bouncer uses an external library, Clib, developed at Politecnico di Torino. This library defines some classes in order to make them system-independent. So, before compiling 46Bouncer you have to compile Clib. Clib sources are inserted into the 46Bouncer source tree. 



Copyright (c) 2001

Fulvio Risso (fulvio.risso[at], Netgroup, Politecnico di Torino. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that:

(1) source code distributions retain the above copyright notice and this paragraph in its entirety,

(2) distributions including binary code include the above copyright notice and this paragraph in its entirety in the documentation or other materials provided with the distribution, and

(3) all advertising materials mentioning features or use of this software display the following acknowledgement:
"This product includes software developed by the Politecnico di Torino, and its contributors."
Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.



For further information...

...please contact Fulvio Risso at Politecnico di Torino (Italy), fulvio.risso[at]

Document Actions