Re: [v6tc] Re: Tunneling and Transition Drafts

Tim Chown <tjc@ecs.soton.ac.uk> Wed, 13 April 2005 09:47 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 FAA10091; Wed, 13 Apr 2005 05:47:33 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLecv-0001To-4P; Wed, 13 Apr 2005 05:57:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLeQI-00057K-OI; Wed, 13 Apr 2005 05:44:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLeQH-00056l-9F for v6tc@megatron.ietf.org; Wed, 13 Apr 2005 05:44:37 -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 FAA09837 for <v6tc@ietf.org>; Wed, 13 Apr 2005 05:44:34 -0400 (EDT)
Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLea1-0001M6-AV for v6tc@ietf.org; Wed, 13 Apr 2005 05:54:42 -0400
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j3D9iTi3000413; Wed, 13 Apr 2005 10:44:29 +0100 (BST)
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA16726; Wed, 13 Apr 2005 10:44:28 +0100 (BST)
Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3D9iSd27831; Wed, 13 Apr 2005 10:44:28 +0100
Date: Wed, 13 Apr 2005 10:44:28 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6tc@ietf.org, "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
Subject: Re: [v6tc] Re: Tunneling and Transition Drafts
Message-ID: <20050413094428.GE26674@login.ecs.soton.ac.uk>
Mail-Followup-To: v6tc@ietf.org, "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
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> <20050413090132.GD28016@sara.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20050413090132.GD28016@sara.nl>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
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.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

On Wed, Apr 13, 2005 at 11:01:32AM +0200, Ronald.vanderPol@rvdp.org wrote:
> 
> > 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.

Between networks the "enough IPv4 addresses that we can build parallel
networks everywhere" argument works, for the ISP systems.  In end user 
or customer systems, I would expect we'll see a lot of dual stack that 
is IPv4+NAT alongside global IPv6.    From the ISP perspective what they
might see now is a handul of users achieving that by using a tunnel broker
(probably not one run by the ISP itself) and the challenge is offering 
(native, dual-stack) IPv6 from the ISP infrastructure directly.

-- 
Tim/::1



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