Communication methods and devices

By using QUIC connections in a distributed gateway network to encrypt messages between the DHCP relay and the DHCP server, the complexity of DHCP relay encryption configuration and the high overhead of IPSec are solved, achieving more efficient encryption protection and reducing operation and maintenance costs.

CN120151086BActive Publication Date: 2026-04-03NEW H3C TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-04-10
Publication Date
2026-04-03

AI Technical Summary

Technical Problem

In distributed gateway networking, the encryption requirements between DHCP relays and DHCP servers are complex, difficult to configure and manage, and IPSec encryption has a large overhead, resulting in high performance consumption and long latency.

Method used

Message encryption is achieved using QUIC connections. A QUIC connection is established between the DHCP management relay and the DHCP server. Each DHCP relay uses a unique flow identifier to achieve message encryption and decryption, simplifying configuration and avoiding the complexity of IPSec.

Benefits of technology

It reduces the configuration complexity of IPSec encryption, prevents packets from being eavesdropped on and tampered with, lowers hardware and maintenance costs, and avoids congestion by using multiplexed flow identifiers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120151086B_ABST
    Figure CN120151086B_ABST
Patent Text Reader

Abstract

This application provides a communication method and apparatus, which receives a first DHCP protocol message sent by a DHCP client; sends a first QUIC message to a DHCP server via a QUIC connection, the first QUIC message including a flow identifier; if a second QUIC message including a flow identifier is received from the DHCP server and a second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then the second QUIC message is decrypted according to a key, and the decrypted second QUIC message is verified; if the verification passes and a temporary entry corresponding to the DHCP client exists, then a binding entry corresponding to the DHCP client is generated according to the temporary entry, and a second DHCP protocol message is sent to the DHCP client; wherein, the flow identifier is assigned by the DHCP management relay, and the flow identifier assigned by each DHCP relay in the distributed network is different.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0002] As network scale continues to expand and business needs become increasingly complex, centralized gateway architecture has gradually exposed many problems, such as performance bottlenecks, insufficient scalability, single points of failure, and complex management. This has also driven the development of distributed gateway networking.

[0003] Ethernet Virtual Private Network (EVPN) and Virtual Extensible Local Area Network (VXLAN) is a Layer 2 VPN technology. Its control plane uses MP-BGP to advertise EVPN routing information, while its data plane uses VXLAN encapsulation to forward packets. EVPN VXLAN identifies VXLAN networks using VXLAN IDs and maintains an independent MAC address table for each VXLAN network to achieve Layer 2 communication within the same VXLAN network and Layer 2 isolation between different VXLAN networks. By deploying an EVPN VXLAN gateway in the network, Layer 3 communication between different VXLAN networks and Layer 3 communication between VXLAN networks and external networks can also be achieved.

[0004] EVPN VXLAN gateways include centralized gateways and distributed gateways. A centralized gateway refers to a network with a single VTEP device acting as the EVPN gateway, handling all traffic between different VXLANs and traffic from VXLANs accessing external networks. A distributed gateway involves multiple VTEP devices acting as EVPN gateways, performing Layer 3 forwarding of traffic from local sites, thus reducing the load on the main gateway. In a distributed gateway network, a border gateway device is typically also deployed for communication with the external network.

[0005] Dynamic Host Configuration Protocol (DHCP) uses a client / server model, where the server dynamically assigns IP addresses and other network configuration parameters to network devices. DHCPv6 (Dynamic Host Configuration Protocol for IPv6) is designed for IPv6 addressing schemes and is used to assign IPv6 prefixes, IPv6 addresses, and other network configuration parameters to hosts.

[0006] When the server and client are not within the same link range, they cannot communicate directly and need to use a DHCP relay to forward messages. Deploying a DHCP relay avoids deploying a DHCP server for every link range, saving costs and facilitating centralized management.

[0007] Currently, network devices within a distributed gateway network can act as DHCP relays. For example... Figure 1 As shown, Figure 1 This is a network diagram illustrating how to support DHCP relay in an existing distributed gateway network. Figure 1 In this configuration, leaf1, leaf2, and leaf3 can all act as DHCP relays, and any one of the leaf nodes can process the online message from a DHCP client.

[0008] Meanwhile, distributed gateway networking also supports the encryption requirements of DHCP relays for DHCP messages. The existing RFC 8213 protocol specifies optional requirements for supporting IPsec authentication and encryption between relays and servers, and recommends that operators use IPsec to encrypt and protect the interaction messages between relays and servers. However, IPsec configuration is relatively complex, requiring the definition of security policies, security associations (SAs), encryption algorithms, authentication mechanisms, etc. Especially in large networks, configuring and managing multiple IPsec tunnels increases the difficulty of operation and maintenance; secondly, if the IP address of a network device changes, it is necessary to reconfigure or negotiate the SA; finally, IPsec encryption has a large overhead and consumes significant performance, resulting in greater latency. Summary of the Invention

[0009] In view of this, this application provides a communication method and apparatus to provide a better protection method for message encryption between DHCP relays and DHCP servers, and between DHCP relays in a distributed gateway network.

[0010] In a first aspect, this application provides a communication method applied to a first DHCP relay within a distributed network, wherein the first DHCP relay is any DHCP relay within the distributed network, and the DHCP management relay in the distributed network establishes a QUIC connection with a DHCP server, the method comprising:

[0011] Receive the first DHCP protocol message sent by the DHCP client;

[0012] Through the QUIC connection, a first QUIC message is sent to the DHCP server. The first QUIC message includes a flow identifier and is obtained by encrypting the first DHCP protocol message according to the key corresponding to the QUIC connection.

[0013] If a second QUIC message including the flow identifier is received from the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then the second QUIC message is decrypted according to the key, and the decrypted second QUIC message is verified.

[0014] If the verification passes and a temporary entry corresponding to the DHCP client exists, then based on the temporary entry, a binding entry corresponding to the DHCP client is generated, and the second DHCP protocol message is sent to the DHCP client.

[0015] The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

[0016] Secondly, this application provides a communication method applied to a DHCP server, wherein the DHCP server has established a QUIC connection with a DHCP management relay in a distributed network, and the distributed network further includes a first DHCP relay, which is any DHCP relay in the distributed network. The method includes:

[0017] Through the QUIC connection, a first QUIC message sent by the first DHCP relay is received, the first QUIC message including a flow identifier;

[0018] If the first DHCP protocol message is encapsulated in the first QUIC message, then the first QUIC message is decrypted according to the key corresponding to the QUIC connection, and the decrypted first QUIC message is verified.

[0019] If the verification passes and the first DHCP protocol message is a first type message, a second QUIC message is generated. The second QUIC message includes the flow identifier and the second DHCP protocol message, which is a response message to the first DHCP protocol message.

[0020] The second QUIC message is sent to the first DHCP relay via the QUIC connection.

[0021] The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

[0022] Thirdly, this application provides a communication device applied to a first DHCP relay within a distributed network, wherein the first DHCP relay is any DHCP relay within the distributed network, and the DHCP management relay in the distributed network establishes a QUIC connection with a DHCP server. The device includes:

[0023] The receiving unit is used to receive the first DHCP protocol message sent by the DHCP client;

[0024] The sending unit is configured to send a first QUIC message to the DHCP server via the QUIC connection. The first QUIC message includes a flow identifier and is obtained by encrypting the first DHCP protocol message using the key corresponding to the QUIC connection.

[0025] The verification unit is configured to, if the receiving unit receives a second QUIC message including the flow identifier sent by the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then decrypt the second QUIC message according to the key and verify the decrypted second QUIC message.

[0026] The generation unit is used to generate a binding entry corresponding to the DHCP client based on the temporary entry if the verification passes and a temporary entry corresponding to the DHCP client exists.

[0027] The sending unit is further configured to send the second DHCP protocol message to the DHCP client;

[0028] The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

[0029] Fourthly, this application provides a communication device applied to a DHCP server, wherein the DHCP server has established a QUIC connection with a DHCP management relay in a distributed network, and the distributed network further includes a first DHCP relay, which is any DHCP relay in the distributed network. The device includes:

[0030] The receiving unit is configured to receive a first QUIC message sent by the first DHCP relay via the QUIC connection, wherein the first QUIC message includes a flow identifier;

[0031] The verification unit is used to decrypt the first QUIC message according to the key corresponding to the QUIC connection if the first DHCP protocol message is encapsulated in the first QUIC message, and to verify the decrypted first QUIC message.

[0032] The generation unit is configured to generate a second QUIC message if the verification passes and the first DHCP protocol message is a first type message. The second QUIC message includes the flow identifier and the second DHCP protocol message, which is a response message to the first DHCP protocol message.

[0033] The sending unit is configured to send the second QUIC message to the first DHCP relay via the QUIC connection;

[0034] The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

[0035] Fifthly, this application provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, which in turn cause the processor to perform the method provided in the first aspect of this application.

[0036] In a sixth aspect, this application provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, which in turn cause the processor to perform the method provided in the second aspect of this application.

[0037] Therefore, using the communication method and apparatus provided in this application, the first DHCP relay receives a first DHCP protocol message sent by a DHCP client; through a QUIC connection, the first DHCP relay sends a first QUIC message to a DHCP server, the first QUIC message including a flow identifier, the first QUIC message being obtained by encrypting the first DHCP protocol message according to the key corresponding to the QUIC connection; if a second QUIC message including a flow identifier is received from the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then according to the key, the first DHCP relay decrypts the second QUIC message and verifies the decrypted second QUIC message; if the verification passes and a temporary entry corresponding to the DHCP client exists, then according to the temporary entry, the first DHCP relay generates a binding entry corresponding to the DHCP client and sends a second DHCP protocol message to the DHCP client; wherein, the flow identifier is allocated by the DHCP management relay and the flow identifier allocated by each DHCP relay in the distributed network is different.

[0038] Thus, in a distributed network, a QUIC connection is established between the DHCP management relay and the DHCP server. Each DHCP relay can use this QUIC connection to send encrypted messages to the DHCP server. This avoids message eavesdropping and tampering; reduces the configuration complexity of IPSec encryption; allows each DHCP relay to use a different flow identifier for multiplexing, avoiding congestion; and lowers hardware and maintenance costs. Attached Figure Description

[0039] Figure 1 A network diagram illustrating the existing distributed gateway network supporting DHCP relay;

[0040] Figure 2 A flowchart illustrating a communication method provided in an embodiment of this application;

[0041] Figure 3 A flowchart illustrating another communication method provided in an embodiment of this application;

[0042] Figure 4 A structural diagram of a communication device provided in an embodiment of this application;

[0043] Figure 5 Another communication device structure diagram provided in the embodiments of this application;

[0044] Figure 6 The network device hardware structure provided in the embodiments of this application. Detailed Implementation

