Subject: Re: [Gen-art] Gen-ART review ofdraft-ietf-mboned-mtrace-v2-08

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 07 Nov 2011 16:33:17 +0900 (JST)

Hello David,

Thank you for your very careful review, and sorry for very long delay
for the update.
I now believe I addressed all issues you raised for our mtrace2 draft.
Could you check the following comments and the attached revised draft
again?

Regards,
--
Hitoshi Asaeda

=====

> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments 
> you may receive.
> 
> Document: draft-ietf-mboned-mtrace-v2-08
> Reviewer: David L. Black
> Review Date: 21 July 2011
> IETF LC End Date: 19 July 2011
> 
> Summary: This draft is on the right track but has open issues, described in the review.
> 
> This draft describes version 2 of multicast traceroute.
> 
> Major Issues:
> 
> This review is late because it took me much longer than expected to
> work through this
> draft in order to figure out how the protocol works. While I believe
> that the protocol 
> does work if correctly implemented, I don't believe that the
> protocol is effectively 
> implementable from this draft, and hence significant work is required.
> 
> The open issues fall into two primary areas:
> 
> - Message Structure: Sections 4 and 5 are confusing.
> - Message Processing: The most important functionality of this
> protocol is the router processing of messages in Section 9.  I found
> numerous problems there, including significant missing pieces of the
> specification (e.g., the material on when and how to generate Reply
> messages is incomplete).

I believe all comments are now addressed in the revised draft.

> In addition there are some missing security considerations around
> traffic amplification.

Thank you for your input. I applied your text into sect.13.

> -- Message Structure --
> 
> The text in sections 4 and 5 is confusing.  The problem starts with 
> the following sentence in section 4.2:
> 
>    An mtrace2 message MUST contain exactly one Mtrace2 Query header.
> 
> Because the mtrace2 Query header is not discussed until section 5, this
> sentence is easy to misread as a requirement for exactly one Mtrace2
> Query TLV.  
> 
> It gets worse, because it turns out that the Mtrace2 Query header is actually
> the value[V] for the Query, Request and Reply TLVs.  Hence, calling
> that a Query
> header is an invitation to confusion (e.g., where are the Request and Reply
> headers?).
> 
> I suggest renaming the Mtrace2 Query header to Mtrace2 Trace header and then
> changing the above sentence to:
> 
>    An mtrace2 message MUST begin with a Query, Request or Reply TLV. The value
>    for each of these TLVs is an Mtrace2 Trace Header (see section 5).  These
>    three TLVs MUST NOT be used in any position other than the beginning of
>    a message.
> 
> That is not easy to figure out from the current text.

I applied these changes in the revised draft.
In the revised version, Mtrace header is the name of the
header. Query, Request, and Reply are the names of the type field in
TLV.

> 5.  Mtrace2 Query Header
> 
> What's the maximum size of the UDP packet?  This is important because there's
> text in Section 9 on that depends on whether another TLV fits into the message
> or not. There needs to be a minimum size, as nothing will work if there isn't
> room for at least one standard response block after the header.

In sect.4, we specified that an mtrace2 message MUST NOT be
fragmented. If an mtrace2 Request packet size exceeds the MTU of the
outgoing interface, an mtrace2 Reply is sent back to the client and a
new mtrace2 Request is continued with appropriate blocks. Sect.8.2.2
describes the all scenarios.

> How does one figure out whether the addresses in the Mtrace2 Query Header
> are IPv4 or IPv6?

In sect.4, we describe "If the mtrace2 Query or Reply arrives in an
IPv4 packet, all addresses specified in the mtrace2 messages must be
with IPv4 addresses. Same applies to IPv6."

> I suspect that at least one of the multicast address and source
> address needs to be valid (i.e., not all 1's for IPv4, not :: for
> IPv6).  That should be stated, along with what happens when both
> addresses are invalid.

We specified;
"Non-group-specific mtrace2 MUST specify valid source address and MUST
NOT all 1 nor unspecified address." in sect.4.2
and
"Non-source-specific mtrace2 MUST specify valid multicast address and
MUST NOT all 1 nor unspecified address." in sect.4.3.

> State that the client address must be valid (not all 1's for IPv4,
> not :: for IPv6).

We specified;
"Mtrace2 Client Address MUST be valid unicast address and MUST NOT all
1 nor unspecified address." in sect.4.4.

> Add the 24 bits of TLV to the packet structure diagrams in sections
> 5, 6, 7 and 8.

Done.

> Sections 6 and 7 - The IPv4 and IPv6 response blocks use the same
> TLV code (4), but have different contents and lengths.  How does the
> receiver determine which response block is present for TLV code 4? 

In section 4, we describe "If the mtrace2 Query or Reply arrives in an
IPv4 packet, all addresses specified in the mtrace2 messages MUST be
with IPv4 addresses. Same applies to IPv6."
Don't you think this is sufficient?

> Section 8 Mtrace2 Augmented Response Block
> 
>    The augmented response block is always appended to mtrace2 TLV header
>    (0x04).
> 
> No, definitely not.  Section 4.2 says that the mtrace2 TLV code for
> an augmented response block is 5, not 4.  The following would be
> better:
> 
>   The augmented response block uses TLV code 5 and always comes
>   after a standard response block TLV (code 4).

Thank you. I applied this.

> -- Message Processing --
> 
> Section 9 is confusing and incomplete.  This is the most important
> functionality in the document, and it needs to be clear to the
> reader.  I'm having a very hard time figuring out exactly what the
> router is supposed to do, and I found a number of things that are
> clearly wrong.  It is not sufficient to just fix the things noted in
> this review - Section 9 needs to be clear and cogent about exactly
> what the router does for each received message so that code can be
> written from it.

I think everything is now in Section 8.
I changed many descriptions in Section 8 and corrected them.
Please read the following replies and review sect.8 again.

> Section 9.1.1 Packet Verification
> 
>    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
>    depending if the Query was received via multicast or unicast.  If the
>    Query was received via multicast, then it MUST be silently dropped.
>    If it was received via unicast, a forwarding code of WRONG_LAST_HOP
>    is noted and processing continues as in Section 9.2.
> 
> The last sentence has a number of problems:
> - It needs to say that the TLV type in the first TLV is changed from 1 to 2,
> - Section 9.2 requires that there be a response block, but the Query
> 	message doesn't have one.
> - Section 9.2 will forward the Request towards the multicast source,
> 	even though the Query was not received by a proper last-hop router.
> 	That seems wrong.
> It would be clearer to describe how to return the WRONG_LAST_HOP error to
> the client here instead of referencing Section 9.2.

I updated sect.8.1.1 as follows;

   "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
   depending on whether the Query was received via multicast or unicast.
   If the Query was received via multicast, then it MUST be silently
   discarded.  If it was received via unicast, the router turns the
   Query into an mtrace2 Reply message by changing the TLV type to 0x03
   and appending a standard response block with a forwarding code of
   WRONG_LAST_HOP.  The other fields in the standard response block MUST
   be zeroed.  The router then sends the mtrace2 Reply message to the
   Mtrace2 Client Address and Port as specified in the Mtrace header."

>    Duplicate Query messages as identified by the tuple (Mtrace2 Client
>    Address, Query ID) SHOULD be ignored.  This MAY be implemented using
>    a simple 1-back cache (i.e. remembering the Mtrace2 Client Address
>    and Query ID of the previous Query message that was processed, and
>    ignoring future messages with the same Mtrace2 Client Address and
>    Query ID).  Duplicate Request messages MUST NOT be ignored in this
>    manner.
> 
> Is a 1-entry cache really sufficient?  What if 2 clients are trying to query
> concurrently causing their duplicate messages to be interleaved?

The revised draft simply mentions "a cache". The amount of cache
depends on the implementation.

> 9.1.2.  Normal Processing
> 
>    When a router receives an mtrace2 Query and it determines that it is
>    the proper last-hop router, it changes the TLV type to 0x2 and
>    treats it like an mtrace2 Request and performs the steps listed in
>    Section 9.2.
> 
> That's problematic - Section 9.2 requires that there be a response block,
> but there won't be one.  Unlike the error case above, this mismatch can
> probably be addressed in Section 9.2.

I believe new sect.8.2.2 addresses the issues.

> 9.2.2.  Normal Processing
> 
> Step 1 in this section is where the Request message needs to have a response
> block.  The problems with the second reference from section 9.1 to section 9.2
> might be correctable by explaining why the "If there was no room" condition
> can't occur at the router that converts a Query to a Request.  This case needs
> to be noted in the initial text in Section 9.2.

We address the issue in sect.8.2.2 as follows;

  "1.   If the mtrace2 Request packet size after appending a standard
        response block would exceed the MTU of the Outgoing Interface,
        modify the forwarding code in the *last* standard response block
        of the received mtrace2 Request packet into "NO_SPACE".  Modify
        the Mtrace header type to 0x03 in order to change it to an
	mtrace2 Reply and send the mtrace2 Reply packet back to the
        mtrace2 client as described in Section 8.3.

        Prepare an mtrace2 Request message to continue the trace from
        that router.  The Mtrace header MUST be copied from the
        received mtrace2 Query.  The router appends a standard response
        block to the Request message and appends the value of type 0x01
        augmented response block.  The value of this augmented response
        block is the number of the standard response blocks returned
        with the mtrace2 Reply to the mtrace2 client.  The router sends
        an mtrace2 Request packet containing only the Mtrace
        header, the prepared standard response block and the prepared
        augmented response block to continue processing the Request."

