draft-ietf-mboned-mtrace-v2-02.txt   draft-ietf-mboned-mtrace-v2-03.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track T. Jinmei Intended status: Standards Track T. Jinmei
Expires: May 7, 2009 ISC Expires: September 10, 2009 ISC
W. Fenner W. Fenner
Arastra, Inc. Arastra, Inc.
S. Casner S. Casner
Packet Design, Inc. Packet Design, Inc.
November 3, 2008 March 9, 2009
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-02 draft-ietf-mboned-mtrace-v2-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes the IP multicast traceroute facility. Unlike This document describes the IP multicast traceroute facility. Unlike
unicast traceroute, multicast traceroute requires special unicast traceroute, multicast traceroute requires special
implementations on the part of routers. This specification describes implementations on the part of routers. This specification describes
the required functionality in multicast routers, as well as how the required functionality in multicast routers, as well as how
management applications can use the router functionality. management applications can use the router functionality.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . . 8 4.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . . 9
4.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . 9
5. Mtrace2 Query Header . . . . . . . . . . . . . . . . . . . . . 9 5. Mtrace2 Query Header . . . . . . . . . . . . . . . . . . . . . 10
5.1. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 9 5.1. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 10 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 10
5.3. Source Address . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Source Address . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Destination Address . . . . . . . . . . . . . . . . . . . 10 5.4. Destination Address . . . . . . . . . . . . . . . . . . . 11
5.5. Response Address . . . . . . . . . . . . . . . . . . . . . 10 5.5. Query ID: 16 bits . . . . . . . . . . . . . . . . . . . . 11
5.6. Query ID: 16 bits . . . . . . . . . . . . . . . . . . . . 10 5.6. Client Port # . . . . . . . . . . . . . . . . . . . . . . 11
5.7. Client Port # . . . . . . . . . . . . . . . . . . . . . . 10 6. IPv4 Mtrace2 Standard Response Block . . . . . . . . . . . . . 12
6. IPv4 Mtrace2 Standard Response Block . . . . . . . . . . . . . 11 6.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 12
6.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 11 6.2. Incoming Interface Address: 32 bits . . . . . . . . . . . 13
6.2. Incoming Interface Address: 32 bits . . . . . . . . . . . 12 6.3. Outgoing Interface Address: 32 bits . . . . . . . . . . . 13
6.3. Outgoing Interface Address: 32 bits . . . . . . . . . . . 12 6.4. Previous-Hop Router Address: 32 bits . . . . . . . . . . . 13
6.4. Previous-Hop Router Address: 32 bits . . . . . . . . . . . 12 6.5. Input packet count on incoming interface: 64 bits . . . . 13
6.5. Input packet count on incoming interface: 64 bits . . . . 12 6.6. Output packet count on incoming interface: 64 bits . . . . 13
6.6. Output packet count on incoming interface: 64 bits . . . . 12
6.7. Total number of packets for this source-group pair: 64 6.7. Total number of packets for this source-group pair: 64
bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.8. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 13 6.8. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 14
6.9. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 13 6.9. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 14
6.10. MBZ: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . 13 6.10. MBZ: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . 14
6.11. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.11. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.12. Src Mask: 6 bits . . . . . . . . . . . . . . . . . . . . . 13 6.12. Src Mask: 6 bits . . . . . . . . . . . . . . . . . . . . . 14
6.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 13 6.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 14
7. IPv6 Mtrace2 Standard Response Block . . . . . . . . . . . . . 16 7. IPv6 Mtrace2 Standard Response Block . . . . . . . . . . . . . 17
7.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 16 7.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 17
7.2. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 16 7.2. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 17
7.3. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 17 7.3. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 18
7.4. Local Address . . . . . . . . . . . . . . . . . . . . . . 17 7.4. Local Address . . . . . . . . . . . . . . . . . . . . . . 18
7.5. Remote Address . . . . . . . . . . . . . . . . . . . . . . 17 7.5. Remote Address . . . . . . . . . . . . . . . . . . . . . . 18
7.6. Input packet count on incoming interface . . . . . . . . . 17 7.6. Input packet count on incoming interface . . . . . . . . . 18
7.7. Output packet count on incoming interface . . . . . . . . 17 7.7. Output packet count on incoming interface . . . . . . . . 18
7.8. Total number of packets for this source-group pair . . . . 17 7.8. Total number of packets for this source-group pair . . . . 18
7.9. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 18 7.9. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 19
7.10. MBZ: 7 bits . . . . . . . . . . . . . . . . . . . . . . . 18 7.10. MBZ: 7 bits . . . . . . . . . . . . . . . . . . . . . . . 19
7.11. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.11. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.12. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 18 7.12. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 19
7.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 18 7.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 19
8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 19 8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 20
9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 20 9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 21
9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 20 9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 21
9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 20 9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 21
9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 20 9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 21
9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 21 9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 22
9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 21 9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 22
9.3. Mtrace2 Response . . . . . . . . . . . . . . . . . . . . . 22 9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 23
9.4. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 22 9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 24
9.5. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 23 9.4.1. Destination Address . . . . . . . . . . . . . . . . . 24
9.5.1. Destination Address . . . . . . . . . . . . . . . . . 23 9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 24
9.5.2. TTL and Hop Limit . . . . . . . . . . . . . . . . . . 23 9.5. Hiding Information . . . . . . . . . . . . . . . . . . . . 24
9.5.3. Source Address . . . . . . . . . . . . . . . . . . . . 23
9.5.4. Sourcing Multicast Responses . . . . . . . . . . . . . 23
9.6. Hiding Information . . . . . . . . . . . . . . . . . . . . 23
10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25 10.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25
10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 25 10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 25
10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 25 10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 25
10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 26 10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 25
10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 26 10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 26
10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 26 10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 26
10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 26 10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27
10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 27 10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 27
10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 27 10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 27
10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 27 10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 27
10.7.4. Traceroute shorter than requested . . . . . . . . . . 27 10.7.4. Traceroute shorter than requested . . . . . . . . . . 27
10.8. Continuing after an error . . . . . . . . . . . . . . . . 27 10.8. Continuing after an error . . . . . . . . . . . . . . . . 27
11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 28 11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 29
11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 28 11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 29
11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 28 11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 29
11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 30 12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 30 12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 31
12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 30 12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31
12.3. Packet loss . . . . . . . . . . . . . . . . . . . . . . . 30 12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31
12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 31 12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 32
12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 31 12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 32
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 32 13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 33
13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 32 13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 33
14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 33 14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 34
14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 33 14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 34
14.3. Unicast Replies . . . . . . . . . . . . . . . . . . . . . 33 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . . 35 16.2. Informative References . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
The unicast "traceroute" program allows the tracing of a path from The unicast "traceroute" program allows the tracing of a path from
one machine to another. The key mechanism for unicast traceroute is one machine to another. The key mechanism for unicast traceroute is
the ICMP TTL exceeded message, which is specifically precluded as a the ICMP TTL exceeded message, which is specifically precluded as a
response to multicast packets. On the other hand, the multicast response to multicast packets. On the other hand, the multicast
traceroute facility allows the tracing of an IP multicast routing traceroute facility allows the tracing of an IP multicast routing
paths. In this document, we specify the multicast "traceroute" paths. In this document, we specify the multicast "traceroute"
facility to be implemented in multicast routers and accessed by facility to be implemented in multicast routers and accessed by
skipping to change at page 7, line 16 skipping to change at page 8, line 16
Given a multicast distribution tree, tracing from a source to a Given a multicast distribution tree, tracing from a source to a
multicast destination is hard, since you don't know down which branch multicast destination is hard, since you don't know down which branch
of the multicast tree the destination lies. This means that you have of the multicast tree the destination lies. This means that you have
to flood the whole tree to find the path from one source to one to flood the whole tree to find the path from one source to one
destination. However, walking up the tree from destination to source destination. However, walking up the tree from destination to source
is easy, as most existing multicast routing protocols know the is easy, as most existing multicast routing protocols know the
previous hop for each source. Tracing from destination to source can previous hop for each source. Tracing from destination to source can
involve only routers on the direct path. involve only routers on the direct path.
The party requesting the traceroute (which need be neither the source The party requesting the traceroute sends a traceroute Query packet
nor the destination) sends a traceroute Query packet to the last-hop to the last-hop multicast router for the given destination. The
multicast router for the given destination. The last-hop router last-hop router turns the Query into a Request packet by adding a
turns the Query into a Request packet by adding a response data block response data block containing its interface addresses and packet
containing its interface addresses and packet statistics, and then statistics, and then forwards the Request packet via unicast to the
forwards the Request packet via unicast to the router that it router that it believes is the proper previous hop for the given
believes is the proper previous hop for the given source and group. source and group. Each hop adds its response data to the end of the
Each hop adds its response data to the end of the Request packet, Request packet, then unicast forwards it to the previous hop. The
then unicast forwards it to the previous hop. The first hop router first hop router (the router that believes that packets from the
(the router that believes that packets from the source originate on source originate on one of its directly connected networks) changes
one of its directly connected networks) changes the packet type to the packet type to indicate a Response packet and sends the completed
indicate a Response packet and sends the completed response to the response to the response destination address. The response may be
response destination address. The response may be returned before returned before reaching the first hop router if a fatal error
reaching the first hop router if a fatal error condition such as "no condition such as "no route" is encountered along the path.
route" is encountered along the path.
Multicast traceroute uses any information available to it in the Multicast traceroute uses any information available to it in the
router to attempt to determine a previous hop to forward the trace router to attempt to determine a previous hop to forward the trace
towards. Multicast routing protocols vary in the type and amount of towards. Multicast routing protocols vary in the type and amount of
state they keep; multicast traceroute endeavors to work with all of state they keep; multicast traceroute endeavors to work with all of
them by using whatever is available. For example, if a PIM-SM router them by using whatever is available. For example, if a PIM-SM router
is on the (*,G) tree, it chooses the parent towards the RP as the is on the (*,G) tree, it chooses the parent towards the RP as the
previous hop. In these cases, no source/group-specific state is previous hop. In these cases, no source/group-specific state is
available, but the path may still be traced. available, but the path may still be traced.
skipping to change at page 9, line 34 skipping to change at page 10, line 34
| | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
| Source Address | | Source Address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination Address | | Destination Address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query ID | Client Port # | | Query ID | Client Port # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
5.1. # hops: 8 bits 5.1. # hops: 8 bits
This field specifies the maximum number of hops that the requester This field specifies the maximum number of hops that the requester
wants to trace. If there is some error condition in the middle of wants to trace. If there is some error condition in the middle of
the path that keeps the mtrace2 request from reaching the first-hop the path that keeps the mtrace2 request from reaching the first-hop
skipping to change at page 10, line 29 skipping to change at page 11, line 22
Note that non-source-specific traceroutes may not be possible with Note that non-source-specific traceroutes may not be possible with
certain multicast routing protocols. certain multicast routing protocols.
5.4. Destination Address 5.4. Destination Address
This field specifies the 32 bits length IPv4 or 128 bits length IPv6 This field specifies the 32 bits length IPv4 or 128 bits length IPv6
address of the multicast receiver for the path being traced. The address of the multicast receiver for the path being traced. The
trace starts at this destination and proceeds toward the traffic trace starts at this destination and proceeds toward the traffic
source. source.
5.5. Response Address 5.5. Query ID: 16 bits
This field specifies 32 bits length IPv4 or 128 bits length IPv6
address to which the completed mtrace2 response packet gets sent. It
MUST be a global unicast address as explained in Section 9.2
5.6. Query ID: 16 bits
This field is used as a unique identifier for this traceroute request This field is used as a unique identifier for this traceroute request
so that duplicate or delayed responses may be detected and to so that duplicate or delayed responses may be detected and to
minimize collisions when a multicast response address is used. minimize collisions when a multicast response address is used.
5.7. Client Port # 5.6. Client Port #
Mtrace2 response is sent back to the address specified in a Response Mtrace2 response is sent back to the address specified in a Response
Address field. This field specifies the UDP port number the router Address field. This field specifies the UDP port number the router
will send Mtrace2 Response. This client port number MUST NOT be will send Mtrace2 Response. This client port number MUST NOT be
changed by any router. changed by any router.
6. IPv4 Mtrace2 Standard Response Block 6. IPv4 Mtrace2 Standard Response Block
Each intermediate IPv4 router in a trace path appends "response data Each intermediate IPv4 router in a trace path appends "response data
block" to the forwarded trace packet. The standard response data block" to the forwarded trace packet. The standard response data
skipping to change at page 13, line 18 skipping to change at page 14, line 18
and the previous-hop router. Specified values include: and the previous-hop router. Specified values include:
0 Unknown 0 Unknown
1 PIM 1 PIM
2 PIM using special routing table 2 PIM using special routing table
3 PIM using a static route 3 PIM using a static route
4 PIM using MBGP route 4 PIM using MBGP route
5 PIM using state created by Assert processing 5 PIM using state created by Assert processing
6 Bi-directional PIM 6 Bi-directional PIM
7 IGMP/MLD proxy 7 IGMP/MLD proxy
8 AMT Relay 8 AMT relay
9 AMT Gateway 9 AMT gateway
10 AMT gateway with IGMP/MLD proxy
To obtain these values, multicast routers access to To obtain these values, multicast routers access to
ipMcastRouteProtocol, ipMcastRouteRtProtocol, and ipMcastRouteRtType ipMcastRouteProtocol, ipMcastRouteRtProtocol, and ipMcastRouteRtType
in IpMcastRouteEntry specified in IPMROUTE-STD-MIB [15], and combine in IpMcastRouteEntry specified in IPMROUTE-STD-MIB [15], and combine
these MIB values to recognize above routing protocol values. these MIB values to recognize above routing protocol values.
6.9. Fwd TTL: 8 bits 6.9. Fwd TTL: 8 bits
This field contains the TTL that a packet is required to have before This field contains the TTL that a packet is required to have before
it will be forwarded over the outgoing interface. it will be forwarded over the outgoing interface.
skipping to change at page 14, line 51 skipping to change at page 16, line 6
0x0A NO_MULTICAST Mtrace2 request arrived on an interface 0x0A NO_MULTICAST Mtrace2 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 0x0B INFO_HIDDEN One or more hops have been hidden from this
trace. 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. mtrace2 requests.
0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited. 0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited.
Note that if a router discovers there is not enough room in a packet 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 previous to insert its response, it puts the NO_SPACE error code in the
router's Forwarding Code field, overwriting any error the previous previous router's Forwarding Code field, overwriting any error the
router placed there. After the router sends the response to the previous router placed there. After the router sends the response to
Response Address in the header, multicast traceroute client MAY the Destination Address in the header, the router continues the
restart the trace at the last hop listed in the packet (as described mtrace2 query by sending an mtrace2 request containing the same
in Section 9.5 and Section 10.1). [TODO: What if the Response mtrace2 query header. Section 9.3 and Section 10.8 include the
Address is not the address of mtrace2 client?] details.
The 0x80 bit of the Forwarding Code is used to indicate a fatal The 0x80 bit of the Forwarding Code is used to indicate a fatal
error. A fatal error is one where the router may know the previous error. A fatal error is one where the router may know the previous
hop but cannot forward the message to it. hop but cannot forward the message to it.
7. IPv6 Mtrace2 Standard Response Block 7. IPv6 Mtrace2 Standard Response Block
Each intermediate IPv6 router in a trace path appends "response data Each intermediate IPv6 router in a trace path appends "response data
block" to the forwarded trace packet. The standard response data block" to the forwarded trace packet. The standard response data
block looks as follows. block looks as follows.
skipping to change at page 19, line 26 skipping to change at page 20, line 26
| Type | Value .... | | Type | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The augmented response block is always appended to mtrace2 TLV header The augmented response block is always appended to mtrace2 TLV header
(0x04). The 16 bits Type filed of the augmented response block is (0x04). The 16 bits Type filed of the augmented response block is
defined for various purposees, such as diagnosis (as in Section 12) defined for various purposees, such as diagnosis (as in Section 12)
and protocol verification. The packet length of the augmented and protocol verification. The packet length of the augmented
response block is specified in the augmented response block TLV response block is specified in the augmented response block TLV
header as see in Section 4.1. header as see in Section 4.1.
[TODO: Define augmented response block types. Specify how to deal This document does not define any augmented response block type.
with diagnosis information.] Specifing how to deal with diagnosis information will be also
described in separate documents.
9. Router Behavior 9. Router Behavior
All of these actions are performed in addition to (NOT instead of) All of these actions are performed in addition to (NOT instead of)
forwarding the packet, if applicable. E.g. a multicast packet that forwarding the packet, if applicable. E.g. a multicast packet that
has TTL or the hop limit remaining MUST be forwarded normally, as has TTL or the hop limit remaining MUST be forwarded normally, as
MUST a unicast packet that has TTL or the hop limit remaining and is MUST a unicast packet that has TTL or the hop limit remaining and is
not addressed to this router. not addressed to this router.
9.1. Traceroute Query 9.1. Traceroute Query
skipping to change at page 21, line 7 skipping to change at page 22, line 7
9.2. Mtrace2 Request 9.2. Mtrace2 Request
An mtrace2 Request is a traceroute message with some number of An mtrace2 Request is a traceroute message with some number of
response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6
mtrace2. Routers can tell the difference between Queries and mtrace2. Routers can tell the difference between Queries and
Requests by checking the length of the packet. Requests by checking the length of the packet.
9.2.1. Packet Verification 9.2.1. Packet Verification
If the mtrace2 Request is not addressed to this router, or if the If the mtrace2 Request does not come from an adjacent host or router,
Request is addressed to a multicast group which is not a link-scoped it MUST be silently ignored. If the mtrace2 Request is not addressed
group (i.e. 224/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be to this router, or if the Request is addressed to a multicast group
silently ignored. which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3]
for IPv6), it MUST be silently ignored.
9.2.2. Normal Processing 9.2.2. Normal Processing
When a router receives an mtrace2 Request, it performs the following When a router receives an mtrace2 Request, it performs the following
steps. Note that it is possible to have multiple situations covered steps. Note that it is possible to have multiple situations covered
by the Forwarding Codes. The first one encountered is the one that by the Forwarding Codes. The first one encountered is the one that
is reported, i.e. all "note forwarding code N" should be interpreted is reported, i.e. all "note forwarding code N" should be interpreted
as "if forwarding code is not already set, set forwarding code to N". as "if forwarding code is not already set, set forwarding code to N".
1. If there is room in the current buffer (or the router can 1. If there is room in the current buffer (or the router can
efficiently allocate more space to use), insert a new response efficiently allocate more space to use), insert a new response
block into the packet and fill in the Query Arrival Time, block into the packet and fill in the Query Arrival Time,
Outgoing Interface Address (for IPv4 mtrace2) or Outgoing Outgoing Interface Address (for IPv4 mtrace2) or Outgoing
Interface ID (for IPv6 mtrace2), Output Packet Count, and Fwd Interface ID (for IPv6 mtrace2), Output Packet Count, and Fwd
TTL (for IPv4 mtrace2). If there was no room, fill in the TTL (for IPv4 mtrace2). If there was no room, fill in the
response code "NO_SPACE" in the *previous* hop's response block, response code "NO_SPACE" in the *previous* hop's response block,
and forward the packet to the requester as described in and forward the packet to the address specified in the
Section 9.4. Destination Address field and continue the trace as described in
Section 9.3.
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, such as "dry- state created only for the purpose of the trace, such as "dry-
run". run".
If using a shared-tree protocol and there is no source-specific If using a shared-tree protocol and there is no source-specific
state, or if the source is specified as "all 1", group state state, or if the source is specified as "all 1", group state
should be used. If there is no group state or the group is should be used. If there is no group state or the group is
specified as 0, potential source state (i.e. the path that would specified as 0, potential source state (i.e. the path that would
be followed for a source-specific Join) should be used. If this be followed for a source-specific Join) should be used. If this
router is the Core or RP and no source-specific information is router is the Core or RP and no source-specific information is
available, note an error code of REACHED_RP. available, note an error code of REACHED_RP.
3. If no forwarding information can be determined, the router notes 3. If no forwarding information can be determined, the router notes
an error code of NO_ROUTE, sets the remaining fields that have an error code of NO_ROUTE, sets the remaining fields that have
not yet been filled in to zero, and then forwards the packet to not yet been filled in to zero, and then forwards the packet to
the requester as described in Section 9.4. the requester as described in Section 9.3.
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 mtrace2 is administratively prohibited or the previous hop 5. If mtrace2 is administratively prohibited or the previous hop
router does not understand mtrace2 requests, note the router does not understand mtrace2 requests, note the
appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If
mtrace2 is administratively prohibited and any of the fields as mtrace2 is administratively prohibited and any of the fields as
filled in step 4 are considered private information, zero out filled in step 4 are considered private information, zero out
the applicable fields. Then the packet is forwarded to the the applicable fields. Then the packet is forwarded to the
requester as described in Section 9.4. requester as described in Section 9.3.
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 the forwarding code NO_MULTICAST. If the reception interface is the
interface from which the router would expect data to arrive from interface from which the router would expect data to arrive from
the source, note forwarding code RPF_IF. Otherwise, if the the source, note forwarding code RPF_IF. Otherwise, if the
reception interface is not one to which the router would forward reception interface is not one to which the router would forward
data from the source to the group, a forwarding code of WRONG_IF data from the source to the group, a forwarding code of WRONG_IF
is noted. 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
skipping to change at page 22, line 37 skipping to change at page 23, line 41
forwarding code of REACHED_RP is noted. 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
source and group in the mtrace2 Request, it notes forwarding source and group in the mtrace2 Request, it notes forwarding
code PRUNE_SENT. If the router has stopped forwarding code PRUNE_SENT. If the router has stopped forwarding
downstream in response to a prune sent by the next hop router, downstream in response to a prune sent by the next hop router,
it notes forwarding code PRUNE_RCVD. If the router should it notes forwarding code PRUNE_RCVD. If the router should
normally forward traffic for this source and group downstream normally forward traffic for this source and group downstream
but is not, it notes forwarding code NOT_FORWARDING. but is not, it notes forwarding code NOT_FORWARDING.
10. The packet is then sent on to the previous hop or the requester 10. The packet is then sent on to the previous hop or the
as described in Section 9.4. Destination Address as described in Section 9.3.
9.3. Mtrace2 Response
A router must forward all mtrace2 response packets normally, with no
special processing. If a router has initiated an mtrace2 with a
Query or Request message, it may listen for Responses to that
traceroute and MUST forward them as well.
9.4. Forwarding Mtrace2 Requests 9.3. Forwarding Mtrace2 Requests
If the Previous-hop router is known for this request and the number If the Previous-hop router is known for this request and the number
of response blocks is less than the number requested (i.e., the "# of response blocks is less than the number requested (i.e., the "#
hops" field in mtrace2 header), the packet is sent to that router. hops" field in mtrace2 header), the packet is sent to that router.
If the Incoming Interface is known but the Previous-hop router is not If the Incoming Interface is known but the Previous-hop router is not
known, the packet is sent to an appropriate multicast address on the known, the packet is sent to an appropriate multicast address on the
Incoming Interface. The appropriate multicast address may depend on Incoming Interface. The appropriate multicast address may depend on
the routing protocol in use, MUST be a link-scoped group (i.e. 224/24 the routing protocol in use, MUST be a link-scoped group (i.e. 224/24
for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET
(224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6, and (224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6, and
MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers
Address (FF02::2) for IPv6 if the routing protocol in use does not Address (FF02::2) for IPv6 if the routing protocol in use does not
define a more appropriate group. Otherwise, it is sent to the define a more appropriate group. Otherwise, it is sent to the
Response Address in the header, as described in Section 9.5. Destination Address in the header.
9.5. Sending Mtrace2 Responses
9.5.1. Destination Address
An mtrace2 response must be sent to the Response Address in the
mtrace2 header.
9.5.2. TTL and Hop Limit When the NO_SPACE error occurs, the multicast routers sends back the
mtrace2 response with contained data and the NO_SPACE error code to
the address specified in the Destination Address field in the mtrace2
query header, and continues the mtrace2 query by sending an mtrace2
request containing the same mtrace2 query header except the # hops
field and its response block. The # hops field must be decreased
according to the number of standard response blocks in the mtrace2
request received by the router.
If the Response Address is unicast, the router inserts its normal 9.4. Sending Mtrace2 Responses
unicast TTL or hop limit in the IP header. If the Response Address
is multicast, the router copies the Response TTL or hop limit from
the mtrace2 header into the IP header.
9.5.3. Source Address 9.4.1. Destination Address
If the Response Address is unicast, the router may use any of its An mtrace2 Response must be sent to the address specified in the
interface addresses as the source address. Since some multicast Destination Address field in the mtrace2 query header.
routing protocols forward based on source address, if the Response
Address is multicast, the router MUST use an address that is known in
the multicast routing topology if it can make that determination.
9.5.4. Sourcing Multicast Responses 9.4.2. Source Address
When a router sources a multicast response, the response packet MUST An mtrace2 Response must be sent with the address of the router's
be sent on a single interface, then forwarded as if it were received reception interface.
on that interface. It MUST NOT source the response packet
individually on each interface, in order to avoid duplicate packets.
9.6. Hiding Information 9.5. Hiding Information
Information about a domain's topology and connectivity may be hidden Information about a domain's topology and connectivity may be hidden
from multicast traceroute requests. The exact mechanism is not from multicast traceroute requests. The exact mechanism is not
specified here; however, the INFO_HIDDEN forwarding code may be used specified here; however, the INFO_HIDDEN forwarding code may be used
to note that, for example, the incoming interface address and packet to note that, for example, the incoming interface address and packet
count are for the entrance to the domain and the outgoing interface count are for the entrance to the domain and the outgoing interface
address and packet count are the exit from the domain. The source- address and packet count are the exit from the domain. The source-
group packet count may be from either router or not specified (all group packet count may be from either router or not specified (all
1). 1).
10. Client Behavior 10. Client Behavior
10.1. Sending Mtrace2 Query 10.1. Sending Mtrace2 Query
When the destination of the mtrace2 is the machine running the When the destination of the mtrace2 is the machine running the
client, the mtrace2 Query packet can be sent to the ALL- client, the mtrace2 Query packet can be sent to the ALL-
ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address
(FF02::2) for IPv6. This will ensure that the packet is received by (FF02::2) for IPv6. This will ensure that the packet is received by
the last-hop router on the subnet. Otherwise, if the proper last-hop the last-hop router on the subnet. Otherwise, if the proper last-hop
router is known for the mtrace2 destination, or if the mtrace2 client router is known for the mtrace2 destination, the Query could be
wants to restart mtrace2 Query from the intermediate router that unicasted to that router. Otherwise, the Query packet should be
responded with NO_SPACE in Forwarding Code of Standard Response Block multicasted to the group being queried; if the destination of the
as specified in Section 6.13, the Query could be unicasted to that mtrace2 is a member of the group, this will get the Query to the
router. Otherwise, the Query packet should be multicasted to the proper last-hop router. In this final case, the packet should
group being queried; if the destination of the mtrace2 is a member of contain the Router Alert option [7][8], to make sure that routers
the group, this will get the Query to the proper last-hop router. In that are not members of the multicast group notice the packet.
this final case, the packet should contain the Router Alert option
[7][8], to make sure that routers that are not members of the
multicast group notice the packet.
See also Section 10.4 on determining the last-hop router. See also Section 10.4 on determining the last-hop router.
10.2. Determining the Path 10.2. Determining the Path
The client could send a small number of initial query messages with a The client could send a small number of initial query messages with a
large "# hops" field, in order to try to trace the full path. If large "# hops" field, in order to try to trace the full path. If
this attempt fails, one strategy is to perform a linear search (as this attempt fails, one strategy is to perform a linear search (as
the traditional unicast traceroute program does); set the "# hops" the traditional unicast traceroute program does); set the "# hops"
field to 1 and try to get a response, then 2, and so on. If no field to 1 and try to get a response, then 2, and so on. If no
skipping to change at page 26, line 23 skipping to change at page 26, line 16
multicast. Mtrace2 requests which are multicasted to the group being multicast. Mtrace2 requests which are multicasted to the group being
traced must include the Router Alert option[7][8]. traced must include the Router Alert option[7][8].
Another alternative is to unicast to the trace destination. Mtrace2 Another alternative is to unicast to the trace destination. Mtrace2
requests which are unicasted to the trace destination must include requests which are unicasted to the trace destination must include
the Router Alert option, in order that the last-hop router is aware the Router Alert option, in order that the last-hop router is aware
of the packet. of the packet.
10.5. First Hop Router 10.5. First Hop Router
The mtrace2 querier may not be unicast reachable from the first hop
router. In this case, the querier should set the mtrace2 response
address to a multicast address, and should set the response TTL (or
hop limit) to a value sufficient for the response from the first hop
router to reach the querier. It may be appropriate to start with a
small TTL and increase in subsequent attempts until a sufficient TTL
is reached, up to an appropriate maximum (such as 192).
The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default
multicast group for IPv4 mtrace responses. However, mtrace2 does not multicast group for IPv4 mtrace responses, in order to support mtrace
reserve any IPv4/IPv6 multicast addresses for mtrace2 responses, queriers that are not unicast reachable from the first hop router.
because mtrace2 does not send its responses with multicast. However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses
for mtrace2 responses. Every mtrace2 response is sent to the unicast
address specified in the Destination Address field of the mtrace2
query header.
The mtrace2 querier may be behind a gateway (e.g., a NAT or firewall)
that blocks unicast packets. When the gateway receives mtrace2 query
from an adjacent host that is not unicast reachable, it sends back
the mtrace2 response with contained data and the NO_SPACE error code
to the address specified in the Destination Address field in the
mtrace2 query header. And to continue the mtrace2 query, the gateway
prepares the mtrace2 query containing the same mtrace2 query header,
except the # hops field, the Destination Address, and its response
block.
The # hops field must be decreased according to the number of
standard response blocks in the mtrace2 request received by the
gateway. And the original Destination Address MUST be replaced with
the gateway address that is unicast reachable from the first hop
router. After that, the gateway restarts the mtrace2 query by
sending an mtrace2 request. When the gateway receives the mtrace2
response from the last hop router, it MUST forward the mtrace2
response back to the original mtrace2 querier with the original
Destination Address in the mtrace2 query header.
10.6. Broken Intermediate Router 10.6. Broken Intermediate Router
A broken intermediate router might simply not understand mtrace2 A broken intermediate router might simply not understand mtrace2
packets, and drop them. The querier would then get no response at packets, and drop them. The querier would then get no response at
all from its mtrace2 requests. It should then perform a hop-by-hop all from its mtrace2 requests. It should then perform a hop-by-hop
search by setting the number of responses field until it gets a search by setting the number of responses field until it gets a
response (both linear and binary search are options, but binary is response (both linear and binary search are options, but binary is
likely to be slower because a failure requires waiting for a likely to be slower because a failure requires waiting for a
timeout). timeout).
skipping to change at page 27, line 29 skipping to change at page 27, line 35
to 0. to 0.
10.7.4. Traceroute shorter than requested 10.7.4. Traceroute shorter than requested
If the trace that is returned is shorter than requested (i.e. the If the trace that is returned is shorter than requested (i.e. the
number of response blocks is smaller than the "# hops" field), the number of response blocks is smaller than the "# hops" field), the
trace encountered an error and could not continue. trace encountered an error and could not continue.
10.8. Continuing after an error 10.8. Continuing after an error
When the NO_SPACE error occurs, the client might try to continue the When the NO_SPACE error occurs, as described in Section 9.3, the
trace by starting it at the last hop in the trace. It can do this by multicast routers sends back the mtrace2 response to the address
unicasting to this router's outgoing interface address, keeping all specified in the Destination Address field in the mtrace2 query
fields the same. If this results in a single hop and a "WRONG_IF" header. In this case, the mtrace2 client may receive multiple
error, the client may try setting the trace destination to the same mtrace2 responses from different routers (along the path). After the
outgoing interface address. client receives multiple mtrace2 response messages, it integrates
(i.e. constructs) them as a single mtrace2 response message.
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 entry router's address will be in the Previous Hop field of the last entry
in the last response packet received. A client may be able to in the last response packet received. A client may be able to
determine (via mrinfo or SNMP [13][15]) a list of neighbors of the determine (via mrinfo or SNMP [13][15]) a list of neighbors of the
non-responding router. If desired, each of those neighbors could be non-responding router. If desired, each of those neighbors could be
probed to determine the remainder of the path. Unfortunately, this probed to determine the remainder of the path. Unfortunately, this
heuristic may end up with multiple paths, since there is no way of heuristic may end up with multiple paths, since there is no way of
knowing what the non-responding router's algorithm for choosing a knowing what the non-responding router's algorithm for choosing a
skipping to change at page 29, line 6 skipping to change at page 30, line 6
lost an Assert battle) and know who the previous hop is (because it lost an Assert battle) and know who the previous hop is (because it
won an Assert battle). Therefore, multicast traceroute is always won an Assert battle). Therefore, multicast traceroute is always
able to follow the proper path when traffic is flowing. able to follow the proper path when traffic is flowing.
11.4. IGMP/MLD Proxy 11.4. IGMP/MLD Proxy
When a mtrace2 Query packet reaches an incoming interface of IGMP/MLD When a mtrace2 Query packet reaches an incoming interface of IGMP/MLD
Proxy [11], it put a WRONG_IF (0x01) value in Forwarding Code of Proxy [11], it put a WRONG_IF (0x01) value in Forwarding Code of
mtrace2 standard response block (as in Section 6.13) and sends the mtrace2 standard response block (as in Section 6.13) and sends the
mtrace2 response back to the Response Address. When a mtrace2 Query mtrace2 response back to the Response Address. When a mtrace2 Query
packet reaches an outgoing interface of IGMP/MLD Proxy, it is packet reaches an outgoing interface of IGMP/MLD proxy, it is
forwarded through its incoming interface towards the upstream router. forwarded through its incoming interface towards the upstream router.
11.5. AMT 11.5. AMT
AMT [12] provides the multicast connectivity to the unicast-only AMT [12] provides the multicast connectivity to the unicast-only
inter-network. To do this, multicast packets being sent to or from a inter-network. To do this, multicast packets being sent to or from a
site are encapsulated in unicast packets. When a mtrace2 Query site are encapsulated in unicast packets. When a mtrace2 query
packet reaches an AMT Pseudo-Interface of an AMT Gateway, the AMT packet reaches an AMT pseudo-interface of an AMT gateway, the AMT
Gateway encapsulats it to a particular AMT Relay reachable across the gateway encapsulats it to a particular AMT relay reachable across the
unicast-only infrastructure. unicast-only infrastructure. Then the AMT relay decapsulates the
mtrace2 query packet and forwards the mtrace2 request to the
appropriate multicast router.
12. Problem Diagnosis 12. Problem Diagnosis
12.1. Forwarding Inconsistencies 12.1. Forwarding Inconsistencies
The forwarding error code can tell if a group is unexpectedly pruned The forwarding error code can tell if a group is unexpectedly pruned
or administratively scoped. or administratively scoped.
12.2. TTL or Hop Limit Problems 12.2. TTL or Hop Limit Problems
By taking the maximum of hops (from source + forwarding TTL (or hop By taking the maximum of hops (from source + forwarding TTL (or hop
limit) threshold) over all hops, it is possible to discover the TTL limit) threshold) over all hops, it is possible to discover the TTL
or hop limit required for the source to reach the destination. or hop limit required for the source to reach the destination.
12.3. Packet loss 12.3. Packet Loss
By taking two traces, it is possible to find packet loss information By taking two traces, it is possible to find packet loss information
by comparing the difference in input packet counts to the difference by comparing the difference in input packet counts to the difference
in output packet counts for the specified source-group address pair in output packet counts for the specified source-group address pair
at the previous hop. On a point-to-point link, any difference in at the previous hop. On a point-to-point link, any difference in
these numbers implies packet loss. Since the packet counts may be these numbers implies packet loss. Since the packet counts may be
changing as the mtrace2 query is propagating, there may be small changing as the mtrace2 query is propagating, there may be small
errors (off by 1 or 2 or more) in these statistics. However, these errors (off by 1 or 2 or more) in these statistics. However, these
errors will not accumulate if multiple traces are taken to expand the errors will not accumulate if multiple traces are taken to expand the
measurement period. On a shared link, the count of input packets can measurement period. On a shared link, the count of input packets can
skipping to change at page 33, line 20 skipping to change at page 35, line 5
network topology is a secret, mtrace2 may be restricted at the border network topology is a secret, mtrace2 may be restricted at the border
of your domain, using the ADMIN_PROHIB forwarding code. of your domain, using the ADMIN_PROHIB forwarding code.
14.2. Traffic Rates 14.2. Traffic Rates
Mtrace2 can be used to discover what sources are sending to what Mtrace2 can be used to discover what sources are sending to what
groups and at what rates. If this information is a secret, mtrace2 groups and at what rates. If this information is a secret, mtrace2
may be restricted at the border of your domain, using the may be restricted at the border of your domain, using the
ADMIN_PROHIB forwarding code. ADMIN_PROHIB forwarding code.
14.3. Unicast Replies
The "Response address" field may be used to send a single packet (the
mtrace2 Reply packet) to an arbitrary unicast address. It is
possible to use this facility as a packet amplifier, as a small
multicast traceroute Query may turn into a large Reply packet.
15. Acknowledgements 15. Acknowledgements
This specification started largely as a transcription of Van This specification started largely as a transcription of Van
Jacobson's slides from the 30th IETF, and the implementation in Jacobson's slides from the 30th IETF, and the implementation in
mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve
Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original
multicast traceroute client, mtrace (version 1), has been implemented multicast traceroute client, mtrace (version 1), has been implemented
by Ajit Thyagarajan, Steve Casner and Bill Fenner. by Ajit Thyagarajan, Steve Casner and Bill Fenner.
The idea of unicasting a multicast traceroute Query to the The idea of unicasting a multicast traceroute Query to the
skipping to change at page 38, line 4 skipping to change at line 1349
US US
Email: fenner@fenron.com Email: fenner@fenron.com
Stephen L. Casner Stephen L. Casner
Packet Design, Inc. Packet Design, Inc.
Palo Alto, CA 94304 Palo Alto, CA 94304
US US
Email: casner@packetdesign.com Email: casner@packetdesign.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 43 change blocks. 
215 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/