Microsoft® Windows® 2000 TCP/IP Protocols and Services Technical Reference

Author Thomas Lee and Joseph Davies Pages 576 Disk 1 Companion CD(s) Level Int/Adv Published 01/05/2000 ISBN 9780735605565 ISBN-10 0-7356-0556-4 Price(USD) $49.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Related Series Related Books About the Author Support: Book & CD Rate this book

Chapter 3: Address Resolution Protocol (ARP)

• Overview of ARP
• The ARP Cache
• Updating the MAC Address
• Windows 2000 ARP Registry Settings
• ARP Frame Structure
• ARP Request and ARP Reply Example
• Gratuitous ARP and Duplicate IP Address Detection
• IP Address Conflict Detection
• The Gratuitous ARP and Address Conflict Exchange
• Inverse ARP (InARP)
• Proxy ARP
• Summary

Chapter 3 Address Resolution Protocol (ARP)

Overview of ARP

The forwarding IP address isn’t necessarily the same as the destination IP address of the IP datagram. As is discussed in detail in Chapter 6, "Internet Protocol (IP) Routing," the result of the route determination process for every outgoing IP datagram is an interface and a forwarding IP address. For direct deliveries to destinations on the same subnet, the forwarding IP address is the datagram’s destination IP address. For indirect deliveries to remote destinations, the forwarding IP address is the IP address of a router on the same subnet as the forwarding host.

IP was designed to be independent of any specific Network Interface Layer technology. Therefore, there’s no way to determine the destination Network Interface Layer address from the forwarding IP address. For example, Ethernet and Token Ring MAC addresses are 6 bytes long, and IP addresses are 4 bytes long. During the manufacturing process, the MAC address is assigned to the adapter. A network administrator assigns the IP address. Because there’s no correlation between the assignment of these two addresses for a given IP node, it’s impossible to derive one address from the other. ARP is a broadcast-based, request-reply protocol that provides a dynamic-resolution facility to map forwarding IP addresses to their corresponding MAC addresses.

ARP consists of the following two messages:

• The forwarding node uses the ARP Request message to request the MAC address for a specific forwarding IP address. The ARP Request is a MAC-level broadcast frame intended to reach all the nodes on the physical network segment to which the interface sending the ARP Request is attached. The node sending the ARP Request is known as the ARP requester.
• The ARP Reply message is used to reply to the ARP requester. The node whose IP address matches the requested IP address in the ARP Request message sends the ARP Reply. The ARP Reply is a unicast MAC frame sent to the destination MAC address of the ARP requester. The node sending the ARP Reply is known as the ARP responder.

Because the ARP Request is a MAC-level broadcast packet, all forwarding IP addresses to be resolved must be directly reachable (on the same subnet) from the interface used to send the ARP Request. For proper routing table entries, this is always the case. If a routing table entry contains an invalid forwarding IP address where that address isn’t directly reachable for the interface, ARP will fail to resolve the forwarding IP address.

All nodes within the same broadcast domain receive the ARP Request. A broadcast domain is a portion of a network over which a broadcast frame is propagated. Hubs, bridges, and, more recently, Layer 2 switches propagate the ARP Request. However, IP routers or Layer 3 switches don’t propagate ARP frames.

The ARP Cache

After the MAC address for a forwarding IP address is determined using an ARP Request-ARP Reply exchange, the resolved MAC address is used as the destination MAC address for subsequent packets. If the node whose IP address has been resolved fails, the ARP requester node will continue to use its ARP cache entry and send packets on the medium to the resolved MAC address. Because the resolved MAC address corresponds to a network adapter that’s no longer present on the network, all of the network segment’s nodes ignore the frame. Because the forwarding IP address was mapped to a MAC address with the ARP cache entry, and the frame was sent on the medium, IP and ARP on the sending node consider the IP datagram to be successfully delivered.

This condition is known as a network black hole; packets sent on the network are dropped and the sender or forwarder is unaware of the condition. The user at the ARP requester computer won’t notice this condition until TCP connections or other types of session-oriented traffic begin to time out. This particular type of network black hole will persist as long as the entry for the mapping remains in the ARP cache. After the entry is removed, an ARP Request-ARP Reply exchange is attempted again. Because the failed node won’t respond to the ARP Request, the lack of an ARP Reply can be used to indicate an unsuccessful delivery of IP packets using the forwarding IP address.

