Internet Draft R. Bonica Expiration Date: August 2001 WorldCom K. Kompella Juniper Networks D. Meyer Cisco Systems R.Dube Xebeo Communications February 2001 Generic Tunnel Tracing Protocol (GTTP) Specification draft-bonica-tunproto-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. 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. 2. Abstract This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. 3. Conventions used in this document 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]. 4. Introduction This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. A requirements document [TUNREQ] describes these applications. Each section of this document presents a significant aspect of GTTP. This section describes the generic tunnel-tracing problem and provides an informal description of GTTP. Section 5 describes protocol mechanisms and Section 6 describes IANA considerations. Section 7 details security considerations. 4.1. The Tunnel Tracing Problem ----- | D0 | |Route| |Trace| ----- | | - H0 - H1 - H2 - (IP) -|D|----|D|-------------------------------------|D|----|D| |1| |2| H1:0 - H1:1 - H1:2 |3| |4| (IP) | | | |------|D|-------------------|D|------| | | | - - |5| H1:1:0 - H1:1:1 |6| - - (MPLS) | |--------|D|--------| | - |7| - | | - Figure 1: Tunnel Tracing Problem Figure 1 depicts eight IP accessible devices (D0 through D7). A tunnel tracing application executes upon device D0. The tunnel tracing application must trace the route between the D1 and D4. In this example, assume that the traced route originates on D1's loopback interface and terminates on D4's loopback interface. The route between D1 and D4 contains three "top-level hops". These are H0, H1 and H2. An IP-in-IP tunnel supports H1. The IP-in-IP tunnel itself contains three hops. These hops, H1:0, H1:1 and H1:2, are subordinate to H1. Finally, an MPLS LSP supports H1:1. The LSP contains two hops, H1:1:0 and H1:1:1. 4.2. Informal Protocol Description GTTP is a nearly stateless protocol. Its protocol data units ride directly over IP. GTTP supports two message types. These are the TraceProbe and the TraceResponse. 4.2.1. Discovering the Top-Level Path In the example above, the application sends one TraceProbe to discover H0, another TraceProbe to discover H1, and a third TraceProbe to discover H2. Each TraceProbe elicits a TraceResponse and each TraceResponse identifies a top-level hop by IP address. (This information is identical to that which the traditional traceroute application provides). The application sends the first TraceProbe to D1, in order to discover H1. The TraceProbe contains the following information: 1) An Identifier, used to match the TraceProbe with a TraceResponse 2) The application's IP address 3) The IP address of the head-end of the traced path (i.e., D1's loopback address) 4) The IP address of the tail-end of the traced path (i.e., D4's loopback address) 5) A top-level hop number. The top-level hop number identifies the hop about which the application is requesting information by its distance from the head-end of the traced path. In this case, the value "1" represents the first top-level hop (i.e., H0). 6) A Hop Pointer. As the current TraceProbe does not elicit tunnel details, the value of this Hop Pointer is equal to 0xff. 7) An optional access control object D1 receives the TraceProbe Message. If D1 does not support GTTP, it sends D0 an ICMP Destination Unreachable Message. The Destination Unreachable Messages specifies that D1 does not support GTTP. If the application receives this ICMP message, it terminates. If D1 supports GTTP, it determines whether access control policy permits it to honor the request. D1 makes this determination based upon its configuration and the contents of the optional access control object. If access control policy does not permit D1 to honor the request, D1 sends the application a TraceResponse Message indicating that the application lacks required access control credentials. If D1 honors the request, it stores the entire TraceProbe in memory. Having stored a copy of the TraceProbe, D1 submits it to the IP module for delivery to D4. D1 specifies a TTL value that is equal to the TraceProbe's top-level hop number (i.e., equal to one). D2 decrements the TTL to 0, discards the TraceProbe Message, and sends D1 an ICMP Time Expired Message. The ICMP Time Expired Message contains the first eight octets of the discarded TraceProbe. As these eight octets contain the TraceProbe Identifier and the application's IP address, D1 can match the ICMP message with a TraceProbe image that it has stored in memory. The ICMP message's source address identifies H0 by IP address. Next, D1 formats a TraceResponse, sends it to the application, and discards its memory image of the TraceProbe. The application has now discovered the IP address associated with H0. In order to discover the IP address associated with H1, the application sends yet another TraceProbe to D1. This TraceProbe is identical to the first, except that the top-level hop number is equal to two. The network processes this request exactly as described above. The TraceProbe elicits a TraceResponse and the TraceResponse identifies H1 by IP address. The TraceResponse does not indicate that a tunnel supports H1 and it does not reveal tunnel details. Finally, the application sends a third TraceProbe to D1, with the top-level hop number equal to three. D1 relays this TraceProbe to D4. This time, the TraceProbe reaches D4. If D4 does not support GTTP, D4 sends D1 an ICMP Destination Unreachable Message. The Destination Unreachable Message indicates that D4 does not support GTTP. If the D1 receives this ICMP message, it matches the ICMP message with a TraceProbe message that it has stored in memory. The ICMP message's source address identifies H2 by IP address. If D4 supports GTTP, D4 sends D1 a TraceResponse message. D4 matches the TraceResponse with a TraceProbe message that it has stored in memory. The TraceResponse Message's source address identifies H2 by IP address. In either case, D1 formats a TraceResponse Message and sends it to the application. 4.2.2. Determining Whether Tunnels Support Top-Level Hops At this point, the application has identified H0, H1 and H2 by IP address. Now it must determine whether tunnels support any of these hops. In order to determine whether a tunnel supports H0, the application sends another TraceProbe to D1. This TraceProbe contains the following information: 1) An Identifier, used to match the TraceProbe with a TraceResponse 2) The application's IP address 3) The IP address of the head end of the traced path (i.e., D1's loopback address) 4) The IP address of the tail end of the traced path (i.e., D4's loopback address) 5) A Hop Object. 6) A Hop pointer, initially equal to zero. 7) An optional access control object The Hop Object identifies the following: 1) The hop about which the application is requesting tunnel details (i.e., H0, identified by the IP address of its tail-end interface) 2) Any interface local to the device at the head-end of the hop (i.e., D1's loopback address) 3) The level to which the hop is subordinate to the top-level path. (Since H0 is part of the top-level path, the subordination level is equal to 1). 4) The TTL value. If a tunnel supports the hop, the TTL value determines which tunnel segment GTTP will discover. D1 receives the TraceProbe and determines whether access control policy permits it to honor the request. If access control policy does not permit D1 to honor the request, D1 sends the application a TraceResponse Message indicating the application lacks required access control credentials. If D1 honors the request, it searches for a Hop Object whose subordination level is greater than the value of the hop pointer by 1. If D1 does not find such a Hop Object, it returns a TraceResponse Message to the application, indicating that the TraceProbe was malformed. If D1 finds such a Hop Object and the Hop Object indicates that D1 is the hop's head-end, D1 increments the hop pointer and processes the message locally. Hence, D1 determines that no traceable tunnel supports H0. D1 formats a TraceResponse Message and returns the TraceResponse message to the application. Now, the application must determine whether a tunnel supports H1. Again, the application sends a TraceProbe to D1. This time, the Hop Object identifies H1 as the interface in question. It also identifies H1's head end device by the interface to which H0 is the tail end. Furthermore, it specifies a tunnel specific TTL value of 1. Having received the TraceProbe, D1 finds a Hop Object whose subordination level is greater than the hop pointer value by one. It increments the hop pointer and forwards the TraceProbe to the head end device identified by that Hop Object (i.e., D2). D2 receives the TraceProbe, exercises access control, and determines that it is the hop's head end device. D2 consults its FIB and determines that an IP-in-IP tunnel supports H1. Therefore, it executes a tunnel specific procedure to identify the first hop in the tunnel (H1:0). As an IP-in-IP tunnel supports H1, the tunnel specific procedure resembles that described in Section 4.2.1. D2 stores the TraceProbe Message, elicits an ICMP Time Expired message from D5 and matches the ICMP Time Expired Message with the stored TraceProbe Message. Having aggregated information from these two messages, D2 formats a TraceResponse Message that provides information regarding H1:0. D2 forwards the TraceResponse Message to D1 and discards its memory image of the TraceProbe. D1 relays the TraceResponse Message to the application. The application sends two more TraceProbe Message, eliciting information regarding H1:1 and H1:2. The TraceResponse Message describing H1:2 indicates that H1:2 is the final member of tunnel H1. Finally, the application sends another TraceProbe Message. This TraceProbe Message elicits details concerning H2. The corresponding TraceResponse Message indicates that no tunnel supports H2. 4.2.3. Determining Whether Tunnels Support Tunnel Hops The procedure described in Section 4.2.2 can be applied recursively to determine whether tunnels support tunnel hops. For example assume that the application must determine whether tunnels support H1:0, H1:1 or H1:2. In order to determine whether a tunnel supports H1:0, the application sends another TraceProbe Message to D1. The TraceProbe Message contains the following information: 1) An Identifier, used to match the TraceProbe with a TraceResponse 2) The application's IP address 3) The IP address of the head end of the traced path (i.e., D1's loopback address) 4) The IP address of the tail end of the traced path (i.e., D4's loopback address) 5) Two Hop Objects. 6) A hop pointer, initially equal to zero. 7) An optional access control object The first Hop Object identifies H1. The second Hop Object identifies H1:0. D1 receives the TraceProbe, increments the hop pointer and relays the TraceProbe to D2. D2 receives the TraceProbe processes it. It formats a TraceResponse Message indicating that no tunnel supports H1:0 and sends the message to D1. D1 relays the message to the application. Now, the application sends D1 another TraceProbe message to determine whether any tunnels support H1:1. This TraceProbe Message is identical to the previous, except that the second Hop Object identifies H1:1. D1 receives the TraceProbe, increments the hop pointer and relays it to D2. D2 receives the TraceProbe, increments the hop pointer and relays it to D5. D5 executes tunnel a tunnel specific procedure to discover H1:1:0. D5 originates a TraceResponse Message that describes H1:1:0. D5 sends the message to D2, D2 relays the message to D1, and D1 relays the message to the application. 5. Protocol Mechanisms 5.1. Transport GTTP rides directly over IP. 5.2. Message Formats The following subsections detail GTTP Message Formats. 5.2.1. The TraceProbe Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Hop Pointer | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head End Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail End Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Top-level Hop | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Objects . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The TraceProbe Message Figure 2 depicts the TraceProbe Message. Applications send the TraceProbe Message in order to solicit details about a hop that is contained by a traced path. The following paragraphs describe each field that contributes to the TraceProbe Message. Version: 4 bits The Version field specifies the GTTP Message format. Value is equal to 1. Type: 4 bits The Type field specifies the GTTP message type. A value of 0 identifies a TraceProbe Message. Hop Pointer: 8 bits The Hop Pointer references the current Hop Object. TraceProbes that elicit top-level path details contain no Hop Objects. In this case, the Hop Pointer is equal to 0xff. Otherwise, the route- tracing application always sets the Hop Pointer to 1. Selected GTTP entities increment the Hop Pointer value as they relay a TraceProbe to the head end of the hop about which the TraceProbe is requesting details. See Section 5.3.1 for a more complete treatment of this field. Identification: 8 bits The Identification field is used to match TraceProbes with the messages that they elicit. The originator of a TraceProbe should mark each TraceProbe with a relatively unique identifier. Application Address: 32 bits The Application Address identifies the application that originated the TraceProbe by IP address. Head End Address: 32 bits The Head End Address identifies the head end of the top-level path. Tail End Address: 32 bits The Tail End Address identifies the tail end of the top-level path. Checksum: 16 bits The checksum is the 16-bit ones's complement of the one's complement sum of the GTTP message starting with the TraceProbe Version. For computing the checksum, the checksum field should be zero. Length: 16 bits The Length field specifies the length of the TraceProbe Message, beginning with the TraceProbe Version, in octets. Top Level Hop: 8 bits The Top-Level Hop number identifies the top-level hop about the application is requesting details. It identifies this hop by its relative position within the top-level path. To discover details regarding the first top-level hop, specify a value of 1. This value is used only when the Hop Pointer is equal to 0xff. Optional Objects: Variable Length Each optional object must begin on a 32 bit boundary. See the following subsections for optional object details. The Access Control Object 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 | Length | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The Access Control Object Figure 3 depicts the Access Control Object. GTTP entities use the access control object to enforce access control policy. The following paragraphs describe each field that contributes to the access control object. Type: 8 bits The Type field specifies the type of the object that follows. For the Access Control Object, the Type field is always equal to 1. Length : 8 bits The Length Field specifies the length of the object that follows, in octets. For the Access Control Object, the value of the Length field is always equal to 12. AuType: 8 bits The AuType specifies the type of authentication used for this message. Encoding rules follow: 1 = Plaintext password 2 = Cryptographic Authentication Authentication: 64 bits The Authentication field contains authentication data. See Appendix D of [RFC 2328] for a description of this field. The Padding Object 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 | Length | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . . . Figure 4: The Padding Object Figure 4 depicts the Padding Object. Route-tracing applications use the Padding object to extend a TraceProbe to the desired size. The following paragraphs describe each field that contributes to the Padding Object. Type: 8 bits The Type field specifies the type of the object that follows. For the Padding Object, the Type field is always equal to 2. Length : 8 bits The Length Field specifies the length of the object that follows, in octets. The length of the Padding Object must be a multiple of four. Unused: variable length Unused bits must be set to zero. Hop Object 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 | Length | Level | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head End Device | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | Unused + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The Hop Object Figure 5 depicts the Hop Object. Route-tracing applications use the Hop Object to specify the hop about which they are requesting tunnel details. The following paragraphs describe fields that contribute to the Hop Object. In order to trace a tunnel through a tunnel, the TraceProbe message must contain two Hop Object instances. One instance represents the outer tunnel while the other represents the inner tunnel. Type: 8 bits The Type field specifies the type of the object that follows. For the Hop Object, the Type field is always equal to 3. Length: 8 bits The Length Field specifies the length of the object that follows. For the Hop Object, the value of the Length field is always equal to 16. Level: 4 bits The Level field specifies the level to which the current hop is subordinate to the top-level path. Head-end Device: 32 bits The Head-end Device field identifies the hop's head-end device by the IP address of any of its interfaces. Hop Address: 32 bits The Hop Address field identifies the hop about which the TraceProbe is requesting tunnel details by IP address. TTL: 8 bits The TTL field identifies a segment of the tunnel that supports the hop. GTTP will return details concerning that segment. 5.2.2. The TraceResponse Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | TunnelPtr | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | Flags | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Objects . . . . . . . Figure 6: The TraceResponse Message Figure 6 depicts the TraceResponse Message. The TraceResponse Message describes a hop that is contained by a traced path. The following paragraphs describe each field that contributes to the TraceResponse Message. Version: 4 bits The Version field indicates the GTTP Message format. Value is equal to 1. Type: 4 bits The Type field specifies the GTTP message type. A value of 1 identifies a TraceResponse Message. TunnelPtr: 8 bits The TunnelPtr references the current Tunnel Object. See Section 5.3 for a more complete treatment of this field. Identification: 8 bits The Identification field is used to match the TraceResponse with the message that elicited it. Application Address: 32 bits The Application Address identifies the application that originated the TraceProbe by IP address. Hop Address: 32 bits The Hop Address identifies a member of the top-level path by IP address. Checksum: 16 bits The checksum is the 16-bit ones's complement of the one's complement sum of the GTTP message starting with the GTTP Version. For computing the checksum, the checksum field should be zero. Length: 16 bits The Length field specifies the length of the GTTP Message, beginning with the GTTP version, in octets. Flags: 4 bits The first bit of the Flags field indicates whether the Code field contains a GTTP error code or an ICMP error code. If it is set, the Code field code field contains a value defined by GTTP. If it is clear, the Code field contains a value that is to be defined by the ICMP Destination Unreachable Message. The second bit of the Flags field indicates whether the current hop terminates the top-level path. If the bit is set, the current hop terminates the top-level path. The remaining Flag bits must be set to zero. Code: 8 bits The Code field contains either an ICMP code or a GTTP code. The following values reflect GTTP codes: 1 = No error 2 = Permission denied 3 = Malformed TraceProbe Optional Objects: Variable Length Each Optional Object must begin on a 32 bit boundary. See the following subsections for optional object details. The Tunnel Object 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 | Length | Flags | Tunnel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Ingress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Egress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Hop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name Length | ID Length | Level | Unused + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: The Tunnel Object Figure 7 depicts the Tunnel Object. GTTP entities use the Tunnel object to return tunnel details regarding specific hops. When tracing tunnels within tunnels, the TraceResponse Message will contain multiple Tunnel Objects, with one Tunnel Object representing each tunnel layer. GTTP entities will use information contained by these Tunnel Objects as they relay the TraceResponse Message to its destination. The following paragraphs describe fields that contribute to the tunnel object. Type: 8 bits The Type field specifies the type of the object that follows. For the Tunnel Object, the Type field is always equal to 4. Length: 8 bits The Length Field specifies the length of the object that follows. For the Tunnel Object, the value of the Length field is always equal to a multiple of four. Flags: 8 bits The Flags field contains binary values. The leftmost bit is set if the hop identified by the Hops field terminates the tunnel. Tunnel Type: 8 bits The Tunnel Type field identifies the type of tunnel that supports the current hop. Encoding rules follow: 1 = No tunnel 2 = MPLS LSP 3 = GRE 4 = IPSEC 5 = IP-in-IP Tunnel Ingress: 32 bits The Tunnel Ingress field identifies the tunnel ingress by IP address. Tunnel Egress: 32 bits The Tunnel Egress field identifies the tunnel egress by IP address. Tunnel Hop: 32 The Tunnel Hop field identifies a specific hop contained by the tunnel by IP address. Tunnel Name Length: 8 bits The Tunnel Name Length field specifies the number of octets used in the Tunnel Name Field. Tunnel ID Length: 8 bits The Tunnel ID Length field specifies the number of octets used in the Tunnel ID field. Level: 8 bits The Level field identifies the level to which the current tunnel is subordinate to the top-level path. Tunnel Name: Variable The Tunnel Name field contains the name of a discovered tunnel. The length of this field must be a multiple of four. Its value can be padded with zeros. Tunnel ID: Variable The Tunnel ID field contains an optional identifier for a discovered tunnel. The length of this field must be a multiple of four. Its value can be padded with zeros. 5.2.3. Common Objects The following section describes objects that are common to the TraceProbe and TraceResponse Messages. The Timestamp Object 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 | Length | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: The Timestamp Object Figure 8 depicts the Timestamp Object. GTTP entities use the Timestamp Object to estimate round trip delay. The following paragraphs describe each field that contributes to the Timestamp Object. Type: 8 bits The Type field specifies the type of the object that follows. For the Timestamp Object, the Type field is always equal to 5. Length : 8 bits The Length Field specifies the length of the object that follows. For the Timestamp Object, the value of the Length field is always equal to 12. Time Sent: 32 bits The Time Sent field reflects the time at which the device at head end of the top-level path last touched the TraceProbe. The Time Sent Field measures time in number of milliseconds since midnight, UTC. Time Received: 32 Bits The Time Received Object reflects the time at which the device at head end of a top-level path received a TraceResponse Message. The Time Received Message measures time in number of milliseconds since midnight, UTC. 5.3. Message Processing 5.3.1. The TraceProbe Message Applications send TraceProbe messages in order to solicit routing details. Applications respond to the TraceProbe Message as follows: Trace the top-level path: Routers take this action if the Hop Pointer is equal to 0 and the TraceProbe Head-end Address is local to the router. Return a TraceResponse Message indicating that the TraceProbe has reached its termination point: Routers take this action if Hop Pointer is equal to 0 and the TraceProbe Tail-end address is local to the router. Routers also take this action if the Hop Pointer is greater than 0 and the TraceProbe's most subordinate Hop Object specifies a local interface as its tail. Increment the Hop Pointer and Forward Downstream: Routers take this action if the Hop Pointer is greater that 0 and current Hop Option specifies a head-end that is reachable but not local. Execute a tunnel specific tracing procedure: Routers take this action if the Hop Pointer is greater than 0 and the current Hop Object specifies a local head-end. Return a TraceResponse Message indicating that an error has occurred: Routers take this action if none of the above conditions apply. 5.3.2. The TraceResponse Message GTTP relays TraceResponse messages upstream, to the application that originated the TraceProbe. The procedure for relaying messages is the inverse of that described in Section 5.3.1. 5.4. Tunnel Specific Tracing Proceedures The following subsections detail tunnel specific tracing procedures. 5.4.1. MPLS The tunnel head-end device stores a copy of the TraceProbe Message, and submits it to the IP module for delivery to the tunnel tail-end device (e.g., the egress LSR). The head-end device specifies a TTL value that is equal to the hop number obtained from the relevant Hop Object. It also specifies that the MPLS TTL value must be equal to the IP TTL value. The head end device then waits for one of the following: 1) a TraceResponse Message 2) an ICMP Time Exceeded Message 3) an ICMP Destination Unreachable Message specifying that the destination does not support GTTP. In any case, the head-end matches the response to a stored TraceProbe and originates a TraceResponse Message. It then deletes its copy of the TraceProbe Message. 5.4.2. IP-in-IP The tunnel head-end device stores a copy of the TraceProbe Message, and submits it to the IP module for delivery to the tunnel tail-end device. The head-end device specifies a TTL value that is equal to the hop number obtained from the relevant Hop Object. It also specifies that the outer TTL value must be equal to the inner IP TTL value. Furthermore, it specifies that the Identification field in the outer IP header should be equal to that obtained from the TraceProbe. The head end device then waits for one of the following: 1) a TraceResponse Message 2) an ICMP Time Exceeded Message 3) an ICMP Destination Unreachable Message specifying that the destination does not support GTTP. In Any case, the head-end matches the response to a stored TraceProbe and originates a TraceResponse Message. It then deletes its copy of the TraceProbe Message. 5.4.3. Others TBD 6. IANA Guidelines Protocol code points [RFC-2434]. 7. Security Considerations The following are security considerations: 1) GTTP must enforce access control policy before disclosing any information. 2) GTTP must never yield multiple messages in response to a single message. 3) When tracing through encrypted tunnels, GTTP must never deliver the cipher-text equivalent of user provided data. 4) GTTP entities should rate limit messages that it sends and receives 5) GTTP entities should discard TraceProbe messages that they have stored for more that a few seconds. 8. References [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 2026, Harvard University, October 1996. [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP Tools and Utilities, RFC 2151, Hill Associates, Inc., June 1997 [RFC-2328], Moy, J., OSPF Version 2, April, 1998. [RFC-2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October, 1998. [RFC-2637] Hamzeh, K. et. al., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July, 1999. [TUNREQ] Bonica, R., Kompella, K., Meyer, D., Tracing Requirements for Generic Tunnels, draft-bonica-tunneltrace-00.txt, December 2000. 9. Acknowledgements Thanks to Randy Bush, Tricci So and Beth Alwin for their comments. 10. Author's Addresses Ronald P. Bonica WorldCom 22001 Loudoun County Pkwy Ashburn, Virginia, 20147 Phone: 703 886 1681 Email: rbonica@mci.net Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089 Email: kireeti@juniper.net Dave Myers Cisco Systems 170 Tasman Drive San Jose, California 94025 Email: dmm@cisco.com Rohit Dube Xebeo Communications Inc. 1 Cragwood Road, Suite 100 South Plainfield, NJ 07080 Email: rohit@xebeo.com 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.