Export (0) Print
Expand All

6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Windows NT operating system

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms SHOULD or SHOULD NOT implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that the product does not follow the prescription.

<1> Section 1.5: The DirectPlay 4 Protocol is available only in Windows operating systems that have the DirectX 6 runtime (from the DirectX 6 Software Development Kit (DirectX SDK)), or later version of the runtime installed. All Microsoft products that are identified as applicable to this protocol in section 6 of this specification meet this requirement.

<2> Section 1.7: The following DirectPlay 4 dialects are natively included in the specified Windows operating systems.

Operating system version

Native dialect version

Windows 2000

DX71VERSION

Windows XP

DX8VERSION

Windows Server 2003

DX8VERSION

Windows Vista

DX9VERSION

Windows Server 2008

DX9VERSION

Windows 7

DX9VERSION

Windows Server 2008 R2

DX9VERSION

Windows 8

DX9VERSION

Windows Server 2012

DX9VERSION

Windows 8.1

DX9VERSION

Windows Server 2012 R2

DX9VERSION

An operating system service pack or out-of-band DirectX redistributable can upgrade the native dialect to a later version. The maximum version to which a dialect can be upgraded is shown in the following table.

Operating system version

Maximum dialect version

Windows 2000

DX9VERSION

Windows XP

DX9VERSION

Windows Server 2003

DX9VERSION

Windows Vista

DX9VERSION

Windows Server 2008

DX9VERSION

Windows Server 2008 R2

DX9VERSION

Windows 8

DX9VERSION

Windows Server 2012

DX9VERSION

Windows 8.1

DX9VERSION

Windows Server 2012 R2

DX9VERSION

The DirectX Software Development Kit (DirectX SDK) provided multiple programming interfaces with names such as IDirectPlay4 and IDirectPlay3, but these do not affect the wire protocol. All interfaces implement the DirectPlay 4 Core and Service Provider Protocol according to the native or upgraded dialect associated with the operating system.

<3> Section 2.2.2: If provided, the Windows Winsock DirectPlay Service Provider stores the following data in the ServiceProviderData field.

2dc6a047-78b5-4eba-a7fe-de0229ce3da4

Figure 5: Windows Winsock DirectPlay Service Provider stores this data in the ServiceProviderData field

Stream Socket Address: A SOCKADDR_IN structure that contains the addressing information to be used when contacting this player over TCP. If the PL flag is set in the Flags field, the Address field of this SOCKADDR_IN must be set to 0.0.0.0.

Datagram Socket Address: A SOCKADDR_IN structure that contains the addressing information to be used when contacting this player over UDP. If the PL flag is set in the Flags field, the Address field of this SOCKADDR_IN must be set to 0.0.0.0.

<4> Section 2.2.3: If the Windows Winsock DirectPlay Service Provider is used, the SL field is set to 0x1 in the PlayerInfoMask field, and the ServiceProviderDataLength field is set to 0x20.

<5> Section 2.2.3: If provided, the Windows Winsock DirectPlay Service Provider stores the following data in the ServiceProviderData field.

2dc6a047-78b5-4eba-a7fe-de0229ce3da4

Figure 6: Windows Winsock DirectPlay Service Provider stores this data in the ServiceProviderData field

Stream Socket Address: A SOCKADDR_IN structure that contains the addressing information to be used when contacting this player over TCP. If the PL flag is set in the Flags field, the Address field of this SOCKADDR_IN must be set to 0.0.0.0.

Datagram Socket Address: A SOCKADDR_IN structure that contains the addressing information to be used when contacting this player over UDP. If the PL flag is set in the Flags field, the Address field of this SOCKADDR_IN must be set to 0.0.0.0.

<6> Section 2.2.4: Windows sets the Size field to 0.

<7> Section 2.2.4: An implementation should support at least one of the values shown in the following table.

Algorithm

Description

OS versions

Reference

CALG_AES

0x00006611

Advanced Encryption Standard (AES). This algorithm is supported by the Microsoft AES Cryptographic Provider.

  • Windows XP SP1

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[FIPS197]

CALG_3DES

0x00006603

Triple Data Encryption Standard (DES) encryption algorithm (3DES).

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

For more information, see the entry for [TDEA] in section 1.2.1.

CALG_DES

0x00006601

Data Encryption Standard (DES).

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[FIPS46-2] and [FIPS46-3]

CALG_RC2

0x00006602

Rivest Cipher 2 (RC2) block encryption algorithm. This algorithm is supported by the Microsoft Base Cryptographic Provider.

  • Windows NT

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[RFC2268]

CALG_RC4

0x00006801

RC4 stream encryption algorithm. This algorithm is supported by the Microsoft Base Cryptographic Provider.

  • Windows NT

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[RC4]

For more information about these encryption algorithms, see [MSDN-ALG_ID].

Implementations MAY choose to support other algorithms and values not shown here; if they do, they should reuse the values specified in [MSDN-CRYPTO] to avoid collisions.

<8> Section 2.2.5: When the OL flag is present, Windows disables the Nagle algorithm for its TCP sockets.

<9> Section 2.2.5: Windows does not initialize the SessionName field to zero when sending; the receiver must ignore the data.

<10> Section 2.2.5: Windows does not initialize the Password field to zero when sending; the receiver must ignore the data.

<11> Section 2.2.28: In Windows, the ShortcutCount field is uninitialized when sent.