[0045] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0046] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0047] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0048] The communication method provided in the embodiments of this application will be described in detail below. See also... Figure 2 , Figure 2 This is a flowchart illustrating a communication method provided in an embodiment of this application. The method is applied to a first DHCP relay, which is located between a DHCP client and a DHCP server. The communication method provided in this embodiment may include the following steps.

[0049] Step 210: Receive the first DHCP protocol message sent by the DHCP client;

[0050] Specifically, the first DHCP relay receives the first DHCP protocol message. This first DHCP protocol message is sent by the DHCP client.

[0051] In this embodiment, there are multiple first DHCP relays, forming a distributed network. A DHCP client connects to any one of the first DHCP relays, and each first DHCP relay connects to the DHCP server via a Spine connection. From the perspective of the DHCP server, all first DHCP relays are considered as a single device.

[0052] like Figure 1 As shown, leaf1, leaf2, and leaf3 are all first DHCP relays, forming a distributed network. DHCP client 1 connects to leaf1, and DHCP client 2 connects to leaf3. Each leaf connects to the DHCP server via a spine.

[0053] In this embodiment, the DHCP client may specifically be a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) client or a DHCPv6 client.

[0054] When the DHCP client is a DHCPv4 client, the first DHCP relay is specifically a DHCPv4 relay, and the DHCP server is specifically a DHCPv4 server; when the DHCP client is a DHCPv6 client, the first DHCP relay is specifically a DHCPv6 relay, and the DHCP server is specifically a DHCPv6 server.

[0055] The communication schemes described in the embodiments of this application below are applicable to both DHCPv4 (client, relay, server) and DHCPv6 (client, relay, server), and will be referred to as DHCP for ease of description thereafter.

[0056] In this embodiment, the first DHCP relay in a distributed network is used as an example. The first DHCP relay receives the first DHCP protocol message sent by the DHCP client.

[0057] In this embodiment of the application, multiple first DHCP relays within the distributed network will elect a DHCP management relay. This DHCP management relay can establish, maintain, and manage a UDP-based modern transport layer protocol (Quick UDP Internet Connections, QUIC) connection with the DHCP server. Specifically, when establishing a QUIC connection between the DHCP management relay and the DHCP server, the DHCP management relay acts as a QUIC client, and the DHCP server acts as a QUIC server. After configuring the QUIC function locally, the DHCP management relay attempts to establish, maintain, and manage a QUIC connection with the DHCP server.

[0058] It is understandable that during the establishment of a QUIC connection between the two devices, the verification of certificates, negotiation of encryption algorithms, versions, keys, etc., are carried out in accordance with the existing QUIC protocol, and will not be repeated here. In this embodiment of the application, multiple first DHCP relays in the distributed network will elect a DHCP management relay, and the DHCP management relay will establish a QUIC connection with the DHCP server. Since each first DHCP relay is configured with the same IP address, each first DHCP relay can reuse the QUIC connection.

[0059] The process of electing a DHCP management relay will be described in subsequent embodiments and will not be repeated here.

[0060] It is understandable that the first DHCP relay in this step can be a DHCP management relay or a non-DHCP management relay.

[0061] Step 220: Send a first QUIC message to the DHCP server through the QUIC connection. The first QUIC message includes a flow identifier and is obtained by encrypting the first DHCP protocol message with the key corresponding to the QUIC connection.

[0062] Specifically, according to the description of step 210, after receiving the first DHCP protocol message, the first DHCP relay continues to forward it to the next hop device.

[0063] In this embodiment, the next-hop device of the first DHCP relay is a DHCP server. As mentioned above, a QUIC connection has been established between the DHCP management relay and the DHCP server according to the existing QUIC protocol, and any first DHCP relay can reuse this QUIC connection. Therefore, in this step, regardless of whether the first DHCP relay is a DHCP management relay or a non-DHCP management relay, messages can be sent to the DHCP server via the QUIC connection.

[0064] According to the first DHCP protocol message, the first DHCP relay generates a first QUIC message, which is obtained by the first DHCP relay encrypting the first DHCP protocol message with the key corresponding to the QUIC connection.

[0065] It is understandable that the first DHCP relay can first generate a new DHCP protocol message based on the first DHCP protocol message (for example, it can be called a third DHCP protocol message, here "third" is used to distinguish it from other DHCP protocol messages, it can also be "second" or "fourth"). This third DHCP protocol message can be specifically obtained by the first DHCP relay after processing according to the existing DHCP protocol (for example, adding an option field (option82), etc., to the first DHCP protocol message). Since the first DHCP relay generates the third DHCP protocol message in the same way as the existing process, this embodiment of the application will not describe it in detail, and will still refer to it as the first DHCP protocol message.

[0066] According to the existing QUIC protocol, the first DHCP relay generates the first QUIC message, which includes a flow identifier and a first DHCP protocol message. After receiving the first QUIC message, the first DHCP relay sends it to the DHCP server via a QUIC connection. It can be understood that in practical applications, QUIC messages are usually assumed to be encrypted.

[0067] The following is a brief explanation of QUIC messages.

[0068] QUIC messages consist of two parts: a common header and a payload. The common header is further divided into a long header and a short header.

[0069] The long header is used during the connection establishment phase (such as the initial handshake and version negotiation) and includes the following fields: Indicator bit field: fixed at 1, indicating a long header. The indicator bit is 1 bit long; Type field: indicates the type of message. The Type field is 4 bits long; Version number (Ver) field: indicates the QUIC protocol version. The Ver field is 4 bytes long; Destination CID Length (DCID Len) field: indicates the length of the Destination CID (DCID). The DCID Len field is 1 byte long; DCID field: indicates the receiver. The DCID field length is variable; Source CID Length (SCID Len) field: indicates the length of the Source CID (SCID). The SCID Len field is 1 byte long; SCID field: indicates the sender. The SCID field length is variable; Packet Number field: used for packet ordering and packet loss detection. The Packet Number field length is variable, ranging from 1 to 4 bytes; Payload Length field: indicates the length of the payload portion. The payload length field is 2 bytes long.

[0070] The short header is used for regular data transmission after the connection is established. It has a more compact format and includes the following fields: Indicator bit field: a fixed value of 0 indicates a short header. The indicator bit is 1 bit long; Reserved bit field: reserved and unused. The reserved bit is 7 bits long; DCID field: indicates the receiver. The DCID field has a variable length; Packet Number field: used for packet sorting and packet loss detection. The packet number field has a variable length, ranging from 1 to 4 bytes.

[0071] The payload of a QUIC message can contain one or more frames, each representing a data transmission or control operation. The general structure of a frame includes two parts: a type and frame data. The type indicates the frame type and is 1 byte in length; the structure of the frame data varies depending on the frame type. Frame types include STREAM, ACK, CRYPTO, PADDING, and CONNECTION_CLOSE.

[0072] In this embodiment of the application, the frame data includes a stream ID field and a stream data field. The stream ID field is used to carry the stream identifier, and the stream data field is used to carry the actual application data, such as a first DHCP protocol message.

[0073] In the QUIC protocol, stream identifiers are assigned and managed by the initiating end (QUIC client or QUIC server). A stream identifier is a unique identifier used in the QUIC protocol to identify different data streams; it is assigned sequentially by the initiating end, usually in ascending order; it follows a parity rule: streams initiated by a QUIC client use even-numbered stream identifiers, while streams initiated by a QUIC server use odd-numbered stream identifiers; the lowest two bits of the stream identifier for bidirectional streams are 0b00 or 0b01, and the lowest two bits of the stream identifier for unidirectional streams are 0b10 or 0b11.

[0074] For example, a QUIC client initiates a bidirectional stream with a stream identifier of 0 (even number); a QUIC server initiates a unidirectional stream with a stream identifier of 1 (odd number); and a QUIC client then initiates another unidirectional stream with a stream identifier of 2 (even number).

[0075] In this embodiment of the application, the flow identifier is assigned by the DHCP management relay so that the flow identifier of each first DHCP relay is unique and corresponds to the Router identifier of each first DHCP relay.

[0076] The frame data also includes an offset field and a length field. The offset field indicates the offset of the current data in the stream; the length field indicates the length of the subsequent stream data.

[0077] In this embodiment, the first DHCP relay fills the allocated flow identifier into the flow identifier field and fills the first DHCP protocol message into the flow data field. Then, the payload is encrypted using the key corresponding to the QUIC connection to obtain the first QUIC message.

[0078] It should be noted that after the first DHCP relay receives the first QUIC message, it encapsulates a UDP header on the outer layer of the first QUIC message. The port number included in the UDP header is set to either 50003 or 50004. Here, 50003 indicates DHCPv4 over QUIC, and 50004 indicates DHCPv6 over QUIC.

[0079] Since the DHCP management relay in the distributed network has established a QUIC connection with the DHCP server, this QUIC connection can be reused by each DHCP relay in the distributed network. Understandably, before a DHCP relay uses the QUIC connection, the DHCP management relay synchronizes the QUIC connection's attribute information to other DHCP relays in the distributed network via Border Gateway Protocol (BGP) Ethernet Virtual Private Network (EVPN) messages. This allows other DHCP relays to obtain the QUIC connection's attribute information, including the QUIC session identifier, QUIC connection address, QUIC connection port, QUIC session key, QUIC session transmission parameters, and the mapping between all router identifiers and flow identifiers within the network.

[0080] In subsequent embodiments, the attribute information of the DHCP management relay synchronization QUIC connection will be described in detail, and will not be repeated here.

[0081] Understandably, after receiving the first QUIC message, the DHCP server first checks whether the first QUIC message encapsulates the first DHCP protocol message. If the first DHCP protocol message is not encapsulated in the first QUIC message, the DHCP server discards the first QUIC message. If the first DHCP protocol message is encapsulated in the first QUIC message, the server uses the key associated with the QUIC connection to decrypt the first QUIC message and then verifies the decrypted message. If the verification passes, the server identifies the type of the first DHCP protocol message. If it is a first-type message, it is processed according to the DHCPv4 / DHCPv6 protocol and a second QUIC message is sent back via the QUIC connection. If the verification fails, the first QUIC message is discarded.

[0082] During the processing of the first QUIC message, the DHCP server also obtains the flow identifier from the first QUIC message. When generating the second QUIC message, the DHCP server continues to fill the flow identifier field included in the second QUIC message with the flow identifier obtained from the first QUIC message. The structure of the second QUIC message is the same as that of the first QUIC message, and will not be repeated here. For details on the specific processing procedures of the DHCP server for the first and second QUIC messages, please refer to the description of the following embodiments.

[0083] Step 230: If a second QUIC message including the flow identifier is received from the DHCP server and the DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then the second QUIC message is decrypted according to the key, and the decrypted second QUIC message is verified.

