Re: [v4v6interim] "IPv4->IPv6 is hard"

Fred Baker <fred@cisco.com> Fri, 17 October 2008 15:56 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 4C9643A6A01; Fri, 17 Oct 2008 08:56:17 -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 7CE773A6A01 for <v4v6interim@core3.amsl.com>; Fri, 17 Oct 2008 08:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.013
X-Spam-Level:
X-Spam-Status: No, score=-106.013 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, J_BACKHAIR_33=1, 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 TZW1Z14nwJoj for <v4v6interim@core3.amsl.com>; Fri, 17 Oct 2008 08:56:15 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4C7B93A67A3 for <v4v6interim@ietf.org>; Fri, 17 Oct 2008 08:56:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,432,1220227200"; d="scan'208";a="96339990"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2008 15:57:18 +0000
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9HFvIP6024614; Fri, 17 Oct 2008 08:57:18 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m9HFvILj008471; Fri, 17 Oct 2008 15:57:18 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 08:57:18 -0700
Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 08:57:17 -0700
Message-Id: <0F551636-8059-4C93-81F6-AB5421CD4F3F@cisco.com>
From: Fred Baker <fred@cisco.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <4391DDA1-6432-4DCD-8A38-F351C68058B5@muada.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 17 Oct 2008 08:57:15 -0700
References: <B4A9FAB9-F39D-42AA-BE3B-AF6A3C48CC93@cisco.com> <4391DDA1-6432-4DCD-8A38-F351C68058B5@muada.com>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 17 Oct 2008 15:57:17.0880 (UTC) FILETIME=[07E73380:01C93071]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3814; t=1224259038; x=1225123038; c=relaxed/simple; s=sjdkim2002; 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=x1SI33k99xfNHYc3yjVSuI3SgFOcYOj5rzJ/wmyJQzM=; b=GkEbVSAZauwu+vVYIroLg+5nbT/vzT3h9iCP/UrLKZREl86ddc/NsK/jk6 buQvYloGxqMJ7a383q2+Afsrb1Nz+zlt+yP+SHSjl7jrGFOCxTxbhJM7NX1d hnJJmqNs0K;
Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 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

On Oct 17, 2008, at 3:40 AM, Iljitsch van Beijnum wrote:
> So you _don't_ want to solve the situation where an IPv4-only host  
> gets to talk to any given IPv6 host.
>
> I think it would be fair to call _that_ scenario "hard".
>
> However, I think there are others who are interested in solving this  
> case.

Correct on both points. NAT-PT tries to connect any IPv4 to any IPv6,  
and winds up with some "interesting" operational complexity as a  
result. I think that if you want to go after that problem for real,  
the solution you come up with is going to have comparable complexity  
and weaknesses. Willing to be proven wrong, but that's what it looks  
like to me.

However, using an IPv4 address mapped into an IPv6 address as SIIT  
does, we can provide access to a subset of IPv6 nodes - the ones that  
have such an address in addition to their standard IPv6 address. We  
can describe a relatively simple mechanism that will address most  
requirements for quite a while. I would far rather go for the low  
hanging fruit and let those who want to solve the bigger problem do so  
without slowing the relatively easy part down.

In my mind, it is in large part a question of requirements. Would it  
be nice to enable any IPv4 node to access any IPv6 node? of course.  
But is that really needed? I don't think so.

As I said in email during the interim, you really have two application  
cases - client/server (the web and POP/IMAP being examples, and SMTP  
when it is configured to upload mail from an application like OutLook  
to a corporate/ISP mail server), and peer-to-peer. SMTP is peer-to- 
peer between MTAs (TCP sessions are created in both directions), and  
applications like BitTorrent are obviously peer-to-peer.

Obviously you need any client to be able to access any server. Given  
that there are often several orders of magnitude more clients than  
servers in such applications, I have a relatively small translation  
requirement - I don't need any computer to any computer, I only need  
for IPv6 clients to be able to access IPv4 servers (mapped address in  
the client or stateful NATs comparable to present NAT44 will work),  
and IPv4 clients to access IPv6 servers (simply done with a mapped  
address).

For peer to peer applications like SMTP, using mapped addresses makes  
it relatively simple to support them. Since one expects them to be the  
bulk of application traffic, stateless translation has some real  
benefits there as well. Why does one expect that? Well, if one MTA  
serves 10,000 MUAs that each upload less than 100 messages a day, that  
MTA is at any given time talking with only a few of them, perhaps  
10-100. But it will be constantly chatting with the next MTA upstream  
as it sends its clients' 10,000*100 messages along.

For peer to peer applications like BitTorrent, while what would  
otherwise be called "clients" in fact open TCP-like connections willy- 
nilly, they have rules about how they open them. They tend to open a  
few connections that they leave open for a long time and use  
bidirectionally, so opening a connection in the IPv6->IPv4 direction  
works also to move content from the IPv4 domain to the IPv6 domain.  
Within each domain, connections generally work, and content can be  
moved where it needs to be. Using NAT44-like technology, IPv6 systems  
can access IPv4 systems readily. IPv4 systems won't be able to access  
IPv6-native peers, but they won't need to as the content will already  
be in their domain.

So I don't think we need any<->any access anywhere near as much as we  
need the much simpler ability to have IPv4 systems access IPv6  
*servers*, systems that have stable addresses that are generally  
assigned to them anyway.

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