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]