The Cable Guy - April 2003

IPv6 Features in the Advanced Networking Pack for Windows XP

By The Cable Guy

Windows Peer-to-Peer Networking is a developer platform that you can use to create peer-to-peer applications for computers running Windows XP. Windows Peer-to-Peer Networking is provided with Windows XP Service Pack 2 (SP2). For computers running Windows XP with Service Pack 1 (SP1), you can obtain and install the Advanced Networking Pack for Windows XP, a free download that provides the components to run Windows Peer-to-Peer Networking applications. For more information, see Windows Peer-to-Peer Networking.

The Windows Peer-to-Peer Networking platform runs exclusively over IPv6. The enhancements to IPv6 included in the Advanced Networking Pack for Windows XP include the following:

• IPv6 Internet Connection Firewall (ICF)

  Computers using Windows Peer-to-Peer Networking must be protected from malicious users that are using IPv6 traffic in the same way that ICF in Windows XP protects computers from malicious users that are using IPv4 traffic.

  Windows XP SP2 does not include IPv6 ICF. Instead, IPv6 ICF has been replaced with IPv6 support in the new Windows Firewall. For more information, see New Networking Features in Microsoft Windows XP Service Pack 2

• Teredo

  When connecting to the Internet, many computers running Windows XP are behind network address translators (NATs), which translate traffic between private and public IPv4 addresses. Teredo is a NAT traversal technology that provides unicast IPv6 connectivity across the IPv4 Internet.

  Windows XP SP2 supports Teredo in the same way as the Advanced Networking Pack for Windows XP.

On This Page

• IPv6 Internet Connection Firewall (ICF)
• Teredo
• For More Information

IPv6 Internet Connection Firewall (ICF)

A firewall provides security by creating a protective boundary between a computer or network and the Internet. You can use IPv6 ICF to dynamically set restrictions for traffic allowed from the Internet. IPv6 ICF is different than the existing ICF in Windows XP, which is used for IPv4 traffic. For more information about ICF for IPv4, see Windows XP online Help.

IPv6 Internet Connection Firewall (ICF):

• Runs automatically and provides filters for all network connections on which IPv6 is enabled.
• Monitors all outbound traffic and dynamically creates inbound packet filters for response traffic. This is known as stateful filtering. IPv6 ICF silently discards all unsolicited inbound traffic.
• Logs IPv6 traffic events to a separate log file (from IPv4 ICF). By default, this log file is located at SystemRoot\Pfirewall-v6.log).

IPv6 ICF protects your computer by silently dropping all packets that are initiated from a source outside the IPv6 ICF computer, such as the Internet. IPv6 ICF stops common attempts to illegally gain access to your computer or network by malicious Internet users using techniques such as port scanning. Instead of notifying you of inbound discarded traffic, IPv6 ICF creates entries in a security log from which you can view the activity that is tracked by the firewall.

IPv6 ICF is configured using commands in the netsh firewall context. You can use netsh commands to configure IPv6 ICF to allow specific types of ICMPv6 traffic or traffic to specific TCP or UDP ports. For more information, see To configure IPv6 Internet Connection Firewall.

Note Windows XP only shows the IPv4 ICF configuration in Network Connections. IPv6 ICF may appear disabled, but it is actually enabled and filtering IPv6 traffic.

Teredo

Teredo, also known as IPv4 NAT traversal for IPv6, is an IPv6/IPv4 transition technology. Teredo provides address assignment and host-to-host automatic tunneling for unicast IPv6 connectivity across the IPv4 Internet when IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs. To traverse IPv4 NATs, IPv6 packets are sent as IPv4-based User Datagram Protocol (UDP) messages. For more information about how network address translation works, see Windows 2000 Network Address Translator (NAT).

6to4 provides the same function as Teredo; however, 6to4 router support is required in the edge device that is connected to the Internet. 6to4 router functionality is not widely supported by IPv4 NATs. Even if the NAT were 6to4-enabled, 6to4 would still not work for configurations in which there are multiple NATs between a site and the Internet.

Note Windows XP with Internet Connection Sharing and the IPv6 protocol supports 6to4 router functionality.

Teredo resolves the issues of the lack of 6to4 functionality in modern-day NATs or multi-layered NAT configurations by tunneling IPv6 packets between the hosts within the sites. In contrast, 6to4 uses tunneling from the edge device. Tunneling from the hosts presents another issue for NATs: IPv4-encapsulated IPv6 packets are sent with the Protocol field in the IPv4 header set to 41. Most NATs only translate TCP or UDP traffic and must either be manually configured to translate other protocols or have an installed NAT editor that handles the translation. Because Protocol 41 translation is not a common feature of NATs, IPv4-encapsulated IPv6 traffic will not flow through typical NATs. Therefore, the IPv6 packet is encapsulated as an IPv4 UDP message, containing both IPv4 and UDP headers. UDP messages can be translated by most NATs and can traverse multiple layers of NATs.

It is important to note that Teredo is designed as a last resort transition technology for IPv6 connectivity. If native IPv6, 6to4, or Intrasite Automatic Tunnel Addressing Protocol (ISATAP) connectivity is present between communicating nodes, Teredo is not used. As more IPv4 NATs are upgraded to support 6to4 and IPv6 connectivity become ubiquitous, Teredo will be used less and less, until eventually it is not used at all.

For more information about IPv6 transition technologies, see IPv6 Transition Technologies.

Note Teredo works only over cone and restricted NATs. A cone NAT stores a mapping between an internal (private) address and port number and an external (public) address and port number. After the NAT translation table entry is in place, inbound traffic to the external address and port number is allowed from any source address and port number. A restricted NAT stores a mapping between an internal address and port number and an external address and port number, for either specific external addresses or specific external addresses and port numbers. An inbound packet that does not match a NAT translation table entry for both the external destination address and port number and a specific external address or port number is silently discarded. There is an additional type of NAT, known as a symmetric NAT, which maps the same internal address and port number to different external addresses and ports, depending on the external destination address (for outbound traffic). Teredo does not work over symmetric NATs.

Teredo host-specific relay

The set of components that enables Teredo connectivity is shown in the following figure.

• Teredo client

  An IPv6/IPv4 node that supports a Teredo tunneling interface through which packets are tunneled to either other Teredo clients or nodes on the IPv6 Internet (through a Teredo relay).

• Teredo server

  An IPv6/IPv4 node that is connected to both the IPv4 Internet and the IPv6 Internet. The role of the Teredo server is to assist in the initial configuration of Teredo clients and to facilitate the initial communication between either different Teredo clients or between Teredo clients and IPv6-only hosts.

• Teredo relay

  An IPv6/IPv4 router that can forward packets between Teredo clients on the IPv4 Internet and IPv6-only hosts.

• Teredo host-specific relay

  An IPv6/IPv4 node that has an interface and connectivity to both the IPv4 Internet and the IPv6 Internet and can communicate directly with Teredo clients over the IPv4 Internet, without the need for an intermediate Teredo relay. The connectivity to the IPv4 Internet can be through a public IPv4 address or through a private IPv4 address and a neighboring NAT. The connectivity to the IPv6 Internet can be through a direct connection to the IPv6 Internet or through an IPv6/IPv4 transition technology such as 6to4.

The Advanced Networking Pack for Windows XP includes Teredo client and Teredo host-specific relay functionality. When the Advanced Networking Pack for Windows XP is installed, the Teredo host-specific relay functionality is automatically enabled if a global IPv6 address has been assigned. A global address can be assigned from a Router Advertisement message that is received from a native IPv6 router, an ISATAP router, or a 6to4 router. If there is no global address configured, Teredo client functionality is enabled.

Teredo addresses

Teredo addresses have the format shown in the following figure.

A Teredo address consists of the following:

• Teredo prefix

  The first 32 bits are for the Teredo prefix, which is the same for all Teredo addresses. The Internet Assigned Numbers Authority (IANA) has not yet defined this prefix, although the prefix 3FFE:831F::/32 is used for initial deployment.

• Teredo server IPv4 address

  The next 32 bits contain the IPv4 public address of the Teredo server that assisted in the configuration of this Teredo address.

• Flags

  The next 16 bits are reserved for Teredo flags. The only defined flag is the high-order bit known as the Cone flag. The Cone flag is set when the NAT connected to the Internet is a cone NAT.

• Obscured external port

  The next 16 bits store an obscured version of the external UDP port that corresponds to all Teredo traffic for this Teredo client. When the Teredo client sends its initial packet to a Teredo server, the source UDP port of the packet is mapped by the NAT to a different, external UDP port. All Teredo traffic for the host uses the same external, mapped UDP port.

  The external port is obscured by exclusive ORing (XORing) the external port with 0xFFFF. For example, the obscured version of the external port 5000 in hexadecimal format is EC77 (5000 equals 0x1388, and 0x1388 XOR 0xFFFF equals 0xEC77). Obscuring the external port prevents NATs from translating it within the payload of the packets that are being forwarded.

• Obscured external address

  The last 32 bits store an obscured version of the external IPv4 address that corresponds to all Teredo traffic for this Teredo client. Just like the external port, when the Teredo client sends its initial packet to a Teredo server, the source IP address of the packet is mapped by the NAT to a different, external address.

  The external address is obscured by XORing the external address with 0xFFFFFFFF. For example, the obscured version of the public IPv4 address 131.107.0.1 in colon-hexadecimal format is 7C94:FFFE (131.107.0.1 equals 0x836B0001, and 0x836B0001 XOR 0xFFFFFFFF equals 0x7C94FFFE). Obscuring the external address prevents NATs from translating it within the payload of the packets that are being forwarded.

How Teredo works

For two computers running Windows Peer-to-Peer Networking, the most crucial Teredo processes are those used for initial configuration and communication with a peer in a different site.

Initial configuration

Initial configuration for Teredo clients is accomplished by sending a series of Router Solicitation messages to Teredo servers. The responses are used to derive a Teredo address and determine whether the client is behind a cone, restricted, or symmetric NAT. If the Teredo client is behind a symmetric NAT, then it cannot function. You can see what type of NAT the Teredo client has discovered from the display of the netsh interface ipv6 show teredo command.

Based on the received Router Advertisement messages, the Teredo client constructs its Teredo address from the following:

• The first 64 bits are set to the value included in the Prefix Information option of the received router advertisement. The 64-bit prefix advertised by the Teredo server consists of the Teredo prefix (32 bits) and the public IPv4 address of the Teredo server (32 bits).
• The next 16 bits are either 0x8000 (cone NAT) or 0x0 (restricted NAT).
• The next 16 bits are set to the obscured external UDP port number that is included in a special Teredo header in the router advertisement.
• The last 32 bits are set to the obscured external IP address that is included in a special Teredo header in the router advertisement.

Initial communication between two Teredo clients in different sites

The success of initial communication between Teredo clients located in different sites depends on whether those sites are using cone NATs or restricted NATs.

When both Teredo clients are located behind cone NATs, the NAT translation table entries for Teredo traffic for each Teredo client allows traffic from any source IP address or source UDP port. Therefore, a Teredo client in one site can send packets directly to a Teredo client in another site without the use of additional packets to establish NAT translation table entries.

When the Teredo clients are located behind restricted NATs, additional NAT translation table entries must be established before unicast packets can be exchanged. The following figure shows the initial communication process between Teredo clients that are located in different sites when both sites are using restricted NATs.

To send an initial communication packet from Teredo Client A to Teredo Client B, the following process is used:

1. Teredo Client A sends a bubble packet directly to Teredo Client B. A bubble packet contains no data and is used to create or maintain NAT mappings. Because Teredo Client B is behind a restricted NAT, Teredo traffic from an arbitrary source IPv4 address and UDP port number is not allowed unless there is a source-specific NAT translation table entry. Assuming that there is none, the restricted NAT silently discards the bubble packet. However, when the restricted NAT for Teredo Client A forwarded the bubble packet, it created a source-specific NAT translation table entry that will allow future packets sent from Teredo Client B to be forwarded to Teredo Client A.
2. Teredo Client A sends a bubble packet to Teredo Client B through Teredo Server 2 (Teredo Client B's Teredo server). The IPv4 destination address in the bubble packet is set to the IPv4 address of Teredo Server 2, which Teredo Client A determines from the third and fourth blocks of Teredo Client B's Teredo address.
3. Teredo Server 2 forwards the bubble packet to Teredo Client B. The restricted NAT for Teredo Client B forwards the packet because there is an existing source-specific mapping for Teredo traffic from Teredo Server 2 (established by the initial configuration of Teredo Client B).
4. Teredo Client B responds to the bubble packet received from Teredo Client A with its own bubble packet, which is sent directly to Teredo Client A. Because Teredo Client A's restricted NAT has a source-specific mapping for Teredo traffic from Teredo Client B (as established by the initial bubble packet sent from Teredo Client A in step 1), it forwards the bubble packet to Teredo Client A.
5. Upon receipt of the bubble packet from Teredo Client B, Teredo Client A determines that source-specific NAT mappings exist for both NATs. Teredo Client A sends an initial communication packet directly to Teredo Client B.

This process occurs transparently to the user at Teredo Client A.

There are additional initial communication processes that depend on whether the destination for the initial communication is on the same link, on the IPv6 Internet, or for a Teredo host-specific relay. For more information, see Teredo Overview.

For More Information

For more information about Windows XP Peer-to-Peer Networking and IPv6, consult the following resources:

• Windows Peer-to-Peer Networking Web site
• Microsoft Windows IPv6 Web site
• Windows 2000 Network Address Translator (NAT) (March 2001 The Cable Guy column)
• IPv6 Transition Technologies

For a list of all The Cable Guy articles, click here.