diff options
Diffstat (limited to 'net/ipv4/Kconfig')
-rw-r--r-- | net/ipv4/Kconfig | 411 |
1 files changed, 411 insertions, 0 deletions
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig new file mode 100644 index 000000000000..6d3e8b1bd1f2 --- /dev/null +++ b/net/ipv4/Kconfig | |||
@@ -0,0 +1,411 @@ | |||
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 | config IP_MULTIPLE_TABLES | ||
57 | bool "IP: policy routing" | ||
58 | depends on IP_ADVANCED_ROUTER | ||
59 | ---help--- | ||
60 | Normally, a router decides what to do with a received packet based | ||
61 | solely on the packet's final destination address. If you say Y here, | ||
62 | the Linux router will also be able to take the packet's source | ||
63 | address into account. Furthermore, the TOS (Type-Of-Service) field | ||
64 | of the packet can be used for routing decisions as well. | ||
65 | |||
66 | If you are interested in this, please see the preliminary | ||
67 | documentation at <http://www.compendium.com.ar/policy-routing.txt> | ||
68 | and <ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex>. | ||
69 | You will need supporting software from | ||
70 | <ftp://ftp.tux.org/pub/net/ip-routing/>. | ||
71 | |||
72 | If unsure, say N. | ||
73 | |||
74 | config IP_ROUTE_FWMARK | ||
75 | bool "IP: use netfilter MARK value as routing key" | ||
76 | depends on IP_MULTIPLE_TABLES && NETFILTER | ||
77 | help | ||
78 | If you say Y here, you will be able to specify different routes for | ||
79 | packets with different mark values (see iptables(8), MARK target). | ||
80 | |||
81 | config IP_ROUTE_MULTIPATH | ||
82 | bool "IP: equal cost multipath" | ||
83 | depends on IP_ADVANCED_ROUTER | ||
84 | help | ||
85 | Normally, the routing tables specify a single action to be taken in | ||
86 | a deterministic manner for a given packet. If you say Y here | ||
87 | however, it becomes possible to attach several actions to a packet | ||
88 | pattern, in effect specifying several alternative paths to travel | ||
89 | for those packets. The router considers all these paths to be of | ||
90 | equal "cost" and chooses one of them in a non-deterministic fashion | ||
91 | if a matching packet arrives. | ||
92 | |||
93 | config IP_ROUTE_MULTIPATH_CACHED | ||
94 | bool "IP: equal cost multipath with caching support (EXPERIMENTAL)" | ||
95 | depends on: IP_ROUTE_MULTIPATH | ||
96 | help | ||
97 | Normally, equal cost multipath routing is not supported by the | ||
98 | routing cache. If you say Y here, alternative routes are cached | ||
99 | and on cache lookup a route is chosen in a configurable fashion. | ||
100 | |||
101 | If unsure, say N. | ||
102 | |||
103 | config IP_ROUTE_MULTIPATH_RR | ||
104 | tristate "MULTIPATH: round robin algorithm" | ||
105 | depends on IP_ROUTE_MULTIPATH_CACHED | ||
106 | help | ||
107 | Mulitpath routes are chosen according to Round Robin | ||
108 | |||
109 | config IP_ROUTE_MULTIPATH_RANDOM | ||
110 | tristate "MULTIPATH: random algorithm" | ||
111 | depends on IP_ROUTE_MULTIPATH_CACHED | ||
112 | help | ||
113 | Multipath routes are chosen in a random fashion. Actually, | ||
114 | there is no weight for a route. The advantage of this policy | ||
115 | is that it is implemented stateless and therefore introduces only | ||
116 | a very small delay. | ||
117 | |||
118 | config IP_ROUTE_MULTIPATH_WRANDOM | ||
119 | tristate "MULTIPATH: weighted random algorithm" | ||
120 | depends on IP_ROUTE_MULTIPATH_CACHED | ||
121 | help | ||
122 | Multipath routes are chosen in a weighted random fashion. | ||
123 | The per route weights are the weights visible via ip route 2. As the | ||
124 | corresponding state management introduces some overhead routing delay | ||
125 | is increased. | ||
126 | |||
127 | config IP_ROUTE_MULTIPATH_DRR | ||
128 | tristate "MULTIPATH: interface round robin algorithm" | ||
129 | depends on IP_ROUTE_MULTIPATH_CACHED | ||
130 | help | ||
131 | Connections are distributed in a round robin fashion over the | ||
132 | available interfaces. This policy makes sense if the connections | ||
133 | should be primarily distributed on interfaces and not on routes. | ||
134 | |||
135 | config IP_ROUTE_VERBOSE | ||
136 | bool "IP: verbose route monitoring" | ||
137 | depends on IP_ADVANCED_ROUTER | ||
138 | help | ||
139 | If you say Y here, which is recommended, then the kernel will print | ||
140 | verbose messages regarding the routing, for example warnings about | ||
141 | received packets which look strange and could be evidence of an | ||
142 | attack or a misconfigured system somewhere. The information is | ||
143 | handled by the klogd daemon which is responsible for kernel messages | ||
144 | ("man klogd"). | ||
145 | |||
146 | config IP_PNP | ||
147 | bool "IP: kernel level autoconfiguration" | ||
148 | depends on INET | ||
149 | help | ||
150 | This enables automatic configuration of IP addresses of devices and | ||
151 | of the routing table during kernel boot, based on either information | ||
152 | supplied on the kernel command line or by BOOTP or RARP protocols. | ||
153 | You need to say Y only for diskless machines requiring network | ||
154 | access to boot (in which case you want to say Y to "Root file system | ||
155 | on NFS" as well), because all other machines configure the network | ||
156 | in their startup scripts. | ||
157 | |||
158 | config IP_PNP_DHCP | ||
159 | bool "IP: DHCP support" | ||
160 | depends on IP_PNP | ||
161 | ---help--- | ||
162 | If you want your Linux box to mount its whole root file system (the | ||
163 | one containing the directory /) from some other computer over the | ||
164 | net via NFS and you want the IP address of your computer to be | ||
165 | discovered automatically at boot time using the DHCP protocol (a | ||
166 | special protocol designed for doing this job), say Y here. In case | ||
167 | the boot ROM of your network card was designed for booting Linux and | ||
168 | does DHCP itself, providing all necessary information on the kernel | ||
169 | command line, you can say N here. | ||
170 | |||
171 | If unsure, say Y. Note that if you want to use DHCP, a DHCP server | ||
172 | must be operating on your network. Read | ||
173 | <file:Documentation/nfsroot.txt> for details. | ||
174 | |||
175 | config IP_PNP_BOOTP | ||
176 | bool "IP: BOOTP support" | ||
177 | depends on IP_PNP | ||
178 | ---help--- | ||
179 | If you want your Linux box to mount its whole root file system (the | ||
180 | one containing the directory /) from some other computer over the | ||
181 | net via NFS and you want the IP address of your computer to be | ||
182 | discovered automatically at boot time using the BOOTP protocol (a | ||
183 | special protocol designed for doing this job), say Y here. In case | ||
184 | the boot ROM of your network card was designed for booting Linux and | ||
185 | does BOOTP itself, providing all necessary information on the kernel | ||
186 | command line, you can say N here. If unsure, say Y. Note that if you | ||
187 | want to use BOOTP, a BOOTP server must be operating on your network. | ||
188 | Read <file:Documentation/nfsroot.txt> for details. | ||
189 | |||
190 | config IP_PNP_RARP | ||
191 | bool "IP: RARP support" | ||
192 | depends on IP_PNP | ||
193 | help | ||
194 | If you want your Linux box to mount its whole root file system (the | ||
195 | one containing the directory /) from some other computer over the | ||
196 | net via NFS and you want the IP address of your computer to be | ||
197 | discovered automatically at boot time using the RARP protocol (an | ||
198 | older protocol which is being obsoleted by BOOTP and DHCP), say Y | ||
199 | here. Note that if you want to use RARP, a RARP server must be | ||
200 | operating on your network. Read <file:Documentation/nfsroot.txt> for | ||
201 | details. | ||
202 | |||
203 | # not yet ready.. | ||
204 | # bool ' IP: ARP support' CONFIG_IP_PNP_ARP | ||
205 | config NET_IPIP | ||
206 | tristate "IP: tunneling" | ||
207 | depends on INET | ||
208 | select INET_TUNNEL | ||
209 | ---help--- | ||
210 | Tunneling means encapsulating data of one protocol type within | ||
211 | another protocol and sending it over a channel that understands the | ||
212 | encapsulating protocol. This particular tunneling driver implements | ||
213 | encapsulation of IP within IP, which sounds kind of pointless, but | ||
214 | can be useful if you want to make your (or some other) machine | ||
215 | appear on a different network than it physically is, or to use | ||
216 | mobile-IP facilities (allowing laptops to seamlessly move between | ||
217 | networks without changing their IP addresses). | ||
218 | |||
219 | Saying Y to this option will produce two modules ( = code which can | ||
220 | be inserted in and removed from the running kernel whenever you | ||
221 | want). Most people won't need this and can say N. | ||
222 | |||
223 | config NET_IPGRE | ||
224 | tristate "IP: GRE tunnels over IP" | ||
225 | depends on INET | ||
226 | select XFRM | ||
227 | help | ||
228 | Tunneling means encapsulating data of one protocol type within | ||
229 | another protocol and sending it over a channel that understands the | ||
230 | encapsulating protocol. This particular tunneling driver implements | ||
231 | GRE (Generic Routing Encapsulation) and at this time allows | ||
232 | encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure. | ||
233 | This driver is useful if the other endpoint is a Cisco router: Cisco | ||
234 | likes GRE much better than the other Linux tunneling driver ("IP | ||
235 | tunneling" above). In addition, GRE allows multicast redistribution | ||
236 | through the tunnel. | ||
237 | |||
238 | config NET_IPGRE_BROADCAST | ||
239 | bool "IP: broadcast GRE over IP" | ||
240 | depends on IP_MULTICAST && NET_IPGRE | ||
241 | help | ||
242 | One application of GRE/IP is to construct a broadcast WAN (Wide Area | ||
243 | Network), which looks like a normal Ethernet LAN (Local Area | ||
244 | Network), but can be distributed all over the Internet. If you want | ||
245 | to do that, say Y here and to "IP multicast routing" below. | ||
246 | |||
247 | config IP_MROUTE | ||
248 | bool "IP: multicast routing" | ||
249 | depends on IP_MULTICAST | ||
250 | help | ||
251 | This is used if you want your machine to act as a router for IP | ||
252 | packets that have several destination addresses. It is needed on the | ||
253 | MBONE, a high bandwidth network on top of the Internet which carries | ||
254 | audio and video broadcasts. In order to do that, you would most | ||
255 | likely run the program mrouted. Information about the multicast | ||
256 | capabilities of the various network cards is contained in | ||
257 | <file:Documentation/networking/multicast.txt>. If you haven't heard | ||
258 | about it, you don't need it. | ||
259 | |||
260 | config IP_PIMSM_V1 | ||
261 | bool "IP: PIM-SM version 1 support" | ||
262 | depends on IP_MROUTE | ||
263 | help | ||
264 | Kernel side support for Sparse Mode PIM (Protocol Independent | ||
265 | Multicast) version 1. This multicast routing protocol is used widely | ||
266 | because Cisco supports it. You need special software to use it | ||
267 | (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more | ||
268 | information about PIM. | ||
269 | |||
270 | Say Y if you want to use PIM-SM v1. Note that you can say N here if | ||
271 | you just want to use Dense Mode PIM. | ||
272 | |||
273 | config IP_PIMSM_V2 | ||
274 | bool "IP: PIM-SM version 2 support" | ||
275 | depends on IP_MROUTE | ||
276 | help | ||
277 | Kernel side support for Sparse Mode PIM version 2. In order to use | ||
278 | this, you need an experimental routing daemon supporting it (pimd or | ||
279 | gated-5). This routing protocol is not used widely, so say N unless | ||
280 | you want to play with it. | ||
281 | |||
282 | config ARPD | ||
283 | bool "IP: ARP daemon support (EXPERIMENTAL)" | ||
284 | depends on INET && EXPERIMENTAL | ||
285 | ---help--- | ||
286 | Normally, the kernel maintains an internal cache which maps IP | ||
287 | addresses to hardware addresses on the local network, so that | ||
288 | Ethernet/Token Ring/ etc. frames are sent to the proper address on | ||
289 | the physical networking layer. For small networks having a few | ||
290 | hundred directly connected hosts or less, keeping this address | ||
291 | resolution (ARP) cache inside the kernel works well. However, | ||
292 | maintaining an internal ARP cache does not work well for very large | ||
293 | switched networks, and will use a lot of kernel memory if TCP/IP | ||
294 | connections are made to many machines on the network. | ||
295 | |||
296 | If you say Y here, the kernel's internal ARP cache will never grow | ||
297 | to more than 256 entries (the oldest entries are expired in a LIFO | ||
298 | manner) and communication will be attempted with the user space ARP | ||
299 | daemon arpd. Arpd then answers the address resolution request either | ||
300 | from its own cache or by asking the net. | ||
301 | |||
302 | This code is experimental and also obsolete. If you want to use it, | ||
303 | you need to find a version of the daemon arpd on the net somewhere, | ||
304 | and you should also say Y to "Kernel/User network link driver", | ||
305 | below. If unsure, say N. | ||
306 | |||
307 | config SYN_COOKIES | ||
308 | bool "IP: TCP syncookie support (disabled per default)" | ||
309 | depends on INET | ||
310 | ---help--- | ||
311 | Normal TCP/IP networking is open to an attack known as "SYN | ||
312 | flooding". This denial-of-service attack prevents legitimate remote | ||
313 | users from being able to connect to your computer during an ongoing | ||
314 | attack and requires very little work from the attacker, who can | ||
315 | operate from anywhere on the Internet. | ||
316 | |||
317 | SYN cookies provide protection against this type of attack. If you | ||
318 | say Y here, the TCP/IP stack will use a cryptographic challenge | ||
319 | protocol known as "SYN cookies" to enable legitimate users to | ||
320 | continue to connect, even when your machine is under attack. There | ||
321 | is no need for the legitimate users to change their TCP/IP software; | ||
322 | SYN cookies work transparently to them. For technical information | ||
323 | about SYN cookies, check out <http://cr.yp.to/syncookies.html>. | ||
324 | |||
325 | If you are SYN flooded, the source address reported by the kernel is | ||
326 | likely to have been forged by the attacker; it is only reported as | ||
327 | an aid in tracing the packets to their actual source and should not | ||
328 | be taken as absolute truth. | ||
329 | |||
330 | SYN cookies may prevent correct error reporting on clients when the | ||
331 | server is really overloaded. If this happens frequently better turn | ||
332 | them off. | ||
333 | |||
334 | If you say Y here, note that SYN cookies aren't enabled by default; | ||
335 | you can enable them by saying Y to "/proc file system support" and | ||
336 | "Sysctl support" below and executing the command | ||
337 | |||
338 | echo 1 >/proc/sys/net/ipv4/tcp_syncookies | ||
339 | |||
340 | at boot time after the /proc file system has been mounted. | ||
341 | |||
342 | If unsure, say N. | ||
343 | |||
344 | config INET_AH | ||
345 | tristate "IP: AH transformation" | ||
346 | depends on INET | ||
347 | select XFRM | ||
348 | select CRYPTO | ||
349 | select CRYPTO_HMAC | ||
350 | select CRYPTO_MD5 | ||
351 | select CRYPTO_SHA1 | ||
352 | ---help--- | ||
353 | Support for IPsec AH. | ||
354 | |||
355 | If unsure, say Y. | ||
356 | |||
357 | config INET_ESP | ||
358 | tristate "IP: ESP transformation" | ||
359 | depends on INET | ||
360 | select XFRM | ||
361 | select CRYPTO | ||
362 | select CRYPTO_HMAC | ||
363 | select CRYPTO_MD5 | ||
364 | select CRYPTO_SHA1 | ||
365 | select CRYPTO_DES | ||
366 | ---help--- | ||
367 | Support for IPsec ESP. | ||
368 | |||
369 | If unsure, say Y. | ||
370 | |||
371 | config INET_IPCOMP | ||
372 | tristate "IP: IPComp transformation" | ||
373 | depends on INET | ||
374 | select XFRM | ||
375 | select INET_TUNNEL | ||
376 | select CRYPTO | ||
377 | select CRYPTO_DEFLATE | ||
378 | ---help--- | ||
379 | Support for IP Payload Compression Protocol (IPComp) (RFC3173), | ||
380 | typically needed for IPsec. | ||
381 | |||
382 | If unsure, say Y. | ||
383 | |||
384 | config INET_TUNNEL | ||
385 | tristate "IP: tunnel transformation" | ||
386 | depends on INET | ||
387 | select XFRM | ||
388 | ---help--- | ||
389 | Support for generic IP tunnel transformation, which is required by | ||
390 | the IP tunneling module as well as tunnel mode IPComp. | ||
391 | |||
392 | If unsure, say Y. | ||
393 | |||
394 | config IP_TCPDIAG | ||
395 | tristate "IP: TCP socket monitoring interface" | ||
396 | depends on INET | ||
397 | default y | ||
398 | ---help--- | ||
399 | Support for TCP socket monitoring interface used by native Linux | ||
400 | tools such as ss. ss is included in iproute2, currently downloadable | ||
401 | at <http://developer.osdl.org/dev/iproute2>. If you want IPv6 support | ||
402 | and have selected IPv6 as a module, you need to build this as a | ||
403 | module too. | ||
404 | |||
405 | If unsure, say Y. | ||
406 | |||
407 | config IP_TCPDIAG_IPV6 | ||
408 | def_bool (IP_TCPDIAG=y && IPV6=y) || (IP_TCPDIAG=m && IPV6) | ||
409 | |||
410 | source "net/ipv4/ipvs/Kconfig" | ||
411 | |||