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]