| Title of Invention | COMMUNICATION MODEL, SIGNAL, METHOD, AND DEVICE FOR CONFIRMING REACHABILITY IN NETWORK WHERE HOST REACHABILITY IS ACCOMPLISHED BY RELATING STATIC IDENTIFIER TO DYNAMIC ADDRESS |
|---|---|
| Abstract | In a network where host reachability is accomplished by relating a static identifier to a dynamic address, the live/death of a communication node and reachability are confirmed by using a sign and countersign. |
| Full Text | FORM 2 THE PATENT ACT 1970 (39 of 1970) & The Patents Rules, 2003 PROVISIONAL/COMPLETE SPECIFICATION (See section 10 and rule 13) 1. COMMUNICATION MODEL, SIGNAL, METHOD, AND DEVICE FOR CONFIRMING REACHABILITY IN NETWORK WHERE HOST REACHABILITY IS ACCOMPLISHED BY RELATING STATIC IDENTIFIER TO DYNAMIC ADDRESS 2. (A) FUKUSHIMA, Hajime (B) JAPAN (C) 2-62-3, Nogata Nakano-ku, Tokyo 165-0027, Japan. The following specification particularly describes the invention and the manner in which it is to be performed. The present invention is related to a communication model, signal, method, and device to solve inadequacies in the process of discovering the destination terminal in a store-and-forward communication network. Specifically, reachability to the destination terminal is provided to the originator by translating a static identifier to a dynamically assigned network address; a clear distinction is made between the case when the originator has wrong reachability to the destination terminal and the case when the originator has correct reachability to the destination,terminal. [Background Art] (Patent document 1) Patent National Publication 2001-519607 or W099/18515 (Intel Corporation, USA): Method and device for translating a static identifier to a dynamically assigned network address (Patent document 2) Patent Kokai 2001-135301 (NTT): IP address information notification method, IP address information notification device, and storage media storing this program (Patent document 3) Patent Kokai 2002-318737 (Index): Management server (Patent document 4) Patent Kokai 2002-281032 (Toshiba): Monitoring target switching program/method, and monitoring system (Patent document 5) Patent Kokai H7-200502 (Omron): Redundant device for transaction processing system S_, The Internet consists of many computers and many networks of computers* ("network" hereafter). These computers are interconnected on a global scale via communication links using TCP/IP protocols. The interconnected computers exchanges information using various services such as e-mail, Gopher, and the World Wide Web / (WWW). J A host on the Internet is identified using a unique IP address assigned by an organization tasked with assigning network addresses. The IP address is represented as fixed-length numbers for easy processing by computers; the long numeric IP address is difficult for people to remember without making input errors. An IP address is needed at a minimum to identify a host on a TCP/IP network but identifying a host using a numeric IP address is difficult for people; to solve this problem, hosts are identified using the domain name system ("DNS" hereafter). DNS is not based on numbers like the IP address; instead it uses a meaningful character string supplied by a database system to identify hosts on the Internet. DNS configures hierarchical name spaces where a character string called domain name is registered and a host on the Internet is identified by associating the domain name with an IP address. This is called forward name resolution. Meanwhile, 2 searching for a domain name from the IP address is called reverse name resolution. A feature of DNS is a tree-structured distributed database with the root server placed at the top. The IP address is subjected to routing restrictions (the IP address is position information in the IP address system), but a name in DNS can exist irrespective of the position of the host on a network. Generally, each user organization connected to the Internet permanently and assigned IP addresses registers domain names via a domain name registration organization which operates the domain names for the user organization. The domain operation server is called a DNS server. To register a DNS server, an IP address and a host name are specified via the domain name registration organization. The root server transfers domain operation authority to the first-level DNS server, which in turn transfers domain operation authority to the second-level DNS server, and finally the DNS server at the immediately preceding level transfers domain operation authority to the DNS server for the said user organization assigned IP addresses. Fig. 17 shows the DNS search sequence. The DNS server for each user-organization-assigned IP address performs actual setting, such as association of host name and IP address with domain name and specification of the mail routing. With a conventional DNS, the setting file is set and updated manually. However, it has recently become difficult to statically associate a single host name and a single IP address with each other, because the IP addresses of PCs on in-house LANs change each time Windows (registered trademark) is restarted, due to popularization of the dynamic host configuration protocol (DHCP). Dynamic DNS provides a mechanism by which the DNS server"s records are updated automatically by ah update request from a client. The practicality of dynamic DNS is presently being verified both in networks not directly connected to the Internet, such as in-house LANs, but also in the Internet"s global services. When dynamic DNS is used in the Internet"s global services, it is possible to provide Internet services at a (dial-up) host not assigned a network by the network assignment organization or not assigned a permanent assigned IP address by a provider. Conventionally, dial-up connection involves the act of making a call to connect to the Internet, but recently, the dial-up connection does not necessarily require making a call because of widespread use of access lines (such as cable TV, digital subscriber lines, optical fibers, satellite links) using a fixed IP connection called permanent" connection. This means that accounting based on connected hours is no longer prevalent. However-, permanent connection is different from connection using leased lines because the IP address may change when reconnecting after the connection is disconnected due to faults such as router power failure, line fault, etc., or maintenance, or line disconnection by provider br timeout at dial-up host. Also, the IP address may change when a mobile terminal moves (handover) through wireless base stations. For convenience, this is also called dial-up because the terminal IP address changes. By comparing connection made by assignment of a permanent network by a 3 network-assignment organization (typically using conventional leased lines) with connection made by assignment of a permanent IP address by a provider (or by each user organization assigned IP addresses), the present invention calls making a connection by being assigned a ■ -IP address by a provider (or by each user-organization- assigned IP address) (including connection made via DHCP or PPPoE not involving calling through a modem) a "dial-up connection". The assignment of a transient IP address is called "perform transient connection" and the transient IP address assignment itself is called "dial-up". Problem peculiar to dynamic DNS Known DNS technology cannot enable a host with a changing IP address to provide Internet services, but dynamic DNS enables hosts to provide limited Internet services. (Global DNS is excluded because it needs a fixed IP address). However, dynamic DNS has a unique problem explained in Figs. 1-12. Fig. 1. The management target equipment ("T" hereafter) (4100) dials up the provider ("P" hereafter) (4000) (including dial-up via PPPoE, etc.) Fig. 2. T (4100) is dynamically assigned an IP address (e.g. 172.16.100.100) by P (4000). Fig. 3. T (4100) requests the dynamic DNS server ("D" hereafter) (1000) to update the DNS. Then, D (1000) associates the IP address (172.16.100.100) assigned to T (4100) with the host name of T (4100) and sets. Fig. 4. T (4100) can accept access requests from general Internet users ("S-2" hereafter) (5300) (normal state). Fig. 5. Some failure occurs causing connection loss from T (4100) to P (4000). Fig. 6. Reconnection is made from T (4100) to P (4000) (including reconnection via PPPoE, etc.). Fig. 7. T (4100) is assigned dynamically a new IP address (172.16.200.10) by P (4000). A different IP address than assigned until an IP address change has occurred, is assigned. Fig. 8. T (4100) issues an update request to D (1000). Then, D (1000) sets the IP address (172.16.200.10) assigned to T (4100) and the host name of T (4100). Fig. 9. In Fig. 7, now T (4100) is assigned a different IP address (172.16.200.10) from the previously assigned IP address (172.16.100.100) which is re-assigned to another user T ("T" hereafter) (4200) at the same provider. In this case, viewed from S-2 (5300), the host seems to have been switched. Fig. 10. On the Internet, referenced DNS cannot be to D (1000); it is the provider"s DNS server (such as 4500 or 5500) connected directly to each user. Consequently, even if D (1000) is updated correctly, name query is not performed from the provider"s DNS server (such as 4500 or 5500) connected directly to each user to D (1000) within the cache TTL, so some time is required for the IP address (172.16.200.10) of T (4100) to be reflected at these DNS servers. The DNS server (such as 4500 or 5500) stores queried resource records locally for some period. This storage is called cache. The resource record in cache is only stored for the specified TTL (time to live) period and is discarded when this period has elapsed. This period is called the cache TTL. During the cache TTL, the DNS server (such as 4500 or 5500) performs name resolution in response to queries from the resolver (such as 4100 or 4200, or 5300) by referencing the local cache storage. This cache method was devised to improve efficiency by suppressing repeated name queries. However, D (1000) suffers from an inadequacy, because the cache cannot follow changes in the IP address of T (4100) as explained below. Fig. 16 shows how DNS is searched for from S-2 (5300) to reach the target host, T (4100). (1): A forward name query for T (4100) is performed from S-2 (5300) to P-2 DNS ("P-2-D" hereafter) (5500). (2): First, P-2-D (5500) checks whether it "knows" the target domain name; if it does, it immediately returns the IP address of T (4100)—the target host—to S-2 (5300). When P-2-D (5500) "knows" the target domain name, there are cases in which name is being managed by P-2-D (5500) and the IP address of T (4100), the target host, is cached in P-2-D (5500). Fig. 17 shows the case when P-2-D (5500) does not "know" the target domain name. (3): In step (2) above, S-2 (5300) could determine the IP address of T (4100). S-2 (5300) accesses T (4100) using this IP address. Fig. 17 shows the DNS search sequence when P-2-D (5500) is not managing the domain for T (4100) and when P-2-D (5500) has no IP address cache (at first name query) (step (2) in Fig. 16). (1): A forward name query for T (4100) is performed from S-2 (5300) to P-2-D (5500). (2): P-2-D (5500) performs a name query to the root DNS when it is not managing the domain for T (4100)—the target domain name—and also cannot find the IP address in cache. (3): The root DNS returns the location of the JP DNS, for example, when the domain name of T (4100) is a JP domain. (If the domain name of T (4100) is not a JP domain, the root DNS returns the location of a name server managing ccTLD or gTLD to P-2-D (5500).) (4): P-2-D (5500) performs a name query for the domain name of T (4100)—the target 5 domain name—to the JP domain DNS obtained in step (3) above. (5): The JP domain DNS returns the location of the server (here D (1000)) managing the domain name of T (4100)—the target host—to P-2-D (5500). (The said location is returned immediately because domains under JP are tree-structure registered at JPNIC and member servers, and are not divided for second-level DNS.) (6): P-2-D (5500) performs a forward name query for the IP address to D (1000) obtained in step (5), using the name of T (4100) as the key. (7): D (1000) returns the location of T (4100) to P-2-D (5500). (8): P-2-D (5500) returns the location of T (4100) obtained in step (7) to S-2 (5300). (9): S-2 (5300) accesses T (4100). Fig. 18. Setting is generally performed so that the DNS (such as 4500 or 5500) is cached by the first name query, and then when the cache TTL has elapsed, the cache is invalidated. The correct IP address of T (4100) is obtained when the cache is invalid (Fig. 17) and name query is performed to D (1000). However, when the IP address of T (4100) changes while the cache is valid (Fig. 16), the IP address cached without performing name query to D (1000) is returned. In other words, the returned IP address (cached) is the address before the update shown in Fig. 18 is performed (172.16.100.100). As described in step (2) in Fig. 16, no cache problem occurs when P-2-D (5500) connected to S-2 (5300) is operating the T (4100) domain. Fig. 11. Consequently, seen from the Internet, T" (4200) can be misidentified as T (4100) when the cache is referenced. Also at this time, even when T (4100) is a host with mail or www server functions, T (4200) is a host in which no mail server or www server is set (or even if T" (4200) is a host in which it is set), the setting for T (4200) is different from that for T (4100), so T (4100) seems abnormal state (failure state). Fig. 12. This problem is solved when the DNS server (such as 4500 or 5500) of each provider on the Internet performs name query to D (1000) again when the cache TTL has elapsed. Consequently, a normal state occurs as time passes as shown in Fig. 12. Next, Figs. 1 - 5 and Figs. 13-14 show the case when T (4100) does not reconnect (remains disconnected). As with the normal case, it returns to the normal state overtime (Figs. 1 -12). Possible reasons for this problem include line or program failure (performing transient connection or dynamic DNS update). Explanation given in Figs. 1 - 5 are the same as the one given earlier. (Skip Figs. 6 -12 as explanation given in them is on cache problem.) Fig. 13: At this time, T (4100) is not connected to the Internet, so P (4000) 6 assigns the IP address (for example, 172.16.100.100 ) that has been assigned to T (4100) until an IP address change has occurred, to T" (4200) when T" (4200) performs transient connection. Fig. 14. Update cannot be performed for the IP address of T (4100) set to D (1000), so the IP address (for example, 172.16.100.100) of T (4100) before T (4100) was disconnected remains set. Consequently, in this case, T" (4200) is also misidentified as T(4100). Incidentally, line disconnection is a detectable event at T (4100) and, at the same time, is also a change in the external environment. Table 01 below shows the patterns of failure that occurs at T (4100) from relationship between its state and its assigned IP address. Table 01 State of IP address IP address before line disconnection * IP address after reconnection IP address before line disconnection = IP address after reconnection State of T (4100) When no hosts using IP address assigned to T before line disconnection When another host using IP address assigned to T before line disconnection IP address assigned to T before line disconnection re-assigned to T Line remains disconnected (pattern 1) Not accessible Misidentification (Fig. 14) - Failure to perform dynamic update to DNS (pattern 2) Not accessible Misidentification OK Reconnection after line disconnection (pattern 3) Within cache TTL Not accessible Misidentification (Fig. 11) OK No cashing performed OK OK (Fig. 12) Pattern 1 shows when the line remains disconnected. When T (4100) cannot make reconnection after line disconnection, misidentification occurs when the IP address assigned to T (4100) before line disconnection occurs is assigned to T" (4200). When the IP address is not assigned to any host, T (4100) is not accessible. Not accessible means the state in which T (4100)—the target host—is lost sight of and cannot be reached. When line remains disconnected, T (4100) naturally cannot perform re-update to DNS servers (such as 4500 or 5500). Pattern 2 shows the failure to perform dynamic update to DNS caused by program failure for dynamic update to T (4100) or by failure at D (1000). In this case, the line is either assumed to be connected, or to be reconnected if disconnected. In pattern 2, misidentification occurs when the IP address assigned to T (4100) before line disconnection is assigned to T" (4200) as with pattern 1, in which T (4100) cannot make reconnection after line disconnection and remains disconnected.) T (4100) is not 7 accessible when the IP address is not assigned to any host. When the assigned IP address does not change, there is no problem with communication from S-2 (5300), so T (4100) seems to be in the normal state. Pattern 3 shows the case when the line is reconnected after being disconnected. The shaded part is affected by the cache TTL; other parts show the case when name query is performed correctly because caching is not performed. S-2 (5300) accessing T (4100) is a general Internet user. Whether or not a case is included in the shaded part depends on whether or not S-2 (5300) has previously performed name referencing, and if so, whether or not it was performed while caching is being performed. The shaded part in Table 01 shows that although T (4100) operates correctly (T (4100) reconnects after line disconnection, and updating to D (1000) is performed correctly), T (4100) seems to be in a temporary failure state.because a DNS server (such as 4500 or 5500) is caching the IP address of T (4100). The above explanation shows that D (1000) has an inadequacy where the cache mechanism cannot follow changes in the IP address of T (4100). This occurs because the dynamic DNS mechanism is an extension of conventional DNS. As described earlier, conventional DNS was set and updated manually. The above explanation shows that when D (1000) is used and T (4100) performs updating to D (1000) at short intervals, sometimes the IP address of T (4100) obtained by performing (normal) referencing to D (1000) is incorrect. S-2 (5300) always misidentifies T (4200) as T (4100) when T (4100) line disconnection intervals and T (4100) IP address update intervals are too short compared to the timing of name query to D (1000) after the cache TTL is exceeded. In such a case, which can also be caused by an unstable line, DNS should function, but D (1000) cannot function in this case, causing what appears to be a failure state. This problem is a DNS problem for the entire Internet that cannot be solved by individual implementations (at individual hosts). Actual example of cache problem An actual example of a cache problem is explained below. Figs. 19-21 show an actual example in which the T (4100) IP address obtained by referencing the cached DNS (measurement made at 4500) during the cache TTL and the T (4100) IP address obtained by performing forward name resolution directly to D (1000) are different. Fig. 19 shows the program used at actual measurement. The program is a UNIX shell script. The arrow (->) at the line end indicates that the line is returned for only display convenience; the actual line continues. Figs. 20 - 21 show the measurement results. At each trial, the first line indicates trial number, the second line indicates trial time, the third line indicates the T (4100) IP address (a, c, e) extracted by performing string processing for the result 8 obtained by referencing D (1000) using the dig command of the ISC BIND, which is standard implementation for DNS, and the fourth to sixth lines indicate the T (4100) IP address (b, d, f) obtained by referencing the P DNS server, cached DNS ("P-D" hereafter) (4500) using the ping command. (Note: P-D (4500) is the DNS server usually referenced by T (4100). Here, the test is conducted at T (4100), so P-D (4500) is referenced, but when conducting the test at S-2 (5300), P-2-D (5500) should be referenced. The DNS referenced at each terminal is determined by the resolver.) The seventh to tenth lines indicate the ping command incidental output. The DNS server D (1000) used in the trial is DynDNS.org, which already hosts dynamic DNS. At the trial, the server cache TTL is 1 minute, a quite short time. An update request is sent from T (4100) concurrent with the first trial, and the update is completed between the first and second trials. Consequently, from the second trial, the dig command"s output (T (4100) IP address indicated by D (1000)) and the ping command"s output (P-D (4500) is referenced at this test but P-D (4500) is affected by the cache TTL) indicate different IP address respectively ("underlined part a = underlined part b" is changed to "underlined part c t underlined part d"). This problem is solved ("underlined part e = underlined part f) at trial 16 performed just 1 minute after the second trial. As described, cache TTL affects the referenced DNS server, causing address disagreement. However, the problem is solved as times passes. The cache TTL at D (1000) is short (1 minute), but address disagreement occurs nevertheless. Common misunderstanding This problem is unique to dynamic DNS, but is generally not well known and even some patent applications contain misunderstandings. For example, paragraph 0047 in patent document 3 says "reply to nslookup becomes abnormal." However, this is not true for two reasons: 1. because the reply to nslookup is not an error. (Patent document 3 shows no grounds for being able to determine that the reply is abnormal although it is not an error.) 2, the data that DNS returns in response to the nslookup query is the final updated IP address even if it is assumed that T (4100) is lost (or that the data is being used by T (4200)). (The IP address may be a cached address or depend on the queried DNS. server. Either case is a problem.) In this case, it cannot be simply determined that the reply is abnormal; such a determination requires application-wise comparative judgment. In other words, to detect that the IP address returned by DNS is abnormal, reachability confirmation must be performed to determine whether the IP address pointed at by DNS is used by T (4100) itself or by a host other than T (4100), such as by T (4200). The same applies to the case when explicit offline processing is performed by T (4100). This case has the effect of causing T" (4200) to not appear. However, because the nslookup reply is not an error, this case requires application-wise 9 comparative judgment about the set IP address. Also, note that generally no offline processing is performed at failure (including line failure) at T (4100). Assuming that S-2 (5300) or management server (S-1 hereafter) (2000) stores the previous IP address of T (4100), the IP address is known to be updated by comparing the previous IP address and the IP address returned as the nslookup reply. However, it cannot be determined whether or not the updated IP address reflects the current state for the reason described in reason 2. In other words, this case is also affected by the cache problem; when T (4100) cannot perform update processing for D (1000) (for example, when line disconnection continues or a failure occurs in the update program), the value returned by D (1000) as the IP address of T (4100) is unreliable. In other words, an IP address no longer used by T (4100) might be returned. However, patent document 3 also seems to state that T (4100) itself compares the reply to nslookup with the IP address of the own host (T (4100) (distribution server 3 in patent document 3). In this case, it is possible to determine that the nslookup reply is abnormal, because T (4100) simply compares the own host IP address and the nslookup result. (However, this compare operation is only possible for connection configurations 1 to 3 described later). However, hosts other than distribution server 3 cannot determine whether or not the reply is abnormal. In other words, only distribution server 3 can determine this. However, it is obvious that T (4100) corresponding to distribution server 3 can determine its own IP address. The object of the present invention is to make it possible for S-2 (5300) to confirm whether the originator reaches T (4100) correctly. It is considered better for distribution server 3 to send an IP address update request to the dynamic DNS server using a change in the IP address assigned to itself as a trigger, than to perform nslookup. Moreover, paragraph 0048 in patent document 3 says "for example, the reply to ICMP (Internet Control Message Protocol) is lost". However, the reply cannot be said to be lost; in this case, the reply is undefined. ICMP is considered to be an ICMP echo request. It is derived from the command implementation, usually called ping. Timing problem: When, for example, P (4000) receives a connection request from a host other than T (4100) immediately after T (4100) enters the line disconnection state, there is a high probability that the IP address assigned to T (4100) until just before is assigned to that terminal. Then, T (4200) appears and the ping command shows that T (4100) is alive. Consequently, a reply may be returned. For example, when the trial count is 2 (Fig. 20 shows an example of the cache problem) note that the values c and d in Fig. 20 are different. During the time from trial count 1 and trial count 2, T (4100) changes from the normal state shown in Fig. 4 to the disconnection state shown in Fig. 5 and then makes reconnection to go into the state shown in Fig. 8. When the another user shown in Fig. 9 dials up, T (4200) appears, because T (4100) is switched to T (4200) and forward 10 name resolution to the DNS server shows no change in IP address. Naturally, "a ping reply is returned" from T" (4200). If the timing matches, a ping reply will be passed continuously to T (4200). Moreover, "a ping reply is returned" does not mean that T (4100) (distribution server 3 in patent document 3) is in a normal state. In this case, since DNS is updated when T (4100) returns to the normal state, the problem is soon solved, even considering the cache problem. However, the biggest problem is that T (4100) remains in the state shown in Fig. 5, and cannot change to the states shown in Fig. 6 or later (meaning that a failure occurs). Unlike the cache problem, once T (4200) of another users appears, (Figs. 13 and 14), T (4100) continues to appear to be in the normal state, receiving the ping reply from T (4200). Therefore, even if it is assumed that the size of a moving object shot by a video camera is recognized, machine cannot identify whether the object is a dog, a child, or a ball. But the"human viewer can identify the image (the moving object) as soon as he/she. Similarly, nslookup or ping cannot solve this problem, and the state is regarded as normal (patent document 3 says this state is abnormal). Specifically, if a webpage for Mr. B is displayed when someone visits the webpage for Mr. A, the human viewer immediately recognizes this as an error, but the DNS servers and other machines cannot. Consequently, without confirming reachablity, machines cannot distinguich between T(4100) having correct reachability and T"(4200) that is a host misidentified as T(4100). Therefore, a host that is transiently assigned a dynamic IP address has a problem of appearing to be in the failure state even if the host is operating correctly, so identification of the other communication end (from where a call should originate), which seems to have been completed with the advent of dynamic DNS, is inadequate. Summary of problem unique to dynamic DNS The problem peculiar to dynamic DNS are summarized here. Summary 1. D (1000) continues announcing the final updated resource record even after T (4100) has ceased to be connected. If T (4100) performs explicit offline processing, D (1000) will never continue announcing information on T (4100) that does not exist. However, when T (4100) is faulty or the line is disconnected, it cannot perform offline processing. Summary 2. When the IP address of T (4100) changes, misidentification occurs during the cache TTL. Scope of extended related art We have discussed the inadequacy of dynamic DNS for discovering the 11 destination terminal. However, a similar problem also occurs in systems other than dynamic DNS. Examples are described in patent document 1, patent document 2, and ENUM. ENUM is an extension of dynamic DNS that maps the telephone number system in the conventional telephone network (PSTN) onto DNS. Patent document 1 adds the concept of user location server, but can be considered to be similar to ENUM. Patent document 2 proposes a specific mapping notification system for a static identifier and dynamic assigned address that locate hosts (DNS is not used). As stated in said summary 1, since misidentification occurs because "D (1000) continues announcing the final updated resource record even after T (4100) is no longer connected", patent documents 1 and 2 disclose a specific method to solve the problem. In patent document 1, the fact that a terminal is alive is notified by sending a keep-alive signal to DNS from the terminal. In patent document 2, a health check is performed from the equivalent of DNS to the equivalent of T to detect the state that the equivalent of T is not connected occurs. In both cases, when a destination terminal is not on the network, the appropriate record in the mapping notification system is deleted so the originator terminal never discovers the destination terminal. However, in both cases, the correctness of reachability from third-party terminal S to T (4100) is not verified (end-to-end accessibility is not verified). [Problems to be solved by the Invention] Even when S-2 (5300) recognizes a host as T (4100), the actual host could be some other host. The present invention provides a means to confirm that the host recognized as T (4100) is actually T. In other words, that the originator reaches destination terminal T (4100) correctly and not T (4200). In addition, the invention proposes how to use the result of the said reachability confirmation. [Effect of the Invention] Usually, the ping command can be used to monitor whether a host that is assigned a fixed IP address on a TCP/IP network is alive or dead. However, the IP address of a dial-up host changes, so if another host (other than T (4100)) replies to ping command, the ping command appears to determine that T (4100) is operating normally. The present invention checks that T (4100) is a host with the correct reachability, making it possible to manage a host with a changing IP address, something that has not been possible previously. Conventionally, normal management has also not been supported previously for hosts with changing IP addresses, but the present invention permits normal and more advanced management (such as CPU load and traffic monitoring). 12 [Overview] The following method confirms that the originator reaches the other communication end recognized as T (4100), correctly. The result of communication from S-1 (2000) to T (4100) is used by S-1 (2000) to determine whether or not T (4100) is a host with correct reachability. The method consists of two steps (external inter-host communication) as follows: The first step is address verification, and the second step is sign and countersign. Fig. 23 shows the operation performed when S-1 (2000) performs reachability confirmation of T (4100) in the first and second steps. Address verification forms one of a pair of parameters needed for reachability confirmation (see communication mode described later). At S202, forward name query is performed from S-1 (2000) to D (1000) to avoid the problem of cache TTL. At S204, the IP address of T (4100) is obtained from the reply from S202. Verification of the IP address of T (4100) can be omitted when S-1 (2000) and D (1000) are the same host, the resolver at S-1 (2000) is set to D (1000), and TTL (cache Time-To-Live) of D (1000) is quite short. D (1000) may be redundant, but it is OK to consider a redundant group as equal to a single server here. The second step is sign and countersign. Since address verification may be omitted, this step is also narrowly defined as reachability confirmation. When the IP address of T (4100) is obtained at S202 and S204, it is unclear whether the T (4100) recognition is actually correct T (4100). When line disconnection occurs between T (4100) and P (4000) or when T (4100) cannot perform an update to D (1000), the reachability of a host thought to be T (4100) can only be found through the reachability confirmation process. Moreover, when the service at T (4100) is known in advance but that service cannot be accessed correctly, it cannot be concluded that this is caused by cache and it cannot be determined that T (4100) is disconnected from the network, because, for example, even when T (4100) is connected to D (1000) correctly, updating to D (1000) is being performed correctly, and there is no cache problem, a failure can occur in the program providing service. From the network administration viewpoint, we need to determine whether T (4100) has an interface failure, network failure (basic failure) such as a line disconnection, or a service failure (application-level failure). When troubleshooting a network failure, it is customary to start at the lower layer by attempting to communicate with the host thought to be T (4100) and to use the result to determine whether or not T (4100) is actually the correct T (4100). (For details, 13 see the later design concept. Here we just want to confirm whether or not the originator can reach the interface of T (4100).) Communication is performed at S206 using the previously agreed method from S-1 (2000) to the IP address of T (4100) obtained from the result of address verification (S202 and S204). (This communication is called a "sign.") S208 determines whether or not there is a reply from S206. (The reply is called the "reply that should be made," and carrying the reply is called "countersign.") If present, the reply is passed to S210; if the reply is not present, processing passes to S216 which displays that T (4100) has been lost sight of. S210 receives the reply from S206 and performs string processing to obtain a string with an unnecessary string removed. S212 performs comparison between the character string extracted at S208 and the reply that should be made from T (4100) responding to the communication using the previously agreed method stored at S-1 (2000). The reply that T(4100) should make and the reply that S-1 (2000) should receive are the same. When the extracted character string matches the reply that ought to be made in response, T (4100) is determined to have correct reachability. When they do not match, it is determined, independently of the problem of cache TTL, either that T (4100) is not connected to the Internet, or that updating to the DNS server on the Center side cannot be made for some reason. The comparison result is displayed. Determination at S212 shows either that T (4100) is operating correctly and has correct reachability (S214), or that T (4100) is in a failure state (S216). The response to the comparison should be based on the contract between the person responsible for T (4100) and the person confirming reachability, so the result is just displayed here. When T (4100) is operating correctly and reachability is correct (S214), normal monitoring, such as traffic monitoring, can be performed as subsequent processing for hosts with changing IP address that cannot be monitored conventionally. Generally, in the case of S214, it is best to write a message indicating that T (4100) is normal state to the log. When S216 (T (4100)) is not normal, notification processing, such as issuing an alert is performed. For S216, when the timing at which S executes the process shown in Fig. 23 overlaps the timing of updating to D (1000) by T (4100), there may be a delay in reflecting the update at D (1000). Based on this, this process should be performed again after a short interval and if failure is still detected, either an alert is issued, or a decision is made about which alerts are issued to whom. Essence of countersign Next, "reachability confirmation" is described. For example, a person viewing a webpage published at T (4100) can easily identify whether the page belongs to Mr. A or Mr. B. If B"s webpage at T" (4200) is displayed when visiting A"s webpage at T (4100), the reachability is incorrect. (The same is true if a timeout error occurs.) If A"s 14 webpage is displayed when visiting A"s webpage, the other end has correct reachability. A person can make this judgment instantly but, as described earlier, a computer cannot. Reachability confirmation enables machines (= communication nodes) to make such identification. The result of reachability confirmation is expressed as true or false. When the result is true, the host has correct reachability. The host is also expressed as a true host. When the result is false, the host does not have correct reachability. Here, suppose that T (4100) is assigned a permanent assigned IP address. 1. As described above, a person can identify the host visually. If a person cannot identify the host, he/she checks to identify the host, roughly as follows: 2. The nslookup and ping commands can also identify the host. 3. The host itself gives its identity. However, "The host itself gives its identity" means that the host identifies itself via a communication service program ("daemon" hereafter). Conventionally, the other communication end takes no special action after listening to the identification reply. For example, special action here means determining whether to allow or reject the connection. 4. If an account is provided, password authentication can also be used. Turning to the case where T (4100) is a dial-up host, which is the premise of the present invention. Item 1 above is not considered here, because reachability confirmation aims at enabling machines to make the said identification. With nslookup and ping described in item 2, it is not known whether or not the other communication end is truly correct. Item 4 is a server account problem. The present invention does not assume that there is an account at the other communication end (or host). So, authentication assuming that an account is provided is not discussed here. With respect to item 3. The daemon is a resident process to open a communication port, wait for it to be connected, and give the host, program, and version names. So, item 3 can be used. When T (4100) has a permanent assigned IP address, the daemon is executed naturally at start of communication. (However, conventionally, it is not determined whether or not to perform communication using the given information) The daemon gives the said information in response to access to the host name; this simply means giving identification information about itself. This is not included in the authentication concept. Moreover, When simply gives its identity, can confirm reachability. In other words, reachability confirmation means: 15 The host is asked "Who are you?" as a sign. "I am so-and-so" is answered as the reply. Consequently, the essence of countersign is to act as a carrier giving identification information about itself that should be naturally given and sign is an arrangement specifying how to ask T (4100) to give its identity. Next, we explain the unfamiliar new network characteristics until dynamic DNS or association of static identifier and dynamically assigned network address becomes common. Unidirectionality in association of static identifier and dynamically assigned network address Generally, only forward name resolution can be used at D (1000). When reverse name resolution is used, the host name that should be dynamically updated is not returned to the IP address. So, what is returned? Generally, the host name set by the network operator operating the network containing the relevant address block (including CIDR block) assigned to the IP address is returned. This expression is difficult to understand. A typical example is the host name of an Internet Service Provider (ISP); the ISP is a form of P (4000)). An example is given below. Forward name resolution: host.customer.co.jp-> 192.168.0.99 Reverse name resolution: 192.168.0.99 -> ppp000099.otemachi.provider.com Forward name resolution: ppp000099.otemachi.provider.com -> 192.168.0.99 As can be seen, host. customer .co.jp is isolated. In other words, when ppp000099 . otemachi .provider . com IS a misidentified host, ppp000099. otemachi. provider. com cannot know the host name "host. customer. co. jp". host. customer .co.jp is the host name that T (4100) performs updating to D (1000), and 192.168.0.99 is the IP address assigned to T (4100) at that time, and ppp000099. otemachi .provider. com is the host name obtained by performing reverse name resolution for the said IP address; the host name is given by the ISP. The reason for this phenomenon is described below. Non-isolation ofhost.customer.co.jp goes against a prerequisite of DNS delegation that disallows setting of reverse name resolution for networks managed by other people (other organizations) (RFC2050, 2317, 3152). For example, when a network that D (1000) belongs and a network that P (4000) belongs to are managed by different organizations, D (1000) cannot set reverse name resolution for P (4000). However, host.customer.co.jp is widely announced by the owner of T (4100) to accept access from S-2 (5300). That is, host "host. customer. co. jp" cannot be known for reverse name resolution although it is a widely known keyword used when performing forward name 16 resolution. When T" (4200) receives a sign, it cannot know what host name is specified as the destination by the originator, due to the network characteristic that host reachability is obtained by associating a static identifier and dynamically assigned network address with each other. Impersonation However, this does not apply in some cases. For example, when the destination port is HTTP, naturally the host name is not included at session establishment, but the destination host name (which the web surfer wishes to see) may be included in the subsequent GET statement. In such a case, when implementing a program that extracts the host name included in the GET statement and thereafter and returns it as is in a host that might be misidentified, the reply that should be made and the countersign to carry it can be impersonated. This is a passive attack. Effect range of impersonation However, this is not realistic because when an impersonation attempt is made, the impersonation must wait for access to the misidentified host T" (4200), and even if such an impersonation succeeds, when the IP address assigned to T (4100) changes, the impersonation can no longer follow the change. Consequently, impersonation is established only for the period while the IP address assigned to T (4100) does not change. Therefore, there is very little effect unless update processing to D (1000) is taken over. (Even if impersonation can be made, it does not last long.) That is, impersonation can be made completely and without causing misidentification only when update processing is taken over. However, this case is no longer impersonation and countersign is not relevant to the password used at updating. Consequently, update processing to D (1000) must be guarded. Impersonation is made in the following case: First, misidentification must occur; impersonation cannot be made unless the host T (4200) is a misidentified host. Upon receiving a sign, the misidentified host T" (4200) performed impersonation by returning a countersign carrying the "reply that should be made" giving T"s identity. Now, as with T (4100), T (4200) is assigned an IP address by P (4000). Moreover, as with T (4100), the IP address of T" (4200) could change. From this, we can say the following: As with T (4100), T (4200) belongs to the address range under P (4000). In other words, the range where misidentification could occur is limited in advance by the IP address range, of P (4000). However, the limitation is determined by the network state 17 and is not man-made limitation. As with T (4100), T" (4200) cannot continue using the IP address assigned to it transiently by P (4000). Consequently, even if T" (4200) makes a successful impersonation, it cannot remain impersonated for long. Impersonation is established in the following case: Basically, impersonation is only possible when T (4100) enters a failure state excluding the cache problem. Moreover, impersonation is established during the following periods: Period while IP address of T" (4200) does not change Period from when T (4100) returns to normal state until update performed again From the above, impersonation is possible, but its effect range is assumed to be permissible. However, a sign, such as "Who are you?" that simply prompts the other communication end to reply is recommended; a sign, such as "Are you so-and-so?" is not recommended because it causes a situation facilitating impersonation. The said "so-and-so" is assumed to be a specific name, etc. Effect of independent reachability confirmation A comparison is made between reachability confirmation and update takeover. From the above, we can say that reachability confirmation need not be guarded. Reachability confirmation and update are independent processes with no direct relationship. Moreover, reachability confirmation is not something like an account password. This is the effect of independent reachability confirmation. (Theory) 1. Communication model List of characters First, values with special meaning in the present invention are shown below. A: Dynamically assigned network address (= network address) Value used by network; and address controlling actual reachability to terminal Assigned transiently by P B: Static identifier Value used by man; and identifier to locate destination terminal Next, functions are shown below. D: Mapping notification system When the originator attempts to start communication, the system provides reachability to the destination terminal, to the originator by associating the 18 destination terminal"s static identifier and dynamically assigned network address. Notifies a pair of A and B, on behalf of T T: Destination terminal Destination terminal in this model Sets a pair of A and B associated, for D Need not be computer; only need be communication node S: Originator terminal Terminal to confirm correctness of reachability to T, with T being destination Verifies correctness of reachability for T Need not be computer; only need be communication node P: Function to assign A, transient address, to T Generally, P is a network or a specific server. Network itself containing T, from viewpoint of telephone company (For example, at a telephone company, DCE is viewed as the clock sending side; DTE is the clock receiving side. That is, the clock is received from the network itself. Accordingly, for example, at the ISP providing Internet service, the IP address is assumed to be assigned by the ISP"s network, not by the network access server (e.g. Livingston Portmaster and Ascend MAX) or RADIUS server.) From the LAN viewpoint, the IP address is assumed to be assigned by DHCP server. A pair consisting of A and B is expressed as "a pair of A and B". Real image of pair of A and B At T, B is an identifier to make T itself public. A is an address assigned transiently to T by P. With B alone, network-wise reachability is not obtained from S, a third party viewed from T. With A alone, network-wise reachability is obtained, but since A is an address that T borrows from P and uses transiently that terminals other than T also use, a third party cannot associate T and A. However, B is information notified to indicate T, and at this time, A is the address assigned to T. With this fact, T is assumed to have the pair of A and B entity ("real image" hereafter). Mapped image of pair of A and B D (mapping notification system) is notified by T that A and B are associated, stores the fact, and notifies it to S (third party) of it. Specifically, when D is queried about either A or B, D replies to either A or B that is not queried. From another viewpoint, when either A or B is an input, D is also regarded as a system that outputs the 19 remaining one of the pair. Uniquely, since T cannot make a notification, D makes it on behalf of T. Therefore, a mapped image of the pair of A and B is notified at D. Incidentally, when incorrect reachability is obtained, it is often said that T is wrong and D is correct. However, this is incorrect because S cannot reach T unless the pair of A and B mapped at D reflects the actual situation. The actual situation means the real image of the pair of A and B at T; each element of the pair of A and B cannot be described as correct or wrong individually. S cannot reach T unless the pair of A and B in its entirety reflects the actual situation correctly. In other words, when S does not reach T correctly, it cannot be said that T with a real image of the pair of A and B is correct, nor that D announcing the mapped image of the pair of A and B is wrong; neither can the opposite be said. What is important is that they— the real and mapped images of pair of A and B —match each other, meaning the mapped image of information about T stored by D, and the real image of information consisting of B (held by T) and A (conditions for being accessed at that point which P gives T) match. Hereafter, the terms "real image" and "mapped image" are assumed to be followed by the term "of the pair of A and B". Now, see Fig. 22. Steps (1) to (5) are a process sequence. In step (1), the pair of A and B is mapped from T to D. In steps (2) and (3), the pair of A and B between D and S is checked. In steps (4) and (5), the pair of A and B between T and S is checked. Hereafter, numbers (1) to (5) refer to Fig. 22. What must be emphasized is that unless the mapped image of the pair of A and B at D and the real image of the pair of A and B at T match, the third-party S cannot reach T. This happens because although the real image of the pair of A and B is undoubtedly at T, the third-party S viewed from T or D, cannot reference T directly in the first place, so S references the mapped image of the pair of A and B at D to obtain reachability to T. In other words, T maps the real image only to D, and is never referenced by third-party S because T is a destination as viewed from S, so S references D first in order to discover T and cannot reference T when S cannot discover it. Access from S to T is made possible after S has discovered T. Therefore, it is verified that S, the originator, reaches T, the destination, correctly as follows: Reachability from originator S to destination T is correct when the pair of A and B between D and S (mapped image of the pair of A and B entity), checked at (2) and (3) and the pair of A and B between T and S (real image of entity of pair of A and B), 20 checked at (4) and (5), match. 2. Sequence So how do we determine whether or not the real and mapped images of the pair of A and B match? This requires discussion based on a sequence. The relationship between values A and B is explained using a sequence from Fig. 22. (1) T creates the mapped image of the pair of A and B at D. (2) S performs a query to D using B. (3) D returns A to S in response to the query. (4) S performs a query to T (or a destination that is believed to be T) using A obtained in (3). (5) T returns B to S in response to the query. If the destination that is believed to be T is actually not T, the destination returns an unknown response. When T returns no response, it is assumed that the "no response" response is returned, "no response" is included in unknown response. In other words, this is based on the concept of the existence of a null value. Hereafter, this specification is described based on such a concept. Each step in the sequence is explained. (1) is a process where T maps the real image of pair of A and B to D. As a result, the mapped image of the pair of A and B is created at D. Normally, this requires authentication between T and D so that a third party cannot map a false pair of A and B to an appropriate T. The real image of the pair of A and B can be not only mapped by T but also by a set, such as a device integrated with T (detailed in embodiment 8). The subject to perform mapping may be P (such as a DHCP server, ISP, operator ENUM). (2) and (3) are regarded as a set of procedures. This process is equivalent to so-called name query. At (2), S performs name query to D regarding static identifier B, a well-known keyword, taking advantage of the system whereby when D inputs either A or B, the remaining partner of the pair is output. At (3), in response to (2), D returns A (dynamically assigned network address), the other half of real image of pair of A and B created at (1). Operations at (1) to (3) described above use related art. Operations at (2) and (3) are regarded as a set of natural phenomena (external objects) that should be used. At (4), S prompts T to reply using A (obtained at (3)) that should have reachability to T as the destination. A is used temporarily at (3) and (4), so it need only be assigned. In other words, S need not store A. (However, occasionally it may be best for S to store A as discussed later.) 21 At (5), T returns B, the other half of pair of A and B, to S. When B is returned (that is, the reply that S receives from T), the originator reaches T correctly because B used at the first query at (2) and B returned from (5) are identical. This case is sharply distinguished from the case when T returns an unknown reply in response to the request at (4) (to return something as a response). Then, S can know the mapped image of the pair of A and B at (2) and (3), and the real image of pair of A and B at (4) and (5). After the sequence is completed, S compares between the mapped image of the pair of A and B at (2) and (3) and the real image of the pair of A and B at (4) and (5), to see if they match. The timing is explained below. At (1), the operation to create a mapped image from the real image is an operation unrelated to S, so S cannot know the operation timing. At (2) and (3), the process of obtaining the mapped image of the pair of A and B is the responsibility of S, so it can execute the process at any timing. Similarly, at (4) and (5), the query about the pair of A and B entity is also executed any timing. The process can be executed at the timing required by S or based on the internal timer of S. Moreover, the operation at (4) and (5) need not necessarily immediately succeed (2) and (3). For example, at (second and subsequent) reachability confirmations after reachability is confirmed, the address of T (4100)—the destination of the sign performed at (4)—is stored; normally, steps (2) and (3) are usually omitted but after S becomes unable to reach T (after reachability correctness is no longer confirmed), steps (2) and (3) are re-executed. The relationship between (2) and (3) and between (4) and (5) are the one between request and reply, respectively. (5) is operation, and simultaneously a carrier of B; the relationship between the carrier and B is like the relationship between a bucket and the water it contains. 3. Extension The theory can be extended to comparison of two mapped images. However, note that if D is already made redundant based on the primary-secondary or master-slave model, it is inadequate to make a comparative judgment regarding two mapped images within that redundant group. In this case, only (2) and (3) are tried twice, and their result is compared; normally this is not a comparison. So, normally, comparison of two mapped images is valid when they are separately mapped by T to the irrelevant mapping notification system. In other words, there must be two or more different non-redundant mapping notification systems equivalent to D. However, there should not be too many Ts meeting such a condition, so another method is used. 22 In this method, S also attempts to communicate to T at (4) and (5), but T returns something other than B as a response. In this method, at (5), T can return—as a response—the character string (associated with T) stored at S, instead of B. Consequently, at (5), T can use every character string as a response, as long as S knows they are associated with T. Similarly, the case where every character string translated based on some rule agreed between T and S should also be permissible. In other words, both a replaced character string and a translated string can be used as a substitute for B. The relationship between every character string and B itself is delicate. Every character string is an extension of B, meaning it is derived from B. On the other hand, every character string naturally includes B when B is simply viewed as a character string. Thus, it is difficult to define which (B or every character string) is the generic concept. In this specification, every character string is assumed to be a substitute for B. In this case, every character string is conditionally established; that is, the condition that S knows that every character string is associated with T, must be met. However, such a statement is omitted hereafter. Summarizing the contents of character string that T returns at (5) to S as a response, when the response is B itself, S only needs to know the static identifier B of destination T. When the response is every character string, D needs to know the static identifier indicating T, and also needs to know either the character string associated with T, or the translation rule. In subsequent description, when simply the symbol B is used, it is assumed to include a substitute for B; "B itself and "a substitute for B" are explicitly stated only when it is important to distinguish between B itself and a substitute for B. Also, unless there is some special need to distinguish between the replaced substitute for B and translated substitute for B, the term "substitute for B" or "every character string" is simply used. At (2), when S performs query using B and then B itself is returned as a response at (5), this situation may be expressed as a "parrot-fashion relationship". In this case, the returned response is B itself, not a substitute for B. So far, we have described the communication model for implementing the present invention. Specific devices for actually controlling specific functions are described below. There may be multiple devices depending on the situation or positional relationship of networks. These specific devices for controlling specific functions can be substituted, forming a specific set. 23 D Mapping notification system D normally often configures a redundant server group, so there is a substitution relationship within this group. Typically, D notifies mapping of B and A disclosed in dynamic DNS, ENUM DNS, and patent documents 1 and 2. T: Destination terminal When T is within the LAN and communicates with D and S via a gateway and then via a public store-and-forward network, viewed from P, there is a substitution relationship between devices integrated with edge nodes. Practical role sharing in this case is detailed in embodiment 8. S: Originator terminal S-2 and S-1 exist. (Basically, S may be either S-1 or S-2. S-1 and S-2 must be clearly differentiated only when they perform client-server type operation. S-2 performing client-server type operation may have no reachability confirmation function.) In implementing the present invention, when a client-server model is adopted, S-2 performs query to S-1, and S-1 confirms reachability to the destination on behalf of S-2; S-1 is the originator. S may be integrated with D on an exceptional basis. P: Entity to assign A, a transient address, to T When T is on a LAN and P is a DHCP server, normally, the DHCP server assigns A. However, this assumes that D and S can also be reached on the same LAN or via an inter-LAN connection. When transiting a public network to communicate to D or S, a network such as the ISP should be P. In other words, P does not assign transient address A to T; P simply assigns A to the edge node. As explained earlier, in this case T is a node reference that is integrated with an edge node that is a gateway. This is also detailed in embodiment 8. A specific P and T should be selected from among substitutes depending on the network configuration (how networks are connected) and the positional relationship of these devices. Operation is given the following names: (1) This process maps pair of A and B from T to S. The process is a related art; and in DNS, it is equivalent to "update." (2) In a DNS example, this process is "name query". For unification of terms, the term "name query" is also used for D other than DNS. (3) In a DNS example, this process is "name resolution"." As with (2) above, the term "name resolution" is also used for D other than DNS. Because (2) and (3) are a set, it is assumed that expressing one half implies the existence of the other half. 24 (4) Conventionally, there is no reachability confirmation process; ordinary communication such as web access is equivalent to this process. This process is called "sign". It is also called "communication using the method agreed upon in advance". (5) This process is a response to sign, so it is called "countersign." Real and mapped images of pair of A and B can be obtained using the above sequence ((2) to (5)). Confirming the reachability by comparing the real and mapped images of the pair of A and B thus obtained is called reachability confirmation. At (4) and (5), the said comparison can be made even when character string is replaced or translated. So, the character string that can be used for a reply that should be made is every character string. As explained earlier, processes (1) to (3) are executed conventionally. When (4) is a general access, T returns a response appropriate to its access method. However, therefore, at (5), T will never return B or return every character string agreed upon between T and S. So, at (5), the said theory cannot be used unless an existing mechanism is diverted or a new mechanism to return a countersign is implemented. Host that performs the process (5) How the host that performs the process (5) should behave is explained below. Here, it is assumed that the host returns B itself as the reply that should be made. 1. In the standard state, T (4100) does not give its identity or gives an irrelevant name as its identity. Giving an irrelevant name as its identity means that PC, for example, returns an appropriate name given to it in advance, as its identity. (An appropriate name does not mean a host name including a domain name that is dynamically updated by T (4100) to D (1000); such a host name cannot be set unless it is intentionally set.) 2. Then, the name cannot be used as a reply that should be made, meaning that the name is not proper. 3. So, T (4100) must return a name that is used as a reply that should be made. A name that is used as a reply that should be made means a host name updated dynamically at D (1000). From 1 above, this means an explicit setting change. This is because S-1 (2000) obtains the IP address of T (4100) by referencing D (1000) that manages the domain of T (4100), and at this time, S-1 (2000) requires T (4100) to return the host name, a key used at name query, as is. 4. The above setting is a special setting; usually, T (4100) is not set as described in item 3 above. Performing such a setting is needed to establish the sign-and-countersign 25 operation performed in the present invention. The same theory also applies to the case when the reply that should be made is a substitute for B. The above explanation is summarized below. Reachability confirmation is established by comparing the real and mapped images of the pair of A and B. To do so, four elements (values) concerning the real and mapped images of the pair of A and B must be obtained. Of these, only the value B for real image cannot be obtained by conventional methods. Consequently, we propose a carrier that we call "countersign". The carrier is obviously a signal, and means an entity to carry information. "Reply that should be made" is information carried by "countersign". The said B itself and the said substitute for B are a type of information. Using an analogy, "countersign" is a bucket, and "reply that should be made" is water in the bucket. "Reply that ought to be made" is information associated with "reply that should be made" that is stored at S. On receiving the "reply that should be made" by T carried by "countersign" at (5), S compares the reply to the "reply that ought to be made" stored internally at S to determine a match. When they match, reachability is correct; when they do not, reachability is wrong. The section entitled "Host that performs the process (5)" is appropriated for the explanation. The communication methods described in embodiments 1 to 7 are related art. However, by using the communication method differently from the conventional method, a new value called reachability confirmation can be created. Communication method only means which communication port is used. Consequently, regardless of whether something new is used or something old is appropriated, they must be within the range of communication port. Normally, it is better to use new ports, but this requires standardization established by a different procedure from the present invention. The reason for appropriation is simple; we wanted to clarify the ability to implement the inventions independently of communication ports. The identity given for the host name is usually stored at the storage device of T (4100). In response to the communication request (= sign) from S, T returns a response (= countersign); at this time, the host name is read, embedded in the response, and returned. The response contents are called the "reply that should be made." Consequently, T (4100) must be explicitly set to return its host name (as its identity) that is updated, to D (1000). However, the replaced or translated B is regarded as B itself. This is explained in the following section "Type of reply that should be made." Type of reply that should be made The character string that can be used as a reply (that should be made by T) carried by countersign is typified. DNS is used as an example. 1. Hostname 26 In the case of B itself, host name is assumed to be FQDN. It is best if the destination"s host name is the reply"s host name. But, when the only host name is returned is rather rare, and actually a fairly lengthy reply seems to be returned. Consequently, a reply that should be made must be extracted from the returned lengthy reply. In other words, this is a typical example of sign-and-countersign. When the said condition is met (that is, when T (4100) is explicitly set to return its host name (as its identity) that T (4100) uses as a reply that should be made), the host name is simply returned as is, so setting of a reply that ought to be made can be omitted at S-1 (2000). The algorithm is explained in embodiment 1 and setting is explained in embodiment 1 and Table 02. In other words, at (2), the contents of the query that S performs to D (1000) are B; and at (5) after going through (3) and (4), the contents of a reply that should be made are also B. At S, B need not be stored twice. The reply can be omitted when the destination and a reply that should be made are the same (that is, the reply is B itself). Multiple replies that should be made can be made. Incidentally, when the mapping notification system is not DNS, the host name can be considered to be static identifier itself instead of FQDN. For example, In patent document 2, FQDN can be replaced by a handle name. 2. URI scheme (= uri_scheme) In this concept that the protocol name is rather included in the reply, since there are many cases that the reply containing the host name is lengthy. When different services are provided at a single host, even when each of these waiting services is associated with each of multiple host names, inclusion of protocol name enables reachability confirmation to be performed for each pair of a host name and a service individually. In other words, this is a case where service is provided using an alias host name (including one in a different domain) at a single host. Uniqueness is provided. Setting of a reply that should be made may be omitted at S-1 (2000) depending on the circumstance, such as when the following services are provided at a single host called user01.customer.co.jp and that reachability confirmation is performed for each of those services. http://wwwhostOl.customer.co. jp mailto:[email protected] mailto:info-fax@ faxsvr.customer.co.jp sip:[email protected] h323:[email protected] 27 h323:[email protected] tel:81-3-1234-5678 enum:8.7.6.5.4.3.2.1.3.1.8.el64.arpa, etc. The URI (Uniform Resource Identifier, RFC2396) features permanence and ability to be referenced without ambiguity. Here, URL is assumed to be a specialized form of URI; and URI is assumed to include URL (RFC1738). In the present invention, URI includes host name, so URI is treated as an extension of the host name. In this case, a reachability confirmation port waiting at T (4100) may also be a well-known port, but a port dedicated to reachability confirmation (a port not for service) can also be provided separately as a non-well-known port. The international public telecommunication number ("telephone number" hereafter) defined by the ITU-T Recommendation E.164 is converted to the host name (FQDN) called a reverse-sequential telephone number, e164.arpa to become input to dynamic DNS (RFC3263) to connect to existing telephone networks. This is commonly called ENUM. In this case, the telephone number (RFC2916) that the sender specifies for the receiver at translation of the character string can also be used as a reply that should be made. This is ideal like when the "destination"s host name is the replied host name" (described in item 1 above) in the parrot-fashion relationship (B used at query and B returned as a reply are the same) is established, so reachability confirmation can be performed. (The telephone number or the said converted telephone number host name are normally included in the host name stated in items 1 above.) Of course, the URI obtained in the intermediate process of the said conversion can also be used as a reply that should be made. The telephone number is obviously a static identifier. The reverse-sequential telephone number e164. arpa in ENUM is a host name, and simultaneously is a telephone number itself. (It is a telephone number itself because it is simply mapped onto DNS and is equivalent to a telephone number. Although some people disagree with this; it is only a matter of notational difference.) When it is a telephone number itself, it should be included in the host name as a type of reply that should be made, and not in the URI. In other words, the final character string obtained as a result of name query (forward name query to T (4100) -> IP address as the other communication end where sign is sent, query as sign -> character string as reply that should be made) is associated with T (4100); of course, and reachability confirmation can be performed when T (4100) only returns identification information about itself as a reply that should be made. Incidentally, when the URI form is used, not only T (4100) but also user (man) of T (4100) can be identified. To identify them, the character processing part only need 28 be constructed to have multiple stages in the algorithm disclosed in embodiment 1 (those skilled in the art can easily imagine this). That is, additional information can be included in a reply that should be made. Also, because multiple replies that should be made are allowed to be made, a single T (4100) can let reachability confirmation be performed for each of multiple services and multiple aliases. For the URI scheme, the character string is on the boundary between B itself and a substitute for B. When B itself is included in URI scheme, a reply that should be made by T (4100) is extracted from the returned lengthy reply, as described earlier in item 1 (host name), so the character string can be regarded as B itself, as with item 1. However, when B itself is not included in the URI scheme or when the entire URI scheme instead of B itself is agreed upon, the character string should be regarded as a substitute for B. 3. When no host name included in reply The character string is a substitute for B. The explanation so far assumes that the host name is FQDN. However, there is an implementation that returns a host name other than FQDN when T (4100) cannot be located from the reply that should be made. The following three patterns are possible: a. When only domain name included, and narrowly-defined host name not included This case is special. When the customer uses a domain name exclusively, the host name can be regarded as FQDN. When the customer does not use a domain name exclusively, no discrimination is provided (self identification information is insufficient). b. When only narrowly-defined host name included, and no subdomain name and domain name included (non-qualified single label) c. When host name and subdomain name included, and no domain name included (non-qualified multiple labels) Unlike name search, S-1 (2000) never adds a suffix, to confirm reachability for T (4100). When the host name is USER01 or HOST01, no discrimination regarding man is also provided. Obviously, no uniqueness is provided. However, this is all right. Having no uniqueness only means that T (4100) cannot be located from the reply received by S-1 (2000) that should be made by T (4100). 29 A character string registered at S-1 (2000) that is neither host name nor URI scheme is also a substitute for B. The character string can be an X509 certificate or simply a public key of T (4100), and need not necessarily be the host name. In other words, T (4100) need not necessarily return its host name; it only needs to return identification information about itself as its identity. More specifically, identification information only need to be agreed between T and S. Agreement between T and S here includes agreement about the character string that T (4100) determines on its own and announces publicly. So, unlike FQDN or URI, the character string need not be unique globally. Moreover, S-1 (2000) naturally knows identification information about T (4100) and confirms reachability by comparing between identification information (= reply that ought to be made) of T (4100) stored at S-1 (2000) in advance and the reply (= reply that should be made) from the device (the other communication end) believed to be T (4100). The above explains the case where no host name is included in the reply and the case where the character string replaces B itself. In the replacement case, the replaced character string is agreed directly between T and S, so replacement is static. In the translation case, the translation rule is agreed, so translation is just dynamic replacement. * Consequently, countersign is a signal that functions to let S confirm reachability to T (4100). Feature of reply that should be made As explained in the Impersonation section, the reply that should be made is not password. That is, the reply that should be made is not a security risk and need not be kept secret. Conventional individual identification is not used to identify T (4100). Reachability is determined by comparing between the value obtained from the network characteristics and the stored information. In addition, S is not a specific single communication node. As seen from the description that S is given as S-2 (5300), S is assumed to include the general user (unspecified majority). In this case, the reply that should be made cannot be secret; it does not mean that the reply need not be made secret. To use a substitute for B, not only a static identifier indicating T (4100) but also the replaced character string and translation rule must be notified to S in advance. This may seem unrealistic but it is not necessarily the case. For example, it is not unusual to notify the URL and mail address instead of a domain name. Considering the same case as this example, it is not that burden on the T (4100) side and the S side increases. But, there is a different case. For example, when a substitute for B is notified only to a specific S-1 (2000) and the substitute is used as a reply that should be made, the substitute is nearly secret. However, even so, the substitute should not be confused with a password. The substitute only means the present invention can be implemented flexibly. 30 From the above, reachability confirmation is made possible if T (4100) only returns a character string containing an expected reply stored at S-1 (2000). Incidentally, DNS is defined as described below viewed from the resolver. (Conventional) In response to query from resolver, system where static identifier translated to static IP address and then output (Recent) In response to query from resolver, system where static identifier (host name, telephone number) is translated to dynamic identifier (URI), translated to static or dynamic IP address and then output using multi-stage recursive query (intermediate processing) The recent DNS includes conventional DNS. As described, the positioning of DNS is changing. The process in which DNS translates the identifier is described below. Alias (= CNAME) -> host name -> IP address Telephone number -> Host name -> URI -> IP address A reply that should be made can be either a static identifier (IP address not included), first input to DNS, or an identifier (IP address not included) that can be obtained in the intermediate identifier translation process at DNS (see above). A translation process starting with an alias may have a special meaning. First, a host on another DNS has been referenced conventionally using an alias. In other words, recursiveness is used before ENUM appears. Second, T (4100) pointed to at another DNS is updated dynamically. When the dynamic update is considered simply as an operation, ignoring translation of character string, the dynamic update can be said to be the same operation as ENUM. When it is assumed here that multiple countersigns may be returned, reachability can be confirmed not only for end-to-end but also for the host (DNS in this case) in the intermediate process during the name search process. At S, a target reply that should be made just needs to be extracted from multiple replies returned that should be made. In this case, two methods are available: one is return multiple replies that should be made, using a single countersign, and the other is return multiple countersigns, each of which carries only one reply that should be made. Returning multiple countersigns has two merits: It is possible to make multiple identifications at a single T (4100). It is possible to increase traceability when a node in the intermediate process 31 during the name transformation process returns multiple countersigns. In this case, T(4100) only need extract a reply that ought to be made indicating the target T (4100) from the reply made by the intermediate node. Consequently, like traceroute, it becomes possible to confirm reachability to the intermediate node, providing great help in locating failure locations. Design concept Network management This explains the needs for network management. First, the term is explained. Network management itself is the concept of ordinary management including so-called configuration management and accounting management. Its target is the network. The relationship between management and monitoring is explained next. It is understood that the large category called network management includes a specific technique called host and network monitoring. (For example, traffic can be measured for both individual nodes and the entire network.) Because the network state is continually changing, monitoring the state is the first step to deal with failure, and the monitoring result should become feedback to network design or become materials indicating the grounds for future network expansion planning. However, in the present invention, T (4100) is a boundary node in the customer network that is assigned a dynamic IP address, or a host integrated with a boundary node that is referenced; T (4100) is quite small. But, because T (4100) . provides some TCP/IP service, Not noticing the state in which no service can be provided due to line disconnection or system failure is a problem. If some failure occurs, it should be promptly notified and recovered. To do so, network management is needed, even for a small-scale network. Network management makes it also possible to manage hosts with changing IP addresses that cannot be managed conventionally. Meaning of ping The ping command implements the echo request of the ICMP protocol and is conventionally used to confirm reachability (host is alive or dead). ping is like fish finder; if a response is returned, it is known that schools of fish (or hosts) are present. However, when the destination host (T (4100)) has a changing IP address, ping indicates that the host (other communication end) responds even when reply is from T (4200) instead of T (4100). In this case, host reachability cannot be said to have been confirmed. Using ping, it is not known whether the other communication end is the real one. Consequently, the present invention asks "Who are you" and the response is "I am so-and-so." If this reply matches the expected name, T (4100) is known to be reachable. The present invention is designed as a substitute for ping, which can no 32 longer be used for hosts with changing IP addresses (different from conventional hosts). In other words, the present invention is not intended as 100% substitute for ping. (In fact, many ping functions are not implemented in the present invention.) The present invention is only used as a substitute for ping because cannot be verified using ping. To facilitate understanding of the present invention, Fig. 39 shows an image of the present invention used as a substitute for ping (an image of the present invention that S-2 (5300) uses as means to confirm reachability to T (4100)). (Details are given in the practical application.) Here, the case that reachability to T (4100) is confirmed means the originator reaches the other communication end and then a reflection is returned from that end, which is equivalent to reachability confirmation—the intended purpose of ping. So, the present invention can be a substitute for ping in terms of reachability confirmation. The round-trip time included in the output from ping is not considered, but addition of calculation of the round-trip time to an implementation of the present invention is easy to those skilled in the art. However, note that when using the present invention shown in the practical application, a redundant output such as round-trip time is undesirable in an implementation as a filter. The situations when there is network "cloud" when a ping is returned from the other communication end, or when the other communication end is on the same Ethernet (not connecting via network cloud) are transparent. Similarly, they are transparent to the present invention (this means end-to-end communication). Design considerations The present invention aims to use the intrinsic autonomy of store-and-forward networks. The present invention tries to be simple and clear. Regarding the simplicity, the invention tries to be self-explanatory structure by people. Also, the invention aims at higher applicability, availability, flexibility and independence of scale. Operability People"s have high psychological resistance to discarding related art. An invention that cannot be implemented without changing social infrastructure has low chance of success. So, the present invention should be implemented to provide convenience and usability without changing related art and by adding new technology. The present invention has a high possibility of becoming widespread because it can be started on a small scale, can be implemented independently of scale, and can be implemented by being highly consistent with related art and without discarding related art. . Scope of application 33 The present invention can be used in Ipv4 and Ipv6 networks. The operation model can be peer-to-peer or client-server. Also, the present invention can be applied to both portable and mobile IP addresses. Here, IP address mobility means cases such as when a networked laptop is turned off, moved (e.g. hotel while on a business trip), and then powered on. IP address mobility refers to a case where IP address handover occurs with communication being maintained (at a mobile terminal). IP address portability tends to be confused with IP address mobility (= IP Mobility; RFC2002 to RFC2006). However, they are different in purpose. IP Mobility is a technology aimed at ensuring that it receives a reply from communication whose call it made itself; providing discrimination of the called party"s (mobile) terminal to the calling party"s terminal is not the primary purpose. Moreover, the mobile IP concept is different from that of the present invention in that dynamic and static addressing are associated. In that sense, the expression "Mobility of IP address" is not appropriate; the present invention verifies a pair of the static identifier and dynamically assigned network address regardless of address mobility. Implementation The present invention operates at the application layer, and is independent of the transport layer. However, the said application layer includes the session layer, presentation layer, and application layer defined by the OSI (= Open System Interconnection) reference model; a standard developed by ISO/ITU-T). As can be seen, this specification is described according to the successional UNIX-like standard. When describing the specification according to other standards such as OSI, a note to that effect is written clearly. Also, the said statement that the present invention operates on the application layer is not restrictive; even when, in the future, a protocol such as ICMP, where the present invention operates on the network layer, is proposed, the said proposal shall be within the scope of the present invention in the sense that the first implementation of the present invention operated on the application layer. (Implementation) The implementation of the present invention is explained using drawings. In each drawing, locations with the same function have the same sign. The following embodiments are examples, not restrictions. In the embodiments, the explanation uses S-1 (2000), but this can be replaced with S-2 (5300). The explanation uses dynamic DNS as an example, but as explained earlier, ENUM, patent document 1, and patent document 2 are also applicable. Embodiments 1 to 7 exemplify the kind of communication used to perform the sign. The sign is expressed as a communication method agreed in advance. In this 34 case, normally, communication ports shall conform to the protocol using them. In embodiments 1 to 7, explanation is given using existing (well-known) ports as communication ports. In embodiment 1, the assumed concept and algorithm are shown. In embodiments 1 and 2, T (4100) is a network boundary (= edge node). Typically, T (4100) is a terminal itself. In embodiments 3 and 4, T (4100) is a network connection equipment; typically, it is NATBOX. In embodiments 5 and 7, it does not matter what kind of equipment T (4100) is. In embodiment 8", the configuration and position of the network are shown. In embodiment 9, an example of implementing the present invention for a device such as NATBOX is given (this is a new implementation). In embodiment 10, an example of implementing the present invention for a terminal itself, typically a mobile terminal, is given. Embodiment 1 Embodiment 1 uses SNMP for the communication method agreed in advance. T (4100) is a computer connected directly via dial-up. An SNMP agent is implemented, and the usual setting is performed. Embodiment 1 is the connection configuration 1 shown in Fig. 37 detailed in embodiment 8. S-1 (2000) is running a monitoring program via a timer. At S-1 (2000): 1. The Internet uses many UNIX (registered trademark; "UNIX" hereafter) servers, so we assume that the present invention would often be implemented on UNIX. 2. On UNIX, major Internet services using well-known ports are introduced in advance, or they can be introduced at lesser cost and labor. 3. On UNIX, the string processing environment is provided as part of the OS from the outset, etc. Consequently, we performed experiments on UNIX (an experimental environment can be created by implementing only the present invention). For OSs in the Windows family, the existing DNS is replaced with ISC BIND (the Internet standard DNS since it was adopted in Berkeley UNIX as the first DNS implementation). Or, the existing DSN is replaced with a substitute for ISC BIND. The said substitute is something like the dig command included in ISC BIND, which can closely examine DNS server information from outside. For the SNMP manager, the Microsoft product can be used, or a product such as OpenView (registered trademark; "OpenView" hereafter) can be introduced. The string processing environment, it is not fully included in Windows OSs, so it may be best to prepare the environment separately or to build it into a program during development of the program to implement the present 35 invention. (However, in this case, a program interface with output of the dig command included in ISC BIND is troublesome; labor might be saved by creating a substitute for the dig command.) When T (4100) is PC, for Windows OSs, it can be used as is, because an SNMP agent is included in Windows NT or Windows 2000. Therefore, the present invention can be implemented regardless of the OS type. For communication methods such as SNMP, waiting port numbers shall be the same as well-known ports defined by RFC1700 ASSIGNED NUMBERS, or shall be something similar, unless otherwise stated. RFC originated from the document published as "Request For Comments" to agree on (or improve) a communication method during ARPANET development. It presently functions as a standard convention set for communication over the Internet or TCP/IP. SNMP (= Simple Network Management Protocol) is a standard network management protocol that is not simple. During communication using SNMP, the community name, and the object ID that should be used for confirming of reachability to T (4100), are agreed as the communication method; the value of the object ID set at T (4100) is agreed as a reply that ought to be made. For example, PUBLIC, initial value, is used for the community name, and sysName representing the host name is used for the object ID. When setting the SNMP agent, in most cases, sysName is not something that is set explicitly, and it simply quotes the system"s host name as is. Here, the explicit setting change described in the section entitled "Host that performs process (5)" and the description given in the section entitled "Type of reply that should be made" shall apply. For the host name set at T (4100), the Fully Qualified Domain Name (consisting of host name, sub-domain name, and domain name; "FQDN" hereafter) that is registered at D (1000) shall be set. In a few devices, there may be a case where FQDN cannot be set and only a host name not including a domain name can be set. In such a case, when daring to use B itself as a reply that should be made, see embodiment 2. In such a case, it is simpler to use a substitute for B as a reply that should be made. Here, since the object ID can be regarded as a variable assigned the contents (= identifier) of a reply, the following is established: Value of object ID (sysName) = FQDN = Contents of reply = Host name of T (4100) Table 02 shows the items required for communication setting, such as name of T (4100) registered at S-1 (2000) and a reply that ought to be returned. 36 Table 02 S-1 (2000) or S-2 (5300) Direction T(4100) Static identifier indicating T, destination (Value) How to perform sign (Destination communication port) Sign -> How to receive sign (Receiving communication port) tting item Reply that ought to be made (Value) Countersign Reply that should be made (Value) CO — B itself Setting not needed because T assigned — B itself B itself — Replaced B Replaced string — Replaced B Replaced string "— Translated B Translation rule "— Translated B Translation rule As seen from Table 02, the setting items are common to S and T except that, at S, a static identifier indicating T (4100), destination, is added. When the reply that should be made by T (4100) is B itself, this setting can be omitted on only the S side. At S, the sequence in the communication model is completed by receiving a countersign. After this, at S, the reply stored internally at S that ought to be made is read for comparison to the reply that should be made by T (4100) that is carried by a countersign. Whether the result of the comparison is true or false makes a sharp distinction between the case that the originator has correct reachability to T (4100) and the case that originator has wrong reachability to T (4100). A variable that temporarily stores a reply when the reply is received is needed, but since the variable is self-explanatory in computer engineering, and also since the variable itself is not so important in the present invention, the variable is expressed as a reply that should be received. At S-1 (2000), setting items required for reachability confirmation can be stored in a storage device as sequential file records or can be a database accessed via DBMS. Alternatively, a program is prepared at each T (4100) and setting information can be input to the program. An appropriate method can be selected from these methods, depending on the volume of T (4100) managed at S-1 (2000). The method of directly embedding setting information in the program is convenient when the number of T (4100) hosts is relatively small (several hundreds at most). Contents set here need only include the items required for each T (4100), but they can also include additional information, such as the address of D (1000) managing the domain name used by T (4100). When applying patent document 2, the address of the IP address information notification server is stored. Also, the item arrangement sequence need not be as shown in Table 02; they need only be stored around T(4100) in such a manner that they do not become confused. In the present invention, storage device means memory and external storage 37 devices; it does not refer to registers or cache. Also, an external storage device need not be a local device incorporated in the appropriate equipment at S-1 (2000) or T (4100). For example, a disk array accessed via fiber channel and a NFS-mounted shared disk are both simply treated as a hard disk drive. Temporary storage need not be retained at restart of the equipment and is deleted after being stored for a short time, but it can be deployed to memory or to a hard disk drive as a temporary file. At T (4100), a few items are required for setting communication. These items are items required for the program part that responds to a communication request made by the agreed method, and items required for communication of the reply itself. If the program is already implemented, the amount of data that should be stored is less. Storage devices storing items required for communication setting include: non-volatile memory, memory cards such as CF card/smart card; hard disk drives with the PCMCIA interface; normal hard disk drives; diskette drives; MO drives; and tape devices. (Also, storage media readers using removable storage media such as DVD-RAM, CD-RW. (using packet writing method), and CD-R (that creates image) can be used.) Further, since the rewrite frequency is extremely low, storage devices that use removal storage media such as CD-ROM, DVD-ROM, ROM cartridges where stored contents are modified by being replaced can be used. (These storage media are not directly written in the appropriate equipment.) Incidentally, the storage device"s interface need not be separated; the USB interface and IEEE 1394 interface need not be separated in the same way that the SCSI interface and IDE interface need not be separated for hard disk drives. In addition, for example, setting can be loaded at start of the system, using communications such as TFTP from the host specified in advance. In this case, the storage device is an external host via communication, and setting is stored temporarily in the internal storage device. The appropriate usable storage devices can be selected depending on the environment (specific devices) to be implemented. Incidentally, as shown in Fig. 15, name query must be performed to D (1000) that is operating the domain name used by T (4100). In other words, it is basically assumed that there are many Ds (1000), meaning the query destination is switched each time a query is performed. For example, when the DNS operating the domain name used by T1 (4101) is D1 (1001), and the DNS operating the domain name used by T2 (4102) is D2 (1002), S-1 (2000) performs name query by switching D1 (1001) and D2 (1002), which are different Ds. When the DNS operating the domain used by T3 (4103) not shown here is D1 (1001), name query regarding T1 (4101) and T3 (4103) should of course be performed to D1 (1001). Consequently, the following algorithm (Fig. 23) is performed for each T (4100) or for each D (1000). Address verification S202 and S204 are address verification processes. Address verification 38 solves the "cache TTL" problem. The "cache TTL" problem means that when an attempt is made to perform forward name query from a DNS server (such as 4500 or 5500) for the IP address of T (4100), if the second or later access is made during the cache TTL specified at D (1000) and T (4100) performs update during that period, a wrong IP address is obtained for T (4100), so access is made to a host other than T (4100). At S202, to solve the "cache TTL" problem, name query (forward) is performed from S-1 (2000) to D (1000). Fig. 25 shows an example output of name query. The underlined part is the IP address of T (4100) last updated to D (1000). When the output is subjected to string processing and only the underlined part is extracted—meaning that the IP address of T (4100) is obtained (S204)—the IP address is stored temporarily at the storage device. To be more precise, the IP address is assigned to the address indicating T (4100), the destination, to confirm reachability at the next step. Fig. 26 shows an example output when error occurs at name query. In this case, the DNS server is not in the normal state or is down. Fig. 27 shows another example of output where an error occurs at name query. In this case, T (4100) is not found (information indicating T (4100) does not exist in the DNS record). As described in the actual example of the cache problem, verification of the IP address of T (4100) can be omitted when either the resolver at S-1 (2000) is set to D (1000), or the cache TTL of D (1000) is quite short. At 204, it is best if the error check shown in Fig. 24 is performed as necessary. If failure occurs at D (1000), the reply received at S204 becomes irregular. When, at S402, it is detected that data indicating T (4100) is not included in the reply received at S204, this is handled as an error. Similarly, when no reply is returned from D, this is handled as an error at S402. In this case, it is best if switching is made to another D (1000) within the range of redundant Ds (1000) (S408 to S410); if the problem persists, processing is stopped. If processing is stopped, reachability to T (4100) is determined to be absent even if the state of T (4100) is assumed to be normal. Also, when the reliability of D (1000) is adequate, the error check can be omitted. In this section, we have explained the patrol within the redundancy range of D (1000). Sign-and-countersign At S206, communication using the method agreed upon in advance (sign) is performed to the IP address of T (4100) obtained at S204. When address verification can be omitted, the string need not be translated to IP address. (Even in this case, query is performed using the IP address obtained at forward name resolution to DNS). At S208, when a reply is returned from S206, the reply is stored temporarily; when no reply is returned from S206, the completion code at S206 is stored temporarily and then error handling at S216 is performed. 39 Fig. 28 shows an example output where the host name of T (4100) is obtained using the GetRequest instruction of SNMP. Fig. 29 shows an example output where communication at S206 fails. Specifically, this means when either the host name is wrong due to the cache TTL problem (the other communication end (host) is not set to accept SNMP), or the other communication end (host) does not exist. Fig. 30 shows an example output where communication at S206 fails. Specifically, this means when the other communication end accepts SNMP, but the community name is wrong. At 208, as with the cases in Figs. 29 and 30 above, error handling is performed when T (4100) does not accept the GetRequest instruction of SNMP from S-1 (2000). When an error occurs with the GetRequest instruction of SNMP shown Figs. 29 and 30, the reply from S206 is only returned at error output; no reply is returned at standard output. In such cases, some action should be taken such as assigning a completion code (indicating error) as a flag. Fig. 31 shows the case when the SNMP object ID is specified incorrectly. In this case, the value of the appropriate object ID is returned normally and no error occurs with the GetRequest instruction of SNMP, so determination should be made at S212. In this example, sysLocation is used. Also, when communication at S206 is correct and a reply that does not match the agreed-upon reply is returned (reply is not reply that ought to be made), determination is made at S212. String processing is performed at S210 in response to the reply from the communication to extract the host name (FQDN) of T (4100). At S212, the reply is compared with the reply that ought to be made in response to the communication using the agreed-upon method and that should be a reply from T (4100) that is set at S-1 (2000) for determination. At S214, when there is a match between the reply that ought to be made from T (4100) that is stored at S-1 (2000) and that is returned in response to the communication performed using the agreed-upon method and the actual reply that is made by T (4100) in response to the query (communication using agreed-upon method) from S-1 (2000), T (4100) is operating correctly and is a host with correct reachability. Output At S214 and S216, the result can either be output to an ordinary console or terminal device consisting of standard output, keyboard, and display device, or can be written as a log file stored at a storage device, or can be output to another host via a TCP/IP communication path such as Syslog, X, or SNMPTRAP. In addition, the output can be e-mailed as input to the SMTP server program, which may be useful in linking the output to maintenance described later. The said result can be output as a combination of two or more of these methods, and can be printed to paper too. In implementing the present invention, it is best to perform output using a method (selected from these 40 methods) matching the environment or subsequent processing. The output classifies whether the result of reachability confirmation is true or false. True is represented as S214. In this case, nothing need be output when the purpose is to detect failure. When the output purpose is something else, only a message saying that reachability to T (4100) is correct need be displayed. In displaying the message, use the most suitable method selected from the said methods. False is represented as S216. When no match occurs (S216), either T (4100) is not connected to the Internet, or it is in a state in which it cannot perform updating to D (1000) due to some problem. At S216, two cases can be displayed by being distinguished in terms of the reason for the inability to reached: one is when no reply is made (S208); the other is when no match occurs (S212). In this case, it is best that the reason for the inability to reached is included in the message and is written to the log file, etc. Incidentally, when a failure seems to have occurred at T (4100) because the timing at which S executes the process shown in Fig. 23 accidentally overlaps the timing of an update request to D (1000) by T (4100), the system should be returned to the normal state by itself if the second monitoring timing is waiting to be reached. In such a case, the failure that seems to have occurred before the second monitoring timing is reached, should not be detected as a failure. At S-1 (2000), the monitoring program is executed via a timer, so setting an error flag at the step (not shown in figure) immediately after S216, can be used to detect whether the pass via the S216 step is the first, second, or later pass. At a normal return, it is best to erase the error flag at the step (not shown in figure) immediately after S214. When the pass via the S216 step is the second pass, there is no timing problem and it is obvious that T (4100) is lost sight of. So it is best if maintenance or recovery is notified by e-mail (issue alert or ring pager) instead of simply writing to a log file. In this case, since it is impossible to notify T (4100) itself that it cannot be reached, notification should be made to the administrator of T (4100) using an available method. However, the expression "notification is made to T (4100)" is used hereafter. When transition must be made to the maintenance or recovery stage, and when T (4100) is disconnected from the Internet for some reason, so T (4100) cannot be found or only T (4200) is found, T (4100) is lost sight of by S-1 (2000), so generally, to access T (4100), its installation location must be physically accessed. However, this prevents quick failure recovery. It is better to recover T (4100) via a second maintenance path (such as a telephone line shown in Fig. 14 from S-1 (2000) to T (4100)) by providing a serial console at T (4100) or LAN connected to T (4100). Embodiment 2 In this example, the environment is the same as example 1 and SNMP is used as the previously agreed communication method; instead of sysName, sysLocation 41 can be used with fewer restrictions on the string compared to sysName. Generally, when sysLocation is used, the replaced string of B is used for the value of "reply that should be made". However, B itself can also be used. In this case, B itself is simply set for sysLocation. See Table 02 for the setting items. Since embodiments 1 and 2 both use SNMP for the agreed communication method, the SNMP usage cautions are given below. When SNMP is in a communication state, it can "know" almost everything about the state of T (4100) in the system. Also, the SNMP setting can be changed. The present invention does not aim to use the powerful SNMP management function; instead it aims to verify whether or not a host assigned a dynamic IP address that tends to be lost sight of and cannot be located correctly, is actually the correct other intended communication end. Here, if an attempt is made to connect to subsequent conventional management, there is a high possibility that the subsequent management method will be SNMP. In this case, since SNMP should be previously available to T (4100), SNMP is used to determine that the result of reachability confirmation is true or false, assuming that this environment is used as is. (The cases when no subsequent management is required and when reachability is confirmed using a method other than SNMP are described later.) The following points should be noted regarding security when using SNMP for the agreed communication method (sign). The present invention uses PUBLIC as the default experimental group name, but since anybody (including unwanted intruders) can access this environment, a default name of PUBLIC (or PRIVATE) must not be used in a production environment. Also, when the IP address of S-1 (2000) is known to T (4100), access must be controlled by refusing access requests from IP addresses other than S-1 (2000). Embodiment 3 In embodiments 1 and 2, T (4100) performs dial-up directly. In embodiment 3, separately provided network connection equipment performs dial-up; T (4100) does not perform dial-up directly. When dial-up is performed by network connection equipment (NATBOX hereafter) that can obtain IP addresses using a dial-up router (ISDN router, etc.) or PPPoE, PPPoA, DHCP (broadband router, etc.), and provides global services to multiple PCs on LAN using dynamic network address translation (NAT hereafter; including NAPT) such as IP masquerading, and T (4100) is connected only to the customer"s LAN (see connection configurations 4 to 6 in Fig. 37), as in embodiments 1 and 2, S-1 (2000) can perform true/false determination by setting static NAT or port forwarding for network connection equipment even when T (4100) does not perform dial-up directly (even when it is not connected to the Internet directly). The conditions for embodiment 3 are the same as for embodiments 1 and 2 (in that an SNMP agent is implemented and set in T (4100)), except that the dial-up 42 function is network connection equipment, not T (4100), and static NAT or port forwarding is set for network connection equipment. Embodiment 4 When, as in embodiment 3, a computer does not perform dial-up directly and network connection equipment performs dial-up, if SNMP is implemented in network connection equipment such as a dial-up router, SNMP can be used as T (4100). According to the conventional UNIX concept, all devices to which IP address can be assigned are called hosts. The present invention uses this same concept and a device is called a host whether it is a router or NATBOX, as long as it is assigned an IP address (as long as it is a communication node). In embodiment 4, the router performing dial-up is a host, T (4100). T (4100) implements SNMP, so it is network connection equipment such as a dial-up router (connection configuration 2 in Fig. 37). Moreover, when this router has dynamic NAT functions, such as IP masquerading, the router can enable PCs on a LAN to update DNS even when it has no function for performing dynamic update to DNS (connection configuration 3 in Fig. 37). In this case, when a name registered in D (1000) is the same as the host name updated dynamically and is set in the dial-up router, S-1 (2000) can determine whether T (4100) is true or false (as with embodiment 1). However, the configuration becomes smarter if a more flexible, arbitrary string is agreed as a reply that should be made-by T (4100), using sysLocation (as with embodiment 2). Embodiment 5 Embodiment 5 uses DOMAIN (DNS) for the previously agreed communication method. It is assumed that T (4100) is a computer with BIND implemented and version information set (explicitly changed). Here, it is assumed that DOMAIN (DNS) is used as the previously agreed communication method and version information is used for a reply mutually agreed. It is assumed that T (4100) is connected directly via dial-up or has static NAT or port forwarding set via network connection equipment. S-1 (2000) is executing a monitoring program via a timer. Other conditions and settings are the same as embodiment 1. In the preparatory stages, it is assumed that the following is agreed and set. The reply that should be made to the communication using the previously agreed method that is set at T (4100) is version information changed to an arbitrary string returned by BIND operating at T (4100). T (4100) can provide DNS service for a local LAN environment even when it does not provide a global name service intended for the Internet. Fig. 32 shows how to set version information for BIND at T (4100). As the standard operation, BIND usually returns the version of the program itself as shown in Fig. 35 if version information is not set explicitly. If the program 43 version information is known to a network attacker, the attacking method is also known, so version information is changed deliberately to try to foil any attacker. However, since version information can be set arbitrarily, the replaced string of B, for example, is set here as a reply that should be made. See Fig. 23 again. S202 and S204 are address verification processes. This is the same as embodiment 1. At S206, communication using the previously agreed method is performed to the IP address of T (4100) obtained at S204. At 208, when a reply is returned, it is stored temporarily; when no reply is returned, the completion code at S206 is stored temporarily. Fig. 33 shows an example output where BIND version information is obtained using dig. The underlined part is the reply that ought to be made to the communication using the agreed method that is set at S-1 (2000) and that should be a reply from T (4100) (underlined part in Fig. 32). Any string can be used here, but it conforms to the type of reply that should be made. Fig. 34 shows the case when is no host currently assigned the IP address previously assigned to T (4100), and the case where there is a host T (4200) currently assigned the IP address previously assigned to T (4100) and BIND does not operate at T (4200). Only an error that is output to the error output is enclosed with a rectangle; other errors are errors that are output to the standard output. Fig. 35 shows the case when there is a host T" (4200) currently assigned the IP address previously assigned to T: (4100) and BIND operates at T (4200). In this case, no dig command output error occurs, so whether or not an error occurs should be determined at S212. I At S210, string processing is performed to extract version information of BIND operating at T (4100) in response to the reply to the communication. At S212, comparison is made between this reply and the reply that ought to be made that is stored at S-1 (2000) for determination. When a match occurs between the reply that should be made and that is carried from T (4100) using countersign and the reply that ought to be made and that is stored at S-1 (2000), T (4100) is a host with correct reachability at S214. At S214, as with embodiment 1, it is best that a message is written to the log file or processing proceeds to the subsequent ordinary monitoring. When no match occurs (that is at S216), it is also best that the same processing be performed as in embodiment 1. Embodiment 6 Embodiment 6 uses SMTP for the previously agreed communication method. It is assumed that T (4100) is a computer with an SMTP server implemented. It is also assumed that SMTP is used for the previously agreed communication method, 44 and that the host name (FQDN) of T (4100) is used for the mutually agreed reply. It is assumed that T (4100) performs directly transient connection or has static NAT or port forwarding set via network connection equipment. S-1 (2000) is executing a monitoring program via a timer. Other conditions and settings are the same as embodiment 1. The reply that should be made to the communication using the previously agreed method set at T (4100) is the host name itself set at T (4100). When a connection is made to the SMTP server, a message like that shown in Fig. 36 is often output. (The example is for SENDMAIL, the most popular SMTP server. However, in the case of QMAIL too (the second most popular SMTP server), the host name is or can be included in the message). In this message, the host name is displayed in the FQDN format (underlined part in Fig. 36), so the host name can be used as an identifier determining whether or not T (4100) can be reached, or in other words as the reply that should be made. Embodiment 7 Embodiment 7 uses HTTP for the previously agreed communication method. It is assumed that T (4100) is a computer with an implemented web server. Here, HTTP is used for the previously agreed communication method. In other words, since the waiting service at T (4100) is a web server, any character string can be used as the mutually agreed reply. It is assumed that T (4100) is directly connected via dial-up or has static NAT or port forwarding set via network connection equipment. S-1 (2000) is executing a monitoring program via a timer. Other conditions and settings are the same as embodiments 1 and 2. The reply that should be made to the communication using the previously agreed method that is set at T (4100) is an arbitrary string embedded in the character string returned by the HTTP server operating at T (4100). Since a web server is well known to people other than computer engineers, it is probably one of the services most provided at a server that provides TCP/IP service at T (4100) or at a customer network. Since HTTP can transfer any string, a character string can be used as the reply to the agreed communication. At many web servers, the index.html file is opened (transferred from web server to client) when no file name is specified. Only the string that should be the reply need be entered in the file. For example, the string at the third word in the text on the top page of the index.html file is agreed. However, in this case, the character string at the third word in the text may be changed accidentally at updating, so it is best to agree another file name, and a particular string in the file is agreed as the reply. Also, a character string can be embedded in an HTML statement, or |
|---|
00535-mumnp-2005-cancelled pages(01-06-2005).pdf
00535-mumnp-2005-claims(granted)-(01-01-2005).doc
00535-mumnp-2005-claims(granted)-(01-06-2005).pdf
00535-mumnp-2005-correspondence(ipo)-(10-01-2008).pdf
00535-mumnp-2005-correspondence1(27-10-2005).pdf
00535-mumnp-2005-correspondence2(19-06-2007).pdf
00535-mumnp-2005-drawing(01-06-2005).pdf
00535-mumnp-2005-form 1(11-12-2006).pdf
00535-mumnp-2005-form 13(13-04-2006).pdf
00535-mumnp-2005-form 13(28-12-2006).pdf
00535-mumnp-2005-form 18(04-08-2005).pdf
00535-mumnp-2005-form 2(granted)-(01-01-2005).doc
00535-mumnp-2005-form 2(granted)-(01-06-2005).pdf
00535-mumnp-2005-form 26(13-04-2006).pdf
00535-mumnp-2005-form 3(13-04-2006).pdf
00535-mumnp-2005-form 3(24-05-2005).pdf
00535-mumnp-2005-form 5(11-12-2006).pdf
00535-mumnp-2005-form 5(24-05-2005).pdf
00535-mumnp-2005-form-pct-isa-210(01-06-2005).pdf
00535-mumnp-2005-petition under rule 137(01-05-2006).pdf
| Patent Number | 213711 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Indian Patent Application Number | 535/MUMNP/2005 | ||||||||
| PG Journal Number | 12/2008 | ||||||||
| Publication Date | 21-Mar-2008 | ||||||||
| Grant Date | 10-Jan-2008 | ||||||||
| Date of Filing | 01-Jun-2005 | ||||||||
| Name of Patentee | FUKUSHIMA HAJIME | ||||||||
| Applicant Address | 2-62-3, NOGATA NAKANO-KU, TOKYO 165-0027 | ||||||||
Inventors:
|
|||||||||
| PCT International Classification Number | H04L12/56 | ||||||||
| PCT International Application Number | PCT/JP2003/016538 | ||||||||
| PCT International Filing date | 2003-12-24 | ||||||||
PCT Conventions:
|
|||||||||