> Also in step 1, how does the router determine whether there is "room in the
> current buffer"?

As you see above, "If the mtrace2 Request packet size after appending
a standard response block would exceed the MTU of the Outgoing
Interface, modify the forwarding code in the *last* standard response
block of the received mtrace2 Request packet into "NO_SPACE"."

> 9.2.3.  Mtrace2 Request Received by Non-Supported Router
> 
> Describe how the client matches the ICMP message with its original Query.

All considerations regarding "non-supported routers" are mentioned in
new sect. 9.7.
On the other hand, using ICMP message is not always appropriate for
mtrace2 because non-supported routers cannot send ICMP port unreach to
the mtrace2 client when they receive mtrace2 Request messages (as the
IP dest of mtrace2 request is not the client address but the neighbor
router address). Therefore in sect.9.7 we describe;

   "However, when the router receives an mtrace2
   Request message whose destination address is the router's interface
   address, the router would return an ICMP port unreachable to an
   adjacent router that has requested the trace and cannot return to the
   mtrace2 client.  Therefore the mtrace2 client needs to terminate the
   trace when the [Mtrace Reply Timeout] timeout has occurred and may
   then issue another mtrace2 Query with the lower number of # hops."

where the [Mtrace Reply Timeout] is newly defined and its default
value is 10 sec.

> 9.3.1.  Destination Address
> 
>    If the Previous-hop router for the mtrace2 Request is known for this
>    request and the number of response blocks is less than the number
>    requested (i.e., the "# hops" field in the mtrace2 Query header), the
>    packet is sent to that router.  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 Incoming Interface.  The
>    appropriate multicast address may depend on 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 (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 Address (FF02::2) for IPv6 if the
>    routing protocol in use does not define a more appropriate group.
>    Otherwise, it is sent to the Mtrace2 Client Address in the header.
> 
> There are multiple problems with that paragraph:
> 
> 1) First line: "response blocks" is wrong.  The treatment of the augmented
> response block's count of already returned response blocks is missing.

I removed "the number of standard response blocks".

> 2) There are no instructions on what to do when the number of response
> blocks is equal to the number of hops - the Request has to be converted to
> a Reply.

I included the explanation. Please check step 12 in sect.8.2.2.

> 3) The last line sends a Request to a Client.  If that's what was intended,
> the Request first needs to be converted to a Reply.

I think this statement was wrong. I remove it.

> 9.3.2.  Source Address
> 
>    When the NO_SPACE error occurs, the router sends back the mtrace2
>    Reply with contained data and the NO_SPACE error code as in
>    Section 9.4, and continues the mtrace2 Query by sending an mtrace2
>    Request containing the same mtrace2 Query header and its standard and
>    augmented response blocks.  The corresponding augmented response
>    block type is "# Mtrace2 Response Blocks Returned" described in
>    Section 8.
> 
> There are a couple of problems with that paragraph:
> 
> 1) What does "its" mean? If it refers to the header, that would
> send all of the response blocks.  I think only this router's
> response block is sent.
> 
> 2) How does the hop count arithmetic work?  I suspect that the value for number
> of response blocks returned is counted against hop count, but that's not
> mentioned in section 9.3.1 .

I think the new sect.9.9 addresses the problems. Following is a part
of paragraphs in sect.9.9.

   "When the NO_SPACE error occurs, as described in Section 8.2, the
   multicast routers sends back the mtrace2 Reply to the address
   specified in the Mtrace2 Client Address field in the Mtrace header.
   In this case, the mtrace2 client may receive multiple mtrace2 Replies
   from different routers (along the path).  After the client receives
   multiple mtrace2 Reply messages, it integrates (i.e. constructs) them
   as a single mtrace2 Reply message."

And 8.2.2 details the procedures.

> 14.  Security Considerations
> 
> There are additional security considerations.  I can see at least two ways
> in which this protocol appears to offer opportunities for traffic
> amplification:
> 
> 1) Suppose the client's address in the Query is a multicast address; the Reply
> 	will get multicast by the router to a multicast address that the client
> 	can't reach.  Use of a multicast address as a client address
> 	should probably be prohibited.
> 
> 2) The proxying and NO_SPACE behaviors result in one Query returning multiple 
> 	Reply messages.  That's necessary for the protocol to work,
> 	but needs some control to prevent abuse.  Some sort of
> 	rate-limiting recommendations should suffice to prevent this
> 	from becoming a problem. 

Thank you. I included above concerns into new sect.13.1 and sect.13.5.

> Minor Issues:
> 
> Section 1 Introduction
> 
> The last 3 paragraphs on p.6 are not clear about how hop count
> works. The statement in the last paragraph on p.6 that a lower hop
> count can be used is not consistent with the summary descriptions in
> the previous two paragraphs that don't discuss hop count. That needs
> to be clearer. One possible approach would be:
> 
> - Add a sentence to the third to last paragraph (about generation of
> 	Request from Query) to say that the hop count in the Query is copied
> 	to the Request.
> - Add a new paragraph following that paragraph to say that when a router
> 	that is not a first-hop router receives a Request message, the router
> 	adds a standard response block  If there are fewer standard response
> 	blocks that the hop count, the Request is forwarded.  If the number
> 	of response blocks matches the hop count or an error condition
> 	such as "no route" is encountered, a Reply is generated.
> 
> There is significant overlap between sections 1 and 3 - consider
> whether they should be merged.  Of the two sections, the contents of
> Section 3 would be a better Introduction than the current section 1.

We merged section 1 and 3, and the previous section 3 are mainly used
for the new Introduction.

> Nits:
> 
> Add a definition of First-hop router to Section 2.

Done.

> idnits 2.12.12 found a bunch of problems
> 
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>   ----------------------------------------------------------------------------
> 
>   == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the
>      document.
> 
>   == There are 1 instance of lines with multicast IPv4 addresses in the
>      document.  If these are generic example addresses, they should be changed
>      to use the 233.252.0.x range defined in RFC 5771
> 
> The above 2 errors can be ignored - they FQDNs are MCAST.NET addresses that
> this draft needs to use, and the multicast IPv4 address is the IPv4 address
> for one of those FQDNs.

Ok, then can I leave them as is?

>   Miscellaneous warnings:
>   ----------------------------------------------------------------------------
> 
>   == The document seems to lack the recommended RFC 2119 boilerplate, even if
>      it appears to use RFC 2119 keywords -- however, there's a paragraph with
>      a matching beginning. Boilerplate error?

I think the revised one fixes the problem, doesn't it?

>      (The document does seem to have the reference to RFC 2119 which the
>      ID-Checklist requires).
>   -- The document date (January 7, 2011) is 195 days in the past.  Is this
>      intentional?

Just we delayed to update. So, it is Ok.

>   Checking references for intended status: Proposed Standard
>   ----------------------------------------------------------------------------
> 
>      (See RFCs 3967 and 4897 for information about using normative references
>      to lower-maturity documents in RFCs)
> 
>   == Unused Reference: '2' is defined on line 1413, but no explicit reference
>      was found in the text

Deleted.

>   == Unused Reference: '5' is defined on line 1422, but no explicit reference
>      was found in the text

Deleted.

>   ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513)

We refer RFC4291 (DS).

>   ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226)

Done.

>   ** Downref: Normative reference to an Unknown state RFC: RFC 1071 (ref. '5')
> 
>   == Outdated reference: A later version (-11) exists of
>      draft-ietf-mboned-auto-multicast-08

AMT is now out of scope of this document.

MBONED Working Group                                           H. Asaeda
Internet-Draft                                           Keio University
Intended status: Standards Track                               T. Jinmei
Expires: May 10, 2012                                                ISC
                                                               W. Fenner
                                                           Arastra, Inc.
                                                               S. Casner
                                                     Packet Design, Inc.
                                                        November 7, 2011

         Mtrace Version 2: Traceroute Facility for IP Multicast
                     draft-ietf-mboned-mtrace-v2-10

Abstract

   This document describes the IP multicast traceroute facility.  Unlike
   unicast traceroute, multicast traceroute requires special
   implementations on the part of routers.  This specification describes
   the required functionality in multicast routers, as well as how
   management applications can use the router functionality.

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 10, 2012.

Asaeda, et al.            Expires May 10, 2012                  [Page 1]

