Router RG Wlan

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.

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.

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

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.

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

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.
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 Internet-
based 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 port-
unreachable 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.
• 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 Wi-
Fi 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 standard-
definition 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
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"
T P1 3 /8"
92'-1
T P3
2 4 '- 0 "
T P2
9 4'-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.

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 Internet-
based 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 peer-
to-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.
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.
• 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.
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 name-
based 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.

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.

• 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
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.

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 low-
priority 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.

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 DSCP
category
Background 1 BK 0x08
Best Effort 0 BE 0x00
Video (AV) 5 VI 0x28
Voice 7 VO 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.”
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/en-
us/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/en-
us/live/connect/diagnosing.htm

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 Required or Data type Allowed Default Eng units
Optional value value
X_DHCPEnabled X Boolean 0,1 Not N/A
specified
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 Moderated Max event Logical Min delta
event rate combination per event
X_DHCPEnabled No No N/A N/A N/A
Actions
Action name Required or Optional
X_SetDHCPEnabled X
X_GetDHCPEnabled X
X_SetDHCPEnabled
This action enables or disables the DHCP services on the LAN interface.
Arguments
Argument Direction relatedStateVariable
NewDHCPEnabled IN 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 Direction relatedStateVariable

NewDHCPEnabled OUT X_DHCPEnabled

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>

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.

Appendix C – Guidelines Summary

Framework category Technology Wired router WLAN AP Wireless router
( = Required, P = Premium
qualification, O = Optional)
Windows Connect Now - Config
Setup and
Configuration WCN-FlashConfig - One Required - One Required
n/a (vendor choice) (vendor choice)
WCN-Config Network or Wi-Fi
Wired Router IP Basics
ICMP Response, MTU size,  n/a 
DHCP Lease characteristics,
TCP FIN segment response
802.11 Wireless Router Basics
Wi-Fi Certified Dualband (a+g) n/a P P
Network and Bus Prolonged throughput for 8 n/a P P
Basics hours, minimal packet loss
22 Mbps for 2 hours, n/a P P
<1% packet loss
Max throughput at 60 ft through n/a P P
2 walls
Web UI accessible on TV n/a P P
screen
IPv6, NAT
Cone or Restricted (not  n/a 
symmetric) NAT
6to4 tunelling support  n/a 
Transparent Proxy DNS queries, DNS IPv6  n/a P
Connectivity configuration options, Stateless
DHCPv6, Native IPv6 on LAN
Support Native IPv6 on WAN P n/a P
Simultaneous v6, v4 LAN  n/a P

addressing
UPnP IGD, WS-D, Auto-bridge
UPnP IGD 1.0 present and  n/a 
enabled by default
PnP-X metadata population  n/a 
Discovery and  n/a 
Implement UPnP IGD Byte
Control
Counters
Auto-Bridge: enter bridge mode  n/a 
on Private WAN IP detection
Support Web Services for P n/a P
Devices Discovery
Identity and Security
Authentication Support WEP and WPA-PSK n/a  
Link Layer Topology Discovery
Implement LLTD Responder   
Device-specifc TLVs: ID NAT   
state, supply bridge table
Management, Quality, QoS
Diagnostics, and No dropped 802.1p (q) packets   
Support
WMM certified n/a  
Support 802.1q and DSCP   
Implement LLTD qWave   

extensions

Router RG Wlan

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Router RG Wlan

Transféré par

Droits d'auteur :

Formats disponibles

Network Infrastructure Device

August 5, 2005 — Version 0.6

© 2005 Microsoft Corporation. All rights reserved.

August 5, 2005 — Version 0.6

August 5, 2005 — Version 0.6

Product Qualification Levels

Technology Framework and Definitions

August 5, 2005 — Version 0.6

August 5, 2005 — Version 0.6

Setup and Configuration

Figure 1. WCN-FlashConfig icon

August 5, 2005 — Version 0.6

Simple Config Overview

Figure 2. Major Components of WCN-Config Network

Registration initiation is ordinarily accomplished by a user action such as powering up the

Requirements for Wireless Routers and WLAP APs

Network and Bus Basics

802.11 Requirements for Premium Logo (Streaming Media)

Requirements for Platform Foundation: Wi-Fi Dual-band Operation

Requirements for Accessibility: Web Page User Interface Usable on TVs

Requirements for Security: WEP and WPA-PSK

Requirements for Reliability: Sustained Throughput at Range for 1 Hour

Figure 3. Test Layout for Wireless Access Point and Stations

Requirements for Reliability: Sustained Throughput for 8 Hours

Requirements for Reliability: Maximum Throughput Stress

August 5, 2005 — Version 0.6

Port Assignment Policy

Port Filtering Policy

IPv6 and Transition Technologies

Private IPv4 Connectivity (Teredo)

Figure 4. Automated Teredo client configuration

Public IPv4 Connectivity (6to4)

Home Router Considerations When Supporting IPv6

August 5, 2005 — Version 0.6

Discovery and Control

Link Layer Topology Discovery

Figure 5. Responder Operational States

August 5, 2005 — Version 0.6

• Meet minimum performance requirements (response time) as described in LLTD

Requirements for WSD, UPnP, and Auto-Bridge Mode

UPnP Internet Gateway Device

The following requirements apply for routers and wireless APs:

QoS and qWAVE

August 5, 2005 — Version 0.6

Figure 5. Example Home Network with Simultaneous AV and Data Traffic

In this example, there are the following:

August 5, 2005 — Version 0.6

Resources and References

August 5, 2005 — Version 0.6

http://www.ietf.org/html.charters/ngtrans-charter.html, under the title “Teredo: Tunneling

August 5, 2005 — Version 0.6

Appendix A – DHCP Enable Vendor Extension

Effect on State (if any)

August 5, 2005 — Version 0.6

NewDHCPEnabled OUT X_DHCPEnabled

Effect on State (if any)

XML Service Description

August 5, 2005 — Version 0.6

Appendix B – UPnP Byte Counter Implementation

Simple tests to ensure appropriate implementation:

August 5, 2005 — Version 0.6

Appendix C – Guidelines Summary