IPv4 and IPv6 Co-existence discussions in Dublin
Mark Townsley <townsley@cisco.com> Fri, 18 July 2008 16:30 UTC
Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E458A3A6AEB; Fri, 18 Jul 2008 09:30:00 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FA53A6AEB; Fri, 18 Jul 2008 09:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.222
X-Spam-Level:
X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 wShOkxVs1e2M; Fri, 18 Jul 2008 09:29:58 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 947663A6AC1; Fri, 18 Jul 2008 09:29:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208";a="14789335"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2008 16:30:30 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6IGUUlE026442; Fri, 18 Jul 2008 18:30:30 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6IGUUdh018209; Fri, 18 Jul 2008 16:30:30 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 18:30:30 +0200
Received: from Townsley-MacBook.local ([10.61.66.3]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 18:30:29 +0200
Message-ID: <4880C50D.9070901@cisco.com>
Date: Fri, 18 Jul 2008 18:30:05 +0200
From: Mark Townsley <townsley@cisco.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: softwires@ietf.org, ipv6@ietf.org, IETF DNSEXT WG <namedroppers@ops.ietf.org>
Subject: IPv4 and IPv6 Co-existence discussions in Dublin
X-OriginalArrivalTime: 18 Jul 2008 16:30:29.0482 (UTC) FILETIME=[97664CA0:01C8E8F3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4103; t=1216398630; x=1217262630; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20<townsley@cisco.com> |Subject:=20IPv4=20and=20IPv6=20Co-existence=20discussions= 20in=20Dublin |Sender:=20; bh=y2lj12IqlR1NdLdp1AFiSlorfiyMNb3uW9OetmfmgJc=; b=A4MVm125TccsD+OZ1wv/F9Jgf3h95dKX4/LA34dTjzAHWjSLIvYR9kBJ30 8qJzbX9plox+Ewl0Vm76dXrcFF+mzMoTIqhSJsKHfYf+QIwc8iykrwGxAa0U ieeDLLLVXk;
Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Internet Area <int-area@ietf.org>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Apologies for cross-posting, please reply only to int-area@ietf.org All, Recent discussions in the IETF indicate that the IPv4 and IPv6 co-existence solutions we have available will not be sufficient for all deployment scenarios which we expect to be necessary in the face of pressures due to upcoming IPv4 address space exhaustion (or "completion"). The INT, TSV and OPS ADs would like to discuss with the community the best way to proceed in chartering this work, with particular focus on solutions which seem both readily tractable and for which provide identifiable benefit. Specifically, two initial steps appear as potential work items: 1. The ability to employ an IPv6-only network infrastructure by, say a cable or DSL operator, and still be able to serve subscriber networks that run on IPv4. This scenario was described in the Vancouver IETF V6OPS meeting [4], and it could be helpful in large networks where private RFC1918 IPv4 space is not sufficient to address all devices without resorting to overlays or NAT of the private space itself. We believe that this is something that can be implemented through the use of tunneling of IPv4 over IPv6. If the subscribers are in turn given private IPv4 address space, the tunnels would be connected to an IPv4 NAT device that serves multiple subscribers, potentially requiring a device that serves a very large number of translations as well as tunnels. It is suggested that this is a work item that fits the SOFTWIRE WG, and the INT ADs will be sending off a recharter proposal for this WG to examine this particular problem space and develop a solution accordingly. 2. NAT-PT was deprecated for reasons described in RFC 4966. However, there are scenarios where some forms of translation may be necessary. In particular, the IAB noted in [1] that scenarios involving servers without public IPv4 addresses cannot be adequately handled with the existing mechanisms. Requirements on this issue have been discussed in V6OPS, and a problem statement document written [2]. One possible translation design with reduced scope from NAT-PT as defined in RFC 2766 has been discussed recently in the BEHAVE WG [3], but there are other possible designs as well [5]. In essence, these designs attempt to reduce the problems present in NAT-PT by various techniques, including limiting themselves to a simpler part of the overall problem, allowing some changes in IPv6 hosts, and generally being designed with a better knowledge of the issues in RFC 4966. We believe that, on balance, the benefits outweigh the costs on developing a standard method for translation of IPv4 and IPv6. This will likely have a smaller scope, at least in the short term, than the original NAT-PT though it will inevitably share some of the same limitations. We will discuss this design in two places at the upcoming meeting: BEHAVE and INTAREA (two separate places because we feel it necessary to involve both the IP experts and people with a history of building address translators). For the moment, general architectural discussion should happen on the int-area@ietf.org list. We would like to focus our discussions on whether the requirements scenario and architectural direction is sufficiently ready so that the work can be given to the protocol WGs. If the answer to these questions is yes, after the Dublin IETF the ADs will recharter the relevant working groups to do the work. V6OPS is already working on the requirements. We expect that the behave WG would be the primary solution discussion forum and produce the base translation specification. 6MAN and DNSEXT would in turn handle any IPv6 stack or DNS protocol impacts (including a DNS ALG, if needed). - INT, OPS, and TSV ADs [1] http://www.ietf.org/mail-archive/web/ietf/current/msg48436.html [2] http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req [3] http://tools.ietf.org/id/draft-bagnulo-behave-nat64 [4] http://www.ietf.org/proceedings/07dec/slides/v6ops-5/sld1.htm [5] http://tools.ietf.org/id/draft-xli-behave-ivi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- IPv4 and IPv6 Co-existence discussions in Dublin Mark Townsley
- Re: IPv4 and IPv6 Co-existence discussions in Dub… Alain Durand