Re: [v4v6interim] "IPv4->IPv6 is hard"
Fred Baker <fred@cisco.com> Wed, 01 October 2008 18:26 UTC
Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2110B3A6AEC; Wed, 1 Oct 2008 11:26:54 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7123A681F for <v4v6interim@core3.amsl.com>; Wed, 1 Oct 2008 11:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.199
X-Spam-Level:
X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 i-0cpZomoRLm for <v4v6interim@core3.amsl.com>; Wed, 1 Oct 2008 11:26:51 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D9B583A676A for <v4v6interim@ietf.org>; Wed, 1 Oct 2008 11:26:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,344,1220227200"; d="scan'208";a="105846680"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2008 18:26:56 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m91IQtiO012120 for <v4v6interim@ietf.org>; Wed, 1 Oct 2008 11:26:55 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m91IQtqS002762 for <v4v6interim@ietf.org>; Wed, 1 Oct 2008 18:26:55 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 11:26:54 -0700
Received: from [192.168.3.103] ([10.21.89.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 11:26:54 -0700
Message-Id: <95D16B70-4462-4BBB-9782-E3DA4B7A1A1B@cisco.com>
From: Fred Baker <fred@cisco.com>
To: Mark Townsley <townsley@cisco.com>
In-Reply-To: <48E3BFE8.5030103@cisco.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 01 Oct 2008 14:26:53 -0400
References: <B4A9FAB9-F39D-42AA-BE3B-AF6A3C48CC93@cisco.com> <48E3BFE8.5030103@cisco.com>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 01 Oct 2008 18:26:54.0494 (UTC) FILETIME=[47C5CBE0:01C923F3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7246; t=1222885615; x=1223749615; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20<fred@cisco.com> |Subject:=20Re=3A=20[v4v6interim]=20=22IPv4->IPv6=20is=20ha rd=22 |Sender:=20; bh=KOcJ0gv7zvYQQfG9xGL/fOSZER6y5cqTi6OAIxbxYms=; b=NsBf1h8uCraP3Tt1lkY76WRMIx5I1/zCgo/yJTkR+Q+jrKVQXOF1gJ6nML awh2D/z/D+EtIVPC59WZfWNLOFGgK3qaH4VAiaeQdEV9ff3lujxAEZLA0hQx 9UWuasRkxo;
Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: v4v6interim@ietf.org
Subject: Re: [v4v6interim] "IPv4->IPv6 is hard"
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org
ack. I think SIIT, NAT64, and IVI have each addressed placing IPv4- accessible systems within an IPv6 network in a scalable fashion (at least as scalable as addressing itself). I obviously have a preference among those, but I think it is both possible and straightforward. On Oct 1, 2008, at 2:22 PM, Mark Townsley wrote: > > Fred, > > By "hard" I didn't intend to predispose whether the solution itself > would be hard or easy to code, scale, or otherwise make work for > some scoped definition of the problem. The statement that this is > "hard" made it's way into the slide based on discussions at the last > ietf, on list, etc. where I found less understanding in the > community on exactly how IPv4 -> IPv6 translation could be made to > work in a scalable or useful manner. As you say, one needs to > approach and analyze the problem in a specific manner in order to > make it seem less "hard." > > Hopefully by the end of the meeting we will all be approaching and > analyzing the problem correctly. Then, it won't seem so hard and I > will happily erase the bullet from the slide deck. > > - Mark > > PS. Apologies that I didn't spend more time on this topic, it was > scenario #5 of 5 - we were running out of time during the slot, and > frankly I ran out of time making the slides leading up to the > meeting as well so perhaps did not give this full billing. I had no > intention of implying one scenario more important than the other > based on slide count. > > > Fred Baker wrote: >> I'm fairly disturbed by Mark's dismissal of IPv4->IPv6 translation >> as "hard". I'll take this note to say why. I am obviously a >> proponent of a particular class of solution, IVI, which is >> specifically targeted at solving this problem, so let me declare >> bias up front. But I do not consider the issue hard if correctly >> analyzed and approached. >> >> In this analysis, I am going to leave out the dual stack case, >> which I frankly consider the strongly preferable deployment model. >> Wherever it is used, matters get simplified. I am expressly looking >> at the more difficult IPv4-only/IPv6-only case. >> >> Mark's dismissal - I call it that because he spent an hour talking >> about CGN solutions and then spent less than a minute charging >> through two slides that discussed actually deploying IPv6 and >> declaring them both "hard" and therefore not worthy of >> consideration - is based on the observation that mapping 2^128 >> addresses into 2^32 bits is hard. I will agree with him that making >> it possible for every IPv6 address to be mapped into IPv4 in a >> scalable manner has issues. The question that I will ask is: is >> that the real requirement? I don't think it is. >> >> While the addressing issue resolves to hosts, the connectivity >> problem is about applications. I think that today's applications >> can largely be broken down into two broad categories, and speakers >> in those applications into three. These are: the clients of client/ >> server applications, the servers in client/server applications, and >> the peer in peer-to-peer applications. In an IPv4-only/IPv6-only >> gateway, we have actually only our session initiation problems to >> solve: >> >> IPv6 client->IPv4 server >> IPv4 client->IPv6 server >> IPv6 peer -> IPv4 peer >> IPv4 peer -> IPv6 peer >> >> Once a session is initiated, we can obviously continue the >> conversation. >> >> IPv6 client->IPv4 server is pretty simple. The DNS ALG advertises >> IPv4 addresses as mapped IPv6 addresses, and the gateway keeps 1:n >> overlaid mappings in a manner not all that different from current >> IPv4/IPv4 NATs. On the IPv6 side of the gateway, we simply use the >> mapped address; on the IPv4 side, we use IPv4 address+port overlay >> as we do in IPv4/IPv4 NATs. >> >> An IPv4 client accessing an IPv6 server is equally simple given a >> 1:1 mapping such as NAT64 or IVI describes. One maps the headers >> and the addresses. >> >> IPv6 peer->IPv4 peer is simple enough; it is essentially the same >> problem as IPv6 client->IPv4 server, and is solved the same way. >> >> Initiating a session from an IPv4 peer to an IPv6 peer with an >> unmapped address is "hard"; that winds up calling for complex >> machinery like NAT-PT proposes. However, it is unnecessary to solve >> the case. p2p technologies open TCP connections between systems, >> leave them open long periods of time, and use them to transport >> data. They are in effect overlay networks. If one IPv6 peer opens a >> session to an IPv4 peer, connectivity is established between IPv4- >> only and IPv6-only p2p networks and the problem is solved. >> >> So to my mind, the requirement is that the gateway provide three >> services: >> - a DNS algorithm that maps IPv4 addresses to a subset of IPv6 >> addresses. >> - a 1:1 NAT algorithm that statelessly supports the common case of >> IPv4 clients accessing IPv6 servers, which will be used by a >> relatively small set of hosts in the IPv6-only domain. >> - 1 1:n NAT algorithm that statefully maps general IPv6 to IPv4 >> address plus port, which might be used by an arbitrarily large >> number of hosts in the IPv6-only domain, but unlikely to be all >> at the same time and diminishing as IPv6 deployment grows. >> >> None of those models is "hard" in light of our present experience >> with SIIT and IPv4/IPv4 NAT. >> >> Now, here is my issue with NAT64/SIIT's addressing model, which we >> deployed and then deprecated in RFC 4291. There are two. First, it >> is a lot like a default route, and limits the network >> administration's options in route management; to fix that, we need >> to have a prefix appropriate to the gateway as opposed to a flat >> "must be zero" style prefix. Second, th addressing architecture is >> essentially that of CIDR and therefore allows routing prefixes to >> be as long or as short as needed, but we have given clear guidance >> that router vendors should think about host routes or prefixes of / >> 64 or shorter, not normally prefixes in the 65..127 length range. >> If we believe that - and RFC 4291 clearly does - then enabling the >> gateway to support routing to multiple sites within the IPv6 domain >> using a single IPv4 prefix advertised in the IPv4 domain (as >> opposed to doing host routing to IPv4-mapped addresses in the IPv6- >> only domain) is important for scaling. IVI moves the address around >> to put IPv4-mapped prefixes within the /64 length rule. >> >> So the fundamental argument for IVI is that it works well with >> routing, and makes interchange of both p2p and client/server >> applications across the IPv4/IPv6 gateway simple. >> >> IPv4 access to the IPv6 network is most definitely *not* hard if >> the problem is correctly parsed and addressed. >> >> No pun intended. >> _______________________________________________ >> v4v6interim mailing list >> v4v6interim@ietf.org >> https://www.ietf.org/mailman/listinfo/v4v6interim >> > _______________________________________________ v4v6interim mailing list v4v6interim@ietf.org https://www.ietf.org/mailman/listinfo/v4v6interim
- [v4v6interim] "IPv4->IPv6 is hard" Fred Baker
- Re: [v4v6interim] "IPv4->IPv6 is hard" Mark Townsley
- Re: [v4v6interim] "IPv4->IPv6 is hard" Fred Baker
- Re: [v4v6interim] "IPv4->IPv6 is hard" Iljitsch van Beijnum
- Re: [v4v6interim] "IPv4->IPv6 is hard" Ed Jankiewicz
- Re: [v4v6interim] "IPv4->IPv6 is hard" Fred Baker
- Re: [v4v6interim] "IPv4->IPv6 is hard" Randy Bush
- Re: [v4v6interim] "IPv4->IPv6 is hard" Ed Jankiewicz
- Re: [v4v6interim] "IPv4->IPv6 is hard" Randy Bush
- Re: [v4v6interim] "IPv4->IPv6 is hard" Ed Jankiewicz
- Re: [v4v6interim] "IPv4->IPv6 is hard" Eric Vyncke (evyncke)
- Re: [v4v6interim] "IPv4->IPv6 is hard" Fred Baker
- Re: [v4v6interim] "IPv4->IPv6 is hard" Fred Baker
- Re: [v4v6interim] "IPv4->IPv6 is hard" Xing Li
- Re: [v4v6interim] "IPv4->IPv6 is hard" marcelo bagnulo braun
- Re: [v4v6interim] "IPv4->IPv6 is hard" Fred Baker
- Re: [v4v6interim] "IPv4->IPv6 is hard" Xing Li
- Re: [v4v6interim] "IPv4->IPv6 is hard" Xing Li
- Re: [v4v6interim] "IPv4->IPv6 is hard" marcelo bagnulo braun
- Re: [v4v6interim] "IPv4->IPv6 is hard" Mark Townsley
- Re: [v4v6interim] "IPv4->IPv6 is hard" Rémi Després
- Re: [v4v6interim] "IPv4->IPv6 is hard" Xing Li