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