By default, ARP cache entries in Windows 2000 persist for only 2 minutes. If the ARP cache entry is used within 2 minutes, it’s given additional time in 2-minute increments, up to a maximum lifetime of 10 minutes. After a maximum time of 10 minutes, the ARP cache entry is removed and must be resolved through another ARP Request-ARP Reply exchange. The time-out of ARP cache entries is configurable with the ArpCacheLife and ArpCacheMinReferencedLife registry settings.

ArpCacheLife

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–0xFFFFFFFF
Default value: 120
Present by default: No

ArpCacheMinReferencedLife

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–0xFFFFFFFF
Default value: 600
Present by default: No

• If ArpCacheLife is greater than or equal to ArpCacheMinReferencedLife, both used and unused ARP cache entries persist for ArpCacheLife seconds.
• If ArpCacheLife is less than ArpCacheMinReferencedLife, unused ARP cache entries expire in ArpCacheLife seconds, and used entries expire in ArpCacheMinReferencedLife seconds.

In addition, Microsoft Windows 2000 TCP/IP allows the use of static ARP cache entries. Static ARP cache entries can be added through the use of the ARP utility using the "-s" command-line option. Static ARP cache entries don’t time out of the ARP cache. However, static ARP cache entries are stored in RAM and must be added each time TCP/IP is initialized.

While a forwarding IP address is being resolved with ARP, Microsoft Windows 2000 ARP will store only one IP datagram for that forwarding IP address. If multiple datagrams are sent to the same forwarding IP address without pause, it’s possible that some datagrams might be dropped before the ARP exchange completes. This isn’t a problem for TCP connection data, but User Datagram Protocol (UDP) messages might experience packet loss because of this behavior. In this case, use the SendArp() function to create the ARP cache entry prior to sending packets.

Updating the MAC Address

When a network black hole is caused by a failed interface, and when the interface is replaced, the first ARP Request frame sent on that interface will contain the interface’s new MAC address. Upon receipt of that ARP Request, all of the network segment’s nodes that have an ARP cache entry for that node’s IP address will update the ARP cache entry with the new MAC address. The network black hole is removed by the resetting of ARP cache entries when the ARP Request is sent.

Windows 2000 ARP Registry Settings

ArpUseEtherSNAP

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–1
Default value: 0
Present by default: No

For Token Ring, the ArpTRSingleRoute and ArpAlwaysSourceRoute provide control over broadcast ARP Requests in a Token Ring source-routed environment.

ArpTRSingleRoute

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–1
Default value: 0
Present by default: No

A Token Ring source-routed environment is a series of rings connected by source-routing bridges. The rings can be connected so that there are multiple paths to any given node. While this creates fault tolerance for the source-routing bridges, it also causes a problem for all-routes broadcast frames. An all-routes broadcast frame travels all possible paths. If there are five different paths between a node sending an all-routes broadcast frame and a ring, five copies of that all-routes broadcast frame appear on that ring.

To prevent this problem, nodes are configured to send single-route broadcast frames, and source-routing bridges are configured to either propagate single-route or all-routes broadcast frames. With proper design, a network administrator can define a single path over which single-route broadcast traffic travels even though multiple paths exist for all-routes broadcast traffic. Using single-route broadcasts, a Token Ring environment can maintain its fault tolerance while avoiding the duplication of broadcast traffic.

ArpAlwaysSourceRoute

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–1 or not present
Default value: Not present
Present by default: No

ARP Frame Structure

As RFC 826 describes, an ARP frame’s structure suggests that ARP could be used for MAC address resolution for protocols other than IP. However, in practice, IP is the only protocol that uses the ARP frame format. Figure 3-1 shows the structure of the ARP frame.

Figure 3-1. The structure of an ARP frame for LAN technologies.

The fields in the ARP header are defined as follows:

