Chapter 2 Network Services Overview

This chapter introduces some of the changes to some of the network services for this release. In addition, it introduces the role of the network administrator. If you are a new network administrator, the topics covered give you an idea of the tasks you might perform. The chapter then presents fundamental networking concepts that you need to know as you progress through this book. If you are an experienced network administrator, consider reviewing the first section, and skipping the rest. The following topics are explained:

• "What's New for the Solaris 8 Release?"

• "Responsibilities of the Network Administrator"

What's New for the Solaris 8 Release?

The table below shows some of the new features included in this release.

New Version of Logical Link Control Driver

The Class II logical link control driver (llc2) interfaces network software (NetBIOS, SNA, OSI, and so forth), running under the Solaris operating environment to a physical LAN network controlled by one of the supported communications adapters. The llc2 driver, which appears as a driver to the network software, resides in the kernel and is accessed by standard UNIX STREAMS functions.

This version of the llc2 driver includes support for both connectionless and connection-oriented logical link control class II llc2 operations for Ethernet, Token Ring, and FDDI adapters when accessed through the appropriate Solaris MAC layer driver. The Data Link Provider Interface (DLPI) to the llc2 driver enables multiple and different protocol stacks, (including NetBIOS and SNA), to operate simultaneously over one or more local area networks.

To start the llc2 driver by default, rename file /etc/llc2/llc2_start.default to /etc/llc2/llc2_start. This allows the /etc/init.d/llc2/rc2.d/S40llc2 script to build up the configuration file for each ppa interface in /etc/llc2/default/llc2.* and start llc2 on each interface. To verify the configuration files, manually run /usr/lib/llc2/llc2_autoconfig.

For more information on the llc2 driver, see the IEEE standard 802.2 Logical Link Control and the llc2(7) man page.

The llc2 files contain information needed by LLC2 to establish the appropriate links to the underlying MAC layer drivers as well as the parameters necessary to configure the LLC (Logical Link Control) Class II Station Component structures for that link. For more information the llc2 configuration files, see the llc2(4) man page.

The llc2_autoconfig utility is used to generate LLC2 configuration files (/etc/llc2/default/llc2.*). If there is no configuration file in /etc/llc2_default/, it detects all the available interfaces in the system and generates corresponding default configuration files.

If configuration files exist in /etc/llc2_default/, it will check if those interfaces defined in the files still exist. If they do not exist in the system, it sets llc2_on in those files to 0. After this, it detects if there are new interfaces in the system. If there are, it generates configuration files for them. For more information on the llc2_autoconfig utility, see the llc2_autoconfig(1) man page.

The llc2_config utility is used to start/stop the LLC2 subsystem and to configure LLC2 interface parameters. For more information on the llc2_config utility, see the llc2_config(1) man page.

You can use the llc2_loop loopback diagnostics command to test the driver, adapter, and network. For more information on the llc2_loop command, see the llc2_loop(1M) man page.

The llc2_stats command is used to retrieve statistical information from the Host-based Logical Link Control Class 2 component of the LLC2 Driver. Statistics are kept for the station, Service Access Point (SAP), and connection components. For more information on the llc2_stats command, see the llc2_stats(1) man page.

Solaris Network Cache and Accelerator (NCA)

The Solaris Network Cache and Accelerator, NCA, increases web server performance by maintaining an in-kernel cache of web pages accessed during HTTP requests. NCA provides full HTTP support in the kernel by either handling the request or passing it to the web server for processing.

This product is intended to be run on a dedicated web server. Running other large processes on a server running NCA can cause problems.

The NCA feature requires two components.

• Kernel module, ncakmod

• Web server, httpd

ncakmod communicates with a web server, httpd, through a Solaris door (see door_create(3DOOR)). The Solaris doors library offers a fast reliable synchronous RPC mechanism between processes on the same host and between the kernel and a user space process.

ncakmod to httpd protocol is a synchronous, request-response protocol using the Solaris doors remote procedure call (RPC) interface. Door RPC calls originate in the kernel in the NCA and are synchronous. Data is transfered in both directions; that is, from the NCA to the http server and from the http server to the NCA in each door RPC. ncakmod passes HTTP requests to httpd. httpd returns a response to the request over the doors interface. This provides functionality similar to features such as acceptx and sendfile.

NCA logging writes HTTP request data to the disk in binary format. The NCA feature supports the CLF (common log format) log file format.

How to Enable NCA

1. Become superuser.

2. Register the interfaces.

   Enter the names of each of the physical interfaces in the /etc/nca/nca.if file (see the nca.if(4) man page for more information).

   # cat /etc/nca/nca.if hme0 hme1

   For each interface, there must be an accompanying hostname.interface-name file and an entry in /etc/hosts file for the contents of hostname.interface-name. To bring up the NCA feature on all interfaces, place an asterisk, *, in the nca.if file.

3. Enable the ncakmod kernel module.

   Change the status entry in /etc/nca/ncakmod.conf to enabled.

   # cat /etc/nca/ncakmod.conf # # Copyright (c) 1998-1999 by Sun Microsystems, Inc. # All rights reserved. # #ident "@(#)ncakmod.conf 1.1 99/08/06 SMI" # # NCA Kernel Module Configuration File # status=enabled httpd_door_path=/var/run/nca_httpd_1.door

   See the ncakmod.conf(4) man page for more information.

4. Enable NCA logging.

   Change the status entry in /etc/nca/ncalogd.conf to enabled.

   # cat /etc/nca/ncalogd.conf # # Copyright (c) 1998-1999 by Sun Microsystems, Inc. # All rights reserved. # #ident "@(#)ncalogd.conf 1.1 99/08/06 SMI" # # NCA Log Daemon Configuration File # status=enabled logd_path_name="/var/nca/log" logd_file_size=1000000

   You can change the location of the log file by changing the path indicted by the logd_path_name entry. See the ncalogd.conf(4) man page for more information.

5. For IA only: Increase the virtual memory size.

   Use the eeprom command to set the kernelbase of the system.

   # eeprom kernelbase=0x900000000 # eeprom kernelbase kernelbase=0x900000000

   The second command verifies that the parameter has been set.

   ---

   Note -

   This reduces the amount of virtual memory that is available to user processes to less than 3 Gbytes, which means that the system is not ABI-compliant. When the system boots, it will display a message warning you about non-compliance. Most programs do not actually need the full 3 Gbyte virtual address space. If you have a program that does, you need to run it on a system that does not have NCA enabled.

   ---

6. Reboot the server.

How to Disable NCA

1. Become superuser.

2. Disable the ncakmod kernel module.

   Change the status entry in /etc/nca/ncakmod.conf to disabled.

   # cat /etc/nca/ncakmod.conf # # Copyright (c) 1998-1999 by Sun Microsystems, Inc. # All rights reserved. # #ident "@(#)ncakmod.conf 1.1 99/08/06 SMI" # # NCA Kernel Module Configuration File # status=disabled httpd_door_path=/var/run/nca_httpd_1.door

   See the ncakmod.conf(4) man page for more information.

3. Disable NCA logging.

   Change the status entry in /etc/nca/ncalogd.conf to disabled.

   # cat /etc/nca/ncalogd.conf # # Copyright (c) 1998-1999 by Sun Microsystems, Inc. # All rights reserved. # #ident "@(#)ncalogd.conf 1.1 99/08/06 SMI" # # NCA Log Daemon Configuration File # status=disabled logd_path_name="/var/nca/log" logd_file_size=1000000

   See the ncalogd.conf(4) man page for more information.

4. Reboot the server.

How to Enable or Disable NCA Logging

NCA log processing can be turned on or off as needed once NCA has been enabled (see "How to Enable NCA" for more information.)

1. Become superuser.

2. Change NCA log processing.

   To permanently disable logging you need to change the status in /etc/nca/ncalogd.conf to disabled and reboot the system. See the ncalogd.conf(4) man page for more information.

   1. To stop logging:

      Type the following command.

      # /etc/init.d/ncalogd stop

   2. To start logging:

      Type the following command.

      # /etc/init.d/ncalogd start

NCA Files

You need several files to support the NCA feature. Many of these files are ASCII, but some of them are binary. The table below lists all of the files.

Perl 5

Practical Extraction and Report Language (Perl) 5.005_03, a powerful general purpose programming language and generally available as free software, is included in this Solaris release. Perl has emerged as the standard development tool for complex system administration tasks, such as graphic, network, and world wide web programming because of its excellent process, file, and text manipulation features.