<12> Section 2.2.33: If provided, the Windows Winsock DirectPlay Service Provider stores the following data in the SPData field.

2dc6a047-78b5-4eba-a7fe-de0229ce3da4

Figure 7: Windows Winsock DirectPlay Service Provider stores this data in the SPData field.

Stream Socket Address: A SOCKADDR_IN structure that contains the addressing information to be used when contacting this player over TCP. The Address field of this SOCKADDR_IN must be set to 0.0.0.0.

Datagram Socket Address: A SOCKADDR_IN structure that contains the addressing information to be used when contacting this player over UDP. The Address field of this SOCKADDR_IN must be set to 0.0.0.0.

<13> Section 2.2.48: Windows implementations may send nonzero values for the X bitfield.

<14> Section 3.1.1: In Windows, the only supported value for Game.SSPIProvider is NTLM.

<15> Section 3.1.1: In Windows, the Game.CAPIProvider must be one of the following cryptographic provider names.

  • Microsoft Base Cryptographic Provider v1.0

  • Microsoft Enhanced Cryptographic Provider v1.0

  • Microsoft RSA Signature Cryptographic Provider

  • Microsoft Base RSA SChannel Cryptographic Provider

  • Microsoft Enhanced RSA SChannelStrong Cryptographic Provider

  • Microsoft Base DSS Cryptographic Provider

  • Microsoft Base DSS and Diffie-Hellman Cryptographic Provider

  • Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider

  • Microsoft Base DH SChannel Cryptographic Provider

  • Microsoft Enhanced DH SChannel Cryptographic Provider

  • Microsoft Base Smart Card Crypto Provider

<16> Section 3.1.1: In Windows, the Game.CAPIProviderType value must be one of the following values.

  • PROV_RSA_FULL (0x00000001).

  • PROV_RSA_SIG (0x00000002): The PROV_RSA_SIG provider type is a subset of the PROV_RSA_FULL type, it only provides support for hashes and signatures using the RSA signature algorithm.

  • PROV_DSS (0x00000003): The PROV_DSS provider type is a subset of the PROV_RSA_FULL type; it only provides support for hashes and signatures using the DSS signature algorithm.

  • PROV_FORTEZZA (0x00000004): The PROV_FORTEZZA provider type specifies cryptographic protocols and algorithms specified by the National Institute for Standards and Technology.

  • PROV_MS_EXCHANGE (0x00000005): The PROV_MS_EXCHANGE provider type is intended for the needs of Microsoft Exchange.

<17> Section 3.1.1: An implementation should support at least one of the values shown in the following table.

Algorithm

Description

OS versions

Reference

CALG_AES

0x00006611

Advanced Encryption Standard (AES). This algorithm is supported by the Microsoft AES Cryptographic Provider.

  • Windows XP SP1

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[FIPS197]

CALG_3DES

0x00006603

Triple DES encryption algorithm (3DES).

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

For more information, see the entry for [TDEA] in section 1.2.1.

CALG_DES

0x00006601

DES Encryption Standard (DES).

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[FIPS46-2] and [FIPS46-3]

CALG_RC2

0x00006602

RC2 block encryption algorithm (RC2). This algorithm is supported by the Microsoft Base Cryptographic Provider.

  • Windows NT

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[RFC2268]

CALG_RC4

0x00006801

RC4 stream encryption algorithm (RC4). This algorithm is supported by the Microsoft Base Cryptographic Provider.

  • Windows NT

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

[RC4]

For more information about these encryption algorithms, see [MSDN-ALG_ID].

Implementations can choose to support other algorithms and values not shown here; if they do, they should reuse the values specified in [MSDN-CRYPTO] in order to avoid collisions.

<18> Section 3.1.2.1: If no application-defined timer has been set, Windows uses a default timer value of 5 seconds.

<19> Section 3.1.4.16: In DirectPlay library implementations for Windows platforms, encryption and signing services are provided by the Windows platform APIs.

<20> Section 3.1.4.16.2: In Windows, if the DirectPlay client is using the DirectPlay Winsock Service and the higher level did not specify guaranteed delivery, then the datagram (UDP) or message (TCP) must be sent over the protocol (UDP or TCP, respectively) to the socket address associated with the target player.

<21> Section 3.1.5.1: In Windows, the only SSPI provider supported is "NTLM".

<22> Section 3.1.5.5: Windows returns a DPERR_LOGONDENIED error code to the caller when this message is received.

<23> Section 3.1.5.10: If the Windows Sockets DirectPlay provider is used, the SpData field of the DPSP_MSG_ADDFORWARD request contains the IP address and port number that must be used to communicate with the system player.

<24> Section 3.2.5.4: In Windows, the only supported SSPI provider is the NTLM SSPI provider which implements the NT LAN Manager (NTLM) Authentication Protocol, as specified in [MS-NLMP].

<25> Section 3.2.5.5: If the service provider is the Windows Winsock DirectPlay Service Provider, then the DPSP_MSG_ADDFORWARD message must contain the IP address of the sender of the DPSP_MSG_ADDFORWARDREQUEST message and the port number contained in the DPSP_MSG_HEADER.SockAddr field (section 2.2.6).

<26> Section 5.1: DirectPlay actually provides access to end-to-end secure identity using Windows NT security, and it provides for packet encryption and signing. For secure operation, employ that mode.

 
Show:
© 2014 Microsoft