Subject: Announcing the 5.1 release of mtrace, the multicast traceroute client.

From: Bill Fenner <[email-masked]>
Date: Thu, 19 Dec 1996 14:26:33 PST

$Id: README.mtrace,v 5.1 1996/12/19 21:53:24 fenner Exp $

	Multicast Traceroute

	Release 5.1
	December 19, 1996

	available from ftp.parc.xerox.com,
	file pub/net-research/ipmulti/mtrace5.1.tar.Z
	binaries pub/net-research/ipmulti/mtrace5.1-sparc-sunos41x.tar.Z
	         pub/net-research/ipmulti/mtrace5.1-sparc-solaris2.tar.Z
	         pub/net-research/ipmulti/mtrace5.1-alpha-osf1.tar.Z
	         pub/net-research/ipmulti/mtrace5.1-sgi-irix.tar.Z

The 5.1 release represents the divorce of the multicast traceroute tool
from the mrouted distribution.  To reduce confusion with mrouted,
mtrace needed a version number from a completely different space, so I
"arbitrarily" chose 5.

The 5.1 release fixes the following bugs:

o Workaround for "0 pps" printed for little-endian hops.  There is a
  missing parenthesis in mrouted 3.8's mtrace responder, causing half
  of a calculation to be byte-swapped and half not.  mtrace now uses
  the time the response was received instead of the timestamp in the
  packet if it detects this bug.

o TTL required is now calculated correctly.

o Wrong-type packets are properly ignored.  If multiple mtrace's are
  running on a single machine, it's possible that a DVMRP_NEIGHBORS2
  ("mrinfo") packet could have been misinterpreted as an mtrace packet,
  displaying a long trace with lots of "0.0.0.0" entries.

o "-m" traces that take less hops than requested are now handled properly.

o No longer allows magic address expansion for multicast addresses, so
  "224.100.102" is now a syntax error instead of a synonym for "224.100.102.0".

o If statistics were aborted because the route changed, don't count them
  as having been printed.

o If the last hop forgot to fill in its IP address, fill it in with the
  source address of the returned packet.

o Missing statistics detection is now more robust; it will just print
  blank lines rather than the confusing "58/58=100%" then "-58/0 = --%".

The 5.1 release has the following new features:

o Netmask printing (with -v) and default route notification

o Traces are no longer restarted from scratch when the route changes;
  they are continued from the information already known.

o The new Watch-Path mode (-P) allows an individual path to be monitored
  periodically; mtrace will print the path initially and only when it
  changes.

o Default multicast TTL changed from 64 to 127, to better match reality.

o Per-hop statistics are normally only printed as a packet-per-second count;
  there are so many bugs in the collection of these counters that the packet
  loss that they report is generally misleading.  The -T flag may be used
  to include these numbers anyway.

o Don't print statistics if there is no group specified, since the per-group
  statistics are the only ones that are meaningful.

o Change the default destination when using "-g <gwy>" to <gwy> if it is
  a different subnet than the host running mtrace.  This elminiates the need
  to use "mtrace -g foo bar foo".

o Print "[reset counters]" on a hop that has reset its counters.

o Allow the number of extra hops to be traced after a non-responding
  router to be specified with the "-e <nhops>" flag.

o Statistics collection in passive mode (slightly buggy)

o The -O flag may be used to supress use of the Router Alert IP option.
  Some versions of Cisco's IOS corrupt multicast traceroute replies when
  the request is sent with IP options, so if the last hop is a Cisco you
  may need to use -O.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 19 Dec 1996 16:55:45 PST

I made a last-minute logic error which made the source un-buildable on
systems with ANSI compilers and header files that define the __P
macro.  I have replaced mtrace5.1.tar.Z on ftp.parc.xerox.com with the
fixed version (mtrace.c will have version 5.1.1.1 in the fixed
version).  Those who fetched the source and are having trouble building
should fetch the fixed version and try again.

  Bill

(pardon me while I go catch a plane... Happy Holidays, everyone!)

---

From: Vera Volfson <[email-masked]>
Date: Fri, 24 Jan 1997 17:02:50 -0500

Hi,
I have a question about draft-ietf-idmr-traceroute-ipm-01 (5.4.3).

"If the Responce Address is multicast, the router MUST use a globally routable
address, if it has one "

What is the definition of 'globally routable address' ?

Thanks,
Vera