Perl 5 includes a dynamically loadable module framework, which allows the addition of new functionality for specific tasks. Many modules are freely available from the Comprehensive Perl Archive Network (CPAN), at http://www.cpan.org. Some of the core modules included with this Solaris Perl installation are CGI, NDBM_File, and Getopt. These modules reside in the /usr/perl5/5.00503 directory. The site_perl directory is initially empty and is intended to store your locally installed Perl 5 modules.

For more information, use the perldoc command to examine the Perl pod (portable documentation) in the /usr/perl5/pod directory, like this:

% cd /usr/perl5/pod 
% /usr/perl5/bin/perldoc perlfaq1.pod

Responsibilities of the Network Administrator

As a network administrator, your tasks generally fall into the following areas:

• Designing and planning the network

• Setting up the network

• Maintaining the network

• Expanding the network

Each task area corresponds to a phase in the continuing life cycle of a network. You might be responsible for all the phases, or you might ultimately specialize in a particular area, for example, network maintenance.

Designing the Network

The first phase in the life cycle of a network involves creating its design, a task not usually performed by new network administrators. Designing a network involves making decisions about the type of network that best suits the needs of your organization. In larger sites this task is performed by a senior network architect: an experienced network administrator familiar with both network software and hardware.

Chapter 5, Planning Your TCP/IP Network describes the factors involved in network design.

Setting Up the Network

After the new network is designed, the second phase of network administration begins, which involves setting up and configuring the network. This consists of installing the hardware that makes up the physical part of the network, and configuring the files or databases, hosts, routers, and network configuration servers.

The tasks involved in this phase are a major responsibility for network administrators. You should expect to perform these tasks unless your organization is very large, with an adequate network structure already in place.

Chapter 6, TCP/IP Administration contains instructions for the tasks involved in this phase of the network life cycle.

Maintaining the Network

The third phase of network administration consists of ongoing tasks that typically constitute the bulk of your responsibilities. They might include:

• Adding new host machines to the network

• Administering network security

• Administering network services, such as NFS^TM services, name services, and electronic mail

• Troubleshooting network problems

"Configuring Network Clients" explains how to set up new hosts on an existing network. "General Troubleshooting Tips" contains hints for solving network problems. For information on network services, refer to Chapter 29, Solaris NFS Environment, Chapter 33, Introduction to Mail Services, the Solaris Naming Administration Guide, and the NIS+ Transition Guide. For security-related tasks, refer to the System Administration Guide, Volume 1.

Expanding the Network

The longer a network is in place and functioning properly, the more your organization might want to expand its features and services. Initially, you can increase network population by adding new hosts and expanding network services by providing additional shared software. But eventually, a single network will expand to the point where it can no longer operate efficiently. That is when it must enter the fourth phase of the network administration cycle: expansion.

Several options are available for expanding your network:

• Setting up a new network and connecting it to the existing network using a machine functioning as a router, thus creating an internetwork

• Configuring machines in users' homes or in remote office sites and enabling these machines to connect over telephone lines to your network

• Connecting your network to the Internet, thus enabling users on your network to retrieve information from other systems throughout the world

• Configuring UUCP communications, enabling users to exchange files and electronic mail with remote machines

"Configuring Routers" contains procedures for setting up an internetwork. "Extending Your Network With PPP" explains how to set up networking connections for nomadic computers. Chapter 25, Overview of UUCP explains how to use UUCP to exchange information between your machine and other UUCP systems.

What is TCP/IP?

A network communications protocol is a set of formal rules that describe how software and hardware should interact within a network. For the network to function properly, information must be delivered to the intended destination in an intelligible form. Because different types of networking software and hardware need to interact to perform the networking function, designers developed the concept of the communications protocol.

The Solaris operating environment includes the software needed for network operations for your organization. This networking software implements the communications protocol suite, collectively referred to as TCP/IP. TCP/IP is recognized as a standard by major international standards organizations and is used throughout the world. Because it is a set of standards, TCP/IP runs on many different types of computers, making it easy for you to set up a heterogeneous network running the Solaris operating environment.

TCP/IP provides services to many different types of computers, operating systems, and networks. Types of networks range from local area networks, such as Ethernet, FDDI, and Token Ring, to wide-area networks, such as T1 (telephone lines), X.25, and ATM.

You can use TCP/IP to construct a network out of a number of local-area networks. You can also use TCP/IP to construct a wide-area network by way of virtually any point-to-point digital circuit.

