Communication method and device

Abstract

The invention provides a communication method and device, and the method comprises the steps: determining a first VPN instance bound with a first interface when a first service message sent by first user side equipment is received through the first interface; in the routing table of the first VPN instance, obtaining a corresponding first VPN SID; when it is determined that the first service message is forwarded through the SRv6 path, performing SRv6 encapsulation processing on the first service message to obtain a second service message; if the first VPN SID exists in the SID list and an encryption mapping table item matched with the first VPN SID exists in a local encryption mapping table, acquiring an IPSec SA identifier from the encryption mapping table item; performing encryption processing on the first service message included in the second service message through the IPSec SA corresponding to the IPSec SA identifier to obtain a third service message; and forwarding the third service message to the next-hop network equipment through the SRv6 path.

Description

Technical Field

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

[0002] Segment Routing over IPv6 Traffic Engineering (SRv6 TE) based on the IPv6 forwarding plane provides a flexible forwarding path selection method, which can meet different forwarding requirements of users. When there are multiple forwarding paths between the source node and the destination node in the SRv6 network, reasonably using SRv6 TE to select the forwarding path can not only facilitate network administrators to manage and plan the network, but also effectively reduce the forwarding pressure on network devices.

[0003] In practical applications, in addition to flexible path planning, users also need to encrypt and protect the transmitted traffic flows. To encrypt and protect the transmitted traffic flows, IPSec tunnels are established between pairwise Endpoint nodes on the forwarding path, and each Endpoint node forwards the service packets through the Internet Protocol Security (IPSec) tunnel.

[0004] However, the above solution for encrypting and protecting traffic flows also exposes the following problems: 1) IPSec tunnels need to be created segment by segment on the entire forwarding path, which is not convenient for network deployment; 2) The IPSec SAs negotiated between every two Endpoint nodes are different, and during the forwarding process, multiple encryption and decryption processes are required, which affects the forwarding performance. Summary of the Invention

[0005] In view of this, this application provides a communication method and apparatus to solve the problems of segmentally creating IPSec tunnels in the existing encryption protection solution, inconvenient network deployment, and multiple encryption and decryption processes during the forwarding process, which affect the forwarding performance.

[0006] In a first aspect, this application provides a communication method, which is applied to a first network device. The first network device includes a first interface. The method includes:

[0007] When receiving a first service packet sent by a first user-side device through the first interface, determine a first VPN instance bound to the first interface according to the first interface;

[0008] Obtain a corresponding first VPN SID in the routing table of the first VPN instance;

[0009] When it is determined to forward the first service packet through the SRv6 path, perform SRv6 encapsulation processing on the first service packet to obtain a second service packet, where the second service packet includes a SID list for indicating the SRv6 forwarding path and the first service packet;

[0010] If the first VPN SID exists in the SID list and there is an encryption mapping entry matching the first VPN SID in the local encryption mapping table, obtain the IPSec SA identifier from the encryption mapping entry;

[0011] Encrypt the first service packet included in the second service packet through the IPSec SA corresponding to the IPSec SA identifier to obtain a third service packet, where the third service packet includes the SID list and the encrypted first service packet;

[0012] Forward the third service packet to the next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device;

[0013] Wherein, the SRv6 path and the IPSec tunnel have been established between the first network device and the second network device.

[0014] In a second aspect, the present application provides a communication device, which is applied to a first network device, the first network device includes a first interface, and the device includes:

[0015] A determination unit, when receiving a first service packet sent by a first user-side device through the first interface, determines a first VPN instance bound to the first interface according to the first interface;

[0016] A first acquisition unit, configured to acquire a corresponding first VPN SID in the routing table of the first VPN instance;

[0017] An encapsulation unit, when it is determined to forward the first service packet through the SRv6 path, performs SRv6 encapsulation processing on the first service packet to obtain a second service packet, where the second service packet includes a SID list for indicating the SRv6 forwarding path and the first service packet;

[0018] A second acquisition unit, configured to, if the first VPN SID exists in the SID list and there is an encryption mapping entry matching the first VPN SID in the local encryption mapping table, obtain the IPSec SA identifier from the encryption mapping entry;

[0019] An encryption unit, configured to identify a corresponding IPSec SA through the IPSec SA, and perform encryption processing on the first service message included in the second service message to obtain a third service message, where the third service message includes the SID list and the encrypted first service message;

[0020] A sending unit, configured to forward the third service message to a next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service message to a second network device;

[0021] Wherein, an SRv6 path and an IPSec tunnel have been established between the first network device and the second network device.

[0022] In a third aspect, the present application provides a network device, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0023] Therefore, by applying the communication method and device provided in the present application, when a first service message sent by a first user-side device is received through a first interface, according to the first interface, the first network device determines a first VPN instance bound to the first interface; in the routing table of the first VPN instance, the first network device obtains a corresponding first VPN SID; when it is determined to forward the first service message through the SRv6 path, the first network device performs SRv6 encapsulation processing on the first service message to obtain a second service message, where the second service message includes an SID list for indicating the SRv6 forwarding path and the first service message; if the first VPN SID exists in the SID list and an encryption mapping entry matching the first VPN SID exists in the local encryption mapping table, the first network device obtains an IPSec SA identifier from the encryption mapping entry; through the IPSec SA corresponding to the IPSec SA identifier, the first network device performs encryption processing on the first service message included in the second service message to obtain a third service message, where the third service message includes the SID list and the encrypted first service message; through the SRv6 path, the first network device forwards the third service message to a next-hop network device, so that the next-hop network device forwards the third service message to a second network device; wherein, an SRv6 path and an IPSec tunnel have been established between the first network device and the second network device.

[0024] In this way, by establishing a mapping relationship between the VPN SID and the IPSec SA, it is ensured that the traffic of interest is encrypted and protected during the transmission process, achieving flexible and efficient service orchestration; during the forwarding process, there is no need for multi-layer encapsulation of service packets, and the encryption function is integrated with the SRv6 function to ensure efficient traffic forwarding. At the same time, it also solves the problems existing in the existing encryption protection scheme, such as segmentally creating IPSec tunnels, inconvenient network deployment, and multiple encryption and decryption processes during the forwarding process, which affect the forwarding performance. Brief Description of the Drawings

[0025] Figure 1 It is a flowchart of the communication method provided by an embodiment of the present application;

[0026] Figure 2 It is a schematic diagram of the communication network networking provided by an embodiment of the present application;

[0027] Figure 3 It is a structural diagram of the communication device provided by an embodiment of the present application;

