Re: [BEHAVE] Discussion on draft-ietf-behave-v6v4-framework-00
"Dan Wing" <dwing@cisco.com> Thu, 23 July 2009 17:33 UTC
Return-Path: <dwing@cisco.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C493A6AEA for <behave@core3.amsl.com>; Thu, 23 Jul 2009 10:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.039
X-Spam-Level:
X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 dpjEI17MFywG for <behave@core3.amsl.com>; Thu, 23 Jul 2009 10:33:58 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6B4D43A67B3 for <behave@ietf.org>; Thu, 23 Jul 2009 10:33:36 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqkEADM7aEqrR7MV/2dsb2JhbACLC64kiCWREwWEDYFI
X-IronPort-AV: E=Sophos;i="4.43,256,1246838400"; d="scan'208";a="352602740"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2009 17:32:47 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6NHWlFq000733; Thu, 23 Jul 2009 10:32:47 -0700
Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6NHWkHK018917; Thu, 23 Jul 2009 17:32:47 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Hui Deng' <denghui02@gmail.com>, behave@ietf.org
References: <1d38a3350907230714g225d71f7g913d494c418a01cd@mail.gmail.com>
Date: Thu, 23 Jul 2009 10:32:44 -0700
Message-ID: <143101ca0bbb$9674b020$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <1d38a3350907230714g225d71f7g913d494c418a01cd@mail.gmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcoLqHzRw0UXH0WHR2ulRxE1ypZmiwAC0Pdg
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5544; t=1248370367; x=1249234367; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[BEHAVE]=20Discussion=20on=20draft-ietf -behave-v6v4-framework-00 |Sender:=20; bh=U0iG2OU1xo61KzyEBN9A/LjQPgZZsjMl39VGvhZcXPo=; b=WVwl9B10ZgHMZKJGd+pKt0fOCFdFU58/lC1PEgvbBnHuo3JM6dVXTJGb/u SZ87u4zxm8m5QrLmYH7VdC7p8ssWreBhjD1WxiKr5P0xZWC5AX6DSz2QDjeg mfDAwJOUdI3lbvmUISLVFQljsKaxmByX2Oro6BtBIdyWFr4VVxEVA=;
Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Subject: Re: [BEHAVE] Discussion on draft-ietf-behave-v6v4-framework-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2009 17:33:59 -0000
> -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Hui Deng > Sent: Thursday, July 23, 2009 7:14 AM > To: behave@ietf.org > Subject: [BEHAVE] Discussion on draft-ietf-behave-v6v4-framework-00 > > Hello, all > > People here asked me to propose the text to this draft. > I read through the draft, but feel that I need some discussion before > move forward. > > China Mobile proposed categorization of scenarios to 3GPP SA2 > which will > be discussed in the next meeting. I write down the link of > our last document > http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_74_Sophia_Antipo > lis/Docs/ > you could download S2-094503 document. (this is not yet an > accepted document) BEHAVE's categories, which are the 4 scenarios in our charter (soon to be 6, assuming our charter update is approved), are based primarily on draft-arkko-townsley-coexistence-00.txt and Mark Townsley's presentation at the October 2008 interim meeting in Montreal. Minutes and presentations from that meeting are here: http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim > Firstly I feel that this draft's scenario is kind of orthogonal with > we proposed in 3GPP. > we have defined IPv6 into four types for a host: > 1) application; 2) Stack; 3) Address, 4) Routing. > Current framework draft define IPv6-only is kind of consider > (2,3,4 only) case, > But I personally feel translator could happen in more cases like 2 > only , 3 only and 4 only and several other cases. Yes, a translation function could occur anywhere in the network -- including inside the host. The IETF has two existing RFCs which describe a function where software inside the host does translation, BIA (RFC3338, published 2002) and BIS (RFC2767, published 2000). One of BEHAVE's significant guiding principles for our 6/4 translation work is to not modify the hosts. This is a principle because we don't have time -- we are exhausting IPv4 addresses in a few years and it would take more years to standardize new functionality in hosts, have vendors implement that new functionality (Apple, Microsoft, various Unix distributions, printers, etc.), and so on. So, we have been concentrating on solutions that describe a *function* (such as translation) that can be placed in the network without requiring the host's software to be upgraded or replaced. However, that same *function* (such as translation) can be placed in a host, and do the same thing. There are side-effects of either choice -- operational complexity, ease of migration for applications, and so on. Over time, that function -- or portions of it -- may migrate into hosts. Multiple translation between address families (IPv4 to IPv6 to IPv4) is also something we want to avoid because it increases complexity of the network (as a whole) and makes troubleshooting more difficult. Alain Durand had proposed doing multiple translation, nicknamed NAT464, but as far as I know he has abandoned that effort, http://tools.ietf.org/html/draft-durand-v6ops-natv4v6v4-01. You might discuss with him the difficulties of multiple translation. It might be possible that the in-host translation, which you seem to prefer to support legacy IPv4 applications, could avoid the difficulties of multiple translation. > Secondly, I guess the working group already concensused about > IPv4/IPv6 network/internet. Yes. That consensus took us about 5 hours at the Montreal interim meeting last October. > But for me I really have the diffculty to tell the difference between > IPv6 network and IPv6 Internet. "a network" is a network under one organization's control. For example, a University's network; an Internet service provider's network and its subscribers; an enterprise's network. "Internet" is the Internet. > I guess NAT66 hasn't been accepted by the IETF. Yes, so far NAT66 has not been accepted. At this point in time it remains an individual draft. > Does IPv4 network/Internet will be differentiated > by private and Public IPv4 address? No. "An IPv4 network" could have public IPv4 addresses; for example, that is how almost all Internet service providers operate today -- they give their subscribers publicly-routable IPv4 addresses. But it can also be a network that uses private IPv4 addresses; for example, many enterprises use a NAT (for various reasons) and provide their employees computers with private IPv4 addresses. > Honestly, as a newbie of this wg, > I am not clear on this. > > Thirdly, terminology for IPv4-only and IPv6-only is different from the > 3gpp document, 3GPP document has more deep defined scenarios. I skimmed the 3GPP document at http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_74_Sophia_Antipolis/Docs/S2-0945 03.zip. Is that the document with more deeply defined scenarios? It lists 26 scenarios, yet doesn't consider applications running on a tethered PC. 4 of the scenarios are listed as high-priority (to solve first), and all 4 of those scenarios have application programs running IPv4 that are running on a dual-stack handset or IPv6-handset, and connected to a dual-stack or IPv6-only 3GPP network. -d > Hope I could receive more comment, and know how to do next. > > thanks for your comments. > > -Hui > > . > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave
- [BEHAVE] Discussion on draft-ietf-behave-v6v4-fra… Hui Deng
- Re: [BEHAVE] Discussion on draft-ietf-behave-v6v4… Dan Wing
- Re: [BEHAVE] Discussion on draft-ietf-behave-v6v4… Dave Thaler
- Re: [BEHAVE] Discussion on draft-ietf-behave-v6v4… Dan Wing
- Re: [BEHAVE] Discussion on draft-ietf-behave-v6v4… Hui Deng