draft-ietf-mboned-mtrace-v2-03.txt   draft-ietf-mboned-mtrace-v2-04.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track T. Jinmei Intended status: Standards Track T. Jinmei
Expires: September 10, 2009 ISC Expires: January 14, 2010 ISC
W. Fenner W. Fenner
Arastra, Inc. Arastra, Inc.
S. Casner S. Casner
Packet Design, Inc. Packet Design, Inc.
March 9, 2009 July 13, 2009
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-03 draft-ietf-mboned-mtrace-v2-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
7.12. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 19 7.12. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 19
7.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 19 7.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 19
8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 20 8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 20
9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 21 9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 21
9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 21 9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 21
9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 21 9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 21
9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 21 9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 21
9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 22 9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 22
9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 22 9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 22
9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 23 9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 24
9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 24 9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 24
9.4.1. Destination Address . . . . . . . . . . . . . . . . . 24 9.4.1. Destination Address . . . . . . . . . . . . . . . . . 24
9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 24 9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 24
9.5. Hiding Information . . . . . . . . . . . . . . . . . . . . 24 9.5. Proxying Mtrace2 Queries . . . . . . . . . . . . . . . . . 24
10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 9.6. Hiding Information . . . . . . . . . . . . . . . . . . . . 25
10.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25 10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 26
10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 25 10.1. Sending Mtrace2 Queries . . . . . . . . . . . . . . . . . 26
10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 25 10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 26
10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 25 10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 26
10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 26 10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 26
10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 26 10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 27
10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 27
10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27 10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27
10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 27 10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 27
10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 27 10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 27
10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 27 10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 27
10.7.4. Traceroute shorter than requested . . . . . . . . . . 27 10.7.4. Traceroute shorter than requested . . . . . . . . . . 28
10.8. Continuing after an error . . . . . . . . . . . . . . . . 27 10.8. Continuing after an error . . . . . . . . . . . . . . . . 28
11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 29 11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 29
11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 29 11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 29
11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 29 11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 29
11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31 12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 31 12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 31
12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31 12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31
12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31 12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31
12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 32 12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 32
12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 32 12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 32
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 33 13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 33
13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 33 13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 33
14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 34 14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 34
14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 34 14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 34
14.3. Limiting Query/Request Rates . . . . . . . . . . . . . . . 34
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The unicast "traceroute" program allows the tracing of a path from The unicast "traceroute" program allows the tracing of a path from
one machine to another. The key mechanism for unicast traceroute is one machine to another. The key mechanism for unicast traceroute is
the ICMP TTL exceeded message, which is specifically precluded as a the ICMP TTL exceeded message, which is specifically precluded as a
response to multicast packets. On the other hand, the multicast response to multicast packets. On the other hand, the multicast
traceroute facility allows the tracing of an IP multicast routing traceroute facility allows the tracing of an IP multicast routing
paths. In this document, we specify the multicast "traceroute" paths. In this document, we specify the multicast "traceroute"
skipping to change at page 6, line 33 skipping to change at page 6, line 33
o. To be able to isolate configuration problems (e.g., TTL o. To be able to isolate configuration problems (e.g., TTL
threshold). threshold).
o. To minimize packets sent (e.g. no flooding, no implosion). o. To minimize packets sent (e.g. no flooding, no implosion).
This document supports both IPv4 and IPv6 multicast traceroute This document supports both IPv4 and IPv6 multicast traceroute
facility. The protocol design, concept, and program behavior are facility. The protocol design, concept, and program behavior are
same between IPv4 and IPv6 mtrace2. While the original IPv4 same between IPv4 and IPv6 mtrace2. While the original IPv4
multicast traceroute, mtrace, the query and response messages are multicast traceroute, mtrace, the query and response messages are
implemented as IGMP messages [4], all mtrace2 messages are carried on implemented as IGMP messages [12], all mtrace2 messages are carried
UDP. The packet formats of IPv4 and IPv6 mtrace2 are different on UDP. The packet formats of IPv4 and IPv6 mtrace2 are different
because of the different address families, but the syntax is similar. because of the different address families, but the syntax is similar.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1]. this document are to be interpreted as described in RFC 2119 [1].
Since multicast traceroutes flow in the opposite direction to the Since multicast traceroutes flow in the opposite direction to the
data flow, we refer to "upstream" and "downstream" with respect to data flow, we refer to "upstream" and "downstream" with respect to
skipping to change at page 7, line 30 skipping to change at page 7, line 30
The interface on which traffic is forwarded from the specified source The interface on which traffic is forwarded from the specified source
and group toward the destination. It is the interface on which the and group toward the destination. It is the interface on which the
multicast traceroute Request was received. multicast traceroute Request was received.
Previous-hop router: Previous-hop router:
The router that is on the link attached to the Incoming Interface and The router that is on the link attached to the Incoming Interface and
is responsible for forwarding traffic for the specified source and is responsible for forwarding traffic for the specified source and
group. group.
Group state: Group state:
It is the state in which a shared-tree protocol (e.g., PIM-SM [9]) 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 running on a router chooses the previous-hop router toward the core
router or Rendezvous Point (RP) as its parent router. In this state, router or Rendezvous Point (RP) as its parent router. In this state,
source-specific state is not available for the corresponding source-specific state is not available for the corresponding
multicast address on the router. multicast address on the router.
Source-specific state: Source-specific state:
It is the state in which a routing protocol running on a router 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. chooses the path that would be followed for a source-specific join.
ALL-[protocol]-ROUTERS.MCAST.NET: ALL-[protocol]-ROUTERS.MCAST.NET:
skipping to change at page 11, line 30 skipping to change at page 11, line 30
source. source.
5.5. Query ID: 16 bits 5.5. Query ID: 16 bits
This field is used as a unique identifier for this traceroute request This field is used as a unique identifier for this traceroute request
so that duplicate or delayed responses may be detected and to so that duplicate or delayed responses may be detected and to
minimize collisions when a multicast response address is used. minimize collisions when a multicast response address is used.
5.6. Client Port # 5.6. Client Port #
Mtrace2 response is sent back to the address specified in a Response Mtrace2 response is sent back to the address specified in a
Address field. This field specifies the UDP port number the router Destination Address field. This field specifies the UDP port number
will send Mtrace2 Response. This client port number MUST NOT be the router will send Mtrace2 Response. This client port number MUST
changed by any router. NOT be changed by any router.
6. IPv4 Mtrace2 Standard Response Block 6. IPv4 Mtrace2 Standard Response Block
Each intermediate IPv4 router in a trace path appends "response data Each intermediate IPv4 router in a trace path appends "response data
block" to the forwarded trace packet. The standard response data block" to the forwarded trace packet. The standard response data
block looks as follows. block looks as follows.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 49 skipping to change at page 15, line 49
0x09 RPF_IF Mtrace2 request arrived on the expected 0x09 RPF_IF Mtrace2 request arrived on the expected
RPF interface for this source and group. RPF interface for this source and group.
0x0A NO_MULTICAST Mtrace2 request arrived on an interface 0x0A NO_MULTICAST Mtrace2 request arrived on an interface
which is not enabled for multicast. which is not enabled for multicast.
0x0B INFO_HIDDEN One or more hops have been hidden from this 0x0B INFO_HIDDEN One or more hops have been hidden from this
trace. trace.
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 querier
0x81 NO_SPACE There was not enough room to insert another 0x81 NO_SPACE There was not enough room to insert another
response data block in the packet. response data block in the packet.
0x82 OLD_ROUTER The previous-hop router does not understand 0x82 OLD_ROUTER The previous-hop router does not understand
mtrace2 requests. mtrace2 requests.
0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited. 0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited.
Note that if a router discovers there is not enough room in a packet Note that if a router discovers there is not enough room in a packet
to insert its response, it puts the NO_SPACE error code in the to insert its response, it puts the NO_SPACE error code in the
skipping to change at page 20, line 10 skipping to change at page 20, line 10
7.13. Forwarding Code: 8 bits 7.13. Forwarding Code: 8 bits
Same definition described in Section 6.13 Same definition described in Section 6.13
8. Mtrace2 Augmented Response Block 8. Mtrace2 Augmented Response Block
In addition to the standard response block, a multicast router on the In addition to the standard response block, a multicast router on the
path will be able to add "augumented response block" when it sends path will be able to add "augumented response block" when it sends
the request to its upstream router or sends the response to the the request to its upstream router or sends the response to the
Response Address. This augmented response block is flexible to add Destination Address. This augmented response block is flexible to
various information. add various information.
0 1 2 3 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 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 | Value .... | | Type | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The augmented response block is always appended to mtrace2 TLV header The augmented response block is always appended to mtrace2 TLV header
(0x04). The 16 bits Type filed of the augmented response block is (0x04). The 16 bits Type filed of the augmented response block is
defined for various purposees, such as diagnosis (as in Section 12) defined for various purposes, such as diagnosis (as in Section 12)
and protocol verification. The packet length of the augmented and protocol verification. The packet length of the augmented
response block is specified in the augmented response block TLV response block is specified in the augmented response block TLV
header as see in Section 4.1. header as seen in Section 4.1.
This document does not define any augmented response block type. The following augmented response block type is defined:
Specifing how to deal with diagnosis information will be also
described in separate documents. Code Type
====== =================================================
0x01 # Mtrace2 Standard Response Blocks Returned
When the NO_SPACE error occurs, the router sends back the mtrace2
response 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 9.3. 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. Specifing
how to deal with diagnosis information will be also described in
separate documents.
9. Router Behavior 9. Router Behavior
All of these actions are performed in addition to (NOT instead of) All of these actions are performed in addition to (NOT instead of)
forwarding the packet, if applicable. E.g. a multicast packet that forwarding the packet, if applicable. E.g. a multicast packet that
has TTL or the hop limit remaining MUST be forwarded normally, as has TTL or the hop limit remaining MUST be forwarded normally, as
MUST a unicast packet that has TTL or the hop limit remaining and is MUST a unicast packet that has TTL or the hop limit remaining and is
not addressed to this router. not addressed to this router.
9.1. Traceroute Query 9.1. Traceroute Query
skipping to change at page 22, line 11 skipping to change at page 22, line 11
response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6
mtrace2. Routers can tell the difference between Queries and mtrace2. Routers can tell the difference between Queries and
Requests by checking the length of the packet. Requests by checking the length of the packet.
9.2.1. Packet Verification 9.2.1. Packet Verification
If the mtrace2 Request does not come from an adjacent host or router, If the mtrace2 Request does not come from an adjacent host or router,
it MUST be silently ignored. If the mtrace2 Request is not addressed 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 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] which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3]
for IPv6), it MUST be silently ignored. for IPv6), it MUST be silently ignored. The router's neighbor
information, e.g. ARP database or PIM neighbor list, should be used
to determine whether the host or router is adjacent or not.
9.2.2. Normal Processing 9.2.2. Normal Processing
When a router receives an mtrace2 Request, it performs the following When a router receives an mtrace2 Request, it performs the following
steps. Note that it is possible to have multiple situations covered steps. Note that it is possible to have multiple situations covered
by the Forwarding Codes. The first one encountered is the one that by the Forwarding Codes. The first one encountered is the one that
is reported, i.e. all "note forwarding code N" should be interpreted is reported, i.e. all "note forwarding code N" should be interpreted
as "if forwarding code is not already set, set forwarding code to N". as "if forwarding code is not already set, set forwarding code to N".
1. If there is room in the current buffer (or the router can 1. If there is room in the current buffer (or the router can
skipping to change at page 22, line 40 skipping to change at page 22, line 42
Section 9.3. Section 9.3.
2. Attempt to determine the forwarding information for the source 2. Attempt to determine the forwarding information for the source
and group specified, using the same mechanisms as would be used and group specified, using the same mechanisms as would be used
when a packet is received from the source destined for the when a packet is received from the source destined for the
group. State need not be instantiated, it can be "phantom" group. State need not be instantiated, it can be "phantom"
state created only for the purpose of the trace, such as "dry- state created only for the purpose of the trace, such as "dry-
run". run".
If using a shared-tree protocol and there is no source-specific If using a shared-tree protocol and there is no source-specific
state, or if the source is specified as "all 1", group state state, or if no source-specific information is desired (i.e.,
should be used. If there is no group state or the group is "all 1" for IPv4 or unspecified address (::) for IPv6), group
specified as 0, potential source state (i.e. the path that would state should be used. If there is no group state or no group-
be followed for a source-specific Join) should be used. If this specific information is desired, potential source state (i.e.
router is the Core or RP and no source-specific information is the path that would be followed for a source-specific Join)
available, note an error code of REACHED_RP. should be used. If this router is the Core or RP 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.
3. If no forwarding information can be determined, the router notes 3. If no forwarding information can be determined, the router notes
an error code of NO_ROUTE, sets the remaining fields that have an error code of NO_ROUTE, sets the remaining fields that have
not yet been filled in to zero, and then forwards the packet to not yet been filled in to zero, and then forwards the packet to
the requester as described in Section 9.3. the requester as described in Section 9.3.
4. Fill in the Incoming Interface Address, Previous-Hop Router 4. Fill in the Incoming Interface Address, Previous-Hop Router
Address, Input Packet Count, Total Number of Packets, Routing Address, Input Packet Count, Total Number of Packets, Routing
Protocol, S, and Src Mask from the forwarding information that Protocol, S, and Src Mask from the forwarding information that
was determined. was determined.
skipping to change at page 23, line 41 skipping to change at page 23, line 46
forwarding code of REACHED_RP is noted. forwarding code of REACHED_RP is noted.
9. If this router has sent a prune upstream which applies to the 9. If this router has sent a prune upstream which applies to the
source and group in the mtrace2 Request, it notes forwarding source and group in the mtrace2 Request, it notes forwarding
code PRUNE_SENT. If the router has stopped forwarding code PRUNE_SENT. If the router has stopped forwarding
downstream in response to a prune sent by the next hop router, downstream in response to a prune sent by the next hop router,
it notes forwarding code PRUNE_RCVD. If the router should it notes forwarding code PRUNE_RCVD. If the router should
normally forward traffic for this source and group downstream normally forward traffic for this source and group downstream
but is not, it notes forwarding code NOT_FORWARDING. but is not, it notes forwarding code NOT_FORWARDING.
10. The packet is then sent on to the previous hop or the 10. If this router is a gateway (e.g., a NAT or firewall) that hides
the information between this router and the mtrace2 querier, it
notes forwarding code REACHED_GW.
11. The packet is then sent on to the previous hop or the
Destination Address as described in Section 9.3. Destination Address as described in Section 9.3.
9.3. Forwarding Mtrace2 Requests 9.3. Forwarding Mtrace2 Requests
If the Previous-hop router is known for this request and the number If the Previous-hop router is known for this request and the number
of response blocks is less than the number requested (i.e., the "# of response blocks is less than the number requested (i.e., the "#
hops" field in mtrace2 header), the packet is sent to that router. hops" field in mtrace2 header), the packet is sent to that router.
If the Incoming Interface is known but the Previous-hop router is not If the Incoming Interface is known but the Previous-hop router is not
known, the packet is sent to an appropriate multicast address on the known, the packet is sent to an appropriate multicast address on the
Incoming Interface. The appropriate multicast address may depend on Incoming Interface. The appropriate multicast address may depend on
the routing protocol in use, MUST be a link-scoped group (i.e. 224/24 the routing protocol in use, MUST be a link-scoped group (i.e. 224/24
for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET
(224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6, and (224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6, and
MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers
Address (FF02::2) for IPv6 if the routing protocol in use does not Address (FF02::2) for IPv6 if the routing protocol in use does not
define a more appropriate group. Otherwise, it is sent to the define a more appropriate group. Otherwise, it is sent to the
Destination Address in the header. Destination Address in the header.
When the NO_SPACE error occurs, the multicast routers sends back the When the REACHED_GW code is noted, the router sends back the mtrace2
mtrace2 response with contained data and the NO_SPACE error code to response as in Section 9.4. In addition to that, it must continue
the address specified in the Destination Address field in the mtrace2 the mtrace2 query by proxying the original querier as in Section 9.5.
query header, and continues the mtrace2 query by sending an mtrace2
request containing the same mtrace2 query header except the # hops When the NO_SPACE error occurs, the router sends back the mtrace2
field and its response block. The # hops field must be decreased response with contained data and the NO_SPACE error code as in
according to the number of standard response blocks in the mtrace2 Section 9.4, and continues the mtrace2 query by sending an mtrace2
request received by the router. 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.
9.4. Sending Mtrace2 Responses 9.4. Sending Mtrace2 Responses
9.4.1. Destination Address 9.4.1. Destination Address
An mtrace2 Response must be sent to the address specified in the An mtrace2 Response must be sent to the address specified in the
Destination Address field in the mtrace2 query header. Destination Address field in the mtrace2 query header.
9.4.2. Source Address 9.4.2. Source Address
An mtrace2 Response must be sent with the address of the router's An mtrace2 Response must be sent with the address of the router's
reception interface. reception interface.
9.5. Hiding Information 9.5. Proxying Mtrace2 Queries
When a gateway (e.g., a NAT or firewall) that needs to block unicast
packets to the mtrace2 querier or hide information between the
gateway and the mtrace2 querier receives mtrace2 query from an
adjacent host or mtrace2 request from an adjacent router, it sends
back the mtrace2 response with contained data and the REACHED_GW code
to the address specified in the Destination Address field in the
mtrace2 query header.
At the same time, the gateway prepares a new mtrace2 query message.
The gateway uses the original mtrace2 query header as the base for
the new mtrace2 query; it sets the Destination 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 response 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 response from the first-hop
router or any intermediate router, it MUST forward the mtrace2
response back to the mtrace2 querier with the original mtrace2 query
header.
9.6. Hiding Information
Information about a domain's topology and connectivity may be hidden Information about a domain's topology and connectivity may be hidden
from multicast traceroute requests. The exact mechanism is not from multicast traceroute requests. The INFO_HIDDEN forwarding code
specified here; however, the INFO_HIDDEN forwarding code may be used may be used to note that, for example, the incoming interface address
to note that, for example, the incoming interface address and packet and packet count are for the entrance to the domain and the outgoing
count are for the entrance to the domain and the outgoing interface interface address and packet count are the exit from the domain. The
address and packet count are the exit from the domain. The source- source-group packet count may be from either router or not specified
group packet count may be from either router or not specified (all (all 1).
1).
10. Client Behavior 10. Client Behavior
10.1. Sending Mtrace2 Query 10.1. Sending Mtrace2 Queries
When the destination of the mtrace2 is the machine running the When the destination of the mtrace2 is the machine running the
client, the mtrace2 Query packet can be sent to the ALL- client, the mtrace2 Query packet can be sent to the ALL-
ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address
(FF02::2) for IPv6. This will ensure that the packet is received by (FF02::2) for IPv6. This will ensure that the packet is received by
the last-hop router on the subnet. Otherwise, if the proper last-hop the last-hop router on the subnet. Otherwise, if the proper last-hop
router is known for the mtrace2 destination, the Query could be router is known for the mtrace2 destination, the Query could be
unicasted to that router. Otherwise, the Query packet should be unicasted to that router.
multicasted to the group being queried; if the destination of the
mtrace2 is a member of the group, this will get the Query to the
proper last-hop router. In this final case, the packet should
contain the Router Alert option [7][8], to make sure that routers
that are not members of the multicast group notice the packet.
See also Section 10.4 on determining the last-hop router. See also Section 10.4 on determining the last-hop router.
10.2. Determining the Path 10.2. Determining the Path
The client could send a small number of initial query messages with a The client could send a small number of initial query messages with a
large "# hops" field, in order to try to trace the full path. If large "# hops" field, in order to try to trace the full path. If
this attempt fails, one strategy is to perform a linear search (as this attempt fails, one strategy is to perform a linear search (as
the traditional unicast traceroute program does); set the "# hops" the traditional unicast traceroute program does); set the "# hops"
field to 1 and try to get a response, then 2, and so on. If no field to 1 and try to get a response, then 2, and so on. If no
skipping to change at page 26, line 7 skipping to change at page 26, line 51
10.4. Last Hop Router 10.4. Last Hop Router
The mtrace2 querier may not know which is the last hop router, or The mtrace2 querier may not know which is the last hop router, or
that router may be behind a firewall that blocks unicast packets but that router may be behind a firewall that blocks unicast packets but
passes multicast packets. In these cases, the mtrace2 request should 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 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 Routers Address (FF02::2) for IPv6. All routers except the correct
last hop router should ignore any mtrace2 request received via last hop router should ignore any mtrace2 request received via
multicast. Mtrace2 requests which are multicasted to the group being multicast. Mtrace2 requests which are multicasted to the group being
traced must include the Router Alert option[7][8]. traced must include the Router Alert option[6][7].
Another alternative is to unicast to the trace destination. Mtrace2 Another alternative is to unicast to the trace destination. Mtrace2
requests which are unicasted to the trace destination must include requests which are unicasted to the trace destination must include
the Router Alert option, in order that the last-hop router is aware the Router Alert option, in order that the last-hop router is aware
of the packet. of the packet.
10.5. First Hop Router 10.5. First Hop Router
The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default
multicast group for IPv4 mtrace responses, in order to support mtrace multicast group for IPv4 mtrace responses, in order to support mtrace
queriers that are not unicast reachable from the first hop router. queriers that are not unicast reachable from the first hop router.
However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses
for mtrace2 responses. Every mtrace2 response is sent to the unicast for mtrace2 responses. Every mtrace2 response is sent to the unicast
address specified in the Destination Address field of the mtrace2 address specified in the Destination Address field of the mtrace2
query header. query header.
The mtrace2 querier may be behind a gateway (e.g., a NAT or firewall)
that blocks unicast packets. When the gateway receives mtrace2 query
from an adjacent host that is not unicast reachable, it sends back
the mtrace2 response with contained data and the NO_SPACE error code
to the address specified in the Destination Address field in the
mtrace2 query header. And to continue the mtrace2 query, the gateway
prepares the mtrace2 query containing the same mtrace2 query header,
except the # hops field, the Destination Address, and its response
block.
The # hops field must be decreased according to the number of
standard response blocks in the mtrace2 request received by the
gateway. And the original Destination Address MUST be replaced with
the gateway address that is unicast reachable from the first hop
router. After that, the gateway restarts the mtrace2 query by
sending an mtrace2 request. When the gateway receives the mtrace2
response from the last hop router, it MUST forward the mtrace2
response back to the original mtrace2 querier with the original
Destination Address in the mtrace2 query header.
10.6. Broken Intermediate Router 10.6. Broken Intermediate Router
A broken intermediate router might simply not understand mtrace2 A broken intermediate router might simply not understand mtrace2
packets, and drop them. The querier would then get no response at packets, and drop them. The querier would then get no response at
all from its mtrace2 requests. It should then perform a hop-by-hop all from its mtrace2 requests. It should then perform a hop-by-hop
search by setting the number of responses field until it gets a search by setting the number of responses field until it gets a
response (both linear and binary search are options, but binary is response (both linear and binary search are options, but binary is
likely to be slower because a failure requires waiting for a likely to be slower because a failure requires waiting for a
timeout). timeout).
skipping to change at page 29, line 19 skipping to change at page 29, line 19
When a multicast traceroute reaches a PIM-SM RP and the RP does not When a multicast traceroute reaches a PIM-SM RP and the RP does not
forward the trace on, it means that the RP has not performed a 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, 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- 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 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. RP, the trace source to the traffic source, and the trace group to 0.
This trace Query may be unicasted to the RP. This trace Query may be unicasted to the RP.
11.2. Bi-Directional PIM 11.2. Bi-Directional PIM
Bi-directional PIM [10] is a variant of PIM-SM that builds bi- Bi-directional PIM [9] is a variant of PIM-SM that builds bi-
directional shared trees connecting multicast sources and receivers. directional shared trees connecting multicast sources and receivers.
Along the bi-directional shared trees, multicast data is natively Along the bi-directional shared trees, multicast data is natively
forwarded from sources to the RPA (Rendezvous Point Address) and from forwarded from sources to the RPA (Rendezvous Point Address) and from
the RPA to receivers without requiring source-specific state. In the RPA to receivers without requiring source-specific state. In
contrast to PIM-SM, RP always has the state to trace. contrast to PIM-SM, RP always has the state to trace.
A Designated Forwarder (DF) for a given RPA is in charge of A Designated Forwarder (DF) for a given RPA is in charge of
forwarding downstream traffic onto its link, and forwarding upstream forwarding downstream traffic onto its link, and forwarding upstream
traffic from its link towards the RPL (Rendezvous Point Link) that traffic from its link towards the RPL (Rendezvous Point Link) that
the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along
skipping to change at page 29, line 52 skipping to change at page 29, line 52
When traffic is flowing, PIM Dense Mode routers know whether or not 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 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 lost an Assert battle) and know who the previous hop is (because it
won an Assert battle). Therefore, multicast traceroute is always won an Assert battle). Therefore, multicast traceroute is always
able to follow the proper path when traffic is flowing. able to follow the proper path when traffic is flowing.
11.4. IGMP/MLD Proxy 11.4. IGMP/MLD Proxy
When a mtrace2 Query packet reaches an incoming interface of IGMP/MLD When a mtrace2 Query packet reaches an incoming interface of IGMP/MLD
Proxy [11], it put a WRONG_IF (0x01) value in Forwarding Code of Proxy [10], it put a WRONG_IF (0x01) value in Forwarding Code of
mtrace2 standard response block (as in Section 6.13) and sends the mtrace2 standard response block (as in Section 6.13) and sends the
mtrace2 response back to the Response Address. When a mtrace2 Query mtrace2 response back to the Destination Address. When a mtrace2
packet reaches an outgoing interface of IGMP/MLD proxy, it is Query packet reaches an outgoing interface of IGMP/MLD proxy, it is
forwarded through its incoming interface towards the upstream router. forwarded through its incoming interface towards the upstream router.
11.5. AMT 11.5. AMT
AMT [12] provides the multicast connectivity to the unicast-only AMT [11] provides the multicast connectivity to the unicast-only
inter-network. To do this, multicast packets being sent to or from a inter-network. To do this, multicast packets being sent to or from a
site are encapsulated in unicast packets. When a mtrace2 query site are encapsulated in unicast packets. When a mtrace2 query
packet reaches an AMT pseudo-interface of an AMT gateway, the AMT packet reaches an AMT pseudo-interface of an AMT gateway, the AMT
gateway encapsulats it to a particular AMT relay reachable across the gateway encapsulats it to a particular AMT relay reachable across the
unicast-only infrastructure. Then the AMT relay decapsulates the unicast-only infrastructure. Then the AMT relay decapsulates the
mtrace2 query packet and forwards the mtrace2 request to the mtrace2 query packet and forwards the mtrace2 request to the
appropriate multicast router. appropriate multicast router.
12. Problem Diagnosis 12. Problem Diagnosis
skipping to change at page 33, line 8 skipping to change at page 33, line 8
If the routers have synchronized clocks, it is possible to estimate If the routers have synchronized clocks, it is possible to estimate
propagation and queuing delay from the differences between the propagation and queuing delay from the differences between the
timestamps at successive hops. However, this delay includes control timestamps at successive hops. However, this delay includes control
processing overhead, so is not necessarily indicative of the delay processing overhead, so is not necessarily indicative of the delay
that data traffic would experience. that data traffic would experience.
13. IANA Considerations 13. IANA Considerations
The following new assignments can only be made via a Standards Action The following new assignments can only be made via a Standards Action
as specified in [5]. as specified in [4].
13.1. Forwarding Codes 13.1. Forwarding Codes
New Forwarding codes must only be created by an RFC that modifies New Forwarding codes must only be created by an RFC that modifies
this document's Section 10, fully describing the conditions under this document's Section 10, fully describing the conditions under
which the new forwarding code is used. The IANA may act as a central 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 repository so that there is a single place to look up forwarding
codes and the document in which they are defined. codes and the document in which they are defined.
13.2. UDP Destination Port and IPv6 Address 13.2. UDP Destination Port and IPv6 Address
skipping to change at page 35, line 5 skipping to change at page 34, line 20
network topology is a secret, mtrace2 may be restricted at the border network topology is a secret, mtrace2 may be restricted at the border
of your domain, using the ADMIN_PROHIB forwarding code. of your domain, using the ADMIN_PROHIB forwarding code.
14.2. Traffic Rates 14.2. Traffic Rates
Mtrace2 can be used to discover what sources are sending to what Mtrace2 can be used to discover what sources are sending to what
groups and at what rates. If this information is a secret, mtrace2 groups and at what rates. If this information is a secret, mtrace2
may be restricted at the border of your domain, using the may be restricted at the border of your domain, using the
ADMIN_PROHIB forwarding code. ADMIN_PROHIB forwarding code.
14.3. 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.
15. Acknowledgements 15. Acknowledgements
This specification started largely as a transcription of Van This specification started largely as a transcription of Van
Jacobson's slides from the 30th IETF, and the implementation in Jacobson's slides from the 30th IETF, and the implementation in
mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve
Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original
multicast traceroute client, mtrace (version 1), has been implemented multicast traceroute client, mtrace (version 1), has been implemented
by Ajit Thyagarajan, Steve Casner and Bill Fenner. by Ajit Thyagarajan, Steve Casner and Bill Fenner.
The idea of unicasting a multicast traceroute Query to the The idea of unicasting a multicast traceroute Query to the
skipping to change at page 36, line 18 skipping to change at page 36, line 18
[1] Bradner, S., "Key words for use in RFCs to indicate requirement [1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[4] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
[6] Braden, B., Borman, D., and C. Partridge, "Computing the [5] Braden, B., Borman, D., and C. Partridge, "Computing the
Internet Checksum", RFC 1071, September 1988. Internet Checksum", RFC 1071, September 1988.
[7] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[8] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [7] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
[9] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [8] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[10] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [9] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-PIM)", "Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
RFC 5015, October 2007. RFC 5015, October 2007.
[11] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet [10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006. RFC 4605, August 2006.
[12] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. [11] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in (AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in
progress), October 2007. progress), October 2007.
16.2. Informative References 16.2. Informative References
[12] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[13] Draves, R. and D. Thaler, "Default Router Preferences and More- [13] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005. Specific Routes", RFC 4191, November 2005.
[14] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", [14] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000. RFC 2863, June 2000.
[15] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", [15] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB",
RFC 5132, December 2007. RFC 5132, December 2007.
Authors' Addresses Authors' Addresses
 End of changes. 42 change blocks. 
100 lines changed or deleted 142 lines changed or added

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