[0028] Figure 4 It is a hardware structure of the network device provided by an embodiment of the present application. Detailed Embodiments

[0029] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0030] The terms used in the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. The singular forms "a", "the", and "said" used in the present 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" used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

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

[0032] The communication method provided by the embodiments of the present application will be described in detail below. Refer to Figure 1 , Figure 1 which is a flowchart of the communication method provided by the embodiments of the present application. This method is applied to a first network device. The communication method provided by the embodiments of the present application may include the following steps.

[0033] Step 110: When a first service packet sent by a first user-side device is received through the first interface, determine a first VPN instance bound to the first interface according to the first interface;

[0034] Specifically, the first network device includes a first interface and is connected to a first user-side device (e.g., a CE device) through the first interface. Through the first interface, the first network device receives the first service packet sent by the first user-side device.

[0035] After the first service packet arrives at the first interface, the first network device determines the first VPN instance bound to the first interface according to the first interface.

[0036] Step 120: Obtain a corresponding first VPN SID in the routing table of the first VPN instance;

[0037] Specifically, according to the description of step 110, after the first network device determines the first VPN instance bound to the first interface, it searches for a routing table entry that matches the destination address in the IPv4 routing table of the first VPN instance according to the destination address included in the first service packet. Through the found routing table entry, the first network device obtains the corresponding first VPN SID.

[0038] In the embodiments of the present application, the first VPN SID is a VPN SID configured in the routing table of a second VPN instance in a second network device. The first VPN SID is synchronized by the second network device to the first network device through a BGP protocol packet, and the BGP protocol packet also includes information such as an RT identifier, a host address, and a second network device address, so that the first network device traverses the local Import RT identifier according to the RT identifier and generates a host route to the host under the local first VPN instance indicated by the local input route target (abbreviation: Import RT) identifier that is the same as the RT identifier, and stores the first VPN SID in the IPv4 routing table of the first VPN instance.

[0039] Step 130: When it is determined to forward the first service packet through an SRv6 path, perform SRv6 encapsulation processing on the first service packet to obtain a second service packet, where the second service packet includes a SID list for indicating the SRv6 forwarding path and the first service packet;

[0040] Specifically, according to the description of step 120, after the first network device finds the routing table entry, it obtains the next hop and the outgoing interface from the matching routing table entry.

[0041] In the embodiment of the present application, the outgoing interface is indicated as an SRv6 Policy pre-configured in the first network device. At this time, the first network device determines to forward the first service packet through the SRv6 Policy. The first network device obtains the SID list from the SRv6 Policy, and according to the existing SRv6 protocol, encapsulates the SRH header and the IPv6 header respectively on the outer layer of the first service packet to obtain a second service packet. The SID list is stored in the SRH header, and this SID list is used to indicate the forwarding path for the first network device to reach the second network device. The second network device is the previous-hop network device of the device indicated by the destination address.

[0042] In this step, the SRv6 Policy is taken as an example of the SRv6 path for illustration. In actual applications, the SRv6 path can also be other forms such as SRv6 BE.

[0043] Step 140: If the first VPN SID exists in the SID list and there is an encryption mapping table entry matching the first VPN SID in the local encryption mapping table, obtain the IPSec SA identifier from the encryption mapping table entry;

[0044] Specifically, according to the descriptions of step 120 and step 130, after the first network device obtains the first VPN SID and the SID list, it first determines whether the first VPN SID exists in the SID list. If the first VPN SID exists in the SID list, the first network device then determines whether there is an encryption mapping table entry matching the first VPN SID in the local encryption mapping table.

[0045] If there is an encryption mapping table entry matching the first VPN SID, the first network device obtains the IPSec SA identifier from the encryption mapping table entry.

[0046] It can be understood that if the first VPN SID does not exist in the SID list, the first network device forwards and processes the second service packet according to the existing SRv6 protocol, and does not continue the subsequent judgment.

[0047] Step 150: Encrypt the first service packet included in the second service packet through the IPSec SA corresponding to the IPSec SA identifier to obtain a third service packet, where the third service packet includes the SID list and the encrypted first service packet;

[0048] Specifically, according to the description of step 140, after the first network device obtains the IPSec SA identifier, through the IPSec SA corresponding to the IPSec SA identifier, the first network device encrypts the first service packet included in the second service packet to obtain a third service packet.

[0049] For example, the first network device encrypts the first service packet using the ESP protocol, and the IPv6 header and SRH header encapsulated outside the first service packet are not encrypted. The first network device inserts an ESP header between the SRH header and the first service packet, and encapsulates an ESP tail at the end of the first service packet to obtain a third service packet. The encryption algorithms used by the ESP protocol include DES, 3DES, AES, etc. At the same time, as an option, the ESP protocol also provides an authentication service, and the authentication algorithms used include HMAC-MD5 and HMAC-SHA1.

[0050] It can be understood that the ESP protocol is a security protocol supported by both the first network device and the second network device. The IPSec SA is formed after the first network device pre-negotiates with the second network device through IKE.

[0051] Step 160: Forward the third service packet to the next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device.

[0052] Specifically, according to the description of step 150, after the first network device obtains the third service packet, it forwards the third service packet to the next-hop network device according to the forwarding path indicated by the SID list.

[0053] It can be understood that in order to achieve forwarding, the first network device also encapsulates a MAC header outside the IPv6 header, so that the third service packet can be forwarded hop by hop.

[0054] After the next-hop network device receives the third service packet, according to the existing SRv6 protocol, it updates the destination address included in the IPv6 header and continues to forward the third service packet on the forwarding path until the second network device receives the third service packet.

[0055] After the second network device receives the third service packet, according to the destination address included in the IPv6 header, the second network device looks up the local SID table and determines the VPN instance to which the destination address belongs. This VPN instance is the second VPN instance in the second network device. This destination address is also the aforementioned first VPN SID.

[0056] According to the existing SRv6 protocol, the second network device first performs decapsulation processing on the third service packet to obtain the encrypted first service packet. The second network device obtains the SPI from the ESP header included in the encrypted first service packet. According to the SPI, the second network device obtains the encryption mapping table entry that matches the SPI from the local encryption mapping table, and obtains the IPSec SA formed by prior negotiation with the first network device therefrom.

[0057] According to the IPSec SA, the second network device decrypts the encrypted first service packet to obtain the first service packet. According to the destination address included in the first service packet, the second network device looks up the routing table entry that matches the destination address in the IPv4 routing table of the second VPN instance, and obtains the next hop and the outgoing interface from the matching routing table entry.

