By Daniele
Muscetta - daniele@muscetta.com
March, 21st 2005
I am no IPv6 expert, but I’ve
been fascinated by the idea of IPv6 for quite an amount of time now. There will
still pass a long time before we will use a native IPv6 Internet, but for the
time being there is already a lot of experimentation out there, and there’s
quite an amount of sites and services on the IPv6 Network already.
The IPv6 Internet runs in parallel as the
IPv4 one, with different points of contacts, such as gateways and routers.
The experimental IPv6 network is called the
6bone (http://www.6bone.net/).
You can even request your IPv6 network and
have it assigned.
This will be a valid routable IPv6
addressing, valid as long as the 6bone experimentation will stay up and running.
Of course buying *real* (native)
connectivity, even if is already possible in some countries, is still
expensive. Instead, most of the IPv6 connectivity these days is achieved
through tunneling of IPv6 INTO IPv4 packets.
These tunnels interconnect the various IPv6
islands over the public, dear old IPv4 Internet.
This tunnels use different technologies, but one of the most
common is the use of IPv4 protocol 41 (also called "Proto-41" in
short).
The
whole idea behind proto-41 is to encapsulate IPv6 into IPv4
packets.
But how do we set up such a tunnel if we
want to experiment with IPv6 out of the home-lab and onto the real world ?
To use a tunnel, we need to go to a tunnel
broker: a company that has native access to the 6bone, and has set up public
gateways that is used as tunnel endpoint. One such service (one of the easiest to use) is
www.freenet6.net
.
It provides with simple to setup, even
anonymous tunnels.
If you register for an account though, you
can make use of a more reliable tunnel endpoint than the anonymous one, and
even request a /48 or /64 block of addresses.
In our example we will use an already
set-up account at freenet6 to get a single IPv6 address.
In our test case we have a Windows XP SP2
machine BEHIND an ISA Server 2004.
We want to be
able to set up an IPv6 tunnel on the Windows XP
machine, so let it tunnel through the ISA server and get a public IPv6 address.
We could have other scenarios, including the one of having
the ISA server being the endpoint for the tunnel, and acting as a router.
This would be achievable even though ISA is
at this time v4 only, because the IPv6 stack, on the other end, has full routing
features built in. Thus a Windows machine is capable of being an IPv6
router.
Since the other setups are a bit trickier to get
right, we will explore those other possibilities in further
articles.For now we will get the basic functionality working.Please write me if you are interested in a follow up with
other methods/scenarios, and I'll see what I can do (in my spare time, which is not
much) to write those too.
First of all you need to enable/install
IPv6 on the WindowsXP machine.
This is accomplished by typing in a CMD
window the command
ipv6 install

After this operation the IPv6 stack will be
installed on the machine, you will be able to see it on the list of protocols
bound to the network interface, and you will automatically get link-local IPv6
addresses (starting with fe80::). These addresses
aren’t routable for on the public Internet, but are used for local
communications only (on a intranet which is not connected to anything); even if
not 100% correct, we can compare them to APIPA addresses (169.254.0.0/16) that
Windows automatically sets up when it doesn’t find a DHCP server.
This just wants to be a step-by-step
minimal guide, so we won’t go into further details.
If you want to understand more of the
theory, I suggest you to read the documents linked in the reference/biography
section at the end of this article.
The second things to do
is to install the freenet6 client (called the TSP Client).
There are pretty good instructions on how
to do this on the producer’s site.
It consists of installing an application,
and the TAP Tunnel Driver tunv6.sys.
Once installed, the driver will show up as
a new network connection:

