Personal                                                     H. Soliman 
                                                            G. Tsirtsis 
                                                                Flarion 
Internet Draft                                     
Document: draft-soliman-v4v6-mipv4-00.txt                

Category: Standards Track                                 August 2003 
Expires: February 2004                             
    
 
                          Dual Stack Mobile IPv6 
                      draft-soliman-v4v6-mipv4-00.txt 
 
 
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by other 
   documents at any time. It is inappropriate to use Internet- Drafts 
   as reference material or to cite them other than as "work in 
   progress."  
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   This specification adds IPv4 extensions to Mobile IPv6 to allow dual 
   stack mobile nodes to roam within the Internet using Mobile IPv6 
   only while simultaneously maintaining connections using their IPv4 
   and IPv6 home addresses.  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
<Soliman and Tsirtsis>            1                                   
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
   Table of Contents 
    
1. Introduction.......................................................2 
1.1 Why Mobile IPv6 only?.............................................2 
2. Solution overview..................................................3 
2.1. Dynamic Home Agent Address Discovery.............................3 
2.2. Binding management...............................................4 
2.2.1 Visited network supports IPv6...................................4 
2.2.2 Visited network supports IPv4 only (public addresses)...........5 
2.3. Route optimization...............................................5 
2.4. Dynamic IPv4 home address allocation.............................6 
3. Extensions and modifications to Mobile IPv6........................6 
3.1. Binding update extensions........................................6 
3.1.1 IPv4 home address option........................................6 
3.2. Binding acknowledgement extensions...............................6 
3.2.1 IPv4 address acknowledgement option.............................7 
3.3. Mobile node operation............................................7 
3.4. Home agent operations............................................9 
3.5. Correspondent node operations...................................10 
4. Security considerations...........................................10 
5. References........................................................10 
Author's Addresses...................................................11 
    
    
    
1. Introduction 
    
   Mobile IPv6 allows mobile nodes to move within the Internet while 
   maintaining reachability and ongoing sessions, using an IPv6 home 
   address. However, since IPv6 is not widely deployed, it is unlikely 
   that mobile nodes will use IPv6 addresses only for their 
   connections. It is reasonable to assume that mobile nodes will, for 
   a long time, need an IPv4 home address that can be used by upper 
   layers. The current Mobile IPv6 specification does not allow mobile 
   nodes to use an IPv4 home address. Hence, this specification extends 
   Mobile IPv6 capabilities to allow dual stack mobile nodes to request 
   that their home agent (also dual stacked) tunnel IPv4/IPv6 packets 
   addressed to their home addresses, to their IPv4/IPv6 care-of 
   address(es).  
    
   As a result, mobile nodes only need Mobile IPv6 to manage mobility 
   while moving within the Internet. This specification provides the 
   extensions needed in order to allow Mobile IPv6 only to be used by 
   dual sack mobile nodes. 
    
1.1 Why Mobile IPv6 only? 
    
   IPv6 offers a number of improvements over todayÆs IPv4, primarily 
   due to its large address space. Mobile IPv6 offers a number of 
   improvements over Mobile IPv4, mainly due to capabilities inherited 
   from IPv6. For instance, route optimization and Dynamic home agent 
   discovery can only be achieved with Mobile IPv6.  
    
 
<Soliman and Tsirtsis>                                               2 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
   One of the advantages of the large address space provided by IPv6 is 
   that it allows mobile nodes to obtain a global care-of address 
   wherever they are. Hence, there is no need for NAT traversal 
   techniques designed for Mobile IPv4. This allows Mobile IPv6 to be a 
   significantly simpler and more bandwidth efficient mobility 
   management protocol.  
    
   All of the above benefits make the case for using Mobile IPv6 only 
   for dual stack mobile nodes.  
    
2. Solution overview 
    
   In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 
   the following needs to be done: 
    
   - Mobile nodes should be able to use an IPv4 and IPv6 home or care-
   of address simultaneously and update their home agents accordingly. 
    
   - Mobile nodes need to be able to know the IPv4 address of the home 
   agent as well as its IPv6 address. There is no need for IPv4 prefix 
   discovery however.  
 
   This section presents an overview of the extensions required in 
   order to allow mobile nodes to use Mobile IPv6 only for IP mobility 
   management.  
    