[0058] Through the second interface indicated by the outgoing interface, the second network device sends the first service packet to the second user-side device (for example, CE device) accessed.

[0059] Therefore, by applying the communication method provided in this application, when receiving the first service packet sent by the first user-side device through the first interface, according to the first interface, the first network device determines the first VPN instance bound to the first interface; in the routing table of the first VPN instance, the first network device obtains the corresponding first VPN SID; when it is determined to forward the first service packet through the SRv6 path, the first network device performs SRv6 encapsulation processing on the first service packet to obtain the second service packet, and the second service packet includes the SID list for indicating the SRv6 forwarding path and the first service packet; if the first VPN SID exists in the SID list and there is an encryption mapping table entry that matches the first VPN SID in the local encryption mapping table, the first network device obtains the IPSec SA identifier from the encryption mapping table entry; through the IPSec SA corresponding to the IPSec SA identifier, the first network device encrypts the first service packet included in the second service packet to obtain the third service packet, and the third service packet includes the SID list and the encrypted first service packet; through the SRv6 path, the first network device forwards the third service packet to the next-hop network device, so that the next-hop network device forwards the third service packet to the second network device; wherein, an SRv6 path and an IPSec tunnel have been established between the first network device and the second network device.

[0060] In this way, by establishing the mapping relationship between the VPN SID and the IPSec SA, it is ensured that the interested traffic flows are encrypted and protected during the transmission process, realizing flexible and efficient service orchestration; during the forwarding process, there is no need for multi-layer encapsulation of service packets, and the encryption function is integrated with the SRv6 function to ensure efficient traffic forwarding. At the same time, it also solves the problems in the existing encryption protection solutions, such as segmentally creating IPSec tunnels, inconvenient network deployment, and multiple encryption and decryption processes during the forwarding process, which affect the forwarding performance.

[0061] Optionally, in the embodiment of the present application, before the first network device executes step 110, it also receives the private network route sent by the second network device and generates a host route locally according to the private network route.

[0062] Specifically, the second user-side device desires to synchronize its own private network route to the second network device. The second user-side device generates a second BGP protocol packet (for example, a BGP Update packet. Here, the second BGP protocol packet is only used to distinguish it from other BGP protocol packets. In practical applications, it can also be called the first BGP protocol packet), and the second BGP protocol packet includes a host address and an RT identifier, and the host address is the address of the second user-side device.

[0063] The second user-side device sends the second BGP protocol packet to the second interface included in the second network device to which it is connected. When the second BGP protocol packet arrives at the second interface, according to the RT identifier, the second network device traverses the local Import RT and determines the Import RT that is the same as the RT identifier from the local Import RT. In the embodiment of the present application, the determined Import RT indicates the second VPN instance.

[0064] In the IPv4 routing table of the second VPN instance, the second network device obtains the first VPN SID. At the same time, the second network device generates a host route to the host (the second user-side device) in the IPv4 routing table of the second VPN instance. The host route includes a destination address field, an outgoing interface field, and a next-hop field. Among them, the host address is stored in the destination address field, the identifier of the second interface is stored in the outgoing interface field, and the interface address of the third interface is stored in the next-hop field. The third interface is the interface through which the second user-side device accesses the second network device.

[0065] The second network device also generates a first BGP protocol packet (for example, a BGP Update packet), and the first BGP protocol packet includes a host address, an RT identifier, the first VPN SID configured in the IPv4 routing table of the second VPN instance indicated by the RT identifier, and the address of the second network device.

[0066] The second network device synchronizes the first BGP protocol packet to the first network device.

[0067] After receiving the first BGP protocol packet, the first network device obtains the host address, RT identifier, the first VPN SID, and the address of the second network device therefrom. According to the RT identifier, the first network device traverses the local Import RT and determines the Import RT that is the same as the RT identifier from the local Import RT. The determined Import RT indicates the first VPN instance. In the IPv4 routing table of the first VPN instance, the first network device stores the first VPN SID and generates a host route to the host (the second user-side device). The host route also includes a destination address field, an outgoing interface field, and a next-hop field. Among them, the host address is stored in the destination address field, the identifier of the pre-configured SRv6 Policy is stored in the outgoing interface field, and the address of the second network device is stored in the next-hop field.

[0068] It should be noted that, in one implementation, after receiving the first BGP protocol packet, the first network device may, according to the locally pre-configured routing policy, store the identifier of the SRv6 Policy in the outgoing interface field, so that after receiving a service packet destined for this host subsequently, the service packet is diverted to the SRv6 Policy for forwarding.

[0069] The above routing policy has configured the address of the second user-side device, the endpoint attribute and color attribute included in the SRv6 Policy, so that after receiving the first BGP protocol packet, the first network device matches the routing policy according to the host address and generates a host route locally.

[0070] In another implementation, the first BGP protocol packet further includes the identifier of the SRv6 Policy. When generating the host route, the first network device may store the identifier of the SRv6 Policy in the outgoing interface field, so that after receiving a service packet destined for the second user-side device subsequently, the service packet is diverted to the SRv6 Policy for forwarding.

[0071] It can be understood that after generating the host route, the first network device continues to synchronize the host route to the first user-side device, so that the first user-side device generates a host route to the host (the second user-side device) locally and distributes the host route to the local IP routing table. This generation process can refer to the existing routing generation process and will not be repeated here.

[0072] Optionally, in the embodiment of this application, before executing step 110, the first network device also negotiates an IPSec SA with the second network device.

[0073] Specifically, after the first network device generates the host route, it starts the process of negotiating IPSec SAs with the second network device.

[0074] According to the existing IKE protocol, in the first stage of negotiation, a channel for mutual authentication and secure protection of communication data is established between the first network device and the second network device, that is, an IKE SA is established. In the second stage of negotiation, the first network device and the second network device use the IKE SA established in the first stage to negotiate security services for IPsec, that is, to negotiate IPsec SAs for IPsec and establish IPsec SAs for the final secure transmission of IP data.

[0075] In the embodiment of the present application, the first network device and the second network device have established an IKE SA in accordance with the existing IKE protocol, which will not be repeated here.

[0076] After establishing the IKE SA, the first network device generates a first IKE protocol message, which includes first SA attributes supported by the first network device (for example, the security protocol used (AH, ESP, or a combination of both), the encapsulation mode of the protocol message (transport mode or tunnel mode), the authentication algorithm (HMAC-MD5 or HMAC-SHA1), the encryption algorithm (DES, 3DES, or AES), the shared key for protecting data in a specific flow, and the lifetime of the key), a first VPN SID, and a second VPN SID.

