Network Infrastructure Device Implementer’s Guide Requirements and implementation details for Consumer and Small Business routers, WLAN APs, and residential gateways for systems that run the Microsoft ® Windows Vista™ operating system August 5, 2005 — Version 0.6 Abstract This paper describes the requirements and implementation details for Consumer and Small Business routers, wireless LAN access points (WLAN APs), and residential gateways to interoperate with the Microsoft® Windows Vista™ operating system. Windows Vista delivers a number of new and enhanced experiences for home networks, including ease of setup, ease of use, and distribution of digital media throughout the home. Devices that meet the requirements outlined in this paper will deliver the best experience with Windows Vista and other Microsoft products, including Microsoft Xbox ® and Windows Media Center Extender, and will receive the benefits of the Windows Vista Logo Program. The information in this document applies for the Microsoft Windows Vista operating system. References and resources discussed here are listed at the end of this paper. The current version of this paper is maintained on the Web at: http://go.microsoft.com/fwlink/?LinkId=50286 For questions or comments about these requirements or implementation guidelines, please send e-mail to rtrlogo@microsoft.com. Contents Introduction ............................................................................................................................. 3 Document Scope .................................................................................................................... 3 Technology Framework and Definitions .................................................................................. 4 Setup and Configuration ......................................................................................................... 6 WCN-Config ....................................................................................................................... 6 WCN-FlashConfig .............................................................................................................. 6 WCN-Config Network ......................................................................................................... 7 Simple Config Overview ..................................................................................................... 7 Requirements for Wireless Routers and WLAP APs .......................................................... 8 Network and Bus Basics ......................................................................................................... 8 Router IP Basics ................................................................................................................ 8 802.11 Requirements for Premium Logo (Streaming Media) ............................................. 9 Transparent Connectivity ...................................................................................................... 11 IPv4 NAT .......................................................................................................................... 11 Port Assignment Policy................................................................................................ 11 Port Filtering Policy...................................................................................................... 11 IPv6 and Transition Technologies .................................................................................... 11 Private IPv4 Connectivity (Teredo) .............................................................................. 12 Public IPv4 Connectivity (6to4) .................................................................................... 13 Home Router Considerations When Supporting IPv6.................................................. 14 Summary .......................................................................................................................... 14 Discovery and Control ........................................................................................................... 15 Link Layer Topology Discovery ........................................................................................ 15 Requirements for WSD, UPnP, and Auto-Bridge Mode Selection .................................... 16 Quality of Service .................................................................................................................. 17 QoS and qWAVE ............................................................................................................. 17 QoS Requirements ........................................................................................................... 19 Resources and References................................................................................................... 19 Appendix A – DHCP Enable Vendor Extension Schema ...................................................... 21 Appendix B – UPnP Byte Counter Implementation Details ................................................... 23 Appendix C – Guidelines Summary ...................................................................................... 24 Network Infrastructure Device Implementer’s Guide - 2 Disclaimer This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred. © 2005 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista, and Xbox are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 3 Introduction The difficulty in setting up home networks is often cited as the single largest impediment to increased Internet usage and delivery of broadband services. Currently, users are confused by the choices they face in selecting home networking equipment, and are frustrated when they purchase the wrong equipment or when they configure their network incorrectly and their devices or applications fail to work. As a result, mainstream consumers are hesitant to purchase home networking devices and fail to move beyond simple single-PC tasks such as email and Web surfing. The Microsoft® Windows Vista™ operating system delivers capabilities that change the landscape for home networks and networking device vendors. Windows Vista makes it easy to set up routers, Wireless LAN access points (WLAN APs), and residential gateways that deliver reliable connectivity and security—provided that these devices meet a base level of requirements for interoperating with Windows Vista. This document describes those requirements. The Windows Vista Logo Program for Consumer routers and WLAN APs creates a single, unified set of requirements across Microsoft. This ensures that vendors can develop products that address multiple scenarios, without being constrained by conflicting requirements. Although these requirements specifically reflect the capabilities and technologies included in Windows Vista, care has been taken to rationalize all Microsoft requirements for routers and WLAN APs. Requirements from Microsoft Xbox®, Windows Media Center, MSN, and Small Business have been unified into one cohesive set to maximize the program’s effectiveness and benefits to partners. Note: Small businesses experience network setup and connectivity problems similar to those found in consumer home networks. For consistency, this document refers primarily to Home network scenarios; these scenarios are either identical or very similar to those for Small Business networks, and hence one set of requirements addresses both customer segments. Document Scope This paper provides the specific requirements and implementation details for vendors who design and produce routers, wireless access points, and residential gateways to interoperate with Windows Vista. Devices that meet the requirements and guidelines in this document will meet the requirements for the Windows Vista Logo Program. Device Types This paper describes requirements and implementation details for these types of devices: Routers (both wireless and wired) Wireless LAN access points (WLAN APs) Residential gateways Definitions of device types are provided in “Technology Framework and Definitions” later in this paper. Note: In this paper, the term “residential gateway” is not used to denote a separate device class; instead, a residential gateway is treated as a router that includes an integrated broadband modem. To receive a logo for a residential gateway product, vendors must meet the requirements for the router device type. No requirements are defined for the modem functionality in a residential gateway. Requirements for the following device types are not discussed in this document: switches, hubs, wireless bridge gaming adapters, broadband modems. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 4 Product Qualification Levels The Windows Vista Logo Program defines requirements for devices that can interoperation with Windows, and also introduces qualification levels for different types of products: The Standard logo ensures baseline compatibility and user experience with Windows Vista. The Premium logo is reserved for products that enable and deliver premium experiences. This document provides additional detail to the individual requirements for the Network device types defined in the Windows Vista Logo Program requirements. This document should be used for design and implementation guidance, and to assist vendors in ensuring that their products will pass the validation tests for Windows Vista Premium or Standard logos. Note: In cases where logo designations (Standard vs. Premium) conflict between this document and Windows Vista Logo Program System and Device Requirements, Version 3.0, the Standard versus Premium definitions in the Windows Vista Logo Program System and Device Requirements take precedence. In this document, the Standard versus Premium information is denoted as follows: “Must” indicates that the item is required for the Standard Logo. For the Premium logo, items are designated with the phrase “must be implemented for the Windows Vista Premium logo.” All requirements for both the Standard and Premium logos will be tested as part of the Windows Vista Logo Program test suite. “Should” indicates that the item is optional, but recommended. “If implemented” indicates that the item must meet specific guidelines only when the feature is implemented in a device, though the feature itself is not required. Technology Framework and Definitions The following technology framework summarizes the key networking components in Windows Vista. This framework provides the structure and order for technologies discussed in this document. Table 1. Technology Framework Summary August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 5 Technology Definitions Bridge A Data Link layer (L2) device that connects two or more different LAN segments to form a single network segment (also known as a subnet or single broadcast domain). A bridge implements a spanning tree algorithm for network loop detection. Broadband modem A Data Link layer (L2) device that bridges a physical broadband WAN interface into Ethernet or USB. Hub A Physical layer device that connects multiple wired network nodes together on the same LAN segment. A hub implements a repeater function and is a single Ethernet collision domain. Network address port translator (NAT) An IP router that translates the IP addresses and TCP/UDP port numbers of packets as they are forwarded, as defined by RFC 1631. A NAT allows multiple private network computers to use a single public IPv4 address. (See NAT references listed at the end of this paper.) Definitions of NAT sub-types are as follows: Full cone All requests from the same internal IP address and port are mapped to the same external IP address and port. Any external host can send a packet to the internal host by sending a packet to the mapped external address. This NAT type is also be referred to as an “Open” NAT. Restricted cone All requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. Port restricted cone Similar to a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P. Symmetric (or “strict” NAT) All requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Only the external host that receives a packet can send a UDP packet back to the internal host. Symmetric NATs do not interoperate properly with Windows and many other operating systems and applications, and should be avoided at all times. Residential gateway A device that combines an IP router with a broadband modem, designed to connect a private network to the Internet. Residential gateways that meet the requirements described in this document for routers meet the requirements for the Windows Vista Logo Program, since they contain a full set of router functionality. Router A Network layer (L3) device that connects disparate network segments (that is, subnets) and forwards traffic based on a combination of a network address and a node address. NAT functionality must be included. Note: A router with multiple Ethernet interfaces (or one or more wireless interfaces) does not route between LAN-side interfaces; they are typically switched or bridged. In other words, a home router generally routes only between the WAN and LAN interfaces. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 6 In this document, the term “router” refers to both wired-only routers (those that have only wired Ethernet interfaces) and wireless routers (a router with a wireless access point as one of its LAN interfaces). Switch A multi-port store-and-forward device that may also implement MAC address learning to selectively forward frames to switch ports based on the destination MAC address. A switch does not implement a spanning tree algorithm. Wired router A router with no wireless (802.11) capabilities. Wireless bridge gaming adapter A device that connects an individual Ethernet device to a WLAN. This device type only bridges between wired and wireless media and only implements a station function on the wireless interface. Requirements for this device type are not discussed in this document. Wireless LAN access point (WLAN AP) A wireless base station used for hosting infrastructure mode IEEE 802.11 wireless networks. WLAN APs bridge network traffic between wireless clients and a wired network segment. A wireless access point enables one or more wireless stations (clients) to associate to its 802.11 interface. Wireless router A router that also contains WLAN AP functionality. A wireless router supports all the functionality defined by both a non-wireless router and WLAN AP. Setup and Configuration The Setup and Configuration technology area of Windows Connect Now (as listed in Table 1) delivers effortless and secure-by-default setup of wireless infrastructure devices and wireless clients. WCN-Config To ensure that a user has a positive experience configuring a secure wireless home network, it is important that the wireless router and WLAN AP devices designed for use in the home support a consistent, secure method for configuration. These capabilities are provided by implementing one or both of the setup methods provided by Windows Connect Now, known as WCN-FlashConfig and WCN-Config Network. WCN-FlashConfig and WCN-Config Network are both mechanisms for configuring wireless devices, but they differ in the method used to transfer wireless configuration settings: WCN-FlashConfig requires that a physical storage device, such as a USB flash drive (UFD) or CompactFlash storage card, be physically moved between the computer and the device in need of wireless configuration settings. WCN-Config Network over Ethernet uses UPnP to transfer settings over the wire. WCN-Config Network over Wi-Fi transfers settings using wireless in-band (that is, no physical medium is needed for transfer). WCN-FlashConfig WCN-FlashConfig first shipped in Windows XP Service Pack 2, and greatly eased the difficulty associated with setting up wireless networks and adding wireless devices to them for the small office/home office (SOHO). WCN-FlashConfig is the technology used by the Wireless Network Setup Wizard in Windows XP Service Pack 2, which can be accessed from the Control Panel as a Networking task, as identified by the following icon. Figure 1. WCN-FlashConfig icon August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 7 WCN-Config Network WCN-Config Network over Ethernet and over Wi-Fi use the Simple Config protocol for configuration and setup. Simple Config Overview Figure 2 depicts the major components and their interfaces as defined by Wi-Fi Simple Config. There are three logical components involved: the Registrar, the access point (AP), and the Enrollee. The Enrollee is a device seeking to join a WLAN domain. Once an Enrollee obtains a valid credential, it becomes a member. A Registrar is an entity with the authority to issue and revoke domain credentials. A registrar can be integrated into an AP. The AP can be either a WLAN AP or a wireless router. Figure 2. Major Components of WCN-Config Network Registration initiation is ordinarily accomplished by a user action such as powering up the Enrollee and, optionally, running a setup wizard on the Registrar (PC). Interface M This interface is between the AP and the Registrar. Interface M enables an external Registrar to manage a Wi-Fi Simple Config AP. Wi-Fi Simple Config uses a similar protocol for setting up the AP Management interface as for issuing credentials to Enrollee devices. AP The AP implements Interface M by: Acting as the Enrollee in the Registration Protocol for initial setup with one or more external Registrars. This includes sending its own Discovery message across all appropriate channels (Ethernet and/or 802.11 probe response over Wi-Fi). Implementing the Management Interface described in the WFADevice and WFAWLANConfig Service documents. This requires the AP to be a UPnP device that includes support for the Wi-Fi Simple Config proxy service. Monitoring 802.11 probe request and EAP messages from Enrollees and converting them to UPnP Event messages according to the method described in the WFAWLANConfig Service document. Interface A This interface is between the Enrollee and the AP. The function of Interface A is to enable discovery of the Simple Config WLAN and to enable communication between the Enrollee and Ethernet-only Registrars. AP The AP implements Interface A by: Sending out 802.11 beacons indicating support for Simple Config and generating Probe Response messages containing a description of the AP. Implementing an 802.1X authenticator and the Simple Config EAP method. Proxying 802.11 probe request and EAP messages between Enrollees and external Registrars as described in the WFADevice and WFAWLANConfig Service documents. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 8 Requirements for Wireless Routers and WLAP APs To ensure that devices work well with Windows Vista WCN-Config, WLAN APs and wireless routers must meet the following requirements: Device must support WCN-Flash Config, WCN-Ethernet, or WCN-Wi-Fi. A device that supports WCN-Config Network over Ethernet: Must support the Windows Connect Now Simple Config protocol. Must use an 8 character PIN. Must be discoverable using SSDP. A device that supports wireless WCN-Config Network over Wi-Fi: Must support the Windows Connect Now Simple Config protocol. Must be discoverable using the Layer 2 wireless EAP method. Should dynamically create a PIN. For Windows Vista Premium logo, the device must use an 8-character PIN. A device that supports WCN-FlashConfig: Must include one of the supported flash drive types. Must comply with the WCN Specification. Device must follow the implementation details provided in the Windows Connect Now specification. (See references listed at the end of this paper.) Network and Bus Basics The Network and Bus Basics technology area of Windows Connect Now (as listed in Table 1) ensures that the networking media and infrastructure devices are correctly matched for the end-use applications and are performing properly. Router IP Basics Routers should properly handle basic packet routing in order to interoperate with Internetbased services. Applications that depend on proper router behavior include online gaming services, peer-to-peer networks, and Internet-based media streaming. Windows Vista delivers new functionality for online and peer-to-peer services. To be compatible with Windows Vista functionality, the router must meet the following requirements: Packet handling and routing: It must be possible for UDP packets from multiple IP addresses to traverse the NAT component of the router. Port mappings must not be changed or closed after receiving an ICMP portunreachable packet on the WAN side interface. MTU size / Fragmentation requirement: IP routers must not fragment IP frames (either LAN to WAN or WAN to LAN) that are less than 1440 bytes. IP routers should not fragment IP frames that are less than 1500 bytes. (This requirement ensures interoperability with latency-sensitive online services.) It must be possible to download packets on TCP ports 80 and 3074. DHCP Lease characteristics: When the router assigns IP addresses through DHCP, it must provide the same IP address with a lease duration of longer than five minutes when a client makes repeated requests to renew its IP address. Session policy: The router must keep a port association open when the only traffic it is receiving is “keep alive” traffic generated by way of UDP packets received on the LAN-side interface. Specifically, the port association must be maintained when the router receives packets at intervals of 60 seconds or less. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 9 TCP finish (FIN) segment response: The router must keep a TCP socket association open until a download is complete, even after an internal client sends a TCP FIN segment. Note: These requirements are the same as those required for Microsoft Xbox Live! router certification program. Vendors whose products already meet Xbox Live! router requirements can take advantage of this interoperability for other Microsoft products, including Windows Vista. 802.11 Requirements for Premium Logo (Streaming Media) For Windows Vista to support transmission of in-home media, the related hardware must meet specific hardware requirements, plus testing requirements and industry certification of components. These requirements issues for performance, which can vary widely across nearly identical devices. Note: All requirements listed in this section apply only for the Windows Vista Premium logo. Requirements for Platform Foundation: Wi-Fi Dual-band Operation A wireless router or WLAN AP must have Wi-Fi certification for 802.11a and 802.11g simultaneous operation. Each radio must have Wi-Fi certification for WPA-Personal and WiFi Multimedia (WMM). Wi-Fi certification enables the device to interoperate with other Wi-Fi certified equipment. If the wireless home network is organized into two independent wireless access points, the media traffic (say, between the Media Center PC and Media Center Extender) can be isolated on the 802.11a band, with all other data networking on the 802.11g/b band. In this way, the 802.11b/g network activity (typical usage) can no longer affect the 802.11a network activity for multimedia streaming. Requirements for Accessibility: Web Page User Interface Usable on TVs If the router or AP has an HTML web-based user interface, it must be usable on a standarddefinition TV output – 640x480i. Font size must be 16pt or greater. Many media sources and sinks have a display capability of a standard television. If the user needs to read information or make a quick setting on the router from one of those devices by use of its HTML interface, it can be difficult or impossible to read unless the web pages can accommodate these low-resolution outputs. This requirement ensures that Web interfaces are usable on a standard-definition television. Requirements for Security: WEP and WPA-PSK Wireless interfaces must support WEP and WPA-PSK Personal. The WEP and PSK key must be accessible and configurable by the end user. It must not be masked or displayed using mask or strikeout characters, such as "*****". Many media devices have built-in wireless and might require the user to enter the wireless security key manually. The ability of the router to show the key for manual entry simplifies certain installation situations. Requirements for Reliability: Sustained Throughput at Range for 1 Hour Each radio of a wireless router or AP must be able to transmit to a wireless station a simulated high-definition video stream on UDP/TCP at 22 Mbps for one hour with less than 1% packet loss through two walls and 75 indoor feet in a typical wood-framed home or apartment. Tests have shown that coverage within the home is a significant factor in the success of establishing and using highly reliable wireless connections for multimedia applications. Antenna design and diversity, power output, and radio agility are some of the key factors that distinguish equipment with great coverage. This requirement is to ensure that the equipment can provide a high-definition multimedia stream to a typical house or apartment. Figure 3 shows the layout of an apartment with the August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 10 router in the northeast corner and three wireless stations in adjoining rooms. Various, typical obstructions such as walls, doors, furniture, and appliances are also shown. The linear distance between the wireless access points and the stations is of some consequence, but the number of obstructions such as walls is more important. 101'-6" 97'-4 1/4" 60'-6 7/16" TP 1 3/8" 92'-1 24'-0" TP 3 TP 2 94'-1" Figure 3. Test Layout for Wireless Access Point and Stations Requirements for Reliability: Sustained Throughput for 8 Hours Each radio of a wireless router or AP must be able to transmit to a wireless station a simulated high-definition video stream on UDP/TCP at 22 Mbps for eight hours with less than 1% packet loss. Sustained 22 Mbps throughput is a requirement for lightly compressed video streams, such as MPEG-2, and to enable an infrastructure that allows for high-definition streaming in the future. Further, some homes are playing video such as television at almost a constant rate. The requirement for sustaining a simulated video stream for eight hours with less than 1% packet loss is meant to validate that the wireless equipment can be used without reboot or power cycles for extended periods by the customer, with the reliability typical of mainstream Consumer Electronics equipment. Requirements for Reliability: Maximum Throughput Stress Each radio and each wired interface of a wireless router or AP must be able to simultaneously transmit to a client station at maximum capacity on UDP for one hour with less than 1% packet loss. The streams will be run simultaneously to stress the device and simulate a heavy load. This requirement stresses the wireless device on all its wireless interfaces (both the 802.11a and 802.11g radios on a dual-band router) at their maximum rate for one hour, simultaneously. This ensures that the device can handle stressful network congestion. Note: Requirements in this section are equivalent to requirements established in the “Designed for Windows XP Media Center Edition” logo program. Vendors whose products meet the current Logo Program router requirements can take advantage of this when meeting the Windows Vista Premium logo requirements for routers. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 11 Transparent Connectivity The Transparent Connectivity technology area of Windows Connect Now (as listed in Table 1) ensures that home networks are properly protected from the WAN environment, while employing firewall traversal and port mapping technologies to seamlessly deliver Internetbased experiences. IPv4 NAT Most home networks involve the use of a cable modem or DSL modem, together with a router, to share the broadband connection to the Internet with all of the computers on the private network. These devices typically perform this sharing function by acting as a NAT. It is important to understand the influence of a NAT on applications such as online gaming, chat, and other peer-to-peer dependent connections. NAT makes it difficult to establish peerto-peer sessions between computers separated by one or more NATs. It is critically important that users do not have to manually configure their NAT devices to access all the services available on the Internet. As a result, proper NAT behavior in routers is an essential part of the Windows Vista experience. Port Assignment Policy When a NAT receives a UDP packet from a client device, it must decide what UDP port to assign to that UDP source port on that client device. The different types of NATs are described in “Technology Framework and Definitions” earlier in this paper. For these three NAT types, symmetric NATs cause the most difficulty when establishing peer-to-peer connectivity between two devices located behind NATs. Symmetric NATs must not be implemented. Port Filtering Policy Some NATs apply filters on incoming traffic. The possible filtering policies include the following: No filtering. Any packet addressed to a port that the NAT has assigned to client devices is forwarded. When combined with a minimal port assignment policy, this is sometimes referred to as a full cone NAT. Address sensitive filtering. A packet addressed to a port that the NAT has assigned is forwarded only if it originated from an IP address to which the client device has previously communicated. Address and port sensitive filtering. A packet addressed to a port that the NAT has assigned is forwarded only if it originated from an IP address and port to which the client device has previously communicated. Windows Vista works best with cone NATs (those with a minimal port assignment policy) that implement no filtering or address sensitive filtering. Users behind these types of NATs will be able to connect to any other user behind any type of NAT, even symmetric NATs. Routers must be capable of performing Network Address Translation. The NAT implementation type must comply with either the Cone or Restricted NAT type definitions described earlier in this paper. IPv6 and Transition Technologies Internet Protocol version 6 (IPv6) is a suite of protocols designed to replace the existing layer protocols of the TCP/IP protocol suite known as Internet Protocol version 4 (IPv4) on which most of today’s Internet traffic is based. Although the most obvious difference between IPv4 and IPv6 is the total number of IP addresses the new protocol supports, IPv6 offers many more benefits, such as a hierarchical addressing structure, additional security, and greater mobility. IPv6 is a requirement for supporting new classes of computing and communication paradigms that are difficult to deliver on the existing IPv4 infrastructure. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 12 Every Windows component in Windows Vista is IPv6 capable and attempts to use IPv6 as the preferred means of communication. Computers running Windows Vista will dramatically increase the rate of deployment of IPv6, and as a result, the availability of IPv6-enabled devices and services. For routers, full support of IPv6 is a requirement for interoperability with Windows Vista. Implementing IPv6 will simplify the customer experience with Windows Vista. Because most of the Internet still uses IPv4, the most important pieces of the IPv6 requirements is to support two transition technologies, called Teredo and 6to4, which allow IPv6 traffic to be carried over IPv4 networks. This allows applications to communicate using IPv6 even when they are connected to IPv4 networks. With Teredo, the Windows Vista network stack tunnels IPv6 traffic over IPv4 UDP. With 6to4 tunneling, the router itself (that is, with no involvement of the operating system) can encapsulate IPv6 traffic for transmission across the IPv4 Internet. Support for both Teredo and 6to4 are required for residential gateways that want to interoperate with Windows Vista. Implementing 6to4 can only be done by creating a complete IPv6 stack and related protocols (e.g. DHCPv6, etc). The following sections outline the two basic types of connectivity scenarios provided by Internet Service Providers (ISPs) and multiple service operators (MSOs), and the resulting router requirements in an IPv4-based network. These scenarios describe how to achieve IPv6 connectivity over an existing IPv4 network infrastructure. For information about additional scenarios that cover native IPv6 deployment, see the IPv6 IGD Cookbook. (See the references and resources listed at the end of this paper.) The additional requirements for achieving full native IPv6 support, described later in this section, must also be met for a router to receive a Windows Vista logo. Private IPv4 Connectivity (Teredo) If the ISP provides only private IPv4 addresses to the WAN interface of the router, then routers cannot use 6to4 to tunnel IPv6 traffic across the IPv4 Internet. Instead, individual hosts will acquire IPv6 addresses and connectivity themselves by using Teredo technology, independently of the routers. Teredo is an IPv6 transition technology that tunnels IPv6 packets as IPv4-based UDP messages. Figure 4 shows the automated configuration of a Teredo client and how the Teredo client detects the type of NAT behind which it is located. Figure 4. Automated Teredo client configuration For Teredo to work properly, the router must meet these basic requirements: Support UPnP IGD port mapping requests. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 13 The Teredo client must be able to send outbound UDP traffic to the Teredo server. If the router has outbound filtering, then it must support UPnP IGD port mapping requests to allow Teredo to open the ports it needs. Avoid resetting port mappings if an Internet Control Message Protocol (ICMP) Echo message fails or times out. Implement cone or restricted NAT. Do not use a symmetric NAT implementation. Teredo only works over cone and restricted NATs. Support Hairpin or Loopback functionality in the NAT. This means the NAT must carry out a “twice-NAT” translation of addresses for local systems, allowing them to communicate with one another. In other words, when a host on the private side of a NAT device attempts to connect with another host behind the same NAT device using the public address of the host, the NAT device must perform the equivalent of a “twice-NAT” translation on the packet. The originating host's private endpoint must be translated into its assigned public endpoint, and the target host's public endpoint must be translated into its private endpoint, before the packet is forwarded to the target host. For details about Teredo, see the related references listed at the end of this paper. Public IPv4 Connectivity (6to4) If the ISP provides a public IPv4 address to the router WAN interface, it is preferable that the router handle all the IPv6 to IPv4 encapsulations (and back again), allowing the hosts on the local network to act as if they are directly attached to an IPv6 network when communicating with remote IPv6 systems across the IPv4 Internet. Routers can provide this transparent IPv6 functionality by supporting the 6to4 transition technology specified in RFCs 3056 and 3068. 6to4 requires the egress router (the router) to an IPv4 network to encapsulate IPv6 packets using 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. Some LAN hosts might still use Teredo. Therefore, a home router must meet the following requirements for WAN and LAN functionality: WAN interface (connected to the IPv4 Internet): Must support 6to4 IPv6-in-IPv4 encapsulation and decapsulation, providing 6to4 router functionality. LAN interface: Must configure an IPv6 prefix on the LAN interface derived from the public IPv4 address from the WAN adapter, as specified in RFC 3056. Must support IPv6 Neighbor Discovery and host autoconfiguration (respond to router Solicitation messages and send Router Advertisement messages with the IPv6 prefix derived from the public IPv4 address), as specified in RFC 2461. Must be able to receive IPv6 Router Solicitations and Send IPv6 Router Advertisements. Must support DHCPv6 stateless server functionality to add DNS configuration to the autoconfigured host, as specified in RFC 3315. It is not required 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. However, the assumption for home networks is that they have a single subnet. Must always assign the address of the residential gateway for DNS queries by using DHCPv6. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 14 Home Router Considerations When Supporting IPv6 This section describes additional router considerations for supporting IPv6: name resolution, firewall capabilities, and configured tunnels. Name Resolution IPv6 addresses are too long to be typed by a user on a regular basis. For example, typing http://192.168.2.1 might be acceptable for IPv4, but IPv6 usability requires using namebased URLs, such as http://myrouter. Routers should: Proxy DNS queries outside on names for which the built-in DNS service is not authoritative, regardless of record type. Respond to DNS queries for the router itself. It is strongly recommended that IPv6 configuration and reports include DNS names alongside (or instead of) IPv6 address. Systems on the local network should be automatically given the router address for DNS lookups by DHCPv6. For names that are not on the local network, the router should proxy the DNS queries to the remote service. Firewall Capabilities Home routers should provide at least stateful IPv6 packet filtering to make up for the fact that the address translation and concealment functionality provided by IPv4 NATs is no longer available. Configured Tunnels Configured IPv6-over-IPv4 tunnels can extend native IPv6 connectivity, but given their poor scaling properties and the need for individual provisioning, they are optional. The 6to4 service does require relaying into the native IPv6 Internet, but has better scaling properties for homes. Summary Table 2 summarizes the requirements and recommendations for ensuring that devices meet transparent connectivity requirements. Table 2. Summary of Router Requirements for IPv6 Scenarios ISP / MSO Required / Implementation details scenario Optional Private IPv4 Required Adhere to Teredo-compatible behavior: for example, do Connectivity not implement a symmetric NAT. (Teredo) Support NAT loopback. Allow outbound UDP traffic. Support UPnP. Public IPv4 Required Implement stateless DHCPv6 server. Connectivity Implement 6to4 tunneling functionality. (6to4) Support IPv6 Neighbor Discovery and host autoconfiguration. Native IPv6 Required for Provide both DHCPv6 server and stateful client Connectivity Premium Logo functionality. Support the ISP’s client-to-ISP authentication and encapsulation protocol. Support IPv6 Neighbor Discovery and host autoconfiguration. Native IPv6 Recommended Provide both DHCPv6 server and stateful client Connectivity (Optional) functionality. with Tunneled Support the ISP’s IPv4-over-IPv6 tunneling protocol. IPv4 Provide both IPv6 native LAN functionality and IPv4 native LAN functionality simultaneously, without the one interfering with the other. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 15 Note: It is not necessary to implement all IPv6 services for the WAN interface as part of the Silver logo requirements. Residential Gateways need to be able to work with IPv6 clients on the LAN side, but IPv6 support is not a requirement on the WAN connection. Full support for IPv6 on the WAN interface is an optional requirement for Premium. Discovery and Control The Discovery and Control technology area of Windows Connect Now (as listed in Table 1) ensures that consumers experience effortless discovery of network devices and resources, and that they can securely access and control computers and devices in their home network. Link Layer Topology Discovery Link Layer Topology Discovery (LLTD) is a method for discovering devices on a network and how they are connected without the need for proper IP configuration. The information provided through LLTD will help users and support professionals identify where networking problems are occurring and improve the overall support experience. LLTD consists of a Mapper and a Responder: The Mapper starts the network topology mapping session and interprets the results to draw a topologically correct map, with no need for IP connectivity at any network node. The Responder participates in the mapping session, telling the Mapper of its presence, performing tests requested by the Mapper, and describing the network infrastructure devices to which it is connected and what other devices it has detected. The following describes the operation of the LLTD protocol. Responders operate in one of four states, as shown in Figure 5. Figure 5. Responder Operational States Quiescent. A Responder waits for a Mapper to start the mapping process. After the Responder receives a MapBegin frame, it moves to the Hello state to begin association with a Mapper. Hello. A Responder associates with a Mapper. The Mapper gets a list of the Responders on the network. A generation number (an identifier for the mapping session) is created. Responders avoid network overload on large networks. After association with Mapper is complete, a Responder moves to the Command Loop state. Command Loop. During an active mapping session, devices spend most of their time in the Command Loop state. When the device is connected using a wired 802.3 interface, the interface must enter promiscuous mode; however, this is not necessary for devices that connect using Wi-Fi. Responders execute Emit and Query commands received from a Mapper. After a timeout period or after receiving a command from the Mapper that the map session is complete, the device returns to its usual Quiescent state. Emit. Each entry from the existing list of Emit requests is serviced in turn. A Responder continues to handle incoming protocol frames. While in this state, it drops incoming Emit and Query requests. After all the requests are serviced, the Responder returns to the Command Loop state. To ensure that devices work well with the Windows Vista LLTD protocol, routers and WLAN APs must do the following: Implement LLTD Responder according to the LLTD specification. (See references and resources at the end of this document.) Report properly formatted metadata for mandatory TLVs (Type Length Value pairs) according to LLTD specification. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 16 Meet minimum performance requirements (response time) as described in LLTD specification. Perform primary functions (routing, bridging, and so on) reliably after repeated (>100) consecutive mapping sessions. Issue “already” response after receiving a second MapBegin command when mapping session is already in progress. Requirements for WSD, UPnP, and Auto-Bridge Mode Selection In Windows Vista, the Web Services for Devices (WSD) protocol delivers improved discovery, additional security methods, and rich interoperability with Internet-based Web protocols. To be eligible for a Windows Vista Premium logo, routers and WLAN APs must implement WSD-Discovery. Guidelines for delivering an improved experience with legacy UPnP-based devices are summarized in this section. Figure 4 shows the logical structure of devices and services within the UPnP IGD DCP. UPnP Internet Gateway Device WAN Device WAN Connection Device Layer 3 Port Forwarding Service LAN Device LANHost Config Management Service (Optional) Figure 4. The Logical Structure of Devices and Services within UPnP IGD The following requirements apply for routers and wireless APs: Receive certification for UPnP IGD implementation from the UPnP Implementers Corporation. Ship with UPnP IGD functionality enabled (turned on) on the device’s LAN interface by default. Default enablement must survive a ‘hard’ device reset. Implement the following actions and state variables, and accurately report statistics in order to interoperate with Windows Vista: Implement the GetTotalBytesSent and GetTotalBytesReceived actions contained within the WANDevice virtual device of the UPnP IGD v1.0 DCP. Values returned by these actions must accurately report traffic sent or received across the WAN interface. For more information on proper implementation of Byte Counters, see Appendix B. Populate sufficient metadata in the UPnP device description document to describe the device and its characteristics during discovery. This functionality is recognized by the PnP-X and Function Discovery components of Windows Vista. The required and optional PnP-X metadata are: Required: deviceType, manufacturer, modelName, modelNumber, friendlyName Optional: hardwareID, compatibleID, deviceCategory August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 17 Populating the Optional metadata values is strongly recommended. For more information about PnP-X, see the “Network Connected Devices, Function Discovery and PnP-X” whitepaper. (See references listed at the end of this paper.) Support “Auto-Bridge”— that is, entering a Bridge mode—as follows: The device must continually perform a DHCP IP address assignment request on its WAN interface. If it receives a private address in the range 192.168.x.y, where x and y are any values between 0 and 9, the device must ‘toggle’ (configure) itself into a bridged mode, to prevent the creation of an additional subnet. In this mode, the device will act as a pure WLAN AP on its WAN interface (that is, it will bridge between the LAN and WAN), and as a switch on all wired interfaces. NAT, DHCP address assignment, and IP routing are disabled in Bridge mode. All interfaces must be bridged together when the device enters Bridge mode. The device must ship with Auto-Bridge configuration as its default mode. The vendor can implement the ability to override default settings through the device’s Web interface management UI. However, the device must ship with Auto-Bridge configuration as the default mode (that is, its factory-configured state), and the device must return to this state after a hard device reset. DHCP server on the router assigns addresses from a preset pool in one of the 192.168.x.y/24 networks ( where x is any value between 0 and 9). The UPnP IGD implementation, must support configuration of at least 25 simultaneous port mappings. In the device’s default (factory-shipping) state, all ports numbers must be allowed to be mapped, including well-known ports such as 21, 25, 80, 445, and 3389. An optional service and schema that the device might choose to implement is outlined in Appendix A. Quality of Service The Quality of Service (QoS) component of Windows Connect Now (as listed in Table 1) ensures that home routers, WLAN APs, and wireless routers employ the necessary protocols to report status, diagnose problems, and manage bandwidth on the home network. QoS and qWAVE Network QoS ensures that bandwidth-sensitive applications continue to operate despite bottlenecks or transient network conditions that reduce available bandwidth. To ensure a good experience for media distribution, it is essential to ensure that network infrastructure devices (routers, WLAN APs, and so on) properly implement and follow QoS guidelines, particularly for wireless networks. The implementation of QoS also provides opportunities to introduce new device capabilities that will work well with Windows Vista. A brief description of a QoS-enabled scenario is outlined in this section, followed by the related device requirements for home routers, WLAN APs, and wireless routers to properly implement QoS in Windows Vista. Figure 5 shows the topology of a home network with simultaneous audio/video (AV) and data traffic. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 18 Figure 5. Example Home Network with Simultaneous AV and Data Traffic In this example, there are the following: Two concurrent high-definition video streams are running over the home network from a computer in the den to display devices in the family room and master bedroom. A tablet PC is accessing e-mail over the Internet. A live gaming session is occurring over the Internet. A job is printing on the network printer. Traffic scenarios such as this, with multiple high-quality video streams and multiple data streams, are already appearing and will be increasingly common in the Windows Vista timeframe. Quality Windows Audio Video Experience (qWAVE), the next generation network QoS functionality available in Windows Vista, addresses home AV streaming scenarios that involve real-time, high-priority traffic that shares a single network with best-effort and lowpriority traffic. These scenarios present challenges for network QoS. The challenges are more critical for scenarios involving home networks that use Wi-Fi technology because of bandwidth, stability, and range limitations. qWAVE provides mechanisms to support home AV streaming scenarios such as distributed admission control, intelligent packet prioritization, bandwidth measurement, run-time monitoring and enforcement, and feedback (congestion notification) that can be used by AV applications to provide glitch-free streaming to the user. The qWAVE framework uses standard Layer 2 technologies with little or no dependency on the network hardware infrastructure. The qWAVE solution is independent of the physical media type (fine tuned for 802.3 and 802.11 mediums), and therefore will work on every IP-based network, whether it is wired or wireless. qWAVE will be integrated with solutions that address other issues for successful AV streaming in the home. These solutions include transport mechanisms for AV streaming, such as RTP and RTCP, network diagnostics, troubleshooting, and content discovery and management. The quality of home routers and wireless routers is crucial for AV streaming. Unstable bandwidth, poor reach (distance), intolerance to RF interference, and poor support for QoS through WMM, 802.1Q, and DSCP can cause unacceptable user experiences with AV streaming applications. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 19 QoS Requirements Baseline QoS requirements for routers and WLAN APs are: Must never drop an 802.1Q priority tagged packet or modify the 802.1Q priority tag. Note: 802.1Q refers to the priority field (i.e. formerly 802.1P), not VLAN. Must never add an 802.1Q tag with priority value of zero (0). Best effort (BE) packets must not carry any 802.1Q priority tag. Must never modify the DSCP field of a packet. Premium QoS requirements for routers and WLAN APs are: Must support IEEE 802.1D Annex G for priority mapping (Table 3 collapses this specification into four traffic classes). 802.11 wireless access points and routers must have Wi-Fi WMM certification. Must implement LLTD Responder protocol with time probe (QoS) extensions. See “Link Layer Topology Discovery” earlier in this document. When bridging packets from an 802.3 LAN interface to an 802.11 LAN interface: If an incoming packet contains an 802.1Q priority tag, this tag must be translated to a WMM access category as defined in section 3.3.1 of WMM specification If an incoming packet does not contain an 802.1Q priority tag, but does contain a DSCP value, this value must be translated to a WMM access category as defined by Table 3. If the DSCP value is not one of those listed in Table 3, the best effort (BE) WMM access category must be used. When bridging packets from an 802.11 LAN interface to an 802.3 LAN interface, if association with 802.11 station (STA) is WMM enabled, the WMM access category must be translated to an 802.1Q priority tag as defined by Table 3. Table 3. WMM Access to 802.1Q Priority Translation Description 802.1Q user priority WMM access category Background 1 BK Best Effort 0 BE Video (AV) 5 VI Voice 7 VO DSCP 0x08 0x00 0x28 0x38 Resources and References For questions or comments about these requirements or implementation guidelines, please send e-mail to rtrlogo@microsoft.com. For additional information, see the following references. IEEE Specifications 2004 Bridge Specification: standards.ieee.org/getieee802/download/802.1D-2004.pdf IPv6 IPv6: http://www.ietf.org/rfc/rfc2460.txt Neighbor Discovery: http://www.ietf.org/rfc/rfc2461.txt 6to4: http://www.ietf.org/rfc/rfc3056.txt Microsoft “IPv6 Support in Internet Gateway Devices” white paper: http://www.microsoft.com/whdc/hwdev/tech/network/IPv6_IGD.mspx Microsoft Windows IPv6 Web site: http://www.microsoft.com/ipv6/ For more information about how Teredo works, see “Teredo Overview”: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx At the time of writing, the Teredo Internet draft can be found at http://www.ietf.org/html.charters/ngtrans-charter.html, under the title “Teredo: Tunneling IPv6 over UDP through NATs.” August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 20 Link Layer Topology Discovery (LLTD) WinHEC 2005 presentation: http://www.microsoft.com/whdc/winhec/Pres05.mspx Additional information: http://www.microsoft.com/whdc/device/netAttach/WCN.mspx NAT Network Address Translation information and type descriptions: http://www.ietf.org/html.charters/nat-charter.html and http://www.ietf.org/rfc/rfc3489.txt qWAVE APIs and QoS Whitepaper:http://www.microsoft.com/whdc/device/stream/Home-AVstream.mspx UPnP Device Architecture, IGDv1, and Basic Device: UPnP IGDv1: http://www.upnp.com/standardizeddcps/igd.asp Device Certification: www.upnp-ic.com UPnP Developer Documentation on MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/enus/wcecomm5/html/wce50oriUniversalPlugPlayUPnP.asp UPnP DCPs: http://www.upnp.org/standardizeddcps/default.asp NATs and NAT Traversal in Windows XP: www.microsoft.com/technet/prodtechnol/winxppro/deploy/nattrnsv.mspx Web Services and Web Services for Devices Web Services: http://msdn.microsoft.com/webservices/default.aspx Web Services Feedback Workshops: http://msdn.microsoft.com/webservices/community/workshops/ Web Services Basics: http://msdn.microsoft.com/webservices/understanding/webservicebasics/ Devices Profile for Web Services: http://msdn.microsoft.com/ws/2004/08/devprof WS-Discovery: http://msdn.microsoft.com/ws/2004/10/ws-discovery/ Network Connected Devices, Function Discovery and PnP-X: http://www.microsoft.com/whdc/device/netattach/default.mspx Wi-Fi Alliance Certification http://www.wi-fi.org http://www.wi-fi.org/OpenSection/MediaResources.asp?TID=5 WMM and QoS: http://www.wi-fi.org/OpenSection/pdf/WMM_QoS_whitepaper.pdf 802.11n Q&A: http://www.wi-fi.org/OpenSection/pdf/802.11n_Q_A.pdf WFA certification of 802.11g: http://www.wi-fi.org/OpenSection/pdf/TGG_QA.pdf Windows Connect Now http://www.microsoft.com/whdc/device/netAttach/WCN.mspx Website contents include whitepapers, specification details, and so on. Windows Vista Logo Program Microsoft Windows Vista Logo Program System and Device Requirements, Version 3.0: http://www.microsoft.com/whdc/winlogo/default.mspx Tests for the Windows Vista Logo Program are built into the Microsoft Windows Driver Kit (WDK): http://www.microsoft.com/whdc/driver/WDK/aboutWDK.mspx “Designed for Windows Media Center” Logo Program: http://www.microsoft.com/WindowsXP/MediaCenter/partners/dfw.mspx Xbox Live Whitepaper: http://www.microsoft.com/whdc/winhec/papers04.mspx Router FAQ: http://www.xbox.com/en-AU/live/start/connect/faq/routers.htm Getting Started: http://www.xbox.com/en-nz/live/start/broadband/ Diagnosing Xbox Live! Connections: http://www.xbox.com/enus/live/connect/diagnosing.htm August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 21 Appendix A – DHCP Enable Vendor Extension Schema Routers and wireless routers can also support remote configuration of DHCP services through UPnP. The UPnP IGD LANHostConfigMangement service may be included in the parent UPnP IGD Device to perform these tasks. If such support is implemented, the DHCPConfigurable state variable must be set to 1 as its default setting. Also, if implemented, this service must be configurable such that Subnet Mask, DNS server, Domain Name, Minimum DHCP address, Maximum DHCP address, and Reserved Addresses can be configured via UPnP. In addition, if implemented, the DHCP state must be able to be set by way of the vendor extension actions X_SetDHCPEnabled and X_GetDHCPEnabled. State Variables Variable name X_DHCPEnabled Required or Optional X Data type Boolean Allowed value 0,1 Default value Not specified Eng units N/A R = Required, O = Optional, X = Non-standard. X_DHCPEnabled This variable enables the DHCP services on the LAN interface. If the value is set to 1, the DHCP server will function according to how DHCPRelay variable is set. If the value is set to 0, IGD will not respond to DHCP requests. Eventing and Moderation Variable name Evented X_DHCPEnabled No Actions Action name X_SetDHCPEnabled X_GetDHCPEnabled Moderated event No Max event rate N/A Logical combination N/A Min delta per event N/A Required or Optional X X X_SetDHCPEnabled This action enables or disables the DHCP services on the LAN interface. Arguments Argument NewDHCPEnabled Direction IN relatedStateVariable X_DHCPEnabled Dependency on State (if any) Effect on State (if any) This action enables or disables other actions in this service. Errors errorCode errorDescription 402 Invalid Args 501 Action Failed X_GetDHCPEnabled This action retrieves the current setting of a flag that indicates whether the DHCP services are enabled. Arguments Argument NewDHCPEnabled Direction OUT August 5, 2005 — Version 0.6 relatedStateVariable X_DHCPEnabled Network Infrastructure Device Implementer’s Guide - 22 Dependency on State (if any) Effect on State (if any) None. Errors errorCode errorDescription 402 Invalid Args 501 Action Failed XML Service Description <?xml version="1.0"?> <scpd xmlns="urn:schemas-upnp-org:service-1-0"> <actionList> <action> <name>X_SetDHCPEnabled</name> <argumentList> <argument> <name>NewDHCPEnabled</name> <direction>in</direction> <relatedStateVariable>X_DHCPEnabled</relatedStatevariable> </argument> </argumentList> </action> <action> <name>X_GetDHCPEnabled</name> <argumentList> <argument> <name>NewDHCPEnabled</name> <direction>out</direction> <relatedStateVariable>X_DHCPEnabled</relatedStatevariable> </argument> </argumentList> </action> </actionList> <serviceStateTable> <stateVariable sendEvents="no"> <name>X_DHCPEnabled</name> <dataType>boolean</dataType> </stateVariable> </serviceStateTable> August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 23 Appendix B – UPnP Byte Counter Implementation Details Routers must implement the GetTotalBytesReceived and GetTotalBytesSent actions of the WANCommonInterfaceConfig service of UPnP IGD v1.0 DCP. Because Windows Vista will query these statistics multiple times per second, devices must respond to the actions as fast as possible. For the Windows Vista Premium Logo, devices must respond within 25 ms and be capable of servicing five simultaneous requests, because multiple machines might query the statistics. The 25 ms requirement is based on a WAN connection speed of 2 Mbps since it is accepted that device implementations might not have a fast enough processor to handle full LAN speeds though the WAN link. Common mistakes to check for in your existing implementation: Returning 0. Returning random values. Drastically underreporting the statistics. Some existing devices only report about 30% of the actual traffic. Treating the statistics as signed numbers. UPnP IGD v1.0 requires these numbers to be unsigned. Signed values will be rejected by the schema validation code of UPnP API. Responding very slowing to queries. Some existing devices take over one second to respond. Placing the operation to increment the statistics in a queue. The pitfall with this approach is that it adds latency and the queue can overflow resulting in underreporting. Simple tests to ensure appropriate implementation: Connect the device up to a 2 Mbps+ WAN link and query the statistics. Transfer a file though HTTP and check the statistics at the end. The statistics should be a good representation of the data that was actually transferred. Flood the WAN link though the device and repeatedly query the counters. The device should respond to counter queries within 25 ms and not report any errors. Repeat this test for 12 hours. August 5, 2005 — Version 0.6 Network Infrastructure Device Implementer’s Guide - 24 Appendix C – Guidelines Summary Framework category Setup and Configuration Network and Bus Basics Technology ( = Required, P = Premium qualification, O = Optional) Windows Connect Now - Config WCN-FlashConfig WCN-Config Network or Wi-Fi Wired Router IP Basics Wired router WLAN AP Wireless router n/a - One Required (vendor choice) - One Required (vendor choice) ICMP Response, MTU size, DHCP Lease characteristics, TCP FIN segment response 802.11 Wireless Router Basics Wi-Fi Certified Dualband (a+g) Prolonged throughput for 8 hours, minimal packet loss n/a n/a n/a P P P P 22 Mbps for 2 hours, <1% packet loss Max throughput at 60 ft through 2 walls Web UI accessible on TV screen IPv6, NAT Cone or Restricted (not symmetric) NAT 6to4 tunelling support n/a P P n/a P P n/a P P n/a n/a n/a P P n/a P n/a P UPnP IGD 1.0 present and enabled by default PnP-X metadata population n/a n/a Implement UPnP IGD Byte Counters Auto-Bridge: enter bridge mode on Private WAN IP detection Support Web Services for Devices Discovery Security n/a n/a P n/a P n/a Implement LLTD Responder Device-specifc TLVs: ID NAT state, supply bridge table No dropped 802.1p (q) packets WMM certified n/a Support 802.1q and DSCP Implement LLTD qWave extensions Transparent Connectivity Proxy DNS queries, DNS IPv6 configuration options, Stateless DHCPv6, Native IPv6 on LAN Support Native IPv6 on WAN Simultaneous v6, v4 LAN addressing UPnP IGD, WS-D, Auto-bridge Discovery and Control Identity and Authentication Support WEP and WPA-PSK Link Layer Topology Discovery Management, Quality, Diagnostics, and Support QoS August 5, 2005 — Version 0.6