2.1. Dynamic Home Agent Address Discovery 
    
   Mobile IPv6 allows mobile nodes to discover their home agents by 
   appending a well-known anycast interface identifier to their home 
   linkÆs prefix. The mobile node sends a Mobile Prefix solicitation 
   and receives a Mobile Prefix Advertisement containing all prefixes 
   advertised on the home link.  
    
   To allow mobile nodes to use an IPv4 home address they need to be 
   configured with the home agentÆs IPv4 address and possibly with the 
   IPv4 home address. A dual stack mobile node MAY send a Mobile Prefix 
   Solicitation message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the 
   case where the mobile node has no access to IPv6 within the local 
   network. Securing such messages would require the mobile node to 
   have security association with the home agent, using IPsec (AH or 
   ESP) and based on the mobile nodeÆs IPv4 care-of address. However, 
   since the mobile node needs to encapsulate all IPv6 traffic into 
   IPv4, while located in an IPv4-only visited network, such SA would 
   affect all packets. That is, the SA selectors being the protocol 
   number (protocol is always IP in IP), as well as, source and 
   destination addresses are all common to all packets. Therefore, it 
   is RECOMMENDED that the mobile node does not use Dynamic Home Agent 
   Address Discovery when located in an IPv4-only network.  
    
   From the above discussion, it is clear that the mobile node will 
   need to be configured with its home agent addresses (IPv4 and IPv6) 
   and its home addresses. 
 
<Soliman and Tsirtsis>                                               3 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
 
2.2. Binding management 
    
   A dual stack mobile node will need to update its home agent with its 
   care-of address. If a mobile node has an IPv4 and an IPv6 home 
   address it will need to create a binding cache entry for each 
   address. The format of the IP packet carrying the binding update and 
   acknowledgement messages will vary depending on whether the mobile 
   node has access to IPv6 in the visited network. There are three 
   different scenarios to consider with respect to the visited network: 
    
   A. The visited network has IPv6 connectivity and provides the mobile   
      node with a care-of address (in a stateful or stateless manner),  
      in addition to IPv4 addresses (public or private).  
    
   B. The mobile node can only configure a globally unique IPv4 address 
      in the visited network.  
   C. The mobile node can only configure a private IPv4 address in the 
      visited network.  
    
   This specification is only concerned with cases A and B. Case C is 
   not supported by this specification. Case C can be supported if the 
   visited network provided IPv6 service, e.g. by introducing an ISATAP 
   router that provides global IPv6 connectivity. Binding management in 
   cases A and B is considered in the following sections. 
    
2.2.1 Visited network supports IPv6  
    
   In this case, the mobile node is able to configure a globally unique 
   IPv6 address. The mobile node will send a binding update to the IPv6 
   address of its home agent, as defined in [1]. The binding update 
   will include the IPv4 home address option introduced in this 
   document. After receiving the binding update, the home agent creates 
   two binding cache entries, one for the mobile nodeÆs IPv4 home 
   address, and another for the mobile nodeÆs IPv6 home address. Both 
   entries will point to the mobile nodeÆs IPv6 care-of address. Hence, 
   whenever a packet is addressed to the mobile nodeÆs IPv4 or IPv6 
   home addresses, it will be tunneled in IPv6 to the mobile nodeÆs 
   IPv6 care-of address included in the binding update. Effectively, 
   the mobile node establishes two different tunnels, one for its IPv4 
   traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 
   with a single binding update. The security implications of this 
   mechanism are discussed in the security considerations section. 
    
   In this scenario, the only addition to [MIPv6] is the inclusion of 
   the IPv4 home address option in the binding update message.  
    
   After accepting the binding update and creating the corresponding 
   binding cache entries, the home agent MUST send a binding 
   acknowledgement to the mobile node as defined in [MIPv6]. In 
   addition, if the binding update included an IPv4 home address 
   option, the binding acknowledgement MUST include the IPv4 address 
   acknowledgment option as described later in this specification. This 
 
<Soliman and Tsirtsis>                                               4 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
   option informs the mobile node whether the binding was accepted for 
   the IPv4 home address. If this option is not included in the binding 
   acknowledgement and the IPv4 home address option was included in the 
   binding update, the mobile node MUST assume that the home agent does 
   not support the IPv4 home address option and therefore SHOULD NOT 
   include the option in future binding updates to that home agent 
   address.  
    
   The routing header in the binding update MUST include the mobile 
   nodeÆs IPv6 home address as specified in [MIPv6]. 
    
