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