Internet-Draft                   Mtrace2                   November 2011

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Defined TLVs . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Mtrace Header  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Multicast Address  . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Source Address . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Mtrace2 Client Address . . . . . . . . . . . . . . . . . . 10
     4.5.  Query ID: 16 bits  . . . . . . . . . . . . . . . . . . . . 10
     4.6.  Client Port #  . . . . . . . . . . . . . . . . . . . . . . 10
   5.  IPv4 Mtrace2 Standard Response Block . . . . . . . . . . . . . 11
     5.1.  MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Query Arrival Time: 32 bits  . . . . . . . . . . . . . . . 11
     5.3.  Incoming Interface Address: 32 bits  . . . . . . . . . . . 12
     5.4.  Outgoing Interface Address: 32 bits  . . . . . . . . . . . 12
     5.5.  Previous-Hop Router Address: 32 bits . . . . . . . . . . . 12
     5.6.  Input packet count on incoming interface: 64 bits  . . . . 12
     5.7.  Output packet count on outgoing interface: 64 bits . . . . 13
     5.8.  Total number of packets for this source-group pair: 64
           bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.9.  Rtg Protocol: 16 bits  . . . . . . . . . . . . . . . . . . 13
     5.10. Multicast Rtg Protocol: 16 bits  . . . . . . . . . . . . . 13
     5.11. Fwd TTL: 8 bits  . . . . . . . . . . . . . . . . . . . . . 13
     5.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.13. Src Mask: 7 bits . . . . . . . . . . . . . . . . . . . . . 14
     5.14. Forwarding Code: 8 bits  . . . . . . . . . . . . . . . . . 14
   6.  IPv6 Mtrace2 Standard Response Block . . . . . . . . . . . . . 16
     6.1.  MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.2.  Query Arrival Time: 32 bits  . . . . . . . . . . . . . . . 17
     6.3.  Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 17
     6.4.  Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 17
     6.5.  Local Address  . . . . . . . . . . . . . . . . . . . . . . 17
     6.6.  Remote Address . . . . . . . . . . . . . . . . . . . . . . 17
     6.7.  Input packet count on incoming interface . . . . . . . . . 17
     6.8.  Output packet count on outgoing interface  . . . . . . . . 18
     6.9.  Total number of packets for this source-group pair . . . . 18
     6.10. Rtg Protocol: 16 bits  . . . . . . . . . . . . . . . . . . 18
     6.11. Multicast Rtg Protocol: 16 bits  . . . . . . . . . . . . . 18
     6.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 18
     6.14. Forwarding Code: 8 bits  . . . . . . . . . . . . . . . . . 18
   7.  Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 18
   8.  Router Behavior  . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Receiving Mtrace2 Query  . . . . . . . . . . . . . . . . . 19

Asaeda, et al.            Expires May 10, 2012                  [Page 2]

Internet-Draft                   Mtrace2                   November 2011

       8.1.1.  Packet Verification  . . . . . . . . . . . . . . . . . 20
       8.1.2.  Normal Processing  . . . . . . . . . . . . . . . . . . 20
     8.2.  Receiving Mtrace2 Request  . . . . . . . . . . . . . . . . 20
       8.2.1.  Packet Verification  . . . . . . . . . . . . . . . . . 20
       8.2.2.  Normal Processing  . . . . . . . . . . . . . . . . . . 21
     8.3.  Forwarding Mtrace2 Request . . . . . . . . . . . . . . . . 23
       8.3.1.  Destination Address  . . . . . . . . . . . . . . . . . 23
       8.3.2.  Source Address . . . . . . . . . . . . . . . . . . . . 23
     8.4.  Sending Mtrace2 Reply  . . . . . . . . . . . . . . . . . . 24
       8.4.1.  Destination Address  . . . . . . . . . . . . . . . . . 24
       8.4.2.  Source Address . . . . . . . . . . . . . . . . . . . . 24
     8.5.  Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . . 24
     8.6.  Hiding Information . . . . . . . . . . . . . . . . . . . . 24
   9.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Sending Mtrace2 Query  . . . . . . . . . . . . . . . . . . 25
       9.1.1.  Destination Address  . . . . . . . . . . . . . . . . . 25
       9.1.2.  Source Address . . . . . . . . . . . . . . . . . . . . 25
     9.2.  Determining the Path . . . . . . . . . . . . . . . . . . . 25
     9.3.  Collecting Statistics  . . . . . . . . . . . . . . . . . . 25
     9.4.  Last Hop Router  . . . . . . . . . . . . . . . . . . . . . 26
     9.5.  First Hop Router . . . . . . . . . . . . . . . . . . . . . 26
     9.6.  Broken Intermediate Router . . . . . . . . . . . . . . . . 26
     9.7.  Non-Supported Router . . . . . . . . . . . . . . . . . . . 26
     9.8.  Mtrace2 Termination  . . . . . . . . . . . . . . . . . . . 27
       9.8.1.  Arriving at Source . . . . . . . . . . . . . . . . . . 27
       9.8.2.  Fatal Error  . . . . . . . . . . . . . . . . . . . . . 27
       9.8.3.  No Previous Hop  . . . . . . . . . . . . . . . . . . . 27
       9.8.4.  Reply Timeout  . . . . . . . . . . . . . . . . . . . . 27
     9.9.  Continuing after an Error  . . . . . . . . . . . . . . . . 27
   10. Protocol-Specific Considerations . . . . . . . . . . . . . . . 28
     10.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 28
     10.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 29
   11. Problem Diagnosis  . . . . . . . . . . . . . . . . . . . . . . 29
     11.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 29
     11.2. TTL or Hop Limit Problems  . . . . . . . . . . . . . . . . 29
     11.3. Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 29
     11.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 30
     11.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 30
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
     12.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 30
     12.2. UDP Destination Port . . . . . . . . . . . . . . . . . . . 30
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
     13.1. Addresses in Mtrace2 Trace Header  . . . . . . . . . . . . 31
     13.2. Topology Discovery . . . . . . . . . . . . . . . . . . . . 31
     13.3. Characteristics of Multicast Channel . . . . . . . . . . . 31
     13.4. Limiting Query/Request Rates . . . . . . . . . . . . . . . 31

Asaeda, et al.            Expires May 10, 2012                  [Page 3]

Internet-Draft                   Mtrace2                   November 2011

     13.5. Limiting Reply Rates . . . . . . . . . . . . . . . . . . . 31
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     15.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34

Asaeda, et al.            Expires May 10, 2012                  [Page 4]

Internet-Draft                   Mtrace2                   November 2011

1.  Introduction

   Given a multicast distribution tree, tracing from a source to a
   multicast receiver is difficult, since you do not know down which
   branch 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 receiver.  However, walking up the tree from a receiver to a
   source is easy, as most existing multicast routing protocols know the
   previous hop for each source.  Tracing from a receiver to a source
   can involve only routers on the direct path.

   This document specifies the multicast traceroute facility named
   mtrace version 2 or mtrace2.  Mtrace2 allows the tracing of an IP
   multicast routing path.  Mtrace2 initiates a trace of a multicast
   routing path from the client toward the specified source, or if no
   source address is specified, toward a Rendezvous Point (RP)
   maintaining the specified multicast address in PIM-SM [1].  Mtrace2
   provides additional information about packet rates and losses, or
   other diagnosis information.  For instance, mtrace2 is used for the
   following purposes.

   o  To trace the path that a packet would take from a source to a
      receiver.

   o  To isolate packet loss problems (e.g., congestion).

   o  To isolate configuration problems (e.g., TTL threshold).

   The party (named mtrace2 client) requesting the multicast traceroute
   sends an mtrace2 Query packet, which is the Mtrace header specifying
   "0x1" in the type field, to the last-hop multicast router for the
   given multicast and source addresses.  The last-hop router turns the
   Query into an mtrace2 Request packet by changing the packet type of
   the Mtrace header and adding a standard response block containing its
   interface addresses and packet statistics.  It then forwards the
   Request packet via unicast to an adjacent router that the last-hop
   router believes is the proper previous hop for the given source and
   group, or via multicast when the last-hop router does not know the
   upstream router's unicast address.  Each hop adds its response data
   (i.e., a standard response block) to the end of the Request packet,
   then forwards it to the previous hop.  The first-hop router or an RP
   changes the packet type to indicate a Reply packet and sends the
   completed Reply to the mtrace2 client address specified in the Mtrace
   header.  The Reply may be returned before reaching the first-hop
   router if a fatal error condition such as "no route" is encountered
   along the path or hop count is exceeded.

   The mtrace2 client waits for the mtrace2 Reply message and displays

Asaeda, et al.            Expires May 10, 2012                  [Page 5]

Internet-Draft                   Mtrace2                   November 2011

   the results.  When an mtrace2 Reply message does not come due to
   network congestion, a broken router (see Section 9.6) or a non-
   responding router (see Section 9.7), the mtrace2 client may resend an
   mtrace2 Query with a lower hop count (see Section 4.1) and repeat the
   process until it receives an mtrace2 Reply message.

   The mtrace2 client should also be aware that the mtrace2 Query may
   follow the control path on the routers, in the case of a router's
   control plane and forwarding plane are not synchronized, e.g., a
   buggy implementation.  In this case, mtrace2 Requests will be
   forwarded toward the specified source or the RP because the router
   does not have any forwarding state for the query.

   The mtrace2 supports both IPv4 and IPv6 multicast traceroute
   facility.  While the previous IPv4 multicast traceroute, mtrace, the
   query and response messages are implemented as IGMP messages [7], all
   mtrace2 messages are carried on UDP.  The packet formats of IPv4 and
   IPv6 mtrace2 are different because of the different address families,
   but the syntax is similar.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [2].

   Since multicast traceroutes flow in the opposite direction to the
   data flow, we refer to "upstream" and "downstream" with respect to
   data, unless explicitly specified.

   Incoming interface:
   The interface on which traffic is expected from the specified source
   and group.

   Outgoing interface:
   The interface on which traffic is forwarded from the specified source
   and group toward the receiver.  It is the interface on which the
   mtrace2 Query or Request was received.

   Previous-hop router:
   The router that is on the link attached to the Incoming interface and
   is responsible for forwarding traffic for the specified source and
   group.

   First-hop router:
   The router that is directly connected to the source the mtrace2 Query
   specifies.