[0084] Specifically, according to the description of step 220, if the first DHCP relay receives a second QUIC message including a flow identifier sent by the DHCP server, the first DHCP relay first identifies whether the second QUIC message encapsulates a second DHCP protocol message generated by the DHCP server.

[0085] Optionally, if the second DHCP protocol message is not encapsulated in the second QUIC message, the first DHCP relay discards the second QUIC message.

[0086] If the second DHCP protocol message is encapsulated within the second QUIC message, the first DHCP relay first decrypts the second QUIC message using the key. Then, the first DHCP relay verifies the decrypted second QUIC message.

[0087] Understandably, the first DHCP relay can verify the second QUIC message according to the existing QUIC protocol. The verification process is briefly described below.

[0088] 1): Parsing the message header

[0089] Extract unencrypted fields (e.g., connection ID, message number, etc.) from the QUIC message; determine the type of the QUIC message (e.g., Initial, Handshake, Short Header, etc.).

[0090] 2): Determine the encryption key

[0091] The QUIC protocol specifies the use of different encryption keys to encrypt different types of messages: Initial messages are encrypted using the Initial Key; Handshake messages are encrypted using the Handshake Key; and 1-RTT messages are encrypted using the Application Data Key. The appropriate key can be selected based on the message type.

[0092] 3): Decrypt the payload

[0093] The payload is decrypted using a selected key and encryption algorithm (e.g., AES-GCM or ChaCha20-Poly1305). The decryption process includes: extracting the ciphertext and authentication tag; and decrypting the ciphertext using the key and initialization vector (IV) to obtain the plaintext.

[0094] 4): Verify integrity

[0095] The integrity of the decrypted plaintext is verified using an authentication tag. The verification process includes: recalculating the authentication tag using the key and initialization vector (IV); comparing the calculated authentication tag with the authentication tag in the QUIC message; if they match, the QUIC message is determined to be intact and untampered with; otherwise, the QUIC message is discarded.

[0096] 5): Process the decrypted data

[0097] If decryption and verification are successful, the decrypted data is uploaded to the upper-layer protocol (e.g., HTTP / 3) for processing. If decryption or verification fails, the error is logged and the QUIC message is discarded.

[0098] According to the above verification process, the first DHCP relay verifies the decrypted second QUIC message.

[0099] Optionally, if the verification fails, the first DHCP relay discards the second QUIC message; if the verification passes, the first DHCP relay executes step 140.

[0100] Step 240: If the verification passes and a temporary entry corresponding to the DHCP client exists, then based on the temporary entry, generate a binding entry corresponding to the DHCP client and send the second DHCP protocol message to the DHCP client.

[0101] Specifically, according to the description of step 230, if the verification of the decrypted second QUIC message passes, the first DHCP relay obtains the second DHCP protocol message from the payload portion of the decrypted second QUIC message, and obtains the Media Access Control (MAC) address of the DHCP client from the second DHCP protocol message. This second DHCP protocol message is the feedback from the DHCP server based on the first DHCP protocol message.

[0102] Based on the MAC address, the first DHCP relay checks its locally stored temporary table for a matching entry. If a matching entry exists, the first DHCP relay determines that it was originally handling the first DHCP message sent by the DHCP client. The first DHCP relay then generates a binding entry for the corresponding DHCP client based on the temporary entry.

[0103] At the same time, the first DHCP relay also sends a second DHCP protocol message to the DHCP client.

[0104] Optionally, in this embodiment, if the decrypted second QUIC message passes verification but no temporary entry matching the MAC address exists, the first DHCP relay determines that it was not originally processing the first DHCP protocol message sent by the DHCP client. The first DHCP relay can obtain the flow identifier from the second QUIC message. Based on the flow identifier, the first DHCP relay determines the fourth DHCP relay (here, "fourth" is used to distinguish it from other DHCP relays; it could also be "second" or "third") that will process the decrypted second QUIC message; the first DHCP relay then sends the decrypted second QUIC message to the fourth DHCP relay.

[0105] Understandably, after receiving the decrypted second QUIC message, the fourth DHCP relay does not need to perform further verification on the decrypted second QUIC message. The fourth DHCP relay can instead search its locally stored temporary table for a matching entry. If a matching entry exists, the fourth DHCP relay determines that it was originally handling the first DHCP protocol message sent by the DHCP client. Based on the temporary entry, the fourth DHCP relay generates a binding entry corresponding to the DHCP client.

[0106] At the same time, the fourth DHCP relay sends a second DHCP protocol message to the DHCP client.

[0107] Optionally, in this embodiment of the application, when the first DHCP relay is a DHCPv4 relay, the first DHCP relay includes a first interface for connecting to a DHCPv4 client.

[0108] Under the above network topology, according to the existing DHCPv4 protocol, the first DHCP relay adds option 82 to the first DHCP protocol message. Option 82 includes sub-option 11, which includes the first address of the first interface.

[0109] After obtaining the first DHCP protocol message from the first QUIC message, the DHCP server processes the first DHCP protocol message according to the DHCPv4 protocol.

[0110] During the DHCP server's processing of the first DHCP protocol message according to DHCPv4 specifications, if the first DHCP protocol message includes option 54, the DHCP server verifies option 54. The DHCP server then checks whether option 82 included in the first DHCP protocol message carries sub-option 11.

[0111] If sub-option 11 is included, the DHCP server checks if the address in sub-option 11 is the same as the address in option 54, or if the address in option 54 is its own address. If the address in sub-option 11 is the same as the address in option 54, or if the address in option 54 is its own address, the DHCP server determines that option 54 has passed verification. Subsequently, the DHCP server continues to include option 54 in the feedback DHCP protocol message. The DHCP server encrypts the feedback DHCP protocol message according to the key corresponding to the QUIC connection and sends it through the QUIC connection.

[0112] If the address in sub-option 11 is different from the address in option 54, or if the address in option 54 is not its own address, the DHCP server determines that option 54 verification failed. Subsequently, the DHCP server discards the first QUIC message.

[0113] If sub-option 11 is not included, the DHCP server checks if the address in option 54 is its own address. If the address in option 54 is its own address, the DHCP server determines that option 54 verification is successful. Subsequently, the DHCP server continues to include option 54 in the feedback DHCP protocol message. The DHCP server encrypts the feedback DHCP protocol message according to the key corresponding to the QUIC connection and sends it through the QUIC connection.

[0114] If the address in option 54 is not its own address, the DHCP server determines that option 54 verification has failed. Subsequently, the DHCP server discards the first QUIC message.

[0115] If the first QUIC message does not include option 54, the DHCP server continues to identify whether option 82 included in the first QUIC message carries sub option 11.

[0116] If sub-option 11 is included, an address is obtained from sub-option 11 and filled into the newly added option 54. Subsequently, the DHCP server includes this newly added option 54 in the returned DHCP protocol message. The DHCP server encrypts the returned DHCP protocol message according to the key corresponding to the QUIC connection and sends it through the QUIC connection.

[0117] If sub-option 11 is not included, the DHCP server fills its own address into the address in the newly added option 54. Subsequently, the DHCP server includes this newly added option 54 in the returned DHCP protocol message. The DHCP server encrypts the returned DHCP protocol message according to the key corresponding to the QUIC connection and sends it through the QUIC connection.

[0118] In this embodiment of the application, the address stored in option54 is collectively referred to as the second address.

[0119] After verifying the decrypted second QUIC message, the first DHCP relay retrieves option 54 from the second DHCP protocol message and obtains the second address from option 54. The first DHCP relay checks if the second address is the same as the first address; that is, it checks if the second address is the interface address of its own first interface. If the second address is different from the first address, the first DHCP relay updates the second address to the first address. This ensures that the DHCP client sends subsequent DHCP protocol messages (e.g., renewal messages, release messages, etc.) to the first DHCP relay, which then encrypts and sends them to the DHCP server. If the second address is the same as the first address, the first DHCP relay retains the second address.

[0120] Therefore, using the communication method provided in this application, the first DHCP relay receives a first DHCP protocol message sent by a DHCP client; through a QUIC connection, the first DHCP relay sends a first QUIC message to the DHCP server, the first QUIC message including a flow identifier, the first QUIC message being obtained by encrypting the first DHCP protocol message according to the key corresponding to the QUIC connection; if a second QUIC message including a flow identifier is received from the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then according to the key, the first DHCP relay decrypts the second QUIC message and verifies the decrypted second QUIC message; if the verification passes and a temporary entry corresponding to the DHCP client exists, then according to the temporary entry, the first DHCP relay generates a binding entry corresponding to the DHCP client and sends a second DHCP protocol message to the DHCP client; wherein, the flow identifier is allocated by the DHCP management relay and the flow identifier allocated by each DHCP relay in the distributed network is different.

[0121] Thus, in a distributed network, a QUIC connection is established between the DHCP management relay and the DHCP server. Each DHCP relay can use this QUIC connection to send encrypted messages to the DHCP server. This avoids message eavesdropping and tampering; reduces the configuration complexity of IPSec encryption; allows each DHCP relay to use a different flow identifier for multiplexing, avoiding congestion; and lowers hardware and maintenance costs.

[0122] Optionally, in this embodiment of the application, the multiple first DHCP relays in the distributed network will also elect a DHCP management relay so that the DHCP management relay can subsequently establish, manage and maintain a QUIC connection with the DHCP server.

[0123] Specifically, before network deployment, each first DHCP relay is configured with the same BGP functionality. The router ID configured for BGP within each first DHCP relay is unique. The same QUIC functionality is also configured within each DHCP relay. Examples include: QUIC protocol version; TLS configuration; connection timeout and retries; flow control; congestion control; connection migration; and 0-RTT and 1-RTT configuration.

[0124] After each first DHCP relay establishes a communication connection with the others, each first DHCP relay establishes a BGP neighbor relationship with the other first DHCP relays. Each first DHCP relay generates and sends a first BGP OPEN message to the other first DHCP relays. This first BGP OPEN message includes a minimum Router ID. This minimum Router ID is the minimum value of the Router ID determined by each first DHCP relay itself.

[0125] In one implementation, during the initial stage of network setup, i.e., after the communication connection has just been established, when each first DHCP relay has not received the first BGP OPEN message from other first DHCP relays (to distinguish between the sender and receiver, other first DHCP relays are referred to as second DHCP relays), the smallest Router identifier determined by each first DHCP relay is its own Router identifier.

[0126] In the second implementation, if the first DHCP relay receives the first BGP OPEN message sent by the second DHCP relay before sending its own first BGP OPEN message, then when the first DHCP relay determines the minimum Router identifier, it needs to compare its own Router identifier with the minimum Router identifier included in the received first BGP OPEN message, and carry the minimum Router identifier after comparison in the first BGP OPEN message it generates.

