Internet DRAFT - draft-elkins-v6ops-eh-deepdive-cloud
draft-elkins-v6ops-eh-deepdive-cloud
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]
