Re: [tae] The internet architecture

Thomas Narten <narten@us.ibm.com> Fri, 05 December 2008 15:40 UTC

Return-Path: <tae-bounces@ietf.org>
X-Original-To: tae-archive@ietf.org
Delivered-To: ietfarch-tae-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CC33A6ABA; Fri, 5 Dec 2008 07:40:52 -0800 (PST)
X-Original-To: tae@core3.amsl.com
Delivered-To: tae@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A1B3A6C72; Fri, 5 Dec 2008 06:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.649
X-Spam-Level:
X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 0qHJgzoK3SnA; Fri, 5 Dec 2008 06:25:28 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 938D83A6C6E; Fri, 5 Dec 2008 06:25:28 -0800 (PST)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB5EOkOU024965; Fri, 5 Dec 2008 07:24:46 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB5EPNW4195134; Fri, 5 Dec 2008 07:25:23 -0700
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB5EPNVk029050; Fri, 5 Dec 2008 07:25:23 -0700
Received: from cichlid.raleigh.ibm.com (sig-9-65-205-212.mts.ibm.com [9.65.205.212]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB5EPLNL028869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 07:25:22 -0700
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mB5EPKEG032766; Fri, 5 Dec 2008 09:25:20 -0500
Message-Id: <200812051425.mB5EPKEG032766@cichlid.raleigh.ibm.com>
To: Keith Moore <moore@network-heretics.com>
In-reply-to: <49382030.5020704@network-heretics.com>
References: <C15AE32B-E564-4C93-86FF-40EF203E673A@mpi-sws.org> <49382030.5020704@network-heretics.com>
Comments: In-reply-to Keith Moore <moore@network-heretics.com> message dated "Thu, 04 Dec 2008 13:23:44 -0500."
Date: Fri, 05 Dec 2008 09:25:20 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Mailman-Approved-At: Fri, 05 Dec 2008 07:40:50 -0800
Cc: tae@ietf.org, ietf@ietf.org, Bryan Ford <brynosaurus@gmail.com>
Subject: Re: [tae] The internet architecture
X-BeenThere: tae@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Architecture Evolution <tae.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tae>
List-Post: <mailto:tae@ietf.org>
List-Help: <mailto:tae-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tae-bounces@ietf.org
Errors-To: tae-bounces@ietf.org

Keith Moore <moore@network-heretics.com> writes:

> > Just think how much easier the IPv4 to IPv6 transition would have
> > been if nothing above the IP layer cared exactly what an IP
> > address looks like or how big it is.

> It wouldn't have made much difference at all,

Wow. I find this statement simply astonishing.

IMO, one of the biggest challenges surrounding IPv6
adoption/deployment is that all applications are potentially impacted,
and each and everyone one of them needs to be explicitely enabled to
work with IPv6. That is a huge challenge, starting with the
observation that there are a bazillion deployed applications that will
NEVER be upgraded.

Boy, wouldn't it be nice of all we had to do was IPv6-enable the
underlying network and stack (along with key OS support routines and
middleware) and have existing apps work over IPv6, oblivious to IPv4
vs. IPv6 underneath.

And, if one wants to look back and see "could we have done it
differently", go back to the BSD folk that came up with the socket
API. It was designed to support multiple network stacks precisely
because at that point in time, there were many, and TCP/IP was
certainly not pre-ordained. But that API makes addresses visible to
APIs. And it is widely used today.

Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).

Thomas
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae