IPv6 Support in Home Routers

Updated: March 8, 2005

Contrary to popular belief, Internet Protocol version 6 (IPv6)-capable devices, computers, and routers can provide users with virtually all the benefits of IPv6 without having to wait for Internet service provider (ISP) support for native IPv6 connectivity. This is made possible through IPv6 transition technologies that support IPv6 communications over an Internet Protocol version 4 (IPv4) network infrastructure.

This article provides recommendations for an IPv6 feature set for home routers that are compatible with scenarios supported by Microsoft Windows family of operating systems.

On This Page

  Introduction
  IPv6 Home LAN Topology Assumptions
  IPv6 Home Router Requirements
  Conclusion and Summary
  Resources and References

Introduction

There is a strong misconception that IPv6 support in home routers is tied to ISP deployment of a native IPv6 service. This is not true. Home routers can deliver the full IPv6 experience to users over the existing IPv4 Internet using IPv6 transition technologies. The goal of this article is to encourage independent hardware vendors (IHVs) to add IPv6 and IPv6 transition capabilities to home routers and not wait until native IPv6 service is widely deployed.

IPv6 support in home routers allows end-to-end connectivity between personal computers and other IPv6-enabled devices, which provides a better user experience in voice and video communications, peer-to-peer games, and other technologies that require end-to-end connectivity. For home router manufacturers, implementing the IPv6 features described in this article promotes a better user experience, compatibility with upcoming technologies, and integration with Microsoft Windows XP.

Home router manufacturers that would like further explanation of the architectural reasoning behind specific recommendations, or how these recommendations affect compatibility with Windows XP and future Microsoft operating systems, are encouraged to send e-mail to IPv6FB@microsoft.com.

IPv6 Home LAN Topology Assumptions

This article assumes that the vast majority of home network topologies have (or will have in the near future) the following properties:

• A single home router

• One subnet per household

• IPv4 and/or IPv6-capable computers and devices

• The home router serving as the network security boundary.

Figure 1 shows a network reference topology of a home network, which consists of a single subnet, four computers, and a Voice over IP (VoIP) phone. As a growing trend, home networks now consist of multiple wired and wireless segments. Figure 1 also shows a second wireless router to illustrate a common case of wireless expansion in the home?most new wireless access points (APs) come with integrated router functionality whether the home user needs it or not. Further discussion about the differences between routers and wireless APs can be found in the following section.

Figure 1: A Single Home Router

In Figure 1, Home Router A implements network address translator (NAT) functionality for IPv4 traffic and router functionality for IPv6 traffic. The home LAN is a leaf network of the IPv6 Internet. Physical network configuration may be more complex, involving Ethernet switches, wireless APs, VoIP adapters, and other connectivity solutions.

A "pure" home router is a device with two Ethernet ports: a wide area network (WAN) port connected to the ISP and a local area network (LAN) port for the home network. However, often home routers are also integrated with other functionalities such as being a broadband modem (digital subscriber line [DSL] or cable), multi-port LAN switch, wireless AP, etc. Figure 2 illustrates the conceptual breakdown of this integration trend. Note that such integration does not alter the core router functionality.

Figure 2: Router integration with other devices

One Subnet per Household

The underlying assumption in this article is that homes consist of a single subnet. From a home network addressing perspective, multi-subnet configurations and intra-home routing are unwarranted. Exceptions to the single subnet design might include:

• Mistaken double NATs. This commonly occurs when an integrated wireless router (instead of a bridged wireless AP) is added to the home network.

• Layered security barriers, or perimeter networks (also known as DMZs). For example, parents may want to separate confidential or sensitive computers away from their children's Internet-facing gaming computers.

In a single-subnet home network, all wired or wireless segments must be bridged transparently. When an integrated router is added to this existing network (for wireless or Ethernet switching), the integrated device must either:

• Turn off its own router functionality and only operate as a wireless AP or bridge, or

• Provide multiple LAN ports and clearly instruct users to connect all segment cables to LAN ports only and to avoid any use of the WAN port (see Figure 3).

Microsoft further recommends including double NAT detection functionality in the home router. When an integrated router obtains a private IPv4 address for its WAN port through the Dynamic Host Configuration Protocol (DHCP), it is most likely due to a double NAT configuration. In contrast, a private IPv4 address obtained through Point-to-Point Protocol over Ethernet (PPPoE), Layer Two Tunneling Protocol (L2TP), or similar WAN/ISP mechanisms are most likely due to an ISP service that is limited to private IPv4 addresses, and is not necessarily an indication of misconfiguration. This is not an entirely accurate technique for detecting double NATs. For example, a DHCP server may be purposefully configured to hand out private IPv4 addresses. Microsoft strongly recommends that customers be warned about the potential network misconfiguration and provided guidelines for fixing the problem.

