Skip to main content

Generalized IPv6 Tunnel (GIP6)
draft-li-rtgwg-generalized-ipv6-tunnel-04

Document Type Active Internet-Draft (individual)
Authors Zhenbin Li , Shuanglong Chen , Qiangzhou Gao , Shuai Zhang , Qingbang Xu
Last updated 2024-10-21
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-rtgwg-generalized-ipv6-tunnel-04
Network Working Group                                              Z. Li
Internet-Draft                                                   S. Chen
Intended status: Standards Track                                  Q. Gao
Expires: 24 April 2025                                            Huawei
                                                                S. Zhang
                                                            China Unicom
                                                                   Q. Xu
                                              Agricultural Bank of China
                                                         21 October 2024

                     Generalized IPv6 Tunnel (GIP6)
               draft-li-rtgwg-generalized-ipv6-tunnel-04

Abstract

   This document defines the generalized IPv6 tunnel based on the
   analysis of challenges of the existing problems of IP tunnels.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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 24 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Li, et al.                Expires 24 April 2025                 [Page 1]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Design Consideration  . . . . . . . . . . . . . . . . . . . .   4
   5.  Structure of a GIP6 Encapsulated Packet . . . . . . . . . . .   5
   6.  GIP6 for VXLAN  . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  GIP6 for GRE  . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  GIP6 for Other Existing IP Tunnels  . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Currently there are many types of IP tunnels, such as VXLAN and GRE.
   On IPv6 networks, it is hard to define extensions for all these
   tunnels to support new features.  On the other hand it is not
   recommended to extend new features based on the IPv4 data plane for
   these tunnels.  This document analyzes the problems of IP tunnels and
   defines a generalized IPv6 tunnel to support the new features.

2.  Terminology

   APN: Application-aware Networking

   GRE: Generic Routing Encapsulation

   IPv4: Internet Protocol version 4

   IPv6: Internet Protocol version 6

   IOAM: In-situ Operations, Administration, and Maintenance

   ISATAP: Intra-Site Automatic Tunnel Addressing Protocol

Li, et al.                Expires 24 April 2025                 [Page 2]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   L2TPv3: Layer Two Tunneling Protocol Version 3

   MPLS: Multiprotocol Label Switching

   NVO3: Network Virtualization Overlays

   SRv6: Segment Routing IPv6

   SID: SR Identification

   VNI: VXLAN Network Identifier

   VXLAN: Virtual eXtensible Local Area Network

3.  Problem Statement

   There have been many types of IP tunnels, including:

   - GRE Tunnels: it is defined in [RFC2784].

   - IP in IP Tunnels: it is defined in [RFC1853].

   - L2TPv3 Tunnels: it is defined in [RFC3931].

   - ISATAP Tunnels: it is defined in [RFC4214].

   - IPv4/IPv6 over IPv6 (4over6) Tunnels: it is defined in[RFC2473].

   - VXLAN Tunnels: it is defined in [RFC7348].

   - NVGRE Tunnels: it is defined in [RFC7637].

   - MPLS over UDP: it is defined in [RFC7510].

   - VXLAN-GPE (Generic Protocol Extension for VXLAN) Tunnels: it is
   defined in [I-D.ietf-nvo3-vxlan-gpe].

   Currently many new features are emerging and the corresponding
   encapsulations over the IPv6 are defined:

   - [I-D.ietf-6man-ipv6-alt-mark] defines IPv6 encapsulation for
   Alternate Marking.

   - [I-D.ietf-ippm-ioam-ipv6-options] defines IPv6 encapsulation for
   IOAM.