[0127] For example, DHCP Relay 1 and DHCP Relay 2 form a distributed network. DHCP Relay 1 has a Router identifier of 1, and DHCP Relay 2 has a Router identifier of 2. In one implementation, if neither DHCP Relay 1 nor DHCP Relay 2 receives a BGP OPEN message 1 from the peer, then when generating its own BGP OPEN message 1, DHCP Relay 1 determines a minimum Router identifier of 1, and DHCP Relay 2 determines a minimum Router identifier of 2.

[0128] In the second implementation, DHCP Relay 1 generates BGP OPEN message 1, which includes a minimum Router identifier of 1. DHCP Relay 1 sends BGP OPEN message 1 to DHCP Relay 2. Before DHCP Relay 2 generates and sends BGP OPEN message 2, it receives BGP OPEN message 1 and retrieves the minimum Router identifier 1 from it. DHCP Relay 2 compares its own Router identifier with the minimum Router identifier 1 and determines that the minimum Router identifier 1 is the minimum value. At this point, DHCP Relay 2 generates BGP OPEN message 2, which includes a minimum Router identifier of 1. DHCP Relay 2 sends BGP OPEN message 2 to DHCP Relay 1.

[0129] In this embodiment of the application, the first DHCP relay receives the first BGP OPEN message sent by each of the second DHCP relays in the distributed network, and obtains the minimum Router identifier from each first BGP OPEN message.

[0130] According to the existing BGP protocol, during the exchange of BGP OPEN messages among DHCP relays, the first DHCP relay establishes a BGP neighbor relationship with each of the second DHCP relays. Once the first DHCP relay successfully establishes a BGP neighbor relationship with the first second DHCP relay, it starts a timer with a preset duration of 10 seconds. Within this preset time, the first DHCP relay determines whether a DHCP management relay exists within the distributed network.

[0131] Understandably, during the initial network setup, each DHCP relay exchanges BGP OPEN messages to establish BGP neighbors and determine which DHCP relay has the smallest Router ID within the network. Therefore, within the preset time, a DHCP management relay has not yet been elected within the distributed network.

[0132] Therefore, if there is no DHCP management relay in the distributed network, the first DHCP relay determines whether each minimum Router identifier is less than its own first Router identifier. If each minimum Router identifier is not less than the first Router identifier, the first DHCP relay determines the first Router identifier as the minimum Router identifier, which is the minimum value of the Router identifier in the distributed network.

[0133] If any of the smallest Router identifiers is smaller than the first Router identifier, the first DHCP relay waits for the BGP EVPN message sent by the second DHCP relay, which will subsequently become the DHCP management relay.

[0134] It should be noted that, in this embodiment, the Router identifier of the DHCP management relay is the minimum value of the Router identifiers within the distributed network. Therefore, if there is a minimum Router identifier smaller than the first Router identifier, the first DHCP relay can determine that it cannot become a DHCP management relay.

[0135] Optionally, in this embodiment, the BGP OPEN message adds a first parameter, Type Length Value (TLV), structure to the existing BGP OPEN message. This first parameter TLV structure is used to carry the minimum router identifier. The first parameter TLV structure includes a Type field, a Length field, and a Value field. The Type field has a length of 1 byte and a value of 240; the Length field has a length of 1 byte and a value of 1; the Value field has a variable length and carries the minimum router identifier.

[0136] Optionally, in this embodiment, after the time for successfully establishing a BGP neighbor with the first second DHCP relay exceeds a preset time, the first DHCP relay determines that the distributed network is stable. The first DHCP relay then determines again whether there is a DHCP management relay in the distributed network (which can be determined by whether a BGP EVPN message is received).

[0137] If no DHCP management relay exists within the distributed network, the first DHCP relay determines whether the first Router identifier is the current minimum Router identifier based on the minimum Router identifier included in each previously acquired first BGP OPEN message. If the first Router identifier is the current minimum Router identifier, the first DHCP relay determines that it will be upgraded to a DHCP management relay and establishes a QUIC connection with the DHCP server.

[0138] It is understandable that the first DHCP relay will act as a QUIC client, and the DHCP server will act as a QUIC server. According to existing QUIC protocol specifications, the first DHCP relay establishes a QUIC connection with the DHCP server, which will not be repeated here. Furthermore, after becoming a DHCP management relay, the first DHCP relay also assigns a corresponding flow identifier to each Router identifier.

[0139] The first DHCP relay generates and sends a first BGP EVPN message to each of the second DHCP relays. The first BGP EVPN message includes attribute information of the QUIC connection, so that each second DHCP relay can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server.

[0140] If a DHCP management relay exists in the distributed network, the first DHCP relay waits for the BGP EVPN message sent by the second DHCP relay, which will subsequently become the DHCP management relay.

[0141] Optionally, in this embodiment, a new BGP EVPN message is added, which includes a TLV structure. The TLV structure includes a type field, a length field, and a value field. The value field includes multiple sub-TLVs, each carrying one attribute from the QUIC connection's attribute information. The type field has a length of 1 byte and a value of 254; the length field has a length of 2 bytes; the value field has a variable length and carries at least one sub-TLV structure.

[0142] This sub-TLV structure includes a Sub-Type field, a Sub-Length field, and a Sub-Value field. The Sub-Type field is 1 byte long, and its value is set according to the attribute information it carries (e.g., 1, 2, 3, etc.); the Sub-Length field is 1 byte long; and the Sub-Value field has a variable length and carries attribute information.

[0143] The attribute information of the above-mentioned QUIC connection includes QUIC session identifier, QUIC connection address, QUIC connection port, QUIC session key, QUIC session transmission parameters, and the correspondence between all router identifiers and flow identifiers in the network.

[0144] For example, in a sub-TLV structure carrying the QUIC session identifier, the subtype field is set to 1; the sublength field is variable, depending on the length of the QUIC session identifier; and the subvalue field carries the unique identifier of the QUIC session, typically a randomly generated string or number. In a sub-TLV structure carrying the QUIC connection address, the subtype field is set to 2; the sublength field is set to 4 (IPv4) or 16 (IPv6); and the subvalue field carries the IP address of the QUIC connection (the IP address of the DHCP relay or DHCP server). In a sub-TLV structure carrying the QUIC connection port, the subtype field is set to 3; the sublength field is set to 2; and the subvalue field carries the port number of the QUIC connection (the port number of the DHCP relay or DHCP server). In a sub-TLV structure carrying the QUIC session key, the subtype field is set to 4; the sublength field is variable, depending on the key length; and the subvalue field carries the encryption key of the QUIC session, used for other DHCP relay authentication sessions. In the sub-TLV structure carrying QUIC session transmission parameters, the sub-type field is set to 5; the sub-length field is variable, depending on the length of the transmission parameters; the sub-value field carries the transmission parameters of the QUIC session, such as maximum packet size and flow control window. In the sub-TLV structure carrying the mapping between Router identifiers and flow identifiers, the sub-type field is set to 6; the sub-length field is variable, depending on the length of the Router identifier and flow identifier; the sub-value field carries the mapping between all Router identifiers and flow identifiers within the distributed network, where each Router identifier corresponds to a unique flow identifier.

[0145] Optionally, in the embodiments of this application, when a new DHCP relay joins the distributed network, the new DHCP relay will also interact with each DHCP relay in the distributed network by sending BGP OPEN messages, establishing BGP, identifying whether a DHCP management relay exists, and obtaining QUIC attribute information.

[0146] Specifically, the first DHCP relay joins the distributed network as a new DHCP relay. After establishing communication connections with each of the second DHCP relays in the distributed network, each DHCP relay generates and sends BGP OPEN messages to each other. The first DHCP relay establishes BGP neighbor relationships with each of the second DHCP relays.

[0147] Each second DHCP relay generates a second BGP OPEN message, which includes a minimum Router identifier and the Router identifier of the DHCP management relay. The minimum Router identifier is the minimum value of the Router identifier determined by the second DHCP relay.

[0148] It is understandable that when a DHCP management relay already exists in a distributed network, the smallest Router identifier determined by each second DHCP relay is the Router identifier of the DHCP management relay.

[0149] Each second DHCP relay sends a second BGP OPEN message to the first DHCP relay.

[0150] In one implementation, when the first DHCP relay does not receive a second BGP OPEN message from the second DHCP relay, the first DHCP relay determines its own router identifier as the minimum router identifier and includes it in its own generated second BGP OPEN message. This second BGP OPEN message does not carry the router identifier of the DHCP management relay. Furthermore, the second BGP OPEN message has the same structure as the aforementioned first BGP OPEN message, both including a first parameter TLV structure, which is used to carry the minimum router identifier.

[0151] In the second implementation, if the first DHCP relay receives a second BGP OPEN message from the second DHCP relay but has not sent its own second BGP OPEN message, then when determining the minimum router identifier, the first DHCP relay needs to compare its own router identifier with the minimum router identifier included in the received second BGP OPEN message, and include the compared minimum router identifier in its own generated second BGP OPEN message. This second BGP OPEN message may also carry the router identifier of the DHCP management relay (which can be determined based on the router identifier of the DHCP management relay sent by the second DHCP relay).

[0152] Similarly, after the second DHCP relay receives the second BGP OPEN message sent by the first DHCP relay, if the Router identifier of the first DHCP relay is smaller than the Router identifier of the DHCP management relay, the second DHCP relay will fill the Router identifier of the first DHCP relay into the smallest Router identifier after comparing the size of the identifiers, but the DHCP management relay will remain unchanged.

[0153] The second BGP OPEN message generated by the second DHCP relay includes a first parameter TLV structure and a second parameter TLV structure. This second parameter TLV structure is used to carry the Router identifier of the DHCP management relay. The second parameter TLV structure is the same as the first parameter TLV structure.

[0154] According to the existing BGP protocol, the first DHCP relay establishes a BGP neighbor relationship with each of the second DHCP relays. After successfully establishing a BGP neighbor relationship with the first second DHCP relay, the first DHCP relay starts a timer with a preset duration of 10 seconds. Within this preset time, the first DHCP relay determines whether a DHCP management relay exists within the distributed network.

[0155] If a DHCP management relay exists within the distributed network (which is usually the case), the first DHCP relay determines whether the smallest Router ID is less than its own first Router ID. If all first Router IDs are not less than the first Router ID, the first DHCP relay determines the first Router ID as the smallest Router ID. Simultaneously, the first DHCP relay waits for BGP EVPN messages sent by the DHCP management relay, for example, a third BGP EVPN message (used only to distinguish it from other BGP EVPN messages).

