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