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