Re: [v6tc] Re: Tunneling and Transition Drafts

Ronald.vanderPol@rvdp.org Wed, 13 April 2005 09:56 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10822; Wed, 13 Apr 2005 05:56:33 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLeld-0001j1-ME; Wed, 13 Apr 2005 06:06:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLeaG-0007Le-Tt; Wed, 13 Apr 2005 05:54:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLdlL-0004uZ-Uy for v6tc@megatron.ietf.org; Wed, 13 Apr 2005 05:02:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07179 for <v6tc@ietf.org>; Wed, 13 Apr 2005 05:02:09 -0400 (EDT)
Received: from rvdp.sara.nl ([145.100.24.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLduy-0000Mc-IP for v6tc@ietf.org; Wed, 13 Apr 2005 05:12:16 -0400
Received: from rvdp.sara.nl (localhost [127.0.0.1]) by rvdp.sara.nl (8.13.3/8.12.11) with ESMTP id j3D91XdT016969; Wed, 13 Apr 2005 11:01:33 +0200 (CEST)
Received: (from rvdp@localhost) by rvdp.sara.nl (8.13.3/8.12.11/Submit) id j3D91WCx007835; Wed, 13 Apr 2005 11:01:32 +0200 (CEST)
Date: Wed, 13 Apr 2005 11:01:32 +0200
From: Ronald.vanderPol@rvdp.org
To: Fred Baker <fred@cisco.com>
Subject: Re: [v6tc] Re: Tunneling and Transition Drafts
Message-ID: <20050413090132.GD28016@sara.nl>
References: <BE78FA5D.F1CA3%jordi.palet@consulintel.es> <425395F8.50501@renater.fr> <Pine.LNX.4.61.0504061057570.11494@netcore.fi> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <23ec6165fdb2ab7b2f3946e45caef796@cisco.com>
User-Agent: Mutt/1.4.2.1i
X-Spam-Score: 0.3 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
X-Mailman-Approved-At: Wed, 13 Apr 2005 05:54:54 -0400
Cc: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>, v6tc@ietf.org
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=subscribe>
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

On Wed, Apr 13, 2005 at 02:44:49 +0800, Fred Baker wrote:

> The key question is how one enables two systems to talk with each 
> other. This is trivial if we have a parallel implementation - dual 
> stacks in both hosts and the entire network. In that case, pick one and 
> go with it, and those systems that have not yet turned on IPv6 use 
> IPv4. That is already a pretty strong recommendation.

Right.

> But it also misses something basic - the value that IPv6 brings to the 
> party is mostly related to increasing the address pool. If that is not 
> true, if we have enough IPv4 addresses that we can build parallel 
> networks everywhere, then we don't need a new protocol in the first 
> place. If it is true (and it is) then you have to assume that there 
> will be edge networks and service networks that are IPv6-only or 
> IPv6-dominant pretty early - pick your reason. Once you have an 
> IPv6-only/dominant service network, you have the question of IPv4 hosts 
> having to use it to communicate over it, IPv6-only/dominant hosts 
> needing to communicate over IPv4-only/dominant networks, and IPv6-only 
> hosts needing to communicate with IPv4-only hosts.

You seem to assume also that upgrading the IPv4-only network to dual
stack is not an option.

> At that point we have to solve a rendezvous problem. When two of one 
> kind of host need to communicate over a network of the other kind, we 
> obviously want to tunnel.

The 6bone ended up in a useless tunnel mess. Keep it simple has always
turned out to be the best approach. I think a dual-stack network is
easier to manage than a tunneled network. When users on an IPv4-only
network want to use IPv6-only services, they should convince the network
managers to upgrade to dual-stack. Otherwise, the tunnel mess will stay
forever, because there is no incentive to upgrade to dual-stack.

Isn't the main reason for tunneling the fact that too few networks are
deploying IPv6? Trying to force IPv6 deployment by creating complicated
tunnel overlays seems to me like wrong engineering.

	rvdp

_______________________________________________
v6tc mailing list
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc