xref: /openbmc/linux/net/ipv4/Kconfig (revision d5cb9783536a41df9f9cba5b0a1d78047ed787f7)
1#
2# IP configuration
3#
4config IP_MULTICAST
5	bool "IP: multicasting"
6	help
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-itg.lbl.gov/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
15	  safe to say N.
16
17config IP_ADVANCED_ROUTER
18	bool "IP: advanced router"
19	---help---
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.
24
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.
28
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
32	  line
33
34	  echo "1" > /proc/sys/net/ipv4/ip_forward
35
36	  at boot time after the /proc file system has been mounted.
37
38	  If you turn on IP forwarding, you will also get 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
46	  rp_filter off use:
47
48	  echo 0 > /proc/sys/net/ipv4/conf/<device>/rp_filter
49	  or
50	  echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
51
52	  If unsure, say N here.
53
54choice
55	prompt "Choose IP: FIB lookup algorithm (choose FIB_HASH if unsure)"
56	depends on IP_ADVANCED_ROUTER
57	default ASK_IP_FIB_HASH
58
59config ASK_IP_FIB_HASH
60	bool "FIB_HASH"
61	---help---
62	Current FIB is very proven and good enough for most users.
63
64config IP_FIB_TRIE
65	bool "FIB_TRIE"
66	---help---
67	Use new experimental LC-trie as FIB lookup algoritm.
68        This improves lookup performance if you have a large
69	number of routes.
70
71	LC-trie is a longest matching prefix lookup algorithm which
72	performs better than FIB_HASH for large routing tables.
73	But, it consumes more memory and is more complex.
74
75	LC-trie is described in:
76
77 	IP-address lookup using LC-tries. Stefan Nilsson and Gunnar Karlsson
78 	IEEE Journal on Selected Areas in Communications, 17(6):1083-1092, June 1999
79	An experimental study of compression methods for dynamic tries
80 	Stefan Nilsson and Matti Tikkanen. Algorithmica, 33(1):19-33, 2002.
81 	http://www.nada.kth.se/~snilsson/public/papers/dyntrie2/
82
83endchoice
84
85config IP_FIB_HASH
86	def_bool ASK_IP_FIB_HASH || !IP_ADVANCED_ROUTER
87
88config IP_MULTIPLE_TABLES
89	bool "IP: policy routing"
90	depends on IP_ADVANCED_ROUTER
91	---help---
92	  Normally, a router decides what to do with a received packet based
93	  solely on the packet's final destination address. If you say Y here,
94	  the Linux router will also be able to take the packet's source
95	  address into account. Furthermore, the TOS (Type-Of-Service) field
96	  of the packet can be used for routing decisions as well.
97
98	  If you are interested in this, please see the preliminary
99	  documentation at <http://www.compendium.com.ar/policy-routing.txt>
100	  and <ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex>.
101	  You will need supporting software from
102	  <ftp://ftp.tux.org/pub/net/ip-routing/>.
103
104	  If unsure, say N.
105
106config IP_ROUTE_FWMARK
107	bool "IP: use netfilter MARK value as routing key"
108	depends on IP_MULTIPLE_TABLES && NETFILTER
109	help
110	  If you say Y here, you will be able to specify different routes for
111	  packets with different mark values (see iptables(8), MARK target).
112
113config IP_ROUTE_MULTIPATH
114	bool "IP: equal cost multipath"
115	depends on IP_ADVANCED_ROUTER
116	help
117	  Normally, the routing tables specify a single action to be taken in
118	  a deterministic manner for a given packet. If you say Y here
119	  however, it becomes possible to attach several actions to a packet
120	  pattern, in effect specifying several alternative paths to travel
121	  for those packets. The router considers all these paths to be of
122	  equal "cost" and chooses one of them in a non-deterministic fashion
123	  if a matching packet arrives.
124
125config IP_ROUTE_MULTIPATH_CACHED
126	bool "IP: equal cost multipath with caching support (EXPERIMENTAL)"
127	depends on IP_ROUTE_MULTIPATH
128	help
129	  Normally, equal cost multipath routing is not supported by the
130	  routing cache. If you say Y here, alternative routes are cached
131	  and on cache lookup a route is chosen in a configurable fashion.
132
133	  If unsure, say N.
134
135config IP_ROUTE_MULTIPATH_RR
136	tristate "MULTIPATH: round robin algorithm"
137	depends on IP_ROUTE_MULTIPATH_CACHED
138	help
139	  Mulitpath routes are chosen according to Round Robin
140
141config IP_ROUTE_MULTIPATH_RANDOM
142	tristate "MULTIPATH: random algorithm"
143	depends on IP_ROUTE_MULTIPATH_CACHED
144	help
145	  Multipath routes are chosen in a random fashion. Actually,
146	  there is no weight for a route. The advantage of this policy
147	  is that it is implemented stateless and therefore introduces only
148	  a very small delay.
149
150config IP_ROUTE_MULTIPATH_WRANDOM
151	tristate "MULTIPATH: weighted random algorithm"
152	depends on IP_ROUTE_MULTIPATH_CACHED
153	help
154	  Multipath routes are chosen in a weighted random fashion.
155	  The per route weights are the weights visible via ip route 2. As the
156	  corresponding state management introduces some overhead routing delay
157	  is increased.
158
159config IP_ROUTE_MULTIPATH_DRR
160	tristate "MULTIPATH: interface round robin algorithm"
161	depends on IP_ROUTE_MULTIPATH_CACHED
162	help
163	  Connections are distributed in a round robin fashion over the
164	  available interfaces. This policy makes sense if the connections
165	  should be primarily distributed on interfaces and not on routes.
166
167config IP_ROUTE_VERBOSE
168	bool "IP: verbose route monitoring"
169	depends on IP_ADVANCED_ROUTER
170	help
171	  If you say Y here, which is recommended, then the kernel will print
172	  verbose messages regarding the routing, for example warnings about
173	  received packets which look strange and could be evidence of an
174	  attack or a misconfigured system somewhere. The information is
175	  handled by the klogd daemon which is responsible for kernel messages
176	  ("man klogd").
177
178config IP_PNP
179	bool "IP: kernel level autoconfiguration"
180	help
181	  This enables automatic configuration of IP addresses of devices and
182	  of the routing table during kernel boot, based on either information
183	  supplied on the kernel command line or by BOOTP or RARP protocols.
184	  You need to say Y only for diskless machines requiring network
185	  access to boot (in which case you want to say Y to "Root file system
186	  on NFS" as well), because all other machines configure the network
187	  in their startup scripts.
188
189config IP_PNP_DHCP
190	bool "IP: DHCP support"
191	depends on IP_PNP
192	---help---
193	  If you want your Linux box to mount its whole root file system (the
194	  one containing the directory /) from some other computer over the
195	  net via NFS and you want the IP address of your computer to be
196	  discovered automatically at boot time using the DHCP protocol (a
197	  special protocol designed for doing this job), say Y here. In case
198	  the boot ROM of your network card was designed for booting Linux and
199	  does DHCP itself, providing all necessary information on the kernel
200	  command line, you can say N here.
201
202	  If unsure, say Y. Note that if you want to use DHCP, a DHCP server
203	  must be operating on your network.  Read
204	  <file:Documentation/nfsroot.txt> for details.
205
206config IP_PNP_BOOTP
207	bool "IP: BOOTP support"
208	depends on IP_PNP
209	---help---
210	  If you want your Linux box to mount its whole root file system (the
211	  one containing the directory /) from some other computer over the
212	  net via NFS and you want the IP address of your computer to be
213	  discovered automatically at boot time using the BOOTP protocol (a
214	  special protocol designed for doing this job), say Y here. In case
215	  the boot ROM of your network card was designed for booting Linux and
216	  does BOOTP itself, providing all necessary information on the kernel
217	  command line, you can say N here. If unsure, say Y. Note that if you
218	  want to use BOOTP, a BOOTP server must be operating on your network.
219	  Read <file:Documentation/nfsroot.txt> for details.
220
221config IP_PNP_RARP
222	bool "IP: RARP support"
223	depends on IP_PNP
224	help
225	  If you want your Linux box to mount its whole root file system (the
226	  one containing the directory /) from some other computer over the
227	  net via NFS and you want the IP address of your computer to be
228	  discovered automatically at boot time using the RARP protocol (an
229	  older protocol which is being obsoleted by BOOTP and DHCP), say Y
230	  here. Note that if you want to use RARP, a RARP server must be
231	  operating on your network. Read <file:Documentation/nfsroot.txt> for
232	  details.
233
234# not yet ready..
235#   bool '    IP: ARP support' CONFIG_IP_PNP_ARP
236config NET_IPIP
237	tristate "IP: tunneling"
238	---help---
239	  Tunneling means encapsulating data of one protocol type within
240	  another protocol and sending it over a channel that understands the
241	  encapsulating protocol. This particular tunneling driver implements
242	  encapsulation of IP within IP, which sounds kind of pointless, but
243	  can be useful if you want to make your (or some other) machine
244	  appear on a different network than it physically is, or to use
245	  mobile-IP facilities (allowing laptops to seamlessly move between
246	  networks without changing their IP addresses).
247
248	  Saying Y to this option will produce two modules ( = code which can
249	  be inserted in and removed from the running kernel whenever you
250	  want). Most people won't need this and can say N.
251
252config NET_IPGRE
253	tristate "IP: GRE tunnels over IP"
254	help
255	  Tunneling means encapsulating data of one protocol type within
256	  another protocol and sending it over a channel that understands the
257	  encapsulating protocol. This particular tunneling driver implements
258	  GRE (Generic Routing Encapsulation) and at this time allows
259	  encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure.
260	  This driver is useful if the other endpoint is a Cisco router: Cisco
261	  likes GRE much better than the other Linux tunneling driver ("IP
262	  tunneling" above). In addition, GRE allows multicast redistribution
263	  through the tunnel.
264
265config NET_IPGRE_BROADCAST
266	bool "IP: broadcast GRE over IP"
267	depends on IP_MULTICAST && NET_IPGRE
268	help
269	  One application of GRE/IP is to construct a broadcast WAN (Wide Area
270	  Network), which looks like a normal Ethernet LAN (Local Area
271	  Network), but can be distributed all over the Internet. If you want
272	  to do that, say Y here and to "IP multicast routing" below.
273
274config IP_MROUTE
275	bool "IP: multicast routing"
276	depends on IP_MULTICAST
277	help
278	  This is used if you want your machine to act as a router for IP
279	  packets that have several destination addresses. It is needed on the
280	  MBONE, a high bandwidth network on top of the Internet which carries
281	  audio and video broadcasts. In order to do that, you would most
282	  likely run the program mrouted. Information about the multicast
283	  capabilities of the various network cards is contained in
284	  <file:Documentation/networking/multicast.txt>. If you haven't heard
285	  about it, you don't need it.
286
287config IP_PIMSM_V1
288	bool "IP: PIM-SM version 1 support"
289	depends on IP_MROUTE
290	help
291	  Kernel side support for Sparse Mode PIM (Protocol Independent
292	  Multicast) version 1. This multicast routing protocol is used widely
293	  because Cisco supports it. You need special software to use it
294	  (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more
295	  information about PIM.
296
297	  Say Y if you want to use PIM-SM v1. Note that you can say N here if
298	  you just want to use Dense Mode PIM.
299
300config IP_PIMSM_V2
301	bool "IP: PIM-SM version 2 support"
302	depends on IP_MROUTE
303	help
304	  Kernel side support for Sparse Mode PIM version 2. In order to use
305	  this, you need an experimental routing daemon supporting it (pimd or
306	  gated-5). This routing protocol is not used widely, so say N unless
307	  you want to play with it.
308
309config ARPD
310	bool "IP: ARP daemon support (EXPERIMENTAL)"
311	depends on EXPERIMENTAL
312	---help---
313	  Normally, the kernel maintains an internal cache which maps IP
314	  addresses to hardware addresses on the local network, so that
315	  Ethernet/Token Ring/ etc. frames are sent to the proper address on
316	  the physical networking layer. For small networks having a few
317	  hundred directly connected hosts or less, keeping this address
318	  resolution (ARP) cache inside the kernel works well. However,
319	  maintaining an internal ARP cache does not work well for very large
320	  switched networks, and will use a lot of kernel memory if TCP/IP
321	  connections are made to many machines on the network.
322
323	  If you say Y here, the kernel's internal ARP cache will never grow
324	  to more than 256 entries (the oldest entries are expired in a LIFO
325	  manner) and communication will be attempted with the user space ARP
326	  daemon arpd. Arpd then answers the address resolution request either
327	  from its own cache or by asking the net.
328
329	  This code is experimental and also obsolete. If you want to use it,
330	  you need to find a version of the daemon arpd on the net somewhere,
331	  and you should also say Y to "Kernel/User network link driver",
332	  below. If unsure, say N.
333
334config SYN_COOKIES
335	bool "IP: TCP syncookie support (disabled per default)"
336	---help---
337	  Normal TCP/IP networking is open to an attack known as "SYN
338	  flooding". This denial-of-service attack prevents legitimate remote
339	  users from being able to connect to your computer during an ongoing
340	  attack and requires very little work from the attacker, who can
341	  operate from anywhere on the Internet.
342
343	  SYN cookies provide protection against this type of attack. If you
344	  say Y here, the TCP/IP stack will use a cryptographic challenge
345	  protocol known as "SYN cookies" to enable legitimate users to
346	  continue to connect, even when your machine is under attack. There
347	  is no need for the legitimate users to change their TCP/IP software;
348	  SYN cookies work transparently to them. For technical information
349	  about SYN cookies, check out <http://cr.yp.to/syncookies.html>.
350
351	  If you are SYN flooded, the source address reported by the kernel is
352	  likely to have been forged by the attacker; it is only reported as
353	  an aid in tracing the packets to their actual source and should not
354	  be taken as absolute truth.
355
356	  SYN cookies may prevent correct error reporting on clients when the
357	  server is really overloaded. If this happens frequently better turn
358	  them off.
359
360	  If you say Y here, note that SYN cookies aren't enabled by default;
361	  you can enable them by saying Y to "/proc file system support" and
362	  "Sysctl support" below and executing the command
363
364	  echo 1 >/proc/sys/net/ipv4/tcp_syncookies
365
366	  at boot time after the /proc file system has been mounted.
367
368	  If unsure, say N.
369
370config INET_AH
371	tristate "IP: AH transformation"
372	select XFRM
373	select CRYPTO
374	select CRYPTO_HMAC
375	select CRYPTO_MD5
376	select CRYPTO_SHA1
377	---help---
378	  Support for IPsec AH.
379
380	  If unsure, say Y.
381
382config INET_ESP
383	tristate "IP: ESP transformation"
384	select XFRM
385	select CRYPTO
386	select CRYPTO_HMAC
387	select CRYPTO_MD5
388	select CRYPTO_SHA1
389	select CRYPTO_DES
390	---help---
391	  Support for IPsec ESP.
392
393	  If unsure, say Y.
394
395config INET_IPCOMP
396	tristate "IP: IPComp transformation"
397	select XFRM
398	select INET_TUNNEL
399	select CRYPTO
400	select CRYPTO_DEFLATE
401	---help---
402	  Support for IP Payload Compression Protocol (IPComp) (RFC3173),
403	  typically needed for IPsec.
404
405	  If unsure, say Y.
406
407config INET_TUNNEL
408	tristate "IP: tunnel transformation"
409	select XFRM
410	---help---
411	  Support for generic IP tunnel transformation, which is required by
412	  the IP tunneling module as well as tunnel mode IPComp.
413
414	  If unsure, say Y.
415
416config INET_DIAG
417	tristate "INET: socket monitoring interface"
418	default y
419	---help---
420	  Support for INET (TCP, DCCP, etc) socket monitoring interface used by
421	  native Linux tools such as ss. ss is included in iproute2, currently
422	  downloadable at <http://developer.osdl.org/dev/iproute2>.
423
424	  If unsure, say Y.
425
426config INET_TCP_DIAG
427	depends on INET_DIAG
428	def_tristate INET_DIAG
429
430config TCP_CONG_ADVANCED
431	bool "TCP: advanced congestion control"
432	---help---
433	  Support for selection of various TCP congestion control
434	  modules.
435
436	  Nearly all users can safely say no here, and a safe default
437	  selection will be made (BIC-TCP with new Reno as a fallback).
438
439	  If unsure, say N.
440
441# TCP Reno is builtin (required as fallback)
442menu "TCP congestion control"
443	depends on TCP_CONG_ADVANCED
444
445config TCP_CONG_BIC
446	tristate "Binary Increase Congestion (BIC) control"
447	default y
448	---help---
449	BIC-TCP is a sender-side only change that ensures a linear RTT
450	fairness under large windows while offering both scalability and
451	bounded TCP-friendliness. The protocol combines two schemes
452	called additive increase and binary search increase. When the
453	congestion window is large, additive increase with a large
454	increment ensures linear RTT fairness as well as good
455	scalability. Under small congestion windows, binary search
456	increase provides TCP friendliness.
457	See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
458
459config TCP_CONG_WESTWOOD
460	tristate "TCP Westwood+"
461	default m
462	---help---
463	TCP Westwood+ is a sender-side only modification of the TCP Reno
464	protocol stack that optimizes the performance of TCP congestion
465	control. It is based on end-to-end bandwidth estimation to set
466	congestion window and slow start threshold after a congestion
467	episode. Using this estimation, TCP Westwood+ adaptively sets a
468	slow start threshold and a congestion window which takes into
469	account the bandwidth used  at the time congestion is experienced.
470	TCP Westwood+ significantly increases fairness wrt TCP Reno in
471	wired networks and throughput over wireless links.
472
473config TCP_CONG_HTCP
474        tristate "H-TCP"
475        default m
476	---help---
477	H-TCP is a send-side only modifications of the TCP Reno
478	protocol stack that optimizes the performance of TCP
479	congestion control for high speed network links. It uses a
480	modeswitch to change the alpha and beta parameters of TCP Reno
481	based on network conditions and in a way so as to be fair with
482	other Reno and H-TCP flows.
483
484config TCP_CONG_HSTCP
485	tristate "High Speed TCP"
486	depends on EXPERIMENTAL
487	default n
488	---help---
489	Sally Floyd's High Speed TCP (RFC 3649) congestion control.
490	A modification to TCP's congestion control mechanism for use
491	with large congestion windows. A table indicates how much to
492	increase the congestion window by when an ACK is received.
493 	For more detail	see http://www.icir.org/floyd/hstcp.html
494
495config TCP_CONG_HYBLA
496	tristate "TCP-Hybla congestion control algorithm"
497	depends on EXPERIMENTAL
498	default n
499	---help---
500	TCP-Hybla is a sender-side only change that eliminates penalization of
501	long-RTT, large-bandwidth connections, like when satellite legs are
502	involved, expecially when sharing a common bottleneck with normal
503	terrestrial connections.
504
505config TCP_CONG_VEGAS
506	tristate "TCP Vegas"
507	depends on EXPERIMENTAL
508	default n
509	---help---
510	TCP Vegas is a sender-side only change to TCP that anticipates
511	the onset of congestion by estimating the bandwidth. TCP Vegas
512	adjusts the sending rate by modifying the congestion
513	window. TCP Vegas should provide less packet loss, but it is
514	not as aggressive as TCP Reno.
515
516config TCP_CONG_SCALABLE
517	tristate "Scalable TCP"
518	depends on EXPERIMENTAL
519	default n
520	---help---
521	Scalable TCP is a sender-side only change to TCP which uses a
522	MIMD congestion control algorithm which has some nice scaling
523	properties, though is known to have fairness issues.
524	See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/
525
526endmenu
527
528config TCP_CONG_BIC
529	tristate
530	depends on !TCP_CONG_ADVANCED
531	default y
532
533source "net/ipv4/ipvs/Kconfig"
534
535