Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

<teemu.savolainen@nokia.com> Thu, 04 November 2010 09:27 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C32B3A69CB for <behave@core3.amsl.com>; Thu, 4 Nov 2010 02:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNoAYGkuaATS for <behave@core3.amsl.com>; Thu, 4 Nov 2010 02:27:41 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 11E563A69CA for <behave@ietf.org>; Thu, 4 Nov 2010 02:27:40 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA49RVrF004360; Thu, 4 Nov 2010 11:27:48 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Nov 2010 11:27:37 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Nov 2010 11:27:37 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 4 Nov 2010 10:27:37 +0100
From: teemu.savolainen@nokia.com
To: ala.hamarsheh@vub.ac.be, behave@ietf.org
Date: Thu, 04 Nov 2010 10:27:34 +0100
Thread-Topic: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih
Thread-Index: Act7phcGPiNrfKBmQnKyJHwwyUHkdwAWiFsQ
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F5F05BF452C@NOK-EUMSG-01.mgdnok.nokia.com>
References: <76714cd1e0d3851bf@wm-srv.ulb.ac.be>
In-Reply-To: <76714cd1e0d3851bf@wm-srv.ulb.ac.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Nov 2010 09:27:37.0232 (UTC) FILETIME=[84F07100:01CB7C02]
X-Nokia-AV: Clean
Subject: Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Nov 2010 09:27:42 -0000

Hi,

If you check out one of the predecessor of current bih draft, e.g. http://tools.ietf.org/id/draft-huang-behave-rfc3338bis-00.txt , you will see familiar looking figure 2. Also in the Introduction it is, for example, stated that:
--
   If the network which host is connecting with is IPv4 only network,
   then host's IPv4 application will behave regularly, and it's IPv6
   application's packets have to be translated into IPv4 packets.
--

Since those early versions of BIAbis the draft's purpose been narrowed down to cover only the use case behave WG is chartered to work on. Hence your generic draft has too wide scope when considering the goals of behave wg (IETF does *not* want generic host based protocol translation tool for IPv6 transition).

Best regards,

Teemu

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of ext Ala Hamarsheh
> Sent: 04. marraskuuta 2010 00:23
> To: behave@ietf.org
> Subject: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-
> v4v6-bih
> 
> Hi,
> 
> I highlight the differences between BIH (draft-ietf-behave-v4v6-bih)
> and our draft (draft-hamarsheh-behave-biav2-03), we compared both, and
> a summary of conclusions is the following:
> 
> 1. BIH is essentially an aggregation of the original BIA (RFC 3338)
> specification and the BIS (RFC 2767) specification.
> The context in which BIH can be used is actually limited, to the
> following two situations:
> - IPv4 only application communicating over IPv6 only network
> connectivity
> - IPv4 only application communicating over IPv4/IPv6 dual network
> connectivity
> The table below shows the scope in which BIH can be used:
> 
>             Host                                      Server
> +---------------+-------------------+          +-------------------+
> | Appl. Version | Host Connectivity | Network  | Host Connectivity |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |      IPv6         | <-IPv6-> |      IPv6         |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |       IPv6        | <-IPv6-> |    IPv4/IPv6      |
> +---------------+-------------------+          +-------------------+
> 
> BIH uses IPv4 - IPv6 Network Address Translation when configured in the
> original BIA mode, or IPv4 - IPv6 protocol translation (with its
> associated overhead) when configured in the original BIS mode.
> BIH is not aimed as a generic IPV6 transition tool.
> 
> 2. Our draft is a generalization of the original BIA specification. It
> describes a mechanism for hosts with IPv6 only, IPv4 only, or dual
> IPv6/IPv4 network connectivity to run IPv6 only, IPv4 only, or dual
> IPv6/IPv4 applications without any modification to those applications.
> It allows complete decoupling of application layer IPv4 or IPv6
> operation from the underlying network layer IPv4 or IPv6 communication
> being used, without requiring any modification in addressing
> capabilities to those applications, effectively isolating the
> application layer from IPv6 or IPv4 connectivity. The table below shows
> the scope in which the mechanism in our draft can be used:
> 
>             Source Host                          Destination Host
> +---------------+-------------------+          +-------------------+
> | Appl. Version | Host Connectivity | Network  | Host Connectivity |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |      IPv6         | <-IPv6-> |      IPv6         |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |      IPv6         | <-IPv6-> |    IPv4/IPv6      |
> +---------------+-------------------+          +-------------------+
> |    IPv6       |      IPv4         | <-IPv4-> |      IPv4         |
> +---------------+-------------------+          +-------------------+
> |    IPv6       |      IPv4         | <-IPv4-> |    IPv4/IPv6      |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |    IPv4/IPv6      | <-IPv6-> |      IPv6         |
> +---------------+-------------------+          +-------------------+
> |    IPv6      |    IPv4/IPv6       | <-IPv4-> |      IPv4        |
> +---------------+-------------------+          +-------------------+
> 
> Only IPv4 - IPv6 Network Address Translation is used, which implies
> minimal processing and communication overhead.
> In contrast with BIH the mechanism proposed in our draft is intended as
> a generic tool to allow the transition to IPv6 network operation
> without requiring all applications (both client and server side) to be
> adapted to IPv6 capability.
> 
> SUMMARY: the mechanism proposed in our draft has a much wider intended
> scope compared to BIH.
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave