idnits 2.17.1 draft-ietf-ccamp-tunproto-01.txt: -(517): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 178 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 7162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1359, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1370, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2151 (ref. '4') ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 3609 (ref. '7') Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group R. Bonica 3 Internet-Draft MCI 4 Expires: March 2, 2005 E. Rosen 5 D. Meyer 6 Cisco Systems 7 K. Kompella 8 Juniper Networks 9 R. Dube 10 Xebeo Communications 11 September 2004 13 Generic Tunnel Tracing Protocol (GTTP) Specification 14 draft-ietf-ccamp-tunproto-01 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 2, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document describes the Generic Tunnel Tracing Protocol (GTTP). 46 GTTP supports enhanced route-tracing applications. Network operators 47 use enhanced route-tracing applications to trace the path between any 48 two points in an IP network including tunnels that support the traced 49 path. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Conventions Used In This Document . . . . . . . . . . . . 3 55 1.2 The Tunnel Tracing Problem . . . . . . . . . . . . . . . . 3 56 1.3 Informal Protocol Description . . . . . . . . . . . . . . 4 57 1.4 Theory of Operation . . . . . . . . . . . . . . . . . . . 7 58 1.4.1 Top Level Path Discovery . . . . . . . . . . . . . . . 8 59 1.4.2 Tunnel Discovery . . . . . . . . . . . . . . . . . . . 10 60 1.5 Timeout Processing . . . . . . . . . . . . . . . . . . . . 11 61 1.6 Context Object Processing . . . . . . . . . . . . . . . . 12 62 1.7 Transient Changes in Topology . . . . . . . . . . . . . . 13 63 1.8 Load Balancing . . . . . . . . . . . . . . . . . . . . . . 13 64 1.9 Incremental Deployment . . . . . . . . . . . . . . . . . . 13 65 2. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . 14 66 2.1 Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 67 2.2 Message Formats . . . . . . . . . . . . . . . . . . . . . 14 68 2.2.1 The TraceProbe Message . . . . . . . . . . . . . . . . 14 69 2.2.2 The TraceResponse Message . . . . . . . . . . . . . . 16 70 2.3 Object Formats . . . . . . . . . . . . . . . . . . . . . . 17 71 2.3.1 The Source Object . . . . . . . . . . . . . . . . . . 17 72 2.3.2 The Head-end Object . . . . . . . . . . . . . . . . . 19 73 2.3.3 The Access Control Object . . . . . . . . . . . . . . 20 74 2.3.4 The Path Object . . . . . . . . . . . . . . . . . . . 21 75 2.3.5 The Propagation Object . . . . . . . . . . . . . . . . 22 76 2.3.6 The Arrival Object . . . . . . . . . . . . . . . . . . 23 77 2.3.7 The Next-Hop Object . . . . . . . . . . . . . . . . . 24 78 2.3.8 The IP Header Object . . . . . . . . . . . . . . . . . 25 79 2.3.9 The Interface Object . . . . . . . . . . . . . . . . . 26 80 2.3.10 The Tunnel Object . . . . . . . . . . . . . . . . . 27 81 2.3.11 The Context Object . . . . . . . . . . . . . . . . . 29 82 3. IANA Guidelines . . . . . . . . . . . . . . . . . . . . . . 31 83 4. Security Considerations . . . . . . . . . . . . . . . . . . 32 84 5. Normative References . . . . . . . . . . . . . . . . . . . . 32 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 86 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 87 Intellectual Property and Copyright Statements . . . . . . . 35 89 1. Introduction 91 This document describes the Generic Tunnel Tracing Protocol (GTTP). 92 GTTP supports enhanced route-tracing applications. Network operators 93 use enhanced route-tracing applications to trace the path between any 94 two points in an IP network. Enhanced route-tracing applications can 95 trace through a network's forwarding plane, its control plane or 96 both. Furthermore, enhanced route-tracing applications can reveal 97 details concerning tunnels that support the traced path. Tunnel 98 details can be revealed regardless of tunneling technology. For 99 example, enhanced route-tracing applications can trace through an 100 MPLS LSP as well as through an IP-in-IP tunnel. 102 RFC 3609 [7] specifies requirements for enhanced route-tracing 103 applications. It also describes protocol requirements for GTTP. 105 Currently, GTTP is specified for IPv4 addressing only. In future 106 revisions, GTTP will also support IPv6 addressing. 108 Each section of this document presents a significant aspect of GTTP. 109 Section 1 describes the generic route-tracing problem and provides an 110 informal description of GTTP. Section 2 describes protocol 111 mechanisms and Section 3 describes IANA considerations. Section 4 112 details security considerations. 114 1.1 Conventions Used In This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [3]. 120 1.2 The Tunnel Tracing Problem 122 This section illustrates how a route-tracing application can use GTTP 123 to trace the path between two points in an IP network. It also 124 illustrates how a route-tracing application can use GTTP to discover 125 tunnels that support the traced path. 127 -- 128 |D0| 129 -- 130 | - H1 - H2 - H3 - 131 (IP) -|D|----|D|-------------------------------------|D|----|D| 132 |1| |2| H2:1 - H2:2 - H2:3 |3| |4| 133 (IP) | | | |------|D|-------------------|D|------| | | | 134 - - |5| H2:2:1 - H2:2:2 |6| - - 135 (MPLS) | |--------|D|--------| | 136 - |7| - 137 - 139 Figure 1: Tunnel Tracing Problem 141 Figure 1 depicts eight IP accessible devices (D0 through D7). An 142 enhanced route-tracing application executes upon device D0. The 143 route-tracing application must trace the route between devices D1 and 144 D4. In this example, the traced route originates on D1's loopback 145 interface and terminates on D4's loopback interface. 147 The route between D1 and D4 contains three top-level hops. These are 148 H1, H2 and H3. No tunnel supports H1 or H3. An IP-in-IP tunnel 149 supports H2. The IP-in-IP tunnel itself contains three hops. These 150 hops, H2:1, H2:2 and H2:3, are subordinate to H2. 152 Finally, an MPLS LSP supports H2:2. The LSP contains two hops, 153 H2:2:1 and H2:2:2. The MPLS LSP is configured for penultimate hop 154 popping. Therefore, MPLS headers do not encapsulate datagrams 155 arriving at D6. 157 1.3 Informal Protocol Description 159 GTTP supports two PDU types. These PDU types represent a traceProbe 160 and a traceResponse. Enhanced route-tracing applications emit a 161 series of traceProbe messages. Each traceProbe elicits exactly one 162 traceResponse and each traceResponse describes a component of the 163 traced path. Specifically, the traceResponse can describe a 164 top-level hop or a hop that is contained by a supporting tunnel. 166 Each traceProbe contains the following objects: 167 Source Object 168 Head-end Object 169 Access Control Object (optional) 170 Path Object 171 Propagation Object 172 Context Object (optional) 174 The Source Object identifies the IP interface and UDP port upon which 175 the route-tracing application is listening for a traceResponse. It 176 also contains a timestamp and sequence number. The route-tracing 177 application provides these values and uses the sequence number to 178 match traceProbes with traceResponses. 180 The Head-end Object identifies the head-end of the traced path by IP 181 address. It also contains two timestamps. The device that supports 182 the head-end of the traced path provides one timestamp while 183 processing a traceProbe message, and the other timestamp while 184 processing the corresponding traceResponse message. The difference 185 between these two timestamps represents the round trip time between 186 the head-end device and the device that provided the traceResponse. 188 The Access Control Object contains an access control token. Network 189 elements use this token in order to determine whether the 190 route-tracing application can access the information that it is 191 requesting. The Access Control Object is optional. 193 The Path Object identifies the path being traced, from the 194 perspective of the head-end device. The traced path can be a 195 top-level path between two points in an IP network. It can also be a 196 tunnel that supports the top-level path. When the Path Object 197 represents a top-level path, it contains an IP Header Object. The IP 198 Header Object contains an IP header. (In most cases, the traced path 199 is identifiable by IP destination address only. In special cases, a 200 router bases its forwarding decision upon multiple IP header fields, 201 so the entire IP header is provided for completeness.) When the Path 202 Object represents a tunnel, it contains a Tunnel Object and the 203 Tunnel Object contains a tunnel identifier. 205 The Propagation Object determines which member of the traced path 206 will respond to the traceProbe. If the traced path supports TTL 207 decrement (as is the case for IP or MPLS) the propagation object 208 contains a Hop Count. This Hop Count determines how far the 209 traceProbe will travel along the traced before it expires and elicits 210 a traceResponse message. If the traced path does not support TTL 211 decrement (as is the case for some tunneling technologies), the 212 Propagation Object identifies the device that will provide a 213 traceResponse by IP address. 215 The Context Object identifies a VPN context. See Section 1.6 for 216 details on Context Object processing and Section 2.3.11 for format 217 details. 219 Each traceResponse message contains an error code and the following 220 objects: 221 Source Object 222 Head-end Object 223 Arrival Object (optional) 224 Next-hop Object (optional) 225 Context Object (optional) 227 The Source and Head-end are described above. 229 The Arrival Object describes how the traceProbe arrived at the 230 responding device. Specifically, the Arrival Object contains the 231 following: 232 o an Interface Object that identifies the interface upon which the 233 traceProbe arrived 234 o an optional Tunnel Object that identifies the tunnel upon which 235 the traceProbe arrived 236 o an Expiration field that indicates whether the traceProbe was 237 contained by a datagram whose TTL expired at the responding device 239 The traceResponse message MUST include an Arrival Object if it 240 describes any interface other than the origination point of a traced 241 path or tunnel. If it describes the origination point of a traced 242 path or tunnel, it MUST NOT include an Arrival Object. 244 The Next-hop Object identifies the next hop along the traced path. 245 Specifically, the Next-hop Object contains the following: 246 o the next hop, identified by IP address. 247 o an Interface Object that identifies the interface through which 248 the responding device would forward the traceProbe if it were to 249 forward it to its ultimate destination. 250 o an optional Tunnel Object that identifies the tunnel through which 251 the responding device would forward the traceProbe if it were to 252 forward it to its ultimate destination. 254 If a traced path does not terminate on the responding device and the 255 responding device can forward datagrams through the traced path, the 256 traceResponse message MUST contain a Next-hop Object. Otherwise, the 257 traceResponse message MUST NOT contain a Next-Hop Object. If the 258 responding device does not terminate the traced path and the 259 responding device cannot forward datagrams through the traced path, 260 the traceResponse MUST contain an error code indicating why the 261 responding device cannot forward datagrams through the traced path. 263 If a device receives a traceProbe that contains a Context Object and 264 responds with a traceResponse, the traceResponse MUST contain an 265 identical Context Object. See Section 1.6 for details. 267 1.4 Theory of Operation 269 The enhanced route-tracing application operates in phases. During 270 its initial phase, the application acquires information regarding the 271 top-level path that connects two IP interfaces. Specifically, the 272 application receives a traceResponse from each device that 273 participates in the top-level path. Each traceResponse can contain 274 an Arrival Object and a Next-hop Object. The Arrival Object 275 describes how the traceProbe arrived at the responding device. It 276 contains an Interface Object, that describes the interface upon which 277 the traceProbe arrived, and possibly a Tunnel Object, that describes 278 the tunnel upon which the traceProbe arrived. The traceResponse 279 message also contains a Next-Hop Object that describes how the 280 responding device would forward the traceProbe if it were to do so. 281 The Next-hop Object contains a Tunnel Object if a tunnel supports the 282 downstream hop. The Tunnel Object contains a tunnel identifier that 283 the application will use in subsequent phases to probe for tunnel 284 details. 286 During the next phase, the application acquires information regarding 287 tunnels that support top-level hops. Specifically, the application 288 uses the Tunnel Object mentioned above to query tunnel details. If 289 the application discovers nested tunnels, it executes subsequent 290 phases as required. 292 During each phase, the route-tracing application sends probes to the 293 device that serves as head-end of the traced object. For example, 294 during the initial phase, the route-tracing application sends 295 traceProbes to the head-end of the top-level path. If the 296 route-tracing application discovers that a tunnel supports one 297 top-level hop, it initiates a second phase. During the second phase, 298 the route-tracing application sends traceProbes directly to the 299 device that supports the tunnel head-end. 301 Therefore, the device that hosts the route-tracing application must 302 maintain a route to the device that hosts the head-end of the 303 top-level path. Conversely, the device that hosts the head-end of 304 the top-level path must maintain a route to the device that hosts the 305 route-tracing application. If the route-tracing application is to 306 discover tunnel details, it must maintain a route to the tunnel 307 ingress device and the tunnel ingress device must maintain a route 308 back to the device that hosts the route-tracing application. 310 The following sections describe how an enhanced route-tracing 311 application would trace the path described in Section 1.2. 313 1.4.1 Top Level Path Discovery 315 D0 formats a traceProbe, encapsulates it within UDP and IP headers, 316 and sends it to D1. The traceProbe contains the following objects: 317 o a Source Object that identifies D0 as the traceProbe's source 318 o a Head-end Object that identifies D1 as the head-end of the traced 319 path 320 o an Access Control Object that contains an access control token 321 o a Path Object that identifies D4 as the tail-end of the traced 322 path 323 o a Propagation Object that contains a Hop Count of 0, indicating 324 that the traceProbe is requesting information about the hop 325 directly downstream from D1. 327 D1 receives the traceProbe and interrogates its Access Control 328 Object. If D1 does not grant access, it sends D0 a traceResponse 329 indicating that access has been denied. If D1 grants access, it 330 interrogates the Head-end object and determines that it is the 331 head-end of the traced path. D1 then interrogates the Path Object 332 and determines that it is tracing the route towards D4. Finally, D1 333 interrogates the Propagation Object and determines that it should 334 report on H1. 336 D1 sends D0 a traceResponse that contains the following objects: 337 o the Source Object, as it arrived in the traceProbe 338 o the Head-end Object, as it arrived in the traceProbe. D1 339 overwrites both timestamps, indicating the time at which it 340 received the traceProbe and the time at which it sent the 341 traceResponse. 342 o a Next-hop Object that identifies the next hop by IP address. The 343 Next-hop Object also contains an Interface Object that describes 344 the interface to the next hop. The Next-hop Object does not 345 contain a Tunnel Object because no tunnel supports H1. 347 D1 directs the traceResponse to the UDP port specified by the Source 348 Object. 350 Having received the traceResponse, D0 has acquired control plane 351 information regarding H1. Now, D0 sends D1 another traceProbe. This 352 traceProbe is identical to the previous traceProbe except that its 353 Propagation Object contains a Hop Count of 1. 355 D1 receives the traceProbe and interrogates its Access Control 356 Object. If D1 does not grant access, it sends D0 a traceResponse 357 indicating that access has been denied. If D1 grants access, it 358 interrogates the Head-end Object and determines that it is the 359 head-end of the traced path. D1 then interrogates the Path Object 360 and determines that it is tracing the route towards D4. Next, D1 361 interrogates the Propagation Object and determines that it should 362 probe the path towards D4. Therefore, D1 timestamps the traceProbe's 363 Head-end Object and encapsulates the traceProbe within UDP and IP 364 headers. D1 sets all IP header values to those specified by the 365 traceProbe's Path Object. It also sets the IP TTL value equal to the 366 Propagation Object's Hop Count (i.e., 1). Finally, D1 recalculates 367 the IP header checksum and forwards the traceProbe towards D4. 369 Because D1 set the IP TTL to 1, the traceProbe expires at D2. D2 370 emits an ICMP Time Expired message, which GTTP ignores. D2 then 371 processes the traceProbe. 373 Specifically, D2 interrogates the traceProbe's Access Control Object. 374 If D2 does not grant access, it sends D1 a traceResponse indicating 375 that access has been denied. (D1 would relay this message to D0, 376 updating timestamps on the Head-end object as appropriate.) If D2 377 grants access, it interrogates the Head-end object and determines 378 that it is not the head-end of the traced-path. D2 then interrogates 379 the Path Object and determines that it is tracing the IP route 380 towards D4. Therefore, D2 determines that it should report 381 forwarding plane information regarding H1 and control plane 382 information regarding H2. Having made this determination, D2 sends 383 D1 a traceResponse that contains the following objects: 384 o the Source Object, as it arrived in the traceProbe 385 o the Head-end Object, as it arrived in the traceProbe 386 o an Arrival Object indicating that the traceProbe arrived in an 387 expired datagram (i.e., TTL = 0). The Arrival Object also 388 describes the interface upon which the datagram arrived. It does 389 not contain a tunnel object because no tunnel supports H1. 390 o a Next-hop Object that identifies the next hop by IP address. The 391 Next-hop Object also contains an Interface Object that describes 392 the interface to the next hop. Furthermore, the Next-hop Object 393 contains a Tunnel Object that will be used when probing for 394 details regarding the tunnel that supports H2. 396 D1 receives the traceResponse. If the traceResponse does not specify 397 any errors, D1 updates the Head-end object's traceResponse timestamp. 398 Whether or not any errors were detected, D1 relays the traceResponse 399 to D0. 401 Having received the traceResponse, D0 has acquired forwarding plane 402 information regarding H1 and control plane information regarding H2. 404 D0 repeats the process described above in order to discover the 405 remaining hops of the top-level path. 407 1.4.2 Tunnel Discovery 409 Having discovered details regarding the top level path, the 410 route-tracing application must obtain details regarding the IP-in-IP 411 tunnel that supports H2. In order to obtain these details, D0 sends 412 D2 a traceProbe. The traceProbe contains the following objects: 413 o a Source Object that identifies D0 as the traceProbe's source 414 o a Head-end Object that identifies D2 as the head-end of the traced 415 tunnel 416 o an Access Control Object that contains an access control token 417 o a Path Object that contains the Tunnel Object obtained from D2, 418 above 419 o a Propagation Object that contains a Hop Count of 0, indicating 420 that the traceProbe is requesting information about the tunnel hop 421 directly downstream from D2. 423 D2 receives the traceProbe and interrogates its Access Control 424 Object. If D2 does not grant access, it sends D0 a traceResponse 425 indicating that access has been denied. If D2 grants access, it 426 interrogates the Head-end object and determines that it is the 427 head-end of the traced tunnel. D2 then interrogates the Path Object 428 and determines that it is tracing Tunnel H2. Finally, D2 429 interrogates the propagation object and determines that it should 430 report on H2:1. 432 D2 sends D0 a traceResponse that contains the following objects: 433 o the Source Object, as it arrived in the traceProbe 434 o the Head-end Object, as it arrived in the traceProbe. D2 435 overwrites both timestamps, indicating the time at which it 436 received the traceProbe and the time at which it sent the 437 traceResponse. 438 o a Next-hop Object that identifies the next hop by IP address. The 439 Next-hop Object also contains an Interface Object that describes 440 the interface to the next hop. It does not contain a Tunnel 441 Object because no tunnel supports H2:1. 443 Having received the traceResponse, D0 has acquired control plane 444 information regarding H2:1. Now, D0 sends D2 another traceProbe. 445 This traceProbe is identical to the previous traceProbe except that 446 its Propagation Object contains a Hop Count of 1. 448 D2 receives the traceProbe and interrogates its Access Control 449 Object. If D2 does not grant access, it sends D0 a traceResponse 450 indicating that access has been denied. If D2 grants access, it 451 interrogates the Head-end Object and determines that it is the 452 head-end of the traced-path. D2 then interrogates the Path Object 453 and determines that it is tracing Tunnel H2. Next, D2 interrogates 454 the Propagation Object and determines that it should probe Tunnel H2. 456 Therefore, D2 timestamps the traceProbe's Head-end Object and 457 encapsulates the traceProbe within UDP and IP headers. (IP header 458 values are determined by the configuration of tunnel H2.) D2 sets the 459 IP TTL value equal to the Propagation Object's Hop Count (i.e., 1), 460 recalculates the checksum and forwards the traceProbe the tunnel 461 endpoint. 463 Because D2 set the IP TTL to 1, the traceProbe expires at D5. D5 464 emits an ICMP Time Expired message, which GTTP ignores. D5 then 465 processes the traceProbe. 467 Specifically, D5 interrogates the traceProbe's Access Control Object. 468 If D5 does not grant access, it sends D2 a traceResponse indicating 469 that access has been denied. (D2 would relay this message to D0.) If 470 D5 grants access, it interrogates the Head-end object and determines 471 that it is not the head-end of the traced-path. D5 then interrogates 472 the Path Object and determines that it is tracing Tunnel H2. 473 Therefore, D5 determines that it should report forwarding plane 474 information regarding H2:1 and control plane information regarding 475 H2:2. Having made this determination, D5 sends D2 a traceResponse 476 that contains the following objects: 477 o the Source Object, as it arrived in the traceProbe 478 o the Head-end Object, as it arrived in the traceProbe. 479 o an Arrival Object indicating that the traceProbe arrived in an 480 expired datagram (i.e., TTL = 0). The Arrival Object also 481 describes the interface upon which the datagram arrived. It does 482 not contain a tunnel object because no tunnel supports H2:1. 483 o a Next-hop Object that identifies the next hop by IP address. The 484 Next-hop Object also contains an Interface Object that describes 485 the interface to the next hop. Furthermore, the Next-hop Object 486 contains a Tunnel Object that will be used when probing for 487 details regarding the tunnel that supports H2:2. 489 D2 receives the traceResponse. If the traceResponse does not specify 490 any errors, D2 updates the Head-end object's traceResponse timestamp. 491 Whether or not any errors were detected, D2 relays the traceResponse 492 to D0. 494 Having received the traceResponse, D0 has acquired forwarding plane 495 information regarding H2:1 and control plane information regarding 496 H2:2. 498 D0 repeats the process described above in order to discover remaining 499 tunnel details. 501 1.5 Timeout Processing 503 As demonstrated above, devices D1 through D7 are stateless with 504 regard to GTTP. Therefore, they need not maintain any timeout logic. 505 However, the route-tracing application does maintain state and it 506 must maintain timeout logic. 508 When the route tracing-application sends a traceProbe, it initiates a 509 timer that will expire after a configurable period of time has 510 elapsed. If the application receives a traceResponse before the 511 timer expires, it destroys the timer. If the timer expires before 512 the application receives a traceResponse, the application invokes 513 timeout logic. 515 Because timeout logic is contained entirely by the route-tracing 516 application, it is beyond the scope of this specification. However, 517 the route-tracing application�s timeout behavior should be similar to 518 that of TRACEROUTE. 520 1.6 Context Object Processing 522 The Context Object allows VPN customers to trace through a Service 523 Provider's network. It is used only when the service provider's 524 policy is to allow such tracing. 526 Assume that a VPN customer wants to trace the path from one VPN site 527 to another. Assume also that the VPN customer wants to discover 528 details regarding the intervening Service Provider network and it is 529 the service provider's policy to allow such discovery. The VPN 530 customer executes a route-tracing application. 532 The route tracing application operates in phases. During the first 533 phase, the route-tracing application discovers the top-level path 534 between the two VPN sites. It also reveals that a tunnel 535 (specifically, a VPN tunnel) connects the Service Provider ingress 536 router to the Service Provider egress router. 538 During the second phase, the route-tracing application probes for 539 details regarding the VPN tunnel. Specifically, the route-tracing 540 application sends probes to the Service Provider ingress router, with 541 each probe containing a Source Object. The Source Object identifies 542 the route-tracing application by IP address and UDP port. However, 543 because the Service Provider may support RFC 1918 [1] addressing, the 544 Source Object may not uniquely identify the route-tracing application 545 to the provider ingress router. Therefore, the Service Provider 546 ingress router MUST append a Context Object to the traceProbe. The 547 Context Object adds VPN context to the IP addresses specified in the 548 Source Object. 550 The Service Provider ingress router forwards the traceProbe 551 downstream and a downstream device responds to it. The responding 552 device MUST return the Context Object in a traceResponse, exactly as 553 it was received. The Service Provider ingress router uses the 554 Context Object, together with the Source Object, to forward the 555 traceResponse message to its ultimate destination (i.e., 556 route-tracing application). Before forwarding the traceResponse to 557 the route-tracing application, the Service Provider ingress router 558 MUST remove the Context Object. 560 The Context Object is only used when probing the VPN tunnel. It is 561 not required when probing the top-level path between VPN sites. 562 Furthermore, the Context Object MUST NOT be exposed outside of the 563 Service Provider Network. 565 As mentioned above, the Service Provider ingress router generates the 566 Context Object and appends it to the traceProbe. The same router 567 uses the Context Object when it returns on the traceResponse. 568 Because a single router both produces and consumes the Context 569 Object, its contents are not the subject of standardization. 571 1.7 Transient Changes in Topology 573 The route-tracing application SHOULD detect transient changes in 574 network topology. In order to do this, the route-tracing application 575 SHOULD probe each hop multiple times, as does the traditional 576 TRACEROUTE [4] application. 578 1.8 Load Balancing 580 The route-tracing application SHOULD detect load balancing. In order 581 to detect load balancing, the route-tracing application SHOULD probe 582 each hop multiple times, as does the traditional TRACEROUTE [4] 583 application. Also, when a device receives a traceProbe that it might 584 forward over multiple downstream interfaces or tunnels, it SHOULD 585 respond with a traceResponse that contains multiple Next-Hop Objects. 587 1.9 Incremental Deployment 589 GTTP may not be deployed on all devices that contribute to a traced 590 path or tunnel. Therefore, the traceProbe message may elicit an ICMP 591 message indicating that GTTP is not available on the responding 592 device. Likewise, the traceProbe may elicit no response at all. 593 When the traceProbe does not elicit a traceResponse, the 594 route-tracing application should proceed to probe the next component 595 of the trace path or tunnel. The trace should expire after probing a 596 configurable number of path or tunnel components. 598 2. Protocol Mechanisms 600 2.1 Transport 602 GTTP obtains transport services from UDP. All GTTP messages are 603 directed to UDP port 3693, except for traceResponse messages that are 604 bound directly for the route-tracing application. Those messages are 605 directed to the UDP port specified by the route-tracing application 606 in the traceProbe Source Object. 608 2.2 Message Formats 610 The following subsections detail GTTP message formats. 612 2.2.1 The TraceProbe Message 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 |Version| Type | Unused | Length | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Source Object | 620 | // | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Head-end Object | 623 | // | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Access Control Object (optional) | 626 | // | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Path Object | 629 | // | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Propagation Object | 632 | // | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Context Object (optional) | 635 | // | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Authentication Data (optional) | 638 | // | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Figure 2: The TraceProbe Message 643 Figure 2 depicts the TraceProbe Message. Route-tracing applications 644 send TraceProbe messages in order to solicit information regarding a 645 component of a traced path. The following paragraphs describe each 646 field that contributes to the TraceProbe Message. 648 Version: 4 bits 650 The Version field specifies the GTTP message format. Value is equal 651 to 1. 653 Type: 4 bits 655 The Type field specifies the GTTP message type. A value of 0 656 identifies a TraceProbe Message. 658 Length: 16 bits 660 The Length field specifies the number of four-octet words that 661 follow. 663 The Source, Head-end, Access Control, Path, Propagation and Context 664 Objects are described in dedicated sections of this document. Every 665 traceProbe MUST contain the Source, Head-end, Path and Propagation 666 objects. The Access Control and Context Objects are optional. 667 Authentication Data is also optional. Authentication Data is 668 REQUIRED when the Authentication Object specifies cryptographic 669 Authentication. In all other cases, Authentication Data MUST NOT be 670 included in the traceProbe message. 672 The object ordering illustrated above is REQUIRED. 674 2.2.2 The TraceResponse Message 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |Version| Type | Error Code | Length | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | ErrObj| Unused | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Source Object | 684 | // | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Head-end Object | 687 | // | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Arrival Object (optional) | 690 | // | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Next-Hop Object(s) (optional) | 693 | // | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Context Object (optional) | 696 | // | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 Figure 3: The TraceResponse Message 701 Figure 3 depicts the TraceResponse Message. Network devices send 702 traceResponse messages in order to provide information regarding a 703 component of a traced path. The following paragraphs describe each 704 field that contributes to the TraceResponse Message. 706 Version: 4 bits 708 The Version field specifies the GTTP message format. Value is equal 709 to 1. 711 Type: 4 bits 713 The Type field specifies the GTTP message type. A value of 1 714 identifies a TraceResponse Message. 716 Error Code: 8 bits 718 The Error Code field defines protocol errors. The following error 719 codes are currently defined: 721 0 - gttp_no_error 722 1 - gttp_access_denied 723 2 - gttp_no_such_tunnel 724 3 - gttp_no_route_to_destination 725 4 - gttp_route_to_destination_administratively_blocked 726 5 - gttp_missing_object 727 6 - gttp_malformed_object 729 Length: 16 bits 731 The Length field specifies the number of four-octet words that 732 follow. 734 ErrObj: 8 bits 736 The ErrObj field identifies a missing or malformed object. If no 737 object is missing or malformed, this value must be set to 0. 739 The Source, Head-end, Arrival, Next-Hop and Context Objects are 740 described in dedicated sections of this document. Every 741 traceResponse message MUST contain the Source and Head-end Objects. 742 The Arrival, Next-Hop and Context Objects are optional. 744 When a device receives a traceProbe that it might forward over 745 multiple downstream interfaces or tunnels, it SHOULD respond with a 746 traceResponse that contains multiple Next-Hop Objects. 748 The object ordering illustrated above is REQUIRED. 750 2.3 Object Formats 752 The following subsections detail GTTP object formats. 754 2.3.1 The Source Object 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type | Unused | Application Port | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Origination Timestamp | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Sequence Number | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Application Address | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Figure 4: The Source Object 769 Figure 4 depicts the Source Object. The Source Object identifies 770 the GTTP message and its source. The following paragraphs describe 771 each field that contributes to the Source Object. 773 Type: 8 bits 775 The Type field specifies the type of the object that follows. For 776 the Source Object, the Type field is always equal to 1. 778 Application Port: 16 bits 780 The Application Port field identifies a UDP port upon which the 781 route-tracing application is listening for a traceResponse. 783 Origination TimeStamp: 32 bits 785 The Origination Timestamp represents the time at which the traceProbe 786 was issued. As the device that hosts the route-tracing application 787 supplies this value and is its only user, the unit of measure is not 788 subject to standardization. 790 Sequence Number: 32 bits 792 The Sequence Number identifies the traceProbe. Applications use this 793 field to match traceProbes with TraceResponses. 795 Application Address: 32 bits 797 The Application Address identifies an IP interface upon which the 798 route-tracing application is awaiting a traceResponse. 800 All Unused bits MUST be set to 0 and ignored. 802 2.3.2 The Head-end Object 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Unused | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | TraceProbe Timestamp | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | TraceResponse Timestamp | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Head-end Address | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Figure 5: The Head-end Object 818 Figure 5 depicts the Head-end Object. The Head-end Object 819 identifies the head-end of a top-level path or supporting tunnel. 820 The following paragraphs describe each field that contributes to the 821 Head-end Object. 823 Type: 8 bits 825 The Type field specifies the type of the object that follows. For 826 the Head-end Object, the Type field is always equal to 2. 828 TraceProbe TimeStamp: 32 bits 830 The TraceProbe Timestamp represents the time at which the Head-end 831 device received the traceProbe. It represents the number of 832 milliseconds since some arbitrarily chosen point in time. 834 When the route-tracing application originates a traceProbe, it MUST 835 set this field to 0x0000. The head-end of a traced path or tunnel 836 updates this field as described above. When the originator of a 837 traceResponse copies the Head-end Object from a traceProbe to a 838 traceResponse, it MUST NOT change the value of this field. 840 TraceResponse TimeStamp: 32 bits 842 The TraceResponse Timestamp represents the time at which the Head-end 843 device sent the traceResponse. It represents the number of 844 milliseconds since some arbitrarily chosen point in time. 846 When the route-tracing application originates a traceProbe, it MUST 847 set this field to 0x0000. The head-end of a traced path or tunnel 848 updates this field as described above. When the originator of a 849 traceResponse copies the Head-end Object from a traceProbe to a 850 traceResponse, it MUST NOT change the value of this field. 852 Head-end Address: 32 bits 854 The Head-end Address identifies the head-end of the top-level path or 855 tunnel that is being traced. 857 All Unused bits MUST be set to 0 and ignored. The TraceProbe 858 Timestamp and TraceResponse Timestamp fields must use the same 859 arbitrarily chosen point in time as a reference. 861 2.3.3 The Access Control Object 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Type | Unused | AuType | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Authentication | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Authentication | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Figure 6: The Access Control Object 875 Figure 6 depicts the Access Control Object. GTTP entities use the 876 access control object to enforce access control policy. The 877 following paragraphs describe each field that contributes to the 878 Access Control Object. 880 Type: 8 bits 882 The Type field specifies the type of the object that follows. For 883 the Access Control Object, the Type field is always equal to 3. 885 AuType: 16 bits 887 The AuType specifies the type of authentication used for this 888 message. Encoding rules follow: 889 1 - Plaintext password 890 2 - Cryptographic Authentication 892 Authentication: 64 bits 894 The Authentication field contains authentication data. See Appendix 895 D of RFC 2328 [5] for a description of this field. This field is 896 used in conjunction with the Authentication Data field that is 897 specified at the end of the traceProbe Message. 899 All Unused bits MUST be set to 0 and ignored. 901 2.3.4 The Path Object 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Type | Unused | Length | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | IP Header Object | 909 | (optional) | 910 | // | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Tunnel Object | 913 | (optional) | 914 | // | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 Figure 7: The Path Object 919 Figure 7 depicts the Path Object. The Path Object identifies the 920 path being traced. The Path Object can represent the top-level path 921 between two points in an IP network. It can also represent a tunnel 922 that supports the top-level path. When the Path Object represents a 923 top-level path, it contains an IP Header Object. The IP Header 924 Object contains an IP header that identifies the traced path. (In 925 most cases, the traced path is identifiable by IP destination address 926 only. In special cases, the router bases its forwarding decision 927 upon multiple IP header fields, so the entire IP header is provided 928 for completeness.) When the Path Object represents a tunnel, it 929 contains a Tunnel Object and the Tunnel Object contains a tunnel 930 identifier. 932 The following paragraphs describe each field that contributes to the 933 Path Object. 935 Type: 8 bits 937 The Type field specifies the type of the object that follows. For 938 the Path Object, the Type field is always equal to 4. 940 Length : 8 bits 942 The Length field specifies the number of four-octet words that 943 follow. 945 The IP Header and Tunnel Objects are described in Section 2.3.8 and 946 Section 2.3.10. The Path Object MUST contain an IP Header Object or 947 a Tunnel Object, but it MUST NOT contain both. 949 All Unused bits MUST be set to 0 and ignored. The object ordering 950 illustrated above is REQUIRED. 952 2.3.5 The Propagation Object 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Type |H| Unused | Hop Count | Length | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Responder Address (optional) | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Figure 8: The Propagation Object 964 Figure 8 depicts the Propagation Object. The Propagation Object 965 determines which member of the traced path will respond to the 966 traceProbe. If the traced path supports TTL decrement (as is the 967 case for IP or MPLS) the H-bit is set and the propagation object 968 specifies a Hop Count. This Hop Count determines how far the 969 traceProbe will travel along the traced path before it expires and 970 elicits a traceResponse message. If the traced path does not support 971 TTL decrement (as is the case for some tunneling technologies), the 972 H-bit is clear and the Propagation Object identifies the device that 973 will provide a traceResponse by IP address. 975 The following paragraphs describe each field that contributes to the 976 Propagation Object. 978 Type: 8 bits 980 The Type field specifies the type of the object that follows. For 981 the Propagation Object, the Type field is always equal to 5. 983 H : 1 bit 985 The H flag determines whether GTTP will use TTL decrement to discover 986 the traced path. If the H flag is set, the Hop Count field is 987 significant and the Responder Address should not be specified. If 988 the H flag is not set, the Hop Count is insignificant and the 989 Responder Address is required. 991 Hop Count: 8 bits 993 The Hop Count field determines which member of the traced path should 994 respond to the traceProbe. A value of 0 indicates that the head-end 995 device should respond. A value of 1 indicates that the device one 996 hop beyond the head and should respond and so forth. The Hop Count 997 field is only significant when the H Flag is set. 999 Length: 8 bits 1001 The Length Field specifies the number of four-octet words that 1002 follow. In the Path Object, its value is equal to 0 or 1. 1004 Responder Address : 32 bits 1006 The Responder Address identifies the device that is to provide the 1007 traceResponse by IP address. When the H-bit is set, this field MUST 1008 NOT be present. When the H-bit is clear, this field MUST be present 1009 and contain a valid IPv4 address. 1011 All Unused bits must be set to 0 and ignored. 1013 2.3.6 The Arrival Object 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Type |E| Unused | Length | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Interface Object | 1021 | // | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Tunnel Object | 1024 | (optional) | 1025 | // | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 Figure 9: The Arrival Object 1030 Figure 9 depicts the Arrival Object. The Arrival Object describes 1031 how a traceProbe arrived at the probed device. The following 1032 paragraphs describe each field that contributes to the Arrival 1033 Object. 1035 Type: 8 bits 1037 The Type field specifies the type of the object that follows. For 1038 the Arrival Object, the Type field is always equal to 6. 1040 E : 1 bit 1042 The E flag indicates that GTTP is responding to a traceProbe that 1043 arrived in an IP datagram whose TTL has expired. 1045 Length : 8 bits 1047 The Length Field specifies the number of four-octet words that 1048 follow. 1050 The Interface Object and Tunnel Object are described in dedicated 1051 sections of this document. 1053 All Unused bits must be set to 0 and ignored. 1055 2.3.7 The Next-Hop Object 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Type | Unused | Length | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Next Hop Address | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Interface Object | 1065 | // | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Tunnel Object | 1068 | (optional) | 1069 | // | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 Figure 10: The Next-Hop Object 1074 Figure 10 depicts the Next-hop Object. The Next-Hop Object describes 1075 how a device would forward a traceProbe toward its destination. The 1076 following paragraphs describe each field that contributes to the 1077 Next-hop Object. 1079 Type: 8 bits 1081 The Type field specifies the type of the object that follows. For 1082 the Next-Hop Object, the Type field is always equal to 7. 1084 Length : 8 bits 1086 The Length Field specifies the number of four-octet words that 1087 follow. 1089 Next Hop Address : 32 bits 1090 The Next Hop Address identifies the device that supports the next hop 1091 by IP address. 1093 The Interface and Tunnel Objects are described in dedicated sections 1094 of this document. 1096 All Unused bits must be set to 0 and ignored. 1098 2.3.8 The IP Header Object 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Type | Unused | Length | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | IP Header | 1106 | // | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 Figure 11: The IP Header Object 1111 Figure 11 depicts the IP Header Object. The IP Header Object 1112 contains an IP Header that identifies the top-level path being 1113 traced. The following paragraphs describe each field that 1114 contributes to the IP Header Object. 1116 Type: 8 bits 1118 The Type field specifies the type of the object that follows. For 1119 the IP Header Object, the Type field is always equal to 8. 1121 Length : 8 bits 1123 The Length Field specifies the number of four-octet words that 1124 follow. 1126 IP Header : Variable Length 1128 This field contains an IP header. It can be 0 padded for word 1129 alignment. 1131 All Unused bits must be set to 0 and ignored. 1133 2.3.9 The Interface Object 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Type | Unused | Length | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | MTU | ifDescr Len | Unused | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | IP Address | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | ifDescr | 1145 | // | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 Figure 12: The Interface Object 1150 Figure 12 depicts the Interface Object. The Interface Object 1151 identifies an interface and specifies its attributes. The Arrival 1152 Object and Next-hop Object can contain the Interface Object. 1154 The following paragraphs describe each field that contributes to the 1155 Interface Object. 1157 Type: 8 bits 1159 The Type field specifies the type of the object that follows. For 1160 the Interface Object, the Type field is always equal to 9. 1162 Length : 8 bits 1164 The Length Field specifies the number of four-octet words that 1165 follow. 1167 MTU : 16 bits 1169 The MTU field specifies interface MTU in octets. 1171 ifDescr Length : 8 bits 1173 The ifDescr Length Field specifies the length of the ifDescr field, 1174 in four-octet words. 1176 IP Address: 32 bits 1178 The IP Address field identifies the interface by IP Address. 1180 ifDescr : Variable Length 1181 The ifDescr field identifies the interface by a unique name. This 1182 field must contain ASCII printable characters followed by a NULL 1183 character. It can be 0 padded for word alignment. 1185 All Unused bits must be set to 0 and ignored. 1187 2.3.10 The Tunnel Object 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Type | Unused | Length | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | MTU | TunnelID Len | TunDetail Len | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 |D|P| Unused | TunnelName Len| Tunnel Type | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Head-end IP Address | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Tail-end IP Address | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | TunnelID | 1203 | // | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Tunnel Details | 1206 | // | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Tunnel Name | 1209 | // | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Figure 13: The Tunnel Object 1214 Figure 13 depicts the Tunnel Object. The Tunnel Object identifies a 1215 tunnel and specifies its attributes. The Path Object, Arrival Object 1216 and Next-hop Object can contain the Tunnel Object. 1218 The following paragraphs describe each field that contributes to the 1219 Tunnel Object. 1221 Type: 8 bits 1223 The Type field specifies the type of the object that follows. For 1224 the Tunnel Object, the Type field is always equal to 10. 1226 Length : 8 bits 1228 The Length Field specifies the number of four-octet words that 1229 follow. 1231 MTU : 16 bits 1233 The MTU field specifies tunnel MTU in octets. 1235 TunnelID Length : 8 bits 1237 The TunnelID Length Field specifies the length of the TunnelID field, 1238 in four-octet words. 1240 TunDetail Length : 8 bits 1242 The TunDetail Length Field specifies the length of the TunDetail 1243 field, in four-octet octet words. 1245 D-Flag : 1 bit 1247 The D-flag is set if the tunnel supports TTL decrement. 1249 P-Flag : 1 bit 1251 The P-Flag is set if the tunnel inherits its TTL value from that of 1252 its payload. The P-Flag is cleared if the tunnel always sets its TTL 1253 to an arbitrarily high value or does not support TTL. 1255 TunnelName Length : 8 bits 1257 The TunnelName Length Field specifies the length of the TunnelName 1258 field, in four-octet words. 1260 Tunnel Type : 8 bits 1262 The Tunnel Type field identifies a tunnel type. Currently, the 1263 following tunnel types are defined: 1264 0 - IP-in-IP 1265 1 - GRE 1266 2 - GMPLS 1267 3 - MPLS 1268 4 - MPLS/LDP Signaled 1269 5 - MPLS/RSVP-TE Signaled 1270 6 - L2TPv2 1271 7 - L2TPv3 1272 8 - IPSEC 1274 Head-end IP Address : 32 bits 1276 The Head-end IP Address field identifies the tunnel head-end by IP 1277 address. 1279 Tail-end IP Address : 32 bits 1281 The Tail-end IP Address field identifies the tunnel tail-end by IP 1282 address. 1284 TunnelID : Variable Length 1286 The TunnelID field identifies the tunnel by a unique identifier. 1287 Because this field is produced and consumed by the same router, its 1288 contents are not the subject of standardization. It can be 0 padded 1289 for word alignment. 1291 Tunnel Details : Variable Length 1293 The Tunnel Details field provides tunnel specific details (e.g., MPLS 1294 label values). This field must contain ASCII printable characters 1295 followed by a NULL character. The route tracing application will 1296 print its contents, verbatim. It can be 0 padded for word alignment. 1298 TunnelName : Variable Length 1300 The TunnelName field identifies the tunnel by name. This field must 1301 contain ASCII printable characters followed by a NULL character. It 1302 can be 0 padded for word alignment. 1304 All Unused bits must be set to 0 and ignored. 1306 2.3.11 The Context Object 1308 0 1 2 3 1309 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 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Type | Unused | Length | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Message Body | 1314 | // | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 Figure 14: The Context Object 1319 Figure 14 depicts the Context Object. The Context Object provides a 1320 context for the Source Object. It is required when the address 1321 provided in the Source Object is to be interpreted within the context 1322 of a VPN. 1324 The following paragraphs describe each field that contributes to the 1325 Context Object. 1327 Type: 8 bits 1329 The Type field specifies the type of the object that follows. For 1330 the Context Object, the Type field is always equal to 11. 1332 Length : 8 bits 1334 The Length Field specifies the length of the object that follows, in 1335 four-octet words. 1337 Message Body : variable length 1339 Because the same device that provides the context object interprets 1340 its meaning, the syntax of this field need not be standardized. 1342 3. IANA Guidelines 1344 IANA has assigned UDP port 3693 to GTTP. IANA will establish a 1345 registry for GTTP codepoints. 1347 4. Security Considerations 1349 The following are security considerations: 1) GTTP MUST enforce 1350 access control policy before disclosing any information. 2) GTTP 1351 entities should rate limit messages that they send and receive. 1353 5 Normative References 1355 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 1356 Lear, "Address Allocation for Private Internets", BCP 5, RFC 1357 1918, February 1996. 1359 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1360 9, RFC 2026, October 1996. 1362 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1363 Levels", BCP 14, RFC 2119, March 1997. 1365 [4] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP 1366 Tools and Utilities", RFC 2151, June 1997. 1368 [5] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1370 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1371 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1373 [7] Bonica, R., Kompella, K. and D. Meyer, "Tracing Requirements for 1374 Generic Tunnels", RFC 3609, September 2003. 1376 Authors' Addresses 1378 Ronald P. Bonica 1379 MCI 1380 22001 Loudoun County Pkwy 1381 Ashburn, VA 20147 1382 US 1384 Phone: +1 703 886 1681 1385 EMail: ronald.p.bonica@mci.com 1386 Eric C. Rosen 1387 Cisco Systems 1388 250 Apollo Drive 1389 Chelmsford, MA 01824 1390 US 1392 EMail: erosen@cisco.com 1394 Dave Meyer 1395 Cisco Systems 1397 EMail: dmm@1-4-5.net 1399 Kireeti Kompella 1400 Juniper Networks 1401 1194 N. Mathilda Ave 1402 Sunnyvale, CA 94089 1403 USA 1405 EMail: kireeti@juniper.net 1407 Rohit Dube 1408 Xebeo Communications 1409 1 Cragwood Road, Suite 100 1410 South Plainfield, NJ 07080 1411 USA 1413 EMail: rohit@xebeo.com 1415 Appendix A. Acknowledgements 1417 Thanks to Richard Rabbat, Adrian Farrel, Randy Bush, Philip Matthews, 1418 Tricci So and Beth Alwin for their comments. 1420 Intellectual Property Statement 1422 The IETF takes no position regarding the validity or scope of any 1423 intellectual property or other rights that might be claimed to 1424 pertain to the implementation or use of the technology described in 1425 this document or the extent to which any license under such rights 1426 might or might not be available; neither does it represent that it 1427 has made any effort to identify any such rights. Information on the 1428 IETF's procedures with respect to rights in standards-track and 1429 standards-related documentation can be found in BCP-11. Copies of 1430 claims of rights made available for publication and any assurances of 1431 licenses to be made available, or the result of an attempt made to 1432 obtain a general license or permission for the use of such 1433 proprietary rights by implementors or users of this specification can 1434 be obtained from the IETF Secretariat. 1436 The IETF invites any interested party to bring to its attention any 1437 copyrights, patents or patent applications, or other proprietary 1438 rights which may cover technology that may be required to practice 1439 this standard. Please address the information to the IETF Executive 1440 Director. 1442 Full Copyright Statement 1444 Copyright (C) The Internet Society (2004). All Rights Reserved. 1446 This document and translations of it may be copied and furnished to 1447 others, and derivative works that comment on or otherwise explain it 1448 or assist in its implementation may be prepared, copied, published 1449 and distributed, in whole or in part, without restriction of any 1450 kind, provided that the above copyright notice and this paragraph are 1451 included on all such copies and derivative works. However, this 1452 document itself may not be modified in any way, such as by removing 1453 the copyright notice or references to the Internet Society or other 1454 Internet organizations, except as needed for the purpose of 1455 developing Internet standards in which case the procedures for 1456 copyrights defined in the Internet Standards process must be 1457 followed, or as required to translate it into languages other than 1458 English. 1460 The limited permissions granted above are perpetual and will not be 1461 revoked by the Internet Society or its successors or assignees. 1463 This document and the information contained herein is provided on an 1464 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1465 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1466 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1467 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1468 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1470 Acknowledgment 1472 Funding for the RFC Editor function is currently provided by the 1473 Internet Society.