Skip to main content

Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
draft-huang-behave-rfc2767bis-02

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Bill Huang , DENG Hui , Teemu Savolainen
Last updated 2010-03-08
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

This document describes the "Bump-In-the-Stack" (BIS) host based protocol translation mechanism that allows applications supporting only one IP address family to communicate with peers that are reachable or supporting only the other address family. Furthermore, this technology avoids need for unnecessary double protocol translation in the case where destination is dual-stack enabled. This specification addresses scenarios where a host is provided dual stack or IPv6 only network connectivity. In the dual stack network case, single address family applications in the host will communicate directly with other hosts reachable with the different address family. In the case of IPv6 only network or IPv6 only destination, IPv4-originated communications have to be be translated into IPv6. In the scenario of single address family access network, but dual- stack destination, network based translation is always avoided. Technically, the BIS-enabled host resolves both IPv4 and IPv6 addresses of the destination and behaves according to received responses. Acknowledgement of previous work This document is an update to and directly derivative from Kazuaki TSUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's [RFC2767], which similarly provides a dual stack host means to communicate with other IPv6 host using existing IPv4 appliations.The original document was a product of the NGTRANS working group. The changes in this document reflect three components 1. Supporting IPv6 only network connections 2. Extending ENR and address mapper to operate differently 3. Adding an alternative way to implement the ENRStatus 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 September 8, 2010. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Authors

Bill Huang
DENG Hui
Teemu Savolainen

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)