Network Working Group B. Huang Internet-Draft H. Deng Intended status: Standards Track China Mobile Expires: January 7, 2010 July 6, 2009 Prefix NAT: Host based IPv6 translation draft-huang-pnat-host-ipv6-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. This Internet-Draft will expire on January 7, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Huang & Deng Expires January 7, 2010 [Page 1] Internet-Draft PNAT July 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Huang & Deng Expires January 7, 2010 [Page 2] Internet-Draft PNAT July 2009 Abstract IPv4 migrating to IPv6 is a network layer issue, it is not easy to mandate the application in the host to change in the first place, the network layer may have to have a solution to support conventional IPv4 appliation in the IPv6 only network, especially when there are multiple applications need to be supported. This document describes the mechanism for providing the host based IPv6 translation technology which could guarantee IPv4 application backward compatible, a new well known prefix has been defined for the destination address translation and network assigned prefix will be used for source address translation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Network Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 3. PNAT module in the host . . . . . . . . . . . . . . . . . . . 6 4. Signaling procedure of PNAT . . . . . . . . . . . . . . . . . 8 5. Operation of PNAT64 Gateway . . . . . . . . . . . . . . . . . 11 6. Socket API Translation . . . . . . . . . . . . . . . . . . . . 12 7. Consideration of PNAT Well Known Prefix . . . . . . . . . . . 13 8. Alternative: PNAT Header Translation . . . . . . . . . . . . . 14 8.1. PNAT Header Translation Host modules . . . . . . . . . . . 14 8.2. Signaling procedure of PNAT Header translation . . . . . . 15 9. Other scenarios: PNAT64COM, PNAT46COM, PNAT66COM . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 13. Normative References . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Huang & Deng Expires January 7, 2010 [Page 3] Internet-Draft PNAT July 2009 1. Introduction IETF has long time to not discuss host based IPv6 translation technology even though there are already several solutions which have been proposed before such as BIA [RFC3338], BIS [RFC2767], and v4- mapped prefix [RFC3493]. BIA and BIS haven't been widely supported and also both of them don't have any description regarding how IPv4 talk with IPv4 over an IPv6 only network; The mapping table in the host seems quite complicated comparing with using well known prefix. [RFC3493] has been implemented by the major OSs, but it is not fullly fledged to support the translation. IPv4 migrating to IPv6 is a principally network issue, so upgrading the applications from IPv4 to IPv6 is always lag-behind from the point view of industrial chain. Especially, there are various kinds of new applicatoins coming out. There are much more benefit to upgrade the network layer to support IPv6 transition in the host especially when there are more mature and multiple operator's level applications. There are some scenarios where IPv6 only bear network exists since it's not easy to guarantee dual stack everywhere. In the IPv6 only network, how to make conventional IPv4 application continue to communicate each other is one basic requirement from the people who is developing the applications. Application layer developers are not familiar with network layer technologies, they are hesitate to migrate their well-developped application to support IPv6. It's also not easy for them to change their experienced network interface API to support dual stack API. Under such scenario, this document propose host based IPv6 translation PNAT(Prefix NAT) solution which could guarantee IPv4 application backward comaptibility in the IPv6 only network. IPv4 application backward compatibility is one key requirement for IPv6 migration, [DS-Lite] already achieved. Besides, PNAT has two more considerations which hasn't been addressed by [DS-Lite]. The first one is that PNAT could support v4v6 and v6v4 communication, secondly, PNAT solutoin could avoid single point of failure. Recently, more and more operators has customized the terminal which make it feasible to do host based translation. It may be cheaper to do it comparing with the application upgrade. Huang & Deng Expires January 7, 2010 [Page 4] Internet-Draft PNAT July 2009 2. Network Scenarios During the deployment of IPv6 only network, depends on the operator policy, the host could get public IPv4 address and IPv6 prefix simultaneously, or sometime the host get private IPv4 address and IPv6 prefix. In each different configuration, PNAT64 gateway knows how to differentiate the public and private IPv4 address. Because the host may communicate with both IPv4 and IPv6 peer node, so the network will assign both DNSv4 and DNSv6 server address to the host. +----------------------------------+ +--------------------+ |IPv6 site 4/6 | | IPv4 site | | +--------+ | | | | | H3 | | | | | +--------+ | | | | | | | | | +--------+ | | | | +----+ | Access | +-------+ |+----------+ +----+| | | H1 |------- | Router |-- | PNAT64|----|| Internet |--| H2 || | +----+ +--------+ +-------+ |+----------+ +----+| | 4/6 | | | | 4 | | +--------+ | | +--------+ | | | DNSv6 | | | | DNSv4 | | | +--------+ | | +--------+ | | AAAA/A | | A | +----------------------------------+ +--------------------+ Figure 1: Network Scenario In Figure 1, H1 is the dual stack host located in the IPv6 site, H2 is IPv4 host stay in the IPv4 Internet, access router will allocate the IPv4 address and IPv6 prefix to the H1 host, DNS1 which have both AAAA and A record, butDNS2 only have A record, the PNAT64 will be used for translation between IPv6 and IPv4. PNAT44COM communication: When v4 application in the H1 need to communicate with v4 application in the H2.Or when v4 applicaiton in the H1 need to communicate with v4 application in the H3. PNAT46COM communication: When v4 application in the H1 need to communicate with v6 application in the H3. PNAT64COM communication: When v6 application in the H1 need to communicate with v4 application in the H2. PNAT66COM communication: When v6 application in the H1 need to communicate with v6 application in the H3. Huang & Deng Expires January 7, 2010 [Page 5] Internet-Draft PNAT July 2009 3. PNAT module in the host Inside the host, v4 to v6 translation including socket API and DNS query would be done firstly , and PNAT64 in the network will translate them back to IPv4 and then forward them into the IPv4 network. Below figure shows host PNAT IPv4/IPv6 translation module. +----------------------------------------------+ | +------------------------------------------+ | | | | | | | IPv4 applications | | | | | | | +------------------------------------------+ | | +-------------+ +-------------------------+ | | | DNS4 | | Socket API (IPv4) | | | +-------------+ +-------------------------+ | | +------------------------------------------+ | | |[Socket API translator] PNAT | | | | Core socket functions | | | | Address data structures | | | | Name-to-address translation functions | | | | Address conversion functions | | | |[Well Known Prefix Support] | | | +------------------------------------------+ | | +-------------+ +-------------------------+ | | | DNS6 | | Socket API (IPv6) | | | +-------------+ +-------------------------+ | | +------------------------------------------+ | | | | | | | TCP(UDP)/IPv6 | | | | | | | +------------------------------------------+ | +----------------------------------------------+ Figure 2: Host IPv6 translation Figure 2 shows modules inside H1, since it is IPv6 only bear network,so the bottom layer is IPv6 stack. PNAT module will do socket translation which is similar to BIA, one difference with BIA is to use well known prefix, other than maintain internally a table of the pairs of an IPv4 address and an IPv6 address. The other difference is that PNAT use network assigned prefix as the source address, but BIA use network assigned IPv6 address. IPv4 application in the host isn't aware of that it is in the IPv6 only network, it will continue to call IPv4 socket API. PNAT inside Huang & Deng Expires January 7, 2010 [Page 6] Internet-Draft PNAT July 2009 the host will translate v4 socket API into v6 socket API. The network assigned IPv6 prefix will be used for PNAT source address translation and well known prefix will be used to concatenate the destination IPv4 address into a IPv6 destination address. DNS4 and DNS6 don't stand for any special module, here each represents gethostbyname() in IPv4 and getaddrinfo() in IPv6. Huang & Deng Expires January 7, 2010 [Page 7] Internet-Draft PNAT July 2009 4. Signaling procedure of PNAT The call flow of the PNAT44COM is shown below, the modules of the host have been divided into three parts: v4 application, Socket Translation and Well Known Prefix. +-----------------------------------+ |(Host Side) | |v4 Appl [ Socket Well Known ]| DNS(4/6) Access PNAT64 v4 peer |ication [Translation Prefix(WKP)]| Server Router Application +-----------------------------------+ | | Address Request | | | | (0) | --------------------------->| | | | DHCPv6(outband) v6 Prefix +v4 addr+DNS4/6 | | | (1) | <----------------------------| | | | DNS4 | | | | | | (2) |------->| | | | | | | DNS4=>DNS6 | | | | | | if DNS4 server | | | | (3) | |----------->| | | | | | | [WKP+ DNSv4] | | | | (4) | |<-----------| | | | | | | | | | | | | |send both DNS4/6 Query | | | | (5) | |------------------------>| | | | | A/AAAA | | | | (6) | |<------------------------| | | | | DNS4 | | | | | | (7) |<-------| | | | | | |Socket4 | | | | | | (8) |------->| | | | | | | Socket4=>Socket6 | | | | | (9) | |----------->| | | | | | | WKP+Dest.IP | | | | (10)| |<-----------| | | | | | | | | | | | | |S:Assigned v6 Prefix D: WKP+Dest.IP| | | (11)| |----------------------------------------->| | | | | | | NAT64 State | (12)| | | | | |----->| (13)| | | | | |<-----| (14)| |<-----------------------------------------| | | Socket6=>Socket4 | | | | | |Socket4 | | | | | | (15)|<-------| | | | | | Figure 3: Signaling procedure of PNAT44COM Huang & Deng Expires January 7, 2010 [Page 8] Internet-Draft PNAT July 2009 (0) The host request the basic configuration such as address and DNS. (1) The network assign both IPv4 address(public or private) and IPv6 prefix, and DNSv4/v6 Server address to the host.(This private IPv4 address could be either a random IPv4 address or assigned by network side. (2) IPv4 application would like to start the communication with the peer application, it sends name resolver through gethostbyname call. Since PNAT host has already get both IPv4 and IPv6 DNS server, so it need send A/AAAA record to IPv6 DNS server, and A record to IPv4 DNS server. for IPv4 DNS server, it will continue call v4 socket api, then do IPv4 header to IPv6 header translation later. (3) if it is DNSv4 server address, it will use WKP to form a IPv6 address. (4) Well known prefix process module send destination IPv6 address back to socket translation module. (5) The host send both DNSv4 and DNSv6 query to DNSv4/v6 server. PNAT will translate DNSv4 header to IPv6 header, PNAT64 on the network side will translate v6 header back to v4 header, then send it to DNSv4 server. (6) The host may get A or AAAA record through PNAT64+DNSv4 server or DNSv6 server. (7) PNAT Socket translation will send DNS4 query resolver back to the IPv4 application. (8) IPv4 application start send regular socket call to communicate with the peer host, PNAT socket translation module translate this socket call. (9) In the case of PNAT44COM, the destination address is IPv4 address, socket translation module will forward this address to WKP module, by adding WKP, the destination address will be changed to IPv6 address. The IPv6 source address will be network assigned prefix plus IPv4 address. (10) The formed IPv6 destination address will be sent back. (11) Depends on the destination, in the case of PNAT44COM, the host will translate the source IPv4 address to network assigned IPv6 prefix+32 all zero + IPv4 private address or IPv6 prefix+32 all one + IPv4 public address, then forward the IPv6 packet to PNAT64. PNAT64 will process the packet differently, if the IPv4 address is the Huang & Deng Expires January 7, 2010 [Page 9] Internet-Draft PNAT July 2009 private address. it will do like normal NAT64, but if the host get public IPv4 address, it will get rid of prefix only, this mechanism still is a stateful work, because PNAT64 have to record which IPv4 public address is matching to which IPv6 prefix, in this case, ALG is not needed,but if it is private IPv4 address then, then ALG is still needed. (12) PNAT64 forward the IPv4 packet to the peer IPv4 node. (13) The peer IPv4 send response IPv4 packet to PNAT64. (14) PNAT64 forward the translated IPv6 packet back to the host based on the network assigned IPv6 prefix, socket translation module translate IPv6 packet to IPv4 packet. (15) The IPv4 packet has been forwarded back to v4 application. Huang & Deng Expires January 7, 2010 [Page 10] Internet-Draft PNAT July 2009 5. Operation of PNAT64 Gateway When PNAT64 received a IPv6 packet, it will decide based on the destination address firstly, if it is WKP prefix it could be judged that this is a translation operation. After that, PNAT64 will analyze its source address, there are 3 possibilities for the last 32 bit: public IPv4 address, private IPv4 address, or normal IPv6 address. if the 65-96 bit is all zero, and the last 32 bit is the private IPv4 address, then it is the scenario of PNAT44COM, PNAT64 will act as the normal NAT64 procedure. if the 65-96 bit is all one, and the last 32 bit is the public IPv4 address, then it is the scenario of PNAT44COM, PNAT64 will simply get rid of prefix, record the relationship between public IPv4 address and IPv6 prefix, and send out the packet. if the 65-96 bit is neither all zero nor all one, then it is the scenario of PNAT64COM, PNAT64 will act as the normal NAT64 procedure. When PNAT64 received a DNS IPv6 packet, it will not do DNS ALG, it will only translate IPv6 header to IPv4 header, then forward it to IPv4 DNS server. Huang & Deng Expires January 7, 2010 [Page 11] Internet-Draft PNAT July 2009 6. Socket API Translation The IPv4 socket API could be divided into different classification such as address conversion function, name to address translation, address data structure, socket operation, call of socket and response of socket. The below table has been made to identify how IPv4 socket API should be translated into IPv6 socket API. +----------------------+-----------------------+ | IPv4 Socket API | IPv6 Socket API | +----------------------+-----------------------+ | socket(AF_INET, , ) | socket(AF_INET6, , ) | +----------------------+-----------------------+ |bind,connect | bind,connect | |sendmsg,sendto | sendmsg,sendto | +----------------------+-----------------------+ |accept,recvfrom | accept,recvfrom | |recvmsg,getpeername | recvmsg,getpeername | |getsockname | getsockname | +----------------------+-----------------------+ |getsocketopt |getsocketopt | |setsocketopt |setsocketopt | +----------------------+-----------------------+ |AF_INET,socketaddr_in |AF_INET6,socketaddr_in6| |INADDR_ANY |in6addr_any | +----------------------+-----------------------+ | gethostbyname | getaddrinfo | +----------------------+-----------------------+ |inet_ntoa,inet_addr |inet_pton,Inet_ntop | +----------------------+-----------------------+ Figure 4: IPv4 IPv6 Socket API Translation Huang & Deng Expires January 7, 2010 [Page 12] Internet-Draft PNAT July 2009 7. Consideration of PNAT Well Known Prefix 0 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFIX64 | IPv4 addr | SUFFIX64 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 5: IPv4 IPv6 Socket API Translation PREFIX64 would better be shorter as much as possible, such as 16/24/32 bits. SUFFIX64 could be designated to all zero tentatively. All IP device between PNAT client and PNAT64 should support it or at least know how to route it to PNAT64. this prefix could also be set to /96 prefix like NAT64. Huang & Deng Expires January 7, 2010 [Page 13] Internet-Draft PNAT July 2009 8. Alternative: PNAT Header Translation With regard to PNAT Socket translation module, there is another translation scheme to satisfy backward compatibility of IPv4 application . It can reach same purpose as above mentioned. 8.1. PNAT Header Translation Host modules The detailed module implementation is described in figure 5, which demonstrates a PNAT module based on packet-header translation. +----------------------------------------------+ | +------------------------------------------+ | | | IPv4 | | | | applications | | | +-------------------+ +--------------------+ | | +-------------------+ +--------------------+ | | | DNS4 | | Socket API (IPv4) | | | +-------------------+ +--------------------+ | | +------------------------- ----------------+ | | | TCP(UDP)/IPv4 | | | +------------------------- ----------------+ | | +------------------------------------------+ | | |[Packet-Header translator] PNAT | | | |[WKP support] | | | |[DNS resolver if needed] | | | |[ALG if needed] | | | +------------------------------------------+ | | +------------------------------------------+ | | | Network card drivers | | | +------------------------------------------+ | +----------------------------------------------+ Figure 6: PNAT Host IPv6 translation based on packet-header translation A packet-header translator is deployed in a PNAT host which is compatible with IPv4 application. The translation approach is similar with BIS. Main difference with BIS is to use well known prefix, other than maintain a stateful mapping information of a pair of IPv4 address and IPv6 address internally. IPv4 applicaiton can make socket call and DNS query depending on IPv4 stack. And, socket handling in PNAT host is same as that in IPv4 host. Before IPv4 datagrams are sent to IPv6 transit network, the PNAT module should block the data flow and make packet-header translation, in which WKP is added to form IPv6 packet. The tranlation method is identical with above PNAT scheme. It should be Huang & Deng Expires January 7, 2010 [Page 14] Internet-Draft PNAT July 2009 noted that ALG handing and DNS resolvering will be performed in specific scenarioes, in which communications between different address families exist. 8.2. Signaling procedure of PNAT Header translation The PNAT44COM procedure also can be implemented depending on packet- header translation.The data flow is shown in figure 7. Accordingly,the modules of host can be classified into three parts: v4 application, Packet-header Translation and Well Known Prefix. +--------------------------------------------+ |Host side | | v4 [Packet-header Well Known ]| DNSv4 v4 peer | application [Translation Prefix(P) ]| PNAT64 Server App. +--------------------------------------------+ | DNS4 | | | | | (0) |---------->| | | | | | DNS4 | | | | (1) | |----------->| | | | | | P+Source IP | | | (2) | |<-----------| | | | |IPv4 Header=>IPv6 Header| | | | (3) | |------------------------>|-------->| | | | A | | | (4) | |<------------------------|<--------| | | DNS4 | | | | | (5) |<----------| | | | | | IPv4 | | | | | | datagram | | | | | (6) |---------->| | | | | |IPv4 Header=>IPv6 Header| | | | (7) | |----------->| | | | | | P+Dest.IP | | | (8) | |<-----------| | | | (9) | |------------------------>| | | | | | | PNAT64 | (10)| | | |------------------->| (11)| | | |<-------------------| (12)| |<------------------------| | | |IPv4 Header=>IPv6 Header| | | | | | | | | | | IPv4 | | | | | | datagram | | | | | (13)|<----------| | | | | Figure 7: PNAT Header Translation Signaling procedure Huang & Deng Expires January 7, 2010 [Page 15] Internet-Draft PNAT July 2009 the host will get network assigned IPv4 address and IPv6 prefix, and DNSv4 and DNSv6 server address which is the same as Figure 3. (0) IPv4 application would like to start the communication with the peer application, it sends name resolver through gethostbyname call. The IPv4 packet header of DNS query should translated into IPv6 packet header before the packets are sent to IPv6 transit network.In the whole process,the DNS call payload is not be modified. (1) When packet-header translation handles this process, it will send this address to well known prefix module. After receiving the destination IPv4 address, well know prefix module appends the well known prefix and get destination IPv6 address. (2) Well known prefix process module send destination IPv6 address back to packet-header translation module. (3) The host send DNS4 query, which is encapsulated in IPv6 datagram. PNAT64 will get rid of IPv6 prefix and send it to DNSv4 server. (4) The host get replied DNS A record. (5) Packet-header translation changes the DNS IPv6 header to IPv4 header in order to send DNS response to corresponding application. (6) IPv4 application initiates communication with the peer host. The system call will invoke IPv4 socket to form IPv4 packet, which will be sniffered in packet-header translation module.The IPv4 header will be tranlated into IPv6 header. (7) Packet-header translation module will forward this address to well known prefix module, by adding IPv6 prefix. The destination address will be changed to IPv6 address. (8) Well known prefix forward the IPv6 address back. (9) Based on the destination, the host forward the IPv6 packet to PNAT64, PNAT64 device will translate the IPv6 packet to IPv4 packet, if there are application layer address, then ALG is still needed. (10) PNAT64 forward the IPv4 packet to the peer IPv4 node. (11) The peer IPv4 send response IPv4 packet to PNAT64. (12) PNAT64 forward the translated IPv6 packet back to the host, packet-header translation module translate IPv6 packet to IPv4 packet. Huang & Deng Expires January 7, 2010 [Page 16] Internet-Draft PNAT July 2009 (13) The IPv4 packet has been forwarded back to v4 application. Huang & Deng Expires January 7, 2010 [Page 17] Internet-Draft PNAT July 2009 9. Other scenarios: PNAT64COM, PNAT46COM, PNAT66COM PNAT64COM has been partly described in the section of PNAT44COM, the only difference is PNAT64 will judge whether it is v4v4 communication over v6 or v6 communicate with v4. The 65-96 bit of IPv6 source address of the packet received in PNAT64 don't have all zero or all one will be the scenario of PNAT64COM. PNAT64 will process this packet as a normal NAT64 operation. PNAT46COM will the same as the BIA and BIS operation, but it may need ALG for some applications like P2P and RTP service PNAT66COM will operate as the regular v6 to v6 communiation, it will not be interupted by PNAT module. Huang & Deng Expires January 7, 2010 [Page 18] Internet-Draft PNAT July 2009 10. Security Considerations It need to be further identified. Huang & Deng Expires January 7, 2010 [Page 19] Internet-Draft PNAT July 2009 11. IANA Consideration This document makes no requests to IANA. Huang & Deng Expires January 7, 2010 [Page 20] Internet-Draft PNAT July 2009 12. Acknowledgments The author thanks the discussion from Gang Chen, Bo Zhou, Dapeng Liu, Hong Liu, Tao Sun et al. in the development of this document. The efforts of Yiu L. Lee, James Woodyatt, Lorenzo Colitti and in reviewing this document are gratefully acknowledged. Huang & Deng Expires January 7, 2010 [Page 21] Internet-Draft PNAT July 2009 13. Normative References [DS-Lite] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work in progress), March 2009. [NAT64] Bagnulo, M., "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03.txt (work in progress), March 2009. [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. Huang & Deng Expires January 7, 2010 [Page 22] Internet-Draft PNAT July 2009 Authors' Addresses Bill Huang China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: bill.huang@chinamobile.com Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Huang & Deng Expires January 7, 2010 [Page 23]