idnits 2.17.1 draft-yin-traceroute-ipmpls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3832 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-yin-tsvwg-ipflow-pathtrace-ps-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Yin 3 Internet-Draft S. Jiang, Ed. 4 Intended status: Informational Z. Li 5 Expires: April 24, 2014 M. Chen 6 Huawei Technologies Co., Ltd 7 October 21, 2013 9 A Traceroute Framework in IP/MPLS Heterogeneous Networks 10 draft-yin-traceroute-ipmpls-00 12 Abstract 14 This document introduces a traceroute framework that can obtain 15 information of a real traffic flow path through heterogeneous IP/MPLS 16 network environments. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 24, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Procedures of the IP/MPLS Heterogeneous Traceroute Mechanism 2 54 2.1. New Components Needed . . . . . . . . . . . . . . . . . . 4 55 2.2. Form a New Echo-Request Message . . . . . . . . . . . . . 5 56 2.3. Process an Echo-Request Message . . . . . . . . . . . . . 5 57 2.3.1. Response requested information . . . . . . . . . . . 5 58 2.3.2. Update Routing-Decide field . . . . . . . . . . . . . 6 59 2.3.3. Update Return-Path field . . . . . . . . . . . . . . 6 60 2.3.4. Send a new Echo-Request message . . . . . . . . . . . 6 61 2.4. Process an Echo-Reply Message . . . . . . . . . . . . . . 6 62 2.5. Termination of the Traceroute Request . . . . . . . . . . 7 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 67 7. Informative References . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 The current ISP networks may actually be constructed by IP/MPLS 73 heterogeneous network technologies. ISP services may be delivered 74 across these IP/MPLS heterogeneous network environments. 76 To locate the network fault quickly, IETF has defined the 77 corresponding ping and trace functions for each network technology, 78 independently. However, none of these technologies are able to 79 gather the trace information of all these heterogeneous network 80 environments. It is difficult to trace the complete end-to-end 81 paths. Another issue of these ping/trace functions is path 82 replicability. [I-D.yin-tsvwg-ipflow-pathtrace-ps] describes the 83 issues and the requirements for a new IP/MPLS traffic flow path trace 84 mechanism in details. 86 In order to meet these requirements, this document introduces a new 87 traceroute framework that traces the real traffic flow path while the 88 real forwarding-relevant information are carried and updated in the 89 path. It can therefore obtain information of a real traffic flow 90 path through IP/MPLS heterogeneous network environments. 92 It is worthy of noticing that this mechanism requires support of all 93 fowarding devices. It is suitable to be used within a single 94 administration domain. 96 2. Procedures of the IP/MPLS Heterogeneous Traceroute Mechanism 97 The new traceroute mechanism, introduced by this document, mainly 98 targets the IP/MPLS heterogeneous networks. 100 In order to describe the applicable scenarios and procedures, in this 101 document, below network topology illustrates a traceroute example 102 scenaio, in which the IP load balancing and traversing a MPLS network 103 are demonstrated. 105 |<-----------------Administration Domain--------------->| 106 | |<-MPLS Domain->| | 107 | +---+ +---+ +---+ | 108 | +---| C |---| M1|---| E |---+ | 109 +---+ | +---+ +---+ | +---+\ /+---+\ /+---+ | +---+ | +---+ 110 | S |---| A |---| B |---+ X X +---| G |---| D | 111 +---+ | +---+ +---+ | +---+/ \+---+/ \+---+ | +---+ | +---+ 112 | +---| D |---| M2|---| F |---+ | 113 | +---+ +---+ +---+ | 114 | |<-MPLS Domain->| | 115 |<-----------------Administration Domain--------------->| 117 The real traffic is from the S(ource) node to the D(estination) node. 118 The traceroute request is initialized at node A, and ideally 119 terminated at node G. From the node B, the IP packet may be forwarded 120 to node C or node D. Then it is MPLS domain, where the intermedia 121 device M1 or M2 cannot be detected by current IP ping/trace 122 mechanism. This mechanism assume that all MPLS nodes have IP 123 connectivities and can communicate with each other according to IP 124 addresses. 126 In the new traceroute mechanism, the traceroute requesting node 127 passes three type of information, as illustrated in the below figure, 128 to the next hop. An example of traceroute request message: 130 +-----------------------------------------------------+ 131 | IP & UDP header for Echo-Request Message | 132 +-----------------------------------------------------+ 133 |Forwarding-Decide field contains Real IP/MPLS headers| 134 +-----------------------------------------------------+ 135 | Options | 136 +-----------------------------------------------------+ 138 The IP and UDP headers indicate the recipient - this is a traceroute 139 request. The Forwarding-Decide field contains real IP/MPLS headers, 140 copied from a packet in a real traffic flow, or pseudo headers 141 forming to represent a traffic flow. It may include IP header, MPLS 142 header and TCP/UDP header. The IP/MPLS headers in the Forwarding- 143 Decide field are maintained or modified in the exactly same way when 144 a real traffic packet is processed in the forwarding procedure. 145 Every on-path node decides the next hop according to the Forwarding- 146 Decide field. This would guarantee the traced route follows the same 147 path of the real traffic packet, because the forwarding decide 148 information is exactly same. Options are mainly used to indicate the 149 on-path nodes requested information and the return path. The on-path 150 nodes report the requested information of themselves to the 151 traceroute requesting node directly. 153 2.1. New Components Needed 155 There are a few new components needed in order to fulfil the newly- 156 introduced hop-by-hop traceroute mechanism. They are listed below. 158 Traceroute Port A well-known UDP port that indicates the recipient 159 devices that received UDP mesages are for traceroute purpose. 161 An echo request message: a new UDP message that is carrying the 162 traceroute request. It is processed, may be modified, then passed 163 on hop by hop. 165 * Transaction ID, used to distinguish mutliple traceroute 166 requests initiated by the same traceroute requesting node. 168 * Forwarding-Decide field, contains all information that may 169 affect the path choice for a specific packet, including IP 170 header, TCP/UDP header, MPLS header, and IP tunnel header. The 171 field contents are maintained or modified in the exactly same 172 way when a real IP packet is processed in the forwarding 173 procedure. 175 * Required-Information option, used to indicate the on-path nodes 176 the information desired by the traceroute requesting node. 178 * Return-Path field, used to indicate the return path for the 179 responsed Echo-Reply message. It operates like a stack: the 180 closed relay nodes first, then second close, till the original 181 requesting node. 183 An echo reply message: a new UDP message that is used to return the 184 requested information of intermedia node to the traceroute 185 requesting node. 187 * Transaction ID, copied from the correspondent Echo-Request 188 message. It is used to distinguish mutliple traceroute 189 requests initiated by the same traceroute requesting node. 191 * Information options, the information of the requested node. 192 They are the response to the required information option. 194 * Return-Path field, copied from the correspondent Echo-Request 195 message. The MPLS or tunnel ingress nodes need these 196 information to relay the Echo-Reply message to the traceroute 197 requesting node. 199 The detailed format or data structure is out of scope for this 200 informational document. 202 2.2. Form a New Echo-Request Message 204 In the new traceroute mechanism, the traceroute request device (node 205 A) forms an Echo-Request message, in which the Forwarding-Decide 206 field contains a real IP header and TCP/UDP hearder that is copied 207 from a packet in a real traffic flow, or a pseudo IP header and TCP/ 208 UDP hearder, towards node D. This Echo-Request message also indicates 209 what information of these on-path devices are desired. The 210 traceroute request device also records itself in the Return-Path 211 field. 213 The Echo-Request message is carried by an IP packet, which the 214 destination address is filled by the loopback address and source 215 address is the requesting node itself. IP TTL is set to value that 216 indicate the maximum trace route hops. It then sends the new IP 217 packet towards the next hop according to the Forwarding-Decide field. 219 This mechanism description in this section currently assumes that the 220 traceroute requests start from IP. 222 2.3. Process an Echo-Request Message 224 Upon receiving the IP packet that contains an Echo-Request message, 225 the recipiet node processes it to the new traceroute function, 226 because of the loopback address and the newly defined Traceroute 227 port. There are four follow-up procedures on the recipient: 228 responsing its own information, updating Fowarding-Decide field, 229 updating Return-Path field, and sending a new Echo-Request message. 231 2.3.1. Response requested information 233 The new traceroute function returns the requested information of this 234 node, according to Required-Information option in the Echo-Request 235 message, back to the traceroute requesting node (or the closest relay 236 node), by sending an Echo-Reply message. 238 The IP address of the traceroute requesting node or the closest relay 239 node, is obtained from the Return-Path field of the Echo-Request 240 message. Transaction ID is copied from the Echo-Request message. 241 The Return-Path field from the Echo-Request message must be copied 242 into the Echo-Reply message. 244 2.3.2. Update Routing-Decide field 246 The Forwarding-Decide field is maintained/modified in the exactly 247 same way when the real traffic packet that the Forwarding-Decide 248 field represents is processed, including add/remove new MPLS header, 249 update MPLS label, add/remove IP tunnel header, NAT44 or NAT66 250 translation or etc. 252 2.3.3. Update Return-Path field 254 The node first check whether the second close node in the Return-Path 255 field is reachable or not. If yes, it removes the closest node in 256 the Return-Path field; if not, do nothing. Note, if there is only 257 one node in the Return-Path field, it must not be removed. 259 The node then adds the IP address of itself into the Return-Path 260 field, and the necessary information that this node must have in 261 order to distinguish the previous node, such as Virtual Routing and 262 Forwarding (VRF) information, etc. 264 2.3.4. Send a new Echo-Request message 266 This node then forms a new IP packet, in which the destination 267 address is filled by the loopback address, source address is itself. 268 It carries the Echo-Request message in the payload. TTL in IP header 269 is reduced by 1 every hop. 271 According to the MPLS header, if there is, IP header and TCP/UDP 272 hearder in the Forwarding-Decide field, the device decides the next 273 hop, then sends the new IP packet towards the next hop. 275 2.4. Process an Echo-Reply Message 277 Upon receiving an Echo-Reply message that the destination IP address 278 is itself, the recipient must decide whether the Echo-Reply is 279 terminate here or needs to be relayed out, by checking whether it is 280 the last node in the Return-Path field. 282 If it is not the last node, it must be the first node. It then 283 obtains the necessary information for it to distinguish the next 284 node. It removes itself out of the stack of the Return-Path field. 285 It then relays the Echo-Reply message to the next relay node or the 286 original requesting node that it learns from the Return-Path field. 288 2.5. Termination of the Traceroute Request 290 Ideally, the traceroute request should be terminated at the edge of 291 the administration domain if the traffic destination was out of 292 domain, Node G in the example scenario. The forwarding devices on 293 the edge of the administration domain should be configured not to 294 send traceroute messages out on the interfaces that connected to 295 subscribers or devices out of the administration domain. 297 However, the leak of traceroute request message should not bring much 298 impact. The subscriber node does not support this traceroute 299 function would drop it siliently as unknown message. The ingress 300 devices of another administration domain or another ISP/transit 301 network would filter this message. 303 3. Security Considerations 305 Without an authentication mechanim, this mechanism would be risk to 306 expose network device information. It should only be used either 307 when combines with an authentication mechanim or in a closed single 308 administration domain, in which the end user requests or request from 309 outside of this administration domain should be filtered at the edge 310 of the sdministration domain. 312 The leak of traceroute request message does not create much security 313 risk. The information carried with in the message does not contain 314 much sensitive information of the network. The only potential risk 315 information is exposing of the IP addresses of intermediate 316 forwarding devices in the return parth option. 318 4. IANA Considerations 320 This memo includes no request to IANA. 322 5. Acknowledgements 324 This document was produced using the xml2rfc tool [RFC2629]. 326 6. Change log [RFC Editor: Please remove] 328 draft-yin-hopbyhop-traceroute-00: original version. 2013-10-21. 330 7. Informative References 332 [I-D.yin-tsvwg-ipflow-pathtrace-ps] 333 Yin, Y., Jiang, S., and G. Yan, "IP Flow Path Trace 334 Requirements", draft-yin-tsvwg-ipflow-pathtrace-ps-00 335 (work in progress), July 2013. 337 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 338 June 1999. 340 Authors' Addresses 342 Yuanbin Yin 343 Huawei Technologies Co., Ltd 344 Q15, Huawei Campus, No.156 Beiqing Road 345 Hai-Dian District, Beijing, 100095 346 P.R. China 348 Email: yinyuanbin@huawei.com 350 Sheng Jiang (editor) 351 Huawei Technologies Co., Ltd 352 Q14, Huawei Campus, No.156 Beiqing Road 353 Hai-Dian District, Beijing, 100095 354 P.R. China 356 Email: jiangsheng@huawei.com 358 Zhenbin Li 359 Huawei Technologies Co., Ltd 360 Q15, Huawei Campus, No.156 Beiqing Road 361 Hai-Dian District, Beijing, 100095 362 P.R. China 364 Email: lizhenbin@huawei.com 366 Mach(Guoyi) Chen 367 Huawei Technologies Co., Ltd 368 Q14, Huawei Campus, No.156 Beiqing Road 369 Hai-Dian District, Beijing, 100095 370 P.R. China 372 Email: mach.chen@huawei.com