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]