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