[0077] Among them, the first IKE protocol message includes a client initiator identifier (IDci) field and a client responder (IDcr) field. The IDci field is used to carry the second VPN SID, and the IDcr field is used to carry the first VPN SID. The second VPN SID is the VPN SID configured in the IPv4 router of the first VPN instance of the first network device.

[0078] It can be understood that the first IKE protocol message also includes a first random number, a first message sequence number, a first hash value, etc. The first hash value is obtained by the first network device after performing a hash calculation on the first random number, the first message sequence number, the first VPN SID, and the second VPN SID.

[0079] The first network device sends the first IKE protocol message to the second network device through the IKE SA.

[0080] After the second network device receives the first IKE protocol message, it obtains the first SA attribute, the first VPN SID, and the second VPN SID supported by the first network device therefrom. According to the first SA attribute, the second network device selects the second SA attribute supported by itself from the first SA attribute (for each sub-attribute, the second network device selects one sub-attribute supported by itself).

[0081] The second network device generates a second IKE protocol message, which includes the second SA attribute, the first VPN SID, and the second VPN SID supported by the second network device.

[0082] Among them, the second IKE protocol message also includes an IDci field and an IDcr field. The IDci field is used to carry the second VPN SID, and the IDcr field is used to carry the first VPN SID.

[0083] It can be understood that the second IKE protocol message also includes contents such as the first random number, the second random number, the second message sequence number, and the second hash value. The second hash value is obtained by the second network device performing a hash calculation on the first random number, the second random number, the second message sequence number, the first VPN SID, and the second VPN SID.

[0084] The second network device sends the second IKE protocol message to the first network device through the IKE SA.

[0085] After the first network device receives the second IKE protocol message, it obtains the second SA attribute, the first VPN SID, and the second VPN SID therefrom. According to the second SA attribute, the first network device determines each sub-attribute supported by the second network device. The first network device generates a third IKE protocol message and sends the third IKE protocol message to the second network device again through the IKE SA. The third IKE protocol message is used to notify the second network device that the first network device has completed the IPSec SA negotiation with the second network device.

[0086] It can be understood that the third IKE protocol message also includes contents such as the first random number, the second random number, the third message sequence number, and the third hash value. The third hash value is obtained by the first network device performing a hash calculation on the first random number, the second random number, and the third message sequence number.

[0087] After the second network device receives the third IKE protocol message, it determines that the IPSec SA negotiation with the first network device has been completed.

[0088] Optionally, in the embodiments of the present application, after the first network device sends the third IKE protocol message to the second network device, the first network device further generates an encryption mapping entry, which is used to store the mapping relationship between the IPSec SA and the VPN SID. The encryption mapping entry includes the IPSec SA identifier of the negotiated IPSec SA and the first VPN SID.

[0089] The first network device stores the encryption mapping entry into the local encryption mapping table.

[0090] Optionally, the encryption mapping entry further includes information such as the second VPN SID, SPI, key, algorithm, etc.

[0091] It can be understood that after receiving the third IKE protocol message, the second network device also generates an encryption mapping entry and stores the encryption mapping entry into the local encryption mapping table. The encryption mapping entry generated by the second network device and the encryption mapping entry generated by the first network device include the IPSec SA identifier of the negotiated IPSec SA and the second VPN SID. The encryption mapping entry further includes information such as the first VPN SID, SPI, key, algorithm, etc.

[0092] Therefore, by carrying the VPN SID configured under the VPN instance in the IKE protocol message, when forwarding the service message under the VPN instance subsequently, the negotiated IPSec SA can be used to encrypt the service message to ensure service security.

[0093] In practical applications, the communication method of the embodiments of the present application can also be used in networking scenarios such as EVPN VPLS over SRv6 and EVPN VPWS over SRv6. At this time, different types of VPN SIDs are configured in different scenarios. For example, in the EVPN VPLS over SRv6 networking scenario, the VPN SID can be configured as an End.DT2U type SID; in the EVPN VPWS over SRv6 networking scenario, the VPN SID can be configured as an End.DX2 type SID. The IPSec SA can also implement encryption protection for the service flows in the above networking scenarios.

[0094] The communication method provided by the embodiments of the present application will be described in detail below. Refer to Figure 2 , Figure 2 which is the schematic diagram of the communication network networking provided by the embodiments of the present application. In Figure 2It includes CE1, PE1, P, PE2, and CE2. CE1 and CE2 are user-side devices respectively, and PE1, P, and PE2 are network-side devices respectively. The IP address of each device is its own LoopBack address. For example, the IPv4 address of CE1 is 11.11.11.11 / 32, and the IPv6 address of PE1 is 2001:DB8:1::1 / 128. An EBGP neighbor is established between CE1 and PE1, and an EBGP neighbor is established between CE2 and PE2. A BGP neighbor is established between PE1 and PE2, and an IPSec tunnel is established.

[0095] PE1 includes interface 1 (address: 10.1.1.1 / 24), and this interface 1 is connected to interface 3 (address: 10.1.1.2 / 24) included in CE1. Interface 1 is bound to VPN1; PE2 includes interface 2 (address: 10.2.1.1 / 24), and this interface 2 is connected to interface 4 (address: 10.2.1.2 / 24) included in CE2. Interface 2 is bound to VPN1.

[0096] PE1 and PE2 belong to AS100. A bidirectional SRv6 TE Policy is established between the two devices, and this SRv6 TE Policy can be used to carry IP L3VPNv4 services. The configuration of PE1 is as follows:

[0097] Segment-routing ipv6

[0098] Segment-list PE1-PE2

[0099] Index5 sid ipv6 2001:DB8:100::1

[0100] Index10 sid ipv6 2001:DB8:200::2

[0101] Srv6-te policy policy1 endpoint 2001:DB8:3::3color101

[0102] Candidate-path preference 200

[0103] Segment-list PE1-PE2

[0104] Similarly, the configuration of PE2 is as follows:

[0105] Segment-routing ipv6

[0106] Segment-list PE2-PE1

[0107] Index5 sid ipv6 2001:DB8:300::1

[0108] Index10 sid ipv6 2001:DB8:200::1

[0109] Srv6-te policy policy1 endpoint 2001:DB8:1::1 color101

[0110] Candidate-path preference 200

[0111] Segment-list PE2-PE1

