Communication equipment and multicast user authentication method

The present invention relates to a communication device and a multicast user authentication method, and more particularly to a communication device and a multicast user authentication method that distributes multicast data in an IP network system only to specific terminals permitted to receive.

Currently, data distribution technology using the multicast relay function is being used in IP network systems. Examples of technologies for controlling this multicast data include IGMP / MLD (Internet Group Management Protocol / Multicast Listener Discovery) and IGMP / MLD snooping technology (see, for example, Non-Patent Documents 1, 2 and 3).

As shown in FIG. 1, terminal 1 (141) and terminal 2 (142) send a reception request by IGMP / MLD addressed to group 1 (G1) to router 120, so that the multicast sender 110 sends the data. Multicast data (D110) can be received by terminal 1 (141) and terminal 2 (142).

In addition, by operating IGMP / MLD snooping on the switch, multicast data (D110) is not transmitted to terminal 3 (143) that has not requested reception by IGMP / MLD. This makes it possible to prevent the divergence of multicast data, for example. If the terminal 3 (143) sends a reception request to the switch 130 or the like in order to receive the multicast data (D110) by IGMP / MLD, the terminal 3 (143) can receive the multicast data. ..

Further, a communication system in which a snooping device is installed between a client device and a routing device is disclosed (see, for example, Patent Document 1). In this system, the snooping device sends the IGMP reception request accompanied by authentication to the routing device as it is, and determines whether the authentication server device matches the database in which the user ID, password, multicast address, etc. are registered, for example. ing.

<patcit num="1"><text>Japanese Unexamined Patent Publication No. 2004-357200</text></patcit><nplcit num="1"><text>RFC2236 Internet Group Management Protocol Version 2</text></nplcit><nplcit num="2"><text>RFC2710 Multicast Listener Discovery (MLD) for IPv6</text></nplcit><nplcit num="3"><text>Internet-Draft IGMP and MLD snooping switches draft-ietf-magma-snoop-10.txt</text></nplcit><nplcit num="4"><text>IGAP (IGMP for Authentication Protocol) draft-andou-igmp-auth-01.txt</text></nplcit><nplcit num="5"><text>MLDA (Multicast Listener Discovery Authentication Protocol) draft-hayashi-mlda-01.txt</text></nplcit>

<p> Multicast relay can easily distribute data to a specific number of users, but can be received regardless of good intentions or bad intentions by the terminal executing a participation request for specific data distribution. For example, in each of the above systems, any terminal that can connect to the system can receive the multicast data (D110) as described above. However, for example, the multicast data of a certain multicast group may be permitted to be distributed only to a specific terminal and may not be distributed to other terminals.</p><p> For example, the following can be considered as a system that realizes a system that delivers multicast only to such a specific terminal. (1) Authenticate access to the system itself Regardless of the data type such as unicast or multicast, the security of the entire system is maintained by providing authentication for access to the system itself. (2) Authentication by Protocol by IGAP / MLDA In a system using multicast, a router and a terminal authenticate using a protocol so that only authorized terminals can receive (see, for example, Non-Patent Documents 4 and 5). (3) Access filter for network devices By setting an access filter based on the destination IP address or MAC address for the physical port on the router or switch, only authorized terminals can receive.</p><p> Multicast data communication can be considered to maintain security by using any of the above means, but each has the following problems. In the system of (1) above, as long as access to the system is permitted, anyone can receive any multicast data simply by making a reception request using IGMP or MLD. In addition, as described in (2) above, the router and the terminal must each support the protocol for authentication by the protocol. That is, for example, when it is applied to an in-house network, the hardware and software of all routers and terminals in the company are replaced, which is too costly. Furthermore, in the access filter described in (3) above, when the multicast data increases, the number of filtering entries increases, which consumes a lot of router and switch resources. In addition, even if the terminal is relocated within the same router or switch, it is necessary to change the settings, which increases the man-hours of the administrator.</p><p> In addition to limiting the terminals to be distributed for each multicast group, there are cases where it is desired to further limit the areas, ports, and VLANs (Virtual LAN, virtual network) in which the terminals receive multicast data.</p><p> For example, in a corporate network, in addition to information that can be seen by everyone (which can be distributed to terminals), information that can be seen by regular employees, information that can be seen by dispatched employees, information that can be seen by seconded employees from other companies, etc. In some cases. In addition, the target may be combined as appropriate, such as information that can be seen by regular employees and dispatched employees. In addition, some information is shown only to regular employees who have a certain position or higher. In addition, in the case of a merger of companies, reorganization of business divisions, etc., it may be desired to distribute to only one employee before the merger, for example. Further, even if the same multicast group and the same terminal are used, there is a need to limit the distribution in a public place such as a hall and allow the distribution in a conference room or the like.</p><p> In view of the above points, an object of the present invention is to provide a communication device and a multicast user authentication method for performing authentication for multicast communication with a switch (communication device). Another object of the present invention is to minimize changes in the system and keep the introduction cost low. For example, one of the objects of the present invention is to make only a switch a change from an existing system. One of the objects of the present invention is to improve security in performing multicast data communication and to provide a switch capable of multicast distribution of important data.</p><p> An object of the present invention is to limit the terminals and VLANs to be distributed for each multicast group. Furthermore, the present invention restricts distribution when the terminal is in a certain location or belongs to a certain VLAN, and when the terminal is in another location or belongs to another VLAN, even if the same multicast group and the same terminal belong to the same VLAN. One of the purposes is to provide a switch and an authentication method capable of permitting distribution.</p>