TCP/IP and its protocol family are fully described in Chapter 4, Overview of TCP/IP.

Types of Hardware That Make Up a Solaris Network

The term local-area network (LAN) refers to a single network of computers limited to a moderate geographical range, such as the floor of a building or two adjacent buildings. A local-area network has both hardware and software components. From a hardware perspective, a basic Solaris LAN consists of two or more computers attached to some form of local-area network media.

Local-Area Network Media

The cabling or wiring used for computer networks is referred to as network media. Figure 2-1 shows four computers connected by means of Ethernet media. In the Solaris LAN environment, Ethernet is the most commonly used local-area network media. Other types of local-area network media used in a Solaris LAN might include FDDI or Token Ring.

Figure 2-1 Solaris Local Area Network

Computers and Their Connectors

Computers on a TCP/IP network use two different kinds of connectors to connect to network media: serial ports, and the ports on the network interface.

Serial Ports

Each computer has at least two serial ports, the connectors that enable you to plug a printer or modem into the computer. The serial ports can be attached to the CPU board, or you might have to purchase them. You use these ports when attaching a modem to the system to establish a PPP or UUCP connection. PPP and UUCP actually provide wide-area network services, since they can use telephone lines as their network media.

Network Interfaces

The hardware in a computer that enables you to connect it to a network is known as a network interface. Many computers come with a preinstalled network interface; others can require you to purchase the network interface separately.

Each LAN media type has its own associated network interface. For example, if you want to use Ethernet as your network media, you must have an Ethernet interface installed in each host to be part of the network. The connectors on the board to which you attach the Ethernet cable are referred to as Ethernet ports. If you plan to use FDDI, each prospective host must have an FDDI network interface, and so on.

This book refers to the default network interface on a host as the primary network interface.

Installing network hardware is outside the scope of this guide. Refer to System Administration Guide, Volume 1 for instructions for configuring serial ports and manuals accompanying network media for installation instructions.

How Network Software Transfers Information

Setting up network software is an involved task. Therefore, it helps to understand how the network software you are about to set up will transfer information.

Figure 2-2 shows the basic elements involved in network communication.

Figure 2-2 How Information Is Transferred on a Network

In this figure, a computer sends a packet over the network media to another computer attached to the same media.

How Information Is Transferred: The Packet

The basic unit of information to be transferred over the network is referred to as a packet. A packet is organized much like a conventional letter.

Each packet has a header, which corresponds to the envelope. The header contains the addresses of the recipient and the sender, plus information on how to handle the packet as it travels through each layer of the protocol suite.

The message part of the packet corresponds to the letter itself. Packets can only contain a finite number of bytes of data, depending on the network media in use. Therefore, typical communications such as email messages are sometimes split into packet fragments.

Who Sends and Receives Information: The Host

If you are an experienced Solaris user, you are no doubt familiar with the term "host," a word often used as a synonym for "computer" or "machine." From a TCP/IP perspective, only two types of entities exist on a network: routers and hosts.

A router is a machine that forwards packets from one network to another. To do this, the router must have at least two network interfaces. A machine with only one network interface cannot forward packets; it is considered a host. Most of the machines you set up on a network will be hosts.

It is possible for a machine to have more than one network interface but not function as a router. This type of machine is called a multihomed host. A multihomed host is directly connected to multiple networks through its network interfaces. However, it does not route packets from one network to another.

When a host initiates communication, it is called a sending host, or the sender. For example, a host initiates communications when its user types rlogin or sends an email message to another user. The host that is the target of the communication is called the receiving host, or recipient. For example, the remote host specified as the argument to rlogin is the recipient of the request to log in.

Each host has three characteristics that help identify it to its peers on the network. These characteristics include:

• Host name

• Internet address, or IP address, the form used in this book

• Hardware address

Host Name

The host name is the name of the local machine, combined with the name of your organization. Many organizations let users choose the host names for their machines. Programs such as sendmail and rlogin use host names to specify remote machines on a network. System Administration Guide, Volume 1 contains more information about host names.

The host name of the machine also becomes the name of the primary network interface. This concept becomes important when you set up the network databases or configure routers.

When setting up a network, you must obtain the host names of all machines to be involved. You will use this information when setting up network databases, as described in "Naming Entities on Your Network".

IP Address