2.2.2 Visited network supports IPv4 only (public addresses) 
    
   In this scenario the mobile node will need to tunnel IPv6 packets 
   containing the binding update to the home agentÆs IPv4 address. The 
   mobile node uses the IPv4 address it gets from the visited network 
   as a source address in the outer header. The binding update will 
   contain the mobile nodeÆs IPv6 home address in the home address 
   option. However, since the care-of address in this scenario is the 
   mobile nodeÆs IPv4 address, the mobile node MUST include its IPv4 
   care-of address in the IPv6 packet. The IPv4 address is represented 
   in an IPv4-mapped IPv6 address and is included in the source address 
   field of the IPv6 header.  
    
   If the mobile node had an IPv4 home address, it MUST also include 
   the IPv4 home address option described in this specification.  
    
   After accepting the binding update, the home agent MUST create a new 
   binding cache entry for the mobile nodeÆs IPv6 home address. If an 
   IPv4 home address option were included, the home agent MUST create 
   another entry for that address. All entries MUST point to the mobile 
   nodeÆs IPv4 care-of address. Hence, all packets addressed to the 
   mobile nodeÆs home address(es) (IPv4 or IPv6) will be encapsulated 
   in an IPv4 header that includes the home agentÆs IPv4 address in the 
   source address field and the mobile nodeÆs IPv4 care-of address in 
   the destination address field.  
    
   After accepting the binding updates and creating the corresponding 
   entries, the home agent MUST send a binding acknowledgement as 
   specified in [MIPv6]. In addition, if the binding update included an 
   IPv4 home address option, the binding acknowledgement MUST include 
   the IPv4 address acknowledgment option as described later in this 
   specification. The binding update is encapsulated to the IPv4 care-
   of address (represented as an IPv4-mapped IPv6 address in the 
   binding update).  
 
2.3. Route optimization  
    
   Route optimization, as specified in [MIPv6] will operate in an 
   identical manner for dual stack mobile nodes when they are located 
   in a visited network that provides IPv6 addresses to the mobile 
   node. However, when located in an IPv4-only network, route 

 
<Soliman and Tsirtsis>                                               5 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
   optimization will not be possible. Therefore, mobile nodes will need 
   to communicate through the home agent.  
    
   Route optimization will not be possible for IPv4 traffic. That is, 
   traffic addressed to the mobile nodeÆs IPv4 home address. This is 
   similar to using Mobile IPv4, therefore there is no reduction of 
   features resulting from using this specification. 
    
2.4. Dynamic IPv4 home address allocation 
    
   It is possible to allow for the mobile nodeÆs IPv4 home address to 
   be allocated dynamically. This is done by including 0.0.0.0 in the 
   IPv4 home address option included in the binding update. The home 
   agent SHOULD allocate an IPv4 address to the mobile node and include 
   it in the IPv4 address acknowledgement option sent to the mobile 
   node. In this case, the lifetime of the binding is bound to the 
   minimum of the lifetimes of the IPv6 binding and the lease time of 
   the IPv4 home address.   
    
3. Extensions and modifications to Mobile IPv6 
 
   This section highlights the protocol and implementation additions 
   required to support this specification.  
 
3.1. Binding update extensions 
    
3.1.1 IPv4 home address option 
    
   This option is included in the Mobility Header including the binding 
   update message sent from the mobile node to a home agent or Mobility 
   Anchor Point. 
 
 
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      |     Type      |    Length     |   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     IPv4 home address                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
   Type                 TBD 
   Length               1 
   IPv4 home address    The mobile nodeÆs IPv4 home address that should  
                        be defended by the home agent. This field could  
                        contain any unicast IPv4 address (public or  
                        private) that was assigned to the mobile node.  
                        The value 0.0.0.0 is used to request an IPv4  
                        home address from the home agent.  
 
3.2. Binding acknowledgement extensions 
    
 
<Soliman and Tsirtsis>                                               6 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
3.2.1 IPv4 address acknowledgement option 
 
   This option is included in the Mobility Header including the binding 
   acknowledgement message sent from the home agent or Mobility Anchor 
   Point to the mobile node. This option indicates whether a binding 
   cache entry was created for the mobile nodeÆs IPv4 address. 
   Additionally, this option can include an IPv4 home address in case 
   the mobile node was not configured with one (i.e. if the unspecified 
   IPv4 address was included in the binding update).  
 
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Type      |    Length     |   Status      |Reserved       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      IPv4 home address                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Type                 TBD 
    
   Length               1 
    
   Status               Indicates success or failure for the IPv4 home  
                        address binding. Values from 0 to 127 indicate  
                        success. Higher values indicate failure. The  
                        following values are reserved: 
                                0   Success 
                                128 Failure, reason unspecified 
                                129 Administratively prohibited 
                                130 Incorrect IPv4 home address 
                                131 Invalid IPv4 address  
                                132 Dynamic IPv4 home address  
                                    assignment not available 
    
   IPv4 home address    The IPv4 home address that the home agent will  
                        use in the binding cache entry. This could be a  
                        public or private address. This field MUST  
                        always contain the mobile nodeÆs IPv4 address.  
                        If the address were dynamically allocated the  
                        home agent will add the address to inform the  
                        mobile node. Otherwise, if the address were  
                        statically allocated to the mobile node, the  
                        home agent will copy it from the binding update  
                        message.  
 
