Re: [BEHAVE] Discussion on draft-ietf-behave-v6v4-framework-00

Hui Deng <denghui02@gmail.com> Sat, 25 July 2009 20:35 UTC

Return-Path: <denghui02@gmail.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 747A03A68AF for <behave@core3.amsl.com>; Sat, 25 Jul 2009 13:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Level:
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599]
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 T38UgV+GYOIs for <behave@core3.amsl.com>; Sat, 25 Jul 2009 13:35:15 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 101A03A6949 for <behave@ietf.org>; Sat, 25 Jul 2009 13:35:15 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 28so637602wff.31 for <behave@ietf.org>; Sat, 25 Jul 2009 13:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E3fzIurkC6DjIlAi1xtBriQI7wti6BFwriFvmndz3/0=; b=EeHF2you5X1mINO5G07BqQSzsYbskllDcLTUR4YxBvKZq0fLA8q8/Ru46eKQQgLLPG U8Jwct1GYjRcdXpqCB40cIsmEl7HNullG6nb2m46euLHc7npdm8ognbmw3L7bc+BmBSm F2No5FQSpUWzJcG/zhMWwoAvjgS0Yx2fMgwxU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gYpwAjZ2FW6MBWTMxlYd0YHJUcIdO/ikwnhHatgwviF3ZuhF6/1e3FSeq2E0pBs0Ak qHHdkKC6D7j0Di9xfLLUM1+5B6f6Sz851LMR2ZlLqJqJr6QFHpcapfpwnRcgK9qQC/D7 C/CnQNP2WBEeQP2+b2Qtwb7TSaHb5zKuPGWZg=
MIME-Version: 1.0
Received: by 10.143.14.16 with SMTP id r16mr663533wfi.339.1248554114472; Sat, 25 Jul 2009 13:35:14 -0700 (PDT)
In-Reply-To: <143101ca0bbb$9674b020$c4f0200a@cisco.com>
References: <1d38a3350907230714g225d71f7g913d494c418a01cd@mail.gmail.com> <143101ca0bbb$9674b020$c4f0200a@cisco.com>
Date: Sun, 26 Jul 2009 04:35:14 +0800
Message-ID: <1d38a3350907251335gfe665c9q53753657e2d0b822@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: Dan Wing <dwing@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
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: Sat, 25 Jul 2009 20:35:16 -0000

excuse me for late reply
snip and reply with [Hui]

> 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
[Hui] Thanks.

>> 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.
[Hui] firstly, my comment hasn't got reply, let me reiterate.
IPv6 onlycould be :1) application; 2) Stack; 3) Address, 4) Routing.
Current framework draft define IPv6-only is kind of consider (1,2,3,4
only) case,
But I personally feel translation could happen in more cases like 2
only , or3 only, or 4 only, or several other cases. the framework like
(1,2,3,4 only)
in my experience network, I haven't see any node. Maybe people could
point out here
where I can find those type of the host.

> 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.
[Hui] I feel it will be largely different if we put the network into the host.

> 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.
[Hui] We did analyzation of that draft, will explain it during the presentation.

>> 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.
[Hui] I personally expect that the draft is easily readable for newbie like me,
other than concensus people only.

>
>> 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.
[Hui] could you let me know what and where is the border between the
network and Internet.
for example, there are lots of IDC server inside the operator, does
that belong to network or 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.
[Hui] if an IPv4 network could have public Ipv4 address, so
what and where is the border between network and Internet.

>> 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.
[Hui] could u kind help to elaborate the difference between tethered
PC and mobile terminal or notebook?

thanks again

-Hui