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