(in this picture
we already RENAMED it from “Local Area Connection #2” to a more straightforward
name).
We find it appropriate to change the
bindings on this new interface.
In fact by default everything that’s bound
to the NIC gets also bound to the TUN adapter, but this is not what we want.
First of all, we will use this for IPv6, so
for INSIDE the tunnel we can disable IPv4; if we don’t, once the tunnel is
established, the machine will try to get an IPv4 address from DHCP, which won’t
work, and which is not necessary – it just wastes bandwidth.
Second, we don’t want to offer any sharing
of resources over this connection.
Even if we are behind the ISA, we will open
a Tunnel through it, letting our Windows XP client practically exposed to the
IPv6 internet.
Then the "endpoint" will
see/receive ALL IPv6 traffic inside the tunnel, it won't be able to filter it
per destination port, for example.
We will be exposing all IPv6 functionality
that can be exposed over protocol-41 as ISA has no understanding of the protocol.

So for this reason we want to harden the
connection.
Also for this reason, we use Windows XP
Service Pack 2 as a client. In fact, the built-in Windows Firewall of XP
Service Pack 2, for those who did not hear the great new, is IPv6 aware. And
NOT ONLY is it aware, it does more: it automatically enforces the same firewall
policy both to IPv4 and to IPv6 interface addresses.
Which means this way we will be able to
surf out, but we can adjust the firewall to block everything inbound over this
tunnel.
After having set up the tsp client, we
should edit its configuration file, tspc.conf (by
default is in the directory where the client is installed – c:\program
files\tsp-client). It is self-explanatory, well-commented, documented, and
there is a sample file.
If you want to use an anonymous tunnel you
can leave it with the default values.
But the anonymous tunnels are somehow not
reliable, and sometimes it is even difficult to connect since there are too
many users.
I highly suggest you to create an account
on freenet6. You can specify your username and your email, and you will be sent
the password to that email (a complex, 10-character password is generated).
When you got your username and the
password, you can change the following three things in tspc.conf:
the username, the password, and the server/tunnel endpoint to connect to:
userid
=
anonymous (insert username)
passwd
=p@sSw0rd (insert password)
comment
the line
server=
anon.freenet6.net
And uncomment
server=
broker.freenet6.net
Save the file, and at this point we have
completed the configuration of the tsp client.
We can open a CMD, go to the c:\program
files\tsp-client directory and type the command
tspc
–vvv
(-vvv uses the
maximum possible verbose logging to tell us how the thing is working or not
working).
Since we are behind the ISA, by default
this kind of traffic won’t be allowed, s we will get something like this:
C:\Program Files\tsp-client>tspc
-vvv
tspc
- Tunnel Setup Protocol Client v2.1.1
Initializing (use -h for help)
Connecting to server with reliable udp
Using TSP protocol version 2.0.0
Establishing connection with tunnel broker...
Getting capabilities from server
No RUDP reply
No RUDP reply
No RUDP reply
tspGetCapabilities
error 2: SOCKET_ERROR
if
you are using udp, there is probably no udp listener at broker.freenet6.net
Reliable udp connection
failed, fallback to tcp and V6V4
Connecting
to
server
with
tcp
Using
TSP protocol version
2.0.0
Establishing connection with tunnel broker...
Unable to establish connection with broker.freenet6.net
All transports failed, quitting
Error is 2: SOCKET_ERROR
TSP session done
Which is quite
self-explanatory.
Firewall is closed, it
can’t work.
There’s
only a couple of things we need to enable in ISA to let this tunnel
work:
First of all, we need to enable TCP port
3653 (check out http://www.hexago.com/index.php?pgID=41).
Just for clarity, we will say that this
port does NOT have anything at all to do with IPv6.
This is just the port where freenet6’s
tunnel broker’s webservice listens.
There’s nothing important or IPv6 specific
about this, it is just that they chose to run their webservice
on that port. But since we use that webservice, we
need to reach it.
I am using TCP in this example.
If you use UDP (useful for NAT Traversal,
see later on) the same port number has to be open for UDP instead.
With this one port open we will connect to
the Tunnel broker, we will get all the necessary parameters to establish the
tunnel, but the tunnel will then try to use a protocol that’s not allowed by
default through the firewall, and fail.
What we have to enable for this to work, is
our tunneling mechanism: as we already said, IPv6-over-IPv4 tunnels use IPv4
protocol number 41.
While on ISA2000 it wouldn’t have been
possible to configure this protocol, in ISA2004 this is now possible:


Depending
on how our access policy is, we might need to explicitly permit this protocol
from the internal client.
In case that we allow “All traffic” then it won’t be needed to add this protocol to the Access Rule, as it will be already included.
Keep
in mind the following when using this newly defined protocol:
ISA
Server supports RAW IP protocols (so new protocols defined only indicating the
protocol number, as
in the example above) but with some limitations.
The limitation with RAW IP protocols comes from the fact that ISA has no additional understanding of the protocol end points (like ports in TCP/UDP).
This leads to the fact that, when passing through NAT, only one client that is using a certain RAW IP protocol can get
to a specific server.
For
example:
Client1
à
NAT à
Server 10.0.0.1 over proto 41 ß
Success
Client2
à
NAT à
Server 10.0.0.1 over proto 41 ß
Duplicate
connection element error
So
now, keeping this in mind, and using only one client (our XP machine) we can try
our tunnel, and it should work:
C:\Program
Files\tsp-client>tspc -vvv
tspc
- Tunnel Setup Protocol Client v2.1.1
Initializing
(use -h for help)
Connecting
to server with reliable udp
Using
TSP protocol version 2.0.0
Establishing
connection with tunnel broker...
Getting
capabilities from server
Connection
established
Authenticating
username
Using
authentification mecanism
DIGEST-MD5
Authentication
success
Asking
for a tunnel
sent
: Content-length: 204
<tunnel
action="create" type="v6anyv4" proxy="no">
<client>
<address
type="ipv4">192.168.0.181</address>
<keepalive interval="30"><address
type="ipv6">::</address></keepalive> </client>
</tunnel>
recv
:
200 Success
<tunnel
action="info" type="v6udpv4"
lifetime="604800">
<server>
<address
type="ipv4">206.123.31.116</address>
<address
type="ipv6">2001:05c0:8fff:fffe:0000:0000:0000:1dc2</address>
</server>
<client>
<address
type="ipv4">63.91.192.213</address>
<address
type="ipv6">2001:05c0:8fff:fffe:0000:0000:0000:1dc3</address>
<address
type="ns">username.broker.freenet6.net</address>
<keepalive
interval="30">
<address
type="ipv6">2001:05c0:8fff:fffe:0000:0000:0000:1dc2</address>
</keepalive>
</client>
</tunnel>
Processing
response from server
sent
: Content-length: 35
<tunnel
action="accept"></tunnel>
Got
tunnel parameters from server, setting up local tunnel
keepalive
interval: 30
tspSetupInterface
beginning
TSP_TUNNEL_MODE=v6udpv4
TSP_HOST_TYPE=host
TSP_TUNNEL_INTERFACE=FreeNet6
Tunnel
TSP_HOME_INTERFACE=
TSP_CLIENT_ADDRESS_IPV4=63.91.192.213
TSP_CLIENT_ADDRESS_IPV6=2001:05c0:8fff:fffe:0000:0000:0000:1dc3
TSP_SERVER_ADDRESS_IPV4=206.123.31.116
TSP_SERVER_ADDRESS_IPV6=2001:05c0:8fff:fffe:0000:0000:0000:1dc2
TSP_TUNNEL_PREFIXLEN=128
TSP_VERBOSE=3
TSP_HOME_DIR=C:\Program Files\tsp-client
Executing
configuration script: "C:\Program Files\tsp-client\template\windows.bat"
04/03/2005
07:03
PM
Testing
IPv6 presence
Testing
Windows NT version
IPv4
tunnel server address configured : 206.123.31.116
Resetting
all the interfaces and routes
Ok.
Configuring
for V6UDPV4 (NAT traversal)
Ok.
Setting
MTU to 1280 on tunnel interface "FreeNet6 Tunnel"
Ok.
Ok.
Ok.
Success !
Now, you're ready to use
IPv6 connectivity to Internet IPv6
Your
host is configured to use this IPv6 address :
2001:05c0:8fff:fffe:0000:0000:0000:1dc3
End
of the script
Script
completed sucessfully
Your
IPv6 address is 2001:05c0:8fff:fffe:0000:0000:0000:1dc3
keepalive
initialized with 2001:05c0:8fff:fffe:0000:0000:0000:1dc2 as a peer, max KA
value of 30
You can see some of the checks (authentication, and the
passing of parameters from server to client) being basically performed over HTTP
(even if on port 3653) with the use of XML tags – this is a web service that is
used to configure the freenet6 client.After
authentication to this webservice, the tunnel will be up,
and the machine will have a globally routable IPv6 address.
You can now see the Tunnel interface being up:

You can now test your IPv6 connectivity
just using a browser and connecting to some site that you know being reachable
on the IPv6 Internet.
This
is now very easy, as most pieces of windows are now IPv6 aware.
This
wasn’t the case just a couple of years ago, but now it is.
So
just open Internet Explorer and surf to those sites.
If
you don’t know any site, I’ll tell you some of them.
To start off with, head on this other tunnel
broker’s test page:
IPv6 Calc (IPv6 connection revealer)
http://www.sixxs.net/tools/ipv6calc/
it
will tell you some details about
your connection, address, browser, etc.
Another funny place to visit is the home of
the BSD IPv6 stack: www.kame.net
This is funny, as there is an image of the
KAME turtle.
If you connect in IPv4 the image is static, like this:

While if you connect over IPv6, you’ll see
a “dancing” KAME:

(Note: it has always looked like being
rather more “swimming” than “dancing” to me, but that might be just my
perception…. After all I have never seen a dancing turtle anywhere else…:-)).
You
can also try http://ipv6.research.microsoft.com
There
are a lot more sites.
One
thing to note is that you will now seamlessly navigate on both the IPv4
internet (thorugh your normal NIC) and on the IPv6
one (through the tunnel) from the XP machine.
Enjoy!
When
you hit CTRL+C in the DOS box, the batch terminates and the tunnel goes down,
as you can see in the following screenshot:

