[Int-area] next steps for ipv4-ipv6 co-existence and an interim meeting

Jari Arkko <jari.arkko@piuha.net> Wed, 20 August 2008 13:06 UTC

Return-Path: <int-area-bounces@ietf.org>
X-Original-To: int-area-archive@megatron.ietf.org
Delivered-To: ietfarch-int-area-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D253A686B; Wed, 20 Aug 2008 06:06:19 -0700 (PDT)
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CC03A682A; Wed, 20 Aug 2008 06:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level:
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[AWL=-1.509, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, SARE_LWSHORTT=1.24]
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 vyfR68zoChGU; Wed, 20 Aug 2008 06:06:15 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id ADF3B3A686B; Wed, 20 Aug 2008 06:06:14 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 33549198746; Wed, 20 Aug 2008 16:06:22 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E91BA19867B; Wed, 20 Aug 2008 16:06:21 +0300 (EEST)
Message-ID: <48AC1715.2000808@piuha.net>
Date: Wed, 20 Aug 2008 16:07:33 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Internet Area <int-area@ietf.org>, behave@ietf.org, 'IPv6 Operations' <v6ops@ops.ietf.org>, softwires@ietf.org
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [Int-area] next steps for ipv4-ipv6 co-existence and an interim meeting
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: int-area-bounces@ietf.org
Errors-To: int-area-bounces@ietf.org

We had many discussions about the IPv4 and IPv6 co-existence, NAT-PT
replacement, and new tunneling or translation solutions in Dublin. My
interpretation of the outcome is that some solutions are ready to move
forward (dual-stack lite to prevent running out of RFC 1918 addresses),
we improved our understanding of the translation designs (nat64 etc),
but that we were less far along in agreeing about the requirements for
that than we had hoped. In the INTAREA meeting you saw us go back to the
question of what scenarios we intend to address. We did not come to a
conclusion on that either, but private discussions afterwards have
convinced at least the INT ADs that we have a real business need for 2-3
different scenarios, requiring different solutions. The reality is that
existing NAT-PT is going to be used for some of these purposes unless
the IETF produces something better. I believe we can improve over the
existing design, and given that the mission of the IETF is to improve
the Internet, it is our duty to make this happen. To do this, we do not
need to find one perfect solution to all scenarios, enumerate all the
different situations that we'll encounter in the future, or even have a
solution that is completely free of problems. All we need to do is to
improve over what would happen otherwise.

With this in mind, I see the following short term next steps:
- Mark and I will produce a scenarios document that describes what
situations we must solve
- SOFTWIRE WG will be rechartered to add a work item on dual-stack
lite/snat (token: SOFTWIRE chairs)
- Progress the spec on dual-stack lite/snat (token: authors)
- For the rest, we need a written analysis of the overall design space
(token: Dan Wing and Alain Durand have agreed to do this)
- Progress the specs for the different translation-based proposals,
based on feedback in Dublin (token: authors)
- More discussion is needed on implications of "carrier-grade NATs" in
the pure IPv4 space

Did I miss anything?

We are also planning to run an interim meeting. The goal would be to
provide enough time to talk about this topic, and make significant
progress before IETF-73. This would be a meeting that affects work
happening in a number of WGs (SOFTWIRE, V6OPS, BEHAVE, INTAREA) and
different solutions for different scenarios. The agenda for the meeting
will be posted later, but it contains slots to talk about the scenarios,
design space, and each different solution approach.

The dates are October 1-2 and the likely location is Montreal, Canada.
We are currently working to confirm availability of meeting space and
other arrangements. So please consider this information tentative at the
moment; if we get surprises this may still change. However, for venue
selection we would like to learn how many people would join such a
meeting. Please fill in a poll here:

http://www.doodle.ch/participation.html?pollId=xw744qvw725cbsfm

Follow-ups regarding the general plan and the interim to intarea only,
please.

Jari Arkko
(on behalf of the ADs and WG chairs)


_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area