MBONED Working Group                                           H. Asaeda
Internet-Draft                                           Keio University
Expires: August 30, 2007                                       T. Jinmei
                                                     Toshiba Corporation
                                                       February 26, 2007


            Mtrace6: Traceroute Facility for IPv6 Multicast
                     draft-asaeda-mboned-mtrace6-00

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Asaeda & Jinmei          Expires August 30, 2007                [Page 1]


Internet-Draft                   Mtrace6                   February 2007


Abstract

   Multicast traceroute requires a special packet type and
   implementation on the part of routers.  This document describes the
   IPv6 multicast traceroute facility.  The main aim of this document is
   to clarify the difference between IPv4 multicast traceroute [5] and
   IPv6 multicast traceroute.












































Asaeda & Jinmei          Expires August 30, 2007                [Page 2]


Internet-Draft                   Mtrace6                   February 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  IPv6 Multicast Traceroute Header . . . . . . . . . . . . . . .  6
     3.1.  ICMPv6 Type: 8 bits  . . . . . . . . . . . . . . . . . . .  7
     3.2.  # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Checksum: 16 bits  . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Reserved: 32 bits  . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Multicast Address: 128 bits  . . . . . . . . . . . . . . .  7
     3.6.  Source Address: 128 bits . . . . . . . . . . . . . . . . .  7
     3.7.  Destination Address: 128 bits  . . . . . . . . . . . . . .  7
     3.8.  Response Address: 128 bits . . . . . . . . . . . . . . . .  8
     3.9.  Resp Hop Limit: 8 bits . . . . . . . . . . . . . . . . . .  8
     3.10. Query ID: 24 bits  . . . . . . . . . . . . . . . . . . . .  8
   4.  IPv6 Multicast Traceroute Response Data  . . . . . . . . . . .  9
     4.1.  Query Arrival Time: 32 bits  . . . . . . . . . . . . . . .  9
     4.2.  Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 10
     4.3.  Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 10
     4.4.  Local Address: 128 bits  . . . . . . . . . . . . . . . . . 10
     4.5.  Remote Address: 128 bits . . . . . . . . . . . . . . . . . 10
     4.6.  Input packet count on incoming interface: 32 bits  . . . . 10
     4.7.  Output packet count on incoming interface: 32 bits . . . . 11
     4.8.  Total number of packets for this source-group pair: 32
           bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.9.  Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 11
     4.10. Fwd Hop Limit: 8 bits  . . . . . . . . . . . . . . . . . . 11
     4.11. MBZ: 7 bits  . . . . . . . . . . . . . . . . . . . . . . . 12
     4.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 12
     4.14. Forwarding Code: 8 bits  . . . . . . . . . . . . . . . . . 12
     4.15. Reserved: 24 bit . . . . . . . . . . . . . . . . . . . . . 13
   5.  Router Behavior  . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Traceroute Query . . . . . . . . . . . . . . . . . . . . . 14
     5.2.  Traceroute Request . . . . . . . . . . . . . . . . . . . . 14
     5.3.  Traceroute Response  . . . . . . . . . . . . . . . . . . . 14
     5.4.  Forwarding Traceroute Requests . . . . . . . . . . . . . . 14
     5.5.  Sending Traceroute Responses . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21





Asaeda & Jinmei          Expires August 30, 2007                [Page 3]


Internet-Draft                   Mtrace6                   February 2007


1.  Introduction

   The multicast traceroute facility allows the tracing of an IP
   multicast routing paths.  This document describes the IPv6 multicast
   traceroute facility, which is implemented in multicast routers and
   accessed by diagnostic programs.  The IPv6 multicast traceroute
   program provides additional information about packet rates and losses
   that the unicast traceroute cannot.

   IPv6 multicast traceroute (mtrace6, hereafter) traces the path that a
   packet would take from some source to some destination.  As with the
   original IPv4 multicast traceroute (mtrace, hereafter) [5] that
   enables to trace IPv4 multicast routing paths, it isolate packet loss
   problems (e.g., congestion), isolate configuration problems (e.g.,
   hop limit threshold), and minimize packets sent (e.g. no flooding, no
   implosion).

   This document aims to clarify the difference between mtrace and
   mtrace6.  The packet formats are different because of the different
   address family.  The query and response messages for mtrace6 are
   implemented as ICMPv6 messages [4], whereas the original mtrace
   messages are of IGMP messages.  And mtrace6 does not use IPv6
   addresses to designate incoming and outgoing interfaces, because an
   interface may be assigned a link-local address only [3], which cannot
   be assumed to be unique even in the node.  Hence, interface IDs are
   used in mtrace6 instead of IPv6 addresses.

   The protocol design, concept, and program behavior of mtrace6 are
   inherited from the original mtrace [5], and so is the description
   given in this document; however, if some unique points or properties
   exist in mtrace6, this document clarifies them.  Hopefully the
   specification described in this document will be incorporated into
   the original specification so that the whole description will be
   simplified without the duplicate text.

















