Chapter 4: Point-to-Point Protocol (PPP) 69
Figure 4-3 The structure of the PAP Authenticate-Request message
■ Password Length A 1-byte field that indicates the size of the Password field in bytes.
■ Password A variable-sized field that contains the password of the calling peer.
Figure 4-4 shows the PAP Authenticate-Ack and Authenticate-Nak messages.
Figure 4-4 The structure of the PAP Authenticate-Ack and Authenticate-Nak messages
The following are the fields in the Authenticate-Ack and Authenticate-Nak messages:
■ Code For an Authenticate-Ack message, the value of the Code field is set to 2. For an
Authenticate-Nak message, the value of the Code field is set to 3.
■ Identifier A 1-byte field that is set to the value of the Identifier field in the correspond-
ing Authenticate-Request message.
■ Length A 2-byte field that indicates the size of the PAP message in bytes.
■ Message Length A 1-byte field that indicates the size of the Message field in bytes.
■ Message A variable-sized field that contains a message for the calling peer. The Mes-
sage field is not used by Windows. Some PPP implementations display the message text
to the user who is connecting.
Protocol
Code
. . .
Identifier
Length
= 0xC0-23
. . .
= 1
Peer ID Length
Peer ID
Password
Password Length
Protocol
Code
Identifier

Response message. If the two hashes are identical, the answering peer sends a CHAP
Success message. If not, the answering peer sends a CHAP Failure message and the
connection is terminated.
Figure 4-5 shows the CHAP Challenge and CHAP Response messages.
Figure 4-5 The structure of the CHAP Challenge and CHAP Response messages.
Protocol
Code
Identifier
Length
= 0xC2-23
. . .
Value Size
Name
. . .
Value
Chapter 4: Point-to-Point Protocol (PPP) 71
The following are the fields in the CHAP Challenge and CHAP Response messages:
■ Code A 1-byte field that identifies the type of CHAP message. For a CHAP Challenge
message, the value of the Code field is set to 1. For a CHAP Response message, the value
of the Code field is set to 2.
■ Identifier A 1-byte field that is used to identify a pair or sequence of CHAP messages
(the CHAP session ID). The calling peer sets the value of the Identifier field.
■ Length A 2-byte field that indicates the size of the CHAP message in bytes.
■ Value Size A 1-byte field that indicates the size of the Value field.
■ Value A variable-sized field that contains either the challenge string for the CHAP Chal-
lenge message or the MD5 hash for the CHAP Response message.
■ Name A variable-sized field that contains the name of either the answering peer for the
CHAP Challenge message or the calling peer for the CHAP Response message.
Figure 4-6 shows the structure of the CHAP Success and CHAP Failure messages.
Figure 4-6 The CHAP Success and CHAP Failure message structure

2. The calling peer sends an MS-CHAP v2 Response message that contains the user name
of the calling peer, a challenge string for the answering peer, and an encrypted response
based on the answering peer’s challenge string and the MD4 hash of the user’s
password.
3. The answering peer calculates its own encrypted result based on its challenge string and
the MD4 hash of the user’s password and compares it to the version in the MS-CHAP v2
Response message. If the two results are identical, the answering peer sends a CHAP
Success message with a Message field that contains an encrypted response based on the
calling peer’s challenge string, the answering peer’s challenge string, the calling peer’s
response, the calling peer’s user name, and the calling peer’s password. If the two results
are not identical, the answering peer sends a CHAP Failure message.
4. The calling peer calculates its own encrypted result to validate the answering peer’s
encrypted response. If the results match, the calling peer continues with the next phase
of the PPP connection. If not, the calling peer terminates the connection.
Figure 4-7 shows the structure of the MS-CHAP v2 Response message.
The following are the fields in the MS-CHAP v2 Response message:
■ Code For an MS-CHAP v2 Response message, the value of the Code field is set to 2.
■ Identifier A 1-byte field that is set to the value of the Identifier field in the original
CHAP Challenge message.
■ Length A 2-byte field that indicates the size of the MS-CHAP v2 Response message
in bytes.
■ Value Size A 1-byte field that indicates the size of the CHAP Value field. For the MS-
CHAP v2 Response message, the CHAP Value field consists of the Peer Challenge,
Reserved, Windows NT Response, and Flags fields and is a fixed size of 49 bytes.
■ Peer Challenge A 16-byte field that contains the challenge string for the answering peer
as set by the calling peer.
Chapter 4: Point-to-Point Protocol (PPP) 73
Figure 4-7 The MS-CHAP v2 Response message structure
■ Reserved An 8-byte field that should be set to 0.
■ Windows NT Response A 24-byte field that contains the Windows NT–encoded

