Internet Draft R. Bonica
Expiration Date: January 2002 WorldCom
E. Rosen
Cisco Systems
K. Kompella
Juniper Networks
D. Meyer
Sprint
R.Dube
Xebeo Communications
July 2001
Generic Tunnel Tracing Protocol (GTTP) Specification
draft-bonica-tunproto-01.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. Network operators
use enhanced route-tracing applications to trace through an IP
network's forwarding plane (including the MPLS forwarding plane).
Enhanced route-tracing applications also reveal details regarding IP
and MPLS tunnels that contribute to the traced path.
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. Network operators
use enhanced route-tracing applications to trace through an IP
network's forwarding plane (including the MPLS forwarding plane).
Enhanced route-tracing applications also reveal details regarding IP
and MPLS tunnels that contribute to traced path. A companion document
[TUNREQ] specifies requirements for enhanced route-tracing
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|
-----
|
| - H1 - H2 - H3 -
(IP) -|D|----|D|-------------------------------------|D|----|D|
|1| |2| H2:1 - H2:2 - H2:3 |3| |4|
(IP) | | | |------|D|-------------------|D|------| | | |
- - |5| H2:2:1 - H2:2:2 |6| - -
(MPLS) | |--------|D|--------| |
- |7| -
| |
-
Figure 1: Tunnel Tracing Problem
Figure 1 depicts eight IP accessible devices (D0 through D7). A
route-tracing application executes upon device D0. The route-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 (TLH) .
These are H1, H2 and H3. An IP-in-IP tunnel supports H2. The IP-in-IP
tunnel itself contains three hops. These hops, H2:1, H2:2 and H2:3,
are subordinate to H2. Finally, an MPLS LSP supports H2:2. The LSP
contains two hops, H2:2:1 and H2:2:2.
4.2. Informal Protocol Description
GTTP supports two PDU types. These PDUs represent a TraceProbe and a
TraceResponse. Route-tracing applications emit a series of
TraceProbes in order to obtain information regarding the path that
connects two network interfaces. Specifically, route-tracing
applications emit one TraceProbe to discover each hop that
contributes to the traced path.
Each TraceProbe elicits exactly one TraceResponse. Each TraceResponse
reveals details concerning one hop that contributes to the traced
path. That hop may represent a TLH or part of a subordinate tunnel.
The User Datagram Protocol (UDP) carries all GTTP traffic. IANA will
assign a UDP port to GTTP. Route-tracing applications will direct all
TraceProbes to this well-known port and network elements will listen
for GTTP traffic on this well-know port only. Route-tracing
applications will listen for TraceResponses on a non-well-known port
that they will specify in the corresponding TraceProbe's UDP source
address.
UDP obtains network layer services from IP. IP datagrams that carry
GTTP MUST NOT specify IP options.
4.3. Discovering the Top-Level Path
In the example above, the route-tracing application sends one
TraceProbe to discover H1, another TraceProbe to discover H2, and a
third TraceProbe to discover H3. Each TraceProbe elicits a single
TraceResponse and each TraceResponse provides details regarding a
single TLH.
The application sends its first TraceProbe to D1, in order to
discover H1. The TraceProbe contains the following information:
1) The IP address of the route-tracing application
2) A Sequence Number, used to match TraceProbes with
TraceResponses
3) An IP address that identifies the head-end of the traced path
(i.e., D1's loopback address)
4) A Path Identifier Object (PIO). In its simplest form, the Path
Identifier Object identifies the traced path by its destination
address (i.e., D4's loopback address). In a more complex form,
the PIO identifies the traced path based upon an incoming
interface (or sub-interface), a tunnel header (e.g. MPLS header),
and an IP header.
5) A TLH Identifier. The TLH identifier identifies the TLH about
which the application is requesting information. In this case, the
value "1" represents the first TLH (i.e., H1).
6) A Tunnel Hop Identifier. As this probe solicits TLH details,
this value is equal to zero.
7) An optional Access Control Object (ACO)
D1 receives the TraceProbe, removes its IP and UDP headers, and
delivers it to a local GTTP module. The GTTP module examines the
TraceProbe ACO in order to determine whether local security policy
permits it to process the probe. If security policy does not permit
the GTTP module to service the probe, D1 can either silently discard
the TraceProbe or send D0 a TraceResponse, indicating insufficient
privilege, as per local security policy.
If security policy permits the GTTP module to process the probe, the
GTTP module examines the TraceProbe and determines that it is
soliciting details regarding a downstream TLH. Therefore, the GTTP
module relays the TraceProbe downstream. First, if required by PIO
size specifications, the GTTP module pads the TraceProbe. Next, the
GTTP module encapsulates the TraceProbe in a UDP header.
The GTTP module then encapsulates the UDP packet in an IP header. The
IP header contains information specified by the original TraceProbe's
PIO. The GTTP module then copies the original TraceProbe's TLH
Identifier to the IP header TTL field and recalculates the IP header
checksum. D1 then forwards the TraceProbe downstream as per all PIO
specifications. (Note that the Layer 2 interface and tunnel upon
which a datagram might arrive can contribute to PIO specifications.)
In our example, D1 forwards the TraceProbe through H1 to D2. D2
decrements the TTL value to 0 and forwards the datagram to an error-
processing module. The error-processing module sends an ICMP Time
Expired Message to D1. D1 discards this ICMP message.
The error-processing module then forwards the TraceProbe to a local
GTTP module. The GTTP module examines the TraceProbe ACO in order to
determine whether local security policy permits it to process the
probe. If security policy does not permit the GTTP module to service
the probe, the GTTP module silently discards the TraceProbe.
If security policy permits the GTTP module to process the probe, the
GTTP module examines the TraceProbe and determines that it is
soliciting details regarding a directly connected, upstream TLH.
Therefore, D2 sends D0 a TraceResponse. The TraceResponse contains
the following information:
1) The IP address of the route-tracing application
2) A Sequence Number, used to match TraceProbes with TraceRespones
3) An IP address identifying the interface upon which the
TraceProbe arrived. If the TraceProbe arrived on an unnumbered
interface, this IP address will not uniquely identify the
interface upon which the TraceProbe arrived
4) The MIB-II ifDescr value associated with the interface upon
which the TraceProbe arrived. This value, in conjunction with the
IP address mentioned above, SHOULD uniquely identify the interface
upon which the datagram arrived.
5) A Tunnel Security Status (TSS). This value indicates whether
local security policy permits GTTP to reveal tunnel details.
6) A Tunnel Identifier Object (TIO). The TraceResponse contains a
TIO if security policy permits GTTP to reveal tunnel details and
if the TraceProbe was encapsulated in a tunnel header when it
arrived at the probed node.
The TIO contains several data items. One data item represents the
type of the outermost tunnel (e.g., IP-in-IP, MPLS). Another data
item represents the entire tunnel header stack, as it encapsulated
the TraceProbe when it arrived at the probed network element.
Another data item represents a tunnel identifier that is shared
between the tunnel ingress and tunnel egress nodes. (This data
item is empty when the tunneling mechanism does not support such a
shared identifier).
7) Egress Indicator. This field indicates whether the
TraceResponse was sent by the tail-end of the traced path. The
GTTP module sets this Egress Indicator if the tail-end of the
traced path, as specified by the PIO, is a local interface.
8) An Optional Access Control Object (ACO). This object is copied
from the TraceProbe.
D0 receives the TraceResponse and processes it if the ACO matches
that which was sent in the corresponding TraceProbe. D0 repeats the
procedure described above, incrementing the TLH identifier in order
to discover each subsequent TLH. Specifically, D0 sends each
TraceProbe to D1 and D1 probes the traced path. D0 repeats this
process until it receives a TraceResponse from the tail-end of the
traced path.
Local policy determines how many times D0 should probe each hop. It
also determines how long D0 should wait for a response to each probe
and the maximum number of probes that D0 should send in order to
trace a given path.
In order to trace the top-level path accurately, D2 must be
configured so that it sets TTL value specified by the outer header of
its IP-in-IP tunnel to an appropriately high value.
4.4. Discovering First Order Tunnel Details
At this point, the network has revealed details regarding H1, H2 and
H3. D3 also has provided cursory information regarding the IP-in-IP
tunnel that supports H2. D2 and D4, however, have provided no
information regarding tunnels that might support H1 and H3.
Even though D2 and D4 returned a TraceProbe that did not include a
TIO, tunnels may support H1 and H3. For example, an MPLS LSP that
engages in penultimate hop popping may support H1. In this case, a
TraceProbe would arrive at D2 without an MPLS header and D2 would
return a TraceResponse that does not include a TIO.
Therefore, the route-tracing application must probe D1, D2 and D3 for
details regarding tunnels that might support H1, H2 and H3,
respectively. The route-tracing application begins by sending a
TraceProbe to D1. The TraceProbe contains the following information:
1) The IP address of the route-tracing application
2) A Sequence Number, used to match TraceProbes with
TraceResponses
3) An IP address that identifies the head-end of the traced tunnel
(i.e., D1's loopback address)
4) A Path Identifier Object (PIO). This PIO contains values
identical to those that were sent to D1 while tracing the top-
level path.
5) A TLH Identifier. As this TraceProbe solicits tunnel details,
the TLH identifier is equal to zero.
6) A Tunnel Hop Identifier. The Tunnel Hop Identifier represents a
tunnel hop about which the current TraceProbe is soliciting
details. In this case, a value of 1 represents the first hop in a
tunnel that might support H1.
7) An optional Access Control Object (ACO)
D1 receives the TraceProbe, removes its IP and UDP headers, and
delivers it to a local GTTP module. The GTTP module examines the
TraceProbe ACO in order to determine whether local security policy
permits it to process the probe. If security policy does not permit
the GTTP module to service the probe, the D1 can either silently
discard the TraceProbe or send D0 a TraceResponse, indicating
insufficient privilege, as per local security policy.
If security policy permits the GTTP module to process the probe, the
GTTP module examines the TraceProbe and determines that it is
soliciting details regarding the first hop of a particular downstream
tunnel. (The GTTP module makes this determination based upon the
Tunnel Hop Identifier value). Therefore, D1 queries its routing
information and determines that no tunnel supports H1. Having made
this determination, D1 sends D0 a TraceResponse message that does not
include a TIO.
D0 receives the TraceResponse and processes it if the ACO matches
that which was sent in the corresponding TraceProbe. Having processed
this TraceResponse, D0 is informed that no tunnel supports H1.
D0 now probes D2, soliciting details concerning the tunnel that
supports H2. Specifically, D0 sends D2 a TraceProbe. The TraceProbe
contains the following information:
1) The IP address of the route-tracing application
2) A Sequence Number, used to match TraceProbes with
TraceResponses
3) An IP address that identifies the head-end of the traced tunnel
(i.e., D2's loopback address)
4) A Path Identifier Object (PIO). The PIO contains the same IP
header that all previously mentioned PIOs contained. The route-
tracing application augments this information information that was
obtained from D2 while discovering the top-level path. For
example, while discovering the top-level path, the the route-
tracing application learned that D2 received its TraceProbe from a
particular sub-interface. The route-tracing application specifies
this sub-interface in the PIO when probing D2 for H2 tunnel
details.
5) A TLH Identifier. As this TraceProbe solicits tunnel details,
the TLH identifier is equal to zero.
6) A Tunnel Hop Identifier. The Tunnel Hop Identifier represents a
tunnel hop about which the current TraceProbe is soliciting
details. In this case, a value of 1 represents the first hop in a
tunnel that might support H2.
7) An optional Access Control Object (ACO)
D2 receives the TraceProbe, removes its IP and UDP headers, and
delivers it to a local GTTP module. The GTTP module examines the
TraceProbe ACO in order to determine whether local security policy
permits it to process the probe. If security policy does not permit
the GTTP module to service the probe, the D2 can either silently
discard the TraceProbe or send D0 a TraceResponse, indicating
insufficient privilege, as per local security policy.
If security policy permits the GTTP module to process the probe, the
GTTP module examines the TraceProbe and determines that it is
soliciting details regarding the first hop of a particular downstream
tunnel. (The GTTP module makes this determination based upon the
Tunnel Hop Identifier value). Therefore, D2 queries its routing
information and determines that an IP-in-IP tunnel supports H2.
D2 then executes a tunnel specific tracing procedure. In this
particular case, D2 encapsulates the TraceProbe in a UDP header. It
then encapsulates the UDP packet in the IP header that is specified
by the PIO. It sets the IP TTL value to 1 and recalculates the
checksum. Finally, D2 encapsulates the IP header in another IP
header. The outer IP header represents the IP-in-IP tunnel. Its
source address represents the tunnel ingress and its destination
address represents the tunnel egress. D2 copies the Tunnel Hop
Identifier to the outer header TTL field and recalculates the outer
checksum. Finally, D2 forwards the encapsulated TraceProbe.
In our example, D2 forwards the TraceProbe through H2:1 to D5. D5
decrements the outer TTL value to 0 and forwards the datagram to an
error-processing module. The error-processing module sends an ICMP
Time Expired Message to D2. D2 discards this ICMP message.
The error-processing module then forwards the TraceProbe to a local
GTTP module. The GTTP module examines the TraceProbe ACO in order to
determine whether local security policy permits it to process the
probe. If security policy does not permit the GTTP module to service
the probe, the GTTP module silently discards the TraceProbe.
If security policy permits the GTTP module to process the probe, the
GTTP module examines the TraceProbe and determines that it is
soliciting details regarding a directly connected, upstream tunnel
hop. Therefore, D5 sends D2 a TraceResponse. The TraceResponse
contains the following information:
1) The IP address of the route-tracing application
2) A Sequence Number, used to match TraceProbes with TraceRespones
3) An IP address identifying the interface upon which the
TraceProbe arrived. If the TraceProbe arrived on an unnumbered
interface, this IP address will not uniquely identify the
interface upon which the TraceProbe arrived
4) The MIB-II ifDescr value associated with the interface upon
which the TraceProbe arrived. This value, in conjunction with the
IP address mentioned above, SHOULD uniquely identify the interface
upon which the datagram arrived.
5) A Tunnel Security Status (TSS). This value indicates whether
local security policy permits GTTP to reveal tunnel details.
6) A Tunnel Identifier Object (TIO). The TIO contains several
data items. One data item represents the type of the outermost
tunnel (i.e., IP-in-IP). Another data item represents the entire
tunnel header stack, as it encapsulated the TraceProbe when it
arrived at the probed network element. Another data item
represents a tunnel identifier that is shared between the tunnel
ingress and tunnel egress nodes. (In this case, the identifier is
a 64 bit value, with the first 32 bits representing the IP address
of the tunnel ingress and the remaining 32 bits representing the
IP address of the tunnel egress).
7) Egress Indicator. This field indicates whether the
TraceResponse was sent by the tail-end of the traced tunnel. The
GTTP module sets this Egress Indicator if the tail-end of the
traced tunnel is a local interface.
8) An Optional Access Control Object (ACO). This object is copied
from the TraceProbe.
D2 receives the TraceResponse and relays it to the route-tracing
application on D0. Having processed this TraceResponse, the route-
tracing application has acquired H2:1 details.
The route-tracing application sends another TraceProbe to D2 in order
to solicit details regarding the second hop of the tunnel that
supports H2. In return, it receives a TraceResponse that describes
H2:2. Next, the route-tracing application sends another TraceProbe to
D2 in order to solicit details regarding the third hop of the tunnel
that supports H2. In response, it receives a TraceResponse that
describes H2:3. This TraceResponse indicates that H2:3 is the final
hop of the tunnel that supports H2.
Finally, the route-tracing application sends a TraceProbe to D3 in
order to determine whether any tunnel supports H3. In return, the
application receives a TraceResponse that does not contain a TIO.
This TraceResponse indicates that no tunnel supports H3.
Local policy determines how many times D0 should probe each tunnel
hop. It also determines how long D0 should wait for a response to
each probe and the maximum number of probes that D0 should send in
order to trace a given tunnel.
In order to trace the the IP-in-IP tunnel accurately, D5 must be
configured so that it sets TTL value specified the MPLS header that
supports H2:2 to an appropriately high value.
4.5. Discovering Order N Tunnel Details
Now D0 probes D2, D5 and D6 in order to determine whether any tunnel
supports H2:1, H2:2 or H2:3. D0 repeats the procedure described
above, this time augmenting the PIO with information obtained while
discovering first layer tunnels.
5. Protocol Mechanisms
5.1. Transport
GTTP rides directly over UDP.
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 | Unused | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head-end Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLH ID | Tunnel Hop ID | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Optional Objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: The TraceProbe Message
Figure 2 depicts the TraceProbe Message. Applications send a
TraceProbe 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.
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.
Application Address: 32 bits
The Application Address identifies the route-tracing application
that originated the TraceProbe by IP address.
Sequence Number: 16 bits
Route-tracing applications use the Sequence Number to match
TraceProbes with TraceResponses.
Length: 16 bits
The Length field specifies the length of the TraceProbe Message,
beginning with the TraceProbe Version, in octets.
Head-end Address: 32 bits
The Head-end Address identifies the head-end of the traced path or
tunnel.
Top Level Hop (TLH) ID: 8 bits
The Top Level Hop (TLD) ID identifies the TLH about which the
TraceProbe is soliciting details. For example, when soliciting
details regarding the first TLH that contributes to a path, the
TLH ID should be equal to 1.
Tunnel Hop ID: 8 bits
The Tunnel Hop ID identifies the tunnel hop about which the
TraceProbe is soliciting details. For example, when soliciting
details regarding the first tunnel hop that contributes to a
tunnel, the Tunnel Hop ID should be equal to 1.
Optional Objects: Variable Length
The ACO, PIO, and Padding Objects may be specified in the
TraceProbe Message. The PIO is mandatory.
Each optional object must begin on a 32 bit boundary. See the
following subsections for optional object details.
All Unused bits must be set to 0.
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 | Flags | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Arrival Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | ifDesc Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifDescr |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Optional Objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The TraceResponse Message
Figure 3 depicts the TraceResponse Message. Network elements send the
TraceResponse Message in order to reveal details concerning a TLH or
tunnel hop. The following paragraphs describe each field that
contributes to the TraceResponse 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 1
identifies a TraceResponse Message.
Flags: 8 bits
The leftmost bit of the Flags field represents the Egress
Indicator. The Egress Indicator bit is set if the path or tunnel
egress device originated the TraceResponse.
The second bit represents the Tunnel Security Status (TSS). The
TSS bit is set if local security policy permits GTTP to reveal
whether a tunnel supports the hop upon which the current
TraceResponse reports.
All unused bits MUST be cleared (i.e., set to zero).
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.
Application Address: 32 bits
The Application Address identifies the route-tracing application
that originated the corresponding TraceProbe by IP address.
Sequence Number: 16 bits
Route-traccing applications use the Sequence Number to match
TraceProbes with TraceResponses.
Length: 16 bits
The Length field specifies the length of the TraceResponse
Message, beginning with the TraceResponse Version, in octets.
Arrival Interface Address: 32 bits
The Arrival Interface Address identifies the interface upon which
the corresponding TraceProbe arrived. If the corresponding
TraceProbe arrived on an unnumbered interface, the Arrival
Interface Address may not uniquely indentify the interface upon
which the corresponding TraceProbe arrived.
Code: 8 bits
The Code represents an error code. The following values are
defined:
0 No Error
1 Insufficient Privilege
2 Malformed TraceProbe
3 No such tunnel
4 No route to destination
5 Communication administratively prohibited
6 Ambiguous PIO
ifDescr Length: 8 bits
The ifDescr Length specifies the number of significant bytes in
the field.
ifDescr: variable Length
The ifDescr field identifies the interface upon which the
corresponding TraceProbe arrived, by name. This value is taken
from the MIB-II ifDesc object. This value, in conjunction with the
Arrival Interface Address, uniquely identifies the interface upon
which the corresponding TraceProbe arrived.
The ifDescr field is zero padded for word alignment.
Optional Objects: Variable Length
The ACO and TIO objects may be specified in the TraceResponse
Message.
Each optional object must begin on a 32 bit boundary. See the
following subsections for optional object details.
5.2.3. 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 4: The Access Control Object
Figure 4 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.
5.2.4. The Path Identifier Object (PIO)
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 | ifDesc Length | Tun Hdr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Hdr Len | Tunnel Type | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Ingress Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Egress Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifDescr |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Stack Header |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Path Identifier Object
Figure 5 depicts the Path Identifier Object (PIO). TraceProbe
Messages use the PIO in order to identify a traced path.
The following paragraphs describe each field that contributes to the
PIO.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the PIO, the Type field is always equal to 2.
Length : 8 bits
The Length field specifies the object length, in octets.
ifDescr Length: 8 bits
The ifDescr Length field specifies the number of significant
octets contained by the ifDescr field.
Tunnel Header Length: 8 bits
The Tunnel Header Length field specifies the number of significant
octets contained by the Tunnel Header field.
IP Header Length: 8 bits
The IP Header Length field represents an IP header that might
encapsulate a datagram.
Tunnel Type: 8 bits
The Tunnel Type field identifies the type of the outermost tunnel
specified in the Tunnel Header. The following values are defined:
0 Undefined
1 GRE
2 MPLS
3 IPSEC
4 IP Optical (IPO)
5 Layer 2 Tunneling Protocol (L2TP)
6 IP-in-IP
7 UTI
Tunnel Ingress Address: 32 bits
When soliciting tunnel details, the Tunnel Ingress address
identifies any interface that is local the the tunnel ingress
node. When soliciting TLH details, the Tunnel Ingress Address is
meaningless.
Tunnel Egress Address: 32 bits
When soliciting tunnel details, the Tunnel Egress address
identifies any interface that is local the the tunnel egress node.
When soliciting TLH details, the Tunnel Egress Address is
meaningless.
ifDescr : variable length
The ifDescr Field identifies the interface or sub-interface upon
which a datagram might arrive, by MIB-II ifDescr. The ifDescr
field can be zero padded for word alignment. This field can be
empty if the incoming interface does not contribute to the routing
decision.
Tunnel Header : variable length
The Tunnel Header Field identifies a tunnel header that might
encapsulate an incoming datagram. The Tunnel Header field can be
zero padded for word alignment. This field can be empty if the
incoming tunnel header does not contribute to the routing
decision.
IP Header : variable length
The IP Header Field identifies a traced path. The Tunnel Type
field can be zero padded for word alignment. The IP Header field
can be zero padded for word alignment. This field must be
specified.
5.2.5. The Tunnel Identification Object (TIO)
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 | Tunnel Type | Tunnel ID Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tun Hdr Len | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Ingress Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Egress Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Header Stack |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Tunnel Identification Object
Figure 6 depicts the Tunnel Identification Object (TIO). The TIO
object describes a tunnel upon which the probed network element
received a TraceProbe.
The following paragraphs describe each field that contributes to the
TIO.
Type: 8 bits
The Type field specifies the type of the object that follows. For
TIO, the Type field is always equal to 3.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in octets.
Tunnel Type: 8 bits
The Tunnel Type field identifies a tunnel type. The following
values are defined:
0 Undefined
1 GRE
2 MPLS
3 IPSEC
4 IP Optical (IPO)
5 Layer 2 Tunneling Protocol (L2TP)
6 IP-in-IP
7 UTI
Tunnel ID Length: 8 bits
The Tunnel ID Length field specifies the number of significant
bits in the Tunnel ID field.
Tun Hdr Len: 8 bits
This field represents the number of significant octets in the
Tunnel Header Stack.
Tunnel Ingress Address: 32 bits
The Tunnel Ingress Address identifies the tunnel ingress, by IP
address. The route-tracing application can send a TraceProbe
Message to this address in order to obtain tunnel details. If the
tail-end device cannot provide this information, it specifies the
address 0.0.0.0.
Tunnel Egress Address: 32 bits
The Tunnel Egress address identifies the tunnel egress, by IP
address. If the tail-end device cannot provide this information, it
specifies the address 0.0.0.0.
Tunnel ID: variable length
The Tunnel ID field identifies the tunnel to its ingress device.
The format of this field is determined by tunnel specific tracing
procedures (defined below). This field is empty when the tunneling
mechanism does not support such an identifier.
Tunnel Header Stack: variable length
This field represents the entire tunnel header stack, as it
encapsulated the TraceProbe when it arrived at the probed node.
5.2.6. 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 7: The Padding Object
Figure 7 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 4.
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.
5.3. Message Processing
5.3.1. The TraceProbe Message
Having received a TraceProbe Message, the GTTP module must examine
TraceProbe's ACO in order to determine whether local security policy
permits it to process the probe. If security policy does not permit
the GTTP module to service the probe, the GTTP module can either
silently discard the TraceProbe or send route-tracing application a
TraceResponse, indicating insufficient privilege, as per local
security policy.
If local security policy permits the GTTP module to process the
probe, the GTTP module must determine which of the following is true:
1) The TraceProbe is soliciting details concerning a downstream
TLH. This condition is true if the TLH Identifier is greater than
zero and the head-end of the traced path is a local interface and
the tail-end of the traced path is not a local interface.
2) The TraceProbe is soliciting details concerning a directly
connected upstream TLH. This condition is true if the TLH
Identifier is greater than zero and the head-end of the traced
path is a not local interface.
3) The TraceProbe is soliciting details concerning a tunnel for
which the local node serves as igress. This condition is true if
the Tunnel Hop Identifier is greater than zero and the head-end of
the traced tunnel is a local interface.
4) The TraceProbe is soliciting details concerning a directly
connected upstream tunnel hop. This condition is true if the
Tunnel Hop Identifier is greater than zero and the head-end of the
traced tunnel is not a local interface.
If the first condition is true, the GTTP module relays the TraceProbe
downstream. First, if required by PIO specifications, the GTTP module
pads the TraceProbe Message. Next, the GTTP module encapsulates the
TraceProbe Message in a UDP header.
The GTTP module then encapsulates the UDP packet in an IP header. The
IP header contains all of the information specified by the original
TraceProbe's PIO. The GTTP module then copies the original
TraceProbe's TLH Identifier to the IP header TTL field and
recalculates the IP header checksum. The GTTP module then forwards
the TraceProbe downstream as per all PIO specifications.
If the second condition is true, the GTTP module formats a
TraceResponse and sends it to the route-tracing application.
If the third condition is true, GTTP executes a tunnel specific
tracing procedure. The tunnel specific tracing procedure elicits a
TraceResponse message that describes a hop of the traced tunnel.
Tunnel specific tracing procedures are described in a later
paragraph.
If the fourth condition is true, the GTTP module formats a
TraceResponse and sends it to the head-end of the traced tunnel.
5.3.2. The TraceResponse Message
Having received a TraceResponse Message, the GTTP module examines the
TraceResponse ACO in order to determine whether local security policy
permits it to process the probe. If security policy does not permit
the GTTP module to service the probe, the the GTTP module silently
discards the TraceResponse.
If security policy permits the GTTP module to process the response,
the GTTP module relays the TraceResponse to the route-tracing
application.
5.4. Tunnel Specific Tracing Proceedures
The following subsections detail tunnel specific tracing procedures.
5.4.1. TTL Aware Tunnels
The GTTP module encapsulates the TraceProbe in a UDP header. It then
encapsulates the UDP packet in the IP header that is specified by the
PIO. It sets the IP TTL value to 1 and recalculates the checksum.
Finally, the GTTP module encapsulates the IP header in tunnel header
(e.g., MPLS shim header). Finally, the GTTP module copies the Tunnel
Hop Identifier to the tunnel header TTL field and recalculates the
tunnel checksum (if required). Finally, the GTTP module forwards the
encapsulated TraceProbe.
5.4.2. Other Tunnel Types
TBD
6. IANA Guidelines
IANA will assign a UDP port to GTTP [RFC-2434].
7. Security Considerations
The following are security considerations:
1) GTTP MUST enforce access control policy before disclosing any
information.
2) GTTP MUST NOT yield multiple TraceResponses in response to a
single TraceProbe.
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 they send and
receive.
5) When the device at the head-end of a traced path generates a
TraceProbe, it MUST identify a local address in that messages IP
Source Address field.
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-02.txt, July 2002.
9. Acknowledgements
Thanks to Randy Bush, Philip Matthews, 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: ronald.p.bonica@wcom.com
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, Massachusetts, 01824
E-mail: erosen@cisco.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, California 94089
Email: kireeti@juniper.net
Dave Myers
Sprint E|Solutions
12502 Sunrise Valley Drive
Reston, Virginia 20191
Email: dmm@sprint.net
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 (2001). 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.