[0112] It can be understood that the type of 2001:DB8:100::1 configured on PE1 is End.X SID, which is used to represent the link between PE1 and P; similarly, the type of 2001:DB8:300::1 configured on PE2 is End.X SID, which is used to represent the link between PE2 and P; the type of 2001:DB8:200::1 configured on P is End.X SID, which is used to represent the link between P and PE1; the type of 2001:DB8:200::2 configured on P is End.X SID, which is used to represent the link between P and PE2. As Figure 2 shown, the arrow direction above the End.X SID indicates the link direction represented by the End.X SID.

[0113] Inside PE1, a VPN SID1 (2001:DB8:100::100) of type End.DT4 is also configured in the IPv4 routing table of VPN1; similarly, inside PE2, a VPN SID2 (2001:DB8:300::300) of type End.DT4 is configured in the IPv4 routing table of VPN1.

[0114] CE2 wants to synchronize the IPv4 private network routes to PE2. CE2 generates a BGP protocol message 1, which includes the address of CE2 (22.22.22.22 / 32) and the RT identifier (1:1). CE2 sends the BGP protocol message 1 to interface 2. When the BGP protocol message 2 arrives at interface 2, according to the RT identifier (1:1), PE2 traverses the local Import RT and determines the Import RT that is the same as this RT identifier from the local Import RT. In the embodiment of the present application, the determined Import RT indicates VPN1 inside PE2.

[0115] In the IPv4 routing table of VPN1, PE2 obtains the VPN SID2 configured in its IPv4 routing table. At the same time, PE2 generates a host route to CE2 within the IPv4 routing table of VPN1. This host route includes a destination address field, an outgoing interface field, and a next-hop field. Among them, the CE2 address (22.22.22.22 / 32) is stored in the destination address field, the identifier of interface 2 is stored in the outgoing interface field, and the address of interface 4 is stored in the next-hop field. This interface 4 is the interface through which CE2 accesses PE2.

[0116] PE2 also generates BGP protocol message 2, which includes a host address, an RT identifier, VPN SID2, and the address of PE2.

[0117] Through P, PE2 synchronizes BGP protocol message 2 to PE2.

[0118] After receiving BGP protocol message 2, PE1 obtains the host address, RT identifier, VPN SID2, and the address of PE2 from it. According to the RT identifier, PE1 traverses the local Import RT and determines the Import RT that is the same as the RT identifier from the local Import RT. The determined Import RT indicates the VPN within PE1. In the IPv4 routing table of VPN1, PE1 stores VPNSID2 and generates a host route to the host, that is, a host route to CE2. This host route also includes a destination address field, an outgoing interface field, and a next-hop field. Among them, the CE2 address (22.22.22.22 / 32) is stored in the destination address field, the identifier of the pre-configured SRv6 Policy (policy1) is stored in the outgoing interface field, and the address of PE2 (2001:DB8:3::3) is stored in the next-hop field.

[0119] In an implementation of this embodiment of the present application, after receiving BGP protocol message 2, PE1 can, according to the locally pre-configured routing policy, store the identifier of the SRv6 Policy in the outgoing interface field, so that after receiving a service message destined for CE2 subsequently, the service message is diverted to the SRv6 Policy for forwarding. The above routing policy has configured the endpoint attribute, color attribute, and the address of CE2 included in the SRv6Policy, so that after receiving BGP protocol message 2, PE1 matches the routing policy according to the host address and generates a host route locally.

[0120] In another implementation, the BGP protocol packet 2 further includes an identifier of the SRv6 Policy. When generating the host route, PE1 can store the identifier of the SRv6 Policy in the outgoing interface field, so that after receiving the service packet destined for CE2 subsequently, the service packet is diverted to the SRv6 Policy for forwarding.

[0121] After generating the host route, PE1 continues to synchronize the host route to CE1, so that CE1 generates a host route to CE2 locally and distributes the host route to the local IP routing table. This generation process can refer to the existing route generation process and will not be repeated here.

[0122] After generating the host route, PE1 starts the process of negotiating the IPSec SA with PE2.

[0123] According to the existing IKE protocol, in the first stage of negotiation, a channel for mutual authentication of identities and security protection of communication data is established between PE1 and PE2, that is, an IKE SA is established. In the second stage of negotiation, PE1 and PE2 use the IKE SA established in the first stage to negotiate security services for IPsec, that is, negotiate the IPsec SA for IPsec, and establish the IPsec SA for the final secure transmission of IP data.

[0124] In the embodiment of the present application, PE1 and PE2 have established the IKE SA according to the existing IKE protocol, which will not be repeated here.

[0125] After establishing the IKE SA, PE1 generates the IKE protocol packet 1, which includes SA attribute 1 supported by PE1 (for example, the security protocol used (AH, ESP, or both), the encapsulation mode of the protocol packet (transport mode or tunnel mode), the authentication algorithm (HMAC-MD5 or HMAC-SHA1), the encryption algorithm (DES, 3DES, or AES), the shared key for protecting data in a specific flow, and the lifetime of the key), VPN SID1, and VPN SID2.

[0126] Among them, the IKE protocol packet 1 includes an IDci field and an IDcr field. The IDci field is used to carry VPN SID1, and the IDcr field is used to carry VPN SID2.

[0127] It can be understood that the IKE protocol packet 1 further includes random number 1, packet sequence number 1, hash value 1, etc. The hash value 1 is obtained by PE1 performing a hash calculation on random number 1, packet sequence number 1, VPN SID1, and VPN SID2. Random number 1 is randomly generated by PE1.

[0128] PE1 sends IKE protocol message 1 to PE2 via IKE SA.

[0129] After receiving IKE protocol message 1, PE2 obtains SA attribute 1, VPN SID1, and VPNSID2 supported by PE1 from it. According to SA attribute 1, PE2 selects SA attribute 2 supported by itself from SA attribute 1 (PE2 selects one sub-attribute supported by itself in each sub-attribute).

[0130] PE2 generates IKE protocol message 2, which includes SA attribute 2 supported by PE2, VPN SID1, and VPN SID2.

[0131] Among them, IKE protocol message 2 also includes IDci field and IDcr field. The IDci field is used to carry VPN SID2, and the IDcr field is used to carry VPN SID2.

[0132] It can be understood that IKE protocol message 2 also includes contents such as random number 1, random number 2, message sequence number 2, hash value 2, etc. This hash value 2 is obtained by PE2 after performing hash calculation on random number 1, random number 2, message sequence number 2, VPN SID1, and VPN SID2. Random number 2 is randomly generated by PE2.

[0133] PE2 sends IKE protocol message 2 to PE1 via IKE SA.