Asaeda, et al.            Expires May 10, 2012                  [Page 6]

Internet-Draft                   Mtrace2                   November 2011

   Last-hop router:
   The router from which traffic is forwarded to an adjacent mtrace2
   client and receives the mtrace2 Query from the mtrace2 client.

   Group state:
   It is the state in which a shared-tree protocol (e.g., PIM-SM [1])
   running on a router chooses the previous-hop router toward the
   Rendezvous Point (RP) as its parent router.  In this state, source-
   specific state is not available for the corresponding multicast
   address on the router.

   Source-specific state:
   It is the state in which a routing protocol running on a router
   chooses the path that would be followed for a source-specific join.

   ALL-[protocol]-ROUTERS.MCAST.NET:
   It is a dedicated multicast address for a multicast router to
   communicate with other routers that are working with the same routing
   protocol.  For instance, the address of ALL-PIM-ROUTERS.MCAST.NET [1]
   is '224.0.0.13' for IPv4 and 'ff02::d' for IPv6.

3.  Packet Formats

   An mtrace2 message is carried as a UDP packet.  The destination
   address of an mtrace2 Query message is either the last-hop router
   unicast address or a multicast address if the mtrace2 client does not
   know the proper last-hop router address.  The destination address of
   an mtrace2 Reply message is the address specified in Previous-Hop
   Router Address field in the last appended mtrace2 Standard Response
   Block, which is either the previous-hop router unicast address or
   multicast address.

   Mtrace2 message is encoded in TLV format.  If an implementation
   receives a TLV whose length exceeds the TLV length specified in the
   Length field, the TLV SHOULD be accepted but any additional data
   SHOULD be ignored.  If an implementation receives a TLV whose type
   value is unknown, the mtrace2 message SHOULD be ignored and silently
   discarded.

3.1.  Mtrace2 TLV format

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |           Length              |   Value ....  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Asaeda, et al.            Expires May 10, 2012                  [Page 7]

Internet-Draft                   Mtrace2                   November 2011

   Type (8 bits)

   Length (16 bits)

   Value (variable length)

3.2.  Defined TLVs

   The following TLV Types are defined:

              Code                       Type
             ======      ======================================
               1             Mtrace2 Query
               2             Mtrace2 Request
               3             Mtrace2 Reply
               4             Mtrace2 Standard Response Block
               5             Mtrace2 Augmented Response Block

   An mtrace2 message MUST begin with a Query, Request or Reply TLV.
   The value for each of these TLVs is an Mtrace header.  These three
   TLVs MUST NOT be used in any position other than the beginning of a
   message.  A multicast router that sends an mtrace2 Request message
   MUST append *one* mtrace2 Standard Response block to the given
   mtrace2 message but MUST NOT append *multiple* mtrace2 Standard
   Response blocks to it.  A multicast router that adds one mtrace2
   Standard Response block to given mtrace2 message MAY append *one or
   multiple* Augmented Response blocks.

   The TLV type field is defined to be "0x1" and "0x2" for mtrace2
   Queries and Requests, respectively.  An mtrace2 message containing
   the type "0x1" is an mtrace2 Query.  It is sent by an mtrace2 client.
   It is changed to "0x2" by the proper last-hop router.  The type field
   is changed to "0x3" when the packet is sent as an mtrace2 Reply from
   a router to the mtrace2 client.

4.  Mtrace Header

   The mtrace2 supports both IPv4 and IPv6.  If the mtrace2 Query or
   Reply arrives in an IPv4 packet, all addresses specified in the
   mtrace2 messages MUST be with IPv4 addresses.  Same applies to IPv6.

   An mtrace2 message is carried as a UDP packet, which MUST NOT be
   fragmented.  The UDP source port is uniquely selected by the local
   host operating system.  The UDP destination port is the IANA reserved
   mtrace2 port number (see Section 12).  The UDP checksum MUST be valid
   in mtrace2 messages.

Asaeda, et al.            Expires May 10, 2012                  [Page 8]

Internet-Draft                   Mtrace2                   November 2011

   The mtrace2 message includes the common Mtrace header as follows.
   The header originated by an mtrace2 client initiates the mtrace2
   Query; intermediate routers MUST NOT modify any of the fields except
   the Type field.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |           Length              |    # hops     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                      Multicast Address                        |
     |                                                               |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                                                               |
     |                        Source Address                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                    Mtrace2 Client Address                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Query ID            |        Client Port #        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

4.1.  # hops: 8 bits

   This field specifies the maximum number of hops that the mtrace2
   client wants to trace.  If there is some error condition in the
   middle of the path that prevents an mtrace2 Reply from being received
   by the client, the client issues another mtrace2 Query with the lower
   number of hops until it receives a Reply from the first-hop router.

4.2.  Multicast Address

   This field specifies the 32 bits length IPv4 or 128 bits length IPv6
   multicast address to be traced, or is filled with "all 1" in case of
   IPv4 or with the unspecified address (::) in case of IPv6 if no
   group-specific information is desired.  Non-group-specific mtrace2
   MUST specify valid source address and MUST NOT all 1 nor unspecified
   address.

4.3.  Source Address

   This field specifies the 32 bits length IPv4 or 128 bits length IPv6
   address of the multicast source for the path being traced, or is

Asaeda, et al.            Expires May 10, 2012                  [Page 9]

Internet-Draft                   Mtrace2                   November 2011

   filled with "all 1" in case of IPv4 or with the unspecified address
   (::) in case of IPv6 if no source-specific information such as a
   trace for RPT in PIM-SM is desired.  Note that non-source-specific
   traceroutes may not be possible with certain multicast routing
   protocols.  Non-source-specific mtrace2 MUST specify valid multicast
   address and MUST NOT all 1 nor unspecified address.

4.4.  Mtrace2 Client Address

   This field specifies the 32 bits length IPv4 or 128 bits length IPv6
   global address of the mtrace2 client.  The trace starts at this
   client address and proceeds toward the traffic source.  Mtrace2
   Client Address MUST be valid unicast address and MUST NOT all 1 nor
   unspecified address.

4.5.  Query ID: 16 bits

   This field is used as a unique identifier for this mtrace2 Query so
   that duplicate or delayed Replies may be detected.

4.6.  Client Port #

   Mtrace2 Reply is sent back to the address specified in an Mtrace2
   Client Address field.  This field specifies the UDP port number the
   router will send Mtrace2 Reply.

Asaeda, et al.            Expires May 10, 2012                 [Page 10]

Internet-Draft                   Mtrace2                   November 2011

5.  IPv4 Mtrace2 Standard Response Block

   Each intermediate IPv4 router in a trace path appends "response data
   block" to the forwarded mtrace2 packet.  The standard response block
   looks as follows.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |           Length              |      MBZ      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Query Arrival Time                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Incoming Interface Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Outgoing Interface Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Previous-Hop Router Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .           Input packet count on incoming interface            .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .           Output packet count on outgoing interface           .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .      Total number of packets for this source-group pair       .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Rtg Protocol         |    Multicast Rtg Protocol     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Fwd TTL    |      MBZ      |S|   Src Mask  |Forwarding Code|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.  MBZ: 8 bit

   Must be zeroed on transmission and ignored on reception.

5.2.  Query Arrival Time: 32 bits

   The Query Arrival Time is a 32-bit NTP timestamp specifying the
   arrival time of the mtrace2 Request packet at this router.  The 32-
   bit form of an NTP timestamp consists of the middle 32 bits of the
   full 64-bit form; that is, the low 16 bits of the integer part and
   the high 16 bits of the fractional part.

Asaeda, et al.            Expires May 10, 2012                 [Page 11]

Internet-Draft                   Mtrace2                   November 2011

   The following formula converts from a UNIX timeval to a 32-bit NTP
   timestamp:

      query_arrival_time
      = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625)

   The constant 32384 is the number of seconds from Jan 1, 1900 to Jan
   1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a
   reduction of ((tv.tv_usec / 100000000) << 16).

   However, mtrace2 does not require synchronizing NTP timestamp among
   all routers along paths to measure one-way latency.  The use of Query
   Arrival Time is useful to measure the packets per second (PPS).
   Suppose that a client issues two queries Q1 and Q2, and the
   corresponding requests R1 and R2 arrive at router X at t1 and t2,
   then the client would be able to calculate the PPS at router X by
   using the packet count results at t1 and t2.

5.3.  Incoming Interface Address: 32 bits

   This field specifies the address of the interface on which packets
   from the source and the group are expected to arrive, or 0 if unknown
   or unnumbered.

5.4.  Outgoing Interface Address: 32 bits

   This field specifies the address of the interface on which packets
   from the source-and-group pair flow to the specified destination, or
   0 if unknown or unnumbered.

5.5.  Previous-Hop Router Address: 32 bits

   This field specifies the router from which this router expects
   packets from this source.  This may be a multicast group (e.g.  ALL-
   [protocol]-ROUTERS.MCAST.NET) if the previous hop is not known
   because of the workings of the multicast routing protocol.  However,
   it should be 0 if the incoming interface address is unknown or
   unnumbered.

5.6.  Input packet count on incoming interface: 64 bits

   This field contains the number of multicast packets received for all
   groups and sources on the incoming interface, or "all 1" if no count
   can be reported.  This counter may have the same value as
   ifHCInMulticastPkts from the IF-MIB [8] for this interface.

Asaeda, et al.            Expires May 10, 2012                 [Page 12]

Internet-Draft                   Mtrace2                   November 2011

5.7.  Output packet count on outgoing interface: 64 bits

   This field contains the number of multicast packets that have been
   transmitted or queued for transmission for all groups and sources on
   the outgoing interface, or "all 1" if no count can be reported.  This
   counter may have the same value as ifHCOutMulticastPkts from the IF-
   MIB for this interface.

5.8.  Total number of packets for this source-group pair: 64 bits

   This field counts the number of packets from the specified source
   forwarded by the router to the specified group, or "all 1" if no
   count can be reported.  If the S bit is set, the count is for the
   source network, as specified by the Src Mask field.  If the S bit is
   set and the Src Mask field is 63, indicating no source-specific
   state, the count is for all sources sending to this group.  This
   counter should have the same value as ipMcastRoutePkts from the
   IPMROUTE-STD-MIB [9] for this forwarding entry.

5.9.  Rtg Protocol: 16 bits

   This field describes the routing protocol used to decide an RPF
   interface for the requested source.  This value should have the same
   value as ipMcastRouteRtProtocol from the IPMROUTE-STD-MIB [9] for
   this entry.  If the router is not able to obtain this value, "all 0"
   must be specified.

5.10.  Multicast Rtg Protocol: 16 bits

   This field describes the multicast routing protocol in use between
   the router and the previous-hop router.  This value should have the
   same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [9] for
   this entry.  If the router is not able to obtain this value, "all 0"
   must be specified.

5.11.  Fwd TTL: 8 bits

   This field contains the TTL that a packet is required to have before
   it will be forwarded over the outgoing interface.

5.12.  S: 1 bit

   This S bit indicates that the packet count for the source-group pair
   is for the source network, as determined by masking the source
   address with the Src Mask field.

Asaeda, et al.            Expires May 10, 2012                 [Page 13]

Internet-Draft                   Mtrace2                   November 2011

5.13.  Src Mask: 7 bits

   This field contains the number of 1's in the netmask the router has
   for the source (i.e. a value of 24 means the netmask is 0xffffff00).
   If the router is forwarding solely on group state, this field is set
   to 127 (0x7f).

5.14.  Forwarding Code: 8 bits

   This field contains a forwarding information/error code.  Section 8.1
   and Section 8.2 explain how and when the forwarding code is filled.
   Defined values are as follows;

     Value   Name            Description

     -----  --------------  -------------------------------------------

     0x00   NO_ERROR        No error

     0x01   WRONG_IF        Mtrace2 Request arrived on an interface
                            to which this router would not forward for
                            this source, group, destination.

     0x02   PRUNE_SENT      This router has sent a prune upstream which
                            applies to the source and group in the
                            mtrace2 Request.

     0x03   PRUNE_RCVD      This router has stopped forwarding for this
                            source and group in response to a request
                            from the next hop router.

     0x04   SCOPED          The group is subject to administrative
                            scoping at this hop.

     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.

     0x07   NOT_FORWARDING  This router is not forwarding this source,
                            group out the outgoing interface for an
                            unspecified reason.

     0x08   REACHED_RP      Reached Rendezvous Point

     0x09   RPF_IF          Mtrace2 Request arrived on the expected

Asaeda, et al.            Expires May 10, 2012                 [Page 14]

Internet-Draft                   Mtrace2                   November 2011

                            RPF interface for this source and group.

     0x0A   NO_MULTICAST    Mtrace2 Request arrived on an interface
                            which is not enabled for multicast.

     0x0B   INFO_HIDDEN     One or more hops have been hidden from this
                            trace.

     0x0C   REACHED_GW      Mtrace2 Request arrived on a gateway (e.g.,
                            a NAT or firewall) that hides the
                            information between this router and the
                            mtrace2 client.

     0x0D   HOP_LIMIT       Mtrace2 Request reaches hop limit.

     0x81   NO_SPACE        There was not enough room to insert another
                            response data block in the packet.

     0x82   ADMIN_PROHIB    Mtrace2 is administratively prohibited.

   Note that if a router discovers there is not enough room in a packet
   to insert its response, it puts the NO_SPACE code value in the
   previous router's Forwarding Code field, overwriting any error the
   previous router placed there.  After the router sends the Reply to
   the Mtrace2 Client Address in the header, the router continues the
   trace by sending an mtrace2 Request containing the same Mtrace
   header.  Section 8.2 and Section 9.9 include the details.

   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
   hop but cannot forward the message to it.

Asaeda, et al.            Expires May 10, 2012                 [Page 15]

Internet-Draft                   Mtrace2                   November 2011

6.  IPv6 Mtrace2 Standard Response Block

   Each intermediate IPv6 router in a trace path appends "response data
   block" to the forwarded mtrace2 packet.  The standard response block
   looks as follows.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |           Length              |      MBZ      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Query Arrival Time                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Incoming Interface ID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Outgoing Interface ID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                         Local Address                         *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                         Remote Address                        *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .           Input packet count on incoming interface            .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .           Output packet count on outgoing interface           .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .      Total number of packets for this source-group pair       .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Rtg Protocol         |    Multicast Rtg Protocol     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              MBZ            |S|Src Prefix Len |Forwarding Code|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.1.  MBZ: 8 bit

   Must be zeroed on transmission and ignored on reception.

Asaeda, et al.            Expires May 10, 2012                 [Page 16]

Internet-Draft                   Mtrace2                   November 2011

6.2.  Query Arrival Time: 32 bits

   Same definition described in Section 5.2

6.3.  Incoming Interface ID: 32 bits

   This field specifies the interface ID on which packets from the
   source and the group are expected to arrive, or 0 if unknown.  This
   ID should be the value taken from InterfaceIndex of the IF-MIB [8]
   for this interface.

6.4.  Outgoing Interface ID: 32 bits

   This field specifies the interface ID on which packets from the
   source-and-group pair flow to the specified destination, or 0 if
   unknown.  This ID should be the value taken from InterfaceIndex of
   the IF-MIB for this interface.

6.5.  Local Address

   This field specifies a global IPv6 address that uniquely identifies
   the router.  A unique local unicast address [10] SHOULD NOT be used
   unless the router is only assigned link-local and unique local
   addresses.  If the router is only assigned link-local addresses, its
   link-local address can be specified in this field.

6.6.  Remote Address

   This field specifies the address of the previous-hop router, which,
   in most cases, is a link-local unicast address for the queried source
   and destination addresses.

   Although a link-local address does not have enough information to
   identify a node, it is possible to detect the previous-hop router
   with the assistance of Incoming Interface ID and the current router
   address (i.e., Local Address).

   This may be a multicast group (e.g., ALL-[protocol]-
   ROUTERS.MCAST.NET) if the previous hop is not known because of the
   workings of the multicast routing protocol.  However, it should be
   the unspecified address (::) if the incoming interface address is
   unknown.

6.7.  Input packet count on incoming interface

   Same definition described in Section 5.6

Asaeda, et al.            Expires May 10, 2012                 [Page 17]

Internet-Draft                   Mtrace2                   November 2011

6.8.  Output packet count on outgoing interface

   Same definition described in Section 5.7

6.9.  Total number of packets for this source-group pair

   This field counts the number of packets from the specified source
   forwarded by this router to the specified group, or "all 1" if no
   count can be reported.  If the S bit is set, the count is for the
   source network, as specified by the Src Prefix Len field.  If the S
   bit is set and the Src Prefix Len field is 255, indicating no source-
   specific state, the count is for all sources sending to this group.
   This counter should have the same value as ipMcastRoutePkts from the
   IPMROUTE-STD-MIB for this forwarding entry.

6.10.  Rtg Protocol: 16 bits

   Same definition described in Section 5.9

6.11.  Multicast Rtg Protocol: 16 bits

   Same definition described in Section 5.10

6.12.  S: 1 bit

   This S bit indicates that the packet count for the source-group pair
   is for the source network, as determined by masking the source
   address with the Src Prefix Len field.

6.13.  Src Prefix Len: 8 bits

   This field contains the prefix length this router has for the source.
   If the router is forwarding solely on group state, this field is set
   to 255 (0xff)

6.14.  Forwarding Code: 8 bits

   Same definition described in Section 5.14

7.  Mtrace2 Augmented Response Block

   In addition to the standard response block, a multicast router on the
   path will be able to add "augmented response block" when it sends the
   mtrace2 Request to its upstream router or sends the Reply to the
   Mtrace2 Client Address.  This augmented response block is flexible
   for adding various information.

Asaeda, et al.            Expires May 10, 2012                 [Page 18]

