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

Xing Li <xing@cernet.edu.cn> Mon, 20 October 2008 05:20 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 271133A68E1; Sun, 19 Oct 2008 22:20:07 -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 A9CF63A68E1 for <v4v6interim@core3.amsl.com>; Sun, 19 Oct 2008 22:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.62
X-Spam-Level: *
X-Spam-Status: No, score=1.62 tagged_above=-999 required=5 tests=[AWL=-2.121, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, FH_HAS_XAIMC=2.696, J_BACKHAIR_33=1]
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 5uc8ftnmmFIH for <v4v6interim@core3.amsl.com>; Sun, 19 Oct 2008 22:20:04 -0700 (PDT)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 1D3003A6885 for <v4v6interim@ietf.org>; Sun, 19 Oct 2008 22:20:03 -0700 (PDT)
Received: from [127.0.0.1]([59.66.24.169]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm2348fc2c3a; Mon, 20 Oct 2008 13:21:13 +0800
Message-ID: <48FBC96D.5020207@cernet.edu.cn>
Date: Mon, 20 Oct 2008 07:57:33 +0800
From: Xing Li <xing@cernet.edu.cn>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <B4A9FAB9-F39D-42AA-BE3B-AF6A3C48CC93@cisco.com> <4391DDA1-6432-4DCD-8A38-F351C68058B5@muada.com> <0F551636-8059-4C93-81F6-AB5421CD4F3F@cisco.com>
In-Reply-To: <0F551636-8059-4C93-81F6-AB5421CD4F3F@cisco.com>
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: jmbMnrUB
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: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

Fred Baker 写道:
>
> 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.

Thanks!

Some additional notes based on CERNET two years experience of running a
pure IPv6 backbone.

We believe the selection of the scenarios could be based on the
incentive of the owner of the IPv6 hosts.
(1) If the IPv6 host needs to be an IPv4-accessible server, they will
use the IVI address. Otherwise, it will use non-IVI address. This is to
say that there is no need to provide a general scheme for any IPv4 host
initiates communication with ANY IPv6 host, since the owner of the IPv6
host can select the suitable category of the IPv6 addresses.
(2) As the ISP, we price IVI addresses (1:1 mapping of IPv4 address,
scarce resource) and non-IVI addresses (non-scarce resource)
differently. So it is also economically reasonable.

Just our two cents.

xing
>
> _______________________________________________
> 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