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 XFRM 360 select INET_XFRM_TUNNEL 361 select CRYPTO 362 select CRYPTO_DEFLATE 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 635source "net/ipv4/ipvs/Kconfig" 636 637