Internet-Draft                   Mtrace2                   November 2011

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |           Length              |      MBZ      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |           Value ....          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The augmented response block uses TLV code 5 and always comes after a
   standard response block TLV (code 4).  The 16 bits Type filed of the
   augmented response block is defined for various purposes, such as
   diagnosis (as in Section 11) and protocol verification.  The packet
   length of the augmented response block is specified in the augmented
   response block TLV header as seen in Section 3.1.

   The following augmented response block type is defined:

         Code                           Type
        ======    =================================================
         0x01        # Mtrace2 Standard Response Blocks Returned

   When the NO_SPACE error occurs, the router sends back the mtrace2
   Reply with contained data (i.e., all appended response blocks), and
   continues the mtrace2 Query by sending an mtrace2 Request as will be
   described in Section 8.2.  In this mtrace2 Request, the router
   appends the augmented response block with the code "0x01" and the
   number of returned mtrace2 response blocks.  Every router between
   this router and the first-hop router can recognize the limit number
   of hops by referring this number and the # hops in the header.

   This document only defines the above augmented response block type
   and does not define other augmented response block types.  Specifying
   how to deal with diagnosis information will be also described in
   separate documents.

8.  Router Behavior

   All of these actions are performed in addition to (NOT instead of)
   forwarding the packet, if applicable.  E.g. a multicast packet that
   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
   not addressed to this router.

8.1.  Receiving Mtrace2 Query

   An mtrace2 Query message is an mtrace2 message with no response
   blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 mtrace2.

Asaeda, et al.            Expires May 10, 2012                 [Page 19]

Internet-Draft                   Mtrace2                   November 2011

8.1.1.  Packet Verification

   Upon receiving an mtrace2 Query message, a router must examine
   whether the Mtrace2 Client Address is a valid IP unicast address.  If
   the Mtrace2 Client Address is an invalid unicast address or not an
   address in the same network, the Query MUST be silently ignored.

   The router must then examine the Query to see if it is the proper
   last-hop router for the destination address in the packet.  It is the
   proper last-hop router if it has a multicast-capable interface on the
   same subnet as the Mtrace2 Client Address and is the router that
   would forward traffic from the given (S,G) or (*,G) onto that subnet.

   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
   depending on whether the Query was received via multicast or unicast.
   If the Query was received via multicast, then it MUST be silently
   discarded.  If it was received via unicast, the router turns the
   Query into an mtrace2 Reply message by changing the TLV type to 0x03
   and appending a standard response block with a forwarding code of
   WRONG_LAST_HOP.  The other fields in the standard response block MUST
   be zeroed.  The router then sends the mtrace2 Reply message to the
   Mtrace2 Client Address and Port as specified in the Mtrace header.

   Duplicate Query messages as identified by the tuple (Mtrace2 Client
   Address, Query ID) SHOULD be ignored.  This MAY be implemented using
   a cache of the Mtrace2 Client Address and Query ID pair of the
   several Query messages that were processed.  Duplicate Request
   messages MUST NOT be ignored in this manner.

8.1.2.  Normal Processing

   When a router receives an mtrace2 Query and it determines that it is
   the proper last-hop router, it changes the TLV type to 0x2 and treats
   it like an mtrace2 Request and performs the steps listed in
   Section 8.2.

8.2.  Receiving Mtrace2 Request

   An mtrace2 Request is an mtrace2 message with some number of response
   blocks filled in, and uses TLV type 0x2 for IPv4 and IPv6 mtrace2.

8.2.1.  Packet Verification

   If the mtrace2 Request does not come from an adjacent router, it MUST
   be silently ignored.  If the mtrace2 Request is not addressed to this
   router, or if the Request is addressed to a multicast group which is
   not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3] for

Asaeda, et al.            Expires May 10, 2012                 [Page 20]

Internet-Draft                   Mtrace2                   November 2011

   IPv6), it MUST be silently ignored.  GTSM [11] SHOULD be used by the
   router to determine whether the router is adjacent or not.

8.2.2.  Normal Processing

   When a router receives an mtrace2 Request, it performs the following
   steps.  Note that it is possible to have multiple situations covered
   by the Forwarding Codes.  The first one encountered is the one that
   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".

   1.   If the mtrace2 Request packet size after appending a standard
        response block would exceed the MTU of the Outgoing Interface,
        modify the forwarding code in the *last* standard response block
        of the received mtrace2 Request packet into "NO_SPACE".  Modify
        the Mtrace header type to 0x03 in order to change it to an
        mtrace2 Reply and send the mtrace2 Reply packet back to the
        mtrace2 client as described in Section 8.4.

        Prepare an mtrace2 Request message to continue the trace from
        that router.  The Mtrace header MUST be copied from the received
        mtrace2 Query.  The router appends a standard response block to
        the Request message and appends the value of type 0x01 augmented
        response block.  The value of this augmented response block is
        the number of the standard response blocks returned with the
        mtrace2 Reply to the mtrace2 client.  The router sends an
        mtrace2 Request packet containing only the Mtrace header, the
        prepared standard response block and the prepared augmented
        response block to continue processing the Request.

   2.   Prepare a standard response block to be appended to the packet
        and fill in the Query Arrival Time, Outgoing Interface Address
        (for IPv4 mtrace2) or Outgoing Interface ID (for IPv6 mtrace2),
        Output Packet Count, and Fwd TTL (for IPv4 mtrace2).  Append the
        prepared type 0x01 augmented response block to the prepared
        standard response block if needed.

   3.   Attempt to determine the forwarding information for the source
        and group specified, using the same mechanisms as would be used
        when a packet is received from the source destined for the
        group.  A state need not be instantiated, it can be a "phantom"
        state created only for the purpose of the trace, such as "dry-
        run".

        If using a shared-tree protocol and there is no source-specific
        state, or if no source-specific information is desired (i.e.,
        "all 1" for IPv4 or unspecified address (::) for IPv6), group
        state should be used.  If there is no group state or no group-

Asaeda, et al.            Expires May 10, 2012                 [Page 21]

Internet-Draft                   Mtrace2                   November 2011

        specific information is desired, potential source state (i.e.,
        the path that would be followed for a source-specific Join)
        should be used.

   4.   If no forwarding information can be determined, the router notes
        a forwarding code of NO_ROUTE, sets the remaining fields that
        have not yet been filled in to zero, and then sends an mtrace2
        Reply.

   5.   Fill in the Incoming Interface Address, Previous-Hop Router
        Address, Input Packet Count, Total Number of Packets, Routing
        Protocol, S, and Src Mask from the forwarding information
        determined by step 3.

   6.   If mtrace2 is administratively prohibited, note the forwarding
        code ADMIN_PROHIB.  If mtrace2 is administratively prohibited
        and any of the fields as filled in step 5 are considered private
        information, zero out the applicable fields.

   7.   If the reception interface is not enabled for multicast, note
        forwarding code NO_MULTICAST.  If the reception interface is the
        interface from which the router would expect data to arrive from
        the source, note forwarding code RPF_IF.  Otherwise, if the
        reception interface is not one to which the router would forward
        data from the source to the group, a forwarding code of WRONG_IF
        is noted.  The router returns an mtrace2 Reply in all three
        cases.

   8.   If the group is subject to administrative scoping on either the
        Outgoing or Incoming interfaces, a forwarding code of SCOPED is
        noted.

   9.   If this router is the Rendezvous Point and no source-specific
        state is available (e.g., this router has been receiving PIM
        Register messages from the first-hop router), note a code of
        REACHED_RP.  The router returns an mtrace2 Reply.

   10.  If this router has sent a prune upstream which applies to the
        source and group in the mtrace2 Request, it notes forwarding
        code PRUNE_SENT.  If the router has stopped forwarding
        downstream in response to a prune sent by the next hop router,
        it notes forwarding code PRUNE_RCVD.  If the router should
        normally forward traffic for this source and group downstream
        but is not, it notes forwarding code NOT_FORWARDING.

   11.  If this router is a gateway (e.g., a NAT or firewall) that hides
        the information between this router and the mtrace2 client, it
        notes forwarding code REACHED_GW.  The router continues the

Asaeda, et al.            Expires May 10, 2012                 [Page 22]

Internet-Draft                   Mtrace2                   November 2011

        processing as described in Section 8.5.

   12.  If an mtrace2 Request reaches the # hops specified in the Mtrace
        header (i.e., if the total number of the standard response
        blocks and the value in type 0x01 augmented response block in
        the received mtrace2 Request is equal to the value in the # hops
        field in the Mtrace header), the router MUST stop the trace and
        sends back the mtrace2 Reply with forwarding code HOP_LIMIT.  If
        the total number of the standard response blocks and the value
        in type 0x01 augmented response block in the received mtrace2
        Request is more than the value in the # hops field in the Mtrace
        header, the router MUST silently discard the Request.

   13.  The packet is then sent on to the previous hop as described in
        Section 8.3 if the total number of the standard response blocks,
        including the newly prepared one, and the value in type 0x01
        augmented response block in the received mtrace2 Request is less
        than the value in the # hops field in the Mtrace header.
        Otherwise, the packet is sent as an mtrace2 Reply to the mtrace2
        Client Address as described in Section 8.4.

8.3.  Forwarding Mtrace2 Request

