



Network Working Group                                           A. Menon
Internet-Draft                                                 Maia Edge
Intended status: Informational                                P. MeLampy
Expires: 9 November 2026                                         Retired
                                                                  M. Baj
                                              Hewlett Packard Enterprise
                                                              P. Timmons
                                                               Maia Edge
                                                               H. Kaplan
                                              Hewlett Packard Enterprise
                                                              8 May 2026


        Hewlett Packard Enterprise's Secure Vector Routing (SVR)
                           draft-menon-svr-08

Abstract

   This document describes Hewlett Packard Enterprise's Secure Vector
   Routing (SVR), an overlay inter-networking protocol that operates at
   the session layer.  SVR conveys end-to-end network requirements that
   cannot be expressed in network-layer headers by carrying application-
   layer cookies in the first packet of a session, eliminating the need
   for tunnel encapsulation and for non-overlapping underlay address
   spaces.  SVR traverses middleboxes and address translators between
   private networks, the IPv4 public Internet, and the IPv6 public
   Internet, and supports SD-WAN, multi-cloud, multicast, and dual-stack
   use cases while improving security at the routing plane.

Note

   This draft provides information for the Internet community.  It does
   not specify an Internet standard that has IETF consensus, nor is this
   part of a standards track of the IETF.  This document is being
   published for the purposes of interoperability.  The authors request
   suggestions for improvement.

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





Menon, et al.            Expires 9 November 2026                [Page 1]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   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 9 November 2026.

Copyright Notice

   Copyright (c) 2026 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     1.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.3.  Document Organization . . . . . . . . . . . . . . . . . .   7
     1.4.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   7
   2.  Configuration and Management  . . . . . . . . . . . . . . . .   9
   3.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  Directionality  . . . . . . . . . . . . . . . . . . . . .  11
     3.2.  Order of Operations . . . . . . . . . . . . . . . . . . .  12
     3.3.  SVR with Other Traffic  . . . . . . . . . . . . . . . . .  12
     3.4.  SVR Metadata Handshake  . . . . . . . . . . . . . . . . .  12
     3.5.  Pathway Obstructions and Changes  . . . . . . . . . . . .  13
     3.6.  SVR Metadata Removal  . . . . . . . . . . . . . . . . . .  13
     3.7.  Transport Address Modification  . . . . . . . . . . . . .  13
     3.8.  Optional Tenant- and Service-Name Routing . . . . . . . .  14
     3.9.  Unique 5-Tuples per Session . . . . . . . . . . . . . . .  14
     3.10. Post-Handshake Packet Handling  . . . . . . . . . . . . .  15
     3.11. Session State Requirements  . . . . . . . . . . . . . . .  15
     3.12. NATs and Session Keep-Alive . . . . . . . . . . . . . . .  16
     3.13. Use of BFD on Peer Pathways . . . . . . . . . . . . . . .  16
   4.  SVR Multi-path Routing Example  . . . . . . . . . . . . . . .  16
     4.1.  Establishing SVR Peering  . . . . . . . . . . . . . . . .  17
       4.1.1.  Reachability and Peer Authentication  . . . . . . . .  17
       4.1.2.  Peer Cryptographic Key and Re-keying  . . . . . . . .  18
       4.1.3.  Metadata Cryptographic Key and Re-keying  . . . . . .  19
       4.1.4.  Bringing a Peer Into Service  . . . . . . . . . . . .  19
       4.1.5.  Resulting Peer Relationship . . . . . . . . . . . . .  19
     4.2.  CIDR-based SVR Peer FIB Entries . . . . . . . . . . . . .  20



Menon, et al.            Expires 9 November 2026                [Page 2]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


     4.3.  Optional Service-Name FIB . . . . . . . . . . . . . . . .  21
     4.4.  SVR Security Definitions  . . . . . . . . . . . . . . . .  22
     4.5.  Time-Based HMAC Details . . . . . . . . . . . . . . . . .  23
     4.6.  Payload Encryption  . . . . . . . . . . . . . . . . . . .  23
     4.7.  New Session Initiation in Detail  . . . . . . . . . . . .  23
       4.7.1.  East: First-Packet Processing . . . . . . . . . . . .  24
         4.7.1.1.  Determine Tenant  . . . . . . . . . . . . . . . .  25
         4.7.1.2.  Determine Service . . . . . . . . . . . . . . . .  25
         4.7.1.3.  Determine Network Requirements  . . . . . . . . .  25
         4.7.1.4.  Picking a Peer Pathway  . . . . . . . . . . . . .  26
         4.7.1.5.  Allocate Source NAT (if Required) . . . . . . . .  26
         4.7.1.6.  Allocate SVR Ports  . . . . . . . . . . . . . . .  26
         4.7.1.7.  Build Session State and SVR Metadata  . . . . . .  26
         4.7.1.8.  Encrypt SVR Metadata  . . . . . . . . . . . . . .  29
         4.7.1.9.  Insert SVR Metadata . . . . . . . . . . . . . . .  29
         4.7.1.10. Sign SVR Packet . . . . . . . . . . . . . . . . .  30
         4.7.1.11. Send the First Packet . . . . . . . . . . . . . .  31
       4.7.2.  West: First-Packet Processing . . . . . . . . . . . .  31
         4.7.2.1.  Verify Source Address is a Waypoint . . . . . . .  31
         4.7.2.2.  Verify SVR Metadata Block . . . . . . . . . . . .  32
         4.7.2.3.  Decrypt, Parse, and Save State  . . . . . . . . .  32
         4.7.2.4.  Restore Addresses and Route . . . . . . . . . . .  32
         4.7.2.5.  Loop Detection  . . . . . . . . . . . . . . . . .  33
       4.7.3.  Pre-established Return-Path State . . . . . . . . . .  33
       4.7.4.  Sending Reverse SVR Metadata  . . . . . . . . . . . .  33
       4.7.5.  Subsequent Packet Processing  . . . . . . . . . . . .  35
       4.7.6.  Session Termination . . . . . . . . . . . . . . . . .  35
       4.7.7.  Unidirectional and Asymmetric Flows . . . . . . . . .  35
       4.7.8.  Multi-Hop Session Ladder Diagram  . . . . . . . . . .  35
   5.  SVR Protocol Definition . . . . . . . . . . . . . . . . . . .  37
     5.1.  Sessions and Types  . . . . . . . . . . . . . . . . . . .  37
     5.2.  SVR Metadata Insertion  . . . . . . . . . . . . . . . . .  37
       5.2.1.  Metadata Location in the Packet . . . . . . . . . . .  38
       5.2.2.  Prerequisites for Insertion . . . . . . . . . . . . .  38
       5.2.3.  Session Port Allocation . . . . . . . . . . . . . . .  38
       5.2.4.  Metadata on Idle Sessions . . . . . . . . . . . . . .  38
       5.2.5.  Packet Structure  . . . . . . . . . . . . . . . . . .  38
       5.2.6.  Prevention of False Positives . . . . . . . . . . . .  39
       5.2.7.  TCP-to-UDP Transformation . . . . . . . . . . . . . .  40
     5.3.  Required and Optional TLVs  . . . . . . . . . . . . . . .  41
       5.3.1.  IP Session TLVs . . . . . . . . . . . . . . . . . . .  41
       5.3.2.  ICMP TLVs . . . . . . . . . . . . . . . . . . . . . .  42
     5.4.  SVR Metadata Encryption . . . . . . . . . . . . . . . . .  42
     5.5.  Packet Authentication . . . . . . . . . . . . . . . . . .  43
       5.5.1.  HMAC Signatures . . . . . . . . . . . . . . . . . . .  43
       5.5.2.  HMAC Verification . . . . . . . . . . . . . . . . . .  44
     5.6.  Processing Packets That May Carry SVR Metadata  . . . . .  45
       5.6.1.  Detection of SVR Metadata . . . . . . . . . . . . . .  45



Menon, et al.            Expires 9 November 2026                [Page 3]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


       5.6.2.  Verification of SVR Metadata  . . . . . . . . . . . .  46
         5.6.2.1.  TLV Parsing . . . . . . . . . . . . . . . . . . .  46
         5.6.2.2.  Decryption of SVR Metadata Blocks . . . . . . . .  46
       5.6.3.  UDP-to-TCP Restoration  . . . . . . . . . . . . . . .  47
       5.6.4.  SVR Session Packets . . . . . . . . . . . . . . . . .  47
       5.6.5.  Tenant and Service Overview . . . . . . . . . . . . .  47
         5.6.5.1.  Service Interpretation  . . . . . . . . . . . . .  48
         5.6.5.2.  Tenant Determination and Interpretation . . . . .  49
       5.6.6.  Payload Encryption  . . . . . . . . . . . . . . . . .  49
   6.  BFD for Peer Pathways . . . . . . . . . . . . . . . . . . . .  51
     6.1.  SVR Peering and BFD . . . . . . . . . . . . . . . . . . .  51
       6.1.1.  Discovering the Peer's Received IP Address  . . . . .  53
       6.1.2.  NAT Detection . . . . . . . . . . . . . . . . . . . .  54
       6.1.3.  Detecting Router Address Changes  . . . . . . . . . .  55
       6.1.4.  MTU Discovery . . . . . . . . . . . . . . . . . . . .  56
       6.1.5.  Path-Quality Measurement  . . . . . . . . . . . . . .  57
       6.1.6.  Failover Detection  . . . . . . . . . . . . . . . . .  58
       6.1.7.  Peer Authentication . . . . . . . . . . . . . . . . .  58
       6.1.8.  Peer Key and Rekey  . . . . . . . . . . . . . . . . .  61
       6.1.9.  SVR Metadata Key and Rekey  . . . . . . . . . . . . .  64
       6.1.10. Certificate Revocation and Replacement  . . . . . . .  66
   7.  Additional SVR Metadata Use Cases . . . . . . . . . . . . . .  66
     7.1.  Moving a Session  . . . . . . . . . . . . . . . . . . . .  66
     7.2.  Moving Idle or Unidirectional Sessions  . . . . . . . . .  68
     7.3.  NAT Keep-Alive  . . . . . . . . . . . . . . . . . . . . .  70
     7.4.  Adaptive Encryption . . . . . . . . . . . . . . . . . . .  72
     7.5.  IPv4 Packet Fragmentation . . . . . . . . . . . . . . . .  73
     7.6.  IPv6 Packet Fragmentation . . . . . . . . . . . . . . . .  76
     7.7.  ICMP and SVR  . . . . . . . . . . . . . . . . . . . . . .  76
     7.8.  State Recovery  . . . . . . . . . . . . . . . . . . . . .  78
   8.  SVR Multicast Support . . . . . . . . . . . . . . . . . . . .  85
     8.1.  Architectural Model . . . . . . . . . . . . . . . . . . .  85
     8.2.  Multicast Terminology . . . . . . . . . . . . . . . . . .  85
     8.3.  Group Membership Distribution . . . . . . . . . . . . . .  86
     8.4.  First-Packet Processing for Multicast . . . . . . . . . .  86
     8.5.  Egress (LHR) Processing . . . . . . . . . . . . . . . . .  87
     8.6.  Keep-Alive and Session Lifetime . . . . . . . . . . . . .  87
     8.7.  Multicast Security Considerations . . . . . . . . . . . .  88
   9.  IPv6 Considerations . . . . . . . . . . . . . . . . . . . . .  88
     9.1.  Addressing and Waypoints  . . . . . . . . . . . . . . . .  88
     9.2.  IPv4 / IPv6 Interworking  . . . . . . . . . . . . . . . .  89
     9.3.  IPv6 Extension Headers  . . . . . . . . . . . . . . . . .  89
     9.4.  Hop Limit, Traffic Class, and Flow Label  . . . . . . . .  90
     9.5.  ICMPv6 Interaction  . . . . . . . . . . . . . . . . . . .  90
     9.6.  BFD over IPv6 . . . . . . . . . . . . . . . . . . . . . .  91
   10. SVR Metadata Format . . . . . . . . . . . . . . . . . . . . .  91
     10.1.  SVR Metadata Header  . . . . . . . . . . . . . . . . . .  91
       10.1.1.  False Positives  . . . . . . . . . . . . . . . . . .  92



Menon, et al.            Expires 9 November 2026                [Page 4]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


       10.1.2.  Forward and Reverse Attributes . . . . . . . . . . .  93
     10.2.  TLVs for Attributes  . . . . . . . . . . . . . . . . . .  93
     10.3.  Header Attributes  . . . . . . . . . . . . . . . . . . .  94
       10.3.1.  Fragment . . . . . . . . . . . . . . . . . . . . . .  94
       10.3.2.  Security ID  . . . . . . . . . . . . . . . . . . . .  95
       10.3.3.  Disable Forward SVR Metadata . . . . . . . . . . . .  96
       10.3.4.  IPv4 ICMP Error Location Address . . . . . . . . . .  96
       10.3.5.  IPv6 ICMP Error Location Address . . . . . . . . . .  97
       10.3.6.  SVR Control Message  . . . . . . . . . . . . . . . .  97
       10.3.7.  Path Metrics . . . . . . . . . . . . . . . . . . . .  99
       10.3.8.  Session Health Check . . . . . . . . . . . . . . . . 101
     10.4.  Payload Attributes . . . . . . . . . . . . . . . . . . . 101
       10.4.1.  Forward Context IPv4 . . . . . . . . . . . . . . . . 101
       10.4.2.  Forward Context IPv6 . . . . . . . . . . . . . . . . 102
       10.4.3.  Reverse Context IPv4 . . . . . . . . . . . . . . . . 104
       10.4.4.  Reverse Context IPv6 . . . . . . . . . . . . . . . . 104
       10.4.5.  Session UUID . . . . . . . . . . . . . . . . . . . . 106
       10.4.6.  Tenant Name  . . . . . . . . . . . . . . . . . . . . 106
       10.4.7.  Service Name . . . . . . . . . . . . . . . . . . . . 107
       10.4.8.  Session Encrypted  . . . . . . . . . . . . . . . . . 107
       10.4.9.  TCP SYN Packet . . . . . . . . . . . . . . . . . . . 108
       10.4.10. Source Router Name . . . . . . . . . . . . . . . . . 109
       10.4.11. Security Policy  . . . . . . . . . . . . . . . . . . 109
       10.4.12. Peer Pathway ID  . . . . . . . . . . . . . . . . . . 110
       10.4.13. IPv4 Source NAT Address  . . . . . . . . . . . . . . 111
       10.4.14. Remaining Session Time . . . . . . . . . . . . . . . 111
       10.4.15. Security Encryption Key  . . . . . . . . . . . . . . 112
       10.4.16. Multicast Group Context  . . . . . . . . . . . . . . 112
       10.4.17. Multicast Egress List  . . . . . . . . . . . . . . . 113
   11. Implementation Status . . . . . . . . . . . . . . . . . . . . 113
     11.1.  Session Smart Router . . . . . . . . . . . . . . . . . . 114
   12. Security Considerations . . . . . . . . . . . . . . . . . . . 114
     12.1.  HMAC Authentication  . . . . . . . . . . . . . . . . . . 114
     12.2.  Replay Prevention  . . . . . . . . . . . . . . . . . . . 114
     12.3.  Payload Encryption . . . . . . . . . . . . . . . . . . . 114
     12.4.  DDoS and Unexpected Traffic on Waypoint Addresses  . . . 115
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 115
   15. Normative References  . . . . . . . . . . . . . . . . . . . . 116
   16. Informative References  . . . . . . . . . . . . . . . . . . . 118
   Appendix A.  Changes from -07 to -08  . . . . . . . . . . . . . . 120
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 120









Menon, et al.            Expires 9 November 2026                [Page 5]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


1.  Introduction

   IP routers need a way to communicate end-to-end network requirements
   and to select paths whose attributes meet those requirements.
   Applications increasingly need the same capability as workloads move
   to multiple public clouds.  Standard practice today is to overlay a
   mesh of tunnels on top of the IP underlay; this addresses address-
   space and policy issues but at the cost of additional encapsulation,
   larger packets, fragmentation, and reduced bandwidth.

   Secure Vector Routing (SVR) is proposed as an alternative to tunnels.
   SVR retains a single network layer, transports traffic securely with
   authentication and adaptive encryption, and expresses network
   requirements abstractly so that policy can be interworked between
   different networks and address spaces.

1.1.  Terminology

   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.

1.2.  Overview

   An SVR router expresses a network requirement semantically and shares
   it with a peer as SVR Metadata, carried as an application-layer
   cookie in the first packet of a session.  Every participating router
   holds session state and installs matching forward and reverse flows.
   Once the session is bidirectionally established, the cookie is
   omitted from subsequent packets, eliminating per-packet overhead.

   Benefits of this approach include:

   *  *Tunnel compression*: SVR Metadata removes the need for an outer
      tunnel header on established sessions, yielding 12% to 100%
      bandwidth savings versus IPsec depending on packet size.

   *  *No tunnel "elephant flows"*: Tunnels are long-lived aggregates
      pinned to a single ECMP hash.  Each SVR session has a unique
      5-tuple and is hashed independently by the underlay.

   *  *Per-flow QoS*: Because each SVR session has a unique on-the-wire
      5-tuple, standard MPLS routing and DSCP-based QoS work without the
      entry-marking and copy-policy gymnastics required for tunnels.





Menon, et al.            Expires 9 November 2026                [Page 6]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   *  *No re-encryption*: SVR's adaptive encryption encrypts only
      sessions that require it, avoiding the encrypt-already-encrypted
      penalty common to IPsec tunnels.

   *  *Inspection-friendly*: Firewalls and security proxies that are
      passive to SVR Metadata can still intercept TLS for decryption/
      inspection.  This is not possible with IPsec by design.

   *  *Encryption scaling*: Per-session keying allows encryption to
      scale across cores.  Tunnel termination is bounded by a single
      core per tunnel (at this writing, ~1.5 Gb/s).

1.3.  Document Organization

   Section 3 describes how SVR works at a high level.  Section 4 walks
   through a worked example.  Section 4.7 details first-packet
   processing.  Section 6 covers Peer Pathway management with BFD.
   Section 7 describes additional procedures.  Section 8 and Section 9
   cover multicast and IPv6.  Section 10 defines the on-the-wire SVR
   Metadata format and TLV catalog.

1.4.  Definitions

   The following terms are used throughout this document.

   Authority:  A textual identifier for the owner of an SVR namespace.
      The Authority allocates Tenant and Service names within its
      namespace and acts as a logical administrative-domain boundary.
      Authority namespaces SHOULD be globally unique when interworking
      is desired.  Naming-dispute resolution is out of scope.

   Tenant:  A textual identifier for a set of network endpoints that
      share a common access policy.  Endpoints MAY be mapped to a Tenant
      by source IP/mask, VLAN tag, ingress interface, authentication
      system, or client assertion; the mapping mechanism is out of
      scope.  Tenant names are scoped to an Authority and MAY use
      hierarchical domain-style syntax (e.g.,
      location.department.example).

   Session:  The complete bidirectional sequence of packets representing
      a single TCP or UDP communication.  The initiator is the client;
      the responder is the server.

   Service:  A textual identifier for the destination(s) reachable via
      SVR (e.g., "Zoom", "Office365/Outlook").  The mapping from Service
      name to concrete endpoints (URLs, IP/protocol/port tuples, CIDR
      blocks, etc.) is out of scope.  Quality and Security policy MAY be
      associated with a Service in data models not described here.



Menon, et al.            Expires 9 November 2026                [Page 7]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Context:  The original 5-tuple of an IP packet (source IP, source
      port, destination IP, destination port, protocol).  Layer-2
      information (MAC, VLAN) MAY also be included for certain use
      cases.

   Signature:  An HMAC computed by the source router.  SVR Metadata
      packets SHOULD be HMAC-signed, and all packets traversing an SVR
      Peer Pathway SHOULD carry an HMAC signature so the next-hop router
      can authenticate the sender and verify integrity.  The signed
      range MUST NOT include the IP header, since the packet may
      traverse a NAT or an IPv4/IPv6 translator.

   Direction:  Inferred per session, not carried as a TLV.  "Forward" is
      client-to-server (the side that sent the first packet); "reverse"
      is server-to-client.  Direction is independent of network
      topology; traffic between two nodes may be "forward" for some
      sessions and "reverse" for others.

   Peer:  A client, server, or router that supports SVR.  A Peer MAY be
      directly adjacent or reachable across an IP network.  "Peer" in
      this document always means SVR Peer; it is unrelated to BGP
      peering (though SVR Peers are commonly co-located with BGP peers
      at network edges).

   Waypoint:  A reachable IP address on an SVR router's interface.  A
      single interface MAY expose multiple Waypoints, and a Waypoint MAY
      change dynamically when an interface uses DHCP or PPPoE.

   Peer Received IP Address:  The destination IP address used to reach a
      Waypoint.  Equal to the Waypoint Address unless a NAT lies between
      the Peers.

   SVR Metadata:  A block of TLVs (defined in Section 10) that carries
      SVR attributes between SVR routers.

   BFD Metadata:  Data appended to BFD messages to support SVR Peer
      relationships beyond what standard BFD provides.  See Section 6.

   Peer Pathway:  A unique pair of mutually reachable Waypoint addresses
      (or domain names that resolve to such addresses).  Peer Pathways
      have availability, performance (jitter, latency, loss), and cost
      attributes.  BFD [RFC5880] is the RECOMMENDED method for
      monitoring Peer Pathway state.

   Router Certificate:  An X.509 certificate issued from a Certificate






Menon, et al.            Expires 9 November 2026                [Page 8]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      Signing Request that contains the router's UUID, Authority, and
      public key.  Used to authenticate routers on Peer Pathways.  The
      certificate is long-lived and rarely used directly; subsequent
      keying uses derived keys.

   Peer Key:  A shared key established between two authenticated Peers,
      used to encrypt selected BFD fields between them.  Rekeyed as
      often as required by deriving a new shared key.  See
      Section 6.1.8.

   SVR Metadata Key:  A per-router key used to encrypt and decrypt SVR
      Metadata.  The router distributes its current Metadata Key to all
      of its Peers in an encrypted BFD Metadata field.  See
      Section 6.1.9.

   Payload Key:  A per-session key for payload encryption, generated by
      the originating router and conveyed inside SVR Metadata.  Reusing
      the same key in both directions avoids glare.  Rekey is achieved
      by generating a new key and conveying it in mid-flow SVR Metadata.

   Session HMAC Key:  A per-session key used for Time-Based HMAC
      signatures, used to protect SVR pathways against replay.  Set to
      the Peer Key in effect at session creation, retained for the
      session's lifetime.  Time-Based HMAC effectively rotates the
      signing input every two seconds without changing this key.

2.  Configuration and Management

   Provisioning and orchestration are out of scope for this document.
   This section sketches the minimum set of attributes that any
   orchestration mechanism MUST be able to deliver to a router in order
   to bring up an SVR peering relationship; it is neither exhaustive nor
   normative as to data-model organization.


















Menon, et al.            Expires 9 November 2026                [Page 9]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


               Adjacency[]
                 port-range
                 peer[]
                 rekey-interval

               Tenant[]
                 name
                 source-ip[]

               SecurityPolicy[]
                 name
                 HMAC
                   mode
                   cipher
                 payload-encryption-cipher
                 adaptive-encryption
                 rekey-interval

               Service[]
                 name
                 domain[]
                 ip-address[]
                 port[]
                 protocol[]
                 permit
                   Tenant[]
                 deny
                   Tenant[]
                 ServiceLevelAgreement
                   max-jitter
                   max-loss
                   max-latency
                 SecurityPolicy



                                  Figure 1

3.  Theory of Operation

   SVR is a session-stateful routing protocol that runs at network
   edges, typically co-located with stateful NAT and multipath routing
   functions: branch routers, data-center edges, and public-cloud
   gateways.  SVR maps local network requirements into administratively
   defined text strings with Authority-wide meaning, and signals them by
   inserting an SVR Metadata cookie directly into in-flight IP packets.





Menon, et al.            Expires 9 November 2026               [Page 10]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


                          +-----------+
                          | Network 2 |
      +-----------+       |           |        +-----------+
      |          SVR<---->+<--L3-IP-->+<----->SVR          |
      |           |       +-----------+        |           |
      | Network 1 |       +-----------+        | Network 4 |
      |          SVR<--->SVR         SVR<---->SVR          |
      +-----------+       |           |        +-----------+
                          | Network 3 |
      +-----------+       |           |
      | Client   SVR<--->SVR          |
      +-----------+       +-----------+



                                  Figure 2

   Figure 2 shows typical SVR deployment topologies.  SVR may be
   deployed end-to-end (Network 1 to Network 4 across Network 3, the
   public Internet), in a chain (Network 1 to Network 3 to Network 4),
   or directly to SVR-capable clients attached to Network 3.

   SVR Metadata is inserted directly after the L4 header (see
   Section 5.2).  Metadata in the first packet of a session is used for
   path selection and security; subsequent packets MAY carry SVR
   Metadata to update networking requirements mid-session.  Metadata
   lives in the packet payload to guarantee delivery between SVR
   routers.

   SVR supports TCP, UDP (including UDP unicast), Multicast, MP-TCP,
   QUIC, point-to-point Ethernet, and ICMP.  A session is bracketed by
   an initial packet with a unique 5-tuple and ends either when the L4
   protocol indicates termination (TCP FIN/FIN-ACK or RST) or after a
   configured inactivity timeout.

3.1.  Directionality

   Every SVR session has a direction: "forward" is from the sender of
   the first packet (the client) toward the responder (the server);
   "reverse" is the opposite.  Direction is independent of network
   topology -- the same Peer Pathway carries forward sessions in both
   physical directions.  Routing policy is expressed as Tenant (source)
   / Service (destination) pairs that match the forward direction.

   SVR Metadata is similarly labeled "forward" (client-to-server) or
   "reverse" (server-to-client) throughout this document.





Menon, et al.            Expires 9 November 2026               [Page 11]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


3.2.  Order of Operations

   Processing of a packet at the first (ingress) SVR router proceeds as
   follows:

   1.  *Detect new flow*: a packet whose 5-tuple is not in the flow
       table is treated as the first packet of a new flow.

   2.  *Parse and route*: parse L2/L3 headers and perform longest-prefix
       match to determine the next hop.

   3.  *SVR-capable next hop?*: if the next hop is a known SVR Peer,
       continue with SVR processing; otherwise forward as a traditional
       IP router.

   4.  *Insert SVR Metadata* into the first packet of the new session.

   5.  *Rewrite transport addresses* to the chosen Peer Pathway's
       Waypoint pair (analogous to IPv6 Segment Routing); the original
       addresses are preserved in the Forward Context TLV.

   6.  *Forward* the SVR-encapsulated packet.

   Processing at a subsequent SVR router differs only at the start: a
   first-packet arrival on a router-interface address from a known SVR
   Peer is interpreted as carrying SVR Metadata.  The router decrypts
   and authenticates the metadata, and either restores the original
   addresses (if the next hop is non-SVR) or repeats steps 2-6 above
   with a new Peer Pathway selection.

3.3.  SVR with Other Traffic

   SVR coexists with traditional routing and non-SVR traffic.  Waypoint
   addresses MUST remain reachable via traditional networking for every
   Peer relationship.  When the next hop returned by FIB lookup matches
   a known Peer's Waypoint, the router MAY insert SVR Metadata and apply
   session-stateful SVR; otherwise it forwards as a traditional IP
   router.

3.4.  SVR Metadata Handshake

   For each session, peers perform a metadata handshake to confirm that
   SVR Metadata has been received and understood.  The initiating router
   inserts forward SVR Metadata into every packet it sends to the
   recipient until it receives a reverse packet that itself carries SVR
   Metadata.  The recipient inserts reverse SVR Metadata into every
   packet until it receives a packet from the initiator that no longer
   carries SVR Metadata.  Once both sides have observed metadata



Menon, et al.            Expires 9 November 2026               [Page 12]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   disappear from their counterpart's stream, the handshake is complete
   and subsequent packets travel without metadata overhead.

3.5.  Pathway Obstructions and Changes

   Middleboxes (firewalls, NATs, traffic-inspection devices) on a Peer
   Pathway may drop TCP SYNs that carry payload data, or invalidate TCP
   streams whose sequence numbers appear inconsistent due to inserted
   metadata (even though SVR does not change sequence numbers).  Peers
   MAY probe their pathways to detect these conditions; BFD with BFD
   Metadata is used to detect NATs (see Section 6.1.2).  Well-known NAT-
   traversal protocols -- STUN [RFC8489], TURN [RFC6062], ICE [RFC8445]
   -- are out of scope for this document.

   When a NAT is detected, the affected SVR router records the pathway's
   externally observed Waypoint address as a pathway attribute and uses
   NAT keep-alives (see Section 7.3) to preserve the binding.

   When a non-NAT middlebox is detected, the transmitting router MAY
   perform TCP-to-UDP transformation (changing the protocol octet from
   0x06 to 0x11), with the receiving router restoring the original
   protocol.  See Section 5.2.7 and Section 5.6.3.

   Dynamic Waypoint addresses (DHCP, PPPoE) MAY change mid-session.  For
   active sessions, the new address is detected by inspecting the source
   address on incoming packets and updating internal references.  For
   idle pathways, BFD with SVR Metadata detects the change; see
   Section 6.1.3.

3.6.  SVR Metadata Removal

   SVR Metadata MUST be removed before traffic is delivered to a non-SVR
   endpoint.  A router can be certain that a downstream SVR peer will
   perform that removal only when the FIB next-hop address exactly
   matches a known Peer Waypoint address; reachability of the Peer
   SHOULD be confirmed via BFD (Section 6) before metadata insertion
   (see also Section 4).  If the next hop is not a known reachable Peer,
   SVR Metadata insertion MUST NOT be performed.  SVR Metadata MAY be
   sent end-to-end when both client and server support SVR.

3.7.  Transport Address Modification

   To steer a packet to a specific peer, the destination address is
   rewritten to that Peer's chosen Waypoint and the source address is
   rewritten to the local egress Waypoint, ensuring symmetric return.
   The original 5-tuple is preserved in the Forward Context TLV
   (Section 10.4.1) and restored at egress.  This is conceptually
   similar to IPv6 Segment Routing ([RFC8986]) or to LISP RLOCs



Menon, et al.            Expires 9 November 2026               [Page 13]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   ([RFC9300]), except that the original addresses live in SVR Metadata
   in the packet payload, not in the IP header.

   Waypoint selection is implementation-specific.  A FIB lookup
   typically returns one or more Waypoints; when multiple are returned,
   the router MAY apply pathway quality, session-layer load balancing,
   or other local logic to choose.  See Section 4.

   Session state, including translation rules for all five tuple fields
   in both directions, MUST be held on both the source and destination
   SVR routers.  Once installed, this state replaces tunnel
   encapsulation/decapsulation -- a substantially cheaper operation than
   tunneling.

3.8.  Optional Tenant- and Service-Name Routing

   SVR Metadata carries textual Tenant and Service names alongside IP-
   level context.  A FIB extended with Service-name entries permits
   policy and route selection based on those names; the egress SVR
   router typically applies destination NAT to a concrete instance.
   This is particularly useful for inter-cloud connectivity (e.g., AWS
   <-> Azure).

   When clients support SVR, semantic routing can replace dynamic DNS
   for service location: the client requests the Service by name and the
   SVR network resolves and steers the session to the best instance.  A
   local DNS server resolving Service names to a nearby SVR router
   achieves the same effect for legacy clients.

3.9.  Unique 5-Tuples per Session

   The ingress SVR router (client side) allocates both source and
   destination ports for the on-wire 5-tuple.  Source ports MUST be
   even; destination ports MUST be odd.  This convention guarantees
   uniqueness between any two peers without negotiation, and even when a
   reverse-direction session is allocated the same port pair, the
   swapped IP addresses keep the on-wire 5-tuple unique.  Allocatable
   port ranges are provisioned per Peer Pathway; a port MUST be free
   before being reused.

   With no NAT between Peers, this scheme provides 2^32 unique sessions
   per pathway (2^30 per direction); a source NAT reduces this to
   roughly 63,000 (2^16 minus 1024 reserved).  Middleboxes may further
   restrict the usable range.

   Because the original packet's DSCP and other QoS-related fields are
   preserved on the wire, underlay QoS continues to operate on a per-
   session basis.



Menon, et al.            Expires 9 November 2026               [Page 14]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


3.10.  Post-Handshake Packet Handling

   Once the handshake is complete, every subsequent packet has all five
   tuple fields rewritten in both directions.  Compared to IPsec, this
   transformation is significantly cheaper: no memory copies, no new
   header construction, no new checksums, and no mandatory encryption.