<p> In FIG. 2, switch 30 snoops (snooping, monitoring, peeping) a membership report (multicast data reception request or distribution request) (D20) by IGMP / MLD from terminal 1 (41), and its source MAC address ( Authenticate with the source MAC address). The switch 30 relays the membership report (D20) to the router 20 after confirming that it is the source MAC address of the terminal 1 (41) permitted by the setting in advance. Upon receiving the membership report (D20), the router 20 considers it as a multicast data reception request transmitted from the multicast sender 10 and transmits the multicast data (D10) to the switch 30. Upon receiving the multicast data (D10), the switch 30 refers to the MAC address forwarding table and transmits the multicast data (D10) to the receiver terminal 41 connected to the port 1.</p><p> In the present invention, for example, the multicast authentication function is realized by linking the IGMP / MLD snooping function and the authentication function. According to the first solution of the present invention, the second port has a first port for receiving multicast data and a plurality of second ports for transmitting the multicast data to a terminal. It is possible to receive the multicast data of a specific virtual network in advance corresponding to a plurality of ports for configuring a plurality of virtual networks including one or more of the above and a group identifier that identifies a group of multicast data. The first unit for transmitting the received multicast data of the group corresponding to the authentication table in which the set of the permitted terminal address and the identifier of the virtual network is stored and the group identifier of the multicast data. A forwarding table that stores the port identifiers of port 2 and In response to a request for distribution of multicast data from the terminal, an authentication process for determining whether reception is permitted and a transfer process for transmitting the received multicast data to the terminal according to the forwarding table are performed. In the authentication process, the processing unit receives a distribution request including a group identifier and an address of the terminal from the terminal via one of the second ports, and the distribution. Identifying the identifier of the virtual network to which the second port belongs based on the second port that received the request, and referring to the authentication table, corresponding to the group identifier included in the received delivery request. , It is determined whether the pair of the terminal address included in the delivery request and the specified virtual network identifier is stored, and when it is determined that the pair is stored in the authentication table, the received delivery request is received. The group identifier included in the above and the port identifier of the second port that received the delivery request are stored in the forwarding table, and when it is determined that the group identifier is not stored in the authentication table, the received delivery is performed. A communication device is provided that includes discarding the request.</p><p> According to a second solution of the present invention, the first method includes a communication device having a first port for receiving multicast data and a plurality of second ports for transmitting the multicast data to a terminal. In a network in which a plurality of virtual networks including one or more of the two ports are configured, a step of receiving a delivery request including a group identifier and a terminal address from a terminal and a virtual network to which the port receiving the delivery request belongs. Corresponding to the step of identifying the identifier of the group and the group identifier that identifies the group of multicast data, the address of the terminal that is previously permitted to receive the multicast data of the group in a specific virtual network, and the address of the virtual network. Refers to the authentication table in which the pair with the identifier is stored, and the pair of the terminal address included in the delivery request and the specified virtual network identifier is stored corresponding to the group identifier included in the received delivery request. Steps to determine if it is done, If it is determined that it is stored in the authentication table, the group identifier included in the received delivery request and the port identifier of the port that received the delivery request are stored in the forwarding table and stored in the authentication table. A multicast user authentication method is provided that includes a step of discarding the received delivery request and a step of sending the received multicast data to the terminal connected to the port according to the forwarding table. ..</p>