The IP address is one of the two types of addresses each machine has on a TCP/IP network that identifies the machine to its peers on the network. This address also gives peer hosts a notion of where a particular host is located on the network. If you have installed the Solaris operating environment on a machine on a network, you might recall specifying the IP address during the installation process. IP addressing is a significant aspect of TCP/IP and is explained fully in "Designing Your IPv4 Addressing Scheme".

Hardware Address

Each host on a network has a unique hardware address, which also identifies it to its peers. This address is physically assigned to the machine's CPU or network interface by the manufacturer. Each hardware address is unique.

This book uses the term Ethernet address to correspond to the hardware address. Because Ethernet is the most commonly used network media on Solaris-based networks, the text assumes that the hardware address of your Solaris host is an Ethernet address. If you are using other network media, such as FDDI, refer to the documentation that came with your media for hardware addressing information.

Reaching Beyond the Local-Area Network--the Wide-Area Network

As your network continues to function successfully, users might need to access information available from other companies, institutes of higher learning, and other organizations not on your LAN. To obtain this information, they might need to communicate over a wide-area network (WAN), a network that covers a potentially vast geographic area and uses network media such as leased data or telephone lines, X.25, and ISDN services.

A prime example of a WAN is the Internet, the global public network that is the successor to the WANs for which TCP/IP was originally developed. Other examples of WANs are enterprise networks, linking the separate offices of a single corporation into one network spanning an entire country, or perhaps an entire continent. It is entirely possible for your organization to construct its own WAN.

As network administrator, you might have to provide access to WANs to the users on your local net. Within the TCP/IP and UNIX community, the most commonly used public network has been the Internet. Information about directly connecting to the Internet is outside the scope of this book. You can find many helpful books on this subject in a computer bookstore.

Security

Connecting a LAN to a WAN poses some security risks. You must make sure your network is protected from unauthorized use, and control access to data and resources. An overview of security issues is provided in the System Administration Guide, Volume 1. Further help can be found in Firewalls and Internet Security by William R. Cheswick and Steven M Bellovin (Addison Wesley, 1994).

You can also become informed by subscribing to majordomo@greatcircle.com, citing subscribe firewalls in the text. If you prefer the shorter version, cite firewalls_digest in the text.

TCP Large Window Support

TCP large windows provides the support described in RFC1323. This support is designed to improve performance over large bandwidth or delay networks such as ATM or satellite networks by using windows that exceed the normal 65535 limit.

This support expands the amount of data that can be outstanding in a TCP session from 65,535 bytes to approximately 1 Gigabyte.

TCP large window supports a number of TCP configuration parameters that allow a system administrator to enable the use of enhanced send and receive window sizes and the RFC1323 timestamp option, without having to modify the applications. These changes can be made on a system-wide basis or can be customized for particular hosts or networks. This is especially useful when using standard network utilities such as ftp and rcp which do not provide facilities to increase the buffer sizes they use.

TCP Large Window Parameters

The configuration parameters are associated with the TCP device, /dev/tcp, and can be inspected or modified using ndd(1M). Normally, these parameters would be set in one of the shell scripts executed by init(1M) when the system is booted (see init.d(4) for information on how to add a new script).

A list of the available parameters and their meanings are shown below.

tcp_xmit_hiwat

Specifies the default value for a connection's send buffer space. The default is 8K.

tcp_recv_hiwat

Specifies the default value for a connection's receive buffer space; that is, the amount of buffer space allocated for received data (and thus the maximum possible advertised receive window). The default is 8K.

tcp_wscale_always

If this parameter is nonzero, a window scale option is always sent when connecting to a remote system. Otherwise, the option is sent if-and-only-if the user has requested a receive window larger than 64K. The default is zero.

Regardless of the value of this parameter, a window scale option is always included in a connect acknowledgment if the connecting system has used the option.

tcp_tstamp_always

If this parameter is nonzero, a timestamp option is always sent when connecting to a remote system. The default is zero.

Regardless of the value of this parameter, a timestamp option is always included in a connect acknowledgment (and all succeeding packets) if the connecting system has used the option.

tcp_tstamp_if_wscale

If this parameter is nonzero, the timestamp option is sent when connecting to a remote system if the user has requested a receive window larger than 64K (that is, if a window scale option with a nonzero scale is being used). The default is zero.

tcp_max_buf