Protocol
Code
Identifier
Length
Value Size
Peer Challenge
Reserved
Windows NT Response
Flags
Name
74 Part I: The Network Interface Layer
When EAP is negotiated during phase 1, the LCP option data for the authentication protocol
indicates EAP (0xC2-27). EAP messages use the PPP Protocol ID 0xC2-27.
Because EAP is architecturally designed to support multiple EAP types, additional types can
be added by creating an EAP type dynamic-link library (DLL) file using the EAP Software
Development Kit (SDK), which is part of the Windows Server Platform SDK, and installing
the DLL file on the calling peer and the authenticating server (the server requiring authenti-
cation of the calling peer). The authenticating server is the computer that actually performs
the validation of the calling peer’s credentials and is typically either the answering peer or a
central authentication server, such as a Remote Authentication Dial-In User Service (RADIUS)
server.
Note
Windows Server 2008 and Windows Vista no longer support the EAP-MD5-CHAP
authentication protocol.
EAP defines four types of messages:
1. An EAP-Request message is sent by the authentication server to request information
from the calling peer. There can be multiple EAP-Request messages for an EAP authenti-
cation session.
2. An EAP-Response message is sent by the calling peer to indicate information requested
by the authentication server in an EAP-Request message.

Windows Server 2008 and Windows Vista provide the following EAP types:
■ EAP-TLS (displayed as Smart Card Or Other Certificate when selecting an EAP type)
■ PEAP (displayed as Protected EAP (PEAP) when selecting an EAP type)
Figure 4-9 shows the structure of EAP-Success and EAP-Failure messages.
Table 4-3 EAP Types
Type Value Type Description
1 Identity Used by the authenticating server to request the identity of the call-
ing client (in the EAP-Request/Identity message) and used by the
calling client to indicate its identity to the authenticating server (in
the EAP-Response/Identity message).
2 Notification Used by the authentication server to indicate a displayable message
to the calling peer.
3 Nak Used by a calling peer in a response message to indicate that the
calling peer does not support the authentication type proposed by
the authenticating server. The Nak message also includes a pro-
posed authentication type that is supported by the calling peer.
13 EAP-TLS Used for the messages of the TLS authentication method.
25 PEAP Used for the messages of the PEAP method.
29 EAP-MS-
CHAP-V2
Used for the messages of the MS-CHAP v2 method.
76 Part I: The Network Interface Layer
Figure 4-9 EAP-Success and EAP-Failure message structure
The following are the fields in an EAP-Success and EAP-Failure message:
■ Code For an EAP-Success message, the value of the Code field is set to 3. For an EAP-
Failure message, the value of the Code field is set to 4.
■ Identifier Set to the value of the last EAP-Response message.
■ Length For the EAP-Success and EAP-Failure messages, the Length field is set to 4.
EAP-MS-CHAP v2
The EAP-MS-CHAP v2 type is the MS-CHAP v2 authentication protocol performed using EAP

next phase of the PPP connection. If not, the calling peer terminates the connection.
More Info
EAP-MS-CHAP v2 is described in the Internet draft named draft-kamath-
pppext-eap-mschapv2-01.txt.
EAP-TLS
EAP-TLS is the use of TLS to provide authentication for the establishment of a PPP connec-
tion. TLS is described in RFC 2246 and EAP-TLS is described in RFC 2716. EAP-TLS can pro-
vide mutual authentication (the calling PPP peer authenticates to the authenticating server
and the authenticating server answers to the calling PPP peer), protected negotiation of the set
of cryptographic services used for the connection, and mutual determination of encryption
and signing key material. EAP-TLS uses digital certificates rather than passwords for authenti-
cation, resulting in a highly protected authentication method.
By default in Windows Server 2008 and Windows Vista, EAP-TLS provides two-way, or
mutual authentication. The authenticating server verifies the PPP peer’s certificate and the
PPP peer verifies the certificate of the authenticating server. It is possible to configure the call-
ing peer to not verify the certificate of the authenticating server, but this is not recommended
for security reasons.
The details of EAP-TLS negotiation are beyond the scope of this book. For more details, see
RFCs 2716 and 2246.
PEAP
Although EAP provides authentication flexibility through the use of EAP types, the entire EAP
conversation might be sent as clear text (unencrypted). A malicious user with access to the
path between the negotiating PPP peers can inject packets into the conversation or capture
the EAP messages from a successful authentication for later analysis. For example, an attacker
can capture a successful password-based authentication exchange with MS-CHAP v2, and
then begin attacking the user’s password with an offline dictionary attack.
Protected EAP (PEAP) is an EAP type that addresses this security issue by first creating a
session that is both encrypted and integrity-protected with TLS. Then a new EAP negotiation
with another EAP type occurs, authenticating the user credentials of the PPP client. Because
the TLS session protects EAP negotiation and authentication for the network access attempt,

Option Name Type Length Description
No Callback 1 2 Used to specify that callback is not used
Callback to a User- Specified
Number
2 Variable Used to specify that the calling PPP peer
determines the callback number
Callback to an Administrator-
Defined Number
3 Variable Used to specify that the answering PPP peer
determines the callback number
Callback to Any of a List of
Numbers
4 Variable Used to specify that the answering PPP peer
calls the calling PPP peer back at one of a
list of phone numbers
Chapter 4: Point-to-Point Protocol (PPP) 79
Network Control Protocols
After the callback phase of the PPP connection process, individual NCPs are used to negotiate
the configuration of networking protocols, such as TCP/IP, and the additional PPP facilities of
compression and encryption.
IPCP
IPCP is used to automatically configure TCP/IP configuration for a calling PPP peer. IPCP as
used by Windows-based PPP peers is described in RFCs 1332 and 1877. RFC 1332 defines
the original set of IPCP options and RFC 1877 defines an additional set of options to automat-
ically configure the IP address of name servers such as Domain Name System (DNS) and Win-
dows Internet Name Service (WINS) servers.
IPCP messages use the PPP Protocol ID 0x80-21 and have the same structure as LCP mes-
sages. However, only the first seven LCP message types are used, corresponding to LCP Codes
1 through 7. For the Configure-Request (Code set to 1), Configure-Ack (Code set to 2), Con-
figure-Nak (Code set to 3), and Configure-Reject (Code set to 4) IPCP messages, the data por-

server, to the point-to-point interface of the calling
PPP peer
80 Part I: The Network Interface Layer
By default, a new default route is added to the routing table. This new default route has the
gateway and interface addresses set to the IP address of the PPP interface and has the lowest
routing metric of all the default routes. The routing metric of the existing default route is
increased for the duration of the PPP connection. To prevent this behavior, you can clear the
Use Default Gateway On Remote Network check box on the IP Settings tab in the advanced
TCP/IP settings for the Internet Protocol Version 4 (TCP/IPv4) component for a dial-up or
VPN connection in the Network Connections folder. You can also disable this behavior with
the Connection Manager Administration Kit, provided with Windows Server 2008.
Although DNS server IP addresses are assigned, a DNS domain name is not. To automatically
configure a DNS domain name, PPP calling peers running Windows Server 2008 or Windows
Vista send a Dynamic Host Configuration Protocol (DHCP) DHCPINFORM message on the
PPP link after the PPP connection is established. If the answering peer supports the relaying of
DHCP messages, the answering peer relays the DHCPINFORM message to a DHCP server
and relays the response back to the PPP calling peer. Based on the DNS domain name DHCP
option (Option 15) in the response, the PPP peer automatically configures a DNS domain
name on the point-to-point interface.
Compression Control Protocol
Compression Control Protocol (CCP), described in RFC 1962, allows PPP peers to negotiate
the use of a data compression algorithm. CCP messages use the PPP Protocol 0x80-FD and
have the same structure as LCP messages. However, only the first seven LCP message types
are used, corresponding to LCP Codes 1 through 7. For the Configure-Request (Code set
to 1), Configure-Ack (Code set to 2), Configure-Nak (Code set to 3), and Configure-Reject
(Code set to 4) CCP messages, the data portion of the CCP message contains one or more
CCP options. Table 4-6 lists these CCP options.
MPPE and MPPC
CCP option 18 for MPPC is used to negotiate the use of both MPPC and MPPE, as described
in RFC 3078. The data for CCP option is a 4-byte (32-bit) Supported Bits field that contains

When negotiating MPPC and MPPE, the PPP peers determine a common setting for MPPC
(enabled or disabled), a common highest MPPE encryption strength (the use of 40-bit, 56-bit,
or 128-bit encryption keys), and whether to use stateless MPPE.
MPPE is only possible if the authentication protocol used during the authentication phase is
MS-CHAP v2, EAP-MS-CHAP v2, or EAP-TLS. Only these authentication methods provide
mutually determined keying material that is used as the initial MPPE encryption key.
Both MPPC and MPPE use the same PPP Protocol ID, 0x00-FD. However, each PPP peer
knows whether MPPC, MPPE, or both are being used for frames sent on the PPP connection.
Therefore, for the following cases:
■ If MPPC is used and MPPE is not, the PPP Protocol ID is 0x00-FD and the PPP payload
is decompressed using the MPPC decompression algorithm.
■ If MPPE is used and MPPC is not, the PPP Protocol ID is 0x00-FD and the PPP payload
is decrypted using the MPPE decryption algorithm.
■ If both MPPC and MPPE are used, the PPP payload is always compressed before it is
encrypted. Therefore, the PPP Protocol ID 0x00-FD identifies an MPPE-encrypted pay-
load. The payload is first decrypted using MPPE. The resulting MPPE payload consists
of a PPP header with the PPP Protocol ID set to 0x00-FD and a payload compressed with
MPPC. MPPC decompresses the payload. The resulting MPPC payload consists of a PPP
header with the PPP Protocol ID set to 0x00-21 (assuming an IP datagram).
If the PPP payload is compressed with MPPC or encrypted with MPPE, the PPP payload is not
parsed by Network Monitor. To view PPP payloads with Network Monitor after the PPP con-
nection is created, disable compression and encryption for the PPP connection.
82 Part I: The Network Interface Layer
Encryption Control Protocol
Encryption Control Protocol (ECP), described in RFC 1968, allows PPP peers to negotiate the
use of a data encryption algorithm. ECP messages use the PPP Protocol IDs 0x80-53 or 0x80-
55 and have the same structure as LCP messages. However, because Windows-based PPP
peers only support the use of MPPE for encryption of PPP payloads, ECP is not supported or
used. For more information, see RFC 1968.
Network Monitor Example

