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-01
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? . . . . . . . . . . . . . . . . . . . . . 6
5. Diagnostic Methodology . . . . . . . . . . . . . . . . . . . 6
5.1. Initial Test: CURL to IP Address of Server without EH . . 6
5.2. Second Test: CURL to IP Address of Server with EH . . . . 7
6. Recommendations and Further Work . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
Elkins, et al. Expires 24 August 2023 [Page 2]
Internet-Draft Deep Dive IPv6 EH CDN February 2023
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
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 "Edge
Servers". You may see the term "Cache Server" also used in some
documentation on CDNs.
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.
Some CDNs use an external DNS service or resolver. In any case, what
is important is that the authoritative DNS must resolve to an IP
address owned by a CDN Edge server (which may vary by client
location).
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.
Elkins, et al. Expires 24 August 2023 [Page 5]
Internet-Draft Deep Dive IPv6 EH CDN February 2023
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.
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. Diagnostic Methodology
Once you have set up the client, server and CDN definitions properly,
we may begin to test.
The following methodology assumes that the operator has:
* an Origin Server enabled to send EH with every packet
* the Origin Server is behind a CDN
* the Origin Server is running an IPv6 enabled web server (Apache /
NGINX / Tomcat, et al)
* a packet trace capture tool such as TCPDump, WireShark, etc.
With this setup, only the server needs to be enabled to send EH. The
client does not need to be able to send EHs, although, if that is a
possibility, it will definitely add richness to the testing. You may
wish to see the Deep-Dive Framework draft for more explanation on how
to send EHs.
We will do two sets of tests:
1. Without EH (to test initial connectivity)
2. With EH (to test EH transmission)
5.1. Initial Test: CURL to IP Address of Server without EH
The first step is to see if the client and server can communicate
properly without EH. If that is successful, we can then continue to
enable EH.
Elkins, et al. Expires 24 August 2023 [Page 6]
Internet-Draft Deep Dive IPv6 EH CDN February 2023
Step 1: Bring up the web server on the server. Configure it to NOT
send EHs Step 2: Start a TCPDump / Wireshark packet trace on the
server Step 3: Start a TCPDump / Wireshark packet trace on the client
Step 4: Do an HTTP CURL from the client to the Domain Name of the
server.
You may wish to use HTTP rather than HTTPS to avoid problems with TLS
or certificate issues.
You should see packets flowing from both ends in the packet trace.
If you do not see packets, then there may be an something on the path
which is stopping traffic or a configuration problem. This needs to
be resolved before proceeding.
Questions you should ask:
1. Are you sending IPv6 packets from the client to the CDN Edge or
Cache Server?
2. Are you sending IPv6 packets from the CDN Edge or Cache Server to
the Origin Server?
If the answer to the first question is "No", then you should look at
the DNS or other configuration.
If the answer to the second question is "No", then you should see if
it is possible with your CDN to send IPv6 packets to the Origin
Server. If this is possible, then you may have a configuration
problem of some kind. This needs to be fixed before proceeding.
5.2. Second Test: CURL to IP Address of Server with EH
If you are successful with the previous tests, then you may enable
EHs on the server end.
Step 1: Enable EH on the server hosting the web server Step 2: Start
a TCPDump / Wireshark packet trace on the server Step 3: Start a
TCPDump / Wireshark packet trace on the client Step 4: Do an HTTP
CURL from the client to the Domain Name of the EH enabled test
server. You may wish to use HTTP rather than HTTPS to avoid problems
with TLS or certificate issues.
You should see packets flowing from both ends in the packet trace.
The EHs will be from the server only. If you do not see packets,
then decide which of the following problems matches what you are
seeing best.
1. Packets are sent by the client but not received by the server
Elkins, et al. Expires 24 August 2023 [Page 7]
Internet-Draft Deep Dive IPv6 EH CDN February 2023
2. Packets are sent by the server but not received by the client
In these scenarios, you will most likely need to discuss with your
CDN provider if it is possible to send IPv6 packets with EH to the
Origin Server.
6. 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
7. Security Considerations
This document has no security considerations.
8. Privacy Considerations
This document has no privacy considerations.
9. IANA Considerations
This document has no IANA actions.
10. References
10.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,
<https://www.rfc-editor.org/rfc/rfc8200>.
10.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,
<https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-
eh-deepdive-cs-00>.
Elkins, et al. Expires 24 August 2023 [Page 8]
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, <https://datatracker.ietf.org/doc/html/
draft-elkins-v6ops-eh-deepdive-fw-01>.
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 9]