Root/net/ipv4/Kconfig

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.savetz.com/mbone/>. For most people, it's safe to say N.
13
14config IP_ADVANCED_ROUTER
15    bool "IP: advanced router"
16    ---help---
17      If you intend to run your Linux box mostly as a router, i.e. as a
18      computer that forwards and redistributes network packets, say Y; you
19      will then be presented with several options that allow more precise
20      control about the routing process.
21
22      The answer to this question won't directly affect the kernel:
23      answering N will just cause the configurator to skip all the
24      questions about advanced routing.
25
26      Note that your box can only act as a router if you enable IP
27      forwarding in your kernel; you can do that by saying Y to "/proc
28      file system support" and "Sysctl support" below and executing the
29      line
30
31      echo "1" > /proc/sys/net/ipv4/ip_forward
32
33      at boot time after the /proc file system has been mounted.
34
35      If you turn on IP forwarding, you should consider the rp_filter, which
36      automatically rejects incoming packets if the routing table entry
37      for their source address doesn't match the network interface they're
38      arriving on. This has security advantages because it prevents the
39      so-called IP spoofing, however it can pose problems if you use
40      asymmetric routing (packets from you to a host take a different path
41      than packets from that host to you) or if you operate a non-routing
42      host which has several IP addresses on different interfaces. To turn
43      rp_filter on use:
44
45      echo 1 > /proc/sys/net/ipv4/conf/<device>/rp_filter
46       or
47      echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
48
49      Note that some distributions enable it in startup scripts.
50      For details about rp_filter strict and loose mode read
51      <file:Documentation/networking/ip-sysctl.txt>.
52
53      If unsure, say N here.
54
55config IP_FIB_TRIE_STATS
56    bool "FIB TRIE statistics"
57    depends on IP_ADVANCED_ROUTER
58    ---help---
59      Keep track of statistics on structure of FIB TRIE table.
60      Useful for testing and measuring TRIE performance.
61
62config IP_MULTIPLE_TABLES
63    bool "IP: policy routing"
64    depends on IP_ADVANCED_ROUTER
65    select FIB_RULES
66    ---help---
67      Normally, a router decides what to do with a received packet based
68      solely on the packet's final destination address. If you say Y here,
69      the Linux router will also be able to take the packet's source
70      address into account. Furthermore, the TOS (Type-Of-Service) field
71      of the packet can be used for routing decisions as well.
72
73      If you are interested in this, please see the preliminary
74      documentation at <http://www.compendium.com.ar/policy-routing.txt>
75      and <ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex>.
76      You will need supporting software from
77      <ftp://ftp.tux.org/pub/net/ip-routing/>.
78
79      If unsure, say N.
80
81config 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
93config IP_ROUTE_VERBOSE
94    bool "IP: verbose route monitoring"
95    depends on IP_ADVANCED_ROUTER
96    help
97      If you say Y here, which is recommended, then the kernel will print
98      verbose messages regarding the routing, for example warnings about
99      received packets which look strange and could be evidence of an
100      attack or a misconfigured system somewhere. The information is
101      handled by the klogd daemon which is responsible for kernel messages
102      ("man klogd").
103
104config IP_ROUTE_CLASSID
105    bool
106
107config IP_PNP
108    bool "IP: kernel level autoconfiguration"
109    help
110      This enables automatic configuration of IP addresses of devices and
111      of the routing table during kernel boot, based on either information
112      supplied on the kernel command line or by BOOTP or RARP protocols.
113      You need to say Y only for diskless machines requiring network
114      access to boot (in which case you want to say Y to "Root file system
115      on NFS" as well), because all other machines configure the network
116      in their startup scripts.
117
118config IP_PNP_DHCP
119    bool "IP: DHCP support"
120    depends on IP_PNP
121    ---help---
122      If you want your Linux box to mount its whole root file system (the
123      one containing the directory /) from some other computer over the
124      net via NFS and you want the IP address of your computer to be
125      discovered automatically at boot time using the DHCP protocol (a
126      special protocol designed for doing this job), say Y here. In case
127      the boot ROM of your network card was designed for booting Linux and
128      does DHCP itself, providing all necessary information on the kernel
129      command line, you can say N here.
130
131      If unsure, say Y. Note that if you want to use DHCP, a DHCP server
132      must be operating on your network. Read
133      <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
134
135config IP_PNP_BOOTP
136    bool "IP: BOOTP support"
137    depends on IP_PNP
138    ---help---
139      If you want your Linux box to mount its whole root file system (the
140      one containing the directory /) from some other computer over the
141      net via NFS and you want the IP address of your computer to be
142      discovered automatically at boot time using the BOOTP protocol (a
143      special protocol designed for doing this job), say Y here. In case
144      the boot ROM of your network card was designed for booting Linux and
145      does BOOTP itself, providing all necessary information on the kernel
146      command line, you can say N here. If unsure, say Y. Note that if you
147      want to use BOOTP, a BOOTP server must be operating on your network.
148      Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
149
150config IP_PNP_RARP
151    bool "IP: RARP support"
152    depends on IP_PNP
153    help
154      If you want your Linux box to mount its whole root file system (the
155      one containing the directory /) from some other computer over the
156      net via NFS and you want the IP address of your computer to be
157      discovered automatically at boot time using the RARP protocol (an
158      older protocol which is being obsoleted by BOOTP and DHCP), say Y
159      here. Note that if you want to use RARP, a RARP server must be
160      operating on your network. Read
161      <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
162
163config NET_IPIP
164    tristate "IP: tunneling"
165    select INET_TUNNEL
166    select NET_IP_TUNNEL
167    ---help---
168      Tunneling means encapsulating data of one protocol type within
169      another protocol and sending it over a channel that understands the
170      encapsulating protocol. This particular tunneling driver implements
171      encapsulation of IP within IP, which sounds kind of pointless, but
172      can be useful if you want to make your (or some other) machine
173      appear on a different network than it physically is, or to use
174      mobile-IP facilities (allowing laptops to seamlessly move between
175      networks without changing their IP addresses).
176
177      Saying Y to this option will produce two modules ( = code which can
178      be inserted in and removed from the running kernel whenever you
179      want). Most people won't need this and can say N.
180
181config NET_IPGRE_DEMUX
182    tristate "IP: GRE demultiplexer"
183    help
184     This is helper module to demultiplex GRE packets on GRE version field criteria.
185     Required by ip_gre and pptp modules.
186
187config NET_IP_TUNNEL
188    tristate
189    default n
190
191config NET_IPGRE
192    tristate "IP: GRE tunnels over IP"
193    depends on (IPV6 || IPV6=n) && NET_IPGRE_DEMUX
194    select NET_IP_TUNNEL
195    help
196      Tunneling means encapsulating data of one protocol type within
197      another protocol and sending it over a channel that understands the
198      encapsulating protocol. This particular tunneling driver implements
199      GRE (Generic Routing Encapsulation) and at this time allows
200      encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure.
201      This driver is useful if the other endpoint is a Cisco router: Cisco
202      likes GRE much better than the other Linux tunneling driver ("IP
203      tunneling" above). In addition, GRE allows multicast redistribution
204      through the tunnel.
205
206config NET_IPGRE_BROADCAST
207    bool "IP: broadcast GRE over IP"
208    depends on IP_MULTICAST && NET_IPGRE
209    help
210      One application of GRE/IP is to construct a broadcast WAN (Wide Area
211      Network), which looks like a normal Ethernet LAN (Local Area
212      Network), but can be distributed all over the Internet. If you want
213      to do that, say Y here and to "IP multicast routing" below.
214
215config IP_MROUTE
216    bool "IP: multicast routing"
217    depends on IP_MULTICAST
218    help
219      This is used if you want your machine to act as a router for IP
220      packets that have several destination addresses. It is needed on the
221      MBONE, a high bandwidth network on top of the Internet which carries
222      audio and video broadcasts. In order to do that, you would most
223      likely run the program mrouted. If you haven't heard about it, you
224      don't need it.
225
226config IP_MROUTE_MULTIPLE_TABLES
227    bool "IP: multicast policy routing"
228    depends on IP_MROUTE && IP_ADVANCED_ROUTER
229    select FIB_RULES
230    help
231      Normally, a multicast router runs a userspace daemon and decides
232      what to do with a multicast packet based on the source and
233      destination addresses. If you say Y here, the multicast router
234      will also be able to take interfaces and packet marks into
235      account and run multiple instances of userspace daemons
236      simultaneously, each one handling a single table.
237
238      If unsure, say N.
239
240config IP_PIMSM_V1
241    bool "IP: PIM-SM version 1 support"
242    depends on IP_MROUTE
243    help
244      Kernel side support for Sparse Mode PIM (Protocol Independent
245      Multicast) version 1. This multicast routing protocol is used widely
246      because Cisco supports it. You need special software to use it
247      (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more
248      information about PIM.
249
250      Say Y if you want to use PIM-SM v1. Note that you can say N here if
251      you just want to use Dense Mode PIM.
252
253config IP_PIMSM_V2
254    bool "IP: PIM-SM version 2 support"
255    depends on IP_MROUTE
256    help
257      Kernel side support for Sparse Mode PIM version 2. In order to use
258      this, you need an experimental routing daemon supporting it (pimd or
259      gated-5). This routing protocol is not used widely, so say N unless
260      you want to play with it.
261
262config SYN_COOKIES
263    bool "IP: TCP syncookie support"
264    ---help---
265      Normal TCP/IP networking is open to an attack known as "SYN
266      flooding". This denial-of-service attack prevents legitimate remote
267      users from being able to connect to your computer during an ongoing
268      attack and requires very little work from the attacker, who can
269      operate from anywhere on the Internet.
270
271      SYN cookies provide protection against this type of attack. If you
272      say Y here, the TCP/IP stack will use a cryptographic challenge
273      protocol known as "SYN cookies" to enable legitimate users to
274      continue to connect, even when your machine is under attack. There
275      is no need for the legitimate users to change their TCP/IP software;
276      SYN cookies work transparently to them. For technical information
277      about SYN cookies, check out <http://cr.yp.to/syncookies.html>.
278
279      If you are SYN flooded, the source address reported by the kernel is
280      likely to have been forged by the attacker; it is only reported as
281      an aid in tracing the packets to their actual source and should not
282      be taken as absolute truth.
283
284      SYN cookies may prevent correct error reporting on clients when the
285      server is really overloaded. If this happens frequently better turn
286      them off.
287
288      If you say Y here, you can disable SYN cookies at run time by
289      saying Y to "/proc file system support" and
290      "Sysctl support" below and executing the command
291
292      echo 0 > /proc/sys/net/ipv4/tcp_syncookies
293
294      after the /proc file system has been mounted.
295
296      If unsure, say N.
297
298config NET_IPVTI
299    tristate "Virtual (secure) IP: tunneling"
300    select INET_TUNNEL
301    select NET_IP_TUNNEL
302    depends on INET_XFRM_MODE_TUNNEL
303    ---help---
304      Tunneling means encapsulating data of one protocol type within
305      another protocol and sending it over a channel that understands the
306      encapsulating protocol. This can be used with xfrm mode tunnel to give
307      the notion of a secure tunnel for IPSEC and then use routing protocol
308      on top.
309
310config INET_AH
311    tristate "IP: AH transformation"
312    select XFRM_ALGO
313    select CRYPTO
314    select CRYPTO_HMAC
315    select CRYPTO_MD5
316    select CRYPTO_SHA1
317    ---help---
318      Support for IPsec AH.
319
320      If unsure, say Y.
321
322config INET_ESP
323    tristate "IP: ESP transformation"
324    select XFRM_ALGO
325    select CRYPTO
326    select CRYPTO_AUTHENC
327    select CRYPTO_HMAC
328    select CRYPTO_MD5
329    select CRYPTO_CBC
330    select CRYPTO_SHA1
331    select CRYPTO_DES
332    ---help---
333      Support for IPsec ESP.
334
335      If unsure, say Y.
336
337config INET_IPCOMP
338    tristate "IP: IPComp transformation"
339    select INET_XFRM_TUNNEL
340    select XFRM_IPCOMP
341    ---help---
342      Support for IP Payload Compression Protocol (IPComp) (RFC3173),
343      typically needed for IPsec.
344
345      If unsure, say Y.
346
347config INET_XFRM_TUNNEL
348    tristate
349    select INET_TUNNEL
350    default n
351
352config INET_TUNNEL
353    tristate
354    default n
355
356config INET_XFRM_MODE_TRANSPORT
357    tristate "IP: IPsec transport mode"
358    default y
359    select XFRM
360    ---help---
361      Support for IPsec transport mode.
362
363      If unsure, say Y.
364
365config INET_XFRM_MODE_TUNNEL
366    tristate "IP: IPsec tunnel mode"
367    default y
368    select XFRM
369    ---help---
370      Support for IPsec tunnel mode.
371
372      If unsure, say Y.
373
374config INET_XFRM_MODE_BEET
375    tristate "IP: IPsec BEET mode"
376    default y
377    select XFRM
378    ---help---
379      Support for IPsec BEET mode.
380
381      If unsure, say Y.
382
383config INET_LRO
384    tristate "Large Receive Offload (ipv4/tcp)"
385    default y
386    ---help---
387      Support for Large Receive Offload (ipv4/tcp).
388
389      If unsure, say Y.
390
391config INET_DIAG
392    tristate "INET: socket monitoring interface"
393    default y
394    ---help---
395      Support for INET (TCP, DCCP, etc) socket monitoring interface used by
396      native Linux tools such as ss. ss is included in iproute2, currently
397      downloadable at:
398      
399        http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
400
401      If unsure, say Y.
402
403config INET_TCP_DIAG
404    depends on INET_DIAG
405    def_tristate INET_DIAG
406
407config INET_UDP_DIAG
408    tristate "UDP: socket monitoring interface"
409    depends on INET_DIAG && (IPV6 || IPV6=n)
410    default n
411    ---help---
412      Support for UDP socket monitoring interface used by the ss tool.
413      If unsure, say Y.
414
415menuconfig TCP_CONG_ADVANCED
416    bool "TCP: advanced congestion control"
417    ---help---
418      Support for selection of various TCP congestion control
419      modules.
420
421      Nearly all users can safely say no here, and a safe default
422      selection will be made (CUBIC with new Reno as a fallback).
423
424      If unsure, say N.
425
426if TCP_CONG_ADVANCED
427
428config TCP_CONG_BIC
429    tristate "Binary Increase Congestion (BIC) control"
430    default m
431    ---help---
432    BIC-TCP is a sender-side only change that ensures a linear RTT
433    fairness under large windows while offering both scalability and
434    bounded TCP-friendliness. The protocol combines two schemes
435    called additive increase and binary search increase. When the
436    congestion window is large, additive increase with a large
437    increment ensures linear RTT fairness as well as good
438    scalability. Under small congestion windows, binary search
439    increase provides TCP friendliness.
440    See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
441
442config TCP_CONG_CUBIC
443    tristate "CUBIC TCP"
444    default y
445    ---help---
446    This is version 2.0 of BIC-TCP which uses a cubic growth function
447    among other techniques.
448    See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
449
450config TCP_CONG_WESTWOOD
451    tristate "TCP Westwood+"
452    default m
453    ---help---
454    TCP Westwood+ is a sender-side only modification of the TCP Reno
455    protocol stack that optimizes the performance of TCP congestion
456    control. It is based on end-to-end bandwidth estimation to set
457    congestion window and slow start threshold after a congestion
458    episode. Using this estimation, TCP Westwood+ adaptively sets a
459    slow start threshold and a congestion window which takes into
460    account the bandwidth used at the time congestion is experienced.
461    TCP Westwood+ significantly increases fairness wrt TCP Reno in
462    wired networks and throughput over wireless links.
463
464config TCP_CONG_HTCP
465        tristate "H-TCP"
466        default m
467    ---help---
468    H-TCP is a send-side only modifications of the TCP Reno
469    protocol stack that optimizes the performance of TCP
470    congestion control for high speed network links. It uses a
471    modeswitch to change the alpha and beta parameters of TCP Reno
472    based on network conditions and in a way so as to be fair with
473    other Reno and H-TCP flows.
474
475config TCP_CONG_HSTCP
476    tristate "High Speed TCP"
477    default n
478    ---help---
479    Sally Floyd's High Speed TCP (RFC 3649) congestion control.
480    A modification to TCP's congestion control mechanism for use
481    with large congestion windows. A table indicates how much to
482    increase the congestion window by when an ACK is received.
483     For more detail see http://www.icir.org/floyd/hstcp.html
484
485config TCP_CONG_HYBLA
486    tristate "TCP-Hybla congestion control algorithm"
487    default n
488    ---help---
489    TCP-Hybla is a sender-side only change that eliminates penalization of
490    long-RTT, large-bandwidth connections, like when satellite legs are
491    involved, especially when sharing a common bottleneck with normal
492    terrestrial connections.
493
494config TCP_CONG_VEGAS
495    tristate "TCP Vegas"
496    default n
497    ---help---
498    TCP Vegas is a sender-side only change to TCP that anticipates
499    the onset of congestion by estimating the bandwidth. TCP Vegas
500    adjusts the sending rate by modifying the congestion
501    window. TCP Vegas should provide less packet loss, but it is
502    not as aggressive as TCP Reno.
503
504config TCP_CONG_SCALABLE
505    tristate "Scalable TCP"
506    default n
507    ---help---
508    Scalable TCP is a sender-side only change to TCP which uses a
509    MIMD congestion control algorithm which has some nice scaling
510    properties, though is known to have fairness issues.
511    See http://www.deneholme.net/tom/scalable/
512
513config TCP_CONG_LP
514    tristate "TCP Low Priority"
515    default n
516    ---help---
517    TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
518    to utilize only the excess network bandwidth as compared to the
519    ``fair share`` of bandwidth as targeted by TCP.
520    See http://www-ece.rice.edu/networks/TCP-LP/
521
522config TCP_CONG_VENO
523    tristate "TCP Veno"
524    default n
525    ---help---
526    TCP Veno is a sender-side only enhancement of TCP to obtain better
527    throughput over wireless networks. TCP Veno makes use of state
528    distinguishing to circumvent the difficult judgment of the packet loss
529    type. TCP Veno cuts down less congestion window in response to random
530    loss packets.
531    See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186>
532
533config TCP_CONG_YEAH
534    tristate "YeAH TCP"
535    select TCP_CONG_VEGAS
536    default n
537    ---help---
538    YeAH-TCP is a sender-side high-speed enabled TCP congestion control
539    algorithm, which uses a mixed loss/delay approach to compute the
540    congestion window. It's design goals target high efficiency,
541    internal, RTT and Reno fairness, resilience to link loss while
542    keeping network elements load as low as possible.
543
544    For further details look here:
545      http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
546
547config TCP_CONG_ILLINOIS
548    tristate "TCP Illinois"
549    default n
550    ---help---
551    TCP-Illinois is a sender-side modification of TCP Reno for
552    high speed long delay links. It uses round-trip-time to
553    adjust the alpha and beta parameters to achieve a higher average
554    throughput and maintain fairness.
555
556    For further details see:
557      http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
558
559choice
560    prompt "Default TCP congestion control"
561    default DEFAULT_CUBIC
562    help
563      Select the TCP congestion control that will be used by default
564      for all connections.
565
566    config DEFAULT_BIC
567        bool "Bic" if TCP_CONG_BIC=y
568
569    config DEFAULT_CUBIC
570        bool "Cubic" if TCP_CONG_CUBIC=y
571
572    config DEFAULT_HTCP
573        bool "Htcp" if TCP_CONG_HTCP=y
574
575    config DEFAULT_HYBLA
576        bool "Hybla" if TCP_CONG_HYBLA=y
577
578    config DEFAULT_VEGAS
579        bool "Vegas" if TCP_CONG_VEGAS=y
580
581    config DEFAULT_VENO
582        bool "Veno" if TCP_CONG_VENO=y
583
584    config DEFAULT_WESTWOOD
585        bool "Westwood" if TCP_CONG_WESTWOOD=y
586
587    config DEFAULT_RENO
588        bool "Reno"
589
590endchoice
591
592endif
593
594config TCP_CONG_CUBIC
595    tristate
596    depends on !TCP_CONG_ADVANCED
597    default y
598
599config DEFAULT_TCP_CONG
600    string
601    default "bic" if DEFAULT_BIC
602    default "cubic" if DEFAULT_CUBIC
603    default "htcp" if DEFAULT_HTCP
604    default "hybla" if DEFAULT_HYBLA
605    default "vegas" if DEFAULT_VEGAS
606    default "westwood" if DEFAULT_WESTWOOD
607    default "veno" if DEFAULT_VENO
608    default "reno" if DEFAULT_RENO
609    default "cubic"
610
611config TCP_MD5SIG
612    bool "TCP: MD5 Signature Option support (RFC2385)"
613    select CRYPTO
614    select CRYPTO_MD5
615    ---help---
616      RFC2385 specifies a method of giving MD5 protection to TCP sessions.
617      Its main (only?) use is to protect BGP sessions between core routers
618      on the Internet.
619
620      If unsure, say N.
621

Archive Download this file



interactive