README for Android-6bed4 ======================== This is an implementation of the 6bed4 tunnel on Android. There is a possibility to set a client side port. This is useful for server applications, but after a crash it may take up to a minute for the port to be free again. Use it for server mode operation, to keep the IPv6 address as constant as the IPv4 address and NAT mapping; do not use it for client-only operations. I am shocked; the file descriptors created by the VPN are non-blocking, making it impossible to wait for its I/O. Furthermore, I found no way to use the select() call as I would have (and actually did) in C. As a result, the tunnel must poll for traffic :'-( So if I missed a Java trick here, *please* let me know. It will greatly help in speeding up the tunnel *and* make it less of a battery suckling. Version 0.5.2 introduces a lot of new code, so don't run your lifeline over it, okay? It adds an initial GUI with toggles (default route does not work yet, and autostart after boot is a shamble too) but the IP and UDP settings do work. If you change a lot quickly in a sequence, someone might get upset. Also, this is a first stab at the TCP bypassing system. Version 0.5 introduces Neighbor Solicitation and Neighbor Advertisement messages to try and pass through NAT and firewall layers, as per draft v01. This means that peer-to-peer connectivity is usually possible; the only ones excepted are those who are behind symmetric NAT; such people should get a decent ISP/router anyway! Version 0.4 is the first with dynamic addresses on the local end. There is no longer a need to specify the external IPv4 address and UDP port, which was there for testing purposes of early versions anyway. This release is a candidate implementation that is basically v00-ish -- it sends RouterSol and gets RouterAdv from the public server, and processes it in the v01 way. It will however not do the new v01 features of Neighbor Discovery for direct peer links. Version 0.3.1 fixes a small problem, namely that the 6bed4 application could not go away because it was too tightly coupled to the tunnel. The application and (background) VpnService are now split. In other words, it is now worth a try to access IPv6 websites. Version 0.3 actually passes information between the tunnel and its usage base, albeit from the assumptions that the IPv4 address is fixed and (not wholy reliable without port mapping and an explicit UDP port)that the external UDP port is the same as the internal one. You need to create a Java source file for that, as described in the header of the TunnelService.java file. Don't be afraid you might forget it though, your compiler will remind you :) Version 0.2 which already had better locations for the various pieces of code that create the tunnel. This makes it work on the first run as well, rather than just on the second run like v0.1 did. Otherwise, it is the same as 0.1 and so not really functional. But the basic user interaction on the VPN is functional and reliable. At best, it claims the VPN for tunneling, pulls in all IPv6 traffic and drops it on the floor ;-) so the only thing that can currently be checked is that the tunnel disables IPv6 without harming IPv4. If you have native IPv6 you will notice that IPv6 stops working. Future versions might be even more useful: 0.1 :- VPN claimed, IPv6 routed by IPv4 is not 0.2 :- VPN properly claimed, also on 1st start 0.3 :- Tunnel IPv6 from *fixed* IPv4 address 0.4 :- Use RtrSol/RtrAdv for autoconfig (v00) 0.5 :- Use NgbSol/NgbAdv for generic peering (v01) 0.6 :- Use TCP SYN/ACK for optimistic peering (v02) 0.7 :- ??? Redirect native through 6bed4 (v02?) 1.0 :- Add artwork and a spiffy webpage Cheers, -Rick