<p> According to the present invention, it is possible to provide the communication device and the multicast user authentication method in which authentication for multicast communication is performed only by a switch (communication device). Further, according to the present invention, changes in the system can be minimized and the introduction cost can be kept low. For example, according to the present invention, only switches can be changed from existing systems. According to the present invention, it is possible to provide a switch capable of improving security in performing multicast data communication and delivering important data by multicast.</p><p> According to the present invention, it is possible to limit the terminals and VLANs to be distributed for each multicast group. Furthermore, according to the present invention, even if the same multicast group and the same terminal belong to a certain location or belong to a certain VLAN, distribution is restricted, and if the terminal is located in another location or belongs to another VLAN. Can provide switches and authentication methods that can allow delivery.</p>

FIG. 2 shows a system configuration diagram of the present embodiment. This system includes, for example, a device for delivering multicast data (hereinafter referred to as a multicast sender) 10, a router 20 for transferring data such as multicast data, and a switch (communication device) 30. In this system, the multicast sender 10 and the router 20 that relays IP packets (unicast, multicast) are connected to the network (IP10). Further, the DHCP server 1 may be provided in an appropriate place such as a network (IP10).

Further, for example, a switch 30 having an IGMP / MLD snooping function and a MAC address authentication function is connected to the router 20. In the example of FIG. 2, the switch 30 has a terminal 1 (41) that is previously permitted to receive the multicast data (D10) transmitted from the multicast sender 10 and a terminal 2 (42) that is not permitted to receive the multicast data (D10). And the terminal 3 (43), which is permitted to receive but does not intend to receive, is connected.

Terminal 1 (41) in FIG. 2 sends an IGMP / MLD membership report, and since the MAC address and VLAN ID are registered in advance in the switch, it can receive multicast data. Terminal 2 (42) sends an IGMP / MLD membership report, but cannot receive multicast data because the MAC address etc. is not registered in switch 30. Terminal 3 (43) does not receive multicast data because it has not sent an IGMP / MLD membership report.

The switch 30 has, for example, a plurality of ports, an authentication table 31, a forwarding table 32, and a processing unit. The authentication table 31 and the forwarding table 32 will be described later.

The plurality of ports described above are, for example, a first port connected to the router 20 for receiving multicast data and a second port connected to the terminal for transmitting multicast data to the terminal (P1 to Pn). And include. In the example of FIG. 2, for example, ports 1, 2, and 3 belong to VLAN100. Also, port n belongs to VLAN200. These VLANs can be appropriately set in advance and managed by the switch 30. For example, it may further have a VLAN management unit that associates a port with a VLAN.

In response to a request for distribution of multicast data addressed to a desired group address (group identifier) from a terminal belonging to a certain VLAN, the processing unit performs authentication processing for permitting or denying distribution of multicast data addressed to the group address. Do. In addition, the processing unit performs a transfer process of transferring the received multicast data to the terminal.

For example, suppose that router 20 and switch 30 have VLAN100 (V100) and VLAN200 (V200), and terminal 1 (41) that was in VLAN100 (V100) moves to VLAN200 (V200). If it is a conventional switch, terminal 1 (41) moves from VLAN 100 to VLAN 200, and by sending membership report D20 from VLAN 200 to switch 30, terminal 1-2 (41-2) can send multicast data D10 even in VLAN 200. It becomes possible to receive.