Asaeda & Jinmei          Expires August 30, 2007                [Page 4]


Internet-Draft                   Mtrace6                   February 2007


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 [1].

   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 destination.  It is the interface on which the
   multicast traceroute 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.

   Group state:
   It is the state in which a shared-tree protocol (e.g., PIM-SM [8])
   running on a router chooses the previous-hop router toward the core
   router (or 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.

















Asaeda & Jinmei          Expires August 30, 2007                [Page 5]


Internet-Draft                   Mtrace6                   February 2007


3.  IPv6 Multicast Traceroute Header

   Mtrace6 includes the common packet header as follows.  The header is
   only filled in by the originator of the traceroute Query;
   intermediate routers MUST NOT modify any of the fields.

      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     |    # hops     |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Reserved                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                                                               *
     |                                                               |
     *                      Multicast Address                        *
     |                                                               |
     *                                                               *
     |                                                               |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                                                               |
     *                                                               *
     |                                                               |
     *                        Source Address                         *
     |                                                               |
     *                                                               *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                                                               *
     |                                                               |
     *                      Destination Address                      *
     |                                                               |
     *                                                               *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Response Address                        *
     |                                                               |
     *                                                               *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Resp Hop Limit |                  Query ID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Asaeda & Jinmei          Expires August 30, 2007                [Page 6]


Internet-Draft                   Mtrace6                   February 2007


3.1.  ICMPv6 Type: 8 bits

   The ICMPv6 type field is defined to be MTRACE6_QRYREQ (TBD (see
   Section 7)) for traceroute queries and requests.  The ICMPv6 type
   field is changed to MTRACE6_RESP (TBD) when the packet is completed
   and sent as a response from the first hop router to the querier.  Two
   codes are required so that multicast routers won't attempt to process
   a completed response in those cases where the initial query was
   issued from a router or the response is sent via multicast.

3.2.  # hops: 8 bits

   This field specifies the maximum number of hops that the requester
   wants to trace.  If there is some error condition in the middle of
   the path that keeps the traceroute request from reaching the first-
   hop router, this field can be used to perform an expanding-ring
   search to trace the path to just before the problem.

3.3.  Checksum: 16 bits

   As defined in [2], the checksum is the 16-bit one's complement of the
   one's complement sum of the entire ICMPv6 message, starting with the
   ICMPv6 message type field, and prepended with a "pseudo-header" of
   IPv6 header fields.

3.4.  Reserved: 32 bits

   Initialized to zero by the sender; ignored by receivers.

3.5.  Multicast Address: 128 bits

   This field specifies the multicast address to be traced, or zero if
   no group-specific information is desired.  Note that non-group-
   specific traceroutes may not be possible with certain multicast
   routing protocols.

3.6.  Source Address: 128 bits

   This field specifies the IPv6 address of the multicast source for the
   path being traced, or is filled with the unspecified address (::) if
   no source-specific information is desired.  Note that non-source-
   specific traceroutes may not be possible with certain multicast
   routing protocols.

3.7.  Destination Address: 128 bits

   This field specifies the IPv6 address of the multicast receiver for
   the path being traced.  The trace starts at this destination and



Asaeda & Jinmei          Expires August 30, 2007                [Page 7]


Internet-Draft                   Mtrace6                   February 2007


   proceeds toward the traffic source.

3.8.  Response Address: 128 bits

   This field specifies where the completed traceroute response packet
   gets sent.  It can be a unicast address or a multicast address, as
   explained in Section 6.2 of [5].

3.9.  Resp Hop Limit: 8 bits

   This field specifies the hop limit at which to multicast the
   response, if the response address is a multicast address.

3.10.  Query ID: 24 bits

   This field is used as a unique identifier for this traceroute request
   so that duplicate or delayed responses may be detected and to
   minimize collisions when a multicast response address is used.

































Asaeda & Jinmei          Expires August 30, 2007                [Page 8]


Internet-Draft                   Mtrace6                   February 2007


4.  IPv6 Multicast Traceroute Response Data

   Each intermediate router in a trace path appends "response data" to
   the forwarded trace packet.  The response data 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      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  | Fwd Hop Limit |     MBZ     |S|Src Prefix Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Forwarding Code|                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.  Query Arrival Time: 32 bits

   The Query Arrival Time is a 32-bit NTP timestamp specifying the
   arrival time of the traceroute request packet at this router as
   defined in [5]





Asaeda & Jinmei          Expires August 30, 2007                [Page 9]


Internet-Draft                   Mtrace6                   February 2007


4.2.  Incoming Interface ID: 32 bits

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

4.3.  Outgoing Interface ID: 32 bits

   This field specifies the interface ID on which packets from this
   source and group flow to the specified destination, or 0 if unknown.
   This field is carried in network byte order.

4.4.  Local Address: 128 bits

   This field specifies a global IPv6 address that uniquely identifies
   the router.  A unique local unicast address [6] SHOULD NOT be used
   unless the node is only assigned link-local and unique local
   addresses.  [TBD: What if the node is only assigned link-local
   addresses?  It should be very unlikely case, but is possible even for
   a properly working router.]

   Note that since interface indices used in the Incoming and Outgoing
   Interface ID fields are node-local information, a global identifier
   is needed to specify the router.

4.5.  Remote Address: 128 bits

   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.

4.6.  Input packet count on incoming interface: 32 bits

   This field contains the number of multicast packets received for all
   groups and sources on the incoming interface, or 0xffffffff if no
   count can be reported.  This counter should have the same value as



Asaeda & Jinmei          Expires August 30, 2007               [Page 10]


Internet-Draft                   Mtrace6                   February 2007


   ifInMulticastPkts from the IF-MIB for this interface.

4.7.  Output packet count on incoming interface: 32 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 0xffffffff if no count can be reported.
   This counter should have the same value as ifOutMulticastPkts from
   the IF-MIB for this interface.

4.8.  Total number of packets for this source-group pair: 32 bits

   This field counts the number of packets from the specified source
   forwarded by this router to the specified group, or 0xffffffff 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 127, indicating no source-
   specific state, the count is for all sources sending to this group.
   [TBD: This counter should have the same value defined in some sort of
   IPv6 Multicast Routing MIB?]

4.9.  Rtg Protocol: 8 bits

   This field describes the routing protocol in use between this router
   and the previous-hop router.  Specified values include:

             1    DVMRP
             2    MOSPF
             3    PIM
             4    CBT
             5    PIM using special routing table
             6    PIM using a static route
             7    DVMRP using a static route
             8    PIM using MBGP route
             9    CBT using special routing table
             10   CBT using a static route
             11   PIM using state created by Assert processing

   Although some of the routing protocols or functions are not supported
   or not used in IPv6 multicast, mtrace6 inherits all of them from
   mtrace to not cause any confusion.  [TBD: Or unneeded protocols
   should be eliminated?]

4.10.  Fwd Hop Limit: 8 bits

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




Asaeda & Jinmei          Expires August 30, 2007               [Page 11]


Internet-Draft                   Mtrace6                   February 2007


4.11.  MBZ: 7 bits

   Must be zeroed on transmission and ignored on reception.

4.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.

4.13.  Src Prefix Len: 8 bits

   This field contains the decimal number of 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)

