NGTRANS WG Shiao-Li Tsao Internet Draft CCL, ITRI Document: draft-ietf-ngtrans-moving-00.txt George Tsirtsis Category: Informational Flarion Technologies Expires: January 2002 Wolfgang Boehm Siemens July 2001 Moving in a Dual Stack Internet 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 document provides an analysis of the requirements to support mobility of hosts in IPv4 and IPv6 networks. In this document, combinations of IPv4, IPv6, and dual stack mobile node moving in IPv4, IPv6, and dual stack networks are listed and requirements to support mobility under different network and mobile node configurations are examined. This document aims to reassess existing next generation transition (NGTRANS) tools from the point of view of mobility. 1. Introduction Mobile IP (MIP) is capable of offering mobile services to terminals. Mobile IPv4 (MIPv4) [1] was designed for Internet Protocol version 4 (IPv4) and mobile IPv6 (MIPv6) [2] has been also defined for IPv6. Considering IPv4 to IPv6 transition, a number of protocols and mechanisms are proposed to facilitate IPv4/IPv6 communication in transition networks for different purposes and under different assumptions. 1 [3] gives an overview of transition mechanisms within IETF NGTRANS working group. However, these transition mechanisms assume that hosts are attached to the network statically. The effects of considering mobile node (MN) roaming in IPv4/IPv6 transition networks have not been investigated. In this document, requirements to support mobility of hosts in IPv4 and IPv6 networks are analyzed. Combinations of mobile nodes moving in networks with different configurations are first listed and then mechanisms to support handoffs in different scenarios are examined. This document does not introduce new protocols and mechanisms, but recommend implementations and configurations for some specific handoffs. The principles behind this analysis are to maintain existing connection of mobile nodes after handoff as much as possible, and to maximize accessibility to the visited networks. Moreover, tunneling mechanism is preferred rather than translators due to security concern. Finally, route optimization is also considered. 2. Terminology IPv4-only network A network that only implements IPv4. It can understand and process IPv4 packets and MIPv4 messages but can not understand IPv6 and MIPv6. IPv6-only network A network that only implements IPv6. It can understand and process IPv6 packets and MIPv6 messages but can not understand IPv4 and MIPv4. Dual stack network (DS network) A network that implements both IPv4 and IPv6. It can understand and process both IPv4/IPv6 packets and MIPv4/MIPv6 messages. IPv4-only mobile node (IPv4-only MN) A node that implements IPv4, MIPv4 and has a global unique IPv4 address. IPv6-only mobile node (IPv6-only MN) A node that implements IPv6, MIPv6 and has a global unique IPv6 address. Dual stack mobile node using IPv4 address (DS MNv4) A node that has IPv4/IPv6 dual stack and a global unique IPv4 address. The node can change its point of attachment from one link to another, while still being reachable via its IPv4 address. Dual stack mobile node using IPv6 address (DS MNv6) A node that has IPv4/IPv6 dual stack and a global unique IPv6 address. The node can change its point of attachment from one link to another, while still being reachable via its IPv6 address. 2 IPv4-compatible IPv6 address An address of the form 0::0:a.b.c.d which refers to an IPv6/IPv4 node that supports automatic tunneling. 3. Combination Table 1 lists all combinations of mobile node and its located networks. Definitions of categories of mobile nodes and networks can be referred to the terminologies defined in the previous section. For example, Combination 1 is the case that an IPv6-only mobile node stays in an IPv6-only network. The case of a MN with both IPv4 and IPv6 address is not in the list since the MN can perform MIPv4 and MIPv6 functions separately depending on the networks it visits. The case does not introduce problems for MN roaming in IPv4/IPv6/DS network. Among twelve combinations, Combination 2 and Combination 5 will result in the loss of connectivity of MN to the network. In the next section, handoff scenarios based on the remaining 10 combinations are examined. Table 1. List of combination of mobile node and its Located networks ---------------------------------------------------- Combination Mobile Node Located Network ---------------------------------------------------- 1 IPv6-only IPv6-only 2(*) IPv4-only IPv6-only 3 DS MNv6 IPv6-only 4 DS MNv4 IPv6-only 5(*) IPv6-only IPv4-only 6 IPv4-only IPv4-only 7 DS MNv6 IPv4-only 8 DS MNv4 IPv4-only 9 IPv6-only DS Network 10 IPv4-only DS Network 11 DS MNv6 DS Network 12 DS MNv4 DS Network ---------------------------------------------------- 4. Handoff Scenarios In this section, procedures and mechanisms to fulfill handoffs are examined. Handoff is defined as a MN moving from one network to another network. The handoff procedures include the registration of MN's care-of address (COA) to its home agent and the maintenance of the existing connections, said native connections, to its correspondent nodes (CN). This document emphasizes on MIP registration process and maintaining the native connections between MN and its CNs during handoff. 3 4.1 Handoffs of IPv6-only MN Table 2. List of handoffs of IPv6-only MN and mechanisms can be applied to the communications with CNs. --------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN --------------------------------------------------------- IPv6-only IPv6-only TR NA6 IPv6-only DS TR NA6 DS IPv6-only TR NA6 DS DS TR NA6 --------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA6 : Native IPv6 For IPv6-only MN, there are four handoff scenarios. That is, from an IPv6-only network to another IPv6-only network, from an IPv6-only network to a DS network, from a DS network to an IPv6-only network, and from a DS network to another DS network. Table 2 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. While moving to a visited IPv6-only or DS network, IPv6- only MN can access the network and send MIPv6 messages to its home agent to perform MIP registration. Then, the mobile node can be reached via its IPv6 address even moving to a visited network. Considering existing connections, IPv6- only and DS CNs can communicate with the MN using native IPv6. As for IPv4-only CNs, communication should go through the translators in the MN's home network and then be tunneled to the visited network. In summary, there is no problem introducing due to handoffs of IPv6-only MNs in an IPv6-only or DS networks. 4.2 Handoffs of IPv4-only MN Table 3. List of handoffs of IPv4-only MN and mechanisms can be applied to the communications with CNs. -------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN -------------------------------------------------------- IPv4-only IPv4-only NA4 TR IPv4-only DS NA4 TR DS IPv4-only NA4 TR DS DS NA4 TR --------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA4 : Native IPv4 4 For IPv4-only MN, there are four handoff scenarios. That is, from an IPv4-only network to another IPv4-only network, from an IPv4-only network to a DS network, from a DS network to an IPv4-only network, and from a DS network to another DS network. Table 3 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. The situations are quite similar as that of IPv6-only MN. IPv4-only MN moves to a visited IPv4-only or DS network, and performs MIPv4 registration. Regarding of existing connections, IPv4-only CNs can communicate with MN using native IPv4. For communication between MN and IPv6-only CNs, packets have to go to translators in the MN's home network first and then be tunneled to the visited network. As for DS CN, DS CN can use native IPv4 to talk to IPv4-only MN or request an IPv4 address as well as Tunnel End Point (TEP) via DSTM[6] and send IPv4 packets encapsulated in IPv6 to IPv4-only MN. In summary, there is no new problem Introduced in this category. 4.3 Handoffs of DS MNv6 Table 4. List of handoffs of DS MNv6 and mechanisms can be applied to the communications with CNs. -------------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN -------------------------------------------------------------- IPv6-only IPv6-only TR, DSTM NA6 IPv6-only DS TR, DSTM NA6 DS IPv6-only TR, DSTM NA6 DS DS TR, DSTM NA6 IPv6-only IPv4-only DSTM(v6), NA4(v4) NA6 IPv4-only IPv6-only DSTM(v6), NA4(v4) NA6 IPv4-only IPv4-only NA4 NA6 IPv4-only DS NA4 NA6 DS IPv4-only NA4 NA6 --------------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA4 : Native IPv4 NA6 : Native IPv6 (v6) : in IPv6-only network (v4) : in IPv4-only network Table 4 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. For a DS MNv6, two sub-categories of handoff are further classified. The first sub-category of handoff includes DS MNv6 moving from an IPv6-only network to another IPv6- only network, from an IPv6-only network to a DS network, from a DS network to an IPv6-only network, and from a DS network to another DS network. This sub- category is very similar to that of IPv6-only MN handoff. DS MNv6 can access IPv6-only and DS networks and perform MIPv6 registration. The difference is the communication between MN and IPv4-only CNs. Since MN is dual stack, MN can request an IPv4 address via DSTM and send IPv4 packets encapsulated in IPv6 to IPv4- only CNs through TEP. Then, translator is no more necessary. 5 Imagine a DS MNv6 that only performs MIPv6 registration and not MIPv4. While stationary and at home the MN does not use its MIPv6 capabilities and thus looks like a regular Dual Stack node. In an environment like that, one of the most appealing interoperability mechanisms proposed by the NGTRANS WG is called[6]. DSTM allows a dual stack node to use DHCPv6 [8] to configure on demand its IPv4 stack. This offers high utilization of IPv4 address space and no requirements for IPv4 support in the domain. Additionally, while the node has an IPv4 address, it can communicate with IPv4-only nodes without the use of Protocol Translators and/or Address Translators. DSTM has been mainly designed for stationary dual stack nodes. We will now examine how a DS MNv6 can take advantage of DSTM in a mobile environment. It is clear that if the DS MNv6 is not moving, DSTM can be directly applicable i.e., the DS MNv6 can use DHCPv6 over MIPv6 to communicate with the DSTM server in the home network and request an IPv4 address. The problem is that while MIPv6 can "move" the mobile's IPv6 stack between access points in the network, it is not obvious how it can move the IPv4 stack of the same DS MNv6. [6] assumes that IPv4 routing is not available in the DSTM domain. The Dynamic Tunneling Interface (DTI) is defined as an interface that encapsulates IPv4 packets into IPv6 packets. The TEP is also defined as the destination of the IPv6 packet containing an IPv4 packet. Providing the DS MNv6 knows where the TEP is, in the domain it happens to be in, it can use MIPv6 to send an encapsulated IPv4 packet to the IPv4-only CN. DS MNv6 essentially uses its MIPv6 COA in the foreign domain to request an IPv4 address (and the local TEP) from the local DHCPv6 server. It then uses MIPv6 to communicate with the local TEP and encapsulate IPv4 packets destined to external IPv4-only nodes. Even if DS MNv6 moves to a new Access Router in this domain, a BU to the TEP will allow the IPv6 tunnel and the IPv4 packets it encapsulates to be maintained. Note that like [9] the level of IPv6 connectivity offered by the above combination is very similar to MIPv4 without route optimization since the IPv4 address used is in fact a dynamically allocated IPv4 Home Address. Also like [9], MIPv6 Route optimization is of course used for the path between the MN and the TEP in that domain. It might also be possible for the MN to use the Home DHCPv6 server when in a foreign domain e.g: if the foreign domain does not support DHCPv6. This would require DHCPv6 request to be sent through the Home Agent of the MN. The reply would then include an IPv4 address and a TEP address from the home domain. Data would have to be sent from the MN to the HA, then to the TEP and eventually to the CN. 6 Second sub-category of handoffs are DS MNv6 moving from an IPv6-only network to an IPv4-only network, from an IPv4-only network to an IPv6-only network, from an IPv4-only network to another IPv4-only network, from an IPv4-only network to a DS network, and from a DS network to an IPv4-only network. In this sub-category, a MN that registered an IPv6 address moves to an IPv4- only network. Suppose a mobile node registers an IPv6 address and moves to an IPv4- only network. The mobile node can still receive IPv6 packets from IPv4- only network if IPv4-only network implements 6over4 [10] on the boundary routers. However, if IPv4-only network does not implement 6over4 mechanism, the mobile node cannot receive IPv6 packets. Since the mobile node is IPv4/IPv6 dual stack, it receives foreign agent advertisement messages from the IPv4 protocol stack. The MN detects the movement to an IPv4-only network without 6over4. The MN asks for a co-located IPv4 COA by certain mechanisms. Once it has an IPv4 COA, it generates an IPv4-compatible IPv6 address and also obtains the IPv4 address of its home agent located in IPv6 home network. The IPv4 COA can be obtained by DHCP or some other dynamic address allocation schemes [4][8]. The address allocation issue is out of the scope of this document. In this case, MIPv6 home agent MUST broadcast its IPv6 as well as its IPv4 address by home agent advertisement. Once MN received the HA advertisement, it MUST keep both IPv6 and IPv4 addresses of its home agent. After the MN has these addresses, it sends MIPv6 binding update (BU) encapsulated in IPv4 packets to its home agent. Here, we assume that home agent is IPv4/IPv6 dual stack. The IPv6 home agent decapsulates the MIPv6 BU and updates the new COA of the mobile node. Packets to the MN will go to the home agent first, and then be tunneled to the visited network. The MN receives and decapsulates the packets. The procedures are summarized as: o In IPv6-only network, IPv6 packets are received and processed by IPv6 protocol stack on a mobile node. o MN received home agent advertisement with HA's IPv4 and IPv6 addresses, it keeps both two addresses. o The MN, which moves to an IPv4-only network without 6over4 support, receives the agent advertisement from MIPv4 foreign agent via the IPv4 protocol stack. o The mobile node obtains an IPv4 COA by certain mechanisms. It generates the IPv4-compatible IPv6 address. MN also has the IPv4 address of the MIPv6 home agent. 7 o The MN sends MIPv6 BU encapsulated in IPv4 packets to its home agent. The home agent decapsulates the MIPv6 BU messages and updates the COA of the mobile node. o Packets to the mobile node will go to its home network, and then be tunneled to the visited network. Then, packets are encapsulated in IPv4 and sent to MN. Regarding of moving to IPv6-only or DS networks from IPv4-only networks, DS MNv6 releases IPv4 COA and registers a new IPv6 COA or deregisters with its home agent. 4.4 Handoffs of DS MNv4 Table 5. List of handoffs of DS MNv4 and mechanisms can be applied to the communications with CNs. ---------------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN ---------------------------------------------------------------- IPv4-only IPv4-only NA4 NA6(in), TR(out) IPv4-only DS NA4 NA6(in), TR(out) DS IPv4-only NA4 NA6(in), TR(out) DS DS NA4 NA6 IPv4-only IPv6-only NA4 NA6(in), TR(out) IPv6-only IPv4-only NA4 NA6(in), TR(out) IPv6-only IPv6-only NA4 NA6 IPv6-only DS NA4 NA6 DS IPv6-only NA4 NA6 ---------------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA4 : Native IPv4 NA6 : Native IPv6 (in) : CN originated (out) : MN originated Table 5 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. For a DS MNv4, two sub-categories of handoff are also classified. First sub-category includes DS MNv4 moving from an IPv4-only network to another IPv4-only network, from an IPv4-only network to a DS network, from a DS network to an IPv4- only network, and from a DS network to another DS network. This sub- category is very similar to that of the IPv4-only MN handoff. DS MNs can access IPv4-only and DS networks, and perform MIPv4 registration procedure to its IPv4 home agent. The difference is the communication between MN and IPv6-only CNs. Since MN is dual stack, MN can use its own IPv4- compatible IPv6 address to talk to IPv6-only CNs without introducing translators. 8 Second sub-category of handoffs are DS MNv4 moving from an IPv4-only network to an IPv6-only network, from an IPv6-only network to an IPv4-only network, from an IPv6-only network to another IPv6-only network, from an IPv6-only network to a DS network, and from a DS network to an IPv6-only network. In this sub-category, a mobile node that registered an IPv4 address as its home address moves to an IPv6-only network. If the IPv6-only network supports DSTM [6], the mobile node can ask for a co-located COA, obtain TEP, and then send MIPv4 registration request encapsulated in IPv6 packets to its home agent. Then, the registration procedure is complete. If the IPv6-only network does not support DSTM, the DS MNv4 cannot receive IPv4 agent advertisement and fails in the registration process to its home network. Since the mobile node is IPv4/IPv6 dual stack, it still can receive router advertisement from IPv6 routers in an IPv6-only network. The MN detects no DSTM support but receives the IPv6 packets, it realizes that it moves to an IPv6-only network. The IPv6 stack generates an IPv6 COA by using subnet prefix of the visited network. Once the mobile node obtains an IPv6 COA, it resolves an IPv4 address by the IPv6 address and also obtains the IPv6 address of its IPv4 home agent. Here we assume that IPv4 home agent is also IPv4/IPv6 dual stack. The IPv6 COA and its mapped IPv4 address must be co- located addresses allocated by the visited network using any mechanisms. The mapping between IPv6 and IPv4 addresses can be obtained by issuing DNS queries. The allocation of the COA in the visited network can be static assignment or dynamic allocation. The generation of the IPv6 address and the mapping of IPv4 and IPv6 addresses are out of the scope of this document. The related information can be found in [4][8]. Since the home agent is IPv4/IPv6 dual stack, the mobile node has IPv6 address of home agent, the MN can then tunnel MIPv4 registration request message to its home agent. Home agent decapsulates the IPv6 packets, receives the registration message and update its care- of- address. Therefore, packets to the mobile node can be transmitted with the new IPv4 COA. The procedures for DS MNv4 which migrates from an IPv4-only network to an IPv6-only network are summarized as: o In IPv4-only network, IPv4 packets are received and processed by IPv4 protocol stack on a mobile node. o The MN, which moves to an IPv6-only network, receives the router advertisement from IPv6 router via the IPv6 protocol stack. o The MN requests an IPv4 address and TEP via DSTM. The MN then sends MIPv4 registration request to its HA via TEP. Packets to MN should go to the home agent first and then be tunneled to the visited network. 9 o If MN can not requests an IPv4 address and TEP via DSTM. It obtains an IPv6 COA by certain mechanisms in the visited network. It resolves the IPv4 address by the IPv6 address, and obtains the IPv6 address of its home agent. The mechanisms to obtain an IPv6 care- of- address and the mapping between IPv6 and IPv4 addresses are out of the scope of the document. o The MN sends MIPv4 registration request encapsulated in IPv6 packets to IPv4 HA. HA updates the COA of the MN. o Packets to the MN are first routed to its home network. Home agent tunnels the packets to the IPv4 COA. Regarding of moving to IPv4-only or DS networks from IPv6-only networks, DS MNv4 releases IPv6 COA and registers a new IPv4 COA or deregisters with its home agent. 5. Route optimization For some specific handoffs, packet routing between CN and MN can be further optimized. Here, IPv4-only CN is assumed to implement route optimization for MIPv4. First case is DS MNv6 moves from an IPv6-only network to another IPv6-only network while communicating with an IPv4-only CN. While DS MN moves to the visited network with DSTM support, DS MN uses its MIPv6 COA in the foreign domain to request an IPv4 address and the local TEP from the local DHCPv6 server. It then uses MIPv6 to communicate with the local TEP and encapsulate IPv4 packets destined to external IPv4-only nodes. Then, DS MN can send MIPv4 binding update encapsulated in IPv6 packet to IPv4-only CN. If IPv4-only CN supports route optimization, it will refresh its binding update list and send packets to MN via new TEP. Thus, packet routing between CN and MN is optimized. Another situation is that DS MNv6 moves from IPv6-only network to IPv4-only network while communicating with an IPv4-only CN. In this case, DS MN will use native IPv4 to talk to CN and send MIPv4 binding update to CN after moving to the visited network. The packets need not go through home TEP so that routing can be also optimized. Considering another scenario that a DS MNv6, talks to an IPv6-only or DS CN. The MN changes its point of attachment to an IPv4-only network. If the visited network supports 6over4 [3] on the boundary routers, the MN can act as normal IPv6- only MN, and update binding information to its home agent and IPv6- only CNs. If the visited network does not support 6over4, mechanisms presented above show the procedures to request an IPv4 COA and register the IPv4-compatible IPv6 address to its home agent. 10 Regarding of packets from IPv6-only CNs to the MN, they go to the home network first, and be tunneled to the MN. To optimize routing, the MN can send MIPv6 BU messages to IPv6 CNs to update their binding information. However, the visited network is IPv4-only and no TEP is available. To solve this problem, the MN can send MIPv6 BU to IPv6- only CNs via reverse tunneling. That is, MIPv6 BU is tunneled to its home agent first and then sent to IPv6-only CNs. CNs can try to obtain a tunneling server by tunnel broker mechanisms [13] or obtain a pre- configured router [11][12], and send packets to the TEP. The TEP encapsulates the packets and sends to the MN. Thus, the routing between TEP/MN, and TEP/CN are both optimized. Suppose a DS MNv4. The MN changes its point of attachment to an IPv6- only network. The MN node requests an IPv4 COA by using DSTM[6] or the mechanisms presented above. It then can perform MIPv4 registration to its home agent. For the incoming packets from IPv4- only CNs, they go to the home agent first, and then be tunneled to the MN. However, triangle routing is introduced in this scenario even MIPv4 route optimization is implemented. To optimize routing, MN can send MIPv4 BU messages to IPv4 CNs. Since MN is in an IPv6-only network, the MIPv4 BU is encapsulated in IPv6 packets to CNs via TEPs. TEP decapsulates packets and then forwards the IPv4 packets to IPv4-only CNs. Once the IPv4-only CNs get the MIPv4 BU, they send packets with the new IPv4 COA address which belongs to the visited network. Thus, the routing between TEP/MN, and TEP/CN are both optimized. 6. Acknowledgments The authors would like to thank Jen-Chi Liu(CCL, ITRI), Alan O'Neill (Flarion Technologies ) and Scott Corson (Flarion Technologies) for their contributions to this memo. We would also like to thank Ra Chen(Siemens), Moter Du(Siemens), and YokeJen Lim(Siemens) for their many useful comments. 7. References [1] Charles E. Perkins, "IP Mobility Support", IETF RFC 2002, Oct. 1996. [2] David B. Johnson and Charles E. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-11.txt, March 2000, (work in progress). [3] K. Yamamoto and M. Sumikawa, "Overview of Transition Techniques for IPv6-only to Talk to IPv4-only communication", draft-ietf- ngtrans-translator-03.txt, March 2000, (work in progress). [4] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", IETF RFC 2462, Dec. 1998. [5] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", IETF RFC 2461, Dec. 1998. [6] Jim Bound et.al, "Dual Stack Transition Mechanism (DSTM)", , October 2000, (Work in Progress). 11 [7] Carpenter, B., and Jung., C. "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529. [8] J. Bound, M. Carney, C. Perkins, and R. Droms. "Dynamic Host Configuration Protocol for IPv6", draft-ietf- dhc-dhcpv6-16.txt, November 2000 (work in progress). [9] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for enhanced routing of inbound packets", , July 2000, (Work in Progress). [10] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC2529, March 1999. [11] W. Biemolt et.al, "On overview of the introduction of IPv6 in the Internet", , November 2000. [12] R. Gilligan et. al, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893. [13] A. Durand et. al, "IPv6 Tunnel Broker", RFC 3053, January 2001. Author's Addresses Shiao-Li Tsao Computer and Communication Research Labs., Industrial Technology Research Institute K400 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung, Hsinchu, Taiwan, 310, R.O.C. Tel: +886-3-5914651 Fax: +886-3-5820310 E-mail: sltsao@itri.org.tw George Tsirtsis Flarion Technologies Phone: +44-20-88260073 Email: G.Tsirtsis@Flarion.com Wolfgang Boehm Siemens Mobile Internet Postal Address: Siemens AG, ICM CA MS MI E Hofmannstr. 51, 81379 Munich / Germany Phone: +49 89 722 31462 Fax: +49 89 722 37661 e-mail: wolfgang-j.boehm@icn.siemens.de Copyright Notice Placeholder for ISOC copyright. 12