However, in the setting of the authentication function of the switch 30 in the present embodiment, it is possible to set which VLAN the MAC address (terminal) belongs to and which multicast data can be received. As shown in the switch authentication settings in Fig. 3, which will be described later, the MAC address (MAC1) can be received only by VLAN100 (V100), and if VLAN200 is not set, terminals 1-2 (44) are addressed to group 1. Multicast data (D10) cannot be received by VLAN200. In this way, a VLAN that can receive multicast data can be specified even within the same switch. For example, even on the same floor, it is possible to prevent reception at a specific location (port corresponding to that location). For example, ports 1 to 3 of VLAN 100 are conference room ports, and port n of VLAN 200 can be associated with a hall port or the like.

Here, the switch 30 of the present embodiment has an advantage that, for example, a table can be easily set as compared with the case where the same security is applied by the access filter using the MAC address.

Typically, a corporate network accommodates each terminal, for example, by placing at least one switch on each floor. If there is one switch on each floor, 10 switches will be placed in a 10-story building.

When setting security for multicast data with an access filter under this condition, set so that a specific terminal cannot receive specific multicast data for all physical ports of the switch, or for each VLAN. It is necessary to set in the same way. If this is set for all floors, the total number of entries will be the number of MAC addresses to be filtered x the number of multicast data x the number of physical ports (or VLANs) of each switch x the number of switches (for example, 10), which makes the setting complicated. .. In addition, time for setting, personnel, and memory capacity are required, and it takes time for memory search during the authentication process. In addition, there are cases where the number of terminals that are permitted to receive multicast data or more is set. In addition, each terminal must clarify which port of which switch it belongs to, which imposes a burden on the terminal user in addition to the man-hours of the administrator.

On the other hand, in the case of the present embodiment, it is only necessary to set the destination group address, MAC address, and VLAN ID for each switch as shown in FIG. It is sufficient to set as many terminals as the number of terminals permitted to receive multicast data, and it is not necessary to set all VLANs and physical ports.

FIG. 3 is an explanatory diagram of the switch authentication table. The authentication table 31 shows, for example, the address of a terminal that is previously permitted to receive the multicast data of the group in a specific virtual network, and the identifier of the virtual network, corresponding to the group identifier that identifies the group of the multicast data. The set with (VLAN ID) is stored in advance. As the terminal address, for example, a MAC address can be used. In addition to the MAC address, an appropriate identifier for identifying the terminal may be used. Further, the ID is not limited to the VLAN ID, and may be an appropriate network or group ID.

The MAC address (MAC1) of the terminal 1 (41) is set to allow reception of the group 1 (G1), which is the destination group address of the multicast data, with the VLAN 100 (V100) of FIG. 2, which is the VLAN to which the terminal 1 (41) belongs. First row of the table). Regarding terminal 2 (42), the multicast data addressed to any group is not permitted to be received, so it is not registered in the authentication table 31. Regarding terminal 3 (43), as with terminal 1 (41), registration of the MAC address (MAC3) is permitted by VLAN100 (V100) in Fig. 2, which is the VLAN to which the destination group address of the multicast data belongs ( Second row of the table).

In the example of FIG. 3, the terminal 1 (41) can receive the multicast data addressed to the group 1 in the VLAN 100, but the multicast data of the group 1 is received in the VLAN 200 because the VLAN 200 is not registered in the authentication table 31. You can't.

Regarding the multicast data of group 2 (G2), for example, terminal 3 (MAC3) can be received by VLAN 100 (4th row of the table). For example, the multicast data of group 2 is not registered in the authentication table 31 because the terminal 1 (41) is not permitted to receive it. In this way, it is possible to set a receivable terminal for each multicast group.

