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