The present application claims priority from chinese patent office, application number 202010785073.1, chinese patent application entitled "a method, apparatus, and system for P2MP tunnel detection" filed 8/6/2020, the entire contents of which are incorporated herein by reference.
Detailed Description
The technical scheme of the application will be described below with reference to the accompanying drawings.
The present application will present various aspects, embodiments, or features about a system comprising a plurality of devices, components, modules, etc. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. Furthermore, combinations of these schemes may also be used.
In addition, in the embodiments of the present application, words such as "exemplary," "for example," and the like are used to indicate an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the term use of an example is intended to present concepts in a concrete fashion.
In embodiments of the present application, "corresponding (corresponding, relevant)" and "corresponding (corresponding)" may sometimes be used in combination, and it should be noted that the meaning of their intended expression is consistent when de-emphasizing their distinction.
The network architecture and the service scenario described in the embodiments of the present application are for more clearly describing the technical solution of the embodiments of the present application, and do not constitute a limitation on the technical solution provided by the embodiments of the present application, and those skilled in the art can know that, with the evolution of the network architecture and the appearance of the new service scenario, the technical solution provided by the embodiments of the present application is applicable to similar technical problems.
Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.
In the present application, "at least one" means one or more, and "a plurality" means two or more. "and/or" describing an association relationship of associated objects means that there may be three relationships, for example, A and/or B, and that it may mean that there is A alone, both A and B together, and B alone, where A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (a, b, or c) of a, b, c, a-b, a-c, b-c, or a-b-c may be represented, wherein a, b, c may be single or plural.
Multicast (multicast) is a data transmission method that uses a multicast address to send user multicast messages to multiple receivers on a transmission control protocol (transmission control protocol, TCP)/internet protocol (internet protocol, IP) network in an efficient manner at the same time. The multicast source sends a multicast stream to multicast group members in a multicast group via links in the network, which can each receive the multicast stream. The multicast transmission mode realizes the point-to-multipoint data connection between the multicast source and the multicast group members. Since the multicast stream only needs to be delivered once per network link, and only when a branch occurs on the link, the multicast is replicated. Therefore, the multicast transmission mode improves the data transmission efficiency and reduces the possibility of congestion of the backbone network.
The IP multicast technique uses the multicast group address as the destination address of the message and uses independent multicast protocol (protocol independent multicast, PIM) signaling to build a multicast forwarding tree. And the network plane logic tree is utilized to realize the data forwarding from multicast point to multipoint. The IP multicast technology for constructing the multicast forwarding tree can realize the efficient point-to-multipoint data transmission in the IP network, and can effectively save network bandwidth and reduce network load. Therefore, the method has wide application in the aspects of real-time data transmission, multimedia conferences, data copying, interactive network televisions (internet protocol television, IPTV), games, simulation and the like.
As an example, the IP multicast technique described above may be implemented by using the internet protocol sixth edition (internet protocol version, ipv 6) unicast address as the destination address of the message. A point-to-multipoint (point to multipoint, P2 MP) forwarding path is established between an ingress router to a plurality of egress routers, and multicast packets are forwarded along the P2MP forwarding path. As an example, the P2MP forwarding path may be used as a tunnel, and the ingress router encapsulates the user multicast packet in the tunnel, and the egress router decapsulates, restores and sends the user multicast packet.
Fig. 1 is a schematic view of a scenario suitable for use in embodiments of the present application. R1, R3, R5, R6, R7, R8 may be included in the segment routing replication (segment routing replication) domain of FIG. 1. Wherein, R1 is an ingress (ingress) device of the segment routing replication domain, which is responsible for IPv6 encapsulation of the user multicast message. Specifically, an IPv6 header may be encapsulated in the outer layer of the user multicast packet, where the IPv6 header may include a destination address (destination address, DA) field and a Source Address (SA) field. R3 and R5 are intermediate forwarding (transit) equipment of the segment routing replication domain, and are responsible for forwarding the message according to a destination address (destination address, DA) in an IPv6 header of the outer package of the user multicast message. R6, R7 and R8 are the exit (egress) devices of the segment routing replication domain, and are responsible for decapsulating the encapsulated user multicast message and forwarding the user multicast message of the inner layer.
The type of the user multicast message is not particularly limited in the embodiment of the present application, and may be an internet protocol fourth version (internet protocol version, ipv 4) multicast message, or may also be an internet protocol sixth version (internet protocol version, ipv 6) multicast message, or may also be an ethernet (etherent) message.
The above R1 is used as an ingress (ingress) device of a segment routing replication domain, and the format of the encapsulated IPv6 message is that an outer layer IPv6 header+a user multicast message (IPv 4 multicast message or IPv6 multicast message or etherent message). In the embodiment of the application, the specific implementation modes for partitioning the types of the user multicast messages behind the outer layer IPv6 header are various. Several possible implementations are described in detail below.
In one possible implementation, different user multicast message types may be identified by the value of the Next Header (NH) field of the outer IPv6 header. For example, a value of 4 in the next header field may indicate that the user multicast message behind the outer layer IPv6 header is an IPv4 multicast message. For another example, a value of 41 in the next header field may indicate that the user multicast message behind the outer layer IPv6 header is an IPv6 multicast message. For another example, a value of 143 in the next header field may indicate that the user multicast message behind the outer layer IPv6 header is etherent.
In another possible implementation manner, the type of the user multicast packet may also be determined through a destination address (destination address, DA) field of the inner layer user multicast packet. For example, the address of the DA field is an IPv4 multicast address (specifically, the upper 4 bits of the IPv4 address are 1110, i.e., the address range is 224.0.0.0 to 239.255.255.255.255), and it may be determined that the user multicast packet is an IPv4 multicast packet. As another example, the address of the DA field is an IPv6 multicast address (specifically, the first byte of the IPv6 address is 0 xff), and it may be determined that the user multicast packet is an IPv6 multicast packet.
Note that, for etherent messages, the etherent header is also followed by an IPv4 or IPv6 multicast message, so the method described above is also applicable.
Optionally, in some embodiments, multicast forwarding based on IPv6 unicast addresses may also support operation maintenance management (operation administration AND MAINTENANCE, OAM) functions. Therefore, the user multicast message may also be an operation maintenance management (operation administration AND MAINTENANCE, OAM) message.
The multicast forwarding process based on the IPv6 unicast address is based on the mode of changing the IPv6 unicast address in the outer layer IPv6 header hop by hop.
In the scenario shown in fig. 1, there are various specific implementation methods for forwarding a multicast packet by using an IPv6 unicast address as a destination address by a device in the network, which is not specifically limited by the present application. Two possible implementations are described in detail below.
It should be appreciated that in various implementations described below, an IPv6 unicast address is used as the destination address and the destination address is changed during forwarding. For example, the destination address of the message sent by R1 to R3 is a unicast address of R3, the destination addresses of the messages sent by R3 to R5 and R6 are R5 and R6, respectively, and the destination addresses of the messages sent by R5 to R7 and R8 are R7 and R8, respectively.
It should also be understood that in the scenario shown in fig. 1, the IPv6 unicast addresses configured on each device may not be the same, or two or more devices may be configured with the same IPv6 unicast address. An IPv6 Anycast (Anycast) may be constructed where two or more devices configure the same IPv6 unicast address.
For convenience of description, the following description will be given by taking an example in which each device uses a different IPv6 unicast address.
In a possible implementation manner, when a plurality of multicast trees (may also be called P2MP trees) need to be established with R1 as a root node, each device (R1, R3, R5, R6, R7, R8) in the segment routing replication domain shown in fig. 1 needs to reserve a plurality of addresses in a respective IPv6 address space, so as to achieve the purpose of establishing a plurality of multicast trees with R1 as a root node.
1. Take the multicast tree identified by the solid line shown in fig. 1 as an example. The information of the multicast tree indicated by the solid line issued by the controller is shown in table 1 below.
Table 1 information of multicast tree identified by solid line
Wherein, replication ID (replication ID), repID) =1 is a multicast tree with solid line identification. The branch information of a device may be a device downstream of one or more P2 MPs of the device. It should be appreciated that if the device is a leaf device of P2MP, the message is typically decapsulated at the device and the inner layer multicast message is forwarded. Thus, such leaf devices may have no downstream devices, and their corresponding branch information may be represented using decapsulation (decap).
The P2MP forwarding table entries generated by each device in fig. 1 according to the information of the multicast tree identified by the solid line issued by the controller are shown in table 2 below.
Table 2P 2MP forwarding table entry corresponding to the multicast tree identified by solid line
Wherein the destination address (destination address, DA) r1_1 in the table is determined according to the node identification (nodeidentifier, node ID) of R1 and RepID =1, and r1_1 is an IPv6 address when applied to the IPv6 data plane. The other addresses are determined in the same manner as the destination address r1_1, and will not be described here.
Taking R1 as an example, if the destination address in the IPv6 header of the outer layer of the packet is r1_1, the forwarding plane further searches the forwarding table of da=r1_1, searches the table entry of P2MP as described above, and knows that the packet is to be "copied" to r3_1, so that the forwarding plane changes the destination address of the packet into r3_1 and sends the r3 node. The message is then sent to and decapsulated by the leaf nodes along the P2MP tree identified by the real line.
2. Take the multicast tree identified by the dashed line shown in fig. 1 as an example. The information of the P2MP tree identified by the dotted line issued by the controller is shown in table 3 below.
Table 3 information of multicast tree identified by dotted line
Wherein, replication ID (replication ID), repID) =2 is a multicast tree identified by a dotted line.
The forwarding table entries of P2MP generated by each device in fig. 1 according to the information of the multicast tree identified by the dotted line issued by the controller are shown in table 4 below.
Table 4P 2MP forwarding table entries corresponding to multicast tree identified by dashed lines
Taking R1 as an example, if the destination address in the IPv6 header of the outer layer of the packet is r1_2, the forwarding plane further searches the forwarding table of da=r1_2, searches the table entry of P2MP as described above, and knows that the packet is to be "copied" to r3_2, so that the forwarding plane changes the destination address of the packet into r3_2 and sends the r3_2 to the R3 node. The datagram Wen Jiuhui is sent to and decapsulated by each leaf node along the P2MP tree identified by the dashed line.
In another possible implementation manner, when a plurality of multicast trees (may also be referred to as P2MP trees) need to be established with R1 as a root node, only the root node R1 needs to reserve a plurality of addresses corresponding to the plurality of multicast trees, and the rest of devices in the segment routing replication domain shown in fig. 1 need not reserve a plurality of addresses corresponding to the plurality of multicast trees, so that the purpose of establishing a plurality of multicast trees with R1 as the root node may also be achieved.
1. Taking the multicast tree with R1 as the root node in fig. 1 as an example, an address r1_1 of R1 needs to be allocated. And sending the address R1_1 to each node under the multicast tree, and sending the branch information of the multicast tree on each node.
The devices under the multicast tree identified by the solid line with R1 as the root node may include R1, R3, R5, R6, R7, R8. The multicast tree information identified by the solid line received by each node is shown in table 5.
Table 5 information of multicast tree identified by solid line
Taking R1 as an example, "tree=r1_1" indicates that the multicast tree is the multicast tree identified by the solid line shown in fig. 1, and "branch=r3" indicates that the downstream device of R1 is R3.
Taking R5 as an example, the multicast tree is the multicast tree identified by the solid line shown in fig. 1, and the downstream devices of R3 are R7 and R8. For R6, the multicast tree is the multicast tree identified by the solid line shown in fig. 1, and "branch=decap" indicates that R6 is a leaf (leaf) device, which needs to decapsulate the encapsulated multicast packet, and then forward the multicast packet of the inner layer.
The P2MP forwarding table entries established by each device in the network according to the multicast tree information shown in table 5 are shown in table 6.
Table 6 solid line identified P2MP forwarding table entry corresponding to multicast tree
It should be understood that each device in the network is configured with a first address as a destination address of the message, where the first address is used to instruct to find a source address corresponding to the message according to the destination address of the message. When the destination address of the message received by the device is the first address, the device searches the source address of the message.
As an example, the first addresses allocated by R1, R3, R5, R6, R7, R8 are r1_0, r3_0, r5_0, r6_0, r7_0, r8_0, respectively. When the destination address of the message received on R1 is r1_0, R1 will search the source address of the message. When the destination address of the message received on R3 is r3_0, R3 will search the source address of the message. And so on.
Taking R1 as an example, since the multicast tree is a multicast tree identified by a solid line shown in fig. 1, and the downstream device of R1 is R3, the source address denoted by "sa=r1_1" in the P2MP forwarding table entry established by R1 is r1_1, and "branch_ip=r3_0" denotes the first address r3_0 allocated for the IP address of the downstream device of R1 to R3.
R1 obtains the destination address of the IPv6 header of the outer layer of the message as R1_0, and searches the source address SA of the message according to the indication of R1_0. R1 determines that the source address SA of the packet is r1_1, and determines that the branch_ip corresponding to sa=r1_1 is r3_0 according to the P2MP forwarding table entry shown in table 6. Therefore, R1 knows that the message is to be "copied" to r3_0, and the forwarding plane of R1 can modify the destination address of the message to r3_0 and send it to the R3 node. Similarly, the destination address of the message received by R5 is r5_0, and R5 searches the source address SA of the message according to the indication that the destination address is r5_0. R5 determines that the source address SA of the message is r1_1, and determines that the branch_ip corresponding to sa=r1_1 is r7_0/r8_0 according to the P2MP forwarding table entry shown in table 7. Therefore, the R5 knows that the message is to be "copied" to r7_0 and r8_0, and the forwarding plane of R5 can modify the destination address of the message to r7_0 and send it to the R7 node, and modify the destination address of the message to r8_0 and send it to the R8 node. The message is then sent to and decapsulated by the leaf nodes along the P2MP tree identified by the real line.
2. Taking the multicast tree identified by the dashed line with R1 as the root node in fig. 1 as an example, an address r1_2 of R1 needs to be allocated. And sending the address R1-2 to each node under the multicast tree, and sending the branch information of the multicast tree on each node.
The devices under the multicast tree identified by the dashed line with R1 as the root node may include R1, R3, R5, R6, R7, R8. The multicast tree information identified by the dashed lines received by each node is shown in table 7.
Table 7 information of multicast tree identified by dotted line
Taking R1 as an example, "tree=r1_2" indicates that the multicast tree is a multicast tree identified by a dotted line shown in fig. 1, and "branch=r3" indicates that a device downstream of R1 is R3.
The P2MP forwarding table entries established by each device in the network according to the multicast tree information shown in table 7 are shown in table 8.
Table 8P 2MP forwarding table entries corresponding to multicast tree identified by dashed lines
Taking R1 as an example, since the multicast tree is a multicast tree identified by a dashed line shown in fig. 1, and the downstream device of R1 is R3, the source address denoted by "sa=r1_2" in the P2MP forwarding table entry established by R1 is r1_2, and "branch_ip=r3_0" denotes the first address r3_0 allocated for the IP address of the downstream device of R1 to R3.
R1 obtains the destination address of the IPv6 header of the outer layer of the message as R1_0, and searches the source address SA of the message according to the indication of R1_0. R1 determines that the source address SA of the packet is r1_2, and determines that the branch_ip corresponding to sa=r1_2 is r3_0 according to the P2MP forwarding table entry shown in table 8. Therefore, R1 knows that the message is to be "copied" to r3_0, and the forwarding plane of R1 can modify the destination address of the message to r3_0 and send it to the R3 node. Similarly, the destination address of the message received by R5 is r5_0, and R5 searches the source address SA of the message according to the indication that the destination address is r5_0. R5 determines that the source address SA of the packet is r1_2, and determines that the branch_ip corresponding to sa=r1_2 is r7_0 according to the P2MP forwarding table entry shown in table 8. Therefore, R5 knows that the message is to be "copied" to r7_0, and the forwarding plane of R5 can modify the destination address of the message to r7_0 and send it to the R7 node. The datagram Wen Jiuhui is sent to and decapsulated by each leaf node along the P2MP tree identified by the dashed line.
The forwarding security problem exists in the method for forwarding the multicast message based on the IPv6 unicast address as the destination address. As an example, the scenario shown in fig. 1 also includes a device that does not perform "multicast forwarding based on IPv6 unicast address" as described above.
It should be understood that a device that does not perform "multicast forwarding based on an IPv6 unicast address" as described above may be a network device that performs unicast forwarding according to a destination address of a received IPv6 message, which is different from an address of the device.
For example, there is also one R35 between R3 and R5 in fig. 1, and one R36 between R3 and R6, where R35 and R36 are both routers of IPv6 and do not perform "multicast forwarding based on IPv6 unicast address" as described above. For such devices that do not perform "multicast forwarding based on IPv6 unicast addresses," the destination address of the IPv6 message is not the address of the device. When the Hop Limit (HL) field value in the outer layer IPv6 header of the packet received by R3 is 2, and the packet is copied and sent to R5 and R6 by R3 according to the protocol, the hop limit field value in the packet received by R35 and R36 actually needs to be 1 respectively, and the packet received by R35 and R36 will send the error packet of the internet control information protocol version 6 (internet control managemet protocol version, icmpv 6) to R1 according to the processing specification of the IPv6 normal unicast packet (while the packet is not perceived to be an IPv6 unicast packet for multicast forwarding), so that the processing pressure of R1 is high.
In particular, in a network that performs multicast forwarding based on an IPv6 unicast address, in a scenario where the source address of IPv6 in the multicast forwarding process remains unchanged and the destination address is a unicast address, if a packet is a forged packet, for example, a packet with a hop limit field value of 2 and a source address forged to an IPv6 address of R1 is sent to R3 from R1, R35 and R36 may be caused to simultaneously send ICMPv6 error packets to R1, and multiple ICMPv6 error packets are caused by one forged packet, so that a denial of service (denial of service, doS) attack on R1 is caused.
For the above-mentioned R35 and R36 that do not perform "multicast forwarding based on IPv6 unicast address", R35 and R36 are devices that do not support multicast forwarding based on unicast address as described above, and therefore pass through (or refer to as skip) such devices when generating the corresponding forwarding table. In another possible scenario, R35 and R36 are devices that support multicast forwarding based on unicast addresses as described above, but traverse (or "skip") such devices to enhance their forwarding performance when generating the corresponding forwarding tables, as the present application is not specifically limited in this regard.
Therefore, in the scenario of multicast forwarding based on the IPv6 unicast address, how to avoid generating a large number of ICMPv6 error messages and improve the security of message forwarding is a current urgent problem to be solved.
In view of this, the embodiment of the present application provides a method for sending an IPv6 packet, where a threshold greater than or equal to 2 may be set on a device that performs multicast forwarding based on an IPv6 unicast address. The device supporting multicast forwarding based on the IPv6 unicast address checks the value of the hop limit field of the message before forwarding the IPv6 message, if the hop limit of the message is less than or equal to the hop limit threshold on the device, and the inner layer user message is a multicast message (including but not limited to an IPv4 multicast message or an IPv6 multicast message or etherent message), the IPv6 message is prevented from being forwarded, and if the hop limit of the message is less than or equal to the threshold, and the inner layer user message is not a multicast message (for example, an OAM message), the message with the forwarding rate exceeding the limiting rate is prevented.
Therefore, on one hand, the probability that the IPv6 message is sent to the device for unicast forwarding based on the IPv6 unicast address can be reduced, so that the probability that the ICMPv6 error message is generated on the device is reduced, the safety of IPv6 message forwarding is improved, and the waste of network bandwidth and the waste of bandwidth of the attacked device caused by a large number of ICMPv6 error messages are avoided. On the other hand, the method can also consider that the safety is improved on the premise of supporting the OAM, or the safety of data transmission is improved, and meanwhile, the function of OAM detection is not influenced.
It should be understood that avoiding forwarding the IPv6 packet in the present application may be considered as preventing the IPv6 packet from being sent to a next hop device, or may be considered as skipping forwarding the IPv6 packet. That is, avoiding forwarding the IPv6 message may be understood as not sending the IPv6 message to the next hop device.
It should be noted that the threshold value of hop limit may be configured on one or more or even all devices in the network, and as an example, the network administrator may configure the threshold value of hop limit on one or more or even all devices, respectively. These thresholds may be the same or different, and embodiments of the present application are not particularly limited in this regard.
A method for sending an IPv6 message according to an embodiment of the present application is described in detail below with reference to fig. 2.
Fig. 2 is a schematic flow chart of a method for sending an IPv6 message according to an embodiment of the present application. As shown in FIG. 2, the method may include steps 210-230, and steps 210-230 are described in detail below, respectively.
Step 210, the first network device receives a first IPv6 message, where the first IPv6 message includes a header and an inner layer message, and the header includes a hop limit field.
The first IPv6 message may be a general IPv6 message, or may also be an explicit copy (bit indexed explicit replication internet protocol version, bierv 6) message based on a bit index of the sixth version of the internet protocol, which is not specifically limited in the embodiment of the present application.
Step 220, the first network device determines whether the value of the hop limit field in the first IPv6 message is less than or equal to a preset threshold on the first network device, where the preset threshold is a number greater than or equal to 2.
The preset threshold configured on the first network device is a number greater than or equal to 2, the preset threshold may be a threshold determined according to the number of one or more continuous second network devices connected to the first network device, the second network device is a network device that performs unicast forwarding based on a destination address of an IPv6 message received from the first network device, and the destination address of the IPv6 message received from the first network device is different from the address of the second network device.
As an example, a hop limit threshold may be configured on the first network device, where the threshold value is not less than the number of consecutive second network devices plus 1. Specific implementation methods for determining the preset threshold configured on the first network device are described in detail below.
Taking the scenario shown in fig. 1 as an example, R35 is a device that does not perform "multicast forwarding based on IPv6 unicast address" as described above. R3 and R5 are both connected to R35, and the number of R35 connected to R3 and R5 is 1, so that the preset threshold number on R3 and R5 can be set to a number not less than 2.
In step 230, the first network device determines whether the inner layer packet is a multicast packet.
The multicast message in the embodiment of the application comprises any one of IPv6 multicast message, fourth edition internet protocol IPv4 multicast message and Ethernet message. For specific implementation ways of determining the type of the inner layer packet, please refer to the description above, and the description is omitted here.
Step 240, when the value of the hop limit field in the first IPv6 message is less than or equal to a preset threshold, and the inner layer message is a multicast message, the first network device avoids forwarding the first IPv6 message.
It should be understood that avoiding forwarding the IPv6 packet in the present application may be considered as preventing the IPv6 packet from being sent to a next hop device, or may be considered as skipping forwarding the IPv6 packet. That is, avoiding forwarding the IPv6 message may be understood as not sending the IPv6 message to the next hop device.
In the above technical solution, a threshold value greater than or equal to 2 may be configured on the first network device (a device supporting multicast forwarding based on a unicast destination address of an IPv6 packet), where the first network device prevents forwarding the IPv6 packet when a hop limit of a check packet before forwarding the IPv6 packet is less than or equal to the threshold value. Therefore, the probability of generating ICMPv6 error messages on the IPv6 hop limit value is 1 or 0 can be reduced, so that the safety of IPv6 message forwarding can be improved, and the waste of network bandwidth and the waste of bandwidth of attacked equipment caused by a plurality of even a large number of ICMPv6 error messages are avoided.
Optionally, in some embodiments, after the first network device avoids forwarding the IPv6 packet, the first network device may further discard the IPv6 packet.
Optionally, in some embodiments, the first network device determines that a value of a hop limit field in the IPv6 packet is greater than a threshold, and the inner layer packet is a multicast packet, and the first network device may forward the IPv6 packet.
In one example, if the first network device is an intermediate forwarding device, the first network device sends the IPv6 packet to a second network device, and the second network device forwards the second IPv6 packet to a third network device, where a destination address of the second IPv6 packet is an address of the third network device. Or alternatively
For another example, if the first network device is an egress device, the first network device decapsulates the IPv6 message and forwards the inner layer message obtained after decapsulating the IPv6 message.
Optionally, in some embodiments, the safety of forwarding the IPv6 message may be further improved under the premise of considering how to support the OAM, so as to avoid the waste of network bandwidth and the waste of bandwidth of the attacked device caused by a plurality of or even a large number of ICMPv6 error messages, or to improve the safety of IPv6 message transmission and ensure that the OAM detection function is not affected. In this implementation, one possible IPv6 message format for R1 encapsulation is an outer IPv6 header+OAM message. The OAM packet may be an IP encapsulated OAM packet, which includes an inner layer IPv6 header, a UDP header, and an OAM header. The inner layer IPv6 header, the UDP header and the OAM header together form the Echo Request message in the embodiment of the application.
That is, in this embodiment, the Echo Request message body includes an IPv6 header, a UDP header, and an OAM header, and the Echo Request message is encapsulated in the outer layer IPv6 header, so that the Echo Request message is forwarded from point to multipoint (P2 MP) according to the outer layer IPv6 header.
It should be understood that the destination address of the inner layer IPv6 header is a valid IPv6 address that can be identified by the network device. Specifically, the valid IPv6 address that can be identified may be any one within the range of 0:0:0:0:0:ffff:7f00:0/104.
In one possible implementation manner, when the inner layer packet of the IPv6 packet is an OAM packet, if the transmission rate of the IPv6 packet is greater than a preset rate, the first network device refrains from forwarding the IPv6 packet. Optionally, the first network device may also discard the IPv6 packet.
In another possible implementation manner, when the inner layer multicast message of the IPv6 message is an OAM message, if the transmission rate of the IPv6 message is less than or equal to a preset rate, the first network device forwards the IPv6 message. It should be appreciated that the rate of message transmission may be the number of messages transmitted per second (PACKET PER seconds, pps), or may also be the number of bits per second (bps) transmitted.
In the following, taking a threshold (threshold) of configuring a hop limit on R3 in fig. 1 as an example, a specific implementation procedure of the method for sending an IPv6 message according to an embodiment of the present application is described in detail with reference to fig. 3.
It should be appreciated that the example of fig. 3 is merely to aid one skilled in the art in understanding embodiments of the present application, and is not intended to limit application embodiments to the specific values or particular scenarios illustrated. Various equivalent modifications and variations will be apparent to those skilled in the art from the example of fig. 3 given below, and such modifications and variations are intended to be within the scope of embodiments of the present application.
Fig. 3 is a schematic flow chart of another method for sending an IPv6 message according to an embodiment of the present application. As shown in FIG. 3, the method may include steps 310-375, with steps 310-375 being described in detail below, respectively.
It should be understood that in fig. 3, the threshold value of hop limit configured on R3 is illustrated as 3.
One possible scenario is listed below.
In step 310, R3 receives an encapsulated IPv6 packet, where in an outer layer IPv6 header of the encapsulated IPv6 packet, a Source Address (SA) =r1, da=r3, hop limit=3, and a user multicast packet behind the outer layer IPv6 header is an IPv4 multicast packet.
Step 315, R3 avoids forwarding the IPv6 message in step 310.
R3 determines that hop limit in the outer layer IPv6 header is equal to the threshold value, and the user multicast message is an IPv4 multicast message, so that R3 can avoid forwarding the encapsulated IPv6 message. Please refer to the description above for specific ways of determining the user multicast message, and details are not repeated here.
It should be understood that, in the present application, avoiding forwarding the encapsulated IPv6 packet may be considered as preventing the encapsulated IPv6 packet from being sent to a next hop device, or may be considered as skipping forwarding of the encapsulated IPv6 packet. That is, avoiding forwarding the encapsulated IPv6 message may be understood as not sending the encapsulated IPv6 message to the next hop device.
Optionally, in some embodiments, R3 may discard the above-mentioned encapsulated IPv6 packet.
Another possible scenario is listed below.
In step 320, R3 receives the encapsulated IPv6 message, where in the outer layer IPv6 header of the encapsulated IPv6 message, sa=r1, da=r3, hop limit=3, and the user multicast message behind the outer layer IPv6 header is the IPv6 message.
Step 325, R3 avoids forwarding the IPv6 message in steps 320.
R3 determines that hop limit in the outer layer IPv6 header is equal to the threshold value, and the user multicast message is an IPv6 multicast message, so that R3 can avoid forwarding the encapsulated IPv6 message. Please refer to the description above for specific ways of determining the user multicast message, and details are not repeated here.
Optionally, in some embodiments, R3 may discard the above-mentioned encapsulated IPv6 packet.
Another possible scenario is listed below.
In step 330, R3 receives the encapsulated IPv6 message, where in the outer layer IPv6 header of the encapsulated IPv6 message, sa=r1, da=r3, hop limit=3, and the user multicast message behind the outer layer IPv6 header is etherent message.
Step 335, R3 avoids forwarding the IPv6 message in steps 330.
R3 determines that hop limit in the outer layer IPv6 header is equal to the threshold value, and the user multicast message is etherent messages, so that R3 can avoid forwarding the encapsulated IPv6 messages. Please refer to the description above for specific ways of determining the user multicast message, and details are not repeated here.
Optionally, in some embodiments, R3 may discard the above-mentioned encapsulated IPv6 packet.
Another possible scenario is listed below.
In step 340, R3 receives the encapsulated IPv6 message, where in the outer layer IPv6 header of the encapsulated IPv6 message, sa=r1, da=r3, hop limit=3, and the user multicast message behind the outer layer IPv6 header is an OAM message.
Step 345R 3 forwards the IPv6 message to R6 with the transmission rate not exceeding the rate limit in step 340.
R3 determines that the hop limit in the outer layer IPv6 header is equal to the threshold value, and determines that the user multicast message is the user multicast message as the OAM message, so that the message limits the speed, the message exceeding the speed limit is prevented from being forwarded, and the message not exceeding the speed limit is forwarded.
Specifically, in one possible implementation manner, R3 may determine that the user multicast packet is an OAM packet by excluding that the user multicast packet is not an IPv4 multicast packet, an IPv6 multicast packet, or etherent packet. R3 can exclude the possibility that the user multicast message is an IPv4 multicast message or an Ethernet message according to the Next Header value of 41 of the outer layer IPv6 Header, because the Next Header value of 4 or 143 corresponds to the R3, respectively, can further check that the 8 bits before the destination address of the inner layer user multicast message is not equal to 0xff, or that the 8 bits before the destination address is equal to 0, or that the 104 bits before the destination address is 0:0:0:0:0:FFFF:7F00 (i.e. the destination address is an address in a address field of 0:0:0:0:FFFF:7F00:0/104), thereby judging that the inner layer user multicast message is not an IPv6 message.
For the user multicast message, the OAM message, if the transmission rate of the message does not exceed the rate limit, R3 will be forwarded to R5 along the P2MP path. In the outer IPv6 header of the message sent to R5, sa=r1, da=r6, hop limit=2.
Step 350, R6 decapsulates the encapsulated IPv6 message received from step 350, and sends a response message to SA (sa=r1).
R6 is used as an egress node, after the IPv6 message is unpacked, the multicast message of the inner layer user is determined to be an OAM message, and R6 sends a response message to SA (SA=R1) in the IPv6 header of the outer layer.
As an example, the response message is an OAM message of Echo Reply.
Step 355, R3 forwards the IPv6 message with the transmission rate not exceeding the rate limit in step 340 to R5.
For the user multicast message, the OAM message, if the transmission rate of the message does not exceed the rate limit, R3 will be forwarded to R6 along the P2MP path. In the outer IPv6 header of the message sent to R6, sa=r1, da=r5, hop limit=2.
In step 360, R5 forwards the hop limit received in step 355 to R7 with the hop limit of 2 and the user multicast message of OAM.
Assuming that there is no Threshold of hop limit configured on R5, for a received hop limit of 2, the user multicast message is an OAM message, which is forwarded to R7. In the outer IPv6 header of the message sent to R7, sa=r1, da=r7, hop limit=1.
Step 365, R7 decapsulates the encapsulated IPv6 message received from step 360 and sends a response message to the SA (sa=r1).
And R7 is used as an egress node, after the IPv6 message is unpacked, the multicast message of the inner layer user is determined to be an OAM message, and R7 sends a response message to SA (SA=R1) in the IPv6 header of the outer layer.
In step 370, R5 forwards the hop limit received in step 355 to R8 with the hop limit of 2 and the user multicast message of OAM.
Assuming that there is no Threshold of hop limit configured on R5, for a received hop limit of 2, the user multicast message is an OAM message, which is forwarded to R8. In the outer layer IPv6 header of the message sent to R8, sa=r1, da=r8, hop limit=1.
In step 475, R8 decapsulates the encapsulated IPv6 message received in step 370, and sends a response message to the SA (sa=r1).
And R8 is used as an egress node, after the IPv6 message is unpacked, the multicast message of the inner layer user is determined to be an OAM message, and R8 sends a response message to SA (SA=R1) in the IPv6 header of the outer layer.
In the above technical solution, for a scenario of forwarding a multicast data packet based on an IPv6 unicast address, a threshold value of hop limit greater than or equal to 2 may be set on a certain device. When the message is forwarded, the message is a multicast data message, and the message hop limit value is smaller than or equal to the threshold value, so that the forwarding is avoided, and ICMPv6 error messages can be prevented from being generated when the multicast data message is sent to part of intermediate nodes, thereby reducing the possibility of network attack. And the normal multicast data message forwarding is not affected as long as the hop limit is not smaller than the set threshold value. Meanwhile, the application also considers the function support of OAM such as Ping or Traceroute, as Ping/Traceroute usually does not need high speed, and for the received message hop limit less than or equal to the threshold value but greater than 1, judging that the message is not a multicast data message, the speed-limiting forwarding is performed, so that Ping/Traceroute function can be normally performed. And meanwhile, the message exceeding the rate limit value is prevented from being forwarded, so that an attacker is prevented from generating attacks by forging Ping/Traceroute messages or other non-multicast data messages.
In some embodiments, there are two modes of transfer of hop limit, a form mode and a Pipe mode, respectively. Details are described below in connection with fig. 4 and 6, respectively.
In the following, taking a threshold (threshold) of configuring a hop limit on R1 in fig. 1, a hop limit transfer mode of R1 is a form mode as an example, and a specific implementation process of multicast forwarding based on an IPv6 unicast address by a device in an embodiment of the present application is described in detail with reference to fig. 4.
It should be appreciated that the example of fig. 4 is merely to aid one skilled in the art in understanding embodiments of the present application, and is not intended to limit application embodiments to the specific values or particular scenarios illustrated. Various equivalent modifications and variations will be apparent to those skilled in the art from the example of fig. 4 given below, and such modifications and variations are intended to be within the scope of embodiments of the present application.
Fig. 4 is a schematic flow chart of another method for sending an IPv6 message according to an embodiment of the present application. As shown in FIG. 4, the method may include steps 410-450, with steps 410-450 being described in detail below, respectively.
It should be understood that in fig. 4, the threshold of hop limit configured on R1 is 5, and the hop limit transfer mode of R1 is illustrated as the form mode.
For convenience of description, fig. 4 is an example of an IPv4 multicast data packet. For the IPv6 multicast data message, the same processing mode is adopted, and the HL field of the IPv6 multicast data message corresponds to the TTL of the IPv4 multicast data message.
One possible scenario is listed below.
In step 410, R1 receives an IPv4 multicast data message sent by customer edge device 1 (CE 1), and the Time To Live (TTL) of the message is 5.
Step 415: r1 avoids encapsulating the IPv4 multicast data message in step 410.
TTL in the IPv4 multicast data message corresponds to hop limit in the IPv6 multicast data message, the threshold value of hop limit configured on R1 is 5, and TTL of the IPv4 multicast data message received by R1 is 5 (TTL is equal to the threshold value of hop limit). Therefore, the R1 avoids encapsulating the IPv4 multicast data message and does not multicast and forward the IPv4 multicast data message.
Optionally, in some embodiments, R1 discards the IPv4 multicast data packet.
Another possible scenario is listed below.
In step 420, R1 receives an IPv4 multicast data message sent by CE1, and TTL of the message is 4.
Step 425, R1 avoids encapsulating the IPv4 multicast data message of step 420.
TTL in the IPv4 multicast data message corresponds to hop limit in the IPv6 multicast data message, the threshold value of hop limit configured on R1 is 5, and TTL of the IPv4 multicast data message received by R1 is 4 (TTL is smaller than threshold value of hop limit). Therefore, the R1 avoids encapsulating the IPv4 multicast data message and does not multicast and forward the IPv4 multicast data message.
Optionally, in some embodiments, R1 discards the IPv4 multicast data packet.
Another possible scenario is listed below.
In step 430, r1 receives an IPv4 multicast data packet sent by customer edge device 1 (CE 1), and the Time To Live (TTL) of the packet is 6.
In step 435, R1 encapsulates the IPv4 multicast data message with TTL of 6 in step 430, and sends the encapsulated IPv4 multicast data message to R3.
TTL in the IPv4 multicast data message corresponds to hop limit in the IPv6 multicast data message, the threshold value of hop limit configured on R1 is 5, and TTL is greater than the threshold value of hop limit, so R1 packages the IPv4 multicast data message and sends the packaged data message to R3.
As an example, R1 encapsulates an outer layer IPv6 header for the IPv4 multicast data packet, and according to the processing of the form mode, the TTL value of the IPv4 multicast data packet is reduced by one, and the value obtained by subtracting the TTL value by one is used as the value of the hop limit field of the outer layer IPv6 header. Therefore, in the outer layer IPv6 header of the IPv6 message sent by R1 to R3, SA=R1, DA=R3, hop limit=5, and TTL=5 of the inner layer IPv4 multicast data message.
And step 440, R3 sends the encapsulated IPv6 message to R5.
In the outer layer IPv6 header of the IPv6 message sent by R3 to R5, SA=R1, DA=R5, hop limit=4, and TTL=5 of the inner layer IPv4 multicast data message.
Step 445, R5 sends the IPv6 message to R7.
In the outer layer IPv6 header of the IPv6 message sent by R5 to R7, SA=R1, DA=R7, hop limit=3, and TTL=5 of the inner layer IPv4 multicast data message.
Step 450, R7 sends the inner layer IPv4 multicast data message to CE2.
In the outer layer IPv6 header of the IPv6 message received by the R7, SA=R1, DA=R7, hop limit=3, TTL=5 of the inner layer IPv4 multicast data message, and assuming that the hop limit transmission mode of the R7 is a form mode, the R7 subtracts the value of HL and assigns the value to the TTL of the inner layer IPv4 multicast data message. Therefore, the TTL value of the IPv4 multicast data packet sent by R7 to CE2 is 2.
In the following, a specific implementation process of multicast forwarding based on an IPv6 unicast address by a device in an embodiment of the present application will be described in detail with reference to fig. 5 by taking a case that a threshold (threshold) of a hop limit is configured on each of a plurality of devices in fig. 1, and a hop limit transfer mode of R1 is a form mode as an example.
It should be appreciated that the example of fig. 5 is merely to aid one skilled in the art in understanding embodiments of the present application, and is not intended to limit application embodiments to the specific values or particular scenarios illustrated. Various equivalent modifications and variations will be apparent to those skilled in the art from the example of fig. 5 given below, and such modifications and variations are intended to be within the scope of embodiments of the present application.
Fig. 5 is a schematic flow chart of another method for sending an IPv6 message according to an embodiment of the present application. As shown in FIG. 5, the method may include steps 510-565, and steps 510-565 are described in detail below, respectively.
It should be understood that, in fig. 5, the threshold value of hop limit set on R1 is 5, the hop limit transmission mode of R1 is the form mode, and the threshold values of hop limit are set for other devices R3/R5/R7/R8, respectively, for illustration.
The threshold value of hop limit set on each device R3/R5/R7/R8 may be the same or may be different. For ease of description, fig. 5 illustrates that the threshold value of hop limit set on R3/R5/R7/R8 is 3.
One possible scenario is listed below, where R1 initiates the first round of probing, constructs an OAM message for an Echo Request using hl=1.
In step 510, R1 sends an encapsulated IPv6 message to R3, wherein the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message constructed by R1, SA=R1, DA=R3, hop limit=1. Although hop limit=1 is smaller than the threshold value (threshold value=5) of hop limit configured on R1, R1 performs rate-limiting forwarding because the inner layer user multicast packet is an OAM packet. When within the limit, the message is allowed to be forwarded to R3.
In step 615, R3 feeds back a response message to R1.
In the outer layer IPv6 header of the IPv6 message received by R3 from R1, SA=R1, DA=R3, hop limit=1, and the inner layer user multicast message is an OAM message. Since hop limit=1 and the inner layer user multicast message is an OAM message, R3 sends a response message to SA (sa=r1) in the outer layer IPv6 header without forwarding to R5 and R6. The first round of detection ends.
As an example, the response message is an OAM message of Echo Reply.
Another possible scenario is listed below, where R1 initiates a second round of probing, constructing an OAM message for an Echo Request using hl=2.
In step 520, R1 sends the encapsulated IPv6 message to R3, wherein the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message sent by R1 to R3, SA=R1, DA=R3, hop limit=2, and the inner layer user multicast message is an OAM message.
In step 525, R3 sends the encapsulated IPv6 message to R5, wherein the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message sent by R3 to R5, SA=R1, DA=R5, hop limit=2, and the inner layer user multicast message is an OAM message. Although hop limit=1 is smaller than the threshold value of hop limit configured on R3 (threshold value=3), R3 performs rate-limiting forwarding because the inner layer user multicast packet is an OAM packet. When within the limit, the message is allowed to be forwarded to R5.
In step 530, R5 feeds back a response message to R1.
The hop limit=1 in the outer layer IPv6 header of the IPv6 packet received by R5 from R3, and the inner layer user multicast packet is an OAM packet, although the threshold of hop limit configured on R3 is 3, because the OAM packet is not directly discarded by R5. Also, because hop limit=1 in the outer layer IPv6 header, R5 sends a response message to SA (sa=r1) in the outer layer IPv6 header, and does not forward to R7 and R8. The second round of detection ends.
In step 533, R3 sends an encapsulated IPv6 message to R6, wherein the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message sent by R3 to R6, SA=R1, DA=R6, hop limit=2, and the inner layer user multicast message is an OAM message. Although hop limit=1 is smaller than the threshold value of hop limit configured on R3 (threshold value=3), R3 performs rate-limiting forwarding because the inner layer user multicast packet is an OAM packet. When within the limit, the message is allowed to be forwarded to R6.
Step 535, R6 feeds back a response message to R1.
Since R6 is an egress node, the hop limit=1 received by R6, so R6 sends a response message to the SA (sa=r1) in the outer layer IPv6 header. The second round of detection ends.
Another possible scenario is listed below, where R1 initiates a second round of probing, constructing an OAM message for an Echo Request using hl=3.
Step 540, R1 sends the encapsulated IPv6 message to R3, wherein the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message sent by R1 to R3, SA=R1, DA=R3, hop limit=3, and the inner layer user multicast message is an OAM message.
In step 545, R3 sends the encapsulated IPv6 message to R6, wherein the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message sent by R3 to R6, SA=R1, DA=R6, hop limit=2, and the inner layer user multicast message is an OAM message.
In step 548, R6 feeds back a response message to R1.
The hop limit=2 in the outer layer IPv6 header of the IPv6 packet received by R6 from R3, and the inner layer user multicast packet is an OAM packet, although the threshold of hop limit configured on R6 is 3, the OAM packet R6 will not directly discard the packet. Also because R6 is an egress node, R6 sends a response message to the SA (sa=r1) in the outer layer IPv6 header. The third round of detection ends.
In step 550, in the outer layer IPv6 header of the IPv6 packet sent from R3 to R5, sa=r1, da=r5, hop limit=2, and the inner layer user multicast packet is an OAM packet.
In step 555, R5 sends the encapsulated IPv6 message to R8, and the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message sent by R5 to R8, SA=R1, DA=R8, hop limit=1, and the inner layer user multicast message is an OAM message.
In step 558, R8 feeds back a response message to R1.
Because R8 is an egress node, R8 sends a response message to the SA (sa=r1) in the outer layer IPv6 header. The third round of detection ends. Please refer to step 660, which is not described herein.
In step 560, R5 sends the encapsulated IPv6 message to R7, and the inner layer of the IPv6 message is an OAM message.
In the outer layer IPv6 header of the IPv6 message sent by R5 to R7, SA=R1, DA=R7, hop limit=1, and the inner layer user multicast message is an OAM message.
Step 565, R7 feeds back a response message to R1.
The hop limit=1 in the outer layer IPv6 header of the IPv6 packet received by R7 from R5 and the inner layer user multicast packet is an OAM packet, although the threshold of hop limit configured on R7 is 3, because the OAM packet R7 does not directly discard the packet. Also, because hop limit=1 in the outer layer IPv6 header, R7 sends a response message 7 to SA (sa=r1) in the outer layer IPv6 header. The third round of detection ends.
In the following, taking a case that a threshold (threshold) of hop limit is set on R1 in fig. 1, a hop limit transfer mode of R1 is a Pipe mode as an example, and a specific implementation process of multicast forwarding based on an IPv6 unicast address by a device in an embodiment of the present application is described in detail with reference to fig. 6.
It should be appreciated that the example of fig. 6 is merely to aid one skilled in the art in understanding embodiments of the present application, and is not intended to limit application embodiments to the specific values or particular scenarios illustrated. Various equivalent modifications and variations will be apparent to those skilled in the art from the example of fig. 6 given below, and such modifications and variations are intended to be within the scope of embodiments of the present application.
Fig. 6 is a schematic flow chart of another method for sending an IPv6 message according to an embodiment of the present application. As shown in FIG. 6, the method may include steps 610-685, and steps 610-685 are described in detail below, respectively.
It should be understood that in fig. 6, the threshold value of hop limit set on R1 is illustrated as 5.
For convenience of description, fig. 6 is an example of an IPv4 multicast data packet. For the IPv6 multicast data message, the same processing is performed, and the HL field of the IPv6 multicast data message corresponds to the TTL of the IPv4 multicast data message.
One possible scenario is listed below.
In step 610, R1 receives an IPv4 multicast data message sent by CE1, and the Time To Live (TTL) of the message is 6.
In step 615, R1 encapsulates the IPv4 multicast data message in step 610 and forwards the encapsulated IPv4 multicast data message to R3.
TTL in the IPv4 multicast data message corresponds to hop limit in the IPv6 multicast data message, the threshold value of hop limit configured on R1 is 5, and TTL of the IPv4 multicast data message received by R1 is 6 (TTL is greater than threshold value of hop limit), so R1 can package the IPv4 multicast data message and forward to R3.
Specifically, when forwarding, R1 encapsulates an outer layer IPv6 header into an IPv4 multicast data packet according to the processing of the Pipe, and the hop limit of the outer layer IPv6 header is set to 255. Therefore, in the outer layer IPv6 header of the IPv6 packet that R1 sends to R3, sa=r1, da=r3, hop limit=255, and ttl=5 of the inner layer IPv4 multicast data packet.
R3 forwards the message received from R1 to R5, step 620.
In the outer layer IPv6 header of the IPv6 packet sent by R3 to R5, sa=r1, da=r5, hop limit=254, and ttl=5 of the inner layer IPv4 multicast data packet.
Step 625, R5 forwards the message received from R3 to R7.
In the outer layer IPv6 header of the IPv6 packet sent by R5 to R7, sa=r1, da=r7, hop limit=253, and ttl=5 of the inner layer IPv4 multicast data packet.
Step 630, R7 sends the inner layer IPv4 multicast data message to CE2.
In the outer layer IPv6 header of the IPv6 message received by the R7, SA=R1, DA=R7, hop limit=253, TTL=5 of the inner layer IPv4 multicast data message, and assuming that the hop limit transmission mode of the R7 is the Pipe mode, the R7 can strip the outer layer IPv6 header and reduce the TTL field of the inner layer IPv4 multicast data message by one, so that the TTL value of the message sent by the R7 to the CE2 is 4.
Another possible scenario is listed below.
In step 640, R1 receives an IPv4 multicast data message sent by CE1, and the Time To Live (TTL) of the message is 5.
In step 645, R1 encapsulates the IPv4 multicast data packet in step 640 and forwards it to R3.
TTL in the IPv4 multicast data message corresponds to hop limit in the IPv6 multicast data message, the threshold value of hop limit configured on R1 is 5, TTL of the IPv4 multicast data message received by R1 is 5 (TTL is equal to threshold value of hop limit), R1 can package the IPv4 multicast data message according to Pipe processing, and the package is forwarded to R3.
Specifically, when forwarding, R1 encapsulates an outer layer IPv6 header into an IPv4 multicast data packet according to the processing of the Pipe, and the hop limit of the outer layer IPv6 header is set to 255. Therefore, in the outer layer IPv6 header of the IPv6 packet that R1 sends to R3, sa=r1, da=r3, hop limit=255, and ttl=4 of the inner layer IPv4 multicast data packet.
R3 forwards the message received from R1 to R5, step 650.
In the outer layer IPv6 header of the IPv6 packet sent by R3 to R5, sa=r1, da=r5, hop limit=254, and ttl=4 of the inner layer IPv4 multicast data packet.
Step 655R 5 forwards the message received from R3 to R7.
In the outer layer IPv6 header of the IPv6 packet sent by R5 to R7, sa=r1, da=r7, hop limit=253, and ttl=4 of the inner layer IPv4 multicast data packet.
Step 660, R7 sends the inner layer IPv4 multicast data message to CE2.
In the outer layer IPv6 header of the IPv6 message received by the R7, SA=R1, DA=R7, hop limit=253, TTL=4 of the inner layer IPv4 multicast data message, and assuming that the hop limit transmission mode of the R7 is the Pipe mode, the R7 can strip the outer layer IPv6 header and reduce the TTL field of the inner layer IPv4 multicast data message by one, so that the TTL value of the message sent by the R7 to the CE2 is 3.
Another possible scenario is listed below.
In step 665, R1 receives an IPv4 multicast data message sent by CE1, and the Time To Live (TTL) of the message is 4.
In step 670, R1 encapsulates the IPv4 multicast data message in step 665 and forwards the encapsulated IPv4 multicast data message to R3.
TTL in the IPv4 multicast data message corresponds to hop limit in the IPv6 multicast data message, the threshold value of hop limit configured on R1 is 4, TTL of the IPv4 multicast data message received by R1 is 5 (TTL is smaller than threshold value of hop limit), R1 can package the IPv4 multicast data message according to Pipe processing, and the package is forwarded to R3.
Specifically, when forwarding, R1 encapsulates an outer layer IPv6 header into an IPv4 multicast data packet according to the processing of the Pipe, and the hop limit of the outer layer IPv6 header is set to 255. Therefore, in the outer layer IPv6 header of the IPv6 message sent by R1 to R3, SA=R1, DA=R3, hop limit=255, and TTL=3 of the inner layer IPv4 multicast data message.
R3 forwards the message received from R1 to R5, step 675.
In the outer layer IPv6 header of the IPv6 packet sent by R3 to R5, sa=r1, da=r5, hop limit=254, and ttl=3 of the inner layer IPv4 multicast data packet.
R5 forwards the message received from R3 to R7, step 680.
In the outer layer IPv6 header of the IPv6 packet sent by R5 to R7, sa=r1, da=r7, hop limit=253, and ttl=3 of the inner layer IPv4 multicast data packet.
Step 685, R7 sends the inner layer IPv4 multicast data message to CE2.
In the outer layer IPv6 header of the IPv6 message received by the R7, SA=R1, DA=R7, hop limit=253, TTL=3 of the inner layer IPv4 multicast data message, and assuming that the hop limit transmission mode of the R7 is the Pipe mode, the R7 can strip the outer layer IPv6 header and reduce the TTL field of the inner layer IPv4 multicast data message by one, so that the TTL value of the message sent by the R7 to the CE2 is 2.
The above-mentioned fig. 1 to fig. 6 are a detailed description of a method for sending a Pv6 message according to an embodiment of the present application, and the following detailed description of an embodiment of the apparatus according to the present application is a detailed description of fig. 7 to fig. 9. It is to be understood that the description of the method embodiments corresponds to the description of the device embodiments, and that parts not described in detail can therefore be seen in the preceding method embodiments.
Fig. 7 is a schematic block diagram of a first network device 700 according to an embodiment of the present application. The first network device 700 shown in fig. 7 may perform the corresponding steps performed by the first network device in the method of the above-described embodiments. As shown in fig. 7, the first network device 700 includes a receiving module 710, a processing module 720,
A receiving module 710, configured to receive a first IPv6 packet, where the first IPv6 packet includes a header and an inner layer packet, and the header includes a hop limit field;
a processing module 720, configured to determine whether the value of the hop limit field in the first IPv6 packet is less than or equal to a preset threshold on the first network device, where the preset threshold is a number greater than or equal to 2;
the processing module 720 is further configured to determine whether the inner layer packet is a multicast packet;
The processing module 720 is further configured to avoid forwarding the first IPv6 message when the value of the hop limit field in the first IPv6 message is less than or equal to the preset threshold, and the inner layer message is the multicast message.
Optionally, the processing module 720 is further configured to discard the first IPv6 packet.
Optionally, the preset threshold is a threshold determined according to the number of one or more continuous second network devices connected to the first network device, where the second network device is a network device that performs unicast forwarding based on a destination address of an IPv6 packet received from the first network device, and the destination address of the IPv6 packet received from the first network device is different from the address of the second network device.
Optionally, the receiving module 710 is further configured to receive a second IPv6 packet, where the second IPv6 packet includes a header and an inner layer packet, and the header includes a hop limit field;
The processing module 720 is further configured to determine whether the value of the hop limit field in the second IPv6 packet is less than or equal to the preset threshold;
The processing module 720 is further configured to determine whether an inner layer packet of the second IPv6 packet is the multicast packet;
The processing module 720 is further configured to process the second IPv6 message when the value of the hop limit field in the second IPv6 message is greater than the preset threshold, and an inner layer message of the second IPv6 message is the multicast message.
Optionally, the processing module 720 is specifically configured to send the second IPv6 packet to a second network device if the first network device is an intermediate forwarding device, and forward the second IPv6 packet to a third network device by the second network device, where a destination address of the second IPv6 packet is an address of the third network device, or decapsulate the second IPv6 packet and forward the inner layer packet obtained after decapsulating the second IPv6 packet if the first network device is an egress device.
Optionally, the multicast message comprises any one of an IPv6 multicast message, a fourth version of Internet protocol IPv4 multicast message and an Ethernet message.
Optionally, the value of the hop limit field in the first IPv6 message is smaller than or equal to the preset threshold, and the processing module is further configured to, when an inner layer message of the first IPv6 message is an OAM message, avoid forwarding the IPv6 message if the transmission rate of the first IPv6 message is greater than a preset rate.
Optionally, the processing module 720 is further configured to discard the first IPv6 packet.
Optionally, the value of the hop limit field in the first IPv6 message is smaller than or equal to the preset threshold, and the processing module is further configured to, when the inner layer multicast message is an OAM message, forward the first IPv6 message if the transmission rate of the first IPv6 message is smaller than or equal to the preset rate.
Fig. 8 is a schematic hardware structure of the first network device 2000 according to an embodiment of the present application. The first network device 2000 shown in fig. 8 may perform the corresponding steps performed by the first network device in the method of the above embodiment.
As shown in fig. 8, the first network device 2000 includes a processor 2001, a memory 2002, an interface 2003, and a bus 2004. The interface 2003 may be implemented in a wireless or wired manner, and may specifically be a network card. The processor 2001, memory 2002, and interface 2003 are connected by a bus 2004.
The interface 2003 may include a transmitter and a receiver, for the first network device to implement the above-mentioned transceiving. For example, the interface 2003 is used to receive IPv6 messages.
The processor 2001 is configured to perform the processing performed by the first network device in the above embodiment. For example, the method is used for determining whether the value of the hop limit field in the first IPv6 message is less than or equal to a preset threshold on the first network device, determining whether the inner layer message is a multicast message, and when the value of the hop limit field in the first IPv6 message is less than or equal to the preset threshold and the inner layer message is the multicast message, the first network device refrains from forwarding the first IPv6 message, and/or other processes for the techniques described herein. Memory 2002 includes an operating system 20021 and application programs 20022 for storing programs, code or instructions which when executed by a processor or hardware device perform the processes of the method embodiments involving the first network device. Alternatively, the memory 2002 may include read-only memory (ROM) and random access memory (random access memory, RAM). Wherein the ROM comprises a basic input/output system (BIOS) or an embedded system, and the RAM comprises an application program and an operating system. When the first network device 2000 needs to be operated, the first network device 2000 is guided to enter a normal operation state by starting a BIOS cured in a ROM or a bootloader booting system in an embedded system. After the first network device 2000 enters the normal operation state, the application programs and the operating system that run in the RAM, and thus, the processing procedure involving the first network device 2000 in the method embodiment is completed.
It is to be understood that fig. 8 only shows a simplified design of the first network device 2000. In practice, the first network device may comprise any number of interfaces, processors or memories.
Fig. 9 is a schematic diagram of a hardware structure of another first network device 2100 according to an embodiment of the present application. The first network device 2100 shown in fig. 9 may perform the corresponding steps performed by the first network device in the method of the above-described embodiments.
As shown in fig. 9, first network device 2100 includes a main control board 2110, an interface board 2130, a switch board 2120, and an interface board 2140. Main control board 2110, interface boards 2130 and 2140, and switching network board 2120 are connected to the system back board via a system bus to achieve interworking. The main control board 2110 is used for completing functions such as system management, equipment maintenance, protocol processing and the like. Switch board 2120 is used to perform data exchanges between interface boards (also known as line cards or traffic boards). Interface boards 2130 and 2140 are used to provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and to enable forwarding of data packets.
The interface board 2130 may include a central processor 2131, a forwarding table entry memory 2134, a physical interface card 2133, and a network processor 2132. The central processor 2131 is used for controlling and managing the interface board and communicating with the central processor on the main control board. The forwarding table entry memory 2134 is used to store table entries. The physical interface card 2133 is used to complete the reception and transmission of traffic.
It should be understood that the operations on the interface board 2140 in the embodiment of the present application are identical to those of the interface board 2130, and are not repeated for brevity.
It should be understood that the first network device 2100 of this embodiment may correspond to the functions and/or the various steps implemented in the above-described method embodiments, which are not described herein.
In addition, it should be noted that the main control board may have one or more blocks, and the main control board and the standby main control board may be included when there are multiple blocks. The interface boards may have one or more blocks, the more data processing capabilities the first network device is, the more interface boards are provided. The physical interface card on the interface board may also have one or more pieces. The switching network board may not be provided, or may be provided with one or more blocks, and load sharing redundancy backup can be jointly realized when the switching network board is provided with the plurality of blocks. Under the centralized forwarding architecture, the first network device may not need a switch board, and the interface board bears the processing function of the service data of the whole system. Under the distributed forwarding architecture, the first network device may have at least one switching fabric, through which data exchange between multiple interface boards is implemented, and a large capacity of data exchange and processing capability is provided. Therefore, the data access and processing power of the first network device of the distributed architecture is greater than that of the devices of the centralized architecture. The specific architecture employed is not limited in any way herein, depending on the specific networking deployment scenario.
The embodiment of the application also provides a computer readable medium storing a program code which, when run on a computer, causes the computer to perform the method performed by the first network device. Such computer-readable storage includes, but is not limited to, one or more of read-only memory (ROM), programmable ROM (PROM), erasable PROM (erasable PROM, EPROM), flash memory, electrically EPROM (EEPROM), and a hard disk drive (HARD DRIVE).
The embodiment of the application also provides a chip system which is applied to the first network equipment and comprises at least one processor, at least one memory and an interface circuit, wherein the interface circuit is responsible for information interaction between the chip system and the outside, the at least one memory, the interface circuit and the at least one processor are interconnected through lines, instructions are stored in the at least one memory, and the instructions are executed by the at least one processor so as to carry out the operation of the first network equipment in the method of each aspect.
In a specific implementation, the chip may be implemented in the form of a central processing unit (central processing unit, CPU), microcontroller (micro controller unit, MCU), microprocessor (micro processing unit, MPU), digital signal processor (DIGITAL SIGNAL processing, DSP), system on chip (SoC), application-specific integrated circuit (ASIC), field-programmable gate array (field programmable GATE ARRAY, FPGA), or programmable logic device (programmable logic device, PLD).
Embodiments of the present application also provide a computer program product for use in a first network device, the computer program product comprising a series of instructions which, when executed, perform the operations of the first network device in the methods of the above aspects.
It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.
In the several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. The storage medium includes a U disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, an optical disk, or other various media capable of storing program codes.
The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.