| Internet-Draft | draft-mcbride-v6ops-eh-use-cases-01 | February 2024 |
| McBride, et al. | Expires 29 August 2024 | [Page] |
This document outlines IPv6 extension header use cases including those intended to be deployed in limited domains and those intended for the global Internet. We specify use cases are deployed today and those which may be of use in the future. The hope is that through understanding these various extension header use cases, we can then better understand how best to improve upon extension header deployments including any limits on their use.¶
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 29 August 2024.¶
Copyright (c) 2024 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 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.¶
Extension headers have been specified since original 1995 IPv6 Specification [RFC2460] and maintained in the more recently updated [RFC8200]. In the nearly 30 years since extension headers were specified, there have been many documents which have specified how to limit, block and deprecate their use. What we haven't had is a document to show how extension headers are being deployed nor how related innovations are being proposed. This document outlines IPv6 extension header use cases including those intended to be deployed in limited domains and those deployed across the Internet. By understanding these various use cases we can better understand how best to improve upon, and perhaps limit, extension header deployment.¶
EH: IPv6 Extension Header¶
Hop-by-Hop Optioners Header: Used to carry optional information intended for every node along the path.¶
Routing Header: Used to list one or more nodes to be visited on the way to a packet's destination.¶
Fragment Header: Used to send a packet larger than would fit in the path MTU to its destination.¶
Encapsulating Security Payload: The Encapsulating Security Payload (ESP) extension header provides confidentiality, integrity, and authentication for IPv6 packets.¶
Authentication Header: The IPv6 Authentication Header (AH) extension provides data integrity, authentication, and anti-replay protection for IPv6 packets.¶
Destination Options Header: Used to carry optional information for destination nodes.¶
Mobility Header: The Mobility Header enables mobility support for network nodes in IPv6 networks.¶
Host Identity Protocol: The Host Identity Protocol (HIP) provides a cryptographic identity-based solution for secure communication and mobility management in IPv6 networks.¶
Shim6 Protocol: The Shim6 IPv6 extension header enables multihoming by providing source and destination address selection for efficient routing.¶
Single Administrative Domain: The EH is limited to one administrative domain.¶
Limited Domain: The EH is limited to a group of administrative domains.¶
Unlimited Domain: The EH is not limited to any group of domains.¶
Segment Routing (SR) can be applied to the IPv6 data plane using a routing header called the Segment Routing Header (SRH). [RFC8402] Defines SRv6 with SRH and SRv6 SID's. [RFC8754] specifies the encoding of IPv6 segments in an SRH. SRv6 uses this IPv6 Routing Extension Header to forward IPv6 packets using the source routing model. The SRH isn't examined by intermediate nodes along the path to the destination unless it implements the hop-by-hop options header. According to [I-D.matsushima-spring-srv6-deployment-status], there have been over 10 announced deployments of an SRH based data plane and over 20 additional deployments without public announcements. There are many large scale SRv6 commerical deployments, many SRv6 implementations and many SRv6 open source platforms. Segment Routing is intended to be used in a limited domain¶
RFC 8250 specifies the Performance and Diagnostic Metrics (PDM) Destination Options header, which is used to measure the performance of IPv6 networks. The PDM header contains sequence numbers and timing information that can be used to calculate metrics such as round-trip delay and server delay.¶
The PDM header is embedded in each packet, and the information it contains is combined with the 5-tuple (source IP address, source port, destination IP address, destination port, and upper-layer protocol) to calculate the metrics. The PDM header also includes fields for storing time scaling factors, which can be used to adjust the measurements for different network conditions.¶
The PDM header can be used to assess performance problems in real time or after the fact. The measurements can be used to troubleshoot network problems, identify bottlenecks, and optimize network performance.¶
[RFC6275] specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet.The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of mobile bindings. The Mobility Header is identified by a Next Header value of 135.¶
[RFC9343] describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header.¶
Multicast Listener Discovery (MLD) is used today by IPv6 routers for discovering multicast listeners on a directly attached link, much like Internet Group Management Protocol (IGMP) is used in IPv4. MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. MLD messages are identified in IPv6 packets by a preceding Next Header value of 58. MLD messages are sent with an IPv6 Router Alert option in a Hop-by-Hop Options header as defined in [RFC2710].¶
Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. As network technologies evolve including deployments of IPv6, SRv6, Segment Routing over MPLS dataplane, the programmability provided by IPv6 and Segment Routing can be augmented by conveying application related information into the network satisfying the fine-granularity requirements. APN documents outline various use cases that could benefit from an Application-aware Networking (APN) framework¶
There's a potential deployment of using a bitstring (such as used in BIER) as part of the IPv6 data plane using an EH.¶
|<<-----(BIER-based multicast overlay)----->>|
| |
|<----------(L3 BIER(P2MP) tunnel)---------->|
| |
| SEP SEP SEP SEP |
| +******************+ +****+ |
| / \ / \ |
+------+ +-------+ +-----+ +------+
| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
+------+ +-------+ +-----+ +------+
------- L2 link
******* IPv6(P2P) segment (SEP = Segment EndPoint)
<-----> BIER(P2MP) tunnel
¶
In this deployment, BIER works as part of the IPv6 data plane. The BFIR and BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6 segment endpoints. The BIER header is processed on each segment endpoint and there is no decapsulation, or re-encapsulation, on the segment endpoints.¶
This deployment typically needs an IPv6 extension header to carry the BIER header and processing of the BIER header (e.g., the bitstring) will be implemented as part of the IPv6 extension header processing. The IPv6 source address is the BIER packet source-origin identifier, and is unchanged through the BIER domain from BFIR to BFERs.¶
None.¶
None.¶
None.¶
Thanks to Dr. Tommaso Pecorella and Dhruv Dhody for their comments.¶
Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC¶
Note to RFC Editor: please remove this appendix before publication as an RFC¶