behave Working Group F. Cao Internet-Draft Z. Cao Intended status: Informational China Mobile Expires: April 22, 2010 October 19, 2009 Requirements for host based translation solution draft-cao-behave-hbt-req-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 April 22, 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 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. Cao & Cao Expires April 22, 2010 [Page 1] Internet-Draft HBT Requirements October 2009 Abstract This document describes the motivation for pursuing host-based translation schemes for allowing co-existence of legacy IPv4 applications in IPv6 only networks. It lays out the requirements that need to be met by the proposed solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. Requirements for a HBT solution . . . . . . . . . . . . . . . . 4 2.1. R1: Support for Legacy IPv4 applications . . . . . . . . . 4 2.2. R2: Support IPv6 only networks . . . . . . . . . . . . . . 4 2.3. R3: Minimize overhead on wireless links . . . . . . . . . . 4 2.4. R4: Allow decentralized peer-to-peer communication . . . . 4 2.5. R5: Simplify DNS Deployment . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Cao & Cao Expires April 22, 2010 [Page 2] Internet-Draft HBT Requirements October 2009 1. Introduction Several wireless operators are trying to deploy IPv6 only networks in order to reduce their dependence on the availability of scarce IPv4 addresses. These networks need to support hosts that run legacy IPv4 applications that cannot be rewritten to support IPv6 or dual stack. For achieving this objective some form of host based translation (HBT) solution is needed and this document sets out the motivation and requirements for such a solution. The document is intended to foster discussion about the requirements and to encourage the creation of HBT solutions. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Cao & Cao Expires April 22, 2010 [Page 3] Internet-Draft HBT Requirements October 2009 2. Requirements for a HBT solution The requirements that need to be met by a HBT solution are described along with their underlying motivations. 2.1. R1: Support for Legacy IPv4 applications The operators have several applications (conservatively hundreds) widely deployed that are not IPv6 aware and can communicate only over IPv4. Those IPv4 applications need to communicate with both the IPv4 hosts and IPv6 hosts. Some of these applications may be reworked to become dual stacked but for the vast majority of these applications, it is impractical to migrate the application over. This can be due to several reasons. e.g. long-tail of IPv4 application, financially not viable, source code not available, based on IPv6 unaware application frameworks. 2.2. R2: Support IPv6 only networks Almost all wireless operators are facing a serious shortage of IPv4 address space and this has started to hinder subscriber growth. For this reason, operators are interested in deploying IPv6-only networks for all new network rollouts. Additionally, the operators see significant management complexity and costs arising out of operating dual stack networks. The operators also use equipment that can be upgraded to support IPv6 but not necessarily support dual stack. 2.3. R3: Minimize overhead on wireless links Wireless spectrum is a very valuable and scarce resource. Due to this, the operators wish to eliminate unnecessary overhead on the wireless links, if possible. Thus if a translation based solution is possible, it is preferred over a tunneling based solution that will end up adding an additional IP header over the air. 2.4. R4: Allow decentralized peer-to-peer communication When legacy IPv4 applications on two hosts need to communicate with each other they must use the most direct route to carry the packets. Due to the scale of some of these networks routing all packets through a central point(s) in the network is undesirable if not impractical. It also eliminates bottlenecks and single points of failure in the network. 2.5. R5: Simplify DNS Deployment Legacy IPv4 applications need to identify the remote peer's IP address for a successful communication. The DNS is an important Cao & Cao Expires April 22, 2010 [Page 4] Internet-Draft HBT Requirements October 2009 infrastructure and changes of DNS have an impact on the whole network scale. So the operator would like to simplify the DNS deployment during IPv6 transition. Wherever the host is, it must be able to translate the DNS query to the format that the DNS server can understand and handle replied resource record to a format the application can use. Cao & Cao Expires April 22, 2010 [Page 5] Internet-Draft HBT Requirements October 2009 3. Security Considerations This document describes the motivation and requirements for a host based translation solution and does not create any new security considerations. Cao & Cao Expires April 22, 2010 [Page 6] Internet-Draft HBT Requirements October 2009 4. IANA Considerations This document does not require any IANA actions. Cao & Cao Expires April 22, 2010 [Page 7] Internet-Draft HBT Requirements October 2009 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Cao & Cao Expires April 22, 2010 [Page 8] Internet-Draft HBT Requirements October 2009 Authors' Addresses Feng Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: fengcao@chinamobile.com Zhen Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: caozhen@chinamobile.com Cao & Cao Expires April 22, 2010 [Page 9]