in fig2 a , which is similar to fig1 a mobile terminal mn 28 has a fa 30 . cn 24 has a ha 26 ; the figure illustrates fa coa mode . in fig2 b , the mode is co - coa , therefore there is no fa and packets pass directly to mn 28 . it will be seen that , in comparison with fig1 fig2 a and 2 b do not have a tunnel from ha 26 towards either fa 30 or mn 28 . this is because in the inventive arrangement the packets are not encapsulated and therefore no tunnel is needed . a suitable name and acronym for the inventive technique is non - encapsulation mobile internet protocol , nemip . in fig3 a , a packet 30 conventionally addressed to a mobile in a foreign network has as source address 32 the ip address of cn 24 ; and as destination address 34 the home address of mn 28 ; fig3 a also illustrates payload 38 and other fields 36 . in fig3 b , in a header according to the invention , the source address 32 is the address of ha 26 and the destination address 34 is the coa of mn 28 . the header contains two new fields , 40 , 42 , containing respectively identifiers ( id ) for cn 24 and mn 28 . when the network is operating in fa coa as illustrated in fig2 a , the re - addressed packet is received by the fa 30 and the mn id 42 is used by the fa to distinguish the different mobile nodes which are simultaneously using that fa , and the packet is routed to mn 28 . when the re - addressed packet is received by fa 30 ( for fa coa mode ), fig2 a ) or by mn 28 ( for co - coa mode , fig2 b ), the cnid 40 is used by the fa or the mn to recover the original source address , i . e . the address of the cn 24 ; the fa 30 or the mn 28 then re - calculates the checksum of the packet , and delivers it to an application . considering now the cnid 40 , this unique identifier is allocated by ha 26 as soon as a packet addressed to the address of mobile is detected . the ha 26 adds an entry to an address mapping table of cnids and cns , which is maintained by ha 26 . then the ha 26 sends the cnid plus the ip address of the correspondent cn to fa 30 ( fa coa mode ) or to mn 28 ( co - coa mode ); either a registration reply message , or a separate cnid notification message can be used . when the cnid is received by fa 30 or by mn 28 , an entry is added to a cnid - to - cn ip address mapping table which is maintained by the fa or mn . as each packet destined for mn 28 arrives at ha 26 , the ha looks up the cnid and cn address mapping table to find the cnid corresponding to the source address on the packet ; the ha then replaces the original source address with the ha address , and the destination address with the coa of mn 28 . the ha 26 adds a cnid field 40 and an mn id field 42 , adjusts the packet checksum , and dispatches the packet . when the packet arrives at the fa 30 or mn 28 , the cnid - to - cn table is looked up and the source address of the ha 26 is replaced by the real address of cn 24 , and the destination address is replaced with the home address of the mobile . for fa coa mode , the mnid - to - mn table is looked up , as explained above . the checksum is adjusted and the packet is delivered to the mn 28 ( for fa coa working ) or to an application ( for co - coa mode ). the cnid and mnid formats can be very short and simple , so that the additional fields do not substantially increase the header length . the method of packet heading according to the invention for a mobile in a foreign network retains the advantage of shorter headers , and higher payloads , in common with the invention set out in the copending patent application no . 99301437 . 2 referred to above . since the ha address is used as the source address , the problems caused during egress filtering by using a source address different from the home network address can be avoided . since the destination address is changed back before a packet is delivered , an application to which the packet is delivered does not need to be reconfigured , so irritating stops and re - starts of the application are avoided . a further advantage is that only the source and destination addresses of the header are changed ; all other information is unchanged , including information identifying the traffic flows from the ha 26 to the current coa of mn 28 . it is therefore possible to adopt a standard qos arrangement , such as rsvp , without modification to provide qos services to the mobile . a qos session will now be described using rsvp as an example . in fig4 the cn 24 and ha 26 are associated with home network 50 , and the mn 28 and fa 30 are associated with a foreign network 52 . the rsvp session is set up as two parts , shown as section 1 and section 2 on the figure ; section 1 operates between the cn 24 and the ha 26 , and section 2 operates between the ha 26 and mn 28 . section 1 is set up as a normal rsvp session in a non - mobile environment , with a path message sent from cn 24 to ha 26 ; the difference in the inventive arrangement is that the return resv message from the ha 26 to cn 24 is not initiated until section 2 has been completed . section 2 covers the mn 28 , and is dynamically adapted as the mobile moves from one network to another . when ha 26 receives the path message from the cn 28 , with the source and destination address being the cn 24 and the home address of mn 28 , the ha 26 intercepts the packet and modifies or regenerates a path message via an rsvp proxy server by re - addressing the packet as described above . the packet passes through a number of nodes or network routers , and two routers , 54 , 56 are illustrated . the path message is an end - to - end message . the proxy server can be attached to ha 26 or it can be a separate entity . in foreign network 52 , a foreign proxy server or its equivalent in the mn 28 or fa 30 , depending on the working mode , prepares a resv message with the coa address of mn 28 as the source address and the ha &# 39 ; s destination address ; the message contains flow identification information such as protocol id as well as source / destination port numbers , and is dispatched . the resv message is routed hop - by - hop through the same servers 54 , 56 as the path message , but in the reverse direction ; the source and destination addresses for each hop are changed appropriately by the routers 54 , 56 . when the resv message is received by ha 26 , or an equivalent such as a home network proxy server , the resv message is modified or re - generated with the home address of mn 28 as source address and the cn 24 as destination address ; i . e . section 2 is completed . the resv message of section 1 is now sent in conventional manner . when the cn 24 or the home network proxy server receives the resv message , a resv confirmation message can , if requested , be sent to confirm the whole rsvp session . when the mode of working is fa coa , to guarantee flow - specific identity , and this class of service differentiation , for section 2 of the rsvp session , port clash avoidance control is necessary ; this can be achieved by any conventional method .