Apparatus for limiting use of particular network address
Summary by NHIP
IP Address Limitation Apparatus
The system receives network signals to acquire internet protocol and media access control addresses from connected devices. It generates a second address based on the media access control address and blocks the device if the original address corresponds to the generated one, indicating duplication.
Claim Score by NHIP
Abstract
An apparatus for limiting the use of a network address acquires identification data specific to a device connected to the network and generates a message preventing the device from using a network address generated based on the identification data. An apparatus for limiting data transfer detects that a device connected to a network sends data containing a network address generated based on an identifier specific to the device and prevents such data from being transferred.
Term
Term ended
Expired 5 April 2026, 0.5 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
9 claims: 6 independent, 3 dependent
- 1Broadest claimClaim Score 71, broad(NHIP)A method for limiting the use of an internet protocol address, the method comprising:receiving a signal from a device connected to a network;acquiring the internet protocol address from the signal;acquiring a media access control address specific to the device from the signal;generating a second internet protocol address according to the acquired media access control address;determining whether the media access control address of the device which sends the signal can be identified from the acquired internet protocol address, according to whether the acquired internet protocol address corresponds to the generated second internet protocol address;and sending a message preventing the device from using the acquired internet protocol address when it is determined that the media access control address of the device which sends the signal can be identified from the acquired internet protocol address.
- 3A storage medium storing computer-executable process steps for limiting the use of an internet protocol address, the computer-executable process steps comprising:receiving a signal from a device connected to a network;acquiring the internet protocol address from the signal;acquiring a media access control address specific to the device from the signal;generating a second internet protocol address according to the acquired media access control address;determining whether the media access control address of the device which sends the signal can be identified from the acquired internet protocol address, according to whether the acquired internet protocol address corresponds to the generated second internet protocol address;and sending a message preventing the device from using the acquired internet protocol address when it is determined that the media access control address of the device which sends the signal can be identified from the acquired internet protocol address.
- 5An apparatus for limiting the use of an internet protocol address, comprising:a connection unit configured to connect to a network and receive a signal from a device connected to the network;an acquisition unit configured to acquire the internet protocol address from the signal, and a media access control address specific to the device from the signal;an address generation unit configured to generate a second internet protocol address according to the media access control address acquired by the acquisition unit;a determination unit configured to determine whether the media access control address of the device which sends the signal can be identified from the acquired internet protocol address, according to whether the acquired internet protocol address corresponds to the generated second internet protocol address;and a message generation unit configured to generate a message preventing the device from using the acquired internet protocol address when it is determined that the media access control address of the device which sends the signal can be identified from the acquired internet protocol address;and a sending unit configured to send the message to the device.
- 7A method for limiting data transfer from a first network to a second network, the method comprising:receiving a signal with a destination address corresponding to a first device connected to the first network from a second device connected to the second network;acquiring an internet protocol address from the signal;acquiring a media access control address specific to the second device from the signal;generating a second internet protocol address according to the acquired media access control address;determining whether the media access control address of the second device can be identified from the acquired internet protocol address, according to whether the acquired internet protocol address corresponds to the generated second internet protocol address;sending a message preventing the second device from using the acquired internet protocol address and limiting transfer of the signal when it is determined that the media access control address of the second device can be identified from the acquired internet protocol address;and transmitting the signal to the first network when it is determined that the media access control address of the second device cannot be identified from the acquired internet protocol address.
- 8A storage medium storing computer-executable process steps for limiting data transfer from a first network to a second network, the computer-executable process steps comprising:receiving a signal with a destination address corresponding to a first device connected to the first network, from a second device connected to a network;acquiring an internet protocol address from the signal;acquiring a media access control address specific to second the device from the signal;generating a second internet protocol address according to the acquired media access control address;determining whether the media access control address of the second device can be identified from the acquired internet protocol address, according to whether the acquired internet protocol address corresponds to the generated second internet protocol address;sending a message preventing the second device from using the acquired internet protocol address and limiting transfer of the signal when it is determined that the media access control address of the second device can be identified from the acquired internet protocol address;and transmitting the signal to the first network when it is determined that the media access control address of the second device cannot be identified from the acquired internet protocol address.
- 9An apparatus for limiting data transfer from a first network to a second network, comprising:a connection unit configured to connect the first network and the second network and receive a signal with a destination address corresponding to the first device connected to the first network, from a second device connected to the second network;an acquisition unit configured to acquire an internet protocol address from the signal, and a media access control address specific to the second device from the signal;an address generation unit configured to generate a second internet protocol address according to the acquired media access control address;a determination unit configured to determine whether the media access control address of the second device can be identified from the internet protocol address acquired from the signal, according to whether acquired internet protocol address corresponds to the generated second internet protocol address;a limiting unit configured to limit transfer of the signal, and send a message preventing the second device from using the acquired internet protocol address when it is determined that the media access control address of the second device can be identified from the acquired internet protocol address;and a transmission unit configured to transmit the signal to the first network when it is determined that the media access control address of the second device cannot be identified from the acquired internet protocol address.
Independent claims6
102 paragraphs in 4 sections, as filed
BACKGROUND OF THE INVENTION
00011. Field of the Invention
0002The present invention relates to an apparatus for limiting the use of a particular network address.
00032. Description of the Related Art
0004Personal computers and workstations supporting IPv6 typically use Ethernet® for the network connection interface, and generate an IPv6 address based on the Ethernet® IEEE identifier (MAC address). Hereinafter, an address generated in the manner described above is called an IEEE EUI-64 IPv6 address.
0005As described later, there are three types of IPv6 address: link-local addresses, site-local addresses, and (aggregatabale) global addresses.
0006The IPv6 addressing scheme is described in detail in the following documents: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0007">Request for Comment (RFC) 2373 IP Version 6 Addressing Architecture,</li><li id="ul0002-0002" num="0008">RFC 2374 An IPv6 Aggregatabale Global Unicast Address Format,</li><li id="ul0002-0003" num="0009">RFC 2375 IPv6 Multicast Address Assignment,</li><li id="ul0002-0004" num="0010">RFC 2450 Proposed TLA and NLA Assignment Rule,</li><li id="ul0002-0005" num="0011">RFC 2461 Neighbor Discovery for IP Version 6 (IPv6), and</li><li id="ul0002-0006" num="0012">RFC 2462 IPv6 Stateless Address Autoconfiguration.</li></ul></li></ul>
0013IEEE EUI-64 IPv6 addresses of network devices are generated based on the IEEE identifiers (i.e., MAC addresses) of the hardware interfaces (e.g., Ethernet®) used in the network devices, where each hardware interface has a unique IEEE identifier. This approach readily leads to privacy infringement of a network device or the user of the network device, because the activities can easily be identified by monitoring communication involving the IEEE EUI-64 IPv6 address of the network device.
0014To overcome this problem, procedures for generating random IPv6 addresses, specifically interface IDs, are proposed in, for example, RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. This document also describes a protocol, and its extension, for detecting whether or not a generated random value is already used and, if used, generating another unique random address. This random IPv6 address is called a temporary address or anonymous address.
0015Not all devices may use an anonymous address. Some devices may be initialized to use an IEEE EUI-64 IPv6 address. Therefore, these devices may be subject to privacy infringement if the IEEE EUI-64 IPv6 address is used continuously.
SUMMARY OF THE INVENTION
0016An object of the present invention is to protect the privacy of network devices. Other objects of the present invention include protecting privacy in a simple manner, protecting privacy while maintaining system operability, limiting data transfer which may lead to privacy infringement, and limiting the scope in which addresses uniquely corresponding to particular devices or the users of the devices can be used.
0017According to an aspect of the present invention, a method for limiting the use of a network address includes the steps of acquiring identification data specific to a device connected to the network, and sending a message preventing the device from using a network address generated based on the identification data.
0018According to another aspect of the present invention, computer-executable process steps (i.e., a program) for limiting the use of a network address include acquiring identification data specific to a device connected to the network, and sending a message preventing the device from using a network address generated based on the identification data.
0019According to yet another aspect of the present invention, an apparatus for limiting the use of a network address includes a connection section for connecting to a network and acquiring identification data specific to a device connected to the network, and a generation section for generating a message preventing the device from using a network address generated based on the identification data, wherein the connection section sends the message to the device.
0020According to still yet another aspect of the present invention, a method for limiting data transfer includes the steps of detecting that a device connected to a network sends data containing a network address generated based on an identifier specific to the device, and preventing the data from being transferred.
0021According to another aspect of the present invention, computer-executable process steps (i.e., a program) for limiting data transfer include detecting that a device connected to a network sends data containing a network address generated based on an identifier specific to the device, and preventing the data from being transferred.
0022According to another aspect of the present invention, an apparatus for limiting data transfer includes a connection section for connecting to a network, and a prevention section for preventing a device connected to the network from transferring data containing a network address generated based on an identifier specific to the device.
0023According to the present invention, the privacy of network devices can be protected.
0024Further objects, features and advantages of the present invention will become apparent from the following description of the preferred embodiments with reference to the attached drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
0025<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of an Ethernet LAN.
0026<figref idref="DRAWINGS">FIG. 2</figref> shows an internal structure of a node.
0027<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart showing the steps of DAD by a host.
0028<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart showing the steps of address autoconfigurations by a host.
0029<figref idref="DRAWINGS">FIG. 5</figref> shows a flowchart for checking a network address.
0030<figref idref="DRAWINGS">FIG. 6</figref> shows a flowchart for determining whether or not data should be transferred.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
0031Embodiments of the present invention will now be described by way of an example where a host connects to the Internet via an Ethernet® LAN. An existing network mechanism is first described, followed by a description of embodiments according to the present invention.
0032<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a network to which the present invention is applied. This network assumes that a host connects to the Internet via an Ethernet® LAN.
0033In <figref idref="DRAWINGS">FIG. 1</figref>, hosts <b>204</b>, <b>205</b>, and <b>206</b> connected to the LAN access the Internet <b>201</b> via a gateway <b>202</b>. According to the embodiments of the present invention, each host is connected to a link <b>207</b>. The gateway <b>202</b> is connected to the Internet <b>201</b> via a link <b>208</b>. A link is a facility or medium that allows devices connected to the same link to communicate with each other or with other devices that are connected via a different link. A link corresponds to the layer underneath the IP layer. In addition to Ethernet®, a link may be realized by a PPP link, X.25, Frame Relay, or ATM network. IPv6 devices connected to a link are referred to as nodes. The network of <figref idref="DRAWINGS">FIG. 1</figref> also includes a DHCP server <b>203</b>.
0034<figref idref="DRAWINGS">FIG. 2</figref> shows a typical internal structure of a node <b>300</b> on a network.
0035The node <b>300</b> may be a router or a host. A router forwards packets destined for devices other than itself, whereas a host does not. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the node <b>300</b> is a computer which includes network interfaces <b>301</b> and <b>302</b>, a CPU <b>303</b>, a read-only memory (ROM) <b>304</b>, a random access memory (RAM) <b>305</b>, a hard disk (HD) <b>306</b>, a power supply <b>307</b>, a keyboard/pointing-device interface <b>308</b>, a monitor interface <b>309</b>, and a bus <b>310</b>.
0036If the node <b>300</b> is a router, it has multiple interfaces <b>301</b> and <b>302</b>. If the node <b>300</b> is a host, it typically has a single interface <b>301</b>. The network interface <b>301</b> is connected to the link <b>207</b> to allow the node <b>300</b> to communicate with other nodes connected to the link <b>207</b>.
0037Through the network interface <b>301</b>, the hosts <b>204</b>, <b>205</b>, and <b>206</b> communicate with other nodes connected to the link <b>207</b> via the link <b>207</b> as well as with sites on the Internet <b>201</b> via the gateway <b>202</b>. In the case where the gateway <b>202</b> functions as a router, the network interface <b>301</b> in the gateway <b>202</b> is connected to the link <b>207</b>, via which the gateway <b>202</b> communicates with other devices on the link <b>207</b>. The network interface <b>302</b> in the gateway <b>202</b> is connected to the link <b>208</b>, via which the gateway <b>202</b> is connected to the Internet <b>201</b> and communicates with nodes on the Internet <b>201</b>.
0038The following processing is achieved by an apparatus or a computer program. An apparatus that carries out the following steps is included in the node <b>300</b>. A computer program that carries out the following steps is stored in the ROM <b>304</b> or the HD <b>306</b> of a node. A computer program that carries out the following steps is loaded by the CPU <b>303</b> to, for example, assign an address to the interfaces <b>301</b> and <b>302</b> via the bus <b>310</b>, while using the RAM <b>305</b> as a work area for calculation if necessary.
0039The mechanism of the protocol for each host to detect the prefix of an IPv6 global address or the address of the default gateway in the Ethernet® LAN environment will be described first, followed by a description of the embodiments of the present invention.
0040A typical IPv6 address is comprised of 128 bits, where the high-order 64 bits include a prefix and the low-order 64 bits include an interface ID. The interface ID is generated based on the 48-bit MAC address of the Ethernet® interface. The interface ID generated based on the 48-bit MAC address of the Ethernet® interface is called an IEEE EUI-64 interface ID. The IPv6 address generated based on the IEEE EUI-64 interface ID is called an IEEE EUI-64 IPv6 address.
0041<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart showing how a node in <figref idref="DRAWINGS">FIG. 2</figref> operates when it is powered ON or rebooted. This operation is called duplicate address detection (DAD).
0042Referring to <figref idref="DRAWINGS">FIG. 3</figref>, when the node <b>300</b> in <figref idref="DRAWINGS">FIG. 2</figref> (i.e., a node in <figref idref="DRAWINGS">FIG. 1</figref>) is powered ON or rebooted (step S<b>801</b>), the node <b>300</b> generates an interface ID based on the Ethernet® MAC address of the network interface <b>301</b> and adds a predetermined prefix to the interface ID, thus producing a tentative link-local address (step S<b>802</b>).
0043The node <b>300</b> proceeds to the following processing to determine whether the tentative link-local address is unique on the link <b>207</b>.
0044In step S<b>803</b>, the node <b>300</b> initializes the interface <b>301</b>. Specifically, the node <b>300</b> assigns to the interface <b>301</b> the all-nodes multicast address (FF02::1) and the solicited-node multicast address of the tentative link-local address.
0045Assignment of the all-nodes multicast address allows the node <b>300</b> to receive data from another node that already uses the tentative link-local address. Assignment of the solicited-node multicast address of the tentative link-local address allows the node <b>300</b> to detect another node that is also going to use the same tentative link-local address.
0046As defined in page 91 of RFC 2461, the solicited-node multicast address of a tentative link-local address is a link-local scope multicast address as obtained by adding the low-order 24 bits of the tentative link-local address to the prefix FF02:0:0:0:0:1:FF00::/104.
0047The node <b>300</b> then generates a Neighbor Solicitation message. For this purpose, the Neighbor Solicitation message is set to have the tentative link-local address to be judged in Target Address, the unspecified address (i.e., where all the 128 bits are 0) in IP Source (source address), and the solicited-node multicast address of the tentative link-local address in IP Destination (destination address).
0048In step S<b>804</b>, the node <b>300</b> sends this Neighbor Solicitation message to the link (i.e., Ethernet® LAN) <b>207</b> at intervals of RetransTimer milliseconds as many times as specified in DupAddrDetectTransmits.
0049Nodes that have received the Neighbor Solicitation message judge that the message is from a node doing DAD by detecting the unspecified address in the source address.
0050If two or more nodes are carrying out DAD for the same address, each node knows that another node is also doing DAD for the address when the node receives a Neighbor Solicitation messages containing the same address in Target Address, as well as its own Neighbor Solicitation messages (i.e., the node receives both its own Neighbor Solicitation message and a Neighbor Solicitation message sent by another node that is carrying out DAD for the same address). If this is the case, no nodes use the address.
0051If a node that has received the Neighbor Solicitation message uses the address specified in Target Address of the message, the node returns to the all-nodes multicast address a multicast Neighbor Advertisement having the tentative link-local address set in Target Address. Thus, if the node <b>300</b> that has sent a Neighbor Solicitation message receives a multicast Neighbor Advertisement sent to the all-nodes multicast address, and if the target address contains the tentative address to be judged (i.e., if “YES” is applicable at step S<b>805</b> in <figref idref="DRAWINGS">FIG. 3</figref>), the tentative address is judged not to be unique (i.e., to be duplicated) and the process ends.
0052If the tentative link-local address is judged to be unique on the link <b>207</b> (“NO” at step S<b>805</b> in <figref idref="DRAWINGS">FIG. 3</figref>) as a result of the processing described above, the node <b>300</b> assigns the address as a link-local address to the interface <b>301</b> in step S<b>806</b>.
0053The DAD operation described above with reference to <figref idref="DRAWINGS">FIG. 3</figref> can be carried out by any of the gateway <b>202</b>, DHCP server <b>203</b>, host <b>204</b>, host <b>205</b>, and host <b>206</b>.
0054After the node <b>300</b> (e.g., the host <b>206</b> in <figref idref="DRAWINGS">FIG. 1</figref>) has assigned the link-local address to the interface <b>301</b>, the host <b>206</b> then attempts to acquire information necessary to determine the global address and the site-local address. This is referred to as Router Advertisement.
0055The method for acquiring a Router Advertisement is described below with reference to <figref idref="DRAWINGS">FIG. 4</figref>. For the following description, the gateway <b>202</b> is presumed to send a Router Advertisement. The gateway <b>202</b> is commonly referred to as a router, thus, hereinafter “gateway <b>202</b>” is referred to as “router <b>202</b>”. The router <b>202</b> has necessary information set by an administrator, and periodically sends a Router Advertisement to the link <b>207</b>. If the host <b>206</b> needs to acquire a Router Advertisement sooner, the host <b>206</b> sends data called Router Solicitation to the router <b>202</b>. Immediately after having assigned the link-local address, the host <b>206</b> does not know the existence of the router <b>202</b>, and hence the host <b>206</b> in fact multicasts Router Solicitation to all routers on the link <b>207</b> (step S<b>901</b>).
0056When the router <b>202</b> receives the Router Solicitation, it sends back a Router Advertisement. If, in step S<b>902</b>, the host <b>206</b> has received a Router Advertisement in which Stateless Address Autoconfiguration only is specified, the host <b>206</b> checks the validity of the prefix(es) contained in the message to ensure that, among other things, the prefix(es) is not used by the host <b>206</b>. Then, in step <b>903</b>, the host <b>206</b> assigns the address composed of the prefix(es) and the interface ID to the interface <b>301</b> as the site-local address or global address(Stateless Address Autoconfiguration).
0057If, in step S<b>902</b>, the host <b>206</b> does not receive a Router Advertisement in which Stateless Address Autoconfiguration only is specified, flow proceeds to step S<b>904</b>, where a determination is made whether the host <b>206</b> receives a Router Advertisement in which both Stateless Address Autoconfiguration and Stateful Address Autoconfiguration are specified. In the case where both Stateless Address Autoconfiguration and Stateful Address Autoconfiguration are specified, Stateless and Stateful Address Autoconfigurations are performed in step S<b>905</b>. In the case where both Stateless Address Autoconfiguration and Stateful Address Configuration are not specified, flow proceeds to step S<b>906</b>.
0058In step <b>906</b>, the host <b>206</b> carries out Stateful Address Autoconfiguration, i.e., DHCP v6 only, as described below.
0059Details such as messages or their contents associated with Stateful Address Autoconfiguration are described in RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The flow of the basic operation is as follows.
0060The host <b>206</b> sends a DHCP Solicit message to the DHCP server <b>203</b>. The host <b>206</b> does not know where the DHCP server <b>203</b> exists, and hence multicasts a DHCP Solicit message onto the link <b>207</b> for the DHCP servers.
0061When the DHCP server <b>203</b> receives the DHCP Solicit message, the DHCP server <b>203</b> responds by returning a DHCP Advertise message to the host <b>206</b>. The DHCP Advertise message reaches the host <b>206</b>. When receiving the DHCP Advertise message, the host <b>206</b> is informed of the address of the DHCP server <b>203</b>.
0062The host <b>206</b> then sends a DHCP Request message to the DHCP server <b>203</b>. When receiving the DHCP Request message, the DHCP server <b>203</b> sends back a DHCP Reply message to the host <b>206</b>.
0063When receiving the DHCP Reply message, the host <b>206</b> determines the site-local address or global address from the DHCP Reply message, and then performs processing necessary for DAD in order to check whether the interface ID in the address is duplicated. In short, the host <b>206</b> sets the multicast address described above and other information to the interface <b>301</b>.
0064The host <b>206</b> then sends a Neighbor Solicitation message and sees whether or not a Neighbor Advertisement message is returned. If a Neighbor Advertisement message is received, the host <b>206</b> judges that the address is duplicated, and hence repeats sending of the DHCP Request message and the subsequent steps in order to receive another address from the DHCP server <b>203</b>.
0065When the host <b>206</b> does not receive a Neighbor Advertisement message, the host <b>206</b> judges that the address is not duplicated and then assigns the address to the interface <b>301</b>.
0066When the host <b>206</b> does not receive a Router Advertisement at step S<b>904</b>, Stateful Address Autoconfiguration is carried out at step <b>906</b> as described above and the processing ends normally.
0067If the host <b>206</b> receives a Router Advertisement in which both Stateless Address Autoconfiguration and Stateful Address Autoconfiguration are specified at step S<b>904</b>, the host <b>206</b> carries out both Stateless Address Autoconfiguration and Stateful Address Autoconfiguration at step S<b>905</b>.
0068In this manner, the host <b>206</b> using Ethernet® as an interface can automatically set a link-local address, a site-local address, a global address, a default gateway, etc. by using any combination of Stateless Address Autoconfiguration and Stateful Address Autoconfiguration (DHCPv6).
0069If an anonymous address is to be used, the above-mentioned protocol is extended as follows. At step S<b>903</b> or step S<b>905</b> in <figref idref="DRAWINGS">FIG. 4</figref>, the host <b>206</b> receives the Router Advertisement, checks the validity of the prefix(es) contained in the message, for example, to ensure that the prefix(es) is not used by the host <b>206</b>, and then assigns the addresses composed of the prefix(es) plus IEEE EUI-64 and random interface IDs to the interface <b>301</b> as the site-local address or global address. At this time, the random interface ID and the IEEE EUI-64 interface ID are subjected to the same processing. The procedures for generating a random interface ID are described later.
0070A new anonymous address is generated by appending the random interface ID to the prefix. If the address already assigned by the host <b>206</b> to the interface <b>301</b> is the same as the new anonymous address, the host <b>206</b> generates a new random interface ID to produce a new anonymous address.
0071The host <b>206</b> then carries out DAD for the anonymous address. If DAD reveals that another device already uses the anonymous address, the host <b>206</b> generates a new anonymous address. If a unique anonymous address cannot be obtained after the host <b>206</b> repeats DAD up to five times, the host <b>206</b> logs a system error and gives up the generation of an anonymous address.
0072A random interface ID is generated using an MD<b>5</b> message digest. MD<b>5</b> is a function for outputting a random 128-bit value based on any input. The procedures described in RFC 3041 use 128 bits as an input. These input 128 bits include high-order 64 bits and low-order 64 bits obtained as follows. The IEEE EUI-64 interface ID is used for the low-order 64 bits of the input 128 bits. A random 64-bit value generated in some way or the low-order 64-bit value of the previous MD<b>5</b> calculation result is used for the high-order 64 bits of the input 128 bits. An MD<b>5</b> message digest is calculated with these 128 bits as an input and the high-order 64 bits of the 128-bit calculation result are employed. The 7th bit from the left of the obtained 64 bits is set to 0 and the resultant 64 bits are used as the random interface ID. The low-order 64 bits of the calculation result are recorded for the next MD<b>5</b> calculation.
First Embodiment
0073A first embodiment according to the present invention will now be described. For this embodiment, a protocol for preventing a node from using an IEEE EUI-64 IPv6 address is described. This protocol works based on the above-described operation.
0074Communication at the level of the data link layer (e.g., Ethernet®) underneath the IP layer is performed as broadcast packet communication where the MAC addresses of Ethernet® interfaces are used as respective identifiers to identify the Ethernet® interfaces. Therefore, devices that are capable of accessing via Ethernet® can monitor all communication packets and can acquire the source MAC address and the destination MAC address of each packet.
0075The operation of an apparatus for limiting the use of a particular address according to this embodiment will be described with reference to <figref idref="DRAWINGS">FIG. 5</figref>. The embodiment is described by way of an example where the host <b>206</b> attempts to use an IEEE EUI-64 IPv6 address. The following processing is carried out by an apparatus or a program. A program that carries out the following steps is stored in the ROM <b>304</b> or the HD <b>306</b> of a node. <figref idref="DRAWINGS">FIG. 5</figref> shows the main section of the program.
0076Any IPv6 device connected to the link <b>207</b> can acquire the MAC address of the host <b>206</b>, and hence any of the gateway <b>202</b>, the DHCP server <b>203</b>, and the hosts <b>204</b>, <b>205</b>, <b>206</b> can be the apparatus for limiting the use of a particular address.
0077The apparatus (i.e., node) for limiting the use of a particular address is installed on the same link (i.e., subnet) <b>207</b> as the host (i.e., IPv6 device) <b>206</b>. The apparatus for limiting the use of a particular address determines whether the IPv6 address to be used by the host <b>206</b> is an anonymous (or temporary) address by comparing the anonymous address with the IEEE EUI-64 IPv6 address generated based on the MAC address of the data link layer of the host <b>206</b>. If the host <b>206</b> attempts to use an IEEE EUI-64 IPv6 address, the apparatus for limiting the use of a particular address sends a message indicating that the address is already used to prevent the host <b>206</b> from using the address.
0078Referring to <figref idref="DRAWINGS">FIG. 5</figref>, when the host <b>206</b> is powered ON or rebooted, the host <b>206</b> carries out DAD. At step S<b>101</b>, the apparatus for limiting the use of a particular address that has received a Neighbor Solicitation message acquires the Target Address to check whether the target address corresponds to its own address. The flow proceeds to step S<b>107</b> when the target address corresponds to its own address or to step S<b>102</b> if does not.
0079At step S<b>102</b>, the apparatus for limiting the use of a particular address acquires the low-order 64 bits (i.e., interface ID) of the Target Address.
0080Next, at step S<b>103</b>, the apparatus for limiting the use of a particular address checks whether the 25th to 40th bits from the left of the acquired interface ID correspond to 0xFFFE. The flow proceeds to step S<b>104</b> if the 25th to 40th bits correspond to 0xFFFE. If they do not correspond, the process ends.
0081At step S<b>104</b>, the apparatus for limiting the use of a particular address checks whether the 7th bit from the left of the acquired interface ID corresponds to 1. The flow proceeds to step S<b>105</b> if the 7th bit corresponds to 1. If it does not, the process ends.
0082At step S<b>105</b>, the apparatus for limiting the use of a particular address acquires the source MAC address (i.e., identifier of the source device at the level of the data link layer and the source device-specific identifier) of the Ethernet® packets including the Neighbor Solicitation message.
0083Then, at step S<b>106</b>, the apparatus for limiting the use of a particular address checks whether the IEEE EUI-64 format 64-bit data generated based on the source MAC address (i.e., source device-specific identifier) corresponds to the interface ID acquired at step S<b>102</b>. The flow proceeds to step S<b>107</b> if the 64-bit data corresponds to the interface ID. If the 64-bit data does not correspond, the process ends.
0084At step S<b>107</b>, the apparatus for limiting the use of a particular address sends a multicast Neighbor Advertisement in accordance with the IPv6 Neighbor Discovery Protocol.
0085In the above-described processing, the host <b>206</b> can use an interface ID other than the IEEE EUI-64 interface ID because in this case the host <b>206</b> does not receive a multicast Neighbor Advertisement. Therefore, the host <b>206</b> can use an IPv6 address generated based on the interface ID other than the IEEE EUI-64 interface ID.
0086In contrast, when the host <b>206</b> attempts to use an IEEE EUI-64 interface ID, the host <b>206</b> receives a multicast Neighbor Advertisement, and therefore, cannot use the IEEE EUI-64 interface ID and accordingly, an IPv6 address generated based on the IEEE EUI-64 interface ID. Thus, the host <b>206</b> will use another IPv6 address, if possible.
0087In short, when the source host <b>206</b> attempts to use an IPv6 address generated based on the IEEE EUI-64 interface ID, namely, a network address generated in the specified manner based on the source MAC address (i.e., identifier of the source device at the level of the data link layer and the source device-specific identifier), the apparatus for limiting the use of a particular address detects this attempt by the host <b>206</b>. The apparatus for limiting the use of a particular address then sends a multicast Neighbor Advertisement, i.e., a message indicating that the network address is already used, to notify the host <b>206</b> that the network address cannot be used.
0088Consequently, the host <b>206</b> is ruled out from the danger of privacy infringement.
Second Embodiment
0089A second embodiment of the present invention will now be described. In this embodiment, an address generated based on an IEEE EUI-64 interface ID is allowed, but extra-network communication by using such an address is prevented to protect privacy.
0090According to this embodiment, an apparatus for limiting the use of a particular address is provided which allows a node to use a link-local address generated based on its IEEE EUI-64 interface ID, but prevents the node from sending data to an external network if the data contains a global address generated based on its IEEE EUI-64 interface ID.
0091The apparatus for limiting the use of a particular address is realized by the gateway (router) <b>202</b> in <figref idref="DRAWINGS">FIG. 1</figref>. The operation of the gateway <b>202</b> as the apparatus for limiting the use of a particular address is described with reference to <figref idref="DRAWINGS">FIG. 6</figref>. The following processing is realized by an apparatus or a program. A program that carries out the following steps is stored in the ROM <b>304</b> or the HD <b>306</b> of a node. <figref idref="DRAWINGS">FIG. 6</figref> shows the main section of the program. For this embodiment, the apparatus for limiting the use of a particular address is capable of generating a list and managing it. This list is stored in the RAM <b>305</b>. This list holds addresses at step S<b>1007</b> in <figref idref="DRAWINGS">FIG. 6</figref> as described below.
0092The apparatus (i.e., router <b>202</b> in this embodiment) for limiting the use of a particular address is installed on the same link (i.e., subnet) <b>207</b> as the host (i.e., IPv6 device) <b>206</b>. The apparatus for limiting the use of a particular address determines whether the IPv6 address used by a host such as the host <b>206</b> is an anonymous (or temporary) address by comparing the anonymous address with the IEEE EUI-64 IPv6 address generated based on the MAC address at the link layer of the host <b>206</b>. The router <b>202</b> checks whether each packet contains an IEEE EUI-64 IPv6 address, and discards applicable packets to prevent such packets from going outside the link (i.e., network) <b>207</b>.
0093The router <b>202</b> handles IPv6 packets that are sent by the host <b>206</b> on the link <b>207</b> to the Internet <b>201</b> in the following manner. IPv6 packets intended to go to the Internet <b>201</b>, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, are those packets having a destination address in the Internet <b>201</b>.
0094Referring to <figref idref="DRAWINGS">FIG. 6</figref>, at step S<b>1001</b>, the router <b>202</b> acquires the source address of an IPv6 packet and checks whether the source address is registered in the list in the RAM <b>305</b>. The flow proceeds to step S<b>1008</b> if the source address is registered, and to step S<b>1002</b> if the source address is not registered.
0095At step S<b>1002</b>, the router <b>202</b> acquires the low-order 64 bits (interface ID) of the source address of the IPv6 packet. The router <b>202</b>, in step S<b>1003</b>, then checks whether the 25th to 40th bits from the left of the interface ID correspond to 0xFFFE. The flow proceeds to step S<b>1004</b> if the 25th to 40th bits correspond to 0xFFFE and to step S<b>1009</b> if the bits do not correspond.
0096At step S<b>1004</b>, the router <b>202</b> checks whether the 7th bit from the left of the obtained interface ID is 1. The flow proceeds to step S<b>1005</b> if the 7th bit corresponds to 1 and to step S<b>1009</b> if the bit does not correspond.
0097At step S<b>1005</b>, the router <b>202</b> acquires the source MAC address of Ethernet® packet containing the IPv6 packet.
0098Next, at step S<b>1006</b>, the router <b>202</b> checks whether the IEEE EUI-64 format 64-bit data generated based on the source MAC address corresponds to the interface ID acquired at step S<b>1002</b>. The flow proceeds to step S<b>1007</b> if the 64-bit data corresponds to the interface ID and to step S<b>1009</b> if the 64-bit data does not correspond.
0099At step S<b>1007</b>, the router <b>202</b> registers the source address of the IPv6 packet in the list and proceeds to step S<b>1008</b>. Thus, for packets having the source address registered in the list, the flow jumps from step S<b>1001</b> to step S<b>1008</b>, i.e., steps S<b>1002</b> to S<b>1007</b> are skipped.
0100At step S<b>1008</b>, the router <b>202</b> discards the IPv6 packet and ends the operation.
0101If, as described above, in step S<b>1003</b> the 25th to 40th bits do not correspond to 0xFFFE, then at step S<b>1009</b>, the router <b>202</b> transfers the IPv6 packet to the Internet (external network) <b>201</b> and then the operation ends.
0102As is apparent from the operation described above, IPv6 packets having a global address generated from an IEEE EUI-64 interface ID in the source address are discarded by the router <b>202</b>, and therefore are not transferred to the Internet <b>201</b>.
0103In contrast, IPv6 packets having a global address generated from an interface ID other than an IEEE EUI-64 interface ID in the source address are transferred to the Internet <b>201</b>.
0104In short, transfer of data containing an IPv6 address generated from an IEEE EUI-64 interface ID, namely, a network address generated in the specified manner from the MAC address (identifier on the data link layer and device-specific identifier) of the source host <b>206</b>, is detected and blocked by the router <b>202</b> as the apparatus for limiting the use of a particular address.
0105Thus, the node <b>206</b> is ruled out from the danger of privacy infringement.
0106While the present invention has been described with reference to what are presently considered to be the preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. On the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.
Contents4
8 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2008301229A1 | Cited by | United States of America | Pre-grant |
| US2002133573A1 | Cites | United States of America | Search report |
| US2002133607A1 | Cites | United States of America | Search report |
| US2003026230A1 | Cites | United States of America | Search report |
| US2004088544A1 | Cites | United States of America | Search report |
| US5826014A | Cites | United States of America | Search report |
| US6101499A | Cites | United States of America | Search report |
| US6178455B1 | Cites | United States of America | Search report |
| US6629149B1 | Cites | United States of America | Search report |
| US6704789B1 | Cites | United States of America | Search report |
| US6745333B1 | Cites | United States of America | Search report |
| US6922412B2 | Cites | United States of America | Search report |
| US6930988B2 | Cites | United States of America | Search report |
| US6959009B2 | Cites | United States of America | Search report |
| US7075897B2 | Cites | United States of America | Search report |
| US7155500B2 | Cites | United States of America | Search report |
| US20020133573A1 | Cites | United States of America | Search report |
| US20020133607A1 | Cites | United States of America | Search report |
| US20030026230A1 | Cites | United States of America | Search report |
| US20040088544A1 | Cites | United States of America | Search report |
| R. Hinden and S. Deering, RFC 2373, IP Version 6 Addressing Architecture, Jul. 1998, pp. 6 and 7. | Non-patent | – | Search report |
| Charles E. Perkins and Jim Bound, DHCP for IPv6, Jun. 30-Jul. 2, 1998, Computers and Communications, pp. 493-497. | Non-patent | – | Search report |
| S. Thomson & T. Narten; RFC 2462—IPv6 Stateless Address Autoconfiguration; Dec. 1999. | Non-patent | – | Search report |
| T. Narten & R. Draves; RFC 3041—Privacy Extensions for Stateless Address Autoconfiguration in IPv6; Jan. 2001. | Non-patent | – | Search report |
| http://www.ietf.org/rfc/rfc2373.txt?number=2373. | Non-patent | – | Third party observation |
| http://www.ietf.org/rfc/rfc2374.txt?number=2374. | Non-patent | – | Third party observation |
| http://www.ietf.org/rfc/rfc2375.txt?number=2375. | Non-patent | – | Third party observation |
| http://www.ietf.org/rfc/rfc2450.txt?number=2450. | Non-patent | – | Third party observation |
| http://www.ietf.org/rfc/rfc2461.txt?number=2461. | Non-patent | – | Third party observation |
| http://www.ietf.org/rfc/rfc2462.txt?number=2462. | Non-patent | – | Third party observation |
| http://www.ietf.org/rfc/rfc3513.txt?number=3513. | Non-patent | – | Third party observation |
| R. Hinden and S. Deering, RFC 2373, IP Version 6 Addressing Architecture, Jul. 1998, pp. 6 and 7. | Non-patent | – | Search report |
| Charles E. Perkins and Jim Bound, DHCP for IPv6, Jun. 30-Jul. 2, 1998, Computers and Communications, pp. 493-497. | Non-patent | – | Search report |
| S. Thomson & T. Narten; RFC 2462-IPv6 Stateless Address Autoconfiguration; Dec. 1999. | Non-patent | – | Search report |
| T. Narten & R. Draves; RFC 3041-Privacy Extensions for Stateless Address Autoconfiguration in IPv6; Jan. 2001. | Non-patent | – | Search report |
| http://www.ietf.org/rfc/rfc2373.txt?number=2373. | Non-patent | – | Applicant |
| http://www.ietf.org/rfc/rfc2374.txt?number=2374. | Non-patent | – | Applicant |
| http://www.ietf.org/rfc/rfc2375.txt?number=2375. | Non-patent | – | Applicant |
| http://www.ietf.org/rfc/rfc2450.txt?number=2450. | Non-patent | – | Applicant |
| http://www.ietf.org/rfc/rfc2461.txt?number=2461. | Non-patent | – | Applicant |
| http://www.ietf.org/rfc/rfc2462.txt?number=2462. | Non-patent | – | Applicant |
| http://www.ietf.org/rfc/rfc3513.txt?number=3513. | Non-patent | – | Applicant |
4 members in 2 offices; this record represents the family
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 2003152834 | Japan | – | |
| 2003152834 | Japan | A |
Members4
| Document | Office | Kind | |
|---|---|---|---|
| US2004243850A1 | United States of America | A1 | |
| JP2004357016A | Japan | A | |
| JP4054719B2 | Japan | B2 | |
| US7530100B2This record | United States of America | B2 |
53 transactions on the USPTO file
Allowed after 2 non-final rejections, 2 final rejections and 2 RCEs.
- Non-final rejections
- 2
- Final rejections
- 2
- RCEs
- 2
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 12th Year, Large EntityM1553 | M1553 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Mail Advisory Action (PTOL - 303)MCTAV | MCTAV | |
| Advisory Action (PTOL-303)CTAV | CTAV | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Correspondence Address ChangeC.ADB | C.ADB | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Request for Foreign Priority (Priority Papers May Be Included)RQPR | RQPR | |
| Application Return from OIPEWROIPE | WROIPE | |
| Application Return TO OIPEROIPE | ROIPE | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
6 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Fee paymentFPAY | FPAY | |
| Fee paymentFPAY | FPAY | |
| Fee payment procedurePAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS |
Numbers
- Publication
- 7530100
- Application
- 10799215
Titles
- English
- Apparatus for limiting use of particular network address
Patent term adjustment
- A delay
- +755 daysthe office missed an examination deadline
- Net adjustment
- 755 days
Classification
- CPC, 1
- H04L45/00
- IPC, 4
- G06F9 00
- G06F17 00
- H04L12 28
- H04L45 00