• Hardware Type  A 2-byte field that indicates the type of hardware being used at the Data Link Layer. Table 3-1 lists some commonly used ARP Hardware Type values. Upon receipt of an ARP frame, an IP node verifies that the Hardware Type of the ARP frame matches the Hardware Type of the interface on which the ARP frame was received. If it doesn’t match, the frame is silently discarded. For a complete list of ARP Hardware Type values, see http://www.isi.edu/in-notes/iana/assignments/arp-parameters.

Table 3-1.  ARP Hardware Type Values

Hardware Type Value	Data Link Layer Technology
1 (0x00-01)	Ethernet (10 Mbps)
6 (0x00-06)	IEEE 802 Networks (Token Ring)
15 (0x00-0F)	Frame Relay
16 (0x00-10)	Asynchronous Transfer Mode

• Protocol Type  A 2-byte field that indicates the protocol for which ARP is providing address resolution. The ARP Protocol Type field uses the same values as the Ethernet II EtherType field. For IP address resolution, the Protocol Type field is set to the EtherType for IP, 0x0800. Upon receipt of an ARP frame, an IP node verifies that the ARP Protocol Type is set to 0x0800. If it’s not set to 0x0800, the frame is silently discarded.
• Hardware Address Length  A 1-byte field that indicates the length in bytes of the hardware address in the Sender Hardware Address and Target Hardware Address fields. For Ethernet and Token Ring, the Hardware Address Length field is set to 6. For Frame Relay, the Hardware Address Length typically is set to 2 (for the commonly used 2-byte Frame Relay Address field).
• Protocol Address Length  A 1-byte field that indicates the length in bytes of the protocol address in the Sender Protocol Address and Target Protocol Address fields. For the IP protocol, the length of IP addresses is 4 bytes.
• Operation (Opcode)  A 2-byte field that indicates the type of ARP frame. Table 3-2 lists the commonly used ARP Operation values. For a complete list of ARP Operation values, see http://www.isi.edu/in-notes/iana/assignments/arp-parameters.

Table 3-2.  ARP Operation Values

Operation Value	Type of ARP Frame
1	ARP Request
2	ARP Reply
8	Inverse ARP Request
9	Inverse ARP Reply

• Sender Hardware Address (SHA)  A field that is the length of the value of the Hardware Address Length field and contains the hardware or Data Link Layer address of the ARP frame’s sender. For Ethernet and Token Ring, the SHA field contains the MAC address of the node sending the ARP frame.
• Sender Protocol Address (SPA)  A field that is the length of the value of the Protocol Address Length field and contains the protocol address of the ARP frame’s sender. For IP, the SPA field contains the IP address of the node sending the ARP frame.
• Target Hardware Address (THA)  A field that is the length of the value of the Hardware Address Length field and contains the hardware or Data Link Layer address of the ARP frame’s target (destination). For Ethernet and Token Ring, the THA field is set to 0x00-00-00-00-00-00 for ARP Request frames, and it’s set to the MAC address of the ARP requester for ARP Reply frames.
• Target Protocol Address (TPA)  A field that is the length of the value of the Protocol Address Length field and contains the protocol address of the ARP frame’s target (destination). For IP, the TPA field is set to the IP address being resolved in the ARP Request frame, and it’s set to the IP address of the ARP requester in the ARP Reply frame.

ARP Request and ARP Reply Example

Figure 3-2. The resolution of Node 2’s MAC address by Node 1, using an exchange of ARP Request and ARP Reply frames.

Node 1, with the IP address of 10.0.0.99 and the MAC address of 0x00-60-08-52-F9-D8, needs to forward an IP datagram to Node 2 at the IP address of 10.0.0.1. Based on information in Node 1’s routing table, the forwarding IP address to reach Node 2 is 10.0.0.1, using the Ethernet interface. Node 1 constructs an ARP Request frame and sends it as a MAC-level broadcast using the Ethernet interface.

The following Network Monitor trace (Capture 03-01 in the \Captures folder on the companion CD-ROM) is for the ARP Request frame sent by Node 1.

+ Frame: Base frame properties
ETHERNET: ETYPE = 0x0806 : Protocol = ARP:  Address Resolution Protocol
    + ETHERNET: Destination address : FFFFFFFFFFFF
    + ETHERNET: Source address : 00600852F9D8
      ETHERNET: Frame Length : 42 (0x002A)
      ETHERNET: Ethernet Type : 0x0806 (ARP:  Address Resolution Protocol)
      ETHERNET: Ethernet Data: Number of data bytes remaining = 28 (0x001C)
  ARP_RARP: ARP: Request, Target IP: 10.0.0.1
      ARP_RARP: Hardware Type = Ethernet (10Mb)
      ARP_RARP: Protocol Type = 2048 (0x800)
      ARP_RARP: Hardware Address Length = 6 (0x6)
      ARP_RARP: Protocol Address Length = 4 (0x4)
      ARP_RARP: Opcode = Request
      ARP_RARP: Sender’s Hardware Address = 00600852F9D8
      ARP_RARP: Sender’s Protocol Address = 10.0.0.99
      ARP_RARP: Target’s Hardware Address = 000000000000
      ARP_RARP: Target’s Protocol Address = 10.0.0.1

Upon receipt of the ARP Request frame at Node 2, the node checks the values of the ARP Hardware Type and Protocol Type fields. Node 2 then examines its own ARP cache for an entry matching the SPA. If an entry exists, Node 2 updates the MAC address of the ARP cache entry with the value stored in the SHA. For our example purposes, no entry for 10.0.0.99 exists.

Node 2 then examines the value of the TPA. Because the TPA is the same as Node 2’s IP address, Node 2 adds an ARP cache entry consisting of [SPA, SHA] to its ARP cache. It then checks the ARP Operation field. Because the received ARP frame is an ARP Request, Node 2 constructs an ARP Reply to send back to Node 1.

The following Network Monitor trace (Capture 03-01 in the \Captures folder on the companion CD-ROM) is for the ARP Reply frame sent by Node 2.

+ Frame: Base frame properties
  ETHERNET: ETYPE = 0x0806 : Protocol = ARP:  Address Resolution Protocol
    + ETHERNET: Destination address : 00600852F9D8
    + ETHERNET: Source address : 001054CAE140
      ETHERNET: Frame Length : 60 (0x003C)
      ETHERNET: Ethernet Type : 0x0806 (ARP:  Address Resolution Protocol)
      ETHERNET: Ethernet Data: Number of data bytes remaining = 46 (0x002E)
  ARP_RARP: ARP: Reply, Target IP: 10.0.0.99 Target Hdwr Addr: 00600852F9D8
      ARP_RARP: Hardware Type = Ethernet (10Mb)
      ARP_RARP: Protocol Type = 2048 (0x800)
      ARP_RARP: Hardware Address Length = 6 (0x6)
      ARP_RARP: Protocol Address Length = 4 (0x4)
      ARP_RARP: Opcode = Reply
      ARP_RARP: Sender’s Hardware Address = 001054CAE140
      ARP_RARP: Sender’s Protocol Address = 10.0.0.1
      ARP_RARP: Target’s Hardware Address = 00600852F9D8
      ARP_RARP: Target’s Protocol Address = 10.0.0.99
      ARP_RARP: Frame Padding

Upon receipt of the ARP Reply frame, Node 1 checks the values of the ARP Hardware Type and Protocol Type fields. Node 1 then examines its own ARP cache for an entry matching the SPA. No entry exists; otherwise, an ARP Request would not have been sent. Node 1 then examines the TPA’s value. Because the TPA is the same as Node 1’s IP address, Node 1 adds an ARP cache entry consisting of [SPA, SHA] to its ARP cache. Node 1 then checks the ARP Operation field. Because the received ARP frame is an ARP Reply, the ARP frame is discarded.

Frame Padding and Ethernet

Notice that the ARP frames of Network Monitor trace contain a Frame Padding field. This Frame Padding field isn’t an ARP field, but the consequence of sending an ARP frame on an Ethernet network. As discussed in Chapter 1, "Local Area Network (LAN) Technologies," Ethernet payloads using the Ethernet II encapsulation must be a minimum length of 46 bytes to adhere to the minimum Ethernet frame size. The ARP frame is only 28 bytes long. Therefore, to send the ARP frame on an Ethernet network, the ARP frame must be padded with 18 padding bytes.

Gratuitous ARP and Duplicate IP Address Detection

If a node sends an ARP Request for its own IP address and no ARP Reply frames are received, the node can assume that its assigned IP address isn’t being used by other nodes. If a node sends an ARP Request for its own IP address and an ARP Reply frame is received, the node can determine that its assigned IP address is already being used by another node.

The ArpRetryCount registry setting controls the number of gratuitous ARPs that are sent.

ArpRetryCount

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 1–3
Default value: 3
Present by default: No

IP Address Conflict Detection

On the Offending Node

If the offending node is a Windows 2000 computer manually configured with a conflicting IP address, the receipt of the ARP Reply to the gratuitous ARP will prevent TCP/IP from initializing using the conflicting address. An error message is displayed and an event is logged in the System Event log.

If the offending node is a Windows 2000 computer using Dynamic Host Configuration Protocol (DHCP), gratuitous ARPs are sent for the IP address received in the DHCPOFFER message. If an ARP Reply is received in response to the gratuitous ARPs, the DHCP client sends a DHCPDECLINE message to the DHCP server. If the DHCP server is a Windows 2000 DHCP server, the IP address sent in the DHCPOFFER is flagged as a bad IP address and isn’t allocated to any other DHCP clients. The DHCP client starts the DHCP lease allocation process by sending a new DHCPDISCOVER message. For more information on Windows 2000 DHCP, see Chapter 15, "Dynamic Host Configuration Protocol (DHCP) Service."

On the Defending Node

The defending node detects an address conflict whenever the SPA of the incoming ARP Request is the same as an IP address configured on the defending node. For gratuitous ARPs from an offending node, both the SPA and TPA are set to the conflicting address. However, gratuitous ARPs aren’t the only ARP Requests that can have the SPA set to the conflicting address.

For example, if a node using a conflicting address is started without being connected to its network segment, no replies to the gratuitous ARPs are received and the node will initialize TCP/IP using the conflicting address. If the node is then placed on the same network segment as the defending node, no additional gratuitous ARPs are sent. However, each time either node using the conflicting address sends an ARP Request, the SPA is set to the conflicting address. In this case, an error message is displayed and an event is logged in the System Event log. Both nodes continue to use the conflicting IP address, but display an error message and log an event every time the other node sends an ARP Request.

The Gratuitous ARP and Address Conflict Exchange

1. The offending node attempting to detect another node on the same network segment using the same IP address sends the gratuitous ARP Request.
2. The defending node sends the ARP Reply to the offending node.

When the gratuitous ARP is sent, the SPA is set to a conflicting IP address and the SHA is set to the offending node’s MAC address. Nodes on the network segment that have an ARP cache entry for [conflicting IP address, defending node’s MAC address] will have their ARP cache entries updated to [conflicting IP address, offending node’s MAC address]. The gratuitous ARP sent by the offending node updates all the ARP cache entries for the nodes communicating with the defending node; this causes future IP datagrams to be sent to the offending node’s MAC address. A worst-case scenario is when the defending node is the default gateway for the network segment. Sending the gratuitous ARP Request causes all nodes on that network segment, with an entry in their ARP cache for the default gateway IP address, to forward all traffic off the subnet to the offending node’s MAC address.

When the ARP Reply is sent, it’s sent to the defending node’s MAC address. The unicast ARP Reply doesn’t correct the improper ARP cache entries. Therefore, to reset the ARP cache entries that were improperly updated by the offending nodes’ sending of the gratuitous ARP Request, the defending node sends another broadcast ARP Request. The defending node’s ARP Request is a gratuitous ARP as if the defending node were doing its own conflict detection. The defending node’s ARP Request contains the SHA set to the offending node’s MAC address. Network segment nodes that have had their ARP cache entries improperly set to [conflicting IP address, offending node’s MAC address] are reset to the proper mapping of [conflicting IP address, defending node’s MAC address].