Furthermore, in addition to setting the destination group address and VLAN for the MAC address of the terminal that is permitted to receive multicast data, you can also register the MAC address that allows multicast data addressed to all group addresses to be received by any VLAN. It is possible. It is also possible to register that multicast data addressed to a specific group address can be received in any VLAN, or that multicast data addressed to all group addresses can be received in a specific VLAN. In the example of FIG. 3, the MAC address (MAC3) of the terminal 3 is set to allow reception in any VLAN for the destination group address of the group 3 (G3) (5th row of the table). In short, it is possible to freely select the destination group address and VLAN when setting the MAC address for the terminal. The above-mentioned example of the table configuration is an example, and all the above-mentioned entries may not be stored.

FIG. 4 is an explanatory diagram of the MAC address forwarding table of the switch (30). In the forwarding table 32, for example, the port identifier of the port that transmits the multicast data is stored corresponding to the group address of the multicast data. Further, the VLAN ID of the VLAN corresponding to the port identifier may be stored. Here, as the group address, the MAC address generated from the destination group address (for example, IP address) in FIG. 3 is used. As a method of converting a multicast IP address to a MAC address, an appropriate method can be used. The IP address may be used.

Normally, a switch that is not running IGMP / MLD snooping does not create an entry in the MAC address forwarding table 32 for multicast data. This is a characteristic of the switch, and when multicast data is received from a physical port belonging to a VLAN, the multicast data is relayed to all physical ports belonging to the same VLAN (this is called flooding). To suppress this characteristic, the IGMP / MLD snooping function registers the multicast MAC address in the MAC address forwarding table only for the port that received the membership report. This prevents flooding to ports that are not requesting multicast data by membership report.

In the present embodiment, for the terminal that sends the membership report (D20), it is determined whether the terminal is a reception permitted terminal or a VLAN by referring to the above-mentioned authentication table 31, and the terminal is permitted. For example, the destination MAC address, transmission port, VLAN ID, etc. are stored in the forwarding table 32. As a result, when the multicast data is received, the switch 30 can refer to the forwarding table 32 and output the data only to the port corresponding to the terminal permitted to receive the multicast data.

In this example, in the VLAN 100 shown in FIG. 2, there are terminals 1 (41) and terminals 2 (42) that send a membership report (D20), but in the authentication table 31 of FIG. 3, the terminal 1 (41) Since only the MAC address is permitted in the authentication setting, the MAC address M100 is registered in the MAC address forwarding table 32 of FIG. 4 for the VLAN 100 to which the terminal 1 (41) belongs and the port 1 (P1). As a result, the switch 30 that receives the multicast data (D10) from the router 20 to the destination MAC address M100 refers to the MAC address forwarding table 32 and only for the port 1 (P1) that accommodates the terminal 1 (41). Send multicast data (D10). When a plurality of transmission ports are stored in the MAC address forwarding table 32 for the same destination MAC address, the switch 30 can appropriately copy and transmit the received multicast data.

(Authentication / Registration Process) Next, in the present embodiment, the flow when the switch 30 authenticates the MAC address of the terminal will be described. FIG. 5 is an operation flowchart of the switch 30 at the time of MAC address authentication. First, switch 30 receives the IGMP / MLD membership report sent from the terminal (F10). For example, it receives through one of a plurality of ports (here, for example, port x). The IGMP / MLD membership report includes, for example, the source MAC address and the destination group address of the multicast data requested by the terminal to be delivered. In addition, data related to VLAN may be included. Here, the source MAC address is the MAC address of the terminal.

Switch 30 determines whether the destination group address included in the received IGMP / MLD membership report is subject to authentication (F20). For example, the destination group address to be authenticated can be stored in advance and compared with this.

If the switch 30 is NO in step F20, it is an IGMP / MLD membership report addressed to the destination group address that is not the authentication target, so it is determined whether to allow communication without authentication (F30). Whether or not to allow unauthenticated communication can be set in advance. The switch 30 sends the received IGMP / MLD membership report to the router 20 if the determination in step F30 is YES (F40). In this case, the data received from the router 20 is relayed to the terminal that sent the reception request.

