RE: IPv4 Outage Planned for IETF 71 Plenary

"Hallam-Baker, Phillip" <pbaker@verisign.com> Tue, 18 December 2007 20:39 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jED-0006zx-1d; Tue, 18 Dec 2007 15:39:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jEA-0006yj-Re; Tue, 18 Dec 2007 15:39:46 -0500
Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4jE9-0004Zu-SY; Tue, 18 Dec 2007 15:39:46 -0500
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id lBIKY31N016243; Tue, 18 Dec 2007 12:34:03 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 12:39:43 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 18 Dec 2007 12:39:41 -0800
Message-ID: <2788466ED3E31C418E9ACC5C31661557084F9A@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IPv4 Outage Planned for IETF 71 Plenary
Thread-Index: AchBri6iPA9PrUsRTymM0vpUpzAQkQABgITf
References: <E1J3IFS-0002yV-CG@ietf.org> <200712142154.lBELs1ne090300@drugs.dv.isc.org> <200712181644.lBIGisBx090029@romeo.rtfm.com> <476800BC.5030504@dcrocker.net> <38033976C354EAB237181075@[192.168.101.1]> <47682268.1000108@piuha.net>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Jari Arkko <jari.arkko@piuha.net>, John C Klensin <john-ietf@jck.com>
X-OriginalArrivalTime: 18 Dec 2007 20:39:43.0833 (UTC) FILETIME=[1EE66C90:01C841B6]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Cc: iaoc@ietf.org, ietf@ietf.org, iesg@ietf.org
Subject: RE: IPv4 Outage Planned for IETF 71 Plenary
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0671577587=="
Errors-To: ietf-bounces@ietf.org

In the same way that there is a difference between a bricklayer and an architect there is a difference between an engineer and a network admin.
 
If I am going to be a labourer I'd prefer to bring along my jointer and table saw and pitch in with the hotel rennovations.
 
 
The idea of having a whole week without IPv4 is an invitation for half the membership to decide its the IETF to miss. And its the wrong strategy. The connection between the laptop and the WiFi access point isn't the problem, its the connection between the access point and the Internet where we are comming under pressure.
 
Run a split network:
 
IPv4 behind a honking great NAT
IPv6 with external routable IP address
 
Then attendees have a choice of challenges:
 
1) Make the applications you need all work from behind an IPv4 NAT
2) Get your platform to run IPv6
 
I don't see much real value in finding out that a bunch of Internet experts can manage the second and I see a real downside to discovering that many cannot. 
 
The split network situation is what I expect to see appearing as the IPv4 address pool shrinks. Actually thats the best case scenario, wost case is that all you can find is just IPv4 NAT.
 
My transition strategy would be 
 
1) Demonstrate that everyone can get work done in the split network scenario
 
2) Develop a specification for a T-Box (Transition Box) which is essentially an extension of current access point, cable, DSL modem etc. NAT capabilities. A T-Box can plug into an IPv4 or IPv6 connection and provides a transparent gateway to IPv4 or IPv6 devices - including devices on a mixed v4/v6 network.
 
3) Persuade the ISPs that they should buy equipment that is T-Box capable as it is their best chance of being future proof.
 
4) Write a new architecture document for writing applications that are T-box friendly. This can also incorporate other goodies we would like to deploy like security.
 
 
 

________________________________

From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Tue 18/12/2007 2:41 PM
To: John C Klensin
Cc: iaoc@ietf.org; ietf@ietf.org; iesg@ietf.org
Subject: Re: IPv4 Outage Planned for IETF 71 Plenary



John,

While I agree with many of your comments, I wanted to touch on this:

> Now we also know that skilled engineers and network operators
> are capable of configuring their way around those problems.
> ...  Inviting the rest of the community to try to
> sort things out in real-time in the plenary is silly at best.
>  
I hope you are not suggesting that there is some significant part of the
IETF community that consists of non-skilled engineers?! ;-)

Jari



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


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