[0134] After receiving IKE protocol message 2, PE1 obtains SA attribute 2, VPN SID1, and VPN SID2 from it. According to SA attribute 2, PE1 determines each sub-attribute supported by PE2. PE1 generates IKE protocol message 3 and sends IKE protocol message 3 to PE2 again via IKE SA. This IKE protocol message 3 is used to notify PE2 that PE1 has completed the IPSec SA negotiation with PE2.

[0135] It can be understood that IKE protocol message 3 also includes contents such as random number 1, random number 2, message sequence number 3, hash value 3, etc. This hash value 3 is obtained by PE1 after performing hash calculation on random number 1, random number 2, and message sequence number 3.

[0136] After receiving IKE protocol message 3, PE2 determines that it has completed the IPSec SA negotiation with PE1.

[0137] After PE1 sends IKE protocol packet 3 to PE2, PE1 will also generate an encryption mapping entry, which is used to store the mapping relationship between the IPSec SA and the VPN SID. Among them, the encryption mapping entry includes the IPSec SA identifier of the negotiated IPSec SA, VPN SID1, and VPN SID2.

[0138] PE1 stores the encryption mapping entry in the local encryption mapping table. Similarly, after receiving IKE protocol packet 3, PE2 also generates an encryption mapping entry and stores it in the local encryption mapping table. The encryption mapping entry generated by PE2 is the same as that generated by PE1.

[0139] CE1 wants to communicate with CE2 for services. CE1 generates service packet 1. The source address included in the service packet 1 is the address of CE1 (11.11.11.11 / 32), and the destination address included is the address of CE2 (22.22.22.22 / 32).

[0140] Through interface 1, PE1 receives service packet 1. According to interface 1, PE1 determines VPN1 bound to interface 1. After determining VPN1, PE1 looks up the routing table entry that matches the destination address in the IPv4 routing table of VPN1 according to the destination address included in service packet 1. Through the found routing table entry, PE1 obtains the VPN SID2 synchronized by PE2 through BGP protocol packet 2.

[0141] After PE1 finds the routing table entry, it obtains the next hop and the outgoing interface from the matching routing table entry.

[0142] In the embodiment of this application, the outgoing interface is indicated as SRv6 Policy1 pre-configured in PE1. At this time, PE1 determines to forward service packet 1 through SRv6 Policy1. PE1 obtains the SID list from SRv6 Policy1 and encapsulates the SRH header and the IPv6 header on the outer layer of service packet 1 respectively according to the existing SRv6 protocol to obtain service packet 2.

[0143] In the embodiment of this application, PE1 first encapsulates the SRH header on the outer layer of service packet 1. The SID list included in the SRv6 Policy1 is stored in the SRH header. The SID list is used to indicate the forwarding path for PE1 to reach PE2, and the SIDs included are: SID[0]=2001:DB8:300::300, SID[1]=2001:DB8:200::2, SID[2]=2001:DB8:100::1. The VPN SID2 configured under VPN1 in PE2 is stored in SID[0], and the SIDs representing the links are stored in SID[1] and SID[0].

[0144] PE1 continues to encapsulate an IPv6 header outside the SRH header. The source address included in this IPv6 header is 2001:DB8:1::1, and the destination address is 2001:DB8:200::2.

[0145] After PE1 obtains the VPN SID2 and the SID list, it first determines whether the VPN SID2 exists in the SID list. In the embodiment of this application, the VPN SID2 exists in the SID list, and PE1 continues to determine whether there is an encryption mapping table entry in the local encryption mapping table that matches the VPN SID2.

[0146] If there is an encryption mapping table entry that matches the VPN SID2, then PE1 obtains the IPSec SA identifier from the encryption mapping table entry. Through the IPSec SA corresponding to the IPSec SA identifier, PE1 encrypts the service packet 1 included in the service packet 2 to obtain the service packet 3.

[0147] In the embodiment of this application, PE1 uses the ESP protocol to encrypt the service packet 1, and the IPv6 header and SRH header encapsulated outside the service packet 1 are not encrypted. PE1 inserts an ESP header between the SRH header and the service packet 1, and encapsulates an ESP tail at the end of the service packet 1 to obtain the service packet 3. The encryption algorithms used by the ESP protocol include DES, 3DES, AES, etc. At the same time, as an option, the ESP protocol also provides an authentication service, and the authentication algorithms used include HMAC-MD5 and HMAC-SHA1.

[0148] After PE1 encrypts the service packet 1, according to SID[2] in the SID list, it looks up the local SID table and determines that the type of this SID is End.X SID. PE1 forwards the service packet 3 to P according to the forwarding method indicated by the existing End.X SID type.

[0149] It can be understood that, in order to achieve forwarding, PE1 also encapsulates a MAC header outside the IPv6 header so that the service packet 3 can be forwarded hop by hop.

[0150] After P receives the service packet 3, according to the existing SRv6 protocol, it updates the destination address of the IPv6 header to obtain the service packet 4. P continues to forward the service packet 4 to PE2 on the forwarding path.

[0151] After PE2 receives service packet 4, according to the destination address included in the IPv6 header, PE2 looks up the local SID table and determines the VPN1 to which the destination address belongs. According to the existing SRv6 protocol, PE2 performs decapsulation processing on service packet 4 to obtain decrypted service packet 1. PE2 obtains the SPI from the ESP header included in the encrypted service packet 1. According to the SPI, PE2 obtains the encryption mapping table entry that matches the SPI from the local encryption mapping table, and obtains the IPSec SA identifier formed by prior negotiation with PE1 therefrom.

[0152] According to the IPSec SA corresponding to the IPSec SA identifier, PE2 performs decryption processing on the encrypted service packet 1 to obtain service packet 1. According to the destination address included in service packet 1, PE2 looks up the routing table entry that matches the destination address in the IPv4 routing table of VPN1, and obtains the next hop and the outgoing interface from the matching routing table entry.

[0153] Through interface 2 indicated by the outgoing interface, PE2 sends service packet 1 to CE2.

[0154] Based on the same inventive concept, an embodiment of the present application further provides a communication device corresponding to the communication method. Refer to Figure 3 , Figure 3 For the communication device provided by the embodiment of the present application, the device is applied to a first network device, the first network device includes a first interface, and the device includes:

[0155] Determination unit 310, when receiving a first service packet sent by a first user-side device through the first interface, determines a first VPN instance bound to the first interface according to the first interface;

[0156] First acquisition unit 320, configured to obtain a corresponding first VPN SID in the routing table of the first VPN instance;

