Connecting to 6bone, with dynamic IPv4 address

Jun-ichiro itojun Hagino (Itoh), KAME Project
$Id: index.html,v 1.1 2001/04/17 03:42:19 itojun Exp $

Introduction

In the previous newsletter, we have described how you can connect to the world 6bone (worldwide IPv6 experimental network). However, the previous newsletter talks mostly about the case where you have fixed IPv4 global address. This time, we would like to talk about the cases wheree you have dynamic IPv4 address, usually assigned dynamically on IPv4 dialup ppp connection, from your ISP.

Dynamic IPv4 address and RFC1933 IPv6-over-IPv4 configured tunnel

RFC1933 describes IPv6-over-IPv4 configured tunnel, which is the most widely deployed mechanism to connect to the world 6bone. This uses IPv4 as underlying medium, and establish IPv6-over-IPv4 tunnel between two fixed IPv4 global address.

There are problems with RFC1933 tunnel, for commodity IPv4 users who use IPv4 dialup ppp connection:

There are several techniques to go around the first problem, and few techniques to go around the second problem. For the following sections, we first assume that you have IPv4 global address assigned to your IPv4/v6 dual stack box (which will become the tunnel endpoint and the IPv6 border router for your home). In the last section of the document we'll give some hint for NAT box users.

freenet6.net and tunnel broker

freenet6.net and CSELT provides a dynamic tunnel configuration service, by using IPv4-accessible webpage. When you sign up, they will assign you a fixed IPv6 subnet address to you. You can ask them (by using web interface) to establish a RFC1933 tunnel dynamically, to your current IPv4 global address.
your ISP
  |
  | phone line
  |
  | IPv4-global-address
dual stack box
  | 192.168.0.1
==+=======================+== 192.168.0.0/24
  | 192.168.0.2		  | 192.168.0.x
random other boxes	random other boxes
This works like this: Consult freenet6.net for more details.

Trumpet dynamic tunnel configuration protocol

KAME kit includes two programs, dtcps and dtcpc, in kit/src/dtcp. Installed programs will be placed in /usr/local/v6/sbin. This implements "Dynamic Tunnel Configuration Protocol", proposed by Trumpet. The protocol is described in this document. Those programs implement APOP-like authentication protocol for establishing RFC1933 tunnel between two end. If you can ask your 6bone upstream to provide dtcp server, you may be able to use this.

You'll first need to setup a password (shared secret) on the upstream so that you can authenticate yourself to the upstream. dtcps awaits IPv4 TCP connection from dtcpc, just like pop server awaits connection from mailers. When connection is made, dtcps will throw a challenge (random hexadecimal string). dtcpc asks you the password locally, and throw a response (keyed MD5 result from challenge and the password). dtcps throws the configuration parameter and RFC1933 tunnel will be established.

dual stack router	upstream
(dtcpc)			(dtcps)
	   --------------->
		IPv4 TCP connection
	   <---------------
		challenge
	   --------------->
		response
	   <---------------
		the configuration parameter
	   <-------------->
		tunnel established
Current implementation simply configures the tunnel between two end. To actually use this, global IPv6 address assignment has to be performed offline. Also, both end needs to perform routing information exchange.

dtcps and dtcpc are written in Ruby scripting language (with IPv6 modification), and Ruby needs to be installed beforehand. Please use kit/ports/ruby for easy installation. Manpages are available in KAME kit so consult these for details.


v6tun: IPv6 tunnel over ssh

For KAME/FreeBSD, you can use v6tun (in kit/ports/v6tun). This automates "IPv6 tunnel over ssh" configuration toward your 6bone upstream. This is not based on RFC1933, but it uses FreeBSD tun tunnelling device. In this case, you'll need an ssh login account on your 6bone upstream. Also, you'll need tun tunnelling device configured in your kernel.

When you use v6tun, v6tun will login to your upstream tunnel endpoint using ssh. Then, it will configure IPv6 tunnel over ssh link, like this.

dual stack router			upstream
	   ------------------------------->
		ssh login
	   <------------------------------>
		IPv6 tunnel over ssh

outgoing packet /dev/tun0 ---ssh---> /dev/tun0	
  v		  ^			v
tun0 device ------+		     kernel

Special configuration for NAT box

If you use NAT box to connect to your IPv4 ISP, your home network is something like this:
your ISP
  |
  | phone line
  |
  | IPv4-global-address
NAT router box
  | 192.168.0.1
==+=======================+== 192.168.0.0/24
  | 192.168.0.2		  | 192.168.0.x
dual stack box		random other nodes
Here, you would like to somehow hook the dual stack box (192.168.0.2) to the world 6bone, by using RFC1933 tunnel. Here are very few possibilities:
  1. Replace NAT box with dual stack box.
  2. Configure NAT box to statically route IP protocol type 41, to 192.168.0.2
The simplest solution is to dump NAT box, and make dual stack box perform both IPv4 NAT and IPv6 router. I recommend this because NAT box does too many tricky things we cannot even imagine. Recent PC UNIX families implement NAT in the kernel. KAME kit (for FreeBSD2.2.8 and BSDI3.1) also includes home-brew NAT code as well.
your ISP
  |
  | phone line
  |
  | IPv4-global-address
dual stack box
  | 192.168.0.1
==+=======================+== 192.168.0.0/24
  | 192.168.0.2		  | 192.168.0.x
			random other nodes
For IPv4, you'll be configuring dual stack box to perform NAT for network in your home (192.168.0.0/24). This is out of the scope of the document so please refer to OS-specific documents. You'll be configuring RFC1933 tunnel by using your dual stack box, and route IPv6 packet for the network in your home.

Next solution is to configure your NAT box to statically route IP packet with protocol number 41, to your dual stack box (192.168.0.2). RFC1933 tunnel uses protocol number 41. In this case, you will need other tricky configurations. This depends on your network configuration, your NAT box implementation, and your IPv6 upstream, so I cannot discuss this in a generic way.


For more information...

Please consult previous newsletter, www.ipv6.org, and www.freenet6.net for more details.