[0156] If no DHCP management relay exists within the distributed network (due to abnormal situations such as DHCP management relay failure or link failure causing DHCP management relay disconnection), the first DHCP relay determines whether each minimum Router identifier is less than its own first Router identifier. If each first Router identifier is not less than the first Router identifier, the first DHCP relay determines the first Router identifier as the minimum Router identifier. If any minimum Router identifier is less than the first Router identifier, the first DHCP relay waits for a BGP EVPN message sent by the second DHCP relay, which subsequently becomes the DHCP management relay, for example, a fourth BGP EVPN message (only used to distinguish other BGP EVPN messages).

[0157] Optionally, in this embodiment of the application, when the time for successfully establishing a BGP neighbor with the first second DHCP relay exceeds the preset time, the first DHCP relay determines whether there is a DHCP management relay in the distributed network.

[0158] If there is no DHCP management relay in the distributed network (DHCP management relay failure, link failure, or other abnormal situations cause the DHCP management relay to lose connection), the first DHCP relay determines whether the first Router identifier is the current smallest Router identifier; if the first Router identifier is the current smallest Router identifier, the first DHCP relay establishes a QUIC connection with the DHCP server.

[0159] It is understandable that the first DHCP relay will act as a QUIC client, and the DHCP server will act as a QUIC server. According to the existing QUIC protocol, the first DHCP relay establishes a QUIC connection with the DHCP server, which will not be repeated here.

[0160] The first DHCP relay sends a second BGP EVPN message to each of the second DHCP relays. The second BGP EVPN message includes the attribute information of the QUIC connection, so that each second DHCP relay can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server.

[0161] It is understood that the format of the second BGP EVPN message is the same as that of the first BGP EVPN message, and will not be repeated here.

[0162] If a DHCP management relay exists in the distributed network (which usually does), the first DHCP relay waits for the BGP EVPN message sent by the DHCP management relay, for example, the third BGP EVPN message (only used to distinguish other BGP EVPN messages).

[0163] For example, DHCP relay 1 and DHCP relay 2 have formed a distributed network. The router identifier of DHCP relay 1 is 4, and the router identifier of DHCP relay 2 is 5. As can be seen from the previous embodiment, within the distributed network, DHCP relay 1 is the DHCP management relay. At this time, DHCP relay 3 joins the distributed network, and the router identifier of DHCP relay 3 is 1.

[0164] In the first implementation, after DHCP Relay 3 establishes communication connections with DHCP Relay 1 and DHCP Relay 2, DHCP Relay 3 does not receive any other BGP OPEN messages. At this point, DHCP Relay 3 determines the minimum Router identifier to be 1 and includes it in BGP OPEN message 1. DHCP Relay 3 then sends BGP OPEN message 1 to DHCP Relay 1 and DHCP Relay 2.

[0165] After receiving the BGP OPEN message 1, DHCP Relay 1 and DHCP Relay 2 retrieve the Router value 1 of DHCP Relay 3 from it. DHCP Relay 1 compares the Router value of DHCP Relay 3 with the current minimum Router value 4, and determines that the Router value 1 of DHCP Relay 3 is the current minimum Router value. DHCP Relay 1 then refreshes the current minimum Router identifier to 1. Similarly, DHCP Relay 2 also refreshes the current minimum Router identifier to 1.

[0166] Simultaneously, DHCP Relay 1 and DHCP Relay 2 also generate BGP OPEN message 2. If generated before receiving BGP OPEN message 1, BGP OPEN message 2 includes the minimum Router ID 4 and the Router ID 4 of the DHCP management relay; if generated after receiving BGP OPEN message 1, BGP OPEN message 1 includes the minimum Router ID 1 and the Router ID 4 of the DHCP management relay.

[0167] After receiving multiple BGP OPEN messages 2, DHCP Relay 3 establishes BGP neighbor relationships with DHCP Relay 1 and DHCP Relay 2 respectively, according to the existing BGP protocol. If DHCP Relay 3 establishes a BGP neighbor relationship with DHCP Relay 1 first, DHCP Relay 3 starts a timer with a preset duration of 10 seconds. Within the preset time, DHCP Relay 3 determines whether a DHCP management relay exists in the distributed network. Based on the Router identifier of the DHCP management relay included in each BGP OPEN message 2, DHCP Relay 3 determines that a DHCP management relay exists in the distributed network, i.e., DHCP Relay 1 is the DHCP management relay. Furthermore, DHCP Relay 3 uses its own Router identifier as the minimum Router identifier. DHCP Relay 3 then waits for the BGP EVPN message sent by DHCP Relay 1.

[0168] After the preset time has elapsed since DHCP Relay 1 successfully established a BGP neighbor relationship, DHCP Relay 3 again checks whether a DHCP management relay exists within the distributed network. At this point, a DHCP management relay exists within the distributed network, meaning DHCP Relay 1 is still functioning as a DHCP management relay. DHCP Relay 3 then waits for a BGP EVPN message from DHCP Relay 1.

[0169] In the second implementation, after DHCP Relay 1, DHCP Relay 2, and DHCP Relay 3 establish a communication connection, DHCP Relay 1 generates a BGP OPEN message 2. If it does not receive a BGP OPEN message 1, DHCP Relay 1 generates and sends a BGP OPEN message 2 to DHCP Relay 3. This BGP OPEN message 2 includes a minimum Router identifier and the Router identifier of the DHCP management relay, both of which are 4, i.e., the Router identifier of DHCP Relay 1. Similarly, DHCP Relay 2 also generates the same BGP OPEN message 2.

[0170] After receiving multiple BGP OPEN messages, DHCP Relay 3 obtains the smallest Router ID 4 and the Router ID 4 of the DHCP Management Relay. DHCP Relay 3 then determines that DHCP Relay 1 is the DHCP Management Relay. DHCP Relay 3 compares its own Router ID 1 with the smallest Router ID 4 and determines that its own Router ID 1 is the current smallest Router ID.

[0171] Simultaneously, DHCP relay 3 also generates BGP OPEN message 1. If generated before receiving BGP OPEN message 2, BGP OPEN message 1 includes the minimum Router identifier 1; if generated after receiving BGP OPEN message 2, BGP OPEN message 1 includes the minimum Router identifier 1 and the Router identifier 4 of the DHCP management relay.

[0172] It is understandable that after DHCP Relay 1 and DHCP Relay 2 receive BGP OPEN message 1, they refresh the current minimum Router identifier to 1 based on the included minimum Router identifier 1.

[0173] After receiving BGP OPEN message 2, DHCP Relay 3 establishes BGP neighbor relationships with both DHCP Relay 1 and DHCP Relay 2 according to the existing BGP protocol. If DHCP Relay 3 establishes a BGP neighbor relationship with DHCP Relay 1 first, DHCP Relay 3 starts a timer with a preset duration of 10 seconds. Within this preset time, DHCP Relay 3 determines whether a DHCP management relay exists within the distributed network. Based on the Router identifier of the DHCP management relay included in each BGP OPEN message 2, DHCP Relay 3 determines that a DHCP management relay exists within the distributed network, i.e., DHCP Relay 1 is the DHCP management relay. Furthermore, DHCP Relay 3 uses its own Router identifier as the minimum Router identifier. DHCP Relay 3 then waits for the BGP EVPN message sent by DHCP Relay 1.

[0174] After a preset time has elapsed since DHCP Relay 1 successfully established a BGP neighbor relationship, DHCP Relay 3 again checks if a DHCP management relay exists within the distributed network. At this point, a DHCP management relay exists within the distributed network, meaning DHCP Relay 1 is still a DHCP management relay. DHCP Relay 3 waits for a BGP EVPN message from DHCP Relay 1. Subsequently, when forwarding DHCP protocol messages to the DHCP server, it reuses the QUIC connection based on the QUIC connection attribute information included in the BGP EVPN message.

[0175] During the process of DHCP Relay 3 joining the distributed network, if DHCP Relay 1 fails or loses connection due to a link failure when DHCP Relay 3 first determines whether a DHCP management relay exists in the distributed network, then DHCP Relay 3 determines that no DHCP management relay exists in the distributed network. At this time, after determining that its own Router ID is the minimum Router ID, DHCP Relay 3 refreshes the current minimum Router ID to its own Router ID.

[0176] Then, after the preset time has elapsed since DHCP Relay 1 successfully established a BGP neighbor relationship, when DHCP Relay 3 checks for the existence of a DHCP management relay in the distributed network for the second time, it still determines that no DHCP management relay exists in the distributed network. At this point, DHCP Relay 3 reaffirms that its Router ID is the smallest Router ID, and then establishes a QUIC connection with the DHCP server.

[0177] It is understandable that DHCP Relay 3 will act as a QUIC client, and the DHCP server will act as a QUIC server. According to the existing QUIC protocol, DHCP Relay 3 establishes a QUIC connection with the DHCP server, which will not be repeated here.

[0178] DHCP Relay 3 sends a BGP EVPN message to DHCP Relay 2.

[0179] Optionally, in this embodiment, when the first DHCP relay does not become a DHCP management relay, it will also receive BGP EVPN messages sent by the DHCP relay that has become a DHCP management relay in order to obtain the attribute information of the QUIC connection.

[0180] Specifically, if a DHCP management relay exists in the distributed network, the first DHCP relay receives a third BGP EVPN message sent by the DHCP management relay (only used to distinguish it from other BGP EVPN messages). This third BGP EVPN message includes the attribute information of the QUIC connection.

[0181] or;

[0182] If there is no DHCP management relay in the distributed network and the first Router identifier of the first DHCP relay is not the minimum value of the Router identifiers among all DHCP relays included in the distributed network, then the first DHCP relay receives the fourth BGP EVPN message (only used to distinguish other BGP EVPN messages) sent by the second DHCP relay, which has become the DHCP management relay. The fourth BGP EVPN message includes the attribute information of the QUIC connection.

[0183] It is understood that the formats of the aforementioned third and fourth BGP EVPN messages are the same as those of the aforementioned first and second BGP EVPN messages, and will not be repeated here.

[0184] Optionally, in this embodiment, if the DHCP management relay fails or the link fails, causing the DHCP management relay to lose connection with the first DHCP relay in the distributed network, the other first DHCP relays will re-elect a DHCP management relay to manage and maintain the QUIC connection.

[0185] Specifically, if the first DHCP relay loses connection with the DHCP management relay, the first DHCP relay obtains the Router identifier of each third DHCP relay in the distributed network other than the DHCP management relay from the local machine.

[0186] It is understandable that, through the BGP EVPN messages sent by the DHCP management relay, each first DHCP relay can store the correspondence between the Router identifier and the flow identifier of all DHCP relays in the network.

[0187] The first DHCP relay selects the minimum value of the Router ID from multiple third DHCP relays. The first DHCP relay then determines whether the minimum value of the selected Router ID is its own first Router ID.

