draft-ietf-idmr-traceroute-ipm-04.txt   draft-ietf-idmr-traceroute-ipm-05.txt 
Internet Engineering Task Force Inter-Domain Multicast Routing Working Group Internet Engineering Task Force Inter-Domain Multicast Routing Working Group
INTERNET-DRAFT W. Fenner INTERNET-DRAFT W. Fenner
draft-ietf-idmr-traceroute-ipm-04.txt Xerox PARC draft-ietf-idmr-traceroute-ipm-05.txt AT&T Research
S. Casner S. Casner
Cisco Systems Cisco Systems
February 26, 1999 June 25, 1999
Expires August 1999 Expires December 1999
A "traceroute" facility for IP Multicast. A "traceroute" facility for IP Multicast.
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with all This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet Drafts are working docu- provisions of Section 10 of RFC2026. Internet Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working doc- working groups. Note that other groups may also distribute working doc-
uments as Internet-Drafts. uments as Internet-Drafts.
skipping to change at page 2, line 9 skipping to change at page 2, line 9
This document is a product of the Inter-Domain Multicast Routing working This document is a product of the Inter-Domain Multicast Routing working
group within the Internet Engineering Task Force. Comments are group within the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing list at solicited and should be addressed to the working group's mailing list at
idmr@cs.ucl.ac.uk and/or the author(s). idmr@cs.ucl.ac.uk and/or the author(s).
Key Words Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [Bradner97]. document are to be interpreted as described in RFC 2119 [Brad97].
1. Introduction 1. Introduction
The unicast "traceroute" program allows the tracing of a path from one The unicast "traceroute" program allows the tracing of a path from one
machine to another, using a mechanism that already existed in IP. machine to another, using a mechanism that already existed in IP.
Unfortunately, no such existing mechanism can be applied to IP multicast Unfortunately, no such existing mechanism can be applied to IP multicast
paths. The key mechanism for unicast traceroute is the ICMP TTL paths. The key mechanism for unicast traceroute is the ICMP TTL
exceeded message, which is specifically precluded as a response to mul- exceeded message, which is specifically precluded as a response to mul-
ticast packets. Thus, we specify the multicast "traceroute" facility to ticast packets. Thus, we specify the multicast "traceroute" facility to
be implemented in multicast routers and accessed by diagnostic programs. be implemented in multicast routers and accessed by diagnostic programs.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
keep; multicast traceroute endeavors to work with all of them by using keep; multicast traceroute endeavors to work with all of them by using
whatever is available. For example, if a DVMRP router has no active whatever is available. For example, if a DVMRP router has no active
state for a particular source but does have a DVMRP route, it chooses state for a particular source but does have a DVMRP route, it chooses
the parent of the DVMRP route as the previous hop. If a PIM-SM router the parent of the DVMRP route as the previous hop. If a PIM-SM router
is on the (*,G) tree, it chooses the parent towards the RP as the previ- is on the (*,G) tree, it chooses the parent towards the RP as the previ-
ous hop. In these cases, no source/group-specific state is available, ous hop. In these cases, no source/group-specific state is available,
but the path may still be traced. but the path may still be traced.
3. Multicast Traceroute header 3. Multicast Traceroute header
The header for all multicast traceroute packets is as follows: The header for all multicast traceroute packets is as follows. The
header is only filled in by the originator of the traceroute Query;
intermediate hops MUST NOT modify any of the fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP Type | # hops | checksum | | IGMP Type | # hops | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address | | Multicast Group Address |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 13 skipping to change at page 9, line 13
source,group,destination. source,group,destination.
0x02 PRUNE_SENT This router has sent a prune upstream which 0x02 PRUNE_SENT This router has sent a prune upstream which
applies to the source and group in the tracer- applies to the source and group in the tracer-
oute request. oute request.
0x03 PRUNE_RCVD This router has stopped forwarding for this 0x03 PRUNE_RCVD This router has stopped forwarding for this
source and group in response to a request from source and group in response to a request from
the next hop router. the next hop router.
0x04 SCOPED The group is subject to administrative scoping 0x04 SCOPED The group is subject to administrative scoping
at this hop. at this hop.
0x05 NO_ROUTE This router has no route for the source. 0x05 NO_ROUTE This router has no route for the source or
group and no way to determine a potential
route.
0x06 WRONG_LAST_HOP This router is not the proper last-hop router. 0x06 WRONG_LAST_HOP This router is not the proper last-hop router.
0x07 NOT_FORWARDING This router is not forwarding this 0x07 NOT_FORWARDING This router is not forwarding this
source,group for an unspecified reason. source,group out the outgoing interface for an
unspecified reason.
0x08 REACHED_RP Reached Rendez-vous Point or Core 0x08 REACHED_RP Reached Rendez-vous Point or Core
0x09 RPF_IF Traceroute request arrived on the expected RPF 0x09 RPF_IF Traceroute request arrived on the expected RPF
interface for this source,group. interface for this source,group.
0x0A NO_MULTICAST Traceroute request arrived on an interface 0x0A NO_MULTICAST Traceroute request arrived on an interface
which is not enabled for multicast. which is not enabled for multicast.
0x0B INFO_HIDDEN One or more hops have been hidden from this
trace.
0x81 NO_SPACE There was not enough room to insert another 0x81 NO_SPACE There was not enough room to insert another
response data block in the packet. response data block in the packet.
0x82 OLD_ROUTER The previous hop router does not understand 0x82 OLD_ROUTER The previous hop router does not understand
traceroute requests. traceroute requests.
0x83 ADMIN_PROHIB Traceroute is administratively prohibited. 0x83 ADMIN_PROHIB Traceroute is administratively prohibited.
Note that if a router discovers there is not enough room in a Note that if a router discovers there is not enough room in a
packet to insert its response, it puts the 0x81 error code in the packet to insert its response, it puts the 0x81 error code in the
previous router's Forwarding Code field, overwriting any error the previous router's Forwarding Code field, overwriting any error the
previous router placed there. It is expected that a multicast previous router placed there. It is expected that a multicast
skipping to change at page 10, line 19 skipping to change at page 10, line 24
nation address in the packet. It is the proper last-hop router if nation address in the packet. It is the proper last-hop router if
it has a multicast-capable interface on the same subnet as the Des- it has a multicast-capable interface on the same subnet as the Des-
tination Address and is the router that would forward traffic from tination Address and is the router that would forward traffic from
the given source onto that subnet. the given source onto that subnet.
If the router determines that it is not the proper last-hop router, If the router determines that it is not the proper last-hop router,
or it cannot make that determination, it does one of two things or it cannot make that determination, it does one of two things
depending if the Query was received via multicast or unicast. If depending if the Query was received via multicast or unicast. If
the Query was received via multicast, then it MUST be silently the Query was received via multicast, then it MUST be silently
dropped. If it was received via unicast, a forwarding code of dropped. If it was received via unicast, a forwarding code of
NOT_LAST_HOP is noted and processing continues as in section 6.2. WRONG_LAST_HOP is noted and processing continues as in section 6.2.
Duplicate Query messages as identified by the tuple (IP Source, Duplicate Query messages as identified by the tuple (IP Source,
Query ID) SHOULD be ignored. Query ID) SHOULD be ignored.
6.1.2. Normal Processing 6.1.2. Normal Processing
When a router receives a traceroute Query and it determines that it When a router receives a traceroute Query and it determines that it
is the proper last-hop router, it treats it like a traceroute is the proper last-hop router, it treats it like a traceroute
Request and performs the steps listed in section 6.2. Request and performs the steps listed in section 6.2.
skipping to change at page 11, line 15 skipping to change at page 11, line 18
1. Insert a new response block into the packet and fill in the 1. Insert a new response block into the packet and fill in the
Query Arrival Time, Outgoing Interface Address, Output Packet Query Arrival Time, Outgoing Interface Address, Output Packet
Count, and FwdTTL. Count, and FwdTTL.
2. Attempt to determine the forwarding information for the source 2. Attempt to determine the forwarding information for the source
and group specified, using the same mechanisms as would be used and group specified, using the same mechanisms as would be used
when a packet is received from the source destined for the when a packet is received from the source destined for the
group. State need not be instantiated, it can be "phantom" group. State need not be instantiated, it can be "phantom"
state created only for the purpose of the trace. state created only for the purpose of the trace.
3. If no forwarding information can be determined, an error code If using a shared-tree protocol and there is no source-specific
of NO_ROUTE is inserted in the Forwarding Code field, the state, or if the source is specified as 0xFFFFFFFF, group state
remaining fields that have not yet been filled in are set to should be used. If there is no group state or the group is
zero, and the packet is forwarded to the requester as described specified as 0, potential source state (i.e. the path that
in "Forwarding Traceroute Requests". would be followed for a source-specific Join) should be used.
If this router is the Core or RP and no source-specific infor-
mation is available, note an error code of REACHED_RP.
3. If no forwarding information can be determined, the router
notes an error code of NO_ROUTE, sets the remaining fields that
have not yet been filled in to zero, and the forwards the
packet to the requester as described in "Forwarding Traceroute
Requests".
4. Fill in the Incoming Interface Address, Previous-Hop Router 4. Fill in the Incoming Interface Address, Previous-Hop Router
Address, Input Packet Count, Total Number of Packets, Routing Address, Input Packet Count, Total Number of Packets, Routing
Protocol, S, and Src Mask from the forwarding information that Protocol, S, and Src Mask from the forwarding information that
was determined. was determined.
5. If traceroute is administratively prohibited or the previous 5. If traceroute is administratively prohibited or the previous
hop router does not understand traceroute requests, note the hop router does not understand traceroute requests, note the
appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If
traceroute is administratively prohibited and any of the fields traceroute is administratively prohibited and any of the fields
as filled in step 4 are considered private information, zero as filled in step 4 are considered private information, zero
out the applicable fields. Then the packet is forwarded to the out the applicable fields. Then the packet is forwarded to the
requester as described in "Forwarding Traceroute Requests". requester as described in "Forwarding Traceroute Requests".
6. If the reception interface is not enabled for multicast, note 6. If the reception interface is not enabled for multicast, note
forwarding code NO_MULTICAST. If the reception interface is forwarding code NO_MULTICAST. If the reception interface is
the interface from which the router would expect data to arrive the interface from which the router would expect data to arrive
from the source, a forwarding code of RPF_IF is noted. Other- from the source, note forwarding code RPF_IF. Otherwise, if
wise, if the reception interface is not one to which the router the reception interface is not one to which the router would
would forward data from the source, a forwarding code of forward data from the source to the group, a forwarding code of
WRONG_IF is noted. WRONG_IF is noted.
7. If the group is subject to administrative scoping on either the 7. If the group is subject to administrative scoping on either the
Outgoing or Incoming interfaces, a forwarding code of SCOPED is Outgoing or Incoming interfaces, a forwarding code of SCOPED is
noted. noted.
8. If this router is the Rendez-vous Point or Core for the group, 8. If this router is the Rendez-vous Point or Core for the group,
a forwarding code of REACHED_RP is noted. a forwarding code of REACHED_RP is noted.
9. If this router has sent a prune upstream which applies to the 9. If this router has sent a prune upstream which applies to the
skipping to change at page 13, line 21 skipping to change at page 13, line 28
in the multicast routing table if it can make that determination. in the multicast routing table if it can make that determination.
6.5.4. Sourcing Multicast Responses 6.5.4. Sourcing Multicast Responses
When a router sources a multicast response, the response packet When a router sources a multicast response, the response packet
MUST be sent on a single interface, then forwarded as if it were MUST be sent on a single interface, then forwarded as if it were
received on that interface. It MUST NOT source the response packet received on that interface. It MUST NOT source the response packet
individually on each interface, since that causes duplicate pack- individually on each interface, since that causes duplicate pack-
ets. ets.
6.6. Hiding information
Information about a domain's topology and connectivity may be hid-
den from multicast traceroute requests. The exact mechanism is not
specified here; however, the INFO_HIDDEN forwarding code may be
used to note that, for example, the incoming interface address and
packet count are for the entrance to the domain and the outgoing
interface address and packet count are the exit from the domain.
The source-group packet count may be from either router or not
specified (0xffffffff).
7. Using multicast traceroute 7. Using multicast traceroute
7.1. Sample Client 7.1. Sample Client
This section describes the behavior of an example multicast traceroute This section describes the behavior of an example multicast traceroute
client. client.
7.1.1. Sending Initial Query 7.1.1. Sending Initial Query
When the destination of the trace is the machine running the When the destination of the trace is the machine running the
skipping to change at page 16, line 11 skipping to change at page 16, line 29
the trace by starting it at the last hop in the trace. It can do the trace by starting it at the last hop in the trace. It can do
this by unicasting to this router's outgoing interface address, this by unicasting to this router's outgoing interface address,
keeping all fields the same. If this results in a single hop and a keeping all fields the same. If this results in a single hop and a
"WRONG_IF" error, the client may try setting the trace destination "WRONG_IF" error, the client may try setting the trace destination
to the same outgoing interface address. to the same outgoing interface address.
If a trace times out, it is likely to be because a router in the If a trace times out, it is likely to be because a router in the
middle of the path does not support multicast traceroute. That middle of the path does not support multicast traceroute. That
router's address will be in the Previous Hop field of the last router's address will be in the Previous Hop field of the last
entry in the last reply packet received. A client may be able to entry in the last reply packet received. A client may be able to
determine (via mrinfo[Pusa98] or SNMP[Thal98a,Thal98b]) a list of determine (via mrinfo[Pusa99] or SNMP[Thal99a,Thal99b]) a list of
neighbors of the non-responding router. If desired, each of those neighbors of the non-responding router. If desired, each of those
neighbors could be probed to determine the remainder of the path. neighbors could be probed to determine the remainder of the path.
Unfortunately, this heuristic may end up with multiple paths, since Unfortunately, this heuristic may end up with multiple paths, since
there is no way of knowing what the non-responding router's algo- there is no way of knowing what the non-responding router's algo-
rithm for choosing a previous-hop router is. However, if all paths rithm for choosing a previous-hop router is. However, if all paths
but one flow back towards the non-responding router, it is possible but one flow back towards the non-responding router, it is possible
to be sure that this is the correct path. to be sure that this is the correct path.
7.7. Multicast Traceroute and shared-tree routing protocols 7.7. Multicast Traceroute and shared-tree routing protocols
skipping to change at page 20, line 45 skipping to change at page 21, line 12
The "Response address" field may be used to send a single packet The "Response address" field may be used to send a single packet
(the traceroute Reply packet) to an arbitrary unicast address. It (the traceroute Reply packet) to an arbitrary unicast address. It
is possible to use this facility as a packet amplifier, as a small is possible to use this facility as a packet amplifier, as a small
multicast traceroute Query may turn into a large Reply packet. multicast traceroute Query may turn into a large Reply packet.
12. References 12. References
Brad88 Braden, B., D. Borman, C. Partridge, "Computing the Brad88 Braden, B., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC 1071, ISI, September 1988. Internet Checksum", RFC 1071, ISI, September 1988.
Bradner97 Bradner, S., "Key words for use in RFCs to Indicate Brad97 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119/BCP 14, Harvard University, Requirement Levels", RFC 2119/BCP 14, Harvard University,
March 1997. March 1997.
Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco Sys- Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco Sys-
tems, February 1997. tems, February 1997.
13. Authors' Addresses Pusa99 Pusateri, T., "DVMRP Version 3", work in progress, June
1999.
William C. Fenner Thal99a Thaler, D., "PIM MIB", work in progress, June 1999.
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94304
Phone: +1 650 812 4816 Thal99b Thaler, D., "DVMRP MIB", work in progress, May 1998.
Email: fenner@parc.xerox.com 13. Authors' Addresses
Stephen L. Casner William C. Fenner
Cisco Systems AT&T Labs -- Research
1072 Arastradero Road 75 Willow Rd.
Palo Alto, CA 94304 Menlo Park, CA 94025
United States
Email: fenner@research.att.com
Stephen L. Casner
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
United States
Email: casner@cisco.com Email: casner@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/