Instead of manually configuring each tunnel endpoint it is possible to use executable scripts instead. This “automatic” alternative is called a “tunnel broker” and is presented in RFC 3053 [RFC3053].
Like manually configured tunnels, the tunnel broker is useful where a user has a dual-stack host in an IPv4-only network, and wishes to gain IPv6 connectivity. The basic philosophy of a tunnel broker is that it allows a user to connect to a web server, (optionally) enter some authentication details, and receive back a short script to run and establish an IPv6-in-IPv4 tunnel to the tunnel broker server.
The operation of a typical tunnel broker service is illustrated in Figure 5-1. The provider of a tunnel broker service needs to provide a web server available over IPv4 and a dual stack router capable of accepting automated setup commands to create new tunnels to client endpoints. It is possible that both functions can be served from one machine.
A tunnel broker can be implemented in many ways and is not constrained to IPv6-in-IPv4 tunnels. Layer 2 or GRE tunnels may be used as well. The requirement for the service is that it needs to keep track of the tunnels created and whom they belong to. Ideally it should have some authentication to grant access to the service, but in practice early implementations have not required this. The Freenet6 service (http://www.freenet6.net) is perhaps best known, but being based in Canada is not ideal for use in European networks (the first hop to any destination would be thousands of miles away). SixXS (http://www.sixxs.com) is another example more suitable and available in Europe; ideally any ISP should offer local tunnel broker facilities for its users, if no native IPv6 service is present.
Tunnel brokers can serve subnet tunnels, as well as single host tunnels. In the former case the host obtaining the tunnel is in reality a router, and the mechanism for obtaining the tunnel can be more generic (using for example TSP, the tunnel setup protocol [BP05]), and may need specific functions to activate or deactivate the tunnel.
The tunnel broker service is generally easy to use for the client, but there are some concerns about the deployment of server systems, e.g. in security of access, and in reallocation of tunnels where clients use dynamic IPv4 addresses (as is typical behind commodity dialup). If using standard IPv6-in-IPv4 tunnelling, any intervening firewall must pass Protocol 41 to/from the tunnel server. Doing so, and without further control of the tunnelled traffic, a site administrator may be blissfully unaware of users on their site who use tunnel brokers, thus not creating any site demand for “proper” IPv6 deployment and possibly creating security holes which the administrator does not know about and therefore does not guard against.
Some tunnel broker implementations will handle clients with dynamically changing IPv4 addresses or that are behind IPv4 NATs. Such features are often highly desirable. Heartbeat features are often used for the former problem, while [BP05] offers a solution for the latter, negotiating a UDP-based encapsulation method that can work through a NAT. Use of TSP will need the client to run a special client however.
A tunnel broker is an important transition aid; it enables easy-to-use IPv6 network access, and we see a number of supported brokers used in the 6NET environment during the project. The tunnel brokers may be deployed by sites (universities) or by NRENs (as not every university will wish to run its own broker). If no broker is available to a national participant, remote brokers may be used, but doing so will naturally reduce the efficiency of the tunnelling, since the first IPv6 hop for the client will be in the (distant) remote network, even if the target is relatively local.