Network Working Group D. Voyer Internet-Draft D. Bernier Intended status: Informational Bell Canada Expires: April 2, 2018 J. Leddy Comcast C. Filsfils S. Previdi, Ed. Cisco Systems, Inc. S. Salsano Universita di Roma Tor Vergata A. Cianfrani Universita La Sapienza D. Lebrun O. Bonaventure Universite Catholique de Louvain P. Jonnalagadda M. Sharif Barefoot Networks H. Elmalky Ericsson A. Abdelsalam Gran Sasso Science Institute R. Raszuk Bloomberg A. Ayyangar Arista D. Steinberg Steinberg Consulting W. Henderickx Nokia September 29, 2017 Insertion of IPv6 Segment Routing Headers in a Controlled Domain draft-voyer-6man-extension-header-insertion-01 Abstract The network operator and vendor community has clearly indicated that IPv6 header insertion is useful and required. This is notably the case when the entire journey of the packet remains in its source domain. In such a context, it does not matter where the extension header is inserted. The source domain may decide to place the IPv6 extension header insertion where it suits its best: at the source of the packet or at any midpoint within the source domain. Voyer, et al. Expires April 2, 2018 [Page 1] Internet-Draft IPv6 SRH Insertion September 29, 2017 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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." Copyright Notice Copyright (c) 2017 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Source Domain and Packet Journey . . . . . . . . . . . . . . 3 2.1. Example: 6PE . . . . . . . . . . . . . . . . . . . . . . 4 3. Transit through a Source Domain . . . . . . . . . . . . . . . 5 4. SRH insertion in Source Domain . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Manageability Considerations . . . . . . . . . . . . . . . . 7 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 Voyer, et al. Expires April 2, 2018 [Page 2] Internet-Draft IPv6 SRH Insertion September 29, 2017 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction We define the concept of "domain" as the set of nodes under the same administration. For example, a network operator infrastructure including routers and links grouped into BGP autonomous systems (ASs) and routing domains (running OSFP or IS-IS). We define "source domain" as the domain of the source of the packet. 2. Source Domain and Packet Journey (--- Source Domain ---) ( ) ( 1-----2-----3-----9 ) ( | | ) ( 4-----5 ) (---------------------) Figure 1: Source Domain In the previous diagram: o All the nodes 1 to 9 are in the same domain D. o Node 1 originates a packet P1 destined to 9 (SA=1, DA=9). o Domain D runs a link-state routing protocols which implements the Fast Reroute (FRR) service through the Topology Independent Loop Free Alternates (TI-LFA, [I-D.bashandy-rtgwg-segment-routing-ti-lfa]). o All link metrics are set to 10. o Node 2's TI-LFA precomputed backup path for the destination 9 is the Segment Routing Policy <5, 9> via outgoing interface (OIF) to node 4 according to [I-D.filsfils-spring-segment-routing-policy], [I-D.filsfils-spring-srv6-network-programming] and [I-D.ietf-6man-segment-routing-header]. Within the 50 milliseconds of link 2-3 failure detection, node 2 reroutes the traffic destined to 9 by inserting the precomputed segment routing header (SRH) with SID list <5, 9> and forwards the packet to node 4. Node 4 forwards based on DA=5 to neighbor 5. Node Voyer, et al. Expires April 2, 2018 [Page 3] Internet-Draft IPv6 SRH Insertion September 29, 2017 5 updates the DA to 9 and removes the SRH. Node 9 receives the packet with (SA=1, DA=9). This FRR service is clearly beneficial for the operator of domain D: without this FRR operation, depending on the scale of the domain and the quality of the routing convergence implementation, traffic could be dropped for hundreds to thousands of milliseconds waiting for the routing plane to converge. This FRR service is largely deployed with MPLS. It is important to note that the operators industry is strongly requiring the same TI-LFA FRR service without the need to deploy or maintain the MPLS layer. Obviously, this FRR service increases the size of the packet during its journey within domain D. This is well-known to operators. Well- known mitigation techniques have been deployed for more than 15 years for the MPLS-based FRR service and the numerous VPN services. The same exact technique can be used which consists of deploying an infrastructure capable of an MTU value higher in the core than at the ingress edge. 2.1. Example: 6PE An illustrative example of packet size increasing while in transit is given by the 6PE use case ([RFC4798]) and consists of the following: o An ingress router encapsulates incoming IPv6 packets into a MPLS label stack. o The ingress router forwards the encapsulated packet across the MPLS core infrastructure of the operator. o While transiting in the core, the size of the label stack (hence the size of the packet) may increase when additional labels are pushed on top of the packet due to services such as traffic engineering (TE) and/or fast reroute (FRR). o Once the packet reaches the egress router, the label stack is removed and the packet is sent out of the operator network as an IPv6 packet. Using the example topology in Figure 1: o Router 1 receives an incoming IPv6 packet, classifies it and does push a label corresponding to the egress router this packet must reach (router 9). At this stage the packet size has already Voyer, et al. Expires April 2, 2018 [Page 4] Internet-Draft IPv6 SRH Insertion September 29, 2017 increased by the size of one label (32 bits). o In addition, router 1 is configured with a policy consisting of a traffic engineered path (2, 4, 5, 9) represented by an additional label. At this stage the packet size has increased by the size of two labels). o While in transit in the traffic engineered path, a link may fail and fast reroute (FRR) may have been provisioned so that the packet is immediately re-routed (e.g., by router 4) using an additional label. At this stage the packet size has increased by the size of three labels. o It has also to be noted that the packet may be part of a virtual private network (VPN) service in which case it will have an additional label corresponding to the VPN the packet belongs to. In this case the packet size has increased by the size of four labels. o Once the packet reaches its egress router (router 9) the label stack is consumed, the packet shape and size is restored to its original state and the packet is forwarded externally, as a plain IPv6 packet. 3. Transit through a Source Domain (--- Source Domain ---) ( ) A---( 1-----2-----3-----9 )---B ( | | ) ( 4-----5 ) (---------------------) Figure 2: Transit Through a Source Domain We now consider a packet P2 sent from A to B where A and B are external nodes to the domain D. We assume that when node 1 receives the packet, for service transparency reason (the packet that exits the domain MUST be the same as when it entered the domain), node 1 encapsulates the packet P2 in an outer IPv6 header with SA=1 and DA=9. We call the resulting packet P3. Voyer, et al. Expires April 2, 2018 [Page 5] Internet-Draft IPv6 SRH Insertion September 29, 2017 Note that node 1 in Domain D is the source of a new IPv6 packet (P3) that encapsulates P2, therefore we refer to this scenario as "Transit Through a Source domain". From the viewpoint of domain D, packet P3 is the same as packet P1 of the previous use-case. Indeed, domain D only considers the outer header and from that viewpoint, the outer header is the same: (SA=1, DA=9). Furthermore, as for packet P1, the entire journey of packet P3 is contained within domain D. Node 2 may thus rightfully insert an SRH on packet P3 to implement a sub-50 milliseconds FRR operation upon the loss of the link 2-to-3 and node 5 can remove this SRH. The transparency of the service is guaranteed: the insertion and removal of the SRH on packet P3 has no impact on packet P2. P2 at the exit of the domain D is the same as at the entrance of the domain D. Customers of the transit service offered by domain D do demand FRR services. The 50 millisecond FRR operation provides a much better service availability than 100's to 1000's of milliseconds of loss for each routing transition. 4. SRH insertion in Source Domain This document reminds that for a packet whose journey is completely contained within its source domain, it does not matter where the IPv6 extension header insertion is done. It could be at the source or at the first-hop router or at any node of the source domain. The source domain owns the packet and decides the location, which suits it best. During the packet journey in the source domain, any node in the source domain may insert an SRH and the egress node MUST remove both the outer IPv6 header and inserted SRH. In conclusion, in a context of a controlled/trusted domain, the insertion of SRHs in packets that are sourced within the domain is useful, required and also harmless. Hence, a context-less ban of IPv6 extension header insertion does not make sense. Voyer, et al. Expires April 2, 2018 [Page 6] Internet-Draft IPv6 SRH Insertion September 29, 2017 5. Security Considerations This document proposes to insert an SRH to a transit packet if such packet is originated and destined within a controlled/trusted domain. Typically, when an operator encapsulates an externally received packet and sends this packet in a tunneled mode from ingress to egress, insertion of SRH is safe and confined within the operator's infrastructure. In such conditions, the security of the original packet is not compromised by header insertion and the packet leaves the operator's domain without the any header that the operator may have added. A controlled/trusted domain can operate SRv6-based services for internal traffic while preventing any external traffic from accessing these internal SRv6-based services. Several mechanisms exists and are currently used by operators. Here follows a non-exhaustive example list: o Access-lists (ACL) on the each externally facing interface in order to drop any incoming traffic with SA or DA belonging to the internal SID space. o ACL to prevent access to local SIDs from outside the operator's infrastructure. o Support Unicast-RPF on source address on external interface. 6. IANA Considerations This document doesn't introduce any IANA request. 7. Manageability Considerations TBD 8. Contributors TBD 9. Acknowledgements TBD 10. References Voyer, et al. Expires April 2, 2018 [Page 7] Internet-Draft IPv6 SRH Insertion September 29, 2017 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.bashandy-rtgwg-segment-routing-ti-lfa] Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., and P. Francois, "Abstract", draft-bashandy-rtgwg-segment- routing-ti-lfa-00 (work in progress), February 2017. [I-D.filsfils-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, S., bogdanov@google.com, b., Horneffer, M., Clad, F., Steinberg, D., Decraene, B., and S. Litkowski, "Segment Routing Policy for Traffic Engineering", draft-filsfils- spring-segment-routing-policy-00 (work in progress), February 2017. [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., Sharif, M., Ayyangar, A., Mynam, S., Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network Programming", draft-filsfils-spring-srv6-network- programming-00 (work in progress), March 2017. [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- segment-routing-header-06 (work in progress), March 2017. [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, February 2007, . Voyer, et al. Expires April 2, 2018 [Page 8] Internet-Draft IPv6 SRH Insertion September 29, 2017 Authors' Addresses Daniel Voyer Bell Canada Montreal CA Email: daniel.voyer@bell.ca Daniel Bernier Bell Canada Montreal CA Email: daniel.bernier@bell.ca John Leddy Comcast 4100 East Dry Creek Road Centennial, CO 80122 US Email: John_Leddy@comcast.com Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy Email: sprevidi@cisco.com Stefano Salsano Universita di Roma Tor Vergata Rome IT Voyer, et al. Expires April 2, 2018 [Page 9] Internet-Draft IPv6 SRH Insertion September 29, 2017 Email: stefano.salsano@uniroma2.it Antonio Cianfrani Universita La Sapienza Rome Italy Email: antonio.cianfrani@uniroma1.it David Lebrun Universite Catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve, 1348 Belgium Email: david.lebrun@uclouvain.be Olivier Bonaventure Universite Catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve, 1348 Belgium Email: olivier.bonaventure@uclouvain.be Prem Jonnalagadda Barefoot Networks US Email: prem@barefootnetworks.com Milad Sharif Barefoot Networks US Email: msharif@barefootnetworks.com Hani Elmalky Ericsson US Email: hani.elmalky@ericsson.com Voyer, et al. Expires April 2, 2018 [Page 10] Internet-Draft IPv6 SRH Insertion September 29, 2017 Ahmed Abdelsalam Gran Sasso Science Institute IT Email: ahmed.abdelsalam@gssi.infn.it Robert Raszuk Bloomberg Email: robert@raszuk.net Arthi Ayyangar Arista Email: arthi@arista.com Dirk Steinberg Steinberg Consulting DE Email: dws@dirksteinberg.de Wim Henderickx Nokia BE Email: wim.henderickx@nokia.com Jeff Tantsura Individual Email: jefftant@gmail.com Voyer, et al. Expires April 2, 2018 [Page 11]