3.3. Mobile node operation 
 
   In addition to the operations specified in [MIPv6], this 
   specification requires mobile nodes to be able to support an IPv4 
   home address. The IPv4 home address is never sent in the IPv4-mapped 
   IPv6 address format. This is primarily done to save bandwidth. 
   However, to simplify the mobile nodeÆs implementation, they SHOULD 
   store the IPv4 home address in the binding update list, using the 
 
<Soliman and Tsirtsis>                                               7 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
   IPv4-mapped IPv6 format. Mobile nodes are also required to be 
   configured with the home agentÆs global IPv4 address. 
    
   When sending an IPv6 packet containing a binding update while 
   connected to an IPv4-only access network, mobile nodes MUST ensure 
   the following: 
    
   - The IPv6 packet is encapsulated in an IPv4 packet 
   - The source address in the IPv4 header is the mobile nodeÆs IPv4  
     care-of address 
   - The destination address in the IPv4 header is the home agentÆs  
     IPv4 address.  
   - The source address in the IPv6 header is the mobile nodeÆs IPv4- 
     mapped IPv6 address. That is, the same IPv4 address in the outer  
     header is placed in the IPv6 header using the mapped address  
     format. 
   - The home address option contains the IPv6 home address as  
     specified in [MIPv6]. 
   - The IPv4 home address option MAY be included in the mobility   
     header. This option contains the IPv4 home address. If the mobile   
     node did not have a static home address it MAY include the  
     unspecified IPv4 address, which acts as a request for a dynamic  
     IPv4 home address. 
   - The IPv6 packet MUST be authenticated as per [MIPv6], based on the  
     mobile nodeÆs IPv6 home address. 
    
   When sending a binding update from a visited network that supports 
   IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In 
   addition, if the mobile node has an IPv4 home address or needs one, 
   it should include the IPv4 home address option in the mobility 
   header. If the mobile node already has a static IPv4 home address, 
   such address MUST be included in the IPv4 home address option. 
   Otherwise, if the mobile node needs a dynamic IPv4 address, it 
   should include the IPv4 unspecified address in the IPv4 home address 
   option.  
    
   When the mobile node receives a binding acknowledgement from the 
   home agent, it should follow the rules in [MIPv6]. In addition, the 
   following actions MUST be made: 
    
   - If the mobility header includes and IPv4 address acknowledgement   
     option indicating success, the mobile node should create two  
     entries in its binding update list, one for the IPv6 home address  
     and another for the IPv4 home address.  
   - If no IPv4 address acknowledgement option were present, and an  
     IPv4 home address option was present in the binding update, the  
     mobile node MUST only create one binding update list entry for its  
     IPv6 home address. The mobile node MAY include the IPv4 home  
     address option in future binding updates. 
   - If an IPv4 address acknowledgement option were present and it  
     indicates failure for the IPv4 home address binding, the mobile   
     node MUST NOT create an entry for that address in its binding  
     update list. The mobile node MAY include the IPv4 home address  
 
<Soliman and Tsirtsis>                                               8 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
     option in future binding updates. 
    
   Note that a mobile node complying with this specification MUST 
   configure an IPv4-mapped IPv6 address on its interface in the 
   visited network. This is needed in order to allow the mobile node to 
   receive binding acknowledgements from its home agent while located 
   in an IPv4-only network. 
    
