Internet Engineering Task Force N. Elkins Internet-Draft M. Ackermann Intended status: Informational Industry Network Technology Council Expires: 8 April 2023 D. Dhody India Internet Engineering Society 5 October 2022 Deep Dive into IPv6 Extension Header Testing: Standalone Client / Server draft-elkins-v6ops-eh-deepdive-cs-00.txt 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. Neither the client nor the server should be behind a CDN or on a Cloud 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 8 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Elkins, et al. Expires 8 April 2023 [Page 1] Internet-Draft Deep Dive into IPv6 EH-Testing October 2022 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 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 1.3. Diagnostic Methodology Overview . . . . . . . . . . . . . 3 2. Initial Test: CURL to IP Address of Server without EH . . . . 4 3. Second Test: CURL to IP Address of Server with EH . . . . . . 4 3.1. Client Packets Not Received by Server . . . . . . . . . . 5 3.2. Server Packets Not Received by Client . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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. Neither the client nor the server should be behind a CDN or on a cloud infrastructure. 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. Being behind a CDN or on a cloud infrastructure poses its own set of complexities. These will be discussed in later documents. Of course, there is the problem of what happens if packets are sent by the client and not received at the server! This document will Elkins, et al. Expires 8 April 2023 [Page 2] Internet-Draft Deep Dive into IPv6 EH-Testing October 2022 discuss some of the potential blockage points. If the steps discussed here do not resolve the issue, then one of the other documents on isolating EH problems should be used. The documents in this series are: - EH problem isolation for standalone client / server - EH problem isolation in a network using a CDN - EH problem isolation in a network using a cloud provider - EH problem isolation for routers - EH problem isolation for load balancers - EH problem isolation for proxies - EH problem isolation for host OSs - EH problem isolation for transit networks - EH problem isolation for ISPs (multiple components / networks) 1.2. Initial Setup Requirements The initial setup requires a: - Client - Server 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. 1.3. Diagnostic Methodology Overview The following methodology assumes that the operator has: - a test server enabled to send EH with every packet - 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) Elkins, et al. Expires 8 April 2023 [Page 3] Internet-Draft Deep Dive into IPv6 EH-Testing October 2022 2. 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. 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 IP address of the server. You may wish to use HTTP rather than HTTPS to avoid problems with TLS or certificate issues. You may also wish to use the explicit IP address rather than a domain name to eliminate the complexity associated with DNS. 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. 3. 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 IP address of the EH enabled test server. You may wish to use HTTP rather than HTTPS to avoid problems with TLS or certificate issues. You may also wish to use the explicit IP address rather than a domain name to eliminate the complexity associated with DNS. 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 2. Packets are sent by the server but not received by the client Elkins, et al. Expires 8 April 2023 [Page 4] Internet-Draft Deep Dive into IPv6 EH-Testing October 2022 3.1. Client Packets Not Received by Server If the packets are sent by the client but not received by the server, then you may conclude that somewhere in the path from the server to the client, EHs are being blocked. The simplest thing to do at this point is to check any firewall or other logs OS to see if the packet reached the server. At a minimum, the initial packet (TCP SYN) which does not have an EH because the client is not EH enabled) should get through. 3.2. Server Packets Not Received by Client If the TCP SYN packet is received by the server and a TCP SYN-ACK with an EH is sent by the server (which can be seen in the packet trace), then you may conclude that somewhere in the path from the server to the client, EHs are being blocked. The simplest thing to do at this point is to check any firewall or other logs at the OS to see if the packet reached the client. If the answer to this is that it did not, then you may wish to repeat this test from other clients which may use a different topology. If the same issue occurs, then refer to the other documents in this series for an in-depth look at how to diagnose problems in routers, transit networks, and so on. 4. Security Considerations This document has no security considerations. 5. Privacy Considerations This document has no privacy considerations. 6. IANA Considerations This memo includes no request to IANA. 7. References 7.1. Normative References 7.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-00, October 2022. Elkins, et al. Expires 8 April 2023 [Page 5] Internet-Draft Deep Dive into IPv6 EH-Testing October 2022 Contributors TBD 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: http://www.bcbsm.com Dhruv Dhody India Internet Engineering Society Email: dhruv.ietf@gmail.com Elkins, et al. Expires 8 April 2023 [Page 6]