Published Protocols and Royalty-Free License

Published Protocols And Royalty-Free License

Microsoft works with many other companies and industry initiatives to enable Microsoft products to provide interoperability with multiple networks and network services. Network protocols are developed and promoted by a variety of formal standards bodies, industry consortia, and individual companies worldwide. Microsoft actively participates and contributes to the standardization process in many standards bodies and develops implementations to make the Windows operating system interoperable with other products that implement these protocols.

Microsoft has committed to make available certain protocols implemented in Windows, together with whatever intellectual property rights it may have in those protocols, consistent with its obligations under various antitrust case settlements and orders. Some of these protocols are published on MSDN or through standards organizations or other third party sources. (Note: Other unpublished communications protocols are available for licensing through the Microsoft Communications Protocol Program and Work Group Server Protocol Program.)

A Royalty Free Protocol License Agreement is available covering any or all of these published protocols. See the FAQ for more details regarding this license. Neither the publication of this list nor the license is a claim of ownership or intellectual property rights in the protocols listed here. Microsoft may have no intellectual property rights at all with respect to many of these protocols. To the extent that Microsoft has made commitments or is obligated through its participation in standards setting activities to offer licenses on other terms and conditions, Microsoft will also comply with those obligations as well. This royalty-free implementation license is in addition to any other license agreements or programs that may exist or that Microsoft may offer in the future.

Many of the reference documents for the protocols identified below are available online. For each of the communications protocols listed below, a link is included that points to either the most recent version of the specification document (of which Microsoft has been apprised at the time this listing was prepared) or, if not available, to the Web site of the source for the published documentation for the protocol. Third-party sources of this documentation and information are solely responsible for their published information and its availability at these links.

Microsoft disclaims all warranties regarding the documentation for these published protocols, including any warranty that implementation of these protocols or use of this documentation will not violate any third-party rights. Microsoft also may not be the owner or sole owner of the documentation. Accordingly, any licensee under the royalty-free implementation license may also need to secure additional rights from third parties in order to implement these protocols or use this documentation. Please contact such third parties directly to discuss licensing details.