8.3.1.  Destination Address

   If the Previous-hop router for the mtrace2 Request is known for this
   request, the mtrace2 Request is sent to that router.  If the Incoming
   Interface is known but the Previous-hop router is not known, the
   mtrace2 Request is sent to an appropriate multicast address on the
   Incoming Interface.  The appropriate multicast address SHOULD depend
   on the routing protocol in use, such as ALL-[protocol]-
   ROUTERS.MCAST.NET.  It MUST be a link-scoped group (i.e. 224/24 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
   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
   define a more appropriate multicast address.

8.3.2.  Source Address

   An mtrace2 Request should be sent with the address of the router's
   reception interface.  However, if the router's interface address is
   unnumbered, the router can use one of its numbered interface address
   as the source address.

Asaeda, et al.            Expires May 10, 2012                 [Page 23]

Internet-Draft                   Mtrace2                   November 2011

8.4.  Sending Mtrace2 Reply

8.4.1.  Destination Address

   An mtrace2 Reply MUST be sent to the address specified in the Mtrace2
   Client Address field in the Mtrace header.

8.4.2.  Source Address

   An mtrace2 Reply SHOULD be sent with the address of the router's
   reception interface.  However, if the router's interface address is
   unnumbered, the router can use one of its numbered interface address
   as the source address.

8.5.  Proxying Mtrace2 Query

   When a gateway (e.g., a NAT or firewall) that needs to block unicast
   packets to the mtrace2 client or hide information between the gateway
   and the mtrace2 client receives mtrace2 Query from an adjacent host
   or mtrace2 Request from an adjacent router, it sends back the mtrace2
   Reply with contained data and the REACHED_GW code to the address
   specified in the Mtrace2 Client Address field in the Mtrace header.

   At the same time, the gateway prepares a new mtrace2 Query message.
   The gateway copies the original Mtrace header for the new mtrace2
   Query, but changes the some original values as follows; it sets the
   Mtrace2 Client Address to its Incoming Interface address and the
   Client Port # to its own port (which may be the same as the mtrace2
   port as the gateway is listening on that port), and decreases # hops
   according to the number of standard response blocks in the returned
   mtrace2 Reply from the gateway.  The mtrace2 Query message is sent to
   the previous-hop router or to an appropriate multicast address on the
   Incoming Interface.

   When the gateway receives the mtrace2 Reply from the first-hop router
   or any intermediate router, it MUST forward the mtrace2 Reply back to
   the mtrace2 client with replacing the received Mtrace header to the
   original Mtrace header.  If the gateway does not receive the
   corresponding mtrace2 Reply within the [Mtrace Reply Timeout] period,
   whose default value is 10 seconds (see Section 9.8.4), then it
   silently discards the cached mtrace2 Query message and terminates the
   trace.

8.6.  Hiding Information

   Information about a domain's topology and connectivity may be hidden
   from mtrace2 Requests.  The INFO_HIDDEN forwarding code may be used
   to note that, for example, the incoming interface address and packet

Asaeda, et al.            Expires May 10, 2012                 [Page 24]

Internet-Draft                   Mtrace2                   November 2011

   count are for the entrance to the domain and the outgoing interface
   address and packet count are the exit from the domain by specifying
   "all 1".  The source-group packet count (Section 5.8 and Section 6.9)
   is from router, but may be "all 1" if it is hidden.

9.  Client Behavior

9.1.  Sending Mtrace2 Query

9.1.1.  Destination Address

   If an mtrace2 client know the proper last-hop router, mtrace2 Query
   packet is unicasted to that router.  If it does not know the proper
   last-hop router, mtrace2 Query packet can be sent to the ALL-
   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
   the last-hop router on the subnet.

   See also Section 9.4 on determining the last-hop router.

9.1.2.  Source Address

   An mtrace2 Query MUST be sent with the valid unicast address of the
   mtrace2 client's reception interface, which would be the Mtrace2
   Client Address.

9.2.  Determining the Path

   An mtrace2 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 this attempt fails, one strategy is to perform a linear search (as
   the traditional unicast traceroute program does); set the "# hops"
   field to 1 and try to get a Reply, then 2, and so on.  If no Reply is
   received at a certain hop, the hop count can continue past the non-
   responding hop, in the hopes that further hops may respond.  These
   attempts should continue until the [Mtrace Reply Timeout] timeout has
   occurred.

   See also Section 9.6 on receiving the results of a trace.

9.3.  Collecting Statistics

   After a client has determined that it has traced the whole path or as
   much as it can expect to (see Section 9.8), it might collect
   statistics by waiting a short time and performing a second trace.  If
   the path is the same in the two traces, statistics can be displayed
   as described in Section 11.3 and Section 11.4.

Asaeda, et al.            Expires May 10, 2012                 [Page 25]

Internet-Draft                   Mtrace2                   November 2011

9.4.  Last Hop Router

   The mtrace2 client may not know which is the last-hop router, or that
   router may be behind a firewall that blocks unicast packets but
   passes multicast packets.  In these cases, the mtrace2 Request should
   be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All
   Routers Address (FF02::2) for IPv6.  All routers except the correct
   last-hop router SHOULD ignore any mtrace2 Request received via
   multicast.

9.5.  First Hop Router

   The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default
   multicast group for old IPv4 mtrace (v1) responses, in order to
   support mtrace clients that are not unicast reachable from the first-
   hop router.  However, mtrace2 does not reserve any IPv4/IPv6
   multicast addresses for mtrace2 Replies.  Every mtrace2 Reply is sent
   to the unicast address specified in the Mtrace2 Client Address field
   of the Mtrace header.

9.6.  Broken Intermediate Router

   A broken intermediate router might simply not understand mtrace2
   packets, and drop them.  The mtrace2 client would then get no mtrace2
   Reply at all from its mtrace2 Requests.  It should then perform a
   hop-by-hop search by setting the number of hops field until it gets
   an mtrace2 Reply (both linear and binary search are options, but
   binary is likely to be slower because a failure requires waiting for
   the [Mtrace Reply Timeout] period).

9.7.  Non-Supported Router

   When a router that does not support mtrace2 receives an mtrace2 Query
   or Request message whose destination address is multicast, the router
   will silently discard the message.  When the router receives an
   mtrace2 Query message whose destination address is the router's
   interface address, the router would return an ICMP port unreachable
   to the mtrace2 client.  However, when the router receives an mtrace2
   Request message whose destination address is the router's interface
   address, the router would return an ICMP port unreachable to an
   adjacent router that has requested the trace and cannot return to the
   mtrace2 client.  Therefore, the mtrace2 client needs to terminate the
   trace when the [Mtrace Reply Timeout] timeout has occurred and may
   then issue another mtrace2 Query with the lower number of # hops.

Asaeda, et al.            Expires May 10, 2012                 [Page 26]

Internet-Draft                   Mtrace2                   November 2011

9.8.  Mtrace2 Termination

   When performing an expanding hop-by-hop trace, it is necessary to
   determine when to stop expanding.

9.8.1.  Arriving at Source

   A trace can be determined to have arrived at the source if the
   Incoming Interface of the last router in the trace is non-zero, but
   the Previous-hop router is zero.

9.8.2.  Fatal Error

   A trace has encountered a fatal error if the last Forwarding Error in
   the trace has the 0x80 bit set.

9.8.3.  No Previous Hop

   A trace can not continue if the last Previous-hop in the trace is set
   to 0.

9.8.4.  Reply Timeout

   This document defines the [Mtrace Reply Timeout] value, which is used
   to time out an mtrace2 Reply as seen in Section 8.5, Section 9.2, and
   Section 9.7.  The default [Mtrace Reply Timeout] value is 10
   (seconds) and can be manually changed in the mtrace2 client and
   router programs.

9.9.  Continuing after an Error

   When the NO_SPACE error occurs, as described in Section 8.2, the
   multicast routers sends back the mtrace2 Reply to the address
   specified in the Mtrace2 Client Address field in the Mtrace header.
   In this case, the mtrace2 client may receive multiple mtrace2 Replies
   from different routers (along the path).  After the client receives
   multiple mtrace2 Reply messages, it integrates (i.e. constructs) them
   as a single mtrace2 Reply message.

   If a trace times out, it is likely to be because a router in the
   middle of the path does not support mtrace2.  That router's address
   will be in the Previous-hop router field of the last entry in the
   last response packet received.  A client may be able to determine
   (via mrinfo or SNMP [10][9]) a list of neighbors of the non-
   responding router.  If desired, each of those neighbors could be
   probed to determine the remainder of the path.  Unfortunately, this
   heuristic may end up with multiple paths, since there is no way of
   knowing what the non-responding router's algorithm for choosing a

Asaeda, et al.            Expires May 10, 2012                 [Page 27]

Internet-Draft                   Mtrace2                   November 2011

   previous-hop router is.  However, if all paths but one flow back
   towards the non-responding router, it is possible to be sure that
   this is the correct path.

10.  Protocol-Specific Considerations

10.1.  PIM-SM

   When an mtrace2 reaches a PIM-SM RP and the RP does not forward the
   trace on, it means that the RP has not performed a source-specific
   join so there is no more state to trace.  However, the path that
   traffic would use if the RP did perform a source-specific join can be
   traced by setting the trace destination to the RP, the trace source
   to the traffic source, and the trace group to 0.  This mtrace2 Query
   may be unicasted to the RP.

10.2.  Bi-Directional PIM

   Bi-directional PIM [4] is a variant of PIM-SM that builds bi-
   directional shared trees connecting multicast sources and receivers.
   Along the bi-directional shared trees, multicast data is natively
   forwarded from sources to the RPA (Rendezvous Point Address) and from
   the RPA to receivers without requiring source-specific state.  In
   contrast to PIM-SM, RP always has the state to trace.

   A Designated Forwarder (DF) for a given RPA is in charge of
   forwarding downstream traffic onto its link, and forwarding upstream
   traffic from its link towards the RPL (Rendezvous Point Link) that
   the RPA belongs to.  Hence mtrace2 Reply reports DF addresses or RPA
   along the path.