Li, et al.                Expires 24 April 2025                 [Page 3]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   - [I-D.dong-6man-enhanced-vpn-vtn-id] defines the IPv6 encapsulation
   used to determine resource isolation.

   - [I-D.li-apn-ipv6-encap] defines the IPv6 encapsulation of an APN.

   If the existing IP tunnels need to support new features such as
   Alternate Marking, IOAM, resource isolation, and APN, the following
   problems exist:

   - All of the IP tunnels mentioned above need to be extended
   accordingly, resulting in a lot of standardization work.

   - It is hard to keep the consistency between IPv4 and IPv6 for these
   IP tunnels (except IPv4 transition tunnels) since the possible
   extensions are recommended to be only done over the IPv6.

   - IPv6 can directly support some functions of these IP tunnels which
   cannot be done over the IPv4.  This means such functions becomes
   redundant over the IPv6.  For example, VXLAN takes use of the UDP to
   support ECMP.  However for the IPv6 VXLAN, the Flow Label in the IPv6
   header can also be used to support ECMP.

   - Some IP tunnels such as VXLAN and GRE have their own headers.  If
   these tunnels need to support new features over the IPv6, there will
   face the challenge of the choice between reusing the exiting IPv6
   encapsulations for these new features based on the IPv6 extension
   header and define new extensions based on their own tunnel headers.

   -- If the tunnel header is extended, it will be redundant with the
   existing IPv6 encapsulation for the new features based on the IPv6
   extension header.

   -- For some existing IP tunnels (such as IP in IP) that do not have
   their own headers, they have to reuse the IPv6 encapsulations for
   these new features based the IPv6 header. extensions need to be
   redefined in the IPv6 extension header.  As a result, their
   extensions may be different from that of the IP tunnels which have
   their own headers.

4.  Design Consideration

   In order to solve the above problems, the following choice can be
   taken into account:

   1.  It is not recommended to support the new features over the IPv4
   for these IP tunnels.

Li, et al.                Expires 24 April 2025                 [Page 4]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   2.  It is to reuse the existing IPv6 encapsulations based on the IPv6
   extension header when support the new features for these IP tunnels
   over the IPv6.

   If these IP tunnels takes use of the existing encapsulations based on
   the IPv6 extension header, for the IP tunnels which have their own
   headers, there are two possible options to cope with their own
   headers:

   Option 1: Tunnels use the IPv6 extension headers to support new
   features and their own headers are retained.

   This Option has the following problems:

   1.  Redundant Functions: For example, the UDP-based IP tunnel can
   directly use IPv6 flow label to implement ECMP.

   2.  Separated process of tunnel functions: Some functions use IPv6
   extension headers and some functions use headers of tunnels.  As a
   result, tunnel processing is separated and complex.

   3.  If the IPSec extension header is used, the tunnel's own header
   maybe encrypted and unable to be parsed when necessary process is
   needed.

   The advantage of the option is that the existing tunnel headers are
   retained and it is easy to implement the smooth evolution.  In
   addition, If the functions of the existing tunnel header is only
   processed at the destination node, it is easy to be retained because
   the IPSec extension header has little effect on the retained tunnel
   headers.

   Option 2: Define a generalized IPv6 tunnel that contains the IPv6
   extension header which not only reuses the existing IPv6
   encapsulations to support new features, but also introduces the new
   extensions to support the necessary functions of their own headers.

   With this option, all the instructions are encapsulated in the IPv6
   extension headers which will facilitate the unifying process.  This
   option is recommended in the document.

5.  Structure of a GIP6 Encapsulated Packet

   The Generalized IPv6 (GIP6) tunnel is defined to use the IPv6 header
   and IPv6 extension header to support both existing IP tunnels
   functions and new features.

   A GIP6 encapsulated packet has the following format:

Li, et al.                Expires 24 April 2025                 [Page 5]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   + - - - - - - - - - - - - - - - - - - - - - - - - - -+     ----
   |                IPv6 Header                         |      |
   + - - - - - - - - - - - - - - - - - - - - - - - - - -+     GIP6
   |               IPv6 Extension Header                | Encapsulation
   |       (Encapsulations of new features +            |      |
   | Encapsulations of functions of existing IP tunnels)|      |
   + - - - - - - - - - - - - - - - - - - - - - - - - - -+     ----
   |                Payload packet                      |
   + - - - - - - - - - - - - - - - - - - - - - - - - - -+
                  Figure 1. GIP6 Encapsulation

   Different types of tunneled payloads, such as IPv4, IPv6, MPLS,
   Ethernet, etc., can be indicated by the IPv6 Next Header.

   Packets encapsulated with the GIP6 tunnel can directly support new
   functions based on existing encapsulation, including Alternate-
   Marking, IOAM, Resource-Isolation, and APN.

   If the functions of the existing tunnel header is only processed at
   the destination node, the tunnel header can be retained and the
   format of the GIP6 encapsulated packet is shown in the following
   figure.

    + - - - - - - - - - - - - - - - - - - - - - - - - - -+     ----
    |                IPv6 Header                         |      |
    + - - - - - - - - - - - - - - - - - - - - - - - - - -+     GIP6
    |               IPv6 Extension Header                | Encapsulation
    |         (Encapsulations of new features)           |      |
    + - - - - - - - - - - - - - - - - - - - - - - - - - -+     ----
    |           Existing IP Tunnel Headers               |
    + - - - - - - - - - - - - - - - - - - - - - - - - - -+
    |                Payload packet                      |
    + - - - - - - - - - - - - - - - - - - - - - - - - - -+
 Figure 2. GIP6 Encapsulation with Existing IP Tunnel Headers

6.  GIP6 for VXLAN

   To support existing VXLAN functions, the GIP6 tunnel is extended as
   follows:

   1.  The function of the UDP is replaced by the flow label of the IPv6
   header in the GIP6 tunnel.  To ensure compatibility, the value of the
   flow label calculated for the purpose of ECMP SHOULD be the same as
   that of the source port of the UDP.

   2.  Definition of the VN Option

Li, et al.                Expires 24 April 2025                 [Page 6]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   A new option called VN Option is defined to carry the VXLAN header
   information.  The VN Option MUST only be encapsulated in the
   Destination Options Header (DOH).

   The following figure shows the data fields format of the VN option:

   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
                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                             |
   |                VXLAN Header (8 Bytes)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Figure 3. VN Option

   The VN Option contains the following fields:

   * Option Type: 8-bit selector.  VN option.  Value TBD by IANA.

   * Opt Data Len: 8-bit unsigned integer.  Length of the option, in
   octets, excluding the Option Type and Option Length fields.  This
   field MUST be set to 8.

   * Option Data: 64-bits VXLAN Header Information.

   The following figure shows the definition of VXLAN headers in
   [RFC7358].  For the detailed definition of the data fields, please
   refer to [RFC7358].

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VXLAN Flags |                  Reserved                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       VXLAN Network Identifier(VNI)           |  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 4. VXLAN headers

7.  GIP6 for GRE

   A new option called GRE Option is defined to carry the GRE header
   information.  The GRE Option MUST only be encapsulated in the
   Destination Options header (DOH).

Li, et al.                Expires 24 April 2025                 [Page 7]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   The definition of a new TLV for the Options Extension Headers,
   carrying the data fields dedicated to the GRE information, is
   reported below.

   The following figure shows the data fields format of the GRE option.

   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
                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                             |
   |                GRE Header (16 Bytes)                        |
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 5. GRE Option

   The GRE Option contains the following fields:

   * Option Type: 8-bit selector.  GRE option.  Value TBD by IANA.

   * Opt Data Len: 8-bit unsigned integer.  Length of the option, in
   octets, excluding the Option Type and Option Length fields.  This
   field MUST be set to 16.

   * Option Data: 128-bits GRE Header Information.

   The following figure shows the definition of the GRE header in
   [RFC2890].  For the detailed definition of the data fields, please
   refer to [RFC2784] and [RFC2890].

        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |C| |K|S| Reserved0       | Ver |         Protocol Type         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Checksum (optional)      |       Reserved1 (Optional)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Key (optional)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Sequence Number (Optional)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Figure 6. GRE Header

   Note: The function of the Protocol Type in the GRE header can be
   replaced by that of the NH in the IPv6 header or IPv6 extension
   header.

Li, et al.                Expires 24 April 2025                 [Page 8]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

8.  GIP6 for Other Existing IP Tunnels

   They will be defined in the future version.

9.  Security Considerations

   TBD.

10.  Contributors

   The following people also gave a substantial contribution to the
   content of this document and should be considered as Contributor:

   Haibo Wang, Huawei Technologies, rainsword.wang@huawei.com

