Internet DRAFT - draft-elkins-v6ops-eh-deepdive-cdn

draft-elkins-v6ops-eh-deepdive-cdn







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]