Specifies the maximum buffer size a user is allowed to specify with the SO_SNDBUF or SO_RCVBUF options. Attempts to use larger buffers fail with EINVAL. The default is 256K. It is unwise to make this parameter much larger than the maximum buffer size your applications require, since that could allow malfunctioning or malicious applications to consume unreasonable amounts of kernel memory.

tcp_host_param

This parameter is a table of IP addresses, networks, and subnetworks, along with default values for certain TCP parameters to be used on connections with the specified hosts. The table can be displayed with the ndd command as follows:

example# ndd /dev/tcp tcp_host_param Hash HSP Address Subnet Mask Send Receive TStamp 027 fc31eea4 129.154.000.000 255.255.255.000 0000008192 0000008192 0 131 fc308244 129.154.152.000 000.000.000.000 0000032000 0000032000 0 133 fc30bd64 129.154.152.006 000.000.000.000 0000128000 0000128000 1

Each element in the table specifies either a host, a network (with optional subnet mask), or a subnet, along with the default send buffer space and receive buffer space, and a flag indicating whether timestamps are to be used.

The default values specified in the table are used for both active and passive connections (that is, both connect() and listen()). The most applicable match found is used; first the full host address, then the subnet, and finally the network. For subnet recognition to work properly, there must be an entry for that subnet's network that specifies the subnet mask.

The example table above specifies that:

• Connections with host 129.154.152.6 uses send and receive buffer sizes of 128000 bytes, and uses timestamps.

• Connections with other hosts on the 129.154.152 subnet uses send and receive buffer sizes of 32000 bytes.

• Connections with other hosts on the 129.154 network uses send and receive buffer sizes of 8192 bytes.

Elements are added to or removed from the table with ndd as follows:

ndd -set /dev/tcp tcp_host_param '<command>'

 
<ipaddr>	[ mask <ipmask>] [ sendspace <integer> ]
				[ recvspace <integer> ] [ timestamp { 0 | 1 } ]

or

<ipaddr> delete

For example, the table above was created by:

# ndd -set /dev/tcp tcp_host_param '129.154.0.0 mask 255.255.255.0
        sendspace 8192 recvspace 8192'
# ndd -set /dev/tcp tcp_host_param '129.154.152.0 sendspace 32000
        recvspace 32000'
# ndd -set /dev/tcp tcp_host_param '129.154.152.6 sendspace 128000
        recvspace 128000 timestamp 1'

The example commands above have been broken over two lines. Each command should be entered on one line.

It could be removed using these commands:

 
# ndd -set /dev/tcp tcp_host_param '129.154.152.6 delete'
# ndd -set /dev/tcp tcp_host_param '129.154.152.0 delete'
# ndd -set /dev/tcp tcp_host_param '129.154.0.0 delete'

Networks and subnets are specified by leaving the host bits zero. The same syntax used to add entries can also be used to modify existing entries.

The send and receive space values from the tcp_host_param table are only used if they are larger than the values set by the user (or obtained from tcp_xmit_hiwat and tcp_recv_hiwat). This is so that the user can specify larger values for improved throughput and not have them erroneously reduced.

If timestamp value in the tcp_host_param table is 1, the timestamp option is sent to the selected host or hosts when a connection is initiated. However, if the value is 0, the timestamp option might still be sent, depending on the settings of the tcp_tstamp_always and tcp_tstamp_if_wscale options.

TCP Selective Acknowledgment Support

The TCP selective acknowledgment (TCP SACK) provides the support described in RFC 2018 to solve the problems related to congestion and multiple packet drops especially in applications making use of TCP large windows (RFC 1323) over satellite links or transcontinental links. See RFC 2018 for complete details on TCP SACK.

The configuration parameter is associated with the TCP device, /dev/tcp, and can be inspected or modified using ndd(1M). Normally, this parameter would be set in one of the shell scripts executed by init(1M) when the system is booted (see init.d(4) for information on how to add a new script).

The available parameter and its meaning is shown below.

tcp_sack_permitted

Specifies whether SACK is permitted. The default is 1. The available options are as follows:

0

TCP does not accept or send SACK information.

1

TCP does not initiate a connection with SACK_PERMITTED option. If the incoming request has SACK_PERMITTED option, TCP responds with SACK_PERMITTED option.

2

TCP initiates and accepts connections with SACK_PERMITTED option.

For additional information see the tcp(7P) man page.