4.14.  Forwarding Code: 8 bits

   This field contains a forwarding information/error code.  Defined
   values are as follows;

     Value   Name            Description

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

     0x00   NO_ERROR        No error

     0x01   WRONG_IF        Traceroute 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
                            traceroute 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.



Asaeda & Jinmei          Expires August 30, 2007               [Page 12]


Internet-Draft                   Mtrace6                   February 2007


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

     0x08   REACHED_RP      Reached Rendez-vous Point or Core

     0x09   RPF_IF          Traceroute request arrived on the expected
                            RPF interface for this source, group.

     0x0A   NO_MULTICAST    Traceroute request arrived on an interface
                            which is not enabled for multicast.

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

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

     0x82   OLD_ROUTER      The previous-hop router does not understand
                            traceroute requests.

     0x83   ADMIN_PROHIB    Traceroute is administratively prohibited.

   Note that if a router discovers there is not enough room in a packet
   to insert its response, it puts the 0x81 error code in the previous
   router's Forwarding Code field, overwriting any error the previous
   router placed there.  A multicast traceroute client, upon receiving
   this error, MAY restart the trace at the last hop listed in the
   packet.

   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.

4.15.  Reserved: 24 bit

   Initialized to zero by the sender; ignored by receivers.














Asaeda & Jinmei          Expires August 30, 2007               [Page 13]


