Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance
draft-xiao-v6ops-eds-01

Network Working Group                                            X. Xiao
Internet-Draft                            Huawei Technologies Dusseldorf
Intended status: Informational                               4 July 2026
Expires: 5 January 2027

Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance
                        draft-xiao-v6ops-eds-01

Abstract

   This document describes Enhanced Dual Stack (EDS), a host-side
   framework intended to reduce the operational risk and workload of
   IPv6 deployment.

   Today, many applications select IPv6 or IPv4 using static address-
   selection rules.  These rules provide a useful baseline, but they are
   not live measurements of current reachability or performance.  If
   IPv6 is selected when it is broken or degraded, users may experience
   failures or delays.  This creates a need for extensive upfront IPv6
   validation before deployment.

   Happy Eyeballs (HE) reduces this risk for applications that implement
   it, but it does not automatically help existing applications that
   continue to use traditional APIs such as getaddrinfo(), socket(), and
   connect().

   EDS aims to make IPv6/IPv4 selection performance-informed for both
   new and existing applications.  It does this through three
   enhancements:

   1.  An OS/platform HEv3 implementation profile.

   2.  Selective operational diagnostics.

   3.  A compatibility path for existing applications.

   With Enhancements 1 and 3, a broad class of existing applications can
   reduce repeated user-visible degradation caused by impaired IPv6
   paths.  The associated upfront IPv6 validation can focus mainly on
   residual critical applications that do not benefit from EDS.  With
   Enhancement 2, network administrators can identify IPv6 problems and
   fix them over time.

   EDS changes IPv6 deployment from a high-risk, upfront project to a
   more gradual and evidence-driven operational improvement process.

Xiao                     Expires 5 January 2027                 [Page 1]
Internet-Draft             Enhanced Dual Stack                 July 2026

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 January 2027.

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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Enhanced Dual Stack Framework . . . . . . . . . . . . . . . .   5
     3.1.  OS/Platform HEv3 Implementation Profile . . . . . . . . .   5
     3.2.  Selective Operational Diagnostics . . . . . . . . . . . .   6
     3.3.  Compatibility Path for Existing Applications  . . . . . .   6
   4.  Incremental EDS Deployment  . . . . . . . . . . . . . . . . .   9
   5.  Limitations . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Standardization Considerations  . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11

Xiao                     Expires 5 January 2027                 [Page 2]
Internet-Draft             Enhanced Dual Stack                 July 2026

   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Enterprise IPv6 deployment considerations are described in [RFC7381].
   The amount of work required to prepare for and validate IPv6
   deployment can appear large.  This mainly results from the need to
   ensure that enabling IPv6 does not create user-visible failures or
   delays.  The underlying reason is as follows.  Applications commonly
   use getaddrinfo() [RFC3493], socket(), and connect() to establish
   communication with a destination. getaddrinfo() returns an ordered
   list of destination addresses, socket() creates a local communication
   endpoint, and connect() attempts to establish communication with one
   selected destination.  Default address-selection rules, including
   [RFC6724], provide useful interoperability and policy control.
   However, these rules are not live measurements of current
   reachability or performance on a particular host, network,
   destination, interface, or time period.  IPv6 can therefore be
   selected even when it is broken or degraded, causing failures,
   delays, or poor application performance.  To reduce this risk,
   network administrators often feel that they must validate IPv6
   extensively before enabling it broadly.  Happy Eyeballs Version 2
   (HEv2) [RFC8305] and Happy Eyeballs Version 3 (HEv3) [HEv3] reduce
   user-visible delay by resolving DNS information asynchronously,
   sorting candidates, and using staggered connection attempts.  HEv3
   also supports SVCB and HTTPS resource records [RFC9460].  However,
   HEv3 does not by itself substantially reduce the required pre-
   deployment validation effort: 1.  HEv3 does not define an OS/platform
   implementation profile.  When an application implements HEv3
   independently, other applications on the same host do not
   automatically benefit.  Such applications may still select IPv6 when
   it is broken, creating a need for validation. 2.  HEv3 can fall back
   to IPv4 without necessarily providing operational information that
   helps a network administrator identify the reason for IPv6 failure or
   degradation. 3.  Many existing applications use traditional resolver
   and socket APIs, such as getaddrinfo(), rather than an HEv3-capable
   networking facility.  They therefore cannot automatically obtain
   HEv3-style connection racing.  EDS is intended to address these three
   gaps through an OS/platform HEv3 implementation profile, selective
   operational diagnostics, and a compatibility path for existing
   applications.

