INTERNET-DRAFT Jiwoong Lee Expires: Feb 2003 KTF 13 August 2002 Explicit multicast reachability test Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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 obsolete by other documents at anytime. 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. All remarks may be forwarded to author's email address or xcast IG(Incubation Group) mailing list: xcast@public.alcatel.com Abstract It can be important to know which node has Explicit multicast receivability and routability before sending a large amount of data traffic in Explicit multicast. This document provides how to test the receivability and routability, in short, the reachability of Explicit multicast packets to a particular node. 1. Introduction Explicit multicast(xcast)[1], which is a new Internet multicast, is placed between IP unicasting and IP host group model multicasting Jiwoong Lee Expire Feb 2003 [Page 1] INTERNET-DRAFT Xcast Reachability August 2002 in the sense of morphology of packet structure and routing algorithm. Xcast inherently does not provide signaling mechanism between two or more xcast nodes, therefore it lacks of 'HELLO' message as well, which could have been used to identify the presence of neighbors and their xcast ability - such as xcast receivability and xcast routability. Xcast basic specification, on the contrary, does provide neither 'HELLO' message nor any other kind of signaling. And people affiliated with xcast does believe that designing and creating xcast-specific signaling might impair the excellence of xcast, which can be achieved by no signaling burden and no stateful feature. However, the features that can be provided by 'HELLO' stuff are still useful and sometimes regarded necessary; a sender node may wish to confirm that the intended destination node can receive and handle legitimate xcast packets before it starts to send a barrage of xcast data packets. Besides the sender node may wish to confirm that the transit network between itself and the receiver nodes can route and forward legitimate xcast packets before it starts to send a barrage of xcast data packets. To achieve those purposes this document specifies how to test a particular node's receivability and how to test a particular node's reachability which depends on xcast routability of each transit router, without newly creating or extending protocol operations. Instead, receivability / reachability test can be made heavily dependent on previously established protocol operations, especially including - ICMP Destination Unreachable, Protocol Unreachable error mes- sage - ICMP Destination Unreachable, Port Unreachable error message - ICMP Time Exceeded, Time to live exceeded in transit error message - Inference of packet discard in transit routers by timer expi- ration. 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[7]. In addition, this document frequently uses the following terms: Jiwoong Lee Expire Feb 2003 [Page 2] INTERNET-DRAFT Xcast Reachability August 2002 AXR All_Xcast_Routers address MX AXR-addressed xcast UX Unicast-addressed xcast MX2U Conversion of MX into Unicast UX2U Conversion of UX into Unicast Xcast receivability Ability of a node with which it can receive an xcast packet and passes the payload to the subsequent upper layer handler. Xcast routability Ability of a node with which it can perform xcast routing over an incoming xcast packet and forward the packets produced as a result of the routing. Xcast reachability Ability of a transit network with which it can deliver the committed xcast packet to destination nodes. Xcast reachabil- ity refers to the ability of set of nodes while xcast routability refers especially to the ability of a particular node. Sender node Node which is supposed to send xcast data packets Receiver node Node which is supposed to receive xcast data packets Tester node Node from which the probe packet is generated. Testee node Node for which the probe packet is heading. Probe packet An experimental packet which travels from the tester node toward testee node. A probe packet may elicit ICMP error mes- sages from an unexpected node while traveling. 3. Test 3.1 Assumption of test operation The nodes on the traveling path of a probe packet MUST satisfy the following assumption. Jiwoong Lee Expire Feb 2003 [Page 3] INTERNET-DRAFT Xcast Reachability August 2002 - All nodes are alive, that is, IP/ICMP sane. - All transit nodes are capable of unicast routing - All hosts are UDP sane. - The sender node is able to generate xcast packets and is capable of xcast encapsulation, which is defined in [6]. - The receiver node, if it is able to receive xcast packets, is capable of xcast decapsulation, which is defined in [6]. - All xcast hosts that can legitimately handle MX packets also can handle UX packets. 3.2 Xcast receivability test A receiver node's xcast receivability MAY be tested before a sender node sends initial xcast data packets to it. With this end, a tester node (which is the sender node in most cases) sends a probe packet to the testee node (the receiver node). The probe packet is essentially a UX packet carrying UDP header and its payload, while the Destination Port of UDP header is randomly given. Packet format of a probe packet MUST obey the following values: IP header Source Address: A unicast address assigned to the tester node Destination Address: A unicast address assigned to the testee node Protocol: PROTO_xcast. Xcast header X bit: MUST be set to 1. P bit: MAY be set to 1. NBR_OF_DEST: MUST be set to 1. PROT ID: MUST be set to 17. (indicating that the following header is Jiwoong Lee Expire Feb 2003 [Page 4] INTERNET-DRAFT Xcast Reachability August 2002 for UDP) Channel Identifier: Random number for identification purpose. List of Addresses: The same address as used in Destination Address in IP header List of Port Numbers: If P bit is set, this value MUST be the same as Destination Port of UDP header. UDP header Source Port: MAY be any number assigned by the tester node. Destination Port: 33434 by default. MAY be changed by the testing configuration. Payload 4 Byte random string for debug purpose. If the testee node does not have xcast receivability, the testee node does not recognize the Protocol number given in the IP header of the probe packet. Therefore, the testee node returns, on receiving the probe packet from the tester node, an ICMP Destination Unreachable, Protocol Unreachable error message to the tester node. Otherwise, the testee node does recognize the Protocol number given in the IP header of the probe packet. However, it does not recognize the given Destination Port number given in the UDP header since it mostly does not have an open socket for that Destination Port number. Therefore, the testee node returns, on receiving the probe packet from the tester node, and ICMP Destination Unreachable, Port Unreachable error message to the tester node. On receiving an ICMP error message elicited by the probe packet from the testee node, the tester node MUST check the TYPE and CODE of the ICMP error message. If TYPE and CODE indicates that the ICMP message is caused by Destination Unreachable, Protocol Unreachable problem, the tester node regards the testee node as not having xcast receivability. If TYPE and CODE indicates that the ICMP message is caused by Destination Unreachable, Port Unreachable problem, the tester node regards the testee node as having xcast receivability. There is a chance that the default UDP Destination port number used in the probe packet happens to be already being used on the testee node when the probe packet reaches it. In this case the tester node Jiwoong Lee Expire Feb 2003 [Page 5] INTERNET-DRAFT Xcast Reachability August 2002 can receive neither ICMP Destination Unreachable, Port Unreachable, nor ICMP Destination Unreachable, Protocol Unreachable on return. For a proper test, the UDP Destination port number SHOULD be changed. The Channel Identifier in the xcast header of the probe packet is used for the identification purpose that is to identify the probe packet causing a returned ICMP error message. This is useful when one application sends multiple probe packets to the same testee node before it receives any of ICMP error message on return, or when multiple application sends their own probe packets to the same testee node at the same tester node. X bit MUST be set to 1 since a transit router SHALL NOT perform UX2U over the probe packet. 3.3 Xcast reachability test Most xcast data packets are addressed to AXR address. The transit routers on the delivery path between the sender node and the receiver node MAY recognize any incoming packet as an xcast packet if it is addressed to AXR. Xcast reachability means the ability of transit routers placed between the sender node and the receiver node on the one-way delivery path. To be successful in the reachability test, all the transit routers MUST not discard the incoming packet only due to the fact that it is addressed to AXR and MUST be capable of xcast routing; if one or more transit routers are incapable of xcast routing, the test will fail. Xcast reachability test MAY be performed before a sender node sends xcast data packets to the receiver node, so as to confirm that the provided transit networks can deliver them to the receiver node successfully. With this end, the tester node (the sender node in most cases) sends one or more probe packets to the receiver node. The probe packet is essentially an AXR-addressed xcast packet carrying xcast receivability probe packet inside. Packet format of a probe packet MUST obey the following values: Tunnel IP Header Source address: A unicast address assigned to the tester node Destination address: All_Xcast_Routers. Jiwoong Lee Expire Feb 2003 [Page 6] INTERNET-DRAFT Xcast Reachability August 2002 Protocol: PROTO_Xcast. Tunnel xcast Header X bit: MUST be set to 1. P bit: MUST be set to 0. NBR_OF_DEST: MUST be set to 1. PROT ID: MUST be set to 4. (indicating that the following header is IP) Channel Identifier: Random number for identification purpose. List of Addresses: The same as Destination Address in original IP header. Original IP Header Source Address: A unicast address assigned to the tester node Destination Address: A unicast address assigned to the receiver node Protocol: PROTO_xcast IP options: The probe packet MUST NOT carry IP options; therefore the length of IP header of the probe packet is exactly 20 bytes in IPv4. Original xcast header X bit: MUST be set to 1 P bit: MAY be set to 1. NBR_OF_DEST: MUST be set to 1 PROT ID: MUST be set to 17. (indicating that the following header is Jiwoong Lee Expire Feb 2003 [Page 7] INTERNET-DRAFT Xcast Reachability August 2002 for UDP) Channel Identifier: Random number for identification purpose. List of Addresses: The same as Destination Address in the Original IP header List of Port Numbers: If P bit is set, this value MUST be the same as Destination Port of UDP header. UDP header Source Port: MAY be any number Destination Port 33434 by default. MAY be changed by the testing configuration. Payload 4 Byte random string for debug purpose. If all of the transit routers on the delivery path are capable of xcast routing and the testee node is xcast reachable, the probe packet will reach the intended receiver node successfully. On receiving the probe packet, the receiver node MUST decapsulate the probe packet and acquire the original packet, which is essentially a probe packet for xcast receivability test. Therefore, the receiver node will return an ICMP Destination Unreachable, Port Unreachable. If one of the transit routers on the delivery path is incapable of xcast routing or the testee node is not xcast-receivable, it MAY discard the incoming probe packet since the probe packet for testing xcast reachability is addressed to AXR, which is a link local multicast address. If it discards the incoming probe packet, it will keep silent with generating no ICMP error message as an indication of discard. If the tester node does not receive an ICMP error message as return of the probe packet for PROBE_TIMEOUT seconds, the reachability test SHOULD be regarded as failure. The failure of xcast reachability test means that at least one transit router on the one way delivery path between the tester node and the testee node is incapable of xcast routing or that the testee node itself is not xcast-receivable. It does not notify the tester node of which transit node is incapable of xcast routing. 4. Identifying the xcast routability of each node on the delivery path Jiwoong Lee Expire Feb 2003 [Page 8] INTERNET-DRAFT Xcast Reachability August 2002 This section describes not protocol specification, but possible extended applicability of protocol. Xcast routability test is a test of the Xcast routing ability of a particular transit node placed on the delivery path to a specified testee node. The purpose of xcast routability test is to determine how far a normal MX packet can reach without undergoing premature MX2U. The xcast routability of each node in the delivery path can be tested by adjusting Time-To-Live(TTL) value of the tunnel IP header of the probe packet during the xcast reachability test. As exactly in the same way as 'traceroute' uses, the tester node may increase TTL value of the probe packet from 1 until it finally gets a result of the xcast reachability test. Xcast reachability test has two kinds of results; one is an ICMP error message generated by the testee node, and the other is 'no message returned.' During the xcast routability test, the tester node will receive one or more ICMP error messages generated by the transit nodes before it finally obtains xcast reachability test result. Example scenario is given below. A ----- B ----- C ----- D ----- E tester testee Node A wishes to test xcast reachability to node E. 1) Node A sends the initial probe packet to E, with TTL = 1. Node B receives the initial probe packet and returns to node A an ICMP error message - Time exceeded, time to live exceeded in transit. Thus, node A identifies the first hop node on the path leading to E is node B. 2) Node A sends the secondary probe packet to E, with TTL = 2. Assume node B is capable of xcast routing. Then node B will forward the probe packet to C. On receiving the probe packet, node C will return to node A an ICMP error message - Time exceeded, time to live exceeded in transit. When node A receives an ICMP error message from node C, it can identify the second hop node on the path leading to node B is node C, and the first hop node is capable of xcast routing. Otherwise node B will discard the probe packet without generating any ICMP error message. In this case node A will not receive any return message from the network for PROBE_TIMEOUT seconds. Since the xcast reachability test fails at the first hop node, node A can identify that node B is incapable of xcast routing. Jiwoong Lee Expire Feb 2003 [Page 9] INTERNET-DRAFT Xcast Reachability August 2002 Node E is not reachable from node A. No further probing is necessary. 3) Assume again that both node B, node C and node D are capable of xcast routing. Node A subsequently sends the probe packet to E, with TTL = 3. Node B and C forwards the probe packet toward node E, and node D will return an ICMP error message - Time exceeded, time to live exceeded in transit. Thus node A identifies the third node on the delivery path. Increasing one more TTL value will cause an ICMP error message - Time exceeded from node E, and additional TTL increment will elicit the result of xcast reachability test. In this way, the tester node can identify which node on the delivery path is capable or incapable of xcast routing. The Channel Identifier in the original xcast header of the probe packet is used for the identification purpose that is to identify the probe packet causing the ICMP error message. This is useful when one application sends multiple probe packets to the same testee node before it receives any of ICMP error message on return, or when multiple application sends their own probe packets to the same testee node. 5. List of default values PROBE_TIMEOUT 5 by defaults. This value MAY be adjustable, preferably, by the command line interface. 6. Security considerations A probe packet does not contain any user-sensitive information within itself. However there is a possibility that a wicked node eavesdrops the probe packet and returns unsolicited ICMP error message to the origin of the probe packet, while one of the transit routers does discard and returns no error message. This can make the tester node misconstrue the result of xcast reachability and may trigger the sender node to start transmitting a barrage of user data packets. The reverse situation is also possible. A Man-in-the-Middle attacker can knowingly impede the progress of probe packet or the returning ICMP error message. This kind of attack can cause abrupt cessation of xcast transmission or blocking the commencement of xcast transmission from the beginning. Jiwoong Lee Expire Feb 2003 [Page 10] INTERNET-DRAFT Xcast Reachability August 2002 References [1] R. Boivie, Y. Imai, W. Livens, D. Ooms, and O. Paridaens, Explicit Multicast Basic Specification, IETF draft-ooms-xcast-basic- spec-01.txt, March 2001 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981. [3] Conta, A. and S. Deering "Internet Control Message Protocol for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998. [4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [5] F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June 1995. [6] J. Lee, Explicit Multicast Tunneling, IETF draft-lee-xcast-tunnel- ing-00.txt, Dec 2001 [7] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- els, RFC 2119, Mar 1997. Author's address Jiwoong Lee KTF Advanced Lab 1321-11 Seocho-Dong Seocho-Ku Seoul Korea, Republic of Phone : +82-2-3488-0416 Email : porce@ktf.com Jiwoong Lee Expire Feb 2003 [Page 11]