IPv6 Operations N. Elkins Internet-Draft Inside Products, Inc. Intended status: Informational P. Sinha Expires: 7 January 2024 Independent A. Deshpande Google 6 July 2023 Deep Dive into IPv6 Extension Header Testing: Cloud draft-elkins-v6ops-eh-deepdive-cloud-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 and server will be both inside and outside the Cloud topology. This document will discuss the testing and topology which need to be considered. 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 7 January 2024. 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 7 January 2024 [Page 1] Internet-Draft Deep Dive IPv6 EH Cloud July 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. Cloud Topology and Concepts . . . . . . . . . . . . . . . . . 3 2.1. Inside Cloud Topology . . . . . . . . . . . . . . . . . . 4 2.1.1. Simple Topology . . . . . . . . . . . . . . . . . . . 4 2.1.2. More Realistic Topology . . . . . . . . . . . . . . . 4 2.1.3. Multiple Cloud Data Centers . . . . . . . . . . . . . 4 2.2. Outside Cloud Topologies . . . . . . . . . . . . . . . . 5 2.2.1. Simple Topology . . . . . . . . . . . . . . . . . . . 5 2.2.2. More Realistic Topology . . . . . . . . . . . . . . . 5 2.3. Data Center Outside Cloud (OC-D) . . . . . . . . . . . . 6 2.4. Between Cloud Topology . . . . . . . . . . . . . . . . . 6 3. Configuration of Environment . . . . . . . . . . . . . . . . 6 3.1. Providing IPv6 addresses . . . . . . . . . . . . . . . . 6 3.2. Changing Firewalls . . . . . . . . . . . . . . . . . . . 6 4. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. What can go wrong? . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 1.1. Problem Description This document 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 and server will be both inside and outside the Cloud topology. Elkins, et al. Expires 7 January 2024 [Page 2] Internet-Draft Deep Dive IPv6 EH Cloud July 2023 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. 1.2. Initial Setup Requirements The initial setup requires a: * Client * Server * Cloud provider 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 [Deep-Dive- 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 [Deep-Dive-FW] document. This document will focus on the setup and topology of the Cloud network and the challenges this poses for testing. 2. Cloud Topology and Concepts In a cloud computing environment, clients and servers interact in various configurations, including: Inside Cloud (IC) * Inside Cloud-Single Datacenter (IC-SD) * Inside Cloud-Multiple Datacenters (IC-MD) * Inside Cloud-Standalone Outside Cloud (IC-S) * Inside Cloud-Data Center Outside Cloud (IC-D) Outside Cloud (OC) * Standalone Outside Cloud - Inside Cloud-(OC-S) * Data Center Outside Cloud - Inside Cloud-(OC-D) * Cloud #1 - Cloud #2 (OC-BC) Elkins, et al. Expires 7 January 2024 [Page 3] Internet-Draft Deep Dive IPv6 EH Cloud July 2023 2.1. Inside Cloud Topology In this configuration, both the client and server exist within the same cloud environment. The client accesses the server's resources, data, and applications through the cloud infrastructure itself. 2.1.1. Simple Topology You may wish to view Figure 1 for a simple topology. +----------------------------------------+ | Cloud Network | | +--------+ +---------+ | | | client |--------- | | | | +--------+ | Server | | | | | | | +---------+ | | | +----------------------------------------+ Figure 1: Inside Cloud Environment 2.1.2. More Realistic Topology This topology includes third party boxes, multiple layers of firewalls, potential load balancers which may be between the client and server within a cloud environment. +------------------------------------------------+ | Cloud Network | | +--------+ +------+ +---------+ | | | client |-- | LB, |---------| | | | +--------+ | FW, | | Server | | | | etc. | | | | | +------+ +---------+ | | | +------------------------------------------------+ Figure 2: More Realistic Inside Cloud Environment 2.1.3. Multiple Cloud Data Centers Cloud providers may have multiple data centers. So, behavior that is entirely within one cloud provider may be different depending on if the activity is entirely within one data center or crosses data center boundaries. Elkins, et al. Expires 7 January 2024 [Page 4] Internet-Draft Deep Dive IPv6 EH Cloud July 2023 2.2. Outside Cloud Topologies Ihe Outside Cloud topologies involve clients and servers where one may be inside the cloud while the other operates outside of it. The external device could be in a stand-alone environment, behind a content delivery network (CDN), in a data center or in another cloud. 2.2.1. Simple Topology You may wish to view Figure 3 for a simple topology. Cloud Network +--------------------------+ +-----------------+ | | | | +--------+ | | | +---------+ | | client |---------| Internet |----| | | | +--------+ | | | | Server | | | | | | | | | | | +---------+ | +--------------------------+ | | | | | | | | | | +-----------------+ Figure 3: Simple Outside Cloud Environment 2.2.2. More Realistic Topology You may wish to view Figure 4 for a more realistic topology. This topology includes third party boxes, multiple layers of firewalls, potential load balancers which may be between the edge of the cloud and the server itself. Cloud Network +-------------------+ +-------------------------+ | | | | +--------+ | | | +----+ +-------+ | | Client |-------} Internet +-----|-------------|LB,-|--| Server || +--------+ | | | |FW..| | || | | | IPv6 +----+ | IPv6 || +-------------------+ | +--------+| | Subnet | +-------------------------+ Elkins, et al. Expires 7 January 2024 [Page 5] Internet-Draft Deep Dive IPv6 EH Cloud July 2023 Figure 4: Outside Cloud Realistic Environment 2.3. Data Center Outside Cloud (OC-D) An organizational data center which is outside the cloud connecting to / from devices inside a cloud is sometimes called a hybrid cloud deployment. This combines cloud-based and on-premises infrastructure. In such configurations, either the client or server operates within the cloud environment, while the other resides outside of it. This is an Outside Cloud (OC) deployment, but we add the distinction that one of the partners is in a managed data center. The managed data center may introduce its own layers of firewalls, load balancers and the like. 2.4. Between Cloud Topology The Between Cloud topology involves using multiple cloud service providers. In this scenario, clients or servers from one cloud provider can interact with clients or servers residing in a different cloud. 3. Configuration of Environment 3.1. Providing IPv6 addresses Within the chosen cloud topology, IPv6 addresses need to be given for the server and client. Some cloud providers have what they call a "private" or "internal" IPv6 address and a "public" or "external" address. 3.2. Changing Firewalls The firewalls within the cloud environment need to be configured to allow access inbound and outbound. Cloud environments may have multiple layers of firewalls. 4. Testing In this document, we will confine ourselves to a discussion of the testing of Inside Cloud (IC) and Outside Cloud (OC) topologies. 5. What can go wrong? It is important to test both sending and retrieving of packets containing extension headers. We have seen some cloud environments which can receive EHs but not send them. These situations require packet traces on both ends so that the situation can be clearly diagnosed. Elkins, et al. Expires 7 January 2024 [Page 6] Internet-Draft Deep Dive IPv6 EH Cloud July 2023 We have also seen cloud environments where the OS supports EHs but the internal network does not. 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 9.2. Informative References [Deep-Dive-FW] Elkins, N., et al, "Deep Dive into IPv6 Extension Header Testing", Work in Progress, draft-elkins-v6ops-eh-deepdive-fw-01, October 2022. Acknowledgments TODO acknowledge. Contributors TODO contributors. Authors' Addresses Nalini Elkins Inside Products, Inc. United States of America Phone: +1 831 234 4232 Email: nalini.elkins@insidethestack.com Elkins, et al. Expires 7 January 2024 [Page 7] Internet-Draft Deep Dive IPv6 EH Cloud July 2023 Priyanka Sinha Independent Email: priyanka.sinha.iitg@gmail.com Ameya Deshpande Google Email: ameyanrd.nitk@gmail.com Elkins, et al. Expires 7 January 2024 [Page 8]