[0157] Encapsulation unit 330, configured to perform SRv6 encapsulation processing on the first service packet to obtain a second service packet when it is determined that the first service packet is forwarded through an SRv6 path, where the second service packet includes a SID list for indicating the SRv6 forwarding path and the first service packet;

[0158] Second acquisition unit 340, configured to obtain an IPSec SA identifier from the encryption mapping table entry if the first VPN SID exists in the SID list and an encryption mapping table entry that matches the first VPN SID exists in the local encryption mapping table;

[0159] An encryption unit 350 is configured to identify a corresponding IPSec SA through the IPSec SA, encrypt the first service message included in the second service message to obtain a third service message, where the third service message includes the SID list and the encrypted first service message;

[0160] A sending unit 360 is configured to forward the third service message to the next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service message to the second network device;

[0161] Wherein, an SRv6 path and an IPSec tunnel have been established between the first network device and the second network device.

[0162] Optionally, the apparatus further includes:

[0163] A receiving unit (not shown in the figure) is configured to receive a first BGP protocol message sent by the second network device, where the first BGP protocol message includes a host address, an RT identifier, a first VPN SID configured in a routing table of a second VPN instance in the second network device indicated by the RT identifier, and an address of the second network device;

[0164] A determining unit (not shown in the figure) is configured to traverse a local Import RT according to the RT identifier, determine an Import RT identical to the RT identifier from the local Import RT, and the determined Import RT indicates the first VPN instance;

[0165] A generating unit (not shown in the figure) is configured to generate a host route to a host indicated by the host address in a routing table of the first VPN instance, where the host route includes the host address and the address of the second network device;

[0166] A storage unit (not shown in the figure) is configured to store the first VPN SID in a routing table of the first VPN instance;

[0167] Wherein, the first BGP protocol message is sent after the second network device receives a second BGP protocol message sent by a second user-side device, and the second BGP protocol message includes the host address and the RT identifier.

[0168] Optionally, the sending unit 360 is further configured to send a first IKE protocol message to the second network device, where the first IKE protocol message includes a first SA attribute supported by the first network device, the first VPN SID, and a second VPN SID;

[0169] The receiving unit (not shown in the figure) is further configured to receive a second IKE protocol packet sent by the second network device, where the second IKE protocol packet includes a second SA attribute supported by the second network device, the first VPN SID, and a second VPN SID;

[0170] The sending unit 360 is further configured to send a third IKE protocol packet to the second network device, where the third IKE protocol packet is used to enable the second network device to determine that the IPSec SA negotiation with the first network device has been completed;

[0171] Wherein, the second SA attribute is an SA attribute supported by the second network device selected from the first SA attribute; the second VPN SID is a VPNSID configured in the routing table of the first VPN instance.

[0172] Optionally, the first IKE protocol packet or the second IKE protocol packet both respectively include a client initiator identifier and a client responder identifier;

[0173] The client initiator identifier carries the second VPN SID, and the client responder identifier carries the first VPN SID.

[0174] Optionally, the storage unit (not shown in the figure) is further configured to store the mapping relationship between the IPSec SA identifier of the negotiated IPSec SA and the first VPN SID into the encryption mapping entry.

[0175] Therefore, by applying the communication device provided in this application, when a first service message sent by a first user-side device is received through a first interface, according to the first interface, a first network device determines a first VPN instance bound to the first interface; in the routing table of the first VPN instance, the first network device obtains a corresponding first VPN SID; when it is determined to forward the first service message through an SRv6 path, the first network device performs SRv6 encapsulation processing on the first service message to obtain a second service message, which includes a SID list for indicating the SRv6 forwarding path and the first service message; if the first VPN SID exists in the SID list and there is an encryption mapping entry matching the first VPN SID in the local encryption mapping table, the first network device obtains an IPSec SA identifier from the encryption mapping entry; through the IPSec SA corresponding to the IPSec SA identifier, the first network device encrypts the first service message included in the second service message to obtain a third service message, which includes the SID list and the encrypted first service message; through the SRv6 path, the first network device forwards the third service message to the next-hop network device, so that the next-hop network device forwards the third service message to the second network device; wherein, an SRv6 path and an IPSec tunnel have been established between the first network device and the second network device.

[0176] In this way, by establishing a mapping relationship between the VPN SID and the IPSec SA, it is ensured that the interested traffic flow is encrypted and protected during transmission, realizing flexible and efficient service orchestration; during the forwarding process, there is no need for multi-layer encapsulation of service messages, and the encryption and SRv6 functions are integrated to ensure efficient traffic forwarding. At the same time, it also solves the problems of the existing encryption protection scheme, such as creating IPSec tunnels segment by segment, inconvenient network deployment, and multiple encryption and decryption processes during the forwarding process, which affect the forwarding performance.

[0177] Based on the same inventive concept, an embodiment of this application also provides a network device, as Figure 4 shown, including a processor 410, a transceiver 420, and a machine-readable storage medium 430. The machine-readable storage medium 430 stores machine-executable instructions that can be executed by the processor 410. The processor 410 is prompted by the machine-executable instructions to execute the communication method provided in the embodiment of this application. The foregoing Figure 3 shown communication device can be implemented by using the hardware structure of the network device as Figure 4 shown.

[0178] The above computer-readable storage medium 430 may include a Random Access Memory (RAM), and may also include a Non-volatile Memory (NVM), such as at least one disk memory. Optionally, the computer-readable storage medium 430 may also be at least one storage device located far from the aforementioned processor 410.

[0179] The above processor 410 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may 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, discrete hardware components.

[0180] In the embodiment of the present application, the processor 410 reads the machine-executable instructions stored in the machine-readable storage medium 430, and is prompted by the machine-executable instructions to enable the processor 410 itself and to call the transceiver 420 to execute the communication method described in the foregoing embodiment of the present application.

[0181] In addition, the embodiment of the present application provides a machine-readable storage medium 430, and the machine-readable storage medium 430 stores machine-executable instructions. When the machine-executable instructions are called and executed by the processor 410, the machine-executable instructions prompt the processor 410 itself and to call the transceiver 420 to execute the communication method described in the foregoing embodiment of the present application.

[0182] For the specific implementation process of the functions and roles of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method, which will not be elaborated here.

[0183] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the descriptions in the method embodiments. The device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application. A person of ordinary skill in the art can understand and implement it without creative work.

[0184] For the communication device and machine-readable storage medium embodiments, since the method content involved is basically similar to the foregoing method embodiments, the description is relatively simple, and the relevant parts can be referred to the descriptions in the method embodiments.

