Browse files

Git repository created from hping3-clockskew-0.tar.gz

This is, AFAIK, the most latest source code for hping3.
Last time I worked at it was September 2006.
  • Loading branch information...
0 parents commit 7257579bc9e722d3f1e28d42c0cd93d769260b2b @antirez committed Jun 13, 2012
Showing with 41,629 additions and 0 deletions.
  1. +45 −0 AUTHORS
  2. +13 −0 BUGS
  3. +4 −0 CHANGES
  4. +351 −0 COPYING
  5. +62 −0 INSTALL
  6. +1 −0 KNOWN-BUGS
  7. +92 −0 Makefile.in
  8. +46 −0 NEWS
  9. +93 −0 README
  10. +28 −0 RFCs/INDEX
  11. +619 −0 RFCs/rfc1063.txt
  12. +893 −0 RFCs/rfc1072.txt
  13. +6,844 −0 RFCs/rfc1122.txt
  14. +2,075 −0 RFCs/rfc1323.txt
  15. +9,803 −0 RFCs/rfc1812.txt
  16. +675 −0 RFCs/rfc2018.txt
  17. +1,347 −0 RFCs/rfc2236.txt
  18. +2,187 −0 RFCs/rfc2460.txt
  19. +174 −0 RFCs/rfc768.txt
  20. +2,887 −0 RFCs/rfc791.txt
  21. +1,218 −0 RFCs/rfc792.txt
  22. +5,247 −0 RFCs/rfc793.txt
  23. +470 −0 RFCs/rfc826.txt
  24. +1,026 −0 RFCs/rfc950.txt
  25. +53 −0 TODO
  26. +375 −0 adbuf.c
  27. +45 −0 adbuf.h
  28. +297 −0 antigetopt.c
  29. +35 −0 antigetopt.h
  30. +1,037 −0 apd.c
  31. +152 −0 apdutils.c
  32. +10 −0 apdutils.h
  33. +989 −0 ars.c
  34. +531 −0 ars.h
  35. +34 −0 arsglue.c
  36. +57 −0 binding.c
  37. +79 −0 byteorder.c
  38. +33 −0 cksum.c
  39. +166 −0 configure
  40. +76 −0 datafiller.c
  41. +41 −0 datahandler.c
  42. +138 −0 display_ipopt.c
  43. +125 −0 docs/APD.txt
  44. +478 −0 docs/API.txt
  45. +37 −0 docs/AS-BACKDOOR
  46. +440 −0 docs/HPING2-HOWTO.txt
  47. +15 −0 docs/HPING2-IS-OPEN
  48. +1 −0 docs/HPING3.txt
  49. +29 −0 docs/MORE-FUN-WITH-IPID
  50. +119 −0 docs/SPOOFED_SCAN.txt
  51. +37 −0 docs/french/AS-BACKDOOR