28 SEND SEND IPCP Configure-Ack, ID = 6
In this example, the following frames show the four phases of the PPP connection:
■ Frames 1 through 8 and frames 10 and 11 are for phase 1, the LCP negotiation.
■ Frames 9, 12, and 13 are for phase 2, authentication.
■ Frames 14 through 16 are for phase 3, callback.
Chapter 4: Point-to-Point Protocol (PPP) 83
■ Frames 16, 19, 20, and 23 are for CCP negotiation (in phase 4).
■ Frames 18, 21, 22, and 24 through 28 are for IPCP negotiation (in phase 4).
PPP over Ethernet
PPP over Ethernet (PPPoE) is a method of encapsulating PPP frames so that they can be sent
over an Ethernet network. PPPoE was created so that Internet service providers (ISPs) that
deploy a broadband Internet access technology in a bridged Ethernet topology, such as cable
modems or Digital Subscriber Line (DSL), can use the per-user authentication and connec-
tion identification facilities of PPP to identify individual customer connections for accounting
and billing purposes. PPPoE is described in RFC 2516.
PPPoE connections have the following two phases:
1. A discovery phase in which a client computer uses PPPoE frames to discover the pres-
ence of an access concentrator (AC), a device that terminates the cable modem or DSL
connection and provides access to the Internet, and to determine a PPPoE session ID
2. A PPP session phase, in which a PPP connection is established and used for data transfer
in the same way as a dial-up or VPN-based PPP connection
Figure 4-10 shows a PPPoE frame.
Figure 4-10 The structure of a PPPoE frame
40 - 1494 bytes
= 1
= 1
. . .
Preamble
Destination Address
Source Address

1. The PPPoE Active Discovery Initiation (PADI) frame is sent by the PPPoE client to the
Ethernet broadcast address (0xFF-FF-FF-FF-FF-FF). Within the Ethernet payload, the
Code field is set to 9, the Session ID is set to 0, and there is a single Service-Name PPPoE
tag, as well as other tags as needed. If the network connection in the Network Connec-
tions folder corresponding to the broadband Internet adapter has been configured with
a service name, that service name is sent. Otherwise, the PADI frame is sent with a null
service name.
2. The PPPoE Active Discovery Offer (PADO) frame is sent by the AC to the unicast MAC
address of the PPPoE client. Within the Ethernet payload, the Code field is set to 7, the
Session ID is set to 0, there are the AC-Name and Service-Name tags, and other tags as
needed. If the network connection in the Network Connections folder corresponding to
the broadband Internet adapter has not been configured with a service name, it is auto-
matically set to the value of the Service-Name tag in the PADO frame.
3. The PPPoE Active Discovery Request (PADR) frame is sent by the PPPoE client to the
unicast MAC address of the AC. Within the Ethernet payload, the Code field is set to 25,
the Session ID is set to 0, and there is a Service-Name tag and other tags as needed.
Chapter 4: Point-to-Point Protocol (PPP) 85
4. The PPPoE Active Discovery Session-confirmation (PADS) frame is sent by the AC to the
unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is
set to 101, the Session ID field is set to the session ID for the PPP session of the PPPoE
client, and there is a Service-Name tag, as well as other tags as needed.
To terminate the PPPoE session, either the PPPoE client or the AC can send a PPPoE Active
Discovery Terminate (PADT) frame, which contains the Code field set to 167 and the session
ID set to the session being terminated.
PPPoE Session Stage
After the PPPoE discovery process is complete, a PPP connection is negotiated and network
protocol data such as IP datagrams are sent over the PPPoE connection. Figure 4-11 shows a
PPPoE frame that contains a PPP frame.
Figure 4-11 The structure of a PPPoE frame that contains a PPP frame
Because of the additional PPPoE overhead, the maximum size of PPP frames that can be sent

and encryption.
PPPoE is a method of encapsulating PPP frames so that they can be sent over an Ethernet link.
A PPPoE connection consists of two phases: a PPPoE discovery phase and a PPPoE session
phase. After a PPPoE connection is negotiated during the discovery phase, PPP is used to
negotiate a connection and send network protocol frames during the PPPoE session phase.
Part II
Internet Layer Protocols
In this part:
Chapter 5: Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Chapter 6: Internet Control Message Protocol (ICMP) . . . . . . . . . . . . . . .125
Chapter 7: Internet Group Management Protocol (IGMP). . . . . . . . . . . .157
Chapter 8: Internet Protocol Version 6 (IPv6) . . . . . . . . . . . . . . . . . . . . . .179
class="bi x37 y17c we h0"
89
Chapter 5
Internet Protocol (IP)
In this chapter:
Introduction to IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
The IP Datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The IP Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
IP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
IP is the internetworking building block of all the other protocols at the Internet Layer and
above. IP is a datagram protocol primarily responsible for addressing and routing packets
between hosts. This chapter describes the details of the fields in the IP header and their role
in IP packet delivery.
Note
This chapter uses the term to refer to version 4 of IP (IPv4), which is in widespread
use today. IP version 6 is denoted as IPv6.