10.3.  PIM-DM

   Routers running PIM Dense Mode [12] do not know the path packets
   would take unless traffic is flowing.  Without some extra protocol
   mechanism, this means that in an environment with multiple possible
   paths with branch points on shared media, mtrace2 can only trace
   existing paths, not potential paths.  When there are multiple
   possible paths but the branch points are not on shared media, the
   previous hop router is known, but the last-hop router may not know
   that it is the appropriate last hop.

   When traffic is flowing, PIM Dense Mode routers know whether or not
   they are the last-hop forwarder for the link (because they won or
   lost an Assert battle) and know who the previous hop is (because it
   won an Assert battle).  Therefore, mtrace2 is always able to follow
   the proper path when traffic is flowing.

Asaeda, et al.            Expires May 10, 2012                 [Page 28]

Internet-Draft                   Mtrace2                   November 2011

10.4.  IGMP/MLD Proxy

   When an mtrace2 Query packet reaches an incoming interface of IGMP/
   MLD Proxy [5], it puts a WRONG_IF (0x01) value in Forwarding Code of
   mtrace2 standard response block (as in Section 5.14) and sends the
   mtrace2 Reply back to the Mtrace2 Client Address.  When an mtrace2
   Query packet reaches an outgoing interface of IGMP/MLD proxy, it is
   forwarded through its incoming interface towards the upstream router.

11.  Problem Diagnosis

11.1.  Forwarding Inconsistencies

   The forwarding error code can tell if a group is unexpectedly pruned
   or administratively scoped.

11.2.  TTL or Hop Limit Problems

   By taking the maximum of hops (from source + forwarding TTL (or hop
   limit) threshold) over all hops, it is possible to discover the TTL
   or hop limit required for the source to reach the destination.

11.3.  Packet Loss

   By taking two traces, it is possible to find packet loss information
   by comparing the difference in input packet counts to the difference
   in output packet counts for the specified source-group address pair
   at the previous hop.  On a point-to-point link, any difference in
   these numbers implies packet loss.  Since the packet counts may be
   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 will not accumulate if multiple traces are taken to expand the
   measurement period.  On a shared link, the count of input packets can
   be larger than the number of output packets at the previous hop, due
   to other routers or hosts on the link injecting packets.  This
   appears as "negative loss" which may mask real packet loss.

   In addition to the counts of input and output packets for all
   multicast traffic on the interfaces, the response data includes a
   count of the packets forwarded by a node for the specified source-
   group pair.  Taking the difference in this count between two traces
   and then comparing those differences between two hops gives a measure
   of packet loss just for traffic from the specified source to the
   specified receiver via the specified group.  This measure is not
   affected by shared links.

   On a point-to-point link that is a multicast tunnel, packet loss is

Asaeda, et al.            Expires May 10, 2012                 [Page 29]

Internet-Draft                   Mtrace2                   November 2011

   usually due to congestion in unicast routers along the path of that
   tunnel.  On native multicast links, loss is more likely in the output
   queue of one hop, perhaps due to priority dropping, or in the input
   queue at the next hop.  The counters in the response data do not
   allow these cases to be distinguished.  Differences in packet counts
   between the incoming and outgoing interfaces on one node cannot
   generally be used to measure queue overflow in the node.

11.4.  Link Utilization

   Again, with two traces, you can divide the difference in the input or
   output packet counts at some hop by the difference in time stamps
   from the same hop to obtain the packet rate over the link.  If the
   average packet size is known, then the link utilization can also be
   estimated to see whether packet loss may be due to the rate limit or
   the physical capacity on a particular link being exceeded.

11.5.  Time Delay

   If the routers have synchronized clocks, it is possible to estimate
   propagation and queuing delay from the differences between the
   timestamps at successive hops.  However, this delay includes control
   processing overhead, so is not necessarily indicative of the delay
   that data traffic would experience.

12.  IANA Considerations

   The following new assignments can only be made via a Standards Action
   as specified in [6].

12.1.  Forwarding Codes

   New forwarding codes must only be created by an RFC that modifies
   this document's Section 5.14, fully describing the conditions under
   which the new forwarding code is used.  The IANA may act as a central
   repository so that there is a single place to look up forwarding
   codes and the document in which they are defined.

12.2.  UDP Destination Port

   The IANA should allocate UDP destination port for multicast
   traceroute version 2 (mtrace2) upon publication of the first RFC.

13.  Security Considerations

Asaeda, et al.            Expires May 10, 2012                 [Page 30]

Internet-Draft                   Mtrace2                   November 2011

13.1.  Addresses in Mtrace2 Trace Header

   An Mtrace header includes three addresses, source address, multicast
   address, and mtrace2 client address.  These addresses MUST be
   congruent with the definition defined in Section 4 and forwarding
   mtrace2 messages having invalid addresses MUST be prohibited.  For
   instance, if Mtrace2 Client Address specified in an Mtrace header is
   a multicast address, then a router that receives the mtrace2 message
   MUST silently discard it.

13.2.  Topology Discovery

   Mtrace2 can be used to discover any actively-used topology.  If your
   network topology is a secret, mtrace2 may be restricted at the border
   of your domain, using the ADMIN_PROHIB forwarding code.

13.3.  Characteristics of Multicast Channel

   Mtrace2 can be used to discover what sources are sending to what
   groups and at what rates.  If this information is a secret, mtrace2
   may be restricted at the border of your domain, using the
   ADMIN_PROHIB forwarding code.

13.4.  Limiting Query/Request Rates

   Routers should limit mtrace2 Queries and Requests by ignoring the
   received messages.  Routers MAY randomly ignore the received messages
   to minimize the processing overhead, i.e., to keep fairness in
   processing queries.  The rate limit is left to the router's
   implementation.

13.5.  Limiting Reply Rates

   The proxying and NO_SPACE behaviors may result in one Query returning
   multiple Reply messages.  However, routers MAY need to control to
   prevent abuse.  Some sort of rate-limiting recommendations should
   suffice to prevent a problem, whereas the rate limit function is left
   to the router's implementation.

14.  Acknowledgements

   This specification started largely as a transcription of Van
   Jacobson's slides from the 30th IETF, and the implementation in
   mrouted 3.3 by Ajit Thyagarajan.  Van's original slides credit Steve
   Casner, Steve Deering, Dino Farinacci and Deb Agrawal.  The original
   multicast traceroute client, mtrace (version 1), has been implemented
   by Ajit Thyagarajan, Steve Casner and Bill Fenner.  The idea of the

Asaeda, et al.            Expires May 10, 2012                 [Page 31]

Internet-Draft                   Mtrace2                   November 2011

   "S" bit to allow statistics for a source subnet is due to Tom
   Pusateri.

   For the mtrace version 2 specification, extensive comments were
   received from David L. Black, Ronald Bonica, Yiqun Cai, Liu Hui,
   Bharat Joshi, Heidi Ou, Pekka Savola, Shinsuke Suzuki, Dave Thaler,
   Achmad Husni Thamrin, and Cao Wei.

15.  References

15.1.  Normative References

   [1]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
         "Protocol Independent Multicast - Sparse Mode (PIM-SM):
         Protocol Specification (Revised)", RFC 4601, August 2006.

   [2]   Bradner, S., "Key words for use in RFCs to indicate requirement
         levels", RFC 2119, March 1997.

   [3]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.

   [4]   Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
         "Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
         RFC 5015, October 2007.

   [5]   Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
         Group Management Protocol (IGMP) / Multicast Listener Discovery
         (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
         RFC 4605, August 2006.

   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", RFC 5226, May 2008.

15.2.  Informative References

   [7]   Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
         Thyagarajan, "Internet Group Management Protocol, Version 3",
         RFC 3376, October 2002.

   [8]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
         RFC 2863, June 2000.

   [9]   McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB",
         RFC 5132, December 2007.

   [10]  Draves, R. and D. Thaler, "Default Router Preferences and More-

Asaeda, et al.            Expires May 10, 2012                 [Page 32]

Internet-Draft                   Mtrace2                   November 2011

         Specific Routes", RFC 4191, November 2005.

   [11]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro,
         "The Generalized TTL Security Mechanism (GTSM)", RFC 5082,
         October 2007.

   [12]  Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent
         Multicast - Dense Mode (PIM-DM): Protocol Specification
         (Revised)", RFC 3973, January 2005.

Authors' Addresses

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   Fujisawa, Kanagawa  252-0882
   Japan

   Email: [email-masked]
   URI:   http://www.sfc.wide.ad.jp/~asaeda/

   Tatuya Jinmei
   Internet Systems Consortium
   Redwood City, CA  94063
   US

   Email: [email-masked]

   William C. Fenner
   Arastra, Inc.
   Menlo Park, CA  94025
   US

   Email: [email-masked]

   Stephen L. Casner
   Packet Design, Inc.
   Palo Alto, CA  94304
   US

   Email: [email-masked]

Asaeda, et al.            Expires May 10, 2012                 [Page 33]

Internet-Draft                   Mtrace2                   November 2011

Full Copyright Statement

   Copyright (C) The IETF Trust (2011).

   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
   [email-masked].

Asaeda, et al.            Expires May 10, 2012                 [Page 34]