Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih
"Goossens, Marnix" <magoosse@etro.vub.ac.be> Thu, 04 November 2010 11:46 UTC
Return-Path: <magoosse@etro.vub.ac.be>
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 DA5763A6866 for <behave@core3.amsl.com>; Thu, 4 Nov 2010 04:46:36 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TGLk3rzNrl11 for <behave@core3.amsl.com>; Thu, 4 Nov 2010 04:46:35 -0700 (PDT)
Received: from mxin.vub.ac.be (mxin.vub.ac.be [134.184.129.112]) by core3.amsl.com (Postfix) with ESMTP id A61703A67F2 for <behave@ietf.org>; Thu, 4 Nov 2010 04:46:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmgFAK800kyGuAIe/2dsb2JhbACBYZ81gU68foVGBI1S
Received: from etro30.vub.ac.be (HELO mail.etro.vub.ac.be) ([134.184.2.30]) by smtp.vub.ac.be with ESMTP; 04 Nov 2010 12:46:43 +0100
Received: from ETROEXBASE1.etro.vub.ac.be ([fe80::59e2:6e68:6318:3238]) by ETROEXHC1.etro.vub.ac.be ([::1]) with mapi id 14.01.0255.000; Thu, 4 Nov 2010 12:46:43 +0100
From: "Goossens, Marnix" <magoosse@etro.vub.ac.be>
To: "teemu.savolainen@nokia.com" <teemu.savolainen@nokia.com>
Thread-Topic: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih
Thread-Index: Act8EmvyM78Y9dkvRGC/tSfuWXYkcw==
Date: Thu, 04 Nov 2010 11:46:42 +0000
Message-ID: <867F7EF003904546AB79DBC23B005FB6176D5D64@ETROEXBASE1.etro.vub.ac.be>
Accept-Language: nl-BE, en-US
Content-Language: nl-BE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.130.162.113]
Content-Type: multipart/alternative; boundary="_000_867F7EF003904546AB79DBC23B005FB6176D5D64ETROEXBASE1etro_"
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 04 Nov 2010 16:14:55 -0700
Cc: "," <ala.hamarsheh@vub.ac.be>, "behave@ietf.org" <behave@ietf.org>
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 11:47:25 -0000
Hello Teemu >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). I am sending you below part of the motivation in the draft why we propose a generic tool, and why we think wide-spread deployment of IPv6, especially in residential context, is bound to fail if not something drastic is done about allowing IPv4-only applications to communicate transparantly over IPv6. I have been fighting for years (mainly in Europe) the blindness of IETF towards PRAGMATIC issues, the IETF sometimes taking a rather "idealistic" (but naive) technical-only stance towards issues such as multicast and now IPv6, and the focus of IETF on network operations mostly ignoring in the process the end-user's viewpoint. If you care to read the motivation, you will find that it is not at all about technical problems, but human and commercial issues... It may be that we have send the draft in error to the behave group, if that WG is too narrow in scope, but we probably had little choice... Kind regards, Marnix Goossens ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- It is probably important to give a brief analysis first of one of the blocking factors withholding the wide-spread introduction of IPv6 in order to fully understand why the here proposed BIA is considered an essential component in the unlocking of IPv6. At the inception of IPv6 it was - probably rather naively - presumed that all parties involved with the Internet would be eager to make the changeover and that the transition would happen spontaneously. It is now quite generally acknowledged that some human and commercial factors preventing a spontaneous transition have been largely underestimated. In the transition to IPv6 there are essentially two parties involved: network providers and end-users. The benefits of using IPv6 are almost entirely for the network providers, while the end-users have only potentially indirect benefits from better network operation. No drive to make the changeover should be expected from the majority of end-users (which includes application developers, that are working for these end-users), as they have probably little to gain. The network providers can expect benefits, but they are obviously dependent on the willingness of their end-users to make any changeover. The result is some kind of deadlock: no (commercial) network provider is going to force the customers to make the changeover against their will. So making the transition transparent to the end-user is the key in any transition to IPv6. The average end-users are not really aware about what goes on in the network layer, and even if they do, they usually could not care less. It does not matter much to them if their applications are communicating using IPv4 or IPv6. But, while there is no drive to be expected from the end-users for any transition to IPv6, the vast majority would not object to the transition on condition they can go on using their applications as before. While the first impression is that applications are not affected by the changeover on the IP layer from IPv4 to IPv6, this is unfortunately not true. The applications are using IP addresses, and hence should be capable of dealing with the longer IPv6 addresses when having to communicate over IPv6. Expecting all applications to be modified to be capable of dealing with the longer IPv6 addresses is rather naive. Apart from the "standard" Internet applications with rather good support such as web browsers, email programs, etc. that can be expected to be IPv6 enabled, there are thousands of other applications, some of them are written by small companies (of which some may be out of business) and others are even "home-made". For some applications, Internet communication is only a side-issue, for example for registering and/or checking for updates, and upgrading to become IPv6 compatible is probably not a high priority. It is to be expected that a large proportion of applications will only be modified to be IPv6 compatible when IPv6 usage gets into full swing. And even if the IPv6 capable new versions of application software are made available, it is again rather naive to expect all end-users to do the required updating of all the software on their system. The end-users MAY be willing to accept a changeover to IPv6, but will NOT accept that some of their applications will no longer work as before. From this observation it becomes obvious that it is absolutely essential that provisions are standard installed and enabled on any general purpose machine (the vast majority of systems connected to the Internet) that is provided for IPv6 communication and potentially has to run IPv4-only applications to continue communicating as before when communicating using IPv6. While the demand for mandatory provisions on every general purpose machine capable of communicating using IPv6 may seem a tall order, it should be realized that this approach is much more realistic then expecting ALL applications to be made IPv6 compatible: compared to thousands of applications that would need conversion requiring all application developers to follow suit, the number of communication stack implementations on general purpose machines is very small and is made by only a handful of developers.
- Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS d… teemu.savolainen
- Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS d… teemu.savolainen
- [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft… Ala Hamarsheh
- Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS d… teemu.savolainen
- Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS d… Goossens, Marnix
- Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS d… Goossens, Marnix
- Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 Brian E Carpenter