[0185] The above are only the preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of this application shall be included in the scope of protection of this application.

Claims

1. A communication method, characterized in that: The method is applied to a first network device, the first network device includes a first interface, and the method includes: When a first service message sent by a first user-side device is received through the first interface, determining a first VPN instance bound to the first interface according to the first interface; In the routing table of the first VPN instance, obtain the corresponding first VPN SID; When it is determined that the first service message is forwarded through the SRv6 path, the first service message is encapsulated in SRv6 to obtain a second service message, where the second service message includes a SID list for indicating the SRv6 forwarding path and the first service message; If the first VPN SID exists in the SID list and an encryption mapping table entry matching the first VPNSID exists in the local encryption mapping table, acquiring the IPSec SA identifier from the encryption mapping table entry; Encrypting the first service message included in the second service message through the IPSec SA corresponding to the IPSec SA identifier to obtain a third service message, wherein the third service message includes the SID list and the encrypted first service message; Forwarding the third service message to the next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service message to the second network device; The first network device has established the SRv6 path and the IPSec tunnel with the second network device.

2. The method according to claim 1, characterized in that When a first service message sent by a user-side device is received through the first interface, before determining, according to the first interface, a first VPN instance bound to the first interface, the method further includes: receiving a first BGP protocol message sent by the second network device, where the first BGP protocol message includes a host address, an RT identifier, a first VPN SID configured in a routing table of a second VPN instance in the second network device indicated by the RT identifier, and an address of the second network device; According to the RT identifier, traverse the local Import RT, and determine the Import RT that is the same as the RT identifier from the local Import RT, and the determined Import RT indicates the first VPN instance; In the routing table of the first VPN instance, generating a host route to the host indicated by the host address, the host route including the host address and the address of the second network device; storing the first VPN SID in a routing table of the first VPN instance; The first BGP protocol message is sent by the second network device after receiving the second BGP protocol message sent by the second user-side device, and the second BGP protocol message includes the host address and the RT identifier.

3. The method according to claim 2, characterized in that When a first service message sent by a user-side device is received through the first interface, before determining, according to the first interface, a first VPN instance bound to the first interface, the method further includes: Sending a first IKE protocol message to the second network device, where the first IKE protocol message includes a first SA attribute supported by the first network device, the first VPN SID, and a second VPN SID; receiving a second IKE protocol message sent by the second network device, where the second IKE protocol message includes a second SA attribute supported by the second network device, the first VPN SID, and the second VPN SID; Sending a third IKE protocol message to the second network device, where the third IKE protocol message is used to enable the second network device to determine that the IPSec SA negotiation has been completed with the first network device; The second SA attribute is an SA attribute supported by the second network device and selected by the second network device from the first SA attribute; and the second VPN SID is a VPN SID configured in the routing table of the first VPN instance.

4. The method according to claim 3, characterized in that The first IKE protocol message or the second IKE protocol message respectively includes a client initiator identifier and a client responder identifier; The client initiator identifier carries the second VPN SID, and the client responder identifier carries the first VPN SID.

5. The method according to claim 3, characterized in that: After sending the third IKE protocol message to the second network device, the method further includes: The mapping relationship between the negotiated IPSec SA identifier and the first VPN SID is stored in the encryption mapping table entry.

6. A communication device, characterized in that: The apparatus is applied to a first network device, the first network device includes a first interface, and the apparatus includes: a determining unit, which determines, according to the first interface, a first VPN instance bound to the first interface when receiving a first service message sent by a first user-side device through the first interface; A first acquiring unit, configured to acquire a corresponding first VPN SID in a routing table of the first VPN instance; an encapsulation unit, configured to, when determining to forward the first service message through an SRv6 path, perform SRv6 encapsulation processing on the first service message to obtain a second service message, wherein the second service message includes a SID list for indicating the SRv6 forwarding path and the first service message; a second acquiring unit, configured to acquire an IPSec SA identifier from the encrypted mapping entry if the first VPN SID exists in the SID list and an encrypted mapping entry matching the first VPN SID exists in the local encrypted mapping table; an encryption unit, configured to encrypt the first service message included in the second service message by using the IPSec SA corresponding to the IPSec SA identifier to obtain a third service message, wherein the third service message includes the SID list and the encrypted first service message; A sending unit, configured to forward the third service message to a next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service message to the second network device; The first network device has established the SRv6 path and the IPSec tunnel with the second network device.

7. The device according to claim 6, characterized in that The device also includes: a receiving unit, configured to receive a first BGP protocol message sent by the second network device, wherein the first BGP protocol message includes a host address, an RT identifier, a first VPN SID configured in a routing table of a second VPN instance in the second network device indicated by the RT identifier, and an address of the second network device; a determining unit, configured to traverse the local Import RT according to the RT identifier, and determine the Import RT identical to the RT identifier from the local Import RT, wherein the determined Import RT indicates the first VPN instance; a generating unit, configured to generate, in a routing table of the first VPN instance, a host route to the host indicated by the host address, wherein the host route includes the host address and an address of the second network device; a storage unit, configured to store the first VPN SID in a routing table of the first VPN instance; The first BGP protocol message is sent by the second network device after receiving the second BGP protocol message sent by the second user-side device, and the second BGP protocol message includes the host address and the RT identifier.

8. The device according to claim 7, characterized in that The sending unit is further configured to send a first IKE protocol message to the second network device, where the first IKE protocol message includes a first SA attribute supported by the first network device, the first VPN SID, and a second VPN SID; The receiving unit is further configured to receive a second IKE protocol message sent by the second network device, where the second IKE protocol message includes a second SA attribute supported by the second network device, the first VPN SID, and a second VPN SID; The sending unit is further used to send a third IKE protocol message to the second network device, where the third IKE protocol message is used to enable the second network device to determine that the IPSec SA negotiation has been completed with the first network device; The second SA attribute is an SA attribute supported by the second network device and selected by the second network device from the first SA attribute; and the second VPN SID is a VPN SID configured in the routing table of the first VPN instance.

9. The device according to claim 8, characterized in that The first IKE protocol message or the second IKE protocol message respectively includes a client initiator identifier and a client responder identifier; The client initiator identifier carries the second VPN SID, and the client responder identifier carries the first VPN SID.

10. The device according to claim 8, characterized in that The storage unit is further configured to store the mapping relationship between the negotiated IPSec SA identifier of the IPSecSA and the first VPN SID in the encryption mapping table entry.

Images