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