5 bool "IP: multicasting"
7 This is code for addressing several networked computers at once,
8 enlarging your kernel by about 2 KB. You need multicasting if you
9 intend to participate in the MBONE, a high bandwidth network on top
10 of the Internet which carries audio and video broadcasts. More
11 information about the MBONE is on the WWW at
12 <http://www.savetz.com/mbone/>. Information about the multicast
13 capabilities of the various network cards is contained in
14 <file:Documentation/networking/multicast.txt>. For most people, it's
17 config IP_ADVANCED_ROUTER
18 bool "IP: advanced router"
20 If you intend to run your Linux box mostly as a router, i.e. as a
21 computer that forwards and redistributes network packets, say Y; you
22 will then be presented with several options that allow more precise
23 control about the routing process.
25 The answer to this question won't directly affect the kernel:
26 answering N will just cause the configurator to skip all the
27 questions about advanced routing.
29 Note that your box can only act as a router if you enable IP
30 forwarding in your kernel; you can do that by saying Y to "/proc
31 file system support" and "Sysctl support" below and executing the
34 echo "1" > /proc/sys/net/ipv4/ip_forward
36 at boot time after the /proc file system has been mounted.
38 If you turn on IP forwarding, you should consider the rp_filter, which
39 automatically rejects incoming packets if the routing table entry
40 for their source address doesn't match the network interface they're
41 arriving on. This has security advantages because it prevents the
42 so-called IP spoofing, however it can pose problems if you use
43 asymmetric routing (packets from you to a host take a different path
44 than packets from that host to you) or if you operate a non-routing
45 host which has several IP addresses on different interfaces. To turn
48 echo 1 > /proc/sys/net/ipv4/conf/<device>/rp_filter
50 echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
52 Note that some distributions enable it in startup scripts.
54 If unsure, say N here.
57 prompt "Choose IP: FIB lookup algorithm (choose FIB_HASH if unsure)"
58 depends on IP_ADVANCED_ROUTER
59 default ASK_IP_FIB_HASH
61 config ASK_IP_FIB_HASH
64 Current FIB is very proven and good enough for most users.
69 Use new experimental LC-trie as FIB lookup algorithm.
70 This improves lookup performance if you have a large
73 LC-trie is a longest matching prefix lookup algorithm which
74 performs better than FIB_HASH for large routing tables.
75 But, it consumes more memory and is more complex.
77 LC-trie is described in:
79 IP-address lookup using LC-tries. Stefan Nilsson and Gunnar Karlsson
80 IEEE Journal on Selected Areas in Communications, 17(6):1083-1092,
83 An experimental study of compression methods for dynamic tries
84 Stefan Nilsson and Matti Tikkanen. Algorithmica, 33(1):19-33, 2002.
85 http://www.nada.kth.se/~snilsson/public/papers/dyntrie2/
90 def_bool ASK_IP_FIB_HASH || !IP_ADVANCED_ROUTER
92 config IP_FIB_TRIE_STATS
93 bool "FIB TRIE statistics"
94 depends on IP_FIB_TRIE
96 Keep track of statistics on structure of FIB TRIE table.
97 Useful for testing and measuring TRIE performance.
99 config IP_MULTIPLE_TABLES
100 bool "IP: policy routing"
101 depends on IP_ADVANCED_ROUTER
104 Normally, a router decides what to do with a received packet based
105 solely on the packet's final destination address. If you say Y here,
106 the Linux router will also be able to take the packet's source
107 address into account. Furthermore, the TOS (Type-Of-Service) field
108 of the packet can be used for routing decisions as well.
110 If you are interested in this, please see the preliminary
111 documentation at <http://www.compendium.com.ar/policy-routing.txt>
112 and <ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex>.
113 You will need supporting software from
114 <ftp://ftp.tux.org/pub/net/ip-routing/>.
118 config IP_ROUTE_MULTIPATH
119 bool "IP: equal cost multipath"
120 depends on IP_ADVANCED_ROUTER
122 Normally, the routing tables specify a single action to be taken in
123 a deterministic manner for a given packet. If you say Y here
124 however, it becomes possible to attach several actions to a packet
125 pattern, in effect specifying several alternative paths to travel
126 for those packets. The router considers all these paths to be of
127 equal "cost" and chooses one of them in a non-deterministic fashion
128 if a matching packet arrives.
130 config IP_ROUTE_VERBOSE
131 bool "IP: verbose route monitoring"
132 depends on IP_ADVANCED_ROUTER
134 If you say Y here, which is recommended, then the kernel will print
135 verbose messages regarding the routing, for example warnings about
136 received packets which look strange and could be evidence of an
137 attack or a misconfigured system somewhere. The information is
138 handled by the klogd daemon which is responsible for kernel messages
142 bool "IP: kernel level autoconfiguration"
144 This enables automatic configuration of IP addresses of devices and
145 of the routing table during kernel boot, based on either information
146 supplied on the kernel command line or by BOOTP or RARP protocols.
147 You need to say Y only for diskless machines requiring network
148 access to boot (in which case you want to say Y to "Root file system
149 on NFS" as well), because all other machines configure the network
150 in their startup scripts.
153 bool "IP: DHCP support"
156 If you want your Linux box to mount its whole root file system (the
157 one containing the directory /) from some other computer over the
158 net via NFS and you want the IP address of your computer to be
159 discovered automatically at boot time using the DHCP protocol (a
160 special protocol designed for doing this job), say Y here. In case
161 the boot ROM of your network card was designed for booting Linux and
162 does DHCP itself, providing all necessary information on the kernel
163 command line, you can say N here.
165 If unsure, say Y. Note that if you want to use DHCP, a DHCP server
166 must be operating on your network. Read
167 <file:Documentation/filesystems/nfsroot.txt> for details.
170 bool "IP: BOOTP support"
173 If you want your Linux box to mount its whole root file system (the
174 one containing the directory /) from some other computer over the
175 net via NFS and you want the IP address of your computer to be
176 discovered automatically at boot time using the BOOTP protocol (a
177 special protocol designed for doing this job), say Y here. In case
178 the boot ROM of your network card was designed for booting Linux and
179 does BOOTP itself, providing all necessary information on the kernel
180 command line, you can say N here. If unsure, say Y. Note that if you
181 want to use BOOTP, a BOOTP server must be operating on your network.
182 Read <file:Documentation/filesystems/nfsroot.txt> for details.
185 bool "IP: RARP support"
188 If you want your Linux box to mount its whole root file system (the
189 one containing the directory /) from some other computer over the
190 net via NFS and you want the IP address of your computer to be
191 discovered automatically at boot time using the RARP protocol (an
192 older protocol which is being obsoleted by BOOTP and DHCP), say Y
193 here. Note that if you want to use RARP, a RARP server must be
194 operating on your network. Read
195 <file:Documentation/filesystems/nfsroot.txt> for details.
198 # bool ' IP: ARP support' CONFIG_IP_PNP_ARP
200 tristate "IP: tunneling"
203 Tunneling means encapsulating data of one protocol type within
204 another protocol and sending it over a channel that understands the
205 encapsulating protocol. This particular tunneling driver implements
206 encapsulation of IP within IP, which sounds kind of pointless, but
207 can be useful if you want to make your (or some other) machine
208 appear on a different network than it physically is, or to use
209 mobile-IP facilities (allowing laptops to seamlessly move between
210 networks without changing their IP addresses).
212 Saying Y to this option will produce two modules ( = code which can
213 be inserted in and removed from the running kernel whenever you
214 want). Most people won't need this and can say N.
217 tristate "IP: GRE tunnels over IP"
219 Tunneling means encapsulating data of one protocol type within
220 another protocol and sending it over a channel that understands the
221 encapsulating protocol. This particular tunneling driver implements
222 GRE (Generic Routing Encapsulation) and at this time allows
223 encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure.
224 This driver is useful if the other endpoint is a Cisco router: Cisco
225 likes GRE much better than the other Linux tunneling driver ("IP
226 tunneling" above). In addition, GRE allows multicast redistribution
229 config NET_IPGRE_BROADCAST
230 bool "IP: broadcast GRE over IP"
231 depends on IP_MULTICAST && NET_IPGRE
233 One application of GRE/IP is to construct a broadcast WAN (Wide Area
234 Network), which looks like a normal Ethernet LAN (Local Area
235 Network), but can be distributed all over the Internet. If you want
236 to do that, say Y here and to "IP multicast routing" below.
239 bool "IP: multicast routing"
240 depends on IP_MULTICAST
242 This is used if you want your machine to act as a router for IP
243 packets that have several destination addresses. It is needed on the
244 MBONE, a high bandwidth network on top of the Internet which carries
245 audio and video broadcasts. In order to do that, you would most
246 likely run the program mrouted. Information about the multicast
247 capabilities of the various network cards is contained in
248 <file:Documentation/networking/multicast.txt>. If you haven't heard
249 about it, you don't need it.
252 bool "IP: PIM-SM version 1 support"
255 Kernel side support for Sparse Mode PIM (Protocol Independent
256 Multicast) version 1. This multicast routing protocol is used widely
257 because Cisco supports it. You need special software to use it
258 (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more
259 information about PIM.
261 Say Y if you want to use PIM-SM v1. Note that you can say N here if
262 you just want to use Dense Mode PIM.
265 bool "IP: PIM-SM version 2 support"
268 Kernel side support for Sparse Mode PIM version 2. In order to use
269 this, you need an experimental routing daemon supporting it (pimd or
270 gated-5). This routing protocol is not used widely, so say N unless
271 you want to play with it.
274 bool "IP: ARP daemon support (EXPERIMENTAL)"
275 depends on EXPERIMENTAL
277 Normally, the kernel maintains an internal cache which maps IP
278 addresses to hardware addresses on the local network, so that
279 Ethernet/Token Ring/ etc. frames are sent to the proper address on
280 the physical networking layer. For small networks having a few
281 hundred directly connected hosts or less, keeping this address
282 resolution (ARP) cache inside the kernel works well. However,
283 maintaining an internal ARP cache does not work well for very large
284 switched networks, and will use a lot of kernel memory if TCP/IP
285 connections are made to many machines on the network.
287 If you say Y here, the kernel's internal ARP cache will never grow
288 to more than 256 entries (the oldest entries are expired in a LIFO
289 manner) and communication will be attempted with the user space ARP
290 daemon arpd. Arpd then answers the address resolution request either
291 from its own cache or by asking the net.
293 This code is experimental and also obsolete. If you want to use it,
294 you need to find a version of the daemon arpd on the net somewhere,
295 and you should also say Y to "Kernel/User network link driver",
296 below. If unsure, say N.
299 bool "IP: TCP syncookie support (disabled per default)"
301 Normal TCP/IP networking is open to an attack known as "SYN
302 flooding". This denial-of-service attack prevents legitimate remote
303 users from being able to connect to your computer during an ongoing
304 attack and requires very little work from the attacker, who can
305 operate from anywhere on the Internet.
307 SYN cookies provide protection against this type of attack. If you
308 say Y here, the TCP/IP stack will use a cryptographic challenge
309 protocol known as "SYN cookies" to enable legitimate users to
310 continue to connect, even when your machine is under attack. There
311 is no need for the legitimate users to change their TCP/IP software;
312 SYN cookies work transparently to them. For technical information
313 about SYN cookies, check out <http://cr.yp.to/syncookies.html>.
315 If you are SYN flooded, the source address reported by the kernel is
316 likely to have been forged by the attacker; it is only reported as
317 an aid in tracing the packets to their actual source and should not
318 be taken as absolute truth.
320 SYN cookies may prevent correct error reporting on clients when the
321 server is really overloaded. If this happens frequently better turn
324 If you say Y here, note that SYN cookies aren't enabled by default;
325 you can enable them by saying Y to "/proc file system support" and
326 "Sysctl support" below and executing the command
328 echo 1 >/proc/sys/net/ipv4/tcp_syncookies
330 at boot time after the /proc file system has been mounted.
335 tristate "IP: AH transformation"
342 Support for IPsec AH.
347 tristate "IP: ESP transformation"
350 select CRYPTO_AUTHENC
357 Support for IPsec ESP.
362 tristate "IP: IPComp transformation"
363 select INET_XFRM_TUNNEL
366 Support for IP Payload Compression Protocol (IPComp) (RFC3173),
367 typically needed for IPsec.
371 config INET_XFRM_TUNNEL
380 config INET_XFRM_MODE_TRANSPORT
381 tristate "IP: IPsec transport mode"
385 Support for IPsec transport mode.
389 config INET_XFRM_MODE_TUNNEL
390 tristate "IP: IPsec tunnel mode"
394 Support for IPsec tunnel mode.
398 config INET_XFRM_MODE_BEET
399 tristate "IP: IPsec BEET mode"
403 Support for IPsec BEET mode.
408 tristate "Large Receive Offload (ipv4/tcp)"
411 Support for Large Receive Offload (ipv4/tcp).
416 tristate "INET: socket monitoring interface"
419 Support for INET (TCP, DCCP, etc) socket monitoring interface used by
420 native Linux tools such as ss. ss is included in iproute2, currently
421 downloadable at <http://linux-net.osdl.org/index.php/Iproute2>.
427 def_tristate INET_DIAG
429 menuconfig TCP_CONG_ADVANCED
430 bool "TCP: advanced congestion control"
432 Support for selection of various TCP congestion control
435 Nearly all users can safely say no here, and a safe default
436 selection will be made (CUBIC with new Reno as a fallback).
443 tristate "Binary Increase Congestion (BIC) control"
446 BIC-TCP is a sender-side only change that ensures a linear RTT
447 fairness under large windows while offering both scalability and
448 bounded TCP-friendliness. The protocol combines two schemes
449 called additive increase and binary search increase. When the
450 congestion window is large, additive increase with a large
451 increment ensures linear RTT fairness as well as good
452 scalability. Under small congestion windows, binary search
453 increase provides TCP friendliness.
454 See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
456 config TCP_CONG_CUBIC
460 This is version 2.0 of BIC-TCP which uses a cubic growth function
461 among other techniques.
462 See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
464 config TCP_CONG_WESTWOOD
465 tristate "TCP Westwood+"
468 TCP Westwood+ is a sender-side only modification of the TCP Reno
469 protocol stack that optimizes the performance of TCP congestion
470 control. It is based on end-to-end bandwidth estimation to set
471 congestion window and slow start threshold after a congestion
472 episode. Using this estimation, TCP Westwood+ adaptively sets a
473 slow start threshold and a congestion window which takes into
474 account the bandwidth used at the time congestion is experienced.
475 TCP Westwood+ significantly increases fairness wrt TCP Reno in
476 wired networks and throughput over wireless links.
482 H-TCP is a send-side only modifications of the TCP Reno
483 protocol stack that optimizes the performance of TCP
484 congestion control for high speed network links. It uses a
485 modeswitch to change the alpha and beta parameters of TCP Reno
486 based on network conditions and in a way so as to be fair with
487 other Reno and H-TCP flows.
489 config TCP_CONG_HSTCP
490 tristate "High Speed TCP"
491 depends on EXPERIMENTAL
494 Sally Floyd's High Speed TCP (RFC 3649) congestion control.
495 A modification to TCP's congestion control mechanism for use
496 with large congestion windows. A table indicates how much to
497 increase the congestion window by when an ACK is received.
498 For more detail see http://www.icir.org/floyd/hstcp.html
500 config TCP_CONG_HYBLA
501 tristate "TCP-Hybla congestion control algorithm"
502 depends on EXPERIMENTAL
505 TCP-Hybla is a sender-side only change that eliminates penalization of
506 long-RTT, large-bandwidth connections, like when satellite legs are
507 involved, especially when sharing a common bottleneck with normal
508 terrestrial connections.
510 config TCP_CONG_VEGAS
512 depends on EXPERIMENTAL
515 TCP Vegas is a sender-side only change to TCP that anticipates
516 the onset of congestion by estimating the bandwidth. TCP Vegas
517 adjusts the sending rate by modifying the congestion
518 window. TCP Vegas should provide less packet loss, but it is
519 not as aggressive as TCP Reno.
521 config TCP_CONG_SCALABLE
522 tristate "Scalable TCP"
523 depends on EXPERIMENTAL
526 Scalable TCP is a sender-side only change to TCP which uses a
527 MIMD congestion control algorithm which has some nice scaling
528 properties, though is known to have fairness issues.
529 See http://www.deneholme.net/tom/scalable/
532 tristate "TCP Low Priority"
533 depends on EXPERIMENTAL
536 TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
537 to utilize only the excess network bandwidth as compared to the
538 ``fair share`` of bandwidth as targeted by TCP.
539 See http://www-ece.rice.edu/networks/TCP-LP/
543 depends on EXPERIMENTAL
546 TCP Veno is a sender-side only enhancement of TCP to obtain better
547 throughput over wireless networks. TCP Veno makes use of state
548 distinguishing to circumvent the difficult judgment of the packet loss
549 type. TCP Veno cuts down less congestion window in response to random
551 See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf
555 depends on EXPERIMENTAL
556 select TCP_CONG_VEGAS
559 YeAH-TCP is a sender-side high-speed enabled TCP congestion control
560 algorithm, which uses a mixed loss/delay approach to compute the
561 congestion window. It's design goals target high efficiency,
562 internal, RTT and Reno fairness, resilience to link loss while
563 keeping network elements load as low as possible.
565 For further details look here:
566 http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
568 config TCP_CONG_ILLINOIS
569 tristate "TCP Illinois"
570 depends on EXPERIMENTAL
573 TCP-Illinois is a sender-side modification of TCP Reno for
574 high speed long delay links. It uses round-trip-time to
575 adjust the alpha and beta parameters to achieve a higher average
576 throughput and maintain fairness.
578 For further details see:
579 http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
582 prompt "Default TCP congestion control"
583 default DEFAULT_CUBIC
585 Select the TCP congestion control that will be used by default
589 bool "Bic" if TCP_CONG_BIC=y
592 bool "Cubic" if TCP_CONG_CUBIC=y
595 bool "Htcp" if TCP_CONG_HTCP=y
598 bool "Vegas" if TCP_CONG_VEGAS=y
600 config DEFAULT_WESTWOOD
601 bool "Westwood" if TCP_CONG_WESTWOOD=y
610 config TCP_CONG_CUBIC
612 depends on !TCP_CONG_ADVANCED
615 config DEFAULT_TCP_CONG
617 default "bic" if DEFAULT_BIC
618 default "cubic" if DEFAULT_CUBIC
619 default "htcp" if DEFAULT_HTCP
620 default "vegas" if DEFAULT_VEGAS
621 default "westwood" if DEFAULT_WESTWOOD
622 default "reno" if DEFAULT_RENO
626 bool "TCP: MD5 Signature Option support (RFC2385) (EXPERIMENTAL)"
627 depends on EXPERIMENTAL
631 RFC2385 specifies a method of giving MD5 protection to TCP sessions.
632 Its main (only?) use is to protect BGP sessions between core routers