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