Index: BOOK/final-system/common/iputils.xml
===================================================================
--- BOOK/final-system/common/iputils.xml	(revision 7f4caf0a06fc6cb89b021e3f7ea2d66df2d6d171)
+++ BOOK/final-system/common/iputils.xml	(revision 52f035dd1e8ab1e000034a0b64802af3540510c4)
@@ -29,4 +29,8 @@
 <screen os="p2"><userinput>patch -Np1 -i ../&iputils-fixes-patch;</userinput></screen>
 
+    <para os="p3">The following patch contains the man-pages for IPutils:</para>
+
+<screen os="p4"><userinput>patch -Np1 -i ../&iputils-manpages-patch;</userinput></screen>
+
     <para os="a">Compile the package:</para>
 
@@ -40,5 +44,6 @@
 cp -v arping /usr/bin
 cp -v tracepath /usr/bin
-cp -v trace{path,route}6 /usr/bin</userinput></screen>
+cp -v trace{path,route}6 /usr/bin
+install -v -m644 doc/*.8 /usr/share/man/man8</userinput></screen>
 
   </sect2>
Index: BOOK/final-system/multilib/iputils.xml
===================================================================
--- BOOK/final-system/multilib/iputils.xml	(revision 7f4caf0a06fc6cb89b021e3f7ea2d66df2d6d171)
+++ BOOK/final-system/multilib/iputils.xml	(revision 52f035dd1e8ab1e000034a0b64802af3540510c4)
@@ -32,4 +32,12 @@
     <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
     href="../common/iputils.xml"
+    xpointer="xpointer(//*[@os='p3'])"/>
+
+    <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
+    href="../common/iputils.xml"
+    xpointer="xpointer(//*[@os='p4'])"/>
+
+    <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
+    href="../common/iputils.xml"
     xpointer="xpointer(//*[@os='a'])"/>
 
Index: BOOK/introduction/common/changelog.xml
===================================================================
--- BOOK/introduction/common/changelog.xml	(revision 7f4caf0a06fc6cb89b021e3f7ea2d66df2d6d171)
+++ BOOK/introduction/common/changelog.xml	(revision 52f035dd1e8ab1e000034a0b64802af3540510c4)
@@ -43,4 +43,7 @@
           <para>[Jim] - Updated Bzip2 Multilib 64bit install. On some occasions the make command
           during an install will rebuild sources. Lets make sure it uses our specified options.</para>
+        </listitem>
+        <listitem>
+          <para>[Jim] - Added Missing ManPages Patch to IPutils.</para>
         </listitem>
       </itemizedlist>
Index: BOOK/materials/common/patches.xml
===================================================================
--- BOOK/materials/common/patches.xml	(revision 7f4caf0a06fc6cb89b021e3f7ea2d66df2d6d171)
+++ BOOK/materials/common/patches.xml	(revision 52f035dd1e8ab1e000034a0b64802af3540510c4)
@@ -192,4 +192,13 @@
 
     <varlistentry>
+      <term>IPUtils Missing Man-Pages Patch - <token>&iputils-manpages-patch-size;</token>:</term>
+      <listitem>
+        <para>Download: <ulink
+        url="&patches-root;&iputils-manpages-patch;"/></para>
+        <para>MD5 sum: <literal>&iputils-manpages-patch-md5;</literal></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
       <term>Man i18n Patch - <token>&man-i18n-patch-size;</token>:</term>
       <listitem>
Index: BOOK/patches.ent
===================================================================
--- BOOK/patches.ent	(revision 7f4caf0a06fc6cb89b021e3f7ea2d66df2d6d171)
+++ BOOK/patches.ent	(revision 52f035dd1e8ab1e000034a0b64802af3540510c4)
@@ -83,4 +83,8 @@
 <!ENTITY iputils-fixes-patch-size "4 KB">
 
+<!ENTITY iputils-manpages-patch "iputils-&iputils-version;-manpages-1.patch">
+<!ENTITY iputils-manpages-patch-md5 "32f117ad86b66d10e1efde7c9134080f">
+<!ENTITY iputils-manpages-patch-size "40 KB">
+
 <!ENTITY man-i18n-patch "man-&man-version;-i18n-1.patch">
 <!ENTITY man-i18n-patch-md5 "8b189d6500461797250ae9f3e5638dd5">
Index: patches/iputils-s20071127-manpages-1.patch
===================================================================
--- patches/iputils-s20071127-manpages-1.patch	(revision 52f035dd1e8ab1e000034a0b64802af3540510c4)
+++ patches/iputils-s20071127-manpages-1.patch	(revision 52f035dd1e8ab1e000034a0b64802af3540510c4)
@@ -0,0 +1,1069 @@
+Submitted By: Jim Gifford <jim at cross-lfs dot org>
+Date: 2009-02-18
+Initial Package Version: s20071127
+Upstream Status: Unknown
+Origin: Jim Gifford
+Description: Provides the man pages (adding docbook2man with all its
+             dependencies would be a major addition to the book, so I built it
+             -once- on a completed system and saved the data). 
+
+diff -Naur iputils-s20071127.orig/doc/arping.8 iputils-s20071127/doc/arping.8
+--- iputils-s20071127.orig/doc/arping.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/arping.8	2009-02-18 20:52:34.000000000 -0800
+@@ -0,0 +1,110 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "ARPING" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++arping \- send ARP REQUEST to a neighbour host
++.SH SYNOPSIS
++
++\fBarping\fR [\fB-AbDfhqUV\fR] [\fB-c \fIcount\fB\fR] [\fB-w \fIdeadline\fB\fR] [\fB-s \fIsource\fB\fR] \fB-I \fIinterface\fB\fR \fB\fIdestination\fB\fR
++
++.SH "DESCRIPTION"
++.PP
++Ping \fIdestination\fR on device \fIinterface\fR by ARP packets,
++using source address \fIsource\fR.
++.SH "OPTIONS"
++.TP
++\fB-A\fR
++The same as \fB-U\fR, but ARP REPLY packets used instead
++of ARP REQUEST.
++.TP
++\fB-b\fR
++Send only MAC level broadcasts. Normally \fBarping\fR starts
++from sending broadcast, and switch to unicast after reply received.
++.TP
++\fB-c \fIcount\fB\fR
++Stop after sending \fIcount\fR ARP REQUEST
++packets. With 
++\fIdeadline\fR
++option, \fBarping\fR waits for
++\fIcount\fR ARP REPLY packets, until the timeout expires.
++.TP
++\fB-D\fR
++Duplicate address detection mode (DAD). See 
++RFC2131, 4.4.1.
++Returns 0, if DAD succeeded i.e. no replies are received
++.TP
++\fB-f\fR
++Finish after the first reply confirming that target is alive.
++.TP
++\fB-I \fIinterface\fB\fR
++Name of network device where to send ARP REQUEST packets. This option
++is required.
++.TP
++\fB-h\fR
++Print help page and exit.
++.TP
++\fB-q\fR
++Quiet output. Nothing is displayed.
++.TP
++\fB-s \fIsource\fB\fR
++IP source address to use in ARP packets.
++If this option is absent, source address is:
++.RS
++.TP 0.2i
++\(bu
++In DAD mode (with option \fB-D\fR) set to 0.0.0.0.
++.TP 0.2i
++\(bu
++In Unsolicited ARP mode (with options \fB-U\fR or \fB-A\fR)
++set to \fIdestination\fR.
++.TP 0.2i
++\(bu
++Otherwise, it is calculated from routing tables.
++.RE
++.TP
++\fB-U\fR
++Unsolicited ARP mode to update neighbours' ARP caches.
++No replies are expected.
++.TP
++\fB-V\fR
++Print version of the program and exit.
++.TP
++\fB-w \fIdeadline\fB\fR
++Specify a timeout, in seconds, before
++\fBarping\fR
++exits regardless of how many
++packets have been sent or received. In this case
++\fBarping\fR
++does not stop after
++\fIcount\fR
++packet are sent, it waits either for
++\fIdeadline\fR
++expire or until
++\fIcount\fR
++probes are answered.
++.SH "SEE ALSO"
++.PP
++\fBping\fR(8),
++\fBclockdiff\fR(8),
++\fBtracepath\fR(8).
++.SH "AUTHOR"
++.PP
++\fBarping\fR was written by
++Alexey Kuznetsov
++<kuznet@ms2.inr.ac.ru>.
++It is now maintained by
++YOSHIFUJI Hideaki
++<yoshfuji@skbuff.net>.
++.SH "SECURITY"
++.PP
++\fBarping\fR requires CAP_NET_RAWIO capability
++to be executed. It is not recommended to be used as set-uid root,
++because it allows user to modify ARP caches of neighbour hosts.
++.SH "AVAILABILITY"
++.PP
++\fBarping\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/clockdiff.8 iputils-s20071127/doc/clockdiff.8
+--- iputils-s20071127.orig/doc/clockdiff.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/clockdiff.8	2009-02-18 20:52:38.000000000 -0800
+@@ -0,0 +1,81 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "CLOCKDIFF" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++clockdiff \- measure clock difference between hosts
++.SH SYNOPSIS
++
++\fBclockdiff\fR [\fB-o\fR] [\fB-o1\fR] \fB\fIdestination\fB\fR
++
++.SH "DESCRIPTION"
++.PP
++\fBclockdiff\fR Measures clock difference between us and
++\fIdestination\fR with 1 msec resolution using ICMP TIMESTAMP
++[2]
++packets or, optionally, IP TIMESTAMP option
++[3]
++option added to ICMP ECHO.
++[1]
++.SH "OPTIONS"
++.TP
++\fB-o\fR
++Use IP TIMESTAMP with ICMP ECHO instead of ICMP TIMESTAMP
++messages. It is useful with some destinations, which do not support
++ICMP TIMESTAMP (f.e. Solaris <2.4).
++.TP
++\fB-o1\fR
++Slightly different form of \fB-o\fR, namely it uses three-term
++IP TIMESTAMP with prespecified hop addresses instead of four term one.
++What flavor works better depends on target host. Particularly,
++\fB-o\fR is better for Linux.
++.SH "WARNINGS"
++.TP 0.2i
++\(bu
++Some nodes (Cisco) use non-standard timestamps, which is allowed
++by RFC, but makes timestamps mostly useless.
++.TP 0.2i
++\(bu
++Some nodes generate messed timestamps (Solaris>2.4), when
++run \fBxntpd\fR. Seems, its IP stack uses a corrupted clock source,
++which is synchronized to time-of-day clock periodically and jumps
++randomly making timestamps mostly useless. Good news is that you can
++use NTP in this case, which is even better.
++.TP 0.2i
++\(bu
++\fBclockdiff\fR shows difference in time modulo 24 days.
++.SH "SEE ALSO"
++.PP
++\fBping\fR(8),
++\fBarping\fR(8),
++\fBtracepath\fR(8).
++.SH "REFERENCES"
++.PP
++[1] ICMP ECHO,
++RFC0792, page 14.
++.PP
++[2] ICMP TIMESTAMP,
++RFC0792, page 16.
++.PP
++[3] IP TIMESTAMP option,
++RFC0791, 3.1, page 16.
++.SH "AUTHOR"
++.PP
++\fBclockdiff\fR was compiled by
++Alexey Kuznetsov
++<kuznet@ms2.inr.ac.ru>. It was based on code borrowed
++from BSD \fBtimed\fR daemon.
++It is now maintained by
++YOSHIFUJI Hideaki
++<yoshfuji@skbuff.net>.
++.SH "SECURITY"
++.PP
++\fBclockdiff\fR requires CAP_NET_RAWIO capability
++to be executed. It is safe to be used as set-uid root.
++.SH "AVAILABILITY"
++.PP
++\fBclockdiff\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/pg3.8 iputils-s20071127/doc/pg3.8
+--- iputils-s20071127.orig/doc/pg3.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/pg3.8	2009-02-18 20:52:42.000000000 -0800
+@@ -0,0 +1,86 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "PG3" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++pg3, ipg, pgset \- send stream of UDP packets
++.SH SYNOPSIS
++
++\fBsource ipg\fR
++
++
++\fBpg\fR
++
++
++\fBpgset\fR \fB\fICOMMAND\fB\fR
++
++.SH "DESCRIPTION"
++.PP
++\fBipg\fR is not a program, it is script which should be sourced
++to \fBbash\fR. When sourced it loads module \fIpg3\fR and
++exports a few of functions accessible from parent shell. These macros
++are \fBpg\fR to start packet injection and to get the results of run;
++and \fBpgset\fR to setup packet generator.
++.PP
++\fBpgset\fR can send the following commands to module \fIpg3\fR:
++.SH "COMMAND"
++.TP
++\fBodev \fIDEVICE\fB\fR
++Name of Ethernet device to test. See
++warning below.
++.TP
++\fBpkt_size \fIBYTES\fB\fR
++Size of packet to generate. The size includes all the headers: UDP, IP,
++MAC, but does not account for overhead internal to medium, i.e. FCS
++and various paddings.
++.TP
++\fBfrags \fINUMBER\fB\fR
++Each packet will contain \fINUMBER\fR of fragments.
++Maximal amount for linux-2.4 is 6. Far not all the devices support
++fragmented buffers.
++.TP
++\fBcount \fINUMBER\fB\fR
++Send stream of \fINUMBER\fR of packets and stop after this.
++.TP
++\fBipg \fITIME\fB\fR
++Introduce artificial delay between packets of \fITIME\fR
++microseconds.
++.TP
++\fBdst \fIIP_ADDRESS\fB\fR
++Select IP destination where the stream is sent to.
++Beware, never set this address at random. \fBpg3\fR is not a toy,
++it creates really tough stream. Default value is 0.0.0.0.
++.TP
++\fBdst \fIMAC_ADDRESS\fB\fR
++Select MAC destination where the stream is sent to.
++Default value is 00:00:00:00:00:00 in hope that this will not be received
++by any node on LAN.
++.TP
++\fBstop\fR
++Abort packet injection.
++.SH "WARNING"
++.PP
++When output device is set to some random device different
++of hardware Ethernet device, \fBpg3\fR will crash kernel.
++.PP
++Do not use it on VLAN, ethertap, VTUN and other devices,
++which emulate Ethernet not being real Ethernet in fact.
++.SH "AUTHOR"
++.PP
++\fBpg3\fR was written by Robert Olsson <robert.olsson@its.uu.se>.
++.SH "SECURITY"
++.PP
++This can be used only by superuser.
++.PP
++This tool creates floods of packets which is unlikely to be handled
++even by high-end machines. For example, it saturates gigabit link with
++60 byte packets when used with Intel's e1000. In face of such stream
++switches, routers and end hosts may deadlock, crash, explode.
++Use only in test lab environment.
++.SH "AVAILABILITY"
++.PP
++\fBpg3\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/ping.8 iputils-s20071127/doc/ping.8
+--- iputils-s20071127.orig/doc/ping.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/ping.8	2009-02-18 20:52:44.000000000 -0800
+@@ -0,0 +1,332 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "PING" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++ping, ping6 \- send ICMP ECHO_REQUEST to network hosts
++.SH SYNOPSIS
++
++\fBping\fR [\fB-LRUbdfnqrvVaAB\fR] [\fB-c \fIcount\fB\fR] [\fB-i \fIinterval\fB\fR] [\fB-l \fIpreload\fB\fR] [\fB-p \fIpattern\fB\fR] [\fB-s \fIpacketsize\fB\fR] [\fB-t \fIttl\fB\fR] [\fB-w \fIdeadline\fB\fR] [\fB-F \fIflowlabel\fB\fR] [\fB-I \fIinterface\fB\fR] [\fB-M \fIhint\fB\fR] [\fB-Q \fItos\fB\fR] [\fB-S \fIsndbuf\fB\fR] [\fB-T \fItimestamp option\fB\fR] [\fB-W \fItimeout\fB\fR] [\fB\fIhop\fB\fR\fI ...\fR] \fB\fIdestination\fB\fR
++
++.SH "DESCRIPTION"
++.PP
++\fBping\fR uses the ICMP protocol's mandatory ECHO_REQUEST
++datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway.
++ECHO_REQUEST datagrams (``pings'') have an IP and ICMP
++header, followed by a struct timeval and then an arbitrary
++number of ``pad'' bytes used to fill out the packet.
++.SH "OPTIONS"
++.TP
++\fB-a\fR
++Audible ping.
++.TP
++\fB-A\fR
++Adaptive ping. Interpacket interval adapts to round-trip time, so that
++effectively not more than one (or more, if preload is set) unanswered probes
++present in the network. Minimal interval is 200msec for not super-user.
++On networks with low rtt this mode is essentially equivalent to flood mode.  
++.TP
++\fB-b\fR
++Allow pinging a broadcast address.
++.TP
++\fB-B\fR
++Do not allow \fBping\fR to change source address of probes.
++The address is bound to one selected when \fBping\fR starts.
++.TP
++\fB-c \fIcount\fB\fR
++Stop after sending \fIcount\fR ECHO_REQUEST
++packets. With 
++\fIdeadline\fR
++option, \fBping\fR waits for
++\fIcount\fR ECHO_REPLY packets, until the timeout expires.
++.TP
++\fB-d\fR
++Set the SO_DEBUG option on the socket being used.
++Essentially, this socket option is not used by Linux kernel. 
++.TP
++\fB-F \fIflow label\fB\fR
++Allocate and set 20 bit flow label on echo request packets.
++(Only \fBping6\fR). If value is zero, kernel allocates random flow label.
++.TP
++\fB-f\fR
++Flood ping. For every ECHO_REQUEST sent a period ``.'' is printed,
++while for ever ECHO_REPLY received a backspace is printed.
++This provides a rapid display of how many packets are being dropped.
++If interval is not given, it sets interval to zero and
++outputs packets as fast as they come back or one hundred times per second,
++whichever is more.
++Only the super-user may use this option with zero interval.
++.TP
++\fB-i \fIinterval\fB\fR
++Wait \fIinterval\fR seconds between sending each packet.
++The default is to wait for one second between each packet normally,
++or not to wait in flood mode. Only super-user may set interval
++to values less 0.2 seconds.
++.TP
++\fB-I \fIinterface address\fB\fR
++Set source address to specified interface address. Argument
++may be numeric IP address or name of device. When pinging IPv6
++link-local address this option is required.
++.TP
++\fB-l \fIpreload\fB\fR
++If \fIpreload\fR is specified,
++\fBping\fR sends that many packets not waiting for reply.
++Only the super-user may select preload more than 3.
++.TP
++\fB-L\fR
++Suppress loopback of multicast packets.  This flag only applies if the ping
++destination is a multicast address.
++.TP
++\fB-n\fR
++Numeric output only.
++No attempt will be made to lookup symbolic names for host addresses.
++.TP
++\fB-p \fIpattern\fB\fR
++You may specify up to 16 ``pad'' bytes to fill out the packet you send.
++This is useful for diagnosing data-dependent problems in a network.
++For example, \fB-p ff\fR will cause the sent packet
++to be filled with all ones.
++.TP
++\fB-Q \fItos\fB\fR
++Set Quality of Service -related bits in ICMP datagrams.  
++\fItos\fR can be either decimal or hex number.
++Traditionally (RFC1349), these have been interpreted as: 0 for reserved
++(currently being redefined as congestion control), 1-4 for Type of Service
++and 5-7 for Precedence.
++Possible settings for Type of Service are: minimal cost: 0x02, 
++reliability: 0x04, throughput: 0x08, low delay: 0x10.  Multiple TOS bits
++should not be set simultaneously.  Possible settings for
++special Precedence range from priority (0x20) to net control (0xe0).  You
++must be root (CAP_NET_ADMIN capability) to use Critical or
++higher precedence value.  You cannot set
++bit 0x01 (reserved) unless ECN has been enabled in the kernel.
++In RFC2474, these fields has been redefined as 8-bit Differentiated
++Services (DS), consisting of: bits 0-1 of separate data (ECN will be used,
++here), and bits 2-7 of Differentiated Services Codepoint (DSCP).
++.TP
++\fB-q\fR
++Quiet output.
++Nothing is displayed except the summary lines at startup time and
++when finished.
++.TP
++\fB-R\fR
++Record route.
++Includes the RECORD_ROUTE option in the ECHO_REQUEST
++packet and displays the route buffer on returned packets.
++Note that the IP header is only large enough for nine such routes.
++Many hosts ignore or discard this option.
++.TP
++\fB-r\fR
++Bypass the normal routing tables and send directly to a host on an attached
++interface.
++If the host is not on a directly-attached network, an error is returned.
++This option can be used to ping a local host through an interface
++that has no route through it provided the option \fB-I\fR is also
++used.
++.TP
++\fB-s \fIpacketsize\fB\fR
++Specifies the number of data bytes to be sent.  
++The default is 56, which translates into 64 ICMP
++data bytes when combined with the 8 bytes of ICMP header data.
++.TP
++\fB-S \fIsndbuf\fB\fR
++Set socket sndbuf. If not specified, it is selected to buffer
++not more than one packet.
++.TP
++\fB-t \fIttl\fB\fR
++Set the IP Time to Live.
++.TP
++\fB-T \fItimestamp option\fB\fR
++Set special IP timestamp options.
++\fItimestamp option\fR may be either 
++\fItsonly\fR (only timestamps), 
++\fItsandaddr\fR (timestamps and addresses) or 
++\fItsprespec host1 [host2 [host3 [host4]]]\fR
++(timestamp prespecified hops).
++.TP
++\fB-M \fIhint\fB\fR
++Select Path MTU Discovery strategy.
++\fIhint\fR may be either \fIdo\fR
++(prohibit fragmentation, even local one), 
++\fIwant\fR (do PMTU discovery, fragment locally when packet size
++is large), or \fIdont\fR (do not set DF flag).
++.TP
++\fB-U\fR
++Print full user-to-user latency (the old behaviour). Normally
++\fBping\fR
++prints network round trip time, which can be different
++f.e. due to DNS failures. 
++.TP
++\fB-v\fR
++Verbose output.
++.TP
++\fB-V\fR
++Show version and exit.
++.TP
++\fB-w \fIdeadline\fB\fR
++Specify a timeout, in seconds, before
++\fBping\fR
++exits regardless of how many
++packets have been sent or received. In this case
++\fBping\fR
++does not stop after
++\fIcount\fR
++packet are sent, it waits either for
++\fIdeadline\fR
++expire or until
++\fIcount\fR
++probes are answered or for some error notification from network.   
++.TP
++\fB-W \fItimeout\fB\fR
++Time to wait for a response, in seconds. The option affects only timeout
++in absense of any responses, otherwise \fBping\fR waits for two RTTs.
++.PP
++When using \fBping\fR for fault isolation, it should first be run
++on the local host, to verify that the local network interface is up
++and running. Then, hosts and gateways further and further away should be
++``pinged''. Round-trip times and packet loss statistics are computed.
++If duplicate packets are received, they are not included in the packet
++loss calculation, although the round trip time of these packets is used
++in calculating the minimum/average/maximum round-trip time numbers.
++When the specified number of packets have been sent (and received) or
++if the program is terminated with a
++SIGINT, a brief summary is displayed. Shorter current statistics
++can be obtained without termination of process with signal
++SIGQUIT.
++.PP
++If \fBping\fR does not receive any reply packets at all it will
++exit with code 1. If a packet 
++\fIcount\fR
++and
++\fIdeadline\fR
++are both specified, and fewer than
++\fIcount\fR
++packets are received by the time the
++\fIdeadline\fR
++has arrived, it will also exit with code 1. 
++On other error it exits with code 2. Otherwise it exits with code 0. This
++makes it possible to use the exit code to see if a host is alive or
++not.
++.PP
++This program is intended for use in network testing, measurement and
++management.
++Because of the load it can impose on the network, it is unwise to use
++\fBping\fR during normal operations or from automated scripts.
++.SH "ICMP PACKET DETAILS"
++.PP
++An IP header without options is 20 bytes.
++An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth
++of ICMP header followed by an arbitrary amount of data.
++When a \fIpacketsize\fR is given, this indicated the size of this
++extra piece of data (the default is 56). Thus the amount of data received
++inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes
++more than the requested data space (the ICMP header).
++.PP
++If the data space is at least of size of struct timeval
++\fBping\fR uses the beginning bytes of this space to include
++a timestamp which it uses in the computation of round trip times.
++If the data space is shorter, no round trip times are given.
++.SH "DUPLICATE AND DAMAGED PACKETS"
++.PP
++\fBping\fR will report duplicate and damaged packets.
++Duplicate packets should never occur, and seem to be caused by
++inappropriate link-level retransmissions.
++Duplicates may occur in many situations and are rarely (if ever) a
++good sign, although the presence of low levels of duplicates may not
++always be cause for alarm.
++.PP
++Damaged packets are obviously serious cause for alarm and often
++indicate broken hardware somewhere in the
++\fBping\fR packet's path (in the network or in the hosts).
++.SH "TRYING DIFFERENT DATA PATTERNS"
++.PP
++The (inter)network layer should never treat packets differently depending
++on the data contained in the data portion.
++Unfortunately, data-dependent problems have been known to sneak into
++networks and remain undetected for long periods of time.
++In many cases the particular pattern that will have problems is something
++that doesn't have sufficient ``transitions'', such as all ones or all
++zeros, or a pattern right at the edge, such as almost all zeros.
++It isn't necessarily enough to specify a data pattern of all zeros (for
++example) on the command line because the pattern that is of interest is
++at the data link level, and the relationship between what you type and
++what the controllers transmit can be complicated.
++.PP
++This means that if you have a data-dependent problem you will probably
++have to do a lot of testing to find it.
++If you are lucky, you may manage to find a file that either can't be sent
++across your network or that takes much longer to transfer than other
++similar length files.
++You can then examine this file for repeated patterns that you can test
++using the \fB-p\fR option of \fBping\fR.
++.SH "TTL DETAILS"
++.PP
++The TTL value of an IP packet represents the maximum number of IP routers
++that the packet can go through before being thrown away.
++In current practice you can expect each router in the Internet to decrement
++the TTL field by exactly one.
++.PP
++The TCP/IP specification states that the TTL field for TCP
++packets should be set to 60, but many systems use smaller values
++(4.3 BSD uses 30, 4.2 used 15).
++.PP
++The maximum possible value of this field is 255, and most Unix systems set
++the TTL field of ICMP ECHO_REQUEST packets to 255.
++This is why you will find you can ``ping'' some hosts, but not reach them
++with
++\fBtelnet\fR(1)
++or
++\fBftp\fR(1).
++.PP
++In normal operation ping prints the ttl value from the packet it receives.
++When a remote system receives a ping packet, it can do one of three things
++with the TTL field in its response:
++.TP 0.2i
++\(bu
++Not change it; this is what Berkeley Unix systems did before the
++4.3BSD Tahoe release. In this case the TTL value in the received packet
++will be 255 minus the number of routers in the round-trip path.
++.TP 0.2i
++\(bu
++Set it to 255; this is what current Berkeley Unix systems do.
++In this case the TTL value in the received packet will be 255 minus the
++number of routers in the path \fBfrom\fR
++the remote system \fBto\fR the \fBping\fRing host.
++.TP 0.2i
++\(bu
++Set it to some other value. Some machines use the same value for
++ICMP packets that they use for TCP packets, for example either 30 or 60.
++Others may use completely wild values.
++.SH "BUGS"
++.TP 0.2i
++\(bu
++Many Hosts and Gateways ignore the RECORD_ROUTE option.
++.TP 0.2i
++\(bu
++The maximum IP header length is too small for options like
++RECORD_ROUTE to be completely useful.
++There's not much that that can be done about this, however.
++.TP 0.2i
++\(bu
++Flood pinging is not recommended in general, and flood pinging the
++broadcast address should only be done under very controlled conditions.
++.SH "SEE ALSO"
++.PP
++\fBnetstat\fR(1),
++\fBifconfig\fR(8).
++.SH "HISTORY"
++.PP
++The \fBping\fR command appeared in 4.3BSD.
++.PP
++The version described here is its descendant specific to Linux.
++.SH "SECURITY"
++.PP
++\fBping\fR requires CAP_NET_RAWIO capability
++to be executed. It may be used as set-uid root.
++.SH "AVAILABILITY"
++.PP
++\fBping\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/rarpd.8 iputils-s20071127/doc/rarpd.8
+--- iputils-s20071127.orig/doc/rarpd.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/rarpd.8	2009-02-18 20:52:48.000000000 -0800
+@@ -0,0 +1,84 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "RARPD" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++rarpd \- answer RARP REQUESTs
++.SH SYNOPSIS
++
++\fBarping\fR [\fB-aAvde\fR] [\fB-b \fIbootdir\fB\fR] [\fB\fIinterface\fB\fR]
++
++.SH "DESCRIPTION"
++.PP
++Listens
++RARP
++requests from clients. Provided MAC address of client
++is found in \fI/etc/ethers\fR database and
++obtained host name is resolvable to an IP address appropriate
++for attached network, \fBrarpd\fR answers to client with RARPD
++reply carrying an IP address.
++.PP
++To allow multiple boot servers on the network \fBrarpd\fR
++optionally checks for presence Sun-like bootable image in TFTP directory.
++It should have form \fBHexadecimal_IP.ARCH\fR, f.e. to load
++sparc 193.233.7.98 \fIC1E90762.SUN4M\fR is linked to
++an image appropriate for SUM4M in directory \fI/etc/tftpboot\fR.
++.SH "WARNING"
++.PP
++This facility is deeply obsoleted by
++BOOTP
++and later
++DHCP protocols.
++However, some clients really still need this to boot.
++.SH "OPTIONS"
++.TP
++\fB-a\fR
++Listen on all the interfaces. Currently it is an internal
++option, its function is overridden with \fIinterface\fR
++argument. It should not be used.
++.TP
++\fB-A\fR
++Listen not only RARP but also ARP messages, some rare clients
++use ARP by some unknown reason.
++.TP
++\fB-v\fR
++Be verbose.
++.TP
++\fB-d\fR
++Debug mode. Do not go to background.
++.TP
++\fB-e\fR
++Do not check for presence of a boot image, reply if MAC address
++resolves to a valid IP address using \fI/etc/ethers\fR
++database and DNS. 
++.TP
++\fB-b \fIbootdir\fB\fR
++TFTP boot directory. Default is \fI/etc/tftpboot\fR
++.SH "SEE ALSO"
++.PP
++\fBarping\fR(8),
++\fBtftpd\fR(8).
++.SH "AUTHOR"
++.PP
++\fBrarpd\fR was written by
++Alexey Kuznetsov
++<kuznet@ms2.inr.ac.ru>.
++It is now maintained by
++YOSHIFUJI Hideaki
++<yoshfuji@skbuff.net>.
++.SH "SECURITY"
++.PP
++\fBrarpd\fR requires CAP_NET_RAWIO capability
++to listen and send RARP and ARP packets. It also needs CAP_NET_ADMIN
++to give to kernel hint for ARP resolution; this is not strictly required,
++but some (most of, to be more exact) clients are so badly broken that
++are not able to answer ARP before they are finally booted. This is
++not wonderful taking into account that clients using RARPD in 2002
++are all unsupported relic creatures of 90's and even earlier.
++.SH "AVAILABILITY"
++.PP
++\fBrarpd\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/rdisc.8 iputils-s20071127/doc/rdisc.8
+--- iputils-s20071127.orig/doc/rdisc.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/rdisc.8	2009-02-18 20:52:53.000000000 -0800
+@@ -0,0 +1,110 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "RDISC" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++rdisc \- network router discovery daemon
++.SH SYNOPSIS
++
++\fBrdisc\fR [\fB-abdfstvV\fR] [\fB\fIsend_address\fB\fR] [\fB\fIreceive_address\fB\fR]
++
++.SH "DESCRIPTION"
++.PP
++\fBrdisc\fR implements client side of the ICMP router discover protocol.
++\fBrdisc\fR is invoked at boot time to populate the network
++routing tables with default routes. 
++.PP
++\fBrdisc\fR listens on the ALL_HOSTS (224.0.0.1) multicast address
++(or \fIreceive_address\fR provided it is given) 
++for ROUTER_ADVERTISE messages from routers. The received
++messages are handled by first ignoring those listed router addresses
++with which the host does not share a network. Among the remaining addresses
++the ones with the highest preference are selected as default routers
++and a default route is entered in the kernel routing table
++for each one of them.
++.PP
++Optionally, \fBrdisc\fR can avoid waiting for routers to announce 
++themselves by sending out a few ROUTER_SOLICITATION messages
++to the ALL_ROUTERS (224.0.0.2) multicast address 
++(or \fIsend_address\fR provided it is given) 
++when it is started.
++.PP
++A timer is associated with each router address and the address will
++no longer be considered for inclusion in the the routing tables if the 
++timer expires before a new 
++\fBadvertise\fR message is received from the router.
++The address will also be excluded from consideration if the host receives an 
++\fBadvertise\fR
++message with the preference being maximally negative.
++.PP
++Server side of router discovery protocol is supported by Cisco IOS
++and by any more or less complete UNIX routing daemon, f.e \fBgated\fR.
++.SH "OPTIONS"
++.TP
++\fB-a\fR
++Accept all routers independently of the preference they have in their 
++\fBadvertise\fR messages.
++Normally \fBrdisc\fR only accepts (and enters in the kernel routing
++tables) the router or routers with the highest preference.
++.TP
++\fB-b\fR
++Opposite to \fB-a\fR, i.e. install only router with the best
++preference value. It is default behaviour.
++.TP
++\fB-d\fR
++Send debugging messages to syslog.
++.TP
++\fB-f\fR
++Run \fBrdisc\fR forever even if no routers are found.
++Normally \fBrdisc\fR gives up if it has not received any 
++\fBadvertise\fR message after after soliciting three times,
++in which case it exits with a non-zero exit code.
++If \fB-f\fR is not specified in the first form then 
++\fB-s\fR must be specified.
++.TP
++\fB-s\fR
++Send three \fBsolicitation\fR messages initially to quickly discover
++the routers when the system is booted.
++When \fB-s\fR is specified \fBrdisc\fR
++exits with a non-zero exit code if it can not find any routers.
++This can be overridden with the \fB-f\fR option.
++.TP
++\fB-t\fR
++Test mode. Do not go to background.
++.TP
++\fB-v\fR
++Be verbose i.e. send lots of debugging messages to syslog.
++.TP
++\fB-V\fR
++Print version and exit.
++.SH "HISTORY"
++.PP
++This program was developed by Sun Microsystems (see copyright
++notice in source file). It was ported to Linux by
++Alexey Kuznetsov
++<kuznet@ms2.inr.ac.ru>.
++It is now maintained by
++YOSHIFUJI Hideaki
++<yoshfuji@skbuff.net>.
++.SH "SEE ALSO"
++.PP
++\fBicmp\fR(7),
++\fBinet\fR(7),
++\fBping\fR(8).
++.SH "REFERENCES"
++.PP
++Deering, S.E.,ed "ICMP Router Discovery Messages",
++RFC1256, Network Information Center, SRI International,
++Menlo Park, Calif., September 1991.
++.SH "SECURITY"
++.PP
++\fBrdisc\fR requires CAP_NET_RAWIO to listen
++and send ICMP messages and capability CAP_NET_ADMIN
++to update routing tables. 
++.SH "AVAILABILITY"
++.PP
++\fBrdisc\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/tftpd.8 iputils-s20071127/doc/tftpd.8
+--- iputils-s20071127.orig/doc/tftpd.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/tftpd.8	2009-02-18 20:52:57.000000000 -0800
+@@ -0,0 +1,85 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "TFTPD" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++tftpd \- Trivial File Transfer Protocol server
++.SH SYNOPSIS
++
++\fBtftpd\fR \fB\fIdirectory\fB\fR
++
++.SH "DESCRIPTION"
++.PP
++\fBtftpd\fR is a server which supports the DARPA
++Trivial File Transfer Protocol
++(RFC1350).
++The TFTP server is started
++by \fBinetd\fR(8).
++.PP
++\fIdirectory\fR is required argument; if it is not given
++\fBtftpd\fR aborts. This path is prepended to any file name requested
++via TFTP protocol, effectively chrooting \fBtftpd\fR to this directory.
++File names are validated not to escape out of this directory, however
++administrator may configure such escape using symbolic links.
++.PP
++It is in difference of variants of \fBtftpd\fR usually distributed
++with unix-like systems, which take a list of directories and match
++file names to start from one of given prefixes or to some random
++default, when no arguments were given. There are two reasons not to
++behave in this way: first, it is inconvenient, clients are not expected
++to know something about layout of filesystem on server host.
++And second, TFTP protocol is not a tool for browsing of server's filesystem,
++it is just an agent allowing to boot dumb clients. 
++.PP
++In the case when \fBtftpd\fR is used together with
++\fBrarpd\fR(8),
++tftp directories in these services should coincide and it is expected
++that each client booted via TFTP has boot image corresponding
++its IP address with an architecture suffix following Sun Microsystems
++conventions. See 
++\fBrarpd\fR(8)
++for more details.
++.SH "SECURITY"
++.PP
++TFTP protocol does not provide any authentication.
++Due to this capital flaw \fBtftpd\fR is not able to restrict
++access to files and will allow only publically readable
++files to be accessed. Files may be written only if they already
++exist and are publically writable.
++.PP
++Impact is evident, directory exported via TFTP \fBmust not\fR
++contain sensitive information of any kind, everyone is allowed
++to read it as soon as a client is allowed. Boot images do not contain
++such information as rule, however you should think twice before
++publishing f.e. Cisco IOS config files via TFTP, they contain
++\fBunencrypted\fR passwords and may contain some information
++about the network, which you were not going to make public.
++.PP
++The \fBtftpd\fR server should be executed by \fBinetd\fR
++with dropped root privileges, namely with a user ID giving minimal
++access to files published in tftp directory. If it is executed
++as superuser occasionally, \fBtftpd\fR drops its UID and GID
++to 65534, which is most likely not the thing which you expect.
++However, this is not very essential; remember, only files accessible
++for everyone can be read or written via TFTP.
++.SH "SEE ALSO"
++.PP
++\fBrarpd\fR(8),
++\fBtftp\fR(1),
++\fBinetd\fR(8).
++.SH "HISTORY"
++.PP
++The \fBtftpd\fR command appeared in 4.2BSD. The source in iputils
++is cleaned up both syntactically (ANSIized) and semantically (UDP socket IO).
++.PP
++It is distributed with iputils mostly as good demo of an interesting feature
++(MSG_CONFIRM) allowing to boot long images by dumb clients
++not answering ARP requests until they are finally booted.
++However, this is full functional and can be used in production.
++.SH "AVAILABILITY"
++.PP
++\fBtftpd\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/tracepath.8 iputils-s20071127/doc/tracepath.8
+--- iputils-s20071127.orig/doc/tracepath.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/tracepath.8	2009-02-18 20:53:04.000000000 -0800
+@@ -0,0 +1,94 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "TRACEPATH" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++tracepath, tracepath6 \- traces path to a network host discovering MTU along this path
++.SH SYNOPSIS
++
++\fBtracepath\fR [\fB-n\fR] [\fB-l \fIpktlen\fB\fR] \fB\fIdestination\fB\fR [\fB\fIport\fB\fR]
++
++.SH "DESCRIPTION"
++.PP
++It traces path to \fIdestination\fR discovering MTU along this path.
++It uses UDP port \fIport\fR or some random port.
++It is similar to \fBtraceroute\fR, only does not not require superuser
++privileges and has no fancy options.
++.PP
++\fBtracepath6\fR is good replacement for \fBtraceroute6\fR
++and classic example of application of Linux error queues.
++The situation with \fBtracepath\fR is worse, because commercial
++IP routers do not return enough information in icmp error messages.
++Probably, it will change, when they will be updated.
++For now it uses Van Jacobson's trick, sweeping a range
++of UDP ports to maintain trace history.
++.SH "OPTIONS"
++.TP
++\fB-n\fR
++Do not look up host names.  Only print IP addresses numerically.
++.TP
++\fB-l\fR
++Sets the initial packet length to \fIpktlen\fR instead of
++65536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR.
++.SH "OUTPUT"
++.PP
++
++.nf
++root@mops:~ # tracepath6 3ffe:2400:0:109::2
++ 1?: [LOCALHOST]                              pmtu 1500
++ 1:  dust.inr.ac.ru                   0.411ms
++ 2:  dust.inr.ac.ru        asymm  1   0.390ms pmtu 1480
++ 2:  3ffe:2400:0:109::2               463.514ms reached
++     Resume: pmtu 1480 hops 2 back 2
++.fi
++.PP
++The first column shows TTL of the probe, followed by colon.
++Usually value of TTL is obtained from reply from network,
++but sometimes reply does not contain necessary information and
++we have to guess it. In this case the number is followed by ?.
++.PP
++The second column shows the network hop, which replied to the probe.
++It is either address of router or word [LOCALHOST], if
++the probe was not sent to the network.
++.PP
++The rest of line shows miscellaneous information about path to
++the correspinding hetwork hop. As rule it contains value of RTT.
++Additionally, it can show Path MTU, when it changes.
++If the path is asymmetric
++or the probe finishes before it reach prescribed hop, difference
++between number of hops in forward and backward direction is shown
++folloing keyword async. This information is not reliable.
++F.e. the third line shows asymmetry of 1, it is because the first probe
++with TTL of 2 was rejected at the first hop due to Path MTU Discovery.
++.PP
++Te last line summarizes information about all the path to the destination,
++it shows detected Path MTU, amount of hops to the destination and our
++guess about amount of hops from the destination to us, which can be
++different when the path is asymmetric.
++.SH "SEE ALSO"
++.PP
++\fBtraceroute\fR(8),
++\fBtraceroute6\fR(8),
++\fBping\fR(8).
++.SH "AUTHOR"
++.PP
++\fBtracepath\fR was written by
++Alexey Kuznetsov
++<kuznet@ms2.inr.ac.ru>.
++.SH "SECURITY"
++.PP
++No security issues.
++.PP
++This lapidary deserves to be elaborated.
++\fBtracepath\fR is not a privileged program, unlike
++\fBtraceroute\fR, \fBping\fR and other beasts of this kind.
++\fBtracepath\fR may be executed by everyone who has some access
++to network, enough to send UDP datagrams to investigated destination
++using given port.
++.SH "AVAILABILITY"
++.PP
++\fBtracepath\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
+diff -Naur iputils-s20071127.orig/doc/traceroute6.8 iputils-s20071127/doc/traceroute6.8
+--- iputils-s20071127.orig/doc/traceroute6.8	1969-12-31 16:00:00.000000000 -0800
++++ iputils-s20071127/doc/traceroute6.8	2009-02-18 20:53:04.000000000 -0800
+@@ -0,0 +1,42 @@
++.\" This manpage has been automatically generated by docbook2man 
++.\" from a DocBook document.  This tool can be found at:
++.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
++.\" Please send any bug reports, improvements, comments, patches, 
++.\" etc. to Steve Cheng <steve@ggi-project.org>.
++.TH "TRACEROUTE6" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
++.SH NAME
++traceroute6 \- traces path to a network host
++.SH SYNOPSIS
++
++\fBtraceroute6\fR [\fB-dnrvV\fR] [\fB-i \fIinterface\fB\fR] [\fB-m \fImax_ttl\fB\fR] [\fB-p \fIport\fB\fR] [\fB-q \fImax_probes\fB\fR] [\fB-s \fIsource\fB\fR] [\fB-w \fIwait time\fB\fR] \fB\fIdestination\fB\fR [\fB\fIsize\fB\fR]
++
++.SH "DESCRIPTION"
++.PP
++Description can be found in 
++\fBtraceroute\fR(8),
++all the references to IP replaced to IPv6. It is needless to copy
++the description from there.
++.SH "SEE ALSO"
++.PP
++\fBtraceroute\fR(8),
++\fBtracepath\fR(8),
++\fBping\fR(8).
++.SH "HISTORY"
++.PP
++This program has long history. Author of \fBtraceroute\fR
++is Van Jacobson and it first appeared in 1988. This clone is
++based on a port of \fBtraceroute\fR to IPv6 published
++in NRL IPv6 distribution in 1996. In turn, it was ported
++to Linux by Pedro Roque. After this it was kept in sync by    
++Alexey Kuznetsov
++<kuznet@ms2.inr.ac.ru>. And eventually entered
++\fBiputils\fR package.
++.SH "SECURITY"
++.PP
++\fBtracepath6\fR requires CAP_NET_RAWIO capability
++to be executed. It is safe to be used as set-uid root.
++.SH "AVAILABILITY"
++.PP
++\fBtraceroute6\fR is part of \fIiputils\fR package
++and the latest versions are  available in source form at
++http://www.skbuff.net/iputils/iputils-current.tar.bz2.
