Internet DRAFT - draft-peng-v6ops-eh-deployment-considerations
draft-peng-v6ops-eh-deployment-considerations
Network Working Group S. Peng
Internet-Draft G. Fioccola
Intended status: Informational J. Dong
Expires: 14 September 2023 Huawei Technologies
13 March 2023
Deployment considerations of IPv6 packets with options
draft-peng-v6ops-eh-deployment-considerations-00
Abstract
As more and more new services using IPv6 options have been proposed
and start being deployed in a large-scale network environment, issues
also start showing up in deployments. This document describes and
analyzes the issues encountered, and aims to provide deployment
guidance when the IPv6 options are used.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [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 14 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Peng, et al. Expires 14 September 2023 [Page 1]
Internet-Draft IPv6 Options Deployment March 2023
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SRH TLV vs. DOH Options . . . . . . . . . . . . . . . . . . . 3
3.1. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 3
3.2. Implementation . . . . . . . . . . . . . . . . . . . . . 4
3.3. Cost . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Deployment guidance . . . . . . . . . . . . . . . . . . . 4
4. Generic Option vs. Specific Option . . . . . . . . . . . . . 4
4.1. Implementation . . . . . . . . . . . . . . . . . . . . . 5
4.2. Extending the allocation space of Option Type . . . . . . 5
4.2.1. Backwards compatibility . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
More and more new services using IPv6 options, such as
[I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking Method
[RFC9343], Minimum Path MTU Hop-by-Hop Option [RFC9268], and Virtual
Transport Network (VTN) [I-D.ietf-6man-enhanced-vpn-vtn-id], have
been proposed. They start being deployed in a large-scale network
environment. However, since IPv6 especially with options has not
been widely deployed, some issues start showing up in deployments
[RFC9098]. It is important to analyze these issues, provide guidance
on their reasonable usages, and help progress their deployments in
large-scale networks [I-D.ietf-6man-eh-limits].
This document describes and analyzes the issues encountered, and aims
to provide deployment guidance when the IPv6 options are used.
Peng, et al. Expires 14 September 2023 [Page 2]
Internet-Draft IPv6 Options Deployment March 2023
2. Terminology
The terms used in this draft refer to the terminologies as defined in
[RFC8200] and [RFC8754].
3. SRH TLV vs. DOH Options
As specified in [RFC8200], the Destination Options header (DOH) is
used to carry optional information that needs be examined only by a
packet's destination node(s). When a Routing header (RH) exists, the
DOH before RH is "for options to be processed by the first
destination that appears in the IPv6 Destination Address field plus
subsequent destinations listed in the Routing header", while the one
after RH is "for options to be processed only by the final
destination of the packet".
As specified in [RFC8754], SR segment endpoint nodes process the
local segment (SID) corresponding to the packet destination address
(DA). Then, the DA is updated according to the segment list. The
Segment Routing Header TLV (SRH TLV) provides metadata for segment
processing, while processing the SID, if the node is locally
configured to do so.
From the aspect of processing function, both the DOH before RH and
SRH TLV are processed at the node being indicated in the DA field of
the IPv6 header. Both can co-exist according to current
specifications, which raises an issue of choice phobia in
deployments.
The two options are analyzed in the following aspects to provide
deployment guidance.
3.1. Usage scenarios
In an IPv6 network without SRv6 being supported, i.e., in an IPv6
header with a RH but not SRH, the DOH is required to carry the
options to be processed by the first destination that appears in the
IPv6 DA field plus subsequent destinations listed in the RH.
When SRv6 is supported, there are two places in the IPv6 header to
carry the options that can be processed on each SRv6 nodes. DOH is
designed for more general IPv6 usages, while SRH TLV is appended to
SRH and designed for SRv6 usage only.
Peng, et al. Expires 14 September 2023 [Page 3]
Internet-Draft IPv6 Options Deployment March 2023
3.2. Implementation
SRH TLV and DOH are generally two functional modules in the
forwarding plane. Some devices may support the processing of SRH TLV
but not DOH at the same time and vice versa.
SRH and SRH TLV are integrated modules, while DOH is a more
independent general IPv6 functional module.
3.3. Cost
Supporting two modules (DOH and SRH TLV) at the same time consume
more cost, so most of time only one module is supported for the same
functional requirement.
When both modules are supported, since SRH TLV is appended to SRH and
separated from other IPv6 options, the confliction with others is
minimal.
3.4. Deployment guidance
The capabilities of devices in network should be evaluated before
supporting any new services. Capability advertisement mechanisms can
be utilized.
The holding place choice is up to network operators, depending on the
service requirements and network device capabilities, etc.
When SRH TLV and DoH and other extension headers coexist, SRH TLV is
recommended to carry SRv6 related information.
Duplication of the same option in different places should be avoided.
4. Generic Option vs. Specific Option
As more and more new services using IPv6 options being proposed,
there is a concern that the allocation space for option types may
quickly exhaust. Therefore, solution such as generic identifier
option [I-D.iurman-6man-carry-identifier] has been proposed.
However, each of the newly proposed options is designed for a
specific service. As specified in [RFC8200], "there has to be a very
clear justification why any new hop-by-hop option is needed before it
is standardized.". These services have already justified their needs
before they are proposed and standardized.
Peng, et al. Expires 14 September 2023 [Page 4]
Internet-Draft IPv6 Options Deployment March 2023
4.1. Implementation
As specified in [I-D.ietf-6man-hbh-processing], the new hop-by-hop
options should be straight forward to process. That is, new Hop-by-
Hop options SHOULD be designed to ensure the node can process the
options at the full forwarding rate (e.g., on the router's Fast
Path).
Such generic option raises the implementation and processing
requirements, while specific option is designed for specific service
usage which eases implementations and is straight forward to process.
4.2. Extending the allocation space of Option Type
As specified in [RFC8200], the option type is a 8-bit identifier of
the type of option. The highest-order 2 bits specify the action that
must be taken if the processing IPv6 node does not recognize the
Option Type, and the third-highest-order bit of the Option Type
specifies whether or not the Option Data of that option can change en
route to the packet's final destination. The three high-order bits
described above are to be treated as part of the Option Type, not
independent of the Option Type. So the allocation space left for new
options are actually left to 5 bits. The concern for quickly
exhaustion makes sense.
The root cause for quick exhaustion is the allocation space of the
option type itself is limited. As more and more new services being
proposed and standardized, a way of holding more options need to be
figured out.
4.2.1. Backwards compatibility
The allocation space extension design should consider the backwards
compatibility, that is, it should not affect the processing of the
existing option types on devices.
5. Security Considerations
The security considerations can refer to [RFC8200], and [RFC8754].
6. IANA Considerations
This document does not include an IANA request.
7. Acknowledgements
The authors would like to acknowledge Stefano Previdi for his
valuable review and comments.
Peng, et al. Expires 14 September 2023 [Page 5]
Internet-Draft IPv6 Options Deployment March 2023
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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/info/rfc8200>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
8.2. Informative References
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-02, 28 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-02>.
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
"Carrying Virtual Transport Network (VTN) Information in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-ietf-6man-enhanced-vpn-vtn-id-02, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
enhanced-vpn-vtn-id-02>.
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
Peng, et al. Expires 14 September 2023 [Page 6]
Internet-Draft IPv6 Options Deployment March 2023
draft-ietf-6man-hbh-processing-05, 23 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-05>.
[I-D.ietf-ippm-ioam-ipv6-options]
Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
ipv6-options-10, 28 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-ipv6-options-10>.
[I-D.iurman-6man-carry-identifier]
Iurman, J., "Carrying an Identifier in IPv6 packets", Work
in Progress, Internet-Draft, draft-iurman-6man-carry-
identifier-00, 8 February 2023,
<https://datatracker.ietf.org/doc/html/draft-iurman-6man-
carry-identifier-00>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
Authors' Addresses
Shuping Peng
Huawei Technologies
China
Email: pengshuping@huawei.com
Giuseppe Fioccola
Huawei Technologies
Germany
Email: giuseppe.fioccola@huawei.com
Jie Dong
Huawei Technologies
China
Email: jie.dong@huawei.com
Peng, et al. Expires 14 September 2023 [Page 7]