On the other hand, it is also possible to set that communication addressed to a destination group address that is not the target of authentication is not performed without authentication. In that case, on switch 30, the judgment in step F30 becomes NO, and the IGMP / MLD membership report is not sent to the router, but is discarded on switch 30 (F60). In addition, the switch 30 does not register the multicast MAC address in the MAC address forwarding table 32 even for the port that received the IGMP / MLD membership report. Therefore, the switch 30 does not relay the data to the terminal that issued the reception request.

If switch 30 determines in step F20 that the destination group address of the IGMP / MLD membership report is subject to authentication (F20, YES), the process proceeds to step F80. In step F80, switch 30 obtains the source MAC address from the Ethernet (registered trademark) header of the IGMP / MLD membership report packet received from the terminal (F80). Further, the switch 30 identifies the VLAN ID of the VLAN to which the port x belongs from the port x that received the IGMP / MLD membership report packet, for example. For example, a port and the VLAN ID of the VLAN to which the port belongs are managed correspondingly, and the VLAN ID can be specified by referring to this.

The switch 30 uses the acquired source MAC address as a key for authentication and makes an authentication determination of the terminal (F90). For example, switch 30 refers to authentication table 31, and for the destination group address included in the received IGMP / MLD membership report packet, the pair of the acquired terminal MAC address and the identified VLAN ID authenticates. Determine if it is stored in Table 31. If the set of MAC address and VLAN ID is stored (F90, YES), the switch 30 determines that the MAC address or terminal is permitted to receive, while if it is not stored (F90, NO), Judge as a MAC address or terminal that is not permitted to receive.

If the MAC address is not permitted in this determination (F90, NO), the switch 30 discards the IGMP / MLD membership report from the terminal and does not register the destination MAC address addressed to the port in the MAC address table (F90, NO). F100). As a result, the data is not distributed to unauthorized terminals.

On the other hand, if the switch 30 is determined to be an authorized MAC address or terminal by the authentication in step F90 (F90, YES), whether or not there is a terminal that has already received data addressed to the destination group address. Make a judgment (F120). For example, the data reception history may be stored and referred to, or a flag indicating that data is being received may be provided for each multicast group. If there is a terminal that has already received the data addressed to the destination group address (F120, YES), the switch 30 has received the data from the router 20, so an IGMP / MLD membership report is sent to the router 20. No need to send. The switch 30 starts the registration process of the forwarding table 32 (F130). Specifically, the switch 30 registers the multicast MAC address that is permitted to receive, the physical port number that received the IGMP / MLD membership report, and the VLAN to be applied in the MAC address forwarding table 32 (F140). Here, the multicast MAC address is the received IGMP / MLD. The destination group address included in the membership report can be converted from an IP address to a MAC address and stored, for example. As for the conversion process, the same method as the conventional method can be used. When the above information is registered in the MAC address forwarding table 32, the authentication / registration process is completed (F150). In the present embodiment, authentication and registration may be collectively referred to as authentication processing.

On the other hand, when the switch 30 determines in step F120 that no other terminal is participating in the group (F120, NO), the switch 30 relays the IGMP / MLD membership report from the terminal to the router 20 (F190). As a result, the switch 30 can receive the multicast data addressed to the group address from the router 20. The operation of steps F200 to F220 is the same as the operation of steps F130 to F180 described above.

(Transfer processing) FIG. 6 is a flowchart of multicast data transfer processing. Here, it is assumed that the data has already been registered in the MAC address forwarding table 32 by the above-mentioned authentication / registration process.

First, the switch 30 receives the multicast data including the destination group address from the router 20 (F160). Next, the switch 30 identifies the physical port x corresponding to the destination group address according to the MAC address forwarding table 32, and transmits multicast data to the terminal via the physical port x (F170). If there are a plurality of physical ports corresponding to the destination group address, the switch appropriately copies and transmits the multicast data. As a result, the terminal permitted to receive the multicast data can receive the multicast data in the predetermined VLAN.

FIG. 7 is a sequence diagram when group member registration is permitted. For example, terminal 1 (41) will be described as an example. First, the terminal 1 (41) performs login authentication (F1) to the system. At that time, as an example, system authentication that can distribute the IP address only to the MAC address registered in DHCP can be used. Login authentication to this system is irrelevant to the data type. After that, terminal 1 (41), which is permitted to communicate, is permitted to communicate in the system.

