This section describes how the package IPv6 can be used to connect your home network to the IPv6 Internet by using a tunnel from the provider SixXS (https://www.sixxs.net/).
First, apply for a SixXS account under ``Signup for new users''. After that you have a user name in the form YYYYY-Sixxs and an associated password. This data is needed later for the tunnel configuration.
At first you have to apply for the tunnel. This happens after registration via the menu item ``request tunnel''. It is important to select ``Dynamic IPv4 Endpoint using Heartbeat protocol'' as the type of the tunnel in the second entry because this configuration is supported directly by the fli4l. The third variant ``Static IPv4 Endpoint'' is also possible if you own a dedicated IPv4 address that never changes. The tunnel variant ``Dynamic NAT traversing IPv4 endpoint is using AYIYA'' currently is not supported by the IPv6 package.
Once you've filled in the details for the location of the router into the other fields the next step is going to the second page via ``changed''. Here one or multiple PoPs (Points of Presence) have to be chosen. They are important for the tunnel construction later. You should take the one which is closest to you in order to make tunneling of IPv6 packets as efficiently as possible.
If all details are filled in and sent via ``Place request for new tunnel'' you will receive an e-mail with the necessary tunnel data. This includes:
Now the tunnel can be configured! First, the variable IPV6_TUNNEL_N has to be set to ``1'' because exactly one tunnel should be built:
IPV6_TUNNEL_N='1'
The details SixXS provided have to be filled in the IPv6 configuration as follows:
In addition the username and password have to be specified in the tunnel
configuration in variables IPV6_TUNNEL_1_USERID and IPV6_TUNNEL_1_PASSWORD.
Finally set the variable IPV6_TUNNEL_1_TYPE to reflect that
the configured tunnel is a SixXS tunnel:
IPV6_TUNNEL_1_TYPE='sixxs'
Example:
If you got the PoP ``deham01'' with the IPv4-address 212.224.0.188
and tunnel end points 2001:db8:900:551::1/64
(remote) and
2001:db8:900:551::2/64
(local) from SixXS, the tunnel-ID is ``T1234'', the
username ``USER1-SIXXS'' and the password ``sixxs'' (do not use this password!)
then the resulting configuration will look like this:
IPV6_TUNNEL_N='1' IPV6_TUNNEL_1_LOCALV4='dynamic' # or fixed local IPv4-address IPV6_TUNNEL_1_REMOTEV4='212.224.0.188' IPV6_TUNNEL_1_LOCALV6='2001:db8:900:551::2/64' IPV6_TUNNEL_1_REMOTEV6='2001:db8:900:551::1' IPV6_TUNNEL_1_TYPE='sixxs' IPV6_TUNNEL_1_USERID='USER1-SIXXS' IPV6_TUNNEL_1_PASSWORD='sixxs' IPV6_TUNNEL_1_TUNNELID='T1234'
If you accomplished this then update and restart the fli4l. After logging in to the router (directly or e.g. via SSH) you should already be able to ping the tunnel endpoint. With the example data above this will look as follows:
garm 3.6.0-revXXXXX # ping -c 4 2001:db8:900:551:0:0:0:1 PING 2001:db8:900:551::1 (2001:db8:900:551::1): 56 data bytes 64 bytes from 2001:db8:900:551::1: seq=0 ttl=64 time=67.646 ms 64 bytes from 2001:db8:900:551::1: seq=1 ttl=64 time=72.001 ms 64 bytes from 2001:db8:900:551::1: seq=2 ttl=64 time=70.082 ms 64 bytes from 2001:db8:900:551::1: seq=3 ttl=64 time=67.996 ms --- 2001:db8:900:551::1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 67.646/69.431/72.001 ms
Important is the part with the ``0 % packet loss''. This means that response packets have been received for all PING packets. If you get no response from the other end of the tunnel, the result is different:
garm 3.6.0-revXXXXX # ping -c 4 2001:db8:900:551:0:0:0:1 PING 2001:db8:900:551::1 (2001:db8:900:551::1): 56 data bytes --- 2001:db8:900:551::1 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss
You may notice that not for a single ping a response packet was received (``100% packet loss''). This either means that the configuration is incorrect or that the tunnel has not been established fully by SixXS yet. In the second case you should wait for some time because the configuration on the PoPs may last a few hours. If you double-checked the configuration and discovered no mistakes, and some time has elapsed without the tunnel working, you should contact SixXS by e-mail and describe the problem in detail.
If the tunnel is working you made the first major step. But you have not yet finished. For now only the router has the ability to send and receive packets to and from the IPv6 internet. But the hosts in the local net can't do this by now. An IPv6 subnet has to be configured to which the local hosts are bound.
Here a small but significant difference to the configuration of an IPv4 network
is to be noticed: Because of the address shortage usually only one host is connected
directly to the internet. The other hosts on the local network receive only
internal network IP addresses that are not routed to the outside. These are
in the ranges 192.168.*.*
, 172.16.*.*
to 172.31.*.*
,
and 10.*.*.*
, depending on the size of the subnet.
A.1
With IPv6 we get far enough IP addresses thus eliminating the need to use internal network addresses. Due to the global nature of local subnets it must be assured that the addresses of local hosts do not collide with other addresses on the Internet. Therefore a subnet of the IPv6 Provider has to be allocated in order to avoid such collisions.
SixXS does this with the menu item ``Request subnet''. Here you mainly have to specify the tunnel to be used. This is easy because only one tunnel has been configured so far. After submitting the form via ``Place request for new subnet'' you will, after some time, obtain the following information by e-mail:
This data is sufficient for configuring an own IPv6 subnet with fli4l.
One more thing must be known: The assigned subnet is usually very large.
SixXS usually allocates /48-subnets, i.e. within the 128-bit IPv6 address
the proportion of the network prefix is 48 bits and the proportion that
is available for addressing of hosts is 128 - 48 = 80 bits. Such a large
subnet has two major drawbacks. The first disadvantage is the sheer size:
this network can address
280 1209 trillion hosts. It
appears inadvisable to use this without structuring the host portion of
the address. The second drawback is more serious: within such a large
subnet the so-called IPv6-autoconfiguration does not work. This
is a process in which the IPv6 host receives the subnet prefix on defined
protocols and derives its IPv6 address from the MAC address of its network
adapter. The MAC address consists of six bytes. Using the standard EUI-64
you can stretch it to eight bytes. This corresponds to 64 bits in the end.
For 80-bit simply not enough information is available on the host.
Long story short: The subnet must be made smaller. It has to become a /64
subnet for auto-configuration to work properly. But that's easy: the subnet mask
has to be changed to /64. If SixXS e.g. assigned the subnet 2001:db8:123::/48
then the subnet for fli4l is just set to 2001:db8:123::/64
. In detail
this means that the /48 subnet is divided in
2(64-48) = 216 = 65536
sub-subnets. The first with the number zero is to be used with fli4l. You have to
remember that the short form 2001:db8:123::
really represents the long
address 2001:db8:123:0:0:0:0:0
. The first three numbers are the IPv6
provider's globally unique part of the subnet, the fourth number represents
the selected sub-subnet ``zero'',A.3
and the last four numbers are reserved for the host portion. This still gives a
huge (sub-) subnet where up to
264 18, 4 trillion hosts can be
accommodated. Thanks to the IPv6 autoconfiguration you will not have to bother
about the actual addresses. And that's good ...
Back to the configuration! At first the variable IPV6_NET_N is set to ``1'' because exactly one local IPv6 subnet has to be established. The IPv6 address of the /64 subnet including the subnet mask goes to the variable IPV6_NET_1. But that's not completely right: here the IPv6 address of the router within that subnet is to be set, but without the subnet prefix that is associated with the tunnel. In fact this is configured somewhere else: in the tunnel configuration. There the variable IPV6_TUNNEL_1_PREFIX has to be set to the requested subnet prefix.
Example:
Having received the /48er-IPv6-subnet 2001:db8:123::/48
from SixXS,
chosen it's subnet with the number `456' to be used as a /64 sub-subnet
and finally determined that the router within that subnet should get the
address of ``1'', we get the following configuration:
IPV6_NET_N='1' IPV6_NET_1='0:0:0:456::1/64' # IPv6-address of the routers (without # subnet-prefix) + subnet mask IPV6_TUNNEL_1_PREFIX='2001:db8:123::/48' # /48-subnet-prefix
It should be noted that the first three zeros in IPV6_NET_1 hold the
place for the /48-subnet-prefix associated with the tunnel. Together
with the /48 subnet prefix assigned by the tunnel provider this results
in the /64-Subnetz 2001:db8:123:456::/64
and the IPv6 router address
2001:db8:123:456::1
.
Now we need the name of the network interface to which this subnet has to be bound. Each subnet is bound to exactly one network interface. If only one configured network card is present in the router the name of the network interface is typically ``eth0'' for wired or ``wlan0'' for wireless adapters. If in doubt have a look at IP_NET_1_DEV (``IP'' without ``6'') and copy the content:
IPV6_NET_1_DEV='eth0' # Network interface for this IPv6-subnet
Finally we just need to let IPv6 autoconfiguration do the rest:
IPV6_NET_1_ADVERTISE='yes' # /64-subnet-prefixaund default-route per RA IPV6_NET_1_ADVERTISE_DNS='yes' # DNS-server per RA (needs # DNS_SUPPORT_IPV6='yes'!) IPV6_NET_1_DHCP='yes' # Domain-name and DNS-server per DHCPv6 # (needs DNS_SUPPORT_IPV6='yes')
The last two settings are not absolutely necessary for a working IPv6 subnet but are very helpful. They serve to spread additional information on the IPv6 subnet, i.e. IPv6 address of the DNS server and the domain used. The DNS server even may be published in two ways. Because different systems have different preferences it is of advantage to activate both methods (RDNSS via router advertisements and DHCPv6).
The whole IPv6-configuration of this example (DNS_SUPPORT_IPV6='yes'
is assumed!) looks like this:
IPV6_NET_N='1' IPV6_NET_1='0:0:0:456::1/64' # IPv6-address of the routers (without # Subnet-prefix) + subnet mask IPV6_NET_1_DEV='eth0' # network interface for this IPv6-subnet IPV6_NET_1_ADVERTISE='yes' # /64-subnetz-prefix and default-route per RA IPV6_NET_1_ADVERTISE_DNS='yes' # DNS-server per RA IPV6_NET_1_DHCP='yes' # Domain-name and DNS-server per DHCPv6 IPV6_TUNNEL_N='1' IPV6_TUNNEL_1_PREFIX='2001:db8:123::/48' # /48-subnet mask IPV6_TUNNEL_1_LOCALV4='dynamic' # or fixed local IPv4-address IPV6_TUNNEL_1_REMOTEV4='212.224.0.188' IPV6_TUNNEL_1_LOCALV6='2001:db8:900:551::2/64' IPV6_TUNNEL_1_REMOTEV6='2001:db8:900:551::1' IPV6_TUNNEL_1_TYPE='sixxs' IPV6_TUNNEL_1_USERID='USER1-SIXXS' IPV6_TUNNEL_1_PASSWORD='sixxs' IPV6_TUNNEL_1_TUNNELID='T1234'
With a fli4l like this a normally configured Windows 7 host should automatically configure its IPv6 address, default route, DNS server and domain and thus make the computer IPv6 capable. This can be verified e.g. with a simple PING from the Windows host to the IPv6 internet. In the following example we try to reach the fli4l.de webserver from the Windows PC (we directly use the IPv6 address here to avoid assumption of correct DNS functionality):
C:\>ping 2001:bf0:c000:a::2:132 Ping executed for 2001:bf0:c000:a::2:132 with 32 bytes data: Answer from 2001:bf0:c000:a::2:132: time=104ms Answer from 2001:bf0:c000:a::2:132: time=102ms Answer from 2001:bf0:c000:a::2:132: time=106ms Answer from 2001:bf0:c000:a::2:132: time=106ms Ping-Statistics for 2001:bf0:c000:a::2:132: Packets: Sent = 4, Received = 4, lost = 0 (0% lost), time in millisecs.: Minimum = 102ms, Maximum = 106ms, Average = 104ms
Yo can try to use the tool ``traceroute'' (in Windows: ``tracert'') in order to examine whether a packet is routed correctly. An example from the local network of the author is found below. This allows to notice that a packet first reaches fli4l (first line), then the other end of the tunnel (second row) and finally the global IPv6 internet (from the third line):
C:\>tracert 2001:bf0:c000:a::2:132 Route tracing to virtualhost.in-berlin.de [2001:bf0:c000:a::2:132] on a maximum of 30 hops: 1 <1 ms <1 ms <1 ms garm.example.org [2001:db8:13da:1::1] 2 70 ms 79 ms 71 ms gw-1362.ham-01.de.sixxs.net [2001:db8:900:551::1] 3 67 ms 71 ms 76 ms 2001:db8:800:1003::209:55 4 68 ms * 70 ms 2001:db8:1:0:87:86:71:240 5 69 ms * 71 ms 2001:db8:1:0:87:86:77:67 6 72 ms * 71 ms 2001:db8:1:0:86:87:77:81 7 71 ms * 71 ms 2001:db8:1:0:87:86:77:83 8 90 ms * 81 ms 2001:db8:1:0:87:86:77:62 9 84 ms * 88 ms 2001:db8:1:0:87:86:77:71 10 99 ms 83 ms 83 ms 2001:db8:1:0:87:86:77:249 11 94 ms 87 ms 87 ms 20gigabitethernet4-3.core1.fra1.he.net [2001:7f8::1b1b:0:1] 12 96 ms 99 ms 99 ms 10gigabitethernet1-4.core1.ams1.he.net [2001:470:0:47::1] 13 105 ms 108 ms 107 ms 2001:7f8:8:5:0:73e6:0:1 14 106 ms 107 ms 104 ms virtualhost.in-berlin.de [2001:bf0:c000:a::2:132] Tracing ended.