Sorry, we could not display the entire diff because it was too big.
45 AUTHORS
@@ -0,0 +1,45 @@
+Lead developer and maintainer:
+
+ Salvatore Sanfilippo <antirez@invece.org>
+
+Regular contributors:
+
+ Nicolas Jombart <Nicolas.Jombart@hsc.fr>
+ Denis Ducamp <Denis.Ducamp@hsc.fr>
+ Yann Berthier <Yann.Berthier@hsc.fr>
+ Stephane Aubert <Stephane.Aubert@hsc.fr>
+
+Other contributors:
+
+ Brieuc Jeunhomme <bbp@via.ecp.fr>
+ Mika <mika@qualys.com>
+ Alfonso De Gregorio <fhex@speedcom.it>
+ Francesco Potorti` <pot@gnu.org>
+ Daniel Ginsburg <dbg@nm.ru>
+ Steve Bleazard <steve@bleazard.com>
+
+
+Also thanks to the following people for testing, bug reports, ideas,
+minor patches, documentation fixes:
+
+ Valeriano Bedeschi <vale@seclab.com>
+ Lorenzo Cavallaro <sullivan@seclab.com>
+ awgn roofing <root@roof.penguinpowered.com>
+ Darren Reed <avalon@COOMBS.ANU.EDU.AU>
+ Lance Spitzner <lance@spitzner.net>
+ Stefano Brandimarte <stevens@alicom.com>
+ "roy kozzer" <royk50@hotmail.com>
+ Jason Lunz <j@trellisinc.com>
+ Domenico Andreoli <cavok@filibusta.crema.unimi.it>
+ Gian-Luca Dei Rossi <acaso@venezia.linux.it>
+ Marco D'Itri <md@linux.it>
+ Rui Miguel Barbosa Machado <rmbm@rccn.net>
+ David Bar <dbar@Checkpoint.com>
+ David Coppa <coffeec@tin.it>
+ Shachar Shemesh <sun@consumer.org.il>
+ Brieuc Jeunhomme <bbp@via.ecp.fr>
+ Hans-Joachim Knobloch <knobloch@secorvo.de>
+ Olivier Warin <daffy@oav.net>
+
+--------------------------------------------------------------------------------
+Note: if you aren't in this list for an oversight, please inform me.
13 BUGS
@@ -0,0 +1,13 @@
+------------------------------------------------
+Please, use this procedure to report hping3 bugs
+------------------------------------------------
+
+- If you are able to use a Wiki:
+
+ Go to http://wiki.hping.org/20 and use the 'edit' button to
+ add your bug report.
+
+- If you can't use the Wiki:
+
+ Follow the istructions at wiki.hping.org/20 but instead to add
+ the bug report in the hping web site, write me an email.
4 CHANGES
@@ -0,0 +1,4 @@
+CHANGES LOG
+$Id: CHANGES,v 1.2 2004/03/29 23:12:04 antirez Exp $
+
+30Mar2004 - First public release of hping3
351 COPYING
@@ -0,0 +1,351 @@
+hping2 is free software. It comes under GPL version 2,
+except for the following:
+
+display_ipopt.c : from ping, BSD style license
+libpcap library : BSD style license
+
+for more information see the upper part of this files.
+
+WARNING: hping2 is covered *ONLY* by GPL version 2, and *NOT* any others.
+
+hping2 is Copyright (C) 1998, 1999 by Salvatore Sanfilippo.
+
+ GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 675 Mass Ave, Cambridge, MA 02139, USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.) You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must show them these terms so they know their
+rights.
+
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary. To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+ GNU GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License. The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language. (Hereinafter, translation is included without limitation in
+the term "modification".) Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+ 1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+ 2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+ a) You must cause the modified files to carry prominent notices
+ stating that you changed the files and the date of any change.
+
+ b) You must cause any work that you distribute or publish, that in
+ whole or in part contains or is derived from the Program or any
+ part thereof, to be licensed as a whole at no charge to all third
+ parties under the terms of this License.
+
+ c) If the modified program normally reads commands interactively
+ when run, you must cause it, when started running for such
+ interactive use in the most ordinary way, to print or display an
+ announcement including an appropriate copyright notice and a
+ notice that there is no warranty (or else, saying that you provide
+ a warranty) and that users may redistribute the program under
+ these conditions, and telling the user how to view a copy of this
+ License. (Exception: if the Program itself is interactive but
+ does not normally print such an announcement, your work based on
+ the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+ 3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+ a) Accompany it with the complete corresponding machine-readable
+ source code, which must be distributed under the terms of Sections
+ 1 and 2 above on a medium customarily used for software interchange; or,
+
+ b) Accompany it with a written offer, valid for at least three
+ years, to give any third party, for a charge no more than your
+ cost of physically performing source distribution, a complete
+ machine-readable copy of the corresponding source code, to be
+ distributed under the terms of Sections 1 and 2 above on a medium
+ customarily used for software interchange; or,
+
+ c) Accompany it with the information you received as to the offer
+ to distribute corresponding source code. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form with such
+ an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it. For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable. However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+ 4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License. Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+ 5. You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Program or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+ 6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+ 7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all. For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+ 8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded. In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+ 9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation. If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+ 10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission. For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this. Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+ NO WARRANTY
+
+ 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+ 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+
+ Appendix: How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+ <one line to give the program's name and a brief idea of what it does.>
+ Copyright (C) 19yy <name of author>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+ Gnomovision version 69, Copyright (C) 19yy name of author
+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+ <signature of Ty Coon>, 1 April 1989
+ Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs. If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library. If this is what you want to do, use the GNU Library General
+Public License instead of this License.
62 INSTALL
@@ -0,0 +1,62 @@
+You can compile hping3 at least under:
+
+Linux
+OpenBSD
+FreeBSD
+NetBSD
+Solaris
+
+But hping3 is beta, for now it was mostly tested only in Linux,
+this should change soon now that the first beta is out.
+
+Note that starting from hping3 libpcap should be used
+with all the kind of systems, including Linux.
+
+Linux
+-----
+
+please, follows this steps:
+
+$ ./configure (first try ./configure --help)
+$ vi Makefile (optional)
+$ make
+$ su
+# make install
+
+FreeBSD, OpenBSD, NetBSD
+------------------------
+
+You will need the libpcap and the gmake utility installed on your system.
+
+$ ./configure
+$ gmake
+$ su (or calife)
+# gmake install
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+NOTE: You should take care about your net/bpf.h file installing on
+ BSD systems (specially with OpenBSD). If your original bpf.h was
+ overwritten with the libpcap one probably hping will not work
+ with over some interface.
+
+ For example if you use the libpcap bpf.h on OpenBSD hping will
+ not work over PPP interfaces.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Solaris
+-------
+
+$ export CC="gcc"
+$ ./configure
+$ gmake
+$ su
+# gmake install
+
+ALL
+---
+
+To setuid hping3 is like to open the port to script kiddies
+for now. Don't do it in any real multiuser and otherwise
+security-sensitive system.
+
+antirez
1 KNOWN-BUGS
@@ -0,0 +1 @@
+See the BUGS manual section.
92 Makefile.in
@@ -0,0 +1,92 @@
+# $smu-mark$
+# $name: Makefile.in$
+# $author: Salvatore Sanfilippo 'antirez'$
+# $copyright: Copyright (C) 1999 by Salvatore Sanfilippo$
+# $license: This software is under GPL version 2 of license$
+# $date: Sun Jul 25 17:56:15 MET DST 1999$
+# $rev: 3$
+
+CC= gcc
+AR=/usr/bin/ar
+RANLIB=/usr/bin/ranlib
+CCOPT= -O2 -Wall @PCAP_INCLUDE@ @TCL_INC@ @USE_TCL@
+DEBUG= -g
+#uncomment the following if you need libpcap based build under linux
+#(not raccomanded)
+COMPILE_TIME=
+INSTALL_MANPATH=@MANPATH@
+@PCAP@
+
+ARSOBJ = ars.o apd.o split.o rapd.o
+
+OBJ= main.o getifname.o getlhs.o \
+ parseoptions.o datafiller.o \
+ datahandler.o gethostname.o \
+ binding.o getusec.o opensockraw.o \
+ logicmp.o waitpacket.o resolve.o \
+ sendip.o sendicmp.o sendudp.o \
+ sendtcp.o cksum.o statistics.o \
+ usage.o version.o antigetopt.o \
+ sockopt.o listen.o \
+ sendhcmp.o memstr.o rtt.o \
+ relid.o sendip_handler.o \
+ libpcap_stuff.o memlockall.o memunlockall.o \
+ memlock.o memunlock.o ip_opt_build.o \
+ display_ipopt.o sendrawip.o signal.o send.o \
+ strlcpy.o arsglue.o random.o scan.o \
+ hstring.o script.o interface.o \
+ adbuf.o hex.o apdutils.o sbignum.o \
+ sbignum-tables.o $(ARSOBJ)
+
+all: .depend hping3
+
+dep: .depend
+.depend:
+ @echo Making dependences
+ @$(CC) -MM *.c > .depend
+
+libars.a: $(ARSOBJ)
+ $(AR) rc $@ $^
+ $(RANLIB) $@
+
+hping3: byteorder.h $(OBJ)
+ $(CC) -o hping3 $(CCOPT) $(DEBUG) $(OBJ) -L/usr/local/lib $(PCAP) @SOLARISLIB@ @TCL_LIB@
+ @echo
+ ./hping3 -v
+ @echo "use \`make strip' to strip hping3 binary"
+ @echo "use \`make install' to install hping3"
+
+hping3-static: byteorder.h $(OBJ)
+ $(CC) -static -o hping3-static $(CCOPT) $(DEBUG) $(OBJ) -L/usr/local/lib $(PCAP) @SOLARISLIB@ @TCL_LIB@ -ldl
+
+byteorder.h:
+ ./configure
+
+.c.o:
+ $(CC) -c $(CCOPT) $(DEBUG) $(COMPILE_TIME) $<
+
+clean:
+ rm -rf hping3 *.o libars.a
+
+distclean:
+ rm -rf hping3 *.o byteorder byteorder.h systype.h Makefile libars.a .depend
+
+install: hping3
+ cp -f hping3 /usr/sbin/
+ chmod 755 /usr/sbin/hping3
+ ln -s /usr/sbin/hping3 /usr/sbin/hping
+ ln -s /usr/sbin/hping3 /usr/sbin/hping2
+ @if [ -d ${INSTALL_MANPATH}/man8 ]; then \
+ cp ./docs/hping3.8 ${INSTALL_MANPATH}/man8; \
+ chmod 644 ${INSTALL_MANPATH}/man8/hping3.8; \
+ else \
+ echo "@@@@@@ WARNING @@@@@@"; \
+ echo "Can't install the man page: ${INSTALL_MANPATH}/man8 does not exist"; \
+ fi
+
+strip: hping3
+ @ls -l ./hping3
+ strip hping3
+ @ls -l ./hping3
+
+include .depend
46 NEWS
@@ -0,0 +1,46 @@
+Read the README file to know about the new features in general.
+
+------ hping3 alpha2 -------
+
+Two new features for the command line interface.
+
+1) Using the --beep option hping will produce a beep for every matching
+ packet received (not for ICMP errors).
+
+2) The --flood option to send packets as fast as possible. This
+ is much faster than "-i u1", because it's actually an endless
+ loop and in this mode hping will not care to read/show replies
+ at all.
+
+------ hping3 alpha1 -------
+
+Read the docs/API.txt for information about scripting capabilties.
+
+Check the libs directory for examples of hping scripts.
+
+Try the --scan option in the command line to see the port-scanner features.
+
+ Example of the --scan option usage:
+
+# hping3 --scan known 1.2.3.4 -S
+
+Scanning 1.2.3.4 (1.2.3.4), port known
+245 ports to scan, use -V to see all the replies
++----+-----------+---------+---+-----+-----+-----+
+|port| serv name | flags |ttl| id | win | len |
++----+-----------+---------+---+-----+-----+-----+
+ 9 discard : .S..A... 64 0 32767 44
+ 13 daytime : .S..A... 64 0 32767 44
+ 21 ftp : .S..A... 64 0 32767 44
+ 22 ssh : .S..A... 64 0 32767 44
+ 25 smtp : .S..A... 64 0 32767 44
+ 37 time : .S..A... 64 0 32767 44
+ 80 www : .S..A... 64 0 32767 44
+ 111 sunrpc : .S..A... 64 0 32767 44
+ 113 auth : .S..A... 64 0 32767 44
+ 631 ipp : .S..A... 64 0 32767 44
+ 3306 mysql : .S..A... 64 0 32767 44
+ 6000 x11 : .S..A... 64 0 32767 44
+ 6667 ircd : .S..A... 64 0 3072 44
+All replies received. Done.
+Not responding ports:
93 README
@@ -0,0 +1,93 @@
+hping3 README file
+antirez@invece.org
+
+DESCRIPTION
+
+ hping3 is a network tool able to send custom TCP/IP
+ packets and to display target replies like ping do with
+ ICMP replies. hping3 can handle fragmentation, and
+ almost arbitrary packet size and content, using the
+ command line interface.
+
+ Since version 3, hping implements scripting capabilties,
+ read the API.txt file under the /docs directory to know
+ more about it.
+
+ As a command line utility, hping is useful to test at
+ many kind of networking devices like firewalls, routers,
+ and so. It can be used as a traceroute alike program over all
+ the supported protocols, firewalk usage, OS fingerprinting,
+ port-scanner (see the --scan option introduced with hping3),
+ TCP/IP stack auditing.
+
+ It's also really a good didactic tool to learn TCP/IP.
+
+ Using Tcl/Tk scripting much more can be done, because
+ while the hping3 packet generation code is actually the
+ hping2 put there mainly for compatibility with the command
+ line interface, all the real news are about scripting.
+
+ See the libs directory for example scripts. To run
+ the example scripts type:
+
+ hping3 exec ScriptName.htcl <arguments, if required>
+
+ hping3 is developed and manteined by antirez@invece.org
+ with the help of other hackers, and comes under GPL version
+ 2 of license. Development is open so you can send me
+ patches/suggestions/affronts without inhibitions.
+
+ Please check the AUTHORS file for a list of people that
+ contribued with code, ideas, bug reports.
+
+ Also vim developer, ee.lbl.gov for tcpdump and GNU in general.
+
+DOCUMENTATION
+
+ For the hping3 API check docs/API.txt
+
+ You can find documentation about hping3 specific functions
+ at http://wiki.hping.org
+
+ Make sure to check the page at http://wiki.hping.org/34
+
+DOWNLOAD
+
+ The hping3 primary download site is the following:
+
+ http://www.hping.org
+
+ ----------------------------------------------------------------
+ How to get the hping3 source code from the anonymous CVS server
+ ----------------------------------------------------------------
+
+ $ cvs -d :pserver:anonymous@cvs.hping2.sourceforge.net:/cvsroot/hping2 login
+
+ CVS will ask for the password, just press enter, no password is required
+
+ than type the following to download the full source code.
+
+ $ cvs -z8 -d :pserver:anonymous@cvs.hping2.sourceforge.net:/cvsroot/hping2 checkout hping3s
+
+ -----------------------------------
+ How to update your source code tree
+ -----------------------------------
+
+ change the current directory to /somewhere/hping2, than just type:
+
+ $ cvs update
+
+REQUIREMENTS
+
+ A supported unix-like OS, gcc, root access.
+
+ Libpcap.
+
+ Tcl/Tk is optional but strongly suggested.
+
+INSTALLATION
+
+ see INSTALL file.
+
+have fun,
+antirez
28 RFCs/INDEX
@@ -0,0 +1,28 @@
+The ARS lib is useless without knowledge about TCP/IP.
+This are the RFCs you need to learn what you need, or to
+refresh your memory.
+
+FILENAME RFC TITLE
+-------- ---------
+
+rfc768.txt User Datagram Protocol
+rfc791.txt INTERNET PROTOCOL
+rfc792.txt INTERNET CONTROL MESSAGE PROTOCOL
+rfc793.txt TRANSMISSION CONTROL PROTOCOL
+rfc826.txt An Ethernet Address Resolution Protocol
+rfc950.txt Internet Standard Subnetting Procedure
+rfc1063.txt IP MTU Discovery Options
+rfc1072.txt TCP Extensions for Long-Delay Paths
+rfc1112.txt Host Extensions for IP Multicasting
+rfc1122.txt Requirements for Internet Hosts -- Communication Layers
+rfc1323.txt TCP Extensions for High Performance
+rfc1812.txt Requirements for IP Version 4 Routers
+rfc2018.txt TCP Selective Acknowledgment Options
+rfc2236.txt Internet Group Management Protocol, Version 2
+rfc2460.txt Internet Protocol, Version 6 (IPv6)
+
+Note that:
+
+rfc950 Contains information about ICMP extensions
+rfc1072 Contains information about TCP options
+rfc1112 Contains information about the IGMP protocol
619 RFCs/rfc1063.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group J. Mogul
+Request For Comments: 1063 C. Kent
+ DEC
+ C. Partridge
+ BBN
+ K. McCloghrie
+ TWG
+ July 1988
+
+
+ IP MTU Discovery Options
+
+STATUS OF THIS MEMO
+
+ A pair of IP options that can be used to learn the minimum MTU of a
+ path through an internet is described, along with its possible uses.
+ This is a proposal for an Experimental protocol. Distribution of
+ this memo is unlimited.
+
+INTRODUCTION
+
+ Although the Internet Protocol allows gateways to fragment packets
+ that are too large to forward, fragmentation is not always desirable.
+ It can lead to poor performance or even total communication failure
+ in circumstances that are surprisingly common. (For a thorough
+ discussion of this issue, see [1]).
+
+ A datagram will be fragmented if it is larger than the Maximum
+ Transmission Unit (MTU) of some network along the path it follows.
+ In order to avoid fragmentation, a host sending an IP datagram must
+ ensure that the datagram is no larger than the Minimum MTU (MINMTU)
+ over the entire path.
+
+ It has long been recognized that the methods for discovering the
+ MINMTU of an IP internetwork path are inadequate. The methods
+ currently available fall into two categories: (1) choosing small MTUs
+ to avoid fragmentation or (2) using additional probe packets to
+ discover when fragmentation will occur. Both methods have problems.
+
+ Choosing MTUs requires a balance between network utilization (which
+ requires the use of the largest possible datagram) and fragmentation
+ avoidance (which in the absence of knowledge about the network path
+ encourages the use of small, and thus too many, datagrams). Any
+ choice for the MTU size, without information from the network, is
+ likely to either fail to properly utilize the network or fail to
+ avoid fragmentation.
+
+ Probe packets have the problem of burdening the network with
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 1]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ unnecessary packets. And because network paths often change during
+ the lifetime of a TCP connection, probe packets will have to be sent
+ on a regular basis to detect any changes in the effective MINMTU.
+
+ Implementors sometimes mistake the TCP MSS option as a mechanism for
+ learning the network MINMTU. In fact, the MSS option is only a
+ mechanism for learning about buffering capabilities at the two TCP
+ peers. Separate provisions must be made to learn the IP MINMTU.
+
+ In this memo, we propose two new IP options that, when used in
+ conjunction will permit two peers to determine the MINMTU of the
+ paths between them. In this scheme, one option is used to determine
+ the lowest MTU in a path; the second option is used to convey this
+ MTU back to the sender (possibly in the IP datagram containing the
+ transport acknowledgement to the datagram which contained the MTU
+ discovery option).
+
+OPTION FORMATS
+
+ Probe MTU Option (Number 11)
+
+ Format
+
+ +--------+--------+--------+--------+
+ |00001011|00000100| 2 octet value |
+ +--------+--------+--------+--------+
+
+ Definition
+
+ This option always contains the lowest MTU of all the networks
+ that have been traversed so far by the datagram.
+
+ A host that sends this option must initialize the value field to
+ be the MTU of the directly-connected network. If the host is
+ multi-homed, this should be for the first-hop network.
+
+ Each gateway that receives a datagram containing this option must
+ compare the MTU field with the MTUs of the inbound and outbound
+ links for the datagram. If either MTU is lower than the value in
+ the MTU field of the option, the option value should be set to the
+ lower MTU. (Note that gateways conforming to RFC-1009 may not
+ know either the inbound interface or the outbound interface at the
+ time that IP options are processed. Accordingly, support for this
+ option may require major gateway software changes).
+
+ Any host receiving a datagram containing this option should
+ confirm that value of the MTU field of the option is less than or
+ equal to that of the inbound link, and if necessary, reduce the
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 2]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ MTU field value, before processing the option.
+
+ If the receiving host is not able to accept datagrams as large as
+ specified by the value of the MTU field of the option, then it
+ should reduce the MTU field to the size of the largest datagram it
+ can accept.
+
+ Reply MTU Option (Number 12)
+
+ Format
+
+ +--------+--------+--------+--------+
+ |00001100|00000100| 2 octet value |
+ +--------+--------+--------+--------+
+
+ Definition
+
+ This option is used to return the value learned from a Probe MTU
+ option to the sender of the Probe MTU option.
+
+RELATION TO TCP MSS
+
+ Note that there are two superficially similar problems in choosing
+ the size of a datagram. First, there is the restriction [2] that a
+ host not send a datagram larger than 576 octets unless it has
+ assurance that the destination is prepared to accept a larger
+ datagram. Second, the sending host should not send a datagram larger
+ than MINMTU, in order to avoid fragmentation. The datagram size
+ should normally be the minimum of these two lower bounds.
+
+ In the past, the TCP MSS option [3] has been used to avoid sending
+ packets larger than the destination can accept. Unfortunately, this
+ is not the most general mechanism; it is not available to other
+ transport layers, and it cannot determine the MINMTU (because
+ gateways do not parse TCP options).
+
+ Because the MINMTU returned by a probe cannot be larger than the
+ maximum datagram size that the destination can accept, this IP option
+ could, in theory, supplant the use of the TCP MSS option, providing
+ an economy of mechanism. (Note however, that some researchers
+ believe that the value of the TCP MSS is distinct from the path's
+ MINMTU. The MSS is the upper limit of the data size that the peer
+ will accept, while the MINMTU represents a statement about the data
+ size supported by the path).
+
+ Note that a failure to observe the MINMTU restriction is not normally
+ fatal; fragmentation will occur, but this is supposed to work. A
+ failure to observe the TCP MSS option, however, could be fatal
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 3]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ because it might lead to datagrams that can never be accepted by the
+ destination. Therefore, unless and until the Probe MTU option is
+ universally implemented, at least by hosts, the TCP MSS option must
+ be used as well.
+
+IMPLEMENTATION APPROACHES
+
+ Who Sends the Option
+
+ There are at least two ways to implement the MTU discovery scheme.
+ One method makes the transport layer responsible for MTU
+ discovery; the other method makes the IP layer responsible for MTU
+ discovery. A host system should support one of the two schemes.
+
+ Transport Discovery
+
+ In the transport case, the transport layer can include the Probe
+ MTU option in an outbound datagram. When a datagram containing
+ the Probe MTU option is received, the option must be passed up to
+ the receiving transport layer, which should then acknowledge the
+ Probe with a Reply MTU option in the next return datagram. Note
+ that because the options are placed on unreliable datagrams, the
+ original sender will have to resend Probes (possibly once per
+ window of data) until it receives a Reply option. Also note that
+ the Reply MTU option may be returned on an IP datagram for a
+ different transport protocol from which it was sent (e.g., TCP
+ generated the probe but the Reply was received on a UDP datagram).
+
+ IP Discovery
+
+ A better scheme is to put MTU discovery into the IP layer, using
+ control mechanisms in the routing cache. Whenever an IP datagram
+ is sent, the IP layer checks in the routing cache to see if a
+ Probe or Reply MTU option needs to be inserted in the datagram.
+ Whenever a datagram containing either option is received, the
+ information in those options is placed in the routing cache.
+
+ The basic working of the protocol is somewhat complex. We trace
+ it here through one round-trip. Implementors should realize that
+ there may be cases where both options are contained in one
+ datagram. For the purposes of this exposition, the sender of the
+ probe is called the Probe-Sender and the receiver, Probe-Receiver.
+
+ When the IP layer is asked to send a Probe MTU option (see the
+ section below on when to probe), it makes some record in the
+ routing cache that indicates the next IP datagram to Probe-
+ Receiver should contain the Probe MTU option.
+
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 4]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ When the next IP datagram to Probe-Receiver is sent, the Probe MTU
+ option is inserted. The IP layer in Probe-Sender should continue
+ to send an occasional Probe MTU in subsequent datagrams until a
+ Reply MTU option is received. It is strongly recommended that the
+ Probe MTU not be sent in all datagrams but only at such a rate
+ that, on average, one Probe MTU will be sent per round-trip
+ interval. (Another way of saying this is that we would hope that
+ only one datagram in a transport protocol window worth of data has
+ the Probe MTU option set). This mechanism might be implemented by
+ sending every Nth packet, or, in those implementations where the
+ round-trip time estimate to the destination is cached with the
+ route, once every estimated RTT.
+
+ When a Probe MTU option is received by Probe-Receiver, the
+ receiving IP should place the value of this option in the next
+ datagram it sends back to Probe-Sender. The value is then
+ discarded. In other words, each Probe MTU option causes the Reply
+ MTU option to be placed in one return datagram.
+
+ When Probe-Sender receives the Reply MTU option, it should check
+ the value of the option against the current MINMTU estimate in the
+ routing cache. If the option value is lower, it becomes the new
+ MINMTU estimate. If the option value is higher, Probe-Sender
+ should be more conservative about changing the MINMTU estimate.
+ If a route is flapping, the MINMTU may change frequently. In such
+ situations, keeping the smallest MINMTU of various routes in use
+ is preferred. As a result, a higher MINMTU estimate should only
+ be accepted after a lower estimate has been permitted to "age" a
+ bit. In other words, if the probe value is higher than the
+ estimated MINMTU, only update the estimate if the estimate is
+ several seconds old or more. Finally, whenever the Probe-Sender
+ receives a Reply MTU option, it should stop retransmitting probes
+ to Probe-Receiver.
+
+ A few additional issues complicate this discussion.
+
+ One problem is setting the default MINMTU when no Reply MTU
+ options have been received. We recommend the use of the minimum
+ of the supported IP datagram size (576 octets) and the connected
+ network MTU for destinations not on the local connected network,
+ and the connected network MTU for hosts on the connected network.
+
+ The MINMTU information, while kept by the Internet layer, is in
+ fact, only of interest to the transport and higher layers.
+ Accordingly, the Internet layer must keep the transport layer
+ informed of the current value of the estimated MINMTU.
+ Furthermore, minimal transport protocols, such as UDP, must be
+ prepared to pass this information up to the transport protocol
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 5]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ user.
+
+ It is expected that there will be a transition period during which
+ some hosts support this option and some do not. As a result,
+ hosts should stop sending Probe MTU options and refuse to send any
+ further options if it does not receive either a Probe MTU option
+ or Reply MTU option from the remote system after a certain number
+ of Probe MTU options have been sent. In short, if Probe-Sender
+ has sent several probes but has gotten no indication that Probe-
+ Receiver supports MTU probing, then Probe-Sender should assume
+ that Probe-Receiver does not support probes. (Obviously, if
+ Probe-Sender later receives a probe option from Probe-Receiver, it
+ should revise its opinion.)
+
+ Implementations should not assume that routes to the same
+ destination that have a different TOS have the same estimated
+ MINMTU. We recommend that the MTU be probed separately for each
+ TOS.
+
+ Respecting the TCP MSS
+
+ One issue concerning TCP MSS is that it is usually negotiated
+ assuming an IP header that contains no options. If the transport
+ layer is sending maximum size segments, it may not leave space for
+ IP to fit the options into the datagram. Thus, insertion of the
+ Probe MTU or Reply MTU option may violate the MSS restriction.
+ Because, unlike other IP options, the MTU options can be inserted
+ without the knowledge of the transport layer, the implementor must
+ carefully consider the implications of adding options to an IP
+ datagram.
+
+ One approach is to reserve 4 bytes from the MINMTU reported to the
+ transport layer; this will allow the IP layer to insert at least
+ one MTU option in every datagram (it can compare the size of the
+ outgoing datagram with the MINMTU stored in the route cache to see
+ how much room there actually is). This is simple to implement,
+ but does waste a little bandwidth in the normal case.
+
+ Another approach is to provide a means for the IP layer to notify
+ the transport layer that space must be reserved for sending an
+ option; the transport layer would then make a forthcoming segment
+ somewhat smaller than usual.
+
+ When a Probe Can Be Sent
+
+ A system that receives a Probe MTU option should always respond
+ with a Reply MTU option, unless the probe was sent to an IP or LAN
+ broadcast address.
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 6]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ A Probe MTU option should be sent in any of the following
+ situations:
+
+ (1) The MINMTU for the path is not yet known;
+
+ (2) A received datagram suffers a fragmentation re-assembly
+ timeout. (This is a strong hint the path has changed;
+ send a probe to the datagram's source);
+
+ (3) An ICMP Time Exceeded/Fragmentation Reassembly Timeout is
+ received (this is the only message we will get that
+ indicates fragmentation occurred along the network path);
+
+ (4) The transport layer requests it.
+
+ Implementations may also wish to periodically probe a path, even
+ if there is no indication that fragmentation is occurring. This
+ practice is perfectly reasonable; if fragmentation and reassembly
+ is working perfectly, the sender may never get any indication that
+ the path MINMTU has changed unless a probe is sent. We recommend,
+ however, that implementations send such periodic probes sparingly.
+ Once every few minutes, or once every few hundred datagrams is
+ probably sufficient.
+
+ There are also some scenarios in which the Probe MTU should not be
+ sent, even though there may be some indication of an MINMTU
+ change:
+
+ (1) Probes should not be sent in response to the receipt of
+ a probe option. Although the fact that the remote peer
+ is probing indicates that the MINMTU may have changed,
+ sending a probe in response to a probe causes a continuous
+ exchange of probe options.
+
+ (2) Probes must not be sent in response to fragmented
+ datagrams except when the fragmentation reassembly
+ of the datagram fails. The problem in this case is
+ that the receiver has no mechanism for informing the remote
+ peer that fragmentation has occurred, unless fragmentation
+ reassembly fails (in which case an ICMP message is sent).
+ Thus, a peer may use the wrong MTU for some time before
+ discovering a problem. If we probe on fragmented
+ datagrams, we may probe, unnecessarily, for some time
+ until the remote peer corrects its MTU.
+
+ (3) For compatibility with hosts that do not implement the
+ option, no Probe MTU Option should be sent more than
+ ten times without receiving a Reply MTU Option or a
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 7]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ Probe MTU Option from the remote peer. Peers which
+ ignore probes and do not send probes must be treated
+ as not supporting probes.
+
+ (4) Probes should not be sent to an IP or LAN broadcast
+ address.
+
+ (5) We recommend that Probe MTUs not be sent to other hosts
+ on the directly-connected network, but that this feature
+ be configurable. There are situations (for example, when
+ Proxy ARP is in use) where it may be difficult to determine
+ which systems are on the directly-connected network. In
+ this case, probing may make sense.
+
+SAMPLE IMPLEMENTATION SKETCH
+
+ We present here a somewhat more concrete description of how an IP-
+ layer implementation of MTU probing might be designed.
+
+ First, the routing cache entries are enhanced to store seven
+ additional values:
+
+ MINMTU: The current MINMTU of the path.
+
+ ProbeRetry: A timestamp indicating when the next probe
+ should be sent.
+
+ LastDecreased: A timestamp showing when the MTU was
+ last decreased.
+
+ ProbeReply: A bit indicating a Reply MTU option should be
+ sent.
+
+ ReplyMTU: The value to go in the Reply MTU option.
+
+ SupportsProbes: A bit indicating that the remote peer
+ can deal with probes (always defaults to
+ 1=true).
+
+ ConsecutiveProbes: The number of probes sent without
+ the receipt of a Probe MTU or Reply
+ MTU option.
+
+ There are also several configuration parameters; these should be
+ configurable by appropriate network management software; the values
+ we suggest are "reasonable":
+
+ Default_MINMTU: The default value for the MINMTU field of the
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 8]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ routing cache entry, to be used when the real
+ MINMTU is unknown. Recommended value: 576.
+
+ Max_ConsecutiveProbs: The maximum number of probes to send
+ before assuming that the destination does
+ not support the probe option.
+ Recommended value: 10.
+
+ ProbeRetryTime: The time (in seconds) to wait before retrying
+ an unanswered probe. Recommended value:
+ 60 seconds, or 2*RTT if the the RTT is available
+ to the IP layer.
+
+ ReprobeInterval: The time to wait before sending a probe after
+ receiving a successful Reply MTU, in order to
+ detect increases in the route's MINMTU.
+ Recommended value: 5 times the ProbeRetryTime.
+
+ IncreaseInterval: The time to wait before increasing the MINMTU
+ after the value has been decreased, to prevent
+ flapping. Recommended value: same as
+ ProbeRetryTime.
+
+ When a new route is entered into the routing cache, the initial
+ values should be set as follows:
+
+ MINMTU = Default_MINMTU
+
+ ProbeRetry = Current Time
+
+ LastDecreased = Current Time - IncreaseInterval
+
+ ProbeReply = false
+
+ SupportsProbes = true
+
+ ConsecutiveProbes = 0
+
+ This initialization is done before attempting to send the first
+ packet along this route, so that the first packet will contain a
+ Probe MTU option.
+
+ Whenever the IP layer sends a datagram on this route it checks the
+ SupportsProbes bit to see if the remote system supports probing. If
+ the SupportsProbes bit is set, and the timestamp in ProbeRetry is
+ less than or equal to the current time, a Probe option should be sent
+ in the datagram, and the ProbeRetry field incremented by
+ ProbeRetryTime.
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 9]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ Whether or not the Probe MTU option is sent in a datagram, if the
+ ProbeReply bit is set, then a Reply MTU option with the value of the
+ ReplyMTU field is placed in the outbound datagram. The ProbeReply
+ bit is then cleared.
+
+ Every time a Probe option is sent, the ConsecutiveProbes value should
+ be incremented. If this value reaches Max_ConsecutiveProbes, the
+ SupportsProbe bit should be cleared.
+
+ When an IP datagram containing the Probe MTU option is received, the
+ receiving IP sets the ReplyMTU to the Probe MTU option value and sets
+ the ProbeReply bit in its outbound route to the source of the
+ datagram. The SupportsProbe bit is set, and the ConsecutiveProbes
+ value is reset to 0.
+
+ If an IP datagram containing the Reply MTU option is received, the IP
+ layer must locate the routing cache entry corresponding to the source
+ of the Reply MTU option; if no such entry exists, a new one (with
+ default values) should be created. The SupportsProbe bit is set, and
+ the ConsecutiveProbes value is reset to 0. The ProbeRetry field is
+ set to the current time plus ReprobeInterval.
+
+ Four cases are possible when a Reply MTU option is received:
+
+ (1) The Reply MTU option value is less than the current
+ MINMTU: the MINMTU field is set to the new value, and
+ the LastDecreased field is set to the current time.
+
+ (2) The Reply MTU option value is greater than the
+ current MINMTU and the LastDecreased field plus
+ IncreaseInterval is less than the current time: set the
+ ProbeRetry field to LastDecreased plus IncreaseInterval,
+ but do not change MINMTU.
+
+ (3) The Reply MTU option value is greater than the
+ current MINMTU and the LastDecreased field plus
+ IncreaseInterval is greater than the current time: set
+ the MINMTU field to the new value.
+
+ (4) The Reply MTU option value is equal to the current
+ MINMTU: do nothing more.
+
+ Whenever the MTU field is changed, the transport layer should be
+ notified, either by an upcall or by a change in a shared variable
+ (which may be accessed from the transport layer by a downcall).
+
+ If a fragmentation reassembly timeout occurs, if an ICMP Time
+ Exceeded/Fragmentation Reassembly Timeout is received, or if the IP
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 10]
+
+RFC 1063 IP MTU Discovery Options July 1988
+
+
+ layer is asked to send a probe by a higher layer, the ProbeRetry
+ field for the appropriate routing cache entry is set to the current
+ time. This will cause a Probe option to be sent with the next
+ datagram (unless the SupportsProbe bit is turned off).
+
+MANAGEMENT PARAMETERS
+
+ We suggest that the following parameters be made available to local
+ applications and remote network management systems:
+
+ (1) The number of probe retries to be made before determining
+ a system is down. The value of 10 is certain to be wrong
+ in some situations.
+
+ (2) The frequency with which probes are sent. Systems may
+ find that more or less frequent probing is more cost
+ effective.
+
+ (3) The default MINMTU used to initialize routes.
+
+ (4) Applications should have the ability to force a probe
+ on a particular route. There are cases where a probe
+ needs to be sent but the sender doesn't know it. An
+ operator must be able to cause a probe in such situations.
+ Furthermore, it may be useful for applications to "ping"
+ for the MTU.
+
+REFERENCES
+
+ [1] Kent, C. and J. Mogul, "Fragmentation Considered
+ Harmful", Proc. ACM SIGCOMM '87, Stowe, VT, August 1987.
+
+ [2] Postel, J., Ed., "Internet Protocol", RFC-791,
+ USC/Information Sciences Institute, Marina del Rey, CA,
+ September 1981.
+
+ [3] Postel, J., Ed., "Transmission Control Protocol", RFC-793,
+ USC/Information Sciences Institute, Marina del Rey, CA,
+ September 1981.
+
+ [4] Postel, J., "The TCP Maximum Segment Size and Related Topics",
+ RFC-879, USC/Information Sciences Institute, Marina del Rey,
+ CA, November 1983.
+
+
+
+
+
+
+
+
+Mogul, Kent, Partridge, & McCloghrie [Page 11]
+
893 RFCs/rfc1072.txt
@@ -0,0 +1,893 @@
+Network Working Group V. Jacobson
+Request for Comments: 1072 LBL
+ R. Braden
+ ISI
+ October 1988
+
+
+ TCP Extensions for Long-Delay Paths
+
+
+Status of This Memo
+
+ This memo proposes a set of extensions to the TCP protocol to provide
+ efficient operation over a path with a high bandwidth*delay product.
+ These extensions are not proposed as an Internet standard at this
+ time. Instead, they are intended as a basis for further
+ experimentation and research on transport protocol performance.
+ Distribution of this memo is unlimited.
+
+1. INTRODUCTION
+
+ Recent work on TCP performance has shown that TCP can work well over
+ a variety of Internet paths, ranging from 800 Mbit/sec I/O channels
+ to 300 bit/sec dial-up modems [Jacobson88]. However, there is still
+ a fundamental TCP performance bottleneck for one transmission regime:
+ paths with high bandwidth and long round-trip delays. The
+ significant parameter is the product of bandwidth (bits per second)
+ and round-trip delay (RTT in seconds); this product is the number of
+ bits it takes to "fill the pipe", i.e., the amount of unacknowledged
+ data that TCP must handle in order to keep the pipeline full. TCP
+ performance problems arise when this product is large, e.g.,
+ significantly exceeds 10**5 bits. We will refer to an Internet path
+ operating in this region as a "long, fat pipe", and a network
+ containing this path as an "LFN" (pronounced "elephan(t)").
+
+ High-capacity packet satellite channels (e.g., DARPA's Wideband Net)
+ are LFN's. For example, a T1-speed satellite channel has a
+ bandwidth*delay product of 10**6 bits or more; this corresponds to
+ 100 outstanding TCP segments of 1200 bytes each! Proposed future
+ terrestrial fiber-optical paths will also fall into the LFN class;
+ for example, a cross-country delay of 30 ms at a DS3 bandwidth
+ (45Mbps) also exceeds 10**6 bits.
+
+ Clever algorithms alone will not give us good TCP performance over
+ LFN's; it will be necessary to actually extend the protocol. This
+ RFC proposes a set of TCP extensions for this purpose.
+
+ There are three fundamental problems with the current TCP over LFN
+
+
+
+Jacobson & Braden [Page 1]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ paths:
+
+
+ (1) Window Size Limitation
+
+ The TCP header uses a 16 bit field to report the receive window
+ size to the sender. Therefore, the largest window that can be
+ used is 2**16 = 65K bytes. (In practice, some TCP
+ implementations will "break" for windows exceeding 2**15,
+ because of their failure to do unsigned arithmetic).
+
+ To circumvent this problem, we propose a new TCP option to allow
+ windows larger than 2**16. This option will define an implicit
+ scale factor, to be used to multiply the window size value found
+ in a TCP header to obtain the true window size.
+
+
+ (2) Cumulative Acknowledgments
+
+ Any packet losses in an LFN can have a catastrophic effect on
+ throughput. This effect is exaggerated by the simple cumulative
+ acknowledgment of TCP. Whenever a segment is lost, the
+ transmitting TCP will (eventually) time out and retransmit the
+ missing segment. However, the sending TCP has no information
+ about segments that may have reached the receiver and been
+ queued because they were not at the left window edge, so it may
+ be forced to retransmit these segments unnecessarily.
+
+ We propose a TCP extension to implement selective
+ acknowledgements. By sending selective acknowledgments, the
+ receiver of data can inform the sender about all segments that
+ have arrived successfully, so the sender need retransmit only
+ the segments that have actually been lost.
+
+ Selective acknowledgments have been included in a number of
+ experimental Internet protocols -- VMTP [Cheriton88], NETBLT
+ [Clark87], and RDP [Velten84]. There is some empirical evidence
+ in favor of selective acknowledgments -- simple experiments with
+ RDP have shown that disabling the selective acknowlegment
+ facility greatly increases the number of retransmitted segments
+ over a lossy, high-delay Internet path [Partridge87]. A
+ simulation study of a simple form of selective acknowledgments
+ added to the ISO transport protocol TP4 also showed promise of
+ performance improvement [NBS85].
+
+
+
+
+
+
+
+Jacobson & Braden [Page 2]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ (3) Round Trip Timing
+
+ TCP implements reliable data delivery by measuring the RTT,
+ i.e., the time interval between sending a segment and receiving
+ an acknowledgment for it, and retransmitting any segments that
+ are not acknowledged within some small multiple of the average
+ RTT. Experience has shown that accurate, current RTT estimates
+ are necessary to adapt to changing traffic conditions and,
+ without them, a busy network is subject to an instability known
+ as "congestion collapse" [Nagle84].
+
+ In part because TCP segments may be repacketized upon
+ retransmission, and in part because of complications due to the
+ cumulative TCP acknowledgement, measuring a segments's RTT may
+ involve a non-trivial amount of computation in some
+ implementations. To minimize this computation, some
+ implementations time only one segment per window. While this
+ yields an adequate approximation to the RTT for small windows
+ (e.g., a 4 to 8 segment Arpanet window), for an LFN (e.g., 100
+ segment Wideband Network windows) it results in an unacceptably
+ poor RTT estimate.
+
+ In the presence of errors, the problem becomes worse. Zhang
+ [Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is
+ not possible to accumulate reliable RTT estimates if
+ retransmitted segments are included in the estimate. Since a
+ full window of data will have been transmitted prior to a
+ retransmission, all of the segments in that window will have to
+ be ACKed before the next RTT sample can be taken. This means at
+ least an additional window's worth of time between RTT
+ measurements and, as the error rate approaches one per window of
+ data (e.g., 10**-6 errors per bit for the Wideband Net), it
+ becomes effectively impossible to obtain an RTT measurement.
+
+ We propose a TCP "echo" option that allows each segment to carry
+ its own timestamp. This will allow every segment, including
+ retransmissions, to be timed at negligible computational cost.
+
+
+ In designing new TCP options, we must pay careful attention to
+ interoperability with existing implementations. The only TCP option
+ defined to date is an "initial option", i.e., it may appear only on a
+ SYN segment. It is likely that most implementations will properly
+ ignore any options in the SYN segment that they do not understand, so
+ new initial options should not cause a problem. On the other hand,
+ we fear that receiving unexpected non-initial options may cause some
+ TCP's to crash.
+
+
+
+
+Jacobson & Braden [Page 3]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ Therefore, in each of the extensions we propose, non-initial options
+ may be sent only if an exchange of initial options has indicated that
+ both sides understand the extension. This approach will also allow a
+ TCP to determine when the connection opens how big a TCP header it
+ will be sending.
+
+2. TCP WINDOW SCALE OPTION
+
+ The obvious way to implement a window scale factor would be to define
+ a new TCP option that could be included in any segment specifying a
+ window. The receiver would include it in every acknowledgment
+ segment, and the sender would interpret it. Unfortunately, this
+ simple approach would not work. The sender must reliably know the
+ receiver's current scale factor, but a TCP option in an
+ acknowledgement segment will not be delivered reliably (unless the
+ ACK happens to be piggy-backed on data).
+
+ However, SYN segments are always sent reliably, suggesting that each
+ side may communicate its window scale factor in an initial TCP
+ option. This approach has a disadvantage: the scale must be
+ established when the connection is opened, and cannot be changed
+ thereafter. However, other alternatives would be much more
+ complicated, and we therefore propose a new initial option called
+ Window Scale.
+
+2.1 Window Scale Option
+
+ This three-byte option may be sent in a SYN segment by a TCP (1)
+ to indicate that it is prepared to do both send and receive window
+ scaling, and (2) to communicate a scale factor to be applied to
+ its receive window. The scale factor is encoded logarithmically,
+ as a power of 2 (presumably to be implemented by binary shifts).
+
+ Note: the window in the SYN segment itself is never scaled.
+
+ TCP Window Scale Option:
+
+ Kind: 3
+
+ +---------+---------+---------+
+ | Kind=3 |Length=3 |shift.cnt|
+ +---------+---------+---------+
+
+ Here shift.cnt is the number of bits by which the receiver right-
+ shifts the true receive-window value, to scale it into a 16-bit
+ value to be sent in TCP header (this scaling is explained below).
+ The value shift.cnt may be zero (offering to scale, while applying
+ a scale factor of 1 to the receive window).
+
+
+
+Jacobson & Braden [Page 4]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ This option is an offer, not a promise; both sides must send
+ Window Scale options in their SYN segments to enable window
+ scaling in either direction.
+
+2.2 Using the Window Scale Option
+
+ A model implementation of window scaling is as follows, using the
+ notation of RFC-793 [Postel81]:
+
+ * The send-window (SND.WND) and receive-window (RCV.WND) sizes
+ in the connection state block and in all sequence space
+ calculations are expanded from 16 to 32 bits.
+
+ * Two window shift counts are added to the connection state:
+ snd.scale and rcv.scale. These are shift counts to be
+ applied to the incoming and outgoing windows, respectively.
+ The precise algorithm is shown below.
+
+ * All outgoing SYN segments are sent with the Window Scale
+ option, containing a value shift.cnt = R that the TCP would
+ like to use for its receive window.
+
+ * Snd.scale and rcv.scale are initialized to zero, and are
+ changed only during processing of a received SYN segment. If
+ the SYN segment contains a Window Scale option with shift.cnt
+ = S, set snd.scale to S and set rcv.scale to R; otherwise,
+ both snd.scale and rcv.scale are left at zero.
+
+ * The window field (SEG.WND) in the header of every incoming
+ segment, with the exception of SYN segments, will be left-
+ shifted by snd.scale bits before updating SND.WND:
+
+ SND.WND = SEG.WND << snd.scale
+
+ (assuming the other conditions of RFC793 are met, and using
+ the "C" notation "<<" for left-shift).
+
+ * The window field (SEG.WND) of every outgoing segment, with
+ the exception of SYN segments, will have been right-shifted
+ by rcv.scale bits:
+
+ SEG.WND = RCV.WND >> rcv.scale.
+
+
+ TCP determines if a data segment is "old" or "new" by testing if
+ its sequence number is within 2**31 bytes of the left edge of the
+ window. If not, the data is "old" and discarded. To insure that
+ new data is never mistakenly considered old and vice-versa, the
+
+
+
+Jacobson & Braden [Page 5]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ left edge of the sender's window has to be at least 2**31 away
+ from the right edge of the receiver's window. Similarly with the
+ sender's right edge and receiver's left edge. Since the right and
+ left edges of either the sender's or receiver's window differ by
+ the window size, and since the sender and receiver windows can be
+ out of phase by at most the window size, the above constraints
+ imply that 2 * the max window size must be less than 2**31, or
+
+ max window < 2**30
+
+ Since the max window is 2**S (where S is the scaling shift count)
+ times at most 2**16 - 1 (the maximum unscaled window), the maximum
+ window is guaranteed to be < 2*30 if S <= 14. Thus, the shift
+ count must be limited to 14. (This allows windows of 2**30 = 1
+ Gbyte.) If a Window Scale option is received with a shift.cnt
+ value exceeding 14, the TCP should log the error but use 14
+ instead of the specified value.
+
+
+3. TCP SELECTIVE ACKNOWLEDGMENT OPTIONS
+
+ To minimize the impact on the TCP protocol, the selective
+ acknowledgment extension uses the form of two new TCP options. The
+ first is an enabling option, "SACK-permitted", that may be sent in a
+ SYN segment to indicate that the the SACK option may be used once the
+ connection is established. The other is the SACK option itself,
+ which may be sent over an established connection once permission has
+ been given by SACK-permitted.
+
+ The SACK option is to be included in a segment sent from a TCP that
+ is receiving data to the TCP that is sending that data; we will refer
+ to these TCP's as the data receiver and the data sender,
+ respectively. We will consider a particular simplex data flow; any
+ data flowing in the reverse direction over the same connection can be
+ treated independently.
+
+3.1 SACK-Permitted Option
+
+ This two-byte option may be sent in a SYN by a TCP that has been
+ extended to receive (and presumably process) the SACK option once
+ the connection has opened.
+
+
+
+
+
+
+
+
+
+
+Jacobson & Braden [Page 6]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ TCP Sack-Permitted Option:
+
+ Kind: 4
+
+ +---------+---------+
+ | Kind=4 | Length=2|
+ +---------+---------+
+
+3.2 SACK Option
+
+ The SACK option is to be used to convey extended acknowledgment
+ information over an established connection. Specifically, it is
+ to be sent by a data receiver to inform the data transmitter of
+ non-contiguous blocks of data that have been received and queued.
+ The data receiver is awaiting the receipt of data in later
+ retransmissions to fill the gaps in sequence space between these
+ blocks. At that time, the data receiver will acknowledge the data
+ normally by advancing the left window edge in the Acknowledgment
+ Number field of the TCP header.
+
+ It is important to understand that the SACK option will not change
+ the meaning of the Acknowledgment Number field, whose value will
+ still specify the left window edge, i.e., one byte beyond the last
+ sequence number of fully-received data. The SACK option is
+ advisory; if it is ignored, TCP acknowledgments will continue to
+ function as specified in the protocol.
+
+ However, SACK will provide additional information that the data
+ transmitter can use to optimize retransmissions. The TCP data
+ receiver may include the SACK option in an acknowledgment segment
+ whenever it has data that is queued and unacknowledged. Of
+ course, the SACK option may be sent only when the TCP has received
+ the SACK-permitted option in the SYN segment for that connection.
+
+ TCP SACK Option:
+
+ Kind: 5
+
+ Length: Variable
+
+
+ +--------+--------+--------+--------+--------+--------+...---+
+ | Kind=5 | Length | Relative Origin | Block Size | |
+ +--------+--------+--------+--------+--------+--------+...---+
+
+
+ This option contains a list of the blocks of contiguous sequence
+ space occupied by data that has been received and queued within
+
+
+
+Jacobson & Braden [Page 7]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ the window. Each block is contiguous and isolated; that is, the
+ octets just below the block,
+
+ Acknowledgment Number + Relative Origin -1,
+
+ and just above the block,
+
+ Acknowledgment Number + Relative Origin + Block Size,
+
+ have not been received.
+
+ Each contiguous block of data queued at the receiver is defined in
+ the SACK option by two 16-bit integers:
+
+
+ * Relative Origin
+
+ This is the first sequence number of this block, relative to
+ the Acknowledgment Number field in the TCP header (i.e.,
+ relative to the data receiver's left window edge).
+
+
+ * Block Size
+
+ This is the size in octets of this block of contiguous data.
+
+
+ A SACK option that specifies n blocks will have a length of 4*n+2
+ octets, so the 44 bytes available for TCP options can specify a
+ maximum of 10 blocks. Of course, if other TCP options are
+ introduced, they will compete for the 44 bytes, and the limit of
+ 10 may be reduced in particular segments.
+
+ There is no requirement on the order in which blocks can appear in
+ a single SACK option.
+
+ Note: requiring that the blocks be ordered would allow a
+ slightly more efficient algorithm in the transmitter; however,
+ this does not seem to be an important optimization.
+
+3.3 SACK with Window Scaling
+
+ If window scaling is in effect, then 16 bits may not be sufficient
+ for the SACK option fields that define the origin and length of a
+ block. There are two possible ways to handle this:
+
+ (1) Expand the SACK origin and length fields to 24 or 32 bits.
+
+
+
+
+Jacobson & Braden [Page 8]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ (2) Scale the SACK fields by the same factor as the window.
+
+
+ The first alternative would significantly reduce the number of
+ blocks possible in a SACK option; therefore, we have chosen the
+ second alternative, scaling the SACK information as well as the
+ window.
+
+ Scaling the SACK information introduces some loss of precision,
+ since a SACK option must report queued data blocks whose origins
+ and lengths are multiples of the window scale factor rcv.scale.
+ These reported blocks must be equal to or smaller than the actual
+ blocks of queued data.
+
+ Specifically, suppose that the receiver has a contiguous block of
+ queued data that occupies sequence numbers L, L+1, ... L+N-1, and
+ that the window scale factor is S = rcv.scale. Then the
+ corresponding block that will be reported in a SACK option will
+ be:
+
+ Relative Origin = int((L+S-1)/S)
+
+ Block Size = int((L+N)/S) - (Relative Origin)
+
+ where the function int(x) returns the greatest integer contained
+ in x.
+
+ The resulting loss of precision is not a serious problem for the
+ sender. If the data-sending TCP keeps track of the boundaries of
+ all segments in its retransmission queue, it will generally be
+ able to infer from the imprecise SACK data which full segments
+ don't need to be retransmitted. This will fail only if S is
+ larger than the maximum segment size, in which case some segments
+ may be retransmitted unnecessarily. If the sending TCP does not
+ keep track of transmitted segment boundaries, the imprecision of
+ the scaled SACK quantities will only result in retransmitting a
+ small amount of unneeded sequence space. On the average, the data
+ sender will unnecessarily retransmit J*S bytes of the sequence
+ space for each SACK received; here J is the number of blocks
+ reported in the SACK, and S = snd.scale.
+
+3.4 SACK Option Examples
+
+ Assume the left window edge is 5000 and that the data transmitter
+ sends a burst of 8 segments, each containing 500 data bytes.
+ Unless specified otherwise, we assume that the scale factor S = 1.
+
+
+
+
+
+Jacobson & Braden [Page 9]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ Case 1: The first 4 segments are received but the last 4 are
+ dropped.
+
+ The data receiver will return a normal TCP ACK segment
+ acknowledging sequence number 7000, with no SACK option.
+
+
+ Case 2: The first segment is dropped but the remaining 7 are
+ received.
+
+ The data receiver will return a TCP ACK segment that
+ acknowledges sequence number 5000 and contains a SACK option
+ specifying one block of queued data:
+
+ Relative Origin = 500; Block Size = 3500
+
+
+ Case 3: The 2nd, 4th, 6th, and 8th (last) segments are
+ dropped.
+
+ The data receiver will return a TCP ACK segment that
+ acknowledges sequence number 5500 and contains a SACK option
+ specifying the 3 blocks:
+
+ Relative Origin = 500; Block Size = 500
+ Relative Origin = 1500; Block Size = 500
+ Relative Origin = 2500; Block Size = 500
+
+
+ Case 4: Same as Case 3, except Scale Factor S = 16.
+
+ The SACK option would specify the 3 scaled blocks:
+
+ Relative Origin = 32; Block Size = 30
+ Relative Origin = 94; Block Size = 31
+ Relative Origin = 157; Block Size = 30
+
+ These three reported blocks have sequence numbers 512 through
+ 991, 1504 through 1999, and 2512 through 2992, respectively.
+
+
+3.5 Generating the SACK Option
+
+ Let us assume that the data receiver maintains a queue of valid
+ segments that it has neither passed to the user nor acknowledged
+ because of earlier missing data, and that this queue is ordered by
+ starting sequence number. Computation of the SACK option can be
+ done with one pass down this queue. Segments that occupy
+
+
+
+Jacobson & Braden [Page 10]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ contiguous sequence space are aggregated into a single SACK block,
+ and each gap in the sequence space (except a gap that is
+ terminated by the right window edge) triggers the start of a new
+ SACK block. If this algorithm defines more than 10 blocks, only
+ the first 10 can be included in the option.
+
+3.6 Interpreting the SACK Option
+
+ The data transmitter is assumed to have a retransmission queue
+ that contains the segments that have been transmitted but not yet
+ acknowledged, in sequence-number order. If the data transmitter
+ performs re-packetization before retransmission, the block
+ boundaries in a SACK option that it receives may not fall on
+ boundaries of segments in the retransmission queue; however, this
+ does not pose a serious difficulty for the transmitter.
+
+ Let us suppose that for each segment in the retransmission queue
+ there is a (new) flag bit "ACK'd", to be used to indicate that
+ this particular segment has been entirely acknowledged. When a
+ segment is first transmitted, it will be entered into the
+ retransmission queue with its ACK'd bit off. If the ACK'd bit is
+ subsequently turned on (as the result of processing a received
+ SACK option), the data transmitter will skip this segment during
+ any later retransmission. However, the segment will not be
+ dequeued and its buffer freed until the left window edge is
+ advanced over it.
+
+ When an acknowledgment segment arrives containing a SACK option,
+ the data transmitter will turn on the ACK'd bits for segments that
+ have been selectively acknowleged. More specifically, for each
+ block in the SACK option, the data transmitter will turn on the
+ ACK'd flags for all segments in the retransmission queue that are
+ wholly contained within that block. This requires straightforward
+ sequence number comparisons.
+
+
+4. TCP ECHO OPTIONS
+
+ A simple method for measuring the RTT of a segment would be: the
+ sender places a timestamp in the segment and the receiver returns
+ that timestamp in the corresponding ACK segment. When the ACK segment
+ arrives at the sender, the difference between the current time and
+ the timestamp is the RTT. To implement this timing method, the
+ receiver must simply reflect or echo selected data (the timestamp)
+ from the sender's segments. This idea is the basis of the "TCP Echo"
+ and "TCP Echo Reply" options.
+
+
+
+
+
+Jacobson & Braden [Page 11]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+4.1 TCP Echo and TCP Echo Reply Options
+
+ TCP Echo Option:
+
+ Kind: 6
+
+ Length: 6
+
+ +--------+--------+--------+--------+--------+--------+
+ | Kind=6 | Length | 4 bytes of info to be echoed |
+ +--------+--------+--------+--------+--------+--------+
+
+ This option carries four bytes of information that the receiving TCP
+ may send back in a subsequent TCP Echo Reply option (see below). A
+ TCP may send the TCP Echo option in any segment, but only if a TCP
+ Echo option was received in a SYN segment for the connection.
+
+ When the TCP echo option is used for RTT measurement, it will be
+ included in data segments, and the four information bytes will define
+ the time at which the data segment was transmitted in any format
+ convenient to the sender.
+
+ TCP Echo Reply Option:
+
+ Kind: 7
+
+ Length: 6
+
+ +--------+--------+--------+--------+--------+--------+
+ | Kind=7 | Length | 4 bytes of echoed info |
+ +--------+--------+--------+--------+--------+--------+
+
+
+ A TCP that receives a TCP Echo option containing four information
+ bytes will return these same bytes in a TCP Echo Reply option.
+
+ This TCP Echo Reply option must be returned in the next segment
+ (e.g., an ACK segment) that is sent. If more than one Echo option is
+ received before a reply segment is sent, the TCP must choose only one
+ of the options to echo, ignoring the others; specifically, it must
+ choose the newest segment with the oldest sequence number (see next
+ section.)
+
+ To use the TCP Echo and Echo Reply options, a TCP must send a TCP
+ Echo option in its own SYN segment and receive a TCP Echo option in a
+ SYN segment from the other TCP. A TCP that does not implement the
+ TCP Echo or Echo Reply options must simply ignore any TCP Echo
+ options it receives. However, a TCP should not receive one of these
+
+
+
+Jacobson & Braden [Page 12]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ options in a non-SYN segment unless it included a TCP Echo option in
+ its own SYN segment.
+
+4.2 Using the Echo Options
+
+ If we wish to use the Echo/Echo Reply options for RTT measurement, we
+ have to define what the receiver does when there is not a one-to-one
+ correspondence between data and ACK segments. Assuming that we want
+ to minimize the state kept in the receiver (i.e., the number of
+ unprocessed Echo options), we can plan on a receiver remembering the
+ information value from at most one Echo between ACKs. There are
+ three situations to consider:
+
+ (A) Delayed ACKs.
+
+ Many TCP's acknowledge only every Kth segment out of a group of
+ segments arriving within a short time interval; this policy is
+ known generally as "delayed ACK's". The data-sender TCP must
+ measure the effective RTT, including the additional time due to
+ delayed ACK's, or else it will retransmit unnecessarily. Thus,
+ when delayed ACK's are in use, the receiver should reply with
+ the Echo option information from the earliest unacknowledged
+ segment.
+
+ (B) A hole in the sequence space (segment(s) have been lost).
+
+ The sender will continue sending until the window is filled, and
+ we may be generating ACKs as these out-of-order segments arrive
+ (e.g., for the SACK information or to aid "fast retransmit").
+ An Echo Reply option will tell the sender the RTT of some
+ recently sent segment (since the ACK can only contain the
+ sequence number of the hole, the sender may not be able to
+ determine which segment, but that doesn't matter). If the loss
+ was due to congestion, these RTTs may be particularly valuable
+ to the sender since they reflect the network characteristics
+ immediately after the congestion.
+
+ (C) A filled hole in the sequence space.
+
+ The segment that fills the hole represents the most recent
+ measurement of the network characteristics. On the other hand,
+ an RTT computed from an earlier segment would probably include
+ the sender's retransmit time-out, badly biasing the sender's
+ average RTT estimate.
+
+
+ Case (A) suggests the receiver should remember and return the Echo
+ option information from the oldest unacknowledged segment. Cases (B)
+
+
+
+Jacobson & Braden [Page 13]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ and (C) suggest that the option should come from the most recent
+ unacknowledged segment. An algorithm that covers all three cases is
+ for the receiver to return the Echo option information from the
+ newest segment with the oldest sequence number, as specified earlier.
+
+ A model implementation of these options is as follows.
+
+
+ (1) Receiver Implementation
+
+ A 32-bit slot for Echo option data, rcv.echodata, is added to
+ the receiver connection state, together with a flag,
+ rcv.echopresent, that indicates whether there is anything in the
+ slot. When the receiver generates a segment, it checks
+ rcv.echopresent and, if it is set, adds an echo-reply option
+ containing rcv.echodata to the outgoing segment then clears
+ rcv.echopresent.
+
+ If an incoming segment is in the window and contains an echo
+ option, the receiver checks rcv.echopresent. If it isn't set,
+ the value of the echo option is copied to rcv.echodata and
+ rcv.echopresent is set. If rcv.echopresent is already set, the
+ receiver checks whether the segment is at the left edge of the
+ window. If so, the segment's echo option value is copied to
+ rcv.echodata (this is situation (C) above). Otherwise, the
+ segment's echo option is ignored.
+
+
+ (2) Sender Implementation
+
+ The sender's connection state has a single flag bit,
+ snd.echoallowed, added. If snd.echoallowed is set or if the
+ segment contains a SYN, the sender is free to add a TCP Echo
+ option (presumably containing the current time in some units
+ convenient to the sender) to every outgoing segment.
+
+ Snd.echoallowed should be set if a SYN is received with a TCP
+ Echo option (presumably, a host that implements the option will
+ attempt to use it to time the SYN segment).
+
+
+5. CONCLUSIONS AND ACKNOWLEDGMENTS
+
+We have proposed five new TCP options for scaled windows, selective
+acknowledgments, and round-trip timing, in order to provide efficient
+operation over large-bandwidth*delay-product paths. These extensions
+are designed to provide compatible interworking with TCP's that do not
+implement the extensions.
+
+
+
+Jacobson & Braden [Page 14]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+The Window Scale option was originally suggested by Mike St. Johns of
+USAF/DCA. The present form of the option was suggested by Mike Karels
+of UC Berkeley in response to a more cumbersome scheme proposed by Van
+Jacobson. Gerd Beling of FGAN (West Germany) contributed the initial
+definition of the SACK option.
+
+All three options have evolved through discussion with the End-to-End
+Task Force, and the authors are grateful to the other members of the
+Task Force for their advice and encouragement.
+
+6. REFERENCES
+
+ [Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction
+ Protocol", RFC 1045, Stanford University, February 1988.
+
+ [Jain86] Jain, R., "Divergence of Timeout Algorithms for Packet
+ Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and Comm.,
+ Scottsdale, Arizona, March 1986.
+
+ [Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times
+ in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT,
+ August 1987.
+
+ [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk
+ Data Transfer Protocol", RFC 998, MIT, March 1987.
+
+ [Nagle84] Nagle, J., "Congestion Control in IP/TCP
+ Internetworks", RFC 896, FACC, January 1984.
+
+ [NBS85] Colella, R., Aronoff, R., and K. Mills, "Performance
+ Improvements for ISO Transport", Ninth Data Comm Symposium,
+ published in ACM SIGCOMM Comp Comm Review, vol. 15, no. 5,
+ September 1985.
+
+ [Partridge87] Partridge, C., "Private Communication", February
+ 1987.
+
+ [Postel81] Postel, J., "Transmission Control Protocol - DARPA
+ Internet Program Protocol Specification", RFC 793, DARPA,
+ September 1981.
+
+ [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data
+ Protocol", RFC 908, BBN, July 1984.
+
+ [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", to
+ be presented at SIGCOMM '88, Stanford, CA., August 1988.
+
+ [Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc.
+
+
+
+Jacobson & Braden [Page 15]
+
+RFC 1072 TCP Extensions for Long-Delay Paths October 1988
+
+
+ SIGCOMM '86, Stowe, Vt., August 1986.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jacobson & Braden [Page 16]
+
6,844 RFCs/rfc1122.txt
6,844 additions, 0 deletions not shown because the diff is too large. Please use a local Git client to view these changes.
2,075 RFCs/rfc1323.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Network Working Group V. Jacobson
+Request for Comments: 1323 LBL
+Obsoletes: RFC 1072, RFC 1185 R. Braden
+ ISI
+ D. Borman
+ Cray Research
+ May 1992
+
+
+ TCP Extensions for High Performance
+
+Status of This Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ This memo presents a set of TCP extensions to improve performance
+ over large bandwidth*delay product paths and to provide reliable
+ operation over very high-speed paths. It defines new TCP options for
+ scaled windows and timestamps, which are designed to provide
+ compatible interworking with TCP's that do not implement the
+ extensions. The timestamps are used for two distinct mechanisms:
+ RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
+ Sequences). Selective acknowledgments are not included in this memo.
+
+ This memo combines and supersedes RFC-1072 and RFC-1185, adding
+ additional clarification and more detailed specification. Appendix C
+ summarizes the changes from the earlier RFCs.
+
+TABLE OF CONTENTS
+
+ 1. Introduction ................................................. 2
+ 2. TCP Window Scale Option ...................................... 8
+ 3. RTTM -- Round-Trip Time Measurement .......................... 11
+ 4. PAWS -- Protect Against Wrapped Sequence Numbers ............. 17
+ 5. Conclusions and Acknowledgments .............................. 25
+ 6. References ................................................... 25
+ APPENDIX A: Implementation Suggestions ........................... 27
+ APPENDIX B: Duplicates from Earlier Connection Incarnations ...... 27
+ APPENDIX C: Changes from RFC-1072, RFC-1185 ...................... 30
+ APPENDIX D: Summary of Notation .................................. 31
+ APPENDIX E: Event Processing ..................................... 32
+ Security Considerations .......................................... 37
+
+
+
+Jacobson, Braden, & Borman [Page 1]
+
+RFC 1323 TCP Extensions for High Performance May 1992
+
+
+ Authors' Addresses ............................................... 37
+
+1. INTRODUCTION
+
+ The TCP protocol [Postel81] was designed to operate reliably over
+ almost any transmission medium regardless of transmission rate,
+ delay, corruption, duplication, or reordering of segments.
+ Production TCP implementations currently adapt to transfer rates in
+ the range of 100 bps to 10**7 bps and round-trip delays in the range
+ 1 ms to 100 seconds. Recent work on TCP performance has shown that
+ TCP can work well over a variety of Internet paths, ranging from 800
+ Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88a].
+
+ The introduction of fiber optics is resulting in ever-higher
+ transmission speeds, and the fastest paths are moving out of the
+ domain for which TCP was originally engineered. This memo defines a
+ set of modest extensions to TCP to extend the domain of its
+ application to match this increasing network capability. It is based
+ upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b].
+
+ There is no one-line answer to the question: "How fast can TCP go?".
+ There are two separate kinds of issues, performance and reliability,
+ and each depends upon different parameters. We discuss each in turn.
+
+ 1.1 TCP Performance
+
+ TCP performance depends not upon the transfer rate itself, but
+ rather upon the product of the transfer rate and the round-trip
+ delay. This "bandwidth*delay product" measures the amount of data
+ that would "fill the pipe"; it is the buffer space required at
+ sender and receiver to obtain maximum throughput on the TCP
+ connection over the path, i.e., the amount of unacknowledged data
+ that TCP must handle in order to keep the pipeline full. TCP
+ performance problems arise when the bandwidth*delay product is
+ large. We refer to an Internet path operating in this region as a
+ "long, fat pipe", and a network containing this path as an "LFN"
+ (pronounced "elephan(t)").
+
+ High-capacity packet satellite channels (e.g., DARPA's Wideband
+ Net) are LFN's. For example, a DS1-speed satellite channel has a
+ bandwidth*delay product of 10**6 bits or more; this corresponds to
+ 100 outstanding TCP segments of 1200 bytes each. Terrestrial
+ fiber-optical paths will also fall into the LFN class; for
+ example, a cross-country delay of 30 ms at a DS3 bandwidth
+ (45Mbps) also exceeds 10**6 bits.
+
+ There are three fundamental performance problems with the current
+ TCP over LFN paths:
+
+
+
+Jacobson, Braden, & Borman [Page 2]
+
+RFC 1323 TCP Extensions for High Performance May 1992
+
+
+ (1) Window Size Limit
+
+ The TCP header uses a 16 bit field to report the receive
+ window size to the sender. Therefore, the largest window
+ that can be used is 2**16 = 65K bytes.
+
+ To circumvent this problem, Section 2 of this memo defines a
+ new TCP option, "Window Scale", to allow windows larger than
+ 2**16. This option defines an implicit scale factor, which
+ is used to multiply the window size value found in a TCP
+ header to obtain the true window size.
+
+ (2) Recovery from Losses
+
+ Packet losses in an LFN can have a catastrophic effect on
+ throughput. Until recently, properly-operating TCP
+ implementations would cause the data pipeline to drain with
+ every packet loss, and require a slow-start action to
+ recover. Recently, the Fast Retransmit and Fast Recovery
+ algorithms [Jacobson90c] have been introduced. Their
+ combined effect is to recover from one packet loss per
+ window, without draining the pipeline. However, more than
+ one packet loss per window typically results in a
+ retransmission timeout and the resulting pipeline drain and
+ slow start.
+
+ Expanding the window size to match the capacity of an LFN
+ results in a corresponding increase of the probability of
+ more than one packet per window being dropped. This could
+ have a devastating effect upon the throughput of TCP over an
+ LFN. In addition, if a congestion control mechanism based
+ upon some form of random dropping were introduced into
+ gateways, randomly spaced packet drops would become common,
+ possible increasing the probability of dropping more than one
+ packet per window.
+
+ To generalize the Fast Retransmit/Fast Recovery mechanism to
+ handle multiple packets dropped per window, selective
+ acknowledgments are required. Unlike the normal cumulative
+ acknowledgments of TCP, selective acknowledgments give the
+ sender a complete picture of which segments are queued at the
+ receiver and which have not yet arrived. Some evidence in
+ favor of selective acknowledgments has been published
+ [NBS85], and selective acknowledgments have been included in
+ a number of experimental Internet protocols -- VMTP
+ [Cheriton88], NETBLT [Clark87], and RDP [Velten84], and
+ proposed for OSI TP4 [NBS85]. However, in the non-LFN
+ regime, selective acknowledgments reduce the number of
+
+
+
+Jacobson, Braden, & Borman [Page 3]
+
+RFC 1323 TCP Extensions for High Performance May 1992
+
+
+ packets retransmitted but do not otherwise improve
+ performance, making their complexity of questionable value.
+ However, selective acknowledgments are expected to become
+ much more important in the LFN regime.
+
+ RFC-1072 defined a new TCP "SACK" option to send a selective
+ acknowledgment. However, there are important technical
+ issues to be worked out concerning both the format and
+ semantics of the SACK option. Therefore, SACK has been
+ omitted from this package of extensions. It is hoped that
+ SACK can "catch up" during the standardization process.
+
+ (3) Round-Trip Measurement
+
+ TCP implements reliable data delivery by retransmitting
+ segments that are not acknowledged within some retransmission
+ timeout (RTO) interval. Accurate dynamic determination of an
+ appropriate RTO is essential to TCP performance. RTO is
+ determined by estimating the mean and variance of the
+ measured round-trip time (RTT), i.e., the time interval
+ between sending a segment and receiving an acknowledgment for
+ it [Jacobson88a].
+
+ Section 4 introduces a new TCP option, "Timestamps", and then
+ defines a mechanism using this option that allows nearly
+ every segment, including retransmissions, to be timed at
+ negligible computational cost. We use the mnemonic RTTM
+ (Round Trip Time Measurement) for this mechanism, to
+ distinguish it from other uses of the Timestamps option.
+
+
+ 1.2 TCP Reliability
+
+ Now we turn from performance to reliability. High transfer rate
+ enters TCP performance through the bandwidth*delay product.
+ However, high transfer rate alone can threaten TCP reliability by
+ violating the assumptions behind the TCP mechanism for duplicate
+ detection and sequencing.
+
+ An especially serious kind of error may result from an accidental
+ reuse of TCP sequence numbers in data segments. Suppose that an
+ "old duplicate segment", e.g., a duplicate data segment that was
+ delayed in Internet queues, is delivered to the receiver at the
+ wrong moment, so that its sequence numbers falls somewhere within
+ the current window. There would be no checksum failure to warn of
+ the error, and the result could be an undetected corruption of the
+ data. Reception of an old duplicate ACK segment at the
+ transmitter could be only slightly less serious: it is likely to
+
+
+
+Jacobson, Braden, & Borman [Page 4]
+
+RFC 1323 TCP Extensions for High Performance May 1992
+
+
+ lock up the connection so that no further progress can be made,
+ forcing an RST on the connection.
+
+ TCP reliability depends upon the existence of a bound on the
+ lifetime of a segment: the "Maximum Segment Lifetime" or MSL. An
+ MSL is generally required by any reliable transport protocol,
+ since every sequence number field must be finite, and therefore
+ any sequence number may eventually be reused. In the Internet
+ protocol suite, the MSL bound is enforced by an IP-layer
+ mechanism, the "Time-to-Live" or TTL field.
+
+ Duplication of sequence numbers might happen in either of two
+ ways:
+
+ (1) Sequence number wrap-around on the current connection
+
+ A TCP sequence number contains 32 bits. At a high enough
+ transfer rate, the 32-bit sequence space may be "wrapped"
+ (cycled) within the time that a segment is delayed in queues.
+
+ (2) Earlier incarnation of the connection
+
+ Suppose that a connection terminates, either by a proper
+ close sequence or due to a host crash, and the same
+ connection (i.e., using the same pair of sockets) is
+ immediately reopened. A delayed segment from the terminated
+ connection could fall within the current window for the new
+ incarnation and be accepted as valid.
+
+ Duplicates from earlier incarnations, Case (2), are avoided by
+ enforcing the current fixed MSL of the TCP spec, as explained in
+ Section 5.3 and Appendix B. However, case (1), avoiding the
+ reuse of sequence numbers within the same connection, requires an
+ MSL bound that depends upon the transfer rate, and at high enough
+ rates, a new mechanism is required.
+
+ More specifically, if the maximum effective bandwidth at which TCP
+ is able to transmit over a particular path is B bytes per second,
+ then the following constraint must be satisfied for error-free
+ operation:
+
+ 2**31 / B > MSL (secs) [1]
+
+ The following table shows the value for Twrap = 2**31/B in
+ seconds, for some important values of the bandwidth B:
+
+
+
+
+
+
+Jacobson, Braden, & Borman [Page 5]
+
+RFC 1323 TCP Extensions for High Performance May 1992
+
+
+ Network B*8 B Twrap
+ bits/sec bytes/sec secs
+ _______ _______ ______ ______
+
+ ARPANET 56kbps 7KBps 3*10**5 (~3.6 days)
+
+ DS1 1.5Mbps 190KBps 10**4 (~3 hours)
+
+ Ethernet 10Mbps 1.25MBps 1700 (~30 mins)
+
+ DS3 45Mbps 5.6MBps 380
+
+ FDDI 100Mbps 12.5MBps 170
+
+ Gigabit 1Gbps 125MBps 17
+
+
+ It is clear that wrap-around of the sequence space is not a
+ problem for 56kbps packet switching or even 10Mbps Ethernets. On
+ the other hand, at DS3 and FDDI speeds, Twrap is comparable to the
+ 2 minute MSL assumed by the TCP specification [Postel81]. Moving
+ towards gigabit speeds, Twrap becomes too small for reliable
+ enforcement by the Internet TTL mechanism.
+
+ The 16-bit window field of TCP limits the effective bandwidth B to
+ 2**16/RTT, where RTT is the round-trip time in seconds
+ [McKenzie89]. If the RTT is large enough, this limits B to a
+ value that meets the constraint [1] for a large MSL value. For
+ example, consider a transcontinental backbone with an RTT of 60ms
+ (set by the laws of physics). With the bandwidth*delay product
+ limited to 64KB by the TCP window size, B is then limited to
+ 1.1MBps, no matter how high the theoretical transfer rate of the
+ path. This corresponds to cycling the sequence number space in
+ Twrap= 2000 secs, which is safe in today's Internet.
+
+ It is important to understand that the culprit is not the larger
+ window but rather the high bandwidth. For example, consider a
+ (very large) FDDI LAN with a diameter of 10km. Using the speed of
+ light, we can compute the RTT across the ring as
+ (2*10**4)/(3*10**8) = 67 microseconds, and the delay*bandwidth
+ product is then 833 bytes. A TCP connection across this LAN using
+ a window of only 833 bytes will run at the full 100mbps and can
+ wrap the sequence space in about 3 minutes, very close to the MSL
+ of TCP. Thus, high speed alone can cause a reliability problem
+ with sequence number wrap-around, even without extended windows.
+
+ Watson's Delta-T protocol [Watson81] includes network-layer
+ mechanisms for precise enforcement of an MSL. In contrast, the IP
+
+
+
+Jacobson, Braden, & Borman [Page 6]
+
+RFC 1323 TCP Extensions for High Performance May 1992
+
+