11.  IANA Considerations

   The Option Type should be assigned in IANA's "Destination Options"
   registry.

   This draft requests the following IPv6 Option Type assignment from
   the Destination Options sub-registry of Internet Protocol Version 6
   (IPv6) Parameters (https://www.iana.org/assignments/
   ipv6-parameters/).

   Hex Value     Binary Value        Description           Reference
                act  chg  rest
   ----------------------------------------------------------------
    TBD         00    0   TBD          VN               [This draft]
    TBD         00    0   TBD          GRE              [This draft]
                     Figure 7. IANA Considerations

12.  References

   [I-D.dong-6man-enhanced-vpn-vtn-id]
              Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
              "Carrying Virtual Transport Network (VTN) Identifier in
              IPv6 Extension Header", Work in Progress, Internet-Draft,
              draft-dong-6man-enhanced-vpn-vtn-id-06, 24 October 2021,
              <https://datatracker.ietf.org/doc/html/draft-dong-6man-
              enhanced-vpn-vtn-id-06>.

Li, et al.                Expires 24 April 2025                 [Page 9]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   [I-D.ietf-6man-ipv6-alt-mark]
              Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate-Marking Method",
              Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
              alt-mark-17, 27 September 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              ipv6-alt-mark-17>.

   [I-D.ietf-ippm-ioam-ipv6-options]
              Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
              Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
              ipv6-options-12, 7 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
              ioam-ipv6-options-12>.

   [I-D.ietf-nvo3-vxlan-gpe]
              Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
              Extension for VXLAN (VXLAN-GPE)", Work in Progress,
              Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              nvo3-vxlan-gpe-13>.

   [I-D.li-apn-ipv6-encap]
              Li, Z., Peng, S., and C. Xie, "Application-aware IPv6
              Networking (APN6) Encapsulation", Work in Progress,
              Internet-Draft, draft-li-apn-ipv6-encap-07, 10 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-li-apn-ipv6-
              encap-07>.

   [RFC1853]  Simpson, W., "IP in IP Tunneling", RFC 1853,
              DOI 10.17487/RFC1853, October 1995,
              <https://www.rfc-editor.org/info/rfc1853>.

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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <https://www.rfc-editor.org/info/rfc2473>.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <https://www.rfc-editor.org/info/rfc2784>.

Li, et al.                Expires 24 April 2025                [Page 10]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, DOI 10.17487/RFC2890, September 2000,
              <https://www.rfc-editor.org/info/rfc2890>.

   [RFC3931]  Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
              "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
              RFC 3931, DOI 10.17487/RFC3931, March 2005,
              <https://www.rfc-editor.org/info/rfc3931>.

   [RFC4214]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", RFC 4214, DOI 10.17487/RFC4214, October 2005,
              <https://www.rfc-editor.org/info/rfc4214>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

   [RFC7358]  Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label
              Advertisement Discipline for LDP Forwarding Equivalence
              Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October
              2014, <https://www.rfc-editor.org/info/rfc7358>.

   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", RFC 7510,
              DOI 10.17487/RFC7510, April 2015,
              <https://www.rfc-editor.org/info/rfc7510>.

   [RFC7637]  Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
              Virtualization Using Generic Routing Encapsulation",
              RFC 7637, DOI 10.17487/RFC7637, September 2015,
              <https://www.rfc-editor.org/info/rfc7637>.

Authors' Addresses

   Zhenbin Li
   Huawei
   156 Beiqing Road
   Beijing,100095
   P.R. China
   Email: lizhenbin@huawei.com

Li, et al.                Expires 24 April 2025                [Page 11]
Internet-Draft           Generalized IPv6 Tunnel            October 2024

   Shuanglong Chen
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China
   Email: chenshuanglong@huawei.com

   Qiangzhou Gao
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China
   Email: gaoqiangzhou@huawei.com

   Shuai Zhang
   China Unicom
   Beijing,100048
   P.R. China
   Email: zhangs366@chinaunicom.cn

   Qingbang Xu
   Agricultural Bank of China
   P.R. China
   Email: michbang@163.com

Li, et al.                Expires 24 April 2025                [Page 12]