IPv6 Operations N. Elkins Internet-Draft M. Ackermann Intended status: Best Current Practice INT Council Expires: 24 August 2023 D. Dhody India Internet Engineering Society 20 February 2023 Deep Dive into IPv6 Extension Header Testing: Behind a CDN draft-elkins-v6ops-eh-deepdive-cdn-00 Abstract This document proposes a methodology for isolating the location and reasons for IPv6 Extension Headers blockage in a network where the operator has access to install products and run diagnostic tests on both the client and server. The client will be outside the Content Delivery Network (CDN) and the server inside the CDN. This document will discuss the testing and topology which need to be considered when testing using a CDN infrastructure. This document is a part of the Deep Dive into EH Testing set of documents. 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 https://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 24 August 2023. Copyright Notice Copyright (c) 2023 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 (https://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 Elkins, et al. Expires 24 August 2023 [Page 1] Internet-Draft Deep Dive IPv6 EH CDN February 2023 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 1.2. Initial Setup Requirements . . . . . . . . . . . . . . . 3 2. CDN Topology and Concepts . . . . . . . . . . . . . . . . . . 3 3. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Connection from Client to Edge of CDN . . . . . . . . . . 5 3.2. Connection from Edge of CDN to Origin Server . . . . . . 5 4. What can go wrong? . . . . . . . . . . . . . . . . . . . . . 5 5. Recommendations and Further Work . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 1.1. Problem Description [I-D.elkins-v6ops-eh-deepdive-fw] proposes a framework to isolate the problem of where the IPv6 [RFC8200] packet is being dropped when Extension Headers (EHs) are used. This document further proposes a framework to isolate the location and reasons for IPv6 Extension Headers blockage in a network where the operator has access to install products and run diagnostic tests on both the client and server. The client will be outside the Content Delivery Network (CDN) and the server inside the CDN. The reason it is important to have control over both client and server is so that diagnostic tests can be run at both ends at the same time. This way, the operator can see if the packets are being sent properly and received properly. Our initial findings are that IPv6 Extension Headers will work to the edge of the CDN. CDN providers need to be encouraged to: Elkins, et al. Expires 24 August 2023 [Page 2] Internet-Draft Deep Dive IPv6 EH CDN February 2023 * Support IPv6 to the Origin Server * Support Extension Headers to the Origin Server 1.2. Initial Setup Requirements The initial setup requires a: * Client * Server * Content Delivery Network You also need to decide whether to craft packets with EH or to enable a client and server which have the ability to send EH along with each packet. You may wish to refer to the discussion in the [I-D.elkins-v6ops-eh-deepdive-fw] document for a detailed review of the options as well as the pros and cons of the decision. To set up the client and server, you may wish to refer to the discussion in the [I-D.elkins-v6ops-eh-deepdive-cs] document. This document will focus on the setup and topology of the CDN network and the challenges this poses for testing. 2. CDN Topology and Concepts You may wish to view Figure 1 for a simple topology. Clearly, within a CDN network, there can be a great deal of complexity including connections to other CDNs and so forth. Elkins, et al. Expires 24 August 2023 [Page 3] Internet-Draft Deep Dive IPv6 EH CDN February 2023 +-----------------+ +--------------------------+ +-----------------+ | | | | CDN Network | | +--------+ | | | +---------+ | | | client |---------| Internet |----| | Edge | | | +--------+ | | | | Server | | | | | | +---------+ | | +--------------------------+ | | | | (LB, Firewall | | | Cache etc) | | | | | | | | | | | | |-+ +-----------------+ | | (*) | +---------+ | Origin | | server | +---------+ (*) - can be over the internet Figure 1: Server behind CDN The basic premise of a Content Delivery Network is to place servers which hold the content of a web site nearer to the client so as to speed the delivery of the desired data. Let us call these "caching servers". The web site which is the real end server, we will call the "origin server". This origin server is what we control and is enabled to send IPv6 Extension Headers. 3. Connections In this document, we will confine ourselves to a discussion of the connections between: * the client and the edge of the CDN * the edge of the CDN and the origin server These are the connections which we can observe and trace. Elkins, et al. Expires 24 August 2023 [Page 4] Internet-Draft Deep Dive IPv6 EH CDN February 2023 3.1. Connection from Client to Edge of CDN Before initiating the connection from the client (which we control) to the CDN, we must discuss the role of DNS. When we initially place our web server (origin server) behind the CDN, we must give the CDN provider the ability to resolve our domain name, that is the CDN will become the DNS server for us. We must then configure the DNS to resolve the domain name into an IPv6 address or an IPv4 address. We can also tell the DNS which type of address to prefer. This will dictate the way how the connection from the client to the edge of the CDN is done. CDN providers may differ in their support of: * whether resolution to an IPv6 address is provided * whether resolution to an IPv6 address is preferred One might think that even if resolution to an IPv6 address is not preferred, we may be able to force resolution to IPv6 address by creating an IPv6-only server. This would be an incorrect assumption. We will discuss this further in the next section. 3.2. Connection from Edge of CDN to Origin Server CDN providers may differ in their support of whether the connection from the edge of the CDN network to the origin server will be in IPv6 or IPv4. For some CDNs, it may be possible to configure IPv6 to the origin. In other cases, it is not possible to do so. That is, the connection to the origin server will travel in IPv4 regardless of whether the connection from the client to the edge of the CDN is IPv6. As discussed previously, one might think that even if DNS resolution to an IPv6 address is not preferred, we may be able to force resolution to IPv6 address by creating an IPv6-only server. We may also apply that thinking to the connection between the edge of the CDN to the origin server. In both cases, we would be wrong. In many cases, the connection simply fails to work at all. 4. What can go wrong? We have spent time in discussing the IPv6 support, in particular to the origin servers by CDN providers because clearly, if IPv6 itself is not supported to the origin server, then IPv6 Extension Headers to the origin server will not work. Elkins, et al. Expires 24 August 2023 [Page 5] Internet-Draft Deep Dive IPv6 EH CDN February 2023 Even in the cases where IPv6 to the origin server is provided, we know of no cases where IPv6 Extension Headers are passed from the edge of the CDN provider to the origin server. This is a WorkInProgress. We continue to work with some CDN providers to discuss this type of support. 5. Recommendations and Further Work Our initial findings are that IPv6 Extension Headers will work to the edge of the CDN. CDN providers need to be encouraged to: * Support IPv6 to the Origin Server * Support Extension Headers to the Origin Server 6. Security Considerations This document has no security considerations. 7. Privacy Considerations This document has no privacy considerations. 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 9.2. Informative References [I-D.elkins-v6ops-eh-deepdive-cs] Elkins, N., ackermann, M., and D. Dhody, "Deep Dive into IPv6 Extension Header Testing: Standalone Client / Server", Work in Progress, Internet-Draft, draft-elkins- v6ops-eh-deepdive-cs-00, 5 October 2022, . Elkins, et al. Expires 24 August 2023 [Page 6] Internet-Draft Deep Dive IPv6 EH CDN February 2023 [I-D.elkins-v6ops-eh-deepdive-fw] Elkins, N., ackermann, M., and D. Dhody, "Deep Dive into IPv6 Extension Header Testing", Work in Progress, Internet-Draft, draft-elkins-v6ops-eh-deepdive-fw-01, 21 October 2022, . Acknowledgments TODO acknowledge. Contributors TODO contributors. Authors' Addresses Nalini Elkins Industry Network Technology Council United States of America Phone: +1 831 234 4232 Email: nalini.elkins@insidethestack.com Michael Ackermann Industry Network Technology Council United States of America Phone: +1 248 703 3600 Email: mackermann@bcbsm.com URI: https://www.bcbsm.com Dhruv Dhody India Internet Engineering Society India Email: dhruv.ietf@gmail.com Elkins, et al. Expires 24 August 2023 [Page 7]