Internet Engineering Task Force Y. Yin Internet-Draft S. Jiang, Ed. Intended status: Informational Z. Li Expires: April 24, 2014 M. Chen Huawei Technologies Co., Ltd October 21, 2013 A Traceroute Framework in IP/MPLS Heterogeneous Networks draft-yin-traceroute-ipmpls-00 Abstract This document introduces a traceroute framework that can obtain information of a real traffic flow path through heterogeneous IP/MPLS network environments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Yin, et al. Expires April 24, 2014 [Page 1] Internet-Draft Traceroute in IP/MPLS Heterogeneous Env October 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Procedures of the IP/MPLS Heterogeneous Traceroute Mechanism 2 2.1. New Components Needed . . . . . . . . . . . . . . . . . . 4 2.2. Form a New Echo-Request Message . . . . . . . . . . . . . 5 2.3. Process an Echo-Request Message . . . . . . . . . . . . . 5 2.3.1. Response requested information . . . . . . . . . . . 5 2.3.2. Update Routing-Decide field . . . . . . . . . . . . . 6 2.3.3. Update Return-Path field . . . . . . . . . . . . . . 6 2.3.4. Send a new Echo-Request message . . . . . . . . . . . 6 2.4. Process an Echo-Reply Message . . . . . . . . . . . . . . 6 2.5. Termination of the Traceroute Request . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 7. Informative References . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The current ISP networks may actually be constructed by IP/MPLS heterogeneous network technologies. ISP services may be delivered across these IP/MPLS heterogeneous network environments. To locate the network fault quickly, IETF has defined the corresponding ping and trace functions for each network technology, independently. However, none of these technologies are able to gather the trace information of all these heterogeneous network environments. It is difficult to trace the complete end-to-end paths. Another issue of these ping/trace functions is path replicability. [I-D.yin-tsvwg-ipflow-pathtrace-ps] describes the issues and the requirements for a new IP/MPLS traffic flow path trace mechanism in details. In order to meet these requirements, this document introduces a new traceroute framework that traces the real traffic flow path while the real forwarding-relevant information are carried and updated in the path. It can therefore obtain information of a real traffic flow path through IP/MPLS heterogeneous network environments. It is worthy of noticing that this mechanism requires support of all fowarding devices. It is suitable to be used within a single administration domain. 2. Procedures of the IP/MPLS Heterogeneous Traceroute Mechanism Yin, et al. Expires April 24, 2014 [Page 2] Internet-Draft Traceroute in IP/MPLS Heterogeneous Env October 2013 The new traceroute mechanism, introduced by this document, mainly targets the IP/MPLS heterogeneous networks. In order to describe the applicable scenarios and procedures, in this document, below network topology illustrates a traceroute example scenaio, in which the IP load balancing and traversing a MPLS network are demonstrated. |<-----------------Administration Domain--------------->| | |<-MPLS Domain->| | | +---+ +---+ +---+ | | +---| C |---| M1|---| E |---+ | +---+ | +---+ +---+ | +---+\ /+---+\ /+---+ | +---+ | +---+ | S |---| A |---| B |---+ X X +---| G |---| D | +---+ | +---+ +---+ | +---+/ \+---+/ \+---+ | +---+ | +---+ | +---| D |---| M2|---| F |---+ | | +---+ +---+ +---+ | | |<-MPLS Domain->| | |<-----------------Administration Domain--------------->| The real traffic is from the S(ource) node to the D(estination) node. The traceroute request is initialized at node A, and ideally terminated at node G. From the node B, the IP packet may be forwarded to node C or node D. Then it is MPLS domain, where the intermedia device M1 or M2 cannot be detected by current IP ping/trace mechanism. This mechanism assume that all MPLS nodes have IP connectivities and can communicate with each other according to IP addresses. In the new traceroute mechanism, the traceroute requesting node passes three type of information, as illustrated in the below figure, to the next hop. An example of traceroute request message: +-----------------------------------------------------+ | IP & UDP header for Echo-Request Message | +-----------------------------------------------------+ |Forwarding-Decide field contains Real IP/MPLS headers| +-----------------------------------------------------+ | Options | +-----------------------------------------------------+ The IP and UDP headers indicate the recipient - this is a traceroute request. The Forwarding-Decide field contains real IP/MPLS headers, copied from a packet in a real traffic flow, or pseudo headers forming to represent a traffic flow. It may include IP header, MPLS header and TCP/UDP header. The IP/MPLS headers in the Forwarding- Yin, et al. Expires April 24, 2014 [Page 3] Internet-Draft Traceroute in IP/MPLS Heterogeneous Env October 2013 Decide field are maintained or modified in the exactly same way when a real traffic packet is processed in the forwarding procedure. Every on-path node decides the next hop according to the Forwarding- Decide field. This would guarantee the traced route follows the same path of the real traffic packet, because the forwarding decide information is exactly same. Options are mainly used to indicate the on-path nodes requested information and the return path. The on-path nodes report the requested information of themselves to the traceroute requesting node directly. 2.1. New Components Needed There are a few new components needed in order to fulfil the newly- introduced hop-by-hop traceroute mechanism. They are listed below. Traceroute Port A well-known UDP port that indicates the recipient devices that received UDP mesages are for traceroute purpose. An echo request message: a new UDP message that is carrying the traceroute request. It is processed, may be modified, then passed on hop by hop. * Transaction ID, used to distinguish mutliple traceroute requests initiated by the same traceroute requesting node. * Forwarding-Decide field, contains all information that may affect the path choice for a specific packet, including IP header, TCP/UDP header, MPLS header, and IP tunnel header. The field contents are maintained or modified in the exactly same way when a real IP packet is processed in the forwarding procedure. * Required-Information option, used to indicate the on-path nodes the information desired by the traceroute requesting node. * Return-Path field, used to indicate the return path for the responsed Echo-Reply message. It operates like a stack: the closed relay nodes first, then second close, till the original requesting node. An echo reply message: a new UDP message that is used to return the requested information of intermedia node to the traceroute requesting node. * Transaction ID, copied from the correspondent Echo-Request message. It is used to distinguish mutliple traceroute requests initiated by the same traceroute requesting node. Yin, et al. Expires April 24, 2014 [Page 4] Internet-Draft Traceroute in IP/MPLS Heterogeneous Env October 2013 * Information options, the information of the requested node. They are the response to the required information option. * Return-Path field, copied from the correspondent Echo-Request message. The MPLS or tunnel ingress nodes need these information to relay the Echo-Reply message to the traceroute requesting node. The detailed format or data structure is out of scope for this informational document. 2.2. Form a New Echo-Request Message In the new traceroute mechanism, the traceroute request device (node A) forms an Echo-Request message, in which the Forwarding-Decide field contains a real IP header and TCP/UDP hearder that is copied from a packet in a real traffic flow, or a pseudo IP header and TCP/ UDP hearder, towards node D. This Echo-Request message also indicates what information of these on-path devices are desired. The traceroute request device also records itself in the Return-Path field. The Echo-Request message is carried by an IP packet, which the destination address is filled by the loopback address and source address is the requesting node itself. IP TTL is set to value that indicate the maximum trace route hops. It then sends the new IP packet towards the next hop according to the Forwarding-Decide field. This mechanism description in this section currently assumes that the traceroute requests start from IP. 2.3. Process an Echo-Request Message Upon receiving the IP packet that contains an Echo-Request message, the recipiet node processes it to the new traceroute function, because of the loopback address and the newly defined Traceroute port. There are four follow-up procedures on the recipient: responsing its own information, updating Fowarding-Decide field, updating Return-Path field, and sending a new Echo-Request message. 2.3.1. Response requested information The new traceroute function returns the requested information of this node, according to Required-Information option in the Echo-Request message, back to the traceroute requesting node (or the closest relay node), by sending an Echo-Reply message. Yin, et al. Expires April 24, 2014 [Page 5] Internet-Draft Traceroute in IP/MPLS Heterogeneous Env October 2013 The IP address of the traceroute requesting node or the closest relay node, is obtained from the Return-Path field of the Echo-Request message. Transaction ID is copied from the Echo-Request message. The Return-Path field from the Echo-Request message must be copied into the Echo-Reply message. 2.3.2. Update Routing-Decide field The Forwarding-Decide field is maintained/modified in the exactly same way when the real traffic packet that the Forwarding-Decide field represents is processed, including add/remove new MPLS header, update MPLS label, add/remove IP tunnel header, NAT44 or NAT66 translation or etc. 2.3.3. Update Return-Path field The node first check whether the second close node in the Return-Path field is reachable or not. If yes, it removes the closest node in the Return-Path field; if not, do nothing. Note, if there is only one node in the Return-Path field, it must not be removed. The node then adds the IP address of itself into the Return-Path field, and the necessary information that this node must have in order to distinguish the previous node, such as Virtual Routing and Forwarding (VRF) information, etc. 2.3.4. Send a new Echo-Request message This node then forms a new IP packet, in which the destination address is filled by the loopback address, source address is itself. It carries the Echo-Request message in the payload. TTL in IP header is reduced by 1 every hop. According to the MPLS header, if there is, IP header and TCP/UDP hearder in the Forwarding-Decide field, the device decides the next hop, then sends the new IP packet towards the next hop. 2.4. Process an Echo-Reply Message Upon receiving an Echo-Reply message that the destination IP address is itself, the recipient must decide whether the Echo-Reply is terminate here or needs to be relayed out, by checking whether it is the last node in the Return-Path field. Yin, et al. Expires April 24, 2014 [Page 6] Internet-Draft Traceroute in IP/MPLS Heterogeneous Env October 2013 If it is not the last node, it must be the first node. It then obtains the necessary information for it to distinguish the next node. It removes itself out of the stack of the Return-Path field. It then relays the Echo-Reply message to the next relay node or the original requesting node that it learns from the Return-Path field. 2.5. Termination of the Traceroute Request Ideally, the traceroute request should be terminated at the edge of the administration domain if the traffic destination was out of domain, Node G in the example scenario. The forwarding devices on the edge of the administration domain should be configured not to send traceroute messages out on the interfaces that connected to subscribers or devices out of the administration domain. However, the leak of traceroute request message should not bring much impact. The subscriber node does not support this traceroute function would drop it siliently as unknown message. The ingress devices of another administration domain or another ISP/transit network would filter this message. 3. Security Considerations Without an authentication mechanim, this mechanism would be risk to expose network device information. It should only be used either when combines with an authentication mechanim or in a closed single administration domain, in which the end user requests or request from outside of this administration domain should be filtered at the edge of the sdministration domain. The leak of traceroute request message does not create much security risk. The information carried with in the message does not contain much sensitive information of the network. The only potential risk information is exposing of the IP addresses of intermediate forwarding devices in the return parth option. 4. IANA Considerations This memo includes no request to IANA. 5. Acknowledgements This document was produced using the xml2rfc tool [RFC2629]. 6. Change log [RFC Editor: Please remove] draft-yin-hopbyhop-traceroute-00: original version. 2013-10-21. Yin, et al. Expires April 24, 2014 [Page 7] Internet-Draft Traceroute in IP/MPLS Heterogeneous Env October 2013 7. Informative References [I-D.yin-tsvwg-ipflow-pathtrace-ps] Yin, Y., Jiang, S., and G. Yan, "IP Flow Path Trace Requirements", draft-yin-tsvwg-ipflow-pathtrace-ps-00 (work in progress), July 2013. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Authors' Addresses Yuanbin Yin Huawei Technologies Co., Ltd Q15, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: yinyuanbin@huawei.com Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Zhenbin Li Huawei Technologies Co., Ltd Q15, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: lizhenbin@huawei.com Mach(Guoyi) Chen Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: mach.chen@huawei.com Yin, et al. Expires April 24, 2014 [Page 8]