Figure 3: Router functionality bypass (LAN switching)

IPv4- and/or IPv6-capable Computers and Devices

IPv6 offers global end-to-end connectivity for peer-to-peer and other new applications and scenarios. The Windows family of operating systems starting from Windows XP with Service Pack 1 and Windows Server 2003 already supports IPv6, as will Windows Vista. Windows CE 4.2 and 5.0 also provide extensive IPv6 support. All these IPv6-enabled versions of Windows support the "Basic socket interface extensions for IPv6" (RFC 2133) and the "Advanced sockets API for IPv6" (RFC 2292) to enable applications programmers to take advantage of IPv6 today.

It is expected that some devices in the home such as computers running Windows 98 will be limited to IPv4, while others (personal data assistants [PDAs], VoIP), might only communicate over IPv6. The IPv4-only and IPv6-only devices cannot communicate directly, however dual-stack computers can communicate with both.

Home Router Serving as the Network Security Boundary

The home router must provide a basic security boundary for the nodes on the home LAN. For many home network configurations, the IPv4 router performs address translation for clients on the home LAN, effectively hiding their private IPv4 addresses. However, since IPv6 provides direct connectivity to the Internet, IPv6 routers do not provide this level of address security. Consequently, since not all devices on the home LAN will have host-based firewalls, routers should provide basic firewall functionality. Such firewall functionality should include, but need not be limited to, stateful packet filtering.

IPv6 Home Router Requirements

An IPv6-enabled home router must implement a number of technologies to be compatible with Windows operating systems and the IPv4 and IPv6 technologies that ISPs and IHVs deliver.

For simplicity, the article lists requirements separately for the WAN, LAN, and core portion of the home router. This organization has two benefits:

• It clearly separates between client and server functionality of the same protocol. For example, home routers serve as DHCP clients on the WAN side and DHCP servers on the LAN side.

• It removes the need for repetition of identical requirements across ISP scenarios. For example, LAN requirements are identical for native IPv6 and 6to4 and the differences are exclusively on the WAN side.

ISP Scenario-driven Requirements

The level of IPv6 support and requirements vary for ISP deployment scenarios. The following represents the most common ones:

Private IPv4 Connectivity (Teredo IPv6)

If the ISP provides only private IPv4 addresses, as described in RFC 1918, then IPv6 connectivity is not expected to be enabled directly by home routers. Instead, individual hosts will acquire IPv6 addresses and connectivity themselves by using Teredo technology, transparently to the home routers. Teredo is an IPv6 transition technology that tunnels IPv6 packets as IPv4-based User Datagram Protocol (UDP) messages using UDP port 3544.

Although there are no specific WAN and LAN requirements for a router to support Teredo, the router should adhere to the following behavior to be compatible with Teredo:

• Allow traffic for the Teredo UDP port 3544 to be sent and received from internal hosts to external hosts.

• Avoid resetting port mappings in the event an Internet Control Message Protocol (ICMP) echo fails or times out.

• Avoid using a symmetric NAT implementation or alternatively support the UPnP Internet gateway device (IGD) specification. Teredo works only over cone and restricted NATs.

  • A cone NAT stores a single 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.

  • A symmetric NAT 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.

The Teredo RFC can be found at http://www.ietf.org/rfc/rfc4380.txt , under the title "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)."

Public IPv4 Connectivity (6to4 IPv6)

If the ISP provides only a single public IPv4 address, then LAN hosts have the additional and preferred option of using the 6to4 transition technology specified in RFCs 3056 and 3068. 6to4 requires the egress router to an IPv4 network to encapsulate IPv6 packets with an IPv4 header with the Protocol field value set to 41. In the home scenario, the home router is the egress router connected to the IPv4 Internet. However, the LAN itself can run in IPv6 native mode. Furthermore, some LAN hosts may still use Teredo. Therefore, a home router has the following requirements for WAN and LAN functionality:

WAN:

• Provide 6to4 router advertisement functionality.

• Support 6to4 IPv6-in-IPv4 encapsulation.

• Configure an IPv6 prefix derived from the public IPv4 address

LAN:

• Support IPv6 host auto-configuration and Neighbor Discovery; respond to Router Solicitation messages and send Router Advertisement (RA) messages. These requirements are specified in RFC 2461.

• Support DHCPv6 stateless server functionality to add DNS configuration to the autoconfigured host. DHCPv6 is specified in RFC 3315.

• It is not mandatory to support DHCPv6 server stateful functionality, although it can be useful to support cascading prefix delegation for automatic subnetting. For example, a home can be allocated a /48 or /63 prefix, and the home router can then delegate a /64 prefix to an internal router within the home. (Note, however, that our assumption for home networks is that they have a single subnet.)

Native IPv6 Connectivity

ISP support for native IPv6 connectivity is about the equivalent functionality to supporting public IPv4 connectivity. The ISP is connected to the global IPv6 Internet, allocates global unicast IPv6 addresses to their customers (in the form of a prefix), and routes IPv6 packets between the home network and the IPv6 Internet.

In this scenario, the ISP may provide a dual-stack service (providing customers with both native IPv6 and native IPv4 connectivity), or it can limit the service to native IPv6 only.

WAN:

• Support DHCPv6 stateful client functionality to receive prefix delegation from the ISP and obtain a DNS configuration. By default, home routers should use the DHCPv6 DNS configuration they receive through prefix delegation and assign it to home network clients in their DHCPv6 service. This approach ensures that any changes to the ISP DNS configuration would be transparently passed on to hosts, without manual reconfiguration. This is important even if the home router has DNS proxy capabilities.

• Support the appropriate ISP, country, or region-specific flavor of broadband dial-up technology (client-to-ISP authentication and traffic encapsulation) such as IPv6 over the Point-to-Point Protocol (PPP) (RFC 2472) or Internet Protocol security (IPsec) over IPv6 (IPsec tunnel mode, RFC 2401).

LAN:

• The same LAN functionality as specified for public IPv4 connectivity. Note that despite having only one WAN port, an IPv6 home can be multihomed. For example, when the ISP supports dual stacks, the home router is expected to have both native IPv6 as well as 6to4 forwarding capabilities, and the router needs to choose the right path depending on the destination address (6to4 vs. native IPv6 address).

Native IPv6 Connectivity with Tunneled IPv4

Even if they have native IPv6 connectivity, most consumers still need IPv4 connectivity for accessing Internet content. However, from the ISP's perspective, the overhead of providing both native IPv4 and native IPv6 connectivity is high, requiring double equipment configuration, provisioning, complicated troubleshooting, etc. As an alternative to this dual stack approach, ISPs are adopting a more economical model that involves tunneling IPv4 traffic over IPv6; that is, transporting IPv4 packets as IPv6 payloads.

This practice is already well established in many regions such as the European Union where government regulation restricts the ability of companies to provide both broadband and Internet services. In these regions, IPv4 customers already have dual connectivity: native IPv4 connectivity to their broadband provider (for added value services and content), and tunneled connectivity (over PPPoE, L2TP, or IPsec) to their chosen Internet provider. In these regions, the broadband network can be upgraded transparently to native IPv6 while users continue to receive their IPv4 Internet service over the same network through IPv4-over-IPv6 tunnels.

WAN:

• IPv6 configuration is the same as for the native IPv6 scenario.

• The home router needs to support IPv4-over-IPv6 tunneling to connect to ISPs. There are various standards for doing this including the following:

  • Generic Tunneling of IPv4 over IPv6 (RFC 2473)

  • Generic Routing Encapsulation (GRE) tunneling over IPv6 (RFC 2784)

  • IPsec tunnel mode, tunneling IPv4 packets over IPv6 (RFC 2401)

    (The PPPoE and PPP protocols are irrelevant since they operate over layer 2 rather than over IPv6).

• The home router must be able to handle separate configurations (DHCP, DNS) on a per-protocol (IPv4 and IPv6) basis similar to a multihomed computer. For example, when an IPv4 client on the LAN queries for the DNS server list, only the list of IPv4 DNS servers must be returned.

LAN:

• Same LAN functionality as native IPv6 and native IPv4 LAN functionality.

Other Home Router Considerations

Name Resolution (DNS)

IPv6 addresses are too long to be typed by a user on a regular basis. For example, typing http://192.168.2.1 may be acceptable for IPv4, but IPv6 usability mandates using name-based URLs such as (http://myrouter). Therefore, on the LAN side, routers must support multicast DNS (mDNS), also known as Link-Local Multicast Name Resolution (LLMNR) (RFC 4795) . Routers should:

Although there are no specific WAN and LAN requirements for a router to support Teredo, the router should adhere to the following behavior to be compatible with Teredo:

• Respond with their IPv6 address when a client on the LAN sends an mDNS query for resolving the router name.

• Send out mDNS queries to resolve names.

It is highly recommended that IPv6 configuration and reports include DNS names alongside (or instead of) IPv6 address.

DNS proxy functionality is not generally needed in the common single subnet case:

• For local names, mDNS sufficiently covers local name resolution on a single subnet (mDNS is scoped by IPv6 link-local addresses).

• For global names, clients can query the ISP DNS servers directly (DNS is configured through DHCPv6).

A stateless DNS relay/proxy is needed for two cases: multi-subnet homes and when IPv6 resource record queries (DNS AAAA records) are sent over IPv4 (with Windows XP with Service Pack 2 and Windows XP with Service Pack 1).

The Teredo RFC can be found at http://www.ietf.org/rfc/rfc4380.txt , under the title "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)."

UPnP-enabled Firewall Capabilities

As mentioned earlier, home routers must provide at least stateful packet filtering to make up for the fact that the address translation and concealment functionality provided by IPv4 NATs is no longer available.

Furthermore it is important that the router's firewall functionality be able to seamlessly co-exist with host-based (personal) firewalls and end-user applications to provide the best user experience. To this end, Microsoft recommends that the router be UPnP enabled, for example, to allow ports to be dynamically opened and closed. More information about the UPnP protocol can be found at http://www.upnp.org . UPnP is supported on Windows XP, Windows 2003 Server, and Windows CE versions 4.2 and 5.0.

Configured Tunnels

Configured IPv6 over IPv4 tunnels can extend native IPv6 connectivity, but given their poor scaling properties and the need for individual configuration, they are optional. The 6to4 service does require relaying into the native IPv6 Internet but has better scaling properties for homes.

IPv6-to-IPv4 Translation (NAT-PT)

Microsoft does not recommend that routers support IPv6-to-IPv4 Network Address Translation Protocol Translation (NAT-PT) because it is known to break end-to-end connectivity. The IETF has been working to resolve these issues, but NAT-PT may be deprecated.

Interoperability and Conformance Testing

As noted, there are various IPv6 standards that home routers must implement. To assist in testing conformance to these standards, Microsoft recommends the use of the third-party Tahi suite of interoperability tests available at http://www.tahi.org/ . Microsoft will provide further information on Microsoft-specific tools and hardware compatibility tests when available.

Conclusion and Summary

Even if ISPs do not all support IPv6 natively, it is possible to take advantage of IPv6 features through transition technologies, such as Teredo and 6to4, that support IPv6 communications over an IPv4 network infrastructure such as the IPv4 Internet. In order to take advantage of IPv6, however, home routers need to provide a basic set of IPv6 features depending on the targeted ISP scenario. Table 1 summarizes these requirements. IPv6 support in home routers will ultimately provide a better user experience in voice and video communications, peer-to-peer games, and other technologies that require end-to-end connectivity.

Table 1: Summary of home router functional requirements

ISP Scenario	Router requirements
Private IPv4 Connectivity (Teredo for IPv6)	Adhere to Teredo-compatible behavior. For example, allow inbound and outbound traffic from UDP port 3544, and do not perform symmetric translation.
Public IPv4 Connectivity (6to4 for IPv6)	Implement DHCPv6 server stateless. Implement 6to4 gateway functionality. Support IPv6 host autoconfiguration and Neighbor Discovery.
Native IPv6 Connectivity	Provide both DHCPv6 server and stateful client functionality. Support the ISP's client-to-ISP authentication and encapsulation protocol. Support IPv6 host autoconfiguration and Neighbor Discovery.
Native IPv6 Connectivity with Tunneled IPv4	Provide both DHCPv6 server and stateful client functionality. Support the ISP's IPv4-over-IPv6 tunneling protocol. Provide both IPv6 native LAN functionality and IPv4 native LAN functionality simultaneously, without one interfering with the other.
All ISP scenarios	Support mDNS (LLMNR). Provide UPnP enabled stateful packet filtering capabilities.

Resources and References

For questions about this document, please send e-mail to ipv6fb@microsoft.com.

For additional information, see the following:

• Microsoft Windows IPv6 Web site

• Microsoft Developer Network (MSDN) Download and Code Center

• Microsoft Windows Driver Development Kit (DDK)

• Windows Logo Program

• Windows Application Compatibility Toolkit

• Windows Hardware Quality Labs (WHQL) Testing Resources