IPv6 Flow Label
draft-ytti-v6ops-flow-label-00

Abstract

This document specified behaviour of IPv6 Flow Label field.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 September 13, 2019.

Copyright Notice

Copyright (c) 2019 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 and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Problem Statement
• 2. Terminology
• 3. Exclusive Key Flag
• 4. References
• 4.1. Normative References
• 4.2. Informative References
• Appendix A. Acknowledgments
• Author's Address

1. Problem Statement

Currently in [RFC6437] IPv6 Flow Label behaviour is defined in such manner that source host cannot predict how setting the Flow Label field will affect behaviour. Source host has two separate problems it may want to communicate. First problem is that source host may want to communicate that two packets with non-identical L3, L4 and LI keys belong to a same flow. Second problem is that source host may want to communicate that two packets with identical L3, L4 and LI keys belong to a different flow. Currenty neither is possible. Host might not use flow label at all for flow speculation, it might use flow label exclusively or it might use some combination. One currently perfectly valid implementation would be to use L3 keys + Flow Label when next-header is not UDP or TCP otherwise use L3 keys + L4 keys.

2. Terminology

This document uses the following terms:

Flow speculation:

Process where host associates packet as a member of a flow

L3 Keys:

Any fields in L3 headers used as keys in Flow Speculation

L4 Keys:

Any fields in L4 headers used as keys in Flow Speculation

LI Keys:

Any other than L3 and L4 headers in IP packet used as keys in Flow Speculation. Host may look beyond L4 for example in tunneling, GTP TEID particularly is commonly supported.

3. Exclusive Key Flag

The most significant bit in IPv6 Flow Label is called EKF or 'Exclusive Key Flag'. When EKF is set host MUST not use any other L3, L4 or LI key for Flow Speculation. When EKF is unset host MAY use other L3, L4 and LI keys for Flow Speculation.

Other keys than L3, L4 and LI keys may still be used for Flow Speculation when EKF is set. Example of other key would be for example an ingress interface.

4. References

4.1. Normative References

4.2. Informative References

Appendix A. Acknowledgments

Author's Address