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-itg.lbl.gov/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 off use: 47 48 echo 0 > /proc/sys/net/ipv4/conf/<device>/rp_filter 49 or 50 echo 0 > /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 IP_FIB_HASH 58 59config 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 algoritm. 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 85# If the user does not enable advanced routing, he gets the safe 86# default of the fib-hash algorithm. 87config IP_FIB_HASH 88 bool 89 depends on !IP_ADVANCED_ROUTER 90 default y 91 92config IP_MULTIPLE_TABLES 93 bool "IP: policy routing" 94 depends on IP_ADVANCED_ROUTER 95 ---help--- 96 Normally, a router decides what to do with a received packet based 97 solely on the packet's final destination address. If you say Y here, 98 the Linux router will also be able to take the packet's source 99 address into account. Furthermore, the TOS (Type-Of-Service) field 100 of the packet can be used for routing decisions as well. 101 102 If you are interested in this, please see the preliminary 103 documentation at <http://www.compendium.com.ar/policy-routing.txt> 104 and <ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex>. 105 You will need supporting software from 106 <ftp://ftp.tux.org/pub/net/ip-routing/>. 107 108 If unsure, say N. 109 110config IP_ROUTE_FWMARK 111 bool "IP: use netfilter MARK value as routing key" 112 depends on IP_MULTIPLE_TABLES && NETFILTER 113 help 114 If you say Y here, you will be able to specify different routes for 115 packets with different mark values (see iptables(8), MARK target). 116 117config IP_ROUTE_MULTIPATH 118 bool "IP: equal cost multipath" 119 depends on IP_ADVANCED_ROUTER 120 help 121 Normally, the routing tables specify a single action to be taken in 122 a deterministic manner for a given packet. If you say Y here 123 however, it becomes possible to attach several actions to a packet 124 pattern, in effect specifying several alternative paths to travel 125 for those packets. The router considers all these paths to be of 126 equal "cost" and chooses one of them in a non-deterministic fashion 127 if a matching packet arrives. 128 129config IP_ROUTE_MULTIPATH_CACHED 130 bool "IP: equal cost multipath with caching support (EXPERIMENTAL)" 131 depends on: IP_ROUTE_MULTIPATH 132 help 133 Normally, equal cost multipath routing is not supported by the 134 routing cache. If you say Y here, alternative routes are cached 135 and on cache lookup a route is chosen in a configurable fashion. 136 137 If unsure, say N. 138 139config IP_ROUTE_MULTIPATH_RR 140 tristate "MULTIPATH: round robin algorithm" 141 depends on IP_ROUTE_MULTIPATH_CACHED 142 help 143 Mulitpath routes are chosen according to Round Robin 144 145config IP_ROUTE_MULTIPATH_RANDOM 146 tristate "MULTIPATH: random algorithm" 147 depends on IP_ROUTE_MULTIPATH_CACHED 148 help 149 Multipath routes are chosen in a random fashion. Actually, 150 there is no weight for a route. The advantage of this policy 151 is that it is implemented stateless and therefore introduces only 152 a very small delay. 153 154config IP_ROUTE_MULTIPATH_WRANDOM 155 tristate "MULTIPATH: weighted random algorithm" 156 depends on IP_ROUTE_MULTIPATH_CACHED 157 help 158 Multipath routes are chosen in a weighted random fashion. 159 The per route weights are the weights visible via ip route 2. As the 160 corresponding state management introduces some overhead routing delay 161 is increased. 162 163config IP_ROUTE_MULTIPATH_DRR 164 tristate "MULTIPATH: interface round robin algorithm" 165 depends on IP_ROUTE_MULTIPATH_CACHED 166 help 167 Connections are distributed in a round robin fashion over the 168 available interfaces. This policy makes sense if the connections 169 should be primarily distributed on interfaces and not on routes. 170 171config IP_ROUTE_VERBOSE 172 bool "IP: verbose route monitoring" 173 depends on IP_ADVANCED_ROUTER 174 help 175 If you say Y here, which is recommended, then the kernel will print 176 verbose messages regarding the routing, for example warnings about 177 received packets which look strange and could be evidence of an 178 attack or a misconfigured system somewhere. The information is 179 handled by the klogd daemon which is responsible for kernel messages 180 ("man klogd"). 181 182config IP_PNP 183 bool "IP: kernel level autoconfiguration" 184 help 185 This enables automatic configuration of IP addresses of devices and 186 of the routing table during kernel boot, based on either information 187 supplied on the kernel command line or by BOOTP or RARP protocols. 188 You need to say Y only for diskless machines requiring network 189 access to boot (in which case you want to say Y to "Root file system 190 on NFS" as well), because all other machines configure the network 191 in their startup scripts. 192 193config IP_PNP_DHCP 194 bool "IP: DHCP support" 195 depends on IP_PNP 196 ---help--- 197 If you want your Linux box to mount its whole root file system (the 198 one containing the directory /) from some other computer over the 199 net via NFS and you want the IP address of your computer to be 200 discovered automatically at boot time using the DHCP protocol (a 201 special protocol designed for doing this job), say Y here. In case 202 the boot ROM of your network card was designed for booting Linux and 203 does DHCP itself, providing all necessary information on the kernel 204 command line, you can say N here. 205 206 If unsure, say Y. Note that if you want to use DHCP, a DHCP server 207 must be operating on your network. Read 208 <file:Documentation/nfsroot.txt> for details. 209 210config IP_PNP_BOOTP 211 bool "IP: BOOTP support" 212 depends on IP_PNP 213 ---help--- 214 If you want your Linux box to mount its whole root file system (the 215 one containing the directory /) from some other computer over the 216 net via NFS and you want the IP address of your computer to be 217 discovered automatically at boot time using the BOOTP protocol (a 218 special protocol designed for doing this job), say Y here. In case 219 the boot ROM of your network card was designed for booting Linux and 220 does BOOTP itself, providing all necessary information on the kernel 221 command line, you can say N here. If unsure, say Y. Note that if you 222 want to use BOOTP, a BOOTP server must be operating on your network. 223 Read <file:Documentation/nfsroot.txt> for details. 224 225config IP_PNP_RARP 226 bool "IP: RARP support" 227 depends on IP_PNP 228 help 229 If you want your Linux box to mount its whole root file system (the 230 one containing the directory /) from some other computer over the 231 net via NFS and you want the IP address of your computer to be 232 discovered automatically at boot time using the RARP protocol (an 233 older protocol which is being obsoleted by BOOTP and DHCP), say Y 234 here. Note that if you want to use RARP, a RARP server must be 235 operating on your network. Read <file:Documentation/nfsroot.txt> for 236 details. 237 238# not yet ready.. 239# bool ' IP: ARP support' CONFIG_IP_PNP_ARP 240config NET_IPIP 241 tristate "IP: tunneling" 242 select INET_TUNNEL 243 ---help--- 244 Tunneling means encapsulating data of one protocol type within 245 another protocol and sending it over a channel that understands the 246 encapsulating protocol. This particular tunneling driver implements 247 encapsulation of IP within IP, which sounds kind of pointless, but 248 can be useful if you want to make your (or some other) machine 249 appear on a different network than it physically is, or to use 250 mobile-IP facilities (allowing laptops to seamlessly move between 251 networks without changing their IP addresses). 252 253 Saying Y to this option will produce two modules ( = code which can 254 be inserted in and removed from the running kernel whenever you 255 want). Most people won't need this and can say N. 256 257config NET_IPGRE 258 tristate "IP: GRE tunnels over IP" 259 select XFRM 260 help 261 Tunneling means encapsulating data of one protocol type within 262 another protocol and sending it over a channel that understands the 263 encapsulating protocol. This particular tunneling driver implements 264 GRE (Generic Routing Encapsulation) and at this time allows 265 encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure. 266 This driver is useful if the other endpoint is a Cisco router: Cisco 267 likes GRE much better than the other Linux tunneling driver ("IP 268 tunneling" above). In addition, GRE allows multicast redistribution 269 through the tunnel. 270 271config NET_IPGRE_BROADCAST 272 bool "IP: broadcast GRE over IP" 273 depends on IP_MULTICAST && NET_IPGRE 274 help 275 One application of GRE/IP is to construct a broadcast WAN (Wide Area 276 Network), which looks like a normal Ethernet LAN (Local Area 277 Network), but can be distributed all over the Internet. If you want 278 to do that, say Y here and to "IP multicast routing" below. 279 280config IP_MROUTE 281 bool "IP: multicast routing" 282 depends on IP_MULTICAST 283 help 284 This is used if you want your machine to act as a router for IP 285 packets that have several destination addresses. It is needed on the 286 MBONE, a high bandwidth network on top of the Internet which carries 287 audio and video broadcasts. In order to do that, you would most 288 likely run the program mrouted. Information about the multicast 289 capabilities of the various network cards is contained in 290 <file:Documentation/networking/multicast.txt>. If you haven't heard 291 about it, you don't need it. 292 293config IP_PIMSM_V1 294 bool "IP: PIM-SM version 1 support" 295 depends on IP_MROUTE 296 help 297 Kernel side support for Sparse Mode PIM (Protocol Independent 298 Multicast) version 1. This multicast routing protocol is used widely 299 because Cisco supports it. You need special software to use it 300 (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more 301 information about PIM. 302 303 Say Y if you want to use PIM-SM v1. Note that you can say N here if 304 you just want to use Dense Mode PIM. 305 306config IP_PIMSM_V2 307 bool "IP: PIM-SM version 2 support" 308 depends on IP_MROUTE 309 help 310 Kernel side support for Sparse Mode PIM version 2. In order to use 311 this, you need an experimental routing daemon supporting it (pimd or 312 gated-5). This routing protocol is not used widely, so say N unless 313 you want to play with it. 314 315config ARPD 316 bool "IP: ARP daemon support (EXPERIMENTAL)" 317 depends on EXPERIMENTAL 318 ---help--- 319 Normally, the kernel maintains an internal cache which maps IP 320 addresses to hardware addresses on the local network, so that 321 Ethernet/Token Ring/ etc. frames are sent to the proper address on 322 the physical networking layer. For small networks having a few 323 hundred directly connected hosts or less, keeping this address 324 resolution (ARP) cache inside the kernel works well. However, 325 maintaining an internal ARP cache does not work well for very large 326 switched networks, and will use a lot of kernel memory if TCP/IP 327 connections are made to many machines on the network. 328 329 If you say Y here, the kernel's internal ARP cache will never grow 330 to more than 256 entries (the oldest entries are expired in a LIFO 331 manner) and communication will be attempted with the user space ARP 332 daemon arpd. Arpd then answers the address resolution request either 333 from its own cache or by asking the net. 334 335 This code is experimental and also obsolete. If you want to use it, 336 you need to find a version of the daemon arpd on the net somewhere, 337 and you should also say Y to "Kernel/User network link driver", 338 below. If unsure, say N. 339 340config SYN_COOKIES 341 bool "IP: TCP syncookie support (disabled per default)" 342 ---help--- 343 Normal TCP/IP networking is open to an attack known as "SYN 344 flooding". This denial-of-service attack prevents legitimate remote 345 users from being able to connect to your computer during an ongoing 346 attack and requires very little work from the attacker, who can 347 operate from anywhere on the Internet. 348 349 SYN cookies provide protection against this type of attack. If you 350 say Y here, the TCP/IP stack will use a cryptographic challenge 351 protocol known as "SYN cookies" to enable legitimate users to 352 continue to connect, even when your machine is under attack. There 353 is no need for the legitimate users to change their TCP/IP software; 354 SYN cookies work transparently to them. For technical information 355 about SYN cookies, check out <http://cr.yp.to/syncookies.html>. 356 357 If you are SYN flooded, the source address reported by the kernel is 358 likely to have been forged by the attacker; it is only reported as 359 an aid in tracing the packets to their actual source and should not 360 be taken as absolute truth. 361 362 SYN cookies may prevent correct error reporting on clients when the 363 server is really overloaded. If this happens frequently better turn 364 them off. 365 366 If you say Y here, note that SYN cookies aren't enabled by default; 367 you can enable them by saying Y to "/proc file system support" and 368 "Sysctl support" below and executing the command 369 370 echo 1 >/proc/sys/net/ipv4/tcp_syncookies 371 372 at boot time after the /proc file system has been mounted. 373 374 If unsure, say N. 375 376config INET_AH 377 tristate "IP: AH transformation" 378 select XFRM 379 select CRYPTO 380 select CRYPTO_HMAC 381 select CRYPTO_MD5 382 select CRYPTO_SHA1 383 ---help--- 384 Support for IPsec AH. 385 386 If unsure, say Y. 387 388config INET_ESP 389 tristate "IP: ESP transformation" 390 select XFRM 391 select CRYPTO 392 select CRYPTO_HMAC 393 select CRYPTO_MD5 394 select CRYPTO_SHA1 395 select CRYPTO_DES 396 ---help--- 397 Support for IPsec ESP. 398 399 If unsure, say Y. 400 401config INET_IPCOMP 402 tristate "IP: IPComp transformation" 403 select XFRM 404 select INET_TUNNEL 405 select CRYPTO 406 select CRYPTO_DEFLATE 407 ---help--- 408 Support for IP Payload Compression Protocol (IPComp) (RFC3173), 409 typically needed for IPsec. 410 411 If unsure, say Y. 412 413config INET_TUNNEL 414 tristate "IP: tunnel transformation" 415 select XFRM 416 ---help--- 417 Support for generic IP tunnel transformation, which is required by 418 the IP tunneling module as well as tunnel mode IPComp. 419 420 If unsure, say Y. 421 422config IP_TCPDIAG 423 tristate "IP: TCP socket monitoring interface" 424 default y 425 ---help--- 426 Support for TCP socket monitoring interface used by native Linux 427 tools such as ss. ss is included in iproute2, currently downloadable 428 at <http://developer.osdl.org/dev/iproute2>. If you want IPv6 support 429 and have selected IPv6 as a module, you need to build this as a 430 module too. 431 432 If unsure, say Y. 433 434config IP_TCPDIAG_IPV6 435 def_bool (IP_TCPDIAG=y && IPV6=y) || (IP_TCPDIAG=m && IPV6) 436 437config TCP_CONG_ADVANCED 438 bool "TCP: advanced congestion control" 439 ---help--- 440 Support for selection of various TCP congestion control 441 modules. 442 443 Nearly all users can safely say no here, and a safe default 444 selection will be made (BIC-TCP with new Reno as a fallback). 445 446 If unsure, say N. 447 448# TCP Reno is builtin (required as fallback) 449menu "TCP congestion control" 450 depends on TCP_CONG_ADVANCED 451 452config TCP_CONG_BIC 453 tristate "Binary Increase Congestion (BIC) control" 454 default y 455 ---help--- 456 BIC-TCP is a sender-side only change that ensures a linear RTT 457 fairness under large windows while offering both scalability and 458 bounded TCP-friendliness. The protocol combines two schemes 459 called additive increase and binary search increase. When the 460 congestion window is large, additive increase with a large 461 increment ensures linear RTT fairness as well as good 462 scalability. Under small congestion windows, binary search 463 increase provides TCP friendliness. 464 See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ 465 466config TCP_CONG_WESTWOOD 467 tristate "TCP Westwood+" 468 default m 469 ---help--- 470 TCP Westwood+ is a sender-side only modification of the TCP Reno 471 protocol stack that optimizes the performance of TCP congestion 472 control. It is based on end-to-end bandwidth estimation to set 473 congestion window and slow start threshold after a congestion 474 episode. Using this estimation, TCP Westwood+ adaptively sets a 475 slow start threshold and a congestion window which takes into 476 account the bandwidth used at the time congestion is experienced. 477 TCP Westwood+ significantly increases fairness wrt TCP Reno in 478 wired networks and throughput over wireless links. 479 480config TCP_CONG_HTCP 481 tristate "H-TCP" 482 default m 483 ---help--- 484 H-TCP is a send-side only modifications of the TCP Reno 485 protocol stack that optimizes the performance of TCP 486 congestion control for high speed network links. It uses a 487 modeswitch to change the alpha and beta parameters of TCP Reno 488 based on network conditions and in a way so as to be fair with 489 other Reno and H-TCP flows. 490 491config TCP_CONG_HSTCP 492 tristate "High Speed TCP" 493 depends on EXPERIMENTAL 494 default n 495 ---help--- 496 Sally Floyd's High Speed TCP (RFC 3649) congestion control. 497 A modification to TCP's congestion control mechanism for use 498 with large congestion windows. A table indicates how much to 499 increase the congestion window by when an ACK is received. 500 For more detail see http://www.icir.org/floyd/hstcp.html 501 502config TCP_CONG_HYBLA 503 tristate "TCP-Hybla congestion control algorithm" 504 depends on EXPERIMENTAL 505 default n 506 ---help--- 507 TCP-Hybla is a sender-side only change that eliminates penalization of 508 long-RTT, large-bandwidth connections, like when satellite legs are 509 involved, expecially when sharing a common bottleneck with normal 510 terrestrial connections. 511 512config TCP_CONG_VEGAS 513 tristate "TCP Vegas" 514 depends on EXPERIMENTAL 515 default n 516 ---help--- 517 TCP Vegas is a sender-side only change to TCP that anticipates 518 the onset of congestion by estimating the bandwidth. TCP Vegas 519 adjusts the sending rate by modifying the congestion 520 window. TCP Vegas should provide less packet loss, but it is 521 not as aggressive as TCP Reno. 522 523config TCP_CONG_SCALABLE 524 tristate "Scalable TCP" 525 depends on EXPERIMENTAL 526 default n 527 ---help--- 528 Scalable TCP is a sender-side only change to TCP which uses a 529 MIMD congestion control algorithm which has some nice scaling 530 properties, though is known to have fairness issues. 531 See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/ 532 533endmenu 534 535config TCP_CONG_BIC 536 tristate 537 depends on !TCP_CONG_ADVANCED 538 default y 539 540source "net/ipv4/ipvs/Kconfig" 541 542