3.11.  Session State Requirements

   Every SVR router MUST maintain per-session state, including the
   original addresses and translation rules.  This state allows peers to
   stop sending SVR Metadata after the handshake and to forward traffic
   akin to segment routing.  State can be lost in three ways:

   *  *Ingress router state loss* -- e.g., during failover or power loss
      at the originating SVR router.

   *  *Intermediate router state loss* -- at the 2nd-to-Nth SVR router
      on the path.

   *  *Middlebox state loss* -- a NAT or firewall between two SVR
      routers loses or modifies session state.

   When state is lost, the affected peer MUST securely reacquire it.  If
   neither peer holds state, the session is processed as a new first
   packet (see Section 4.7.1).

   State-loss detection:  Before transmitting each packet, an SVR router
      compares the elapsed time since the last received packet from the
      peer to a configurable inactivity timeout (RECOMMENDED 5 seconds).
      Exceeding this threshold MAY indicate state loss.  This logic is
      independent of session-idle timers used for state expiry.

   Unicast / asymmetric flows:  For unidirectional or highly asymmetric
      flows, this timeout will trigger routinely; this is expected.

   Health check:  On timeout, a Session Health Check SVR Metadata TLV is
      inserted in the outgoing packet.  A peer that holds valid session
      state responds with a generated packet carrying Forced Drop SVR
      Metadata, reason 8 ("health check OK").  This bidirectional
      exchange also confirms middlebox state.  It is incidental to
      normal traffic and does not replace session keep-alive (see
      Section 3.12).

   State not present:  A peer that receives a Session Health Check but
      holds no state for the session responds with a generated packet
      carrying Forced Drop SVR Metadata, reason 2 ("send full session
      metadata").  See Section 7.8.  If a middlebox has lost state or



Menon, et al.            Expires 9 November 2026               [Page 15]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      mangled the session (e.g., CGNAT) such that no Health Check
      response arrives, the next forward packet is treated as a new
      session (Section 4.7.1).

3.12.  NATs and Session Keep-Alive

   When NAT or a stateful firewall lies between Peers, the source
   address observed at the receiving SVR router may differ from the
   sender's Waypoint.  Routers MUST store the actual on-wire Waypoint
   addresses received from each Peer (in addition to provisioned
   values).

   For sessions traversing such middleboxes, the SVR router behind the
   middlebox SHOULD send periodic SVR Control Messages on idle sessions
   to keep pinholes open.  The RECOMMENDED idle interval is 20 seconds.
   The Control Message uses the saved source/destination ports of the
   idle session; see Section 10.3.6 for the message format and
   Section 7.3 for an example.

3.13.  Use of BFD on Peer Pathways

   BFD [RFC5880] is the RECOMMENDED mechanism for Peer Pathway
   management.  It is used for reachability, NAT detection, Waypoint-
   address-change detection, MTU discovery, idle-pathway quality
   measurement, peer authentication, and key maintenance.  Alternative
   mechanisms MAY be used by mutual agreement of the Peers.

   Because standard BFD authentication fields are insufficient for SVR's
   needs, this document defines BFD Metadata: an extension appended to
   the end of a BFD control packet (in contrast to SVR Metadata, which
   follows the L4 header).  Some BFD Metadata fields are encrypted.
   Protocol Buffers, rather than TLVs, are used to encode BFD Metadata
   for ease of processing.  The full BFD Metadata definition is in
   Section 6.

4.  SVR Multi-path Routing Example

   The example below shows two SVR capable routers, peering with each
   other over multiple pathways.












Menon, et al.            Expires 9 November 2026               [Page 16]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


    Client
     LAN
   10.x.x.x
      |
      |  +--------+                                  +---------+
      |  |        |                                  |         |
      |  |        |                                  |         |
      +->] East  [203.0.113.1<---MPLS---->203.0.113.89] West   |
         | SVR    |                                  |  SVR    |
         | Router[198.51.80.2<--Inet-+--->198.51.80.8]  Router |
         |        |                  |               |         |
         |       [192.0.2.1<-----LTE-+               |         [<--+
         |        |                                  |         |   |
         +--------+                                  +---------+   |
                   <========= Peer Pathways ========>              |
                                                                   |
                                                             172.15.11.x
                                                                 LAN
                                                                Servers



                                  Figure 3

   Note: The client, server, and MPLS network can support the private
   routes in 10.x.x.x and 172.15.11.x address spaces natively, but the
   internet and LTE networks do not.  This is an example of using secure
   vectors to join networks together.

4.1.  Establishing SVR Peering

   Peering proceeds in two steps.  First, each router applies any local
   static L3 routes and exchanges routes via standard L3 protocols (BGP,
   OSPF, etc.) to build a FIB and confirm bidirectional Waypoint
   reachability.  Second, each Peer Pathway between the two routers is
   authenticated; pathways SHOULD be authenticated bidirectionally
   before being used for SVR traffic.

4.1.1.  Reachability and Peer Authentication

   Peer authentication is RECOMMENDED.  Sending SVR Metadata without
   authentication is technically possible but discouraged; either Peer
   MAY require authentication and reject the relationship if it fails.








Menon, et al.            Expires 9 November 2026               [Page 17]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Authentication uses a Router Certificate: an X.509 certificate issued
   from a CSR containing the router's UUID and Authority, signed by a
   trusted CA.  The UUID is administrator-assigned and persists across
   hostname changes, and avoids exposing router names (typically the
   hostname) in packet traces.  Device registration, certificate
   signing, and secure installation are out of scope; see [RFC4210].

   Elliptic Curve cryptography ([RFC8422]) is RECOMMENDED over RSA.  The
   curve is administratively chosen and MUST be the same across all
   routers in an SVR network; NIST P-256 is RECOMMENDED.

   Each Peer transmits a BFD packet with cleartext BFD Metadata carrying
   its X.509 Router Certificate in PEM format ([RFC5758]); see
   Section 6.1.7.  The receiver verifies the certificate (chain to a
   trusted CA), confirms the certificate's common-name UUID matches a
   configured Peer, and stores the public key for use in subsequent
   keying (Section 4.1.2).  To acknowledge receipt and stop further
   certificate transmission, the Peer sends a BFD packet without a
   certificate.  A Peer MAY request retransmission (e.g., after reboot)
   by sending its own certificate again.  Certificate updates trigger a
   repeat of this exchange; existing valid keys remain operational to
   avoid recertification outages.

4.1.2.  Peer Cryptographic Key and Re-keying

   In the example (Figure 3), the East-West Peer relationship has three
   authenticated Peer Pathways.  Securely exchanging BFD between East
   and West requires a Peer Key. Because the Router Certificate's
   keypair is long-lived, the Peer Key is derived using ECDH-ES with the
   Concat KDF ([NIST_SP_800-56A]).

   Concat KDF inputs are: a Salt from each Peer, the local private key,
   and both public keys.  The resulting key is implicitly authenticated
   by the certificates, preventing man-in-the-middle attacks.  Encrypted
   BFD Metadata fields then distribute SVR Metadata Keys; see
   Section 6.1.9.

   A nonce in BFD Metadata, tracked at the receiver, prevents replay of
   old BFD packets.  To bound nonce-table size, tracking SHOULD be rate-
   limited (e.g., one per minute -- ~1440 entries per Peer per day).

   Either Peer MAY rekey at any time by re-running the same exchange
   with new Salt values.  A single Peer Key is shared across all
   pathways between two Peers, which is efficient when many parallel
   pathways exist.






Menon, et al.            Expires 9 November 2026               [Page 18]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


4.1.3.  Metadata Cryptographic Key and Re-keying

   SVR routers may receive metadata-bearing packets on any interface,
   from any Peer, and source addresses can change due to NAT or
   rerouting.  Each router therefore needs to know the cryptographic key
   for each Peer in advance.

   Each SVR router generates (or obtains via a quantum-safe mechanism) a
   single SVR Metadata Key and distributes it to all Peers via encrypted
   BFD Metadata, along with a version identifier.  All SVR Metadata sent
   from this router uses this key until rotation.  See Section 6.1.9.

4.1.4.  Bringing a Peer Into Service

   A Peer is declared operational and in service when at least one
   authenticated pathway exists and an Elliptic Curve Peer Key (ECPK)
   has been established.  It is then ready to carry bidirectional
   traffic.

4.1.5.  Resulting Peer Relationship

   In service, East and West run BFD on each pathway to monitor
   operational status and measure jitter, latency, and packet loss.  For
   the running example, assuming all pathways are healthy:



   PEER: East -> West Authenticated/In Service
     Name      Description                    Characteristics
     MPLS      203.0.113.1->203.0.113.89      20ms Lat, 0 Loss,  2 Jit
     Internet  198.51.80.2->198.51.80.8       30ms Lat, 0 Loss,  3 Jit
     LTE       192.0.2.1->198.51.80.8         50ms Lat, 0 Loss, 15 Jit

   PEER: West -> East Authenticated/In Service
     Name      Description                    Characteristics
     MPLS      203.0.113.89->203.0.113.1      20ms Lat, 0 Loss,  2 Jit
     Internet  198.51.80.8->198.51.80.2       30ms Lat, 0 Loss,  3 Jit
     LTE       198.51.80.8->192.0.2.1         50ms Lat, 0 Loss, 15 Jit



                                  Figure 4

   BFD also runs on in-service Peer Pathways for MTU discovery, address-
   change detection, and idle-pathway quality monitoring.






Menon, et al.            Expires 9 November 2026               [Page 19]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


4.2.  CIDR-based SVR Peer FIB Entries

   Forwarding sessions onto an SVR Peer Pathway requires a route lookup
   that resolves to an SVR Peer (Waypoint) next-hop.  Continuing the
   running example, assume servers in 172.15.11.0/24 sit behind West and
   West advertises the prefix to East over each pathway.  East's FIB
   then contains:



     East's Forward Information Base (FIB)
        Route             Next-Hop IP Addr
        ----------------  -----------------
        172.15.11.0/24    203.0.113.89
        172.15.11.0/24    198.51.80.8
        ....
        [FIB Entries to reach Waypoints omitted]



                                  Figure 5

   Assume an Authority "example" defines Tenant "engineering" as
   10.0.0.0/25 on VLAN 2 and Service "github.example" as 172.15.11.23
   TCP/22.  (Policy provisioning is out of scope.)  When an engineering
   client initiates a session toward github at the East router, FIB
   lookup yields two next-hop Waypoints, which East cross-references
   against its Peer Pathway list to identify three usable pathways:



     Possible Routes
       MPLS      20ms Latency, 0 Loss,  2 Jitter
       Internet  30ms Latency, 0 Loss,  3 Jitter
       LTE       50ms Latency, 0 Loss, 15 Jitter



                                  Figure 6

   East selects a pathway based on quality SLAs and/or load-balancing
   policy, then constructs SVR Metadata, inserts it into the first
   packet, and forwards it down the chosen pathway to West.  The running
   example uses a private LAN behind East with overlapping addresses
   (typical of branch deployments), so East applies source NAT.






Menon, et al.            Expires 9 November 2026               [Page 20]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Assuming MPLS is chosen, East performs first-packet processing
   (Section 4.7.1) and emits the packet on its MPLS interface with
   source 203.0.113.1 and destination 203.0.113.89 -- the MPLS pathway's
   Waypoint pair.  The bidirectional session uses the same address pair
   (reversed for return); per-session uniqueness on the wire is provided
   entirely by the SVR-allocated source/dest ports.

4.3.  Optional Service-Name FIB

   Because SVR Metadata carries Service names as text, an SVR FIB MAY be
   extended with name-based entries to enable routing decisions on
   Service name rather than (or in addition to) CIDR.  Two use cases
   motivate this:

   Avoiding Dynamic DNS:  Dynamic DNS is often used to answer "which IP
      is the best instance right now?".  It can be slow to update,
      costly, and oblivious to private-network path state.  SVR can
      route by Service name directly and resolve the destination at
      egress.

   Multi-cloud networking:  Public clouds publish accurate per-instance
      DNS, but only inside the cloud.  SVR routers can resolve Service
      names at egress to bridge clouds without exposing those DNS
      responders externally.

   An example FIB combining named and CIDR entries:



     East's Extended SVR Forward Information Base (OPTIONAL)

                                                          Egress
     Service Name     Route                 Waypoint      Action
     --------------   --------------------  ------------  --------
     github.example   172.15.11.23:TCP:22   203.0.113.89  FWD
     github.example   172.15.11.23:TCP:22   198.51.80.8   FWD
     logsvc.example   172.15.11.20:UDP:514  203.0.113.89  DNS
     logsvc.example   172.15.11.20:UDP:514  198.51.80.8   DNS
     https.example    172.15.11.24:TCP:443  203.0.113.89  DEST NAT
                                                          -196.168.1.1
                                                          -196.168.1.2
                                                          -196.168.1.3
        [FIB Entries to reach Waypoints omitted]



                                  Figure 7




Menon, et al.            Expires 9 November 2026               [Page 21]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Longest-prefix matching on destination address combined with exact
   protocol/port match is used at ingress to select the route.  The
   Service name string (e.g., "github.example") then travels in SVR
   Metadata across the SVR network until egress.  Implicit default-deny:
   in this example only SSH, Syslog, and HTTPS are permitted; everything
   else is dropped.

   The egress action MAY be one of:

   Forward (default):  Restore the original IP addresses and forward;
      apply source NAT if a Source NAT TLV is present.

   DNS:  Resolve the Service name locally via DNS at the egress router.

   Destination NAT:  Rewrite the destination to a chosen address (or
      load-balance across a pool); equivalent to a load balancer.

   Named routes coexist with CIDR FIB entries; named routes are matched
   first, with CIDR as fallback.

4.4.  SVR Security Definitions

   An Authority MUST provision a common set of security parameters
   across its peers:

   HMAC algorithm:  SHA1, SHA256, or SHA256-128.

   Time-Based HMAC:  YES or NO.

   HMAC scope:  NONE, SVR Metadata only, or ALL packets.

   SVR Metadata block cipher:  NONE, AES128, or AES256.

   Other ciphers MAY be used, provided they produce fixed, well-known
   block sizes for both signing and encryption.

   Per-session payload-encryption Security Policies are negotiated in
   the first-packet SVR Metadata.  The example uses:



         HMAC: (On, time-based, SHA256-128, ALL Packets)
         SVR Metadata Encryption (On, AES256)



                                  Figure 8




Menon, et al.            Expires 9 November 2026               [Page 22]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


4.5.  Time-Based HMAC Details

   SVR uses Time-Based HMAC (per [RFC2104]) for authentication and
   integrity; see Section 5.5.1.  The running example uses SHA256-128
   (16-octet signature).

4.6.  Payload Encryption

   Every SVR Metadata transaction includes a Security ID header TLV
   (Section 10.3.2).

   A unique Payload Key is used per session, for each direction.  Keys
   are generated by the originating router and conveyed in the encrypted
   portion of metadata.  Per-flow keying eliminates glare and simplifies
   key exchange.  Payload Keys and IVs SHOULD be generated using a FIPS
   140-3-approved DRBG.

   Long-lived sessions MAY require rekey if their duration exceeds the
   configurable rekey interval.  Rekey is performed by generating a new
   key, conveying it in mid-flow SVR Metadata, and applying it to all
   subsequent packets.  Downstream SVR routers MUST monitor for mid-flow
   metadata and update their keying state accordingly.

4.7.  New Session Initiation in Detail

   The ladder diagram below shows the example github SSH session
   traversing the East and West routers.

   Ladder Diagram for SSH Example:






















Menon, et al.            Expires 9 November 2026               [Page 23]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


       Engineering                                      Github
       Client . . . . . . . . . . . . . . . . . . . . . Server
         |                                                 |
         |         East Router              West Router    |
         |            |                        |           |
         |---SYN----->|                        |           |
         |            |--SYN[w/MD]------------>|           |
         |            |                        |--SYN----->|
         |            |                        |           |
         |            |                        |<--SYN/ACK-|
         |            |<------SYN/ACK[w/RMD]---|           |
         |<--SYN/ACK--|                        |           |
         |            |                        |           |
         |----ACK---->|                        |           |
         |            |-----------ACK--------->|           |
         |            |                        |---ACK---->|
         |            |                        |           |
         |<== Session Packets Flow with No SVR Metadata ==>|



                                  Figure 9

   East MUST construct and insert SVR Metadata into the first packet of
   the SSH session (the TCP SYN).  West MUST remove the metadata,
   forward the SYN, and on receipt of the SYN/ACK insert reverse SVR
   Metadata into it.  Once both directions have seen metadata from their
   counterpart, the handshake is complete; metadata is carried in
   existing packets when possible.

   Detecting a first packet is protocol-specific: for TCP, a new 5-tuple
   with only the SYN flag set; for UDP, a new 5-tuple not currently
   active.

4.7.1.  East: First-Packet Processing

   Assume the SSH packet arrives at East from the client LAN as shown:

   Arriving Packet at East Router












Menon, et al.            Expires 9 November 2026               [Page 24]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         Packet received on LAN side East Router
         Engineer using SSH to access Github
         +---------+---------------------+--------------+----------+
         |L2 HDR   | IP Header           | TCP Header   | PAYLOAD  |
         |  VLAN=2 |    SRC=10.0.1.1     |   Sport=6969 |   Data   |
         |         |    DST=172.15.11.23 |   Dport=22   |  (N/A)   |
         +---------+---------------------+--------------+----------+



                                 Figure 10

4.7.1.1.  Determine Tenant

   A Tenant is a textual identifier for a group of source endpoints with
   common access policy (akin to a security zone).  In the example, the
   "engineer" Tenant is mapped from VLAN 2 in the Authority "example".
   The attribute-to-Tenant mapping is implementation-specific; routers
   SHOULD associate a default Tenant with each logical interface.

4.7.1.2.  Determine Service

   Service identification is out of scope for this document but is the
   mechanism by which a session is bound to policy.  Common techniques
   include IP/port ranges, TLS SNI, certificate Common Name, and HTTP
   URL extraction; SaaS vendors typically publish their CIDRs and ports.
   For the example, 172.15.11.23 TCP/22 is taken to be the "github"
   Service in Authority "example".

4.7.1.3.  Determine Network Requirements

   With Tenant and Service known, network requirements are looked up:

   Example Network Requirements



             SERVICE: github
               Access Policies:
                 Tenants Allowed: engineering
                 Tenants Denied: release.engineering
               Quality Policy: latency < 40ms
               Security Policy: None



                                 Figure 11




Menon, et al.            Expires 9 November 2026               [Page 25]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Access policies determine which tenants are allowed, and if any are
   specifically denied.  The Quality policy defines the service level
   experience requirements.  Secure Vector Routing exchanges tenants,
   services, and security policies using character strings in SVR
   Metadata.  Access and quality policies are defined and used locally
   within a router and logically associated with the service.  The
   implementation of quality and access policy controls are site
   specific.  For example, VLAN based subnets may have different
   meanings at various locations.  Also, QoS management schemes may be
   different for different network areas.

4.7.1.4.  Picking a Peer Pathway

   Of East's three reachable Peer Pathways, the 40 ms latency budget
   eliminates LTE.  MPLS and Internet are both within SLA; MPLS is
   chosen for its lower latency.

   Pathway selection criteria are implementation-specific and may
   include pathway utilization and capacity, cost (e.g., reserving
   LTE/5G for backup), and operator-defined load-balancing policies.
   The selection algorithm is out of scope for this document.

4.7.1.5.  Allocate Source NAT (if Required)

   The example uses source NAT at the East router's MPLS interface so
   that overlapping branch address spaces can coexist.  A NATing router
   may reuse the interface address with a new source port, or allocate
   from an IP pool.  Either way, the chosen address is placed in SVR
   Metadata; the actual translation is applied at the egress (West)
   router.

4.7.1.6.  Allocate SVR Ports

   The router allocates new source and destination ports for the
   session.  Ports MUST NOT be currently in use and SHOULD NOT have been
   recently freed (to avoid middlebox state confusion); see Section 5.2.
   The allocatable range is provisioned per site to accommodate upstream
   firewall and middlebox restrictions.  East has 8000-24000 available;
   the example uses source 8000 (even) and destination 8001 (odd).  Both
   ports are allocated by the router that initiates SVR Metadata.

4.7.1.7.  Build Session State and SVR Metadata

   With requirements, pathway, and ports in hand, East creates session
   state (including a Session UUID for end-to-end tracking) and builds
   the SVR Metadata block.  The table below maps state to SVR Metadata
   TLVs (full TLV definitions in Section 10):




Menon, et al.            Expires 9 November 2026               [Page 26]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Session State Table Entry


















































Menon, et al.            Expires 9 November 2026               [Page 27]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


  State Information & Mappings to SVR Metadata Fields

                SVR Metadata TLV                       |------TLV------|
  Category       -Field              VALUE             Type   Len  Hdr
  --------      ------------------   ----------------
  Header                                                       12
  Header TLVs
                Security ID          1                   16     4    4
                Path Metrics                             26    10    4
                 -Tx Color           5
                 -Tx TimeValue       4200 MSecs
                 -Rx Color           3
                 -Rx TimeVlue        3950 MSecs
                 -Drop               No
                 -Prev Color Count   950 Packets
                                                              ---  ---
                              Total Header Length = 34 (26+8)  26    8

  Payload TLVs
                 Forward Context                         2     13    4
                 - Source IP Addr     10.0.0.1
                 - Dest IP Addr       172.15.11.23
                 - Protocol           TCP
                 - Source Port        6969
                 - Dest Port          22
                 Tenant Name          engineering         7    11    4
                 Service Name         github             10     6    4
                 UUID                 e9b083df-d922.....  6    16    4
                 Source Router Name   East Router        14    11    4
                 Source NAT Address   203.0.113.1        25     4    4
                 Security Policy      NONE               15     4    4
                 Peer Path                               19    22    4
                 - Source Addr        203.0.113.1
                 - Dest Addr          203.0.113.89
                                                              ---  ---
                           Total Payload Length = 119 (87+32)  87   32

                                   To West     Fr West
                Allocated Ports     Router      Router
                 -Source Port        8000        8001
                 -Dest Port          8001        8000

                Session HMAC Key    [Peer Key at session start]



                                Figure 12




Menon, et al.            Expires 9 November 2026               [Page 28]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   The required first-packet TLVs are defined in Section 5.3.1: Security
   ID, Forward Context, Tenant Name, Service Name, Session UUID, Source
   Router Name, Security Policy, and Peer Pathway ID.  The example also
   includes two optional TLVs: Path Metrics (Section 10.3.7) and IPv4
   Source NAT Address (Section 10.4.13).

   TLV order is arbitrary, but Header TLVs MUST precede Payload TLVs.  A
   peer that receives an unknown TLV MUST ignore it.  In this example
   the header (with two Header TLVs) is 34 octets and the eight Payload
   TLVs total 119 octets.

   The Session HMAC Key is router-local state, conveyed between Peers in
   BFD Metadata, and used for the life of the session.

4.7.1.8.  Encrypt SVR Metadata

   The Payload TLVs are encrypted per Section 5.4.  The example
   provisioning uses AES-256, which has a 128-bit (16-octet) block size.
   With 119 octets of payload, 9 octets of padding bring the encrypted
   region to 128 octets; a 16-octet IV is appended.  The full SVR
   Metadata block is 34 (header) + 128 (encrypted) + 16 (IV) = 178
   octets:

   SVR Metadata Block



         +--------------+--------------+---------+----------------+
         |   SVR        |   SVR        |         |                |
         | Metadata     | Metadata     | Padding | Initialization |
         | Header       | Payload TLVs |         |    Vector      |
         | (Unecrypted) |              |         |                |
         | 34 Bytes     | 119 Bytes    | 9 Bytes |  16 Bytes      |
         +--------------+--------------+---------+----------------+
         |<---Clear---->|<---Encrypted Portion-->|

         |<--------------178 Byte SVR Metadata Block------------->|



                                 Figure 13

4.7.1.9.  Insert SVR Metadata

   The 178-octet block is inserted directly after the L4 header.  Any
   existing payload data is shifted to make room:

   SVR Metadata Added



Menon, et al.            Expires 9 November 2026               [Page 29]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         Packet with SVR Metadata inserted
         +---------------------+--------------+-----------+------------+
         | IP Header           | TCP Header   |  SVR      |  PAYLOAD   |
         |    SRC=10.0.1.1     |   Sport=6969 | Metadata  |    Data    |
         |    DST=172.15.11.23 |   Dport=22   | 178 Bytes | (optional) |
         +---------------------+--------------+-----------+------------+



                                 Figure 14

   The transport addresses are then rewritten to the chosen Peer
   Pathway's Waypoints, and the SVR-allocated ports are installed:

   Transport Addresses Updated



         Final Transformed Packet with SVR Metadata inserted
         +---------------------+--------------+-----------+------------+
         | IP Header           | TCP Header   |  SVR      |  PAYLOAD   |
         |    SRC=203.0.113.1  |   Sport=8000 | Metadata  |    Data    |
         |    DST=203.0.113.89 |   Dport=8001 | 178 Bytes | (optional) |
         +---------------------+--------------+-----------+------------+



                                 Figure 15

4.7.1.10.  Sign SVR Packet

   The packet is then HMAC-signed (Section 4.5) using the current SVR
   Metadata Key (Section 6.1.9).  The signature is appended to the end
   of the packet, extending its length by the signature size (16 octets
   in this example).  The IP header is excluded from the signed range.

   HMAC Signature Added














Menon, et al.            Expires 9 November 2026               [Page 30]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      Packet with SVR Metadata inserted
      +-------------------+--------------+-----------+---------+-------+
      | IP Header         | TCP Header   | Encrypted | PAYLOAD | HMAC  |
      |  SRC=203.0.113.1  |   Sport=8000 |   SVR     |   Data  |  16   |
      |  DST=203.0.113.89 |   Dport=8001 | Metadata  |         | Bytes |
      +-------------------+--------------+-----------+---------+-------+
                          |                                    |
                          |<=========HMAC Signed Data=========>|



                                Figure 16

4.7.1.11.  Send the First Packet

   The IP length and checksum are recomputed and the packet is
   transmitted.  East continues to include the same SVR Metadata in
   every outbound packet of the session until it sees a reverse packet
   carrying SVR Metadata (handshake complete).  For TCP this is
   typically the SYN/ACK; thereafter no further metadata is inserted for
   the lifetime of the session unless a path-migration event occurs.



           Client ----> TCP SYN w/SVR Metadata --------> Server
           Client <---- TCP SYN-ACK w/SVR Metadata <---- Server



                                 Figure 17

   For UDP, metadata is inserted on every packet until a reverse packet
   carrying metadata is observed, except for unidirectional flows; see
   Section 4.7.7.

4.7.2.  West: First-Packet Processing

   A packet arriving at West with West's own Waypoint as the IP
   destination (i.e., addressed to the router rather than transiting it)
   likely carries SVR Metadata and is processed as follows.

4.7.2.1.  Verify Source Address is a Waypoint

   The packet MUST be validated before processing (Section 5.6.2).  On
   authentication or validation failure, the packet MAY be dropped or
   returned with an ICMP Destination Unreachable.  In the example, only
   three source addresses are valid:




Menon, et al.            Expires 9 November 2026               [Page 31]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Possible Source Addresses



               203.0.113.1      MPLS Peer Pathway
               198.51.80.2      Internet Peer Pathway
               169.254.231.106  LTE Peer Pathway



                                 Figure 18

4.7.2.2.  Verify SVR Metadata Block

   The most efficient first test is checking for the SVR header magic
   number (Section 5.6.1).  The HMAC signature is then verified
   (Section 5.5.1); on failure the packet is dropped and a security
   event recorded.  The unencrypted portions of the SVR Metadata header
   MUST be sanity-checked (header and payload lengths must each be less
   than the total block size).

4.7.2.3.  Decrypt, Parse, and Save State

   The metadata block is decrypted (Section 5.6.2.2); any decryption
   failure causes the packet to be dropped.  The Payload TLVs are parsed
   and the resulting state and translation rules are installed; any
   parse failure causes the packet to be dropped.  The SVR Metadata
   block and the HMAC signature are then removed from the packet.

4.7.2.4.  Restore Addresses and Route

   The original 5-tuple is restored from the Forward Context TLV and the
   packet is processed recursively as if it were a new first packet
   (Section 4.7.1), with one difference: the Tenant, Service, Security
   Policy, and Session UUID are taken from the received metadata rather
   than locally derived.  The packet may then traverse another Peer
   Pathway or be delivered via standard forwarding -- in the example,
   West delivers the packet to the server LAN.

   When forwarding to another SVR Peer, Tenant, Service, Session UUID,
   Security Policy, and the original 5-tuple are cloned into the new
   metadata so that semantics remain consistent across multi-hop SVR
   paths.  SVR Metadata MUST be decrypted and re-encrypted at every hop
   (because each hop uses different Waypoint addresses), but payload
   encryption is end-to-end -- applied at the first SVR router and
   decrypted at the last.





Menon, et al.            Expires 9 November 2026               [Page 32]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


4.7.2.5.  Loop Detection

   Because every SVR hop preserves the Session UUID, a looping first
   packet is trivial to detect: there MUST never be two sessions with
   the same UUID, and any duplicate MUST be dropped.  Detecting the loop
   on the first packet allows subsequent packets to be dropped at
   ingress.  SVR routers MUST also decrement TTL/Hop Limit so that loops
   not caught by SVR are still bounded by traditional IP forwarding
   rules.

   A packet bearing SVR Metadata that arrives after the handshake is
   treated as an in-session update, not a loop.  Updates may modify any
   attribute; most commonly they change the Peer Pathway for the
   session.  See Section 7.1.

4.7.3.  Pre-established Return-Path State

   After East and West each process the first forward packet, both
   directions of forwarding state and any required translations are
   installed.  Subsequent packets in either direction are matched on
   5-tuple and forwarded without further routing-table consultation
   ("fast path").

4.7.4.  Sending Reverse SVR Metadata

   Each SVR Router tracks the metadata-handshake status per session.  If
   a forward packet arrives for a session whose handshake is incomplete,
   the router MUST insert SVR Metadata; it continues until it sees
   evidence (a reverse packet bearing metadata) that the peer received
   it.  For TCP, the first reverse packet is normally the SYN/ACK.
   Reverse metadata serves to:

   *  signal the sender to stop inserting metadata (handshake complete);
      and

   *  convey return-direction Service information for future routing
      decisions.

   The reverse SVR Metadata for the example contains:

   Reverse SVR Metadata Response










Menon, et al.            Expires 9 November 2026               [Page 33]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


             Reverse SVR Metadata Response
   State Information & Mappings to SVR Metadata Fields

                 SVR Metadata TLV                      |------TLV------|
   Category       -Field              VALUE             Type   Len  Hdr
   --------      ------------------   ----------------
   Header                                                       12
   Header TLVs
                 Security ID          1                   16     4    4
                 Path Metrics                             26    10    4
                  -Tx Color           3
                  -Tx TimeValue       4100 msecs
                  -Rx Color           5
                  -Rx TimeVlue        4050 msecs
                  -Drop               No
                  -Prev Color Count   1950 packets
                                                               ---  ---
                              Total Header Length = 34 (26+8)   26    8

   Payload TLVs
                  Reverse Context                         4     13    4
                  - Source IP Addr     203.0.113.1
                  - Dest IP Addr       172.15.11.23
                  - Protocol           TCP
                  - Source Port        7891
                  - Dest Port          6969
                  Peer Path                               19    22    4
                  - Source Addr        203.0.113.89
                  - Dest Addr          203.0.113.1
                                                               ---  ---
                             Total Payload Length = 43 (35+8)   35    8

                                      To East     From East
                  Allocated Ports     Router       Router
                  - Source Port        8001         8000
                  - Dest Port          8000         8001

                 Session HMAC Key   [Peer key used by remote peer]



                                 Figure 19

   See Section 5.3 for required and optional reverse metadata TLVs.  The
   example also includes the optional Path Metrics TLV (Section 10.3.7).






Menon, et al.            Expires 9 November 2026               [Page 34]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   The Session HMAC Key is router-local state communicated to peers in
   BFD Metadata; its lifetime tracks the Peer Metadata key.  The key is
   used for the life of the session.

   The Forward and Reverse Contexts together give SVR end-to-end
   visibility of every session: pre-NAT 5-tuple at ingress, post-NAT
   5-tuple at egress, and the Waypoint addresses/ports used on each
   pathway.

   This SVR Metadata will be encrypted, inserted, and an HMAC checksum
   will be computed and attached as per the previous example.  The
   reverse packet in this example will have 34 octets of header data,
   and 43 octets of payload data, 5 octets of padding, and a 16 octets
   initialization vector resulting in an SVR Metadata block that is 98
   octets long.

4.7.5.  Subsequent Packet Processing

   A peer that receives a session packet without SVR Metadata treats the
   handshake as complete and stops inserting metadata in its own
   outbound direction.  This applies symmetrically to East and West.

4.7.6.  Session Termination

   No SVR Metadata is exchanged on normal termination.  For TCP, the
   router monitors FIN/ACK or RST and removes session state after a
   guard timer; a new SYN matching the same 5-tuple during that window
   immediately tears down the prior session.  All protocols additionally
   have an inactivity timeout; a packet arriving after the timeout is
   treated as a new session.

4.7.7.  Unidirectional and Asymmetric Flows

   When a flow is unidirectional or asymmetric (e.g., TCP sequence
   numbers advance with no observed reverse packets but end-to-end
   delivery is confirmed), the sender stops inserting SVR Metadata.  For
   UDP asymmetry, the sender inserts metadata in at most ~20 packets; if
   no reverse packet appears in that window, the receiving peer
   generates a "disable metadata" packet to complete the handshake.  The
   exact packet count is implementation-specific.

4.7.8.  Multi-Hop Session Ladder Diagram

   The diagram below illustrates a TCP session traversing three SVR
   routers:

   Ladder Diagram for Session Initiation with SVR Metadata:




Menon, et al.            Expires 9 November 2026               [Page 35]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


           Client . . . . . . . . . . . . . . . . . . . . . . Server
             |                                                   |
             |         Router A      Router B     Router C       |
             |            |             |            |           |
             |----SYN---->|             |            |           |
             |            |--SYN[MD1]-->|            |           |
             |            |             |--SYN[MD2]->|           |
             |            |             |            |----SYN--->|
             |            |             |            |           |
             |            |             |            |<--SYN/ACK-|
             |            |             |<--SYN/ACK--|           |
             |            |<--SYN/ACK---|   [RMD2]   |           |
             |<--SYN/ACK--|    [RMD1]   |            |           |
             |            |             |            |           |
             |            |             |            |           |
             |<=== Session Packets Flow with No SVR Metadata ===>|



                                 Figure 20

   Each router builds metadata (MD1, MD2) for the next chosen Peer; on
   the first reverse packet each router inserts reverse metadata (RMD1,
   RMD2).  Each router allocates its own Waypoints and ports.  The
   Forward Context, Tenant, Service, and Session UUID are preserved
   across all hops, allowing consistent policy application end-to-end.
   The Session UUID is identical in MD1, MD2, RMD1, and RMD2.

   A TCP teardown is similarly direct -- no SVR Metadata is required:

   Ladder Diagram for Session Teardown SVR Metadata:




















Menon, et al.            Expires 9 November 2026               [Page 36]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


           Client . . . . . . . . . . . . . . . . . . . . . . Server
             |                                                   |
             |         Router A      Router B     Router C       |
             |            |             |            |           |
             |---FIN----->|             |            |           |
             |            |-----FIN---->|            |           |
             |            |             |----FIN---->|           |
             |            |             |            |-----FIN-->|
             |            |             |            |           |
             |            |             |            |<--FIN/ACK-|
             |            |             |<--FIN/ACK--|           |
             |            |<--FIN/ACK---|            |           |
             |<--FIN/ACK--|             |            |           |
             |            |             |            |           |
             |            |             |            |           |



                                 Figure 21

   No SVR Metadata is sent on session termination.  Each router retains
   state for a configurable interval (covering FIN/ACK loss) before
   removing it.

5.  SVR Protocol Definition

   This section provides the normative requirements for SVR Metadata.

5.1.  Sessions and Types

   SVR implementations MUST support TCP, UDP, and ICMP.  SVR
   implementations SHOULD support UDP Unicast.  A session is identified
   by a 5-tuple unique to the SVR router; it begins on the first packet
   and ends when either the L4 protocol signals completion (TCP FIN/FIN-
   ACK or RST) or after a protocol-specific inactivity timeout (UDP,
   ICMP, UDP Unicast, point-to-point Ethernet).

   SVR is always OPTIONAL: implementations MAY choose per session
   whether to apply SVR, and SVR implementations MUST also support non-
   SVR traffic.

5.2.  SVR Metadata Insertion









Menon, et al.            Expires 9 November 2026               [Page 37]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


5.2.1.  Metadata Location in the Packet

   SVR implementations MUST insert SVR Metadata directly after the L4
   header, even if doing so causes IP fragmentation.  For Ethernet
   point-to-point and ICMP error messages, IP and L4 headers MUST be
   created; if associated with an existing session, the created packet
   MUST share the exact 5-tuple (Waypoints and Ports) of that session.
   SVR Metadata MUST appear in the very first packet of a new session
   (TCP or UDP bidirectional flow) to influence path selection or
   security.  SVR Metadata SHALL be inserted in any subsequent packet in
   either direction to update networking requirements.  Metadata is
   carried in the L4 payload to ensure end-to-end transparency.  Packet
   lengths and L3/L4 checksums MUST be adjusted; TCP sequence numbers
   MUST NOT be adjusted.

5.2.2.  Prerequisites for Insertion

   A Peer Pathway MUST be selected before SVR Metadata is inserted.  The
   pathway's Waypoint addresses serve as the L3 source/destination for
   every packet bearing SVR Metadata.

5.2.3.  Session Port Allocation

   The originating SVR peer (client side) MUST allocate both source and
   destination ports.  The ingress side MUST use even ports for the
   local (source) port and odd ports for the remote (destination) port,
   guaranteeing uniqueness between any peer pair without negotiation.
   The allocatable range is provisioned.  Ports in use MUST be excluded
   from allocation; ports MUST be released when the session is removed;
   and a freed port MUST observe a 60-second guard time before
   reallocation.

5.2.4.  Metadata on Idle Sessions

   An SVR implementation MAY need to send metadata to a peer when no
   data packets are flowing (see Section 7.3).  In that case it MUST
   synthesize an IP packet matching the session's 5-tuple, marked to be
   dropped after processing; the directly adjacent peer MUST process and
   discard it without forwarding to any other SVR peer.

5.2.5.  Packet Structure










Menon, et al.            Expires 9 November 2026               [Page 38]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


     Existing IP Packet with SVR Metadata inserted
     +------------------+-----------------+----------+----------+------+
     | Existing IP Hdr  | Existing L4 Hdr |  SVR     | PAYLOAD  | HMAC |
     |   Source IP Addr |   Source Port   | Metadata |   Data   |      |
     |   Dest IP Addr   |   Dest Port     | Block    |(optional)|      |
     +------------------+-----------------+----------+----------+------+

     Generated IP Packet with SVR Metadata inserted
     +-------------------+------------------+----------+------+
     | Created  IP Hdr   | Created L4 Hdr   |  SVR     | HMAC |
     |   Source IP Addr  |   Source Port    | Metadata |      |
     |   Dest IP Addr    |   Dest Port      | Block    |      |
     +-------------------+------------------+----------+------+

     ICMP Packet with SVR Metadata inserted
     +-----------------+-----------------+----------+--------+------+
     | Created IP Hdr  | Created UDP Hdr |  SVR     |  ICMP  | HMAC |
     |  Source IP Addr |   Source Port   | Metadata |  MSG   |      |
     |  Dest IP Addr   |   Dest Port     | Block    |        |      |
     +-----------------+-----------------+----------+--------+------+

     Ethernet Packet with SVR Metadata inserted
     +-----------------+-----------------+----------+----------+------+
     | Created IP Hdr  | Created UDP Hdr |  SVR     | Ethernet | HMAC |
     |  Source IP Addr |   Source Port   | Metadata | MSG      |      |
     |  Dest IP Addr   |   Dest Port     | Block    |          |      |
     +-----------------+-----------------+----------+----------+------+



                                Figure 22

   For UDP, the UDP header length field MUST be updated.  The L4
   checksum (TCP or UDP) MUST be recalculated.  The IP total-length
   field MUST be updated to account for the inserted metadata block and
   the appended HMAC, and the IP header checksum MUST then be
   recomputed.  For TCP, sequence numbers MUST NOT be modified.

5.2.6.  Prevention of False Positives

   Because SVR Metadata is carried in the L4 payload, an existing
   payload could coincidentally begin with the same 8-octet SVR magic
   number.  False-positive logic prevents downstream routers from
   misinterpreting such payloads.

   False positives SHALL NOT occur on first packets, since valid
   metadata is unconditionally inserted there.  They can only arise on
   mid-session packets of an established SVR session.



Menon, et al.            Expires 9 November 2026               [Page 39]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   When a mid-session packet's payload begins with the SVR magic number,
   the implementation MUST insert an empty SVR Metadata header (12
   octets, zero TLVs).  This establishes the contract that any
   appearance of the magic number on the wire indicates valid metadata
   that downstream routers MUST process and remove.  The inserted header
   carries no TLVs and is not encrypted.

   SVR Metadata Location



      Received Midstream SVR Packet matching SVR Magic Number
      +-------+--------+--------------------------+
      |IP Hdr | L4 Hdr | 0x4c48dbc6ddf6670c ..... |
      +-------+--------+--------------------------+

      Midstream SVR Packet with False Positive SVR Metadata inserted
      +--------+--------+----------+---------------------------+
      |        |        |   SVR    |                           |
      | IP Hdr | L4 Hdr | Metadata | 0x4c48dbc6ddf6670c ...... |
      |        |        |   HDR    |                           |
      +--------+--------+----------+---------------------------+



                                 Figure 23

   Header or payload TLVs MAY be added at the implementation's
   discretion; if added, standard processing rules apply (including
   encryption when payload TLVs are present).

5.2.7.  TCP-to-UDP Transformation

   When a middlebox blocks TCP packets that carry SVR Metadata,
   implementations transform the affected TCP session to UDP for the
   duration it crosses the middlebox and restore TCP at the egress.
   Pathway-test traffic typically detects the need for this.  The
   transform proceeds as follows:

   The IP protocol field MUST be changed from 0x06 (TCP) to 0x11 (UDP).
   The original TCP sequence number is preserved by copying it to the
   TCP checksum/urgent-pointer field before the UDP checksum overlays
   the sequence number location.  TLV 12 (Section 10.4.9) MUST be added
   to the SVR Metadata to flag the transformation.

   Once engaged, every packet of the session is transformed -- not just
   those carrying metadata.  Restoration is described in Section 5.6.3.




Menon, et al.            Expires 9 November 2026               [Page 40]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


5.3.  Required and Optional TLVs

5.3.1.  IP Session TLVs

   The first forward SVR Metadata of a new session MUST contain:

   *  Header: Security ID: see Section 10.3.2.

   *  Payload: Forward Context: see Section 10.4.1, Section 10.4.2.

   *  Payload: Tenant Name: see Section 10.4.6.

   *  Payload: Service Name: see Section 10.4.7.

   *  Payload: Session UUID: see Section 10.4.5.

   *  Payload: Source Router Name: see Section 10.4.10.

   *  Payload: Security Policy: see Section 10.4.11.

   *  Payload: Peer Pathway ID: see Section 10.4.12.

   Forward SVR Metadata MAY also include the following optional TLVs:

   *  Header: Path Metrics: see Section 10.3.7.

   *  Header: SVR Control Message: see Section 10.3.6.

   *  Payload: Session Encrypted: see Section 10.4.8.

   *  Payload: TCP Syn Packet: see Section 10.4.9.

   *  Payload: IPv4 Source NAT Address: see Section 10.4.13.

   *  Payload: Remaining Session Time: see Section 10.4.14.

   TLV order is arbitrary, but Header TLVs MUST precede Payload TLVs.  A
   peer MUST ignore any TLV it does not recognize.

   The first reverse packet of a new session MUST contain:

   *  Header: Security ID: see Section 10.3.2.

   *  Payload: Reverse Context: see Section 10.4.3, Section 10.4.4.

   *  Payload: Peer Pathway ID: see Section 10.4.12.

   Reverse SVR Metadata MAY also include:



Menon, et al.            Expires 9 November 2026               [Page 41]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   *  Payload: Path Metrics: see Section 10.3.7.

5.3.2.  ICMP TLVs

   A returned ICMP error MUST contain:

   *  Header: ICMP Error Location Address: see Section 10.3.4,
      Section 10.3.5.

   It MAY also include:

   *  Header: Path Metrics: see Section 10.3.7.

5.4.  SVR Metadata Encryption

   SVR Metadata encryption uses block ciphers with a fixed block size.
   The cipher and its block size MUST be provisioned and known to peers
   in advance (provisioning is out of scope).  The SVR Metadata Key is
   common to all Peer Pathways between two peers and is obtained via BFD
   with SVR Metadata (Section 6.1.9).  Payload TLVs are zero-padded
   (0x00) up to a multiple of the block size, and a per-block IV makes
   decryption stateless.

   SVR Metadata Block



             Cipher       Block Size         IV Size
            -------    ------------------    --------
             AES256    128 Bits(16 Bytes)    16 Bytes
             AES128    128 Bits(16 Bytes)    16 Bytes

         +----------+--------+---------+---------+----------------+
         |   SVR    |        |         |         |                |
         | Metadata | Header | Payload | Padding | Initialization |
         | Header   | TLVs   | TLVs    |         |    Vector      |
         +----------+--------+---------+---------+----------------+
         |<------Clear------>|<--- Encrypted --->|

         |<------------------ SVR Metadata Block ---------------->|



                                 Figure 24

   The required pad length is (block_size - (payload_len mod
   block_size)) mod block_size.




Menon, et al.            Expires 9 November 2026               [Page 42]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


5.5.  Packet Authentication

5.5.1.  HMAC Signatures

   An SVR Authority MUST provision (out of scope here): whether HMAC
   signatures are used; whether Time-Based HMAC is used; and whether ALL
   packets are signed or only those carrying SVR Metadata.  Time-Based
   HMAC on ALL packets is RECOMMENDED to mitigate replay attacks.  The
   Session HMAC Key is conveyed between peers in BFD Metadata
   (Section 6.1.9) and is used for the life of the session.

   SVR peers SHOULD sign all packets per [RFC2104] using the Session
   HMAC Key. When present, an IP packet MUST contain at most one HMAC
   signature, even if it is fragmented.  For Time-Based HMAC, the
   implementation appends (current_epoch_seconds / 2) to the signed
   data; clocks MUST be synchronized accurately, with NTP ([RFC5905]) as
   a baseline.  Disabling Time-Based HMAC in favor of standard HMAC is
   NOT RECOMMENDED.

   The HMAC signature is appended to the end of the packet.  Its length
   depends on the algorithm; supported algorithms include SHA1,
   SHA256-128, and SHA256.

   Location of HMAC Checksum



























Menon, et al.            Expires 9 November 2026               [Page 43]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


       SVR Packet with SVR Metadata inserted
       +-----------+--------------+----------+----------+------+
       | IP Header |  L4 Header   |   SVR    | PAYLOAD  | HMAC |
       |           |              | Metadata |(optional)|      |
       +-----------+--------------+----------+----------+------+
                   |                                    |
                   |<======= HMAC Signed Data =========>|

       Subsequent SVR Packet
       +-----------+--------------+---------+------+
       | IP Header |  L4 Header   | Payload | HMAC |
       |           |              |         |      |
       +-----------+--------------+---------+------+
                   |                        |
                   |<== HMAC Signed Data ==>|


         HMAC TYPE     LENGTH OF SIGNATURE
         ----------    -------------------
         SHA1          20 Bytes
         SHA256-128    16 Bytes
         SHA256        32 Bytes



                                 Figure 25

5.5.2.  HMAC Verification

   When HMAC signatures are in use, SVR implementations MUST verify and
   remove the signature on receipt.  Verification provides both peer
   authentication and integrity protection across the previous hop.
   Provisioning rules (signatures present, Time-Based, ALL vs. metadata-
   only) are as in Section 5.5.1.  Verification regenerates the
   signature locally and compares it byte-wise to the one in the packet,
   using the Session HMAC Key from the matching session state.

   HMAC Signature Removed













Menon, et al.            Expires 9 November 2026               [Page 44]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


       SVR Packet with HMAC Signature
       +-----------+--------------+----------+------+
       | IP Header |  L4 Header   | PAYLOAD  | HMAC |
       |           |              |(optional)|      |
       +-----------+--------------+----------+------+
                   |                         |
                   |<== Signed Data ========>|

       SVR Packet with HMAC Signature removed
       +-----------+--------------+----------+
       | IP Header |  L4 Header   | PAYLOAD  |
       |           |              |(optional)|
       +-----------+--------------+----------+



                                 Figure 26

   For efficiency with Time-Based HMAC, implementations SHOULD compute
   the partial HMAC over the packet body once (excluding the IP header),
   then attempt finalization with the current time window; on mismatch,
   retry with the next window (current+2 seconds) and then the previous
   (current-2 seconds).  The active window for a given peer SHOULD be
   cached and advanced as time progresses.

   If no time window and no recently-issued key produces a match, the
   packet MUST be dropped and a security event recorded.

   On match, the packet is authenticated; the HMAC signature MUST be
   removed, the IP total-length field MUST be updated, and the IP header
   checksum MUST then be recomputed.

5.6.  Processing Packets That May Carry SVR Metadata

   SVR routers MUST process both SVR and non-SVR traffic and MUST track
   which sessions are using SVR.  SVR-bearing traffic always uses
   Waypoint addresses, providing efficient ingress separation between
   SVR and non-SVR traffic.  Packets arriving on a known Peer Pathway
   MUST be presumed to either contain SVR Metadata or belong to an
   established SVR session.

5.6.1.  Detection of SVR Metadata

   DPI MUST be used on every packet to detect SVR Metadata.  For first
   packets, metadata is required and its absence causes the packet to be
   dropped.  The HMAC verification step (above) MUST run before any
   further metadata processing, to prevent on-path tampering.




Menon, et al.            Expires 9 November 2026               [Page 45]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   If the first 8 octets of the L4 payload (TCP or UDP) exactly match
   the SVR magic number (0x4c48dbc6ddf6670c), the packet MUST be treated
   as bearing SVR Metadata.  If they do not match, the packet does not
   contain metadata; if it belongs to an existing session it SHOULD be
   routed (Section 5.6.4), otherwise it MUST be dropped and a security
   event recorded.

5.6.2.  Verification of SVR Metadata

5.6.2.1.  TLV Parsing

   The SVR Metadata header is parsed (Section 10.1).  If both the header
   length and payload length are zero, the metadata is simply removed
   and the packet forwarded -- this is the false-positive case
   (Section 5.2.6).  The implementation then walks any header TLVs to
   validate them; with payload length zero, no decryption is required.

   An unknown TLV SHOULD be skipped and MUST be forwarded unchanged.  If
   any TLV value is unreasonable, the packet MUST be dropped and a
   security event recorded.

5.6.2.2.  Decryption of SVR Metadata Blocks

   If the peers have been provisioned to encrypt SVR Metadata and the
   payload length is non-zero, the implementation MUST treat the payload
   region as an encrypted block.  The pre-provisioned cipher, block
   size, and IV size, combined with the header's payload length, fully
   determine the block layout.

   Encrypted SVR Metadata Block



           Known in advance: Cipher, Block Size, IV size
           From SVR Metadata Header: Payload TLV size

      +----------+--------+---------+---------+----------------+--~~~
      | SVR      | Header | Payload | Padding | Initialization | Rest...
      | Metadata | TLVs   | TLVs    |         |   Vector (IV)  | of  ...
      | Header   |        |         |         |                | Pkt ...
      +----------+--------+---------+---------+----------------+--~~~
      |<----- Clear ----->|<--- Encrypted --->|

      |<---------------- SVR Metadata Block ------------------>|



                                 Figure 27



Menon, et al.            Expires 9 November 2026               [Page 46]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   The pad length is (block_size - (payload_len mod block_size)) mod
   block_size; the IV immediately follows the encrypted block.

   If decryption fails, the packet MUST be dropped and a security event
   recorded.  On success, the payload TLVs MUST be checked for
   completeness against Section 5.3; insufficient or unreasonable TLVs
   cause the packet to be dropped with an error recorded.  The metadata
   block is then removed and the IP total-length and header checksum
   MUST be updated.

5.6.3.  UDP-to-TCP Restoration

   If the received metadata contains a TCP SYN Packet TLV
   (Section 10.4.9), the following MUST be performed on every packet of
   the session, in both directions (see Section 5.2.7):

   The IP protocol field MUST be changed from 0x11 (UDP) back to 0x06
   (TCP).  The 32-bit value at the TCP checksum/urgent-pointer location
   is copied back to the sequence-number field; the urgent pointer is
   zeroed and its flag cleared.  The TCP checksum MUST then be
   recomputed.

5.6.4.  SVR Session Packets

   A packet whose source and destination addresses both map to a Peer
   Pathway is an SVR packet.  Such packets without metadata are in-
   session traffic and MUST have matching session state; if no state
   exists, the packet MUST be dropped or session state MUST be restored
   (Section 3.11).

   Ingressing in-session packets MUST be translated bidirectionally on
   all 5-tuple fields: source address to the local Waypoint, destination
   address to the chosen peer's Waypoint, ports to the allocated SVR
   ports, and protocol modified if UDP transformation applies
   (Section 5.2.7).  Implementations SHOULD cache a single checksum
   delta per session, since the rewrite is identical for every packet.

   Egressing in-session packets MUST have the original 5-tuple restored
   from saved session state (source/destination addresses, ports, and
   protocol -- with UDP-to-TCP restoration per Section 5.6.3 if
   applicable).

5.6.5.  Tenant and Service Overview

   A provisioned SVR Policy SHOULD include both a Tenant and a Service.
   Absence of an applicable SVR Policy SHOULD prevent SVR session
   establishment; traditional IP routing MAY be used when no SVR policy
   applies.



Menon, et al.            Expires 9 November 2026               [Page 47]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


5.6.5.1.  Service Interpretation

   A Service is a textual name for a set of CIDR blocks, protocols, and
   ports (e.g., "Zoom", "Office365").

   Service Definition



               Service Name
                   protocol: TCP/UDP
                   port ranges[]
                   CIDR Blocks[]



                                 Figure 28

   A packet arriving with SVR Metadata MUST carry the Service name in
   the first-packet metadata.  A packet arriving without SVR Metadata is
   classified by destination address/port/protocol lookup; if that
   fails, application-recognition techniques (HTTP request inspection,
   TLS SNI, certificate Common Name) MAY be used.  These techniques are
   out of scope for this document.

   Services MAY have associated quality and security policies
   provisioned (out of scope here).

   At SVR egress, the Service name MAY be used to forward to another SVR
   peer (in which case it MUST be carried unchanged) or to resolve to a
   final IP destination by one of:

   Use Destination from Context (default):  Restore the original
      destination address and forward.

   Destination NAT:  Map the Service to one or more local IP addresses
      (load-balancing to Service instances; common in public clouds).

   DNS Resolution:  Some provisioned service configurations locally
      (nearest the destination SVR router) will map the service to one
      or more local IP addresses through implementation of a destination
      NAT.  This effectively becomes a load balancing algorithm to
      destination service instances, and is useful in public clouds.

   Services SHOULD be provisioned with allow/deny lists of Tenants;
   these access controls are RECOMMENDED.





Menon, et al.            Expires 9 November 2026               [Page 48]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


5.6.5.2.  Tenant Determination and Interpretation

   A Tenant is a period-delimited textual hierarchy, logically akin to a
   VLAN, CIDR subnet, or security zone.  Policy match is performed
   right-to-left on full segments, with the longest segment match
   winning.

   A Tenant SHOULD be paired with a Service to form a from-to vector
   (allowing ACLs to be tied directly to destinations).  A provisioned
   SVR Policy SHOULD include both; absence of an applicable policy
   prevents session establishment.  Default-deny is RECOMMENDED.

   It is RECOMMENDED that Tenants be associated with physical and
   logical (VLAN) interfaces as defaults; CIDR-block-based Tenants
   SHOULD override these defaults; client self-asserted Tenants SHOULD
   override all other definitions.

   Interface-based Tenant assignments are local to each SVR router;
   ingress and egress Tenant identities need not match, allowing
   heterogeneous segmentation across networks.

5.6.6.  Payload Encryption

   When payload encryption is required, a Security Policy specifies the
   agreed methods.  The policy semantics MUST be valid and identical at
   the points of encryption and decryption (relevant for multi-hop SVR
   routes).

   An SVR router generates a Payload Key locally on the first packet
   requiring encryption per the policy.  Keys and IVs MUST be generated
   using a FIPS 140-3-approved DRBG; following NIST SP 800-90B for
   entropy is strongly RECOMMENDED (see [NIST_SP_800-90B]).  OpenSSL's
   RAND_bytes() is one suitable option.  The key is conveyed in the
   first encrypted packet's SVR Metadata.  Future implementations MAY
   source key material from quantum entropy.

   The metadata is forwarded hop-by-hop until SVR egress; the egress
   router MUST extract the Payload Key and store it in session state for
   decrypting all subsequent payload packets in that direction.  The
   reverse direction uses an independently generated key, carried in
   reverse metadata.  Asymmetric per-direction keying simplifies key
   management and avoids glare.

   The originator MAY rekey at any time by inserting new SVR Metadata
   bearing a new key; the new key takes effect on the carrying packet.






Menon, et al.            Expires 9 November 2026               [Page 49]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   The Security KEY TLV (Section 10.4.15) carries the encryption/
   decryption key in the first-packet metadata for each direction.  End-
   to-end key conveyance is safe because SVR Metadata is encrypted hop-
   by-hop; payload decryption occurs only at the final SVR hop.  Named
   Security Policies allow any cipher; the default is AES-256 with a
   256-bit key.

   Payload Encryption:



             Peer A          Peer B          Peer C
               |               |               |
       fpkt--->|               |               |
               |               |               |
            Gen Key            |               |
            Encrypt Payload    |               |
            Add Key to MD      |               |
               |               |               |
               |--fpkt w/md--->|               |
               |            Forward            |
               |               |--fpkt w/md--->|
               |               |             Save Key
               |               |               |
               |               |               |--fpkt->
               |               |               |<-rpkt
               |               |               |
               |               |             Lookup Key
               |               |             from session
               |               |               |
               |               |             Gen Key
               |               |             Encrypt Payload
               |               |             Add Key to MD
               |               |<--rpkt w/md---|
               |            Forward            |
               |<--rpkt w/md---|               |
               |               |               |
        <-rpkt-|               |               |
               <== ALL PAYLOAD PKTS ENCRYPTED =>



                                 Figure 29








Menon, et al.            Expires 9 November 2026               [Page 50]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


6.  BFD for Peer Pathways

   Peer Pathways are virtual transport links between routers, analogous
   to tunnels.  SVR uses BFD for reachability, quality measurement, peer
   authentication, and key management.

6.1.  SVR Peering and BFD

   It is RECOMMENDED that every configured or discovered Peer Pathway
   run a UDP BFD session for liveness and quality measurement.

   BFD timers per pathway are administratively determined.  Because BFD
   ([RFC5880]) does not natively support certificates or public-key
   exchange, SVR carries this information in BFD Metadata appended to
   BFD control messages.  BFD Metadata is used to:

   *  discover the Peer Received IP address;

   *  detect NATs on a Peer Pathway;

   *  detect changes to a router's Peer Received IP address;

   *  determine pathway MTU;

   *  measure path quality during idle periods (active-flow measurement
      uses Path Metrics, Section 10.3.7);

   *  detect failover to a redundant link;

   *  authenticate peers via certificate exchange; and

   *  derive a Peer Key for SVR Metadata Key encryption.

   BFD Metadata is appended after the BFD control message; the IP, UDP,
   and BFD length fields MUST be adjusted accordingly.

   BFD Metadata Location:














Menon, et al.            Expires 9 November 2026               [Page 51]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         BFD Control Packet with BFD Metadata

       +-----------+--------+---------+----------+
       | IP Header | UDP    | BFD     | protobuf |
       |           | Header | Control | BFD      |
       |           |        | Packet  | Metadata |
       +-----------+--------+---------+----------+
                            |                    |
                            |<== BFD Pkt Len  ==>|



                                 Figure 30

   All messages are BFD Control packets.  "MeasureData" messages behave
   like BFD Echo packets and require Required Min Echo RX Interval
   ([RFC5880]) to be greater than zero.

   BFD Metadata is encoded in protobuf as follows:

   BFD Metadata Protobuf Definition:



     syntax = "proto2";
     package pb.bfd;
     import "ip.proto";

     message SessionData {
         required ip.Tuple original_ipTuple = 1;
         required ip.Tuple received_ipTuple = 2;
         optional string peername           = 3;
         optional string routername         = 4;
         optional string routerID           = 5;
     }

     message MeasureData {
         message Request {
             required uint32 transId = 1;
         }
         message Response {
             required uint32 request_transId  = 1;
             required uint32 response_transId = 2;
         }
         oneof type {
             Request  request  = 1;
             Response response = 2;
         }



Menon, et al.            Expires 9 November 2026               [Page 52]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         optional bool mtu_discovery = 3;
     }

     message NodeInfo {
         required uint32 id               = 1;
         required uint64 create_timestamp = 2;
         optional uint64 time_value       = 3;
         optional string nonce            = 4;
         optional string public_key       = 5;
         optional uint32 salt             = 6;
     }

     message Encrypted {
       optional NodeInfo node_info          = 1;
       optional string   metadata_key       = 2;
       optional uint32   metadata_key_index = 3;
       optional string   hmac_key           = 4;
     }

     message Metadata {
         optional SessionData sessionData = 1;
         optional MeasureData measure     = 2;
         optional NodeInfo    nodeInfo    = 3;
         optional Encrypted   encrypted   = 4;
     }



                                 Figure 31

6.1.1.  Discovering the Peer's Received IP Address

   SessionData carries the source address a remote peer observes for
   this router on a Peer Pathway.  This is required for pathway
   establishment because configuration references router IDs rather than
   dynamic addresses; remote peers maintain a local resolution table
   (e.g., /etc/hosts) keyed by the configured hostname.  This step can
   be combined with NAT detection (below).

   Determination of Peer Received Address:











Menon, et al.            Expires 9 November 2026               [Page 53]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


        Router A                Router B                 Local
       [Addr A -> Addr B]                                 DNS
           |                       |                       |
           |- BFD ---------------->|                       |
           | original_ipTuple=A    |                       |
           | hostname="Router A"   |                       |
           |                       |- DNS Update---------->|
           |                       | Router A: Address A   |
           |                       |                       |
           |                       |                       |

       Router B has hostname lookup for Router A



                                 Figure 32

6.1.2.  NAT Detection

   SessionData also detects NATs on a pathway, typically during initial
   peer establishment (and often combined with certificate exchange).
   Like STUN, the originating interface address is placed in
   SessionData.original_ipTuple; on receipt, a router stores the
   observed source address from the IP header in
   SessionData.received_ipTuple.  Comparing the wire address against the
   peer's claimed original_ipTuple reveals any intervening NAT.  The
   peername field MAY also be set.

   BFD NAT Detection on Pathway:






















Menon, et al.            Expires 9 November 2026               [Page 54]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


        Router A                  NAT                  Router B
        Addr A                   Addr N                 Addr B
           |                       |                       |
           |- BFD ---------------->|                       |
           | original_ipTuple=A    |                       |
           |                       |                       |
           |                       |- BFD ---------------->|
           |                       | original_ipTuple=N    |
           |                       |                       |
           |                       |                       |
           |                       |
           |                       |               NAT Detected
           |                       |               Router B gets N
           |                       |               address on the wire
           |                       |               and it doesn't match
           |                       |               original_ipTuple
           |                       |
           |                       |                       |
           |                       |                       |
           |                       |<---------------- BFD -|
           |                       |    original_ipTuple=B |
           |                       |    received_ipTuple=N |
           |<---------------- BFD -|                       |
           |    original_ipTuple=B |                       |
           |    received_ipTuple=N |                       |
           |                       |                       |

       No NAT detected
       Router A gets B's address
       on the wire which matches
       the original_ipTuple



                                 Figure 33

   When NAT is detected, the NAT-side address MUST be associated with
   the pathway to the far peer.  Sessions traversing such a pathway may
   require NAT keep-alive processing (Section 7.3).

6.1.3.  Detecting Router Address Changes

   Branch routers commonly receive their addresses dynamically (DHCP,
   LTE, PPPoE) and the address may change unexpectedly (e.g., lease
   expiry or reconnection).  Without intervention, peers using the old
   address would lose connectivity.  SessionData BFD Metadata makes
   learning the new address and recovering connectivity fast.




Menon, et al.            Expires 9 November 2026               [Page 55]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   BFD Detection on Router Address Change:



        Router A               DHCP                Router B
       [Addr A -> Server  <- Addr B]
           |                     |                     |
           |- BFD ------------------------------------>|
           | original_ipTuple=A  |                     |
           | received_ipTuple="" |                     |
           |                     |                     |
           |<------------------------------------ BFD -|
           |                     |  original_ipTuple=B |
           |                     |  received_ipTuple=A |
           |- BFD ------------------------------------>|
           | original_ipTuple=A  |                     |
           | received_ipTuple=B  |                     |

           Both routers have learned each other's IP Address
           and have determined there are no NATs between them

           |- DHCP Lease Exp --->|                     |
           |<---- New Address C -|                     |
           |                     |                     |
           |- BFD ------------------------------------>|
           | original_ipTuple=C  |                     |
           | received_ipTuple=B  |                     |
           |<------------------------------------ BFD -|
           |                     |  original_ipTuple=B |
           |                     |  received_ipTuple=C |

           Both routers have the correct IP Address and
           have determined there are no NATs between them



                                 Figure 34

6.1.4.  MTU Discovery

   Knowing the pathway MTU lets routers fragment when necessary.  After
   a pathway is established, BFD MeasureData packets of increasing size
   probe for the limit; the IP, UDP, and BFD length fields are adjusted
   to enlarge the BFD packet.  A peer that receives a fragmented
   MeasureData request with mtu_discovery=TRUE simply does not respond,
   signaling that the size exceeds the path MTU.

   Because networks change, MTU SHOULD be remeasured periodically.



Menon, et al.            Expires 9 November 2026               [Page 56]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   BFD MeasureData for Determining Pathway MTU:



        Router A                                          Router B
       [Addr A -> <-Addr B]
            |                                                 |
            |-BFD MeasureData (id=1, size 1200)-------------->|
            |-BFD MeasureData (id=2, size 1250)-------------->|
            |-BFD MeasureData (id=3, size 1300)-------------->|
            |-BFD MeasureData (id=4, size 1350)-------------->|
            |-BFD MeasureData (id=5, size 1400)-------------->|
            |-BFD MeasureData (id=6, size 1450)-------------->|
            |-BFD MeasureData (id=7, size 1500)-{fragmented}->|
            |                                                 |
            |<----(req_id=1, resp_id=1)-------BFD MeasureData-|
            |<----(req_id=2, resp_id=2)-------BFD MeasureData-|
            |<----(req_id=3, resp_id=3)-------BFD MeasureData-|
            |<----(req_id=4, resp_id=4)-------BFD MeasureData-|
            |<----(req_id=5, resp_id=5)-------BFD MeasureData-|
            |<----(req_id=6, resp_id=6)-------BFD MeasureData-|

            MTU Size = 1450



                                 Figure 35

6.1.5.  Path-Quality Measurement

   Once a pathway is operational, BFD MeasureData packets are used to
   measure latency, jitter, and loss.  Either side MAY measure; burst
   size and frequency are configuration.  Hub routers with many pathways
   often rely on spoke-side measurements rather than measuring
   themselves.

   BFD-based measurement is useful only when a pathway is idle.  For
   pathways carrying live sessions, SVR Path Metrics are used
   (Section 10.3.7).

   The receiver responds to each request by echoing it with its own
   transaction ID.  Each request and each response carry a transaction
   ID, eliminating any ambiguity between requests and responses.

   BFD MeasureData for Measuring Pathway Quality:






Menon, et al.            Expires 9 November 2026               [Page 57]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


        Router A                                      Router B
       [Addr A -> <-Addr B]
            |                                              |
            |-BFD MeasureData (req_id=1)------------------>|
            |-BFD MeasureData (req_id=2)------------------>|
            |-BFD MeasureData (req_id=3)------------------>|
                    .......
            |-BFD MeasureData (req_id=n)------------------>|
            |                                              |
            |<----(req_id=1, resp_id=1)----BFD MeasureData-|
            |<----(req_id=3, resp_id=2)----BFD MeasureData-|
            |<----(req_id=1, resp_id=3)----BFD MeasureData-|
                     ......
            |<----(req_id=N, resp_id=N-1)--BFD MeasureData-|

         Latency = Sum of RTT(pkt 1-n)/(2*n)
         Jitter = Std Dev RTT(pkt 1-n)
         Packet Loss = 1-((Pcks_Sent - Pcks_recv)/Pkts_Sent)



                                 Figure 36

   The sender derives latency from the round-trip times of matching
   request/response IDs; missing responses count as packet loss; the
   distribution of RTTs gives jitter; MoS scores follow from latency,
   loss, and jitter together.  Each direction is measured independently
   because network behavior may be asymmetric.

6.1.6.  Failover Detection

   BFD NodeInfo carries a node ID (cluster member instance) and a peer
   start timestamp.  Changes to either signal cluster failover or peer-
   side restart, allowing remote peers to react to redundancy events on
   the far side of a pathway.  Inclusion of this information is
   OPTIONAL.

6.1.7.  Peer Authentication

   A router lacking a valid signed certificate MUST obtain one from a
   CA.  The router generates an elliptic-curve key pair ([RFC8422]) --
   elliptic curves are used to keep the X.509 certificate small -- and
   submits an X.509 CSR with the router's UUID as the Common Name.  The
   CA returns an ECDSA-signed certificate.  Detailed enrollment
   procedures are out of scope but SHOULD follow [RFC4210].
   Certificates and public keys are stored locally in PEM format
   ([RFC7468]).




Menon, et al.            Expires 9 November 2026               [Page 58]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Router Authentication:



                              Router A
                            Certificate
             Router A        Authority
                 |                |
          +------+------+         |
          |Cert Missing,|         |
          | Invalid     |         |
          | or Expiring |         |
          +-------------+         |
                 |                |
           +-----+------+         |
           |   Create   |         |
           | Curve-P256 |         |
           |  Pub/Priv  |         |
           |  Key Pair  |         |
           +------------+         |
                 |                |
           +-----+------+         |
           |   Create   |         |
           | X.509 Cert |         |
           | CN=RouterA |         |
           +------------+         |
                 |                |
                 +------CSR------>|
                                  |
                 |<-X.509 Signed--+



                                 Figure 37

   The certificate is persisted on the router in PEM format.  The
   associated private key SHOULD be created and stored in secure non-
   volatile storage such as a TPM.

   During pathway establishment, peers authenticate using their UUIDs
   and public keys, then derive a symmetric Peer Key from their X.509
   key material.  UUIDs are used (rather than IP addresses) because
   router addresses commonly change (e.g., DHCP lease expiry on branch
   routers).

   The diagram below shows two routers with two pathways each exchanging
   X.509 certificates in BFD NodeInfo public_key fields.  Certificates
   are exchanged on every pathway but validated only once per peer.



Menon, et al.            Expires 9 November 2026               [Page 59]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Router Authentication:



              Router A     Router A     Router B     Router B
              Peerpath 1   Peerpath 2   Peerpath 1   Peerpath 2
                  |           |            |            |
          =============ALL PEER PATHS ARE DISCONNECTED==========
                  |           |            |            |
                  |--BFD w/X.509 Cert----->|            |
                  |           |--BFD w/X.509 Cert------>|
                  |           |            |            |
                 ....Delay between retransmissions .......
                  |           |            |            |
                  |--BFD w/X.509 Cert----->|            |
                  |           |         Router A        |
                  |           |        Validated        |
                  |           |            |            |
                  |           |--BFD w/X.509 Cert------>|
                  |           |            |            |
                  |<----BFD w/X.509 Cert---|            |
               Router B       |            |            |
              Validated       |            |            |
                  |           |<-----BFD w/X.509 Cert---|
                  |           |            |            |
         =============ALL PEER PATHS ARE OPERATIONAL==========
                  |           |            |            |
                 ....Delay between retransmissions .......
                  |           |            |            |
                  |----BFD---------------->|            |
                  |           |-------BFD-------------->|
                  |<-------------BFD-------|            |
                  |           |<-------------BFD--------|



                                 Figure 38

   A received certificate MUST be validated:

   *  dates are within validity;

   *  CA signature verifies;

   *  if a CRL is available, the certificate is not revoked; and

   *  the router name appears in the local configuration (administrative
      revocation is the primary control).



Menon, et al.            Expires 9 November 2026               [Page 60]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Validation runs once per peer; subsequent receipts of the same
   certificate on other pathways MAY use a cached result.  After
   validation, the receiver extracts and stores the peer's public key
   for use in Peer Key/rekey authentication.

   A router SHOULD renew its certificate using the same procedure before
   expiry.

6.1.8.  Peer Key and Rekey

   A single Peer Key is used across all pathways between two router
   peers and remains valid until replaced.  The key persists across
   network outages.  If the key is lost or fails, a new key MUST be
   established before encrypted BFD traffic can resume.

   To establish or replace a key, the initiator generates a salt and
   sends it in BFD NodeInfo; the peer responds with its own salt in BFD
   NodeInfo.  With both salts, each side runs Concat KDF to derive a
   symmetric Peer Key.

   Concat KDF ([NIST_SP_800-56A]) uses the routers' authenticated
   certificate private keys, providing man-in-the-middle resistance.

   OpenSSL provides ConcatKDF() with the following parameters:

   ConcatKDF Function (Part of OpenSSL):



           Peer Key = ConcatKDF(SharedSecret,
                                AlgorithmID,
                                PartyUInfo,
                                PartyVInfo,
                                SuppPubInfo,
                                SuppPrivInfo,
                                KeyDataLen)

           Here's what each parameter represents:

           SharedSecret: The result of an ECDH calculation with the peer
           AlgorithmID: "ECDH"
           PartyUInfo: UUID of the Router
           PartyVInfo: UUID of the Peer Router
           SuppPubInfo: Initiator Salt Concatenated with Responder Salt
           SuppPrivInfo: ""
           KeyDataLen: 256





Menon, et al.            Expires 9 November 2026               [Page 61]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   SuppPubInfo is the initiator salt concatenated with the responder
   salt; SharedSecret is the result of an ECDH exchange
   ([ECDH_Key_Exchange]).

   After a brief guard period (1-2 s) to allow both sides to complete
   their computation, the Peer Key is active across all pathways between
   the two peers and replaces any prior key.

   The key MAY be used immediately to encrypt BFD Metadata.

   Peer Key-Rekeying:








































Menon, et al.            Expires 9 November 2026               [Page 62]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


              Router A     Router A     Router B     Router B
              Peerpath 1   Peerpath 2   Peerpath 1   Peerpath 2
                  |           |            |            |
               .......NO Current Peer Key Exists............
                  |           |            |            |
               Gen Salt       |            |            |
                  |           |            |            |
                  |--BFD Nodeinfo Req----->|            |
                  |           |            |            |
                  |           |        Gen Salt         |
                  |           |            |            |
                  |<----BFD Nodeinfo Req---|            |
                  |           |            |            |
                 Key          |           Key           |
               Computed       |         Computed        |
                  |           |            |            |
                ........Transition Guard Time..............
                  |           |            |            |
                ......... 1st Peer Key Exists..............
                  |           |            |            |
                ...........At Rekeying Interval............
                  |           |            |            |
                  |        Gen Salt        |            |
                  |           |            |            |
                  |           |--BFD NodeinfoReq------->|
                  |           |            |            |
                  |           |            |         Gen Salt
                  |           |            |            |
                  |           |<---BFD Node Info Req----|
                  |           |            |            |
                 Key          |           Key           |
               Computed       |         Computed        |
                  |           |            |            |
                ..........Transition Guard Time.............
                  |           |            |            |
                ........... 2nd Peer Key Exists.............



                                 Figure 39

   The Peer Key is symmetric and is used to encrypt the SVR Metadata Key
   exchange.  Concat KDF (a form of ECDH-ES) yields a symmetric key only
   if there is no man-in-the-middle; if peers cannot decrypt each
   other's messages, an MITM is likely and the affected pathway SHOULD
   be removed from service.





Menon, et al.            Expires 9 November 2026               [Page 63]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   If a BFD NodeInfo elicits no response, the sender retries
   periodically; after an extended interval (e.g., 1 hour) with no
   response, the pathway MAY be declared invalid and removed from
   service per administrative timers.

6.1.9.  SVR Metadata Key and Rekey

   The SVR Metadata security association is not pathway-specific:
   multiple pathways may share an interface or source address (e.g.,
   over the public Internet), so peer identity can only be established
   by decrypting the metadata.  Each SVR router MUST therefore be able
   to decrypt SVR Metadata arriving on any interface.

   SVR Metadata is encrypted for the chosen next-hop SVR router; no
   other router should be able to decrypt it.  Senders MUST select the
   key associated with the chosen next-hop peer.

   Keys are generated locally per the security policy using a FIPS
   140-3-approved DRBG (NIST SP 800-90B for entropy is RECOMMENDED; see
   [NIST_SP_800-90B]).  OpenSSL's RAND_bytes() is suitable for producing
   a 256-bit key.

   The key and its index are distributed to all known peers in an
   Encrypted BFD NodeInfo message.  The 256-bit SVR Metadata Key is
   encrypted with the current Peer Key, producing a 32-octet ciphertext
   plus a 16-octet IV (48 octets total).  The key index is incremented
   on each rekey.  Encryption follows the SVR Metadata encryption
   procedure (Section 4.7.1.8) but uses the Peer Key. SVR Metadata keys
   are asymmetric: forward metadata is encrypted with the destination
   router's key, reverse metadata with the originating router's key.

   SVR Metadata Key/Rekeying:



















Menon, et al.            Expires 9 November 2026               [Page 64]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


            Peer A       Peer B       Peer C       Peer D
               |            |            |            |
            ...NO Current SVR Metadata Key Exists For A....
               |            |            |            |
            Gen Key         |            |            |
            Inc Indx        |            |            |
               |            |            |            |
               |-BFD w/key->|            |            |
               |<-BFD w/key-|            |            |
               |                         |            |
               |--------BFD w/key------->|            |
               |<-------BFD w/key--------|            |
               |                                      |
               |----------------BFD w/key------------>|
               |<---------------BFD w/key-------------|
               |            |            |            |
            ..........A updates SVR Metadata Key .........
               |            |            |            |
          Gen New Key       |            |            |
            Inc Indx        |            |            |
               |            |            |            |
               |-BFD w/key->|            |            |
               |<-BFD w/key-|            |            |
               |                         |            |
               |--------BFD w/key------->|            |
               |<-------BFD w/key--------|            |
               |                                      |
               |----------------BFD w/key------------>|
               |<---------------BFD w/key-------------|



                                 Figure 40

   The diagram shows Peer A distributing its key/index to Peers B, C,
   and D, then later rekeying.  Each peer responds with its own current
   key/index, providing a handshake; this is also how a restarting
   router quickly acquires every key it needs.  A router that needs to
   send SVR Metadata to a peer for which it lacks a key MAY use this
   procedure to obtain it.  Whenever a peer rekeys, it MUST update all
   of its peers.  Stored peer state pairs each shared key with its
   metadata_key_index; the Security ID field in incoming SVR Metadata
   identifies which key to use for decryption (Section 10.3.2).








Menon, et al.            Expires 9 November 2026               [Page 65]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


6.1.10.  Certificate Revocation and Replacement

   A new certificate loaded onto the router triggers re-execution of the
   peer authentication procedure (Section 6.1.7).  The mechanism for
   loading the certificate is out of scope.

   If a system is compromised, its certificate SHOULD be revoked.  The
   router's management platform SHOULD periodically check the CRL, or
   use OCSP to validate certificates directly.  On revocation, the
   router consults configured policy to choose its behavior.

   A policy SHOULD govern behavior on certificate expiry or revocation.
   The default SHOULD be fail-soft (signal that action is required).  A
   fail-hard configuration MUST tear down all peering relationships,
   removing the router from SVR participation.

7.  Additional SVR Metadata Use Cases

   The following examples illustrate additional uses of SVR Metadata.
   They are not exhaustive.

7.1.  Moving a Session

   Any SVR router MAY move an existing session onto a different Peer
   Pathway by re-emitting the session-establishment metadata of
   Section 4.7.1.7 on the new pathway while preserving the Session UUID.
   It simultaneously updates fast-path forwarding for the new Waypoints/
   ports; everything else about the session is unchanged.  Both
   endpoints MUST then redo NAT detection on the new pathway and update
   wire addresses/ports as needed.

   Old and new fast-path entries are kept for ~5 seconds to avoid
   dropping in-flight packets, after which the old state is removed.

   Ladder Diagram for Existing Session Reroute with SVR Metadata:
















Menon, et al.            Expires 9 November 2026               [Page 66]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


                      RTR-A      RTR-B      RTR-C      RTR-D
           Client . . . . . . . . . . . . . . . . . . . . . . . . Server
             |          |          |          |          |          |
             |--PUSH--->|          |          |          |          |
             |          |--PUSH-------------->|          |          |
             |          |          |          |--PUSH--->|          |
             |          |          |          |          |--PUSH--->|
             |          |          |          |          |<---ACK---|
             |          |          |          |<---ACK---|          |
             |          |<--------------ACK---|          |          |
             |<---ACK---|          |          |          |          |
             |          |          |          |          |          |
             ......................RTR-C Fails.......................
             |--PUSH--->|          |          |          |          |
             |          |--PUSH--->|          |          |          |
             |          |  [MD1]   |          |          |          |
             |          |          |--PUSH[MD2]--------->|          |
             |          |          |          |          |--PUSH--->|
             |          |          |          |          |<--ACK----|
             |          |          |<-----ACK[RMD2]------|          |
             |          |<--ACK----|          |          |          |
             |<--ACK----|  [RMD1]  |          |          |          |
             |          |          |          |          |          |
             |<==== Session Packets Flow without SVR Metadata =====>|



                                 Figure 41

   When Router C fails, Router B inserts MD1/MD2 in the next packet in
   either direction; RMD1/RMD2 confirm the move.  For TCP this can be a
   PUSH (shown) or an ACK.  The technique installs SVR session state on
   Router B even though it had no prior involvement in the session, and
   can equally be used to migrate a session between transports (e.g.,
   MPLS to LTE).  A move can be initiated by any router at any time.

   Ladder Diagram for Session Reroute Between Peers with SVR Metadata:














Menon, et al.            Expires 9 November 2026               [Page 67]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


                    +-------+              +--------+
                    |       +-----MPLS-----+        |
            Client--| Rtr-A |              | Rtr-B  +----Server
                    |       +------LTE-----+        |
                    +-------+              +--------+

           Client . . . . . . . . . . . . . . . . . . . . . . Server
             |                                                   |
             |         RouterA                    RouterB        |
             |            |                          |           |
             |---PUSH---->|                          |           |
             |            |---PUSH over MPLS-------->|           |
             |            |                          |---PUSH--->|
             ................MPLS has Poor Quality ................
             |            |                          |           |
             |---PUSH---->|                          |           |
             |            |---PUSH over LTE[MD]----->|           |
             |            |                          |---PUSH--->|
             |            |                          |<---ACK----|
             |            |<---ACK over LTE[RMD]-----|           |
             |<---ACK-----|                          |           |
             |            |                          |           |
             |<=== Session Packets Flow without SVR Metadata ===>|



                                 Figure 42

   The diagram shows an active TCP session migrated from MPLS to LTE by
   inserting metadata on any in-flight packet; reverse meta data on the
   reverse direction confirms the move.

7.2.  Moving Idle or Unidirectional Sessions

   Idle sessions and one-way flows (TCP pushes with bare ACKs) may not
   offer a packet into which metadata can be piggybacked.

   If, after a move, no packets are seen for 1 second on an active
   session, the SVR router MUST emit an SVR Control Message to its peer.

   Ladder Diagram for One Way Media Move with SVR Metadata:










Menon, et al.            Expires 9 November 2026               [Page 68]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


                    +-------+              +--------+
                    |       +-----MPLS-----+        |
            Client--| Rtr-A |              | Rtr-B  +----Server
                    |       +------LTE-----+        |
                    +-------+              +--------+

           Client . . . . . . . . . . . . . . . . . . . . . . Server
             |                                                   |
             |         RouterA                    RouterB        |
             |            |                          |           |
             |            |                          |<---PUSH---|
             |            |<---PUSH over MPLS------->|           |
             |<---PUSH----|                          |           |
             |----ACK---->|                          |           |
             |            |------ACK over MPLS------>|           |
             |            |                          |---ACK---->|
             |            X RouterA MPLS FAILS       |           |
             |            X           RouterB MPLS OK|           |
             |            X                          |           |
             ..............RouterA Moves Session to LTE..........
             |            |                          |<---PUSH---|
             |            X<---PUSH over MPLS------->|           |
             |            |                          |<---PUSH---|
             |            X<---PUSH over MPLS------->|           |
             |            |                          |           |
             .......NO Packets at Router A for Moved Session......
             |            |                          |           |
             |            |-----[MD over LTE]------->|           |
             ...............RouterB Moves Session to LTE..........
             |            |                          |<---PUSH---|
             |            |<--PUSH over LTE [RMD]--->|           |
             |<---PUSH----|                          |           |
             |----ACK---->|                          |           |
             |            |------ACK over LTE------->|           |
             |            |                          |---ACK---->|
             |<======== Session Packets Continue flowing =======>|



                                 Figure 43











Menon, et al.            Expires 9 November 2026               [Page 69]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   The SVR Control Message uses the new Waypoint addresses and carries
   the standard first-packet TLVs plus an SVR Control Message TLV with
   drop reason "FLOW MOVED" and a Remaining Session Time TLV (so that
   intermediate routers age the session out roughly together).  It is
   sent once per second for up to 5 seconds, or until reverse metadata
   arrives; if no reverse metadata arrives within 5 seconds, the session
   is torn down.  For an idle flow the reverse metadata is itself a
   generated SVR Control Message:

   Ladder Diagram for Quiescent Moved Session with SVR Metadata:



                    +-------+              +--------+
                    |       +-----MPLS-----+        |
            Client--| Rtr-A |              | Rtr-B  +----Server
                    |       +------LTE-----+        |
                    +-------+              +--------+

           Client . . . . . . . . . . . . . . . . . . . . . . Server
             |                                                   |
             |         RouterA                    RouterB        |
             |            |                          |           |
             |<========== Quiescent Session Established ========>|
             |            |                          |           |
             |            X RouterA MPLS FAILS       |           |
             |            X           RouterB MPLS OK|           |
             |            X                          |           |
             ..............RouterA Moves Session to LTE..........
             |            |                          |           |
             |            |-----[MD over LTE]------->|           |
             |            |                          |           |
             ...............RouterB Moves Session to LTE..........
             |            |                          |           |
             |            |<-----[RMD over LTE]----->|           |
             |            |                          |           |
             |<=========== Quiescent Session Continues =========>|



                                 Figure 44

7.3.  NAT Keep-Alive

   When a Peer Pathway has one or more NATs (Section 3.5), each side
   MUST refresh the NAT bindings for each active session by sending a
   keep-alive packet that matches the idle session's L4 header and
   carries SVR Metadata with TLV 24 and drop reason "Keep Alive".



Menon, et al.            Expires 9 November 2026               [Page 70]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Ladder Diagram for NAT Keep Alive with SVR Metadata:



                      RTR-A       NAT       RTR-B
           Client . . . . . . . . . . . . . . . . . . Server
             |          |          |          |          |
             ...................Existing SVR Session......
             |--PUSH--->|          |          |          |
             |          |--PUSH--->|          |          |
             |          |          |---PUSH-->|          |
             |          |          |          |--PUSH--->|
             |          |          |          |<---ACK---|
             |          |          |<---ACK---|          |
             |          |<--PUSH---|          |          |
             |<--PUSH---|          |          |          |
         .........NO PACKETS EITHER DIRECTION FOR 20 SECS.......
             |          |          |          |          |
             |          |--[MD1]-->|          |          |
             |          |          |--[MD1]-->|          |
             |          |          |          |          |
         .........NO PACKETS EITHER DIRECTION FOR 20 SECS.......
             |          |          |          |          |
             |          |--[MD1]-->|          |          |
             |          |          |--[MD1]-->|          |
             |          |          |          |          |



                                 Figure 45

   A keep-alive MUST contain:

   *  Header: SVR Control Message: see Section 10.3.6.

   *  Header: Security ID: see Section 10.3.2.

   *  Payload: Session UUID: see Section 10.4.5.

   *  Payload: Source Router Name: see Section 10.4.10.

   *  Payload: Peer Pathway ID: see Section 10.4.12.

   This minimal set lets the receiver verify the session (by UUID) and
   update any NAT-state changes.






Menon, et al.            Expires 9 November 2026               [Page 71]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


7.4.  Adaptive Encryption

   Unlike a tunnel, each SVR session is independent, so SVR can encrypt
   only those sessions that are not already encrypted by the
   application.  With adaptive encryption every session begins
   unencrypted; by inspecting the first four packets, the router
   determines whether application-layer encryption is in use (e.g., a
   TLS Client Hello).  If yes, no SVR encryption is applied; otherwise
   SVR encryption is enabled bidirectionally.

   Ladder Diagram of Adaptive Encryption with Client Hello:



           Client . . . . . . . . . . . . . . . . . . Server
             |                                           |
             |         RouterA            RouterB        |
             |---SYN----->|                  |           |
             |            |----SYN[MD1]----->|           |
             |            |                  |---SYN---->|
             |            |                  |<--SYN/ACK-|
             |            |<----SYN/ACK------|           |
             |<--SYN/ACK--|    [RMD1]        |           |
             |---ACK----->|                  |           |
             |            |------ACK-------->|           |
             |            |                  |---ACK---->|
             |--Client--->|                  |           |
             |  Hello     |<== ENCRYPTION===>|           |
             |            |   Not Required   |           |
             |            |                  |           |
             |            |-----Client------>|           |
             |            |     Hello        |--Client-->|
             |            |                  |           |



                                 Figure 46

   If the fourth packet does not indicate transport-layer encryption,
   the ingress and egress SVR routers MUST encrypt and decrypt the
   session bidirectionally, ensuring all data between SVR routers is
   encrypted.

   Ladder Diagram of Adaptive Encryption with data:







Menon, et al.            Expires 9 November 2026               [Page 72]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


           Client . . . . . . . .  . . . . . . . . Server
             |                                       |
             |         RouterA        RouterB        |
             |---SYN----->|              |           |
             |            |--SYN[MD1]--->|           |
             |            |              |---SYN---->|
             |            |              |<--SYN/ACK-|
             |            |<--SYN/ACK----|           |
             |<--SYN/ACK--|    [RMD1]    |           |
             |---ACK----->|              |           |
             |            |----ACK------>|           |
             |            |              |---ACK---->|
             |---Data---->|              |           |
             |            |<==ENCRYPT===>|           |
             |            |  Required    |           |
             |            |              |           |
             |            |--Encrypted-->|           |
             |            |   Data       |---Data--->|



                                 Figure 47

   Adaptive encryption is configured via Security Policy.  Policies are
   bound to Services, so different Services may mandate, allow, or
   disallow encryption.

7.5.  IPv4 Packet Fragmentation

   A fragmented packet arriving at an SVR router MUST be fully
   reassembled before processing, since HMAC and routing apply to the
   whole packet.  The router then re-fragments as needed onto the Peer
   Pathway, copying the Peer Pathway's L4 header onto every fragment and
   inserting SVR Metadata identifying the fragment to the downstream
   peer.  The Time-Based HMAC covers the entire packet and is appended
   to the last fragment.

   Ladder Diagram Fragmented Packets:













Menon, et al.            Expires 9 November 2026               [Page 73]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


        Client . . . . . . . . . . . . . . . . . . . . . . Server
          |                                                   |
          |         RouterA                    RouterB        |
          |            |                          |           |
          |--Frag 1--->|                          |           |
          |--Frag 3--->|                          |           |
          |--Frag 2--->|                          |           |
          |        +---+----+                     |           |
          |        |Assemble|                     |           |
          |        +---+----+                     |           |
          |            |----Frag 1[L4/MD]-------->|           |
          |            |                          |           |
          |            |----Frag 2[L4/MD]-------->|           |
          |            |                          |           |
          |            |----Frag 3[L4/MD]-------->|           |
          |            |                     +--------+       |
          |            |                     |Assemble|       |
          |            |                     +--------+       |
          |            |                          |--Frag 1-->|
          |            |                          |--Frag 2-->|
          |            |                          |--Frag 3-->|



                                 Figure 48

   Router A reassembles, recording the original ID and largest fragment
   size.  It then transmits the reassembled jumbo packet, re-fragmenting
   onto the chosen Peer Pathway with the pathway's L4 header on each
   fragment.  The fragment size is min(path-MTU, largest-fragment-seen).
   The SVR Metadata header and header TLVs are not encrypted; the per-
   fragment layout is:

   SVR Packet Layout

















Menon, et al.            Expires 9 November 2026               [Page 74]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


        Fragment 1
       +------+------+----------+----------+----------+
       |      |      |  SVR     |          |          |
       | Peer | Peer | Metadata | Header   | First    |
       | IP   | L4   | Header   | TLV-1,16 | Fragment |
       | HDR  | HDR  | 12 Bytes | 22 Bytes |          |
       +------+------+----------+----------+----------+

        Fragment 2
       +------+------+----------+----------+----------+
       |      |      |  SVR     |          |          |
       | Peer | Peer | Metadata | Header   | Second   |
       | IP   | L4   | Header   | TLV-1    | Fragment |
       | HDR  | HDR  | 12 Bytes | 14 Bytes |          |
       +------+------+----------+----------+----------+

        Fragment 3
       +------+------+----------+----------+----------+-----------+
       |      |      |  SVR     |          |          |           |
       | Peer | Peer | Metadata | Header   | Third    | PKT       |
       | IP   | L4   | Header   | TLV-1    | Fragment | HMAC      |
       | HDR  | HDR  | 12 Bytes | 14 Bytes |          | SIGNATURE |
       +------+------+----------+----------+----------+-----------+



                                 Figure 49

   The SVR Metadata Type 1 header gets its own extended ID, allowing the
   number of fragments between Router A and Router B to differ from the
   client/server fragmentation.  Router B re-fragments to its egress MTU
   using the Largest Fragment Seen value carried in the metadata.

   No other SVR Metadata fields are required; session state is keyed by
   the Peer Pathway 5-tuple.  The fragmentation mechanics are otherwise
   standard IP fragmentation.

   If a router itself needs to fragment a packet (e.g., to make room for
   SVR Metadata), it inserts SVR Metadata on the first fragment,
   duplicates the L4 header on the remaining fragments, and inserts SVR
   Metadata on each.  In this case, Largest Fragment Seen and Original
   ID are left blank.

   Ladder Diagram Fragmented Packets:







Menon, et al.            Expires 9 November 2026               [Page 75]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


           Client . . . . . . . . . . . . . . . . . . . . . . Server
             |                                                   |
             |         RouterA                    RouterB        |
             |            |                          |           |
             |--Lg Pkt--->|                          |           |
             |            |--------Frag 1[MD]------->|           |
             |            |                          |           |
             |            |----Frag 2[L4 Hdr|MD]---->|           |
             |            |                          |--Lg Pkt-->|
             |            |                          |           |



                                 Figure 50

7.6.  IPv6 Packet Fragmentation

   IPv6 fragments only at the source, so SVR routers perform no special
   handling.  An oversized packet elicits an ICMPv6 "Packet Too Big"
   from the destination, which the routers forward back along the
   reverse flow.



           Client . . . . . . . . . . . . . . . . . Server
             |                                        |
             |         RouterA        RouterB         |
             |--Lg Pkt--->|              |            |
             |            |----Lg Pkt--->|            |
             |            |              |--Lg Pkt--->|
             |            |              |<--ICMPv6---|
             |            |<--ICMPv6-----|            |
             |<--ICMPv6---|              |            |
             |            |              |            |



                                 Figure 51

7.7.  ICMP and SVR

   ICMP messages fall into two categories.  The first is session-
   associated network errors:

   *  Type 3: Destination Unreachable

   *  Type 11: Time Exceeded




Menon, et al.            Expires 9 November 2026               [Page 76]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   These carry the original IP header plus 8 octets ([RFC0792]) and MUST
   be returned to the session originator.  The router parses the
   embedded IP header to identify the session, then forwards the ICMP
   message back across the SVR network as reverse SVR Metadata, with the
   destination set to the upstream peer's Waypoint.  SVR Metadata Types
   20/21 (Section 10.3.4, Section 10.3.5) carry the original ICMP source
   address hop-by-hop until the ingress router recreates the ICMP
   message with the correct source address.

   SVR Fragment Packet Layout


       +------------+------------+----------------+--------------+
       |            |            |    SVR         |              |
       |  IP HEADER | UDP HEADER | Metadata 20/21 | ICMP Packet  |
       +------------+------------+----------------+--------------+


                                 Figure 52

   ICMP over SVR for Network Failures



       Client . . . . . . . . . . . . . . . . . . . . . . .No Network
         |                                                  Found
         |         Router A                   Router B         |
         |            |                          |             |
         |----PKT---->|                          |             |
         |            |------PKT[MD]------------>|             |
         |            |                          |<---ICMP-----|
         |            |                          |  (Router B) |
         |            |<--UDP[ICMP[RMD]]---------|             |
         |<---ICMP----|                          |             |
         | (Client)   |                          |             |
         |            |                          |             |



                                 Figure 53

   Router B receives the ICMP error, looks up the session, and forwards
   back to Router A's Waypoint; Router A recreates the ICMP message and
   delivers it to the client.

   The second category is session-independent ICMP (e.g., ICMP Echo).
   SVR encapsulates these as UDP and creates a session keyed by the ICMP
   identifier and IP addresses:



Menon, et al.            Expires 9 November 2026               [Page 77]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   *  Type 8: Echo Request (Ping)

   ICMP over SVR for Information



           Client . . . . . . . . . . . . . . . . . . . . . . . Target
             |                                                     |
             |             RouterA             RouterB             |
             |                |                   |                |
             |--ICMP ECHO---->|                   |                |
             |                |---UDP[ICMP ECHO]->|                |
             |                |       [MD1]       |                |
             |                |                   |---ICMP ECHO--->|
             |                |                   |<--ECHO RESP----|
             |                |<--UDP[ECHO RESP]--|                |
             |                |       [RMD1]      |                |
             |<--ECHO RESP----|                   |                |



                                 Figure 54

   The first Echo Request creates a UDP-encapsulated session at Router
   A; MD1/RMD1 establish the bidirectional path.  Subsequent ECHO
   messages reuse the path without further metadata.  Session state MUST
   be aged with an inactivity timer.

   ICMPv6 is handled identically; only header sizes/types differ.

7.8.  State Recovery

   Session state can occasionally be lost.  Most applications recover on
   their own, but long-lived idle sessions (e.g., SIP on idle handsets)
   may need explicit state recovery.

   Every SVR session has at least one router holding full state.
   Recovery techniques include obtaining state from a peer or
   regenerating it from session-establishment metadata.

   The simplest case is loss at the ingress router: a fresh session is
   created using the original parameters; first-packet metadata then
   reaches the egress, which updates state, restoring the bidirectional
   flow.  The first-packet metadata is signed and encrypted, so this
   recovery is secure.

   State Recovering Ingress Router with Active Session




Menon, et al.            Expires 9 November 2026               [Page 78]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         Client . . . . . . . . . . . . . . . . . . . . . . . Server
           |                                                     |
           |        Ingress      Middle        Egress            |
           |          SVR         BOX           SVR              |
           |           |           |             |               |
         <================Existing Bi-Directional Session=========>
           |           |           |             |               |
           |         State         |             |               |
           |         Lost          |             |               |
           |           |           |             |               |
           |---PKT---->|           |             |               |
           |         Create        |             |               |
           |          New          |             |               |
           |        Session        |             |               |
           |           |--PKT[MD]->|             |               |
           |           |           |--PKT[MD]--->|               |
           |           |           |           Update            |
           |           |           |          Existing           |
           |           |           |           Session           |
           |           |           |             |----PKT------->|



                                 Figure 55

   If the ingress loses state while the client is idle (server-side data
   cannot be delivered), the egress checks the client inactivity timer
   (default 5 s) on the next server packet, and if exceeded inserts
   Session Health Check metadata (Section 10.3.8).  The ingress responds
   by generating a UDP packet matching the session's L3/L4 with an SVR
   Control Message (Section 10.3.6) carrying drop reason 6 ("delete
   session").  The egress then clears state, and the next server packet
   carries first-packet SVR Metadata, treated as a new session for state
   restoration.

   State Recovering Ingress Router Client Inactive















Menon, et al.            Expires 9 November 2026               [Page 79]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         Client . . . . . . . . . . . . . . . . . . . . . . Server
           |                                                     |
           |        Ingress        Middle        Egress          |
           |          SVR           BOX           SVR            |
           |           |             |             |             |
           <============== Existing Bi-Directional Session ======>
           |           |             |             |             |
           |         State           |             |             |
           |         Lost            |             |             |
           |           |             |             |<----PKT-----|
           |           |             |             |             |
           |           |             |       Client Inactivity   |
           |           |             |         Timer Exceeded    |
           |           |             |             |             |
           <---<--< SEND SESSION HEALTH CHECK METADATA <---<---<--
           |           |             |             |             |
           |           |             |<---PKT[MD]--|             |
           |           |<--PKT[MD]---|             |             |
           |       No State          |             |             |
           |           |             |             |             |
           >---->--->SEND SVR Control Metadata Drop=6 >--->---->-
           |           |             |             |             |
           |           |-GenPKT[MD]->|             |             |
           |           |             |-GenPKT[MD]->|             |
           |           |             |             |             |
           |           |             |         Clear State       |
           |           |             |             |             |
           |           |             |          Send First       |
           |           |             |       PKT SVR Metadata    |
           |           |             |          Next PKT         |
           |           |             |             |             |
           <--<- ON NEXT PACKET SEND FIRST PACKET METADATA <---<--
           |           |             |             |             |
           |           |             |             |<---PKT------|
           |           |             |<--PKT[MD]---|             |
           |           |<--PKT[MD]---|             |             |
           |           |             |             |             |
           |    New Session State    |             |             |
           |           |             |             |             |
           =======Treat as a new session from this point =========



                                 Figure 56

   If the egress loses state, it pulls state from a peer.  The ingress
   recognizes the recovery condition when it receives a packet for a
   session the server has not responded to within the inactivity timer;



Menon, et al.            Expires 9 November 2026               [Page 80]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   it augments the next packet with Session Health Check metadata
   (Section 10.3.8).  The egress MUST respond with a UDP packet carrying
   an SVR Control Message (Section 10.3.6) using drop reason 2 ("send
   metadata").  The client's next packet will carry full first-packet
   SVR Metadata, restoring egress state.

   State Recovering Egress Router












































Menon, et al.            Expires 9 November 2026               [Page 81]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         Client . . . . . . . . . . . . . . . . . . . . . . Server
           |                                                     |
           |        Ingress        Middle        Egress          |
           |          SVR           BOX           SVR            |
           |           |             |             |             |
           <============ Existing Bi-Directional Session ========>
           |           |             |             |             |
           |           |             |           State           |
           |           |             |            Lost           |
           |           |             |             |             |
           |---PKT---->|             |             |<----PKT-----|
           |           |----PKT----->|             |             |
           |           |             |----PKT----->|             |
           |           |             |             |             |
           |           |             |          Pkts Dropped     |
           |---PKT---->|             |             |             |
           |       Inactivity        |             |             |
           |       Exceeded          |             |             |
           |           |             |             |             |
           >--->---> SEND SESSION HEALTH CHECK METADATA >--->--->|
           |           |             |             |             |
           |           |---PKT[MD]-->|             |             |
           |           |             |--PKT[MD]--->|             |
           |           |             |          No State         |
           |           |             |             |             |
           <----<---- SEND SVR CONTROL MESSAGE TYPE=2 <----<----<-
           |           |             |             |             |
           |           |             |<-GenPKT[MD]-|             |
           |           |<-GenPKT[MD]-|             |             |
           |---PKT---->|             |             |             |
           |           |             |             |             |
           -->---> SEND FIRST PACKET METADATA IN NEXT PACKET --->|
           |           |             |             |             |
           |           |---PKT[MD]-->|             |             |
           |           |             |--PKT[MD]--->|             |
           |           |             |          Session          |
           |           |             |        State Restored     |
           |           |             |             |----PKT----->|
           |           |             |             |             |



                                 Figure 57

   Middleboxes are the most common cause of state loss; they may stop
   forwarding in one or both directions, or silently rewrite ports.





Menon, et al.            Expires 9 November 2026               [Page 82]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Because the location of the loss is unknown, the router includes
   Session Health Check metadata in a packet of the session.  SVR peers
   MUST respond; absence of a response indicates a middlebox or network
   problem.

   Recovery is performed by clearing session state and treating the next
   packet as a first packet (full SVR Metadata exchange per
   Section 4.7.1).  Both ingress and egress detect the matching 5-tuple
   and replace the existing session state.

   State Recovering of Middlebox








































Menon, et al.            Expires 9 November 2026               [Page 83]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


         Client . . . . . . . . . . . . . . . . . . . . . . Server
           |                                                     |
           |        Ingress        Middle        Egress          |
           |          SVR           BOX           SVR            |
           |           |             |             |             |
           <============ Existing Bi-Directional Session =======>|
           |           |             |             |             |
           |           |          State            |             |
           |           |           Lost            |             |
           |           |             |             |             |
           |---PKT---->|             |             |<---PKT------|
           |           |----PKT----->|             |             |
           |           |             |<---PKT------|             |
           |           |          Packets          |             |
           |           |          Dropped          |             |
           |        Inactivty        |             |             |
           |        Exceeded         |             |             |
           |           |             |             |             |
           |---PKT---->|             |             |             |
           |           |             |             |             |
           |           |             |             |             |
           |           |---PKT[MD]-->|             |             |
           |           |             |             |             |
           |      No Response        |             |             |
           |           |             |             |             |
           |      Re Allocate Ports  |             |             |
           |   Update Session State  |             |             |
           |           |             |             |             |
           |---PKT---->|             |             |             |
           |           |             |             |             |
           ---> SEND FIRST PACKET METADATA, KEEP OLD SESSIONID -->
           |           |             |             |             |
           |           |--PKT[MD]--->|             |             |
           |           |             |--PKT[MD]--->|             |
           |           |             |          Update           |
           |           |             |          Session          |
           |           |             |             |----PKT----->|
           |           |             |             |             |



                                 Figure 58









Menon, et al.            Expires 9 November 2026               [Page 84]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


8.  SVR Multicast Support

   This section describes how SVR transports IPv4 and IPv6 multicast
   traffic across an SVR overlay.  SVR's session model, designed for
   unicast TCP/UDP, is extended to multicast by treating each (S,G) flow
   as a long-lived, unidirectional SVR session whose set of egress peers
   is derived from receiver-side group membership.

8.1.  Architectural Model

   SVR multicast is a hybrid distribution model:

   *  Where two or more SVR Peer Pathways share an underlay that
      supports native IP multicast (a common LAN segment, an IP/MPLS
      core with PIM, or an overlay that already provides multicast), the
      ingress SVR router MAY transmit a single replicated copy of the
      packet on a shared multicast Waypoint and rely on the underlay to
      fan out to egress SVR routers.  This is the "native multicast"
      mode.

   *  Where the underlay does not support multicast end-to-end (the
      public IPv4 or IPv6 Internet, most SD-WAN transports, NATed
      paths), the ingress SVR router MUST fall back to ingress
      replication: a separate unicast SVR session is established to each
      egress SVR peer that has at least one interested receiver.

   A single (S,G) flow MAY use a mix of both modes simultaneously (e.g.,
   native multicast on an MPLS pathway and ingress replication over the
   Internet) without coordination beyond what is described below.

   Multicast control-plane interaction with hosts uses standard IGMPv2
   ([RFC2236]), IGMPv3 ([RFC3376]), and MLDv2 ([RFC3810]) at the SVR
   edge only.  SVR does NOT run PIM, MSDP, or any multicast routing
   protocol over Peer Pathways; receiver state is distributed inside the
   SVR control channel as described in Section 8.3.

8.2.  Multicast Terminology

   Multicast Session:  A unidirectional SVR session keyed by (Source IP,
      Group IP, Protocol) for SSM, or (*, Group IP, Protocol) for ASM.
      Identified by a Session UUID like any other SVR session.

   First-Hop SVR Router (FHR):  The SVR router on whose interface the
      multicast source is reachable.  The FHR originates the multicast
      SVR session and inserts SVR Metadata into the first packet seen
      for an (S,G).

   Last-Hop SVR Router (LHR):  An SVR router that has one or more



Menon, et al.            Expires 9 November 2026               [Page 85]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      downstream receivers (learned via IGMP/MLD) for an (S,G) and that
      emits native multicast onto the receiver-facing interface.

   Egress Set:  The set of LHRs (identified by Router Name) currently
      interested in an (S,G).  Maintained by the FHR.

8.3.  Group Membership Distribution

   When an LHR receives an IGMP/MLD Report or Done/Leave message that
   changes its receiver state for an (S,G), it MUST signal the change to
   every potential FHR using an SVR Control Message (Section 10.3.6)
   carrying a Multicast Group Context TLV (Section 10.4.16).

   The set of potential FHRs for a group is determined by routing policy
   (typically, peers that advertise reachability to the source prefix in
   ASM, or to the explicit source in SSM).  Distribution of this policy
   is outside the scope of this document.

   An FHR maintains the Egress Set per (S,G) as the union of all LHRs
   that have signaled non-empty receiver interest and have not
   subsequently signaled withdrawal.  Egress Set entries SHOULD be soft
   state, refreshed at an administratively configured interval (default
   60 seconds, RECOMMENDED upper bound 240 seconds, to align with
   IGMPv3/MLDv2 query intervals).

8.4.  First-Packet Processing for Multicast

   When the FHR receives the first packet of an (S,G) flow whose Egress
   Set is non-empty, it MUST construct forward SVR Metadata identical in
   structure to a unicast first packet (see Section 4.7.1) with the
   following differences:

   *  The Forward Context (Section 10.4.1 or Section 10.4.2) carries the
      original (S,G) addresses and the original L4 ports.  The
      Destination Address in the Forward Context is the multicast group
      address.

   *  A Multicast Egress List TLV (Section 10.4.17) MUST be included,
      enumerating the Router Names of every LHR in the Egress Set.

   *  No Reverse Context is created; multicast SVR sessions are
      unidirectional.  The SVR Metadata handshake described in
      Section 3.4 is replaced by the keep-alive procedure in
      Section 8.6.







Menon, et al.            Expires 9 November 2026               [Page 86]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   *  Port allocation (Section 5.2.3) is performed once per (S,G), not
      per egress peer; the same allocated ports are reused across all
      replicated copies so that a single (Group, port) tuple identifies
      the multicast SVR session on the wire.

   For each entry in the Egress Set, the FHR then chooses a Peer Pathway
   to that LHR using the same selection logic as for unicast
   (Section 4.7.1.4).  If two or more chosen pathways share a common
   multicast-capable Waypoint, the FHR MAY transmit a single copy onto
   that Waypoint with a multicast destination address; this is the
   native-multicast optimization.  Otherwise, the FHR transmits one
   unicast copy per chosen pathway (ingress replication).

8.5.  Egress (LHR) Processing

   An LHR that receives a multicast SVR packet:

   1.  Validates and decrypts SVR Metadata exactly as for unicast
       (Section 5.6).

   2.  Restores the original (S,G) addresses and L4 ports from the
       Forward Context.

   3.  Uses local IGMP/MLD state to determine which receiver-facing
       interfaces have interested receivers for that (S,G), and emits a
       native multicast packet on each such interface.  The TTL/Hop
       Limit MUST be decremented per [RFC1112] / [RFC4604].

   4.  If the LHR has no remaining receivers when the packet arrives, it
       MUST drop the packet and SHOULD send an SVR Control Message with
       reason code "NO_MULTICAST_RECEIVERS" back to the FHR.  On
       receipt, the FHR removes the LHR from the Egress Set.

8.6.  Keep-Alive and Session Lifetime

   Because multicast SVR sessions are unidirectional, the standard
   bidirectional handshake cannot be used to confirm receipt of SVR
   Metadata.  Instead:

   *  The FHR includes SVR Metadata in the first packet of every Egress
      Set refresh interval (default 60 seconds), and on every change to
      the Egress Set.

   *  LHRs MUST treat absence of multicast SVR data for the source-
      active timer (default 210 seconds, configurable, aligned with
      IGMPv3/MLDv2) as session termination and withdraw their Egress Set
      entry.




Menon, et al.            Expires 9 November 2026               [Page 87]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   *  If an LHR has not received a refresh after the source-active timer
      but still has interested receivers, it MUST re-signal its Group
      Context to potential FHRs as described in Section 8.3.

8.7.  Multicast Security Considerations

   All multicast SVR packets MUST be authenticated with the same Time-
   Based HMAC mechanism as unicast SVR (Section 5.5.1).  The Session
   HMAC Key is established from the Peer Key of the FHR-to-LHR Peer
   Pathway being used; when a single replicated copy traverses a native-
   multicast underlay to multiple LHRs, every LHR in the Egress Set MUST
   share a common Metadata Key derived as described in Section 6.1.9,
   and that key MUST NOT be reused outside the Egress Set.

   Payload encryption (Section 7.4) for multicast uses a single Payload
   Key generated by the FHR and distributed to every LHR in the Egress
   Set inside the encrypted portion of the unicast SVR Metadata sent at
   session start (or at rekey).  When native-multicast replication is in
   use, the Payload Key is additionally distributed to all LHRs out-of-
   band over their respective unicast Peer Pathways before it is first
   applied to the shared multicast packet stream.

   LHR removal from the Egress Set MUST trigger a Payload Key rekey if
   payload encryption is in use; otherwise a departing receiver could
   decrypt traffic for which it is no longer authorized.

9.  IPv6 Considerations

   SVR is dual-stack by design.  This section consolidates IPv6-specific
   behavior that applies in addition to, or in place of, the procedures
   described elsewhere for IPv4.  Where an existing section is IP-
   version-agnostic it is referenced; where it is not, the IPv6 behavior
   is stated here.

9.1.  Addressing and Waypoints

   An SVR Waypoint MAY be an IPv6 Global Unicast Address (GUA,
   [RFC4291]) or a Unique Local Address (ULA, [RFC4193]).  Link-local
   addresses (fe80::/10) MUST NOT be used as Waypoints because they are
   not routable beyond a single link and therefore cannot anchor an SVR
   Peer Pathway.  IPv4-mapped IPv6 addresses (::ffff:0:0/96) MUST NOT be
   used as Waypoints; an IPv4 Waypoint is configured as an IPv4 address.









Menon, et al.            Expires 9 November 2026               [Page 88]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   A single SVR router MAY simultaneously expose IPv4 and IPv6 Waypoints
   on the same physical interface; each is treated as an independent
   Peer Pathway.  A given SVR Peer relationship MAY span IPv4-only,
   IPv6-only, and dual-stack pathways; the Peer Pathway selected for a
   session (Section 4.7.1.4) determines the IP version of the
   encapsulating transport, independently of the IP version of the
   original packet.

9.2.  IPv4 / IPv6 Interworking

   Because the original 5-tuple is preserved in the Forward Context TLV
   and reconstructed at the egress SVR router, an SVR session whose
   original packet is IPv4 MAY traverse an IPv6 Peer Pathway, and vice
   versa.  Concretely:

   *  The FHR selects the Forward Context TLV based on the original
      packet's IP version: Section 10.4.1 for IPv4 sources,
      Section 10.4.2 for IPv6 sources.

   *  The transport IP header used between SVR routers is independent
      and is built from the chosen Peer Pathway's Waypoint addresses.

   *  At the egress SVR router, the original packet is reconstructed in
      its original address family.

   This behavior provides a NAT64-like service ([RFC6146]) for SVR-
   managed sessions without requiring a NAT64 gateway in the data plane:
   an IPv4-only client behind an SVR router can reach an IPv6-only
   server behind another SVR router, provided routing policy at the
   egress router resolves the destination Service to an IPv6 address and
   applies destination NAT as in Section 3.8.  Stateful per-flow
   translation as described in [RFC6146] is the RECOMMENDED model for
   SVR egress when interworking address families.

   SVR routers MUST NOT silently translate between IPv4 and IPv6 for
   non-SVR (transit) traffic; address-family interworking is provided
   only for sessions in which the FHR has constructed SVR Metadata.

9.3.  IPv6 Extension Headers

   SVR Metadata is inserted directly after the L4 (TCP or UDP) header
   (Section 5.2.1).  For IPv6 packets, "directly after the L4 header"
   means after any chain of IPv6 extension headers ([RFC8200]) that
   precede the L4 header.

   When building the transport IPv6 header for an SVR-encapsulated
   packet, an SVR router:




Menon, et al.            Expires 9 November 2026               [Page 89]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   *  MUST NOT copy Hop-by-Hop or Destination extension headers from the
      original IPv6 packet onto the SVR transport header.  The original
      extension header chain is preserved as part of the original
      payload but is not visible to the underlay.

   *  MUST NOT insert a Routing extension header on its own initiative.
      If SR-over-v6 ([RFC8986]) policy applies to the chosen Peer
      Pathway, the SR Header is constructed per [RFC8986] and is treated
      as part of the underlay transport.

   *  MUST handle a received Fragment header per Section 7.6; SVR
      Metadata MUST be present only in the first fragment.

9.4.  Hop Limit, Traffic Class, and Flow Label

   The original IPv6 header fields are preserved in SVR Metadata via the
   Forward and Reverse Context TLVs, and on egress are restored to their
   original values.  On the SVR transport header, the following rules
   apply:

   *  *Hop Limit*: SVR routers act as IP routers and MUST decrement the
      original packet's Hop Limit by 1 at the FHR (or by N at an N-hop
      SVR path, one per SVR router that the original packet logically
      traverses).  The transport Hop Limit is independent and set by the
      originating SVR router according to local policy (default 64).

   *  *Traffic Class*: The original Traffic Class (including DSCP) MUST
      be copied to the transport IPv6 header by default, so that DSCP-
      based QoS in the underlay applies.  An administrator MAY override
      this by policy.

   *  *Flow Label*: The transport Flow Label is set per session and MUST
      be derived from the SVR-allocated source/dest port pair so that
      ECMP hashing in the IPv6 underlay ([RFC6438]) treats each SVR
      session as a distinct flow, mirroring the unique-5-tuple property
      of SVR over IPv4 (Section 3.9).  The original packet's Flow Label
      is preserved in the Forward Context TLV.

9.5.  ICMPv6 Interaction

   ICMPv6 ([RFC4443]) replaces ICMP for IPv6 SVR sessions.  The ICMP
   procedures in Section 7.7 apply with the following IPv6-specific
   details:








Menon, et al.            Expires 9 November 2026               [Page 90]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   *  A Packet Too Big (Type 2) message received on an SVR transport
      IPv6 packet MUST be honored by the receiving SVR router for Path
      MTU Discovery ([RFC8201]) on that Peer Pathway, in addition to
      being relayed back to the original sender as described in
      Section 7.6.

   *  Neighbor Discovery ([RFC4861]) traffic MUST NOT be encapsulated in
      SVR.  NS, NA, RS, RA, and Redirect messages are link-local and are
      forwarded by the underlay only.

   *  MLDv1/MLDv2 ([RFC3810]) at the LHR is the IPv6 analog of IGMPv2/v3
      in Section 8.3; the same distribution mechanism and timers apply.

9.6.  BFD over IPv6

   BFD ([RFC5880]) and BFD Metadata (Section 6) operate identically over
   IPv6 Peer Pathways, with the encapsulation defined by [RFC5881] for
   single-hop and [RFC5883] for multihop.  The BFD Metadata payload is
   unchanged.  When a Peer Pathway uses an IPv6 Waypoint, BFD packets
   MUST use a matching IPv6 source address; IPv4 BFD MUST NOT be used to
   monitor an IPv6 pathway.

10.  SVR Metadata Format

   SVR Metadata consists of Header attributes and Payload attributes.
   Header attributes are always unencrypted, are router/pathway scoped
   (no forward/reverse distinction), and MAY be inspected by
   intermediate elements but MUST NOT be modified.  Payload attributes
   are session scoped (with forward/reverse semantics) and MAY be
   encrypted by the sender.  Each TLV defined below is exclusively
   either a header or payload attribute.

10.1.  SVR Metadata Header

   The SVR Metadata header begins with a well-known 8-octet "cookie"
   (0x4c48dbc6ddf6670c, network byte order) immediately following the L4
   header, used by receivers to detect SVR Metadata.  Normal IP traffic
   never targets a Waypoint address; any packet arriving at a Waypoint
   MUST either carry SVR Metadata or belong to an active SVR session
   (see Section 3.11 for state recovery).











Menon, et al.            Expires 9 November 2026               [Page 91]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                             Cookie                            +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version|   Header Length       |         Payload Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Header TLVs ...           |       Payload TLVs ...        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 59

   Cookie (8 octets):  The fingerprint of SVR Metadata.  This value is
      used to determine the existence of SVR Metadata within a packet.

   Version (4-bits):  Field representing the version of the SVR Metadata
      header.  The current version of SVR Metadata is 0x1.

   Header Length (12-bits):  Length of the SVR Metadata header including
      any added Header TLV attributes that are guaranteed to be
      unencrypted.  When there are no Header TLVs, the value Header
      Length is 12 Bytes or OxC.

   Payload Length (2 octets):  Length of data following the SVR Metadata
      header, not including the size of the header.  This data may be
      encrypted.  The value of this field is the number of octets in the
      Payload TLVs.  If there are no TLVs the value is zero.

10.1.1.  False Positives

   Given that no octet sequence is truly unique in the payload of a
   packet, in the scenario where the original payload after the L4
   header contained the same octet sequence as the cookie, false
   positive logic is enacted on the packet.  If the SVR Metadata HMAC
   signature can't verify that the SVR Metadata is valid, then a false
   positive SVR Metadata header is added to the packet to indicate that
   the first eight octets of the payload matches the cookie.

   The structure of a false positive SVR Metadata includes just a header
   of length 12 octets, with zero header TLVs and zero payload TLVs.
   The receiving side of a packet with false positive SVR Metadata will
   strip out the SVR Metadata header.





Menon, et al.            Expires 9 November 2026               [Page 92]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   In the scenario where a router receives a false positive SVR Metadata
   header but intends to add SVR Metadata to the packet, the false
   positive SVR Metadata header is modified to contain the newly added
   attributes.  Once attributes are added, the SVR Metadata header is no
   longer considered to be false positive.

10.1.2.  Forward and Reverse Attributes

   Payload SVR Metadata attributes may be valid in the forward
   direction, the reverse direction, or both.  If not valid, it is
   ignored quietly by the receiving side.

10.2.  TLVs for Attributes

   All SVR Metadata attributes are expressed as Tag Length Values or
   TLVs.  This includes Header and Payload TLVs.  It is recommended that
   Payload TLVs be encrypted, but not mandatory.  When debugging
   networks, or if mid-stream routers need to consult the TLVs, they can
   be transmitted in clear text.  The entire SVR Metadata block is
   signed, and thus the integrity of the data can be verified.  No
   midstream router or middlebox can modify any aspect of the SVR
   Metadata.  Doing so will invalidate the signature, and the SVR
   Metadata will be dropped.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type               |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Variable Length Values .....                         |
     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



                                 Figure 60

   Type (2 octets):  Type of data that follows.  Each of different
      Header and Payload TLVs are defined below.

   Length (2 octets):  Number of octets associated with the length of
      the value (not including the 4 octets associated with the type and
      length fields).







Menon, et al.            Expires 9 November 2026               [Page 93]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


10.3.  Header Attributes

10.3.1.  Fragment

   When a packet is fragmented to insert SVR Metadata, a new
   fragmentation mechanism must be added to prevent fragmentation
   attacks and to support reassembly (which requires protocol and port
   information).  If a packet is received that IS a fragment, and it
   must transit through an SVR Metadata signaled pathway, it must also
   have this SVR Metadata attached to properly bind the fragment with
   the correct session.

   All fragments will have an SVR Metadata header and the fragment TLV
   added to the guaranteed unencrypted portion of the SVR Metadata
   header.  If the original packet already has an SVR Metadata header on
   it, the fragment TLV will be added to it.  See [RFC0791] for
   information about IP Fragmentation.  For a detailed example of packet
   fragmentation in SVR please see Section 7.5



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 1           |           Length = 10         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Extended ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Original ID             |Flags|    Fragment Offset      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Largest Seen Fragment      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 61

   TLV:  Type 1, Length 10.

   Extended ID (4 octets):  Uniquely identifies a packet that is broken
      into fragments.  This ID is assigned by the SVR that is processing
      fragmented packets.  IPv6 uses a 32-bit Extended ID, and IPv4 uses
      a 16-bit ID.  The same algorithm for fragmenting packets is used
      for both IPv6 and IPv4, therefore a 32-Bit Extended ID is used.

   Original ID (2 octets):  Original identification value of the L3
      header of a received packet that is already fragmented.




Menon, et al.            Expires 9 November 2026               [Page 94]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Flags (3-bits):  Field used for identifying fragment attributes.
      They are (in order, from most significant to least

         bit 0: Reserved; must be zero.

         bit 1: Don't fragment (DF).

         bit 2: More fragments (MF).

   Fragment Offset (13-bits):  Field associated with the number of
      eight-octet segments the fragment payload contains.

   Largest Seen Fragment (2 octets):  Each SVR router keeps track of the
      largest fragment processed from each interface.  This allows the
      router to make inferences about the MTU size when fragmenting
      packets in the opposite direction.  This information is used along
      with a given egress network interface MTU to determine the
      fragment size of a reassembled packet.

10.3.2.  Security ID

   A versioning identifier used to determine which security key version
   should be used when handling features dealing with security and
   authenticity of a packet.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type = 16           |            Length = 4         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Security Key Version                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 62

   TLV:  Type 16, Length 4.

   Security Key Version (4 octets):  This is a four-octet security key
      version identifier.  This is used to identify the algorithmic
      version used for SVR Metadata authentication and encryption.







Menon, et al.            Expires 9 November 2026               [Page 95]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


10.3.3.  Disable Forward SVR Metadata

   An indication that forward SVR Metadata should be disabled.  This is
   sent in the reverse SVR Metadata to acknowledge receipt of the SVR
   Metadata.  This is the second part of the SVR Metadata handshake.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type = 18           |         Length = 0            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 63

   TLV:  Type 18, Length 0.

   No other data is required.  The specific session referenced is looked
   up based on the 5-tuple address of the packet.  See SVR Metadata
   handshake in Section 3.4.

10.3.4.  IPv4 ICMP Error Location Address

   This is exclusively used to implement ICMP messages that need to
   travel backwards through SVR pathways.  See Section 7.7 for more
   information.  The IPv4 address of the source of the ICMP message is
   placed into SVR Metadata.  This SVR Metadata travels in the reverse
   direction backwards to the originating SVR, which restores the
   information and sends an ICMP message to the originator of the
   packet.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type = 20           |          Length = 4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Source Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 64




Menon, et al.            Expires 9 November 2026               [Page 96]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   TLV:  Type 20, Length 4.

   Source Address (4 octets):  Original IPv4 source address of the
      originating router.

10.3.5.  IPv6 ICMP Error Location Address

   This is exclusively used to implement ICMP messages that need to
   travel backwards through SVR pathways.  See Section 7.7 for more
   information.  The IPv6 address of the source of the ICMP message is
   placed into SVR Metadata.  This SVR Metadata travels in the reverse
   direction backwards to the originating SVR, which restores the
   information and sends an ICMP message to the originator of the
   packet.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type = 21           |          Length = 16          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                        Source Address                         +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 65

   TLV:  Type 21, Length 16.

   Source Address (16 octets):  Original IPv6 source address of the
      originating router.

10.3.6.  SVR Control Message

   The SVR Control Message is used for protocol specific purposes that
   are limited to a single peer pathway.  This message is sent by an SVR
   router to a peer.  This SVR Metadata is always sent in a UDP message
   originating by the SVR control plane.

   Keep Alive:  When an SVR peer is behind a NAT device and the SVR peer



Menon, et al.            Expires 9 November 2026               [Page 97]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      has active sessions, the SVR peer will generate a "Keep Alive" at
      a rate (e.g., one message every 20 seconds) to prevent the
      firewall from closing a pinhole.  This message is generated
      completely by the SVR router, and directed to the SVR peer for a
      session.  The UDP address and ports fields must exactly match the
      session that has been idle longer than the provisioned time.

   Turn On SVR Metadata:  When a packet is received and there is missing
      SVR Session State, the correction procedure may involve sending
      this request to a peer SVR router that has the information.
      Please see Section 3.11 for more information.

   Turn Off SVR Metadata:  Disable SVR Metadata on a specific 5-tuple.
      In certain cases the SVR peer may continue so send SVR Metadata
      because there are no reverse flow packets or because SVR Metadata
      was enabled to recover from a loss of state.  This message is not
      part of the normal SVR Metadata handshake and only has a scope of
      a single peer pathway.

   Delete Session:  The session associated with the flow spec used by
      this generated packet should be deleted.  This provides an
      administrative and error correcting capability to remove a session
      when required.

   Session State Exists:  In response to a Session Health Check request
      (see Section 10.3.8 to indicate that state for a session exists.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Type = 24            |           Length = 1          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Drop Reason  |
     +-+-+-+-+-+-+-+-+



                                 Figure 66

   TLV:  Type 24, Length 1.

   Drop Reason (1 octet):  Reason why this packet should be dropped.

      *  0 = Unknown.  This value is reserved and used for backwards
         compatibility.




Menon, et al.            Expires 9 November 2026               [Page 98]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      *  1 = Keep Alive.  A packet that is dropped by the receiving
         node.  Used only to keep NAT pinholes alive on middleboxes.

      *  2 = Enable SVR Metadata.  Begin sending SVR Metadata on the
         peer pathway for the 5-tuple matching this control packet.

      *  3 = Disable SVR Metadata.  Stop sending SVR Metadata on the
         peer pathway for a 5-tuple matching this control packet.

      *  6 = Delete Session.  Delete any state for the session
         associated with this SVR Metadata.

      *  8 = Session Health Check indicates state exists, and is valid.

10.3.7.  Path Metrics

   This SVR Metadata type is used to allows peers to measure and compute
   inline flow metrics for a specific peer pathway and a chosen subset
   of traffic class.  The flow metrics can include jitter, latency and
   packet loss.  This is an optional SVR Metadata type.

   When a peer sends this SVR Metadata, it provides the information for
   the period of time to the peer.

   When a peer receives this SVR Metadata type 26, it responds with SVR
   Metadata type 26.

   After several exchanges, each side can compute accurate path metrics
   for the traffic included.  This SVR Metadata can be sent at any time,
   but is normally sent when SVR Metadata is being sent for other
   reasons.  The SVR Metadata includes "colors" which represent blocks
   of packets.  Packet loss and latency can be determined between
   routers using this in line method.  Using colors to measure inline
   flow performance is outside the scope of this document.  Please refer
   to [RFC9341]
















Menon, et al.            Expires 9 November 2026               [Page 99]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type = 26           |           Length = 10         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Tx Co |                Transmit TimeValue                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Rx Co |                Received TimeValue                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |D|   Previous Rx Color Count   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 67

   TLV:  Type 26, Length 10.

   Transmit Color (4-bits):  Current color of a transmitting node.

   Transmit Time Value (28-bits):  Current time value in milliseconds at
      time of marking.  This time value represents the amount of time
      that has elapsed since the start of a transmit color.

   Received Color (4-bits):  Most recently received color from a remote
      node.  This represents the color last received from a specific
      peer.

   Receive Time Value (28-bits):  Cached time value in milliseconds from
      adjacent node, adjusted by the elapsed time between caching of the
      value and current time.  This time value is associated with the
      received color.

   Drop Bit (1-bit):  Should this packet be dropped.  This is required
      if a packet is being sent solely to measure quality on an
      otherwise idle link.

   Previous Rx Color Count (15-bits):  Number of packets received from
      the previous color block.  This count is in reference to the color
      previous to the current RX color which is defined above.











Menon, et al.            Expires 9 November 2026              [Page 100]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


10.3.8.  Session Health Check

   This SVR Metadata is used to request a session state check by a peer.
   The peer responds upon receipt with a generated packet with SVR
   Metadata confirming presence of SVR Metadata.  This SVR Metadata type
   can be included in an existing packet to check that the peer has
   session state.  The peer will always respond with a generated packet
   that includes a forced drop SVR Metadata attribute.  See Section 7.8
   for an example.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 46          |           Length = 1          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = 1    |
     +-+-+-+-+-+-+-+-+



                                 Figure 68

   TLV:  Type 46, Length 1.

   TYPE: (1=Request, 2=Request/Timeout)  Request to verify session state
      with backward SVR Metadata.  Type 1 indicates session state is
      available, Type 2 indicates session state is available but will be
      cleared and replaced upon receipt of state from a peer.  Type 2 is
      used when a middle box closes pinholes that must be recovered.

10.4.  Payload Attributes

   Payload attributes are used for session establishment and SHOULD be
   encrypted to provide privacy.  Encryption can be disabled for
   debugging.

10.4.1.  Forward Context IPv4

   The context contains a five-tuple associated with the original
   addresses, ports, and protocol of the packet.  This is also known as
   the Forward Session Key.








Menon, et al.            Expires 9 November 2026              [Page 101]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type = 2          |           Length = 13         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Source Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Source Port           |      Destination Port         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Protocol    |
     +-+-+-+-+-+-+-+-+



                                 Figure 69

   TLV:  Type 2, Length 13.

   Source Address (4 octet):  Original IPv4 source address of the
      packet.

   Destination Address (4 octets):  Original IPv4 destination address of
      the packet.

   Source Port (2 octets):  Original source port of the packet.

   Destination Port (2 octets):  Original destination port of the
      packet.

   Protocol (1 octet):  Original protocol of the packet.

10.4.2.  Forward Context IPv6

   A five-tuple associated with the original addresses, ports, and
   protocol of the packet for IPv6.














Menon, et al.            Expires 9 November 2026              [Page 102]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type = 3            |          Length = 37          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                         Source Address                        +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Destination Address                     +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Source Port          |        Destination Port       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Protocol    |
     +-+-+-+-+-+-+-+-+



                                 Figure 70

   TLV:  Type 3, Length 37.

   Source Address (16 octets):  Original IPv6 source address of the
      packet.

   Destination Address (16 octets):  Original IPv6 destination address
      of the packet.

   Source Port (2 octets):  Original source port of the packet.

   Destination Port (2 octets):  Original destination port of the
      packet.

   Protocol (1 octet):  Original protocol of the packet.







Menon, et al.            Expires 9 November 2026              [Page 103]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


10.4.3.  Reverse Context IPv4

   Five-tuple associated with the egress (router) addresses, ports, and
   protocol of the packet.  Forward context and reverse context session
   keys are not guaranteed to be symmetrical due to functions which
   apply source NAT, destination NAT, or both to a packet before leaving
   the router.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type = 4          |           Length = 13         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Source Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Source Port           |      Destination Port         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Protocol    |
     +-+-+-+-+-+-+-+-+



                                 Figure 71

   TLV:  Type 4, Length 13.

   Source Address (4 octets):  Egress IPv4 source address of the packet.

   Destination Address (4 octets):  Egress IPv4 destination address of
      the packet.

   Source Port (2 octets):  Egress source port of the packet.

   Destination Port (2 octets):  Egress destination port of the packet.

   Protocol (1 octet):  Original protocol of the packet.

10.4.4.  Reverse Context IPv6

   Five-tuple associated with the egress (router) addresses, ports, and
   protocol of the packet.  Forward and reverse session keys are not
   guaranteed to be symmetrical due to functions which apply source NAT,
   destination NAT, or both to a packet before leaving the router.




Menon, et al.            Expires 9 November 2026              [Page 104]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type = 5            |          Length = 37          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                         Source Address                        +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Destination Address                     +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Source Port          |        Destination Port       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Protocol    |
     +-+-+-+-+-+-+-+-+



                                 Figure 72

   TLV:  Type 5, Length 37.

   Source Address (16 octets):  Egress IPv6 source address of the
      packet.

   Destination Address (16 octets):  Egress IPv6 destination address of
      the packet.

   Source Port (2 octets):  Egress source port of the packet.

   Destination Port (2 octets):  Egress destination port of the packet.

   Protocol (1 octet):  Original protocol of the packet.








Menon, et al.            Expires 9 November 2026              [Page 105]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


10.4.5.  Session UUID

   Unique identifier of a session.  The UUID MUST be conformant to
   [RFC9562].  This is assigned by the peer that is initiating a
   session.  Once assigned, it is maintained through all participating
   routers end-to-end.

   The UUID is used to track sessions across multiple routers.  The UUID
   also can be used to detect a looping session.  The UUID SVR Metadata
   field is required for all session establishment.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 6           |           Length = 16         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                              UUID                             +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 73

   TLV:  Type 6, Length 16.

   UUID (16 octets):  Unique identifier of a session.

10.4.6.  Tenant Name

   An alphanumeric ASCII string which dictates what tenancy the session
   belongs to.












Menon, et al.            Expires 9 November 2026              [Page 106]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 7           |       Length = variable       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Name (1 - n octets) ....                      |
     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



                                 Figure 74

   TLV:  Type 7, Length variable.

   Name (variable length):  The tenant name represented as a string.

10.4.7.  Service Name

   An alphanumeric string which dictates what service the session
   belongs to.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 10          |       Length = variable       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Name (1-n octets) .....              |
     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



                                 Figure 75

   TLV:  Type 10, Length variable.

   Name (variable length):  The service name represented as a string.

10.4.8.  Session Encrypted

   Indicates if the session is having its payload encrypted by the SVR
   router.  This is different from having the SVR Metadata encrypted.
   The keys used for payload encryption are dependent on the Security
   Policy defined for a session.






Menon, et al.            Expires 9 November 2026              [Page 107]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   This field is necessary because often traffic is already encrypted
   before arriving at an SVR router (making DPI a poor choice).  Also in
   certain use cases, re-encryption may be required.  This SVR Metadata
   TLV is always added when SVR encrypts the payload.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 11          |           Length = 0          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 76

   TLV:  Type 11, Length 0.

10.4.9.  TCP SYN Packet

   Indicates if the session is being converted from TCP to UDP to enable
   passing through middle boxes that are TCP session stateful.  A SVR
   implementation must verify that SVR Metadata can be sent inside TCP
   packets through testing the Peer Pathway.  If the data is blocked,
   then all TCP sessions must be converted to UDP sessions and restored
   on the destination peer.

   Although this may seem redundant with the Forward Context that also
   has the same originating protocol, this refers to a specific peer
   pathway.  In a multi-hop network, the TCP conversion to UDP could
   occur at the second hop.  It's important to restore the TCP session
   as soon as possible after passing through the obstructive middlebox.

   When TCP to UDP conversion occurs, no octets are changed other than
   the protocol value (TCP->UDP).  Because the UDP message length and
   checksum overlap with the TCP Sequence Number, the Sequence number is
   overwritten.  The Sequence number is saved by copying it to the TCP
   Checksum and Urgent Pointer portion of the packet.  The Checksum is
   recalculated upon restoration of the packet.  The urgent pointer is
   zeroed out and urgent flag is cleared.










Menon, et al.            Expires 9 November 2026              [Page 108]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 12          |           Length = 0          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 77

   TLV:  Type 12, Length 0.

   Note: This type does not contain any value as its existence in SVR
   Metadata indicates a value.

10.4.10.  Source Router Name

   An alphanumeric string which dictates which source router the packet
   is originating from.  This attribute may be present in all forward
   SVR Metadata packets if needed.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 14          |       Length = variable       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Router Name (1-n octets) ....                   |
     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



                                 Figure 78

   TLV:  Type 14, Length variable.

   Name (variable length):  The router name represented as a string.

10.4.11.  Security Policy

   An alphanumeric string containing the Security Policy to use for a
   particular session.  This is used only when payload encryption is
   being performed.  The Security Policy describes the specifics about
   ciphers used for payload encryption.






Menon, et al.            Expires 9 November 2026              [Page 109]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 15          |       Length = variable       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        SECURITY POLICY                        |
     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



                                 Figure 79

   TLV:  Type 15, Length variable.

   KEY (variable length):  The session key to use for encryption/
      decryption for this packet and future packets in a session.

10.4.12.  Peer Pathway ID

   An ASCII string which dictates which router peer pathway has been
   chosen for a packet.  This name is the hostname or IP address of the
   egress interface of the originating router.  This can be used to
   determine the peer pathway used exactly when there may be multiple
   possibilities.  This enables association of policies with specific
   paths.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 19          |       Length = variable       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Peer Pathway Name (1-n octets) ....                |
     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



                                 Figure 80

   TLV:  Type 19, Length variable.

   Name (variable length):  The peer pathway name which is represented
      as a string.







Menon, et al.            Expires 9 November 2026              [Page 110]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


10.4.13.  IPv4 Source NAT Address

   Routers may be provisioned to perform source NAT functions while
   routing packets.  When a source NAT is performed by an SVR Peer, this
   SVR Metadata TLV MUST be included.  When the far end router
   reconstructs the packet, it will use this address as the source
   address for packets exiting the SVR.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 25          |           Length = 4          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     IPv4 Source Nat Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 81

   TLV:  Type 25, Length 4.

   Source Address (4 octets):  Source NAT address of the packet.

10.4.14.  Remaining Session Time

   After a path failure, it may become necessary to transmit an SVR
   Control Message when there are one-way flows waiting for a packet to
   be transmitted.  In these cases, the SVR Metadata includes an
   attribute defining the remaining session time so intermediate routers
   creating new session entries will expire the session at the correct
   time.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 42          |           Length = 4          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Remaining Session Time (seconds)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 82



Menon, et al.            Expires 9 November 2026              [Page 111]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   TLV:  Type 42, Length 4.

   Remaining Session Time (4 octets):  Number of seconds remaining on a
      session packet guard time.  This ensures accurate guarding of
      sessions that have been moved.

10.4.15.  Security Encryption Key

   An alphanumeric string containing the cryptographic key to use for a
   payload encryption of a particular session.  This is used only when
   payload encryption is being performed.  The key is encrypted in SVR
   Metadata hop-by-hop through a network, preventing any party from
   obtaining the key.  The router terminating the session utilizes this
   key to decrypt payload portions of packets.  This prevents re-
   encryption penalties associated with multi-hop routing scenarios.

   To rekey a session, this SVR Metadata can be included in any
   subsequent packet with the new key to use.  When rekeying, the SVR
   that initiated the encrypted session must compute a new key, and
   include the key as SVR Metadata.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 46          |       Length = variable       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        SECURITY KEY                           |
     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



                                 Figure 83

   TLV:  Type 46, Length variable.

   KEY (variable length):  The session key to use for encryption/
      decryption for this packet and future packets in a session.

10.4.16.  Multicast Group Context

   Identifies the (Source, Group, Protocol) of a multicast SVR session.
   Used both in SVR Control Messages signaling group membership
   (Section 8.3) and as a payload TLV in the first packet of a multicast
   session.  The address family field selects between IPv4 (lengths
   shown) and IPv6 (16-octet addresses).




Menon, et al.            Expires 9 November 2026              [Page 112]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   TLV:  Type 50, Length variable.

   Address Family (1 octet):  0x04 = IPv4, 0x06 = IPv6.

   Flags (1 octet):  Bit 0 = SSM (1) or ASM (0).  Bit 1 = Join (1) /
      Leave (0) when used in a Control Message; ignored when used as
      session metadata.  Remaining bits reserved, MUST be sent as 0 and
      ignored on receipt.

   Source Address (4 or 16 octets):  The multicast source address.  For
      ASM, the all-zero address of the appropriate family.

   Group Address (4 or 16 octets):  The multicast group address.

   Protocol (1 octet):  L4 protocol of the multicast flow (typically 17,
      UDP).

10.4.17.  Multicast Egress List

   Enumerates the LHRs currently in the Egress Set of a multicast SVR
   session.  Carried in forward SVR Metadata sent by the FHR.

   TLV:  Type 51, Length variable.

   Count (2 octets):  Number of router-name entries that follow.

   Entries (variable):  A sequence of Count entries, each consisting of
      a 1-octet length followed by that many octets of UTF-8 router
      name.  Total TLV length MUST match the Length field.

11.  Implementation Status

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in RFC 7942.
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.  According to RFC 7942, "this will allow reviewers and working
   groups to assign due consideration to documents that have the benefit
   of running code, which may serve as evidence of valuable
   experimentation and feedback that have made the implemented protocols
   more mature.  It is up to the individual working groups to use this



Menon, et al.            Expires 9 November 2026              [Page 113]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   information as they see fit".

11.1.  Session Smart Router

   *  Organization: Hewlett Packard Enterprise

   *  Name: Session Smart Router

   *  Description: The Session Smart Router exists as a SDWAN router
      following the implementation defined in this document.

   *  Level of maturity: Production

   *  Coverage: All aspects of the protocol are implemented.

   *  Licensing: Proprietary

   *  Contact: michael.baj@hpe.com

   *  URL: https://www.juniper.net/documentation/us/en/software/session-
      smart-router/

12.  Security Considerations

12.1.  HMAC Authentication

   Packets carrying SVR Metadata are HMAC-signed to authenticate the
   sender and protect integrity.  Any HMAC algorithm agreed by both
   peers MAY be used (e.g., SHA1, SHA256, SHA256-128).  The signature
   covers the L4 payload and is appended to the end of the packet.

12.2.  Replay Prevention

   Time-Based HMAC on every packet is RECOMMENDED.  It prevents in-
   stream tampering, supports egress state-loss detection
   (Section 3.11), and binds each signature to a time window to prevent
   replay.  Provisioning of HMAC parameters is out of scope.

12.3.  Payload Encryption

   Payload encryption uses AES-CBC-128 or AES-CBC-256.  Plaintext is
   padded to a 16-octet boundary; if the plaintext is already a multiple
   of 16, an additional 16-octet pad block is appended whose last octet
   indicates the pad length.







Menon, et al.            Expires 9 November 2026              [Page 114]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


12.4.  DDoS and Unexpected Traffic on Waypoint Addresses

   Any host can send packets to a Waypoint address.  SVR routers MUST
   treat such packets as either bearing SVR Metadata or belonging to an
   established session/protocol; everything else is dropped.

   Source-address ACLs SHOULD restrict accepted SVR traffic to
   provisioned peers.  The 8-octet SVR cookie is checked first; on
   mismatch the packet is dropped.  The HMAC is checked next; on failure
   the packet is dropped.  Together these checks deflect DDoS attempts
   targeting Waypoint addresses.

13.  IANA Considerations

   This document is published as an Independent Submission and does not
   require IANA to create new top-level registries.  The SVR Metadata
   Type code points used in this document are administered by the
   Authority that operates an SVR deployment (see Section 1.4) and are
   summarized below for implementer convenience.  Type values are scoped
   separately for Header and Payload TLVs.

   Header TLV Types currently defined: 1 (Fragment), 16 (Security ID),
   18 (Disable Forward SVR Metadata), 20 (IPv4 ICMP Error Location), 21
   (IPv6 ICMP Error Location), 24 (SVR Control Message), 26 (Path
   Metrics), 46 (Session Health Check).

   Payload TLV Types currently defined: 2 (Forward Context IPv4), 3
   (Forward Context IPv6), 4 (Reverse Context IPv4), 5 (Reverse Context
   IPv6), 6 (Session UUID), 7 (Tenant Name), 10 (Service Name), 11
   (Session Encrypted), 12 (TCP SYN Packet), 14 (IPv4 Source NAT
   Address), 15 (Source Router Name), 19 (Peer Pathway ID), 25
   (Remaining Session Time), 42 (Security Policy), 46 (Security Key), 50
   (Multicast Group Context), 51 (Multicast Egress List).

   Unassigned values in either space are available for future use.
   Implementations MUST ignore unknown TLVs as required by
   Section 5.6.2.1.

14.  Acknowledgements

   The authors would like to thank Anya Yungelson, Scott McCulley, and
   Chao Zhao for their input into this document.

   The authors would like to thank Tony Li for his extensive support and
   help with all aspects of this document.






Menon, et al.            Expires 9 November 2026              [Page 115]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   The authors want to thank Ron Bonica, Kireeti Kompella, and other
   IETFers at Hewlett Packard Enterprise (formerly Juniper Networks) for
   their support and guidance.

15.  Normative References

   [ECDH_Key_Exchange]
              Nakov, S., "Practical Cryptography for Developers",
              ISBN 978-619-00-0870-5, Publisher Sofia, November 2018,
              <https://cryptobook.nakov.com/asymmetric-key-ciphers/ecdh-
              key-exchange>.

   [NIST_SP_800-56A]
              Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
              Davis, "Recommendation for Pair-Wise Key-Establishment
              Schemes Using Discrete Logarithm Cryptography", ISBN NIST
              Special Publication 800-56A Rev3, Publisher National
              Security Agency, April 2018,
              <https://csrc.nist.gov/pubs/sp/800/56/a/r3/final>.

   [NIST_SP_800-90B]
              Turan, M., Barker, E., Kelsey, J., McKay, K., Baish, M.,
              and M. Boyle, "Recommendation for the Entropy Sources Used
              for Random Bit Generation", ISBN NIST Special Publication
              800-90B, Publisher National Institute of Standards and
              Technology, January 2018,
              <https://csrc.nist.gov/pubs/sp/800/90/b/final>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [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>.






Menon, et al.            Expires 9 November 2026              [Page 116]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   [RFC9562]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 9562,
              DOI 10.17487/RFC9562, July 2005,
              <https://www.rfc-editor.org/info/rfc9562>.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210,
              DOI 10.17487/RFC4210, September 2005,
              <https://www.rfc-editor.org/info/rfc4210>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC5758]  Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
              Polk, "Internet X.509 Public Key Infrastructure:
              Additional Algorithms and Identifiers for DSA and ECDSA",
              RFC 5758, DOI 10.17487/RFC5758, January 2010,
              <https://www.rfc-editor.org/info/rfc5758>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6062]  Perreault, S., Ed. and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN) Extensions for TCP Allocations",
              RFC 6062, DOI 10.17487/RFC6062, November 2010,
              <https://www.rfc-editor.org/info/rfc6062>.

   [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 9300,
              DOI 10.17487/RFC9300, January 2013,
              <https://www.rfc-editor.org/info/rfc9300>.

   [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
              PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
              April 2015, <https://www.rfc-editor.org/info/rfc7468>.

   [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>.








Menon, et al.            Expires 9 November 2026              [Page 117]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   [RFC9341]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 9341, DOI 10.17487/RFC9341,
              January 2018, <https://www.rfc-editor.org/info/rfc9341>.

   [RFC8422]  Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
              Curve Cryptography (ECC) Cipher Suites for Transport Layer
              Security (TLS) Versions 1.2 and Earlier", RFC 8422,
              DOI 10.17487/RFC8422, August 2018,
              <https://www.rfc-editor.org/info/rfc8422>.

   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
              Connectivity Establishment (ICE): A Protocol for Network
              Address Translator (NAT) Traversal", RFC 8445,
              DOI 10.17487/RFC8445, July 2018,
              <https://www.rfc-editor.org/info/rfc8445>.

   [RFC8489]  Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
              D., Mahy, R., and P. Matthews, "Session Traversal
              Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
              February 2020, <https://www.rfc-editor.org/info/rfc8489>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [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>.

16.  Informative References

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989,
              <https://www.rfc-editor.org/info/rfc1112>.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997,
              <https://www.rfc-editor.org/info/rfc2236>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002,
              <https://www.rfc-editor.org/info/rfc3376>.



Menon, et al.            Expires 9 November 2026              [Page 118]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006,
              <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using IGMPv3 and
              MLDv2 for Source-Specific Multicast", RFC 4604, August
              2006, <https://www.rfc-editor.org/info/rfc4604>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007, <https://www.rfc-editor.org/info/rfc4861>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
              2010, <https://www.rfc-editor.org/info/rfc5881>.

   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, June 2010,
              <https://www.rfc-editor.org/info/rfc5883>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011,
              <https://www.rfc-editor.org/info/rfc6146>.

   [RFC6438]  Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
              for Equal Cost Multipath Routing and Link Aggregation in
              Tunnels", RFC 6438, November 2011,
              <https://www.rfc-editor.org/info/rfc6438>.

   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
              July 2017, <https://www.rfc-editor.org/info/rfc8201>.




Menon, et al.            Expires 9 November 2026              [Page 119]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


Appendix A.  Changes from -07 to -08

   *  Added Section 8 describing SVR support for IPv4 and IPv6
      multicast, including a hybrid native-multicast / ingress-
      replication distribution model, edge-only IGMP/MLD interaction,
      and per-(S,G) session lifecycle.

   *  Added Section 9 consolidating IPv6-specific behavior: addressing
      and Waypoints, IPv4/IPv6 interworking, IPv6 extension header
      handling, Hop Limit / Traffic Class / Flow Label rules, ICMPv6
      interaction, and BFD over IPv6.

   *  Added two new payload TLVs: Multicast Group Context (Type 50,
      Section 10.4.16) and Multicast Egress List (Type 51,
      Section 10.4.17).

   *  Updated Section 13 to enumerate the currently-defined Header and
      Payload TLV Type code points, including the new multicast TLVs.

   *  Tightened the Abstract.

Authors' Addresses

   Abilash Menon
   Maia Edge
   77 S Bedford St Suite 150
   Burlington, MA 01803
   United States of America
   Email: abilashmenon@maiaedge.io


   Patrick MeLampy
   Retired
   1024 Main St.
   Dustable, MA 01827
   United States of America
   Email: pmelampy@gmail.com


   Michael Baj
   Hewlett Packard Enterprise
   10 Technology Park Dr.
   Westford, MA 01886
   United States of America
   Email: michael.baj@hpe.com






Menon, et al.            Expires 9 November 2026              [Page 120]

Internet-Draft       HPE Secure Vector Routing (SVR)            May 2026


   Patrick Timmons
   Maia Edge
   77 S Bedford St Suite 150
   Burlington, MA 01803
   United States of America
   Email: ptimmons@maiaedge.io


   Hadriel Kaplan
   Hewlett Packard Enterprise
   10 Technology Park Dr.
   Westford, MA 01886
   United States of America
   Email: hadriel.kaplan@hpe.com





































Menon, et al.            Expires 9 November 2026              [Page 121]