3.4. Home agent operations 
    
   In addition to the home agent specification in [MIPv6], the home 
   agent needs to be able to process the IPv4 home address option and 
   generate the IPv4 address acknowledgement option. Both options are 
   included in the mobility header.  
    
   In order to comply with this specification, the home agent MUST be 
   able to find the IPv4 home address of a mobile node when given the 
   IPv6 home address. That is, given an IPv6 home address, the home 
   agent MUST store the corresponding IPv4 home address if a static one 
   is present. If a dynamic address were requested by the mobile node, 
   the home agent MUST store that address (associated with the IPv6 
   home address) after itÆs allocated to the mobile node. 
    
   When the home agent receives a binding update containing the IPv4 
   home address option, it needs to follow all the steps in [MIPv6], in 
   addition, the following checks MUST be done: 
    
   - If the IPv4 home address option contains a valid unicast IPv4  
     address, the home agent MUST check that this address is allocated  
     to the mobile node that has the IPv6 home address included in the  
     home address option.  
    
   - If the IPv4 home address option contained the unspecified IPv4  
     address, the home agent SHOULD dynamically allocate and IPv4 home  
     address to the mobile node. If none is available, the home agent  
     MUST return an appropriate error code in the status field of the  
     IPv4 address acknowledgement option. 
    
   - If the binding update is accepted for the IPv4 home address, the  
     home agent MUST create a binding cache entry for the IPv4 home  
     address. The IPv4 home address MAY be stored in the IPv4-mapped  
     IPv6 address format. The home agent MUST include an IPv4  
     acknowledgement option in the mobility header containing the  
     binding acknowledgement. 
    
   If the binding update is accepted for both IPv4 and IPv6 home 
   addresses, the home agent MUST create two separate binding cache 
   entries, on for each home address. The care-of address is the one 
   included in the binding update. If the care-of address is an IPv4-
   mapped IPv6 address, the home agent MUST setup a tunnel to the IPv4 
   care-of address of the mobile node. 
    

 
<Soliman and Tsirtsis>                                               9 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
   When sending a binding acknowledgement to the mobile node, the home 
   agent would construct the message according to [MIPv6]. Note that 
   the routing header MUST always contain the IPv6 home address as 
   specified in [MIPv6].  
    
   If the care-of address of the mobile node were an IPv4 address, the 
   home agent MUST include this address in the destination address in 
   the IPv6 header using the IPv4-mapped IPv6 format. The home agent 
   MUST then encapsulate the packet in an IPv4 header. The source 
   address is set to the home agentÆs IPv4 address and the destination 
   address is set to the mobile nodeÆs IPv4 care-of address.  
    
   After creating a binding cache entry for the mobile nodeÆs home 
   addresses. All packets sent to the mobile nodeÆs home addresses are 
   tunneled by the home agent to the mobile nodeÆs care-of address. If 
   the care-of address is an IPv4 address, packets are encapsulated in 
   an IPv4 header. Note that the mapped address format is not used to 
   encapsulate the mobile nodeÆs traffic. The mapped address format is 
   only used when sending binding acknowledgements to the mobile node. 
    
3.5. Correspondent node operations 
    
   The specification has no impact on IPv4 or IPv6 correspondent nodes. 
    
4. Security considerations 
    
   This specification allows a mobile node to send one binding update 
   for its IPv6 and its IPv4 home address. This is a slight deviation 
   from [MIPv6] which requires one binding update per home address. 
   However, like [MIPv6], the IPsec security association needed to 
   authenticate the binding update is till based on the mobile nodeÆs 
   IPv6 home address. Therefore, in order to authenticate the mobile 
   nodeÆs IPv4 home address binding, the home agent MUST store the IPv4 
   address corresponding to the IPv6 address that is allocated to a 
   mobile node. Therefore, it is sufficient for the home agent to know 
   that the IPsec verification for the packet containing the binding 
   update was valid provided that it knows which IPv4 home address is 
   associated with which IPv6 home address. Hence, the security of the 
   IPv4 home address binding is the same as the IPv6 binding.  
    
   In effect, associating the mobile nodeÆs IPv4 home address with its 
   IPv6 home address moves the authorization of the binding update for 
   the IPv4 address to the Mobile IPv6 implementation, which infers it 
   from the fact that mobile node has an IPv6 home address and the 
   right credentials for sending an authentic binding update for such 
   address.  
    
5. References 
    
   [IPv6] S. Deering and B. Hinden, ôInternet Protocol version 6 (IPv6)   
          specificationö, RFC 2460  
    
   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate 
 
<Soliman and Tsirtsis>                                              10 
                       <Dual Stack Mobile IPv6>        <August> <2003> 
 
 
                Requirement Levels", BCP 14, RFC 2119, March 1997. 
 
   [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 
    
   [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in   
           IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. 
    
Author's Addresses 
    
   Hesham Soliman 
   Flarion Technologies 
   Phone:  +61400500321 
   E-mail: H.Soliman@Flarion.com 
    
   George Tsirtsis 
   Flarion Technologies 
   Phone: +44-20-88260073 
   Email1: G.Tsirtsis@Flarion.com 
   Email2: tsirtsisg@yahoo.com 
 
 
































 
<Soliman and Tsirtsis>                                              11