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