Xiao                     Expires 5 January 2027                 [Page 3]
Internet-Draft             Enhanced Dual Stack                 July 2026

1.1.  Requirements Language

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

2.  Terminology

   Enhanced Dual Stack (EDS):  A host-side dual-stack framework that
      uses local policy and recent local performance observations to
      improve IPv6/IPv4 selection.

   OS/platform HEv3 implementation profile:  A model in which HEv3
      behavior is implemented by the operating system, a platform
      networking library, or another common host networking function, so
      that applications can benefit from HEv3 behavior without each
      application implementing HEv3 independently.

   Operational Diagnostics:  Selected local information about address
      selection, connection attempts, IPv4 fallback, and related host
      behavior.  It is exposed subject to local policy and privacy
      constraints to help network administrators diagnose IPv6
      reachability and performance problems.

   Compatibility path for existing applications:  A mechanism for non-
      racing resolver and connection-establishment facilities that uses
      applicable recent local performance observations to improve
      destination candidate ordering while preserving existing APIs and
      application semantics.

   EDS-capable host:  A host on which an OS/platform HEv3 implementation
      profile, operational diagnostics, and a compatibility path for
      existing applications are each available.  These capabilities can
      be provided by different implementations on the host and need not
      cover every application on the host.

   Partially EDS-capable host:  A host on which one or two, but not all
      three, EDS enhancement categories are available.  Such a host can
      still obtain useful EDS benefits for the applications using the
      available facilities, but has less complete coverage than an EDS-
      capable host.

   Non-EDS host:  A host that has none of the EDS enhancement categories
      available.

Xiao                     Expires 5 January 2027                 [Page 4]
Internet-Draft             Enhanced Dual Stack                 July 2026

3.  Enhanced Dual Stack Framework

   EDS provides a framework for making IPv6/IPv4 selection performance-
   informed across both existing and new applications.

   The framework consists of three complementary enhancements:

   1.  An OS/platform HEv3 implementation profile.

   2.  Selective operational diagnostics.

   3.  A compatibility path for existing applications.

3.1.  OS/Platform HEv3 Implementation Profile

   HEv3 specifies client behavior but does not prescribe the
   implementation location.  It can be implemented in the connection-
   establishment layer used by the application, including an operating-
   system networking framework, platform library, language runtime,
   browser stack, or application library.

   For the EDS deployment model, an OS/platform implementation is
   important because applications using such APIs can benefit from HEv3
   behavior without having to explicitly implement HEv3.

   In general, when an operating system, platform networking facility,
   language runtime, browser stack, client library, or user-space
   transport implementation is invoked by applications with a hostname
   and controls candidate gathering and connection establishment, it
   SHOULD implement HEv3-style IPv6/IPv4 racing.  This allows the
   applications that use that facility to benefit from HEv3 behavior
   without each application explicitly implementing HEv3.

   For example, an HTTP client library that receives a hostname from an
   application and creates the corresponding TCP connections can
   implement HEv3 behavior internally while preserving its existing
   application-facing API.  By contrast, a resolver interface such as
   getaddrinfo() returns an ordered address list but does not control
   multiple connection attempts.  It therefore cannot implement
   HEv3-style racing.  However, it can still support applications that
   call it with performance-informed IPv6/IPv4 selection, as described
   in the "Compatibility Path" section below.

Xiao                     Expires 5 January 2027                 [Page 5]
Internet-Draft             Enhanced Dual Stack                 July 2026

   The Transport Services (TAPS) architecture [RFC9621] and its abstract
   API [RFC9622] provide an asynchronous connection-establishment
   architecture: they combine name resolution with connection
   establishment and allow selection among multiple endpoints, paths,
   and transport protocols.  TAPS can provide a long-term architectural
   basis for an OS/platform HEv3 implementation.  However, TAPS does not
   by itself prescribe HEv3 behavior, and EDS does not require TAPS.

3.2.  Selective Operational Diagnostics

   EDS is intended not only to reduce user-visible deployment risk, but
   also to help network administrators improve IPv6 over time.

   An EDS-capable host or platform SHOULD make selected diagnostic
   information available to authorized network administrators,
   applications, or management systems, subject to local policy and
   privacy constraints.

   At a minimum, such diagnostic information SHOULD make it possible to
   determine:

   *  Whether IPv6 was selected, attempted, bypassed, or deprioritized.

   *  Whether IPv4 was used because IPv6 failed, did not become usable
      before another candidate, was deprioritized based on previous
      local observations, or was selected by explicit policy.

   *  Whether the decision was based on a current connection attempt,
      previous local observations, policy, or insufficient information.

   *  The destination and local network context associated with repeated
      IPv6 problems, subject to privacy constraints.

   Related Happy Eyeballs reporting considerations are described in
   [HE-REPORT].  If an HEv3 reporting mechanism is specified, EDS
   implementations can use that mechanism where appropriate.

3.3.  Compatibility Path for Existing Applications

   Many existing applications use resolver interfaces that return an
   ordered set of destination addresses and then use socket APIs to
   attempt connections sequentially, rather than performing real-time
   IPv6/IPv4 connection racing. getaddrinfo(), used with socket() and
   connect(), is an important and widely deployed example.  Other
   examples include Java's InetAddress resolver APIs, such as
   InetAddress.getAllByName(), and asynchronous resolver libraries such
   as c-ares ares_getaddrinfo().

Xiao                     Expires 5 January 2027                 [Page 6]
Internet-Draft             Enhanced Dual Stack                 July 2026

   These applications cannot be expected to change quickly.  EDS
   therefore includes a compatibility path that improves destination
   candidate ordering and records relevant connection observations while
   preserving existing APIs and application semantics.

   These traditional resolver and socket APIs are available across Unix-
   like systems, Windows, Apple platforms, and Android.  Therefore,
   enhancements to them can cover a broad class of existing
   applications.

   The compatibility path does not provide real-time IPv6/IPv4 racing.
   Instead, it allows the OS or platform to learn from previous
   connection attempts and use applicable recent observations when
   ordering future IPv6 and IPv4 destination addresses.  Using
   getaddrinfo() and connect() as an example, this is done through the
   following OS/platform improvements:

   1.  Improved getaddrinfo() behavior

       The OS or platform can use configured policy, [RFC6724], and
       applicable recent local observations when ordering IPv6 and IPv4
       destination addresses.

       If no applicable observations exist, getaddrinfo() behaves as it
       does today.  Therefore, the first connection to a destination can
       still select IPv6 and experience delay or failure before the
       application retries IPv4, if it retries at all.

       After relevant observations have been learned, later connection
       attempts can avoid repeatedly preferring an IPv6 path that
       recently failed or performed poorly.

       When applicable IPv6 and IPv4 performance are sufficiently
       similar, local policy MAY retain a bounded preference for IPv6 by
       applying a threshold when ordering candidates.  Such a preference
       MUST NOT exclude IPv4 candidates or otherwise prevent IPv4
       fallback when IPv6 fails or is materially degraded.

       When ordering destination addresses, the OS or platform MAY
       internally consider the source/destination address pair that
       would likely be selected for each candidate in the current
       network context.  More precisely, when ordering destination
       addresses returned by getaddrinfo(), the implementation can
       determine the source address that would normally be selected for
       each destination, taking account of the applicable route,
       interface, provisioning-domain, and VPN context, and take the
       resulting source/destination pair into account [GET-ADDR-PAIRS].
       It can also take applicable performance observations for that

Xiao                     Expires 5 January 2027                 [Page 7]
Internet-Draft             Enhanced Dual Stack                 July 2026

       pair into account.  This prediction does not apply when an
       application explicitly binds or otherwise constrains its source
       address.  In that case, the application's choice takes
       precedence.

   2.  Improved connect() behavior

       The OS or platform can record the outcome of transport connection
       establishment, such as success, failure, or timeout.  Where the
       relevant transport stack or shared library can observe it, it can
       also record whether a connection became usable and relevant
       lifetime connection-performance information, such as repeated
       degradation after establishment or a measured RTT estimate.

       For QUIC, a UDP connect() operation does not indicate whether the
       QUIC connection or handshake succeeded, and does not provide QUIC
       lifetime performance information.  Equivalent observations
       therefore need to be provided by the relevant QUIC library or
       platform QUIC API.

       One possible format for a local Connection Performance Cache is:

       *  Index key: destination IP address and port or service,
          transport protocol, outgoing interface or network context,
          and, where relevant, source prefix.

       *  Value: connection-performance outcome and, where available,
          RTT.

       This information can be used when ordering IPv6 and IPv4
       destination candidates.

   The OS or platform can retain such observations for a limited time
   and use them only when they apply to the new connection attempt.  The
   method used to store, age, scope, and look up these observations is
   implementation-specific.

   Applications are not required to supply the outgoing interface or
   network context.  The OS or platform can determine relevant context
   from locally available information, such as route lookup, source-
   address selection, interface binding, and VPN state.

   The compatibility path MUST NOT override explicit administrative,
   application, routing, or security policy.

Xiao                     Expires 5 January 2027                 [Page 8]
Internet-Draft             Enhanced Dual Stack                 July 2026

4.  Incremental EDS Deployment

   For enterprises, EDS changes the deployment model from:

      Validate everything before enabling IPv6.

   to:

      Enable IPv6 with reduced user-visible risk, observe where IPv6
      problems occur, and fix them over time.

   EDS does not require every host to be fully EDS-capable before IPv6
   deployment can begin.  An enterprise can divide its hosts into early-
   adopter hosts and critical hosts, and apply different deployment
   approaches to them.

   Early-adopter hosts can be partially EDS-capable.  They can use any
   available HEv3-style racing, compatibility behavior, or operational
   diagnostics, while accepting a limited residual risk of user-visible
   IPv6 degradation during the initial phase.  IPv6 can be enabled for
   these hosts first, and their observed connection outcomes, fallback
   behavior, and diagnostic information can help identify and correct
   IPv6 problems.  Useful indicators to monitor include the proportion
   of IPv6 traffic, IPv4 fallback rate, and IPv6 connection-failure or
   degradation rate.  These values need not change monotonically, but
   significant changes or persistent lack of IPv6 use should be
   explainable from observed destination, application, or network
   conditions.

   Critical hosts can remain in an IPv4-only environment during the
   initial phase when their important applications lack sufficient EDS
   coverage or when their business impact does not permit the residual
   risk accepted for early-adopter hosts.  This can be done by placing
   them in an IPv4-only VLAN or by another applicable mechanism.
   Critical hosts can join the IPv6-enabled environment when they become
   EDS-capable, or when the enterprise has gained sufficient IPv6
   operational experience and confidence to evaluate them in a
   controlled rollout.  If necessary, an individual host or group of
   hosts can be returned to an IPv4-only environment temporarily until
   the problems are fixed.

   After stable operation has been demonstrated in IPv6-enabled
   environments, network administrators can begin migrating selected
   environments toward IPv6-mostly or IPv6-only operation where
   appropriate.

Xiao                     Expires 5 January 2027                 [Page 9]
Internet-Draft             Enhanced Dual Stack                 July 2026

5.  Limitations

   EDS has several limitations.  With incremental deployment, these
   limitations do not require an enterprise to delay IPv6 deployment for
   all hosts, but they can affect the host cohorts selected for rollout
   and the additional validation needed before critical hosts are
   migrated.

   First, the compatibility path does not provide real-time connection
   racing like HEv3.  It uses configured policy and applicable
   historical performance observations.  When no applicable performance
   data exist, the first legacy connection can still suffer delay or
   failure before the application retries IPv4.  Later connections can
   use applicable observations from the first attempt to avoid
   repeatedly preferring a recently failing or degraded IPv6 path.  This
   can significantly reduce repeated user-visible degradation that can
   happen without EDS.

   Second, although HEv3 and the EDS compatibility path can cover a
   broad class of applications, coverage may not be universal.
   Applications that do not use an HEv3-capable or other EDS-integrated
   networking facility may require additional measures.

   Third, lifetime connection-performance information can be obtained
   from the OS for TCP, but it may be unavailable for other transport
   protocols, especially when transport behavior is implemented entirely
   in user space.  Obtaining lifetime connection-performance information
   for such transport protocols requires case-by-case treatment.  The
   implementation decision is left to the developers.  If such
   information is unavailable, IPv6/IPv4 ordering can be based only on
   connection-establishment outcome, which is still better than the case
   without EDS.