Network Monitor trace 3-2 (Capture 03-02 in the \Captures folder on the companion CD-ROM) shows the gratuitous ARP and address conflict exchange. Frame 1 is the offending node’s gratuitous ARP. Frame 2 is the defending node’s ARP Reply. Frame 3 is the defending node’s gratuitous ARP. At the end of frame 3, all network segment nodes that have the IP address 192.168.0.1 in their ARP caches have been reset to the proper MAC address of 0x00-60-97-02-6D-3D.

Inverse ARP (InARP)

InARP is used to resolve the IP address on the other end of a virtual circuit based on a known Frame Relay DLCI. As RFC 2390 describes, InARP was designed specifically for Frame Relay virtual circuits. Frame Relay link management protocols such as Local Management Interface (LMI) determine which virtual circuits are in use over the physical connection to the Frame Relay service provider. Once the DLCIs are determined, InARP is used to query each virtual circuit to determine the IP address of the interface on the other end. The response to the InARP is used to build a table of entries consisting of [DLCI, forwarding IP address].

Because the DLCI values are only locally significant, the SHA and THA are irrelevant. In both the InARP Request and InARP Reply, the SHA field is typically set to 0 and the TPA field is set to the local DLCI value. The relevant information is the value of the SPA field in the InARP Request and the InARP Reply. The InARP responder uses the InARP Request’s SPA to add an entry to its table consisting of [local DLCI, SPA of InARP Request]. The InARP requester uses the InARP Reply’s SPA to add an entry to its table consisting of [local DLCI, SPA of InARP Reply].

The InARP Request and Reply have the same structure as the ARP Request and Reply, except 2-byte hardware adresses are used. The ARP Operation field is set to 0x0008 for an InARP Request and 0x0009 for an InARP Reply.

Proxy ARP

Figure 3-3. A single subnet configuration, using a Proxy ARP device.

When Node 1 wants to send an IP datagram to Node 2 on the other side of the proxy ARP device, because Node 1 and Node 2 are on the same logical IP subnet, Node 1 sends an ARP Request with Node 2’s IP address as the TPA. The proxy ARP device receives the ARP Request and, even though the TPA isn’t its own address, the proxy ARP device sends an ARP Reply to Node 1 with the proxy ARP device’s MAC address as the SHA. Node 1 then sends the IP datagram to the proxy ARP device’s MAC address. As far as Node 1 is concerned, it has resolved Node 2’s MAC address and delivered the IP datagram to Node 2. The proxy ARP device next delivers the IP datagram to Node 2, using ARP if necessary to resolve Node 2’s MAC address.

The Windows 2000 Routing and Remote Access service uses proxy ARP to facilitate communications between remote access clients and nodes on the network segment to which the remote access server is attached. When IP-based remote access clients connect, the remote access server assigns them an IP address. The IP address assigned can either be from the address range of a subnet to which the remote access server is attached, an on-subnet address, or from the address range of a separate subnet, an off-subnet address. Proxy ARP is used when the remote access server assigns an on-subnet address. An on-subnet address range is used when either the Routing and Remote Access service is configured to use DHCP to obtain addresses, or a range of addresses from a directly attached subnet is manually configured. Figure 3-4 shows an example of a remote access server manually configured with an on-subnet address range.

The subnet to which the remote access server is attached is 10.1.1.0/24, implying a range of usable addresses from 10.1.1.1 through 10.1.1.254. In this case, the network administrator is using the high end of the range (10.1.1.200 through 10.1.1.254) for assignment to remote access clients.

Figure 3-4. A Windows 2000 remote access server, configured with an on-subnet address range using proxy ARP.

When an IP-based remote access client successfully connects and is assigned an IP address, the Routing and Remote Access service tracks the assigned address in a connection table. When a host on the network to which the remote access server is attached sends an ARP Request for the remote access client’s assigned on-subnet IP address, the remote access server answers with an ARP Reply and receives the forwarded IP datagram. The Routing and Remote Access service then forwards the IP datagram addressed to the remote access client over the appropriate remote access connection.

If the remote access server is manually configured with a range of addresses that represents a different subnet (an off-subnet address range), the remote access server acts as an IP router forwarding IP datagrams between separate subnets.

Summary