net Control Message Protocol (ICMP) and Internet Group Management Protocol
(IGMP) and Transport Layer protocols such as Transmission Control Protocol (TCP)
and User Datagram Protocol (UDP).
■ Datagram delivery IP is a datagram protocol that provides a connectionless, unreliable
delivery service for upper layer protocols. Connectionless means that no handshaking
occurs between IP nodes prior to sending data, and no logical connection is created or
maintained at the Internet Layer. Unreliable means that IP sends a packet without
sequencing and without an acknowledgment that the destination was reached. IP
makes a best effort to deliver packets to the next hop or the final destination. End-to-end
reliability is the responsibility of upper-layer protocols such as TCP.
■ Independence from Network Interface Layer At the Internet Layer, IP is designed to be
independent of the network technology present at the Network Interface Layer of the
DARPA model, which encompasses the Open Systems Interconnection (OSI) Physical and
Data Link Layers. IP is independent of OSI Physical Layer attributes such as cabling, signal-
ing, and bit rate. It also is independent of OSI Data Link Layer attributes such as media
access control (MAC) scheme, addressing, and maximum frame size. IP uses a 32-bit
address that is independent of the addressing scheme used at the Network Interface Layer.
■ Fragmentation and reassembly To support the maximum frame sizes of different Net-
work Interface Layer technologies, IP allows for the fragmentation of a payload when
forwarding onto a link that has a lower maximum transmission unit (MTU) than the IP
datagram size. Routers or sending hosts fragment an IP payload, and fragmentation can
occur multiple times. The destination host then reassembles the fragments into the
Chapter 5: Internet Protocol (IP) 91
originally sent IP payload. More information on fragmentation and reassembly are pro-
vided later in this chapter in the section titled “Fragmentation.”
■ Extensible through IP options When features are required that are not available using
the standard IP header, IP options can be used. IP options are appended to the standard
IP header and provide custom functionality, such as the ability to specify a path that an
IP datagram follows through the IP internetwork.
■ Datagram packet-switching technology IP is an example of a datagram packet-switching

1492
92 Part I: Internet Layer Protocols
In Windows Server 2008 and Windows Vista, it is possible to override the MTU as reported to
the Network Driver Interface Specification (NDIS) interface by the network adapter driver
with the following command:
netsh interface ipv4 set interface
InterfaceNameOrIndex
mtu=
MtuSize
InterfaceNameOrIndex
is the name of the interface from the Network Connections folder or
its interface index.
MtuSize
is the IP MTU.
You can also use the following registry value:
MTU
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\Interfaces\
InterfaceGUID

Data type: REG_DWORD
Valid range: 576 - <the MTU reported by the network adapter>
Default: 0xFFFFFFFF (the MTU reported by the network adapter)
Present by default: No
When TCP/IP initializes, it queries its bound NDIS network adapter driver and receives the
MTU. The MTU registry value is used to set an MTU that is lower than the default MTU, as
reported by the NDIS driver, and greater than the minimum value of 576. Values in the MTU
registry value that are greater than the default MTU are ignored. If the MTU registry value is
set to a value less than 576, 576 is used.
It is useful to change the default MTU size for testing or for solving MTU issues in transla-

header
IP header IP payload
Network
Interface
trailer
IP datagram
Network Interface Layer frame
. . .
=4
Version
Internet Header Length
Type of Service
Total Length
Identification
Flags
Fragment Offset
Time-to-Live
Protocol
Header Checksum
Source Address
Destination Address
Options and Padding