6.  Standardization Considerations

   EDS may require work in multiple IETF Working Groups.

   The OS/platform HEv3 implementation profile and selective operational
   diagnostics are closely related to HEv3 behavior and could be
   developed in the HAPPY Working Group as extensions to, or companion
   documents for, HEv3.

   The compatibility behavior affecting getaddrinfo() and connect()
   would likely require work in the 6man Working Group, or another
   appropriate IETF venue, and coordination with operating-system and
   platform networking implementers.

Xiao                     Expires 5 January 2027                [Page 10]
Internet-Draft             Enhanced Dual Stack                 July 2026

   This document does not define new APIs or a mandatory storage model
   for local performance observations.  Its purpose is to identify the
   required functions and their relationship to one another.

7.  Security Considerations

   EDS incorporates HEv3 behavior where available.  The security
   considerations of [HEv3] apply to EDS.

   In the compatibility path, local observations and operational
   diagnostics can contain sensitive information about destination
   usage, failure patterns, interfaces, network context, and transport
   behavior.  Access to this information MUST be controlled, and
   exported information MUST be minimized and protected.  Telemetry
   export, if supported, MUST be controlled by local policy.

8.  IANA Considerations

   This document makes no request of IANA.

9.  References

9.1.  Normative References

   [HEv3]     Pauly, T., Schinazi, D., Jaju, N., and K. Ishibashi,
              "Happy Eyeballs Version 3: Better Connectivity Using
              Concurrency", Work in Progress, Internet-Draft, draft-
              ietf-happy-happyeyeballs-v3-04, 1 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-happy-
              happyeyeballs-v3-04>.

   [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/rfc/rfc2119>.

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <https://www.rfc-editor.org/rfc/rfc6724>.

   [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/rfc/rfc8174>.

9.2.  Informative References

Xiao                     Expires 5 January 2027                [Page 11]
Internet-Draft             Enhanced Dual Stack                 July 2026

   [GET-ADDR-PAIRS]
              Carpenter, B., "Get Address Pairs for Socket Programming
              in Python", GitHub Repository,
              <https://github.com/becarpenter/getapr>.

   [HE-REPORT]
              Martinez, J. P. and P. S. Tiesel, "Considerations for
              Happy Eyeballs Error Reporting", Work in Progress,
              Internet-Draft, draft-palet-happy-reporting-
              considerations-01, 18 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-palet-happy-
              reporting-considerations-01>.

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, DOI 10.17487/RFC3493, March 2003,
              <https://www.rfc-editor.org/rfc/rfc3493>.

   [RFC7381]  Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
              Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
              Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,
              <https://www.rfc-editor.org/rfc/rfc7381>.

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8305>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [RFC9621]  Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A.,
              Fairhurst, G., and C. S. Perkins, "Architecture and
              Requirements for Transport Services", RFC 9621,
              DOI 10.17487/RFC9621, January 2025,
              <https://www.rfc-editor.org/rfc/rfc9621>.

   [RFC9622]  Trammell, B., Ed., Welzl, M., Ed., Enghardt, R.,
              Fairhurst, G., Kühlewind, M., Perkins, C. S., Tiesel,
              P.S., and T. Pauly, "An Abstract Application Programming
              Interface (API) for Transport Services", RFC 9622,
              DOI 10.17487/RFC9622, January 2025,
              <https://www.rfc-editor.org/rfc/rfc9622>.

Xiao                     Expires 5 January 2027                [Page 12]
Internet-Draft             Enhanced Dual Stack                 July 2026

Acknowledgements

   Brian Carpenter and Nick Buraglio contributed to the
   [GET-ADDR-PAIRS]-related improvement.  Their feedback also helped
   shape the distinction between the compatibility path for existing
   applications and HEv3-based behavior for new or modified
   applications.

   Comments from David Schinazi, Tim Chown, Philipp Tiesel, Franck
   Martin, Mike Ackermann, and Gert Doering led to revisions and
   improvements of this draft.

Author's Address

   Xipeng Xiao
   Huawei Technologies Dusseldorf
   Email: xipengxiao@gmail.com

Xiao                     Expires 5 January 2027                [Page 13]