the embodiments of the present invention are described below in the following order . c - 2 . internetwork device startup process ( prevention of discarding of packets from network by bringing down the link ) c - 3 . internetwork device startup process ( prevention of discarding of packets from network by route propagation ) fig1 is an illustration schematically depicting the configuration of a network 10 according to an embodiment 1 of the present invention . the network 10 includes three isps ( internet service providers ) 200 . each isp 200 accommodates a number of individual users 220 via a home router 210 having nat functionality , as well as a number of enterprise users 250 via an enterprise network ( enterprise internal networks ) 240 and an enterprise router 230 having nat functionality . isp - a ( 200 a ) is an isp having a global address , and is able to communicate with the internet 300 through a direct connection with a carrier edge router 310 . an http server 320 is provided on the internet 300 , at a location accessible by individual user 220 and enterprise user 250 clients . isp - b ( 200 b ) and isp - c ( 200 c ) are isps that lack a global address , and are able to communicate with the internet 300 by connecting to the carrier edge router 310 via internetwork devices 100 with lsn ( large scale nat ) functionality . the present embodiment employs a redundant configuration in which two internetwork devices 100 ( internetwork device a ( 100 a ) and internetwork device b ( 100 b )) having identical functionality and configuration operate simultaneously ( double act configuration ). specifically , isp - b ( 200 b ) and isp - c ( 200 c ) are each connected to the two internetwork devices 100 and are able thereby to connect to the carrier edge router 310 through either internetwork device 100 . the two internetwork devices 100 synchronize with one another information needed for address translation ( session information ). isp - b ( 200 b ) and isp - c ( 200 c ) respectively have routers ( not shown ) connected to the two internetwork devices 100 . these routers direct packets in communications bound from the isp 200 ( local network ) to the internet 300 ( hereinafter termed “ outbound communications ”) to either of the two internetwork devices 100 . similarly , the carrier edge router 310 directs packets in communications bound from the internet 300 to the isp 200 ( hereinafter termed “ inbound communications ”) to either of the two internetwork devices 100 . load dispersion between the two internetwork devices 100 is accomplished thereby . if either of the two internetwork devices 100 encounters a problem , it is possible for address translation to continue by directing all packets to the other internetwork device 100 . the functions of the internetwork devices 100 may be viewed as part of the functionality of the carrier edge router 310 . fig2 is an illustration schematically depicting the configuration of internetwork devices 100 . the configurations of two internetwork devices 100 ( internetwork device a ( 100 a ) and internetwork device b ( 100 b )) are shown in fig2 . because the two internetwork devices have identical configurations , in the following description , the identifiers for distinguishing between devices ( i . e . “ a ” and “ b ”) are not appended to names or drawing symbols except where necessary to do so to distinguish the two internetwork devices 100 and their constituent elements from one another . the internetwork devices 100 are devices for performing address translation ( address and port translation ) so that communication can take place between a local network lnet and a global network gnet . each internetwork device 100 includes an inside packet interface ( packet i / f ( i )) 101 for connecting to the local network lnet ; an outside packet interface ( packet i / f ( o )) 103 for connecting to the global network gnet ; a routing controller 102 for controlling packet routing ; an inside address translation module ( address translation module ( i )) 104 for performing address translation of outbound communication packets ( hereinafter termed “ outbound packets obp ”); an outside address translation module ( address translation module ( o )) 105 for performing address translation of inbound communication packets ( hereinafter termed “ inbound packets ibp ”); an inside inter - device packet transfer interface ( inter - device packet forwarding i / f ( i )) 106 for forwarding outbound packets obp to the other internetwork device 100 ; and an outside inter - device packet transfer interface ( inter - device packet forwarding i / f ( o )) 107 for forwarding inbound packets ibp to the other internetwork device 100 . the inside packet interface 101 is connected to the routing controller 102 , and to a router ( not shown ) located on the local network lnet and that carries out load dispersion . the inside packet interface 101 receives outbound packets obp sent from the router and forwards these to the routing controller 102 , and also receives inbound packets ibp forwarded from the routing controller 102 and forwards these to the router . the outside packet interface 103 is connected to the routing controller 102 and to the carrier edge router 310 ( fig1 ). the outside packet interface 103 receives inbound packets ibp sent from the carrier edge router 310 and forwards these to the routing controller 102 , and also receives outbound packets obp forwarded from the routing controller 102 and forwards these to the carrier edge router 310 . the inside packet interface 101 and the outside packet interface 103 function as the transmission module and the receiving module in the present invention . the routing controller 102 is connected to constituent elements of the internetwork device 100 . the routing controller 102 carries out forwarding of packets received from the various interfaces , as well as a process to determine whether received packets are fragmented packets . the packet forwarding process of the routing controller 102 will be discussed in detail later . the inside redundant inter - device packet transfer interface 106 is an interface adapted for direct connection to another internetwork device 100 . specifically , for operation in double act configuration , the inside redundant inter - device packet transfer interface 106 is connected via a dedicated line 112 to the inside redundant inter - device packet transfer interface 106 of the other internetwork device 100 . the inside redundant inter - device packet transfer interface 106 is adapted to receive outbound packets obp forwarded from the routing controller 102 in its home device and to transmit these to the inside redundant inter - device packet transfer interface 106 of the other internetwork device 100 ; as well as to receive outbound packets obp forwarded from the other internetwork device 100 ( termed “ inter - device transfer outbound packets tobp ”) and to forward these to the routing controller 102 in its home device . in the present embodiment , the communication band ( line speed ) of the inside redundant inter - device packet transfer interface 106 is the same as the communication band ( line speed ) of the inside packet interface 101 , so as to be able to handle instances in which all outbound packets obp received by the inside packet interface 101 are forwarded to the other internetwork device 100 as inter - device transfer outbound packets tobp . the outside redundant inter - device packet transfer interface 107 is an interface adapted for direct connection to another internetwork device 100 . specifically , for operation in double act configuration , the outside redundant inter - device packet transfer interface 107 is connected via a dedicated line 114 to the outside redundant inter - device packet transfer interface 107 of the other internetwork device 100 . the outside redundant inter - device packet transfer interface 107 is adapted to receive inbound packets ibp forwarded from the routing controller 102 in its home device and to transmit these to the outside redundant inter - device packet transfer interface 107 of the other internetwork device 100 ; as well as to receive inbound packets ibp forwarded from the other internetwork device 100 ( termed “ inter - device transferred inbound packets tibp ”) and to forward these to the routing controller 102 in its home device . in the present embodiment , the communication band ( line speed ) of the outside redundant inter - device packet transfer interface 107 is the same as the communication band ( line speed ) of the outside packet interface 103 , so as to be able to handle instances in which all inbound packets ibp received by the outside packet interface 103 are forwarded to the other internetwork device 100 as inter - device transferred inbound packets tibp . the inside redundant inter - device packet transfer interface 106 and the outside redundant inter - device packet transfer interface 107 function as the inter - device packet forwarding interfaces in the present invention . the routing controller 102 functions as the inter - device packet forwarding controller in the present invention . the inside address translation module 104 is adapted to maintain address and port translation information ( session information ); and on the basis of the address and port translation information , to carry out translation of the source address ( sending address ) and communication port number ( address translation ) of outbound packets obp forwarded from the routing controller 102 , then re - forward the address - translated outbound packets obp back to the routing controller 102 . the outside address translation module 105 is adapted to maintain address and port translation information ( session information ); and on the basis of the address and port translation information , to carry out translation of the destination address and communication port number ( address translation ) of inbound packets ibp forwarded from the routing controller 102 , then re - forward the address - translated inbound packets ibp back to the routing controller 102 . the inside address translation module 104 and the outside address translation module 105 are connected to one another via a line 126 , and are also connected to the inside address translation module 104 and the outside address translation module 105 of the other internetwork device 100 via lines 122 and 124 . the inside address translation modules 104 and the outside address translation modules 105 of the internetwork devices 100 carry out synchronization of address and port translation information via these lines . address and port translation information includes an address translation rule table indicating mappings between local addresses and global addresses ; a free port management table indicating in use / not in use status of communication ports in global addresses ; and an address / port translation table indicating corresponding relations between address / communication port combinations on the local network side and address / communication port combinations on the global network side . the inside address translation module 104 and the outside address translation module 105 function as the address translation modules in the present invention . fig3 is a flowchart depicting the flow of the outbound packet forwarding process . fig4 is an illustration of packet forwarding routes in the outbound packet forwarding process . the outbound packet forwarding process is a process whereby an internetwork device 100 that has received outbound packets obp from the local network lnet forwards the received packets to the global network gnet . the following description assumes that the two internetwork devices 100 are operating simultaneously in double act redundant configuration , and describes the outbound packet forwarding process that takes place when outbound packets obp sent from the local network lnet are received by the internetwork device 100 a ( see fig4 ). in step s 110 ( fig3 ), the inside packet interface 101 of the internetwork device 100 ( 100 a ) receives outbound packets obp from the local network lnet . the inside packet interface 101 then forwards the received outbound packets obp to the routing controller 102 ( step s 120 ). in step s 130 ( fig3 ), the routing controller 102 determines whether the received outbound packets obp meet either a first condition or a second condition . here , the first condition and the second condition are set up so that any outbound packet obp meets either the first condition or the second condition . also , the first condition and the second condition are set up so that all fragmented packets contained in a same - source fragmented packet group meet the same condition . herein , a same - source fragmented packet group means a set of multiple fragmented packets created from the same original packet . the first condition and the second condition in one internetwork device 100 are set up to be the opposite of the first condition and the second condition in the other internetwork device 100 . in the present embodiment , in the internetwork device 100 a , the first condition is that “ the source address is an even number ” and the second condition is that “ the source address is not an even number ( is an odd number )”. in the internetwork device 100 b on the other hand , in order to make the relationship of the first condition and the second condition the reverse of their relationship in the internetwork device 100 a , the first condition is that “ the source address is not an even number ( is an odd number )” and the second condition is that “ the source address is an even number ”. where the first and second conditions are set up in this way , any outbound packet obp meets either the first condition or the second condition . also , because fragmented packets contained in a given same - source fragmented packet group share the same source address , they all meet the same condition . in step s 130 ( fig3 ), the routing controller 102 of the internetwork device 100 a determines whether the outbound packet obp source address is an even number ( i . e . whether it meets the first condition ) or an odd number ( i . e . whether it meets the second condition ). if it is determined that the outbound packet obp meets the second condition and not the first condition ( step s 130 : no ), the routing controller 102 forwards the outbound packet obp to the other internetwork device 100 ( 100 b ) via the inside redundant inter - device packet transfer interface 106 ( step s 140 ) ( see path p 2 in fig4 ). the process that takes place when an internetwork device 100 receives an outbound packet obp transferred from the other internetwork device 100 ( inter - device transfer outbound packet tobp ) will be discussed later . if on the other hand it is determined that the outbound packet obp meets the first condition ( step s 130 : yes ), the routing controller 102 then determines whether the outbound packet obp is a fragmented packet ( step s 160 ). if determined that the outbound packet obp is not a fragmented packet ( step s 160 : no ), the routing controller 102 forwards the outbound packet obp to the inside address translation module 104 ( step s 190 ) ( see path p 1 in fig4 ). the inside address translation module 104 having received the outbound packet obp references the address / port translation information and carries out address translation ( translation of the source address and communication port number ) ( step s 200 ). if on the other hand it is determined that the outbound packet obp is a fragmented packet , ( step s 160 : yes ), the routing controller 102 waits to receive all of the packets that make up the same - source fragmented packet group to which the received fragmented packet belongs ( step s 170 ). through monitoring of packets forwarded from the local network lnet via the inside packet interface 101 and of packets transferred from the other internetwork device 100 via the inside redundant inter - device packet transfer interface 106 , the routing controller 102 determines whether all of the packets that make up the same - source fragmented packet group have been received . once all of the packets that make up the same - source fragmented packet group are received , the routing controller 102 sorts all the received fragmented packets in order of sequence number ( step s 180 ). the routing controller 102 then forwards the fragmented packets ( outbound packets obp ) in order of sequence number to the inside address translation module 104 ( step s 190 ) ( see path p 1 in fig4 ). once the inside address translation module 104 has received the outbound packets obp , it references the address / port translation information and carries out address translation ( translation of the source address and communication port number ) ( step s 200 ). the inside address translation module 104 forwards the address - translated outbound packets obp to the routing controller 102 , whereupon the routing controller 102 carries out routing according to the destination address , and forwards the outbound packets obp to the global network gnet via the outside packet interface 103 ( step 5210 ) ( see path p 1 in fig4 ). the outbound packet forwarding process when outbound packets obp are received by the internetwork device 100 b takes place in the same manner as above . in this case , in step s 130 ( fig3 ) it is determined whether the outbound packet obp source address is an odd number ( i . e . meets condition 1 ) or an even number ( i . e . meets condition 2 ), and according to the outcome of the decision either a process to forward the outbound packet obp to the other internetwork device 100 ( step s 140 ), or to process it internally ( steps s 160 - 210 ) is carried out . fig5 is a flowchart depicting the flow of the inter - device transfer outbound packet forwarding process . the inter - device transfer outbound packet forwarding process is a process by which an internetwork device 100 having received outbound packets obp ( inter - device transfer outbound packets tobp ) from the other internetwork device 100 forwards the received packets to the global network gnet . the following description assumes that the two internetwork devices 100 are operating simultaneously in double act redundant configuration , and describes the inter - device transfer outbound packet forwarding process that takes place when inter - device transfer outbound packets tobp transferred from the internetwork device 100 a are received by the internetwork device 100 b ( see path p 2 in fig4 ). the specifics of the inter - device transfer outbound packet forwarding process that takes place when inter - device transfer outbound packets tobp transferred from the internetwork device 100 b are received by the internetwork device 100 a would be the same . in step s 310 ( fig5 ), the inside redundant inter - device packet transfer interface 106 of the internetwork device 100 ( 100 b ) receives an outbound packet obp ( inter - device transfer outbound packet tobp ) from the other internetwork device 100 ( 100 a ). the inside redundant inter - device packet transfer interface 106 forwards the received outbound packet obp to the routing controller 102 ( step s 320 ). in step s 330 ( fig5 ), the routing controller 102 determines whether the outbound packet obp is a fragmented packet ( step s 330 ). if determined that the outbound packet obp is not a fragmented packet ( step s 330 : no ), the routing controller 102 forwards the outbound packet obp to the inside address translation module 104 ( step s 360 ) ( see path p 2 in fig4 ). the inside address translation module 104 having received the outbound packet obp references the address / port translation information and carries out address translation ( translation of the source address and communication port number ) ( step s 370 ). if on the other hand it is determined that the outbound packet obp is a fragmented packet , ( step s 330 : yes ), the routing controller 102 waits to receive all of the packets that make up the same - source fragmented packet group to which the received fragmented packet belongs ( step s 340 ). through monitoring of packets forwarded from the local network lnet via the inside packet interface 101 and of packets transferred from the other internetwork device 100 via the inside redundant inter - device packet transfer interface 106 , the routing controller 102 determines whether all of the packets that make up the same - source fragmented packet group have been received . once all of the packets that make up the same - source fragmented packet group are received , the routing controller 102 sorts all the received fragmented packets in order of sequence number ( step s 350 ). the routing controller 102 then forwards the fragmented packets ( outbound packets obp ) in order of sequence number to the inside address translation module 104 ( step s 360 ). once the inside address translation module 104 has received the outbound packets obp , it references the address / port translation information and carries out address translation ( translation of the source address and communication port number ) ( step s 370 ). the inside address translation module 104 forwards the address - translated outbound packets obp to the routing controller 102 , whereupon the routing controller 102 carries out routing according to the destination address , and forwards the outbound packets obp to the global network gnet via the outside packet interface 103 ( step s 380 ) ( see path p 2 in fig4 ). fig6 is a flowchart depicting the flow of the inbound packet forwarding process . fig7 is an illustration of packet forwarding routes in the inbound packet forwarding process . the inbound packet forwarding process is a process whereby an internetwork device 100 that has received inbound packets ibp from the global network gnet forwards the received packets to the local network lnet . the following description assumes that the two internetwork devices 100 are operating simultaneously in double act redundant configuration , and describes the inbound packet forwarding process that takes place when inbound packets ibp sent from the global network gnet are received by the internetwork device 100 a ( see fig7 ). in step s 410 ( fig6 ), the outside packet interface 103 of the internetwork device 100 ( 100 a ) receives inbound packets ibp from the global network gnet . the outside packet interface 103 then forwards the received inbound packets ibp to the routing controller 102 ( step s 420 ). in step s 430 ( fig6 ), the routing controller 102 determines whether the received inbound packets ibp meet either a first condition or a second condition . here , the first condition and the second condition are set up so that any inbound packet ibp meets either the first condition or the second condition . also , the first condition and the second condition are set up so that all fragmented packets contained in a same - source fragmented packet group meet the same condition . the first condition and the second condition in one internetwork device 100 are set up to be the opposite of the first condition and the second condition in the other internetwork device 100 . in the present embodiment , in the internetwork device 100 a , the first condition is that “ the source address is an even number ” and the second condition is that “ the source address is not an even number ( is an odd number )”. in the internetwork device 100 b on the other hand , in order to make the relationship of the first condition and the second condition the reverse of their relationship in the internetwork device 100 a , the first condition is that “ the source address is not an even number ( is an odd number )” and the second condition is that “ the source address is an even number ”. where the first and second conditions are set up in this way , any inbound packet ibp meets either the first condition or the second condition . also , because fragmented packets contained in a given same - source fragmented packet group share the same source address , they all meet the same condition . in step s 430 ( fig6 ), the routing controller 102 of the internetwork device 100 a determines whether the inbound packet ibp source address is an even number ( i . e . whether it meets the first condition ) or an odd number ( i . e . whether it meets the second condition ). if it is determined that the inbound packet ibp meets the second condition and not the first condition ( step s 430 : no ), the routing controller 102 forwards the inbound packet ibp to the other internetwork device 100 ( 100 b ) via the outside redundant inter - device packet transfer interface 107 ( step s 440 ) ( see path p 2 in fig7 ). the process that takes place when an internetwork device 100 receives an inbound packet ibp transferred from the other internetwork device 100 ( inter - device transfer inbound packet tibp ) will be discussed later . if on the other hand it is determined that the inbound packet ibp meets the first condition ( step s 430 : yes ), the routing controller 102 then determines whether the inbound packet ibp is a fragmented packet ( step s 460 ). if determined that the inbound packet ibp is not a fragmented packet ( step s 460 : no ), the routing controller 102 forwards the inbound packet ibp to the outside address translation module 105 ( step s 490 ) ( see path p 1 in fig7 ). the outside address translation module 105 having received the inbound packet ibp references the address / port translation information and carries out address translation ( translation of the destination address and communication port number ) ( step s 500 ). if on the other hand it is determined that the inbound packet ibp is a fragmented packet , ( step s 460 : yes ), the routing controller 102 waits to receive all of the packets that make up the same - source fragmented packet group to which the received fragmented packet belongs ( step s 470 ). through monitoring of packets forwarded from the global network gnet via the outside packet interface 103 and of packets transferred from the other internetwork device 100 via the outside redundant inter - device packet transfer interface 107 , the routing controller 102 determines whether all of the packets that make up the same - source fragmented packet group have been received . once all of the packets that make up the same - source fragmented packet group are received , the routing controller 102 sorts all the received fragmented packets in order of sequence number ( step s 480 ). the routing controller 102 then forwards the fragmented packets ( inbound packets ibp ) in order of sequence number to the outside address translation module 105 ( step s 490 ) ( see path p 1 in fig7 ). once the outside address translation module 105 has received the inbound packets ibp , it references the address / port translation information and carries out address translation ( translation of the destination address and communication port number ) ( step s 500 ). the outside address translation module 105 forwards the address - translated inbound packets ibp to the routing controller 102 , whereupon the routing controller 102 carries out routing according to the destination address , and forwards the inbound packets ibp to the local network lnet via the inside packet interface 101 ( step s 510 ) ( see path p 1 in fig7 ). the inbound packet forwarding process when inbound packets ibp are received by the internetwork device 100 b takes place in the same manner as above . in this case , in step s 430 ( fig6 ) it is determined whether the inbound packet ibp source address is an odd number ( i . e . meets condition 1 ) or an even number ( i . e . meets condition 2 ), and according to the outcome of the decision either a process to forward the inbound packet ibp to the other internetwork device 100 ( step s 440 ), or to process it internally ( steps s 460 - 510 ) is carried out . fig8 is a flowchart depicting the flow of the inter - device transfer inbound packet forwarding process . the inter - device transfer inbound packet forwarding process is a process by which an internetwork device 100 having received inbound packets ibp ( inter - device transfer inbound packets tibp ) from the other internetwork device 100 forwards the received packets to the local network lnet . the following description assumes that the two internetwork devices 100 are operating simultaneously in double act redundant configuration , and describes the inter - device transfer inbound packet forwarding process that takes place when inter - device transfer inbound packets tibp transferred from the internetwork device 100 a are received by the internetwork device 100 b ( see path p 2 in fig7 ). the specifics of the inter - device transfer inbound packet forwarding process that takes place when inter - device transfer inbound packets tibp transferred from the internetwork device 100 b are received by the internetwork device 100 a would be the same . in step s 610 ( fig8 ), the outside redundant inter - device packet transfer interface 107 of the internetwork device 100 ( 100 b ) receives an inbound packet ibp ( inter - device transfer inbound packet tibp ) from the other internetwork device 100 ( 100 a ). the outside redundant inter - device packet transfer interface 107 forwards the received inbound packet ibp to the routing controller 102 ( step s 620 ). in step s 630 ( fig8 ), the routing controller 102 determines whether the inbound packet ibp is a fragmented packet ( step s 630 ). if determined that the inbound packet ibp is not a fragmented packet ( step s 630 : no ), the routing controller 102 forwards the inbound packet ibp to the outside address translation module 105 ( step s 660 ) ( see path p 2 in fig7 ). the outside address translation module 105 having received the inbound packet ibp references the address / port translation information and carries out address translation ( translation of the destination address and communication port number ) ( step s 670 ). if on the other hand it is determined that the inbound packet ibp is a fragmented packet , ( step s 630 : yes ), the routing controller 102 waits to receive all of the packets that make up the same - source fragmented packet group to which the received fragmented packet belongs ( step s 640 ). through monitoring of packets forwarded from the global network gnet via the outside packet interface 103 and of packets transferred from the other internetwork device 100 via the outside redundant inter - device packet transfer interface 107 , the routing controller 102 determines whether all of the packets that make up the same - source fragmented packet group have been received . once all of the packets that make up the same - source fragmented packet group are received , the routing controller 102 sorts all the received fragmented packets in order of sequence number ( step s 650 ). the routing controller 102 then forwards the fragmented packets ( inbound packets ibp ) in order of sequence number to the outside address translation module 105 ( step s 660 ). once the outside address translation module 105 has received the inbound packets ibp , it references the address / port translation information and carries out address translation ( translation of the destination address and communication port number ) ( step s 670 ). the outside address translation module 105 forwards the address - translated inbound packets ibp to the routing controller 102 , whereupon the routing controller 102 carries out routing according to the destination address , and forwards the inbound packets ibp to the local network lnet via the inside packet interface 101 ( step s 680 ) ( see path p 2 in fig7 ). as described above , according to the present embodiment , when an internetwork device 100 receives packets from either the local network lnet or the global network gnet , after first determining whether the packets meet either the first condition or the second condition ( step s 130 in fig3 and step s 430 in fig6 ), the received packets are directed to either the home internetwork device 100 or the other internetwork device 100 . here , because the first condition and the second condition are set up such that all fragmented packets included in a same - source fragmented packet group meet the same condition , the entire same - source fragmented packet group is collected by the same internetwork device 100 . typically , the initial fragmented packet in a same - source fragmented packet group contains in its data portion information identifying the communication port number , whereas the second and subsequent fragmented packets do not contain information identifying the communication port number . in the present embodiment however , because the entire same - source fragmented packet group is collected by the same internetwork device 100 , address translation inclusive of communication port number ( address and port translation ) can be accomplished on such fragmented packets as well . thus , according to the present embodiment , fragmented packets contained in a same - source fragmented packet group can undergo identical address translation , and the terminal for which the fragmented packets are destined will be able to correctly reassemble the original packet on the basis of the received fragmented packets . thus , where the present embodiment is employed for address translation in a configuration with multiple internetwork devices 100 operating simultaneously , address translation of fragmented packets can be carried out correctly . moreover , in the present embodiment , if a received packet is a fragmented packet , the device waits until all of the fragmented packets that make up the same - source fragmented packet group are received , and having received these then sorts all of the fragmented packets in order of sequence number , and forwards them in order of sequence number . thus , according to the present embodiment , fragmented packets can be forwarded in order of sequence number to devices downstream from the internetwork devices 100 . according to the present embodiment , conditions that pertain to information originally included in packets , i . e . the source address , are employed as the first and second conditions , so same - source fragmented packet groups can be collected by the same internetwork device 100 without any need to append to the packets additional information for the purpose of packet collection . in lsn , address and port translation information ( session information ) that indicates currently corresponding relations of address / communication port combinations on the local network side and address / communication port combinations on the global network side is determined either dynamically or statically in the respective internetwork devices 100 according to the ip address and port number of the original packet that was initially received . in configurations where packets are transferred among multiple internetwork devices 100 operating simultaneously and address translation frequently takes place in a different internetwork device , because it is necessary for the respective internetwork devices to carry out address translation based on the same session information regardless of which internetwork device receives the original packet , the multiple internetwork devices 100 must synchronize session information with one another in order to maintain the same session information . in the event that , for example , a stopped internetwork device 100 is restarted , another operational internetwork device 100 must transfer the session information it maintains to the internetwork device 100 that has started up , so that the two internetwork devices 100 can maintain the same session information . under these circumstances , if for example when a first internetwork device 100 is started up , packets are transferred between the two internetwork devices 100 prior to synchronization of session information between the devices , address translation cannot take place because the first internetwork device 100 lacks session information , so the packets are discarded . the present embodiment describes an embodiment of the present invention whereby in a configuration in which address translation is carried out on packets transferred between multiple internetwork devices 100 operating simultaneously , if an internetwork device 100 is started up , discarding of packets by the started up internetwork device 100 is prevented so that correct address translation can take place on the basis of session information . fig9 is a flowchart depicting the flow of a startup process of an internetwork device 100 . fig1 is a flowchart depicting the flow of an outbound packet forwarding process . the following description of the outbound packet forwarding process assumes that , in a redundant configuration with the internetwork device 100 a already operating , when the internetwork device 100 b is started up , outbound packets obp sent from the local network lnet are received by the internetwork device 100 a , transferred between the devices , and then sent from the internetwork device 100 b to the global network gnet ( see path p 2 in fig4 ). in step s 910 ( fig9 ), functioning of the address translation module ( i ) 104 b of the internetwork device 100 b is started up . in step s 920 ( fig9 ), upon startup , the address translation module ( i ) 104 b of the internetwork device 100 b , via the line 122 , sends the address translation module ( i ) 104 a of the other internetwork device 100 a a control packet 400 requesting it to transfer address / port translation information . fig1 is an illustration schematically depicting the control packet 400 for requesting transfer of address / port translation information . the control packet 400 includes a mac header 410 and a command 420 requesting transfer of address / port translation information . in step s 930 ( fig9 ), the address translation module ( i ) 104 a of the other internetwork device 100 a that received the control packet 400 now sends the address translation module ( i ) 104 b a control packet 500 that contains the address / port translation information currently maintained by itself , in order to transfer the address / port translation information to the address translation module ( i ) 104 b of the internetwork device 100 b via the line 122 . fig1 is an illustration schematically depicting the control packet 500 for transferring address / port translation information . the control packet 500 includes a mac header 510 , a command 520 for transferring address / port translation information , a maintained address / port translation information count 530 , and address / port translation information 540 . in step s 940 ( fig9 ), once the address translation module ( i ) 104 b of the internetwork device 100 b has acquired the address / port translation information contained in the received control packet 500 , it now sends a control packet 600 providing notification of nat - enabled status to the routing controller 102 a of the other internetwork device 100 a via the line 122 . fig1 is an illustration schematically depicting the control packet 600 for providing notification of nat - enabled status . the control packet 600 includes a mac header 610 and a command 620 for notification of nat - enabled status . through notification of nat - enabled status by the control packet 600 , the internetwork device 100 b can notify the other internetwork device 100 a that synchronization of address / port translation information is complete and that the address translation process is enabled . next , the outbound packet forwarding process in the other internetwork device 100 a is described with reference to fig1 . the flowchart of fig1 is substantially identical to the flowchart of fig3 except for an additional step s 1040 between step s 130 and step s 140 ; parts that are not appreciably different from fig3 are not described . in step s 1010 ( fig1 ), the inside packet interface 101 of the internetwork device 100 ( 100 a ) receives an outbound packet obp from the local network lnet . the inside packet interface 101 forwards the received outbound packet obp to the routing controller 102 ( step s 1020 ). in step s 1030 ( fig1 ), the routing controller 102 determines if the received outbound packet obp meets either the first condition or the second condition . if it is determined that the outbound packet obp meets the second condition and not the first condition ( step s 1030 : no ), in step s 1040 , the routing controller 102 of the internetwork device 100 a determines whether the address translation module ( i ) 104 b of the internetwork device 100 b has nat - enabled status . if determined to have nat - enabled status ( step s 1040 : yes ), the routing controller 102 transfers the outbound packet obp to the other internetwork device 100 b via the inside inter - device packet transfer interface 106 ( step s 1050 ) ( see path p 2 in fig4 ). on the other hand , if determined that the outbound packet obp meets the first condition ( step s 1030 : yes ) or that transfer of address / port translation information is not complete and nat is not enabled ( step s 1040 : no ), the routing controller 102 then determines whether the outbound packet obp is a fragmented packet ( step s 1060 ). if determined that the outbound packet obp is not a fragmented packet ( step s 1060 : no ), the routing controller 102 forwards the outbound packet obp to the inside address translation module 104 ( step s 1090 ) ( see path p 1 in fig4 ). the inside address translation module 104 having received the outbound packet obp then refers to the address / port translation information and carries out address translation ( translation of the source address and communication port number ) ( step s 1100 ). if on the other hand it is determined that the outbound packet obp is a fragmented packet , ( step s 1060 : yes ), the routing controller 102 waits to receive all of the packets that make up the same - source fragmented packet group to which the received fragmented packet belongs ( step s 1070 ). through monitoring of packets forwarded from the local network lnet via the inside packet interface 101 and of packets transferred from the other internetwork device 100 via the inside redundant inter - device packet transfer interface 106 , the routing controller 102 determines whether all of the packets that make up the same - source fragmented packet group have been received . once all of the packets that make up the same - source fragmented packet group are received , the routing controller 102 sorts all the received fragmented packets in order of sequence number ( step s 1080 ). the routing controller 102 then forwards the fragmented packets ( outbound packets obp ) in order of sequence number to the inside address translation module 104 ( step s 1090 ) ( see path p 1 in fig4 ). once the inside address translation module 104 has received the outbound packets obp , it references the address / port information and carries out address translation ( translation of the source address and communication port number ) ( step s 1100 ). the inside address translation module 104 forwards the address - translated outbound packets obp to the routing controller 102 , whereupon the routing controller 102 carries out routing according to the destination address , and forwards the outbound packets obp to the global network gnet via the outside packet interface 103 ( step s 1110 ) ( see path p 1 in fig4 ). according to the present embodiment , because the internetwork device 100 a performs inter - device packet transfer only if the address translation module ( i ) 104 b of the internetwork device 100 b has nat - enabled status , discarding of packets due to inability for address translation to take place on the internetwork device 100 b can be prevented . while the present embodiment described the outbound packet forwarding process , in the inbound packet forwarding process as well , discarding of inbound packets ibp can be prevented analogously through an additional step equivalent to step s 1040 of fig1 coming between step s 430 and step s 440 of the flowchart of fig6 . c - 2 . internetwork device startup process ( prevention of discarding of packets from network by bringing down the link ) fig1 is a flowchart depicting the flow of a startup process of an internetwork device . the following description of the outbound packet forwarding process assumes that , in a redundant configuration with the internetwork device 100 a already operating , when the internetwork device 100 b is started up , outbound packets obp sent from the local network lnet are received by the internetwork device 100 b and sent to the global network gnet ( see fig4 ). in step s 1210 ( fig1 ), functioning of the address translation module ( i ) 104 b of the internetwork device 100 b is started up . in step s 1220 ( fig1 ), upon startup , the address translation module ( i ) 104 b of the internetwork device 100 b , via the line 122 , sends the address translation module ( i ) 104 a of the other internetwork device 100 a a control packet 400 requesting it to transfer address / port translation information . in step s 1230 ( fig1 ), the address translation module ( i ) 104 a of the other internetwork device 100 a that received the control packet 400 now sends the address translation module ( i ) 104 b a control packet 500 that contains the address / port translation information currently maintained by itself , in order to transfer the address / port translation information to the address translation module ( i ) 104 b of the internetwork device 100 b via the line 122 . in step s 1240 ( fig1 ), once the address translation module ( i ) 104 b of the internetwork device 100 b has acquired the address / port translation information contained in the received control packet 500 , it notifies its own routing controller 102 b of nat - enabled status . in step s 1250 ( fig1 ), the routing controller 102 b of the internetwork device 100 b having received notification of nat - enabled status uplinks to the packet i / f ( i ) 101 b . when the link from internetwork device 100 b to the packet i / f ( i ) 101 b is up , outbound packets obp sent from the internetwork local network lnet are received from the internetwork device 100 b through routing control in the local network lnet . on the other hand , when the link from the internetwork device 100 b to the packet i / f ( i ) 101 b is down , outbound packets obp sent from the local network lnet are received from the internetwork device 100 a through routing control in the local network lnet . according to the present embodiment , the internetwork device 100 b upon startup uplinks to the packet i / f ( i ) 101 b only if the address translation module ( i ) 104 b has nat - enabled status , thereby preventing packets from being discarded due to inability to carry out address translation of packets received from the packet i / f ( i ) 101 b . additionally , while the present embodiment described the outbound packet forwarding process , in the inbound packet forwarding process as well , discarding of inbound packets ibp can be prevented analogously by uplinking to the packet i / f ( o ) only after the address translation module ( o ) 105 has finished synchronizing address / port translation information according to the flowchart of fig1 . c - 3 . internetwork device startup process ( prevention of discarding of packets from network by route propagation ) fig1 is a flowchart depicting the flow of a startup process of an internetwork device . the following description of the outbound packet forwarding process assumes that , in a redundant configuration with the internetwork device 100 a already operating , when the internetwork device 100 b is started up , outbound packets obp sent from the local network lnet are received by the internetwork device 100 b and sent to the global network gnet ( see fig4 ). in step s 1310 ( fig1 ), functioning of the address translation module ( i ) 104 b of the internetwork device 100 b is started up . in step s 1320 ( fig1 ), upon startup , the address translation module ( i ) 104 b of the internetwork device 100 b , via the line 122 , sends the address translation module ( i ) 104 a of the other internetwork device 100 a a control packet 400 requesting it to transfer address / port translation information . in step s 1330 ( fig1 ), the address translation module ( i ) 104 a of the other internetwork device 100 a that received the control packet 400 now sends the address translation module ( i ) 104 b a control packet 500 that contains the address / port translation information currently maintained by itself , in order to transfer the address / port translation information to the address translation module ( i ) 104 b of the internetwork device 100 b via the line 122 . in step s 1340 ( fig1 ), once the address translation module ( i ) 104 b of the internetwork device 100 b has acquired the address / port translation information contained in the received control packet 500 , it notifies its own routing controller 102 b of nat - enabled status . in step s 1350 ( fig1 ), the routing controller 102 b of the internetwork device 100 b having received notification of nat - enabled status now advertises to the local network lnet the route to the destination address via the packet interface i / f ( i ) 101 b . with the route from the routing controller 102 b of the internetwork device 100 b advertised in this way , outbound packets obp sent from the internetwork local network lnet are received from the internetwork device 100 b through routing control in the local network lnet . on the other hand , if the route from the routing controller 102 b of the internetwork device 100 b is not advertised , outbound packets obp sent from the internetwork local network lnet are received from the internetwork device 100 a through routing control in the local network lnet . according to the present embodiment , upon startup , the routing controller of the internetwork device 100 b advertises to the local network lnet the route via the packet i / f ( i ) 100 b only if nat is enabled , thereby preventing packets from being discarded due to inability to carry out address translation of packets received from the packet i / f ( i ) 101 b . additionally , while the present embodiment described the outbound packet forwarding process , in the inbound packet forwarding process as well , discarding of inbound packets ibp can be prevented analogously by having the routing controller advertise to the global network gnet the route via the packet i / f ( o ) after the address translation module ( o ) 105 has finished synchronizing the address / port translation information according to the flowchart of fig1 . the present invention is not limited to the embodiments and aspects described above . the present invention may be worked in various aspects within limits that involve no departure from the spirit of the invention ; for example , the following modifications are possible . in the preceding embodiment , a combination of the conditions that “ the source address is an even number ” and “ the source address is an odd number ” are employed as the combination of the first condition and the second condition ; however , other combinations are possible . for example , a combination of conditions that “ the ones position of the source address is any digit from 0 to 4 ” and “ the ones position of the source address is any digit from 5 to 9 ” may be employed as the combination of the first condition and the second condition . alternatively , a combination of conditions that “ the ones position of the source address is either 0 or 1 ” and “ the ones position of the source address is any digit from 2 to 9 ” may be employed . it is preferable to monitor the load on each internetwork device 100 and to establish a combination of conditions such the load assigned to each internetwork device 100 may be adjusted to the desired value ( e . g . so that their respective loads are equal ). the combination of conditions may be reset at periodic intervals or on an as needed basis . as yet another alternative , a combination of the conditions that “ the destination address is an even number ” and “ the destination address is an odd number ” may be employed as the combination of the first condition and the second condition . because all of the fragmented packets contained in a same - source fragmented packet group share the same destination address , this combination of conditions also results in the packets meeting the same condition . other combinations of a first condition and a second condition that relate to information shared in common by all fragmented packets of a same - source fragmented packet group could be adopted as well . however , where a combination of conditions relating to the source address are employed as the first and second conditions as taught in the preceding embodiment , all packets sent from a given terminal , not just fragmented packets , are collected by the same internetwork device 100 , which is preferable in terms of packet management . while the preceding embodiment described an example of a redundant configuration in which two internetwork devices 100 with identical functions and features operate simultaneously ( double act configuration ), the present invention may be implemented in any redundant configuration in which n ( n is an integer equal to 3 or greater ) internetwork devices 100 operate simultaneously . in this case , a number n of conditions ranging from a first condition to an n - th condition would be established in manner analogous to the preceding embodiment , so that any packet meets one of the n conditions , and all of the fragmented packets included in a same - source fragmented packet group meet the same condition . packets received by any one of the internetwork devices 100 are then distributed to any of the n internetwork devices 100 based on the determination as to which of the n conditions they meet . with such an arrangement , fragmented packets can be processed correctly in instances where address translation takes place in a configuration with n internetwork devices operating simultaneously . some of the features implemented through hardware in the preceding embodiment may be replaced by software , and conversely some of the features implemented through software may be replaced by hardware .