The 6to4 Tunneling Protocol
The 6to4 protocol
provides for automatic address assignment and tunneling of IPv6 across
the IPv4 Internet. The protocol is detailed in IETF RFC3056. The 6to4
protocol uses the prefix 2002::/16—otherwise known as a 6to4 address.
The global address prefix
for a given organization takes the form 2002:WWXX:YYZZ::/48, where
WWXX:YYZZ is the colon hexadecimal format of the organization’s public
IPv4 dotted decimal address w.x.y.z assigned to the router.
Note
The 6to4 protocol only
supports IPv6 computer to IPv6 computer communications. It does not
support communications between IPv6 and IPv4 computers. Both endpoints
must support IPv6.
The 6to4 protocol
allows organizations to assign globally routable IPv6 address without
needing to connect to the IPv6 Internet or to request an assigned range
of IPv6 addresses. Because the IPv6 address is derived from the public
assigned IPv4 address, it is guaranteed to be unique.
In addition, the 6to4 address
supports a subnet field for organizations with IPv4 subnet address
ranges. The format of the 6to4 IPv6 address is shown in Figure 6.
For example, the public IPv4 address 12.155.166.101 with subnet
255.255.255.128 would automatically generate the global IPv6 prefix
2002:C9B:A665:80::/64.
Table 3 lists some example values for IP address conversions in 6to4.
Table 3. Example 6to4 IP Address Conversions
| IPv4 Address | IPv6 6to4 Address |
|---|
| 12.155.166.101 | 2002:C9B:A665:1:: C9B:A665 |
| 65.55.12.249 | 2002:4137:CF9:1: :4137:CF9 |
| 144.48.9.14 | 2002:9030:90E:1::9030:90E |
The 6to4 protocol defines several components that participate in the transmission of packets. These are as follows:
6to4 host— A IPv6 device that is configured with a 6to4 address (that is, a 2002::/16 prefix).
6to4 router— Routes IPv6 traffic over the IPv4 Internet using 6to4 tunneling.
6to4 host/router—
An IPv6 device that is configured with a 6to4 address and can also use
6to4 tunneling to communicate with other 6to4 devices over the IPv4
Internet. However, it does not route traffic to other devices.
6to4 relay— Forwards 6to4 traffic between the IPv4 Internet and pure IPv6 devices.
Essentially, 6to4 and its components allow IPv6 devices to communicate while residing in the IPv4 world. Figure 7 shows the components of 6to4.
Windows Server 2008 R2,
Windows 2008, Windows 7, and Windows Vista can function as a 6to4
host/router or a 6to4 router. By default, these operating systems
operate as 6to4 host/router components. The Windows IPv6 protocol
automatically does the following if there is a public IPv4 address
assigned to a network interface:
1. | Creates
a 6to4 tunnel adapter and assigns it a 6to4 address in the form
2002:WWXX:YYZZ::WWXX:YYZZ for each of the public addresses.
|
2. | Creates a 2002::/16 route to forward all 6to4 addresses to the tunnel adapter.
|
3. | Does a lookup of the FQDN 6to4.ipv6.microsoft.com will give a 6to4 relay address. That address is set as the next hop for the 6to4 tunnel adapter.
|
Note
The FQDN 6to4.ipv6.microsoft.com
is the address of the 6to4 relay that is operated by Microsoft and
allows 6to4 access to the IPv6 Internet. This is a service that
Microsoft provides to help with the integration of Microsoft operating
systems with IPv6.
To have a system operate
as a 6to4 router component, the Internet Connection Sharing (ICS)
feature must be enabled. If ICS is enabled on network interface with an
IPv4 address, the IPv6 protocol automatically does the following:
1. | Enables IPv6 forwarding on the 6to4 tunneling adapter and on any private network interfaces.
|
2. | Assigns
a 6to4 subnet prefix of the form 2002:WWXX:YYZZ:I::/64, where WWXX:YYZZ
is the colon hexadecimal form of the IPv4 public IP address and I is
the interface index of the private network interface.
|
3. | Sends router advertisements on the private network interface.
|
For any traffic forwarded to other 6to4 sites, the Windows 6to4 router uses the default 2002::/16 route.
The Teredo Tunneling Protocol
The Teredo tunneling
protocol is a protocol that provides IPv6 connectivity through Network
Address Translation (NAT) devices that are not IPv6 aware. The Teredo
tunneling protocol is described in IETF RFC4380. The Teredo protocol
gets around the requirement of the 6to4 tunneling protocol that the
tunnel endpoint be a public IPv4 address. The reality of today’s IPv4
Internet is that there is a scarcity of public IPv4 address (the entire
rational behind IPv6) and so most hosts will be behind a NAT device.
Note
Perhaps less than
fortuitously, the Teredo protocol is named after the shipworm “Teredo
navalis,” which tunneled through the hulls of wooden ships and sank many
a vessel back in the day. These marine mollusks continue to be a threat
today to any wood structure in seawater, like dikes, docks, and piers.
The Teredo protocol tunnels through NAT firewalls in much the same
fashion. The Teredo protocol was initially named the “Shipworm”
protocol, but that made it seem too much like malicious software, and it
was renamed to Teredo.
Teredo encapsulates the IPv6
packets twice: once to encapsulate the IPv6 packet in an IPv4 packet
with the IPv4 protocol field set to 41, and a second time to put the
resulting IPv4 packet in the message of a IPv4 UDP packet. This double
encapsulation gets through the NAT but comes at a heavy cost in protocol
overhead. In addition, the Teredo tunnel also exposes the host to
scanning attacks because the Teredo tunneling adapter in effect opens a
port on the host to entities through the firewall. This port can be
discovered and attacked. Thus, due to the overhead and security
concerns, the Teredo tunneling protocol is really a tunneling protocol
of last resort.
Microsoft’s
implementation of the Teredo protocol includes additional measures
against IPv6 scanning attacks, including an option of which traffic to
accept: from anywhere except the Teredo tunnel (the default), from
anywhere including the Teredo tunnel, or only from the local Intranet.
The default option prevents scanning of the Teredo tunnel interface. Of
course, the host can initiate traffic through the tunnel.
Teredo clients use IPv6
addresses that start with the prefix 2001::/32, otherwise known as the
Teredo prefix. The address is somewhat more complicated than the
addressing for the other tunneling protocols. The elements of the Teredo
address are the following:
Teredo prefix (32 bits)— This is 2001 for all Teredo addresses, per IETF RFC4380.
Teredo server IPv4 address (32 bits)— The IPv4 address of the Teredo Server in colon hexadecimal format.
Flags (16 bits)—
This includes a bit for the type of NAT. Microsoft uses two of the bits
to set the Universal/Local flag and the Individual/Group flag for the
enhanced security. The remaining bits are set to a random number to make
scanning attacks more difficult.
Obscured external port (16 bits)— This is the external UDP port that is assigned by the NAT, but is obscured by an XOR it with FFFF.
Obscured external address (32 bits)— This is the IPv4 external address of the NAT, but it is obscured by an XOR with FFFFFFFF.
Figure shows the structure of a Teredo address.
Because of the flag
randomization, UDP port assignment, and the obscuring, the final Teredo
addresses will vary considerably even within the same Teredo client.
Teredo tunneling components include the following:
Teredo client—
This is an IPv6/IPv4 device that has a Teredo tunneling adapter and
communicates with other Teredo clients or IPv6 networks via a Teredo
Relay. The Teredo client is typically behind a NAT.
Teredo server—
This is an IPv6/IPv4 device that is connected to both the IPv6 and IPv4
networks. The Teredo server assists with the configuration of Teredo
clients.
Teredo relay—
This is an IPv6/IPv4 device that is connected to IPv6 and IPv4
networks. The Teredo relay routes between Teredo clients and IPv6 hosts
in the IPv6 network.
Teredo host-specific relay—
This is an IPv6/IPv4 device that is connected to IPv6 and IPv4
networks. It can communicate with the IPv6 network, the IPv4 network,
and Teredo clients without a Teredo relay.
Figure 9 shows the components of Teredo.
Windows Server 2008 R2,
Windows Server 2008, Windows 7, and Windows Vista can all operate as
Teredo clients and Teredo host-specific relays.
The Windows Teredo clients
send Router Solicitation messages to Teredo servers. These responses to
the router solicitation messages are used to build the Teredo address
and what type of NAT is in place.
Note
The command netsh interface ipv6 show teredo can be used to see how the Teredo client configured itself.
Once the Teredo address has
been determined, the Teredo client can then communicate with Teredo
clients. This is facilitated by the Teredo server, which brokers
communications between
the two Teredo clients during the initial start of communications.
Following the initial setup of communications, the two Teredo clients
communicate directly.
NAT-PT Devices
Internally, IPv6 devices can use
Network Address Translation-Protocol Translation (NAT-PT) devices,
which can be used to provide access to IPv4 resources. Resources that
don’t support IPv6 natively can be accessed through the use of a Network
Address Translation-Protocol Translation (NAT-PT) device. Microsoft
Windows Server 2008 R2 does not currently include that capability, so a
third-party device would be needed for this functionality.
Note
NAT-PT is covered in IETF RFC-2766 (http://tools.ietf.org/html/rfc2766), but was reclassified from a Proposed Standard to Historic due to issues with the standard. RFC4966 (http://tools.ietf.org/html/rfc4966)
contains the details of these issues. These include difficulty with
integrity mechanisms, inability to redirect protocols that lack
demultiplexing capabilities, premature state timeouts, loss of
information due to IPv4 and IPv6 header incompatibilities, packet
fragmentation issues, and an inability to handle multicast traffic.
NAT-PT devices are only recommended as a stop-gap measure due to these
issues.
As long as all Intranet resources that IPv6 clients need to reach support IPv6, then there should be no need for NAT-PT devices.
