INTERNET-DRAFT Alain Durand, IMAG November 18, 1997 Laurent Toutain, ENSTb Expires April 23, 1998 IPv6 traceroute option Status of this Memo ------------------- This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This draft expires in February 10, 1998. 1 Abstract ---------- The traceroute program has proven very useful and has been extensively used in the Internet for measurement and debugging purposes. However, it only shows the originator to target path and gives no indication on the reverse path. Source routing may sometimes be used to find it, but it's very often disable by intermediary routers. Another problem occurs when packets do not follow the same routes: traceroute outputs are very difficult to read. Other solutions has been proposed to record the route taken by an IPv4 packet. Originally, IPv4 contains an option in which every intermediary router can add its address [RFC791]. Unfortunately, the limitation in size imposed by the options design of IPv4 limits its use to 9 routers. In [RFC1393] another strategy was proposed. An new IPv4 option was created. When a router receives a packet containing this option, it generates a ICMP Echo message to the source. This technique couldn't be widely deployed in IPv4 because it needed a change in every single router to be efficient. These two methods create less traffic on the network and are more accurate, since they give the real route taken by packets and are less sensitive to fluttering. The IPv6 deployment could be the opportunity to widely deploy a new traceroute mechanism based on those two methods. We propose to combine the two previous methods by defining a new hop-by-hop option and a new ICMP message type to record the direct path from the originator to the target and the reverse path from the target to the originator. 2 Underlying concepts ---------------------- Four strategies can be used. The first one is the most efficient in term of packets carried by the network, but can fails on large networks or in case of packet loss. The originating host places a traceroute hop-by-hop option in an ICMP echo request message sent to the target. Routers process this option by adding information in the fields of the option. The target returns an ICMP echo reply to the source using a traceroute hop-by-hop option initialized with the content of the traceroute option received in the ICMP echo request message. Routers on the return path also record information in this option. The ICMP echo messages payload SHOULD be empty in order to save space for the traceroute option. If the minimum MTU is 576 bytes, only 21 routers can be recorded, but if the minimum MTU is raised to 1 200 bytes, 47 routers could be recorded within the traceroute option. In case of large network or small MTU, it could not be possible to store all the routers information in a single packet. In a second strategy, the originating packet can include a boundary indication. Only the routers after this boundary will record information. This originator will have to specify if this apply to the direct path or the reverse path. One should notice that fluttering might disturb measurements. In case of congestion in heavy loaded networks, the odds of packet loss are high. As a third strategy, a debugging mode, close to the [RFC1393] method is specified. Every router receiving the traceroute hop-by-hop option including a debug flag should send back a ICMP message to the originator. A combination of the second and third strategy can be used in a fourth one. 3. hop-by-hop traceroute option ------------------------------- The traceroute option (value TBD) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Ptr | Flags | Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | space to record information | | | | | ....... | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value: TBD Length: option length in 64 bit not including the traceroute option ID: Identifier randomly chosen by the originator Ptr: first 64 bit word available to store router information Flags: U U S D O R P B B: Backward. gives the direction 0 : forward, originator to target 1: backward, target to originator P: Partial node 0 : record all information 1 : only record information from router located after the boundary R: Reverse record. Only if the P flag is on 0 : boundaries apply to the direct path 1 : boundaries apply to the reverse path O: Overflow. indicates an overflow in the packet 0 : there is some room left in the option to record information 1 : overflow, routers SHOULD NOT any more information D: Debug mode 0 : routers SHOULD insert information in the traceroute option 1 : routers SHOULD send an ICMP packet either to the source or the destination according to the B bit S: Source route. Only applyes if a source routing option is used and the D bit is on. 0 : source routing, reverse the source route 1 : source routing and calculate a route U: Undefined, reserved for future use. Boundary: applies only in partial mode. Give the lower boundary for recording. If the HOP LIMIT of the packet is higher than this value, the router SHOULD NOT record information. Note: If the R and B flags have not the same value, routers SHOULD NOT include any information. The originator MUST set the B flag to zero and the Hop limit to 255. The target MUST turn the B flag and reset the Hop limit to 255. In the first strategy, the P and the D flag are off. In the second strategy, the P flag is on and the D flag is off. In the third strategy, the P flag is off and the D flag is on. Second and third strategy can be combined by turning the P and D flag on. The strategy choice is made by the originator. The target MUST replicate those strategy bits when building the traceroute option. 4. Information inserted by routers. ----------------------------------- Routers should include information from the receiving interface using the following format: 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 | HL | Medium | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ | AS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: the format of the information included by the router, current type is 1. HL: the Hop Limit value in the request packet Medium: the nature of the link, the code is given in [RFC1700] AS: Autonomous System number address: a 'meaningfull' IPv6 address of the equipment. MBZ: MUST BE ZERO 5. ICMP debugging message. ------------------------- In the debug mode, routers should return this ICMP message to the originator. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | MBZ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | HL | Medium | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ | AS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID: Identifier randomly value chosen by the originator HL: Hop Limit value in the received packet Medium: the nature of the link, the code is given in [RFC1700] AS: Autonomous System number (optional) address: a 'meaningful' IPv6 address of the equipment MBZ: MUST BE ZERO 5. Security consideration ------------------------- Unlike the original traceroute program, the traceroute option does not use any UDP port number. This mechanism can go through firewall if allowed. Router may not return information, if the traceroute option is not implemented or configured not to answer. Authentication option can restrict the use of this mechanism to specific originators. 6. References ------------- [RFC791] 1981 Internet Protocol, J. Postel. [RFC1393] 1393 Traceroute Using an IP Option. G. Malkin. January 1993. 7. Author addresses ------------------- Alain Durand Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France Phone : +33 4 76 63 57 03 Fax : +33 4 76 51 49 64 E-Mail: Alain.Durand@imag.fr Laurent Toutain Ecole Nationale Superieure de Telecom de Bretagne 2, rue de la chataigneraie 35512 Cesson Sevigne CEDEX France Phone: +33 2 99 12 70 26 Fax : +33 2 99 12 70 30 E-Mail: Laurent.Toutain@enst-bretagne.fr