Protocol	Description
AppleTalk	AppleTalk includes protocols that interconnect computer workstations, printers, shared modems, and other computers acting as file servers and print servers. AppleTalk is maintained by Apple Computer, Inc. For information on AppleTalk, see Apple Developer Connection.
Asynchronous Transfer Mode (ATM (UNI 3.0; UNI 4.0; LANE))	The Asynchronous Transfer Mode (ATM (UNI 3.0; UNI 4.0; LANE)) protocol provides a means of digital communication that is capable of very high speeds. It is used for the transport of voice, video, data, and images. ATM is maintained by The ATM Forum. For information on ATM, see: MFA Forum http://www.ipmplsforum.org/ftp/pub/approved-specs/af-lane-0021.000.pdf http://www.ipmplsforum.org/ftp/pub/approved-specs/af-sig-0061.000.pdf
Automatic Web Proxy Detection	The Automatic Web Proxy Detection protocol is used by a client to determine a URL from which to download HTTP proxy and other configuration information. It is typically used by Web clients to locate nearby(caching) Web proxies. For the IETF Internet Draft on Automatic Web Proxy Detection, see Web Proxy Auto-Discovery Protocol.
Background Intelligent Transfer Service (BITS) Upload Protocol	The Background Intelligent Transfer Service (BITS) Upload Protocol implements resumable and rate-throttled transfer of data to an Internet Information Services (IIS) virtual directory. For information on BITS, see Background Intelligent Transfer Service and BITS Upload Protocol.
Bandwidth Allocation Protocol (BAP)	The Bandwidth Allocation Protocol (BAP) manages the number of links in a multilink bundle. BAP defines datagrams to coordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. The RFC for BAP is stored by the Internet Engineering Task Force (IETF). For information on BAP, see RFC 2125: The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP).
Bluetooth	The Bluetooth protocol is a serial bus protocol. The Bluetooth specification is maintained by the Bluetooth Special Interest Group (SIG). For information on the Bluetooth protocol, see Bluetooth.
Bluetooth Hardcopy Cable Replacement Profile (Bluetooth HCRP)	The Bluetooth Hardcopy Cable Replacement Profile (HCRP) protocol is the "wire protocol" for printing to Bluetooth printers. The Bluetooth HCRP specification is maintained by the Bluetooth Special Interest Group (SIG). For information on Bluetooth HCRP, see Bluetooth.
Bluetooth Human Interface Devices (Bluetooth HID)	The Bluetooth Human Interface Devices (HID) protocol defines a set of services that can be used between a host capable of supporting HID devices and a BT-HID device. The Bluetooth HID specification is maintained by the Bluetooth Special Interest Group (SIG). For information on Bluetooth HID, see Bluetooth.
Bluetooth Personal Area Network (Bluetooth PAN)	Bluetooth Personal Area Network (PAN) provides wireless connections by enabling links between mobile computers, mobile phones, portable handheld devices, and connectivity to the Internet. Bluetooth PAN is maintained by Bluetooth. For information on Bluetooth PAN, see Bluetooth.
Bluetooth Radio Frequency Communications (Bluetooth RFCOMM)	The Bluetooth RFCOMM protocol provides emulation of RS232 serial ports over the L2CAP protocol. The Bluetooth RFCOMM specification is maintained by the Bluetooth Special Interest Group (SIG). For information on Bluetooth RFCOMM, see RFCOMM Protocol and Bluetooth.
Callback Control Protocol (CBCP)	The Callback Control Protocol (CBCP) enables automatic callback for a dial-up connection. For an IETF draft of CBCP, see Proposal for Callback Control Protocol (CBCP).
Character Generator Protocol	The Character Generator Protocol is a debugging and measurement tool. A character generator service sends data without regard to the input. The RFC for Character Generator Protocol is stored by the Internet Engineering Task Force (IETF). For information on the Character Generator Protocol, see RFC 864: Character Generator Protocol.
Classless Static Route Option for DHCP	The Classless Static Route Option for DHCP allows the client to query a DHCP server to obtain routing information to enable a remote access client to send traffic to the target network without treating the target network as the default route. For example, this allows a remote client to simultaneously view sites on the Internet as well as sites on the target network. For the IETF Internet Draft on the Classless Static Route Option for DHCP, see http://ftp.isc.org/isc/dhcp/draft-ietf-dhc-csr-06.txt.
Collaboration Data Object for Windows 2000 Protocol Library	Enables Windows XP and Windows 2000 applications to efficiently route e-mail and USENET-style news posts across multiple platforms.
Common Internet File System (CIFS)	The CIFS (Common Internet File System) protocol, a subset of the SMB (Server Message Block) protocol used between Windows clients and servers to request file and print services over a network, is available at Common Internet File System (CIFS/1.0) Protocol. SMB is included in the protocols licensed under the Microsoft Communications Protocol Program.
Compression Control Protocol (CCP)	The Compression Control Protocol (CCP) configures, enables, and disables data compression algorithms on both ends of the point-to-point link. The RFC for CCP is stored by the Internet Engineering Task Force (IETF). For information on CCP, see RFC 1962: The PPP Compression Control Protocol (CCP).
Data Link Control (DLC)	The Data Link Control (DLC) protocol is a transport protocol commonly used for communicating with mainframes. The DLC specification is maintained by IBM. For information on DLC, see Generic Data Link Control Environment Overview.
Daytime Protocol	The Daytime Protocol is a debugging and measurement tool. A daytime service sends the current date and time as a character string without regard to the input. The RFC for Daytime Protocol is stored by the Internet Engineering Task Force (IETF). For information on the Daytime Protocol, see RFC 867: Daytime Protocol.
Differentiated Services (DIFFSERV)	The Differentiated Services (DIFFSERV) protocol provides a framework that enables deployment of scalable service discrimination over the Internet. The RFC for DIFFSERV is stored by the Internet Engineering Task Force (IETF). For information on DIFFSERV, see RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.
Discard Protocol	The Discard Protocol is a debugging and measurement tool. A discard service throws away any data that it receives. The RFC for Discard Protocol is stored by the Internet Engineering Task Force (IETF). For information on the Discard Protocol, see RFC 863: Discard Protocol.
Domain Name System (DNS)	The Domain Name System (DNS) protocol provides a mechanism for naming resources in a way that allows the names to be used on different hosts, networks, protocol families, internets, and administrative organizations. RFCs for DNS are stored by the Internet Engineering Task Force (IETF). For information on DNS, see: RFC 1034: Domain Names - Concepts and Facilities RFC 1035: Domain Names - Implementation and Specification RFC 2181: Clarifications to the DNS Specification RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE) RFC 2782: A DNS RR for specifying the location of services (DNS SRV) RFC 2845: Secret Key Transaction Authentication for DNS (TSIG) RFC 2930: Secret Key Establishment for DNS (TKEY RR) RFC 3007: Secure Domain Name System (DNS) Dynamic Update
Dynamic Host Configuration Protocol (DHCP)	The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. The RFC for DHCP is stored by the Internet Engineering Task Force (IETF). For information on DHCP, see RFC 2131: Dynamic Host Configuration Protocol.
Echo Protocol	The Echo Protocol is a debugging and measurement tool. An echo service sends any data it receives back to the originating source. The RFC for Echo Protocol is stored by the Internet Engineering Task Force (IETF). For information on the Echo Protocol, see RFC 862: Echo Protocol.
File Transfer Protocol (FTP)	The File Transfer Protocol (FTP) allows file transfers. Though usable directly by a user at a terminal, it is designed for use by programs. FTP meets the following objectives: Promotes file sharing (computer programs and/or data) Encourages indirect or implicit (via programs) use of remote computers Shields a user from variations in file storage systems among hosts Transfers data reliably and efficiently The RFC for FTP is stored by the Internet Engineering Task Force (IETF). For information on FTP, see RFC 959: File Transfer Protocol (FTP).
General Event Notification Architecture (GENA)	The General Event Notification Architecture (GENA) provides for the sending of HTTP Notifications using administratively scoped unreliable Multicast UDP. Multicast UDP is useful in that it allows a single notification to be delivered to a potentially large group of recipients using only a single request. For the IETF Internet Draft on GENA see General Event Notification Architecture Base: Client to Arbiter.
HTTP Authentication: Basic and Digest	The HTTP Authentication: Basic and Digest protocol verifies that both parties of a communication know a shared secret (a password). The RFC for HTTP Authentication: Basic and Digest is stored by the Internet Engineering Task Force (IETF). For information on HTTP Authentication: Basic and Digest, see RFC 2617: HTTP Authentication: Basic and Digest Access Authentication.
HTTP Authentication: Simple and Protected GSS_API Negotiation Mechanism (SPNEGO)	The HTTP Authentication: SPNEGO protocol describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS), incorporated in Microsoft Windows 2000, use Kerberos for security enhancements of web transactions. For the IETF Internet Draft on HTTP Authentication: SPNEGO, see RFC 2478: The Simple and Protected GSS-API Negotiation Mechanism.
HyperTerminal Protocols	Provides terminal emulation protocols, file transfer protocols, and character set options for point-to-point communication via a serial (RS-232) link or a TCP/IP link.
Hypertext Transfer Protocol (HTTP)	The Hypertext Transfer (HTTP) protocol is used primarily to transfer data between servers and clients in hypertext/hypermedia environments. HTTP is built upon a request/response model. An HTTP client or its agent, often a Web browser, connects to an HTTP server by using a URL, and requests a resource, such as an HTML document. MIME is then used to encapsulate the requested data, and the data is sent back to the client. Traditionally, HTTP clients and servers communicate over TCP/IP using port 80, the default TCP port assigned to HTTP. However, different ports can be used if the port is specified in the URL. In addition, HTTP can be used with other reliable protocols. HTTP is maintained by the World Wide Web (W3C) Consortium. For information on HTTP, see http://www.w3.org/Protocols/HTTP/.
ICMP Router Discovery Messages	The ICMP Router Discovery Messages protocol specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. The RFC for ICMP Router Discovery Messages is stored by the Internet Engineering Task Force (IETF). For information on ICMP Router Discovery Messages, see RFC 1256: ICMP Router Discovery Messages.
IEC 61883	The IEC 61883 protocol uses the IEEE 1394 standard to specify a digital interface for electronic audio/video equipment. IEC 61883 is maintained by the International Electrotechnical Commission (IEC). For information on IEC 61883, see IEC.
IEEE 802.1x (802.1x)	The 802.1x protocol provides port-based network access control capability. Specifications for 802.1x are maintained by the Institute of Electrical and Electronics Engineers, Inc., (IEEE). For information on 802.1x, see802.1X - Port Based Network Access Control . For information on integrity checks and key encryption calculations for 802.1x, see the radius extensions draft RFC 3580: IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines.
Infrared Data Association Standards (IrDA)	The IrDA standards support a broad range of appliances, computing, and communications devices. The Infrared Data Association is an international organization that creates and promotes interoperable, low cost, infrared data interconnection standards that support a walk-up, point-to-point user model. IrDA standards support a broad range of appliances, computing, and communications devices. IrDA standards are maintained by the Infrared Data Association. For information on IrDA standards, see Infrared Data Association.
Infrared Network (IrNET)	The Infrared Network (IrNET) protocol supports peer-to-peer infrared access through the Point-to-Point Protocol (PPP). IrNET encapsulates PPP packets in IrDA Tiny Transport Protocol (Tiny TP) packets. Tiny TP provides a flow-control mechanism, long packet segmentation, and reassembly for the IrDA Link Management Protocol (IrLMP). Specifications for both Tiny TP and IrLMP are available from the Infrared Data Association. RFCs for PPP are stored by the Internet Engineering Task Force (IETF). For information on PPP, see RFC 1661: The Point-to-Point Protocol (PPP) and RFC 1662:PPP in HDLC-like Framing.
Interface - Parallel (IEEE 1284)	The Interface - Parallel (IEEE 1284) protocol is a signaling method for asynchronous, fully interlocked, bidirectional parallel communications between hosts and printers or other peripherals is defined. A format for a peripheral identification string and a method of returning this string to the host outside of the bi-directional data stream is also specified. Specifications for Interface - Parallel (IEEE 1284) are maintained by the Institute of Electrical and Electronics Engineers, Inc., (IEEE). For information on Interface - Parallel (IEEE 1284) see IEEE Std 1284-1994 IEEE Standard Signaling Method for a Bidirectional Parallel Peripheral Interface for Personal Computers -Description.
Interface - Universal Serial Bus (USB)	The Interface - Universal Serial Bus (USB) Core protocol is an external bus architecture for connecting USB-capable peripheral devices to a host computer. Interface - USB Core is maintained by the USB Implementers Forum. For information on Interface - USB Core, see Universal Serial Bus.
Internet Control Message Protocol (ICMP)	The ICMP protocol is used by Internet nodes and routes to signal networking conditions, as well as for network diagnostics. The RFC for ICMP is stored by the Internet Engineering Task Force (IETF). For information on ICMP, see RFC 792: Internet Control Message Protocol DARPA Internet Program Protocol Specification.
Internet Gopher	The Internet Gopher protocol is designed for distributed document search and retrieval. Where documents (and services) reside on many servers, Gopher client software presents users with a hierarchy of items and directories much like a file system. The Gopher interface is designed to resemble a file system because a file system is a good model for organizing documents and services; the user sees what amounts to one big networked information system that contains primarily document items, directory items, and search items (the latter allow searches for documents across subsets of the information base). The RFC for the Internet Gopher protocol is stored by the Internet Engineering Task Force (IETF). For information on the Internet Gopher protocol, see RFC 1436: The Internet Gopher Protocol (a distributed document search and retrieval protocol).
Internet Group Management Protocol v1, v2(IGMP)	The Internet Group Management Protocol (IGMP v1, v2) is used by IP hosts to report their multicast group memberships to multicast routers. RFCs for IGMP are stored by the Internet Engineering Task Force (IETF). For information on IGMP, see RFC 1112: Host Extensions for IP Multicasting and RFC 2236: Internet Group Management Protocol, Version 2.
Internet Group Management Protocol v3 (IGMP)	The IGMP v3 protocol is used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. For the IETF Internet Draft on IGMP, see: RFC 3376: Internet Group Management Protocol, Version 3.
Internet Information Services (IIS) Application Host COM Protocol	The IIS Application Host COM provides programmatic access to navigate, read and write IIS web server administration and configuration information as stored in the applicationhost.config file.
Internet Printing Protocol (IPP)	The Internet Printing Protocol (IPP) is a standard, application-level protocol that can be used for distributed printing using Internet tools and technologies. IPP uses a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The objects include a Printer object and a Job object. A Job optionally supports multiple documents. IPP 1.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. RFCs for IPP are stored by the Internet Engineering Task Force (IETF). For more information on IPP, see: RFC 2567: Design Goals for an Internet Printing Protocol RFC 2568: Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol RFC 2569: Mapping between LPD and IPP Protocols RFC 2910: Internet Printing Protocol/1.1: Encoding and Transport RFC 2911: Internet Printing Protocol/1.1: Model and Semantics
Internet Protocol Control Protocol (IPCP)	The Internet Protocol Control Protocol (IPCP) configures, enables, and disables the IP protocol modules on both ends of the point-to-point link. The RFC for IPCP is stored by the Internet Engineering Task Force (IETF). For information on IPCP, see RFC 1332: The PPP Internet Protocol Control Protocol (IPCP).
Internet Protocol over Asynchronous Transfer Mode (IP over ATM)	The IP over ATM protocol uses the services of local ATM signaling entities to establish and release ATM connections. The RFCs for IP over ATM are stored by the Internet Engineering Task Force (IETF). For information on IP over ATM, see: RFC 1483: Multiprotocol Encapsulation over ATM Adaptation Layer 5 RFC 1755: ATM Signaling Support for IP over ATM RFC 2225: Classical IP and ARP over ATM
Internet Protocol Security Protocols	Provides privacy and authentication services at the IP layer.
Internetwork Packet Exchange Control Protocol (IPXCP)	The IPXCP protocol configures, enables, and disables the IPX protocol modules on both ends of the point-to-point link. The RFC for IPXCP is stored by the Internet Engineering Task Force (IETF). For information on IPXCP, see RFC 1552: The PPP Internetwork Packet Exchange Control Protocol (IPXCP).
Internetwork Packet Exchange (IPX)	The Internetwork Packet Exchange (IPX) protocol provides a connectionless transport service that is packet-oriented. The Sequenced Packet Exchange SPX protocol relies on the IPX protocol to send and receive packets. IPX is maintained by Novell, Inc. For information on IPX, see Novell: NDK:NetWare Server Protocol Libraries for C Documentation.
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)	The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) provides IPv6 connectivity within an IPv4 intranet. For information on ISATAP, see RFC 4214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
IP Security (IPsec)	The IP Security (IPsec) protocol suite is used to provide privacy and authentication services at the IP layer. RFCs for IPsec are stored by the Internet Engineering Task Force (IETF). For information on IPsec, see: RFC 2401: Security Architecture for the Internet Protocol RFC 2402: IP Authentication Header RFC 2403: The Use of HMAC-MD5-96 within ESP and AH RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV RFC 2406: IP Encapsulating Security Payload (ESP) RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409: The Internet Key Exchange (IKE) RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec RFC 2411: IP Security Document Roadmap RFC 2412: The OAKLEY Key Determination Protocol
IPv4 over High Performance Serial Bus (IEEE 1394)	The 1394 protocol is a standard for a high-performance serial bus that conforms to the CSR architecture (ISO/IEC 13213:1994) and permits communication between nodes over shared physical media. The RFC for 1394 is stored by the Internet Engineering Task Force (IETF). For information on 1394, see RFC 2734: IPv4 over IEEE 1394.
IPv6 over IPv4 (6to4)	The 6to4 router connects IPv6 hosts or sites over the existing IPv4 Internet infrastructure. RFCs for 6to4 are stored by the Internet Engineering Task Force (IETF). For information on 6to4, see RFC 3056: Connection of IPv6 Domains via IPv4 Clouds and RFC 3068: An Anycast Prefix for 6to4 Relay Routers.
Kerberos	The Kerberos protocol provides a means of verifying the identities of principals (for example, a workstation user or a network server) on an open (unprotected) network. RFCs for Kerberos are stored by the Internet Engineering Task Force (IETF). For information on Kerberos, see RFC 1510: The Kerberos Network Authentication Service (V5) and RFC 1964: The Kerberos Version 5 GSS-API Mechanism.
Kerberos Authentication Group Membership Extensions	The Kerberos Authentication Group Membership Extensions extend the Kerberos Authentication Network Service (version 5) specification to support group membership information for the Microsoft Windows operating system. Extensions include the Privilege Access Certificate (PAC) structure, located in the authorization data field of the Kerberos v5 ticket. The RFC for Kerberos is stored by the Internet Engineering Task Force (IETF). For information on Kerberos Authentication Network Service (version 5), see RFC 1510: The Kerberos Network Authentication Service (V5). For information on the use of PAC to supply group membership information, see Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources.
Kerberos Change Password	The Kerberos Change Password protocol is a request/reply protocol that includes a KRB_PRIV message, which contains the user's new password. The original change password protocol does not allow an administrator to set a password for a new user. The RFC for Kerberos Change Password is stored by the Internet Engineering Task Force (IETF). For information on Kerberos Change Password, see RFC 3244: Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols.
Layer Two Tunneling Protocol (L2TP)	The Layer Two Tunneling Protocol (L2TP) defines an encapsulation mechanism for transporting multiple-protocol packets across layer 2 (L2) point-to-point links. The RFC for L2TP is stored by the Internet Engineering Task Force (IETF). For information on L2TP, see RFC 2661: Layer Two Tunneling Protocol "L2TP".
Lightweight Directory Access Protocol (LDAP v3)	The Lightweight Directory Access Protocol (LDAP v3) is a directory access protocol that provides both read and write access. RFCs for LDAP are stored by the Internet Engineering Task Force (IETF). For information on LDAP, see: RFC 2251: Lightweight Directory Access Protocol (v3) RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions RFC 2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names RFC 2254: The String Representation of LDAP Search Filters RFC 2255: The LDAP URL Format RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3
Line Printer Daemon (LPD)	The Line Printer Daemon (LPD) protocol communicates between line printer daemons (clients and servers). The Berkeley versions of the Unix operating system provide line printer spooling with a collection of programs: lpr (assign to queue), lpq (display the queue), lprm (remove from queue), and lpc (control the queue). These programs interact with the line printer daemon autonomous process. The RFC for LPD is stored by the Internet Engineering Task Force (IETF). For information on LPD, see RFC 1179: Line Printer Daemon Protocol.
MD5 Challenge Handshake Authentication Protocol (MD5-CHAP)	The MD5 Challenge Handshake Authentication Protocol (MD5-CHAP) is used to periodically verify the identity of the peer using a three-way handshake. This is done upon initial link establishment, and may be repeated anytime after the link has been established. The RFC for MD5-CHAP is stored by the Internet Engineering Task Force (IETF). For information on MD5-CHAP, see RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP).
Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)	The Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) extends to remote workstations the user authentication functionality provided on networks running the Windows operating system. The RFC for MS-CHAP is stored by the Internet Engineering Task Force (IETF). For information on MS-CHAP, see RFC 2433: Microsoft PPP CHAP Extensions.
Microsoft Point-to-Point Compression (MPPC)	The Microsoft Point-to-Point Compression (MPPC) protocol provides a method to negotiate and use compression protocols over PPP-encapsulated links. The RFC for MPPC is stored by the Internet Engineering Task Force (IETF). For information on MPPC, see RFC 2118: Microsoft Point-To-Point Compression (MPPC) Protocol.
Microsoft Point-To-Point Encryption (MPPE)	The Microsoft Point-To-Point Encryption (MPPE) Protocol is means of representing Point-to-Point Protocol (PPP) packets in an encrypted form, providing enhanced confidentiality of PPP-encapsulated packets. The RFC for MPPE is stored by the Internet Engineering Task Force (IETF). For information on MPPE, see RFC 3078: Microsoft Point-To-Point Encryption (MPPE) Protocol.
Multicast Address Dynamic Client Allocation Protocol (MADCAP)	The Multicast Address Dynamic Client Allocation Protocol (MADCAP) allows hosts to request multicast address allocation services from multicast address allocation servers. The RFC for MADCAP is stored by the Internet Engineering Task Force (IETF). For information on MADCAP, see RFC 2730: Multicast Address Dynamic Client Allocation Protocol (MADCAP).
Multilink Protocol (MP)	The Multilink Protocol (MP) coordinates multiple independent links between a fixed pair of systems to provide a virtual link with greater bandwidth than any of the constituent members. The RFC for MP is stored by the Internet Engineering Task Force (IETF). For information on MP, see RFC 1990: The PPP Multilink Protocol (MP).
NetBIOS Extended User Interface (NetBEUI)	The NetBIOS Extended User Interface (NetBEUI) protocol is the original personal computer networking protocol and interface specified by IBM for their LAN Manager server. The Microsoft protocol NetBIOS Frame (NBF) implements the IBM NetBEUI version 3.0 specification and provides compatibility with LANs that use the NetBEUI protocol. The NBF protocol uses the same network packet formats as the NetBEUI protocol. NetBEUI is maintained by IBM. For information on NetBEUI, see LAN Technical Reference: 802.2 and NetBIOS APIs.
NetBIOS Frames Control Protocol (NBFCP)	The NetBIOS Frames Control Protocol (NBFCP) is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. The RFC for NBFCP is stored by the Internet Engineering Task Force (IETF). For information on NBFCP, see RFC 2097: The PPP NetBIOS Frames Control Protocol (NBFCP).
NetBIOS over Internetwork Packet Exchange (NBIPX)	The NBIPX protocol provides a NetBIOS layer over Internetwork Packet Exchange (IPX). The services provided by NBIPX include: Translating NetBIOS-Names to IPX-addresses mappings. Providing a connection-oriented transport layer on top of a connectionless transport (IPX) layer. NBIPX is maintained by Novell, Inc. For information on NBIPX, see Novell: NDK:NetWare Server Protocol Libraries for C Documentation.
NetBIOS over TCP (NETBT)	The NETBT protocol supports NetBIOS services in a TCP/IP environment. RFCs for NETBT are stored by the Internet Engineering Task Force (IETF). For information on NETBT, see RFC 1001: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts AND Methods and RFC 1002: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications.
Network Access Protection (NAP) Statement of Health (SoH) Messages	The NAP Statement of Health (SoH) message is generated by a System Health Agent (SHA) and is used to represent a snapshot of one or more aspects of a client's health state (for example if Antivirus is installed and enabled).
Packet Internet Groper (ping)	The Packet Internet Groper (ping) command is used to test connectivity between IP hosts. Ping uses a series of Internet Control Message Protocol (ICMP) echo messages to determine whether a remote host is active and what the round-trip delay currently is in communicating with it. The RFC for ping is stored by the Internet Engineering Task Force (IETF). For information on ping, see RRC 1739: A Primer On Internet and TCP/IP Tools.
Password Authentication Protocol (PAP)	The Password Authentication Protocol (PAP) is an authentication protocol that passes the user name and password in plaintext. The RFC for PAP is stored by the Internet Engineering Task Force (IETF). For information on PAP, see RFC 1334: PPP Authentication Protocols.
Point-to-Point (PPP)	The Point-to-Point (PPP) protocol is designed for simple links that transport packets between two peers. The RFC for PPP is stored by the Internet Engineering Task Force (IETF). For information on PPP, see RFC 1661: The Point-to-Point Protocol (PPP).
Point-to-Point over ATM Adaptation Layer 5 (PPPOA)	The Point-to-Point over ATM Adaptation Layer 5 (PPPOA) protocol provides virtual connections between end stations that are attached to the same network. The RFC for PPOA is stored by the Internet Engineering Task Force (IETF). For information on PPOA, see RFC 2364: PPP Over AAL5.
Point-to-Point over Ethernet (PPPOE)	The Point-to-Point over Ethernet (PPPOE) protocol connects a network of hosts over a simple bridging access device to a remote Access Concentrator. The RFC for PPPOE is stored by the Internet Engineering Task Force (IETF). For information on PPPOE, see RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE).
Point-to-Point Tunneling Protocol (PPTP)	The Point-to-Point Tunneling Protocol (PPTP) allows the Point-to-Point Protocol (PPP) to tunnel through an IP network. PPTP does not specify any changes to the PPP protocol, but rather describes a new vehicle for carrying PPP. The RFC for PPTP is stored by the Internet Engineering Task Force (IETF). For information on PPTP, see RFC 2637: Point-to-Point Tunneling Protocol (PPTP).
Post Office Protocol, v3(POP3)	The Post Office Protocol, version 3, (POP3) permits a workstation to dynamically access a maildrop on a server host. The POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it. The RFC for POP3 is stored by the Internet Engineering Task Force (IETF). For information on POP3, see RFC 1939: Post Office Protocol - Version 3.
PPP EAP Transport Level Security Authentication Protocol	The PPP EAP TLS Authentication Protocol is made up of the following: The Point-to-Point Protocol (PPP) provides a standard method for transporting multiple-protocol datagrams over point-to-point links. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. The PPP EAP TLS Authentication Protocol describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mechanisms within EAP. The RFC for PPP EAP TLS Authentication Protocol is stored by the Internet Engineering Task Force (IETF). For information on how EAP-TLS provides for TLS mechanisms within EAP, see RFC 2284: PPP Extensible Authentication Protocol (EAP).
PPP Extensible Authentication Protocol (EAP)	The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication that supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at the link control phase, but rather postpones this until the authentication phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a back-end server, which implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange. The RFC for EAP is stored by the Internet Engineering Task Force (IETF). For information on EAP, see RFC 2284: PPP Extensible Authentication Protocol (EAP).
Pragmatic General Multicast (PGM)	The PGM Protocol is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. The RFC for PGM Protocol is stored by the Internet Engineering Task Force (IETF). For information on PGM Protocol, see RFC 3208: PGM Reliable Transport Protocol Specification.
Preboot Execution Environment (PXE)	The Preboot Execution Environment (PXE) protocol embodies the following three technologies to establish a common and consistent set of preboot services within the boot firmware of Intel architecture systems: A uniform protocol for the client to use to request the allocation of a network address and subsequently request the download of a Network Bootstrap Program (NBP) from a network boot server A set of APIs available in the computer's preboot firmware environment that constitutes a consistent set of services to be employed by the NBP or the BIOS A standard method of initiating the preboot firmware to execute the PXE protocol on the client computer PXE is maintained by the Intel Corporation. For information on PXE, see http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf.
Protocol for Address Space Traversal	Allows a server to allocate addressing and control parameters for a client so that the client retains functionality behind a Network Address Translation (NAT) firewall. The protocol is mainly used by DirectX 8.1.
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)	The Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) protocol enables access to Kerberos-secured services based on initial authentication using public key cryptography. PKINIT uses standard public key signature and encryption data formats within the standard Kerberos messages. For information on PKINIT, see RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT).
Quote of the Day Protocol	The Quote of the Day Protocol is a debugging and measurement tool. A quote of the day service sends a short message, without regard to the input. The RFC for Quote of the Day Protocol is stored by the Internet Engineering Task Force (IETF). For information on the Quote of the Day Protocol, see RFC 865: Quote of the Day Protocol.
Real-Time Transport Protocol (RTP)	The Real-Time Transport Protocol (RTP) provides end-to-end network transport functions that are suitable for applications that transmit real-time data, such as audio, video, or simulation data, over multicast or unicast network services. The RFC for RTP is stored by the Internet Engineering Task Force (IETF). For information on RTP, see RFC 1889: RTP: A Transport Protocol for Real-Time Applications.
Remote LOGIN (rlogin)	The Remote LOGIN (rlogin) protocol provides a remote-echoed, locally flow-controlled virtual terminal with proper output flushing. It is widely used between UNIX hosts because it transports more of the UNIX terminal environment semantics than the Telnet protocol, and because it can be configured not to require password entry by users when connections originate from trusted hosts. The RFC for rlogin protocol is stored by the Internet Engineering Task Force (IETF). For information on rlogin, see RFC 1282: BSD Rlogin.
Remote X/Open Directory Services Remote Protocol	Used by legacy mail clients to access Active Directory™. These methods are described in the rxds interface and allow interactions with a directory.
Resource Reservation Setup (RSVP)	The Resource Reservation Setup (RSVP) protocol is designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows. The RFC for RSVP is stored by the Internet Engineering Task Force (IETF). For information on RSVP, see RFC 2205: Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification.
Routing Information Protocol 1.0, 2.0 (RIP)	The Routing Information Protocol (RIP 1.0, 2.0) exchanges routing information among gateways and other hosts. RFCs for RIP are stored by the Internet Engineering Task Force (IETF). For information on RIP, see RFC 1058: Routing Information Protocol and RFC 2453: RIP Version 2.
Secure Sockets Layer v3 (SSL)	The Secure Sockets Layer (SSL v3) protocol provides communications privacy over the Internet to prevent eavesdropping, tampering, or message forgery between client/server applications. For the IETF Internet Draft on SSL v3, see http://wp.netscape.com/eng/ssl3/draft302.txt.
Sequenced Packet Exchange (SPX)	The Sequenced Packet Exchange (SPX) protocol provides a connection-oriented transport service and lets data travel over an established connection in a reliable, sequenced manner. SPX relies on the Internetwork Packet Exchange (IPX) protocol to send and receive packets. SPX is maintained by Novell, Inc. For information on SPX, see Novell: NDK:NetWare Server Protocol Libraries for C Documentation.
Serial Bus Protocol 2	Used to encapsulate small computer system interface (SCSI) requests over an IEEE (Institute of Electrical and Electronics Engineers) 1394 bus. It provides support for IEEE 1394 printers, CD-ROM, DVD, scanner, and storage devices.
Serial Line Internet Protocol (SLIP)	The SLIP protocol is a packet-framing protocol. SLIP defines a sequence of characters that frame IP packets on a serial line, nothing more. The RFC for SLIP is stored by the Internet Engineering Task Force (IETF). For information on SLIP, see RFC 1055: A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP .
Service Advertising Protocol (SAP)	The Service Advertising Protocol (SAP) is included in the Internetwork Packet Exchange (IPX) protocol. SAP makes the process of adding and removing services on an IPX internetwork dynamic. SAP is maintained by Novell, Inc. For information on SAP, see Novell: NDK:NetWare Server Protocol Libraries for C Documentation.
Simple Authentication and Security Layer (SASL)	The Simple Authentication and Security Layer (SASL) protocol is a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions. RFCs for SASL are stored by the Internet Engineering Task Force (IETF). For information on SASL, see RFC 2222: Simple Authentication and Security Layer (SASL).
Simple Service Discovery Protocol Extensions	Used to detect Universal Plug and Play (UPnP) devices on a network.
Simple Network Management Protocol v2 (SNMP)	The Simple Network Management Protocol (SNMP v2) conveys management information between agents and management stations. Operations of the protocol are carried out under an administrative framework that defines authentication, authorization, access control, and privacy policies. RFCs for SNMP v2 are stored by the Internet Engineering Task Force (IETF). For information on SNMP v2, see: RFC 1901: Introduction to Community-based SNMPv2 RFC 1902: Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1903: Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1904: Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1905: Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1906: Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1907: Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1908: Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets RFC 1157: A Simple Network Management Protocol (SNMP) RFC 1213: Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC 1289: DECnet Phase IV MIB Extensions
Simple Network Time Protocol Extensions	Used to synchronize computer clocks on the Internet (for more information, see RFC 2030: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI ). It is an adaptation of the Network Time Protocol (NTP). Microsoft extensions to SNTP enable digital packet signing and apply only to releases of Windows 2000.
Simple Public-Key GSS-API Mechanism (SPKM)	The Simple Public-Key GSS-API Mechanism (SPKM) protocol is employed by peers implementing the Generic Security Service Application Program Interface (GSSAPI) when using SPKM. SPKM is based on a public-key, rather than a symmetric-key, infrastructure. SPKM provides authentication, key establishment, data integrity, and data confidentiality in an online distributed application environment using a public-key infrastructure. RFCs for SPKM are stored by the Internet Engineering Task Force (IETF). For information on SPKM, see: RFC 2025: The Simple Public-Key GSS-API Mechanism (SPKM) RFC 1508: Generic Security Service Application Program Interface RFC 1509: Generic Security Service API : C-bindings
Simple and Protected GSS-API Negotiation (SPNEGO)	The Simple and Protected GSS-API Negotiation (SPNEGO) protocol negotiates different security mechanisms, different options within a given security mechanism, or different options from several security mechanisms. The RFC for SPNEGO is stored by the Internet Engineering Task Force (IETF). For information on SPNEGO, see RFC 2478: The Simple and Protected GSS-API Negotiation Mechanism.
Small Computer Systems Interface Multimedia Command Set - 2	The SCSI Multimedia Command Set - 2 protocol allows communication with optical devices (for example, CD and DVD). SCSI Multimedia Command Set - 2 is maintained by the National Committee on Interface Technology Standards (NCITS). For information on SCSI Multimedia Command Set - 2, see NCITS T10 1228D: SCSI Multimedia Commands - 2(MMC-2).
Small Computer Systems Interface Multimedia Command Set - 3	The SCSI Multimedia Command Set - 3 protocol allows communication with optical devices (for example,CD and DVD). SCSI Multimedia Command Set - 3 is maintained by the National Committee on Interface Technology Standards (NCITS). For information on SCSI Multimedia Command Set - 3, see NCITS XXX T10/1363-D: SCSI Multimedia Commands - 3(MMC-3).
Small Computer Systems Interface Primary Command Set (SCSI)	The SCSI Primary Command Set protocol allows communication with SCSI peripherals. SCSI Primary Command Set is maintained by the American National Standards Institute (ANSI). For information on SCSI Primary Command Set, see ANSI X3T10 995D Rev. 11: SCSI-3 Primary Commands.
Subnet Bandwidth Manager (SBM)	The Subnet Bandwidth Manager (SBM) protocol is a signaling protocol for RSVP-based admission control over IEEE 802-style networks. SBM provides a method for mapping an Internet-level setup protocol, such as RSVP, onto IEEE 802 networks. The RFC for SBM is stored by the Internet Engineering Task Force (IETF). For information on SBM, see RFC 2814: SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks.
Sun Microsystems Remote Procedure Call (SunRPC)	The Sun Microsystems Remote Procedure Call (SunRPC) protocol forms the basis of many UNIX services, especially Network File System (NFS). For information on SunRPC, see http://docs.sun.com.
T.120	The T.120 standards define the document conferencing and application sharing (sometimes called data conferencing) portion of a multimedia teleconference. The recommendations specify how to efficiently and reliably distribute files and graphical information in real-time during a multipoint multimedia meeting. T.120 is maintained by the International Multimedia Telecommunications Consortium, Inc. (IMTC). For information on T.120, see http://www.itu.int/rec/T-REC-T.120/en.
TCP/IP Extensions	The TCP/IP Extensions protocol [Postel81] was designed to operate over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. It was designed to improve performance and reliability operation over high-speed paths. RFCs for TCP/IP Extensions are stored by the Internet Engineering Task Force (IETF). For information on TCP/IP Extensions, see: RFC 1323: TCP Extensions for High Performance RFC 2018: TCP Selective Acknowledgment Options RFC 2581: TCP Congestion Control RFC 1191: Path MTU Discovery
Telnet Protocol	The Telnet Protocol defines a standard method for interfacing terminal devices and terminal-oriented processes. The RFC for Telnet is stored by the Internet Engineering Task Force (IETF). For information on Telnet, see RFC 854: TELNET Protocol Specification.
Teredo	The Teredo protocol enables computers located behind a Network Access Translation (NAT) to obtain an IPv6 address, which can then be used by IPv6-enabled applications (peer-to-peer applications for example). For the IETF Internet Draft on Teredo, see http://www.microsoft.com/technet/network/ipv6/teredo.mspx.
Trace Route	The Trace Route protocol is a network debugging tool. It has the advantage of being automatically supported by all routers; however, it has two problems: The number of packets it generates The amount of time it takes to run The RFC for Trace Route is stored by the Internet Engineering Task Force (IETF). For information on Trace Route, see RFC 1393: Traceroute Using an IP Option.
Transmission Control Protocol/Internet Protocol v4 (TCP/IP v4)	The TCP/IP v4 protocol is used for host-to-host datagram service in a system of interconnected networks (catenet). RFCs for TCP/IP are stored by the Internet Engineering Task Force (IETF). For information on TCP/IP, see: RFC 791: Internet Protocol DARPA Internet Program Protocol Specification RFC 768: User Datagram Protocol RFC 792: Internet Control Message Protocol DARPA Internet Program Protocol Specification RFC 793: Transmission Control Protocol DARPA Internet Program Protocol Specification RFC 826: An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
Transmission Control Protocol/Internet Protocol v6 (TCP/IP v6)	The TCP/IP v6 protocol is used by nodes to communicate with other nodes across a network, independent of the types of physical links present in the network. RFCs for TCP/IP are stored by the Internet Engineering Task Force (IETF). For information on TCP/IP, see RFC 2460: Internet Protocol, Version 6 (IPv6) Specification and RFC 1180: A TCP/IP Tutorial. IP v6 is the successor to IP v4 (RFC 791). IP v6 is sometimes referred to as IP Next Generation (IPng).
Transport Layer Security (TLS)	The Transport Layer Security (TLS) protocol provides privacy and data integrity between two communicating applications to help prevent eavesdropping, tampering, or message forgery between client/server applications. The RFC for TLS is stored by the Internet Engineering Task Force (IETF). For information on TLS, see RFC 2246: The TLS Protocol Version 1.0.
Trivial File Transfer Protocol (TFTP)	Trivial File Transfer Protocol (TFTP) is a simple protocol that transfers files; it can only read or write files (or e-mail messages) to or from a remote server. The RFC for TFTP is stored by the Internet Engineering Task Force (IETF). For information on TFTP, see RFC 783: The TFTP Protocol (Revision 2).
Universal Plug and Play Internet Gateway Device Extensions	Describe Microsoft® vendor extensions to the XML schema that describes an Internet gateway device. For more information, see the standardized device and services descriptions in the Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0 document at The UPnP Forum.
Universal Plug and Play (UPnP)	The Universal Plug and Play (UPnP) architecture targets peer-to-peer networking of intelligent appliances, wireless devices, and computers of varying form factors. UPnP defines a set of common protocols that devices use to join a network and describe themselves and their capabilities, which enables other devices and people to use them without setup or configuration. UPnP is maintained by the Universal Plug and Play Forum (UPnP Forum). For information on UPnP, see The UPnP Forum.
VTNT Terminal	VTNT terminal emulation is an extension to the Telnet Terminal Type Option standard (RFC 884), which is part of the Telnet protocol family of RFCs. VTNT supports remote Telnet console control by transmitting display coordinates and character attributes using structures defined in the Microsoft Console API For more information, see Character-Mode Applications in the Platform SDK. The VTNT terminal type emulation is selectable at a user console when the Telnet session is launched. VTNT is stored by the Internet Engineering Task Force (IETF). For more information on VTNT, see RFC 884: TELNET Terminal Type Option.
VT-UTF8 and VT100+ Protocols	Used for point-to-point serial communication for terminal control and headless server configuration.
Wireless Provisioning Service Protocol	Provides configuration and service information to a wireless client. The Wireless Provisioning Service protocol authenticates the client using the PEAP TLV protocol and provides the configuration and service information in the form of XML schema. For information about deploying Wireless Provisioning Services (WPS) technology, see Deploying Wireless Provisioning Services (WPS) Technology.