Internet-Draft                   Mtrace6                   February 2007


5.  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 the hop limit remaining MUST be forwarded normally, as MUST a
   unicast packet that has the hop limit remaining and is not addressed
   to this router.

5.1.  Traceroute Query

   A traceroute Query message is a traceroute message with no response
   blocks filled in, and uses ICMPv6 type MTRACE6_QRYREQ (TBD).

5.2.  Traceroute Request

   A traceroute Request is a traceroute message with some number of
   response blocks filled in, and also uses ICMPv6 type MTRACE6_QRYREQ
   (TBD).  Routers can tell the difference between Queries and Requests
   by checking the length of the packet.

5.3.  Traceroute Response

   A router must forward all traceroute response packets normally, with
   no special processing.  If a router has initiated a traceroute with a
   Query or Request message, it may listen for Responses to that
   traceroute but MUST still forward them as well.

5.4.  Forwarding Traceroute Requests

   If the Previous-hop router is known for this request and the number
   of response blocks is less than the number requested, 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., FF02::/16 [3]), MUST NOT be
   All Nodes Address (i.e., FF02::1) and MAY be All Routers Address
   (i.e., FF02::2) if the routing protocol in use does not define a more
   appropriate group.  Otherwise, it is sent to the Response Address in
   the header, as described in Section 5.5.

   Note that it is not an error for the number of response blocks to be
   greater than the number requested; such a packet should simply be
   forwarded to the requester as described in Section 5.5.







Asaeda & Jinmei          Expires August 30, 2007               [Page 14]


Internet-Draft                   Mtrace6                   February 2007


5.5.  Sending Traceroute Responses

   A traceroute response must be sent to the Response Address in the
   traceroute header.

   If the Response Address is unicast, the router inserts its normal
   unicast hop limit in the IPv6 header, and may use any of its
   interface addresses as the source address.  If the Response Address
   is multicast, the router copies the Response hop limit from the
   traceroute header into the IPv6 header; in addition, since some
   multicast routing protocols forward based on source address, the
   router MUST use an address that is known in the multicast routing
   topology if it can make that determination.






































Asaeda & Jinmei          Expires August 30, 2007               [Page 15]


Internet-Draft                   Mtrace6                   February 2007


6.  Security Considerations

   The security consideration is the same as that of the IPv4 multicast
   traceroute [5].

   Additional security consideration TBD.













































Asaeda & Jinmei          Expires August 30, 2007               [Page 16]


Internet-Draft                   Mtrace6                   February 2007


7.  IANA Considerations

   The IANA should allocate ICMPv6 type for IPv6 multicast traceroute
   upon publication of the first RFC.  Additionally, the well-known
   multicast addresses intended for default use by IPv6 multicast
   traceroute should be registered and defined by the first RFC
   published.












































Asaeda & Jinmei          Expires August 30, 2007               [Page 17]


Internet-Draft                   Mtrace6                   February 2007


8.  Acknowledgements

   Many parts of the contents of this document were derived from the
   original mtrace document [5] as the protocol is mostly the same.  The
   authors gratefully acknowledge the original document and the authors,
   Bill Fenner and Steve Casner.













































Asaeda & Jinmei          Expires August 30, 2007               [Page 18]


Internet-Draft                   Mtrace6                   February 2007


9.  References

9.1.  Normative References

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

   [2]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [3]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [4]  Conta, A., Deering, S., and M. Gupta, "Internet Control Message
        Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
        Specification", RFC 4443, March 2006.

   [5]  Fenner, W. and S. Casner, "A "traceroute" facility for IP
        Multicast", draft-fenner-traceroute-ipm-00.txt (work in
        progress), December 2003.

9.2.  Informative References

   [6]  Draves, R. and D. Thaler, "Default Router Preferences and More-
        Specific Routes", RFC 4191, November 2005.

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

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

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















Asaeda & Jinmei          Expires August 30, 2007               [Page 19]


Internet-Draft                   Mtrace6                   February 2007


Authors' Addresses

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   Japan

   Email: asaeda@wide.ad.jp


   Tatsuya Jinmei
   Toshiba Corporation
   Corporate Research & Development Center
   Japan

   Email: jinmei@isl.rdc.toshiba.co.jp



































Asaeda & Jinmei          Expires August 30, 2007               [Page 20]


Internet-Draft                   Mtrace6                   February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Asaeda & Jinmei          Expires August 30, 2007               [Page 21]