NOTE: IPv6 behind a NAT (on FreeBSD)
http://ezine.daemonnews.org/200009/ipv6.html
I bumped into this article, while researching for
writing the one you're reading.
This
stuff is pretty much not an issue anymore these days – it was some
years ago, but now not anymore.
Or better, it can still be, if you use a NAT device which is not
quite modern.
Specifically I had a lot of issues with some cheap DSL routers which
are doing NAT, but that only support PORT MAPPING, as they could not really
understand PROTO-41.
This kind of devices is the same kind of thing that has problems
with IPSec, anyway.
For this need, pretty much like we have implemented Nat-Traversal
for IPSec over UDP in XP, there’s an option in freenet6’s configuration to
use “v6udpv4”:
[…]
On June
16th 2004, Freenet6 started to offer an innovative new feature called NAT
traversal, allowing people behind NAT devices to get IPv6
connectivity.
[…]
Everything here is "as is", my words only, not the official word of Microsoft, nothing here supported by PSS, etc. I am not affiliated in any way to freenet6 nor to any of the other organizations (6bone, kame, etc) mentioned here. I just tried their service and I found them good, that's why I use them. This is published on my PERSONAL site because this is a *personal* test / procedure - nothing here has been scrutinized, checked, corrected nor approved by anybody at Microsoft, and thus DOES NOT HAVE TO BE CONSIDERED OFFICIAL DOCUMENTATION for the product mentioned. It only represents the description of some of my TESTs and, since they worked for me, I wanted to share them.