In this state, when multicast data distribution (multicast) is started from a specified time, the router 20 sends a general query, for example, periodically to the switch 30 in accordance with the reception of the multicast data. The switch 30 sends this to the terminal 1 (41) or the like connected to each port, and inquires whether to join the group.

After that, for example, when terminal 1 (41) wishes to join the group, for example, by sending an IGMP / MLD membership report according to the input from the user, the terminal 1 (41) requests the group join for the multicast data currently being distributed. (Request to receive multicast data). Switch 30 receives the packet through port 1. Switch 30 snoops the IGMP / MLD membership report packet and checks whether its source MAC address is subject to multicast data distribution permission and whether it matches the authentication settings it manages. This process corresponds to the process shown in FIG.

In this example, since the source MAC address of terminal 1 (41) is permitted in advance by setting, the switch 30 relays the IGMP / MLD membership report to the router 20. The router 20 receives the IGMP / MLD membership report and registers the group member to relay the multicast data from the multicast sender 10 to the switch 30. Here, the router 20 generates a MAC address from the IP group address as the destination address of the multicast data.

The switch 30 relays the multicast data to the port 1 to which the terminal 1 (41) to which the reception request is connected is connected according to the MAC address forwarding table 32, and does not relay to other ports here. This enables multicast data authentication on switch 30 to operate.

FIG. 8 shows a sequence when group member registration is not permitted. For example, terminal 2 (42) will be described as an example. First, the terminal 2 (42) performs login authentication (F1) to the system. At that time, as an example, system authentication that can distribute the IP address only to the MAC address registered in DHCP can be used. Login authentication to this system is irrelevant to the data type. After that, the terminal 2 (42) to which communication is permitted is permitted to communicate in the system.

In this state, when multicast data distribution (multicast) is started from a specified time, the router 20 sends a general query, for example, periodically to the switch 30 in accordance with the reception of the multicast data. The switch 30 sends this to the terminal 2 (42) or the like connected to each port, and inquires whether to join the group.

After that, for example, when terminal 2 (42) wishes to join the group, for example, by sending an IGMP / MLD membership report according to the input from the user, the terminal 2 (42) requests the group join for the multicast data currently being distributed. (Request to receive multicast data). Switch 30 receives the packet through port 1. Switch 30 snoops the IGMP / MLD membership report packet and checks whether its source MAC address is subject to multicast data distribution permission and whether it matches the authentication settings it manages. This process corresponds to the process shown in FIG.

Since the source MAC address of terminal 2 (42) is not allowed in the settings of switch 30, switch 30 does not relay the IGMP / MLD membership report to router 20 and discards it.

As a result, the router 20 does not deliver the multicast data to the switch 30 because the group join request from the terminal has not been received. If there are other terminals that have already joined the same group, the switch 30 has received the multicast data, but the data is for port 2 to which the terminal 2 (42) is connected. Since the multicast MAC address of is not set in the forwarding table 32, the multicast data is not relayed to the terminal 2 (42). This enables multicast data authentication on switch 30 to operate.

The present invention can be used, for example, when performing multicast distribution in an IP network system.

<figref num="1">Schematic diagram of conventional multicast operation.</figref><figref num="2">Schematic diagram of system configuration and operation of multicast user authentication.</figref><figref num="3">Explanatory diagram of the switch authentication table.</figref><figref num="4">Explanatory diagram of the MAC address forwarding table.</figref><figref num="5">Operation flowchart at the time of MAC address authentication.</figref><figref num="6">Multicast data transfer flowchart.</figref><figref num="7">Authentication sequence diagram when group member registration is permitted.</figref><figref num="8">Authentication sequence diagram when group member registration is not permitted.</figref>

Code description

10: Multicast delivery device (multicast sender) 20: Router 30: Switch 31: Authentication table 32: MAC address forwarding table 41 ~ 43: Terminal