[0188] If the minimum value of the Router ID selected by the first DHCP relay is its own first Router ID, then the first DHCP relay acts as a new DHCP management relay to maintain the QUIC connection (e.g., interact with the DHCP server, keep the QUIC connection alive, etc.), and sends a fifth BGP EVPN message to each third DHCP relay. This fifth BGP EVPN message includes the attribute information of the QUIC connection, so that each third DHCP relay can reuse the QUIC connection based on the QUIC connection attribute information when forwarding DHCP protocol messages to the DHCP server.

[0189] If the minimum value of the Router ID selected by the first DHCP relay is not its own first Router ID, the first DHCP relay waits for the sixth BGP EVPN message sent by the third DHCP relay, which will become the new DHCP management relay. Upon receiving the sixth BGP EVPN message, the first DHCP relay retrieves the QUIC connection attribute information from it. Subsequently, when forwarding DHCP protocol messages to the DHCP server, the QUIC connection is reused based on the QUIC connection attribute information.

[0190] Optionally, in this embodiment, during the establishment of a QUIC connection with the DHCP server, the DHCP management relay communicates with each other using QUIC connection request and QUIC connection response messages. During this interaction, since the DHCP relays within the distributed network share the same IP address, when the DHCP server sends a QUIC connection response message, this message will be forwarded to a non-DHCP management relay. In this case, the non-DHCP management relay should forward the QUIC connection response message to the DHCP management relay.

[0191] Specifically, if the first DHCP relay receives a QUIC connection response message from the DHCP server and the first DHCP relay is not a DHCP management relay, then according to the minimum value of the Router identifier among all DHCP relays included in the distributed network, the first DHCP relay sends a QUIC connection response message to the DHCP relay indicated by the minimum value of the Router identifier.

[0192] It is understandable that the DHCP relay indicated by the minimum value of the Router identifier is the DHCP management relay.

[0193] The communication method provided in the embodiments of this application will be described in detail below. See also... Figure 3 , Figure 3 This is a flowchart illustrating another communication method provided in an embodiment of this application. The method is applied to a DHCP server that has established a QUIC connection with a DHCP management relay in a distributed network. The communication method provided in this application embodiment may include the following steps.

[0194] Step 310: Receive a first QUIC message sent by the first DHCP relay via the QUIC connection. The first QUIC message includes a flow identifier.

[0195] Specifically, as described in the foregoing embodiments, the DHCP server can be a DHCPv4 server or a DHCPv6 server. In a distributed network, the DHCP server establishes a QUIC connection with the DHCP management relay and acts as a QUIC server.

[0196] As can be seen from the foregoing embodiments, after receiving the first DHCP protocol message, the first DHCP relay in the distributed network encrypts the first DHCP protocol message according to the key corresponding to the QUIC connection, reuses the QUIC connection, and sends it to the DHCP server.

[0197] In this step, the DHCP server receives the first QUIC message via the QUIC connection.

[0198] Step 320: If the first DHCP protocol message is encapsulated in the first QUIC message, then the first QUIC message is decrypted according to the key corresponding to the QUIC connection, and the decrypted first QUIC message is verified.

[0199] Specifically, according to the description of step 310, after the DHCP server receives the first QUIC message, it first identifies whether the first QUIC message encapsulates the first DHCP protocol message.

[0200] If the first DHCP protocol message is encapsulated within the first QUIC message, the DHCP server decrypts the first QUIC message using the key corresponding to the QUIC connection. Then, the DHCP server verifies the decrypted first QUIC message.

[0201] If the first decrypted QUIC message passes verification, the DHCP server proceeds to step 230.

[0202] Optionally, in this embodiment of the application, if the verification of the decrypted first QUIC message fails, the DHCP server discards the first QUIC message.

[0203] Optionally, in this embodiment of the application, if the first DHCP protocol message is not encapsulated in the first QUIC message, the DHCP server discards the first QUIC message.

[0204] It should be noted that the process by which the DHCP server verifies the QUIC message is the same as the process by which the DHCP relay verifies the QUIC message in the aforementioned embodiment, and will not be repeated here.

[0205] Step 330: If the verification passes and the first DHCP protocol message is a first type message, then generate a second QUIC message. The second QUIC message includes the flow identifier and the second DHCP protocol message. The second DHCP protocol message is a response message to the first DHCP protocol message.

[0206] Specifically, according to the description of step 320, if the decrypted first QUIC message passes the verification, the DHCP server identifies the type of the first DHCP protocol message included in the payload portion of the first QUIC message.

[0207] If the first DHCP protocol message is a Type 1 message, then according to the existing DHCP protocol, the DHCP server generates a second DHCP protocol message. This second DHCP protocol message is the response message to the first DHCP protocol message.

[0208] In this embodiment of the application, the first type of message specifically refers to a DHCP protocol message that requires a reply from the DHCP server.

[0209] Optionally, in this embodiment of the application, when the DHCP server is a DHCPv4 server, it can be as described above to identify whether the first QUIC message encapsulates the first DHCP protocol message, decrypt the first QUIC message, verify the decrypted first QUIC message, and identify the type of the first DHCP protocol message.

[0210] During the generation of the second DHCP protocol message, the DHCP server processes the first DHCP protocol message according to the DHCPv4 protocol.

[0211] During the process of the DHCP server processing the first DHCP protocol message according to the DHCPv4 specification, if the first DHCP protocol message includes option 54, the DHCP server will verify option 54.

[0212] The DHCP server continues to identify whether option 82 of the first DHCP protocol message carries suboption 11.

[0213] If sub-option 11 is included, the DHCP server checks if the address in sub-option 11 is the same as the address in option 54, or if the address in option 54 is its own address. If the address in sub-option 11 is the same as the address in option 54, or if the address in option 54 is its own address, the DHCP server determines that option 54 has passed verification. Subsequently, the DHCP server continues to include option 54 in the second DHCP protocol message. The DHCP server fills the payload portion with the flow identifier included in the first QUIC message and the second DHCP protocol message, generating the second QUIC message.

[0214] If the address in sub-option 11 is different from the address in option 54, or if the address in option 54 is not its own address, the DHCP server determines that option 54 verification failed. Subsequently, the DHCP server discards the first QUIC message.

[0215] If sub-option 11 is not included, the DHCP server checks if the address in option 54 is its own address. If the address in option 54 is its own address, the DHCP server determines that option 54 verification is successful. Subsequently, the DHCP server continues to include option 54 in the second DHCP protocol message. The DHCP server fills the payload portion with the flow identifier included in the first QUIC message and the second DHCP protocol message, generating the second QUIC message.

[0216] If the address in option 54 is not its own address, the DHCP server determines that option 54 verification has failed. Subsequently, the DHCP server discards the first QUIC message.

[0217] If the first DHCP protocol message does not include option 54, the DHCP server continues to identify whether option 82 included in the first DHCP protocol message carries sub option 11.

[0218] If sub-option 11 is included, an address is obtained from sub-option 11 and filled into the newly added option 54. Subsequently, the DHCP server includes this newly added option 54 in the second DHCP protocol message. The DHCP server fills the payload portion with the flow identifier included in the first QUIC message and the second DHCP protocol message, generating the second QUIC message.

[0219] If sub-option 11 is not included, the DHCP server fills its own address into the address in the newly added option 54. Subsequently, the DHCP server includes this newly added option 54 in the second DHCP protocol message. The DHCP server fills the payload portion with the flow identifier included in the first QUIC message and the second DHCP protocol message, generating the second QUIC message.

[0220] Step 340: Send the second QUIC message to the first DHCP relay through the QUIC connection.

[0221] Specifically, according to the description of step 330, after the DHCP server generates the second QUIC message, it also encrypts the second QUIC message according to the key.

[0222] It should be noted that when the DHCP server encrypts a QUIC message, it encrypts the complete QUIC message, but does not encrypt the outer encapsulated IP header and UDP header.

[0223] The DHCP server sends a second QUIC message to the first DHCP relay via a QUIC connection.

[0224] Therefore, using the communication method provided in this application, through a QUIC connection, the DHCP server receives a first QUIC message sent by a first DHCP relay, the first QUIC message including a flow identifier; if a first DHCP protocol message is encapsulated in the first QUIC message, then according to the key corresponding to the QUIC connection, the DHCP server decrypts the first QUIC message and verifies the decrypted first QUIC message; if the verification passes and the first DHCP protocol message is a first type message, then the DHCP server generates a second QUIC message, the second QUIC message including a flow identifier and a second DHCP protocol message, the second DHCP protocol message being a response message to the first DHCP protocol message; through the QUIC connection, the DHCP server sends the second QUIC message to the first DHCP relay; wherein, the flow identifier is assigned by the DHCP management relay and the flow identifier assigned by each DHCP relay in the distributed network is different.

[0225] Thus, in a distributed network, a QUIC connection is established between the DHCP management relay and the DHCP server. Each DHCP relay can use this QUIC connection to send encrypted messages to the DHCP server. This avoids message eavesdropping and tampering; reduces the configuration complexity of IPSec encryption; allows each DHCP relay to use a different flow identifier for multiplexing, avoiding congestion; and lowers hardware and maintenance costs.

[0226] Based on the same inventive concept, embodiments of this application also provide a communication device corresponding to the communication method. See also Figure 4 , Figure 4 A communication device provided in this application embodiment is applied to a first DHCP relay within a distributed network. The first DHCP relay is any DHCP relay within the distributed network. The DHCP management relay in the distributed network establishes a QUIC connection with a DHCP server. The device includes:

[0227] The receiving unit 410 is used to receive the first DHCP protocol message sent by the DHCP client;

[0228] The sending unit 420 is configured to send a first QUIC message to the DHCP server through the QUIC connection. The first QUIC message includes a flow identifier and is obtained by encrypting the first DHCP protocol message according to the key corresponding to the QUIC connection.

[0229] The verification unit 430 is configured to, if the receiving unit receives a second QUIC message including the flow identifier sent by the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, decrypt the second QUIC message according to the key and verify the decrypted second QUIC message.

[0230] The generation unit 440 is used to generate a binding entry corresponding to the DHCP client based on the temporary entry if the verification passes and a temporary entry corresponding to the DHCP client exists.

[0231] The sending unit 420 is further configured to send the second DHCP protocol message to the DHCP client;

[0232] The flow identifier is assigned by the DHCP management relay, and each DHCP relay within the distributed network assigns a unique flow identifier.

[0233] Optionally, the receiving unit 410 is further configured to receive a first BGP OPEN message sent by each second DHCP relay in the distributed network, wherein each first BGP OPEN message includes a minimum Router identifier, and the minimum Router identifier is the minimum value of the Router identifier determined by the second DHCP relay.

[0234] The device further includes: a first judgment unit (not shown in the figure), used to determine whether the DHCP management relay exists in the distributed network within a preset time after successfully establishing a BGP neighbor with the first second DHCP relay;

[0235] The second judgment unit (not shown in the figure) is used to determine whether each smallest Router identifier is less than the first Router identifier of the first DHCP relay if it does not exist.

