﻿<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-mcbride-v6ops-eh-use-cases-01" ipr="trust200902">

  <front>
    <title abbrev="draft-mcbride-v6ops-eh-use-cases-01">Extension Header Use Cases</title>
    <seriesInfo name="Internet-Draft" value="draft-mcbride-v6ops-eh-use-cases-01"/>
    <author fullname="Mike McBride">
      <organization>Futurewei</organization>
      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>
    <author fullname="Nalini Elkins">
      <organization>Inside Products, Inc</organization>
      <address>
        <email>nalini.elkins@insidethestack.com</email>
      </address>
    </author>
    <author fullname="Nick Buraglio">
      <organization>Forwarding Plane</organization>
      <address>
        <email>buraglio@forwardingplane.net</email>
      </address>
    </author>
    <author fullname="Xuesong Geng">
      <organization>Huawei Technologies</organization>
      <address>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>
    <author fullname="Michael Ackermann">
      <organization>BCBS Michigan</organization>
      <address>
        <email>mackermann@bcbsm.com</email>
      </address>
    </author>
    <date year="2024" month="February" day="26"/>
    <area>Ops</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>Extension Headers</keyword>
    <keyword>IPv6</keyword>
    <abstract>
      <?line 84?>

<t>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.</t>
    </abstract>

  </front>

  <middle>
<section anchor="introduction">
      <name>Introduction</name>
      <t>Extension headers have been specified since original 1995 IPv6
Specification <xref target="RFC2460"/> and maintained in the more recently updated
<xref target="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.</t>
    </section>
    <section anchor="glossary">
      <name>Glossary</name>
      <t>EH: IPv6 Extension Header</t>
      <t>Hop-by-Hop Optioners Header: Used to carry optional information
intended for every node along the path.</t>
      <t>Routing Header: Used to list one or more nodes to be visited on the
way to a packet's destination.</t>
      <t>Fragment Header: Used to send a packet larger than would fit in the
path MTU to its destination.</t>
      <t>Encapsulating Security Payload: The Encapsulating Security Payload
(ESP) extension header provides confidentiality, integrity, and
authentication for IPv6 packets.</t>
      <t>Authentication Header: The IPv6 Authentication Header (AH) extension
provides data integrity, authentication, and anti-replay protection
for IPv6 packets.</t>
      <t>Destination Options Header: Used to carry optional information for
destination nodes.</t>
      <t>Mobility Header: The Mobility Header enables mobility support for
network nodes in IPv6 networks.</t>
      <t>Host Identity Protocol: The Host Identity Protocol (HIP) provides
a cryptographic identity-based solution for secure communication and
mobility management in IPv6 networks.</t>
      <t>Shim6 Protocol: The Shim6 IPv6 extension header enables multihoming
by providing source and destination address selection for efficient 
routing.</t>
      <t>Single Administrative Domain: The EH is limited to one administrative
domain.</t>
      <t>Limited Domain: The EH is limited to a group of administrative
domains.</t>
      <t>Unlimited Domain: The EH is not limited to any group of domains.</t>
    </section>
 
       <section anchor="existing-network-management-extension-headers">
        <name>Standards Based Extension Headers</name>
      
      <section anchor="Segment Routing Header (SRH)">
      <name>Segment Routing Header (SRH)</name>
      <t>Segment Routing (SR) can be applied to the IPv6 data plane using a routing header called the Segment Routing Header (SRH).
      <xref target="RFC8402"/> Defines SRv6 with SRH and SRv6 SID's.
      <xref target="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 <xref target="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</t>
      </section>
      

        <section anchor="rfc8250-performance-and-diagnostic-metrics-pdm">
          <name>Performance and Diagnostic Metrics (PDM)</name>
          <t>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.</t>
          <t>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.</t>
          <t>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.</t>
        </section>
      
      <section anchor="Mobility Header">
      <name>Mobility Header</name>
      <t><xref target="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. </t>
      </section>
      
      <section anchor="Alternate-Marking Method">
      <name>Alternate-Marking Method</name>
      <t><xref target="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. </t>
      </section>     
      
              <section anchor="mld-messages">
          <name>MLD Messages</name>
          <t>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 <xref target="RFC2710"/>.</t>
        </section>
        
              </section>
      
                  <section anchor="potential-routing-extension-headers">
        <name>Proposed Extension Headers</name>
        
     <section anchor="APN6">
      <name>Application Aware Networking</name>
          <t>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</t>
       </section> 
      
      <section anchor="bier-integrated-multicast-bitstring">
      <name>Integrated Multicast Bitstring</name>
          <t>There's a potential deployment of using a bitstring (such as used in
BIER) as part of the IPv6 data plane using an EH.</t>
          <artwork><![CDATA[
         |<<-----(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

]]></artwork>
          <t>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.</t>
          <t>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.</t>
        </section>
                      </section>
  
 
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>None.</t>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>None.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>None.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>Thanks to Dr. Tommaso Pecorella and Dhruv Dhody for their comments.</t>
    </section>
    <section anchor="change-log">
      <name>Change Log</name>
      <t>Note to RFC Editor: if this document does not obsolete an existing
RFC, please remove this appendix before publication as an RFC</t>
    </section>
    <section anchor="open-issues">
      <name>Open Issues</name>
      <t>Note to RFC Editor: please remove this appendix before publication as
an RFC</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">

      <?rfc include='reference.RFC.4302'?>
      <?rfc include='reference.RFC.4303'?>
      <?rfc include='reference.RFC.4727'?>
      <?rfc include='reference.RFC.4782'?>
      <?rfc include='reference.RFC.5095'?>
      <?rfc include='reference.RFC.5533'?>
      <?rfc include='reference.RFC.5570'?>
      <?rfc include='reference.RFC.6554'?>
      <?rfc include='reference.RFC.6744'?>
      <?rfc include='reference.RFC.6788'?>
      <?rfc include='reference.RFC.6971'?>
      <?rfc include='reference.RFC.3692'?>
      <?rfc include='reference.RFC.2780'?>
      <?rfc include='reference.RFC.2710'?>      
      <?rfc include='reference.RFC.2711'?>    
      <?rfc include='reference.RFC.2675'?> 
      <?rfc include='reference.RFC.2473'?>
      <?rfc include='reference.RFC.2460'?>
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.4271'?>
      <?rfc include='reference.RFC.4607'?>
      <?rfc include='reference.RFC.2858'?>
      <?rfc include='reference.RFC.8279'?>
      <?rfc include='reference.RFC.2236'?>
      <?rfc include='reference.RFC.3810'?>
      <?rfc include='reference.RFC.7401'?>
      <?rfc include='reference.RFC.8200'?>
      <?rfc include='reference.RFC.8250'?>
      <?rfc include='reference.RFC.9008'?>
      <?rfc include='reference.RFC.9268'?>
      <?rfc include='reference.RFC.9343'?>
      <?rfc include='reference.RFC.8754'?>
      <?rfc include='reference.RFC.9180'?>
      <?rfc include='reference.RFC.1421'?>
      <?rfc include='reference.RFC.6275'?>
      <?rfc include='reference.RFC.8402'?>     
      <?rfc include='reference.I-D.matsushima-spring-srv6-deployment-status'?>
    </references>
      </back>
  </rfc>