[0236] A processing unit (not shown in the figure) is configured to, if not, use the first Router identifier as the minimum Router identifier.

[0237] Optionally, the first judgment unit (not shown in the figure) is further configured to determine whether the DHCP management relay exists in the distributed network after the time for successfully establishing a BGP neighbor with the first second DHCP relay exceeds the preset time.

[0238] The second judgment unit (not shown in the figure) is also used to determine whether the first Router identifier is the smallest Router identifier at present if it does not exist.

[0239] An establishment unit (not shown in the figure) is used to establish the QUIC connection with the DHCP server if the condition is met.

[0240] The sending unit 420 is further configured to send a first BGP EVPN message to each of the second DHCP relays, the first BGP EVPN message including the attribute information of the QUIC connection, so that each of the second DHCP relays can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server.

[0241] Optionally, the receiving unit 410 is further configured to receive a second BGP OPEN message sent by each second DHCP relay in the distributed network, wherein each second BGP OPEN message includes a minimum Router identifier and a Router identifier of the DHCP management relay, and the minimum Router identifier is the minimum value of the Router identifier determined by the second DHCP relay.

[0242] The first judgment unit (not shown in the figure) is also used to determine, within a preset time, whether the DHCP management relay exists in the distributed network after a BGP neighbor is successfully established with the first second DHCP relay.

[0243] The second judgment unit (not shown in the figure) is also used to, if it exists, determine whether each minimum Router identifier is less than the first Router identifier of the first DHCP relay;

[0244] The processing unit (not shown in the figure) is further configured to, if not, use the first Router identifier as the minimum Router identifier.

[0245] Optionally, the first judgment unit (not shown in the figure) is further configured to determine whether the DHCP management relay exists in the distributed network after the time for successfully establishing a BGP neighbor with the first second DHCP relay exceeds the preset time.

[0246] The second judgment unit (not shown in the figure) is also used to determine whether the first Router identifier is the smallest Router identifier at present if it does not exist.

[0247] The establishment unit (not shown in the figure) is also used to, if so, establish the QUIC connection with the DHCP server;

[0248] The sending unit 420 is further configured to send a second BGP EVPN message to each of the second DHCP relays, the second BGP EVPN message including the attribute information of the QUIC connection, so that each of the second DHCP relays can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server.

[0249] Optionally, the receiving unit 410 is further configured to, if the distributed network contains the DHCP management relay, receive a third BGP EVPN message sent by the DHCP management relay, wherein the third BGP EVPN message includes attribute information of the QUIC connection;

[0250] or;

[0251] The receiving unit 410 is further configured to, if there is no DHCP management relay in the distributed network and the first Router identifier of the first DHCP relay is not the minimum value of the Router identifiers among all DHCP relays included in the distributed network, receive a fourth BGP EVPN message sent by the second DHCP relay that becomes the DHCP management relay, wherein the fourth BGP EVPN message includes the attribute information of the QUIC connection.

[0252] Optionally, the device further includes:

[0253] The acquisition unit (not shown in the figure) is used to acquire the Router identifier of each third DHCP relay other than the DHCP management relay in the distributed network if the connection with the DHCP management relay is lost.

[0254] The selection unit (not shown in the figure) is used to select the minimum value of the Router ID from multiple third DHCP relay Router IDs;

[0255] The second judgment unit (not shown in the figure) is further used to determine whether the minimum value of the selected Router identifier is the first Router identifier of the first DHCP relay;

[0256] The sending unit 420 is further configured to, if so, maintain the QUIC connection as a new DHCP management relay, and send a fifth BGP EVPN message to each of the third DHCP relays respectively. The fifth BGP EVPN message includes attribute information of the QUIC connection, so that each of the third DHCP relays can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server.

[0257] The receiving unit 410 is further configured to, if not, receive a sixth BGP EVPN message sent by a third DHCP relay that has become a new DHCP management relay, the sixth BGP EVPN message including attribute information of the QUIC connection.

[0258] Optionally, when the first DHCP relay is a DHCPv4 relay, the first DHCP relay includes a first interface;

[0259] The first QUIC message also includes option 82, which includes sub option 11, and sub option 11 includes the first address of the first interface; the second QUIC message also includes option 54, which includes the second address.

[0260] The device further includes:

[0261] An identification unit (not shown in the figure) is used to identify whether the second address is the same as the first address;

[0262] An update unit (not shown in the figure) is used to update the second address to the first address if they are different;

[0263] A holding unit (not shown in the figure) is used to hold the second address if they are the same.

[0264] Optionally, the device further includes:

[0265] The determining unit (not shown in the figure) is used to determine the fourth DHCP relay to process the decrypted second QUIC message based on the MAC address of the DHCP client if the verification passes and there is no temporary table entry corresponding to the DHCP client.

[0266] The sending unit 420 is further configured to send the decrypted second QUIC message to the fourth DHCP relay.

[0267] Optionally, the sending unit 420 is further configured to, if the receiving unit 410 receives a QUIC connection response message sent by the DHCP server and the first DHCP relay is not the DHCP management relay, send the QUIC connection response message to the DHCP relay indicated by the minimum value of the Router identifier among all DHCP relays included in the distributed network.

[0268] Optionally, the BGP OPEN message includes a first parameter TLV structure, which is used to carry the first minimum Router identifier.

[0269] or;

[0270] The BGP OPEN message includes a first parameter TLV structure and a second parameter TLV structure. The first parameter TLV structure is used to carry the first minimum Router identifier, and the second parameter TLV structure is used to carry the Router identifier of the DHCP management relay.

[0271] Optionally, the BGP EVPN message includes a TLV structure, the TLV structure includes a value field, the value field includes multiple sub-TLV structures, and each sub-TLV structure is used to carry one type of attribute information from the attribute information of the QUIC connection;

[0272] The attribute information of the QUIC connection includes the QUIC session identifier, QUIC connection address, QUIC connection port, QUIC session key, QUIC session transmission parameters, and the correspondence between the Router identifier and the stream identifier.

[0273] Optionally, the device further includes:

[0274] A discarding unit (not shown in the figure) is used to discard the second QUIC message if the second DHCP protocol message is not encapsulated in the second QUIC message;

[0275] The discarding unit (not shown in the figure) is also used to discard the second QUIC message if the verification fails.

[0276] Therefore, using the communication method provided in this application, the first DHCP relay receives a first DHCP protocol message sent by a DHCP client; through a QUIC connection, the first DHCP relay sends a first QUIC message to the DHCP server, the first QUIC message including a flow identifier, the first QUIC message being obtained by encrypting the first DHCP protocol message according to the key corresponding to the QUIC connection; if a second QUIC message including a flow identifier is received from the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then according to the key, the first DHCP relay decrypts the second QUIC message and verifies the decrypted second QUIC message; if the verification passes and a temporary entry corresponding to the DHCP client exists, then according to the temporary entry, the first DHCP relay generates a binding entry corresponding to the DHCP client and sends a second DHCP protocol message to the DHCP client; wherein, the flow identifier is allocated by the DHCP management relay and the flow identifier allocated by each DHCP relay in the distributed network is different.

[0277] Thus, in a distributed network, a QUIC connection is established between the DHCP management relay and the DHCP server. Each DHCP relay can use this QUIC connection to send encrypted messages to the DHCP server. This avoids message eavesdropping and tampering; reduces the configuration complexity of IPSec encryption; allows each DHCP relay to use a different flow identifier for multiplexing, avoiding congestion; and lowers hardware and maintenance costs.

[0278] Based on the same inventive concept, embodiments of this application also provide a communication device corresponding to the communication method. See also Figure 5 , Figure 5 Another communication device provided in this application embodiment is applied to a DHCP server, the DHCP server having established a QUIC connection with a DHCP management relay in a distributed network, the distributed network further including a first DHCP relay, the first DHCP relay being any DHCP relay in the distributed network, the device comprising:

[0279] The receiving unit 510 is configured to receive a first QUIC message sent by the first DHCP relay via the QUIC connection, wherein the first QUIC message includes a flow identifier.

[0280] The verification unit 520 is used to decrypt the first QUIC message according to the key corresponding to the QUIC connection if the first DHCP protocol message is encapsulated in the first QUIC message, and to verify the decrypted first QUIC message.

[0281] The generation unit 530 is configured to generate a second QUIC message if the verification passes and the first DHCP protocol message is a first type message. The second QUIC message includes the flow identifier and the second DHCP protocol message, which is a response message to the first DHCP protocol message.

[0282] Sending unit 540 is used to send the second QUIC message to the first DHCP relay via the QUIC connection;

[0283] The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

[0284] Optionally, the QUIC message includes a flow identifier field, which carries the flow identifier.

[0285] Optionally, the device further includes:

[0286] A discarding unit (not shown in the figure) is used to discard the first QUIC message if the first DHCP protocol message is not encapsulated in the first QUIC message.

[0287] The discarding unit (not shown in the figure) is also used to discard the first QUIC message if the verification fails.

[0288] Therefore, using the communication method provided in this application, through a QUIC connection, the DHCP server receives a first QUIC message sent by a first DHCP relay, the first QUIC message including a flow identifier; if a first DHCP protocol message is encapsulated in the first QUIC message, then according to the key corresponding to the QUIC connection, the DHCP server decrypts the first QUIC message and verifies the decrypted first QUIC message; if the verification passes and the first DHCP protocol message is a first type message, then the DHCP server generates a second QUIC message, the second QUIC message including a flow identifier and a second DHCP protocol message, the second DHCP protocol message being a response message to the first DHCP protocol message; through the QUIC connection, the DHCP server sends the second QUIC message to the first DHCP relay; wherein, the flow identifier is assigned by the DHCP management relay and the flow identifier assigned by each DHCP relay in the distributed network is different.

[0289] Thus, in a distributed network, a QUIC connection is established between the DHCP management relay and the DHCP server. Each DHCP relay can use this QUIC connection to send encrypted messages to the DHCP server. This avoids message eavesdropping and tampering; reduces the configuration complexity of IPSec encryption; allows each DHCP relay to use a different flow identifier for multiplexing, avoiding congestion; and lowers hardware and maintenance costs.

[0290] Based on the same inventive concept, embodiments of this application also provide a network device, such as... Figure 6 As shown, the system includes a processor 610, a transceiver 620, and a machine-readable storage medium 630. The machine-readable storage medium 630 stores machine-executable instructions that can be executed by the processor 610. The processor 610 is prompted by the machine-executable instructions to execute the communication method provided in the embodiments of this application. (The foregoing...) Figure 4 , Figure 5 The communication device shown can be used as follows: Figure 6 The hardware structure of the network device shown is implemented.

[0291] The aforementioned computer-readable storage medium 630 may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the computer-readable storage medium 630 may also be at least one storage device located remotely from the aforementioned processor 610.

[0292] The processor 610 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0293] In this embodiment of the application, the processor 610 reads the machine-executable instructions stored in the machine-readable storage medium 630, and is prompted by the machine-executable instructions to enable the processor 610 itself and the transceiver 620 to execute the communication method described in the foregoing embodiment of the application.

[0294] In addition, this application provides a machine-readable storage medium 630 that stores machine-executable instructions. When called and executed by the processor 610, the machine-executable instructions cause the processor 610 itself and the transceiver 620 to execute the communication method described in the aforementioned application.

[0295] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0296] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0297] For the embodiments of communication devices and machine-readable storage media, since the methods involved are basically similar to those of the aforementioned method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0298] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A communication method, characterized in that, The method, applied to a first DHCP relay within a distributed network, wherein the first DHCP relay is any DHCP relay within the distributed network, and the DHCP management relay in the distributed network establishes a QUIC connection with the DHCP server, includes: Receive the first DHCP protocol message sent by the DHCP client; Through the QUIC connection, a first QUIC message is sent to the DHCP server. The first QUIC message includes a flow identifier and is obtained by encrypting the first DHCP protocol message according to the key corresponding to the QUIC connection. If a second QUIC message including the flow identifier is received from the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then the second QUIC message is decrypted according to the key, and the decrypted second QUIC message is verified. If the verification passes and a temporary entry corresponding to the DHCP client exists, then based on the temporary entry, a binding entry corresponding to the DHCP client is generated, and the second DHCP protocol message is sent to the DHCP client. The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

2. The method according to claim 1, characterized in that, Before receiving the first DHCP protocol message sent by the DHCP client, the method further includes: Receive the first BGP OPEN message sent by each second DHCP relay in the distributed network. Each first BGP OPEN message includes a minimum Router identifier, which is the minimum value of the Router identifier determined by the second DHCP relay. After successfully establishing a BGP neighbor with the first second DHCP relay, within a preset time, it is determined whether the DHCP management relay exists in the distributed network. If it does not exist, then determine whether each smallest Router identifier is less than the first Router identifier of the first DHCP relay; If not, then the first Router identifier is used as the minimum Router identifier.

3. The method according to claim 2, characterized in that, The method further includes: If the time taken to successfully establish a BGP neighbor with the first second DHCP relay exceeds the preset time, it is determined whether the DHCP management relay exists in the distributed network. If it does not exist, then determine whether the first Router identifier is the smallest Router identifier at present; If so, then establish the QUIC connection with the DHCP server; A first BGP EVPN message is sent to each of the second DHCP relays. The first BGP EVPN message includes the attribute information of the QUIC connection, so that each of the second DHCP relays can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server.

4. The method according to claim 1, characterized in that, Before receiving the first DHCP protocol message sent by the DHCP client, the method further includes: Receive the second BGP OPEN message sent by each second DHCP relay in the distributed network. Each second BGP OPEN message includes a minimum Router identifier and the Router identifier of the DHCP management relay. The minimum Router identifier is the minimum value of the Router identifier determined by the second DHCP relay. After successfully establishing a BGP neighbor with the first second DHCP relay, within a preset time, it is determined whether the DHCP management relay exists in the distributed network. If it exists, determine whether each smallest Router identifier is less than the first Router identifier of the first DHCP relay; If not, then the first Router identifier is used as the minimum Router identifier.

5. The method according to claim 4, characterized in that, The method further includes: If the time taken to successfully establish a BGP neighbor with the first second DHCP relay exceeds the preset time, it is determined whether the DHCP management relay exists in the distributed network. If it does not exist, then determine whether the first Router identifier is the smallest Router identifier at present; If so, then establish the QUIC connection with the DHCP server; A second BGP EVPN message is sent to each second DHCP relay. The second BGP EVPN message includes the attribute information of the QUIC connection, so that each second DHCP relay can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server.

6. The method according to any one of claims 2-5, characterized in that, The method further includes: If the distributed network contains the DHCP management relay, then the third BGP EVPN message sent by the DHCP management relay is received, and the third BGP EVPN message includes the attribute information of the QUIC connection; or; If there is no DHCP management relay in the distributed network and the first Router identifier of the first DHCP relay is not the minimum value of the Router identifiers among all DHCP relays included in the distributed network, then a fourth BGP EVPN message sent by the second DHCP relay, which becomes the DHCP management relay, is received. The fourth BGP EVPN message includes the attribute information of the QUIC connection.

7. The method according to claim 1, characterized in that, The method further includes: If the connection with the DHCP management relay is lost, the Router identifier of each third DHCP relay in the distributed network other than the DHCP management relay is obtained; Select the minimum value of the Router ID from multiple third-party DHCP relay Router IDs; Determine whether the minimum value of the selected Router identifier is the first Router identifier of the first DHCP relay; If so, the QUIC connection is maintained as a new DHCP management relay, and a fifth BGP EVPN message is sent to each of the third DHCP relays. The fifth BGP EVPN message includes the attribute information of the QUIC connection, so that each of the third DHCP relays can reuse the QUIC connection according to the attribute information of the QUIC connection when forwarding DHCP protocol messages to the DHCP server. If not, then receive the sixth BGP EVPN message sent by the third DHCP relay that becomes the new DHCP management relay, the sixth BGP EVPN message including the attribute information of the QUIC connection.

8. The method according to claim 1, characterized in that, When the first DHCP relay is a DHCPv4 relay, the first DHCP relay includes a first interface; The first QUIC message also includes option 82, which includes sub option 11, and sub option 11 includes the first address of the first interface; the second QUIC message also includes option 54, which includes the second address. Before sending the second DHCP protocol message to the DHCP client, the method further includes: Identify whether the second address is the same as the first address; If they are different, then update the second address to the first address; If they are the same, then keep the second address.

9. The method according to claim 1, characterized in that, The method further includes: If the verification passes and there is no temporary entry corresponding to the DHCP client, then the fourth DHCP relay to process the decrypted second QUIC message is determined based on the MAC address of the DHCP client. The decrypted second QUIC message is sent to the fourth DHCP relay.

10. The method according to claim 1, characterized in that, The method further includes: If a QUIC connection response message is received from the DHCP server and the first DHCP relay is not the DHCP management relay, then the QUIC connection response message is sent to the DHCP relay indicated by the minimum value of the Router identifier among all DHCP relays included in the distributed network.

11. The method according to claim 2 or 4, characterized in that, The BGP OPEN message includes a first parameter TLV structure, which is used to carry the first minimum Router identifier. or; The BGP OPEN message includes a first parameter TLV structure and a second parameter TLV structure. The first parameter TLV structure is used to carry the first minimum Router identifier, and the second parameter TLV structure is used to carry the Router identifier of the DHCP management relay.

12. The method according to any one of claims 3, 5-7, characterized in that, BGP EVPN packets include a TLV structure, the TLV structure includes a value field, the value field includes multiple sub-TLV structures, each sub-TLV structure is used to carry one type of attribute information in the attribute information of the QUIC connection; The attribute information of the QUIC connection includes the QUIC session identifier, QUIC connection address, QUIC connection port, QUIC session key, QUIC session transmission parameters, and the correspondence between the Router identifier and the stream identifier.

13. The method according to claim 1, characterized in that, The method further includes: If the second DHCP protocol message is not encapsulated in the second QUIC message, then the second QUIC message is discarded; If the verification fails, the second QUIC message is discarded.

14. A communication method, characterized in that, Applied to a DHCP server, wherein the DHCP server has established a QUIC connection with a DHCP management relay in a distributed network, the distributed network further includes a first DHCP relay, which is any DHCP relay in the distributed network, and the method includes: Through the QUIC connection, a first QUIC message sent by the first DHCP relay is received, the first QUIC message including a flow identifier; If the first DHCP protocol message is encapsulated in the first QUIC message, then the first QUIC message is decrypted according to the key corresponding to the QUIC connection, and the decrypted first QUIC message is verified. If the verification passes and the first DHCP protocol message is a first type message, a second QUIC message is generated. The second QUIC message includes the flow identifier and the second DHCP protocol message, which is a response message to the first DHCP protocol message. The second QUIC message is sent to the first DHCP relay via the QUIC connection. The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

15. The method according to claim 14, characterized in that, QUIC messages include a flow identifier field, which carries the flow identifier.

16. The method according to claim 14, characterized in that, The method further includes: If the first DHCP protocol message is not encapsulated in the first QUIC message, then the first QUIC message is discarded; If the verification fails, the first QUIC message is discarded.

17. A communication device, characterized in that, An apparatus for use with a first DHCP relay within a distributed network, wherein the first DHCP relay is any DHCP relay within the distributed network, and the DHCP management relay in the distributed network establishes a QUIC connection with a DHCP server, the apparatus comprising: The receiving unit is used to receive the first DHCP protocol message sent by the DHCP client; The sending unit is configured to send a first QUIC message to the DHCP server via the QUIC connection. The first QUIC message includes a flow identifier and is obtained by encrypting the first DHCP protocol message using the key corresponding to the QUIC connection. The verification unit is configured to, if the receiving unit receives a second QUIC message including the flow identifier sent by the DHCP server and the second DHCP protocol message generated by the DHCP server is encapsulated in the second QUIC message, then decrypt the second QUIC message according to the key and verify the decrypted second QUIC message. The generation unit is used to generate a binding entry corresponding to the DHCP client based on the temporary entry if the verification passes and a temporary entry corresponding to the DHCP client exists. The sending unit is further configured to send the second DHCP protocol message to the DHCP client; The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

18. A communication device, characterized in that, Applied to a DHCP server, the DHCP server has established a QUIC connection with a DHCP management relay in a distributed network, the distributed network further includes a first DHCP relay, which is any DHCP relay in the distributed network, the device comprising: The receiving unit is configured to receive a first QUIC message sent by the first DHCP relay via the QUIC connection, wherein the first QUIC message includes a flow identifier; The verification unit is used to decrypt the first QUIC message according to the key corresponding to the QUIC connection if the first DHCP protocol message is encapsulated in the first QUIC message, and to verify the decrypted first QUIC message. The generation unit is configured to generate a second QUIC message if the verification passes and the first DHCP protocol message is a first type message. The second QUIC message includes the flow identifier and the second DHCP protocol message, which is a response message to the first DHCP protocol message. The sending unit is configured to send the second QUIC message to the first DHCP relay via the QUIC connection; The flow identifier is assigned by the DHCP management relay, and each DHCP relay in the distributed network assigns a different flow identifier.

Citation Information

Patent Citations

  • Method and apparatus for implementing multi-host multi-path secure transmission using QUIC

    CN115244897A

  • Method and apparatus for user equipment-to-network relay communication in wireless communications

    CN115379591A