From jan@go6.si Mon Aug 1 02:21:33 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08D521F86DD for ; Mon, 1 Aug 2011 02:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5075q5tgmjD for ; Mon, 1 Aug 2011 02:21:33 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDB521F8571 for ; Mon, 1 Aug 2011 02:21:32 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 9DA5A23780AE for ; Mon, 1 Aug 2011 11:21:32 +0200 (CEST) Message-ID: <4E36701C.4060201@go6.si> Date: Mon, 01 Aug 2011 11:21:32 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: softwires@ietf.org References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 09:21:33 -0000 On 7/29/11 11:41 AM, Rémi Després wrote: > Dear all, > > Dave rightly expresses in the Softwire meeting the need to separate/clarify discussion about: > - Stateless vs stateful > – Static vs dynamic port sets Does this belong to softwires anymore? New WG maybe? Cheers, Jan Zorz From jan@go6.si Mon Aug 1 02:26:17 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0461D21F8610 for ; Mon, 1 Aug 2011 02:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMzFRmnCZ8AQ for ; Mon, 1 Aug 2011 02:26:16 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D1121F85F7 for ; Mon, 1 Aug 2011 02:26:16 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 729B223780AE for ; Mon, 1 Aug 2011 11:26:20 +0200 (CEST) Message-ID: <4E36713C.904@go6.si> Date: Mon, 01 Aug 2011 11:26:20 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: softwires@ietf.org References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> In-Reply-To: <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 09:26:17 -0000 On 7/30/11 3:38 PM, Satoru Matsushima wrote: > On 2011/07/30, at 8:26, Peng Wu wrote: >>> >>> a) Stateful+Dynamic port sets: e.g. DS-Lite >>> b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 >>> c) Stateless + Static port set: e.g. 4rd, 4via6 translation >>> d) Stateless + Dynamic port set: ??(Any candidate solution?) >> >> I would say that the last one makes no sense > > Agree. It is a problem space only on that logical frame. > I think that the analysis work doesn't need to insist necessity of unfeasible area solution. Well, A+P got enormous amounts of criticism because there was no dynamic allocations of additional ports. Now we don't need that anymore, just because stateless solution can't handle it by design? I love stateless a+p flavors, but imho we'll need both solutions, stateless and statefull and both of them with dynamic port ranges or sets, whatever you might call them. Cheers, Jan Zorz From ichiroumakino@gmail.com Mon Aug 1 02:42:01 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1674B21F86BE for ; Mon, 1 Aug 2011 02:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OxTiCcpp0JQ for ; Mon, 1 Aug 2011 02:42:00 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0866D21F86DF for ; Mon, 1 Aug 2011 02:41:59 -0700 (PDT) Received: by wwe5 with SMTP id 5so3603014wwe.13 for ; Mon, 01 Aug 2011 02:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Z6YD2aTfA4VhzA6N3gmyaAAuD+YxaLqNB11dqd2mLbM=; b=XqRLPNRprpF5wpO6GIBN2BEKyevEs/BM2eNE1lglQ9NblIFqOoDd85yg3Xpwe9cw6B noY95p6fgeRzCYmgA9lqT4pSUoPx5EHr/HCE38+V7/imJTk6IwR/Ny/bpS9hWjvGVgJ7 YVLumsoQPCVdJVyFzofE6hC+rwWmame9Cq9ZE= Received: by 10.216.221.6 with SMTP id q6mr514721wep.12.1312191725074; Mon, 01 Aug 2011 02:42:05 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-124.cisco.com ([64.103.53.124]) by mx.google.com with ESMTPS id m56sm3196644wed.35.2011.08.01.02.42.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 02:42:04 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E36713C.904@go6.si> Date: Mon, 1 Aug 2011 11:41:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8525BEE4-C249-4055-9E01-779A56A9C271@employees.org> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> To: Jan Zorz @ go6.si X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 09:42:01 -0000 > Well, A+P got enormous amounts of criticism because there was no = dynamic allocations of additional ports. >=20 > Now we don't need that anymore, just because stateless solution can't = handle it by design? >=20 > I love stateless a+p flavors, but imho we'll need both solutions, = stateless and statefull and both of them with dynamic port ranges or = sets, whatever you might call them. we can do static allocations for new port ranges. cheers, Ole= From bingxuere@gmail.com Mon Aug 1 03:06:34 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3973921F8752 for ; Mon, 1 Aug 2011 03:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNFCpX6-IVAT for ; Mon, 1 Aug 2011 03:06:33 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9AE21F874B for ; Mon, 1 Aug 2011 03:06:33 -0700 (PDT) Received: by pzk6 with SMTP id 6so10455565pzk.26 for ; Mon, 01 Aug 2011 03:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XcSyOmdoZ6hd0T3J3RL1aRMguWiKmhsaFeflUGy9lGc=; b=aTrSQa5y+xsOcfRu/ZVITTZxB0TRNqcIghuxN/zOSN9Fd+QiOwh1/4ch9GNr6npdq9 uWCRSQsEET9PYj83ie+otmYlG2RYemdO5a9MLbdnj4H2U0NdLblkzgdf5CZ7ukP8TCOD gRHo9k72DS7/DI5MWHAuvUEqvKvRGmc3qJ+KI= Received: by 10.68.22.41 with SMTP id a9mr7767820pbf.57.1312193199169; Mon, 01 Aug 2011 03:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.6 with HTTP; Mon, 1 Aug 2011 03:06:19 -0700 (PDT) In-Reply-To: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> From: Qiong Date: Mon, 1 Aug 2011 18:06:19 +0800 Message-ID: To: Satoru Matsushima Content-Type: multipart/alternative; boundary=bcaec521578d8361e504a96ec94c Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 10:06:34 -0000 --bcaec521578d8361e504a96ec94c Content-Type: text/plain; charset=UTF-8 Hi, Satoru, Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing. http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt Thanks Best wishes Qiong Sun On Sat, Jul 30, 2011 at 9:57 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > One clarification. > > On 2011/07/29, at 10:18, GangChen wrote: > > > Before making such comparison (of course it should be as fair as > possible), > > I think we need to state what solution space we are targeting and what > > category mode we should take care. > > If I understand correctly, I would paraphrase as following categories. > > > > a) Stateful+Dynamic port sets: e.g. DS-Lite > > b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 > > c) Stateless + Static port set: e.g. 4rd, 4via6 translation > > d) Stateless + Dynamic port set: ??(Any candidate solution?) > > AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address > sharing. Is that correct? > > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --bcaec521578d8361e504a96ec94c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Satoru,

Yes,=C2=A0the 'draft-cui-softwire-host-4= over6' doesn't mention IPv4 address sharing. But 'lightweight 4= over6' has mentioned IPv4 address sharing.

Thanks

Best wishes
<= br>
Qiong Sun

On Sat, Jul 30, 2= 011 at 9:57 PM, Satoru Matsushima <satoru.matsushima@gmail.com> wrot= e:
One clarification.

On 2011/07/29, at 10:18, GangChen wrote:

> Before making such comparison (of course it should be as fair as possi= ble),
> I think we need to state what solution space we are targeting and what=
> category mode we should take care.
> If I understand correctly, I would paraphrase as following categories.=
>
> a) Stateful+Dynamic port sets: e.g. DS-Lite
> b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 > c) Stateless + Static port set: e.g. 4rd, 4via6 translation
> d) Stateless + Dynamic port set: ??(Any candidate solution?)

AFAIK, the 'draft-cui-softwire-host-4over6' doesn't menti= on IPv4 address sharing. Is that correct?

cheers,
--satoru
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--bcaec521578d8361e504a96ec94c-- From satoru.matsushima@gmail.com Mon Aug 1 03:59:46 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C755E21F876A for ; Mon, 1 Aug 2011 03:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkLAvLGDXAmQ for ; Mon, 1 Aug 2011 03:59:46 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6221F86DE for ; Mon, 1 Aug 2011 03:59:46 -0700 (PDT) Received: by pzk6 with SMTP id 6so10520626pzk.26 for ; Mon, 01 Aug 2011 03:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gmiWqc5+kXe7BxnYHD0P4cs9jEV0RiUUU7ZuLSAHzAQ=; b=YamMaLzgLSeKOxK5GAYqDN8GALMBXSfo21sj8tlFhkKQmdGcHlVPjnY4Y2IKXUFcc+ BQvuO5319ykHpZru7J99SdQKRFvzSBz0JIqpAH+EWyN5zVv5AaPb6nJNl2sMOeFF524J 8ExdGt1KS3S0C/tdOLPzc9oOubHOvqWuqm7zY= Received: by 10.68.28.104 with SMTP id a8mr6792746pbh.431.1312196392320; Mon, 01 Aug 2011 03:59:52 -0700 (PDT) Received: from [10.201.80.64] ([202.45.12.174]) by mx.google.com with ESMTPS id b4sm5425195pba.11.2011.08.01.03.59.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 03:59:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Mon, 1 Aug 2011 19:59:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0C13D39F-7AAD-41C4-86E1-8A13F7142BD6@gmail.com> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Qiong X-Mailer: Apple Mail (2.1244.3) Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 10:59:46 -0000 Hi Qiong, On 2011/08/01, at 19:06, Qiong wrote: > Hi, Satoru, >=20 > Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address = sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing. > = http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt Thanks, I got it. Then I think that we should take = 'draft-cui-softwire-b4-translated-ds-lite' as a solution for b). cheers, --satoru >=20 > Thanks >=20 > Best wishes >=20 > Qiong Sun >=20 > On Sat, Jul 30, 2011 at 9:57 PM, Satoru Matsushima = wrote: > One clarification. >=20 > On 2011/07/29, at 10:18, GangChen wrote: >=20 > > Before making such comparison (of course it should be as fair as = possible), > > I think we need to state what solution space we are targeting and = what > > category mode we should take care. > > If I understand correctly, I would paraphrase as following = categories. > > > > a) Stateful+Dynamic port sets: e.g. DS-Lite > > b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 > > c) Stateless + Static port set: e.g. 4rd, 4via6 translation > > d) Stateless + Dynamic port set: ??(Any candidate solution?) >=20 > AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 = address sharing. Is that correct? >=20 > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 From satoru.matsushima@gmail.com Mon Aug 1 04:07:55 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB3F21F8748 for ; Mon, 1 Aug 2011 04:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4iSFxbVNluz for ; Mon, 1 Aug 2011 04:07:55 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5C9321F8743 for ; Mon, 1 Aug 2011 04:07:54 -0700 (PDT) Received: by yie30 with SMTP id 30so4043534yie.31 for ; Mon, 01 Aug 2011 04:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gxlpa1XA4XYw+62G8xz70FLiuXmkChDc93nIaRCkc0o=; b=SgbgNVATxzbIjQ5ChY8gJO/HyRMtelTTPv4os2Q7YKGgHUP+TP1pDqrg2+IcVlX9uf LKnb5e1N7cySCdAsK1a+yQHNGY4QIOwYI+IziGQJXk4iniBwwO+zTacexLAbxf/Wl0qZ tKo/exqzm/9urtGZU47vPK3LAg/2i4smNldD0= Received: by 10.142.248.36 with SMTP id v36mr2803624wfh.437.1312196880361; Mon, 01 Aug 2011 04:08:00 -0700 (PDT) Received: from [10.201.80.64] ([202.45.12.174]) by mx.google.com with ESMTPS id l7sm5422629pbh.74.2011.08.01.04.07.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 04:07:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4E36713C.904@go6.si> Date: Mon, 1 Aug 2011 20:07:55 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> To: "Jan Zorz @ go6.si" X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 11:07:55 -0000 On 2011/08/01, at 18:26, Jan Zorz @ go6.si wrote: > Well, A+P got enormous amounts of criticism because there was no = dynamic allocations of additional ports. >=20 > Now we don't need that anymore, just because stateless solution can't = handle it by design? >=20 > I love stateless a+p flavors, but imho we'll need both solutions, = stateless and statefull and both of them with dynamic port ranges or = sets, whatever you might call them. So my question is that how dynamic is dynamic, and how static is static. The analogy of dynamic routing is that dynamic for updating routing = information for prefixes but forwarding plane is stateless. If you = imagine dynamic port ranges within stateless, it sounds like port range = aware routing. I think that it would be controversial.=20 cheers, --satoru= From despres.remi@laposte.net Mon Aug 1 05:15:00 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B684421F8DC8 for ; Mon, 1 Aug 2011 05:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8MjOOMynUme for ; Mon, 1 Aug 2011 05:14:59 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 02F2E21F8DC0 for ; Mon, 1 Aug 2011 05:14:58 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 089607000091; Mon, 1 Aug 2011 14:15:03 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 3B611700008B; Mon, 1 Aug 2011 14:14:58 +0200 (CEST) X-SFR-UUID: 20110801121458243.3B611700008B@msfrf2417.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-63-1033732234 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 1 Aug 2011 14:14:57 +0200 Message-Id: <21CA1D1A-4887-4BAD-AD4A-E863DF0B7B1B@laposte.net> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Qiong X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:15:00 -0000 --Apple-Mail-63-1033732234 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 1 ao=FBt 2011 =E0 12:06, Qiong a =E9crit : > Hi, Satoru, >=20 > Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address = sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing. > = http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt Thanks for the correction. The confusion came from my original proposal (copied below with = asterisks added), and carried forward in Gang Chen's answer, sorry for = that. << a) Stateful per transport connection (and also stateful per customer = IPv6 prefix) e.g. DS-lite with CGN b) Stateful per customer IPv6 prefix (but Stateless per transport = connection)=20 e.g. *** draft-cui-softwire-host-4over6-06=20 c) Stateless per customer IPv6 prefix (and also stateless per transport = connection) - Hub-an-spoke =20 TBD - Direct CE-CE paths (mesh) . Encapsulation based=20 e.g. draft-murakami-softwire-4rd-00 alias . Translation based =20 e.g. draft-murakami-softwire-4v6-translation-00 >> Regards, RD >=20 > Thanks >=20 > Best wishes >=20 > Qiong Sun >=20 > On Sat, Jul 30, 2011 at 9:57 PM, Satoru Matsushima = wrote: > One clarification. >=20 > On 2011/07/29, at 10:18, GangChen wrote: >=20 > > Before making such comparison (of course it should be as fair as = possible), > > I think we need to state what solution space we are targeting and = what > > category mode we should take care. > > If I understand correctly, I would paraphrase as following = categories. > > > > a) Stateful+Dynamic port sets: e.g. DS-Lite > > b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 > > c) Stateless + Static port set: e.g. 4rd, 4via6 translation > > d) Stateless + Dynamic port set: ??(Any candidate solution?) >=20 > AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 = address sharing. Is that correct? >=20 > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-63-1033732234 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi, = Satoru,

Yes, the = 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address sharing. = But 'lightweight 4over6' has mentioned IPv4 address = sharing.

Thanks for the = correction.

The confusion came from my = original proposal (copied below with asterisks added), and carried = forward in Gang Chen's answer, sorry for that.
a) Stateful per transport connection = (and also stateful per customer IPv6 prefix)  e.g. DS-lite with CGNb) Stateful per customer IPv6 prefix (but Stateless per = transport connection)   e.g. *** = draft-cui-softwire-host-4over6-06 c) Stateless per customer IPv6 prefix (and also stateless = per transport connection)
    TBD  - Direct CE-CE paths (mesh)    . Encapsulation based
    . Translation based =  

Thanks

Best = wishes

Qiong Sun

On Sat, Jul 30, 2011 at 9:57 PM, Satoru Matsushima = <satoru.matsushima@gmail.com> wrote:
One = clarification.

On 2011/07/29, at 10:18, GangChen wrote:

> Before making such comparison (of course it should be as fair as = possible),
> I think we need to state what solution space we are targeting and = what
> category mode we should take care.
> If I understand correctly, I would paraphrase as following = categories.
>
> a) Stateful+Dynamic port sets: e.g. DS-Lite
> b) Stateful+Static port set: e.g. = draft-cui-softwire-host-4over6-06
> c) Stateless + Static port set: e.g. 4rd, 4via6 translation
> d) Stateless + Dynamic port set: ??(Any candidate solution?)

AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 = address sharing. Is that correct?

cheers,

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-63-1033732234-- From despres.remi@laposte.net Mon Aug 1 05:30:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12111E81AE for ; Mon, 1 Aug 2011 05:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHPfYEfNGZjY for ; Mon, 1 Aug 2011 05:30:12 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id EE3A211E81D8 for ; Mon, 1 Aug 2011 05:30:11 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 9AA70700008C; Mon, 1 Aug 2011 14:30:17 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 6C418700008A; Mon, 1 Aug 2011 14:30:17 +0200 (CEST) X-SFR-UUID: 20110801123017443.6C418700008A@msfrf2417.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4E36713C.904@go6.si> Date: Mon, 1 Aug 2011 14:30:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <640FF45D-C259-4D2D-A490-17DE1075B379@laposte.net> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> To: Jan Zorz @ go6.si X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:30:13 -0000 Le 1 ao=FBt 2011 =E0 11:26, Jan Zorz @ go6.si a =E9crit : > On 7/30/11 3:38 PM, Satoru Matsushima wrote: >> On 2011/07/30, at 8:26, Peng Wu wrote: >>>>=20 >>>> a) Stateful+Dynamic port sets: e.g. DS-Lite >>>> b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 >>>> c) Stateless + Static port set: e.g. 4rd, 4via6 translation >>>> d) Stateless + Dynamic port set: ??(Any candidate solution?) >>>=20 >>> I would say that the last one makes no sense >>=20 >> Agree. It is a problem space only on that logical frame. >> I think that the analysis work doesn't need to insist necessity of = unfeasible area solution. >=20 > Well, A+P got enormous amounts of criticism because there was no = dynamic allocations of additional ports. These criticisms are not necessarily well placed. Note that direct CE-CE paths (which some ISP's WANT to have), are = incompatible with dynamic allocations of additional ports. ISP's that want to offer dynamic allocations can always have these, = loosing then the advantage of direct CE-CE paths. > Now we don't need that anymore, just because stateless solution can't = handle it by design? We don't need it because that keeps networks simple and efficient. The debate is AFAIK still open. > I love stateless a+p flavors, but imho we'll need both solutions, = stateless and statefull and both of them with dynamic port ranges or = sets, whatever you might call them. Stateless "per customer IPv6 prefix" is incompatible with dynamic port = ranges assignable to customers. Cheers, RD >=20 > Cheers, Jan Zorz > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Aug 1 05:48:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6974A11E8443 for ; Mon, 1 Aug 2011 05:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 029vmpXgQSWg for ; Mon, 1 Aug 2011 05:48:48 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 923FE11E837E for ; Mon, 1 Aug 2011 05:48:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 922047000088; Mon, 1 Aug 2011 14:48:52 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 139DC700008A; Mon, 1 Aug 2011 14:48:50 +0200 (CEST) X-SFR-UUID: 20110801124850804.139DC700008A@msfrf2417.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-64-1035764132 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 1 Aug 2011 14:48:49 +0200 Message-Id: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:48:49 -0000 --Apple-Mail-64-1035764132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 29 juil. 2011 =E0 16:27, Cameron Byrne a =E9crit : >=20 > On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" = wrote: > > > > > > Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit : > > > > > Cameron, > > ... > > > Stateless is not exclusive with stateful one, and also NAT64. > > > I agree with Hui. > > > > +1 > > RD > > >=20 > Ok. I do think the draft would benefit from narrowing some of the = options. It seemed to me that statelessness was a key feature, but I may = have misread. >=20 Some providers may indeed prefer to have only a stateless solution, = especially in for DSL networks where ISP's provide CPE's, but there is = no technical reason preventing both solutions to coexist. > ... I am skeptical about stateless operation scaling. I don't even = have 2000 ports per user (growth to 2015 ...), >=20 Since concerned ports are only those that are residually used in IPv4 = (while more and more traffic should sooner or later become IPv6), 2000 = IPv4 ports per user seems quite sufficient. If not, would you have figures that show it? (Besides, note that 16 users per IPv4 address (a quite significant = increase), 3840 ports are available per customer (almost twice 2000). > and I don't want to get into a position where I have to tactically = move ipv4 addresses around to meet demand. >=20 If each 3GPP user gets a different IPv4 address each time it is = connected, this shouldn't be a concern. is there a different use case you have in mind? Last point: are you in fact proposing that 3GPP IPv4v6 bearers be = _replaced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both = should coexist to widen the number of options? Regards, RD=20 >=20 > > > > --Apple-Mail-64-1035764132 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> = wrote:
>
>
> Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit :
>
> > Cameron,
> ...
> > Stateless is not exclusive with stateful one, and also = NAT64.
> > I agree with Hui.
>
> +1
> RD
>

Ok. I do think the draft would benefit from narrowing some of = the options. It seemed to me that statelessness was a key feature, but I = may have misread.

Some providers may indeed prefer to = have only a stateless solution, especially in for DSL networks where = ISP's provide CPE's, but there is no technical reason preventing both = solutions to coexist.

... I am = skeptical about stateless operation scaling. I don't even have 2000 = ports per user (growth to 2015 ...),

Since concerned = ports are only those that are residually used in IPv4 (while more and = more traffic should sooner or later become IPv6), 2000 IPv4 ports per = user seems quite sufficient.
If not, would you have figures = that show it?

(Besides, note that 16 users per = IPv4 address (a quite significant increase), 3840 ports are = available per customer (almost twice = 2000).

and I don't = want to get into a position where I have to tactically move ipv4 = addresses around to meet demand.

If each 3GPP user = gets a different IPv4 address each time it is connected, this shouldn't = be a concern.
is there a different use case you have in = mind?



Last point: = are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by = IPv6-only bearers with IPv4/IPv6 translation, or that both should = coexist to widen the number of = options?



Regards,
RD 


>
>


= --Apple-Mail-64-1035764132-- From rajiva@cisco.com Mon Aug 1 06:22:24 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9062111E8078 for ; Mon, 1 Aug 2011 06:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyjTti-7eDCb for ; Mon, 1 Aug 2011 06:22:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BD00A11E8070 for ; Mon, 1 Aug 2011 06:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5227; q=dns/txt; s=iport; t=1312204950; x=1313414550; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KZjPye7rcI3YYy1Qcx2fZgj+9qGCS0b09LWEmHQbKH0=; b=gSNvPCbMopytkhrfX+jqVQy62Rj5DnuakmyXNJrjyI8JH99Uu+sFWh5s T6+TSf3rqJXad2TVxa/VYiZ0HC8Yrp0j/WCUbf/8eVPgLi8/T8Py9RwV8 K6oen+XizuCTgL7UQtMWq+NMBtLJdVzLWItXphZFQ1cXITyQ6o1bpkcmc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAOWnNk6tJV2d/2dsb2JhbABBmA2PVHeBQAEBAQECAQEBAQ8BFAkKNAsFBwQCAQgOAwEDAQEBCgYXAQYBIAYfAwYIAQEEARIIARIHh0oEoXMBnjeFY18Eh1qQMYRbhxc X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8427173" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 01 Aug 2011 13:22:26 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p71DMQxb008562; Mon, 1 Aug 2011 13:22:26 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 08:22:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 08:20:10 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6E25@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 Thread-Index: AcxNb02w9IFJj/AsTFi4fIqoTYVISQACD3+A References: From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" , "Hui Deng" X-OriginalArrivalTime: 01 Aug 2011 13:22:26.0688 (UTC) FILETIME=[0E715000:01CC504E] Cc: softwires@ietf.org, "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 13:22:24 -0000 Hi Cameron, Please see inline, > I believe the mapped mode has some similar challenges in mobile as > DS-lite. It is an IP in IP tunnel. It is really a non-starter in > 3GPP networks as the draft amply notes. =20 Thanks for sharing your opinion about the 4v6 encap mode as well as other tunneling modes (e.g DS-Lite). We agree. We make a distinction between 4v6 encap mode and tunneling mode for one simple reason - unlike an IPv4-in-IPv6 tunnel, which would carry any IPv4 datagram inside an IPv6 tunnel, 4v6 encap mode (i.e. 4rd) is about carrying only certain types (particular layer4 such as TCP, UDP) of IPv4 datagram inside an IPv6 tunnel.=20 For ex, IP-in-IP tunnel can carry GRE encapsulated IP datagrams or L2TP encaped IP datagrams, whereas 4v6 encap mode can not, as =09 defined.=20 One could deduce that 6rd and DS-Lite employ IP-in-IP tunnel, whereas 4rd doesn't really, strictly speaking. Of course, it is not a significant issue. > I believe it is best to state > that clearly for the 3GPP case, and move on without elaboration. At v6ops meeting last week, there was a consensus that softwire was to be made home for this draft (as well as various stateless NAT solutions), if Behave was to close down. Or form a new WG for stateless NAT/A+P solutions. > Is the reference to RFC6053 right? Oops. Typo. Should be 6052. Thanks for pointing it out. > Right now, i feel like it would be easier for the IETF to just define > NAT464 in general and stateless translation 4V6 is a flavor of NAT464. That's certainly one way to tackle this. > I understand the allure of stateless. But, IMHO the address > multiplexing of stateful is very useful and many large SPs already run > this way, and that operational experience is very important. =20 Many SPs have to abide by the government/regulatory mandates for Lawful Intercept and honor customers' request for particular port-forwarding/opening, and they find stateless NAT in SP network being more useful than anything else. The advantages are being better captured in the 'motivation draft'. http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motiva tion-02 Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of Cameron Byrne > Sent: Thursday, July 28, 2011 5:43 PM > To: Hui Deng > Cc: softwires@ietf.org; Wojciech Dec (wdec); Paco Cortes > Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 >=20 > On Thu, Jul 28, 2011 at 10:48 AM, Hui Deng wrote: > > Hi Cameron, > > > > You may need spend time to review it later, it's different from 6RD and > > DS-Lite, > > >=20 > I just now read it in more detail. My first piece of feedback is that > it is too long :) I assume future revisions will be more tight. I > would also say that the translation part be put into a separate draft > that goes to BEHAVE. >=20 > I believe the mapped mode has some similar challenges in mobile as > DS-lite. It is an IP in IP tunnel. It is really a non-starter in > 3GPP networks as the draft amply notes. I believe it is best to state > that clearly for the 3GPP case, and move on without elaboration. >=20 > The translation mode looks like NAT464, and i like it NAT464 + DNS64 > since it solves a real problem, as noted here > http://www.ietf.org/mail-archive/web/behave/current/msg09480.html >=20 > Is the reference to RFC6053 right? >=20 > "The operation of the 4V6 CE and > gateway are very similar, if not identical, to that of stateless > NAT64 as specified in RFC 6053." >=20 > So is this right? >=20 > CPE/UE (NAT46) --->ipv6 only network--> NAT64 (stateless port restricted) >=20 > And the port-set is delivered via some encoding in the IPv6 address > assigned to the UE? This is clever. I remain concerned about being > able to engineer stateless port allocations that sufficiently meet > everyone's needs with a limited free public IPv4 pool vs. dynamic > allocation. I do not have much experience with stateless LSN, i am > not sure anyone has much experience at scale with port restricted > stateless? I believe there are ways of going beyond 65k ports per > IPv4 address in stateful, what about in stateless? I think this will > be a requirement as the IPv4 pool keeps getting stretched thin. >=20 > Right now, i feel like it would be easier for the IETF to just define > NAT464 in general and stateless translation 4V6 is a flavor of NAT464. >=20 > I understand the allure of stateless. But, IMHO the address > multiplexing of stateful is very useful and many large SPs already run > this way, and that operational experience is very important. The IPv6 > transition space is becoming very crowded, i personally would like to > see more work to make IPv6 a true replacement for IPv4 instead of yet > another transition mechanism that meets some set for checkboxs. >=20 > This architecture is complicated. >=20 > CB > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Mon Aug 1 06:36:53 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B0C11E809D for ; Mon, 1 Aug 2011 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.87 X-Spam-Level: X-Spam-Status: No, score=-2.87 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOctlHbhKh0E for ; Mon, 1 Aug 2011 06:36:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 026D311E80AF for ; Mon, 1 Aug 2011 06:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1591; q=dns/txt; s=iport; t=1312205818; x=1313415418; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ySPwuYfMBmj2bzIh0N8M6udUWqb/SSDqqBvAFuAPhBY=; b=H9qo9nG/N9q7USEV7K6C6UOQfNB93aAousViQsAPm9/cEb5G/4TWn9IP byW0TDSDH16FD/r9VZCT/uADrYTrnTZSiiu22xYKqRGy+T6zMK5gXxECR 5UIE3sTZRYL5iucoIATRWqtT0aaVQ+TDjD/HXXw4Ei24Lnj4ni5ZKeRvv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAOiqNk6tJXHA/2dsb2JhbABBmA2PVHeBQAEBAQEDAQEBDwEdCjQXBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBMHh06hUAGeN4VjXwSHWpAxi3I X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8432762" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2011 13:36:58 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p71DawSR028917; Mon, 1 Aug 2011 13:36:58 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 08:36:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 08:36:57 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> In-Reply-To: <4E36713C.904@go6.si> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AcxQLRsXCiKMiXw3R6C7A/Czd7LBuQAIs+Fw References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> From: "Rajiv Asati (rajiva)" To: "Jan Zorz @ go6.si" , X-OriginalArrivalTime: 01 Aug 2011 13:36:57.0528 (UTC) FILETIME=[1580F380:01CC5050] Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 13:36:53 -0000 Jan, Interesting enough, the static port-set is one of the reasons why many find 4v6 being so useful.=20 Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of Jan Zorz @ go6.si > Sent: Monday, August 01, 2011 5:26 AM > To: softwires@ietf.org > Subject: Re: [Softwires] Clarification of the stateles/stateful discussion >=20 > On 7/30/11 3:38 PM, Satoru Matsushima wrote: > > On 2011/07/30, at 8:26, Peng Wu wrote: > >>> > >>> a) Stateful+Dynamic port sets: e.g. DS-Lite > >>> b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 > >>> c) Stateless + Static port set: e.g. 4rd, 4via6 translation > >>> d) Stateless + Dynamic port set: ??(Any candidate solution?) > >> > >> I would say that the last one makes no sense > > > > Agree. It is a problem space only on that logical frame. > > I think that the analysis work doesn't need to insist necessity of > unfeasible area solution. >=20 > Well, A+P got enormous amounts of criticism because there was no dynamic > allocations of additional ports. >=20 > Now we don't need that anymore, just because stateless solution can't > handle it by design? >=20 > I love stateless a+p flavors, but imho we'll need both solutions, > stateless and statefull and both of them with dynamic port ranges or > sets, whatever you might call them. >=20 > Cheers, Jan Zorz > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Aug 1 07:22:03 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BAC11E80A5 for ; Mon, 1 Aug 2011 07:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hv2p-L6jfTT for ; Mon, 1 Aug 2011 07:22:02 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7274E11E80AB for ; Mon, 1 Aug 2011 07:22:02 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id C596C7000091; Mon, 1 Aug 2011 16:22:07 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id 3FFC77000090; Mon, 1 Aug 2011 16:22:06 +0200 (CEST) X-SFR-UUID: 20110801142207262.3FFC77000090@msfrf2317.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> Date: Mon, 1 Aug 2011 16:22:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <891C27B3-1080-4F29-9820-4C095160C269@laposte.net> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:22:03 -0000 Le 1 ao=FBt 2011 =E0 15:36, Rajiv Asati (rajiva) a =E9crit : > ... Interesting enough, the static port-set is one of the reasons why = many > find 4v6 being so useful.=20 Indeed: operation simplicity, scalability, possible direct CE-CE paths. Very legitimate. Regards, RD= From jan@go6.si Mon Aug 1 07:31:42 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8953F21F8EA8 for ; Mon, 1 Aug 2011 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTjyPxBbbpYC for ; Mon, 1 Aug 2011 07:31:42 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0455E21F8EA9 for ; Mon, 1 Aug 2011 07:31:42 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 3D55723780AF; Mon, 1 Aug 2011 16:31:45 +0200 (CEST) Message-ID: <4E36B8D1.9060403@go6.si> Date: Mon, 01 Aug 2011 16:31:45 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> <891C27B3-1080-4F29-9820-4C095160C269@laposte.net> In-Reply-To: <891C27B3-1080-4F29-9820-4C095160C269@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:31:42 -0000 On 8/1/11 4:22 PM, Rémi Després wrote: > > Le 1 aoűt 2011 ŕ 15:36, Rajiv Asati (rajiva) a écrit : > >> ... Interesting enough, the static port-set is one of the reasons why many >> find 4v6 being so useful. > > Indeed: operation simplicity, scalability, possible direct CE-CE paths. > Very legitimate. Let me repeat, what was "thrown" at us, when writing ymbk-aplusp: "what happens, if customer behind CPE that shares IPv4 address runs out of ports? Does this mean that all his additional traffic from this point does not go anywhere? To end customer, this looks like broken internet connectivity." Don't get me wrong, just repeating what we needed to solve in order to move on from that point. Basically, to solve that we needed to introduce states at some point. If we can solve this issue on stateless solution, I'm all for it. Cheers, Jan From cb.list6@gmail.com Mon Aug 1 07:33:48 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D2211E8088 for ; Mon, 1 Aug 2011 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk3cWJANXsbL for ; Mon, 1 Aug 2011 07:33:48 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDCE111E8085 for ; Mon, 1 Aug 2011 07:33:47 -0700 (PDT) Received: by wyj26 with SMTP id 26so1437750wyj.31 for ; Mon, 01 Aug 2011 07:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kma4gh7TvXKLuBFMQGRyLYzpMy/X8T4XRgfXwIYjPtA=; b=sQFXiEp0gntqssTRMh1ePrEzusFxY/3sSgCP7l4Qfoe8MmbJ4fQM9gw197D86nIhdg TfzecOaJp2K7DHYORoQymR57MmhOHDLYhepfUBcJVi1+kJCDdZOueFJXVapNMvelB7wL +IKxI2NsiCRmeeuivgww78mxGQ5j61MF7KqLo= MIME-Version: 1.0 Received: by 10.216.168.72 with SMTP id j50mr767795wel.88.1312209233436; Mon, 01 Aug 2011 07:33:53 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 07:33:52 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 07:33:52 -0700 (PDT) In-Reply-To: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> Date: Mon, 1 Aug 2011 07:33:52 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0016364d259d3ae28004a97285d0 Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:33:49 -0000 --0016364d259d3ae28004a97285d0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Aug 1, 2011 5:48 AM, "R=E9mi Despr=E9s" wrote= : > > > Le 29 juil. 2011 =E0 16:27, Cameron Byrne a =E9crit : > >> >> On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" w= rote: >> > >> > >> > Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit : >> > >> > > Cameron, >> > ... >> > > Stateless is not exclusive with stateful one, and also NAT64. >> > > I agree with Hui. >> > >> > +1 >> > RD >> > >> >> Ok. I do think the draft would benefit from narrowing some of the options. It seemed to me that statelessness was a key feature, but I may have misread. > > Some providers may indeed prefer to have only a stateless solution, especially in for DSL networks where ISP's provide CPE's, but there is no technical reason preventing both solutions to coexist. >> >> ... I am skeptical about stateless operation scaling. I don't even have 2000 ports per user (growth to 2015 ...), > > Since concerned ports are only those that are residually used in IPv4 (while more and more traffic should sooner or later become IPv6), 2000 IPv4 ports per user seems quite sufficient. > If not, would you have figures that show it? > > (Besides, note that 16 users per IPv4 address (a quite significant increase), 3840 ports are available per customer (almost twice 2000). > >> and I don't want to get into a position where I have to tactically move ipv4 addresses around to meet demand. > > If each 3GPP user gets a different IPv4 address each time it is connected= , this shouldn't be a concern. > is there a different use case you have in mind? > Many, if not most, 3gpp users get rfc1918 or bogon public addresses today. Giving my users public addresses using 4v6 stateless probably does not make sense for me or many similar mobile operators. ... there are not enough public address to give these users (growth through 2015) each 2000 ports. This is just a 3gpp data point, since the draft chooses to include 3gpp as motivation. Cb > > > Last point: are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both should coexist to widen the number of options? > > > > Regards, > RD > >> >> > >> > > > --0016364d259d3ae28004a97285d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 1, 2011 5:48 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>
> Le 29 juil. 2011 =E0 16:27, Cameron Byrne a =E9crit :
>
>>
>> On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote= :
>> >
>> >
>> > Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit :
>> >
>> > > Cameron,
>> > ...
>> > > Stateless is not exclusive with stateful one, and also N= AT64.
>> > > I agree with Hui.
>> >
>> > +1
>> > RD
>> >
>>
>> Ok. I do think the draft would benefit from narrowing some of the = options. It seemed to me that statelessness was a key feature, but I may ha= ve misread.
>
> Some providers may indeed prefer to have only a stateless solution, es= pecially in for DSL networks where ISP's provide CPE's, but there i= s no technical reason preventing both solutions to coexist.
>>
>> ... I am skeptical about stateless operation scaling.=A0I don'= t even have 2000 ports per user (growth to 2015 ...),
>
> Since concerned ports are only those that are residually used in IPv4 = (while more and more traffic should sooner or later become IPv6), 2000 IPv4= ports per user seems quite sufficient.
> If not, would you have figures that show it?
>
> (Besides, note that 16 users per IPv4 address (a quite significant inc= rease),=A03840=A0ports are available per customer (almost twice 2000).
>
>> and I don't want to get into a position where I have to tactic= ally move ipv4 addresses around to meet demand.
>
> If each 3GPP user gets a different IPv4 address each time it is connec= ted, this shouldn't be a concern.
> is there a different use case you have in mind?
>

Many, if not most, 3gpp users get rfc1918 or bogon public addresses toda= y.=A0 Giving my users public addresses using 4v6 stateless probably does no= t make sense for me or many similar mobile operators. ... there are not eno= ugh public address to give these users (growth through 2015) each 2000 port= s.

This is just a 3gpp data point, since the draft chooses to include 3gpp = as motivation.

Cb
>
>
> Last point: are you in fact proposing that 3GPP IPv4v6 bearers be _rep= laced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both should= coexist to widen the number of options?
>
>
>
> Regards,
> RD=A0
>
>>
>> >
>> >
>
>

--0016364d259d3ae28004a97285d0-- From cb.list6@gmail.com Mon Aug 1 07:36:08 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E94211E8089 for ; Mon, 1 Aug 2011 07:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bZzJRs0i-Ly for ; Mon, 1 Aug 2011 07:36:07 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23B11E8073 for ; Mon, 1 Aug 2011 07:36:07 -0700 (PDT) Received: by wyj26 with SMTP id 26so1439702wyj.31 for ; Mon, 01 Aug 2011 07:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BoZdYmtaosD+C5Rn+d4aELMTI0TXFrMFPWrod/HV4hs=; b=O5krtqUAuGuoXr5EniJnxXYf6O5W4sZQ2uusA6Z1faVdwR1Z2DnsH6jaG31NMD9hwf 8lN8R7jEWNGYJEKKrKGDNL2HTgDtgzn0Xate4fnPROMJOXXgo5a/VO0BVW+71hdmewKb TDppzDJjeArKfNsT+MyyMzgeXz4cG3G74l2ek= MIME-Version: 1.0 Received: by 10.216.165.82 with SMTP id d60mr756218wel.72.1312209373039; Mon, 01 Aug 2011 07:36:13 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 07:36:12 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 07:36:12 -0700 (PDT) In-Reply-To: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> Date: Mon, 1 Aug 2011 07:36:12 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=001485f453188d0c4504a9728d20 Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:36:08 -0000 --001485f453188d0c4504a9728d20 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Aug 1, 2011 5:48 AM, "R=E9mi Despr=E9s" wrote= : > > > Le 29 juil. 2011 =E0 16:27, Cameron Byrne a =E9crit : > >> >> On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" w= rote: >> > >> > >> > Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit : >> > >> > > Cameron, >> > ... >> > > Stateless is not exclusive with stateful one, and also NAT64. >> > > I agree with Hui. >> > >> > +1 >> > RD >> > >> >> Ok. I do think the draft would benefit from narrowing some of the options. It seemed to me that statelessness was a key feature, but I may have misread. > > Some providers may indeed prefer to have only a stateless solution, especially in for DSL networks where ISP's provide CPE's, but there is no technical reason preventing both solutions to coexist. >> >> ... I am skeptical about stateless operation scaling. I don't even have 2000 ports per user (growth to 2015 ...), > > Since concerned ports are only those that are residually used in IPv4 (while more and more traffic should sooner or later become IPv6), 2000 IPv4 ports per user seems quite sufficient. > If not, would you have figures that show it? > > (Besides, note that 16 users per IPv4 address (a quite significant increase), 3840 ports are available per customer (almost twice 2000). > >> and I don't want to get into a position where I have to tactically move ipv4 addresses around to meet demand. > > If each 3GPP user gets a different IPv4 address each time it is connected= , this shouldn't be a concern. > is there a different use case you have in mind? > > > > Last point: are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both should coexist to widen the number of options? > > Both do exist today. I have had the latter in beta for over a year and it will go to production soon. Cb > > Regards, > RD > >> >> > >> > > > --001485f453188d0c4504a9728d20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 1, 2011 5:48 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>
> Le 29 juil. 2011 =E0 16:27, Cameron Byrne a =E9crit :
>
>>
>> On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote= :
>> >
>> >
>> > Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit :
>> >
>> > > Cameron,
>> > ...
>> > > Stateless is not exclusive with stateful one, and also N= AT64.
>> > > I agree with Hui.
>> >
>> > +1
>> > RD
>> >
>>
>> Ok. I do think the draft would benefit from narrowing some of the = options. It seemed to me that statelessness was a key feature, but I may ha= ve misread.
>
> Some providers may indeed prefer to have only a stateless solution, es= pecially in for DSL networks where ISP's provide CPE's, but there i= s no technical reason preventing both solutions to coexist.
>>
>> ... I am skeptical about stateless operation scaling.=A0I don'= t even have 2000 ports per user (growth to 2015 ...),
>
> Since concerned ports are only those that are residually used in IPv4 = (while more and more traffic should sooner or later become IPv6), 2000 IPv4= ports per user seems quite sufficient.
> If not, would you have figures that show it?
>
> (Besides, note that 16 users per IPv4 address (a quite significant inc= rease),=A03840=A0ports are available per customer (almost twice 2000).
>
>> and I don't want to get into a position where I have to tactic= ally move ipv4 addresses around to meet demand.
>
> If each 3GPP user gets a different IPv4 address each time it is connec= ted, this shouldn't be a concern.
> is there a different use case you have in mind?
>
>
>
> Last point: are you in fact proposing that 3GPP IPv4v6 bearers be _rep= laced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both should= coexist to widen the number of options?
>
>

Both do exist today. I have had the latter in beta for over a year and i= t will go to production soon.

Cb
>
> Regards,
> RD=A0
>
>>
>> >
>> >
>
>

--001485f453188d0c4504a9728d20-- From jan@go6.si Mon Aug 1 07:36:28 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F400711E80DD for ; Mon, 1 Aug 2011 07:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4mA3dBCOF9n for ; Mon, 1 Aug 2011 07:36:27 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5411E8073 for ; Mon, 1 Aug 2011 07:36:27 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id B562523780AF; Mon, 1 Aug 2011 16:36:31 +0200 (CEST) Message-ID: <4E36B9F0.3070607@go6.si> Date: Mon, 01 Aug 2011 16:36:32 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Satoru Matsushima References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:36:28 -0000 On 8/1/11 1:07 PM, Satoru Matsushima wrote: > So my question is that how dynamic is dynamic, and how static is > static. The analogy of dynamic routing is that dynamic for updating > routing information for prefixes but forwarding plane is stateless. > If you imagine dynamic port ranges within stateless, it sounds like > port range aware routing. I think that it would be controversial. yes, kind of. Well, is short words, whatever number of ports you assign in port-set/range, end user can exhaust them. You need then give the user additional ports in order to communicate or decide otherwise and send all additional traffic from this point on to big evil CGN in the core. Any idea how to solve this with 4rd and don't use CGN? Cheers, Jan Zorz From simon.perreault@viagenie.ca Mon Aug 1 07:44:54 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031A811E80ED for ; Mon, 1 Aug 2011 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1kqVF8orM6z for ; Mon, 1 Aug 2011 07:44:52 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD111E8073 for ; Mon, 1 Aug 2011 07:44:52 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9A14220BE2 for ; Mon, 1 Aug 2011 10:44:58 -0400 (EDT) Message-ID: <4E36BBF9.9070709@viagenie.ca> Date: Mon, 01 Aug 2011 10:45:13 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: softwires@ietf.org References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> In-Reply-To: <4E36B9F0.3070607@go6.si> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:44:54 -0000 Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: > Well, is short words, whatever number of ports you assign in port-set/range, end > user can exhaust them. The fact that most ISPs have been successfully operating with 65536 ports per subscriber demonstrates that it is possible to statically provision subscribers with "enough" ports. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rajiva@cisco.com Mon Aug 1 07:52:47 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AEC21F869D for ; Mon, 1 Aug 2011 07:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy7VfPmWP2Vc for ; Mon, 1 Aug 2011 07:52:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 010C721F8666 for ; Mon, 1 Aug 2011 07:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1645; q=dns/txt; s=iport; t=1312210373; x=1313419973; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Nrd0UCnVwGnJ/LZE20ksDI7FV6hyCRGPbOa++oYPdaQ=; b=Ro6A+/xC2Wl9M/AzrefIf7hrxEbehaiNHdU813uN8B8u8yApQRfbNkmZ hGLIqqxa00L7Tn29pdrmiinZc/W7mxvcJpHILub+fwX6/48gAV4UpTmbu FXS7AJ2KXXx7DIC2D/4gRE0S4LPzvw/1m+UKS/Hun+CKVcyti2/dO1bLD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAIC9Nk6tJXHB/2dsb2JhbABBmA2PVHeBQAEBAQEDEgEdSQwEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggTB6h6AZ5GhWNfBIcrL5Axi3I X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8456039" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2011 14:52:47 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p71EqlJ1028065; Mon, 1 Aug 2011 14:52:47 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 09:52:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 09:52:45 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6EA4@XMB-RCD-111.cisco.com> In-Reply-To: <4E36B8D1.9060403@go6.si> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AcxQV8LY9iaIWKpzQ+CTDKQlouXydwAAQeSQ References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> <891C27B3-1080-4F29-9820-4C095160C269@laposte.net> <4E36B8D1.9060403@go6.si> From: "Rajiv Asati (rajiva)" To: "Jan Zorz @ go6.si" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 01 Aug 2011 14:52:47.0107 (UTC) FILETIME=[AD439D30:01CC505A] Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:52:47 -0000 Jan, That limitation is valid, and is well applicable to both stateless and = stateful NAT. In fact, many SPs deploying stateful NAT are already carving = per-subscriber limit to solve another key problem in which one = subscriber can starve other subscribers. Eureka. :-) So, introducing state doesn't really solve the problem, considering the = evolving operational practices. Cheers, Rajiv > -----Original Message----- > From: Jan Zorz @ go6.si [mailto:jan@go6.si] > Sent: Monday, August 01, 2011 10:32 AM > To: R=E9mi Despr=E9s > Cc: Rajiv Asati (rajiva); softwires@ietf.org > Subject: Re: [Softwires] Clarification of the stateles/stateful = discussion >=20 > On 8/1/11 4:22 PM, R=E9mi Despr=E9s wrote: > > > > Le 1 ao=FBt 2011 =E0 15:36, Rajiv Asati (rajiva) a =E9crit : > > > >> ... Interesting enough, the static port-set is one of the reasons = why many > >> find 4v6 being so useful. > > > > Indeed: operation simplicity, scalability, possible direct CE-CE = paths. > > Very legitimate. >=20 > Let me repeat, what was "thrown" at us, when writing ymbk-aplusp: >=20 > "what happens, if customer behind CPE that shares IPv4 address runs = out > of ports? Does this mean that all his additional traffic from this = point > does not go anywhere? To end customer, this looks like broken internet > connectivity." >=20 > Don't get me wrong, just repeating what we needed to solve in order to > move on from that point. Basically, to solve that we needed to = introduce > states at some point. If we can solve this issue on stateless = solution, > I'm all for it. >=20 > Cheers, Jan From rajiva@cisco.com Mon Aug 1 07:59:04 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3466F11E80A0 for ; Mon, 1 Aug 2011 07:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqUrCxMR7ETN for ; Mon, 1 Aug 2011 07:59:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2111E8091 for ; Mon, 1 Aug 2011 07:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1252; q=dns/txt; s=iport; t=1312210750; x=1313420350; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vk0B1BU5GFmWFhhcBrq5hWQvtEnmml+HCclqH/GILpg=; b=WErETCLu7DW/6moWuujy1S2xV0ynvtHxuwdD7WTowatG3EWYgYIXL8H4 25bW16OpUbzB9026/1bya0NUW9E8SvkyjRX+WNM/eg9OGPDYlA3dMFz0b hTevQha0TjGuPXoMtTCOlTmXjEKtSKZjUVvRr0v6cESlxpEZbvSwMCjl3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoBAOS+Nk6tJXHB/2dsb2JhbABBmA2IPIFMhUx3gUABAQEBAwEBAQ8BFAkKNBcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah06hPQGeR4VjXwSHWpAxi3I X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8457794" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2011 14:59:09 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p71Ex3iu001539; Mon, 1 Aug 2011 14:59:09 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 09:59:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 09:59:04 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6EAD@XMB-RCD-111.cisco.com> In-Reply-To: <4E36BBF9.9070709@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AcxQWZp2BhAbON0LQFyqPnoKNQygowAAVCxw References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> From: "Rajiv Asati (rajiva)" To: "Simon Perreault" , X-OriginalArrivalTime: 01 Aug 2011 14:59:05.0693 (UTC) FILETIME=[8EEB40D0:01CC505B] Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:59:04 -0000 Indeed. And we keep forgetting an important point that most of us have been *just* fine with only 1000 (or 2000) ports since that's what most CPE/home routers in our homes had with NAT44, by default. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of Simon Perreault > Sent: Monday, August 01, 2011 10:45 AM > To: softwires@ietf.org > Subject: Re: [Softwires] Clarification of the stateles/stateful discussion >=20 > Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: > > Well, is short words, whatever number of ports you assign in port-set/range, > end > > user can exhaust them. >=20 > The fact that most ISPs have been successfully operating with 65536 ports per > subscriber demonstrates that it is possible to statically provision > subscribers > with "enough" ports. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Mon Aug 1 08:04:50 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D8521F8CFA for ; Mon, 1 Aug 2011 08:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7H5tpvwvzoo for ; Mon, 1 Aug 2011 08:04:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEA121F8CF7 for ; Mon, 1 Aug 2011 08:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1541; q=dns/txt; s=iport; t=1312211096; x=1313420696; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=uY2EGsajpobGUKTrulFE2dHdyNAAb3v+TdMTQUhkA6Q=; b=L9cYkYaY+YZxSKQ6dMBuonIGIqe8AjwoeX2nfzNOYZeB1NvPWDVmqdV6 08EbiufJ4seLkZM5RJvsdGJm3euwFpilSi/QBbVHeZ3MURakvO3MxN6mj 9+uFzpBQpBebfqqm3vLPPbWZHpuKdnDjdTtPQ+PUp4LeVP0V5Mo7KNZcG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAALANk6tJV2Z/2dsb2JhbABBmA2PVHeBQAEBAQEDAQEBDwEdCjQLDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggTB4dOoSUBnkeFY18Eh1qQMYty X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8460277" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2011 15:04:56 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p71F4uDG018978; Mon, 1 Aug 2011 15:04:56 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 10:04:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 10:04:54 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6EB7@XMB-RCD-111.cisco.com> In-Reply-To: <4E36B9F0.3070607@go6.si> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AcxQWG2hi2a99yw5QECTSiZXPIMtWQAA0qiw References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com><4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> From: "Rajiv Asati (rajiva)" To: "Jan Zorz @ go6.si" , "Satoru Matsushima" X-OriginalArrivalTime: 01 Aug 2011 15:04:56.0302 (UTC) FILETIME=[5FE5F0E0:01CC505C] Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:04:50 -0000 Jan, The better solution would be to allocate more ports to the user, depending on ISP policy. The CPE/home router can log the exhaustion of the binding and this could be notified by SNMP (at least in the managed CPE case). Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of Jan Zorz @ go6.si > Sent: Monday, August 01, 2011 10:37 AM > To: Satoru Matsushima > Cc: softwires@ietf.org > Subject: Re: [Softwires] Clarification of the stateles/stateful discussion >=20 > On 8/1/11 1:07 PM, Satoru Matsushima wrote: > > So my question is that how dynamic is dynamic, and how static is > > static. The analogy of dynamic routing is that dynamic for updating > > routing information for prefixes but forwarding plane is stateless. > > If you imagine dynamic port ranges within stateless, it sounds like > > port range aware routing. I think that it would be controversial. >=20 > yes, kind of. >=20 > Well, is short words, whatever number of ports you assign in > port-set/range, end user can exhaust them. >=20 > You need then give the user additional ports in order to communicate or > decide otherwise and send all additional traffic from this point on to > big evil CGN in the core. >=20 > Any idea how to solve this with 4rd and don't use CGN? >=20 > Cheers, Jan Zorz > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Mon Aug 1 08:05:09 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97BB11E80A0 for ; Mon, 1 Aug 2011 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OBCoOyHWNsU for ; Mon, 1 Aug 2011 08:05:09 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0F67321F8CFE for ; Mon, 1 Aug 2011 08:05:09 -0700 (PDT) Received: by pzk6 with SMTP id 6so10821957pzk.26 for ; Mon, 01 Aug 2011 08:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oxtfGWG+CIuatVmHzwVdJzAMtgJqFIWtQqXJAeqyLeo=; b=OABch9NdNYtyYi9I6+ScD22xS5IpREHTGeJ7FrEDleerQdCWji8lhK+xZOZjILLX0A tWTfIGyxIk2ReDJ9VE36eNqLlK/1yckjDOEF3viSu4m7z6KsUXMuy58WkFgWvYNFXS2R LYGw4R//vSqVbeAn1S/roTvsyk8IliYUpNsU0= Received: by 10.68.1.38 with SMTP id 6mr6574839pbj.526.1312211115277; Mon, 01 Aug 2011 08:05:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.6 with HTTP; Mon, 1 Aug 2011 08:04:54 -0700 (PDT) In-Reply-To: <4E36BBF9.9070709@viagenie.ca> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> From: Qiong Date: Mon, 1 Aug 2011 23:04:54 +0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=bcaec5215e4d657de804a972f593 Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:05:10 -0000 --bcaec5215e4d657de804a972f593 Content-Type: text/plain; charset=UTF-8 Hi, Jan, I guess this kind of port exhaustion problem will also exist in dynamic CGN. Assume the average port number consumed by average subscribers are 2000 (around 32 users per public IPv4 address) and this CGN has 32 concurrent users at that time with the only public IPv4 address in the address pool, one can still find port exhaustion when applying for more 2500 concurrent ports. So, this is a problem about how to define appropriate port set for our customers, or to define maximum concurrent subscribers for a given IPv4 address pool. Otherwise, there would either be a waste of resource, or port exhaustion. Maybe we can even make some more flexible port-set rules for different time-slot or different types of users. But anyway, this is the problem we have to face in the further, and I also suggest that port-consuming applications should upgrade to IPv6 directly. Best regards On Mon, Aug 1, 2011 at 10:45 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: > > Well, is short words, whatever number of ports you assign in > port-set/range, end > > user can exhaust them. > > The fact that most ISPs have been successfully operating with 65536 ports > per > subscriber demonstrates that it is possible to statically provision > subscribers > with "enough" ports. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --bcaec5215e4d657de804a972f593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Jan,

I guess this kind of port=C2=A0exhaustion=C2=A0= problem will also exist in dynamic CGN. Assume the average port number cons= umed by average subscribers are 2000 (around 32 users per public IPv4 addre= ss) and this CGN has 32 concurrent users at that time with the only public = IPv4 address in the address pool, one can still find port=C2=A0exhaustion w= hen applying for more 2500 concurrent ports.=C2=A0

So, this is a problem about how to define appropriate p= ort set for our customers, or to define maximum concurrent subscribers for = a given IPv4 address pool. Otherwise, there would either be a waste of reso= urce, or port=C2=A0exhaustion. Maybe we can even make some more flexible po= rt-set rules for different time-slot or different types of users. But anywa= y, this is the problem we have to face in the further, and I also suggest t= hat port-consuming applications should upgrade to IPv6 directly.

Best regards


On Mon, Aug 1, 2011 at 10:45 PM, Simon Perreault <simon.perreault@viagenie.ca= > wrote:
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
> Well, is short words, whatever number of ports you a= ssign in port-set/range, end
> user can exhaust them.

The fact that most ISPs have been successfully operating with 65536 p= orts per
subscriber demonstrates that it is possible to statically provision subscri= bers
with "enough" ports.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=
__________________________________= _____________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--bcaec5215e4d657de804a972f593-- From despres.remi@laposte.net Mon Aug 1 08:05:51 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9411E8070 for ; Mon, 1 Aug 2011 08:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzR0iD86lelc for ; Mon, 1 Aug 2011 08:05:51 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 410C621F8D00 for ; Mon, 1 Aug 2011 08:05:51 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id 13793700008A; Mon, 1 Aug 2011 17:05:57 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id D067A700008E; Mon, 1 Aug 2011 17:05:50 +0200 (CEST) X-SFR-UUID: 20110801150550853.D067A700008E@msfrf2317.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4E36B8D1.9060403@go6.si> Date: Mon, 1 Aug 2011 17:05:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60374189-CCEE-40E8-A707-8642023CD4E7@laposte.net> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> <891C27B3-1080-4F29-9820-4C095160C269@laposte.net> <4E36B8D1.9060403@go6.si> To: "Jan Zorz go6.si" X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:05:52 -0000 Le 1 ao=FBt 2011 =E0 16:31, Jan Zorz @ go6.si a =E9crit : > On 8/1/11 4:22 PM, R=E9mi Despr=E9s wrote: >>=20 >> Le 1 ao=FBt 2011 =E0 15:36, Rajiv Asati (rajiva) a =E9crit : >>=20 >>> ... Interesting enough, the static port-set is one of the reasons = why many >>> find 4v6 being so useful. >>=20 >> Indeed: operation simplicity, scalability, possible direct CE-CE = paths. >> Very legitimate. >=20 > Let me repeat, what was "thrown" at us, when writing ymbk-aplusp: >=20 > "what happens, if customer behind CPE that shares IPv4 address runs = out of ports? Does this mean that all his additional traffic from this = point does not go anywhere? To end customer, this looks like broken = internet connectivity." Thanks for the quotation. What was "thrown" to you doesn't seem right, and needs to be challenged. Answer to the question:=20 - The customer doesn't run out of ports because it has an exclusive = private IPv4 address. - If the CPE NAT44 runs out of ports, is just does what it does today in = the same situation. In addition, the probability of the CPE running out of IPv4 ports in a = dual-stack-service site having 4K ports needs not be higher than in an = IPv4-only site having 64K ports. > Don't get me wrong, just repeating what we needed to solve in order to = move on from that point. I think I don't get you wrong, and actually I believe your pioneer work = on the subject has been quite useful. It is just that what you felt obliged to solve isn't in reality needed = in a significant number of legitimate use cases. > Basically, to solve that we needed to introduce states at some point. > If we can solve this issue on stateless solution, I'm all for it. See above. Cheers, RD From rajiva@cisco.com Mon Aug 1 08:09:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCDC11E8075 for ; Mon, 1 Aug 2011 08:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g51Wj2J7fe4Z for ; Mon, 1 Aug 2011 08:09:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C3F8821F8B0A for ; Mon, 1 Aug 2011 08:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3230; q=dns/txt; s=iport; t=1312211361; x=1313420961; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jpHC6qKnQKAc0SknCN9AQK/m93GkUkKVHJT2fKJp4Lo=; b=Z4DG3eP06TJxT2iDZs+q11SjWPBmeagsaWv79rrmNKIvOTdh3Cs52eJs CxS222ZGIX3uwWbURaC4fEpWnWrxMXr8JKFDfqHHFismOk3pzoEr4dnmS 1xpLAzvobF3F5+FvWou0qz1m4ZWQTqZPNva8x0OzK9hb3Mqhd33JXtn5v 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAELBNk6tJV2d/2dsb2JhbABBmA2PVHeBQAEBAQEDEgEdSQwEAgEIDgMEAQEBCgYXAQYBRQkIAQEEARIIEwepAwGeSIVjXwSHKy+QMYty X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8462103" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2011 15:09:21 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p71F9LnS020916; Mon, 1 Aug 2011 15:09:21 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 10:09:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 10:09:19 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6EC2@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 Thread-Index: AcxQWA5dTzYtFUgUTV2GKkZqE3q2jAABGj5Q References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 01 Aug 2011 15:09:20.0519 (UTC) FILETIME=[FD624170:01CC505C] Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:09:15 -0000 Cameron, > ... there are not enough public > address to give these users (growth through 2015) each 2000 ports.=09 Agreed. Please note that 2000 ports per subscriber is just one = allocation point. It could be as low as 16 ports per subscriber.=20 In wireline deployments, 256 or 512 or 1000 ports per subscriber may be = chosen (per my discussion with various ISPs). Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf > Of Cameron Byrne > Sent: Monday, August 01, 2011 10:34 AM > To: R=E9mi Despr=E9s > Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > Subject: Re: [Softwires] 3gpp related comments on = draft-dec-stateless-4v6-02 >=20 >=20 > On Aug 1, 2011 5:48 AM, "R=E9mi Despr=E9s" = wrote: > > > > > > Le 29 juil. 2011 =E0 16:27, Cameron Byrne a =E9crit : > > > >> > >> On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" = wrote: > >> > > >> > > >> > Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit : > >> > > >> > > Cameron, > >> > ... > >> > > Stateless is not exclusive with stateful one, and also NAT64. > >> > > I agree with Hui. > >> > > >> > +1 > >> > RD > >> > > >> > >> Ok. I do think the draft would benefit from narrowing some of the = options. > It seemed to me that statelessness was a key feature, but I may have = misread. > > > > Some providers may indeed prefer to have only a stateless solution, > especially in for DSL networks where ISP's provide CPE's, but there is = no > technical reason preventing both solutions to coexist. > >> > >> ... I am skeptical about stateless operation scaling. I don't even = have > 2000 ports per user (growth to 2015 ...), > > > > Since concerned ports are only those that are residually used in = IPv4 (while > more and more traffic should sooner or later become IPv6), 2000 IPv4 = ports per > user seems quite sufficient. > > If not, would you have figures that show it? > > > > (Besides, note that 16 users per IPv4 address (a quite significant > increase), 3840 ports are available per customer (almost twice 2000). > > > >> and I don't want to get into a position where I have to tactically = move > ipv4 addresses around to meet demand. > > > > If each 3GPP user gets a different IPv4 address each time it is = connected, > this shouldn't be a concern. > > is there a different use case you have in mind? > > >=20 > Many, if not most, 3gpp users get rfc1918 or bogon public addresses = today. > Giving my users public addresses using 4v6 stateless probably does not = make > sense for me or many similar mobile operators. ... there are not = enough public > address to give these users (growth through 2015) each 2000 ports.=09 >=20 > This is just a 3gpp data point, since the draft chooses to include = 3gpp as > motivation. >=20 > Cb > > > > > > Last point: are you in fact proposing that 3GPP IPv4v6 bearers be = _replaced_ > by IPv6-only bearers with IPv4/IPv6 translation, or that both should = coexist > to widen the number of options? > > > > > > > > Regards, > > RD > > > >> > >> > > >> > > > > > >=20 From rajiva@cisco.com Mon Aug 1 08:11:41 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0969321F8B65 for ; Mon, 1 Aug 2011 08:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeMcE-FVtu1S for ; Mon, 1 Aug 2011 08:11:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4CC21F8BF6 for ; Mon, 1 Aug 2011 08:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2370; q=dns/txt; s=iport; t=1312211506; x=1313421106; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9BHlN5Y1rvOqI1Mom1uURMPaa0ODhaRJbeJV3cUc8LM=; b=Cz4MqZC6zCzvcv8akQSkoXAD8677AbmiO5Vk+P4oBbU/2n6+oQlweqvo sbI2StuNh5c96QPhURY7Uk0SZ+ENX7N0c3MOSXxSJ6em+HxaSPN1evB51 MP+lonuJ6g3lCb4WA21SuG56SADqNBobxAnh//C4rX1m49cbDVY5eTGoa c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAELBNk6tJXG+/2dsb2JhbABBmA2PVHeBQAEBAQECARIBHUkFBwQCAQgRBAEBAQoGFwEGAUUJCAEBBAESCBMHh0qhOQGeSIVjXwSHKy+QMYty X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8464652" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2011 15:11:46 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p71FBk2K008408; Mon, 1 Aug 2011 15:11:46 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 10:11:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 10:11:45 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6EC4@XMB-RCD-111.cisco.com> In-Reply-To: <60374189-CCEE-40E8-A707-8642023CD4E7@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AcxQXIVcy/L4jVZ4STONZmOyblMy8wAAK+6g References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> <891C27B3-1080-4F29-9820-4C095160C269@laposte.net> <4E36B8D1.9060403@go6.si> <60374189-CCEE-40E8-A707-8642023CD4E7@laposte.net> From: "Rajiv Asati (rajiva)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Jan Zorz go6.si" X-OriginalArrivalTime: 01 Aug 2011 15:11:45.0564 (UTC) FILETIME=[53D65DC0:01CC505D] Cc: Softwires-wg Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:11:41 -0000 > I think I don't get you wrong, and actually I believe your pioneer = work on the > subject has been quite useful. Well said, Remi. +1.=20 Cheers, Rajiv > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] > Sent: Monday, August 01, 2011 11:06 AM > To: Jan Zorz go6.si > Cc: Softwires-wg; Rajiv Asati (rajiva) > Subject: Re: [Softwires] Clarification of the stateles/stateful = discussion >=20 >=20 > Le 1 ao=FBt 2011 =E0 16:31, Jan Zorz @ go6.si a =E9crit : >=20 > > On 8/1/11 4:22 PM, R=E9mi Despr=E9s wrote: > >> > >> Le 1 ao=FBt 2011 =E0 15:36, Rajiv Asati (rajiva) a =E9crit : > >> > >>> ... Interesting enough, the static port-set is one of the reasons = why many > >>> find 4v6 being so useful. > >> > >> Indeed: operation simplicity, scalability, possible direct CE-CE = paths. > >> Very legitimate. > > > > Let me repeat, what was "thrown" at us, when writing ymbk-aplusp: > > > > "what happens, if customer behind CPE that shares IPv4 address runs = out of > ports? Does this mean that all his additional traffic from this point = does not > go anywhere? To end customer, this looks like broken internet = connectivity." >=20 > Thanks for the quotation. > What was "thrown" to you doesn't seem right, and needs to be = challenged. >=20 > Answer to the question: > - The customer doesn't run out of ports because it has an exclusive = private > IPv4 address. > - If the CPE NAT44 runs out of ports, is just does what it does today = in the > same situation. > In addition, the probability of the CPE running out of IPv4 ports in a = dual- > stack-service site having 4K ports needs not be higher than in an = IPv4-only > site having 64K ports. >=20 >=20 > > Don't get me wrong, just repeating what we needed to solve in order = to move > on from that point. >=20 > I think I don't get you wrong, and actually I believe your pioneer = work on the > subject has been quite useful. > It is just that what you felt obliged to solve isn't in reality needed = in a > significant number of legitimate use cases. >=20 >=20 > > Basically, to solve that we needed to introduce states at some = point. > > If we can solve this issue on stateless solution, I'm all for it. >=20 > See above. >=20 > Cheers, > RD >=20 >=20 >=20 >=20 >=20 >=20 >=20 From despres.remi@laposte.net Mon Aug 1 08:24:36 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E42111E80C7 for ; Mon, 1 Aug 2011 08:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxSUj7VgL08G for ; Mon, 1 Aug 2011 08:24:35 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 506FA11E8094 for ; Mon, 1 Aug 2011 08:24:34 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id 03BC07000087; Mon, 1 Aug 2011 17:24:41 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id A2A21700008C; Mon, 1 Aug 2011 17:24:40 +0200 (CEST) X-SFR-UUID: 20110801152440666.A2A21700008C@msfrf2317.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-65-1045115071 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 1 Aug 2011 17:24:40 +0200 Message-Id: <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:24:36 -0000 --Apple-Mail-65-1045115071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Cameron, Thanks for the clarification. More below. =20 Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : ... > > Some providers may indeed prefer to have only a stateless solution, = especially in for DSL networks where ISP's provide CPE's, but there is = no technical reason preventing both solutions to coexist >=20 ... > Many, if not most, 3gpp users get rfc1918 or bogon public addresses = today. Giving my users public addresses using 4v6 stateless probably = does not make sense for me or many similar mobile operators. ... there = are not enough public address to give these users (growth through 2015) = each 2000 ports. >=20 I don't se a significant disagreement here.=20 If you have an overwhelming need for dynamic port sharing, it has to be = faced, and you will go for CGN's. I don't argue against this. Some other operators may however have different constraints, and should = be permitted to operate whatever simpler solution applies to their case. Note that one can expect that in 2015 users should work mostly, if not = exclusively in IPv6, so that their need should be well well below 2000 = IPv4 ports for each. > This is just a 3gpp data point, since the draft chooses to include = 3gpp as motivation. >=20 I appreciate that, and agree that the case for stateless A+P mapping is = clearer for DSL and optical fibers than for 3GPP=20 Regards, RD --Apple-Mail-65-1045115071 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

> Some providers may indeed prefer to have only a stateless solution, = especially in for DSL networks where ISP's provide CPE's, but there is = no technical reason preventing both solutions to = coexist

...

Many, if not = most, 3gpp users get rfc1918 or bogon public addresses today.  = Giving my users public addresses using 4v6 stateless probably does not = make sense for me or many similar mobile operators. ... there are not = enough public address to give these users (growth through 2015) each = 2000 ports.

I don't se a significant disagreement = here. 

If you have an overwhelming need for = dynamic port sharing, it has to be faced, and you will go for CGN's. I = don't argue against this.

Some other operators = may however have different constraints, and should be permitted to = operate whatever simpler solution applies to their = case.

Note that one can expect that in 2015 = users should work mostly, if not exclusively in IPv6, so that their need = should be well well below 2000 IPv4 ports for = each.

This is just = a 3gpp data point, since the draft chooses to include 3gpp as = motivation.

I appreciate that, and agree = that the case for stateless A+P mapping is clearer for DSL and = optical fibers than for = 3GPP 


Regards,
RD
<= div>


= --Apple-Mail-65-1045115071-- From despres.remi@laposte.net Mon Aug 1 08:32:53 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C75521F8869 for ; Mon, 1 Aug 2011 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3qtdZw5aIXI for ; Mon, 1 Aug 2011 08:32:52 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 6D39111E80DA for ; Mon, 1 Aug 2011 08:32:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 4C1F87000088; Mon, 1 Aug 2011 17:32:54 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 5C04F700008A; Mon, 1 Aug 2011 17:32:53 +0200 (CEST) X-SFR-UUID: 20110801153253377.5C04F700008A@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-66-1045607735 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 1 Aug 2011 17:32:53 +0200 Message-Id: <8E225408-EACE-490A-B5B5-41F9AF0F8C2C@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:32:53 -0000 --Apple-Mail-66-1045607735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 1 ao=FBt 2011 =E0 16:36, Cameron Byrne a =E9crit : > > are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by = IPv6-only bearers with IPv4/IPv6 translation, or that both should = coexist to widen the number of options? > > >=20 >=20 > Both do exist today. I have had the latter in beta for over a year and = it will go to production soon. >=20 Thank you for sharing this information. I infer that the extra header size of 20 octets that 4V6 Translation = has, compared to the IPv4v6 Bearer, isn't considered a show stopper. Hopefully, we won't hear too much of the header size argument in the = future. Regards, RD=20 --Apple-Mail-66-1045607735 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

> are = you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by = IPv6-only bearers with IPv4/IPv6 translation, or that both should = coexist to widen the number of options?
>

Both do = exist today. I have had the latter in beta for over a year and it will = go to production soon.


Thank you for sharing = this information.

I infer that the extra header = size of 20 octets that 4V6 Translation has, compared to the IPv4v6 = Bearer, isn't considered a show stopper.
Hopefully, we won't = hear too much of the header size argument in the = future.

Regards,
RD 

= --Apple-Mail-66-1045607735-- From cb.list6@gmail.com Mon Aug 1 08:36:14 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E352721F8B3C for ; Mon, 1 Aug 2011 08:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP3DqG26T7XR for ; Mon, 1 Aug 2011 08:36:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E947621F8B3B for ; Mon, 1 Aug 2011 08:36:13 -0700 (PDT) Received: by wyj26 with SMTP id 26so1492646wyj.31 for ; Mon, 01 Aug 2011 08:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bw+fOblDkYcUJ9ngGmih2Iw4Y6TG4Nj6Lv9pexvzQx4=; b=RwvOrAoNdkitlDL4m/S4q8HfNZ9jfisIoflCnhqwiWXb2NMD+GOh0pDYVzBNnb/2Vx R+e2NyN3im4+mK85vNQXc+d5PNbM8c6Y93bJGPBPmHCwaTkLluhZlFUxBezx7Jvm/mA5 lqQRuWfbPv8jGxYWxxVJLl4Q+7pP6j3o0wbUI= MIME-Version: 1.0 Received: by 10.216.132.129 with SMTP id o1mr809064wei.73.1312212979830; Mon, 01 Aug 2011 08:36:19 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 08:36:18 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 08:36:18 -0700 (PDT) In-Reply-To: <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> Date: Mon, 1 Aug 2011 08:36:18 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0016e6de03a48850eb04a97364e3 Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:36:15 -0000 --0016e6de03a48850eb04a97364e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Aug 1, 2011 8:24 AM, "R=E9mi Despr=E9s" wrote= : > > Cameron, > > Thanks for the clarification. > More below. > > Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > ... >> >> > Some providers may indeed prefer to have only a stateless solution, especially in for DSL networks where ISP's provide CPE's, but there is no technical reason preventing both solutions to coexist > > ... >> >> Many, if not most, 3gpp users get rfc1918 or bogon public addresses today. Giving my users public addresses using 4v6 stateless probably does not make sense for me or many similar mobile operators. ... there are not enough public address to give these users (growth through 2015) each 2000 ports. > > I don't se a significant disagreement here. > > If you have an overwhelming need for dynamic port sharing, it has to be faced, and you will go for CGN's. I don't argue against this. > > Some other operators may however have different constraints, and should b= e permitted to operate whatever simpler solution applies to their case. > Of course, agreed. > Note that one can expect that in 2015 users should work mostly, if not exclusively in IPv6, so that their need should be well well below 2000 IPv4 ports for each. >> This is just a 3gpp data point, since the draft chooses to include 3gpp as motivation. > > I appreciate that, and agree that the case for stateless A+P mapping is clearer for DSL and optical fibers than for 3GPP > The authors may want to note this point. > > Regards, > RD > > > --0016e6de03a48850eb04a97364e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 1, 2011 8:24 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
> Cameron,
>
> Thanks for the clarification.
> More below.
> =A0
> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit :
> ...
>>
>> > Some providers may indeed prefer to have only a stateless sol= ution, especially in for DSL networks where ISP's provide CPE's, bu= t there is no technical reason preventing both solutions to coexist
>
> ...
>>
>> Many, if not most, 3gpp users get rfc1918 or bogon public addresse= s today.=A0 Giving my users public addresses using 4v6 stateless probably d= oes not make sense for me or many similar mobile operators. ... there are n= ot enough public address to give these users (growth through 2015) each 200= 0 ports.
>
> I don't se a significant disagreement here.=A0
>
> If you have an overwhelming need for dynamic port sharing, it has to b= e faced, and you will go for CGN's. I don't argue against this.
>
> Some other operators may however have different constraints, and shoul= d be permitted to operate whatever simpler solution applies to their case.<= br> >

Of course, agreed.

> Note that one can expect that in 2015 users should work mostly, if = not exclusively in IPv6, so that their need should be well well below 2000 = IPv4 ports for each.
>> This is just a 3gpp data point, since the draft chooses to include= 3gpp as motivation.
>
> I appreciate that, and agree that=A0the case for stateless A+P mapping= is clearer for DSL and optical fibers than for 3GPP=A0
>

The authors may want to note this point.

>
> Regards,
> RD
>
>
>

--0016e6de03a48850eb04a97364e3-- From rajiva@cisco.com Mon Aug 1 08:38:29 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0707F21F8C3A for ; Mon, 1 Aug 2011 08:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbMLnGuP48Rl for ; Mon, 1 Aug 2011 08:38:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5494321F8C36 for ; Mon, 1 Aug 2011 08:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2294; q=dns/txt; s=iport; t=1312213115; x=1313422715; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EL9L1abRn6h86ZL0o+dAu3WTwXfEfsiFC/Fcg77WJ5I=; b=bySU7QesSUlteTIIl6njundnyq7IUDBAJplyi4lKGQ/VcKyMe8TG9N1j goFRufayq5M/WeddBwdkAp/4dDRapjDwSQWl8bFQOCD/ZAUCzDRiUR5HY XB9wMRbPS2BE5mCeG6Ugh29uH9DyAW9K93QVYcAL6IdPyQeG4CbQnmSg+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAHrHNk6tJV2a/2dsb2JhbABBmA2PVHeBQAEBAQECARIBHUkFBwQCAQgRBAEBCwYXAQYBRQkIAQEEARIIEweHSqFUAZ5GhWNfBIcrL5Axi3I X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8471630" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 01 Aug 2011 15:38:17 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p71FcHED023976; Mon, 1 Aug 2011 15:38:17 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 10:38:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 10:38:15 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6EFE@XMB-RCD-111.cisco.com> In-Reply-To: <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 Thread-Index: AcxQXybSHpaI09/XQkaQgczs4gVXeQAAaSwA References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> From: "Rajiv Asati (rajiva)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Cameron Byrne" X-OriginalArrivalTime: 01 Aug 2011 15:38:17.0060 (UTC) FILETIME=[08716240:01CC5061] Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:38:29 -0000 > I appreciate that, and agree that the case for stateless A+P mapping = is > clearer for DSL and optical fibers than for 3GPP There are other 3GPP operators who favor using stateless A+P mapping, so = I would shy away from the above agreement. Of course, different = operators have different constraints that make them favor one or the = other solution, as you rightly said.=20 Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf > Of R=E9mi Despr=E9s > Sent: Monday, August 01, 2011 11:25 AM > To: Cameron Byrne > Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > Subject: Re: [Softwires] 3gpp related comments on = draft-dec-stateless-4v6-02 >=20 > Cameron, >=20 > Thanks for the clarification. > More below. >=20 >=20 >=20 > Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > ... >=20 > > Some providers may indeed prefer to have only a stateless solution, > especially in for DSL networks where ISP's provide CPE's, but there is = no > technical reason preventing both solutions to coexist >=20 > ... >=20 >=20 > Many, if not most, 3gpp users get rfc1918 or bogon public addresses > today. Giving my users public addresses using 4v6 stateless probably = does not > make sense for me or many similar mobile operators. ... there are not = enough > public address to give these users (growth through 2015) each 2000 = ports. >=20 > I don't se a significant disagreement here. >=20 > If you have an overwhelming need for dynamic port sharing, it has to = be faced, > and you will go for CGN's. I don't argue against this. >=20 > Some other operators may however have different constraints, and = should be > permitted to operate whatever simpler solution applies to their case. >=20 > Note that one can expect that in 2015 users should work mostly, if not > exclusively in IPv6, so that their need should be well well below 2000 = IPv4 > ports for each. >=20 >=20 > This is just a 3gpp data point, since the draft chooses to include = 3gpp > as motivation. >=20 > I appreciate that, and agree that the case for stateless A+P mapping = is > clearer for DSL and optical fibers than for 3GPP >=20 >=20 > Regards, > RD >=20 >=20 From rajiva@cisco.com Mon Aug 1 08:44:10 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBC521F8C88 for ; Mon, 1 Aug 2011 08:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO6kcaskofHA for ; Mon, 1 Aug 2011 08:44:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CD28C21F8C3B for ; Mon, 1 Aug 2011 08:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2498; q=dns/txt; s=iport; t=1312213456; x=1313423056; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=m172/Gu1yLQpi1xgisV2nevzo9jG9aXXFSolq0UFEAQ=; b=ZjuBt/Yusbhe07PuJvXqS0cGaMZy/eH33JkOoauXXrlbaTUjxuQ2vUCH 4VumDY//spu6Oika+75UvN5PPbkLRx3rAQa1ybFQngujvKQi2TtVep6PE C2af11sWvG03NoK1JBIqD/kECwTCoTGsznU3aIIJYl0sfMBLMsLjkBTRM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAPfINk6tJXG+/2dsb2JhbABBmA2PVHeBQAEBAQEDEgEdSQwEAgEIDgMEAQEBCgYXAQYBRQkIAQEEARIIEwepCwGeRoVjXwSHKy+QMYty X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8475318" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2011 15:44:16 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p71FiGB2022904; Mon, 1 Aug 2011 15:44:16 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 10:44:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 10:44:14 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6F05@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 Thread-Index: AcxQYNC4MWYdWuFVT7CdvQIq36+JSgAAFfKw References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net><59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 01 Aug 2011 15:44:15.0910 (UTC) FILETIME=[DE558C60:01CC5061] Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:44:10 -0000 We agree that different operators (whether in 3GPP/mobile space or = Wireline (DSL/Cable/Fiber) space) would embrace stateful or stateless = NAT based solution, per their short-term & long-term plans and = associated constraints.=20 Perhaps, it could be phrased a bit better in the draft, but that's not = to say that stateless NAT/A+P becomes inapplicable to a particular space = right away. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf > Of Cameron Byrne > Sent: Monday, August 01, 2011 11:36 AM > To: R=E9mi Despr=E9s > Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > Subject: Re: [Softwires] 3gpp related comments on = draft-dec-stateless-4v6-02 >=20 >=20 > On Aug 1, 2011 8:24 AM, "R=E9mi Despr=E9s" = wrote: > > > > Cameron, > > > > Thanks for the clarification. > > More below. > > > > Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > > ... > >> > >> > Some providers may indeed prefer to have only a stateless = solution, > especially in for DSL networks where ISP's provide CPE's, but there is = no > technical reason preventing both solutions to coexist > > > > ... > >> > >> Many, if not most, 3gpp users get rfc1918 or bogon public addresses = today. > Giving my users public addresses using 4v6 stateless probably does not = make > sense for me or many similar mobile operators. ... there are not = enough public > address to give these users (growth through 2015) each 2000 ports. > > > > I don't se a significant disagreement here. > > > > If you have an overwhelming need for dynamic port sharing, it has to = be > faced, and you will go for CGN's. I don't argue against this. > > > > Some other operators may however have different constraints, and = should be > permitted to operate whatever simpler solution applies to their case. > > >=20 > Of course, agreed. >=20 > > Note that one can expect that in 2015 users should work mostly, if = not > exclusively in IPv6, so that their need should be well well below 2000 = IPv4 > ports for each. > >> This is just a 3gpp data point, since the draft chooses to include = 3gpp as > motivation. > > > > I appreciate that, and agree that the case for stateless A+P mapping = is > clearer for DSL and optical fibers than for 3GPP > > >=20 > The authors may want to note this point. >=20 > > > > Regards, > > RD > > > > > > >=20 From ichiroumakino@gmail.com Mon Aug 1 08:50:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156E111E80A6 for ; Mon, 1 Aug 2011 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd9aBjx33wwu for ; Mon, 1 Aug 2011 08:50:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDFBD11E8090 for ; Mon, 1 Aug 2011 08:50:13 -0700 (PDT) Received: by wyj26 with SMTP id 26so1503633wyj.31 for ; Mon, 01 Aug 2011 08:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Je1obmRZjVv/qlXVAi1J54mv2hUHXGf3zdYtqRug1BM=; b=ZMpAnreIeNdHvKr1ZQxOQLDecQiLKYpnEaYmaYt6eqRv/Hrjq3SF3X7K5YykGU0W2S QBtCoAKX9lq684ejXvVGYRJw/1unQFLfY6w7QAml8ejYW55vBa/OkKua3I+0YuGJqiB4 98WiupSeelQPnvYVEd+q5tlErfwUwrzFDkeHQ= Received: by 10.216.142.6 with SMTP id h6mr864484wej.19.1312213818446; Mon, 01 Aug 2011 08:50:18 -0700 (PDT) Received: from ams3-vpn-dhcp6883.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id n33sm3422676weq.36.2011.08.01.08.50.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 08:50:17 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E36BBF9.9070709@viagenie.ca> Date: Mon, 1 Aug 2011 17:50:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:50:15 -0000 > Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: >> Well, is short words, whatever number of ports you assign in = port-set/range, end >> user can exhaust them. >=20 > The fact that most ISPs have been successfully operating with 65536 = ports per > subscriber demonstrates that it is possible to statically provision = subscribers > with "enough" ports. many ISPs have deployed with much less than 64K ports. a typical = limitation in CPE's NAT table is just 1024 ports. I've certainly = returned CPEs to my ISPs with that limitation in the past. cheers, Ole From despres.remi@laposte.net Mon Aug 1 08:53:09 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C415011E80B7 for ; Mon, 1 Aug 2011 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejU+af52WeNA for ; Mon, 1 Aug 2011 08:53:09 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7D311E8090 for ; Mon, 1 Aug 2011 08:53:08 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 2BDC57000090; Mon, 1 Aug 2011 17:53:15 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id CCFBD700008F; Mon, 1 Aug 2011 17:53:14 +0200 (CEST) X-SFR-UUID: 20110801155314839.CCFBD700008F@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 1 Aug 2011 17:53:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> To: Qiong X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:53:09 -0000 Le 1 ao=FBt 2011 =E0 17:04, Qiong a =E9crit : ... > So, this is a problem about how to define appropriate port set for our = customers, or to define maximum concurrent subscribers for a given IPv4 = address pool. Otherwise, there would either be a waste of resource, or = port exhaustion. > Maybe we can even make some more flexible port-set rules for different = time-slot or different types of users. There is AFAIK no need to make port-set rules themselves more flexible. Two customer classes (and tariffs) with standard port-set sizes should = IMHO be sufficient: =20 - One for exclusive IOPv4 addresses - One for shared addresses. Their different port-set sizes are expressed by the difference between = lengths of their IPv6 assigned prefixes.=20 Three classes would give even more flexibility, but it doesn't seem to = me necessary. (Keep it simple, stupid!) > But anyway, this is the problem we have to face in the further, and > I also suggest that port-consuming applications should upgrade to IPv6 = directly. Absolutely. Actually, where native IPv6 addresses are already available, a = significant part of the traffic is already IPv6. Regards, RD From rajiva@cisco.com Mon Aug 1 08:55:29 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A5C11E80CC for ; Mon, 1 Aug 2011 08:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt1PWUk5ykwd for ; Mon, 1 Aug 2011 08:55:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 378B611E8090 for ; Mon, 1 Aug 2011 08:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1890; q=dns/txt; s=iport; t=1312214136; x=1313423736; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=J1DCioHgx+h/gh+bKyKc8cLR/0+59jtjPosj/gDNEmM=; b=Jmsmnzoh/bSLhs6hSdQ74mgxKRngnRNgMBWvkOPqFVAMYleQOXUf7IV5 aSBe4/zMhj+DB5dAC0doP9M02lsA5DSQHau5mIFaXma8oNjUgHbROYEAX uN5r+UxWcQl75f5phx65YQjYMxsn2oxEjss5G6hsR2Cl8A7sSR1uTEmNY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AALDLNk6tJXG//2dsb2JhbABBDpd/j1R3gUABAQEBAgEBAQEPAR0KNBAHBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCBMHh0oEoUIBnkaFY18Eh1qQMYsdVQ X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8478357" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 01 Aug 2011 15:55:35 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71FtZ4L028059; Mon, 1 Aug 2011 15:55:35 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 10:55:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 10:55:34 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6F17@XMB-RCD-111.cisco.com> In-Reply-To: <201107302215444330623@csnet1.cs.tsinghua.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] DS-lite Multicast Thread-Index: AcxOw0IQuTE4OsdfS0eODozSshY1JgBoBDMQ References: <201107302215444330623@csnet1.cs.tsinghua.edu.cn> From: "Rajiv Asati (rajiva)" To: "Peng Wu" , "Lee, Yiu" , X-OriginalArrivalTime: 01 Aug 2011 15:55:35.0375 (UTC) FILETIME=[7353ADF0:01CC5063] Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:55:29 -0000 > I think definitely we should define the first case, isn't reduce redundant > delivery the original spirit of multicast? Deliver multicast over an IPv6 > multicast disabled network doesn't seem quite persuading, except the legacy > case.=09 And AMT has been devised to address that very space. :) We should not reinvent another solution for that space. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of Peng Wu > Sent: Saturday, July 30, 2011 10:16 AM > To: Lee, Yiu; softwires@ietf.org > Subject: Re: [Softwires] DS-lite Multicast >=20 > Hi all, >=20 > I think definitely we should define the first case, isn't reduce redundant > delivery the original spirit of multicast? Deliver multicast over an IPv6 > multicast disabled network doesn't seem quite persuading, except the legacy > case.=09 >=20 > So if we need to choose one, then I prefer the first one. Or can we make the > second case a special case in one unified draft? >=20 > >Hi WG, > > > >In today meeting, we presented two drafts on to enable multicast in DS-lite. > I think they target different use cases: > > > >The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite- > multicast-04 is to deliver multicast over DS-lite in an IPv6 multicast enabled > network. > > > >The use case of http://tools.ietf.org/html/draft-sarikaya-softwire- > dslitemulticast-00 is to deliver multicast over DS-lite in an IPv6 multicast > disabled network. > > > >I think both drafts target different use cases. My question to the WG is: > Should we work on both use cases? If not, which use case the WG should work on > first? > > >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Mon Aug 1 09:01:27 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DF811E8090 for ; Mon, 1 Aug 2011 09:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tem+jQ6IZlIs for ; Mon, 1 Aug 2011 09:01:27 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4297211E8077 for ; Mon, 1 Aug 2011 09:01:27 -0700 (PDT) Received: by yie30 with SMTP id 30so4242437yie.31 for ; Mon, 01 Aug 2011 09:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AipvU4IMXA3X2XyZIz95ylXi1rYHDSA81heNAxHUJMQ=; b=UAeuguxDr8nzv1jjWAKkHpwmm9oJePb4NBi1dFQOAHMWBlspjBivn5zU95S3+js3qp /hL8puHOqaMhlsriobxDtXIfFRrb9rEu7iFI5ywz/rvj0VhpZ4IfFc15nXe8pcZZZnK9 cD3PL1ugSagzakBgJ5UVohxC8SQDPFPnwf7RM= Received: by 10.68.58.231 with SMTP id u7mr3365498pbq.258.1312214491143; Mon, 01 Aug 2011 09:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.196 with HTTP; Mon, 1 Aug 2011 09:01:11 -0700 (PDT) In-Reply-To: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> From: Qiong Date: Tue, 2 Aug 2011 00:01:11 +0800 Message-ID: To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Content-Type: multipart/alternative; boundary=bcaec54306389d1e0e04a973beff Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:01:28 -0000 --bcaec54306389d1e0e04a973beff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Remi, Agree. I only mean that for some extreme use cases where higher priority user would like to apply for more ports. But in the foreseeable future, I also think that two customer classes would be enough. Thanks. On Mon, Aug 1, 2011 at 11:53 PM, R=C3=A9mi Despr=C3=A9s wrote: > > Le 1 ao=C3=BBt 2011 =C3=A0 17:04, Qiong a =C3=A9crit : > > ... > > So, this is a problem about how to define appropriate port set for our > customers, or to define maximum concurrent subscribers for a given IPv4 > address pool. Otherwise, there would either be a waste of resource, or po= rt > exhaustion. > > > Maybe we can even make some more flexible port-set rules for different > time-slot or different types of users. > > There is AFAIK no need to make port-set rules themselves more flexible. > > Two customer classes (and tariffs) with standard port-set sizes should IM= HO > be sufficient: > - One for exclusive IOPv4 addresses > - One for shared addresses. > Their different port-set sizes are expressed by the difference between > lengths of their IPv6 assigned prefixes. > > Three classes would give even more flexibility, but it doesn't seem to me > necessary. (Keep it simple, stupid!) > > > But anyway, this is the problem we have to face in the further, and > > > I also suggest that port-consuming applications should upgrade to IPv6 > directly. > > Absolutely. > Actually, where native IPv6 addresses are already available, a significan= t > part of the traffic is already IPv6. > > Regards, > RD > > > > > --bcaec54306389d1e0e04a973beff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Remi,

Agree. I only mean that for some extreme use cases wh= ere higher priority user would like to apply for more ports. But in the for= eseeable future, I also think that two customer classes would be enough.

Thanks.=C2=A0

= On Mon, Aug 1, 2011 at 11:53 PM, R=C3=A9mi Despr=C3=A9s &= lt;despres.remi@laposte.net= > wrote:

Le 1 ao=C3=BBt 2011 =C3=A0 17:04, Qiong a =C3=A9crit :

...
> So, this is a problem about how to define appropriat= e port set for our customers, or to define maximum concurrent subscribers f= or a given IPv4 address pool. Otherwise, there would either be a waste of r= esource, or port exhaustion.

> Maybe we can even make some more flexible port-set rules for different= time-slot or different types of users.

There is AFAIK no need to make port-set rules themselves more flexibl= e.

Two customer classes (and tariffs) with standard port-set sizes should IMHO= be sufficient:
- One for exclusive IOPv4 addresses
- One for shared addresses.
Their different port-set sizes are expressed by the difference between leng= ths of their IPv6 assigned prefixes.

Three classes would give even more flexibility, but it doesn't seem to = me necessary. (Keep it simple, stupid!)

> But anyway, this is the problem we have to face in the further, and
> I also suggest that port-consuming applications should upgrade to IPv6= directly.

Absolutely.
Actually, where native IPv6 addresses are already available, a significant = part of the traffic is already IPv6.

Regards,
RD





--bcaec54306389d1e0e04a973beff-- From despres.remi@laposte.net Mon Aug 1 09:21:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ECF11E8104 for ; Mon, 1 Aug 2011 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brgUeXIMQ8f9 for ; Mon, 1 Aug 2011 09:21:14 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB8011E80FE for ; Mon, 1 Aug 2011 09:21:12 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 9B229700008C; Mon, 1 Aug 2011 18:21:18 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 1DC1E700008A; Mon, 1 Aug 2011 18:21:14 +0200 (CEST) X-SFR-UUID: 20110801162114121.1DC1E700008A@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C058E6F05@XMB-RCD-111.cisco.com> Date: Mon, 1 Aug 2011 18:21:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EF6E9E8-C917-4A3D-B8E6-607747D06CF8@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net><59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> <067E6CE33034954AAC05C9EC85E2577C058E6F05@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:21:15 -0000 Le 1 ao=FBt 2011 =E0 17:44, Rajiv Asati (rajiva) a =E9crit : > We agree that different operators (whether in 3GPP/mobile space or = Wireline (DSL/Cable/Fiber) space) would embrace stateful or stateless = NAT based solution, per their short-term & long-term plans and = associated constraints.=20 Note that with stateless mappings + encapsulation, "stateless NAT" is an = inappropriate wording, because there is no translation: - This ensures e2e transparency,=20 - At least for customers that are assigned exclusive IPv4 addresses, = this e2e transparency is important (IP options, TOS, maybe others). Cheers, RD >=20 > Perhaps, it could be phrased a bit better in the draft, but that's not = to say that stateless NAT/A+P becomes inapplicable to a particular space = right away. >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf >> Of Cameron Byrne >> Sent: Monday, August 01, 2011 11:36 AM >> To: R=E9mi Despr=E9s >> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) >> Subject: Re: [Softwires] 3gpp related comments on = draft-dec-stateless-4v6-02 >>=20 >>=20 >> On Aug 1, 2011 8:24 AM, "R=E9mi Despr=E9s" = wrote: >>>=20 >>> Cameron, >>>=20 >>> Thanks for the clarification. >>> More below. >>>=20 >>> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : >>> ... >>>>=20 >>>>> Some providers may indeed prefer to have only a stateless = solution, >> especially in for DSL networks where ISP's provide CPE's, but there = is no >> technical reason preventing both solutions to coexist >>>=20 >>> ... >>>>=20 >>>> Many, if not most, 3gpp users get rfc1918 or bogon public addresses = today. >> Giving my users public addresses using 4v6 stateless probably does = not make >> sense for me or many similar mobile operators. ... there are not = enough public >> address to give these users (growth through 2015) each 2000 ports. >>>=20 >>> I don't se a significant disagreement here. >>>=20 >>> If you have an overwhelming need for dynamic port sharing, it has to = be >> faced, and you will go for CGN's. I don't argue against this. >>>=20 >>> Some other operators may however have different constraints, and = should be >> permitted to operate whatever simpler solution applies to their case. >>>=20 >>=20 >> Of course, agreed. >>=20 >>> Note that one can expect that in 2015 users should work mostly, if = not >> exclusively in IPv6, so that their need should be well well below = 2000 IPv4 >> ports for each. >>>> This is just a 3gpp data point, since the draft chooses to include = 3gpp as >> motivation. >>>=20 >>> I appreciate that, and agree that the case for stateless A+P mapping = is >> clearer for DSL and optical fibers than for 3GPP >>>=20 >>=20 >> The authors may want to note this point. >>=20 >>>=20 >>> Regards, >>> RD >>>=20 >>>=20 >>>=20 >>=20 >=20 From wdec.ietf@gmail.com Mon Aug 1 09:26:27 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2589B21F8C3F for ; Mon, 1 Aug 2011 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68AIUgv8PyeC for ; Mon, 1 Aug 2011 09:26:26 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5C421F8C25 for ; Mon, 1 Aug 2011 09:26:26 -0700 (PDT) Received: by gwb20 with SMTP id 20so4390942gwb.31 for ; Mon, 01 Aug 2011 09:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tLuUE3bSBbQ1IFHVCyfwwyU/zUcYf1gxWQ3iWXVRvPk=; b=Pw+BTVTh7bW2atimADJk9/8Yo8EKmmRBNr1ZsAR5t6qcDTAp286UOvcNw/OeyuLMtV 9WY2O2nPOXKaBo/B86q4EkC3r/p9UMZ0+O+BaJ/EIllvsfmXMCXIx8M8VvDQrJm4CvmR IOrZEmlGptW9ALwY0DH76BU6qm8+TyUMMfbp8= MIME-Version: 1.0 Received: by 10.142.204.9 with SMTP id b9mr2954033wfg.3.1312215991485; Mon, 01 Aug 2011 09:26:31 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Mon, 1 Aug 2011 09:26:31 -0700 (PDT) In-Reply-To: <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> Date: Mon, 1 Aug 2011 18:26:31 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=000e0cd1a07a0a85be04a97418f6 Cc: Softwires-wg , Wojciech Dec , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:26:27 -0000 --000e0cd1a07a0a85be04a97418f6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any operator wired/wireless/whatever can deploy dual stack and NAT/CGN, and there is abundant evidence of that. Equally well, any operator can deploy stateless (once we actually have it) Some may also choose to do a mix. Some may do neither... In fact this is what is said to be an operator's choice. -Woj. On 1 August 2011 17:24, R=E9mi Despr=E9s wrote: > Cameron, > > Thanks for the clarification. > More below. > > Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > ... > > > Some providers may indeed prefer to have only a stateless solution, > especially in for DSL networks where ISP's provide CPE's, but there is no > technical reason preventing both solutions to coexist > > ... > > Many, if not most, 3gpp users get rfc1918 or bogon public addresses today= . > Giving my users public addresses using 4v6 stateless probably does not ma= ke > sense for me or many similar mobile operators. ... there are not enough > public address to give these users (growth through 2015) each 2000 ports. > > I don't se a significant disagreement here. > > If you have an overwhelming need for dynamic port sharing, it has to be > faced, and you will go for CGN's. I don't argue against this. > > Some other operators may however have different constraints, and should b= e > permitted to operate whatever simpler solution applies to their case. > > Note that one can expect that in 2015 users should work mostly, if not > exclusively in IPv6, so that their need should be well well below 2000 IP= v4 > ports for each. > > This is just a 3gpp data point, since the draft chooses to include 3gpp a= s > motivation. > > I appreciate that, and agree that the case for stateless A+P mapping is > clearer for DSL and optical fibers than for 3GPP > > > Regards, > RD > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --000e0cd1a07a0a85be04a97418f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any operator wired/wireless/whatever can deploy dual stack and NAT/CGN,=20 and there is abundant evidence of that. Equally well, any operator=20 can deploy stateless (once we actually have it) Some may also choose to=20 do a mix. Some may do neither... In fact this is what is said to be an oper= ator's choice.

-Woj.


On 1 = August 2011 17:24, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Cameron,

Thanks for the clarificati= on.
More below.
=A0
Le 1 ao=FBt 2011 =E0 16:33, Camer= on Byrne a =E9crit :
...

> Some providers may indeed prefer to have only a stateless solution, es= pecially in for DSL networks where ISP's provide CPE's, but there i= s no technical reason preventing both solutions to coexist

...

Many, if not most, 3gpp users get= rfc1918 or bogon public addresses today.=A0 Giving my users public address= es using 4v6 stateless probably does not make sense for me or many similar = mobile operators. ... there are not enough public address to give these use= rs (growth through 2015) each 2000 ports.

I don't se a significant disagreement here.=A0
<= br>
If you have an overwhelming need for dynamic port sharing, it= has to be faced, and you will go for CGN's. I don't argue against = this.

Some other operators may however have different constra= ints, and should be permitted to operate whatever simpler solution applies = to their case.

Note that one can expect that in 20= 15 users should work mostly, if not exclusively in IPv6, so that their need= should be well well below 2000 IPv4 ports for each.

This is = just a 3gpp data point, since the draft chooses to include 3gpp as motivati= on.

I appreciate that, and agree that=A0the case= for stateless A+P mapping is clearer for DSL and optical fibers than for 3= GPP=A0


Regards,
RD




______= _________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--000e0cd1a07a0a85be04a97418f6-- From wdec.ietf@gmail.com Mon Aug 1 09:34:23 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC61421F8EBD for ; Mon, 1 Aug 2011 09:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyurhIePKEQM for ; Mon, 1 Aug 2011 09:34:23 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D706721F8E12 for ; Mon, 1 Aug 2011 09:34:22 -0700 (PDT) Received: by gwb20 with SMTP id 20so4396769gwb.31 for ; Mon, 01 Aug 2011 09:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GzuUo82qqRFqLWJzGkaqb7y+AXETnejAO8ohWyiVCko=; b=GT1T/cwFSVuUsoRSujnj4zvumLApM3qGLZE+fYMMHEnqbnJppHw+nv8vFO4P1f2SYr yAmStgy45c4cdOKc+IgnHofm0XY4Afiw55t2gaQbAWLKhbjBoCZbmeUh3xAH+4Fa0hyf 9S9l0U0/bpOwDlFnc42cvoHCHcp8flaBRj6cA= MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr2959221wfe.60.1312216467416; Mon, 01 Aug 2011 09:34:27 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Mon, 1 Aug 2011 09:34:27 -0700 (PDT) In-Reply-To: <8EF6E9E8-C917-4A3D-B8E6-607747D06CF8@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> <067E6CE33034954AAC05C9EC85E2577C058E6F05@XMB-RCD-111.cisco.com> <8EF6E9E8-C917-4A3D-B8E6-607747D06CF8@laposte.net> Date: Mon, 1 Aug 2011 18:34:27 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=000e0cd2e33e68a5ff04a9743496 Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:34:23 -0000 --000e0cd2e33e68a5ff04a9743496 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1 August 2011 18:21, R=E9mi Despr=E9s wrote: > > Le 1 ao=FBt 2011 =E0 17:44, Rajiv Asati (rajiva) a =E9crit : > > > We agree that different operators (whether in 3GPP/mobile space or > Wireline (DSL/Cable/Fiber) space) would embrace stateful or stateless NAT > based solution, per their short-term & long-term plans and associated > constraints. > > Note that with stateless mappings + encapsulation, "stateless NAT" is an > inappropriate wording, because there is no translation: > All of the current Stateless46 variants TRANSLATE Layer 4 (TCP/UDP) + laye= r 3 (IPv4) info into Layer 3 (IPv6). Would be happy to use another term if... > - This ensures e2e transparency, > - At least for customers that are assigned exclusive IPv4 addresses, this > e2e transparency is important (IP options, TOS, maybe others). > Perhaps for some, but for some the loss of IP Options vs the efficiencies/gains in other areas are a price worth paying. (note: we have already agreed that TOS transparency is achievable with either mode) Cheers, Woj. > > Cheers, > RD > > > > > > Perhaps, it could be phrased a bit better in the draft, but that's not = to > say that stateless NAT/A+P becomes inapplicable to a particular space rig= ht > away. > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n > Behalf > >> Of Cameron Byrne > >> Sent: Monday, August 01, 2011 11:36 AM > >> To: R=E9mi Despr=E9s > >> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] 3gpp related comments on > draft-dec-stateless-4v6-02 > >> > >> > >> On Aug 1, 2011 8:24 AM, "R=E9mi Despr=E9s" > wrote: > >>> > >>> Cameron, > >>> > >>> Thanks for the clarification. > >>> More below. > >>> > >>> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > >>> ... > >>>> > >>>>> Some providers may indeed prefer to have only a stateless solution, > >> especially in for DSL networks where ISP's provide CPE's, but there is > no > >> technical reason preventing both solutions to coexist > >>> > >>> ... > >>>> > >>>> Many, if not most, 3gpp users get rfc1918 or bogon public addresses > today. > >> Giving my users public addresses using 4v6 stateless probably does not > make > >> sense for me or many similar mobile operators. ... there are not enoug= h > public > >> address to give these users (growth through 2015) each 2000 ports. > >>> > >>> I don't se a significant disagreement here. > >>> > >>> If you have an overwhelming need for dynamic port sharing, it has to = be > >> faced, and you will go for CGN's. I don't argue against this. > >>> > >>> Some other operators may however have different constraints, and shou= ld > be > >> permitted to operate whatever simpler solution applies to their case. > >>> > >> > >> Of course, agreed. > >> > >>> Note that one can expect that in 2015 users should work mostly, if no= t > >> exclusively in IPv6, so that their need should be well well below 2000 > IPv4 > >> ports for each. > >>>> This is just a 3gpp data point, since the draft chooses to include > 3gpp as > >> motivation. > >>> > >>> I appreciate that, and agree that the case for stateless A+P mapping = is > >> clearer for DSL and optical fibers than for 3GPP > >>> > >> > >> The authors may want to note this point. > >> > >>> > >>> Regards, > >>> RD > >>> > >>> > >>> > >> > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --000e0cd2e33e68a5ff04a9743496 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 1 August 2011 18:21, R=E9mi Despr=E9s= <despres.remi@laposte.net> wrote:

Le 1 ao=FBt 2011 =E0 17:44, Rajiv Asati (rajiva) a =E9crit :

> We agree that different operators (whether in 3GPP/mobile space or Wir= eline (DSL/Cable/Fiber) space) would embrace stateful or stateless NAT base= d solution, per their short-term & long-term plans and associated const= raints.

Note that with stateless mappings + encapsulation, "stateless NA= T" is an inappropriate wording, because there is no translation:

=A0All of the current Stateless46 variants TRANSLATE La= yer 4 (TCP/UDP) + layer 3 (IPv4) info into Layer 3 (IPv6). Would be happy t= o use another term if...
=A0
- This ensures e2e transparency,
- At least for customers that are assigned exclusive IPv4 addresses, this e= 2e transparency is important (IP options, TOS, maybe others).

Perhaps for some, but for some the loss of IP Options vs the ef= ficiencies/gains in other areas are a price worth paying. (note: we have al= ready agreed that TOS transparency is achievable with either mode)

Cheers,
Woj.
=A0

Cheers,
RD


>
> Perhaps, it could be phrased a bit better in the draft, but that's= not to say that stateless NAT/A+P becomes inapplicable to a particular spa= ce right away.
>
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf >> Of Cameron Byrne
>> Sent: Monday, August 01, 2011 11:36 AM
>> To: R=E9mi Despr=E9s
>> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] 3gpp related comments on draft-dec-statel= ess-4v6-02
>>
>>
>> On Aug 1, 2011 8:24 AM, "R=E9mi Despr=E9s" <despres.remi@laposte= .net> wrote:
>>>
>>> Cameron,
>>>
>>> Thanks for the clarification.
>>> More below.
>>>
>>> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit :
>>> ...
>>>>
>>>>> Some providers may indeed prefer to have only a statel= ess solution,
>> especially in for DSL networks where ISP's provide CPE's, = but there is no
>> technical reason preventing both solutions to coexist
>>>
>>> ...
>>>>
>>>> Many, if not most, 3gpp users get rfc1918 or bogon public = addresses today.
>> Giving my users public addresses using 4v6 stateless probably does= not make
>> sense for me or many similar mobile operators. ... there are not e= nough public
>> address to give these users (growth through 2015) each 2000 ports.=
>>>
>>> I don't se a significant disagreement here.
>>>
>>> If you have an overwhelming need for dynamic port sharing, it = has to be
>> faced, and you will go for CGN's. I don't argue against th= is.
>>>
>>> Some other operators may however have different constraints, a= nd should be
>> permitted to operate whatever simpler solution applies to their ca= se.
>>>
>>
>> Of course, agreed.
>>
>>> Note that one can expect that in 2015 users should work mostly= , if not
>> exclusively in IPv6, so that their need should be well well below = 2000 IPv4
>> ports for each.
>>>> This is just a 3gpp data point, since the draft chooses to= include 3gpp as
>> motivation.
>>>
>>> I appreciate that, and agree that the case for stateless A+P m= apping is
>> clearer for DSL and optical fibers than for 3GPP
>>>
>>
>> The authors may want to note this point.
>>
>>>
>>> Regards,
>>> RD
>>>
>>>
>>>
>>
>


_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--000e0cd2e33e68a5ff04a9743496-- From cb.list6@gmail.com Mon Aug 1 09:37:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402DC21F8BDE for ; Mon, 1 Aug 2011 09:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnEXEAJm2yfN for ; Mon, 1 Aug 2011 09:37:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B12321F8BBB for ; Mon, 1 Aug 2011 09:37:44 -0700 (PDT) Received: by wyj26 with SMTP id 26so1543990wyj.31 for ; Mon, 01 Aug 2011 09:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JvXD2G8QKxSYl1jtG2CFqKqo8UXvWr7IKNs8YVtLmHE=; b=iFLr3AEbpm7VWW7nmdJbpIdgEFFew3eoC6HGj+6/9nIv8bNcWYIohBxvWfbyQQOapP Cd/HW/XZfQrbMywfvGxKbl7sxpmmbQNXN9gaE3O3rnytZFfLnO8/GWx0mGP22JBLNhQH Mwyd51fTm8nu2ma/jn95C5sPH36f0MGRII1rc= MIME-Version: 1.0 Received: by 10.216.233.95 with SMTP id o73mr894221weq.103.1312216670510; Mon, 01 Aug 2011 09:37:50 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 09:37:50 -0700 (PDT) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C058E6EFE@XMB-RCD-111.cisco.com> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> <067E6CE33034954AAC05C9EC85E2577C058E6EFE@XMB-RCD-111.cisco.com> Date: Mon, 1 Aug 2011 09:37:50 -0700 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:37:45 -0000 2011/8/1 Rajiv Asati (rajiva) : >> I appreciate that, and agree that the case for stateless A+P mapping is >> clearer for DSL and optical fibers than for 3GPP > > There are other 3GPP operators who favor using stateless A+P mapping, so = I would shy away from the above agreement. Of course, different operators h= ave different constraints that make them favor one or the other solution, a= s you rightly said. > Is it possible for those 3GPP operators to speak for themselves and not via a vendor? If not, i understand. I always consider the source of information. I am looking to avoid an echo chamber where the IETF is doing something it thinks the 3GPP wants and therefore the 3GPP adopts something that it thinks the IETF wants. Does that make sense? I would prefer that the draft drop reference to 3GPP since this is a generic solution, right? It is not appropriated to try and sell/target this solution in the RFC to a particular market segment. There is no specific 3GPP engineering in this solution, so lets just say it is a generic solution. Or, we can go a step further and call it NAT464, then people would intuitively know what it is. Cameron > Cheers, > Rajiv > > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On = Behalf >> Of R=E9mi Despr=E9s >> Sent: Monday, August 01, 2011 11:25 AM >> To: Cameron Byrne >> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) >> Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v= 6-02 >> >> Cameron, >> >> Thanks for the clarification. >> More below. >> >> >> >> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : >> ... >> >> =A0 =A0 =A0 > Some providers may indeed prefer to have only a stateless = solution, >> especially in for DSL networks where ISP's provide CPE's, but there is n= o >> technical reason preventing both solutions to coexist >> >> ... >> >> >> =A0 =A0 =A0 Many, if not most, 3gpp users get rfc1918 or bogon public ad= dresses >> today. =A0Giving my users public addresses using 4v6 stateless probably = does not >> make sense for me or many similar mobile operators. ... there are not en= ough >> public address to give these users (growth through 2015) each 2000 ports= . >> >> I don't se a significant disagreement here. >> >> If you have an overwhelming need for dynamic port sharing, it has to be = faced, >> and you will go for CGN's. I don't argue against this. >> >> Some other operators may however have different constraints, and should = be >> permitted to operate whatever simpler solution applies to their case. >> >> Note that one can expect that in 2015 users should work mostly, if not >> exclusively in IPv6, so that their need should be well well below 2000 I= Pv4 >> ports for each. >> >> >> =A0 =A0 =A0 This is just a 3gpp data point, since the draft chooses to i= nclude 3gpp >> as motivation. >> >> I appreciate that, and agree that the case for stateless A+P mapping is >> clearer for DSL and optical fibers than for 3GPP >> >> >> Regards, >> RD >> >> > > From cb.list6@gmail.com Mon Aug 1 09:49:10 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCE21F8EDA for ; Mon, 1 Aug 2011 09:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgPEXKm+bS6W for ; Mon, 1 Aug 2011 09:49:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48DD121F8EE2 for ; Mon, 1 Aug 2011 09:49:09 -0700 (PDT) Received: by wyj26 with SMTP id 26so1552423wyj.31 for ; Mon, 01 Aug 2011 09:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0Ojdw8ABrDcDy1+8Ev1snlKPscAsrfutKcpRhxzy8k0=; b=cdnh2RGN/Qn72rQvOiebF0MZINfU8qGurk4TjWiDIInpLpzGsg9+NwsEcaP1iJbX+t Ch2BLOHWGlXW15qrxCmrcuihA3ywWNt+b95nRFimNoAJpS/Dk/E4Bz2kKd+Ya9zA0oJI vLr2pPWbXmg+bPH3Qtqybt8YTWGD1pWnsCcxU= MIME-Version: 1.0 Received: by 10.216.168.72 with SMTP id j50mr889686wel.88.1312217355321; Mon, 01 Aug 2011 09:49:15 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Mon, 1 Aug 2011 09:49:15 -0700 (PDT) In-Reply-To: <8E225408-EACE-490A-B5B5-41F9AF0F8C2C@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <8E225408-EACE-490A-B5B5-41F9AF0F8C2C@laposte.net> Date: Mon, 1 Aug 2011 09:49:15 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:49:10 -0000 On Mon, Aug 1, 2011 at 8:32 AM, R=E9mi Despr=E9s = wrote: > > Le 1 ao=FBt 2011 =E0 16:36, Cameron Byrne a =E9crit : > >> are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by >> IPv6-only bearers with IPv4/IPv6 translation, or that both should coexis= t to >> widen the number of options? >> > > Both do exist today. I have had the latter in beta for over a year and it > will go to production soon. > > Thank you for sharing this information. > I infer that the extra header size of 20 octets that 4V6 Translation has, > compared to the IPv4v6 Bearer, isn't considered a show stopper. > Hopefully, we won't hear too much of the header size argument in the futu= re. > Regards, > RD > I don't think headers are the issue, yes, some bit twiddlers will disagree. The challenge is getting the UE software implemented. Take IPv6 for example. Many operators have been asking for support for years, and now Nokia is closing down Symbian. With Symbian gone as a platform for new phones (effective now in many operators), there will be ZERO IPv6 handsets available for GSM/UMTS that you can purchase. I feel confident this will change, but i just want to share with you the fact that the UE ecosystem is a very complex balance of power between chipsets / Mobile OS / OEM / and service provider. New features are very hard to get committed, especially when NAT444 and NAT44 + IPv6 just work today in the mobile router segment. Cameron From wdec.ietf@gmail.com Mon Aug 1 09:57:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B954C21F8F2B for ; Mon, 1 Aug 2011 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py3QnZ4gjxXA for ; Mon, 1 Aug 2011 09:57:12 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id C861D21F8F28 for ; Mon, 1 Aug 2011 09:57:12 -0700 (PDT) Received: by pzk6 with SMTP id 6so10962158pzk.26 for ; Mon, 01 Aug 2011 09:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I4duqOaxWheTJbNjMcEY9n1Urn7uRT+dT/dVd65o1Sk=; b=t7Lm0NHUagOhyBdal5AjMa1dSwi4/wa202a20XC5IOYhc7p610Hr3JbpifwAU2VaBE 3C/2rGGiwP+i43rn2TLB7i9cQh7PfJVKUB81UPXPYEX/9Iph8D2xVeITetuFvsjIGL9n 7wEaXLXF2JOosAXFxqkP7fmo983aujorvN7f4= MIME-Version: 1.0 Received: by 10.68.49.5 with SMTP id q5mr2830620pbn.63.1312217839173; Mon, 01 Aug 2011 09:57:19 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Mon, 1 Aug 2011 09:57:19 -0700 (PDT) In-Reply-To: References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> <067E6CE33034954AAC05C9EC85E2577C058E6EFE@XMB-RCD-111.cisco.com> Date: Mon, 1 Aug 2011 18:57:19 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=bcaec54307002c01dd04a9748644 Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:57:13 -0000 --bcaec54307002c01dd04a9748644 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Indeed, there is nothing here which says that this or that operator or body needs to do or adopt something. It leaves the pro/con for the operator to weigh, but to do that there must be some context. This draft thus illustrates not only the issues attributable to A+P based solutions and their impact, but also a likely impact to various system contexts formed by standard/generic architectures. It happened to have been written with operator input and in doing that we think it provides a useful picture (ie how this stuff may actually be used in a system). Regards, Wojciech. On 1 August 2011 18:37, Cameron Byrne wrote: > 2011/8/1 Rajiv Asati (rajiva) : > >> I appreciate that, and agree that the case for stateless A+P mapping i= s > >> clearer for DSL and optical fibers than for 3GPP > > > > There are other 3GPP operators who favor using stateless A+P mapping, s= o > I would shy away from the above agreement. Of course, different operators > have different constraints that make them favor one or the other solution= , > as you rightly said. > > > > Is it possible for those 3GPP operators to speak for themselves and > not via a vendor? If not, i understand. I always consider the source > of information. > > I am looking to avoid an echo chamber where the IETF is doing > something it thinks the 3GPP wants and therefore the 3GPP adopts > something that it thinks the IETF wants. Does that make sense? > > I would prefer that the draft drop reference to 3GPP since this is a > generic solution, right? It is not appropriated to try and > sell/target this solution in the RFC to a particular market segment. > There is no specific 3GPP engineering in this solution, so lets just > say it is a generic solution. Or, we can go a step further and call > it NAT464, then people would intuitively know what it is. > > Cameron > > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n > Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Monday, August 01, 2011 11:25 AM > >> To: Cameron Byrne > >> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] 3gpp related comments on > draft-dec-stateless-4v6-02 > >> > >> Cameron, > >> > >> Thanks for the clarification. > >> More below. > >> > >> > >> > >> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > >> ... > >> > >> > Some providers may indeed prefer to have only a stateless > solution, > >> especially in for DSL networks where ISP's provide CPE's, but there is > no > >> technical reason preventing both solutions to coexist > >> > >> ... > >> > >> > >> Many, if not most, 3gpp users get rfc1918 or bogon public > addresses > >> today. Giving my users public addresses using 4v6 stateless probably > does not > >> make sense for me or many similar mobile operators. ... there are not > enough > >> public address to give these users (growth through 2015) each 2000 > ports. > >> > >> I don't se a significant disagreement here. > >> > >> If you have an overwhelming need for dynamic port sharing, it has to b= e > faced, > >> and you will go for CGN's. I don't argue against this. > >> > >> Some other operators may however have different constraints, and shoul= d > be > >> permitted to operate whatever simpler solution applies to their case. > >> > >> Note that one can expect that in 2015 users should work mostly, if not > >> exclusively in IPv6, so that their need should be well well below 2000 > IPv4 > >> ports for each. > >> > >> > >> This is just a 3gpp data point, since the draft chooses to inclu= de > 3gpp > >> as motivation. > >> > >> I appreciate that, and agree that the case for stateless A+P mapping i= s > >> clearer for DSL and optical fibers than for 3GPP > >> > >> > >> Regards, > >> RD > >> > >> > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --bcaec54307002c01dd04a9748644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Indeed, there is nothing here which says that this or that operator= or=20 body needs to do or adopt something. It leaves the pro/con for the=20 operator to weigh, but to do that there must be some context. This draft th= us=A0 illustrates not only the issues attributable to A+P based solutions a= nd their impact, but also a likely impact to various system contexts formed= by standard/generic architectures. It happened to have been written with o= perator input and in doing that we think it provides a useful picture (ie h= ow this stuff may actually be used in a system).


Regards,
Wojciech.


On 1 Au= gust 2011 18:37, Cameron Byrne <cb.list6@gmail.com> wrote:
2011/8/1 Rajiv Asati (rajiva) <rajiv= a@cisco.com>:
>> I appreciate that, and agree that the case for s= tateless A+P mapping is
>> clearer for DSL and optical fibers than for 3GPP
>
> There are other 3GPP operators who favor using stateless A+P mapping, = so I would shy away from the above agreement. Of course, different operator= s have different constraints that make them favor one or the other solution= , as you rightly said.
>

Is it possible for those 3GPP operators to speak for themselves and not via a vendor? =A0If not, i understand. I always consider the source
of information.

I am looking to avoid an echo chamber where the IETF is doing
something it thinks the 3GPP wants and therefore the 3GPP adopts
something that it thinks the IETF wants. =A0Does that make sense?

I would prefer that the draft drop reference to 3GPP since this is a
generic solution, right? =A0It is not appropriated to try and
sell/target this solution in the RFC to a particular market segment.
There is no specific 3GPP engineering in this solution, so lets just
say it is a generic solution. =A0Or, we can go a step further and call
it NAT464, then people would intuitively know what it is.

Cameron



> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-boun= ces@ietf.org [mailto:soft= wires-bounces@ietf.org] On Behalf
>> Of R=E9mi Despr=E9s
>> Sent: Monday, August 01, 2011 11:25 AM
>> To: Cameron Byrne
>> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] 3gpp related comments on draft-dec-statel= ess-4v6-02
>>
>> Cameron,
>>
>> Thanks for the clarification.
>> More below.
>>
>>
>>
>> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit :
>> ...
>>
>> =A0 =A0 =A0 > Some providers may indeed prefer to have only a s= tateless solution,
>> especially in for DSL networks where ISP's provide CPE's, = but there is no
>> technical reason preventing both solutions to coexist
>>
>> ...
>>
>>
>> =A0 =A0 =A0 Many, if not most, 3gpp users get rfc1918 or bogon pub= lic addresses
>> today. =A0Giving my users public addresses using 4v6 stateless pro= bably does not
>> make sense for me or many similar mobile operators. ... there are = not enough
>> public address to give these users (growth through 2015) each 2000= ports.
>>
>> I don't se a significant disagreement here.
>>
>> If you have an overwhelming need for dynamic port sharing, it has = to be faced,
>> and you will go for CGN's. I don't argue against this.
>>
>> Some other operators may however have different constraints, and s= hould be
>> permitted to operate whatever simpler solution applies to their ca= se.
>>
>> Note that one can expect that in 2015 users should work mostly, if= not
>> exclusively in IPv6, so that their need should be well well below = 2000 IPv4
>> ports for each.
>>
>>
>> =A0 =A0 =A0 This is just a 3gpp data point, since the draft choose= s to include 3gpp
>> as motivation.
>>
>> I appreciate that, and agree that the case for stateless A+P mappi= ng is
>> clearer for DSL and optical fibers than for 3GPP
>>
>>
>> Regards,
>> RD
>>
>>
>
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--bcaec54307002c01dd04a9748644-- From rajiva@cisco.com Mon Aug 1 10:06:36 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7507D11E8118 for ; Mon, 1 Aug 2011 10:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROLLtHOKGhha for ; Mon, 1 Aug 2011 10:06:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7CE11E810D for ; Mon, 1 Aug 2011 10:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4061; q=dns/txt; s=iport; t=1312218402; x=1313428002; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=S7f0VS0DXUgk+6B0QyfZaAOTcWZck79FBDeu40yAZpU=; b=ae5WNVI279N3sex1hyNbbLlIimgU3Rk6hydr6qEiZPmPzFfkXCz4h6Lh TyEBu93vz7s2bk8g+AB0FfVY+C7cYFE38Dzeie2k/ITeOGdMZ8Od1B95/ ipNHDRDpPUeP3wsaKvfteNcqSj0x8/H3F4uGFrLFfJBrCjPZ71D/KNN51 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AACLcNk6tJV2b/2dsb2JhbABBmA2PVHeBQAEBAQEDEgEdSQwEAgEIDgMEAQELBhcBBgEgJQkIAQEEEwgTB6kMAZ5ThWNfBIcrL5AxhFuHFw X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8500907" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2011 17:06:40 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71H6eeX024761; Mon, 1 Aug 2011 17:06:40 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 12:06:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 12:06:39 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C058E6F83@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 Thread-Index: AcxQaVwmSRJ2umHSReaNisFQ/WQuUQAA0bWA References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net><59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net><067E6CE33034954AAC05C9EC85E2577C058E6EFE@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" X-OriginalArrivalTime: 01 Aug 2011 17:06:40.0526 (UTC) FILETIME=[618E12E0:01CC506D] Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:06:36 -0000 Cameron, Your points are valid. I agree to all but the last one.=20 The draft is not intended to provide/propose/recommend a solution, = rather share the analysis (e.g. impact if such a solution was to be = deployed). Do you find the abstract worthy of rephrasing? There are other drafts that talk about solutions, of course. Cheers, Rajiv > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Monday, August 01, 2011 12:38 PM > To: Rajiv Asati (rajiva) > Cc: R=E9mi Despr=E9s; Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > Subject: Re: [Softwires] 3gpp related comments on = draft-dec-stateless-4v6-02 >=20 > 2011/8/1 Rajiv Asati (rajiva) : > >> I appreciate that, and agree that the case for stateless A+P = mapping is > >> clearer for DSL and optical fibers than for 3GPP > > > > There are other 3GPP operators who favor using stateless A+P = mapping, so I > would shy away from the above agreement. Of course, different = operators have > different constraints that make them favor one or the other solution, = as you > rightly said. > > >=20 > Is it possible for those 3GPP operators to speak for themselves and > not via a vendor? If not, i understand. I always consider the source > of information. >=20 > I am looking to avoid an echo chamber where the IETF is doing > something it thinks the 3GPP wants and therefore the 3GPP adopts > something that it thinks the IETF wants. Does that make sense? >=20 > I would prefer that the draft drop reference to 3GPP since this is a > generic solution, right? It is not appropriated to try and > sell/target this solution in the RFC to a particular market segment. > There is no specific 3GPP engineering in this solution, so lets just > say it is a generic solution. Or, we can go a step further and call > it NAT464, then people would intuitively know what it is. >=20 > Cameron >=20 >=20 >=20 > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] On > Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Monday, August 01, 2011 11:25 AM > >> To: Cameron Byrne > >> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] 3gpp related comments on = draft-dec-stateless-4v6- > 02 > >> > >> Cameron, > >> > >> Thanks for the clarification. > >> More below. > >> > >> > >> > >> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > >> ... > >> > >> =A0 =A0 =A0 > Some providers may indeed prefer to have only a = stateless solution, > >> especially in for DSL networks where ISP's provide CPE's, but there = is no > >> technical reason preventing both solutions to coexist > >> > >> ... > >> > >> > >> =A0 =A0 =A0 Many, if not most, 3gpp users get rfc1918 or bogon = public addresses > >> today. =A0Giving my users public addresses using 4v6 stateless = probably does > not > >> make sense for me or many similar mobile operators. ... there are = not > enough > >> public address to give these users (growth through 2015) each 2000 = ports. > >> > >> I don't se a significant disagreement here. > >> > >> If you have an overwhelming need for dynamic port sharing, it has = to be > faced, > >> and you will go for CGN's. I don't argue against this. > >> > >> Some other operators may however have different constraints, and = should be > >> permitted to operate whatever simpler solution applies to their = case. > >> > >> Note that one can expect that in 2015 users should work mostly, if = not > >> exclusively in IPv6, so that their need should be well well below = 2000 IPv4 > >> ports for each. > >> > >> > >> =A0 =A0 =A0 This is just a 3gpp data point, since the draft chooses = to include > 3gpp > >> as motivation. > >> > >> I appreciate that, and agree that the case for stateless A+P = mapping is > >> clearer for DSL and optical fibers than for 3GPP > >> > >> > >> Regards, > >> RD > >> > >> > > > > From yiu_lee@cable.comcast.com Mon Aug 1 10:12:39 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D033E21F87F9 for ; Mon, 1 Aug 2011 10:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.709 X-Spam-Level: X-Spam-Status: No, score=-100.709 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-32ej8bPbug for ; Mon, 1 Aug 2011 10:12:39 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 821E621F8663 for ; Mon, 1 Aug 2011 10:12:36 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46995839; Mon, 01 Aug 2011 11:16:19 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Mon, 1 Aug 2011 13:11:35 -0400 From: "Lee, Yiu" To: Peng Wu , GangChen , =?gb2312?B?UultaSBEZXNwculz?= Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AQHMUG4RQBO1e0clAEa8F8t0pBcCDg== Date: Mon, 1 Aug 2011 17:11:35 +0000 Message-ID: In-Reply-To: <201107302126309348102@csnet1.cs.tsinghua.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.241.25.0] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:12:39 -0000 KzENCg0KT24gNy8zMC8xMSA5OjI2IEFNLCAiUGVuZyBXdSIgPHdlYXBvbkBjc25ldDEuY3MudHNp bmdodWEuZWR1LmNuPiB3cm90ZToNCg0KPkhpIEdhbmcsDQo+DQo+PkJlZm9yZSBtYWtpbmcgc3Vj aCBjb21wYXJpc29uIChvZiBjb3Vyc2UgaXQgc2hvdWxkIGJlIGFzIGZhaXIgYXMNCj4+cG9zc2li bGUpLA0KPj5JIHRoaW5rIHdlIG5lZWQgdG8gc3RhdGUgd2hhdCBzb2x1dGlvbiBzcGFjZSB3ZSBh cmUgdGFyZ2V0aW5nIGFuZCB3aGF0DQo+PmNhdGVnb3J5IG1vZGUgd2Ugc2hvdWxkIHRha2UgY2Fy ZS4NCj4+SWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgSSB3b3VsZCBwYXJhcGhyYXNlIGFzIGZv bGxvd2luZyBjYXRlZ29yaWVzLg0KPj4NCj4+YSkgU3RhdGVmdWwrRHluYW1pYyBwb3J0IHNldHM6 IGUuZy4gRFMtTGl0ZQ0KPj5iKSBTdGF0ZWZ1bCtTdGF0aWMgcG9ydCBzZXQ6IGUuZy4gZHJhZnQt Y3VpLXNvZnR3aXJlLWhvc3QtNG92ZXI2LTA2DQo+PmMpIFN0YXRlbGVzcyArIFN0YXRpYyBwb3J0 IHNldDogZS5nLiA0cmQsIDR2aWE2IHRyYW5zbGF0aW9uDQo+PmQpIFN0YXRlbGVzcyArIER5bmFt aWMgcG9ydCBzZXQ6ID8/KEFueSBjYW5kaWRhdGUgc29sdXRpb24/KQ0KPg0KPkkgd291bGQgc2F5 IHRoYXQgdGhlIGxhc3Qgb25lIG1ha2VzIG5vIHNlbnNlDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ U29mdHdpcmVzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zb2Z0d2lyZXMNCg0K From yiu_lee@cable.comcast.com Mon Aug 1 10:14:05 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C3411E8115 for ; Mon, 1 Aug 2011 10:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.586 X-Spam-Level: X-Spam-Status: No, score=-104.586 tagged_above=-999 required=5 tests=[AWL=3.877, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-LZYXDkAJft for ; Mon, 1 Aug 2011 10:14:04 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA3411E8127 for ; Mon, 1 Aug 2011 10:14:04 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135809353; Mon, 01 Aug 2011 13:13:58 -0400 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 1 Aug 2011 13:13:53 -0400 From: "Lee, Yiu" To: Satoru Matsushima , GangChen Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AQHMUG5jQBO1e0clAEa8F8t0pBcCDg== Date: Mon, 1 Aug 2011 17:13:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.241.25.0] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:14:05 -0000 You are right. The current 'draft-cui-softwire-host-4over6' describes how a server is provisioned a public IPv4 address over an IPv6-only network. IPv4 address sharing wasn't discussed in the draft. On 7/30/11 9:57 AM, "Satoru Matsushima" wrote: >AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address >sharing. Is that correct? From yiu_lee@cable.comcast.com Mon Aug 1 10:16:27 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1808C11E80AB for ; Mon, 1 Aug 2011 10:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.379 X-Spam-Level: X-Spam-Status: No, score=-103.379 tagged_above=-999 required=5 tests=[AWL=-1.644, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unpZC2X5Jvpw for ; Mon, 1 Aug 2011 10:16:26 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 52CAA11E8077 for ; Mon, 1 Aug 2011 10:16:26 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46996816; Mon, 01 Aug 2011 11:21:25 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Mon, 1 Aug 2011 13:16:28 -0400 From: "Lee, Yiu" To: Satoru Matsushima , Qiong Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AQHMUG69Zte5ary0HEmJEVjzdLYrpA== Date: Mon, 1 Aug 2011 17:16:27 +0000 Message-ID: In-Reply-To: <0C13D39F-7AAD-41C4-86E1-8A13F7142BD6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <8E1E00703601614D8E401DB590C7BFA8@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:16:27 -0000 We didn't have time to discuss this in the WG meeting. We will need to see how people accept this technology. I wish more discussions will come in the mailing list and hopefully some operators express interests in it in the mailing list. On 8/1/11 6:59 AM, "Satoru Matsushima" wrote: >Hi Qiong, > >On 2011/08/01, at 19:06, Qiong wrote: > >> Hi, Satoru, >>=20 >> Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address >>sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing. >> http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt > >Thanks, I got it. Then I think that we should take >'draft-cui-softwire-b4-translated-ds-lite' as a solution for b). > >cheers, >--satoru > > >>=20 >> Thanks >>=20 >> Best wishes >>=20 >> Qiong Sun >>=20 >> On Sat, Jul 30, 2011 at 9:57 PM, Satoru Matsushima >> wrote: >> One clarification. >>=20 >> On 2011/07/29, at 10:18, GangChen wrote: >>=20 >> > Before making such comparison (of course it should be as fair as >>possible), >> > I think we need to state what solution space we are targeting and what >> > category mode we should take care. >> > If I understand correctly, I would paraphrase as following categories. >> > >> > a) Stateful+Dynamic port sets: e.g. DS-Lite >> > b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 >> > c) Stateless + Static port set: e.g. 4rd, 4via6 translation >> > d) Stateless + Dynamic port set: ??(Any candidate solution?) >>=20 >> AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 >>address sharing. Is that correct? >>=20 >> cheers, >> --satoru >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Mon Aug 1 10:18:24 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3859611E8137 for ; Mon, 1 Aug 2011 10:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXhkIH4lNVPT for ; Mon, 1 Aug 2011 10:18:23 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C811E80AB for ; Mon, 1 Aug 2011 10:18:23 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46997120; Mon, 01 Aug 2011 11:22:49 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Mon, 1 Aug 2011 13:18:07 -0400 From: "Lee, Yiu" To: Satoru Matsushima , "Jan Zorz @ go6.si" Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AQHMUG76Zte5ary0HEmJEVjzdLYrpA== Date: Mon, 1 Aug 2011 17:18:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.241.25.0] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:18:24 -0000 In this case,=20 http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt couldn't be controversial because it will turn AFTR a PRR. On 8/1/11 7:07 AM, "Satoru Matsushima" wrote: >If you imagine dynamic port ranges within stateless, it sounds like port >range aware routing. I think that it would be controversial. From yiu_lee@cable.comcast.com Mon Aug 1 10:30:07 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50121F8CCD for ; Mon, 1 Aug 2011 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.047 X-Spam-Level: X-Spam-Status: No, score=-103.047 tagged_above=-999 required=5 tests=[AWL=-1.612, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGI312CUCPHW for ; Mon, 1 Aug 2011 10:30:06 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4D44D21F8CC3 for ; Mon, 1 Aug 2011 10:30:06 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46999434; Mon, 01 Aug 2011 11:34:26 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Mon, 1 Aug 2011 13:29:53 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Jan Zorz go6.si" Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AQHMUHCf991MMO+hbU+lSZJHvE5KOg== Date: Mon, 1 Aug 2011 17:29:52 +0000 Message-ID: In-Reply-To: <60374189-CCEE-40E8-A707-8642023CD4E7@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:30:07 -0000 Actually, Orange Lab did some tests on A+P. They published the results in v6ops: http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results-01 In their tests, bittorrent seems use most ports (200). Other public apps use no more than 100 ports. For a family of 5, I think 2000 ports should be significant at any given time. On 8/1/11 11:05 AM, "R=E9mi Despr=E9s" wrote: >Thanks for the quotation. >What was "thrown" to you doesn't seem right, and needs to be challenged. > >Answer to the question: >- The customer doesn't run out of ports because it has an exclusive >private IPv4 address. >- If the CPE NAT44 runs out of ports, is just does what it does today in >the same situation. >In addition, the probability of the CPE running out of IPv4 ports in a >dual-stack-service site having 4K ports needs not be higher than in an >IPv4-only site having 64K ports. From despres.remi@laposte.net Mon Aug 1 10:35:28 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7D811E80AB for ; Mon, 1 Aug 2011 10:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL1v3OLgVpgr for ; Mon, 1 Aug 2011 10:35:28 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5D11E8077 for ; Mon, 1 Aug 2011 10:35:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id D12B5700008F; Mon, 1 Aug 2011 19:35:33 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 3404C700008C; Mon, 1 Aug 2011 19:35:33 +0200 (CEST) X-SFR-UUID: 20110801173533213.3404C700008C@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 1 Aug 2011 19:35:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <890CBB61-453E-46A9-8858-E8D20CE26362@laposte.net> References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <8E225408-EACE-490A-B5B5-41F9AF0F8C2C@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Paco Cortes , Wojciech Dec Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:35:28 -0000 Le 1 ao=FBt 2011 =E0 18:49, Cameron Byrne a =E9crit : > On Mon, Aug 1, 2011 at 8:32 AM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 1 ao=FBt 2011 =E0 16:36, Cameron Byrne a =E9crit : >>=20 >>> are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by >>> IPv6-only bearers with IPv4/IPv6 translation, or that both should = coexist to >>> widen the number of options? >>>=20 >>=20 >> Both do exist today. I have had the latter in beta for over a year = and it >> will go to production soon. >>=20 >> Thank you for sharing this information. >> I infer that the extra header size of 20 octets that 4V6 Translation = has, >> compared to the IPv4v6 Bearer, isn't considered a show stopper. >> Hopefully, we won't hear too much of the header size argument in the = future. >> Regards, >> RD >>=20 >=20 > I don't think headers are the issue, yes, some bit twiddlers will > disagree. =20 Agreed. > The challenge is getting the UE software implemented. Take > IPv6 for example. Many operators have been asking for support for > years, and now Nokia is closing down Symbian. With Symbian gone as > a platform for new phones (effective now in many operators), there > will be ZERO IPv6 handsets available for GSM/UMTS that you can > purchase. >=20 > I feel confident this will change, but i just want to share with you > the fact that the UE ecosystem is a very complex balance of power > between chipsets / Mobile OS / OEM / and service provider. =20 Same understanding. > New > features are very hard to get committed, especially when NAT444 and > NAT44 + IPv6 just work today in the mobile router segment. Agreed. As a matter of fact, adding 4rd to IPv6, in order to statelessly provide = a few IPv5 incoming ports to customers, in addition to their outgoing = ports of NAT444, might be a way to avoid the need for PCP. (If you find this subject too controversial, it's fine with me to avoid = opening it now, but if don't, why not). Regards, RD >=20 > Cameron From yiu_lee@cable.comcast.com Mon Aug 1 10:36:21 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8B511E811D for ; Mon, 1 Aug 2011 10:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr1GOyFMy7ER for ; Mon, 1 Aug 2011 10:36:20 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id C63A411E8077 for ; Mon, 1 Aug 2011 10:36:20 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47001028; Mon, 01 Aug 2011 11:40:54 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 1 Aug 2011 13:36:10 -0400 From: "Lee, Yiu" To: "Lee, Yiu" , Satoru Matsushima , "Jan Zorz @ go6.si" Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AQHMUHF/lcAGq1K8DkOmuuNtDaeoWQ== Date: Mon, 1 Aug 2011 17:36:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.241.25.0] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:36:21 -0000 Sorry typo: I mean this draft "could" be controversial. On 8/1/11 1:18 PM, "Lee, Yiu" wrote: >In this case,=20 >http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt >couldn't be controversial because it will turn AFTR a PRR. > >On 8/1/11 7:07 AM, "Satoru Matsushima" >wrote: > >>If you imagine dynamic port ranges within stateless, it sounds like port >>range aware routing. I think that it would be controversial. > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From jan@go6.si Mon Aug 1 13:14:16 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A9621F8D17 for ; Mon, 1 Aug 2011 13:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVleLVboS02d for ; Mon, 1 Aug 2011 13:14:16 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5359621F8D16 for ; Mon, 1 Aug 2011 13:14:16 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id EFD502378050 for ; Mon, 1 Aug 2011 22:14:19 +0200 (CEST) Message-ID: <4E37091A.8000400@go6.si> Date: Mon, 01 Aug 2011 22:14:18 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: softwires@ietf.org References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:14:17 -0000 On 8/1/11 5:04 PM, Qiong wrote: > So, this is a problem about how to define appropriate port set for our > customers, or to define maximum concurrent subscribers for a given IPv4 > address pool. Otherwise, there would either be a waste of resource, or > port exhaustion. Maybe we can even make some more flexible port-set > rules for different time-slot or different types of users. But anyway, > this is the problem we have to face in the further, and I also suggest > that port-consuming applications should upgrade to IPv6 directly. hi assigning initial port range to every user and then dynamically additional port ranges (or sets) solves this problem. This was solved for statefull a+p. stateless still lacks this feature, requested by this wg years ago. cheers, /jan From jan@go6.si Mon Aug 1 13:19:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE1121F8DCC for ; Mon, 1 Aug 2011 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-9Jt0e7tQeS for ; Mon, 1 Aug 2011 13:19:25 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E5A21F8D18 for ; Mon, 1 Aug 2011 13:19:25 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 2DB722378050; Mon, 1 Aug 2011 22:19:28 +0200 (CEST) Message-ID: <4E370A4F.5030407@go6.si> Date: Mon, 01 Aug 2011 22:19:27 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn><51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <067E6CE33034954AAC05C9EC85E2577C058E6E3F@XMB-RCD-111.cisco.com> <891C27B3-1080-4F29-9820-4C095160C269@laposte.net> <4E36B8D1.9060403@go6.si> <60374189-CCEE-40E8-A707-8642023CD4E7@laposte.net> In-Reply-To: <60374189-CCEE-40E8-A707-8642023CD4E7@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires-wg Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:19:26 -0000 On 8/1/11 5:05 PM, Rémi Després wrote: > Thanks for the quotation. What was "thrown" to you doesn't seem > right, and needs to be challenged. well, that changed significantly the face of a+p :) ...or maybe that was used to effectively delay the whole process :) > > Answer to the question: - The customer doesn't run out of ports > because it has an exclusive private IPv4 address. - If the CPE NAT44 > runs out of ports, is just does what it does today in the same > situation. In addition, the probability of the CPE running out of > IPv4 ports in a dual-stack-service site having 4K ports needs not be > higher than in an IPv4-only site having 64K ports. that's defined in "overall architecture" as a+p-light. > > >> Don't get me wrong, just repeating what we needed to solve in order >> to move on from that point. > > I think I don't get you wrong, and actually I believe your pioneer > work on the subject has been quite useful. It is just that what you > felt obliged to solve isn't in reality needed in a significant number > of legitimate use cases. thnx. obligation came from legitimate questions from community. cheers, Jan From jan@go6.si Mon Aug 1 13:21:11 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5FF21F8DD3 for ; Mon, 1 Aug 2011 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGW4pNthwGTq for ; Mon, 1 Aug 2011 13:21:10 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EF121F8DD4 for ; Mon, 1 Aug 2011 13:21:10 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id D4F0E23780AE for ; Mon, 1 Aug 2011 22:21:15 +0200 (CEST) Message-ID: <4E370ABB.30200@go6.si> Date: Mon, 01 Aug 2011 22:21:15 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: softwires@ietf.org References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:21:11 -0000 On 8/1/11 5:50 PM, Ole Troan wrote: >> Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: >>> Well, is short words, whatever number of ports you assign in >>> port-set/range, end user can exhaust them. >> >> The fact that most ISPs have been successfully operating with 65536 >> ports per subscriber demonstrates that it is possible to statically >> provision subscribers with "enough" ports. > > many ISPs have deployed with much less than 64K ports. a typical > limitation in CPE's NAT table is just 1024 ports. I've certainly > returned CPEs to my ISPs with that limitation in the past. +1 :) I would do the same :) /jan From denghui02@gmail.com Mon Aug 1 16:27:19 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEA111E8144 for ; Mon, 1 Aug 2011 16:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG0ooMeOkd+z for ; Mon, 1 Aug 2011 16:27:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F36AB11E813E for ; Mon, 1 Aug 2011 16:27:18 -0700 (PDT) Received: by wwe5 with SMTP id 5so4115155wwe.13 for ; Mon, 01 Aug 2011 16:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nh67MPXNiDlABO8rSHsSKXh3JAnVnwzXeLHA8LnMaAA=; b=hRo/QejQby373tp28y5ssjfLc2Fx7ketF6wxcbM+2rgD84xlYsRJUj1HtJVxrn32eS esEhGuQsfZ02j0vZlVuKXcDYokRUOrV+KkNCRJcThwKPq5e8ha6OHu6XJr/xdIMsy1tx TjmBlsjFXUOUy28HqE32RiozlvsSokTjb/GPE= MIME-Version: 1.0 Received: by 10.216.229.165 with SMTP id h37mr1140781weq.69.1312241245369; Mon, 01 Aug 2011 16:27:25 -0700 (PDT) Received: by 10.216.0.21 with HTTP; Mon, 1 Aug 2011 16:27:25 -0700 (PDT) In-Reply-To: References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> Date: Tue, 2 Aug 2011 07:27:25 +0800 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=0016e64768024a353e04a979f98b Cc: Softwires-wg , Wojciech Dec , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 23:27:20 -0000 --0016e64768024a353e04a979f98b Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron Many, if not most, 3gpp users get rfc1918 or bogon public addresses today. Giving my users public addresses using 4v6 stateless probably does not make sense for me or many similar mobile operators. ... there are not enough public address to give these users (growth through 2015) each 2000 ports. ==> this should be emphasized here in order to not mis-guiding, so I cut off other wordings. those bogon public addresses are not static, they are dynamical to assigned to dynamical online user, I don't see there are not enough bogon public address, because not all mobile subscriber are always online. Secondly, they are considered as mobile CPE case at this moment, not for mobile itself, there are maybe more mobile user under mobile CPE. it won't conflict with your stateful NAT64 deployment hopefully. Regards, -Hui --0016e64768024a353e04a979f98b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Cameron
=A0
Many, if not most, 3gpp users get rfc1918 or bogon public addresses to= day.=A0 Giving my users public addresses using 4v6 stateless probably does = not make sense for me or many similar mobile operators. ... there are not e= nough public address to give these users (growth through 2015) each 2000 po= rts.
=A0
=3D=3D> this should be emphasized here in order to not mis-guiding,= so I cut off other wordings.
those bogon public addresses are not static, they are dynamical to ass= igned to dynamical online user, I don't see there are not enough bogon = public address, because not all mobile subscriber are always online.
=A0
Secondly, they are considered as mobile CPE case at this moment, not f= or mobile itself,
there are maybe more mobile user under mobile CPE. it won't confli= ct with your stateful NAT64 deployment hopefully.
=A0
Regards,
=A0
-Hui
--0016e64768024a353e04a979f98b-- From denghui02@gmail.com Mon Aug 1 16:33:18 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F06511E8077 for ; Mon, 1 Aug 2011 16:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2KFTwD4vPTg for ; Mon, 1 Aug 2011 16:33:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7311E8154 for ; Mon, 1 Aug 2011 16:33:16 -0700 (PDT) Received: by wyj26 with SMTP id 26so1799722wyj.31 for ; Mon, 01 Aug 2011 16:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ctF4q9hwFHjArh7JRpYnb1s4VEtIb1837eb65msTWMk=; b=KqhEMXMiR4d2VE//y+/CZPdlzE1EfOhDcsfBnqMKcjr1RQaQzq6p+LOFTnhp5tbUx1 QViccAAnsaOcfzjl2mseTqBhkh9+9btZXTw8Y4LY03biP6iE2RnuJWYQey9Lncr9tl5A 3mxXjdKDq/uZ8CJB/0DS8ZnEGVikvlNupjL2Y= MIME-Version: 1.0 Received: by 10.216.81.7 with SMTP id l7mr1134840wee.69.1312241603353; Mon, 01 Aug 2011 16:33:23 -0700 (PDT) Received: by 10.216.0.21 with HTTP; Mon, 1 Aug 2011 16:33:23 -0700 (PDT) In-Reply-To: References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> <067E6CE33034954AAC05C9EC85E2577C058E6EFE@XMB-RCD-111.cisco.com> Date: Tue, 2 Aug 2011 07:33:23 +0800 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf302ad6aca09ad104a97a0ef8 Cc: Softwires-wg , "Wojciech Dec \(wdec\)" , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 23:33:18 -0000 --20cf302ad6aca09ad104a97a0ef8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cameron, inline please 2011/8/2 Cameron Byrne > 2011/8/1 Rajiv Asati (rajiva) : > >> I appreciate that, and agree that the case for stateless A+P mapping i= s > >> clearer for DSL and optical fibers than for 3GPP > > > > There are other 3GPP operators who favor using stateless A+P mapping, s= o > I would shy away from the above agreement. Of course, different operators > have different constraints that make them favor one or the other solution= , > as you rightly said. > > > > Is it possible for those 3GPP operators to speak for themselves and > not via a vendor? If not, i understand. I always consider the source > of information. > =3D=3D> I could forsee the stateless 464 could benefit for 3GPP operator CP= E case after BBF deployed if opeartor could has similar management and opeation platform. As you said, doesn't see the potential of handset solution for it. > > I am looking to avoid an echo chamber where the IETF is doing > something it thinks the 3GPP wants and therefore the 3GPP adopts > something that it thinks the IETF wants. Does that make sense? > =3D=3D> probably bring to 3GPP for discussion early, then could make right judgement I guess. > > I would prefer that the draft drop reference to 3GPP since this is a > generic solution, right? It is not appropriated to try and > sell/target this solution in the RFC to a particular market segment. > There is no specific 3GPP engineering in this solution, so lets just > say it is a generic solution. Or, we can go a step further and call > it NAT464, then people would intuitively know what it is. > =3D=3D> stateless 464. it will be dfiferent from today's your trial statefu= l NAT64. how could make them work together will be one key for 3GPP to consider abou= t it. -Hui > > Cameron > > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n > Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Monday, August 01, 2011 11:25 AM > >> To: Cameron Byrne > >> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] 3gpp related comments on > draft-dec-stateless-4v6-02 > >> > >> Cameron, > >> > >> Thanks for the clarification. > >> More below. > >> > >> > >> > >> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit : > >> ... > >> > >> > Some providers may indeed prefer to have only a stateless > solution, > >> especially in for DSL networks where ISP's provide CPE's, but there is > no > >> technical reason preventing both solutions to coexist > >> > >> ... > >> > >> > >> Many, if not most, 3gpp users get rfc1918 or bogon public > addresses > >> today. Giving my users public addresses using 4v6 stateless probably > does not > >> make sense for me or many similar mobile operators. ... there are not > enough > >> public address to give these users (growth through 2015) each 2000 > ports. > >> > >> I don't se a significant disagreement here. > >> > >> If you have an overwhelming need for dynamic port sharing, it has to b= e > faced, > >> and you will go for CGN's. I don't argue against this. > >> > >> Some other operators may however have different constraints, and shoul= d > be > >> permitted to operate whatever simpler solution applies to their case. > >> > >> Note that one can expect that in 2015 users should work mostly, if not > >> exclusively in IPv6, so that their need should be well well below 2000 > IPv4 > >> ports for each. > >> > >> > >> This is just a 3gpp data point, since the draft chooses to inclu= de > 3gpp > >> as motivation. > >> > >> I appreciate that, and agree that the case for stateless A+P mapping i= s > >> clearer for DSL and optical fibers than for 3GPP > >> > >> > >> Regards, > >> RD > >> > >> > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf302ad6aca09ad104a97a0ef8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Cameron,
=A0
inline please

2011/8/2 Cameron Byrne <cb.list6@gmail.com>
2011/8/1 Rajiv Asati (rajiva) &l= t;rajiva@cisco.com>:
>> I appreciate that, and agree that the case for s= tateless A+P mapping is
>> clearer for DSL and optical fibers than= for 3GPP
>
> There are other 3GPP operators who favor using st= ateless A+P mapping, so I would shy away from the above agreement. Of cours= e, different operators have different constraints that make them favor one = or the other solution, as you rightly said.
>

Is it possible for those 3GPP operators to speak for them= selves and
not via a vendor? =A0If not, i understand. I always consider = the source
of information.
=3D=3D> I could forsee the stateless 464 could benefit for 3GPP ope= rator CPE case after BBF deployed if opeartor could has similar management = and opeation platform. As you said, doesn't see the potential of handse= t solution for it.
=A0

I am looking to avoid an ech= o chamber where the IETF is doing
something it thinks the 3GPP wants and= therefore the 3GPP adopts
something that it thinks the IETF wants. =A0Does that make sense?
=3D=3D> probably bring to 3GPP for discussion early, then could mak= e right judgement I guess.
=A0

I would prefer that the draf= t drop reference to 3GPP since this is a
generic solution, right? =A0It = is not appropriated to try and
sell/target this solution in the RFC to a particular market segment.
The= re is no specific 3GPP engineering in this solution, so lets just
say it= is a generic solution. =A0Or, we can go a step further and call
it NAT4= 64, then people would intuitively know what it is.
=3D=3D> stateless 464. it will be dfiferent from today's your t= rial stateful NAT64.
how could make them work together will be one key for 3GPP to consider= about it.
=A0
-Hui
=A0

Came= ron



> Cheers,
> Rajiv
>
>>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beha= lf
>> Of R=E9mi Despr=E9s
>> Sent: Monday, August 01, 2011 11:2= 5 AM
>> To: Cameron Byrne
>> Cc: Softwires-wg; Paco Corte= s; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] 3gpp related co= mments on draft-dec-stateless-4v6-02
>>
>> Cameron,
>>
>> Thanks for the clarif= ication.
>> More below.
>>
>>
>>
>= ;> Le 1 ao=FBt 2011 =E0 16:33, Cameron Byrne a =E9crit :
>> ...=
>>
>> =A0 =A0 =A0 > Some providers may indeed prefer to h= ave only a stateless solution,
>> especially in for DSL networks w= here ISP's provide CPE's, but there is no
>> technical rea= son preventing both solutions to coexist
>>
>> ...
>>
>>
>> =A0 =A0 =A0 Ma= ny, if not most, 3gpp users get rfc1918 or bogon public addresses
>&g= t; today. =A0Giving my users public addresses using 4v6 stateless probably = does not
>> make sense for me or many similar mobile operators. ... there are = not enough
>> public address to give these users (growth through 2= 015) each 2000 ports.
>>
>> I don't se a significant = disagreement here.
>>
>> If you have an overwhelming need for dynamic port shar= ing, it has to be faced,
>> and you will go for CGN's. I don&#= 39;t argue against this.
>>
>> Some other operators may h= owever have different constraints, and should be
>> permitted to operate whatever simpler solution applies to their ca= se.
>>
>> Note that one can expect that in 2015 users sho= uld work mostly, if not
>> exclusively in IPv6, so that their need= should be well well below 2000 IPv4
>> ports for each.
>>
>>
>> =A0 =A0 =A0 Th= is is just a 3gpp data point, since the draft chooses to include 3gpp
&g= t;> as motivation.
>>
>> I appreciate that, and agree = that the case for stateless A+P mapping is
>> clearer for DSL and optical fibers than for 3GPP
>>
&g= t;>
>> Regards,
>> RD
>>
>>
><= br>>
_______________________________________________
Softwires mai= ling list
Softwires@ietf.org
https://= www.ietf.org/mailman/listinfo/softwires

--20cf302ad6aca09ad104a97a0ef8-- From denghui02@gmail.com Mon Aug 1 16:35:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8E11E814D for ; Mon, 1 Aug 2011 16:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.234 X-Spam-Level: X-Spam-Status: No, score=-103.234 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpSTmWR0G35z for ; Mon, 1 Aug 2011 16:35:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE9D11E8077 for ; Mon, 1 Aug 2011 16:35:44 -0700 (PDT) Received: by wwe5 with SMTP id 5so4118605wwe.13 for ; Mon, 01 Aug 2011 16:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YwQODJ6pFIj4tU90FLQh8t+TiDLS8TIO3eZWMdm6qIk=; b=cyi2zKIxBiGeRw9qEF+QV+aiFAETzh4jJct+pJtRKyKKu2ki6dsCMq1fUFpysCY5HB rOYdMWEC+i2fGtBdJN/f0lsoZTM0u5ZGpDvpxpNqXWQ1isevqqdttI/3cYWPw9XXNgbo jxnhiXC1C5WBt6KOZxaltPEc9ZBGDiD7dxU0s= MIME-Version: 1.0 Received: by 10.216.237.144 with SMTP id y16mr1146973weq.114.1312241751349; Mon, 01 Aug 2011 16:35:51 -0700 (PDT) Received: by 10.216.0.21 with HTTP; Mon, 1 Aug 2011 16:35:51 -0700 (PDT) In-Reply-To: References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <8E225408-EACE-490A-B5B5-41F9AF0F8C2C@laposte.net> Date: Tue, 2 Aug 2011 07:35:51 +0800 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=000e0cd28bd272d9ed04a97a1707 Cc: Softwires-wg , Wojciech Dec , Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 23:35:45 -0000 --000e0cd28bd272d9ed04a97a1707 Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron > > I don't think headers are the issue, yes, some bit twiddlers will > disagree. The challenge is getting the UE software implemented. Take > IPv6 for example. Many operators have been asking for support for > years, and now Nokia is closing down Symbian. With Symbian gone as > a platform for new phones (effective now in many operators), there > will be ZERO IPv6 handsets available for GSM/UMTS that you can > purchase. > > I feel confident this will change, but i just want to share with you > the fact that the UE ecosystem is a very complex balance of power > between chipsets / Mobile OS / OEM / and service provider. New > features are very hard to get committed, especially when NAT444 and > NAT44 + IPv6 just work today in the mobile router segment. > ==> I share your concern here, since TE+ME eco system will be different for mobiel CPE case. hope it will make difference. -Hui --000e0cd28bd272d9ed04a97a1707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cameron


=A0
I don't think headers are the issu= e, yes, some bit twiddlers will
disagree. =A0The challenge is getting th= e UE software implemented. =A0Take
IPv6 for example. =A0Many operators h= ave been asking for support for
years, and now =A0Nokia is closing down Symbian. =A0With Symbian gone =A0as=
a platform for new phones (effective now in many operators), there
w= ill be ZERO IPv6 handsets available for GSM/UMTS that you can
purchase.<= br>
I feel confident this will change, but i just want to share with youthe fact that the UE ecosystem is a very complex balance of power
betwe= en chipsets / Mobile OS / OEM / and service provider. =A0New
features ar= e very hard to get committed, especially when NAT444 and
NAT44 + IPv6 just work today in the mobile router segment.
=3D=3D> I share your concern here,=A0since=A0TE+ME eco system will = be different for mobiel CPE case. hope it will make difference.
=A0
-Hui
=A0
--000e0cd28bd272d9ed04a97a1707-- From satoru.matsushima@gmail.com Mon Aug 1 19:41:44 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C813611E80C4 for ; Mon, 1 Aug 2011 19:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIGKY-LF3TNL for ; Mon, 1 Aug 2011 19:41:43 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66711E809E for ; Mon, 1 Aug 2011 19:41:43 -0700 (PDT) Received: by pzk6 with SMTP id 6so11664002pzk.26 for ; Mon, 01 Aug 2011 19:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VMxXMrmNVXDMC9z95prXKy1HnikbQJ3T1Ndhl1Rs8NQ=; b=XVF2t8nf5I1q9C5oQIuX2RfZc+Ss1bNy54BjYBAyRPyL6d+Dt2we9nb8D5AiIFtOyk tdhA77H+zgsBUhOvdgNDroetH3ke075nTVUWGD4uLwHQIY/XaiD4djKw0rhOzPAHVKZu 4ZPhB7CWAyIwjwYvyp2d06BM8rwBO+5+8Exbg= Received: by 10.68.54.234 with SMTP id m10mr1248102pbp.254.1312252911168; Mon, 01 Aug 2011 19:41:51 -0700 (PDT) Received: from [10.201.80.64] ([202.45.12.174]) by mx.google.com with ESMTPS id i9sm6215687pbk.52.2011.08.01.19.41.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 19:41:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4E370ABB.30200@go6.si> Date: Tue, 2 Aug 2011 11:41:45 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> <4E370ABB.30200@go6.si> To: Jan Zorz @ go6.si X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 02:41:45 -0000 On 2011/08/02, at 5:21, Jan Zorz @ go6.si wrote: > On 8/1/11 5:50 PM, Ole Troan wrote: >>> Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: >>>> Well, is short words, whatever number of ports you assign in >>>> port-set/range, end user can exhaust them. >>>=20 >>> The fact that most ISPs have been successfully operating with 65536 >>> ports per subscriber demonstrates that it is possible to statically >>> provision subscribers with "enough" ports. >>=20 >> many ISPs have deployed with much less than 64K ports. a typical >> limitation in CPE's NAT table is just 1024 ports. I've certainly >> returned CPEs to my ISPs with that limitation in the past. >=20 > +1 :) >=20 > I would do the same :) Thanks, a clarification has made to clear a confusion of restricted port = set/ranges and NAT session table limitation. Even if a CPE is allocated = 256 ports, NAT session can be made over 900G sessions in theory. = ('2^32' - '2^29' - '2^7'<0/8,127/8>) = * 2^8<256 ports>. cheers, --satoru= From satoru.matsushima@gmail.com Mon Aug 1 23:00:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8610B11E8088 for ; Mon, 1 Aug 2011 23:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqJ0Wzu3IYg8 for ; Mon, 1 Aug 2011 23:00:24 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99F11E8075 for ; Mon, 1 Aug 2011 23:00:24 -0700 (PDT) Received: by pzk6 with SMTP id 6so11901016pzk.26 for ; Mon, 01 Aug 2011 23:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Z0mug36omUSGZHw1PEot/sAEPY+1lQ2yUouoFDsIdks=; b=FsF1O40YO9gwKqol5erUy7TvTlSM7tIMFMkqGp8J+5+IPKMIJspJHsgCDoBs3d5bNX hkfGLdsQ0Dlt0tAQBxLRD+CXfwhpP1sW1eNDaw89oRW00yCHbgD0JZpxnFpb4CkXjXfX Fj9xjYrjHvO47HBXQoDKuqLKdSLYB74ZRat3Y= Received: by 10.68.30.198 with SMTP id u6mr8243879pbh.451.1312264832663; Mon, 01 Aug 2011 23:00:32 -0700 (PDT) Received: from [10.201.80.64] ([202.45.12.174]) by mx.google.com with ESMTPS id d3sm3719102pbg.92.2011.08.01.23.00.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 23:00:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <4E376AC0.9090000@jacni.com> Date: Tue, 2 Aug 2011 15:00:27 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <30725ED0-529F-46BB-8313-B7975A3278FD@gmail.com> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E376AC0.9090000@jacni.com> To: Jacni Qin X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:00:25 -0000 On 2011/08/02, at 12:10, Jacni Qin wrote: > hi Jan, >=20 > On 8/1/2011 10:36 PM, Jan Zorz @ go6.si wrote: >> On 8/1/11 1:07 PM, Satoru Matsushima wrote:=20 >>> So my question is that how dynamic is dynamic, and how static is=20 >>> static. The analogy of dynamic routing is that dynamic for updating=20= >>> routing information for prefixes but forwarding plane is stateless.=20= >>> If you imagine dynamic port ranges within stateless, it sounds like=20= >>> port range aware routing. I think that it would be controversial.=20 >>=20 >> yes, kind of.=20 >>=20 >> Well, is short words, whatever number of ports you assign in = port-set/range, end user can exhaust them.=20 >>=20 >> You need then give the user additional ports in order to communicate = or decide otherwise and send all additional traffic from this point on = to big evil CGN in the core.=20 > No, this hurts. I'd rather choose one then insist on it. ;-) Ok, Let's get back to analysis work as original discussion. cheers, --satoru= From bingxuere@gmail.com Mon Aug 1 23:12:08 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9EA21F8CB2 for ; Mon, 1 Aug 2011 23:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFiYdYn6m-sR for ; Mon, 1 Aug 2011 23:12:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1801A21F8CAA for ; Mon, 1 Aug 2011 23:12:07 -0700 (PDT) Received: by iye7 with SMTP id 7so9177814iye.31 for ; Mon, 01 Aug 2011 23:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SrmF2qCLtJ0mXm8XvwROHrCgYCw3OnsfhQyiu6405fI=; b=OhzQ0xr5nwjKTRp03ekPOU4Bm+vAmG+BcjYdpatTEc8m3rauWL91x6eYw0ONs5aKoK r+RxtNjGmnsnq+6IKcNgMkuRfpr5SPwbC69ifaw7BTIvPYQob7HTCqAnrTpD6Mu5eUjU 9Mbr/OEUr+Be7W0D4ylXAhW1vYfrQ2km4P4kA= Received: by 10.43.135.72 with SMTP id if8mr3532806icc.393.1312265535089; Mon, 01 Aug 2011 23:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.15.8 with HTTP; Mon, 1 Aug 2011 23:11:55 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Tue, 2 Aug 2011 14:11:55 +0800 Message-ID: To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=20cf307f358e11ed9204a97fa11d Cc: "softwires@ietf.org" Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:12:08 -0000 --20cf307f358e11ed9204a97fa11d Content-Type: text/plain; charset=UTF-8 Hi Lee, Thank you very much for your interests on 'lightweight 4over6'. In our consideration, lightweight AFTR is not doing port-range routing. In this lightweight AFTR, it would firstly lookup a mapping table (recording [IPv6 address, IPv4 address, Port set]) for a downstream IPv4 packet. Then after IPv4 packet has been encapsulated into IPv6 packet, it will do IPv6 routing based on different IPv6 addresses. So, lightweight AFTR does not need to distribute port-set info into FIB and there is no impact on existing routing architecture between B4 and AFTR. Actually, the basic idea behind 'lightweight 4over6' is to include addressing sharing for 'public 4over6', and to enhance DS-Lite for better scalability. It is a lightweight solution which only keeps customer-based state in AFTR compared to DS-Lite. And there is also no IPv6 address format restriction and no IPv6 routing impact on existing network infrastructure. We have implemented a prototype in our commercial network and find it easy to deploy in practice. With regard to so much stateful/stateless discussion, I think actually there is no solution with totally stateless in the address sharing world. It is only a matter of fact where to keep the states, either distributed in CPE or centralized in the core CGN. Given the fact that most existing CPEs can support NAT already, our solution is to keep less states in the Core CGN, while keeping the simplicity of IPv6 addressing and routing. Sorry to make the discussion even more complicated. Your comments are more than welcome. Thanks in advance. Best wishes On Tue, Aug 2, 2011 at 1:18 AM, Lee, Yiu wrote: > In this case, > http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt > could be (modified here) controversial because it will turn AFTR a PRR. > > On 8/1/11 7:07 AM, "Satoru Matsushima" > wrote: > > >If you imagine dynamic port ranges within stateless, it sounds like port > >range aware routing. I think that it would be controversial. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf307f358e11ed9204a97fa11d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lee,

Thank you very much for your interests on 'l= ightweight 4over6'.

In our consideration, ligh= tweight AFTR is not doing port-range routing. In this lightweight AFTR, it = would firstly lookup a mapping table (recording [IPv6 address, IPv4 address= , Port set])=C2=A0for a downstream IPv4 packet. Then after IPv4 packet has = been encapsulated into IPv6 packet, it will do IPv6 routing based on differ= ent IPv6 addresses. So, lightweight AFTR does not need to distribute port-s= et info into FIB and there is no impact on existing routing architecture be= tween B4 and AFTR.

Actually, the basic idea behind 'lightweight 4over6= ' is to include addressing sharing for 'public 4over6', and to = enhance DS-Lite for better scalability. It is a lightweight solution which = only keeps customer-based state in AFTR compared to DS-Lite. And there is a= lso no IPv6 address format restriction and no IPv6 routing impact on existi= ng network infrastructure. We have implemented a prototype in our=C2=A0comm= ercial network and=C2=A0find it easy to deploy in practice.=C2=A0

With regard to so much stateful/stateless discussion, I= think actually there is no solution with totally stateless in the address = sharing world. It is only a matter of fact where to keep the states, either= distributed in CPE or centralized in the core CGN. Given the fact that mos= t existing CPEs can support NAT already, =C2=A0our solution is to keep less= states in the Core CGN, while keeping the simplicity of IPv6 addressing an= d routing.

Sorry to make the discussion even more complicated. You= r comments are more than welcome.

Thanks in advanc= e.

Best wishes


On Tue, Aug 2, 2011 at 1:18 AM, Lee, Yiu <Yiu_Lee@ca= ble.comcast.com> wrote:
In this case,
http://tools.ietf.org/id/draf= t-cui-softwire-b4-translated-ds-lite-01.txt
could be (modified here) controversial because it will turn AFTR a PR= R.

On 8/1/11 7:07 AM, "Satoru Matsushima" <satoru.matsushima@gmail.com> wrote:

>If you imagine dynamic port ranges within stateless, it sounds like por= t
>range aware routing. I think that it would be controversial.

___________________________________= ____________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf307f358e11ed9204a97fa11d-- From satoru.matsushima@gmail.com Mon Aug 1 23:23:33 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720D721F884E for ; Mon, 1 Aug 2011 23:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMDcy-ufbZIh for ; Mon, 1 Aug 2011 23:23:32 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3021F8844 for ; Mon, 1 Aug 2011 23:23:32 -0700 (PDT) Received: by pzk6 with SMTP id 6so11929698pzk.26 for ; Mon, 01 Aug 2011 23:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0UfwS3GzWn82bEpm0h+ARxDMlZotJ/sw3FWdWMhfG+E=; b=ZMj1OA4SrxJjUinruLKZvbilRZ1qufQINAcn18ondZBuQ94uexi3Q57HzwPIn2rg2o S26MbJ+wdpeQlPfNQVMl7+6MEyAn6wzFkk5ZRkGhDCo+enX7A5E0pjYVqea0URO9IG3+ EloIxioaj+j+X7XYKhC3+hp5SlON+Nt7QM2fo= Received: by 10.68.8.38 with SMTP id o6mr8961415pba.129.1312266220740; Mon, 01 Aug 2011 23:23:40 -0700 (PDT) Received: from [10.201.80.64] ([202.45.12.174]) by mx.google.com with ESMTPS id g4sm39948pbj.57.2011.08.01.23.23.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 23:23:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4E37091A.8000400@go6.si> Date: Tue, 2 Aug 2011 15:23:36 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5AE212F8-CA6B-4892-AA2E-96BEF68F738D@gmail.com> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> <4E37091A.8000400@go6.si> To: Jan Zorz @ go6.si X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:23:33 -0000 On 2011/08/02, at 5:14, Jan Zorz @ go6.si wrote: > On 8/1/11 5:04 PM, Qiong wrote: >> So, this is a problem about how to define appropriate port set for = our >> customers, or to define maximum concurrent subscribers for a given = IPv4 >> address pool. Otherwise, there would either be a waste of resource, = or >> port exhaustion. Maybe we can even make some more flexible port-set >> rules for different time-slot or different types of users. But = anyway, >> this is the problem we have to face in the further, and I also = suggest >> that port-consuming applications should upgrade to IPv6 directly. >=20 > hi >=20 > assigning initial port range to every user and then dynamically = additional port ranges (or sets) solves this problem. This was solved = for statefull a+p. stateless still lacks this feature, requested by this = wg years ago. I agree with Qiong. This stateless/stateless and static/dynamic discussion assumes ipv4 over = ipv6 environment. Let see Yahoo, Google and Facebook, have already been = on ipv6. We don't need to take care about ports for these = sites(hopefully iTunes in near future). I also agree with that it would = be more significant to allocate appropriate port sets which are outside = of default static port sets for customer demand than ports exhaustion in = the v4 over v6 network. cheers, --satoru= From satoru.matsushima@gmail.com Mon Aug 1 23:32:58 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED10921F8B50 for ; Mon, 1 Aug 2011 23:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmbO7Vjt2oXX for ; Mon, 1 Aug 2011 23:32:58 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9921F8ABD for ; Mon, 1 Aug 2011 23:32:58 -0700 (PDT) Received: by pzk6 with SMTP id 6so11941590pzk.26 for ; Mon, 01 Aug 2011 23:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DwfXK99dOFbJGkg4WSsiqdyQj4q6hKQobXWG3aARaXo=; b=CdDfnB6G3ZmXefAZ5nnCftXIIFm39Vmthz0+fvO+NWokAY9d7CoDl4emO6djPTdh7G reTT5+AInkGnRUBSbId4cNKM5HM7Xhb3V0rLEKsAbWFeT3b5XtF5aVQpJLB1iyPnHU/v TU1/thuosU1UsRx9dKv02W51Uu6Lj4YxEAZR4= Received: by 10.68.57.100 with SMTP id h4mr3849097pbq.317.1312266786614; Mon, 01 Aug 2011 23:33:06 -0700 (PDT) Received: from [10.201.80.64] ([202.45.12.174]) by mx.google.com with ESMTPS id e6sm6407625pbm.55.2011.08.01.23.33.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 23:33:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Tue, 2 Aug 2011 15:33:01 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8FF93261-8992-4A71-BF47-95C52C9C98B7@gmail.com> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1244.3) Cc: Softwires-wg Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:32:59 -0000 Hi Yiu, One clarification. On 2011/08/02, at 2:29, Lee, Yiu wrote: > Actually, Orange Lab did some tests on A+P. They published the results = in > v6ops: >=20 > = http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results-01 >=20 > In their tests, bittorrent seems use most ports (200). Other public = apps > use no more than 100 ports. For a family of 5, I think 2000 ports = should > be significant at any given time. >=20 Which do you mean '2000' is the number of port you need, or the number = of NAT table sessions? cheers, --satoru >=20 >=20 > On 8/1/11 11:05 AM, "R=E9mi Despr=E9s" = wrote: >=20 >> Thanks for the quotation. >> What was "thrown" to you doesn't seem right, and needs to be = challenged. >>=20 >> Answer to the question: >> - The customer doesn't run out of ports because it has an exclusive >> private IPv4 address. >> - If the CPE NAT44 runs out of ports, is just does what it does today = in >> the same situation. >> In addition, the probability of the CPE running out of IPv4 ports in = a >> dual-stack-service site having 4K ports needs not be higher than in = an >> IPv4-only site having 64K ports. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jacni@jacni.com Tue Aug 2 00:57:37 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A991A21F87C2 for ; Tue, 2 Aug 2011 00:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neVsQjlFXseP for ; Tue, 2 Aug 2011 00:57:36 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id AA83321F87AF for ; Tue, 2 Aug 2011 00:57:36 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 5BE713801DE for ; Mon, 1 Aug 2011 23:11:00 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id 03B04340155 for ; Tue, 2 Aug 2011 11:10:57 +0800 (CST) Received: from [172.23.2.245] (unknown [112.64.190.183]) by app (Coremail) with SMTP id +AWowJC7CwebajdOujNCAA--.32673S2; Tue, 02 Aug 2011 11:10:54 +0800 (CST) Message-ID: <4E376AC0.9090000@jacni.com> Date: Tue, 02 Aug 2011 11:10:56 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Jan Zorz @ go6.si" References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> In-Reply-To: <4E36B9F0.3070607@go6.si> Content-Type: multipart/alternative; boundary="------------060406000703070602010201" X-CM-TRANSID: +AWowJC7CwebajdOujNCAA--.32673S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZw43ZFWfZrW7JF18JF1fJFb_yoWDAFX_ur ZYqr1xWr4UZr10yF1xKr4xJr93A3yUuF1Ut34kXw1xX3s5KFZ8Jrs5K3srK34rKFyUArn8 WFnayw17tw4xujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUjz8YjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6F4UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_JFC_Wr1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1ln4vE4IxY62xKV4CY8xCE548m6r4UJryUGwAawVCIc40E5I027xCE 548m6r1DJr4UtwAa7VCY0VAaVVAqrcv_Jw1UWr13McIj6xIIjxv20xvE14v26r1j6r18Mc Ij6I8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2 V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFI7vE0wC2zVAF1VAY17CE14v26r 1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jyYL9UUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAIEko7lMymJQAAsx Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 07:57:37 -0000 This is a multi-part message in MIME format. --------------060406000703070602010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi Jan, On 8/1/2011 10:36 PM, Jan Zorz @ go6.si wrote: > On 8/1/11 1:07 PM, Satoru Matsushima wrote: >> So my question is that how dynamic is dynamic, and how static is >> static. The analogy of dynamic routing is that dynamic for updating >> routing information for prefixes but forwarding plane is stateless. >> If you imagine dynamic port ranges within stateless, it sounds like >> port range aware routing. I think that it would be controversial. > > yes, kind of. > > Well, is short words, whatever number of ports you assign in > port-set/range, end user can exhaust them. > > You need then give the user additional ports in order to communicate > or decide otherwise and send all additional traffic from this point on > to big evil CGN in the core. No, this hurts. I'd rather choose one then insist on it. ;-) Cheers, Jacni > > Any idea how to solve this with 4rd and don't use CGN? > > Cheers, Jan Zorz > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --------------060406000703070602010201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi Jan,

On 8/1/2011 10:36 PM, Jan Zorz @ go6.si wrote:
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my question is that how dynamic is dynamic, and how static is
static. The analogy of dynamic routing is that dynamic for updating
routing information for prefixes but forwarding plane is stateless.
If you imagine dynamic port ranges within stateless, it sounds like
port range aware routing. I think that it would be controversial.

yes, kind of.

Well, is short words, whatever number of ports you assign in port-set/range, end user can exhaust them.

You need then give the user additional ports in order to communicate or decide otherwise and send all additional traffic from this point on to big evil CGN in the core.
No, this hurts. I'd rather choose one then insist on it. ;-)


Cheers,
Jacni


Any idea how to solve this with 4rd and don't use CGN?

Cheers, Jan Zorz
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--------------060406000703070602010201-- From jacni@jacni.com Tue Aug 2 01:03:12 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1255B21F8834 for ; Tue, 2 Aug 2011 01:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMTJRHumQPrb for ; Tue, 2 Aug 2011 01:03:11 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCA921F8749 for ; Tue, 2 Aug 2011 01:02:36 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 22F953801D7 for ; Mon, 1 Aug 2011 23:14:05 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id B2988860014 for ; Tue, 2 Aug 2011 11:14:03 +0800 (CST) Received: from [172.23.2.245] (unknown [112.64.190.183]) by app (Coremail) with SMTP id +AWowJArNAJ0azdO4DRCAA--.33523S2; Tue, 02 Aug 2011 11:13:58 +0800 (CST) Message-ID: <4E376BA3.5090207@jacni.com> Date: Tue, 02 Aug 2011 11:14:43 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Simon Perreault References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> In-Reply-To: <4E36BBF9.9070709@viagenie.ca> Content-Type: multipart/alternative; boundary="------------010906060807040903090703" X-CM-TRANSID: +AWowJArNAJ0azdO4DRCAA--.33523S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU8k7k042IEc7kJM7k042IE4IxYO2xFxVAq jxCEw4Av424lb7Iv0xC_Cr1lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWUuV WrJwAawVACjsI_Ar4v6c8GOVW06r1DJrWUAwAawVCFI7vE04vSzxk24VAqrcv_Gr1UXr18 M2vj6xkI62vS6c8GOVWUtr1rJFylYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14 v26r1j6r4UM4x0Y48IcVAKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE 67vIY487MxAIw28IcxkI7VAKI48JMxCIbVAxMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2 Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7IUn17K3UUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIIEko7lMym5AAAsy Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 08:03:12 -0000 This is a multi-part message in MIME format. --------------010906060807040903090703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Simon, On 8/1/2011 10:45 PM, Simon Perreault wrote: > Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: >> Well, is short words, whatever number of ports you assign in port-set/range, end >> user can exhaust them. > The fact that most ISPs have been successfully operating with 65536 ports per > subscriber demonstrates that it is possible to statically provision subscribers > with "enough" ports. Sorry, I don't catch your point here, could you? Cheers, Jacni > > Simon --------------010906060807040903090703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Simon,

On 8/1/2011 10:45 PM, Simon Perreault wrote: 
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:

Well, is short words, whatever number of ports you assign in port-set/range, end
user can exhaust them.

The fact that most ISPs have been successfully operating with 65536 ports per
subscriber demonstrates that it is possible to statically provision subscribers
with "enough" ports.
Sorry, I don't catch your point here, could you?


Cheers,
Jacni


Simon
--------------010906060807040903090703-- From despres.remi@laposte.net Tue Aug 2 02:35:00 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7AF21F8EF7 for ; Tue, 2 Aug 2011 02:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZNL7GFpStqp for ; Tue, 2 Aug 2011 02:35:00 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 02E6B21F8EF0 for ; Tue, 2 Aug 2011 02:35:00 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id A75E67000092; Tue, 2 Aug 2011 11:35:07 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id 85FD7700008C; Tue, 2 Aug 2011 11:35:03 +0200 (CEST) X-SFR-UUID: 20110802093507548.85FD7700008C@msfrf2418.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2011 11:35:03 +0200 To: Softwires-wg Message-Id: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 09:35:00 -0000 Hi, all, Several contributors have expressed, in the context of stateless = solutions, wishes to add flexibility to static port set assignment. But, where "stateless" has to mean "no per-customer state", this wish is = self-contradictory. Now: - Some ISP's want _direct CE-CE paths_ .=20 - For this each CE must know mapping rules for all other CE's. - Mapping rules must therefore not depend on any per customer state. - This doesn't permit dynamic increase of CE-assigned port sets. If I missed something, please let me know. If not, agreement on this point could facilitate the ongoing discussion. Thanks, RD= From despres.remi@laposte.net Tue Aug 2 05:57:46 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3D721F84EB for ; Tue, 2 Aug 2011 05:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhePEknKFstU for ; Tue, 2 Aug 2011 05:57:45 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 794F821F84F2 for ; Tue, 2 Aug 2011 05:57:45 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 9B1C2700008D; Tue, 2 Aug 2011 14:57:53 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 4A08F7000090; Tue, 2 Aug 2011 14:57:49 +0200 (CEST) X-SFR-UUID: 20110802125749303.4A08F7000090@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-71--1024779927 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 2 Aug 2011 14:57:49 +0200 Message-Id: References: <249B3B24-FC2A-4F93-8597-2ED45040C8AB@laposte.net> <59B8E080-A2A9-45B6-B085-57DD71660547@laposte.net> <067E6CE33034954AAC05C9EC85E2577C058E6F05@XMB-RCD-111.cisco.com> <8EF6E9E8-C917-4A3D-B8E6-607747D06CF8@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Paco Cortes Subject: Re: [Softwires] Naming IPv4-via-IPv6 solutions (was 3gpp related comments on draft-dec-stateless-4v6-02) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:57:46 -0000 --Apple-Mail-71--1024779927 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 1 ao=FBt 2011 =E0 18:34, Wojciech Dec a =E9crit : ... > Note that with stateless mappings + encapsulation, "stateless NAT" is = an inappropriate wording, because there is no translation: >=20 > All of the current Stateless46 variants TRANSLATE Layer 4 (TCP/UDP) + = layer 3 (IPv4) info into Layer 3 (IPv6). Would be happy to use another = term if... > =20 > - This ensures e2e transparency, Right, if IPv4 packets are encapsulated, they cannot be said to be = "translated". "Stateless NAT" isn't therefore an adequate generic term for all the = stateless solutions being discussed or IPv4 via IPv6.=20 "Stateless IPv4-via-IPv6", as in your draft, is AFAIK much better. 4V6 variants could then be named, for example: - Stateless 4V6 Translation=20 - Stateless 4V6 Encapsulation - Stateful 4V6 without CGN (RFC 6145, but no NAPT64) - Stateful 4V6 with CGN (NAPT64) If acronyms are needed (and they tend to be), they could be something = like: - 4V6T, 4V6E, 4V6N , 4V6C=20 - or 4V6-T, 4V6-E, 4V-6N , 4V6-C - whatever expresses both what is common and what is different Thoughts? Cheers, RD --Apple-Mail-71--1024779927 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Note that with stateless mappings + = encapsulation, "stateless NAT" is an inappropriate wording, because = there is no = translation:

 All of the current = Stateless46 variants TRANSLATE Layer 4 (TCP/UDP) + layer 3 (IPv4) info = into Layer 3 (IPv6). Would be happy to use another term if...
 

"Stateless NAT" isn't = therefore an adequate generic term for all the stateless solutions being = discussed or IPv4 via IPv6. 
"Stateless IPv4-via-IPv6", = as in your draft, is AFAIK much = better.

4V6 variants could then be named, = for example:
- Stateless 4V6 = Translation 
- Stateless 4V6 = Encapsulation
- Stateful 4V6 without CGN (RFC 6145, but no = NAPT64)
- Stateful 4V6 with CGN = (NAPT64)

If acronyms are needed (and they tend = to be), they could be something like:
- 4V6T, 4V6E, 4V6N , = 4V6C 
- or 4V6-T, 4V6-E, 4V-6N , 4V6-C
- = whatever expresses both what is common and what is = different

Thoughts?

Chee= rs,
RD


= --Apple-Mail-71--1024779927-- From simon.perreault@viagenie.ca Tue Aug 2 06:24:20 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B155821F889F for ; Tue, 2 Aug 2011 06:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx-bilpxpEQ6 for ; Tue, 2 Aug 2011 06:24:20 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CFD3321F87F0 for ; Tue, 2 Aug 2011 06:24:19 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 06BF921F26 for ; Tue, 2 Aug 2011 09:24:25 -0400 (EDT) Message-ID: <4E37FA9A.5070909@viagenie.ca> Date: Tue, 02 Aug 2011 09:24:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: softwires@ietf.org References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> In-Reply-To: <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:24:20 -0000 Satoru Matsushima wrote, on 08/01/2011 10:41 PM: > Thanks, a clarification has made to clear a confusion of restricted port > set/ranges and NAT session table limitation. Even if a CPE is allocated 256 > ports, NAT session can be made over 900G sessions in theory. ('2^32' 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) * 2^8<256 ports>. This is only true for endpoint-dependent NATs, which are forbidden by the BEHAVE RFCs (4787 and 5382). According to these RFCs, NATs MUST have endpoint-independent mapping behaviour. This means that each NAT session will consume one external port. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Aug 2 06:32:42 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99AE21F84CE for ; Tue, 2 Aug 2011 06:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1HEC0hCWKW4 for ; Tue, 2 Aug 2011 06:32:41 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 96C1621F84CB for ; Tue, 2 Aug 2011 06:32:41 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 660B421F26; Tue, 2 Aug 2011 09:32:49 -0400 (EDT) Message-ID: <4E37FC91.90202@viagenie.ca> Date: Tue, 02 Aug 2011 09:33:05 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Jacni Qin References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> <4E376BA3.5090207@jacni.com> In-Reply-To: <4E376BA3.5090207@jacni.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:32:42 -0000 Jacni Qin wrote, on 08/01/2011 11:14 PM: > On 8/1/2011 10:45 PM, Simon Perreault wrote: >> Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: >>> Well, is short words, whatever number of ports you assign in port-set/range, end >>> user can exhaust them. >> The fact that most ISPs have been successfully operating with 65536 ports per >> subscriber demonstrates that it is possible to statically provision subscribers >> with "enough" ports. > Sorry, I don't catch your point here, could you? The original assertion was "there is no X such that X number of ports per user is enough." Past experience shows that "X=65536 is enough". Therefore, the original assertion is false. :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Aug 2 06:54:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624B721F86AC for ; Tue, 2 Aug 2011 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCcqX-XT7AiV for ; Tue, 2 Aug 2011 06:54:12 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id AF8D221F85AC for ; Tue, 2 Aug 2011 06:54:12 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7F71221F26 for ; Tue, 2 Aug 2011 09:54:21 -0400 (EDT) Message-ID: <4E38019D.3090206@viagenie.ca> Date: Tue, 02 Aug 2011 09:54:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: softwires@ietf.org References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> <4E37FA9A.5070909@viagenie.ca> In-Reply-To: <4E37FA9A.5070909@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:54:13 -0000 Simon Perreault wrote, on 08/02/2011 09:24 AM: > Satoru Matsushima wrote, on 08/01/2011 10:41 PM: >> Thanks, a clarification has made to clear a confusion of restricted port >> set/ranges and NAT session table limitation. Even if a CPE is allocated 256 >> ports, NAT session can be made over 900G sessions in theory. ('2^32'> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) * 2^8<256 ports>. > > This is only true for endpoint-dependent NATs, which are forbidden by the BEHAVE > RFCs (4787 and 5382). According to these RFCs, NATs MUST have > endpoint-independent mapping behaviour. This means that each NAT session will > consume one external port. Sorry, I confused the terminology. Each NAT *binding* will consume one external port. There may be multiple session to different destinations using the same external port. The 900G figure is valid, as long as internal hosts reuse the same source address+port for different destinations. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rajiva@cisco.com Tue Aug 2 15:39:04 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68011E80CD for ; Tue, 2 Aug 2011 15:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1xFSvZ3qlg0 for ; Tue, 2 Aug 2011 15:39:03 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9007311E8095 for ; Tue, 2 Aug 2011 15:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2186; q=dns/txt; s=iport; t=1312324754; x=1313534354; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dymIpp3AXI1v+Agbh+RmDBVT8dHUTy1aBDGezKMc6Ko=; b=K2x/cwhFOur1w5gw5pPF+VtOJxBC5Z+5ShHOijEH9QRrcuC45mlyLQTb KiFjEwFxLSFFmBzlCI2x50sgFkXAmWVjcnzaRCNSpQBn9WPCwwp17xj/L cjeFe7gLgX8hQPMe8udJtIZOSu7gBDBOoo0JPfz9hLcqBfLPEFWROAFJU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0BACh8OE6tJV2d/2dsb2JhbABCmBKIPYFMhU13gUABAQEBAgEBAQEPARQJCjQQBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHSgSgVQGeVIVjXwSHWpAxi3I X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="8991834" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2011 22:39:13 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p72MdDBk010740; Tue, 2 Aug 2011 22:39:13 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 17:39:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2011 17:39:12 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com> In-Reply-To: <4E38019D.3090206@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion Thread-Index: AcxRG7mQWwLRWtXqRjOOu3Bt8MMYkAASKQTw References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> From: "Rajiv Asati (rajiva)" To: "Simon Perreault" , , "Satoru Matsushima" X-OriginalArrivalTime: 02 Aug 2011 22:39:13.0156 (UTC) FILETIME=[00A98C40:01CC5165] Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:39:04 -0000 Satoru-san, =20 This is an important point that most of us forget that restricting to "n" ports doesn't equate to just "n" NAT sessions rather many more than n sessions. We must add that to the 4v6 motivation draft as well as to the 4v6 comparison draft. > port. There may be multiple session to different destinations using the same > external port. The 900G figure is valid, as long as internal hosts reuse the > same source address+port for different destinations. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of Simon Perreault > Sent: Tuesday, August 02, 2011 9:55 AM > To: softwires@ietf.org > Subject: Re: [Softwires] Clarification of the stateles/stateful discussion >=20 > Simon Perreault wrote, on 08/02/2011 09:24 AM: > > Satoru Matsushima wrote, on 08/01/2011 10:41 PM: > >> Thanks, a clarification has made to clear a confusion of restricted port > >> set/ranges and NAT session table limitation. Even if a CPE is allocated 256 > >> ports, NAT session can be made over 900G sessions in theory. ('2^32' >> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) * 2^8<256 > ports>. > > > > This is only true for endpoint-dependent NATs, which are forbidden by the > BEHAVE > > RFCs (4787 and 5382). According to these RFCs, NATs MUST have > > endpoint-independent mapping behaviour. This means that each NAT session > will > > consume one external port. >=20 > Sorry, I confused the terminology. Each NAT *binding* will consume one > external > port. There may be multiple session to different destinations using the same > external port. The 900G figure is valid, as long as internal hosts reuse the > same source address+port for different destinations. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jacni@jacni.com Tue Aug 2 17:54:01 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB4F11E8115 for ; Tue, 2 Aug 2011 17:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNpj5IYpoPsG for ; Tue, 2 Aug 2011 17:53:57 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 4836911E80F7 for ; Tue, 2 Aug 2011 17:53:56 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 77BD13801F9 for ; Tue, 2 Aug 2011 20:54:06 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id 06DF534011A for ; Wed, 3 Aug 2011 08:54:03 +0800 (CST) Received: from [172.20.219.196] (unknown [112.64.190.173]) by app (Coremail) with SMTP id +AWowJAbJAIonDhO5C1DAA--.35730S2; Wed, 03 Aug 2011 08:54:02 +0800 (CST) Message-ID: <4E389C63.9030001@jacni.com> Date: Wed, 03 Aug 2011 08:54:59 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Simon Perreault References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si> <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca> <4E376BA3.5090207@jacni.com> <4E37FC91.90202@viagenie.ca> In-Reply-To: <4E37FC91.90202@viagenie.ca> Content-Type: multipart/alternative; boundary="------------030608040105090108010505" X-CM-TRANSID: +AWowJAbJAIonDhO5C1DAA--.35730S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtrWDWF1UGr4xtw45Kr4fuFg_yoW3GrX_ua yDK3y8Gw15JF4akw47Kw47urs5GF1I9F90qrs8Grn3Ar1Y9ryDJFW5JF1a9w1xGa15Zw13 W39YvrWfXwsxtjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUjY8YjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6F4UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_JFC_Wr1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1ln4vE4IxY62xKV4CY8xCE548m6r4UJryUGwAa7VCY0VAaVVAqrcv_ Jw1UWr13McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwCFI7vE0wC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxh VjvjDU0xZFpf9x07jyYL9UUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIJEko7lM0aYwAAsJ Cc: softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:54:01 -0000 This is a multi-part message in MIME format. --------------030608040105090108010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi, On 8/2/2011 9:33 PM, Simon Perreault wrote: > Jacni Qin wrote, on 08/01/2011 11:14 PM: >> On 8/1/2011 10:45 PM, Simon Perreault wrote: >>> Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM: >>>> Well, is short words, whatever number of ports you assign in port-set/range, end >>>> user can exhaust them. >>> The fact that most ISPs have been successfully operating with 65536 ports per >>> subscriber demonstrates that it is possible to statically provision subscribers >>> with "enough" ports. >> Sorry, I don't catch your point here, could you? > The original assertion was "there is no X such that X number of ports per user > is enough." > > Past experience shows that "X=65536 is enough". > > Therefore, the original assertion is false. > > :) > > Simon Ok, Thanks. Cheers, Jacni --------------030608040105090108010505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi,

On 8/2/2011 9:33 PM, Simon Perreault wrote: 
Jacni Qin wrote, on 08/01/2011 11:14 PM:

On 8/1/2011 10:45 PM, Simon Perreault wrote:

Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:

Well, is short words, whatever number of ports you assign in port-set/range, end
user can exhaust them.

The fact that most ISPs have been successfully operating with 65536 ports per
subscriber demonstrates that it is possible to statically provision subscribers
with "enough" ports.

Sorry, I don't catch your point here, could you?

The original assertion was "there is no X such that X number of ports per user
is enough."

Past experience shows that "X=65536 is enough".

Therefore, the original assertion is false.

:)

Simon

Ok, Thanks.


Cheers,
Jacni


    

  


--------------030608040105090108010505--


From despres.remi@laposte.net  Wed Aug  3 01:01:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13F21F8B34 for ; Wed,  3 Aug 2011 01:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjiA1UNxRBMo for ; Wed,  3 Aug 2011 01:01:45 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 398F121F8B32 for ; Wed,  3 Aug 2011 01:01:43 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id C0C4D940155; Wed,  3 Aug 2011 10:01:47 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>
Date: Wed, 3 Aug 2011 10:01:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>
To: Rajiv Asati (rajiva) 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 08:01:46 -0000

Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :

> Satoru-san, =20
>=20
> This is an important point that most of us forget that restricting to
> "n" ports doesn't equate to just "n" NAT sessions rather many more =
than
> n sessions. We must add that to the 4v6 motivation draft as well as to
> the 4v6 comparison draft.

+1

RD

>=20
>> port. There may be multiple session to different destinations using
> the same
>> external port. The 900G figure is valid, as long as internal hosts
> reuse the
>> same source address+port for different destinations.
>=20
> Cheers,
> Rajiv
>=20
>=20
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> On Behalf
>> Of Simon Perreault
>> Sent: Tuesday, August 02, 2011 9:55 AM
>> To: softwires@ietf.org
>> Subject: Re: [Softwires] Clarification of the stateles/stateful
> discussion
>>=20
>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
>>>> Thanks, a clarification has made to clear a confusion of restricted
> port
>>>> set/ranges and NAT session table limitation. Even if a CPE is
> allocated 256
>>>> ports, NAT session can be made over 900G sessions in theory.
> ('2^32'>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
> 2^8<256
>> ports>.
>>>=20
>>> This is only true for endpoint-dependent NATs, which are forbidden
> by the
>> BEHAVE
>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have
>>> endpoint-independent mapping behaviour. This means that each NAT
> session
>> will
>>> consume one external port.
>>=20
>> Sorry, I confused the terminology. Each NAT *binding* will consume =
one
>> external
>> port. There may be multiple session to different destinations using
> the same
>> external port. The 900G figure is valid, as long as internal hosts
> reuse the
>> same source address+port for different destinations.
>>=20
>> Simon
>> --
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> STUN/TURN server               --> http://numb.viagenie.ca
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From simon.perreault@viagenie.ca  Wed Aug  3 06:05:47 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C409421F8B4C for ; Wed,  3 Aug 2011 06:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.390,  BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j05g4D7A+hly for ; Wed,  3 Aug 2011 06:05:47 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E736421F8B4B for ; Wed,  3 Aug 2011 06:05:46 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A8FD420CC4; Wed,  3 Aug 2011 09:05:57 -0400 (EDT)
Message-ID: <4E3947B4.3050008@viagenie.ca>
Date: Wed, 03 Aug 2011 09:05:56 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com> 
In-Reply-To: 
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 13:05:47 -0000

On 2011-08-03 04:01, Rémi Després wrote:
> 
> Le 3 aoűt 2011 ŕ 00:39, Rajiv Asati (rajiva) a écrit :
> 
>> Satoru-san,  
>>
>> This is an important point that most of us forget that restricting to
>> "n" ports doesn't equate to just "n" NAT sessions rather many more than
>> n sessions. We must add that to the 4v6 motivation draft as well as to
>> the 4v6 comparison draft.
> 
> +1

I think there is an important point missing from this discussion. It is
tricky but it has important practical consequences.

As I said, "The 900G figure is valid, *as long as internal hosts reuse
the same source address+port for different destinations*."

The "as long as ..." part is important. I don't know of any operating
system that behaves like that. That is, a different source port will be
used for each new outbound session, regardless of the destination.
Therefore, in practice, each session will require one NAT binding, which
will in turn consume one external port.

So the 900G figure is valid *in theory*, but *in practice* we're stuck
with a number of sessions roughly equal to the number of external ports
available on the NAT.

Now, if there is no NAT and the host itself is constrained to a given
port range, the OS will usually start reusing source ports for different
destinations when there is pressure to do so (i.e. when all source ports
are in use). Where a NAT would simply drop the session-creating packet,
in this case the OS is able to reuse a source port. So if there is no
NAT, the 900G figure is also valid in practice.

Simon

>>> -----Original Message-----
>>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
>> On Behalf
>>> Of Simon Perreault
>>> Sent: Tuesday, August 02, 2011 9:55 AM
>>> To: softwires@ietf.org
>>> Subject: Re: [Softwires] Clarification of the stateles/stateful
>> discussion
>>>
>>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
>>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
>>>>> Thanks, a clarification has made to clear a confusion of restricted
>> port
>>>>> set/ranges and NAT session table limitation. Even if a CPE is
>> allocated 256
>>>>> ports, NAT session can be made over 900G sessions in theory.
>> ('2^32'>>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
>> 2^8<256
>>> ports>.
>>>>
>>>> This is only true for endpoint-dependent NATs, which are forbidden
>> by the
>>> BEHAVE
>>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have
>>>> endpoint-independent mapping behaviour. This means that each NAT
>> session
>>> will
>>>> consume one external port.
>>>
>>> Sorry, I confused the terminology. Each NAT *binding* will consume one
>>> external
>>> port. There may be multiple session to different destinations using
>> the same
>>> external port. The 900G figure is valid, as long as internal hosts
>> reuse the
>>> same source address+port for different destinations.


-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From despres.remi@laposte.net  Wed Aug  3 06:32:34 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99821F8B23 for ; Wed,  3 Aug 2011 06:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.594
X-Spam-Level: 
X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bhm6CNyNZNbV for ; Wed,  3 Aug 2011 06:32:34 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id 784A521F8B10 for ; Wed,  3 Aug 2011 06:32:33 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 550AA7000092; Wed,  3 Aug 2011 15:32:44 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id A779C700008C; Wed,  3 Aug 2011 15:32:41 +0200 (CEST)
X-SFR-UUID: 20110803133241686.A779C700008C@msfrf2313.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4E3947B4.3050008@viagenie.ca>
Date: Wed, 3 Aug 2011 15:32:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D5A55B5-0583-4518-A639-8BB26B1090F9@laposte.net>
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 13:32:34 -0000

Hi, Simon,

See inline.

Le 3 ao=FBt 2011 =E0 15:05, Simon Perreault a =E9crit :

> On 2011-08-03 04:01, R=E9mi Despr=E9s wrote:
>>=20
>> Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :
>>=20
>>> Satoru-san, =20
>>>=20
>>> This is an important point that most of us forget that restricting =
to
>>> "n" ports doesn't equate to just "n" NAT sessions rather many more =
than
>>> n sessions. We must add that to the 4v6 motivation draft as well as =
to
>>> the 4v6 comparison draft.
>>=20
>> +1
>=20
> I think there is an important point missing from this discussion. It =
is
> tricky but it has important practical consequences.
>=20
> As I said, "The 900G figure is valid, *as long as internal hosts reuse
> the same source address+port for different destinations*."
>=20
> The "as long as ..." part is important.

Agreed.

> I don't know of any operating
> system that behaves like that.

The point is that this behavior concerns the NAT44 of a CE that supports =
address sharing (it doesn't concern a PC OS).
By permitting _this_ NAT to do endpoint-dependent mapping for TCP =
connections, the number of supported connections can be largely =
increased (if found useful).

Cheers,
RD


> That is, a different source port will be
> used for each new outbound session, regardless of the destination.
> Therefore, in practice, each session will require one NAT binding, =
which
> will in turn consume one external port.
>=20
> So the 900G figure is valid *in theory*, but *in practice* we're stuck
> with a number of sessions roughly equal to the number of external =
ports
> available on the NAT.
>=20
> Now, if there is no NAT and the host itself is constrained to a given
> port range, the OS will usually start reusing source ports for =
different
> destinations when there is pressure to do so (i.e. when all source =
ports
> are in use). Where a NAT would simply drop the session-creating =
packet,
> in this case the OS is able to reuse a source port. So if there is no
> NAT, the 900G figure is also valid in practice.
>=20
> Simon
>=20
>>>> -----Original Message-----
>>>> From: softwires-bounces@ietf.org =
[mailto:softwires-bounces@ietf.org]
>>> On Behalf
>>>> Of Simon Perreault
>>>> Sent: Tuesday, August 02, 2011 9:55 AM
>>>> To: softwires@ietf.org
>>>> Subject: Re: [Softwires] Clarification of the stateles/stateful
>>> discussion
>>>>=20
>>>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
>>>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
>>>>>> Thanks, a clarification has made to clear a confusion of =
restricted
>>> port
>>>>>> set/ranges and NAT session table limitation. Even if a CPE is
>>> allocated 256
>>>>>> ports, NAT session can be made over 900G sessions in theory.
>>> ('2^32'>>>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
>>> 2^8<256
>>>> ports>.
>>>>>=20
>>>>> This is only true for endpoint-dependent NATs, which are forbidden
>>> by the
>>>> BEHAVE
>>>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have
>>>>> endpoint-independent mapping behaviour. This means that each NAT
>>> session
>>>> will
>>>>> consume one external port.
>>>>=20
>>>> Sorry, I confused the terminology. Each NAT *binding* will consume =
one
>>>> external
>>>> port. There may be multiple session to different destinations using
>>> the same
>>>> external port. The 900G figure is valid, as long as internal hosts
>>> reuse the
>>>> same source address+port for different destinations.
>=20
>=20
> --=20
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca



From simon.perreault@viagenie.ca  Wed Aug  3 06:45:51 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314AC21F8B4D for ; Wed,  3 Aug 2011 06:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Level: 
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyY3uPg99mWB for ; Wed,  3 Aug 2011 06:45:50 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 975D121F8AEE for ; Wed,  3 Aug 2011 06:45:50 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 03A4E20D0C; Wed,  3 Aug 2011 09:46:01 -0400 (EDT)
Message-ID: <4E395119.8020209@viagenie.ca>
Date: Wed, 03 Aug 2011 09:46:01 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca> <7D5A55B5-0583-4518-A639-8BB26B1090F9@laposte.net>
In-Reply-To: <7D5A55B5-0583-4518-A639-8BB26B1090F9@laposte.net>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 13:45:51 -0000

On 2011-08-03 09:32, Rémi Després wrote:
>> I think there is an important point missing from this discussion. It is
>> tricky but it has important practical consequences.
>>
>> As I said, "The 900G figure is valid, *as long as internal hosts reuse
>> the same source address+port for different destinations*."
>>
>> The "as long as ..." part is important.
> 
> Agreed.
> 
>> I don't know of any operating
>> system that behaves like that.
> 
> The point is that this behavior concerns the NAT44 of a CE that supports address sharing (it doesn't concern a PC OS).
> By permitting _this_ NAT to do endpoint-dependent mapping for TCP connections, the number of supported connections can be largely increased (if found useful).

Agreed. IMHO, a NAT should be allowed to do endpoint-dependent mapping
for protocols that are known not to cause issues (e.g. HTTP and DNS). I
think this would address most scaling concerns people have with port
ranges. This was already discussed in the behave WG by the way...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From bingxuere@gmail.com  Wed Aug  3 07:09:23 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2221F863A for ; Wed,  3 Aug 2011 07:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.39
X-Spam-Level: 
X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=-0.092,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRGAKvGYKDTt for ; Wed,  3 Aug 2011 07:09:23 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E00A321F861E for ; Wed,  3 Aug 2011 07:09:22 -0700 (PDT)
Received: by iye7 with SMTP id 7so1155570iye.31 for ; Wed, 03 Aug 2011 07:09:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4Ll2m2a4n3blWNJ0wTdc9yE5jL7RVlwrMEZ7ol6ziuc=; b=LM7EQwH1TyTdD+RUihnersAj+Xl4XbdvUabFkRYsO5vJRZrkxPBxerTlc0y5xkeTN8 59v90D0HCpGENXmgKSGRj9Q38GBS1wVjDO1/sCSIm5m0M4Of8bWxI48uuEpQwJdQT9wo 8S83CvqqyeZCj+d02Q3zxySLUlXFDsix+ABAw=
Received: by 10.231.111.39 with SMTP id q39mr4745558ibp.106.1312380574714; Wed, 03 Aug 2011 07:09:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.43.1 with HTTP; Wed, 3 Aug 2011 07:09:14 -0700 (PDT)
In-Reply-To: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net>
References: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net>
From: Qiong 
Date: Wed, 3 Aug 2011 22:09:14 +0800
Message-ID: 
To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= 
Content-Type: multipart/alternative; boundary=0016367d72e0f74bcb04a99a690e
Cc: Softwires-wg 
Subject: Re: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 14:09:24 -0000

--0016367d72e0f74bcb04a99a690e
Content-Type: text/plain; charset=UTF-8

Hi, Remi,

This is just the question I would like to mention. Please see inline.

Several contributors have expressed, in the context of stateless solutions,
> wishes to add flexibility to static port set assignment.
>
> But, where "stateless" has to mean "no per-customer state", this wish is
> self-contradictory.
>
> Now:
> - Some ISP's want _direct CE-CE paths_ .
>
[Qiong] : Agree. This is a good feature for stateless solution. But there
might be no big differences from stateful solutions when deploying CGN on
the edge of network, e.g. BRAS, etc.


> - For this each CE must know mapping rules for all other CE's.
>
[Qiong]: Agree, especially when applying the co-existence scenario for
exclusive-mode and shared mode. Given the fact the IPv4 prefixes are not
continuous anymore, there might be up to hundreds/thousands of rules for a
certain area.

Although I think that it would be not a big problem for stateless GW to
handle these rules, I would still doubt the possibility that a customer-side
CPE dealing with the same amount of IPv4 prefixes with network-side GW.

And another question, when should we announce these rules into CEs and BRs.
Since in CE-CE situation, a source should always send a packet with the
right destination port in the valid range of destinations. Is it has to been
guaranteed by individual applications ? Or does it have some kind of
limitations depending on applications ?

Thanks.

Best regards

Qiong Sun


- Mapping rules must therefore not depend on any per customer state.
> - This doesn't permit dynamic increase of CE-assigned port sets.
>
> If I missed something, please let me know.
> If not, agreement on this point could facilitate the ongoing discussion.
>
> Thanks,
> RD
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--0016367d72e0f74bcb04a99a690e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Remi,

This is just the question I would like to ment=
ion. Please see inline.=C2=A0



Several contributors have expressed, in the context of stateless solutions,=
 wishes to add flexibility to static port set assignment.



But, where "stateless" has to mean "no per-customer state&qu=
ot;, this wish is self-contradictory.



Now:

- Some ISP's want _direct CE-CE paths_ .
[Qiong] :=
 Agree. This is a good feature for stateless solution. But there might be n=
o big differences from stateful solutions when deploying CGN on the edge of=
 network, e.g. BRAS, etc.=C2=A0



=C2=A0

- For this each CE must know mapping rules for all other CE's.
[Qiong]: Agree, especially when applying the co-existence scen=
ario for exclusive-mode and shared mode. Given the fact the IPv4 prefixes a=
re not continuous anymore, there might be up to=C2=A0hundreds/thousands of =
rules for a certain area.




Although I think that it would be not a big problem for=
 stateless GW to handle these rules, I would still doubt the possibility th=
at a customer-side CPE dealing with the same amount of IPv4 prefixes with n=
etwork-side GW.=C2=A0




And another question, when should we=C2=A0announce thes=
e rules into CEs and BRs. Since in CE-CE situation, a source should always =
send a packet with the right destination port in the valid range of destina=
tions. Is it has to been guaranteed by individual applications ? Or does it=
 have some kind of limitations depending on applications ?




Thanks.

Best regards

Qiong Sun




- Mapping rules must therefore not depend on any per customer state.

- This doesn't permit dynamic increase of CE-assigned port sets.



If I missed something, please let me know.

If not, agreement on this point could facilitate the ongoing discussion.


Thanks,

RD

_______________________________________________

Softwires mailing list

Softwires@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/softwires





--0016367d72e0f74bcb04a99a690e--

From despres.remi@laposte.net  Wed Aug  3 07:13:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C0421F8AE9 for ; Wed,  3 Aug 2011 07:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.59
X-Spam-Level: 
X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.241,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aplmQWnf4t3M for ; Wed,  3 Aug 2011 07:13:53 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1241E21F862F for ; Wed,  3 Aug 2011 07:13:53 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 3A6B37000086; Wed,  3 Aug 2011 16:14:04 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id E51BB7000085; Wed,  3 Aug 2011 16:14:03 +0200 (CEST)
X-SFR-UUID: 20110803141403938.E51BB7000085@msfrf2313.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4E395119.8020209@viagenie.ca>
Date: Wed, 3 Aug 2011 16:14:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca> <7D5A55B5-0583-4518-A639-8BB26B1090F9@laposte.net> <4E395119.8020209@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 14:13:54 -0000

Le 3 ao=FBt 2011 =E0 15:46, Simon Perreault a =E9crit :

> On 2011-08-03 09:32, R=E9mi Despr=E9s wrote:
>>> I think there is an important point missing from this discussion. It =
is
>>> tricky but it has important practical consequences.
>>>=20
>>> As I said, "The 900G figure is valid, *as long as internal hosts =
reuse
>>> the same source address+port for different destinations*."
>>>=20
>>> The "as long as ..." part is important.
>>=20
>> Agreed.
>>=20
>>> I don't know of any operating
>>> system that behaves like that.
>>=20
>> The point is that this behavior concerns the NAT44 of a CE that =
supports address sharing (it doesn't concern a PC OS).
>> By permitting _this_ NAT to do endpoint-dependent mapping for TCP =
connections, the number of supported connections can be largely =
increased (if found useful).
> Agreed.


> IMHO, a NAT should be allowed to do endpoint-dependent mapping
> for protocols that are known not to cause issues (e.g. HTTP and DNS).

Agreed.

> I
> think this would address most scaling concerns people have with port
> ranges.

Note that, even without that, expressed concerns on this tread are in =
general excessive because this thread only concerns port sets used for =
residual IPv4 traffic where IPv6 has been deployed. Numbers of needed =
ports will quickly decrease.
=20
Also, one should not forget that assigning full IPv4 addresses to DSL =
customers who need it remains possible with  stateless solutions =
(presumably at a price, but we know there is no free lunch).

Cheers,=20
RD



> This was already discussed in the behave WG by the way...

>=20
> Simon
> --=20
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca



From despres.remi@laposte.net  Wed Aug  3 07:59:25 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B29B21F8B74 for ; Wed,  3 Aug 2011 07:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.585
X-Spam-Level: 
X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC30FxXKe3-m for ; Wed,  3 Aug 2011 07:59:24 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id 39EE721F8B50 for ; Wed,  3 Aug 2011 07:59:23 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 745407000090; Wed,  3 Aug 2011 16:59:29 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 237EE700008D; Wed,  3 Aug 2011 16:59:29 +0200 (CEST)
X-SFR-UUID: 20110803145929145.237EE700008D@msfrf2313.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-73--931080043
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Wed, 3 Aug 2011 16:59:28 +0200
Message-Id: 
References: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net> 
To: Qiong 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 14:59:25 -0000

--Apple-Mail-73--931080043
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 3 ao=FBt 2011 =E0 16:09, Qiong a =E9crit :

> Hi, Remi,
>=20
> This is just the question I would like to mention. Please see inline.=20=

>=20
> Several contributors have expressed, in the context of stateless =
solutions, wishes to add flexibility to static port set assignment.
>=20
> But, where "stateless" has to mean "no per-customer state", this wish =
is self-contradictory.
>=20
> Now:
> - Some ISP's want _direct CE-CE paths_ .

> [Qiong] : Agree. This is a good feature for stateless solution.

> But there might be no big differences from stateful solutions when =
deploying CGN on the edge of network, e.g. BRAS, etc.=20

Depending on various factors, he bottom-line cost may be slightly or =
highly different.
One size may not fit all.

> =20
> - For this each CE must know mapping rules for all other CE's.

> [Qiong]: Agree, especially when applying the co-existence scenario for =
exclusive-mode and shared mode. Given the fact the IPv4 prefixes are not =
continuous anymore, there might be up to hundreds/thousands of rules for =
a certain area.

Thousands of rules seems to me a lot.=20
(I keep doubts that, if CE's support statically shared addresses, =
keeping thousands of IPv4 prefixes would be needed to support IPv4 via =
IPv6.)
In any case, this can be among factors that differentiate which solution =
applies best to which network.

>=20
> Although I think that it would be not a big problem for stateless GW =
to handle these rules, I would still doubt the possibility that a =
customer-side CPE dealing with the same amount of IPv4 prefixes with =
network-side GW.=20

Adapting a CE to up to 1000 rules doesn't seem difficult to me, and with =
O(log n) matching this can be done with satisfactory performance.=20
(More details would be private consultancy ;-)).=20

> And another question, when should we announce these rules into CEs and =
BRs.

At the same time as other parameters (once in awhile to avoid lifetime =
expiry).

> Since in CE-CE situation, a source should always send a packet with =
the right destination port in the valid range of destinations. Is it has =
to been guaranteed by individual applications ? Or does it have some =
kind of limitations depending on applications ?

Applications that don't depend on well-known ports continue to do what =
they do behind NAT44's.
How applications get A+P addresses of peer applications is out of scope.

Hope it helps,

Regards,
RD



>=20
> Thanks.
>=20
> Best regards
>=20
> Qiong Sun
>=20
>=20
> - Mapping rules must therefore not depend on any per customer state.
> - This doesn't permit dynamic increase of CE-assigned port sets.
>=20
> If I missed something, please let me know.
> If not, agreement on this point could facilitate the ongoing =
discussion.
>=20
> Thanks,
> RD
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>=20


--Apple-Mail-73--931080043
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


Hi, =
Remi,

This is just the question I would like to =
mention. Please see inline. 



Several contributors have expressed, in the context of stateless =
solutions, wishes to add flexibility to static port set assignment.



But, where "stateless" has to mean "no per-customer state", this wish is =
self-contradictory.



Now:

- Some ISP's want _direct CE-CE paths_ =
.

[Qiong] : Agree. This =
is a good feature for stateless solution. =


But there might be no big differences from =
stateful solutions when deploying CGN on the edge of network, e.g. BRAS, =
etc. 

Depending&nbs=
p;on various factors, he bottom-line cost may be slightly or highly =
different.
One size may not fit all.




 

- For this each CE must know mapping rules for all other =
CE's.

[Qiong]: Agree, =
especially when applying the co-existence scenario for exclusive-mode =
and shared mode. Given the fact the IPv4 prefixes are not continuous =
anymore, there might be up to hundreds/thousands of rules for a =
certain =
area.

Thousands of =
rules seems to me a lot. 
(I keep doubts that, if =
CE's support statically shared addresses, keeping thousands of IPv4 =
prefixes would be needed to support IPv4 via IPv6.)
In any =
case, this can be among factors that differentiate which solution =
applies best to which network.


Although I think that it would =
be not a big problem for stateless GW to handle these rules, I would =
still doubt the possibility that a customer-side CPE dealing with the =
same amount of IPv4 prefixes with network-side =
GW. 

Adapting a =
CE to up to 1000 rules doesn't seem difficult to me, and with O(log n) =
matching this can be done with satisfactory =
performance. 
(More details would be private consultancy =
;-)). 




And another question, when should we announce these rules into =
CEs and BRs.

At the same =
time as other parameters (once in awhile to avoid lifetime =
expiry).

 Since in CE-CE situation, a source should =
always send a packet with the right destination port in the valid range =
of destinations. Is it has to been guaranteed by individual =
applications ? Or does it have some kind of limitations depending on =
applications =
?

Applications that =
don't depend on well-known ports continue to do what they do =
behind NAT44's.
How applications get A+P addresses of =
peer applications is out of scope.

Hope it =
helps,

Regards,
RD

=







Thanks.

Best =
regards

Qiong =
Sun




- Mapping rules must therefore not depend on any per customer state.

- This doesn't permit dynamic increase of CE-assigned port sets.



If I missed something, please let me know.

If not, agreement on this point could facilitate the ongoing =
discussion.



Thanks,

RD

_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires






=

--Apple-Mail-73--931080043--


From phdgang@gmail.com  Wed Aug  3 09:04:31 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27C21F8A95 for ; Wed,  3 Aug 2011 09:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.412
X-Spam-Level: 
X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np9amrrqR3Bi for ; Wed,  3 Aug 2011 09:04:31 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8421F88DD for ; Wed,  3 Aug 2011 09:04:30 -0700 (PDT)
Received: by vws12 with SMTP id 12so777779vws.31 for ; Wed, 03 Aug 2011 09:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DDewiGVW6vMolsO1wtPZWvzWOlMAdhbw4l3IywuarGg=; b=LoBthvceczJyafO7W30UwBMStuDkS7Kz7DFCI5Y/2bj6xFLd+Ohfovk/Fmw505pS7v +IW60ZAu/KYkPrQeHpg+6/DxS69S8+uJBqxSxOi6pXAqa/84gGLal5CJEDKVTR1gK0CN os7/VpSN6JEKFNpJtKBaENRYg6O48j69ZmWII=
MIME-Version: 1.0
Received: by 10.52.22.148 with SMTP id d20mr7008491vdf.453.1312387482899; Wed, 03 Aug 2011 09:04:42 -0700 (PDT)
Received: by 10.52.156.229 with HTTP; Wed, 3 Aug 2011 09:04:42 -0700 (PDT)
In-Reply-To: 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>   <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si>  <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca>  <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> <4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca> <7D5A55B5-0583-4518-A639-8BB26B1090F9@laposte.net> <4E395119.8020209@viagenie.ca> 
Date: Thu, 4 Aug 2011 00:04:42 +0800
Message-ID: 
From: GangChen 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 16:04:31 -0000

2011/8/3, R=E9mi Despr=E9s :
>
> Also, one should not forget that assigning full IPv4 addresses to DSL
> customers who need it remains possible with  stateless solutions (presuma=
bly
> at a price, but we know there is no free lunch).

In some sense, statelss solution could give such flexibilities to
DYNAMICALLY adjust how many ports are available to a sepecific CE.
Does this belong to static port behaviour or dynamic port behaviour?

BRs

Gang

From despres.remi@laposte.net  Wed Aug  3 09:42:28 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534CF21F8BC5 for ; Wed,  3 Aug 2011 09:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.882
X-Spam-Level: 
X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlzYJSdg6TrE for ; Wed,  3 Aug 2011 09:42:27 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 204E221F8BBE for ; Wed,  3 Aug 2011 09:42:27 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 8E9BB7000090; Wed,  3 Aug 2011 18:42:38 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 310E27000091; Wed,  3 Aug 2011 18:42:34 +0200 (CEST)
X-SFR-UUID: 20110803164234201.310E27000091@msfrf2208.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Wed, 3 Aug 2011 18:42:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>   <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si>  <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca>  <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> <4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca> <7D5A55B5-0583-4518-A639-8BB26B1090F9@laposte.net> <4E395119.8020209@viagenie.ca>  
To: GangChen 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 16:42:28 -0000

Le 3 ao=FBt 2011 =E0 18:04, GangChen a =E9crit :

> 2011/8/3, R=E9mi Despr=E9s :
>>=20
>> Also, one should not forget that assigning full IPv4 addresses to DSL
>> customers who need it remains possible with  stateless solutions =
(presumably
>> at a price, but we know there is no free lunch).
>=20
> In some sense, statelss solution could give such flexibilities to
> DYNAMICALLY adjust how many ports are available to a sepecific CE.
> Does this belong to static port behaviour or dynamic port behaviour?

If stateless means "without per customer state" in BR's, as it should by =
default in this discussion (IMHO), no dynamic changes of port-set sizes =
are practicable.

But this permits IMHO realistic stateless deployments: as  already said =
on this list, DSL ISP's can propose two tariffs: one for exclusive IPv4 =
addresses, and a lower one for shared IPv4 addresses with the same =
number of ports for each.

More flexible approaches are clearly possible, but the price paid for =
this flexibility is having to maintain per-customer states in BR's, and =
impossible direct CE-CE paths.

Regards,
RD





From tetsuya@ipinfusion.com  Wed Aug  3 13:43:58 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B93421F8564 for ; Wed,  3 Aug 2011 13:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHMA2eJXU6TL for ; Wed,  3 Aug 2011 13:43:58 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0FB521F8519 for ; Wed,  3 Aug 2011 13:43:57 -0700 (PDT)
Received: by iye7 with SMTP id 7so1521209iye.31 for ; Wed, 03 Aug 2011 13:44:10 -0700 (PDT)
Received: by 10.42.146.10 with SMTP id h10mr5477384icv.300.1312404250467; Wed, 03 Aug 2011 13:44:10 -0700 (PDT)
Received: from [10.70.2.140] ([12.248.239.142]) by mx.google.com with ESMTPS id bq3sm1117004icb.23.2011.08.03.13.44.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 13:44:09 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=utf-8
From: Tetsuya Murakami 
In-Reply-To: <4E3947B4.3050008@viagenie.ca>
Date: Wed, 3 Aug 2011 13:44:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <13EA4294-8326-4DCD-B732-6632472D7282@ipinfusion.com>
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1244.3)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 20:43:58 -0000

Hi Simon,

On 2011/08/03, at 6:05, Simon Perreault wrote:

> On 2011-08-03 04:01, R=C3=A9mi Despr=C3=A9s wrote:
>>=20
>> Le 3 ao=C3=BBt 2011 =C3=A0 00:39, Rajiv Asati (rajiva) a =C3=A9crit :
>>=20
>>> Satoru-san, =20
>>>=20
>>> This is an important point that most of us forget that restricting =
to
>>> "n" ports doesn't equate to just "n" NAT sessions rather many more =
than
>>> n sessions. We must add that to the 4v6 motivation draft as well as =
to
>>> the 4v6 comparison draft.
>>=20
>> +1
>=20
> I think there is an important point missing from this discussion. It =
is
> tricky but it has important practical consequences.
>=20
> As I said, "The 900G figure is valid, *as long as internal hosts reuse
> the same source address+port for different destinations*."
>=20
> The "as long as ..." part is important. I don't know of any operating
> system that behaves like that. That is, a different source port will =
be
> used for each new outbound session, regardless of the destination.
> Therefore, in practice, each session will require one NAT binding, =
which
> will in turn consume one external port.

=46rom the developer point of view, almost operating systems such as =
netbsd, Linux can support the above function.

At first, the NAT function in these operating systems has already =
supported to specify the port-range. In terms of the port number =
allocation in the NAT, if there are unused port number in a given =
port-range, then the NAT function allocates a new port number from the =
unused port numbers. But if there is no unused port number in a given =
port-range, then the NAT function tries to reuse a port number which is =
used for another NAT session with the different destination address.

Hence, as Satoru-san mentioned, the existed operating system such as =
netbsd, linux, has already reuse the same port number on multiple NAT =
session with the different destination.

> So the 900G figure is valid *in theory*, but *in practice* we're stuck
> with a number of sessions roughly equal to the number of external =
ports
> available on the NAT.

As I mentioned above, the number of NAT session can be greater than the =
available port number in practice because the NAT function in these =
operating systems has already supported to reuse a port number which is =
used for another NAT session with the different destination. So, the =
900G figure is valid today. In practice, there are another limitation =
from the memory size for keeping all NAT session and so the NAT function =
has a limitation of maximum number of NAT session. But this is totally =
regardless of the port-range functionality.

Thanks,
Tetsuya Murakami

> Now, if there is no NAT and the host itself is constrained to a given
> port range, the OS will usually start reusing source ports for =
different
> destinations when there is pressure to do so (i.e. when all source =
ports
> are in use). Where a NAT would simply drop the session-creating =
packet,
> in this case the OS is able to reuse a source port. So if there is no
> NAT, the 900G figure is also valid in practice.

From tetsuya@ipinfusion.com  Wed Aug  3 15:11:29 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DFD21F87D9 for ; Wed,  3 Aug 2011 15:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WxneSGeRmhc for ; Wed,  3 Aug 2011 15:11:28 -0700 (PDT)
Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id 83E7D21F87C3 for ; Wed,  3 Aug 2011 15:11:26 -0700 (PDT)
Received: by iyh42 with SMTP id 42so2226671iyh.39 for ; Wed, 03 Aug 2011 15:11:36 -0700 (PDT)
Received: by 10.42.147.8 with SMTP id l8mr5431740icv.496.1312409496244; Wed, 03 Aug 2011 15:11:36 -0700 (PDT)
Received: from [10.70.2.140] ([12.248.239.142]) by mx.google.com with ESMTPS id v16sm813242ibe.51.2011.08.03.15.11.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 15:11:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1DD157DC-BBD5-4B7A-9E7E-58EC701797A8"
From: Tetsuya Murakami 
In-Reply-To: 
Date: Wed, 3 Aug 2011 15:11:31 -0700
Message-Id: 
References: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net>  
To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires-wg 
Subject: Re: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 22:11:29 -0000

--Apple-Mail=_1DD157DC-BBD5-4B7A-9E7E-58EC701797A8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Remi, Qiong,

>> - For this each CE must know mapping rules for all other CE's.
>=20
>> [Qiong]: Agree, especially when applying the co-existence scenario =
for exclusive-mode and shared mode. Given the fact the IPv4 prefixes are =
not continuous anymore, there might be up to hundreds/thousands of rules =
for a certain area.
>=20
> Thousands of rules seems to me a lot.=20
> (I keep doubts that, if CE's support statically shared addresses, =
keeping thousands of IPv4 prefixes would be needed to support IPv4 via =
IPv6.)
> In any case, this can be among factors that differentiate which =
solution applies best to which network.
>=20
>>=20
>> Although I think that it would be not a big problem for stateless GW =
to handle these rules, I would still doubt the possibility that a =
customer-side CPE dealing with the same amount of IPv4 prefixes with =
network-side GW.=20
>=20
> Adapting a CE to up to 1000 rules doesn't seem difficult to me, and =
with O(log n) matching this can be done with satisfactory performance.=20=

> (More details would be private consultancy ;-)).=20

Thousands of rules sounds a lot to me as well. But I don't think it is =
difficult for CE to support such a number of rules. In fact, our =
implementation was tested under 10k rules in our lab.

Also, the rule consists of Domain IPv6 prefix/length, Domain IPv4 =
prefix/length, CE IPv6 prefix length and Domain IPv6 suffix/length. So, =
the total data size of these tuples is 40bytes roughly. So, if using =
1000 rules, the total data size is roughly 40kbytes. So, I don't think =
the big chunk of memory is not required for storing all of rules in CE.

Thanks,
Tetsuya Murakami=

--Apple-Mail=_1DD157DC-BBD5-4B7A-9E7E-58EC701797A8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Remi, Qiong,


- For this each CE must know mapping rules for all other =
CE's.

[Qiong]: Agree, =
especially when applying the co-existence scenario for exclusive-mode =
and shared mode. Given the fact the IPv4 prefixes are not continuous =
anymore, there might be up to hundreds/thousands of rules for a =
certain =
area.

Thousands of =
rules seems to me a lot. 
(I keep doubts that, if =
CE's support statically shared addresses, keeping thousands of IPv4 =
prefixes would be needed to support IPv4 via IPv6.)
In any =
case, this can be among factors that differentiate which solution =
applies best to which network.


Although I think that =
it would be not a big problem for stateless GW to handle these rules, I =
would still doubt the possibility that a customer-side CPE dealing with =
the same amount of IPv4 prefixes with network-side =
GW. 

Adapting a =
CE to up to 1000 rules doesn't seem difficult to me, and with O(log n) =
matching this can be done with satisfactory =
performance. 
(More details would be private consultancy =
;-)). 

Thousands =
of rules sounds a lot to me as well. But I don't think it is difficult =
for CE to support such a number of rules. In fact, our implementation =
was tested under 10k rules in our lab.

Also, =
the rule consists of Domain IPv6 prefix/length, Domain IPv4 =
prefix/length, CE IPv6 prefix length and Domain IPv6 suffix/length. So, =
the total data size of these tuples is 40bytes roughly. So, if using =
1000 rules, the total data size is roughly 40kbytes. So, I don't think =
the big chunk of memory is not required for storing all of rules in =
CE.

Thanks,
Tetsuya =
Murakami
=

--Apple-Mail=_1DD157DC-BBD5-4B7A-9E7E-58EC701797A8--

From jacni@jacni.com  Wed Aug  3 18:12:20 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3F21F87F0 for ; Wed,  3 Aug 2011 18:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.097,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13FCoqIsHdci for ; Wed,  3 Aug 2011 18:12:20 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id ED07121F8797 for ; Wed,  3 Aug 2011 18:12:19 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id C0E113801D0 for ; Wed,  3 Aug 2011 21:12:31 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id 7534F3400D6 for ; Thu,  4 Aug 2011 09:12:28 +0800 (CST)
Received: from [172.27.59.218] (unknown [112.64.191.174]) by app (Coremail) with SMTP id +AWowJALQwP38TlOy0dEAA--.29341S2; Thu, 04 Aug 2011 09:12:27 +0800 (CST)
Message-ID: <4E39F232.2070902@jacni.com>
Date: Thu, 04 Aug 2011 09:13:22 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= 
References: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070500030208030809090700"
X-CM-TRANSID: +AWowJALQwP38TlOy0dEAA--.29341S2
X-Coremail-Antispam: 1UD129KBjvdXoW7Gw1fWFyfGF18tr4DZr4ruFg_yoWDCrXEvw s7KFy7Gw17WryfK3WxtrWFgrWkC3yYv3WFqr1vqw1fA348tws3GrZ8WFWv9wn3uayUur15 uFs3Xr10qwsI9jkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUj18YjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6w4kM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_JFC_Wr1ln4vE4IxY62xKV4 CY8xCE548m6r4UJryUGwAa7VCY0VAaVVAqrcv_Jw1UWr13McIj6xIIjxv20xvE14v26r1j 6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F4 1lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFI7vE0wC2zVAF1VAY17CE 14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jTwZcUUUUU=
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEKEko7lM2sJAAAs4
Cc: Softwires-wg 
Subject: Re: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2011 01:12:20 -0000

This is a multi-part message in MIME format.
--------------070500030208030809090700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

hi,

On 8/3/2011 10:59 PM, Rémi Després wrote:
>
> ...
>
> Thousands of rules seems to me a lot.
> (I keep doubts that, if CE's support statically shared addresses, 
> keeping thousands of IPv4 prefixes would be needed to support IPv4 via 
> IPv6.)
> In any case, this can be among factors that differentiate which 
> solution applies best to which network.
>
>>
>> Although I think that it would be not a big problem for stateless GW 
>> to handle these rules, I would still doubt the possibility that a 
>> customer-side CPE dealing with the same amount of IPv4 prefixes with 
>> network-side GW.
>
> Adapting a CE to up to 1000 rules doesn't seem difficult to me, and 
> with O(log n) matching this can be done with satisfactory performance.
> (More details would be private consultancy ;-)).
>
In theory, the CE can be connected to multiple domains (1000?  with 
different rules), but in practice I guess that will not happen even in 
context of fragmented spaces where only the Access Gateway (ISP side) 
needs to maintain "1000.." rules of domains.


Cheers,
Jacni


--------------070500030208030809090700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    hi,

    

    On 8/3/2011 10:59 PM, Rémi Després wrote:
    


      
...
        


        

        
Thousands of rules seems to me a lot. 

        
(I keep doubts that, if CE's support statically shared
          addresses, keeping thousands of IPv4 prefixes would be needed
          to support IPv4 via IPv6.)

        
In any case, this can be among factors that differentiate
          which solution applies best to which network.

        


        

        

          

            

              


                

              
Although I think that it would be not a big problem
                for stateless GW to handle these rules, I would still
                doubt the possibility that a customer-side CPE dealing
                with the same amount of IPv4 prefixes with network-side
                GW. 

            

          

        

        


        

        
Adapting a CE to up to 1000 rules doesn't seem difficult to
          me, and with O(log n) matching this can be done with
          satisfactory performance. 

        
(More details would be private consultancy ;-)). 

        

      

    

    In theory, the CE can be connected to multiple domains (1000?  with
    different rules), but in practice I guess that will not happen even
    in context of fragmented spaces where only the Access Gateway (ISP
    side) needs to maintain "1000.." rules of domains.

    

    

    Cheers,

    Jacni

    

    

    

  


--------------070500030208030809090700--


From simon.perreault@viagenie.ca  Thu Aug  4 05:25:58 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3C721F8B21 for ; Thu,  4 Aug 2011 05:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CufNMy+HXSlE for ; Thu,  4 Aug 2011 05:25:58 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12721F8B17 for ; Thu,  4 Aug 2011 05:25:58 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4210521F49; Thu,  4 Aug 2011 08:26:12 -0400 (EDT)
Message-ID: <4E3A8FE3.5060703@viagenie.ca>
Date: Thu, 04 Aug 2011 08:26:11 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: Tetsuya Murakami 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca> <13EA4294-8326-4DCD-B732-6632472D7282@ipinfusion.com>
In-Reply-To: <13EA4294-8326-4DCD-B732-6632472D7282@ipinfusion.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2011 12:25:58 -0000

On 2011-08-03 16:44, Tetsuya Murakami wrote:
>> So the 900G figure is valid *in theory*, but *in practice* we're
>> stuck with a number of sessions roughly equal to the number of
>> external ports available on the NAT.
> 
> As I mentioned above, the number of NAT session can be greater than
> the available port number in practice because the NAT function in
> these operating systems has already supported to reuse a port number
> which is used for another NAT session with the different destination.

Yes, because these NATs are endpoint-dependent, which is forbidden by
the BEHAVE RFCs.

> So, the 900G figure is valid today. In practice, there are another
> limitation from the memory size for keeping all NAT session and so
> the NAT function has a limitation of maximum number of NAT session.
> But this is totally regardless of the port-range functionality.

Agreed.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From cb.list6@gmail.com  Thu Aug  4 08:01:43 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFA521F8B47 for ; Thu,  4 Aug 2011 08:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level: 
X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eW3Gfa2i7gC for ; Thu,  4 Aug 2011 08:01:42 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 115AC21F8B21 for ; Thu,  4 Aug 2011 08:01:41 -0700 (PDT)
Received: by wwg11 with SMTP id 11so4462580wwg.1 for ; Thu, 04 Aug 2011 08:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pJVMC2xAfJLr8lsgEGnzsJZPxHpPjzsOpqQfGWX9jgY=; b=gZo0/ErCcUQy1kxhjuiE+cABfVJEAIeyoGlM0WtQGFFZhc4J/TZimC3ktNiRk8BZu0 wYzoCEcANetzrFOJPpse3J4fdJZIJaDgjg4NmTiqwXRsP+IKY4+sMVugGF9IyAMPhqCS 7rs2xPH6Sy6Z5J/FTrkhVqCP03ORAFThTubHo=
MIME-Version: 1.0
Received: by 10.216.9.219 with SMTP id 69mr798282wet.72.1312470115229; Thu, 04 Aug 2011 08:01:55 -0700 (PDT)
Received: by 10.216.177.213 with HTTP; Thu, 4 Aug 2011 08:01:54 -0700 (PDT)
Received: by 10.216.177.213 with HTTP; Thu, 4 Aug 2011 08:01:54 -0700 (PDT)
In-Reply-To: <4E3A8FE3.5060703@viagenie.ca>
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>   <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si>  <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca>  <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> <4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca> <13EA4294-8326-4DCD-B732-6632472D7282@ipinfusion.com> <4E3A8FE3.5060703@viagenie.ca>
Date: Thu, 4 Aug 2011 08:01:54 -0700
Message-ID: 
From: Cameron Byrne 
To: Simon Perreault 
Content-Type: multipart/alternative; boundary=0016e64c25aeff21d204a9af4263
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2011 15:01:43 -0000

--0016e64c25aeff21d204a9af4263
Content-Type: text/plain; charset=ISO-8859-1

On Aug 4, 2011 5:26 AM, "Simon Perreault" 
wrote:
>
> On 2011-08-03 16:44, Tetsuya Murakami wrote:
> >> So the 900G figure is valid *in theory*, but *in practice* we're
> >> stuck with a number of sessions roughly equal to the number of
> >> external ports available on the NAT.
> >
> > As I mentioned above, the number of NAT session can be greater than
> > the available port number in practice because the NAT function in
> > these operating systems has already supported to reuse a port number
> > which is used for another NAT session with the different destination.
>
> Yes, because these NATs are endpoint-dependent, which is forbidden by
> the BEHAVE RFCs.
>

It is still very usefull and will be deployed regardless.

I understand you need to keep your documents consistent, but stretching
those ipv4 addresses further is a network and business reality of today's
big nat and future big nat.

Cb

> > So, the 900G figure is valid today. In practice, there are another
> > limitation from the memory size for keeping all NAT session and so
> > the NAT function has a limitation of maximum number of NAT session.
> > But this is totally regardless of the port-range functionality.
>
> Agreed.
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--0016e64c25aeff21d204a9af4263
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Aug 4, 2011 5:26 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:

>

> On 2011-08-03 16:44, Tetsuya Murakami wrote:

> >> So the 900G figure is valid *in theory*, but *in practice* we=
're

> >> stuck with a number of sessions roughly equal to the number o=
f

> >> external ports available on the NAT.

> >

> > As I mentioned above, the number of NAT session can be greater th=
an

> > the available port number in practice because the NAT function in=


> > these operating systems has already supported to reuse a port num=
ber

> > which is used for another NAT session with the different destinat=
ion.

>

> Yes, because these NATs are endpoint-dependent, which is forbidden by<=
br>
> the BEHAVE RFCs.

>


It is still very usefull and will be deployed regardless.


I understand you need to keep your documents consistent, but stretching =
those ipv4 addresses further is a network and business reality of today'=
;s big nat and future big nat.


Cb


> > So, the 900G figure is valid today. In practice, there are ano=
ther

> > limitation from the memory size for keeping all NAT session and s=
o

> > the NAT function has a limitation of maximum number of NAT sessio=
n.

> > But this is totally regardless of the port-range functionality.
>

> Agreed.

>

> Simon

> --

> DTN made easy, lean, and smart --> http://postellation.viagenie.ca

> NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca

> STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

> _______________________________________________

> Softwires mailing list

> Softwires@ietf.org

> https://ww=
w.ietf.org/mailman/listinfo/softwires




--0016e64c25aeff21d204a9af4263--

From simon.perreault@viagenie.ca  Thu Aug  4 08:04:17 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF55421F8B4B for ; Thu,  4 Aug 2011 08:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level: 
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRhEDqQmKiZf for ; Thu,  4 Aug 2011 08:04:17 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 38DEE21F8B3D for ; Thu,  4 Aug 2011 08:04:17 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ACC7D20D1D; Thu,  4 Aug 2011 11:04:31 -0400 (EDT)
Message-ID: <4E3AB4FF.7090906@viagenie.ca>
Date: Thu, 04 Aug 2011 11:04:31 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: Cameron Byrne 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>	<9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>			<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com>	<4E37FA9A.5070909@viagenie.ca>	<4E38019D.3090206@viagenie.ca>	<067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>		<4E3947B4.3050008@viagenie.ca>	<13EA4294-8326-4DCD-B732-6632472D7282@ipinfusion.com>	<4E3A8FE3.5060703@viagenie.ca> 
In-Reply-To: 
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2011 15:04:17 -0000

On 2011-08-04 11:01, Cameron Byrne wrote:
>> Yes, because these NATs are endpoint-dependent, which is forbidden by
>> the BEHAVE RFCs.
> 
> It is still very usefull and will be deployed regardless.

Right. But the IETF needs consistency in the advice it provides.

> I understand you need to keep your documents consistent, but stretching
> those ipv4 addresses further is a network and business reality of
> today's big nat and future big nat.

That's why there's a proposal floating around (no draft) that NATs MAY
apply endpoint-dependent mapping to protocols that are known to not
cause problems (e.g. HTTP and DNS).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From tetsuya@ipinfusion.com  Thu Aug  4 12:37:39 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32D21F863A for ; Thu,  4 Aug 2011 12:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level: 
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk7HC8bEzUW4 for ; Thu,  4 Aug 2011 12:37:38 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B974F21F85CA for ; Thu,  4 Aug 2011 12:37:38 -0700 (PDT)
Received: by gyd5 with SMTP id 5so1472795gyd.31 for ; Thu, 04 Aug 2011 12:37:52 -0700 (PDT)
Received: by 10.143.67.19 with SMTP id u19mr1154960wfk.158.1312486671982; Thu, 04 Aug 2011 12:37:51 -0700 (PDT)
Received: from [10.70.2.140] ([12.248.239.142]) by mx.google.com with ESMTPS id v2sm2539235pbi.51.2011.08.04.12.37.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 12:37:49 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Tetsuya Murakami 
In-Reply-To: <4E3A8FE3.5060703@viagenie.ca>
Date: Thu, 4 Aug 2011 12:37:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <4E3947B4.3050008@viagenie.ca> <13EA4294-8326-4DCD-B732-6632472D7282@ipinfusion.com> <4E3A8FE3.5060703@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1244.3)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2011 19:37:39 -0000

Hi Simon,

On 2011/08/04, at 5:26, Simon Perreault wrote:

> On 2011-08-03 16:44, Tetsuya Murakami wrote:
>>> So the 900G figure is valid *in theory*, but *in practice* we're
>>> stuck with a number of sessions roughly equal to the number of
>>> external ports available on the NAT.
>>=20
>> As I mentioned above, the number of NAT session can be greater than
>> the available port number in practice because the NAT function in
>> these operating systems has already supported to reuse a port number
>> which is used for another NAT session with the different destination.
>=20
> Yes, because these NATs are endpoint-dependent, which is forbidden by
> the BEHAVE RFCs.

If using endpoint-independent mapping, one NAT session can cover =
multiple destinations. For instance,

Internal : External : Destination
X:x -> E:e -> n/a:n/a

So, if a CPE has a limited set of the port number, the CPE can provide =
the access to many destination with one NAT session.

If using endpoint-dependent mapping, the same port number can be reused =
if the destination address is same. For instance,

Internal : External : Destination
X:x -> E:e1 -> Y1:n/a
X:x -> E:e2 -> Y2:n/a

In this case, since the destination is different, 2 NAT sessions can be =
created.

In terms of NAT implementation on the existed operating systems, the =
endpoint-independent mapping is not supported. In fact, we added the =
endpoint-independent mapping function in the existed operating system =
such as linux, netbsd, For instance, netbsd creates the following NAT =
sessions.

Internal : External : Destination
X:x -> E:e1 -> Y1:y1
X:x -> E:e2 -> Y1:y2
X:x -> E:e3 -> Y2:y3

If there are unused port number in its port-range, the NAT function =
allocates a new port number for each NAT session like the above. But if =
there is no unused port number, the NAT function tries to reuse a same =
port number which is used for another NAT session with the different =
destination address like X:x -> E:e1 -> Y4:y4. Hence, from the current =
implementation point of view, if a CPE has a limited set of the port =
number, the existed NAT function can provide the access to many =
destinations.

Thanks,
Tetsuya Murakami

>> So, the 900G figure is valid today. In practice, there are another
>> limitation from the memory size for keeping all NAT session and so
>> the NAT function has a limitation of maximum number of NAT session.
>> But this is totally regardless of the port-range functionality.
>=20
> Agreed.
>=20
> Simon
> --=20
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca


From rpenno@juniper.net  Thu Aug  4 13:00:29 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3B21F8B0A for ; Thu,  4 Aug 2011 13:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.473
X-Spam-Level: 
X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxdY3ypQ9NVQ for ; Thu,  4 Aug 2011 13:00:29 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id B61F75E8010 for ; Thu,  4 Aug 2011 13:00:26 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTjr6ajaogwrVTUJJGmkdgpOLhUFHl2Xm@postini.com; Thu, 04 Aug 2011 13:00:44 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 4 Aug 2011 12:58:59 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 4 Aug 2011 15:58:58 -0400
From: Reinaldo Penno 
To: Simon Perreault , Cameron Byrne 
Date: Thu, 4 Aug 2011 15:58:56 -0400
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxSt9Umqfbeayt6Rga4nf/mwQN2BQAKRwTi
Message-ID: 
In-Reply-To: <4E3AB4FF.7090906@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.9.0.110114
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2011 20:00:29 -0000

On 8/4/11 8:04 AM, "Simon Perreault"  wrote:

> On 2011-08-04 11:01, Cameron Byrne wrote:
>>> Yes, because these NATs are endpoint-dependent, which is forbidden by
>>> the BEHAVE RFCs.
>>=20
>> It is still very usefull and will be deployed regardless.
>=20
> Right. But the IETF needs consistency in the advice it provides.
>=20
>> I understand you need to keep your documents consistent, but stretching
>> those ipv4 addresses further is a network and business reality of
>> today's big nat and future big nat.
>=20
> That's why there's a proposal floating around (no draft) that NATs MAY
> apply endpoint-dependent mapping to protocols that are known to not
> cause problems (e.g. HTTP and DNS).

This was discussed in BEHAVE many times. There is a subtle, but yet
important, difference between 'recommending EIM behavior' and having it 'on=
'
all the time. The current RFCs do not really dwell into that space.

Simon and I will be updating the bis draft to clarify (amongst other new
things) this issue.

https://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-00


>=20
> Simon


From bingxuere@gmail.com  Thu Aug  4 18:40:53 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C622821F8AEE for ; Thu,  4 Aug 2011 18:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.085
X-Spam-Level: 
X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svBSDzB1bkMv for ; Thu,  4 Aug 2011 18:40:53 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCAF21F8AED for ; Thu,  4 Aug 2011 18:40:53 -0700 (PDT)
Received: by pzk33 with SMTP id 33so7062922pzk.18 for ; Thu, 04 Aug 2011 18:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Y1TWb2Tu6hcIDjVEBk+AcvMiWW5HxyK16igPTFztcqY=; b=KZRQJe3LW99TeoHtT2xImwx8dQkAG1P5PWWZobfABqxfsPWXs2q6L16dBIS9gSmejM 9pspr//URJPC5NFYOatuyBkn6NeAPc5oXBXaAyy1kcWguaDIGi5oI8OmxHgdv8iXY347 SbaNujBrFl4cjWn35wACZczsHlg93ydpm9LoA=
Received: by 10.142.47.2 with SMTP id u2mr1491398wfu.80.1312508469045; Thu, 04 Aug 2011 18:41:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.54.138 with HTTP; Thu, 4 Aug 2011 18:40:49 -0700 (PDT)
In-Reply-To: 
References: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net>  
From: Qiong 
Date: Fri, 5 Aug 2011 09:40:49 +0800
Message-ID: 
To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= ,  tetsuya@ipinfusion.com
Content-Type: multipart/alternative; boundary=000e0cd17e4c0feab704a9b831fb
Cc: Softwires-wg 
Subject: Re: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2011 01:40:53 -0000

--000e0cd17e4c0feab704a9b831fb
Content-Type: text/plain; charset=UTF-8

Hi  Remi, Tetsuya,

Thank you for your reply. Please see inline.

Thousands of rules seems to me a lot.
> (I keep doubts that, if CE's support statically shared addresses,
> keeping thousands of IPv4 prefixes would be needed to support IPv4 via
> IPv6.)
> In any case, this can be among factors that differentiate which solution
> applies best to which network.
>
> [Qiong]: Agree.

>
> Adapting a CE to up to 1000 rules doesn't seem difficult to me, and with
> O(log n) matching this can be done with satisfactory performance.
> (More details would be private consultancy ;-)).
>

    [Tetsuya] Thousands of rules sounds a lot to me as well. But I don't
think it is difficult for CE to support such a    number of rules. In fact,
our implementation was tested under 10k rules in our lab.

    [Tetsuya] Also, the rule consists of Domain IPv6 prefix/length, Domain
IPv4 prefix/length, CE IPv6 prefix length and Domain IPv6 suffix/length. So,
the total data size of these tuples is 40bytes roughly. So, if using 1000
rules, the total data size is roughly 40kbytes. So, I don't think the big
chunk of memory is not required for storing all of rules in CE.


[Qiong]: I can fully understand that rule matching algorithm would not be
difficult to handle 1000 rules. But we should still keep in mind
that traditional CPEs are usually embedded systems with restricted
resources. The amount of NAT sessions it can handle is approximately about
2000~3000. When we add another 1000 rules to do prefix matching in CPE, I
think it would still cost more than before.

BTW, what's the output performance of your algorithm apart from memory
occupation and what's the configuration of your platform in your test ?


At the same time as other parameters (once in awhile to avoid lifetime
> expiry).
>
> [Qiong]: I think in this case, we would need another specification to
distribute this rules automatically.


Thanks

Best wishes

Qiong Sun

--000e0cd17e4c0feab704a9b831fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi =C2=A0Remi,=C2=A0Tetsuya,

Thank you for your reply. Please see inline.



Thousands of rules seems to me a lot.=C2=A0
(I keep doubts that,=C2=A0if CE's support statically shared addre=
sses, keeping=C2=A0thousands of IPv4 prefixes would be needed to support IP=
v4 via IPv6.)



In any case, this can be among factors that differentiate which soluti=
on applies best to which network.

[Qiong]: Agree.=C2=A0




<=
/div>
Adapting a CE to up to 1000 rules doesn't seem difficult to m=
e, and with O(log n) matching this can be done with satisfactory performanc=
e.=C2=A0



(More details would be private consultancy ;-)).=C2=A0



=C2=A0 =C2=A0 [Tetsuya] Thousands of rules sounds a lot to me as well. But =
I don't think it is difficult for CE to support such a =C2=A0 =C2=A0num=
ber of rules. In fact, our implementation was tested under 10k rules in our=
 lab.



=C2=A0 =C2=A0=
 [Tetsuya]=C2=A0=
Also, the rule consists of Dom=
ain IPv6 prefix/length, Domain IPv4 prefix/length, CE IPv6 prefix length an=
d Domain IPv6 suffix/length. So, the total data size of these tuples is 40b=
ytes roughly. So, if using 1000 rules, the total data size is roughly 40kby=
tes. So, I don't think the big chunk of memory is not required for stor=
ing all of rules in CE.=





[Qiong]:=C2=A0I can fully unders=
tand that rule matching=C2=A0algorithm would not be difficult to handle 100=
0 rules. But we should still keep in mind that=C2=A0traditional=C2=A0CPEs a=
re usually embedded systems with restricted resources. The amount of NAT se=
ssions it can handle is approximately about 2000~3000. When we add another =
1000 rules to do prefix matching in CPE, I think it would still cost more t=
han before. =C2=A0




BTW, what's the output performance of your algorith=
m apart from memory occupation and what's the=C2=A0configuration of you=
r platform in your test ?=C2=A0





At the same=
 time as other parameters (once in awhile to avoid lifetime expiry).
<=
/div>

[=
Qiong]: I think in this case, we would need another specification to distri=
bute this rules automatically.=C2=A0





Thanks

Best wis=
hes

Qiong Sun=C2=A0



--000e0cd17e4c0feab704a9b831fb--

From tetsuya@ipinfusion.com  Thu Aug  4 23:11:26 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980465E8005 for ; Thu,  4 Aug 2011 23:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJowczj39UHc for ; Thu,  4 Aug 2011 23:11:25 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id A44EE21F8ADC for ; Thu,  4 Aug 2011 23:11:25 -0700 (PDT)
Received: by iye1 with SMTP id 1so2696395iye.27 for ; Thu, 04 Aug 2011 23:11:42 -0700 (PDT)
Received: by 10.42.244.3 with SMTP id lo3mr626780icb.335.1312524702209; Thu, 04 Aug 2011 23:11:42 -0700 (PDT)
Received: from [192.168.0.6] (c-76-102-170-116.hsd1.ca.comcast.net [76.102.170.116]) by mx.google.com with ESMTPS id d8sm3646520icy.21.2011.08.04.23.11.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 23:11:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_45D05785-C735-4459-913A-9A66D19A090C"
From: Tetsuya Murakami 
In-Reply-To: 
Date: Thu, 4 Aug 2011 23:11:39 -0700
Message-Id: 
References: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net>   
To: Qiong 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires-wg 
Subject: Re: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2011 06:11:26 -0000

--Apple-Mail=_45D05785-C735-4459-913A-9A66D19A090C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Qiong,

On 2011/08/04, at 18:40, Qiong wrote:

> Hi  Remi, Tetsuya,
>=20
> Thank you for your reply. Please see inline.
>=20
> Thousands of rules seems to me a lot.=20
> (I keep doubts that, if CE's support statically shared addresses, =
keeping thousands of IPv4 prefixes would be needed to support IPv4 via =
IPv6.)
> In any case, this can be among factors that differentiate which =
solution applies best to which network.
>=20
> [Qiong]: Agree.=20
>=20
> Adapting a CE to up to 1000 rules doesn't seem difficult to me, and =
with O(log n) matching this can be done with satisfactory performance.=20=

> (More details would be private consultancy ;-)).=20
>=20
>     [Tetsuya] Thousands of rules sounds a lot to me as well. But I =
don't think it is difficult for CE to support such a    number of rules. =
In fact, our implementation was tested under 10k rules in our lab.
>=20
>     [Tetsuya] Also, the rule consists of Domain IPv6 prefix/length, =
Domain IPv4 prefix/length, CE IPv6 prefix length and Domain IPv6 =
suffix/length. So, the total data size of these tuples is 40bytes =
roughly. So, if using 1000 rules, the total data size is roughly =
40kbytes. So, I don't think the big chunk of memory is not required for =
storing all of rules in CE.
>=20
>=20
> [Qiong]: I can fully understand that rule matching algorithm would not =
be difficult to handle 1000 rules. But we should still keep in mind that =
traditional CPEs are usually embedded systems with restricted resources. =
The amount of NAT sessions it can handle is approximately about =
2000~3000. When we add another 1000 rules to do prefix matching in CPE, =
I think it would still cost more than before. =20

Agreed. Some of traditional CPEs might not be able to handle a bunch of =
NAT sessions due to the resource limitation such as memory, cpu, etc. =
=46rom the implementation point of view, I think the required resources =
for 4rd mapping rule is smaller than the resources for NAT session =
because usually NAT session contains many information.

> BTW, what's the output performance of your algorithm apart from memory =
occupation and what's the configuration of your platform in your test ?=20=


Did you asked about the forwarding performance? We used netbsd running =
on arm core cpu (400MHz). The accrual ratio of the latency is just 2 to =
5 % under 4rd environment.

Thanks,
Tetsuya Murakami

> At the same time as other parameters (once in awhile to avoid lifetime =
expiry).
>=20
> [Qiong]: I think in this case, we would need another specification to =
distribute this rules automatically.=20
>=20
>=20
> Thanks
>=20
> Best wishes
>=20
> Qiong Sun=20
>=20


--Apple-Mail=_45D05785-C735-4459-913A-9A66D19A090C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Qiong,

On 2011/08/04, at 18:40, Qiong wrote:

Hi =
 Remi, Tetsuya,

Thank you for your reply. =
Please see inline.




Thousands of rules seems to me a =
lot. 
(I keep doubts that, if CE's support =
statically shared addresses, keeping thousands of IPv4 prefixes =
would be needed to support IPv4 via IPv6.)



In any case, this can be among factors that differentiate which =
solution applies best to which network.

[Qiong]: =
Agree. 




Adapting a CE to up to 1000 rules =
doesn't seem difficult to me, and with O(log n) matching this can be =
done with satisfactory performance. 



(More details would be private consultancy =
;-)). 



    [Tetsuya] Thousands of rules sounds a lot to me as well. =
But I don't think it is difficult for CE to support such a   =
 number of rules. In fact, our implementation was tested under 10k =
rules in our lab.



    [Tetsuya] Also, the rule =
consists of Domain IPv6 prefix/length, Domain IPv4 prefix/length, CE =
IPv6 prefix length and Domain IPv6 suffix/length. So, the total data =
size of these tuples is 40bytes roughly. So, if using 1000 rules, the =
total data size is roughly 40kbytes. So, I don't think the big chunk of =
memory is not required for storing all of rules in CE.




[Qiong]: I can fully =
understand that rule matching algorithm would not be difficult to =
handle 1000 rules. But we should still keep in mind =
that traditional CPEs are usually embedded systems with =
restricted resources. The amount of NAT sessions it can handle is =
approximately about 2000~3000. When we add another 1000 rules to do =
prefix matching in CPE, I think it would still cost more than before. =
 

Agreed. Some of =
traditional CPEs might not be able to handle a bunch of NAT sessions due =
to the resource limitation such as memory, cpu, etc. =46rom the =
implementation point of view, I think the required resources for 4rd =
mapping rule is smaller than the resources for NAT session because =
usually NAT session contains many information.

BTW, what's the =
output performance of your algorithm apart from memory occupation and =
what's the configuration of your platform in your test =
? 

Did you asked =
about the forwarding performance? We used netbsd running on arm core cpu =
(400MHz). The accrual ratio of the latency is just 2 to 5 % under 4rd =
environment.

Thanks,
Tetsuya =
Murakami




At the =
same time as other parameters (once in awhile to avoid lifetime =
expiry).

[Qiong]: I think in =
this case, we would need another specification to distribute this rules =
automatically. 





Thanks

Best =
wishes

Qiong Sun 




=

--Apple-Mail=_45D05785-C735-4459-913A-9A66D19A090C--

From adurand@juniper.net  Fri Aug  5 12:43:04 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CEA21F85AA for ; Fri,  5 Aug 2011 12:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.412
X-Spam-Level: 
X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxKx60QRFR1q for ; Fri,  5 Aug 2011 12:43:04 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id BD57C21F85A4 for ; Fri,  5 Aug 2011 12:42:59 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTjxH1UXuhVZCl6Fjib/46FUkxbVdzp+W@postini.com; Fri, 05 Aug 2011 12:43:22 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 5 Aug 2011 12:38:39 -0700
From: Alain Durand 
To: "softwires@ietf.org list" 
Date: Fri, 5 Aug 2011 12:38:38 -0700
Thread-Topic: Softwire Interim meeting
Thread-Index: AcxTp0ZVYR6ejQvsR0C+Sm+rXiq+hA==
Message-ID: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ralph Droms 
Subject: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2011 19:43:04 -0000

Following-up on the Quebec meeting, we would like to organize an interim me=
eting end of September.
We will focus on so-called stateless solutions and other remaining business=
 in the wg (multicast. mibs,...)
that require more time than we usually have during a normal IETF meeting.
The format will be a 2 day intensive meeting, with white board discussions,=
 similar to what we did in the early days of the working group.

We've got an offer to host the meeting in Beijin on Sept. 26-27th or 27-28t=
h (right after the Boradband forum meeting in Shanghai).
Yong and I would like to make a decision soon, please send us email directl=
y if you intend to come and tell us which set of dates is more convenient.
Please respond by August 11th, we will formally announce the meeting with t=
he logistic information end of next week.

Alain & Yong.




From mark@townsley.net  Fri Aug  5 12:57:10 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5B11E8070 for ; Fri,  5 Aug 2011 12:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDaV5XWtijqR for ; Fri,  5 Aug 2011 12:57:10 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1AE5E8005 for ; Fri,  5 Aug 2011 12:57:10 -0700 (PDT)
Received: by vxi40 with SMTP id 40so3074217vxi.31 for ; Fri, 05 Aug 2011 12:57:27 -0700 (PDT)
Received: by 10.52.24.2 with SMTP id q2mr2840026vdf.147.1312574247452; Fri, 05 Aug 2011 12:57:27 -0700 (PDT)
Received: from [192.168.1.137] (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id u4sm1603442vdh.13.2011.08.05.12.57.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 12:57:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
Date: Fri, 5 Aug 2011 14:57:24 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
To: Alain Durand 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org list" , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2011 19:57:10 -0000

On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:

> Following-up on the Quebec meeting, we would like to organize an =
interim meeting end of September.
> We will focus on so-called stateless solutions and other remaining =
business in the wg (multicast. mibs,...)
> that require more time than we usually have during a normal IETF =
meeting.
> The format will be a 2 day intensive meeting, with white board =
discussions, similar to what we did in the early days of the working =
group.
>=20
> We've got an offer to host the meeting in Beijin on Sept. 26-27th or =
27-28th (right after the Boradband forum meeting in Shanghai).

Would it be possible to keep it in the same city as the BBF to cut down =
travel/costs a bit more for those going to both?

- Mark

> Yong and I would like to make a decision soon, please send us email =
directly if you intend to come and tell us which set of dates is more =
convenient.
> Please respond by August 11th, we will formally announce the meeting =
with the logistic information end of next week.
>=20
> Alain & Yong.
>=20
>=20
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From bingxuere@gmail.com  Fri Aug  5 22:51:43 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA88811E807B for ; Fri,  5 Aug 2011 22:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.516
X-Spam-Level: 
X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8kB4oDfRPSQ for ; Fri,  5 Aug 2011 22:51:43 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6750711E8070 for ; Fri,  5 Aug 2011 22:51:43 -0700 (PDT)
Received: by iye1 with SMTP id 1so4581765iye.27 for ; Fri, 05 Aug 2011 22:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eZ5rDLDKJCruKbSglkxyX8ggLHQqvytOH6Rx9ZL4wbs=; b=cC/KlleqyplH0gogi0Bf63t0NCXTZ5AV5AX1SJuk/X3hqzi9IzIH3Z45faHa/jfdv5 V+Yh7B51X5m+KqRsiv+/XQZXH2xARAzv+HX507/UL+WV4oAirtEEqYYbDle/xPfeFN8C ytSMyZ0eQ1IhJwd7RRDmUlD6HfGE+uNdtyVhY=
Received: by 10.42.150.132 with SMTP id a4mr2957595icw.291.1312609922231; Fri, 05 Aug 2011 22:52:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.253.77 with HTTP; Fri, 5 Aug 2011 22:51:42 -0700 (PDT)
In-Reply-To: 
References: <8EDB9B95-ACDA-4D12-95C2-3DD03EA1E4B8@laposte.net>    
From: Qiong 
Date: Sat, 6 Aug 2011 13:51:42 +0800
Message-ID: 
To: Tetsuya Murakami 
Content-Type: multipart/alternative; boundary=90e6ba21237324ad4004a9cfd073
Cc: Softwires-wg 
Subject: Re: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 Aug 2011 05:51:44 -0000

--90e6ba21237324ad4004a9cfd073
Content-Type: text/plain; charset=UTF-8

Hi Tetsuya,

Thank you very much to provide your test results.  Please see inline.

Agreed. Some of traditional CPEs might not be able to handle a bunch of NAT
> sessions due to the resource limitation such as memory, cpu, etc. From the
> implementation point of view, I think the required resources for 4rd mapping
> rule is smaller than the resources for NAT session because usually NAT
> session contains many information.
>
> [Qiong]: Basically agree that '4rd mapping rule is smaller than the
resources for NAT session', but 4rd CEs would still do NAPT similar to
traditional CPE's NAPT (with restricted port range), right ?



> Did you asked about the forwarding performance? We used netbsd running on
> arm core cpu (400MHz). The accrual ratio of the latency is just 2 to 5 %
> under 4rd environment.
>

[Qiong]: Well, this latency is acceptable to me.

>
>
Thanks

Qiong Sun

--90e6ba21237324ad4004a9cfd073
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi=C2=A0Tetsuya,

Thank you very much to provide your tes=
t results. =C2=A0Please see inline.




Agreed. Some of tra=
ditional CPEs might not be able to handle a bunch of NAT sessions due to th=
e resource limitation such as memory, cpu, etc. From the implementation poi=
nt of view, I think the required resources for 4rd mapping rule is smaller =
than the resources for NAT session because usually NAT session contains man=
y information.






[Qiong]: Basically agree=
 that '4rd mapping rule is smaller than the resources for NAT session&#=
39;, but 4rd CEs would still do NAPT similar to traditional CPE's NAPT =
(with restricted=C2=A0port range), right ? =C2=A0




=C2=A0
Did you aske=
d about the forwarding performance? We used netbsd running on arm core cpu =
(400MHz). The accrual ratio of the latency is just 2 to 5 % under 4rd envir=
onment.




[Qiong]: Well, this late=
ncy is acceptable to me.=C2=A0



=C2=A0
Thanks
=


Qiong Sun=C2=A0




--90e6ba21237324ad4004a9cfd073--

From yiu_lee@cable.comcast.com  Sun Aug  7 15:51:01 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4828E21F8880 for ; Sun,  7 Aug 2011 15:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.754
X-Spam-Level: 
X-Spam-Status: No, score=-105.754 tagged_above=-999 required=5 tests=[AWL=2.709, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfoazP-fJWa2 for ; Sun,  7 Aug 2011 15:51:00 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0321F887C for ; Sun,  7 Aug 2011 15:51:00 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136475633; Sun, 07 Aug 2011 18:51:19 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Sun, 7 Aug 2011 18:51:19 -0400
From: "Lee, Yiu" 
To: Mark Townsley , Alain Durand 
Thread-Topic: [Softwires] Softwire Interim meeting
Thread-Index: AQHMVVSE63bVN84rN0qy8gSE5GHezw==
Date: Sun, 7 Aug 2011 22:51:17 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [147.191.125.11]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "softwires@ietf.org list" , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 07 Aug 2011 22:51:01 -0000

I am speaking for myself. It will be tough for me to go to China in Sept
and Taiwan in Nov.=20

On 8/5/11 3:57 PM, "Mark Townsley"  wrote:

>
>On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:
>
>> Following-up on the Quebec meeting, we would like to organize an
>>interim meeting end of September.
>> We will focus on so-called stateless solutions and other remaining
>>business in the wg (multicast. mibs,...)
>> that require more time than we usually have during a normal IETF
>>meeting.
>> The format will be a 2 day intensive meeting, with white board
>>discussions, similar to what we did in the early days of the working
>>group.
>>=20
>> We've got an offer to host the meeting in Beijin on Sept. 26-27th or
>>27-28th (right after the Boradband forum meeting in Shanghai).
>
>Would it be possible to keep it in the same city as the BBF to cut down
>travel/costs a bit more for those going to both?
>
>- Mark
>
>> Yong and I would like to make a decision soon, please send us email
>>directly if you intend to come and tell us which set of dates is more
>>convenient.
>> Please respond by August 11th, we will formally announce the meeting
>>with the logistic information end of next week.
>>=20
>> Alain & Yong.
>>=20
>>=20
>>=20
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


From jiangsheng@huawei.com  Sun Aug  7 18:18:02 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD17F21F86DE for ; Sun,  7 Aug 2011 18:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.995
X-Spam-Level: 
X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3yd-9R1qjcg for ; Sun,  7 Aug 2011 18:18:02 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id F131721F86D7 for ; Sun,  7 Aug 2011 18:18:01 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL00JK84YNY5@szxga05-in.huawei.com> for softwires@ietf.org; Mon, 08 Aug 2011 09:18:24 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL000XV4YICX@szxga05-in.huawei.com> for softwires@ietf.org; Mon, 08 Aug 2011 09:18:23 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADB20600; Mon, 08 Aug 2011 09:18:22 +0800 (CST)
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 08 Aug 2011 09:18:21 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Mon, 08 Aug 2011 09:18:23 +0800
Date: Mon, 08 Aug 2011 01:18:21 +0000
From: Jiangsheng 
In-reply-to: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
X-Originating-IP: [10.110.98.152]
To: Alain Durand , "softwires@ietf.org list" 
Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012281F4@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: Softwire Interim meeting
Thread-index: AcxTp0ZVYR6ejQvsR0C+Sm+rXiq+hABwQkOQ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
Cc: Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 01:18:02 -0000

The best would be the week before BBF in Beijing, say Sep 18, 19. I would like to inform everyone that the week starting from Oct 1st is the golden holiday week in China, and hundred million people will travel the weeks before and after. So the wisest is to avoid the crowd peak. :)

Sheng

> -----Original Message-----
> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
> Behalf Of Alain Durand
> Sent: Saturday, August 06, 2011 3:39 AM
> To: softwires@ietf.org list
> Cc: Ralph Droms
> Subject: [Softwires] Softwire Interim meeting
> 
> Following-up on the Quebec meeting, we would like to organize an
> interim meeting end of September.
> We will focus on so-called stateless solutions and other remaining
> business in the wg (multicast. mibs,...)
> that require more time than we usually have during a normal IETF
> meeting.
> The format will be a 2 day intensive meeting, with white board
> discussions, similar to what we did in the early days of the working
> group.
> 
> We've got an offer to host the meeting in Beijin on Sept. 26-27th or
> 27-28th (right after the Boradband forum meeting in Shanghai).
> Yong and I would like to make a decision soon, please send us email
> directly if you intend to come and tell us which set of dates is more
> convenient.
> Please respond by August 11th, we will formally announce the meeting
> with the logistic information end of next week.
> 
> Alain & Yong.
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From jacni@jacni.com  Sun Aug  7 18:26:35 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4F221F84FE for ; Sun,  7 Aug 2011 18:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.754
X-Spam-Level: 
X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.534,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r55kQZTWoASt for ; Sun,  7 Aug 2011 18:26:34 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id BFDF021F84CF for ; Sun,  7 Aug 2011 18:26:34 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 13AF53800CF for ; Sun,  7 Aug 2011 21:26:58 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id 7C646340160 for ; Mon,  8 Aug 2011 09:26:54 +0800 (CST)
Received: from [172.18.99.154] (unknown [112.64.190.38]) by app (Coremail) with SMTP id +AWowJA7gwZWOz9OSNtHAA--.41965S2; Mon, 08 Aug 2011 09:26:53 +0800 (CST)
Message-ID: <4E3F3B91.6050607@jacni.com>
Date: Mon, 08 Aug 2011 09:27:45 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Jiangsheng 
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net> <5D36713D8A4E7348A7E10DF7437A4B92012281F4@SZXEML506-MBS.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92012281F4@SZXEML506-MBS.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-CM-TRANSID: +AWowJA7gwZWOz9OSNtHAA--.41965S2
X-Coremail-Antispam: 1UD129KBjvJXoW7tF45JF4DCF4kJw45Gr1Dtrb_yoW8Zr4Upr WrJ3WDGFn8tr1xC348CF1UCFyv9rWrJrW7Jw15Jr1YkFy5JF1xta1vg3y5W34DCrs5JF18 tr1Uuw17Xa98XFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU4qb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6r1S6rWUM2kK67kvxFCE54 8m6r1fGryUXwAawVACjsI_Ar4v6c8GOVW06r1DJrWUAwAawVCIc40E5I027xCE548m6r1D Jr4UtwAa7VCY0VAaVVAqrcv_Jw1UWr13Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY 0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFI7vE0wC2zVAF1VAY17CE14v26r126r 1DMIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jcPEfUUUUU=
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAOEko7lM8gRQAAsS
Cc: "softwires@ietf.org list" , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 01:26:35 -0000

Re-,

On 8/8/2011 9:18 AM, Jiangsheng wrote:
> The best would be the week before BBF in Beijing, say Sep 18, 19. I would like to inform everyone that the week starting from Oct 1st is the golden holiday week in China, and hundred million people will travel the weeks before and after. So the wisest is to avoid the crowd peak. :)
>
> Sheng
Exactly, no matter in Beijing or Shanghai (BBF), before BBF will be much 
easier than after.


Cheers,
Jacni

>
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
>> Behalf Of Alain Durand
>> Sent: Saturday, August 06, 2011 3:39 AM
>> To: softwires@ietf.org list
>> Cc: Ralph Droms
>> Subject: [Softwires] Softwire Interim meeting
>>
>> Following-up on the Quebec meeting, we would like to organize an
>> interim meeting end of September.
>> We will focus on so-called stateless solutions and other remaining
>> business in the wg (multicast. mibs,...)
>> that require more time than we usually have during a normal IETF
>> meeting.
>> The format will be a 2 day intensive meeting, with white board
>> discussions, similar to what we did in the early days of the working
>> group.
>>
>> We've got an offer to host the meeting in Beijin on Sept. 26-27th or
>> 27-28th (right after the Boradband forum meeting in Shanghai).
>> Yong and I would like to make a decision soon, please send us email
>> directly if you intend to come and tell us which set of dates is more
>> convenient.
>> Please respond by August 11th, we will formally announce the meeting
>> with the logistic information end of next week.
>>
>> Alain&  Yong.
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>


From xiaohong.deng@orange-ftgroup.com  Sun Aug  7 20:58:28 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234DB21F874F for ; Sun,  7 Aug 2011 20:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.669,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63YGBXYERbs7 for ; Sun,  7 Aug 2011 20:58:27 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5015621F86C3 for ; Sun,  7 Aug 2011 20:58:27 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 354C08F0005; Mon,  8 Aug 2011 05:59:39 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 143DF8B8002; Mon,  8 Aug 2011 05:59:37 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 8 Aug 2011 05:58:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Aug 2011 11:50:23 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01918D5B@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Softwire Interim meeting
Thread-Index: AcxVfk1dZEqe5zTbS1OlHKDyde1rlA==
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net> 
From: 
To: , 
X-OriginalArrivalTime: 08 Aug 2011 03:58:14.0810 (UTC) FILETIME=[660AE7A0:01CC557F]
Cc: softwires@ietf.org, rdroms@cisco.com
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 03:58:28 -0000

Either Shanghai or Beijing will do. Just some pieces of info:
 Autumn is definitely the best season in Beijing! With fabulous views
and weather! ;) And there is a high speed railway between Shanghai and
Beijing, costing 60 Euros approximately. Please also note that 26-27th
or 27-28th is near the Chinese Golden week in China beginning with Oct.
1st, during which a lot visitors will rush into either Beijing or
Shanghai. So some time before Broadband forum may give us a better
alternative.=20

Xiaohong

|On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:
|
|> Following-up on the Quebec meeting, we would like to=20
|organize an interim meeting end of September.
|> We will focus on so-called stateless solutions and other remaining=20
|> business in the wg (multicast. mibs,...) that require more=20
|time than we usually have during a normal IETF meeting.
|> The format will be a 2 day intensive meeting, with white=20
|board discussions, similar to what we did in the early days of=20
|the working group.
|>=20
|> We've got an offer to host the meeting in Beijin on Sept.=20
|26-27th or 27-28th (right after the Boradband forum meeting in=20
|Shanghai).
|
|Would it be possible to keep it in the same city as the BBF to=20
|cut down travel/costs a bit more for those going to both?
|
|- Mark
|
|> Yong and I would like to make a decision soon, please send=20
|us email directly if you intend to come and tell us which set=20
|of dates is more convenient.
|> Please respond by August 11th, we will formally announce the=20
|meeting with the logistic information end of next week.
|>=20
|> Alain & Yong.
|>=20
|>=20
|>=20
|> _______________________________________________
|> Softwires mailing list
|> Softwires@ietf.org
|> https://www.ietf.org/mailman/listinfo/softwires
|
|
|

From xiaohong.deng@orange-ftgroup.com  Sun Aug  7 20:58:29 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692B021F8880 for ; Sun,  7 Aug 2011 20:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.628
X-Spam-Level: 
X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.621,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsUAcC6yWbEt for ; Sun,  7 Aug 2011 20:58:28 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5D021F86C3 for ; Sun,  7 Aug 2011 20:58:28 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AC14D8C000B; Mon,  8 Aug 2011 05:59:41 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 61B598C0001; Mon,  8 Aug 2011 05:59:40 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 8 Aug 2011 05:58:16 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Aug 2011 11:55:21 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01918D5F@ch-mailsrv.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Softwire Interim meeting
Thread-Index: AcxVfk1dZEqe5zTbS1OlHKDyde1rlAAAHxqw
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>  
From: 
To: , , 
X-OriginalArrivalTime: 08 Aug 2011 03:58:16.0763 (UTC) FILETIME=[6734E8B0:01CC557F]
Cc: softwires@ietf.org, rdroms@cisco.com
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 03:58:29 -0000

BTW, the high speed railway between Shanghai and Beijing takes 4 hours.=20

|-----Original Message-----
|From: DENG Xiaohong ESP/PEK=20
|Sent: Monday, August 08, 2011 11:50 AM
|To: Alain Durand; 'Mark Townsley'
|Cc: softwires@ietf.org list; Ralph Droms
|Subject: RE: [Softwires] Softwire Interim meeting
|
|Either Shanghai or Beijing will do. Just some pieces of info:
| Autumn is definitely the best season in Beijing! With=20
|fabulous views and weather! ;) And there is a high speed=20
|railway between Shanghai and Beijing, costing 60 Euros=20
|approximately. Please also note that 26-27th or 27-28th is=20
|near the Chinese Golden week in China beginning with Oct. 1st,=20
|during which a lot visitors will rush into either Beijing or=20
|Shanghai. So some time before Broadband forum may give us a=20
|better alternative.=20
|
|Xiaohong
|
||On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:
||
||> Following-up on the Quebec meeting, we would like to
||organize an interim meeting end of September.
||> We will focus on so-called stateless solutions and other remaining=20
||> business in the wg (multicast. mibs,...) that require more
||time than we usually have during a normal IETF meeting.
||> The format will be a 2 day intensive meeting, with white
||board discussions, similar to what we did in the early days of the=20
||working group.
||>=20
||> We've got an offer to host the meeting in Beijin on Sept.=20
||26-27th or 27-28th (right after the Boradband forum meeting in=20
||Shanghai).
||
||Would it be possible to keep it in the same city as the BBF=20
|to cut down=20
||travel/costs a bit more for those going to both?
||
||- Mark
||
||> Yong and I would like to make a decision soon, please send
||us email directly if you intend to come and tell us which set=20
|of dates=20
||is more convenient.
||> Please respond by August 11th, we will formally announce the
||meeting with the logistic information end of next week.
||>=20
||> Alain & Yong.
||>=20
||>=20
||>=20
||> _______________________________________________
||> Softwires mailing list
||> Softwires@ietf.org
||> https://www.ietf.org/mailman/listinfo/softwires
||
||
||

From despres.remi@laposte.net  Sun Aug  7 22:37:52 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7849921F89A7 for ; Sun,  7 Aug 2011 22:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level: 
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0JchvelUaqF for ; Sun,  7 Aug 2011 22:37:51 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6194F21F899F for ; Sun,  7 Aug 2011 22:37:50 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 12647700008E; Mon,  8 Aug 2011 07:38:15 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id A0B947000087; Mon,  8 Aug 2011 07:38:10 +0200 (CEST)
X-SFR-UUID: 20110808053810658.A0B947000087@msfrf2207.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-79--532758578
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Mon, 8 Aug 2011 07:38:10 +0200
Message-Id: <43C12B92-3F8F-4406-880A-8FC05EEC0490@laposte.net>
References:   
To: Qiong 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 05:37:52 -0000

--Apple-Mail-79--532758578
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Quiong,

Clarifying what is meant by "stateless" in different contexts is highly =
desirable.

The objective of the 4rd address mapping is
- no "per customer" state in provider nodes (BR, AFTR...)
- direct customer-customer paths made possible

The 'Lightweight 4over6' proposal has in my understanding a different =
objective: flexible port sets assignable to each individual customer.
It can therefore coexist with one or both "per-sustomer-stateless" =
solution(s) (with encapsulation and/or double-translation).

Hope it helps.

Regards,
RD


Le 2 ao=FBt 2011 =E0 08:11, Qiong a =E9crit :

> Hi Lee,
>=20
> Thank you very much for your interests on 'lightweight 4over6'.
>=20
> In our consideration, lightweight AFTR is not doing port-range =
routing. In this lightweight AFTR, it would firstly lookup a mapping =
table (recording [IPv6 address, IPv4 address, Port set]) for a =
downstream IPv4 packet. Then after IPv4 packet has been encapsulated =
into IPv6 packet, it will do IPv6 routing based on different IPv6 =
addresses. So, lightweight AFTR does not need to distribute port-set =
info into FIB and there is no impact on existing routing architecture =
between B4 and AFTR.
>=20
> Actually, the basic idea behind 'lightweight 4over6' is to include =
addressing sharing for 'public 4over6', and to enhance DS-Lite for =
better scalability. It is a lightweight solution which only keeps =
customer-based state in AFTR compared to DS-Lite. And there is also no =
IPv6 address format restriction and no IPv6 routing impact on existing =
network infrastructure. We have implemented a prototype in our =
commercial network and find it easy to deploy in practice.=20
>=20
> With regard to so much stateful/stateless discussion, I think actually =
there is no solution with totally stateless in the address sharing =
world. It is only a matter of fact where to keep the states, either =
distributed in CPE or centralized in the core CGN. Given the fact that =
most existing CPEs can support NAT already,  our solution is to keep =
less states in the Core CGN, while keeping the simplicity of IPv6 =
addressing and routing.
>=20
> Sorry to make the discussion even more complicated. Your comments are =
more than welcome.
>=20
> Thanks in advance.
>=20
> Best wishes
>=20
>=20
> On Tue, Aug 2, 2011 at 1:18 AM, Lee, Yiu  =
wrote:
> In this case,
> =
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt
> could be (modified here) controversial because it will turn AFTR a =
PRR.
>=20
> On 8/1/11 7:07 AM, "Satoru Matsushima"  =
wrote:
>=20
> >If you imagine dynamic port ranges within stateless, it sounds like =
port
> >range aware routing. I think that it would be controversial.
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


--Apple-Mail-79--532758578
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



The =
objective of the 4rd address mapping is
- no "per customer" =
state in provider nodes (BR, AFTR...)
- direct =
customer-customer paths made possible

The =
'Lightweight 4over6' proposal has in my understanding a different =
objective: flexible port sets assignable to each individual =
customer.
It can therefore coexist with one or both =
"per-sustomer-stateless" solution(s) (with encapsulation and/or =
double-translation).

Hope it =
helps.

Regards,
RD

=


Le 2 ao=FBt 2011 =E0 08:11, Qiong a =E9crit =
:

Hi Lee,

Thank you very much for your =
interests on 'lightweight 4over6'.

In our =
consideration, lightweight AFTR is not doing port-range routing. In this =
lightweight AFTR, it would firstly lookup a mapping table (recording =
[IPv6 address, IPv4 address, Port set]) for a downstream IPv4 =
packet. Then after IPv4 packet has been encapsulated into IPv6 packet, =
it will do IPv6 routing based on different IPv6 addresses. So, =
lightweight AFTR does not need to distribute port-set info into FIB and =
there is no impact on existing routing architecture between B4 and =
AFTR.




Actually, the basic idea behind 'lightweight 4over6' =
is to include addressing sharing for 'public 4over6', and to enhance =
DS-Lite for better scalability. It is a lightweight solution which only =
keeps customer-based state in AFTR compared to DS-Lite. And there is =
also no IPv6 address format restriction and no IPv6 routing impact on =
existing network infrastructure. We have implemented a prototype in =
our commercial network and find it easy to deploy in =
practice. 




With regard to so much stateful/stateless =
discussion, I think actually there is no solution with totally stateless =
in the address sharing world. It is only a matter of fact where to keep =
the states, either distributed in CPE or centralized in the core CGN. =
Given the fact that most existing CPEs can support NAT already, =
 our solution is to keep less states in the Core CGN, while keeping =
the simplicity of IPv6 addressing and routing.




Sorry to make the discussion even more complicated. =
Your comments are more than welcome.

Thanks in =
advance.

Best =
wishes





_______________________________________________
Softwires mailing =
list
Softwires@ietf.org
https://www.i=
etf.org/mailman/listinfo/softwires

=
=

--Apple-Mail-79--532758578--


From weapon@csnet1.cs.tsinghua.edu.cn  Sun Aug  7 23:31:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F100D21F8A30 for ; Sun,  7 Aug 2011 23:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.305
X-Spam-Level: ***
X-Spam-Status: No, score=3.305 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOGjlZbJch7k for ; Sun,  7 Aug 2011 23:31:42 -0700 (PDT)
Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 558A221F8A23 for ; Sun,  7 Aug 2011 23:31:16 -0700 (PDT)
Received: from PengWu-laptop (unknown [144.214.110.35]) by mail.csnet1.cs.tsinghua.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id B31B31B0404B6; Mon,  8 Aug 2011 14:31:33 +0800 (CST)
Date: Mon, 8 Aug 2011 14:31:30 +0800
From: "Peng Wu" 
To: "xiaohong.deng@orange-ftgroup.com" , "adurand@juniper.net" , "mark@townsley.net" 
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>, 
Message-ID: <201108081431283721107@csnet1.cs.tsinghua.edu.cn>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Cc: softwires , rdroms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 06:31:46 -0000

SW4gbXkgZXhwZXJpZW5jZSwgdGhlIGNyb3dkbmVzcyBvZiAgR29sZGVuIFdlZWsgYmVnaW5zIGF0
IDI5LTMwdGguIFNvIHVubGVzcyB5b3UgaGF2ZSB0cmlwcyBwbGFucyBhZnRlciB0aGUgbWVldGlu
ZywgdGhlIGRhdGVzIGFyZSBmaW5lLiAyNi0yN3RoIGFyZSBwcm9iYWJseSBiZXR0ZXIuDQpKdXN0
IHJlbWVtYmVyIHRvIHJ1biBhd2F5IGluIHRpbWUgYWZ0ZXIgdGhlIG1lZXRpbmcsIGhhOikNCg0K
QW5vdGhlciBmYWN0IGlzIHRoYXQgaXQncyBhIGxpdHRsZSBkaWZmaWN1bHQgdG8gZ2V0IHRyYWlu
IHRpY2tldHMgbmVhciB0aGUgR29sZGVuIFdlZWsuIE5vdCBzdXJlIGFib3V0IHRoZSBoaWdoIHNw
ZWVkIGxpbmUgc2luY2UgaXQganVzdCBzdGFydCB0aGlzIHllYXIgYW5kIHRoZSBwcmljZSBpcyBt
dWNoIGhpZ2hlciB0aGFuIHJlZ3VsZXIgb25lcy4gQW55d2F5IGlmIHRoaXMgSW50ZXJpbSBtZWV0
aW5nIHRha2VzIHBsYWNlIGluIEJlaWppbmcsIGp1c3QgdGFrZSBmbGlnaHQgYmFjayBmcm9tIEJl
aWppbmcgYWZ0ZXJ3YXJkcyByYXRoZXIgdGhhbiBnbyBiYWNrIHRvIFNoYW5naGFpIGZpcnN0Lg0K
LS0tLS0tLS0tLS0tLS0tLS0tCQkJCSANClBlbmcgV3UNClBoRCBjYW5kaWRhdGUNCkRlcGFydG1l
bnQgb2YgQ29tcHV0ZXIgU2NpZW5jZSAmIFRlY2hub2xvZ3kNClRzaW5naHVhIFVuaXZlcnNpdHks
IEJlaWppbmcsIENoaW5hDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb22junhpYW9ob25nLmRlbmcNCkRhdGWjujIwMTEt
MDgtMDggMTE6NTk6NDQNClRvo7phZHVyYW5kQGp1bmlwZXIubmV0OyBtYXJrQHRvd25zbGV5Lm5l
dA0KQ0OjunNvZnR3aXJlczsgcmRyb21zDQpTdWJqZWN0o7pSZTogW1NvZnR3aXJlc10gU29mdHdp
cmUgSW50ZXJpbSBtZWV0aW5nDQoNCj5FaXRoZXIgU2hhbmdoYWkgb3IgQmVpamluZyB3aWxsIGRv
LiBKdXN0IHNvbWUgcGllY2VzIG9mIGluZm86DQo+IEF1dHVtbiBpcyBkZWZpbml0ZWx5IHRoZSBi
ZXN0IHNlYXNvbiBpbiBCZWlqaW5nISBXaXRoIGZhYnVsb3VzIHZpZXdzDQo+YW5kIHdlYXRoZXIh
IDspIEFuZCB0aGVyZSBpcyBhIGhpZ2ggc3BlZWQgcmFpbHdheSBiZXR3ZWVuIFNoYW5naGFpIGFu
ZA0KPkJlaWppbmcsIGNvc3RpbmcgNjAgRXVyb3MgYXBwcm94aW1hdGVseS4gUGxlYXNlIGFsc28g
bm90ZSB0aGF0IDI2LTI3dGgNCj5vciAyNy0yOHRoIGlzIG5lYXIgdGhlIENoaW5lc2UgR29sZGVu
IHdlZWsgaW4gQ2hpbmEgYmVnaW5uaW5nIHdpdGggT2N0Lg0KPjFzdCwgZHVyaW5nIHdoaWNoIGEg
bG90IHZpc2l0b3JzIHdpbGwgcnVzaCBpbnRvIGVpdGhlciBCZWlqaW5nIG9yDQo+U2hhbmdoYWku
IFNvIHNvbWUgdGltZSBiZWZvcmUgQnJvYWRiYW5kIGZvcnVtIG1heSBnaXZlIHVzIGEgYmV0dGVy
DQo+YWx0ZXJuYXRpdmUuIA0KPg0KPlhpYW9ob25nDQo+DQo+fE9uIEF1ZyA1LCAyMDExLCBhdCAy
OjM4IFBNLCBBbGFpbiBEdXJhbmQgd3JvdGU6DQo+fA0KPnw+IEZvbGxvd2luZy11cCBvbiB0aGUg
UXVlYmVjIG1lZXRpbmcsIHdlIHdvdWxkIGxpa2UgdG8gDQo+fG9yZ2FuaXplIGFuIGludGVyaW0g
bWVldGluZyBlbmQgb2YgU2VwdGVtYmVyLg0KPnw+IFdlIHdpbGwgZm9jdXMgb24gc28tY2FsbGVk
IHN0YXRlbGVzcyBzb2x1dGlvbnMgYW5kIG90aGVyIHJlbWFpbmluZyANCj58PiBidXNpbmVzcyBp
biB0aGUgd2cgKG11bHRpY2FzdC4gbWlicywuLi4pIHRoYXQgcmVxdWlyZSBtb3JlIA0KPnx0aW1l
IHRoYW4gd2UgdXN1YWxseSBoYXZlIGR1cmluZyBhIG5vcm1hbCBJRVRGIG1lZXRpbmcuDQo+fD4g
VGhlIGZvcm1hdCB3aWxsIGJlIGEgMiBkYXkgaW50ZW5zaXZlIG1lZXRpbmcsIHdpdGggd2hpdGUg
DQo+fGJvYXJkIGRpc2N1c3Npb25zLCBzaW1pbGFyIHRvIHdoYXQgd2UgZGlkIGluIHRoZSBlYXJs
eSBkYXlzIG9mIA0KPnx0aGUgd29ya2luZyBncm91cC4NCj58PiANCj58PiBXZSd2ZSBnb3QgYW4g
b2ZmZXIgdG8gaG9zdCB0aGUgbWVldGluZyBpbiBCZWlqaW4gb24gU2VwdC4gDQo+fDI2LTI3dGgg
b3IgMjctMjh0aCAocmlnaHQgYWZ0ZXIgdGhlIEJvcmFkYmFuZCBmb3J1bSBtZWV0aW5nIGluIA0K
PnxTaGFuZ2hhaSkuDQo+fA0KPnxXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBrZWVwIGl0IGluIHRo
ZSBzYW1lIGNpdHkgYXMgdGhlIEJCRiB0byANCj58Y3V0IGRvd24gdHJhdmVsL2Nvc3RzIGEgYml0
IG1vcmUgZm9yIHRob3NlIGdvaW5nIHRvIGJvdGg/DQo+fA0KPnwtIE1hcmsNCj58DQo+fD4gWW9u
ZyBhbmQgSSB3b3VsZCBsaWtlIHRvIG1ha2UgYSBkZWNpc2lvbiBzb29uLCBwbGVhc2Ugc2VuZCAN
Cj58dXMgZW1haWwgZGlyZWN0bHkgaWYgeW91IGludGVuZCB0byBjb21lIGFuZCB0ZWxsIHVzIHdo
aWNoIHNldCANCj58b2YgZGF0ZXMgaXMgbW9yZSBjb252ZW5pZW50Lg0KPnw+IFBsZWFzZSByZXNw
b25kIGJ5IEF1Z3VzdCAxMXRoLCB3ZSB3aWxsIGZvcm1hbGx5IGFubm91bmNlIHRoZSANCj58bWVl
dGluZyB3aXRoIHRoZSBsb2dpc3RpYyBpbmZvcm1hdGlvbiBlbmQgb2YgbmV4dCB3ZWVrLg0KPnw+
IA0KPnw+IEFsYWluICYgWW9uZy4NCj58PiANCj58PiANCj58PiANCj58PiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnw+IFNvZnR3aXJlcyBtYWlsaW5n
IGxpc3QNCj58PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj58PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPnwNCj58DQo+fA0KPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0K
PlNvZnR3aXJlc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vc29mdHdpcmVzDQo+DQo+IURTUEFNOjEsNGUzZjVmMzAzMDg5NTkyMzc3MTA3MSENCj4NCj4N
Cg==


From wwwrun@rfc-editor.org  Mon Aug  8 12:12:31 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A0421F8C0F; Mon,  8 Aug 2011 12:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.776
X-Spam-Level: 
X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8t8qfBnC2mI; Mon,  8 Aug 2011 12:12:31 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 305B321F8754; Mon,  8 Aug 2011 12:12:13 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id E12F298C532; Mon,  8 Aug 2011 12:12:32 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20110808191232.E12F298C532@rfc-editor.org>
Date: Mon,  8 Aug 2011 12:12:32 -0700 (PDT)
Cc: softwires@ietf.org, rfc-editor@rfc-editor.org
Subject: [Softwires] RFC 6333 on Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 19:12:31 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6333

        Title:      Dual-Stack Lite Broadband Deployments Following 
                    IPv4 Exhaustion 
        Author:     A. Durand, R. Droms,
                    J. Woodyatt, Y. Lee
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2011
        Mailbox:    adurand@juniper.net, 
                    rdroms@cisco.com, 
                    jhw@apple.com,  yiu_lee@cable.comcast.com
        Pages:      32
        Characters: 65622
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-softwire-dual-stack-lite-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6333.txt

This document revisits the dual-stack model and introduces the Dual-
Stack Lite technology aimed at better aligning the costs and benefits
of deploying IPv6 in service provider networks.  Dual-Stack Lite
enables a broadband service provider to share IPv4 addresses among
customers by combining two well-known technologies: IP in IP (IPv4-
in-IPv6) and Network Address Translation (NAT).  [STANDARDS-TRACK]

This document is a product of the Softwires Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Mon Aug  8 12:12:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4D821F8C3A; Mon,  8 Aug 2011 12:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.771
X-Spam-Level: 
X-Spam-Status: No, score=-101.771 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUENRkBrrh4m; Mon,  8 Aug 2011 12:12:45 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6466721F8B72; Mon,  8 Aug 2011 12:12:23 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 33AB998C53D; Mon,  8 Aug 2011 12:12:46 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20110808191246.33AB998C53D@rfc-editor.org>
Date: Mon,  8 Aug 2011 12:12:46 -0700 (PDT)
Cc: softwires@ietf.org, rfc-editor@rfc-editor.org
Subject: [Softwires] RFC 6334 on Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2011 19:12:45 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6334

        Title:      Dynamic Host Configuration Protocol for 
                    IPv6 (DHCPv6) Option for Dual-Stack Lite 
        Author:     D. Hankins, T. Mrugalski
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2011
        Mailbox:    dhankins@google.com, 
                    tomasz.mrugalski@eti.pg.gda.pl
        Pages:      7
        Characters: 14362
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-softwire-ds-lite-tunnel-option-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6334.txt

This document specifies a DHCPv6 option that is meant to be used by a
Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the
IPv6 address of its corresponding Address Family Transition Router
(AFTR).  [STANDARDS-TRACK]

This document is a product of the Softwires Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From yiu_lee@cable.comcast.com  Mon Aug  8 18:09:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797821F8BB0 for ; Mon,  8 Aug 2011 18:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.463
X-Spam-Level: 
X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHw0brg2OdVO for ; Mon,  8 Aug 2011 18:09:45 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id EA20021F8BA9 for ; Mon,  8 Aug 2011 18:09:44 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136591967; Mon, 08 Aug 2011 21:10:01 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Mon, 8 Aug 2011 21:10:01 -0400
From: "Lee, Yiu" 
To: Satoru Matsushima 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVjEPzusyyICqCUGPZREqvWwScw==
Date: Tue, 9 Aug 2011 01:10:00 +0000
Message-ID: 
In-Reply-To: <8FF93261-8992-4A71-BF47-95C52C9C98B7@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [68.82.30.70]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires-wg 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 01:09:46 -0000

Hi Satoru,

I think you answered your question. As you said, it is possible to use 1
port (in theory) to reach 2000 sessions as long as each destination is
different. So given user 256 ports could create a much larger set of NAT
sessions in the CGN.

Cheers,
Yiu


On 8/2/11 2:33 AM, "Satoru Matsushima"  wrote:

>Which do you mean '2000' is the number of port you need, or the number of
>NAT table sessions?
>
>cheers,
>--satoru


From yiu_lee@cable.comcast.com  Mon Aug  8 18:11:24 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4A21F8BB8 for ; Mon,  8 Aug 2011 18:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.099
X-Spam-Level: 
X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-3.364, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGPTZpu8aa8g for ; Mon,  8 Aug 2011 18:11:23 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3F55421F8BA9 for ; Mon,  8 Aug 2011 18:11:22 -0700 (PDT)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.48033646; Mon, 08 Aug 2011 19:16:50 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Mon, 8 Aug 2011 21:11:39 -0400
From: "Lee, Yiu" 
To: Qiong 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVjFKzusyyICqCUGPZREqvWwScw==
Date: Tue, 9 Aug 2011 01:11:38 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [68.82.30.70]
Content-Type: multipart/alternative; boundary="_000_CA66013B13742yiuleecablecomcastcom_"
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 01:11:24 -0000

--_000_CA66013B13742yiuleecablecomcastcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Qiong,

I see your point. So what is the difference between a lightweight AFTR and =
4rd BR?

Cheers,
Yiu

From: Qiong >
Date: Tue, 2 Aug 2011 14:11:55 +0800
To: "Yiu L. LEE" >
Cc: Satoru Matsushima >, "Jan Zorz @ go6.si" >, "softwir=
es@ietf.org" >
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion

In our consideration, lightweight AFTR is not doing port-range routing. In =
this lightweight AFTR, it would firstly lookup a mapping table (recording [=
IPv6 address, IPv4 address, Port set]) for a downstream IPv4 packet. Then a=
fter IPv4 packet has been encapsulated into IPv6 packet, it will do IPv6 ro=
uting based on different IPv6 addresses. So, lightweight AFTR does not need=
 to distribute port-set info into FIB and there is no impact on existing ro=
uting architecture between B4 and AFTR.

--_000_CA66013B13742yiuleecablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Qiong,







I see your point. So what is the difference between a lightweight AFTR=
 and 4rd BR?







Cheers,


Yiu









From: Qiong <bingxuere@gmail.com>

Date: Tue, 2 Aug 2011 14:11:55 +=
;0800

To: "Yiu L. LEE" <yiu_lee@cable.comcast.com><=
br>
Cc: Satoru Matsushima <satoru.matsushima@gmail.com>=
, "Jan Zorz @ go6.si" <jan@go6.s=
i>, "softwires@ietf.org"
 <softwires@ietf.org>

Subject: Re: [Softwires] Clarificat=
ion of the stateles/stateful discussion








In
 our consideration, lightweight AFTR is not doing port-range routing. In th=
is lightweight AFTR, it would firstly lookup a mapping table (recording [IP=
v6 address, IPv4 address, Port set]) for a downstream IPv4 packet. The=
n after IPv4 packet has been encapsulated
 into IPv6 packet, it will do IPv6 routing based on different IPv6 addresse=
s. So, lightweight AFTR does not need to distribute port-set info into FIB =
and there is no impact on existing routing architecture between B4 and AFTR=
.



--_000_CA66013B13742yiuleecablecomcastcom_--

From jacni@jacni.com  Mon Aug  8 18:22:24 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB23521F86DE for ; Mon,  8 Aug 2011 18:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level: 
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.467,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jq5e+b0h5IG for ; Mon,  8 Aug 2011 18:22:24 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3E60621F8596 for ; Mon,  8 Aug 2011 18:22:23 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 30E4C3800F0 for ; Mon,  8 Aug 2011 21:22:50 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id AC703860022 for ; Tue,  9 Aug 2011 09:22:46 +0800 (CST)
Received: from [172.23.204.210] (unknown [112.64.190.234]) by app (Coremail) with SMTP id +AWowJALdgfgi0BOCO9IAA--.42840S2; Tue, 09 Aug 2011 09:22:44 +0800 (CST)
Message-ID: <4E408C18.8030301@jacni.com>
Date: Tue, 09 Aug 2011 09:23:36 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Lee, Yiu" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060905050607060700070300"
X-CM-TRANSID: +AWowJALdgfgi0BOCO9IAA--.42840S2
X-Coremail-Antispam: 1UD129KBjvJXoW7Zw4ktF15Xr4xZryruw1fCrg_yoW8JFy7pF Z7Gw1DGa4kAr1Iy3ykuF1Yyr4qvrykArWUtwn8Xr1qkas8JF10vw409345ArWDJr45Aa15 tr4UuF1UJFs3XaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUI2b7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VW7JwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6r1S6rWUM2kK64x0aVW7Gw IE548m6rI_Jw1UWr17M2kK64x0aVW7GwIE548m6rv_Jw1UWr17M2kK6xCIbVAIwIAEc20F 6c8GOVW8Jr15Jr4ln4vEIxkG6c02xx0F6c8GOVWUtr18Jw1lnx0Ec2IEnICE548m6r1DJr WUZwAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vI r41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64 vIr41l4IxY624lx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrbIYCTnIWIevJa73 UjIFyTuYvjxUay8BUUUUU
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEOEko7lM+GRgAJs-
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 01:22:25 -0000

This is a multi-part message in MIME format.
--------------060905050607060700070300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hi,

If I understand it correctly, a per user address/port mapping table is 
maintained on the LW AFTR, then no session table on it.


Cheers,
Jacni

On 8/9/2011 9:11 AM, Lee, Yiu wrote:
> Hi Qiong,
>
> I see your point. So what is the difference between a lightweight AFTR 
> and 4rd BR?
>
> Cheers,
> Yiu
>
> From: Qiong >
> Date: Tue, 2 Aug 2011 14:11:55 +0800
> To: "Yiu L. LEE"  >
> Cc: Satoru Matsushima  >, "Jan Zorz @ go6.si"  >, "softwires@ietf.org " 
> >
> Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
>
> In our consideration, lightweight AFTR is not doing port-range 
> routing. In this lightweight AFTR, it would firstly lookup a mapping 
> table (recording [IPv6 address, IPv4 address, Port set]) for a 
> downstream IPv4 packet. Then after IPv4 packet has been encapsulated 
> into IPv6 packet, it will do IPv6 routing based on different IPv6 
> addresses. So, lightweight AFTR does not need to distribute port-set 
> info into FIB and there is no impact on existing routing architecture 
> between B4 and AFTR.
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--------------060905050607060700070300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    hi,

      

      If I understand it correctly, a per user address/port mapping
      table is maintained on the LW AFTR, then no session table on it.

      

      

      Cheers,

      Jacni

    

    On 8/9/2011 9:11 AM, Lee, Yiu wrote:
    

      
      
Hi Qiong,

      


      

      
I see your point. So what is the difference between a
        lightweight AFTR and 4rd BR?

      


      

      
Cheers,

      
Yiu

      


      

      
        

          From: Qiong <bingxuere@gmail.com>

          Date: Tue, 2 Aug 2011
          14:11:55 +0800

          To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>

          Cc: Satoru Matsushima
          <satoru.matsushima@gmail.com>,
          "Jan Zorz @ go6.si" <jan@go6.si>, "softwires@ietf.org"
          <softwires@ietf.org>

          Subject: Re:
          [Softwires] Clarification of the stateles/stateful discussion

        

        


        

        In our consideration, lightweight
          AFTR is not doing port-range routing. In this lightweight
          AFTR, it would firstly lookup a mapping table (recording [IPv6
          address, IPv4 address, Port set]) for a downstream IPv4
          packet. Then after IPv4 packet has been encapsulated into IPv6
          packet, it will do IPv6 routing based on different IPv6
          addresses. So, lightweight AFTR does not need to distribute
          port-set info into FIB and there is no impact on existing
          routing architecture between B4 and AFTR.
      

      

      

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


    

  


--------------060905050607060700070300--


From yiu_lee@cable.comcast.com  Mon Aug  8 18:25:21 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF86B21F85A0 for ; Mon,  8 Aug 2011 18:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.78
X-Spam-Level: 
X-Spam-Status: No, score=-106.78 tagged_above=-999 required=5 tests=[AWL=1.682, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEC+nqCcCqSF for ; Mon,  8 Aug 2011 18:25:21 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3421F859F for ; Mon,  8 Aug 2011 18:25:20 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136592580; Mon, 08 Aug 2011 21:25:44 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Mon, 8 Aug 2011 21:25:44 -0400
From: "Lee, Yiu" 
To: Jacni Qin 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVjNBd8zS8vuogUiPLuMY5/4K9Q==
Date: Tue, 9 Aug 2011 01:25:43 +0000
Message-ID: 
In-Reply-To: <4E408C18.8030301@jacni.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [68.82.30.70]
Content-Type: multipart/alternative; boundary="_000_CA6604891374Byiuleecablecomcastcom_"
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 01:25:21 -0000

--_000_CA6604891374Byiuleecablecomcastcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

So the only difference between 4rd BR and lightweight AFTR is just a static=
 mapping rule for all users in the same domain (4rd BR case) and group rule=
 or user specific rule for different users (LW AFTR)?

From: Jacni Qin >
Date: Tue, 9 Aug 2011 09:23:36 +0800
To: "Yiu L. LEE" >
Cc: Qiong >, "softwires@iet=
f.org" >
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion

hi,

If I understand it correctly, a per user address/port mapping table is main=
tained on the LW AFTR, then no session table on it.


Cheers,
Jacni

On 8/9/2011 9:11 AM, Lee, Yiu wrote:
Hi Qiong,

I see your point. So what is the difference between a lightweight AFTR and =
4rd BR?

Cheers,
Yiu

From: Qiong >
Date: Tue, 2 Aug 2011 14:11:55 +0800
To: "Yiu L. LEE" >
Cc: Satoru Matsushima >, "Jan Zorz @ go6.si" >, "softwir=
es@ietf.org" >
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion

In our consideration, lightweight AFTR is not doing port-range routing. In =
this lightweight AFTR, it would firstly lookup a mapping table (recording [=
IPv6 address, IPv4 address, Port set]) for a downstream IPv4 packet. Then a=
fter IPv4 packet has been encapsulated into IPv6 packet, it will do IPv6 ro=
uting based on different IPv6 addresses. So, lightweight AFTR does not need=
 to distribute port-set info into FIB and there is no impact on existing ro=
uting architecture between B4 and AFTR.


_______________________________________________
Softwires mailing list
Softwires@ietf.orghttps://www.ietf.org/mailman/l=
istinfo/softwires

--_000_CA6604891374Byiuleecablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







So the only difference between 4rd BR and lightweight AFTR is just a s=
tatic mapping rule for all users in the same domain (4rd BR case) and group=
 rule or user specific rule for different users (LW AFTR)?









From: Jacni Qin <jacni@jacni.com>

Date: Tue, 9 Aug 2011 09:23:36 +=
;0800

To: "Yiu L. LEE" <yiu_lee@cable.comcast.com><=
br>
Cc: Qiong <bingxuere@gmail.com>, "softwires@ietf.org" <softwires@ietf.org>

Subject: Re: [Softwires] Clarificat=
ion of the stateles/stateful discussion











hi,



If I understand it correctly, a per user address/port mapping table is main=
tained on the LW AFTR, then no session table on it.





Cheers,

Jacni



On 8/9/2011 9:11 AM, Lee, Yiu wrote:



Hi Qiong,







I see your point. So what is the difference between a lightweight AFTR=
 and 4rd BR?







Cheers,


Yiu









From: Qiong <bingxuere@gmail.com>
Date: Tue, 2 Aug 2011 14:11:55 +=
;0800

To: "Yiu L. LEE" <yiu_lee@c=
able.comcast.com>

Cc: Satoru Matsushima <satoru.matsu=
shima@gmail.com>, "Jan Zorz @ go6.si" <jan@go6.si>, "softwires@ietf.org=
"
 <softwir=
es@ietf.org>

Subject: Re: [Softwires] Clarificat=
ion of the stateles/stateful discussion








In
 our consideration, lightweight AFTR is not doing port-range routing. In th=
is lightweight AFTR, it would firstly lookup a mapping table (recording [IP=
v6 address, IPv4 address, Port set]) for a downstream IPv4 packet. The=
n after IPv4 packet has been encapsulated
 into IPv6 packet, it will do IPv6 routing based on different IPv6 addresse=
s. So, lightweight AFTR does not need to distribute port-set info into FIB =
and there is no impact on existing routing architecture between B4 and AFTR=
.



 


_______________________________________________
Softwires mailing list
So=
ftwires@ietf.orghttps://www.ietf.org/mailman/listinfo/=
softwires











--_000_CA6604891374Byiuleecablecomcastcom_--

From jacni@jacni.com  Mon Aug  8 19:22:12 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4021F8571 for ; Mon,  8 Aug 2011 19:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.872
X-Spam-Level: 
X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.415,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSEO5wz8RefR for ; Mon,  8 Aug 2011 19:22:11 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id EBABF21F84E9 for ; Mon,  8 Aug 2011 19:22:10 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 78D613801E3 for ; Mon,  8 Aug 2011 22:22:37 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id B8351340150 for ; Tue,  9 Aug 2011 10:22:35 +0800 (CST)
Received: from [172.23.204.210] (unknown [112.64.190.234]) by app (Coremail) with SMTP id +AWowJC7wALbmUBOiwJJAA--.43375S2; Tue, 09 Aug 2011 10:22:27 +0800 (CST)
Message-ID: <4E409A12.3050706@jacni.com>
Date: Tue, 09 Aug 2011 10:23:14 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Lee, Yiu" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030208070405080302040603"
X-CM-TRANSID: +AWowJC7wALbmUBOiwJJAA--.43375S2
X-Coremail-Antispam: 1UD129KBjvJXoW7ur1DJF1UtF47AFWDCrWrGrg_yoW8ZrW3pF WkGw1DKaykJr1xA3ykuF1Fvr1v9FykAryrtwn8Xr1qkasxJF10vw4F9345AFWDJr43Jan0 qr4UuF18AFsxXaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUI2b7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6r1S6rWUM2kK64x0aVW7Gw IE548m6rI_Jw1UWr17M2kK64x0aVW7GwIE548m6rv_Jw1UWr17M2kK6xCIbVAIwIAEc20F 6c8GOVW8Jr15Jr4ln4vEIxkG6c02xx0F6c8GOVWUtr18Jw1lnx0Ec2IEnICE548m6r1DJr WUZwAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vI r41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64 vIr41l4IxY624lx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrbIYCTnIWIevJa73 UjIFyTuYvjxUaJKsUUUUU
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEOEko7lM+GRgALs9
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 02:22:12 -0000

This is a multi-part message in MIME format.
--------------030208070405080302040603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Re-,

Since the "rules" are "maintained" in different ways, then the 
forwarding behaviors, for incoming traffics and CE-CE etc., are 
different, IMHO.


Cheers,
Jacni

On 8/9/2011 9:25 AM, Lee, Yiu wrote:
> So the only difference between 4rd BR and lightweight AFTR is just a 
> static mapping rule for all users in the same domain (4rd BR case) and 
> group rule or user specific rule for different users (LW AFTR)?
>
> From: Jacni Qin >
> Date: Tue, 9 Aug 2011 09:23:36 +0800
> To: "Yiu L. LEE"  >
> Cc: Qiong >, 
> "softwires@ietf.org "  >
> Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
>
> hi,
>
> If I understand it correctly, a per user address/port mapping table is 
> maintained on the LW AFTR, then no session table on it.
>
>
> Cheers,
> Jacni
>
> On 8/9/2011 9:11 AM, Lee, Yiu wrote:
>> Hi Qiong,
>>
>> I see your point. So what is the difference between a lightweight 
>> AFTR and 4rd BR?
>>
>> Cheers,
>> Yiu
>>
>> From: Qiong >
>> Date: Tue, 2 Aug 2011 14:11:55 +0800
>> To: "Yiu L. LEE" > >
>> Cc: Satoru Matsushima > >, "Jan Zorz @ go6.si" 
>> >, "softwires@ietf.org 
>> " > >
>> Subject: Re: [Softwires] Clarification of the stateles/stateful 
>> discussion
>>
>> In our consideration, lightweight AFTR is not doing port-range 
>> routing. In this lightweight AFTR, it would firstly lookup a mapping 
>> table (recording [IPv6 address, IPv4 address, Port set]) for a 
>> downstream IPv4 packet. Then after IPv4 packet has been encapsulated 
>> into IPv6 packet, it will do IPv6 routing based on different IPv6 
>> addresses. So, lightweight AFTR does not need to distribute port-set 
>> info into FIB and there is no impact on existing routing architecture 
>> between B4 and AFTR.
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires

--------------030208070405080302040603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Re-,

      

      Since the "rules" are "maintained" in different ways, then the
      forwarding behaviors, for incoming traffics and CE-CE etc., are
      different, IMHO.

      

      

      Cheers,

      Jacni

    

    On 8/9/2011 9:25 AM, Lee, Yiu wrote:
    

      
      
So the only difference between 4rd BR and lightweight AFTR is
        just a static mapping rule for all users in the same domain (4rd
        BR case) and group rule or user specific rule for different
        users (LW AFTR)?

      


      

      
        

          From: Jacni Qin <jacni@jacni.com>

          Date: Tue, 9 Aug 2011
          09:23:36 +0800

          To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>

          Cc: Qiong <bingxuere@gmail.com>,
          "softwires@ietf.org"
          <softwires@ietf.org>

          Subject: Re:
          [Softwires] Clarification of the stateles/stateful discussion

        

        


        

        

          
hi,

              

              If I understand it correctly, a per user address/port
              mapping table is maintained on the LW AFTR, then no
              session table on it.

              

              

              Cheers,

              Jacni

            

            On 8/9/2011 9:11 AM, Lee, Yiu wrote:
            

              
Hi Qiong,

              


              

              
I see your point. So what is the difference between a
                lightweight AFTR and 4rd BR?

              


              

              
Cheers,

              
Yiu

              


              

              
                

                  From: Qiong
                  <bingxuere@gmail.com>

                  Date: Tue, 2
                  Aug 2011 14:11:55 +0800

                  To: "Yiu L.
                  LEE" <yiu_lee@cable.comcast.com>

                  Cc: Satoru
                  Matsushima <satoru.matsushima@gmail.com>,
                  "Jan Zorz @ go6.si" <jan@go6.si>, "softwires@ietf.org"
                  <softwires@ietf.org>

                  Subject: Re:
                  [Softwires] Clarification of the stateles/stateful
                  discussion

                

                


                

                In

                  our consideration, lightweight AFTR is not doing
                  port-range routing. In this lightweight AFTR, it would
                  firstly lookup a mapping table (recording [IPv6
                  address, IPv4 address, Port set]) for a downstream
                  IPv4 packet. Then after IPv4 packet has been
                  encapsulated into IPv6 packet, it will do IPv6 routing
                  based on different IPv6 addresses. So, lightweight
                  AFTR does not need to distribute port-set info into
                  FIB and there is no impact on existing routing
                  architecture between B4 and AFTR.
              

              

              

              
_______________________________________________
Softwires mailing list
Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires

            

          

        

      
    

  


--------------030208070405080302040603--


From yiu_lee@cable.comcast.com  Mon Aug  8 19:27:40 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C3511E8086 for ; Mon,  8 Aug 2011 19:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.341
X-Spam-Level: 
X-Spam-Status: No, score=-107.341 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmPtqJwggE7f for ; Mon,  8 Aug 2011 19:27:39 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 453D611E8070 for ; Mon,  8 Aug 2011 19:27:39 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136594744; Mon, 08 Aug 2011 22:28:01 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Mon, 8 Aug 2011 22:28:01 -0400
From: "Lee, Yiu" 
To: Jacni Qin 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVjv1T7MkY3XGIkOXtnUUZ5VJjQ==
Date: Tue, 9 Aug 2011 02:28:00 +0000
Message-ID: 
In-Reply-To: <4E409A12.3050706@jacni.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [68.82.30.70]
Content-Type: multipart/alternative; boundary="_000_CA66127013757yiuleecablecomcastcom_"
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 02:27:40 -0000

--_000_CA66127013757yiuleecablecomcastcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agree that the CE-CE communication will be possible for LW AFTR because the=
 rules are not store in the CE but in the LW AFTR.

But my main question is both technical are so similar, can we have a sessio=
n in 4rd to extend this special scenario rather than writing a new draft fo=
r it?

From: Jacni Qin >
Date: Tue, 9 Aug 2011 10:23:14 +0800
To: "Yiu L. LEE" >
Cc: Qiong >, "softwires@iet=
f.org" >
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion

Re-,

Since the "rules" are "maintained" in different ways, then the forwarding b=
ehaviors, for incoming traffics and CE-CE etc., are different, IMHO.


Cheers,
Jacni

--_000_CA66127013757yiuleecablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Agree that the CE-CE communication will be possible for LW AFTR becaus=
e the rules are not store in the CE but in the LW AFTR.







But my main question is both technical are so similar, can we have a s=
ession in 4rd to extend this special scenario rather than writing a new dra=
ft for it? 









From: Jacni Qin <jacni@jacni.com>

Date: Tue, 9 Aug 2011 10:23:14 +=
;0800

To: "Yiu L. LEE" <yiu_lee@cable.comcast.com><=
br>
Cc: Qiong <bingxuere@gmail.com>, "softwires@ietf.org" <softwires@ietf.org>

Subject: Re: [Softwires] Clarificat=
ion of the stateles/stateful discussion








Re-,



Since the "rules" are "maintained" in different ways, t=
hen the forwarding behaviors, for incoming traffics and CE-CE etc., are dif=
ferent, IMHO.





Cheers,

Jacni



--_000_CA66127013757yiuleecablecomcastcom_--

From jacni@jacni.com  Mon Aug  8 19:58:01 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83221F8A80 for ; Mon,  8 Aug 2011 19:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level: 
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.373,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2O84XK72Dr7 for ; Mon,  8 Aug 2011 19:58:00 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id D671C21F8A70 for ; Mon,  8 Aug 2011 19:58:00 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id DB5263801E3 for ; Mon,  8 Aug 2011 22:58:26 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 736ED340116 for ; Tue,  9 Aug 2011 10:58:25 +0800 (CST)
Received: from [172.23.204.210] (unknown [112.64.190.234]) by app (Coremail) with SMTP id +AWowJBrcwM6okBOigxJAA--.42461S2; Tue, 09 Aug 2011 10:58:21 +0800 (CST)
Message-ID: <4E40A278.1050002@jacni.com>
Date: Tue, 09 Aug 2011 10:59:04 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Lee, Yiu" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050401030601000207090600"
X-CM-TRANSID: +AWowJBrcwM6okBOigxJAA--.42461S2
X-Coremail-Antispam: 1UD129KBjvJXoW7JFW8Gw1rXFy5Wr1fJw4fZrb_yoW8JryfpF W7Xr98tFs7W3WfGrs7ua1F9w4vgFZ3G3sxJFnFgrWqy3Z8Ga40gr4ay3WYvFyUWay8XF4Y gw4j9FykGa9avFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU4Gb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6r1S6rWUM2kK64x0aVW7Gw IE548m6rI_Jw1UWr17M2kK64x0aVW7GwIE548m6rv_Jw1UWr17M2kK6xCIbVAIwIAEc20F 6c8GOVW8Jr15Jr4lnx0Ec2IEnICE548m6r1DJrWUZwAv7VC0I7IYx2IY67AKxVWUJVWUGw Av7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0 xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4IxY624lx4CE17CEb7AF67AKxV WUXVWUAwCIc40Y0x0EwIxGrbIYCTnIWIevJa73UjIFyTuYvjxUaJKsUUUUU
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEOEko7lM+GRgANs7
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 02:58:01 -0000

This is a multi-part message in MIME format.
--------------050401030601000207090600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hi Yiu,

On 8/9/2011 10:28 AM, Lee, Yiu wrote:
> Agree that the CE-CE communication will be possible for LW AFTR 
> because the rules are not store in the CE but in the LW AFTR.
>
> But my main question is both technical are so similar, can we have a 
> session in 4rd to extend this special scenario rather than writing a 
> new draft for it?

Sorry, I don't follow and please correct me if I made mistakes,
In the LW AFTR approach, the CE gets its port range, and the LW AFTR 
maintain the binding info. per user. The CE-CE communications have to 
pass through LW AFTR. The LW AFTR forwards incoming traffics based on 
the binding table.
In 4rd, the rule is identical within one domain (on both CEs, and BR), 
then the CE can calculate Src/Dst of IPv6 encapsulation and route the 
packets to the other CEs.


Cheers,
Jacni

>
> From: Jacni Qin >
> Date: Tue, 9 Aug 2011 10:23:14 +0800
> To: "Yiu L. LEE"  >
> Cc: Qiong >, 
> "softwires@ietf.org "  >
> Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
>
> Re-,
>
> Since the "rules" are "maintained" in different ways, then the 
> forwarding behaviors, for incoming traffics and CE-CE etc., are 
> different, IMHO.
>
>
> Cheers,
> Jacni 

--------------050401030601000207090600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    hi Yiu,

    

    On 8/9/2011 10:28 AM, Lee, Yiu wrote:
    

      
      
Agree that the CE-CE communication will be possible for LW
        AFTR because the rules are not store in the CE but in the LW
        AFTR.

      


      

      
But my main question is both technical are so similar, can we
        have a session in 4rd to extend this special scenario rather
        than writing a new draft for it? 

      

    

    

    Sorry, I don't follow and please correct me if I made mistakes,

    In the LW AFTR approach, the CE gets its port range, and the LW AFTR
    maintain the binding info. per user. The CE-CE communications have
    to pass through LW AFTR. The LW AFTR forwards incoming traffics
    based on the binding table.

    In 4rd, the rule is identical within one domain (on both CEs, and
    BR), then the CE can calculate Src/Dst of IPv6 encapsulation and
    route the packets to the other CEs.

    

    

    Cheers,

    Jacni

    

    

      


      

      
        

          From: Jacni Qin <jacni@jacni.com>

          Date: Tue, 9 Aug 2011
          10:23:14 +0800

          To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>

          Cc: Qiong <bingxuere@gmail.com>,
          "softwires@ietf.org"
          <softwires@ietf.org>

          Subject: Re:
          [Softwires] Clarification of the stateles/stateful discussion

        

        


        

        Re-,

          

          Since the "rules" are "maintained" in different ways, then the
          forwarding behaviors, for incoming traffics and CE-CE etc.,
          are different, IMHO.

          

          

          Cheers,

          Jacni
    

  


--------------050401030601000207090600--


From weapon@csnet1.cs.tsinghua.edu.cn  Mon Aug  8 20:02:00 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0F222800F for ; Mon,  8 Aug 2011 20:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.429
X-Spam-Level: **
X-Spam-Status: No, score=2.429 tagged_above=-999 required=5 tests=[AWL=0.877,  BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwtpZN4N5uix for ; Mon,  8 Aug 2011 20:01:59 -0700 (PDT)
Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2D07F22800D for ; Mon,  8 Aug 2011 20:01:39 -0700 (PDT)
Received: from PengWu-laptop (unknown [144.214.105.209]) by mail.csnet1.cs.tsinghua.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id 1A0861B0404B5; Tue,  9 Aug 2011 11:02:02 +0800 (CST)
Date: Tue, 9 Aug 2011 11:02:00 +0800
From: "Peng Wu" 
To: "Lee, Yiu" , "Jacni Qin" 
References: 
Message-ID: <201108091101592724491@csnet1.cs.tsinghua.edu.cn>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 03:02:00 -0000

Hi Yiu and all,
>Agree that the CE-CE communication will be possible for LW AFTR because the rules are not store in the CE but in the LW AFTR.
                      Should be CE--LW AFTR--CE style, is that what you mean here?
>But my main question is both technical are so similar, can we have a session in 4rd to extend this special scenario rather than writing a new draft for it?
                      Not sure about it. The thing is that it's lightweight state while 4rd is stateless. Addressing is different.


From yiu_lee@cable.comcast.com  Mon Aug  8 20:03:32 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D8F11E8091 for ; Mon,  8 Aug 2011 20:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.621
X-Spam-Level: 
X-Spam-Status: No, score=-107.621 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwvKsI95KvH0 for ; Mon,  8 Aug 2011 20:03:32 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id E170811E8070 for ; Mon,  8 Aug 2011 20:03:31 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136595728; Mon, 08 Aug 2011 23:03:56 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 8 Aug 2011 23:03:56 -0400
From: "Lee, Yiu" 
To: Jacni Qin 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVkD5a7fQaNGG30OJkAoZwSa3BQ==
Date: Tue, 9 Aug 2011 03:03:55 +0000
Message-ID: 
In-Reply-To: <4E40A278.1050002@jacni.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [68.82.30.70]
Content-Type: multipart/alternative; boundary="_000_CA661BC413764yiuleecablecomcastcom_"
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 03:03:32 -0000

--_000_CA661BC413764yiuleecablecomcastcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Oops. Typo. I mean "won't be possible". Sorry for the confusion.

From: Jacni Qin >
Date: Tue, 9 Aug 2011 10:59:04 +0800
To: "Yiu L. LEE" >
Cc: Qiong >, "softwires@iet=
f.org" >
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion

hi Yiu,

On 8/9/2011 10:28 AM, Lee, Yiu wrote:
Agree that the CE-CE communication will be possible for LW AFTR because the=
 rules are not store in the CE but in the LW AFTR.

But my main question is both technical are so similar, can we have a sessio=
n in 4rd to extend this special scenario rather than writing a new draft fo=
r it?

Sorry, I don't follow and please correct me if I made mistakes,
In the LW AFTR approach, the CE gets its port range, and the LW AFTR mainta=
in the binding info. per user. The CE-CE communications have to pass throug=
h LW AFTR. The LW AFTR forwards incoming traffics based on the binding tabl=
e.
In 4rd, the rule is identical within one domain (on both CEs, and BR), then=
 the CE can calculate Src/Dst of IPv6 encapsulation and route the packets t=
o the other CEs.


Cheers,
Jacni


From: Jacni Qin >
Date: Tue, 9 Aug 2011 10:23:14 +0800
To: "Yiu L. LEE" >
Cc: Qiong >, "softwires@iet=
f.org" >
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion

Re-,

Since the "rules" are "maintained" in different ways, then the forwarding b=
ehaviors, for incoming traffics and CE-CE etc., are different, IMHO.


Cheers,
Jacni

--_000_CA661BC413764yiuleecablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <8026A1E505174241B71E3559436CF305@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable







Oops. Typo. I mean "won't be possible". Sorry for the confus=
ion.









From: Jacni Qin <jacni@jacni.com>

Date: Tue, 9 Aug 2011 10:59:04 +=
;0800

To: "Yiu L. LEE" <yiu_lee@cable.comcast.com><=
br>
Cc: Qiong <bingxuere@gmail.com>, "softwires@ietf.org" <softwires@ietf.org>

Subject: Re: [Softwires] Clarificat=
ion of the stateles/stateful discussion











hi Yiu,



On 8/9/2011 10:28 AM, Lee, Yiu wrote:



Agree that the CE-CE communication will be possible for LW AFTR becaus=
e the rules are not store in the CE but in the LW AFTR.







But my main question is both technical are so similar, can we have a s=
ession in 4rd to extend this special scenario rather than writing a new dra=
ft for it?








Sorry, I don't follow and please correct me if I made mistakes,

In the LW AFTR approach, the CE gets its port range, and the LW AFTR mainta=
in the binding info. per user. The CE-CE communications have to pass throug=
h LW AFTR. The LW AFTR forwards incoming traffics based on the binding tabl=
e.

In 4rd, the rule is identical within one domain (on both CEs, and BR), then=
 the CE can calculate Src/Dst of IPv6 encapsulation and route the packets t=
o the other CEs.





Cheers,

Jacni













From: Jacni Qin <jacni@jacni.com>

Date: Tue, 9 Aug 2011 10:23:14 +=
;0800

To: "Yiu L. LEE" <yiu_lee@c=
able.comcast.com>

Cc: Qiong <bingxuere@gmail.com>, &qu=
ot;softwires=
@ietf.org" <softwires@ietf.org>

Subject: Re: [Softwires] Clarificat=
ion of the stateles/stateful discussion








Re-,



Since the "rules" are "maintained" in different ways, t=
hen the forwarding behaviors, for incoming traffics and CE-CE etc., are dif=
ferent, IMHO.





Cheers,

Jacni 









--_000_CA661BC413764yiuleecablecomcastcom_--

From yiu_lee@cable.comcast.com  Mon Aug  8 20:57:06 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD5A21F86C4 for ; Mon,  8 Aug 2011 20:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.426
X-Spam-Level: 
X-Spam-Status: No, score=-104.426 tagged_above=-999 required=5 tests=[AWL=-2.691, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1EhL3P2D4ln for ; Mon,  8 Aug 2011 20:57:05 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id A42BA21F86CA for ; Mon,  8 Aug 2011 20:57:05 -0700 (PDT)
Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.48040030; Mon, 08 Aug 2011 22:00:04 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 8 Aug 2011 23:54:53 -0400
From: "Lee, Yiu" 
To: "softwires@ietf.org" 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVkgXw5FSQJDBskWQ6QVQ5NfXOA==
Date: Tue, 9 Aug 2011 03:54:52 +0000
Message-ID: 
In-Reply-To: <201108091101592724491@csnet1.cs.tsinghua.edu.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [68.82.30.70]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <03FFC481D87C734993C39037BA6D19AC@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 03:57:06 -0000

Couple thoughts.

1. The current draft doesn't specify the static mapping rule like what 4rd
does. So I guess we can't compare this to 4rd.

2. I keep thinking what are the difference of this and PRR. I guess
Qiong's PRR definition is the forwarding decision would be done in the
FIB. I don't disagree with this. My argument is the AFTR will need to use
the port-range to find out the next-hop (the b4's IPv6 address). The
difference between this and the PRR is the information is stored in the
NAT table rather than the routing table. But the general idea is the same.



On 8/8/11 11:02 PM, "Peng Wu"  wrote:

>Hi Yiu and all,
>>Agree that the CE-CE communication will be possible for LW AFTR because
>>the rules are not store in the CE but in the LW AFTR.
>                      Should be CE--LW AFTR--CE style, is that what you
>mean here?
>>But my main question is both technical are so similar, can we have a
>>session in 4rd to extend this special scenario rather than writing a new
>>draft for it?
>                      Not sure about it. The thing is that it's
>lightweight state while 4rd is stateless. Addressing is different.
>


From weapon@csnet1.cs.tsinghua.edu.cn  Mon Aug  8 21:03:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8320A11E808A for ; Mon,  8 Aug 2011 21:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.99
X-Spam-Level: *
X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDV3lGxOU8Mf for ; Mon,  8 Aug 2011 21:03:55 -0700 (PDT)
Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id DF04411E8086 for ; Mon,  8 Aug 2011 21:03:54 -0700 (PDT)
Received: from PengWu-laptop (unknown [144.214.105.209]) by mail.csnet1.cs.tsinghua.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id 8E4AF1B0404B5; Tue,  9 Aug 2011 12:04:17 +0800 (CST)
Date: Tue, 9 Aug 2011 12:04:16 +0800
From: "Peng Wu" 
To: "Lee, Yiu" , "softwires@ietf.org" 
References: 
Message-ID: <201108091204137366147@csnet1.cs.tsinghua.edu.cn>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 04:03:55 -0000

Hi Yiu,

Agree, both.

>Couple thoughts.
>
>1. The current draft doesn't specify the static mapping rule like what 4rd
>does. So I guess we can't compare this to 4rd.
>
>2. I keep thinking what are the difference of this and PRR. I guess
>Qiong's PRR definition is the forwarding decision would be done in the
>FIB. I don't disagree with this. My argument is the AFTR will need to use
>the port-range to find out the next-hop (the b4's IPv6 address). The
>difference between this and the PRR is the information is stored in the


From xiaohong.deng@orange-ftgroup.com  Mon Aug  8 21:06:53 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0241B11E80A8 for ; Mon,  8 Aug 2011 21:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level: 
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eaZLVN2Ik7e for ; Mon,  8 Aug 2011 21:06:52 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5F311E808A for ; Mon,  8 Aug 2011 21:06:52 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7D3306FCC07; Tue,  9 Aug 2011 06:15:47 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 46E6F6FCC09; Tue,  9 Aug 2011 06:15:47 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 9 Aug 2011 06:03:47 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Aug 2011 12:03:41 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01918FB1@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <201108081431283721107@csnet1.cs.tsinghua.edu.cn>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: [Softwires] Softwire Interim meeting
Thread-Index: AcxVlNqFJXJQEm40T3uKC4vXMYPa7AAsipMw
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>,  <201108081431283721107@csnet1.cs.tsinghua.edu.cn>
From: 
To: , , 
X-OriginalArrivalTime: 09 Aug 2011 04:03:47.0920 (UTC) FILETIME=[57013500:01CC5649]
Cc: softwires@ietf.org, rdroms@cisco.com
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 04:06:53 -0000

=20

|-----Original Message-----
|From: Peng Wu [mailto:weapon@csnet1.cs.tsinghua.edu.cn]=20
|Sent: Monday, August 08, 2011 2:32 PM
|To: DENG Xiaohong ESP/PEK; adurand@juniper.net; mark@townsley.net
|Cc: softwires; rdroms
|Subject: Re: Re: [Softwires] Softwire Interim meeting
|
|In my experience, the crowdness of  Golden Week begins at=20
|29-30th. So unless you have trips plans after the meeting, the=20
|dates are fine. 26-27th are probably better.
|Just remember to run away in time after the meeting, ha:)
|
|Another fact is that it's a little difficult to get train=20
|tickets near the Golden Week. Not sure about the high speed=20

Don't think you your first fact and the second fact are confilict to =
each other?=20

|line since it just start this year and the price is much=20
|higher than reguler ones. Anyway if this Interim meeting takes=20
|place in Beijing, just take flight back from Beijing=20
|afterwards rather than go back to Shanghai first.

To my experience, it's niether that high nor that hard to get high speed =
train
tickets.

Note that discount ticket of flight between Shanghai and Beijing are =
always=20
available even during holidays, as there are frequent flights, but the =
total price
woule be the same or even higher than high way train ticket.

As far as myself concerned, would rather take high speed train to avoid =
possible=20
flight delay,  transport (traffic jams)  from/to airport, and waiting at =
airport...

Xiaohong

|------------------				=20
|Peng Wu
|PhD candidate
|Department of Computer Science & Technology Tsinghua=20
|University, Beijing, China
|
|-------------------------------------------------------------
|From=A3=BAxiaohong.deng
|Date=A3=BA2011-08-08 11:59:44
|To=A3=BAadurand@juniper.net; mark@townsley.net
|CC=A3=BAsoftwires; rdroms
|Subject=A3=BARe: [Softwires] Softwire Interim meeting
|
|>Either Shanghai or Beijing will do. Just some pieces of info:
|> Autumn is definitely the best season in Beijing! With fabulous views=20
|>and weather! ;) And there is a high speed railway between=20
|Shanghai and=20
|>Beijing, costing 60 Euros approximately. Please also note=20
|that 26-27th=20
|>or 27-28th is near the Chinese Golden week in China beginning=20
|with Oct.
|>1st, during which a lot visitors will rush into either Beijing or=20
|>Shanghai. So some time before Broadband forum may give us a better=20
|>alternative.
|>
|>Xiaohong
|>
|>|On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:
|>|
|>|> Following-up on the Quebec meeting, we would like to
|>|organize an interim meeting end of September.
|>|> We will focus on so-called stateless solutions and other remaining=20
|>|> business in the wg (multicast. mibs,...) that require more
|>|time than we usually have during a normal IETF meeting.
|>|> The format will be a 2 day intensive meeting, with white
|>|board discussions, similar to what we did in the early days of the=20
|>|working group.
|>|>=20
|>|> We've got an offer to host the meeting in Beijin on Sept.=20
|>|26-27th or 27-28th (right after the Boradband forum meeting in=20
|>|Shanghai).
|>|
|>|Would it be possible to keep it in the same city as the BBF to cut=20
|>|down travel/costs a bit more for those going to both?
|>|
|>|- Mark
|>|
|>|> Yong and I would like to make a decision soon, please send
|>|us email directly if you intend to come and tell us which=20
|set of dates=20
|>|is more convenient.
|>|> Please respond by August 11th, we will formally announce the
|>|meeting with the logistic information end of next week.
|>|>=20
|>|> Alain & Yong.
|>|>=20
|>|>=20
|>|>=20
|>|> _______________________________________________
|>|> Softwires mailing list
|>|> Softwires@ietf.org
|>|> https://www.ietf.org/mailman/listinfo/softwires
|>|
|>|
|>|
|>_______________________________________________
|>Softwires mailing list
|>Softwires@ietf.org
|>https://www.ietf.org/mailman/listinfo/softwires
|>
|>!DSPAM:1,4e3f5f3030895923771071!
|>
|>
|

From bingxuere@gmail.com  Mon Aug  8 23:43:16 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061AF11E8093 for ; Mon,  8 Aug 2011 23:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.369
X-Spam-Level: 
X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO2RH3WM-UsE for ; Mon,  8 Aug 2011 23:43:15 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6D71211E808A for ; Mon,  8 Aug 2011 23:43:15 -0700 (PDT)
Received: by iye1 with SMTP id 1so10108290iye.27 for ; Mon, 08 Aug 2011 23:43:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cpt3hglRl9BU1U9jkw7iw47bLwWFkhKgjf55XKZQnW8=; b=j7AXnPrjYeCeduDxhn3OpjBbobTyvWmUXH8FOmNdeA+Gq7eufpUxqt9mZGJCCkSpZw 3OGzWi8Mw4vyE6d9Xcpj4JwBvNyAd/4st80d3sS8/891GOq27wnACWv9mH7sx4XIOqQ5 QPWfj55V5RoC1GwNQ5p/aUWXA8EZqML7e1rvo=
Received: by 10.231.6.40 with SMTP id 40mr6976091ibx.80.1312872223196; Mon, 08 Aug 2011 23:43:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.38.5 with HTTP; Mon, 8 Aug 2011 23:43:23 -0700 (PDT)
In-Reply-To: <43C12B92-3F8F-4406-880A-8FC05EEC0490@laposte.net>
References:    <43C12B92-3F8F-4406-880A-8FC05EEC0490@laposte.net>
From: Qiong 
Date: Tue, 9 Aug 2011 14:43:23 +0800
Message-ID: 
To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= 
Content-Type: multipart/alternative; boundary=0015177403b47fc76404aa0ce241
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 06:43:16 -0000

--0015177403b47fc76404aa0ce241
Content-Type: text/plain; charset=UTF-8

Hi, Remi,

Thanks for your interests on 'Lightweight 4over6'.  Please see inline.

Clarifying what is meant by "stateless" in different contexts is highly
> desirable.
>
> The objective of the 4rd address mapping is
> - no "per customer" state in provider nodes (BR, AFTR...)
> - direct customer-customer paths made possible
>
> The 'Lightweight 4over6' proposal has in my understanding a different
> objective: flexible port sets assignable to each individual customer.
>
[Qiong]: Yes. And in addition, its objective is also to achieve 'lightweight
addressing and routing' with no special requirements on IPv6 address format.




> It can therefore coexist with one or both "per-sustomer-stateless"
> solution(s) (with encapsulation and/or double-translation).
>
[Qiong]: Sorry, I'm not quite clear of 'per-customer-stateless' solution. Is
it for the ones where different customers have different IPv6 prefixes and
then embedded with IPv4 address?
For example:
user1_v6 = user1_prefix+user1_v4+suffix;
user2_v6 = user2_prefix+user2_v4+suffix;
...
where user1_prefix != user2_prefix

Is it right?

Thanks

Best regards.

Qiong Sun

--0015177403b47fc76404aa0ce241
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Remi,

Thanks for your interests on 'Lightweight =
4over6'. =C2=A0Please see inline.




Clarifying what is meant by "=
stateless" in different contexts is highly desirable.

The objective of the 4rd address mapping is
- no "p=
er customer" state in provider nodes (BR, AFTR...)



- direct customer-customer paths made possible

The 'Lightweight 4over6'=C2=A0proposal has in my understanding a =
different objective: flexible port sets assignable to each individual custo=
mer.



[Qiong]: Yes. And in addition, its objective is als=
o to achieve 'lightweight addressing and routing' with no special r=
equirements on IPv6 address format. =C2=A0

=C2=A0<=
/div>



It can therefore coexist with one =
or both "per-sustomer-stateless" solution(s) (with encapsulation =
and/or double-translation).
[Qiong]: Sorry, I&=
#39;m not quite clear of 'per-customer-stateless' solution. Is it f=
or the ones where different customers have different IPv6 prefixes and then=
 embedded with IPv4 address?



For example:
user1_v6 =3D user1_prefix+user1_v4+suffix;
user2_v6 =3D user2_prefix+user2_v4+suffix;
...
wh=
ere user1_prefix !=3D user2_prefix

Is it right?



Thanks

Best regards.

Qiong Sun



--0015177403b47fc76404aa0ce241--

From bingxuere@gmail.com  Mon Aug  8 23:48:23 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E6E11E8093 for ; Mon,  8 Aug 2011 23:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.516
X-Spam-Level: 
X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlLdJklKm0EZ for ; Mon,  8 Aug 2011 23:48:22 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A211E807F for ; Mon,  8 Aug 2011 23:48:22 -0700 (PDT)
Received: by iye1 with SMTP id 1so10115403iye.27 for ; Mon, 08 Aug 2011 23:48:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Ycp0itOemOclHrpia2Hu70EtiJaEr9idlkm5Uiky78=; b=Aar3ul+HiW/90uETo8hOGqtNv5FptOHTe/EbCAIaXxgIg4qBM7jRQTl4oEk95a+Q6X SyGVXLVTzxB+O06k91aXuPoSm8MHjQ531DWmaVmzIEiQzilffpu3aG4VZe9FOIqZu8y/ CP3Qp+ls/GZQx3K/0fX6aVGaX7ncTKK5Q8mCs=
Received: by 10.42.156.71 with SMTP id y7mr6085425icw.425.1312872530315; Mon, 08 Aug 2011 23:48:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.38.5 with HTTP; Mon, 8 Aug 2011 23:48:30 -0700 (PDT)
In-Reply-To: 
References: <4E408C18.8030301@jacni.com> 
From: Qiong 
Date: Tue, 9 Aug 2011 14:48:30 +0800
Message-ID: 
To: "Lee, Yiu" 
Content-Type: multipart/alternative; boundary=90e6ba6e8bbcce092d04aa0cf486
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 06:48:23 -0000

--90e6ba6e8bbcce092d04aa0cf486
Content-Type: text/plain; charset=UTF-8

Hi Yiu, Jacni,

On Tue, Aug 9, 2011 at 9:25 AM, Lee, Yiu  wrote:

>  So the only difference between 4rd BR and lightweight AFTR is just a
> static mapping rule for all users in the same domain (4rd BR case) and group
> rule or user specific rule for different users (LW AFTR)?
>

[Qiong]: Agree. And LW AFTR will not expose port-set information in IPv6
address directly.  So it would not introduce any specific requirements on
IPv6 address format. I think this is also a major difference between 4rd and
Lightweight 4over6.

Best regards.

Qiong Sun

--90e6ba6e8bbcce092d04aa0cf486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yiu, Jacni,

On Tue, Aug 9, 2011 at 9:2=
5 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:









So the only difference between 4rd BR and lightweight AFTR is just a s=
tatic mapping rule for all users in the same domain (4rd BR case) and group=
 rule or user specific rule for different users (LW AFTR)?




[Qiong]: Agree. And LW AFTR will not expos=
e port-set information in IPv6 address directly. =C2=A0So it would not intr=
oduce any=C2=A0specific=C2=A0requirements on IPv6 address format. I think t=
his is also a major difference between 4rd and Lightweight 4over6.




Best regards.

Qiong Sun
<=
/div>

--90e6ba6e8bbcce092d04aa0cf486--

From satoru.matsushima@gmail.com  Tue Aug  9 00:10:26 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AB921F8760 for ; Tue,  9 Aug 2011 00:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmb0xJVB6wWW for ; Tue,  9 Aug 2011 00:10:25 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA4221F875E for ; Tue,  9 Aug 2011 00:10:25 -0700 (PDT)
Received: by ywm21 with SMTP id 21so3593683ywm.31 for ; Tue, 09 Aug 2011 00:10:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=sxRYiX77AZC5e63gYlnQEXH9t9NCpg9kLM3FbqLeKaw=; b=Pc2z/GVNiT4CEQmixPBXtPu3JU5KUZ7QbAhcIEk6Yh9iQr7MSiaC0pIPhvge5kLIBi 496XvsEzcrIwiuZRMAB3akmMWtzRZKuJngCZw9OiOLhSYB+d8egdQ2SIcOZ9yUasTopH kLRPm5XGvq0ekh3VY4vgKCZxngLuVE78e8pBM=
Received: by 10.42.168.198 with SMTP id x6mr6972639icy.148.1312873853039; Tue, 09 Aug 2011 00:10:53 -0700 (PDT)
Received: from [10.42.46.96] (pw126195162230.109.tss.panda-world.ne.jp [126.195.162.230]) by mx.google.com with ESMTPS id n18sm3137582ibg.52.2011.08.09.00.10.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 00:10:50 -0700 (PDT)
References: <4E408C18.8030301@jacni.com>  
In-Reply-To: 
Mime-Version: 1.0 (iPad Mail 8K2)
Content-Type: multipart/alternative; boundary=Apple-Mail-80--440800919
Message-Id: <4819CBA3-5D23-405E-92D9-40673E4D7535@gmail.com>
Content-Transfer-Encoding: 7bit
X-Mailer: iPad Mail (8K2)
From: Satoru Matsushima 
Date: Tue, 9 Aug 2011 16:10:40 +0900
To: Qiong 
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 07:10:26 -0000

--Apple-Mail-80--440800919
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Qiong,

in fact, 4rd doesn't require specific format to ipv6 address.
what do you find in 4rd?

--satoru sent from my iPad

On 2011/08/09, at 15:48, Qiong  wrote:

> Hi Yiu, Jacni,
>=20
> On Tue, Aug 9, 2011 at 9:25 AM, Lee, Yiu  wrote=
:
> So the only difference between 4rd BR and lightweight AFTR is just a stati=
c mapping rule for all users in the same domain (4rd BR case) and group rule=
 or user specific rule for different users (LW AFTR)?
>=20
> [Qiong]: Agree. And LW AFTR will not expose port-set information in IPv6 a=
ddress directly.  So it would not introduce any specific requirements on IPv=
6 address format. I think this is also a major difference between 4rd and Li=
ghtweight 4over6.
>=20
> Best regards.
>=20
> Qiong Sun
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--Apple-Mail-80--440800919
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=utf-8


Hi Qiong,

in fact, 4rd doesn't require specific format to ipv6 address.
what do you find in 4rd?

--satoru sent from my iPad

On 2011/08/09, at 15:48, Qiong <bingxuere@gmail.com> wrote:

Hi Yiu, Jacni,

On Tue, Aug 9, 2011 at 9:25 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:









So the only difference between 4rd BR and lightweight AFTR is just a static mapping rule for all users in the same domain (4rd BR case) and group rule or user specific rule for different users (LW AFTR)?




[Qiong]: Agree. And LW AFTR will not expose port-set information in IPv6 address directly.  So it would not introduce any specific requirements on IPv6 address format. I think this is also a major difference between 4rd and Lightweight 4over6.




Best regards.

Qiong Sun


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

--Apple-Mail-80--440800919--

From despres.remi@laposte.net  Tue Aug  9 00:16:23 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2993F11E80A5 for ; Tue,  9 Aug 2011 00:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.727
X-Spam-Level: 
X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAXnj-c8K1+K for ; Tue,  9 Aug 2011 00:16:22 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4165011E80A6 for ; Tue,  9 Aug 2011 00:16:22 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 547A07000087; Tue,  9 Aug 2011 09:16:49 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 8A166700008C; Tue,  9 Aug 2011 09:16:48 +0200 (CEST)
X-SFR-UUID: 20110809071648565.8A166700008C@msfrf2403.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-80--440440693
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Tue, 9 Aug 2011 09:16:48 +0200
Message-Id: <0C74C5C2-AB93-465B-BF48-0492801EC7B5@laposte.net>
References:    <43C12B92-3F8F-4406-880A-8FC05EEC0490@laposte.net> 
To: Qiong 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 07:16:23 -0000

--Apple-Mail-80--440440693
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi, Qiong,

Le 9 ao=FBt 2011 =E0 08:43, Qiong a =E9crit :

> Hi, Remi,
>=20
> Thanks for your interests on 'Lightweight 4over6'.  Please see inline.
>=20
> Clarifying what is meant by "stateless" in different contexts is =
highly desirable.
>=20
> The objective of the 4rd address mapping is
> - no "per customer" state in provider nodes (BR, AFTR...)
> - direct customer-customer paths made possible
>=20
> The 'Lightweight 4over6' proposal has in my understanding a different =
objective: flexible port sets assignable to each individual customer.
> [Qiong]: Yes. And in addition, its objective is also to achieve =
'lightweight addressing and routing' with no special requirements on =
IPv6 address format. =20
>=20
> =20
> It can therefore coexist with one or both "per-sustomer-stateless" =
solution(s) (with encapsulation and/or double-translation).

> [Qiong]: Sorry, I'm not quite clear of 'per-customer-stateless' =
solution. Is it for the ones where different customers have different =
IPv6 prefixes and then embedded with IPv4 address?

It simply means that the number parameters of the address mapping =
algorithm is not related to the number of customer sites.

The number of these parameters generally depends on the number of =
disjoint IPv4 prefixes that the ISP has to support (typically just a =
few), while tens of thousands or millions of customers can be supported.

Regards,
RD=20


> For example:
> user1_v6 =3D user1_prefix+user1_v4+suffix;
> user2_v6 =3D user2_prefix+user2_v4+suffix;
> ...
> where user1_prefix !=3D user2_prefix
>=20
> Is it right?
>=20
> Thanks
>=20
> Best regards.
>=20
> Qiong Sun
>=20


--Apple-Mail-80--440440693
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Hi, =
Qiong,

Le 9 ao=FBt 2011 =E0 08:43, Qiong a =E9crit =
:

Hi, Remi,

Thanks for your interests on =
'Lightweight 4over6'.  Please see inline.




Clarifying what is meant by =
"stateless" in different contexts is highly =
desirable.

The objective of the 4rd address =
mapping is
- no "per customer" state in provider nodes (BR, =
AFTR...)



- direct customer-customer paths made =
possible

The 'Lightweight 4over6' proposal =
has in my understanding a different objective: flexible port sets =
assignable to each individual customer.



[Qiong]: Yes. And in addition, its objective is =
also to achieve 'lightweight addressing and routing' with no special =
requirements on IPv6 address format. =
 

 




It can therefore coexist with =
one or both "per-sustomer-stateless" solution(s) (with encapsulation =
and/or =
double-translation).

=

[Qiong]: =
Sorry, I'm not quite clear of 'per-customer-stateless' solution. Is it =
for the ones where different customers have different IPv6 prefixes and =
then embedded with IPv4 =
address?

It =
simply means that the number parameters of the address mapping algorithm =
is not related to the number of customer =
sites.

The number of these parameters generally =
depends on the number of disjoint IPv4 prefixes that the ISP has to =
support (typically just a few), while tens of thousands or millions of =
customers can be =
supported.

Regards,
RD 





For example:
user1_v6 =3D =
user1_prefix+user1_v4+suffix;
user2_v6 =3D =
user2_prefix+user2_v4+suffix;
...
where user1_prefix =
!=3D user2_prefix

Is it right?




Thanks

Best =
regards.

Qiong Sun




=

--Apple-Mail-80--440440693--


From roberta.maglione@telecomitalia.it  Tue Aug  9 08:17:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4529821F8736 for ; Tue,  9 Aug 2011 08:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.187
X-Spam-Level: *
X-Spam-Status: No, score=1.187 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f56JPZ9V3mUt for ; Tue,  9 Aug 2011 08:17:43 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB221F86C1 for ; Tue,  9 Aug 2011 08:17:37 -0700 (PDT)
Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Aug 2011 17:18:03 +0200
Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 9 Aug 2011 17:18:02 +0200
From: Maglione Roberta 
To: 'Peng Wu' , "xiaohong.deng@orange-ftgroup.com" ,  "adurand@juniper.net" , "mark@townsley.net" 
Date: Tue, 9 Aug 2011 17:18:02 +0200
Thread-Topic: [Softwires] Softwire Interim meeting
Thread-Index: AcxVlQPMSfcc7NeySTyhj0iFpPbMAwBEcl/g
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D6A@GRFMBX704BA020.griffon.local>
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>,  <201108081431283721107@csnet1.cs.tsinghua.edu.cn>
In-Reply-To: <201108081431283721107@csnet1.cs.tsinghua.edu.cn>
Accept-Language: en-US, it-IT
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, it-IT
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: softwires , rdroms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 15:17:44 -0000

SGkgQWxsLA0KICBBcyBpbiBvcmRlciB0byBnZXQgYSB2aXNhIGZvciBDaGluYSB3ZSBuZWVkIHRv
IGhhdmUgdGhlIGZsaWdodCB0aWNrZXQsIEkgd2FzIHdvbmRlcmluZyBpZiBpdCB3b3VsZCBiZSBw
b3NzaWJsZSB0byBmaW5hbGl6ZSB0aGUgZGF0ZXMgZm9yIGludGVyaW0gbWVldGluZy4NCg0KVGhh
bmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZW5nIFd1DQpTZW50OiBsdW5lZKisIDggYWdvc3RvIDIw
MTEgOC4zMg0KVG86IHhpYW9ob25nLmRlbmdAb3JhbmdlLWZ0Z3JvdXAuY29tOyBhZHVyYW5kQGp1
bmlwZXIubmV0OyBtYXJrQHRvd25zbGV5Lm5ldA0KQ2M6IHNvZnR3aXJlczsgcmRyb21zDQpTdWJq
ZWN0OiBSZTogW1NvZnR3aXJlc10gU29mdHdpcmUgSW50ZXJpbSBtZWV0aW5nDQoNCkluIG15IGV4
cGVyaWVuY2UsIHRoZSBjcm93ZG5lc3Mgb2YgIEdvbGRlbiBXZWVrIGJlZ2lucyBhdCAyOS0zMHRo
LiBTbyB1bmxlc3MgeW91IGhhdmUgdHJpcHMgcGxhbnMgYWZ0ZXIgdGhlIG1lZXRpbmcsIHRoZSBk
YXRlcyBhcmUgZmluZS4gMjYtMjd0aCBhcmUgcHJvYmFibHkgYmV0dGVyLg0KSnVzdCByZW1lbWJl
ciB0byBydW4gYXdheSBpbiB0aW1lIGFmdGVyIHRoZSBtZWV0aW5nLCBoYTopDQoNCkFub3RoZXIg
ZmFjdCBpcyB0aGF0IGl0J3MgYSBsaXR0bGUgZGlmZmljdWx0IHRvIGdldCB0cmFpbiB0aWNrZXRz
IG5lYXIgdGhlIEdvbGRlbiBXZWVrLiBOb3Qgc3VyZSBhYm91dCB0aGUgaGlnaCBzcGVlZCBsaW5l
IHNpbmNlIGl0IGp1c3Qgc3RhcnQgdGhpcyB5ZWFyIGFuZCB0aGUgcHJpY2UgaXMgbXVjaCBoaWdo
ZXIgdGhhbiByZWd1bGVyIG9uZXMuIEFueXdheSBpZiB0aGlzIEludGVyaW0gbWVldGluZyB0YWtl
cyBwbGFjZSBpbiBCZWlqaW5nLCBqdXN0IHRha2UgZmxpZ2h0IGJhY2sgZnJvbSBCZWlqaW5nIGFm
dGVyd2FyZHMgcmF0aGVyIHRoYW4gZ28gYmFjayB0byBTaGFuZ2hhaSBmaXJzdC4NCi0tLS0tLS0t
LS0tLS0tLS0tLQ0KUGVuZyBXdQ0KUGhEIGNhbmRpZGF0ZQ0KRGVwYXJ0bWVudCBvZiBDb21wdXRl
ciBTY2llbmNlICYgVGVjaG5vbG9neQ0KVHNpbmdodWEgVW5pdmVyc2l0eSwgQmVpamluZywgQ2hp
bmENCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KRnJvbaO6eGlhb2hvbmcuZGVuZw0KRGF0ZaO6MjAxMS0wOC0wOCAxMTo1OTo0
NA0KVG+jumFkdXJhbmRAanVuaXBlci5uZXQ7IG1hcmtAdG93bnNsZXkubmV0DQpDQ6O6c29mdHdp
cmVzOyByZHJvbXMNClN1YmplY3SjulJlOiBbU29mdHdpcmVzXSBTb2Z0d2lyZSBJbnRlcmltIG1l
ZXRpbmcNCg0KPkVpdGhlciBTaGFuZ2hhaSBvciBCZWlqaW5nIHdpbGwgZG8uIEp1c3Qgc29tZSBw
aWVjZXMgb2YgaW5mbzoNCj4gQXV0dW1uIGlzIGRlZmluaXRlbHkgdGhlIGJlc3Qgc2Vhc29uIGlu
IEJlaWppbmchIFdpdGggZmFidWxvdXMgdmlld3MNCj5hbmQgd2VhdGhlciEgOykgQW5kIHRoZXJl
IGlzIGEgaGlnaCBzcGVlZCByYWlsd2F5IGJldHdlZW4gU2hhbmdoYWkgYW5kDQo+QmVpamluZywg
Y29zdGluZyA2MCBFdXJvcyBhcHByb3hpbWF0ZWx5LiBQbGVhc2UgYWxzbyBub3RlIHRoYXQgMjYt
Mjd0aA0KPm9yIDI3LTI4dGggaXMgbmVhciB0aGUgQ2hpbmVzZSBHb2xkZW4gd2VlayBpbiBDaGlu
YSBiZWdpbm5pbmcgd2l0aCBPY3QuDQo+MXN0LCBkdXJpbmcgd2hpY2ggYSBsb3QgdmlzaXRvcnMg
d2lsbCBydXNoIGludG8gZWl0aGVyIEJlaWppbmcgb3INCj5TaGFuZ2hhaS4gU28gc29tZSB0aW1l
IGJlZm9yZSBCcm9hZGJhbmQgZm9ydW0gbWF5IGdpdmUgdXMgYSBiZXR0ZXINCj5hbHRlcm5hdGl2
ZS4NCj4NCj5YaWFvaG9uZw0KPg0KPnxPbiBBdWcgNSwgMjAxMSwgYXQgMjozOCBQTSwgQWxhaW4g
RHVyYW5kIHdyb3RlOg0KPnwNCj58PiBGb2xsb3dpbmctdXAgb24gdGhlIFF1ZWJlYyBtZWV0aW5n
LCB3ZSB3b3VsZCBsaWtlIHRvDQo+fG9yZ2FuaXplIGFuIGludGVyaW0gbWVldGluZyBlbmQgb2Yg
U2VwdGVtYmVyLg0KPnw+IFdlIHdpbGwgZm9jdXMgb24gc28tY2FsbGVkIHN0YXRlbGVzcyBzb2x1
dGlvbnMgYW5kIG90aGVyIHJlbWFpbmluZw0KPnw+IGJ1c2luZXNzIGluIHRoZSB3ZyAobXVsdGlj
YXN0LiBtaWJzLC4uLikgdGhhdCByZXF1aXJlIG1vcmUNCj58dGltZSB0aGFuIHdlIHVzdWFsbHkg
aGF2ZSBkdXJpbmcgYSBub3JtYWwgSUVURiBtZWV0aW5nLg0KPnw+IFRoZSBmb3JtYXQgd2lsbCBi
ZSBhIDIgZGF5IGludGVuc2l2ZSBtZWV0aW5nLCB3aXRoIHdoaXRlDQo+fGJvYXJkIGRpc2N1c3Np
b25zLCBzaW1pbGFyIHRvIHdoYXQgd2UgZGlkIGluIHRoZSBlYXJseSBkYXlzIG9mDQo+fHRoZSB3
b3JraW5nIGdyb3VwLg0KPnw+DQo+fD4gV2UndmUgZ290IGFuIG9mZmVyIHRvIGhvc3QgdGhlIG1l
ZXRpbmcgaW4gQmVpamluIG9uIFNlcHQuDQo+fDI2LTI3dGggb3IgMjctMjh0aCAocmlnaHQgYWZ0
ZXIgdGhlIEJvcmFkYmFuZCBmb3J1bSBtZWV0aW5nIGluDQo+fFNoYW5naGFpKS4NCj58DQo+fFdv
dWxkIGl0IGJlIHBvc3NpYmxlIHRvIGtlZXAgaXQgaW4gdGhlIHNhbWUgY2l0eSBhcyB0aGUgQkJG
IHRvDQo+fGN1dCBkb3duIHRyYXZlbC9jb3N0cyBhIGJpdCBtb3JlIGZvciB0aG9zZSBnb2luZyB0
byBib3RoPw0KPnwNCj58LSBNYXJrDQo+fA0KPnw+IFlvbmcgYW5kIEkgd291bGQgbGlrZSB0byBt
YWtlIGEgZGVjaXNpb24gc29vbiwgcGxlYXNlIHNlbmQNCj58dXMgZW1haWwgZGlyZWN0bHkgaWYg
eW91IGludGVuZCB0byBjb21lIGFuZCB0ZWxsIHVzIHdoaWNoIHNldA0KPnxvZiBkYXRlcyBpcyBt
b3JlIGNvbnZlbmllbnQuDQo+fD4gUGxlYXNlIHJlc3BvbmQgYnkgQXVndXN0IDExdGgsIHdlIHdp
bGwgZm9ybWFsbHkgYW5ub3VuY2UgdGhlDQo+fG1lZXRpbmcgd2l0aCB0aGUgbG9naXN0aWMgaW5m
b3JtYXRpb24gZW5kIG9mIG5leHQgd2Vlay4NCj58Pg0KPnw+IEFsYWluICYgWW9uZy4NCj58Pg0K
Pnw+DQo+fD4NCj58PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPnw+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj58PiBTb2Z0d2lyZXNAaWV0Zi5vcmcN
Cj58PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPnwN
Cj58DQo+fA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPlNvZnR3aXJlc0BpZXRmLm9yZw0KPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo+DQo+IURTUEFNOjEsNGUz
ZjVmMzAzMDg5NTkyMzc3MTA3MSENCj4NCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQoN
ClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2Ns
dXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8g
cXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVz
dGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlh
dGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50
ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUg
ZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFp
bCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJp
dmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBE
aXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlz
IHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl
YXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRo
ZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQo=

From xiaohong.deng@orange-ftgroup.com  Tue Aug  9 09:34:11 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4B211E8098 for ; Tue,  9 Aug 2011 09:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.06
X-Spam-Level: 
X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=0.304,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPlvTn+PwD25 for ; Tue,  9 Aug 2011 09:34:10 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id B38F111E8085 for ; Tue,  9 Aug 2011 09:34:09 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2B139FC4006; Tue,  9 Aug 2011 18:34:37 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1B976FC4003; Tue,  9 Aug 2011 18:34:37 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 9 Aug 2011 17:25:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC56A8.8EEE59ED"
Date: Tue, 9 Aug 2011 23:25:23 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC019190E1@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxWqI6dZEz7t5thRJ+7mggi3XWXFQ==
References: <4E408C18.8030301@jacni.com> 
From: 
To: , 
X-OriginalArrivalTime: 09 Aug 2011 15:25:26.0976 (UTC) FILETIME=[90BDE400:01CC56A8]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 16:34:11 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC56A8.8EEE59ED
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8gWWl1LCBRaW9uZywgYWxsLA0KDQogDQoNCkludGVyZXN0aW5nIGRpc2N1c3Npb24sIGFu
ZCBob3BlIGFtIG5vdCBqdW1waW5nIHRvbyBsYXRlISBJIGd1ZXNzIEknbSBzdGlsbCBjdXJpbmcg
bXkgamV0IGxhZy4gOzANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJ
RnJvbTogUWlvbmcgW21haWx0bzpiaW5neHVlcmVAZ21haWwuY29tXSANCglTZW50OiBUdWVzZGF5
LCBBdWd1c3QgMDksIDIwMTEgMjo0OSBQTQ0KCVRvOiBMZWUsIFlpdQ0KCUNjOiBzb2Z0d2lyZXNA
aWV0Zi5vcmcNCglTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gQ2xhcmlmaWNhdGlvbiBvZiB0aGUg
c3RhdGVsZXMvc3RhdGVmdWwgZGlzY3Vzc2lvbg0KCQ0KCQ0KCUhpIFlpdSwgSmFjbmksDQoJDQoJ
DQoJT24gVHVlLCBBdWcgOSwgMjAxMSBhdCA5OjI1IEFNLCBMZWUsIFlpdSA8WWl1X0xlZUBjYWJs
ZS5jb21jYXN0LmNvbT4gd3JvdGU6DQoJDQoNCgkJU28gdGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3
ZWVuIDRyZCBCUiBhbmQgbGlnaHR3ZWlnaHQgQUZUUiBpcyBqdXN0IGEgc3RhdGljIG1hcHBpbmcg
cnVsZSBmb3IgYWxsIHVzZXJzIGluIHRoZSBzYW1lIGRvbWFpbiAoNHJkIEJSIGNhc2UpIGFuZCBn
cm91cCBydWxlIG9yIHVzZXIgc3BlY2lmaWMgcnVsZSBmb3IgZGlmZmVyZW50IHVzZXJzIChMVyBB
RlRSKT8NCg0KDQoJW1Fpb25nXTogQWdyZWUuICANCgkgDQoJWGlhb2hvbmc6IElmIHRoYXQncyB0
aGUgb25seSBkaWZmZXJlbmNlLCBkb24ndCBzZWUgYSBuZWVkIGZvciB0d28gZGlmZmVyZW50IHNv
bHV0aW9ucy4NCgkgDQoJIEFuZCBMVyBBRlRSIHdpbGwgbm90IGV4cG9zZSBwb3J0LXNldCBpbmZv
cm1hdGlvbiBpbiBJUHY2IGFkZHJlc3MgZGlyZWN0bHkuICBTbyBpdCB3b3VsZCBub3QgaW50cm9k
dWNlIGFueSBzcGVjaWZpYyByZXF1aXJlbWVudHMgb24gSVB2NiBhZGRyZXNzIGZvcm1hdC4gSSB0
aGluayB0aGlzIGlzIGFsc28gYSBtYWpvciBkaWZmZXJlbmNlIGJldHdlZW4gNHJkIGFuZCBMaWdo
dHdlaWdodCA0b3ZlcjYuIA0KCSANCglYaWFvaG9uZzogIENvdWxkIHlvdSBleHBsYWluIG1vcmUg
YWJvdXQgeW91ciBjb25jZXJuIG9uICAic3BlY2lmaWMgcmVxdWlyZW1lbnRzIG9uIElQdjYgYWRk
cmVzcyBmb3JtYXQiPyANCg0KCUlNSE8sIEkgZG9uJ3Qgc2VlIGEgaXNzdWUgaW4gNHJkIElQdjYg
YWRkcmVzcyBmb3JtYXQsIGFzIDRyZCBhdXRob3JzIGhhdmUgYmVlbiBjYXJlZnVsbHkgZGVzaWdu
aW5nIHRoZSBwb3J0IGFsbG9jYXRpb24gYWxnb3JpdGhtIGZvciBDRSBJUHY2IHByZWZpeCwgd2hp
Y2ggaXMgZWZmaWNpZW50bHkgZW5jb2RlZCAobGVzcyB0aGFuIDY0IGJpdHMpIGF0IGxlYXN0IHRv
IG15IGV5ZXMuICBPcGVuIHRvIGhlYXIgb3Bwc2l0ZSBvcGluaW9ucyAgaWYgeW91IGhhdmUgb3Bl
cmF0aW9uIGlzc3VlcyB3aXRoIHlvdXIgbmV0d29yay4gIDspIA0KDQoJIA0KDQoJQXMgYSBtYXR0
ZXIgb2YgZmFjdCwgSSBzZWUgYSBuZWVkIHdoZW4gYSAgKiBpbmNvbWluZyBwb3J0ICogIHJlcXVl
c3QgaXMgb3V0IHNpZGUgNHJkIHBvcnQgc2V0LCBmb3IgZXhhbXBsZSwgVVBuUCAxLjAgYXBwbGlj
YXRpb25zIGFzayBmb3IgYSBzcGVjaWZpYyBwb3J0IGFuZCB0cnkgY29uc2VjdXRpdmUgcG9ydHMs
IFJUUC9SVENQIGFuZCBzb21lIEZUUCBjbGllbnQgaW1wbGVtZW50YXRpb25zIGFzayBmb3IgYm90
aCBldmVuIGFuZCBvZGQgcG9ydHMgcGFpciwgYWNjb3JkaW5nIHRvIG91ciBBK1AgaW1wbGVtZW50
YXRpb24sIGFuZCBhbmFseXNpcyBhbmQgaW52ZXN0aWdhdGlvbiBvZiBpdCdzIGltcGFjdCBvbiBj
dXJyZW50IHByYWN0aWNlIHNpbmNlIDIwMDkuICANCg0KCSANCg0KCSANCg0KCUhvdyB0byBkZWFs
IHdpdGggaW5jb21pbmcgcG9ydCBvdXQgc2lkZSBvZiBzdGF0ZWxlc3Mgc29sdXRpb24gaXMgc29t
ZXRoaW5nIHdlIGhhdmUgYWRkcmVzc2VkIGJ5IHByb3Bvc2luZyBhIG5ldyBwb3J0IGFsbG9jYXRp
b24gYWxnb3JpdGhtIGFuZCBpbXBsZW1lbnRlZCBhIHNjYXR0ZXJlZCBwb3J0IGFsbG9jYXRpb24g
QStQLCBkb2N1bWVudGVkIGluIEErUCBleHBlcmltZW50cyBkcmFmdDoNCg0KCWh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlbmctdjZvcHMtYXBsdXNwLWV4cGVyaW1lbnQt
cmVzdWx0cyANCg0KCSANCg0KCUluIGNhc2UgeW91J3JlIGNvdXJpb3VzIGFib3V0IHBvcnQgY29u
c3VtcHRpb25zIG9mIGFwcGxpY2F0aW9ucyBpbiB0aGUgSVB2NCBhZGRyZXNzIHNoYXJpbmcgY29u
dGV4dCwgeW91IG1heSBsaWtlIHRvIGhhdmUgYSBsb29rIGF0Og0KDQoJaHR0cDovL29wZW5zb3Vy
Y2V2NnRyYW5zdGVjaG5vbG9naWVzLndlZWJseS5jb20vZXhwZXJpbWVudHMtcmVzdWx0cy5odG1s
DQoNCgkgDQoNCgkgDQoNCglBbmQgaXQncyBhbHNvIGFwcGxpY2FibGUgdG8gRFMtTGl0ZSBzY2Vu
YXJpbywgaW4gY2FzZSBhIGRlcGxveW1lbnQgd2FudHMgdG8gYWxsb2NhdGUgYSBidWxrIG9mIGlu
Y29taW5nIHBvcnRzIHRvIGJlIHVuZGVyIGNvbnRyb2wgb2YgY3VzdG9tZXIsIGEgZGVwbG95bWVu
dCBhcHByb2FjaCB3YXMgZG9jdW1lbnRlZCBpbjoNCg0KCURTLUxpdGUgQUZUUiBOQVQgQnlwYXNz
OiBDby1sb2NhdGVkIEI0IGFuZCBOQVQgTW9kZWwNCg0KCWh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LXpob3Utc29mdHdpcmUtYjQtbmF0LTAyIA0KDQoJIA0KDQoJQW5kIHRoZSBtZWFu
cyBvZiBwcm92aXNpb25pbmcgdHdvIHBhcmFtZXRlcnMgZm9yIHRoaXMgcG9ydCBhbGxvY2F0aW9u
IGlzIHZpYSBQQ1AsIGFuZCB3YXMgZG9jdW1lbnRlZCBpbg0KDQoJaHR0cDovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtdHNvdS1wY3AtbmF0Y29vcmQtMDMgDQoNCgkgDQoNCglUaGlzIGRlcGxv
eW1lbnQgaGFzIGJlZW4gYWxzbyBkZW1vZWQgZHVyaW5nIElFVEYgODEgUENQIGRlbW8sIGFuZCB0
aGUgd2Vic2l0ZSBmb3IgdGhpcyBkZW1vIGhhcyBiZWVuIG1vdmVkIHRvIChpbiBjYXNlIHlvdSdy
ZSBpbnRvIGFzY2lpIGRyYXdpbmdzIDspKSA6ICANCg0KCWh0dHA6Ly9vcGVuc291cmNldjZ0cmFu
c3RlY2hub2xvZ2llcy53ZWVibHkuY29tL2lldGYtODEtcGNwLWRlbW8tc2l0ZS5odG1sIDxodHRw
Oi8vb3BlbnNvdXJjZXY2dHJhbnN0ZWNobm9sb2dpZXMud2VlYmx5LmNvbS9pZXRmLTgxLXBjcC1k
ZW1vLXNpdGUuaHRtbD4gIA0KDQoJIA0KDQoJVGhvdWdodHMgYXJlIHZlcnkgbXVjaCB3ZWxjb21l
ZCENCg0KCSANCg0KCVAuUy4gSSdtIG5vdCBzYXlpbmcgdGhpcyBhbGdvcml0aG0gaXMgdGhlIG9u
bHkgd2F5IGZvciA0cmQgdG8gZGVhbCB3aXRoIGluY29taW5nIHBvcnQgcmVzdHJpY3Rpb24sIGFu
ZCB0aGVyZSBhcmUgY2VydGFpbmx5IHdheXMgdG8gZGVzaWduIDRyZCBwb3J0IGFsbG9jYXRpb24g
d2hpbGUga2VlcCBpdHMgSVB2NiBwcmVmaXggZW5jb2RpbmcgZWZmaWNpZW50bHkuIFRoZSBwb2lu
dCBpcyB0aGF0IHRoZXJlIGlzIGEgcmVhc29uIChjdXJyZW50L3Bhc3QtdG8tYmUgcHJhY3RpY2Up
IGZvciA0cmQgdG8gdGFrZSBjYXJlIG9mIHBvcnQgYWxsb2NhdGlvbi4NCg0KCSANCg0KCSAgICAg
ICAgICAgICAgICAgICAgIF8uLl8uLixfX18sDQoJICAgICAgICAgICAgICAgICAgICAoICAgQ2hl
ZXJzISApDQoJICAgICAgICAgICAgICAgICAgICBdfiwiLS4tfiAgICAgWyANCgkgICAgICAgICAg
ICAgICAgIC49XSApICAnICg7ICAgICAgKFsgDQoJICAgICAgICAgICAgICAgICAgfCBdOjogICAn
ICAgICAgICAgIFsgICANCgkgICAgICAgICAgICAgICAgICAnPV0pOiAgICAuKSAgICAgKFsNCgkg
ICAgICAgICAgICAgICAgICAgIHwgOiA6ICAgICAgICAgICAgIHwNCgkgICAgICAgICAgICAgICAg
ICAgICB+fn4tLS0tLS0tICAgIA0KDQoJIA0KDQoJIFhpYW9ob25nDQoNCgkNCg0KCQ0KCQ0KDQoJ
IA0KDQoJIA0KDQoJQmVzdCByZWdhcmRzLg0KDQoJUWlvbmcgU3VuDQoNCg==

------_=_NextPart_001_01CC56A8.8EEE59ED
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2
LjAwLjYwMDAuMTcwOTUiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPjxGT05UIGZhY2U9
5a6L5L2TIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz
dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJtc28t
YmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+
SGVsbG8gWWl1LCANClFpb25nLCBhbGwsPD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8gbnMgPSAN
CiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIC8+PG86cD48L286cD48
L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ
TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0ibXNvLWJpZGktZm9udC1z
aXplOiAxMC4wcHQiPjxvOnA+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDs8L0ZP
TlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw
Y20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6
IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+SW50ZXJlc3RpbmcgDQpk
aXNjdXNzaW9uLCBhbmQgaG9wZSBhbSBub3QganVtcGluZyB0b28gbGF0ZTxTUEFOIA0KY2xhc3M9
MTY2MzA0NjEyLTA5MDgyMDExPiE8L1NQQU4+IEkgZ3Vlc3MgSSdtIHN0aWxsIGN1cmluZyBteSBq
ZXQgbGFnLiANCjswPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+PEJSPg0KPEJM
T0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6
IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+
DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz16aC1jbiBkaXI9bHRyIGFs
aWduPWxlZnQ+DQogIDxIUiB0YWJJbmRleD0tMT4NCiAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0y
PjxCPkZyb206PC9CPiBRaW9uZyBbbWFpbHRvOmJpbmd4dWVyZUBnbWFpbC5jb21dIA0KICA8QlI+
PEI+U2VudDo8L0I+IFR1ZXNkYXksIEF1Z3VzdCAwOSwgMjAxMSAyOjQ5IFBNPEJSPjxCPlRvOjwv
Qj4gTGVlLCANCiAgWWl1PEJSPjxCPkNjOjwvQj4gc29mdHdpcmVzQGlldGYub3JnPEJSPjxCPlN1
YmplY3Q6PC9CPiBSZTogW1NvZnR3aXJlc10gDQogIENsYXJpZmljYXRpb24gb2YgdGhlIHN0YXRl
bGVzL3N0YXRlZnVsIGRpc2N1c3Npb248QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJ
Vj5IaSBZaXUsIEphY25pLDxCUj48QlI+DQogIDxESVYgY2xhc3M9Z21haWxfcXVvdGU+T24gVHVl
LCBBdWcgOSwgMjAxMSBhdCA5OjI1IEFNLCBMZWUsIFlpdSA8U1BBTiANCiAgZGlyPWx0cj4mbHQ7
PEEgDQogIGhyZWY9Im1haWx0bzpZaXVfTGVlQGNhYmxlLmNvbWNhc3QuY29tIj5ZaXVfTGVlQGNh
YmxlLmNvbWNhc3QuY29tPC9BPiZndDs8L1NQQU4+IA0KICB3cm90ZTo8QlI+DQogIDxCTE9DS1FV
T1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0KICBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJ
TjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+DQogICAg
PERJViANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxNHB4OyBDT0xPUjogcmdiKDAsMCwwKTsgRk9O
VC1GQU1JTFk6IENhbGlicmksIHNhbnMtc2VyaWY7IFdPUkQtV1JBUDogYnJlYWstd29yZCI+DQog
ICAgPERJVj5TbyB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gNHJkIEJSIGFuZCBsaWdodHdl
aWdodCBBRlRSIGlzIGp1c3QgYSANCiAgICBzdGF0aWMgbWFwcGluZyBydWxlIGZvciBhbGwgdXNl
cnMgaW4gdGhlIHNhbWUgZG9tYWluICg0cmQgQlIgY2FzZSkgYW5kIGdyb3VwIA0KICAgIHJ1bGUg
b3IgdXNlciBzcGVjaWZpYyBydWxlIGZvciBkaWZmZXJlbnQgdXNlcnMgKExXIA0KICBBRlRSKT88
L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPltRaW9u
Z106IEFncmVlLiZuYnNwOzxTUEFOIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAxMT48Rk9OVCBmYWNl
PeWui+S9kyANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJ
Vj4NCiAgPERJVj48U1BBTiBjbGFzcz0xNjYzMDQ2MTItMDkwODIwMTE+PEZPTlQgZmFjZT3lrovk
vZMgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQog
IDxESVY+PFNQQU4gY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPjxGT05UIGZhY2U95a6L5L2TIGNv
bG9yPSMwMDAwZmYgc2l6ZT0yPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlhpYW9o
b25nOiBJZiB0aGF0J3MgdGhlIG9ubHkgZGlmZmVyZW5jZSwgZG9uJ3Qgc2VlIGEgDQogIG5lZWQg
Zm9yIHR3byBkaWZmZXJlbnQgc29sdXRpb25zPC9GT05UPi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0K
ICA8RElWPjxTUEFOIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAxMT48Rk9OVCBmYWNlPeWui+S9kyBj
b2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJ
Vj48U1BBTiBjbGFzcz0xNjYzMDQ2MTItMDkwODIwMTE+Jm5ic3A7PC9TUEFOPkFuZCBMVyBBRlRS
IHdpbGwgbm90IGV4cG9zZSANCiAgcG9ydC1zZXQgaW5mb3JtYXRpb24gaW4gSVB2NiBhZGRyZXNz
IGRpcmVjdGx5LiAmbmJzcDtTbyBpdCB3b3VsZCBub3QgaW50cm9kdWNlIA0KICBhbnkmbmJzcDtz
cGVjaWZpYyZuYnNwO3JlcXVpcmVtZW50cyBvbiBJUHY2IGFkZHJlc3MgZm9ybWF0LiBJIHRoaW5r
IHRoaXMgaXMgDQogIGFsc28gYSBtYWpvciBkaWZmZXJlbmNlIGJldHdlZW4gNHJkIGFuZCBMaWdo
dHdlaWdodCA0b3ZlcjYuPFNQQU4gDQogIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAxMT48Rk9OVCBm
YWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48
L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0xNjYzMDQ2MTItMDkwODIwMTE+PEZPTlQgZmFjZT3l
rovkvZMgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+
DQogIDxESVY+PFNQQU4gY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPg0KICA8UCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0
eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9O
VCANCiAgc2l6ZT0yPlhpYW9ob25nOiZuYnNwOzxTUEFOIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAx
MT4mbmJzcDtDb3VsZCB5b3UgZXhwbGFpbiANCiAgbW9yZSBhYm91dCB5b3VyIGNvbmNlcm4gb24m
bmJzcDsgInNwZWNpZmljIHJlcXVpcmVtZW50cyBvbiBJUHY2IGFkZHJlc3MgDQogIGZvcm1hdCI/
Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y
bWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHls
ZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UPjxGT05UIGNvbG9yPSMwMDAwZmY+
PEZPTlQgDQogIHNpemU9Mj48U1BBTiBjbGFzcz0xNjYzMDQ2MTItMDkwODIwMTE+SU1ITywgSSBk
PC9TUEFOPm9uJ3Qgc2VlIGEgaXNzdWUgaW4gNHJkIA0KICBJUHY2IGFkZHJlc3MgZm9ybWF0LCBh
cyA0cmQgYXV0aG9ycyBoYXZlIGJlZW4gY2FyZWZ1bGx5IGRlc2lnbmluZyB0aGUgcG9ydCANCiAg
YWxsb2NhdGlvbiBhbGdvcml0aG0gZm9yIENFIElQdjYgcHJlZml4LCB3aGljaCBpcyBlZmZpY2ll
bnRseSBlbmNvZGVkIChsZXNzIA0KICB0aGFuIDY0IGJpdHMpIGF0IGxlYXN0IHRvIG15IGV5ZXMu
Jm5ic3A7PFNQQU4gDQogIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAxMT4mbmJzcDtPcGVuIHRvIGhl
YXIgb3Bwc2l0ZSANCiAgb3BpbmlvbnMmbmJzcDs8L1NQQU4+Jm5ic3A7aWYgeW91IGhhdmUgb3Bl
cmF0aW9uIGlzc3VlcyB3aXRoIHlvdXIgDQogIG5ldHdvcmsuPEZPTlQgZmFjZT3lrovkvZM+PFNQ
QU4gY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPiZuYnNwOyANCiAgOykmbmJzcDs8L1NQQU4+PG86
cD48L286cD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVT
IA0KICBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxvOnA+PEZPTlQgY29sb3I9
IzAwMDBmZiANCiAgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KICA8UCBj
bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4t
VVMgDQogIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAw
MDBmZj48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAxMT5BcyBh
IG1hdHRlciBvZiBmYWN0PC9TUEFOPiwgSSBzZWUgYSBuZWVkIHdoZW4gDQogIGEmbmJzcDs8U1BB
TiBjbGFzcz0xNjYzMDQ2MTItMDkwODIwMTE+PEZPTlQgDQogIGZhY2U95a6L5L2TPiZuYnNwOyom
bmJzcDs8L0ZPTlQ+PC9TUEFOPmluY29taW5nIHBvcnQ8U1BBTiANCiAgY2xhc3M9MTY2MzA0NjEy
LTA5MDgyMDExPjxGT05UIGZhY2U95a6L5L2TPiZuYnNwOyombmJzcDs8L0ZPTlQ+PC9TUEFOPiBy
ZXF1ZXN0IGlzIA0KICBvdXQgc2lkZSA0cmQgcG9ydCBzZXQsIGZvciBleGFtcGxlLCBVUG5QIDEu
MCBhcHBsaWNhdGlvbnMgYXNrIGZvciBhIHNwZWNpZmljIA0KICBwb3J0IGFuZCB0cnkgY29uc2Vj
dXRpdmUgcG9ydHMsIFJUUC9SVENQIGFuZCBzb21lIEZUUCBjbGllbnQgaW1wbGVtZW50YXRpb25z
IA0KICBhc2sgZm9yIGJvdGggZXZlbiBhbmQgb2RkIHBvcnRzIHBhaXIsIGFjY29yZGluZyB0byBv
dXIgQStQIGltcGxlbWVudGF0aW9uLCBhbmQgDQogIGFuYWx5c2lzIGFuZCBpbnZlc3RpZ2F0aW9u
IG9mIGl0J3MgaW1wYWN0IG9uIGN1cnJlbnQgcHJhY3RpY2Ugc2luY2UgMjAwOS4gDQogIDxTUEFO
IA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj48bzpwPjwvbzpwPjwv
Rk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH
SU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0ibXNvLWJpZGktZm9u
dC1zaXplOiAxMC4wcHQiPjxvOnA+PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPiZuYnNw
OzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B
UkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJtc28tYmlkaS1m
b250LXNpemU6IDEwLjBwdCI+PG86cD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+Jm5i
c3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i
TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9Im1zby1iaWRp
LWZvbnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj5Ib3cg
dG8gDQogIGRlYWwgd2l0aCBpbmNvbWluZyBwb3J0IG91dCBzaWRlIG9mIHN0YXRlbGVzcyBzb2x1
dGlvbiBpcyBzb21ldGhpbmcgd2UgaGF2ZSANCiAgYWRkcmVzc2VkIGJ5IHByb3Bvc2luZyBhIG5l
dyBwb3J0IGFsbG9jYXRpb24gYWxnb3JpdGhtIGFuZCBpbXBsZW1lbnRlZCBhIA0KICBzY2F0dGVy
ZWQgcG9ydCBhbGxvY2F0aW9uIEErUCwgZG9jdW1lbnRlZCBpbiBBK1AgZXhwZXJpbWVudHMgDQog
IGRyYWZ0OjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1N
c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQog
IHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48
Rk9OVCBzaXplPTI+PEEgDQogIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWRlbmctdjZvcHMtYXBsdXNwLWV4cGVyaW1lbnQtcmVzdWx0cyI+aHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGVuZy12Nm9wcy1hcGx1c3AtZXhwZXJpbWVudC1y
ZXN1bHRzPC9BPjxGT05UIA0KICBmYWNlPeWui+S9kz48U1BBTiANCiAgY2xhc3M9MTY2MzA0NjEy
LTA5MDgyMDExPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0K
ICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxh
bmc9RU4tVVMgDQogIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29s
b3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PEZPTlQgDQogIGZhY2U95a6L5L2TPjxTUEFOIA0KICBj
bGFzcz0xNjYzMDQ2MTItMDkwODIwMTE+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BB
Tj4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt
IDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAu
MHB0Ij48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KICBzaXplPTI+PEZPTlQ+PFNQQU4gY2xh
c3M9MTY2MzA0NjEyLTA5MDgyMDExPkluIGNhc2UgeW91J3JlIGNvdXJpb3VzIGFib3V0IHBvcnQg
DQogIGNvbnN1bXB0aW9ucyBvZiBhcHBsaWNhdGlvbnMgaW4gdGhlIElQdjQgYWRkcmVzcyBzaGFy
aW5nIGNvbnRleHQsIHlvdSBtYXkgbGlrZSANCiAgdG8gaGF2ZSBhIGxvb2sgYXQ6PC9TUEFOPjwv
Rk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHls
ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9Im1zby1i
aWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KICBzaXpl
PTI+PEZPTlQ+PFNQQU4gY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPjxBIA0KICBocmVmPSJodHRw
Oi8vb3BlbnNvdXJjZXY2dHJhbnN0ZWNobm9sb2dpZXMud2VlYmx5LmNvbS9leHBlcmltZW50cy1y
ZXN1bHRzLmh0bWwiPmh0dHA6Ly9vcGVuc291cmNldjZ0cmFuc3RlY2hub2xvZ2llcy53ZWVibHku
Y29tL2V4cGVyaW1lbnRzLXJlc3VsdHMuaHRtbDwvQT48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZP
TlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAw
Y20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAx
MC4wcHQiPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPjxGT05UIA0KICBmYWNlPeWu
i+S9kz48U1BBTiANCiAgY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPiZuYnNwOzwvU1BBTj48bzpw
PjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5
bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48bzpwPjxGT05UIGNvbG9yPSMwMDAwZmYg
DQogIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNv
Tm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBz
dHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZP
TlQgc2l6ZT0yPkFuZCBpdCdzIA0KICBhbHNvIGFwcGxpY2FibGUgdG8gRFMtTGl0ZSBzY2VuYXJp
bywgaW4gY2FzZSBhIGRlcGxveW1lbnQgd2FudHMgdG8gYWxsb2NhdGUgYSANCiAgYnVsayBvZiBp
bmNvbWluZyBwb3J0cyB0byBiZSB1bmRlciBjb250cm9sIG9mIGN1c3RvbWVyLCBhIGRlcGxveW1l
bnQgYXBwcm9hY2ggDQogIHdhcyBkb2N1bWVudGVkIGluOjxvOnA+PC9vOnA+PC9GT05UPjwvRk9O
VD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj
bSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEw
LjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+RFMtTGl0ZSANCiAgQUZUUiBO
QVQgQnlwYXNzOiBDby1sb2NhdGVkIEI0IGFuZCBOQVQgDQogIE1vZGVsPG86cD48L286cD48L0ZP
TlQ+PC9GT05UPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9Im1zby1iaWRpLWZvbnQt
c2l6ZTogMTAuMHB0Ij48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj48QSANCiAgaHJl
Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhvdS1zb2Z0d2lyZS1iNC1uYXQt
MDIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpob3Utc29mdHdpcmUtYjQtbmF0
LTAyPC9BPjxGT05UIA0KICBmYWNlPeWui+S9kz48U1BBTiANCiAgY2xhc3M9MTY2MzA0NjEyLTA5
MDgyMDExPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8
UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9
RU4tVVMgDQogIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9
IzAwMDBmZj48Rk9OVCBzaXplPTI+PEZPTlQgDQogIGZhY2U95a6L5L2TPjxTUEFOIA0KICBjbGFz
cz0xNjYzMDQ2MTItMDkwODIwMTE+Jm5ic3A7PC9TUEFOPjxvOnA+PC9vOnA+PC9GT05UPjwvRk9O
VD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46
IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0ibXNvLWJpZGktZm9udC1z
aXplOiAxMC4wcHQiPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPkFuZCB0aGUgDQog
IG1lYW5zIG9mIHByb3Zpc2lvbmluZyB0d28gcGFyYW1ldGVycyBmb3IgdGhpcyBwb3J0IGFsbG9j
YXRpb24gaXMgdmlhIFBDUCwgYW5kIA0KICB3YXMgZG9jdW1lbnRlZCBpbjxvOnA+PC9vOnA+PC9G
T05UPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ
TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJtc28tYmlkaS1mb250
LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PEEgDQogIGhy
ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzb3UtcGNwLW5hdGNvb3JkLTAz
Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c291LXBjcC1uYXRjb29yZC0wMzwv
QT48Rk9OVCANCiAgZmFjZT3lrovkvZM+PFNQQU4gDQogIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAx
MT4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVT
IA0KICBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIGNvbG9yPSMwMDAw
ZmY+PEZPTlQgc2l6ZT0yPjxGT05UIA0KICBmYWNlPeWui+S9kz48U1BBTiANCiAgY2xhc3M9MTY2
MzA0NjEyLTA5MDgyMDExPiZuYnNwOzwvU1BBTj48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9G
T05UPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20g
MGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTog
MTAuMHB0Ij48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj5UaGlzIA0KICBkZXBsb3lt
ZW50IGhhcyBiZWVuIGFsc28gZGVtb2VkIGR1cmluZyBJRVRGIDgxIFBDUCBkZW1vLCBhbmQgdGhl
IHdlYnNpdGUgZm9yIA0KICB0aGlzIGRlbW8gaGFzIGJlZW4gbW92ZWQgdG88U1BBTiBjbGFzcz0x
NjYzMDQ2MTItMDkwODIwMTE+Jm5ic3A7KGluIGNhc2UgDQogIHlvdSdyZSBpbnRvIGFzY2lpIGRy
YXdpbmdzIDspKSZuYnNwOzwvU1BBTj48U1BBTiANCiAgY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDEx
PjombmJzcDs8L1NQQU4+PFNQQU4gDQogIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAxMT4mbmJzcDs8
L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5
bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJtc28t
YmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48QSANCiAgaHJlZj0i
aHR0cDovL29wZW5zb3VyY2V2NnRyYW5zdGVjaG5vbG9naWVzLndlZWJseS5jb20vaWV0Zi04MS1w
Y3AtZGVtby1zaXRlLmh0bWwiPjxGT05UIA0KICBzaXplPTI+aHR0cDovL29wZW5zb3VyY2V2NnRy
YW5zdGVjaG5vbG9naWVzLndlZWJseS5jb20vaWV0Zi04MS1wY3AtZGVtby1zaXRlLmh0bWw8L0ZP
TlQ+PC9BPjxGT05UIA0KICBmYWNlPeWui+S9kz48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNz
PTE2NjMwNDYxMi0wOTA4MjAxMT4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9T
UEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0
Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQi
PjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgZmFjZT3lrovkvZM+PEZPTlQgDQogIHNpemU9Mj48
U1BBTiANCiAgY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPiZuYnNwOzwvU1BBTj48bzpwPjwvbzpw
PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+PFNQQU4gDQogIGxhbmc9RU4tVVMgc3R5
bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0
eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0ibXNv
LWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIHNpemU9Mj48Rk9OVCBjb2xvcj0jMDAwMGZm
PlRob3VnaHRzIA0KICBhcmUgdmVyeSBtdWNoIHdlbGNvbWVkITxvOnA+PC9vOnA+PC9GT05UPjwv
Rk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt
IDBjbSAwcHQiPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0ibXNvLWJpZGktZm9u
dC1zaXplOiAxMC4wcHQiPjxvOnA+PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPiZuYnNw
OzwvRk9OVD48L286cD48L1NQQU4+PC9QPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJtc28t
YmlkaS1mb250LXNpemU6IDEwLjBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9Im1zby1i
aWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH
SU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0ibXNvLWJpZGktZm9u
dC1zaXplOiAxMC4wcHQiPjxGT05UIHNpemU9Mj48Rk9OVCBjb2xvcj0jMDAwMGZmPlAuUy4gSSdt
IA0KICBub3Qgc2F5aW5nIHRoaXMgYWxnb3JpdGhtIGlzIHRoZSBvbmx5IHdheSBmb3IgNHJkIHRv
IGRlYWwgd2l0aCBpbmNvbWluZyBwb3J0IA0KICByZXN0cmljdGlvbiwgYW5kIHRoZXJlIGFyZSBj
ZXJ0YWlubHkgd2F5cyB0byBkZXNpZ24gNHJkIHBvcnQgYWxsb2NhdGlvbiB3aGlsZSANCiAga2Vl
cCBpdHMgSVB2NiBwcmVmaXggZW5jb2RpbmcgZWZmaWNpZW50bHkuIFRoZSBwb2ludCBpcyB0aGF0
IHRoZXJlIGlzIGEgcmVhc29uIA0KICAoY3VycmVudC9wYXN0LXRvLWJlIHByYWN0aWNlKSBmb3Ig
NHJkIHRvIHRha2UgY2FyZSBvZiBwb3J0IA0KICBhbGxvY2F0aW9uLjxvOnA+PC9vOnA+PC9GT05U
PjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog
MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJtc28tYmlkaS1mb250LXNp
emU6IDEwLjBwdCI+PG86cD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+Jm5ic3A7PC9G
T05UPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9Im1zby1iaWRpLWZvbnQt
c2l6ZTogMTAuMHB0Ij48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj48U1BBTiANCiAg
Y2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPjxGT05UIGZhY2U95a6L5L2TPjxGT05UIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiIgDQogIGNvbG9yPSMwMDAwMDAgDQogIHNpemU9Mz4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIF8u
Ll8uLixfX18sPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyANCiAgKCZuYnNwOyZuYnNwOyBDaGVlcnMhIA0KICApPEJSPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgXX4s
Ii0uLX4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWyANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgLj1dICkmbmJzcDsgJyAoOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyhbIA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB8IF06OiZuYnNwOyZuYnNwOyAnJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBbJm5ic3A7Jm5i
c3A7IA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IA0KICAnPV0pOiZuYnNwOyZuYnNwOyZuYnNwOyAuKSZuYnNwOyAmbmJzcDsmbmJzcDsgDQogIChb
PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyANCiAgfCA6IDombmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz
cDsmbmJzcDsgDQogICZuYnNwO3w8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB+fn4tLS0tLS0tJm5ic3A7Jm5ic3A7
Jm5ic3A7PC9GT05UPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9Q
Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFO
IGxhbmc9RU4tVVMgDQogIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQg
Y29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTE2NjMwNDYxMi0wOTA4
MjAxMT48L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPg0KICA8UCBjbGFzcz1N
c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQog
IHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgY29sb3I9IzAwMDBmZj48
Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTE2NjMwNDYxMi0wOTA4MjAxMT4mbmJzcDs8L1NQ
QU4+WGlhb2hvbmc8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48L1NQQU4+PC9TUEFOPjwv
U1BBTj48U1BBTiANCiAgY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPjxTUEFOIGNsYXNzPTE2NjMw
NDYxMi0wOTA4MjAxMT48Rk9OVCBmYWNlPeWui+S9kyANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+
PC9GT05UPjwvU1BBTj48L1NQQU4+PC9QPjwvRElWPjxTUEFOIA0KICBjbGFzcz0xNjYzMDQ2MTIt
MDkwODIwMTE+PFNQQU4gY2xhc3M9MTY2MzA0NjEyLTA5MDgyMDExPjxGT05UIGZhY2U95a6L5L2T
IA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48UFJFIGNsYXNzPW5ld3BhZ2U+PFNQQU4gY2xhc3M9
aDQ+PEg0PiZuYnNwOzwvSDQ+PC9TUEFOPjwvUFJFPg0KICA8RElWPjwvRk9OVD48L1NQQU4+Jm5i
c3A7PC9TUEFOPjwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj5CZXN0IHJlZ2FyZHMu
PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPlFpb25nIFN1bjwvRElWPjwvRElWPjwv
QkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K

------_=_NextPart_001_01CC56A8.8EEE59ED--

From yiu_lee@cable.comcast.com  Tue Aug  9 09:36:36 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7011E8073 for ; Tue,  9 Aug 2011 09:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.248
X-Spam-Level: 
X-Spam-Status: No, score=-104.248 tagged_above=-999 required=5 tests=[AWL=1.578, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aof4J81Vc97 for ; Tue,  9 Aug 2011 09:36:36 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id D6FFC11E8080 for ; Tue,  9 Aug 2011 09:36:35 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136647926; Tue, 09 Aug 2011 12:37:03 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 9 Aug 2011 12:37:01 -0400
From: "Lee, Yiu" 
To: "xiaohong.deng@orange-ftgroup.com" , "bingxuere@gmail.com" 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVrKPr8Livb8OOU6x5beYhOgl1Q==
Date: Tue, 9 Aug 2011 16:36:59 +0000
Message-ID: 
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC019190E1@ch-mailsrv.rd.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [69.241.25.0]
Content-Type: multipart/alternative; boundary="_000_CA66DA4D1384Ayiuleecablecomcastcom_"
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Aug 2011 16:36:36 -0000

--_000_CA66DA4D1384Ayiuleecablecomcastcom_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

WW91IGdvIGl0Lg0KDQpGcm9tOiA8eGlhb2hvbmcuZGVuZ0BvcmFuZ2UtZnRncm91cC5jb208bWFp
bHRvOnhpYW9ob25nLmRlbmdAb3JhbmdlLWZ0Z3JvdXAuY29tPj4NCkRhdGU6IFR1ZSwgOSBBdWcg
MjAxMSAyMzoyNToyMyArMDgwMA0KVG86IDxiaW5neHVlcmVAZ21haWwuY29tPG1haWx0bzpiaW5n
eHVlcmVAZ21haWwuY29tPj4sICJZaXUgTC4gTEVFIiA8eWl1X2xlZUBjYWJsZS5jb21jYXN0LmNv
bTxtYWlsdG86eWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbT4+DQpDYzogPHNvZnR3aXJlc0BpZXRm
Lm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbU29mdHdpcmVz
XSBDbGFyaWZpY2F0aW9uIG9mIHRoZSBzdGF0ZWxlcy9zdGF0ZWZ1bCBkaXNjdXNzaW9uDQoNClhp
YW9ob25nOiAgQ291bGQgeW91IGV4cGxhaW4gbW9yZSBhYm91dCB5b3VyIGNvbmNlcm4gb24gICJz
cGVjaWZpYyByZXF1aXJlbWVudHMgb24gSVB2NiBhZGRyZXNzIGZvcm1hdCI/DQpJTUhPLCBJIGRv
bid0IHNlZSBhIGlzc3VlIGluIDRyZCBJUHY2IGFkZHJlc3MgZm9ybWF0LCBhcyA0cmQgYXV0aG9y
cyBoYXZlIGJlZW4gY2FyZWZ1bGx5IGRlc2lnbmluZyB0aGUgcG9ydCBhbGxvY2F0aW9uIGFsZ29y
aXRobSBmb3IgQ0UgSVB2NiBwcmVmaXgsIHdoaWNoIGlzIGVmZmljaWVudGx5IGVuY29kZWQgKGxl
c3MgdGhhbiA2NCBiaXRzKSBhdCBsZWFzdCB0byBteSBleWVzLiAgT3BlbiB0byBoZWFyIG9wcHNp
dGUgb3BpbmlvbnMgIGlmIHlvdSBoYXZlIG9wZXJhdGlvbiBpc3N1ZXMgd2l0aCB5b3VyIG5ldHdv
cmsuICA7KQ0K

--_000_CA66DA4D1384Ayiuleecablecomcastcom_
Content-Type: text/html; charset="gb2312"
Content-ID: <2069D14284C99C4F9351AD6422351340@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable







You go it.









From: <xiaohong.deng@orange-ftgroup.com>

Date: Tue, 9 Aug 2011 23:25:23 +=
;0800

To: <bingxuere@gmail.com>, "Yiu L. LEE" <yiu_lee@cable.comcast.com>

Cc: <softwires@ietf.org>

Subject: RE: [Softwires] Clarificat=
ion of the stateles/stateful discussion











Xiaohong:&nbs=
p; Could you explain more about you=
r concern on  "specific requirements on IPv6 address format"=
? 



IMHO, I don't see a issue in 4rd IPv6 ad=
dress format, as 4rd authors have been carefully designing the port allocat=
ion algorithm for CE IPv6 prefix, which
 is efficiently encoded (less than 64 bits) at least to my eyes.  Open to hear oppsite opinions  if you have operation issues with your network.  ;) =






--_000_CA66DA4D1384Ayiuleecablecomcastcom_--

From xiaohong.deng@orange-ftgroup.com  Wed Aug 10 01:24:25 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9448F21F871C for ; Wed, 10 Aug 2011 01:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level: 
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=0.328,  BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaFpBTQ0qNTH for ; Wed, 10 Aug 2011 01:24:25 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5621F8715 for ; Wed, 10 Aug 2011 01:24:24 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B30607B800E; Wed, 10 Aug 2011 10:26:13 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A402C738006; Wed, 10 Aug 2011 10:26:13 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 10 Aug 2011 10:19:39 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Aug 2011 16:19:36 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195ABE1@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <9721E717-3BDC-4909-A3E5-BE7CFC304B17@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Port allocation considerations (UPnP friendly and odd-even pairs possible) for 4rd
Thread-Index: AcxWsRANQJUPjwIQTy6rv3DPAXyLhQAg2ldg
References: <0962B0BEF842A24191AD9BE41A8DD2FC019182BD@ch-mailsrv.rd.francetelecom.fr> <29716072-5BD9-4275-8E04-F68590062EEE@tm.softbank.co.jp> <0962B0BEF842A24191AD9BE41A8DD2FC019182BE@ch-mailsrv.rd.francetelecom.fr> <474B0FCE-10BE-4E92-947C-BE7FCF3BE1F8@gmail.com> <4FFC4350-2236-4719-B34D-B6168B9D61C7@cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC01918CB2@ch-mailsrv.rd.francetelecom.fr> <887B4DE8-6164-4052-B20A-BE1433B5DF81@ipinfusion.com> <0962B0BEF842A24191AD9BE41A8DD2FC01918DFE@ch-mailsrv.rd.francetelecom.fr>  <0962B0BEF842A24191AD9BE41A8DD2FC01918E34@ch-mailsrv.rd.francetelecom.fr> <97C29A5B-90F0-480D-9B4F-799034112D40@cisco.com>  <8EA6EDD4-FE3B-43F4-A0B0-9203F5C47434@gmail.com> <0962B0BEF842A24191AD9BE41A8DD2FC01918E82@ch-mailsrv.rd.francetelecom.fr> <03C74114-7ED1-4937-971E-43C7A59E1CBB@ipinfusion.com>  <0962B0BEF842A24191AD9BE41A8DD2FC019190D3@ch-mailsrv.rd.francetelecom.fr> <9721E717-3BDC-4909-A3E5-BE7CFC304B17@cisco.com>
From: 
To: 
X-OriginalArrivalTime: 10 Aug 2011 08:19:39.0558 (UTC) FILETIME=[3FB50460:01CC5736]
Cc: softwires@ietf.org, remi.despres@free.fr
Subject: [Softwires] Port allocation considerations (UPnP friendly and odd-even pairs possible) for 4rd
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 08:24:25 -0000

Ole,=20

|-----Original Message-----
|From: Ole Troan [mailto:ot@cisco.com]=20
|Sent: Tuesday, August 09, 2011 11:08 PM
|To: DENG Xiaohong ESP/PEK
|Cc: Tetsuya Murakami; Satoru Matsushima; R=E9mi Despr=E9s; Dan Wing
|Subject: Re: Port allocation considerations for 4rd
|
|Xiaohong,
|
|> Like I stated in the former mail in this thread, I'm not suggesting=20
|> 4rd use the exact algorithm as mine, but just suggesting 4rd=20
|algorithm=20
|> should take 2 more points in to account, as what Remi=20
|summarized in this thread before:
|> (a) optimize chances of UPnP to ask for an acceptable port=20
|when trying _consecutive ports_.
|> (b) mitigate this requirement to have odd-even pairs in the port sets
|
|if I interpreted Dan Wing's comments correctly, it is not at=20

Yes, you made it clearly.

|all clear that these should be requirements for a port mapping=20
|algorithm.

If I don't recall wrong, in the previous discussion, there are still =
other
points, for example, legacy FTP implementations (do not extended
to RFC2428) couple even-odd ports, to make this consideration=20
open to discuss.

P.S I extend this discussion to the list to lead to more comments to us,
hopefully.;-)

Xiaohong

|
|cheers,
|Ole
|
|

From xiaohong.deng@orange-ftgroup.com  Wed Aug 10 02:36:34 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F2521F873D for ; Wed, 10 Aug 2011 02:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.241
X-Spam-Level: 
X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=0.408,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1T6ofLf0TQb for ; Wed, 10 Aug 2011 02:36:33 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 161DA21F86C2 for ; Wed, 10 Aug 2011 02:36:33 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A5EE57B800A; Wed, 10 Aug 2011 11:38:22 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9A4EF738007; Wed, 10 Aug 2011 11:38:22 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 10 Aug 2011 11:35:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Aug 2011 17:35:11 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxXQM0E433K7146TX+2ru2VPb36pA==
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com> 
From: 
To: , 
X-OriginalArrivalTime: 10 Aug 2011 09:35:15.0310 (UTC) FILETIME=[CF39D8E0:01CC5740]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 09:36:34 -0000

=20

|-----Original Message-----
|From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20
|Sent: Wednesday, August 03, 2011 4:02 PM
|To: Rajiv Asati (rajiva)
|Cc: softwires@ietf.org
|Subject: Re: [Softwires] Clarification of the=20
|stateles/stateful discussion
|
|
|Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :
|
|> Satoru-san,
|>=20
|> This is an important point that most of us forget that=20
|restricting to=20
|> "n" ports doesn't equate to just "n" NAT sessions rather many more=20
|> than n sessions. We must add that to the 4v6 motivation=20
|draft as well=20
|> as to the 4v6 comparison draft.
|
|+1

+1. Session number are usually many more than ports number.

We tested port and sessions assumptions of applications on the A+P NAT,
which has been documented in A+P experiments draft, to investigate how=20
many ports and sessions they are costing on the NAT mapping table =
dynamically=20
from the first NAT bindings being established to the last one being=20
destroyed.

Some results below:

Usually, apps consume some more sessions than ports, and for the P2P =
apps, sessions
number could even be as a couple of times as ports number.

 For example, BitTorrent established five hundreds of sessions while the =
port consumption
 was under a hundred in the first minute of the communication, because =
when BitTorrent=20
initiates a downloading, it first uses the same source port to connect =
to the different destinations=20
(destination IP and port) therefore one source port multiplexing =
different sessions. Skype is
 another example that uses one source port to  multiplex different =
sessions thereby saving=20
source port consumptions on NAT.

 For exact figures of ports/session number for apps, see my page:=20
 =
http://opensourcev6transtechnologies.weebly.com/experiments-results.html
The session consumption comparison among the same set of applications is
 illustrated in Figure 4.=20

Xiaohong


|
|RD
|
|>=20
|>> port. There may be multiple session to different destinations using
|> the same
|>> external port. The 900G figure is valid, as long as internal hosts
|> reuse the
|>> same source address+port for different destinations.
|>=20
|> Cheers,
|> Rajiv
|>=20
|>=20
|>> -----Original Message-----
|>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
|> On Behalf
|>> Of Simon Perreault
|>> Sent: Tuesday, August 02, 2011 9:55 AM
|>> To: softwires@ietf.org
|>> Subject: Re: [Softwires] Clarification of the stateles/stateful
|> discussion
|>>=20
|>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
|>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
|>>>> Thanks, a clarification has made to clear a confusion of=20
|restricted
|> port
|>>>> set/ranges and NAT session table limitation. Even if a CPE is
|> allocated 256
|>>>> ports, NAT session can be made over 900G sessions in theory.
|> ('2^32'>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
|> 2^8<256
|>> ports>.
|>>>=20
|>>> This is only true for endpoint-dependent NATs, which are forbidden
|> by the
|>> BEHAVE
|>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have=20
|>>> endpoint-independent mapping behaviour. This means that each NAT
|> session
|>> will
|>>> consume one external port.
|>>=20
|>> Sorry, I confused the terminology. Each NAT *binding* will consume=20
|>> one external port. There may be multiple session to different=20
|>> destinations using
|> the same
|>> external port. The 900G figure is valid, as long as internal hosts
|> reuse the
|>> same source address+port for different destinations.
|>>=20
|>> Simon
|>> --
|>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|>> STUN/TURN server               --> http://numb.viagenie.ca
|>> _______________________________________________
|>> Softwires mailing list
|>> Softwires@ietf.org
|>> https://www.ietf.org/mailman/listinfo/softwires
|> _______________________________________________
|> Softwires mailing list
|> Softwires@ietf.org
|> https://www.ietf.org/mailman/listinfo/softwires
|
|
|

From Yiu_Lee@Cable.Comcast.com  Wed Aug 10 03:45:28 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF7F21F863E for ; Wed, 10 Aug 2011 03:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.147
X-Spam-Level: 
X-Spam-Status: No, score=-101.147 tagged_above=-999 required=5 tests=[AWL=-1.536, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEgAVOX-0oM4 for ; Wed, 10 Aug 2011 03:45:10 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 45C3321F8639 for ; Wed, 10 Aug 2011 03:45:10 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A78537B8010; Wed, 10 Aug 2011 12:47:00 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 97F907B800B; Wed, 10 Aug 2011 12:47:00 +0200 (CEST)
Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 10 Aug 2011 12:01:49 +0200
Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 02:02:50 +0200
Received: from omfeda08.si.francetelecom.fr ([10.98.3.82]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 9 Aug 2011 18:37:07 +0200
Received: from omfeda09.si.francetelecom.fr (unknown [10.98.77.161]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id F271038404A for ; Tue,  9 Aug 2011 18:37:06 +0200 (CEST)
Received: from omfeda09.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfeda09.si.francetelecom.fr (ESMTP service) with SMTP id E6F60C0392 for ; Tue,  9 Aug 2011 18:37:06 +0200 (CEST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 618C3C037E for ; Tue,  9 Aug 2011 18:37:06 +0200 (CEST)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136647926; Tue, 09 Aug 2011 12:37:03 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 9 Aug 2011 12:37:01 -0400
From: "Lee, Yiu" 
To: "xiaohong.deng@orange-ftgroup.com" , "bingxuere@gmail.com" 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMVrKPr8Livb8OOU6x5beYhOgl1Q==
Date: Tue, 9 Aug 2011 16:36:59 +0000
Message-ID: 
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC019190E1@ch-mailsrv.rd.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [69.241.25.0]
Content-Type: multipart/alternative; boundary="_000_CA66DA4D1384Ayiuleecablecomcastcom_"
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.163016
X-PerlMx-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' HTML_70_90 0.1, HTML_NO_HTTP 0.1, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, SPF_NONE 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_XOIP 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __MIME_CHARSET_FARAWAY 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
X-OriginalArrivalTime: 09 Aug 2011 16:37:07.0206 (UTC) FILETIME=[93E0EA60:01CC56B2]
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 10:45:28 -0000

--_000_CA66DA4D1384Ayiuleecablecomcastcom_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

WW91IGdvIGl0Lg0KDQpGcm9tOiA8eGlhb2hvbmcuZGVuZ0BvcmFuZ2UtZnRncm91cC5jb208bWFp
bHRvOnhpYW9ob25nLmRlbmdAb3JhbmdlLWZ0Z3JvdXAuY29tPj4NCkRhdGU6IFR1ZSwgOSBBdWcg
MjAxMSAyMzoyNToyMyArMDgwMA0KVG86IDxiaW5neHVlcmVAZ21haWwuY29tPG1haWx0bzpiaW5n
eHVlcmVAZ21haWwuY29tPj4sICJZaXUgTC4gTEVFIiA8eWl1X2xlZUBjYWJsZS5jb21jYXN0LmNv
bTxtYWlsdG86eWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbT4+DQpDYzogPHNvZnR3aXJlc0BpZXRm
Lm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbU29mdHdpcmVz
XSBDbGFyaWZpY2F0aW9uIG9mIHRoZSBzdGF0ZWxlcy9zdGF0ZWZ1bCBkaXNjdXNzaW9uDQoNClhp
YW9ob25nOiAgQ291bGQgeW91IGV4cGxhaW4gbW9yZSBhYm91dCB5b3VyIGNvbmNlcm4gb24gICJz
cGVjaWZpYyByZXF1aXJlbWVudHMgb24gSVB2NiBhZGRyZXNzIGZvcm1hdCI/DQpJTUhPLCBJIGRv
bid0IHNlZSBhIGlzc3VlIGluIDRyZCBJUHY2IGFkZHJlc3MgZm9ybWF0LCBhcyA0cmQgYXV0aG9y
cyBoYXZlIGJlZW4gY2FyZWZ1bGx5IGRlc2lnbmluZyB0aGUgcG9ydCBhbGxvY2F0aW9uIGFsZ29y
aXRobSBmb3IgQ0UgSVB2NiBwcmVmaXgsIHdoaWNoIGlzIGVmZmljaWVudGx5IGVuY29kZWQgKGxl
c3MgdGhhbiA2NCBiaXRzKSBhdCBsZWFzdCB0byBteSBleWVzLiAgT3BlbiB0byBoZWFyIG9wcHNp
dGUgb3BpbmlvbnMgIGlmIHlvdSBoYXZlIG9wZXJhdGlvbiBpc3N1ZXMgd2l0aCB5b3VyIG5ldHdv
cmsuICA7KQ0K

--_000_CA66DA4D1384Ayiuleecablecomcastcom_
Content-Type: text/html; charset="gb2312"
Content-ID: <2069D14284C99C4F9351AD6422351340@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable







You go it.









From: <xiaohong.deng@orange-ftgroup.com>

Date: Tue, 9 Aug 2011 23:25:23 +=
;0800

To: <bingxuere@gmail.com>, "Yiu L. LEE" <yiu_lee@cable.comcast.com>

Cc: <softwires@ietf.org>

Subject: RE: [Softwires] Clarificat=
ion of the stateles/stateful discussion











Xiaohong:&nbs=
p; Could you explain more about you=
r concern on  "specific requirements on IPv6 address format"=
? 



IMHO, I don't see a issue in 4rd IPv6 ad=
dress format, as 4rd authors have been carefully designing the port allocat=
ion algorithm for CE IPv6 prefix, which
 is efficiently encoded (less than 64 bits) at least to my eyes.  Open to hear oppsite opinions  if you have operation issues with your network.  ;) =






--_000_CA66DA4D1384Ayiuleecablecomcastcom_--

From rajiva@cisco.com  Wed Aug 10 05:38:17 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CAC21F87C7 for ; Wed, 10 Aug 2011 05:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level: 
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5XPo6X4M92x for ; Wed, 10 Aug 2011 05:38:16 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2DB21F869D for ; Wed, 10 Aug 2011 05:38:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5069; q=dns/txt; s=iport; t=1312979928; x=1314189528; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=N/LjfuUgSPRRdFrebpmaTiuZ0spi8dyQKpLml3a3e20=; b=M9f5LwL2ZG/tppEzZicwpZApNlKH9J9rVJXAVkgZJgoMDuN8oM9nOBFU qWZH+sit9AY4CVo/umhOEZS68ozO4FKbH854X6BIEEre+8rqUeHyla4zz 1Cz7V9EAChOapz0vxMeKpT8UqlmTbhG+ZEFn0e4W2UFYeA3rbv+eRbE5a s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai4BAFZ7Qk6tJV2a/2dsb2JhbABBl2mIQ4FMhVB3gUABAQEBAwEBAQ8BFAk+CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah1CfTwGeVIVnXwSHLi+QP4t4
X-IronPort-AV: E=Sophos;i="4.67,350,1309737600"; d="scan'208";a="11712274"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 10 Aug 2011 12:38:47 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7ACcjtQ016429;  Wed, 10 Aug 2011 12:38:45 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 10 Aug 2011 07:38:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Aug 2011 07:38:44 -0500
Message-ID: <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com>
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxXQM0E433K7146TX+2ru2VPb36pAAGKXTA
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr>
From: "Rajiv Asati (rajiva)" 
To: , 
X-OriginalArrivalTime: 10 Aug 2011 12:38:45.0470 (UTC) FILETIME=[71CAEFE0:01CC575A]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 12:38:17 -0000

Xiaohong,

Your work is very insightful. Thanks for pointing it out.

In your experimentation, did you use 'consecutive' port-set or =
'scattered' port-set or both? If just the former, then is it possible to =
experiment using 'scattered' port-set?

Cheers,
Rajiv


> -----Original Message-----
> From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Wednesday, August 10, 2011 5:35 AM
> To: despres.remi@laposte.net; Rajiv Asati (rajiva)
> Cc: softwires@ietf.org
> Subject: RE: [Softwires] Clarification of the stateles/stateful =
discussion
>=20
>=20
>=20
> |-----Original Message-----
> |From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]
> |Sent: Wednesday, August 03, 2011 4:02 PM
> |To: Rajiv Asati (rajiva)
> |Cc: softwires@ietf.org
> |Subject: Re: [Softwires] Clarification of the
> |stateles/stateful discussion
> |
> |
> |Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :
> |
> |> Satoru-san,
> |>
> |> This is an important point that most of us forget that
> |restricting to
> |> "n" ports doesn't equate to just "n" NAT sessions rather many more
> |> than n sessions. We must add that to the 4v6 motivation
> |draft as well
> |> as to the 4v6 comparison draft.
> |
> |+1
>=20
> +1. Session number are usually many more than ports number.
>=20
> We tested port and sessions assumptions of applications on the A+P =
NAT,
> which has been documented in A+P experiments draft, to investigate how
> many ports and sessions they are costing on the NAT mapping table =
dynamically
> from the first NAT bindings being established to the last one being
> destroyed.
>=20
> Some results below:
>=20
> Usually, apps consume some more sessions than ports, and for the P2P =
apps,
> sessions
> number could even be as a couple of times as ports number.
>=20
>  For example, BitTorrent established five hundreds of sessions while =
the port
> consumption
>  was under a hundred in the first minute of the communication, because =
when
> BitTorrent
> initiates a downloading, it first uses the same source port to connect =
to the
> different destinations
> (destination IP and port) therefore one source port multiplexing =
different
> sessions. Skype is
>  another example that uses one source port to  multiplex different =
sessions
> thereby saving
> source port consumptions on NAT.
>=20
>  For exact figures of ports/session number for apps, see my page:
>  =
http://opensourcev6transtechnologies.weebly.com/experiments-results.html
> The session consumption comparison among the same set of applications =
is
>  illustrated in Figure 4.
>=20
> Xiaohong
>=20
>=20
> |
> |RD
> |
> |>
> |>> port. There may be multiple session to different destinations =
using
> |> the same
> |>> external port. The 900G figure is valid, as long as internal hosts
> |> reuse the
> |>> same source address+port for different destinations.
> |>
> |> Cheers,
> |> Rajiv
> |>
> |>
> |>> -----Original Message-----
> |>> From: softwires-bounces@ietf.org =
[mailto:softwires-bounces@ietf.org]
> |> On Behalf
> |>> Of Simon Perreault
> |>> Sent: Tuesday, August 02, 2011 9:55 AM
> |>> To: softwires@ietf.org
> |>> Subject: Re: [Softwires] Clarification of the stateles/stateful
> |> discussion
> |>>
> |>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
> |>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
> |>>>> Thanks, a clarification has made to clear a confusion of
> |restricted
> |> port
> |>>>> set/ranges and NAT session table limitation. Even if a CPE is
> |> allocated 256
> |>>>> ports, NAT session can be made over 900G sessions in theory.
> |> ('2^32' |>>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
> |> 2^8<256
> |>> ports>.
> |>>>
> |>>> This is only true for endpoint-dependent NATs, which are =
forbidden
> |> by the
> |>> BEHAVE
> |>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have
> |>>> endpoint-independent mapping behaviour. This means that each NAT
> |> session
> |>> will
> |>>> consume one external port.
> |>>
> |>> Sorry, I confused the terminology. Each NAT *binding* will consume
> |>> one external port. There may be multiple session to different
> |>> destinations using
> |> the same
> |>> external port. The 900G figure is valid, as long as internal hosts
> |> reuse the
> |>> same source address+port for different destinations.
> |>>
> |>> Simon
> |>> --
> |>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> |>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> |>> STUN/TURN server               --> http://numb.viagenie.ca
> |>> _______________________________________________
> |>> Softwires mailing list
> |>> Softwires@ietf.org
> |>> https://www.ietf.org/mailman/listinfo/softwires
> |> _______________________________________________
> |> Softwires mailing list
> |> Softwires@ietf.org
> |> https://www.ietf.org/mailman/listinfo/softwires
> |
> |
> |

From internet-drafts@ietf.org  Wed Aug 10 06:58:38 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E821F8A96; Wed, 10 Aug 2011 06:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.496
X-Spam-Level: 
X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH6PlTcs7Wi1; Wed, 10 Aug 2011 06:58:37 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39D021F86B1; Wed, 10 Aug 2011 06:58:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.57
Message-ID: <20110810135837.28422.54357.idtracker@ietfa.amsl.com>
Date: Wed, 10 Aug 2011 06:58:37 -0700
Cc: softwires@ietf.org
Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-radius-ext-05.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 13:58:38 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Softwires Working Group of the IETF.

	Title           : RADIUS Extensions for Dual-Stack Lite
	Author(s)       : Roberta Maglione
                          Alain Durand
	Filename        : draft-ietf-softwire-dslite-radius-ext-05.txt
	Pages           : 11
	Date            : 2011-08-10

   Dual-Stack Lite is a solution to offer both IPv4 and IPv6
   connectivity to customers which are addressed only with an IPv6
   prefix.  Dual-Stack Lite requires to pre-configure the Dual-Stack
   Lite Address Family Transition Router (AFTR) tunnel information on
   the Basic Bridging BroadBand (B4) element.  In many networks, the
   customer profile information may be stored in Authentication
   Authorization and Accounting (AAA) servers while client
   configurations are mainly provided through Dynamic Host Configuration
   Protocol (DHCP).  This document specifies a new Remote Authentication
   Dial In User Service (RADIUS) attribute to carry Dual-Stack Lite
   Address Family Transition Router Tunnel name; the RADIUS attribute is
   defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option.  This
   RADIUS attribute is meant to be used between the RADIUS Server and
   the Network Access Server (NAS), it is not intended to be used
   directly between the Basic Bridging BroadBand element and the RADIUS
   Server.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-radius-ext-0=
5.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-dslite-radius-ext-05=
.txt

From yiu_lee@cable.comcast.com  Wed Aug 10 10:44:06 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4556721F88A6 for ; Wed, 10 Aug 2011 10:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.624
X-Spam-Level: 
X-Spam-Status: No, score=-101.624 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2kQuVVUq0F3 for ; Wed, 10 Aug 2011 10:44:05 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 43AC121F88A5 for ; Wed, 10 Aug 2011 10:44:05 -0700 (PDT)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.48301417; Wed, 10 Aug 2011 11:49:45 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 10 Aug 2011 13:44:32 -0400
From: "Lee, Yiu" 
To: "softwires@ietf.org" 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AQHMV4UoyPnFstq8S0CexTk5AuD6Og==
Date: Wed, 10 Aug 2011 17:44:31 +0000
Message-ID: 
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [69.241.25.0]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <70CBCEAF375D1D4B92986B8B1646E18F@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 17:44:06 -0000

I also agree this is a very nice piece of work. The current title is
"Implementing AplusP in the provider's IPv6-only network". I think this
not only covers "Implementing AplusP in an IPv6-only network", but also
captures very important information about the port usage in various
applications. I would like to see the draft to expand to include more
popular applications and OS, and the radio between port usage and number
of sessions. By reading Fig. 3 and Fig. 4 in
http://opensourcev6transtechnologies.weebly.com/experiments-results.html,
the radio is roughly 1 to 4. These experiments give concrete results to
operators to plan for any port-sharing technology.

Cheers,
Yiu


On 8/10/11 8:38 AM, "Rajiv Asati (rajiva)"  wrote:

>Xiaohong,
>
>Your work is very insightful. Thanks for pointing it out.
>
>In your experimentation, did you use 'consecutive' port-set or
>'scattered' port-set or both? If just the former, then is it possible to
>experiment using 'scattered' port-set?
>
>Cheers,
>Rajiv
>
>
>> -----Original Message-----
>> From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange-
>> ftgroup.com]
>> Sent: Wednesday, August 10, 2011 5:35 AM
>> To: despres.remi@laposte.net; Rajiv Asati (rajiva)
>> Cc: softwires@ietf.org
>> Subject: RE: [Softwires] Clarification of the stateles/stateful
>>discussion
>>=20
>>=20
>>=20
>> |-----Original Message-----
>> |From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]
>> |Sent: Wednesday, August 03, 2011 4:02 PM
>> |To: Rajiv Asati (rajiva)
>> |Cc: softwires@ietf.org
>> |Subject: Re: [Softwires] Clarification of the
>> |stateles/stateful discussion
>> |
>> |
>> |Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :
>> |
>> |> Satoru-san,
>> |>
>> |> This is an important point that most of us forget that
>> |restricting to
>> |> "n" ports doesn't equate to just "n" NAT sessions rather many more
>> |> than n sessions. We must add that to the 4v6 motivation
>> |draft as well
>> |> as to the 4v6 comparison draft.
>> |
>> |+1
>>=20
>> +1. Session number are usually many more than ports number.
>>=20
>> We tested port and sessions assumptions of applications on the A+P NAT,
>> which has been documented in A+P experiments draft, to investigate how
>> many ports and sessions they are costing on the NAT mapping table
>>dynamically
>> from the first NAT bindings being established to the last one being
>> destroyed.
>>=20
>> Some results below:
>>=20
>> Usually, apps consume some more sessions than ports, and for the P2P
>>apps,
>> sessions
>> number could even be as a couple of times as ports number.
>>=20
>>  For example, BitTorrent established five hundreds of sessions while
>>the port
>> consumption
>>  was under a hundred in the first minute of the communication, because
>>when
>> BitTorrent
>> initiates a downloading, it first uses the same source port to connect
>>to the
>> different destinations
>> (destination IP and port) therefore one source port multiplexing
>>different
>> sessions. Skype is
>>  another example that uses one source port to  multiplex different
>>sessions
>> thereby saving
>> source port consumptions on NAT.
>>=20
>>  For exact figures of ports/session number for apps, see my page:
>> =20
>>http://opensourcev6transtechnologies.weebly.com/experiments-results.html
>> The session consumption comparison among the same set of applications is
>>  illustrated in Figure 4.
>>=20
>> Xiaohong
>>=20
>>=20
>> |
>> |RD
>> |
>> |>
>> |>> port. There may be multiple session to different destinations using
>> |> the same
>> |>> external port. The 900G figure is valid, as long as internal hosts
>> |> reuse the
>> |>> same source address+port for different destinations.
>> |>
>> |> Cheers,
>> |> Rajiv
>> |>
>> |>
>> |>> -----Original Message-----
>> |>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
>> |> On Behalf
>> |>> Of Simon Perreault
>> |>> Sent: Tuesday, August 02, 2011 9:55 AM
>> |>> To: softwires@ietf.org
>> |>> Subject: Re: [Softwires] Clarification of the stateles/stateful
>> |> discussion
>> |>>
>> |>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
>> |>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
>> |>>>> Thanks, a clarification has made to clear a confusion of
>> |restricted
>> |> port
>> |>>>> set/ranges and NAT session table limitation. Even if a CPE is
>> |> allocated 256
>> |>>>> ports, NAT session can be made over 900G sessions in theory.
>> |> ('2^32'> |>>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
>> |> 2^8<256
>> |>> ports>.
>> |>>>
>> |>>> This is only true for endpoint-dependent NATs, which are forbidden
>> |> by the
>> |>> BEHAVE
>> |>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have
>> |>>> endpoint-independent mapping behaviour. This means that each NAT
>> |> session
>> |>> will
>> |>>> consume one external port.
>> |>>
>> |>> Sorry, I confused the terminology. Each NAT *binding* will consume
>> |>> one external port. There may be multiple session to different
>> |>> destinations using
>> |> the same
>> |>> external port. The 900G figure is valid, as long as internal hosts
>> |> reuse the
>> |>> same source address+port for different destinations.
>> |>>
>> |>> Simon
>> |>> --
>> |>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> |>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> |>> STUN/TURN server               --> http://numb.viagenie.ca
>> |>> _______________________________________________
>> |>> Softwires mailing list
>> |>> Softwires@ietf.org
>> |>> https://www.ietf.org/mailman/listinfo/softwires
>> |> _______________________________________________
>> |> Softwires mailing list
>> |> Softwires@ietf.org
>> |> https://www.ietf.org/mailman/listinfo/softwires
>> |
>> |
>> |
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


From behcetsarikaya@yahoo.com  Wed Aug 10 11:37:19 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DC21F8AA9 for ; Wed, 10 Aug 2011 11:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level: 
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGIgLJ6mhZSE for ; Wed, 10 Aug 2011 11:37:18 -0700 (PDT)
Received: from nm29-vm2.bullet.mail.ne1.yahoo.com (nm29-vm2.bullet.mail.ne1.yahoo.com [98.138.91.129]) by ietfa.amsl.com (Postfix) with SMTP id C62C421F85AA for ; Wed, 10 Aug 2011 11:37:08 -0700 (PDT)
Received: from [98.138.90.57] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 18:37:38 -0000
Received: from [98.138.89.192] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 18:37:38 -0000
Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 18:37:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 397467.71578.bm@omp1050.mail.ne1.yahoo.com
Received: (qmail 50708 invoked by uid 60001); 10 Aug 2011 18:37:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313001457; bh=kkppt+n2cWPAWvwxofsOJRdRah5Y63B/Ff1WNYIMjm0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4TQgQamwEwP6zc0PKzg/YZBxQLw2TsoVAI0yWSw0ycCFhWLgQta3BV2fCncb9dq8aJq6wDhsFYx5gQ+PHar6vSC9eGkTHhuIPURQIJpd8wh/C9KdRhTOmNvM0iJV/vmhw5P51PUb8fX25YA1bEnuqs+JcOJJ2l+rUq9kyEIMK/s=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qGFA0l/Ilt7IJFzAHF4MGSIjcd3TZICNv8taZBU/QJqpHJEEmfXIdI+huC9Lg8r5RYV18DhC0WRozxU+LFA8Gu2hzTuTwZs5AX5NS++flAclakKXeOY5BbGa3fRf6EKnDgMXWYdB2ngGs0atuPG1v6Jt4GSj7TUyxj94BmfUxF4=;
X-YMail-OSG: fCPbaWIVM1kJPHTISYkI3cub6wxDc0cG12AjWnItriMN8A8 ro525LJPGd1bn3ieqT8M2BWxPCYT7GnTOB8R_fMDIxBhkK7Cgl71bY19ANJE ba6EhPL4RCFKtdlmn5gLzOjwQsJSjxrASE2RVXRdrRagc5vznrW85T2YPJCA sie27i_rPp2yvPcf9zgmwzVz8sG8aaDhQQHipPl9fO9LX61aHRExP22Rlzkw Io7nsitqTpGpWUzT4OKuDeshHX4Tm_wUZ00WKKkPBVpIAn4ktijYZ0YbaKM3 TZQuXbc7KcqmZ1eMgzQcpFj44QK5exMOOa5fWg2wY1ctCHanf3jpn2pq7.1g wnQwacdI803CqkFqPx8zepuCoHA2cPMlX8D9DElWjTEkRmEETeLR1tcMVXes U2_8WC2T5QqpGkg_iD8QLZbVCDyqdZgfrde_nrKyOHcD.URIHR8FnWm.8.k5 jTeiL9pM-
Received: from [50.58.7.243] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 10 Aug 2011 11:37:37 PDT
X-Mailer: YahooMailWebService/0.8.113.313619
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net> 
Message-ID: <1313001457.13773.YahooMailNeo@web111402.mail.gq1.yahoo.com>
Date: Wed, 10 Aug 2011 11:37:37 -0700 (PDT)
From: Behcet Sarikaya 
To: Mark Townsley , Alain Durand 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "softwires@ietf.org list" , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 18:37:19 -0000

> 
> On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:
> 
>>  Following-up on the Quebec meeting, we would like to organize an interim 
> meeting end of September.
>>  We will focus on so-called stateless solutions and other remaining business 
> in the wg (multicast. mibs,...)
>>  that require more time than we usually have during a normal IETF meeting.
>>  The format will be a 2 day intensive meeting, with white board discussions, 
> similar to what we did in the early days of the working group.
>> 
>>  We've got an offer to host the meeting in Beijin on Sept. 26-27th or 
> 27-28th (right after the Boradband forum meeting in Shanghai).
> 
> Would it be possible to keep it in the same city as the BBF to cut down 
> travel/costs a bit more for those going to both?
> 

+1 and 
make it on Sept. 15-16.

Behcet


From xing@cernet.edu.cn  Wed Aug 10 20:05:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1F711E80BB for ; Wed, 10 Aug 2011 20:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.738
X-Spam-Level: 
X-Spam-Status: No, score=-99.738 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxLEACHZR9E1 for ; Wed, 10 Aug 2011 20:05:54 -0700 (PDT)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id C75D211E8086 for ; Wed, 10 Aug 2011 20:05:53 -0700 (PDT)
Received: from [127.0.0.1]([220.165.223.217]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104e4384d7; Thu, 11 Aug 2011 11:06:22 +0800
Message-ID: <4E434726.8010303@cernet.edu.cn>
Date: Thu, 11 Aug 2011 11:06:14 +0800
From: Xing Li 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Behcet Sarikaya 
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>	 <1313001457.13773.YahooMailNeo@web111402.mail.gq1.yahoo.com>
In-Reply-To: <1313001457.13773.YahooMailNeo@web111402.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: cxMbVr0B
Cc: "softwires@ietf.org list" , Behcet Sarikaya , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 03:05:55 -0000

于 2011/8/11 2:37, Behcet Sarikaya 写é“:
>
>> On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:
>>
>>>   Following-up on the Quebec meeting, we would like to organize an interim
>> meeting end of September.
>>>   We will focus on so-called stateless solutions and other remaining business
>> in the wg (multicast. mibs,...)
>>>   that require more time than we usually have during a normal IETF meeting.
>>>   The format will be a 2 day intensive meeting, with white board discussions,
>> similar to what we did in the early days of the working group.
>>>   We've got an offer to host the meeting in Beijin on Sept. 26-27th or
>> 27-28th (right after the Boradband forum meeting in Shanghai).
>>
>> Would it be possible to keep it in the same city as the BBF to cut down
>> travel/costs a bit more for those going to both?
>>
> +1 and
> make it on Sept. 15-16.

+1, I also prefer Sept. 15-16. xing

> Behcet
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>


From xiaohong.deng@orange-ftgroup.com  Thu Aug 11 03:43:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4962D21F89C2 for ; Thu, 11 Aug 2011 03:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level: 
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=0.373,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzIkvJxqpfR9 for ; Thu, 11 Aug 2011 03:43:45 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0817821F89C1 for ; Thu, 11 Aug 2011 03:43:45 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69F4BFC4008; Thu, 11 Aug 2011 12:44:18 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5DBB7FC4006; Thu, 11 Aug 2011 12:44:18 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 11 Aug 2011 12:44:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Aug 2011 18:44:13 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195AE60@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxYE5xoS4oZw4b7QEWChBQ0TwxkaA==
References: <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> 
From: 
To: , 
X-OriginalArrivalTime: 11 Aug 2011 10:44:18.0263 (UTC) FILETIME=[9F080E70:01CC5813]
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 10:43:46 -0000

Thanks Yiu, your suggestion makes a lot of sense, and I'm considering =
it.

Cheers,
Xiaohong=20

|-----Original Message-----
|From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20
|Sent: Thursday, August 11, 2011 1:45 AM
|To: softwires@ietf.org
|Subject: Re: [Softwires] Clarification of the=20
|stateles/stateful discussion
|
|I also agree this is a very nice piece of work. The current=20
|title is "Implementing AplusP in the provider's IPv6-only=20
|network". I think this not only covers "Implementing AplusP in=20
|an IPv6-only network", but also captures very important=20
|information about the port usage in various applications. I=20
|would like to see the draft to expand to include more popular=20
|applications and OS, and the radio between port usage and=20
|number of sessions. By reading Fig. 3 and Fig. 4 in=20
|http://opensourcev6transtechnologies.weebly.com/experiments-res
|ults.html,
|the radio is roughly 1 to 4. These experiments give concrete=20
|results to operators to plan for any port-sharing technology.
|
|Cheers,
|Yiu
|
|
|On 8/10/11 8:38 AM, "Rajiv Asati (rajiva)"  wrote:
|
|>Xiaohong,
|>
|>Your work is very insightful. Thanks for pointing it out.
|>
|>In your experimentation, did you use 'consecutive' port-set or=20
|>'scattered' port-set or both? If just the former, then is it possible=20
|>to experiment using 'scattered' port-set?
|>
|>Cheers,
|>Rajiv
|>
|>
|>> -----Original Message-----
|>> From: xiaohong.deng@orange-ftgroup.com=20
|[mailto:xiaohong.deng@orange- =20
|>>ftgroup.com]
|>> Sent: Wednesday, August 10, 2011 5:35 AM
|>> To: despres.remi@laposte.net; Rajiv Asati (rajiva)
|>> Cc: softwires@ietf.org
|>> Subject: RE: [Softwires] Clarification of the stateles/stateful=20
|>>discussion
|>>=20
|>>=20
|>>=20
|>> |-----Original Message-----
|>> |From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]
|>> |Sent: Wednesday, August 03, 2011 4:02 PM
|>> |To: Rajiv Asati (rajiva)
|>> |Cc: softwires@ietf.org
|>> |Subject: Re: [Softwires] Clarification of the stateles/stateful=20
|>> |discussion
|>> |
|>> |
|>> |Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :
|>> |
|>> |> Satoru-san,
|>> |>
|>> |> This is an important point that most of us forget that
|>> |restricting to
|>> |> "n" ports doesn't equate to just "n" NAT sessions rather=20
|many more=20
|>> |> than n sessions. We must add that to the 4v6 motivation
|>> |draft as well
|>> |> as to the 4v6 comparison draft.
|>> |
|>> |+1
|>>=20
|>> +1. Session number are usually many more than ports number.
|>>=20
|>> We tested port and sessions assumptions of applications on the A+P=20
|>>NAT,  which has been documented in A+P experiments draft, to=20
|>>investigate how  many ports and sessions they are costing on the NAT=20
|>>mapping table dynamically  from the first NAT bindings being=20
|>>established to the last one being  destroyed.
|>>=20
|>> Some results below:
|>>=20
|>> Usually, apps consume some more sessions than ports, and=20
|for the P2P=20
|>>apps,  sessions  number could even be as a couple of times as ports=20
|>>number.
|>>=20
|>>  For example, BitTorrent established five hundreds of=20
|sessions while=20
|>>the port  consumption
|>>  was under a hundred in the first minute of the communication,=20
|>>because when  BitTorrent  initiates a downloading, it first uses the=20
|>>same source port to connect to the  different destinations =20
|>>(destination IP and port) therefore one source port multiplexing=20
|>>different  sessions. Skype is
|>>  another example that uses one source port to  multiplex different=20
|>>sessions  thereby saving  source port consumptions on NAT.
|>>=20
|>>  For exact figures of ports/session number for apps, see my page:
|>> =20
|>>http://opensourcev6transtechnologies.weebly.com/experiments-r
|esults.ht
|>>ml  The session consumption comparison among the same set of=20
|>>applications is
|>>  illustrated in Figure 4.
|>>=20
|>> Xiaohong
|>>=20
|>>=20
|>> |
|>> |RD
|>> |
|>> |>
|>> |>> port. There may be multiple session to different destinations=20
|>> |>> using
|>> |> the same
|>> |>> external port. The 900G figure is valid, as long as internal=20
|>> |>> hosts
|>> |> reuse the
|>> |>> same source address+port for different destinations.
|>> |>
|>> |> Cheers,
|>> |> Rajiv
|>> |>
|>> |>
|>> |>> -----Original Message-----
|>> |>> From: softwires-bounces@ietf.org=20
|>> |>> [mailto:softwires-bounces@ietf.org]
|>> |> On Behalf
|>> |>> Of Simon Perreault
|>> |>> Sent: Tuesday, August 02, 2011 9:55 AM
|>> |>> To: softwires@ietf.org
|>> |>> Subject: Re: [Softwires] Clarification of the stateles/stateful
|>> |> discussion
|>> |>>
|>> |>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
|>> |>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
|>> |>>>> Thanks, a clarification has made to clear a confusion of
|>> |restricted
|>> |> port
|>> |>>>> set/ranges and NAT session table limitation. Even if a CPE is
|>> |> allocated 256
|>> |>>>> ports, NAT session can be made over 900G sessions in theory.
|>> |> ('2^32'> |>>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
|>> |> 2^8<256
|>> |>> ports>.
|>> |>>>
|>> |>>> This is only true for endpoint-dependent NATs, which are=20
|>> |>>> forbidden
|>> |> by the
|>> |>> BEHAVE
|>> |>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have=20
|>> |>>> endpoint-independent mapping behaviour. This means=20
|that each NAT
|>> |> session
|>> |>> will
|>> |>>> consume one external port.
|>> |>>
|>> |>> Sorry, I confused the terminology. Each NAT *binding* will=20
|>> |>> consume one external port. There may be multiple session to=20
|>> |>> different destinations using
|>> |> the same
|>> |>> external port. The 900G figure is valid, as long as internal=20
|>> |>> hosts
|>> |> reuse the
|>> |>> same source address+port for different destinations.
|>> |>>
|>> |>> Simon
|>> |>> --
|>> |>> DTN made easy, lean, and smart -->=20
|http://postellation.viagenie.ca
|>> |>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|>> |>> STUN/TURN server               --> http://numb.viagenie.ca
|>> |>> _______________________________________________
|>> |>> Softwires mailing list
|>> |>> Softwires@ietf.org
|>> |>> https://www.ietf.org/mailman/listinfo/softwires
|>> |> _______________________________________________
|>> |> Softwires mailing list
|>> |> Softwires@ietf.org
|>> |> https://www.ietf.org/mailman/listinfo/softwires
|>> |
|>> |
|>> |
|>_______________________________________________
|>Softwires mailing list
|>Softwires@ietf.org
|>https://www.ietf.org/mailman/listinfo/softwires
|
|
|

From xiaohong.deng@orange-ftgroup.com  Thu Aug 11 04:01:30 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5924021F8A4F for ; Thu, 11 Aug 2011 04:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.059
X-Spam-Level: 
X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1+QYC+10fqD for ; Thu, 11 Aug 2011 04:01:29 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4263221F8A1A for ; Thu, 11 Aug 2011 04:01:29 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C21BC8C0004; Thu, 11 Aug 2011 13:02:53 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id B7A518B8007; Thu, 11 Aug 2011 13:02:53 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 11 Aug 2011 13:02:03 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Aug 2011 19:01:58 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxXQM0E433K7146TX+2ru2VPb36pAAGKXTAAC8RD8A=
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com>
From: 
To: , 
X-OriginalArrivalTime: 11 Aug 2011 11:02:03.0004 (UTC) FILETIME=[19AAA3C0:01CC5816]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 11:01:30 -0000

Rajiv,

Thanks!

It's 'consecutive' port-set, and thanks for your proposal for testing  =
'scattered' port-set.

But I don't understand will the figure be different with 'scattered' =
port-set NAT? To my knowledge, it's something todo with app's behaviours =
and NAT type(EIM in our test).
Would you explain if I miss something? Thanks

Cheers,
Xiaohong

|-----Original Message-----
|From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20
|Sent: Wednesday, August 10, 2011 8:39 PM
|To: DENG Xiaohong ESP/PEK; despres.remi@laposte.net
|Cc: softwires@ietf.org
|Subject: RE: [Softwires] Clarification of the=20
|stateles/stateful discussion
|
|Xiaohong,
|
|Your work is very insightful. Thanks for pointing it out.
|
|In your experimentation, did you use 'consecutive' port-set or=20
|'scattered' port-set or both? If just the former, then is it=20
|possible to experiment using 'scattered' port-set?
|
|Cheers,
|Rajiv
|
|
|> -----Original Message-----
|> From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange-=20
|> ftgroup.com]
|> Sent: Wednesday, August 10, 2011 5:35 AM
|> To: despres.remi@laposte.net; Rajiv Asati (rajiva)
|> Cc: softwires@ietf.org
|> Subject: RE: [Softwires] Clarification of the stateles/stateful=20
|> discussion
|>=20
|>=20
|>=20
|> |-----Original Message-----
|> |From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]
|> |Sent: Wednesday, August 03, 2011 4:02 PM
|> |To: Rajiv Asati (rajiva)
|> |Cc: softwires@ietf.org
|> |Subject: Re: [Softwires] Clarification of the stateles/stateful=20
|> |discussion
|> |
|> |
|> |Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :
|> |
|> |> Satoru-san,
|> |>
|> |> This is an important point that most of us forget that
|> |restricting to
|> |> "n" ports doesn't equate to just "n" NAT sessions rather=20
|many more=20
|> |> than n sessions. We must add that to the 4v6 motivation
|> |draft as well
|> |> as to the 4v6 comparison draft.
|> |
|> |+1
|>=20
|> +1. Session number are usually many more than ports number.
|>=20
|> We tested port and sessions assumptions of applications on the A+P=20
|> NAT, which has been documented in A+P experiments draft, to=20
|> investigate how many ports and sessions they are costing on the NAT=20
|> mapping table dynamically from the first NAT bindings being=20
|> established to the last one being destroyed.
|>=20
|> Some results below:
|>=20
|> Usually, apps consume some more sessions than ports, and for the P2P=20
|> apps, sessions number could even be as a couple of times as ports=20
|> number.
|>=20
|>  For example, BitTorrent established five hundreds of sessions while=20
|> the port consumption  was under a hundred in the first minute of the=20
|> communication, because when BitTorrent initiates a downloading, it=20
|> first uses the same source port to connect to the different=20
|> destinations (destination IP and port) therefore one source port=20
|> multiplexing different sessions. Skype is  another example that uses=20
|> one source port to  multiplex different sessions thereby=20
|saving source=20
|> port consumptions on NAT.
|>=20
|>  For exact figures of ports/session number for apps, see my page:
|> =20
|>=20
|http://opensourcev6transtechnologies.weebly.com/experiments-results.ht
|> ml The session consumption comparison among the same set of=20
|> applications is  illustrated in Figure 4.
|>=20
|> Xiaohong
|>=20
|>=20
|> |
|> |RD
|> |
|> |>
|> |>> port. There may be multiple session to different destinations=20
|> |>> using
|> |> the same
|> |>> external port. The 900G figure is valid, as long as=20
|internal hosts
|> |> reuse the
|> |>> same source address+port for different destinations.
|> |>
|> |> Cheers,
|> |> Rajiv
|> |>
|> |>
|> |>> -----Original Message-----
|> |>> From: softwires-bounces@ietf.org=20
|> |>> [mailto:softwires-bounces@ietf.org]
|> |> On Behalf
|> |>> Of Simon Perreault
|> |>> Sent: Tuesday, August 02, 2011 9:55 AM
|> |>> To: softwires@ietf.org
|> |>> Subject: Re: [Softwires] Clarification of the stateles/stateful
|> |> discussion
|> |>>
|> |>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
|> |>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
|> |>>>> Thanks, a clarification has made to clear a confusion of
|> |restricted
|> |> port
|> |>>>> set/ranges and NAT session table limitation. Even if a CPE is
|> |> allocated 256
|> |>>>> ports, NAT session can be made over 900G sessions in theory.
|> |> ('2^32' |>>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
|> |> 2^8<256
|> |>> ports>.
|> |>>>
|> |>>> This is only true for endpoint-dependent NATs, which are=20
|> |>>> forbidden
|> |> by the
|> |>> BEHAVE
|> |>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have=20
|> |>>> endpoint-independent mapping behaviour. This means that each NAT
|> |> session
|> |>> will
|> |>>> consume one external port.
|> |>>
|> |>> Sorry, I confused the terminology. Each NAT *binding*=20
|will consume=20
|> |>> one external port. There may be multiple session to different=20
|> |>> destinations using
|> |> the same
|> |>> external port. The 900G figure is valid, as long as=20
|internal hosts
|> |> reuse the
|> |>> same source address+port for different destinations.
|> |>>
|> |>> Simon
|> |>> --
|> |>> DTN made easy, lean, and smart -->=20
|http://postellation.viagenie.ca
|> |>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|> |>> STUN/TURN server               --> http://numb.viagenie.ca
|> |>> _______________________________________________
|> |>> Softwires mailing list
|> |>> Softwires@ietf.org
|> |>> https://www.ietf.org/mailman/listinfo/softwires
|> |> _______________________________________________
|> |> Softwires mailing list
|> |> Softwires@ietf.org
|> |> https://www.ietf.org/mailman/listinfo/softwires
|> |
|> |
|> |
|

From simon.perreault@viagenie.ca  Thu Aug 11 05:37:22 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C524B21F8546 for ; Thu, 11 Aug 2011 05:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlmAwDNVoVl9 for ; Thu, 11 Aug 2011 05:37:22 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6C421F8514 for ; Thu, 11 Aug 2011 05:37:22 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 09F5E21F49; Thu, 11 Aug 2011 08:37:55 -0400 (EDT)
Message-ID: <4E43CD23.9060308@viagenie.ca>
Date: Thu, 11 Aug 2011 08:37:55 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: xiaohong.deng@orange-ftgroup.com
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 12:37:22 -0000

On 2011-08-11 07:01, xiaohong.deng@orange-ftgroup.com wrote:
> But I don't understand will the figure be different with 'scattered'
> port-set NAT? To my knowledge, it's something todo with app's
> behaviours and NAT type(EIM in our test). Would you explain if I miss
> something? Thanks

As it was discussed in this thread [*], an EIM NAT will, in theory, only
be able to support a number of sessions roughly equal to the number of
external ports. That is because internal hosts typically do not reuse
source port numbers for sessions to different destinations.

If your tests show otherwise, it would be very important for this
working group to understand exactly why theory does not match practice.

[*] http://www.ietf.org/mail-archive/web/softwires/current/msg02461.html

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From nejc@skoberne.net  Thu Aug 11 12:59:50 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B79221F8B4B for ; Thu, 11 Aug 2011 12:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd5LDovP+7T0 for ; Thu, 11 Aug 2011 12:59:49 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0221F8B42 for ; Thu, 11 Aug 2011 12:59:48 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 5F47D22780FC; Thu, 11 Aug 2011 22:00:22 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgAAwp8bspX4; Thu, 11 Aug 2011 22:00:20 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id ED25B22780FB; Thu, 11 Aug 2011 22:00:19 +0200 (CEST)
Message-ID: <4E4434D2.1080801@skoberne.net>
Date: Thu, 11 Aug 2011 21:00:18 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: Olaf Maennel , Jozef Woods , Roshan Mosaheb , Iain Phillips 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 19:59:50 -0000

Hello all,

I am working on a trade-off analysis of IPv4 address sharing mechanisms. I am 
replying to Remi's e-mail (sent before I subscribed to the list):

> I therefore worked out a way to present the range of solutions to be compared, 
> with the following taken in consideration:
> - The stateless/stateful IPv4 across IPv6 comparison isn't limited to IPv4 
>   shared addresses (applies also to exclusive IPv4 customer addresses).
> - If there is, in BR/AFBR's, no Customer state (i.e. no states referring to 
>   individual IPv6 prefixes), there can't be per-transport-connection state either.
> - CE-CE direct paths are possible only if IPv4/IPv6 mappings of BR/AFBR's don't 
>   depend on Customer state.
>
> The proposed document structure is as follows, with pros and cons for each section:
> a) Stateful per transport connection (and also stateful per customer IPv6 prefix)
>    e.g. DS-lite with CGN
> b) Stateful per customer IPv6 prefix (but Stateless per transport connection)
>    e.g. draft-cui-softwire-host-4over6-06
> c) Stateless per customer IPv6 prefix (and also stateless per transport connection)
>   - Hub-an-spoke
>      TBD
>    - Direct CE-CE paths (mesh)
>      . Encapsulation based
>        e.g. draft-murakami-softwire-4rd-00 alias
>      . Translation based
>        e.g. draft-murakami-softwire-4v6-translation-00

I think we really need such a comparison document. As a newcomer I spent a lot
of time digging up all the scattered documents here and it wasn't easy grasp the 
"big picture" of what has been proposed. I think we also need a trade-off analysis 
document, which I am writing at the moment.

Anyway, I am not sure I agree with the structure suggested. I think we should try
to be even more general and try to abstract all packet manipulations. I have prepared
a table which tries to document all so-far implemented combinations (IPv4 address sharing
mechanisms + 4via6 mechanisms, the intersection includes all but NAT444, which is
only IPv4 address sharing mechanism and Public 4over6 which is only a 4via6 mechanism). 
It would be useful to know if any of the missing combinations might be useful in 
practice as well, I hope this table will help in determining that.

I will be very happy to hear any comments on the comparison. It's only a 1-page table.

The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf

Thanks,
Nejc



From rpenno@juniper.net  Thu Aug 11 22:58:18 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C9D11E8087 for ; Thu, 11 Aug 2011 22:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level: 
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2qRB9tp6QT1 for ; Thu, 11 Aug 2011 22:58:16 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3221F84E0 for ; Thu, 11 Aug 2011 22:58:08 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTkTBDpKN8dg1f1knUt8/WFLS4Xs8POMA@postini.com; Thu, 11 Aug 2011 22:58:45 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 11 Aug 2011 22:56:46 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 12 Aug 2011 01:56:45 -0400
From: Reinaldo Penno 
To: =?iso-8859-2?Q?Nejc_=A9koberne?= , "softwires@ietf.org" 
Date: Fri, 12 Aug 2011 01:56:40 -0400
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxYYVjBguDw6tv3SFaJj52kAhK40gAU0H0K
Message-ID: 
In-Reply-To: <4E4434D2.1080801@skoberne.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.9.0.110114
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "EXT - O.M.Maennel@lboro.ac.uk" , "EXT - I.W.Phillips@lboro.ac.uk" , Roshan Mosaheb , Jozef Woods 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 05:58:18 -0000

I like it. Nice and clean diagram.

I believe NAT64 & 'provision of additional IP address and port ranges'
should be 'yes'. NAT64 uses a IPv4 NAT pool much like NAT444 and needs to
support all the bells and whistles...APP, EIM, HP, PB, etc

Same goes for " Requirements for provision of additional IPv4 addresses and
port ranges" and "NAT64". I believe it should be 'none' since it is
automatic.

Thanks,

Reinaldo


On 8/11/11 1:00 PM, "Nejc =A9koberne"  wrote:

> Hello all,
>=20
> I am working on a trade-off analysis of IPv4 address sharing mechanisms. =
I am
> replying to Remi's e-mail (sent before I subscribed to the list):
>=20
>> I therefore worked out a way to present the range of solutions to be
>> compared,=20
>> with the following taken in consideration:
>> - The stateless/stateful IPv4 across IPv6 comparison isn't limited to IP=
v4
>>   shared addresses (applies also to exclusive IPv4 customer addresses).
>> - If there is, in BR/AFBR's, no Customer state (i.e. no states referring=
 to
>>   individual IPv6 prefixes), there can't be per-transport-connection sta=
te
>> either.
>> - CE-CE direct paths are possible only if IPv4/IPv6 mappings of BR/AFBR'=
s
>> don't=20
>>   depend on Customer state.
>>=20
>> The proposed document structure is as follows, with pros and cons for ea=
ch
>> section:
>> a) Stateful per transport connection (and also stateful per customer IPv=
6
>> prefix)
>>    e.g. DS-lite with CGN
>> b) Stateful per customer IPv6 prefix (but Stateless per transport connec=
tion)
>>    e.g. draft-cui-softwire-host-4over6-06
>> c) Stateless per customer IPv6 prefix (and also stateless per transport
>> connection)
>>   - Hub-an-spoke
>>      TBD
>>    - Direct CE-CE paths (mesh)
>>      . Encapsulation based
>>        e.g. draft-murakami-softwire-4rd-00 alias
>>      . Translation based
>>        e.g. draft-murakami-softwire-4v6-translation-00
>=20
> I think we really need such a comparison document. As a newcomer I spent =
a lot
> of time digging up all the scattered documents here and it wasn't easy gr=
asp
> the=20
> "big picture" of what has been proposed. I think we also need a trade-off
> analysis=20
> document, which I am writing at the moment.
>=20
> Anyway, I am not sure I agree with the structure suggested. I think we sh=
ould
> try
> to be even more general and try to abstract all packet manipulations. I h=
ave
> prepared
> a table which tries to document all so-far implemented combinations (IPv4
> address sharing
> mechanisms + 4via6 mechanisms, the intersection includes all but NAT444, =
which
> is
> only IPv4 address sharing mechanism and Public 4over6 which is only a 4vi=
a6
> mechanism).=20
> It would be useful to know if any of the missing combinations might be us=
eful
> in=20
> practice as well, I hope this table will help in determining that.
>=20
> I will be very happy to hear any comments on the comparison. It's only a
> 1-page table.
>=20
> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
>=20
> Thanks,
> Nejc
>=20
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From nejc@skoberne.net  Fri Aug 12 00:28:06 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E27921F84CF for ; Fri, 12 Aug 2011 00:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcxhP2Lg35Rv for ; Fri, 12 Aug 2011 00:28:05 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 74FE021F84CB for ; Fri, 12 Aug 2011 00:28:03 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 5100A22780F5; Fri, 12 Aug 2011 09:26:25 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnAOhuG9+pIH; Fri, 12 Aug 2011 09:26:23 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id D3AF922780F3; Fri, 12 Aug 2011 09:26:22 +0200 (CEST)
Message-ID: <4E44D59C.3040701@skoberne.net>
Date: Fri, 12 Aug 2011 08:26:20 +0100
From: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Reinaldo Penno 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , "EXT - O.M.Maennel@lboro.ac.uk" , "EXT - I.W.Phillips@lboro.ac.uk" , Roshan Mosaheb , Jozef Woods 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 07:28:06 -0000

Dear Reinaldo,

> I like it. Nice and clean diagram.

Thanks.

> I believe NAT64&  'provision of additional IP address and port ranges'
> should be 'yes'. NAT64 uses a IPv4 NAT pool much like NAT444 and needs to
> support all the bells and whistles...APP, EIM, HP, PB, etc
> 
> Same goes for " Requirements for provision of additional IPv4 addresses and
> port ranges" and "NAT64". I believe it should be 'none' since it is
> automatic.

Of course, that's true, my mistake. I already fixed it and reuploaded it so 
there's an updaten version online already.

Thanks!

Nejc

From xiaohong.deng@orange-ftgroup.com  Fri Aug 12 05:32:06 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5964E21F8538 for ; Fri, 12 Aug 2011 05:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level: 
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.291,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3t0ERzP6UpC for ; Fri, 12 Aug 2011 05:32:04 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5837221F84ED for ; Fri, 12 Aug 2011 05:32:04 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7FFE958005; Fri, 12 Aug 2011 14:41:12 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5FC906FCAFB; Fri, 12 Aug 2011 14:41:02 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Aug 2011 14:32:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2011 20:32:26 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195B02C@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <4E43CD23.9060308@viagenie.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxYI4GaqsTxRsAjS0SERBqpe2gfSQAw6dDg
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E43CD23.9060308@viagenie.ca>
From: 
To: 
X-OriginalArrivalTime: 12 Aug 2011 12:32:30.0645 (UTC) FILETIME=[E734AE50:01CC58EB]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 12:32:06 -0000

=20

|-----Original Message-----
|From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20
|Sent: Thursday, August 11, 2011 8:38 PM
|To: DENG Xiaohong ESP/PEK
|Cc: rajiva@cisco.com; despres.remi@laposte.net; softwires@ietf.org
|Subject: Re: [Softwires] Clarification of the=20
|stateles/stateful discussion
|
|On 2011-08-11 07:01, xiaohong.deng@orange-ftgroup.com wrote:
|> But I don't understand will the figure be different with 'scattered'
|> port-set NAT? To my knowledge, it's something todo with app's=20
|> behaviours and NAT type(EIM in our test). Would you explain=20
|if I miss=20
|> something? Thanks
|
|As it was discussed in this thread [*], an EIM NAT will, in=20

Understood EIM behaviors. My point is port-range
NAT or scattered port-set NAT is nothing to do with EIM.

|theory, only be able to support a number of sessions roughly=20
|equal to the number of external ports. That is because=20
|internal hosts typically do not reuse source port numbers for=20
|sessions to different destinations.

Could you explain how this conclusion was drawed?

According to [a], port usage in figure 3 and session usage in figure 4 =
show that,
for Google Earth, port and session usage are roughly the same,
while firefox session usage is roughly 1.5 times as port usage.

|
|If your tests show otherwise, it would be very important for=20
|this working group to understand exactly why theory does not=20
|match practice.

BitTorrent and Skype are definitely cases that show othersiwse.

As the detailed analysis I stated in the previous email, but don't mind =
to
explain again:

When BT Client initiates a downloading it first uses the same=20
source port to connect to the different destinations (destination IP and =
port)=20
therefore a source port multiplexing different sessions. Data shows =
maxium
port usuage reaches 160, while session usuage continously stays above =
450.

Skype is another example that uses a source port to multiplex=20
different sessions thereby introducing less source port than sessions on =
NAT.
Data shows less than a couple of ports achieve more than a hundred =
sessions!

But, don't ask me why, as  niether did I write code for BT Client nor =
for Skype. ;0

[a] =
http://opensourcev6transtechnologies.weebly.com/experiments-results.html


Cheers,
Xiaohong
---
Open-source PCP Client : =
http://opensourcev6transtechnologies.weebly.com/
A+P experiments results: =
http://opensourcev6transtechnologies.weebly.com/experiments-results.html
IETF81 PCP demo page: =
http://opensourcev6transtechnologies.weebly.com/ietf-81-pcp-demo-site.htm=
l
|
|[*]=20
|http://www.ietf.org/mail-archive/web/softwires/current/msg02461.html
|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca
|

From mohamed.boucadair@orange-ftgroup.com  Fri Aug 12 05:59:24 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D143721F8997 for ; Fri, 12 Aug 2011 05:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2lTQGQh+m8l for ; Fri, 12 Aug 2011 05:59:24 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2D91E21F84E4 for ; Fri, 12 Aug 2011 05:59:24 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id D6F253741C5; Fri, 12 Aug 2011 14:59:57 +0200 (CEST)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BEEE8384055; Fri, 12 Aug 2011 14:59:57 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 12 Aug 2011 14:59:57 +0200
From: 
To: Dave Thaler , Satoru Matsushima , "softwires@ietf.org list" 
Date: Fri, 12 Aug 2011 14:59:56 +0200
Thread-Topic: [Softwires] Yesterday's slides
Thread-Index: AQHMTUvbTxfJJyZcp0uk7fBnTS8kdpUCIpYggBcgJIA=
Message-ID: <94C682931C08B048B7A8645303FDC9F33E54A62ABC@PUEXCB1B.nanterre.francetelecom.fr>
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.12.122415
Subject: Re: [Softwires] Yesterday's slides
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 12:59:24 -0000

Dear Dave,

I would personally appreciate if you can draft your thoughts in form of an =
I-D before the meeting so that we can comment on them and discuss the point=
s you are raising.

FWIW, draft-operators-softwire-stateless-4v6-motivation does not argue agai=
nst stateful but it elaborates on a set of motivations to explain why state=
less is also needed. -00 and -01 of the draft includes a set of open issues=
. That section has been removed because of the comments received in this li=
st.

As for the point about failure modes, this is discussed in: draft-dec-state=
less-4v6

Cheers,
Med

-----Message d'origine-----
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Dave Thaler
Envoy=E9 : jeudi 28 juillet 2011 21:45
=C0 : Satoru Matsushima; softwires@ietf.org list
Objet : Re: [Softwires] Yesterday's slides

Attaching here since they don't seem to be posted yet.

-Dave

> -----Original Message-----
> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
> Behalf Of Satoru Matsushima
> Sent: Thursday, July 28, 2011 1:29 PM
> To: softwires@ietf.org list
> Subject: [Softwires] Yesterday's slides
>=20
> Hi,
>=20
> Could someone tell me where is Dave Thaler's slides?
>=20
> Best regards,
> --satoru
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From simon.perreault@viagenie.ca  Fri Aug 12 06:21:14 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5072821F8A69 for ; Fri, 12 Aug 2011 06:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Level: 
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIwqFINRNR1O for ; Fri, 12 Aug 2011 06:21:13 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id A53D221F8A67 for ; Fri, 12 Aug 2011 06:21:13 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 025F020DC2; Fri, 12 Aug 2011 09:21:49 -0400 (EDT)
Message-ID: <4E4528ED.2050500@viagenie.ca>
Date: Fri, 12 Aug 2011 09:21:49 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: xiaohong.deng@orange-ftgroup.com
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E43CD23.9060308@viagenie.ca> <0962B0BEF842A24191AD9BE41A8DD2FC0195B02C@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0195B02C@ch-mailsrv.rd.francetelecom.fr>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 13:21:14 -0000

Initially I wrote a long email with a point-by-point reply, but then I
found what I think could be the source of our misunderstanding:

On 2011-08-12 08:32, xiaohong.deng@orange-ftgroup.com wrote:
> BitTorrent and Skype are definitely cases that show othersiwse.
> 
> As the detailed analysis I stated in the previous email, but don't mind to
> explain again:
> 
> When BT Client initiates a downloading it first uses the same 
> source port to connect to the different destinations (destination IP and port) 
> therefore a source port multiplexing different sessions. Data shows maxium
> port usuage reaches 160, while session usuage continously stays above 450.
> 
> Skype is another example that uses a source port to multiplex 
> different sessions thereby introducing less source port than sessions on NAT.
> Data shows less than a couple of ports achieve more than a hundred sessions!

In your experiments, do you measure port and session usage on the NAT,
on the internal host, or both? It's not clear to me when reading your
experiment results at
http://opensourcev6transtechnologies.weebly.com/experiments-results.html

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From xiaohong.deng@orange-ftgroup.com  Fri Aug 12 06:24:32 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA6421F8A80 for ; Fri, 12 Aug 2011 06:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.674
X-Spam-Level: 
X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=0.575,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAa7W-qDmVB0 for ; Fri, 12 Aug 2011 06:24:32 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id AB08D21F8A7A for ; Fri, 12 Aug 2011 06:24:31 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 71080958007; Fri, 12 Aug 2011 15:33:39 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 686A2958006; Fri, 12 Aug 2011 15:33:39 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Aug 2011 15:25:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2011 21:25:03 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195B02E@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <4E4528ED.2050500@viagenie.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxY8s5KK4u7Fce4Qemw0cA3Ssfi4AAACaQg
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E43CD23.9060308@viagenie.ca> <0962B0BEF842A24191AD9BE41A8DD2FC0195B02C@ch-mailsrv.rd.francetelecom.fr> <4E4528ED.205 0500@via genie.ca>
From: 
To: 
X-OriginalArrivalTime: 12 Aug 2011 13:25:07.0754 (UTC) FILETIME=[40FD48A0:01CC58F3]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 13:24:32 -0000

=20

|-----Original Message-----
|From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20
|Sent: Friday, August 12, 2011 9:22 PM
|To: DENG Xiaohong ESP/PEK
|Cc: rajiva@cisco.com; despres.remi@laposte.net; softwires@ietf.org
|Subject: Re: [Softwires] Clarification of the=20
|stateles/stateful discussion
|
|Initially I wrote a long email with a point-by-point reply,=20
|but then I found what I think could be the source of our=20
|misunderstanding:
|
|On 2011-08-12 08:32, xiaohong.deng@orange-ftgroup.com wrote:
|> BitTorrent and Skype are definitely cases that show othersiwse.
|>=20
|> As the detailed analysis I stated in the previous email, but don't=20
|> mind to explain again:
|>=20
|> When BT Client initiates a downloading it first uses the same source=20
|> port to connect to the different destinations (destination IP and=20
|> port) therefore a source port multiplexing different sessions. Data=20
|> shows maxium port usuage reaches 160, while session usuage=20
|continously stays above 450.
|>=20
|> Skype is another example that uses a source port to multiplex=20
|> different sessions thereby introducing less source port than=20
|sessions on NAT.
|> Data shows less than a couple of ports achieve more than a=20
|hundred sessions!
|
|In your experiments, do you measure port and session usage on=20
|the NAT, on the internal host, or both? It's not clear to me=20
|when reading your experiment results at=20
|http://opensourcev6transtechnologies.weebly.com/experiments-res
|ults.html

The data shows there are only the port and session usage on the NAT.

Cheers,
Xiaohong

|
|Thanks,
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca
|

From simon.perreault@viagenie.ca  Fri Aug 12 06:40:04 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CFB21F8997 for ; Fri, 12 Aug 2011 06:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level: 
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEfQUK7v4nWS for ; Fri, 12 Aug 2011 06:40:03 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 306BE21F88DC for ; Fri, 12 Aug 2011 06:40:03 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EECC420DC2; Fri, 12 Aug 2011 09:40:39 -0400 (EDT)
Message-ID: <4E452D57.6090501@viagenie.ca>
Date: Fri, 12 Aug 2011 09:40:39 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: xiaohong.deng@orange-ftgroup.com
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E43CD23.9060308@viagenie.ca> <0962B0BEF842A24191AD9BE41A8DD2FC0195B02C@ch-mailsrv.rd.francetelecom.fr> <4E4528ED.205 0500@via genie.ca> <0962B0BEF842A24191AD9BE41A8DD2FC0195B02E@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0195B02E@ch-mailsrv.rd.francetelecom.fr>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 13:40:04 -0000

On 2011-08-12 09:25, xiaohong.deng@orange-ftgroup.com wrote:
> |In your experiments, do you measure port and session usage on 
> |the NAT, on the internal host, or both? It's not clear to me 
> |when reading your experiment results at 
> |http://opensourcev6transtechnologies.weebly.com/experiments-res
> |ults.html
> 
> The data shows there are only the port and session usage on the NAT.

Ok. Thanks.

Then I think we're missing an important piece of data: port and session
usage on the host. Here's why, with an example.


Suppose I run an app on my host that creates two sessions using two
different source ports:

192.168.0.10:65000 --> 1.2.3.4:80
192.168.0.10:65001 --> 5.6.7.8:80

An EIM NAT will always map these two sessions to two different external
ports, let's say like this:

4.4.4.4:65000 --> 1.2.3.4:80
4.4.4.4:65001 --> 5.6.7.8:80

A non-EIM NAT could instead conserve ports by reusing the same external
port for the two sessions:

4.4.4.4:65000 --> 1.2.3.4:80
4.4.4.4:65000 --> 5.6.7.8:80

------------------------------

Suppose now that a different app creates two sessions using the same
source port:

192.168.0.10:65000 --> 1.2.3.4:80
192.168.0.10:65000 --> 5.6.7.8:80

Both the EIM NAT and the non-EIM NAT would map them to the same external
port:

4.4.4.4:65000 --> 1.2.3.4:80
4.4.4.4:65000 --> 5.6.7.8:80

--------------------------------------


So, conclusion: unless your extremely certain of the NAT behaviour (we
rarely are, especially in edge cases), just by looking at the NAT port
and session usage says nothing about what happens on the host. We don't
know whether BitTorrent, Skype, or Firefox reuse source ports for
different destinations or whether they simply use additional internal
source ports.

Usually, if an application just uses the usual BSD sockets API to
initiate each new session (socket() then connect()), the OS will assign
a different source ports (for all common consumer OSes). It could be
possible that the application does it otherwise, but the straightforward
way to do it just consumes another port.

So your observations on the NAT, where significantly more sessions were
active than there were ports, mean that either of these is true:

a) Firefox, the BitTorrent client you tested, and Skype do not create
new sessions with the usual socket() then connect() sequence. (That
would be quite strange for Firefox and BitTorrent, not so much for Skype.)

b) The NAT you tested was not EIM. (This would not be surprising since
there are many non-EIM consumer grade NATs out there.)

Thoughts?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Fri Aug 12 07:00:42 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD39021F8A23 for ; Fri, 12 Aug 2011 07:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level: 
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUd0OT8LSk6U for ; Fri, 12 Aug 2011 07:00:42 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB521F881C for ; Fri, 12 Aug 2011 07:00:42 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 050E420DC2 for ; Fri, 12 Aug 2011 10:01:18 -0400 (EDT)
Message-ID: <4E45322E.9050700@viagenie.ca>
Date: Fri, 12 Aug 2011 10:01:18 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E4434D2.1080801@skoberne.net>
In-Reply-To: <4E4434D2.1080801@skoberne.net>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 14:00:42 -0000

On 2011-08-11 16:00, Nejc Škoberne wrote:
> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf

VERY nice!

One comment I would have is that maybe colour could be used to indicate
good/bad instead of yes/no.

Then we just pick the column with the less red on it and we're done. ;)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From rajiva@cisco.com  Fri Aug 12 07:08:10 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE3821F8A67 for ; Fri, 12 Aug 2011 07:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Level: 
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNKFSWe+1ODu for ; Fri, 12 Aug 2011 07:08:09 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CD08C21F8A51 for ; Fri, 12 Aug 2011 07:08:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1293; q=dns/txt; s=iport; t=1313158121; x=1314367721; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=2sskVFdH3tTHgzE9Lwt6dUk5G65V4jK71VliyZTjEJM=; b=bKeWqM2HrK7NmhRUn6Jk5+xMnRqDp/x6Cd4+HnBF/RpIRRh9X8PoNnxB lG18N4MnKczV1yfSt2uQWcIb7XsrpAW+hymoIyJWF8Tao7P3MtdKsLZCi aGPXdInRGNKJlFAmUtxVhlMrs9w8zwwUUCfVZW45tMfmHcwdJ0lRqCXNE c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmIBAMgyRU6tJXG//2dsb2JhbABBmCiISoFMhTl3gUABAQEBAQIBAQEPARQJPhcEAgEIEQQBAQEKBhcBBgEmHwkIAQEEAQkJCBqHUZsUAZ50hWhfBIdfkEaLeg
X-IronPort-AV: E=Sophos;i="4.67,362,1309737600"; d="scan'208";a="12579247"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 12 Aug 2011 14:08:41 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7CE8eNm031491;  Fri, 12 Aug 2011 14:08:40 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Aug 2011 09:08:40 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2011 09:08:39 -0500
Message-ID: <067E6CE33034954AAC05C9EC85E2577C05A6FFC1@XMB-RCD-111.cisco.com>
In-Reply-To: <4E45322E.9050700@viagenie.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxY+FJwsVQIixD/SViv/VbEoIJ5DgAALorQ
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com><0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr><067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com><0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr><4E4434D2.1080801@skoberne.net> <4E45322E.9050700@viagenie.ca>
From: "Rajiv Asati (rajiva)" 
To: "Simon Perreault" , 
X-OriginalArrivalTime: 12 Aug 2011 14:08:40.0883 (UTC) FILETIME=[56892030:01CC58F9]
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 14:08:10 -0000

Nejc,

Good table indeed.=20

If you could add few more service related impact due to other features =
such as UPNP inside home, DPI in the network, L4 QoS in the network, =
L4-aware routing etc., then it would be quite insightful. I may also =
help you with that.

Cheers,
Rajiv


> -----Original Message-----
> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] =
On Behalf
> Of Simon Perreault
> Sent: Friday, August 12, 2011 10:01 AM
> To: softwires@ietf.org
> Subject: Re: [Softwires] Clarification of the stateles/stateful =
discussion
>=20
> On 2011-08-11 16:00, Nejc =A9koberne wrote:
> > The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
>=20
> VERY nice!
>=20
> One comment I would have is that maybe colour could be used to =
indicate
> good/bad instead of yes/no.
>=20
> Then we just pick the column with the less red on it and we're done. =
;)
>=20
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From rajiva@cisco.com  Fri Aug 12 07:20:14 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1BC21F8AAA for ; Fri, 12 Aug 2011 07:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.035
X-Spam-Level: 
X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUhvDe3medc5 for ; Fri, 12 Aug 2011 07:20:13 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4383321F8AA8 for ; Fri, 12 Aug 2011 07:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6680; q=dns/txt; s=iport; t=1313158851; x=1314368451; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hVXgwt6i0LuaUjgZiIzrG+LBXzQZLmCYQxu0BtOStXQ=; b=Tw8g+uuiIx67kSqFaUYPGDFzzDz+HsiuoqTjU4ccVe8uSX8wwtnFf4Ur xJnG2Mgj5nZUziyTRfZDW3JaRV8/8T0y9TChSDL0iEO3t3mBhUsTzcrgl QoU1VKHZcbmMFN6BXLIADFSEbsmr1Tq1dTcwDre3Fl3bo7sIueUlTxowb I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmIBAJI1RU6tJV2Y/2dsb2JhbABBmCiISoFMhTl3gUABAQEBAwEBAQ8BFAk+CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah1GbCgGec4VoXwSHMC+QRot6
X-IronPort-AV: E=Sophos;i="4.67,362,1309737600"; d="scan'208";a="12586758"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 12 Aug 2011 14:20:50 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7CEKoEe006975;  Fri, 12 Aug 2011 14:20:50 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Aug 2011 09:20:50 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2011 09:20:49 -0500
Message-ID: <067E6CE33034954AAC05C9EC85E2577C05A6FFCC@XMB-RCD-111.cisco.com>
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxXQM0E433K7146TX+2ru2VPb36pAAGKXTAAC8RD8AAOU2HkA==
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch- mailsrv. rd.francetelecom.fr>
From: "Rajiv Asati (rajiva)" 
To: , 
X-OriginalArrivalTime: 12 Aug 2011 14:20:50.0227 (UTC) FILETIME=[09423030:01CC58FB]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 14:20:14 -0000

Xiaohong,

It shouldn't, I agree. And your test could attest to that (as some may =
not agree otherwise).

Cheers,
Rajiv


> -----Original Message-----
> From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Thursday, August 11, 2011 7:02 AM
> To: Rajiv Asati (rajiva); despres.remi@laposte.net
> Cc: softwires@ietf.org
> Subject: RE: [Softwires] Clarification of the stateles/stateful =
discussion
>=20
> Rajiv,
>=20
> Thanks!
>=20
> It's 'consecutive' port-set, and thanks for your proposal for testing
> 'scattered' port-set.
>=20
> But I don't understand will the figure be different with 'scattered' =
port-set
> NAT? To my knowledge, it's something todo with app's behaviours and =
NAT
> type(EIM in our test).
> Would you explain if I miss something? Thanks
>=20
> Cheers,
> Xiaohong
>=20
> |-----Original Message-----
> |From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]
> |Sent: Wednesday, August 10, 2011 8:39 PM
> |To: DENG Xiaohong ESP/PEK; despres.remi@laposte.net
> |Cc: softwires@ietf.org
> |Subject: RE: [Softwires] Clarification of the
> |stateles/stateful discussion
> |
> |Xiaohong,
> |
> |Your work is very insightful. Thanks for pointing it out.
> |
> |In your experimentation, did you use 'consecutive' port-set or
> |'scattered' port-set or both? If just the former, then is it
> |possible to experiment using 'scattered' port-set?
> |
> |Cheers,
> |Rajiv
> |
> |
> |> -----Original Message-----
> |> From: xiaohong.deng@orange-ftgroup.com =
[mailto:xiaohong.deng@orange-
> |> ftgroup.com]
> |> Sent: Wednesday, August 10, 2011 5:35 AM
> |> To: despres.remi@laposte.net; Rajiv Asati (rajiva)
> |> Cc: softwires@ietf.org
> |> Subject: RE: [Softwires] Clarification of the stateles/stateful
> |> discussion
> |>
> |>
> |>
> |> |-----Original Message-----
> |> |From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]
> |> |Sent: Wednesday, August 03, 2011 4:02 PM
> |> |To: Rajiv Asati (rajiva)
> |> |Cc: softwires@ietf.org
> |> |Subject: Re: [Softwires] Clarification of the stateles/stateful
> |> |discussion
> |> |
> |> |
> |> |Le 3 ao=FBt 2011 =E0 00:39, Rajiv Asati (rajiva) a =E9crit :
> |> |
> |> |> Satoru-san,
> |> |>
> |> |> This is an important point that most of us forget that
> |> |restricting to
> |> |> "n" ports doesn't equate to just "n" NAT sessions rather
> |many more
> |> |> than n sessions. We must add that to the 4v6 motivation
> |> |draft as well
> |> |> as to the 4v6 comparison draft.
> |> |
> |> |+1
> |>
> |> +1. Session number are usually many more than ports number.
> |>
> |> We tested port and sessions assumptions of applications on the A+P
> |> NAT, which has been documented in A+P experiments draft, to
> |> investigate how many ports and sessions they are costing on the NAT
> |> mapping table dynamically from the first NAT bindings being
> |> established to the last one being destroyed.
> |>
> |> Some results below:
> |>
> |> Usually, apps consume some more sessions than ports, and for the =
P2P
> |> apps, sessions number could even be as a couple of times as ports
> |> number.
> |>
> |>  For example, BitTorrent established five hundreds of sessions =
while
> |> the port consumption  was under a hundred in the first minute of =
the
> |> communication, because when BitTorrent initiates a downloading, it
> |> first uses the same source port to connect to the different
> |> destinations (destination IP and port) therefore one source port
> |> multiplexing different sessions. Skype is  another example that =
uses
> |> one source port to  multiplex different sessions thereby
> |saving source
> |> port consumptions on NAT.
> |>
> |>  For exact figures of ports/session number for apps, see my page:
> |>
> |>
> =
|http://opensourcev6transtechnologies.weebly.com/experiments-results.ht
> |> ml The session consumption comparison among the same set of
> |> applications is  illustrated in Figure 4.
> |>
> |> Xiaohong
> |>
> |>
> |> |
> |> |RD
> |> |
> |> |>
> |> |>> port. There may be multiple session to different destinations
> |> |>> using
> |> |> the same
> |> |>> external port. The 900G figure is valid, as long as
> |internal hosts
> |> |> reuse the
> |> |>> same source address+port for different destinations.
> |> |>
> |> |> Cheers,
> |> |> Rajiv
> |> |>
> |> |>
> |> |>> -----Original Message-----
> |> |>> From: softwires-bounces@ietf.org
> |> |>> [mailto:softwires-bounces@ietf.org]
> |> |> On Behalf
> |> |>> Of Simon Perreault
> |> |>> Sent: Tuesday, August 02, 2011 9:55 AM
> |> |>> To: softwires@ietf.org
> |> |>> Subject: Re: [Softwires] Clarification of the stateles/stateful
> |> |> discussion
> |> |>>
> |> |>> Simon Perreault wrote, on 08/02/2011 09:24 AM:
> |> |>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
> |> |>>>> Thanks, a clarification has made to clear a confusion of
> |> |restricted
> |> |> port
> |> |>>>> set/ranges and NAT session table limitation. Even if a CPE is
> |> |> allocated 256
> |> |>>>> ports, NAT session can be made over 900G sessions in theory.
> |> |> ('2^32' |> |>>>> 32bits v4 address> - '2^29' - '2^7'<0/8,127/8>) *
> |> |> 2^8<256
> |> |>> ports>.
> |> |>>>
> |> |>>> This is only true for endpoint-dependent NATs, which are
> |> |>>> forbidden
> |> |> by the
> |> |>> BEHAVE
> |> |>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have
> |> |>>> endpoint-independent mapping behaviour. This means that each =
NAT
> |> |> session
> |> |>> will
> |> |>>> consume one external port.
> |> |>>
> |> |>> Sorry, I confused the terminology. Each NAT *binding*
> |will consume
> |> |>> one external port. There may be multiple session to different
> |> |>> destinations using
> |> |> the same
> |> |>> external port. The 900G figure is valid, as long as
> |internal hosts
> |> |> reuse the
> |> |>> same source address+port for different destinations.
> |> |>>
> |> |>> Simon
> |> |>> --
> |> |>> DTN made easy, lean, and smart -->
> |http://postellation.viagenie.ca
> |> |>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> |> |>> STUN/TURN server               --> http://numb.viagenie.ca
> |> |>> _______________________________________________
> |> |>> Softwires mailing list
> |> |>> Softwires@ietf.org
> |> |>> https://www.ietf.org/mailman/listinfo/softwires
> |> |> _______________________________________________
> |> |> Softwires mailing list
> |> |> Softwires@ietf.org
> |> |> https://www.ietf.org/mailman/listinfo/softwires
> |> |
> |> |
> |> |
> |

From rpenno@juniper.net  Fri Aug 12 09:25:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DF521F871E for ; Fri, 12 Aug 2011 09:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level: 
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4D3MTu4jg2C for ; Fri, 12 Aug 2011 09:25:37 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DF4FE21F871C for ; Fri, 12 Aug 2011 09:25:34 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTkVUI0kHJQWVqbiIYz981KlspK6ScFYy@postini.com; Fri, 12 Aug 2011 09:26:14 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 12 Aug 2011 09:25:36 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 12 Aug 2011 12:25:36 -0400
From: Reinaldo Penno 
To: "Rajiv Asati (rajiva)" , Simon Perreault , "softwires@ietf.org" 
Date: Fri, 12 Aug 2011 12:25:32 -0400
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxY+FJwsVQIixD/SViv/VbEoIJ5DgAALorQAATaCRM=
Message-ID: 
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05A6FFC1@XMB-RCD-111.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.9.0.110114
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 16:25:37 -0000

This could be a separate table. The good thing about this table is that is
clean and focused.


On 8/12/11 7:08 AM, "Rajiv Asati (rajiva)"  wrote:

> Nejc,
>=20
> Good table indeed.
>=20
> If you could add few more service related impact due to other features su=
ch as
> UPNP inside home, DPI in the network, L4 QoS in the network, L4-aware rou=
ting
> etc., then it would be quite insightful. I may also help you with that.
>=20
> Cheers,
> Rajiv
>=20
>=20
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
>> Behalf
>> Of Simon Perreault
>> Sent: Friday, August 12, 2011 10:01 AM
>> To: softwires@ietf.org
>> Subject: Re: [Softwires] Clarification of the stateles/stateful discussi=
on
>>=20
>> On 2011-08-11 16:00, Nejc =A9koberne wrote:
>>> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
>>=20
>> VERY nice!
>>=20
>> One comment I would have is that maybe colour could be used to indicate
>> good/bad instead of yes/no.
>>=20
>> Then we just pick the column with the less red on it and we're done. ;)
>>=20
>> Simon
>> --
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> STUN/TURN server               --> http://numb.viagenie.ca
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From rajiva@cisco.com  Fri Aug 12 09:27:13 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3866F21F8582 for ; Fri, 12 Aug 2011 09:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.613
X-Spam-Level: 
X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaWg0ZP+Gq7Z for ; Fri, 12 Aug 2011 09:27:12 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 752E621F8574 for ; Fri, 12 Aug 2011 09:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2205; q=dns/txt; s=iport; t=1313166470; x=1314376070; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=rj95jXJ653LinBBNi/2uO5CDV9gQq6+5aN5e+xIVpRk=; b=GnHcEYOoer9iQmizErt80eWaCcW0I+e79eEXtrO5AXlZh8kNKuxYTWrE 7+Kaj/PUG39XouZbOTwkM/R6eVpx4riIYSio97PD7lCEedt9zNPfanLoP jgk8CSS/iZLZ3BQpqk79NWvP9zgYoOGpubKcfYvDVl7HX2YIBHyc1WH9q I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlgBAGxURU6tJV2d/2dsb2JhbABCmCyISoFMhTd3gUABAQEBAQIBAQEPARQJPhcEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAEJCQgah1GbPQGecoVoXwSHX5BGi3o
X-IronPort-AV: E=Sophos;i="4.67,363,1309737600"; d="scan'208";a="12642505"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 12 Aug 2011 16:27:40 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7CGRd5U002219;  Fri, 12 Aug 2011 16:27:40 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Aug 2011 11:27:40 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2011 11:27:39 -0500
Message-ID: <067E6CE33034954AAC05C9EC85E2577C05A7006B@XMB-RCD-111.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxY+FJwsVQIixD/SViv/VbEoIJ5DgAALorQAATaCRMAAA044A==
References: <067E6CE33034954AAC05C9EC85E2577C05A6FFC1@XMB-RCD-111.cisco.com> 
From: "Rajiv Asati (rajiva)" 
To: "Reinaldo Penno" , "Simon Perreault" , 
X-OriginalArrivalTime: 12 Aug 2011 16:27:40.0049 (UTC) FILETIME=[C110E010:01CC590C]
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 16:27:13 -0000

Keeping it clean and focused would yield minimal benefit if the =
operators can't relate to the impact on their services and =
infrastructures.

Cheers,
Rajiv


> -----Original Message-----
> From: Reinaldo Penno [mailto:rpenno@juniper.net]
> Sent: Friday, August 12, 2011 12:26 PM
> To: Rajiv Asati (rajiva); Simon Perreault; softwires@ietf.org
> Subject: Re: [Softwires] Clarification of the stateles/stateful =
discussion
>=20
> This could be a separate table. The good thing about this table is =
that is
> clean and focused.
>=20
>=20
> On 8/12/11 7:08 AM, "Rajiv Asati (rajiva)"  wrote:
>=20
> > Nejc,
> >
> > Good table indeed.
> >
> > If you could add few more service related impact due to other =
features such
> as
> > UPNP inside home, DPI in the network, L4 QoS in the network, =
L4-aware
> routing
> > etc., then it would be quite insightful. I may also help you with =
that.
> >
> > Cheers,
> > Rajiv
> >
> >
> >> -----Original Message-----
> >> From: softwires-bounces@ietf.org =
[mailto:softwires-bounces@ietf.org] On
> >> Behalf
> >> Of Simon Perreault
> >> Sent: Friday, August 12, 2011 10:01 AM
> >> To: softwires@ietf.org
> >> Subject: Re: [Softwires] Clarification of the stateles/stateful =
discussion
> >>
> >> On 2011-08-11 16:00, Nejc =A9koberne wrote:
> >>> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
> >>
> >> VERY nice!
> >>
> >> One comment I would have is that maybe colour could be used to =
indicate
> >> good/bad instead of yes/no.
> >>
> >> Then we just pick the column with the less red on it and we're =
done. ;)
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> >> STUN/TURN server               --> http://numb.viagenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires


From rpenno@juniper.net  Fri Aug 12 09:35:04 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94221F85A7 for ; Fri, 12 Aug 2011 09:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.453
X-Spam-Level: 
X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrcxcojPxhHe for ; Fri, 12 Aug 2011 09:35:01 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 0893E21F856D for ; Fri, 12 Aug 2011 09:34:58 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTkVWWCgmalwuja75Y2KbNKiF8fToWl2u@postini.com; Fri, 12 Aug 2011 09:35:38 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 12 Aug 2011 09:33:36 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 12 Aug 2011 12:33:35 -0400
From: Reinaldo Penno 
To: "Rajiv Asati (rajiva)" , Simon Perreault , "softwires@ietf.org" 
Date: Fri, 12 Aug 2011 12:33:33 -0400
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxY+FJwsVQIixD/SViv/VbEoIJ5DgAALorQAATaCRMAAA044AAAOnW9
Message-ID: 
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05A7006B@XMB-RCD-111.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.9.0.110114
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 16:35:04 -0000

Can you propose a list of all 'other features' you have in mind that might
impact all operators?


On 8/12/11 9:27 AM, "Rajiv Asati (rajiva)"  wrote:

> Keeping it clean and focused would yield minimal benefit if the operators
> can't relate to the impact on their services and infrastructures.
>=20
> Cheers,
> Rajiv
>=20
>=20
>> -----Original Message-----
>> From: Reinaldo Penno [mailto:rpenno@juniper.net]
>> Sent: Friday, August 12, 2011 12:26 PM
>> To: Rajiv Asati (rajiva); Simon Perreault; softwires@ietf.org
>> Subject: Re: [Softwires] Clarification of the stateles/stateful discussi=
on
>>=20
>> This could be a separate table. The good thing about this table is that =
is
>> clean and focused.
>>=20
>>=20
>> On 8/12/11 7:08 AM, "Rajiv Asati (rajiva)"  wrote:
>>=20
>>> Nejc,
>>>=20
>>> Good table indeed.
>>>=20
>>> If you could add few more service related impact due to other features =
such
>> as
>>> UPNP inside home, DPI in the network, L4 QoS in the network, L4-aware
>> routing
>>> etc., then it would be quite insightful. I may also help you with that.
>>>=20
>>> Cheers,
>>> Rajiv
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O=
n
>>>> Behalf
>>>> Of Simon Perreault
>>>> Sent: Friday, August 12, 2011 10:01 AM
>>>> To: softwires@ietf.org
>>>> Subject: Re: [Softwires] Clarification of the stateles/stateful discus=
sion
>>>>=20
>>>> On 2011-08-11 16:00, Nejc =A9koberne wrote:
>>>>> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
>>>>=20
>>>> VERY nice!
>>>>=20
>>>> One comment I would have is that maybe colour could be used to indicat=
e
>>>> good/bad instead of yes/no.
>>>>=20
>>>> Then we just pick the column with the less red on it and we're done. ;=
)
>>>>=20
>>>> Simon
>>>> --
>>>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>>>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>>>> STUN/TURN server               --> http://numb.viagenie.ca
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>=20


From behcetsarikaya@yahoo.com  Fri Aug 12 15:24:42 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BE111E80AA for ; Fri, 12 Aug 2011 15:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.666
X-Spam-Level: 
X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_40=-0.185]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIxuuFSNaK01 for ; Fri, 12 Aug 2011 15:24:42 -0700 (PDT)
Received: from nm13-vm0.bullet.mail.ne1.yahoo.com (nm13-vm0.bullet.mail.ne1.yahoo.com [98.138.91.48]) by ietfa.amsl.com (Postfix) with SMTP id 0AC7011E80A9 for ; Fri, 12 Aug 2011 15:24:41 -0700 (PDT)
Received: from [98.138.90.53] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 22:25:14 -0000
Received: from [98.138.89.232] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 22:25:14 -0000
Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 22:25:14 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 59672.84030.bm@omp1047.mail.ne1.yahoo.com
Received: (qmail 64305 invoked by uid 60001); 12 Aug 2011 22:25:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313187913; bh=XN5yax8wy7Mvm+UPJJI1yPS1RNlkRq4FVABRltsSJe0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=j8L8Id2foBIB6U4IWZ5Qy9cDfflncHMij7+H/w7uadC/VtwZqJOqBl5QIn9QMbE1EQKtSjgv/GyqN1yup5cYFRCf+7AiHO1h7jZvORrZAvnCo05wbYrb8iPw/DYNRJrJ6OFks9Ks3UUXh2w6sLYr8RcwwJRKjj3wgMy1uCXvS4c=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iT/9+VR1oC8tCItO67GzdMBtV/O9CxQA8HqUJjJYTkM1tlnec/4+7L5/hvquFN9QeayABcyB0GEeEpmg+Mkyn1AKKXOriiZ4kUqqe5nOd9KIwTX9Djkr746eE7cKkUn6kEWJZkzmexkPrFUZqozpXU1HsHaaFZ7r6n+QMRVhRtg=;
X-YMail-OSG: vI3zNe4VM1mO74FqtPsXQ6caK1xd5Q64oDs_kI0HNL7CsXx KZKI8oyYeGdplKQ40AgSuIUnPJDjU7tTRA8kBrMMxqaEmJtjNi.WlhDbY3gl sUh4zKbCF1GHLcVqY.6Jx3YLgC83BNVu3woaK6AeLthferXM2S_l67kBVKCR .0HWrilsdLi5_AMaAitY7e_erunrA_DozuunPnhxpuA01JQpvqTT7wa071y1 DLqSZScEaAht1pnWKzTuNKoVPD_ghZwq8YqHn1qdEXap.AcMSp7Ryp.eVIDD oX7Cy9u11LB0g4YEHEfp6KtwxvouONWqBNuDmXRQkKQ4ctCFlKrqCgUGqyuX f7Sj519aAhNX8IO2uRdC3w_LDTK5E_CSu063iNy5NVsAI_F_l4iP5bQIZp3c jQ7cU54OzKmZMDxkQXe1ksYNpqlWZwVh2Ku2AhVEiMhToU_InmvB16gZ_UxT ToOvYzQo-
Received: from [50.58.7.243] by web111412.mail.gq1.yahoo.com via HTTP; Fri, 12 Aug 2011 15:25:13 PDT
X-Mailer: YahooMailWebService/0.8.113.313619
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
Message-ID: <1313187913.63798.YahooMailNeo@web111412.mail.gq1.yahoo.com>
Date: Fri, 12 Aug 2011 15:25:13 -0700 (PDT)
From: Behcet Sarikaya 
To: Alain Durand , "softwires@ietf.org list" 
In-Reply-To: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 22:24:42 -0000

Hi Alain,=0A=A0 Can we assume that this meeting will not happen as I see no=
 formal announcement?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A> Following-up o=
n the Quebec meeting, we would like to organize an interim meeting =0A> end=
 of September.=0A> We will focus on so-called stateless solutions and other=
 remaining business in =0A> the wg (multicast. mibs,...)=0A> that require m=
ore time than we usually have during a normal IETF meeting.=0A> The format =
will be a 2 day intensive meeting, with white board discussions, =0A> simil=
ar to what we did in the early days of the working group.=0A> =0A> We've go=
t an offer to host the meeting in Beijin on Sept. 26-27th or 27-28th =0A> (=
right after the Boradband forum meeting in Shanghai).=0A> Yong and I would =
like to make a decision soon, please send us email directly if =0A> you int=
end to come and tell us which set of dates is more convenient.=0A> Please r=
espond by August 11th, we will formally announce the meeting with the =0A> =
logistic information end of next week.=0A> =0A> Alain & Yong.=0A> =0A> =0A>=
 =0A> _______________________________________________=0A> Softwires mailing=
 list=0A> Softwires@ietf.org=0A> https://www.ietf.org/mailman/listinfo/soft=
wires=0A>

From nejc@skoberne.net  Sat Aug 13 08:29:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89E21F86EA for ; Sat, 13 Aug 2011 08:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.391
X-Spam-Level: 
X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uEDOymZEzjl for ; Sat, 13 Aug 2011 08:29:44 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 74E2D21F86DC for ; Sat, 13 Aug 2011 08:29:36 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 25DFD22780ED for ; Sat, 13 Aug 2011 17:30:15 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jZkzgi411N2 for ; Sat, 13 Aug 2011 17:30:14 +0200 (CEST)
Received: from [192.168.1.2] (host-2-100-23-117.as13285.net [2.100.23.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 298A822780EC for ; Sat, 13 Aug 2011 17:30:14 +0200 (CEST)
Message-ID: <4E469886.9040201@skoberne.net>
Date: Sat, 13 Aug 2011 16:30:14 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E4434D2.1080801@skoberne.net> <4E45322E.9050700@viagenie.ca>
In-Reply-To: <4E45322E.9050700@viagenie.ca>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Aug 2011 15:29:44 -0000

Dear Simon,

>> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
> 
> VERY nice!

Thanks.

> One comment I would have is that maybe colour could be used to indicate
> good/bad instead of yes/no.
> 
> Then we just pick the column with the less red on it and we're done. ;)

Well, I was thinking about this, but it's not really easy to make such
judgements. I mean, a lot of preassumptions are needed to make this
consistent. So perhaps I'll try to change red-green to something less
"judging". This table doesn't want to judge, it just want's to document
current status. At least that was my idea.

Nejc


From nejc@skoberne.net  Sat Aug 13 08:31:39 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF6321F86EE for ; Sat, 13 Aug 2011 08:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.391
X-Spam-Level: 
X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s21+fM-9e1WA for ; Sat, 13 Aug 2011 08:31:39 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 393BC21F86EA for ; Sat, 13 Aug 2011 08:31:39 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 01DE222780ED for ; Sat, 13 Aug 2011 17:32:19 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0WYITvOq8lB for ; Sat, 13 Aug 2011 17:32:18 +0200 (CEST)
Received: from [192.168.1.2] (host-2-100-23-117.as13285.net [2.100.23.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 4F9C622780EC for ; Sat, 13 Aug 2011 17:32:18 +0200 (CEST)
Message-ID: <4E469902.4040803@skoberne.net>
Date: Sat, 13 Aug 2011 16:32:18 +0100
From: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com><0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr><067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com><0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr><4E4434D2.1080801@skoberne.net> <4E45322E.9050700@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C05A6FFC1@XMB-RCD-111.cisco. com>
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05A6FFC1@XMB-RCD-111.cisco.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Aug 2011 15:31:39 -0000

Dear Rajiv,

> Good table indeed.

Thanks.

> If you could add few more service related impact due to other features such as UPNP inside home, DPI in the network, L4 QoS in the network, L4-aware routing etc., then it would be quite insightful. I may also help you with that.

Yes, this is the general idea here. I will extend the table onto next 
page and compare all these aspects. I'd really appreciate any help.

Will send my first extended draft here and then you can comment/add
additional lines. You can also send me private mail, of course.

Thanks,
Nejc

From nejc@skoberne.net  Sat Aug 13 08:32:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9965321F874F for ; Sat, 13 Aug 2011 08:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.391
X-Spam-Level: 
X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEYdN1EyVs3h for ; Sat, 13 Aug 2011 08:32:44 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 12DA521F86EA for ; Sat, 13 Aug 2011 08:32:44 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id D1DA122780ED for ; Sat, 13 Aug 2011 17:33:23 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYWjpHB4AlGa for ; Sat, 13 Aug 2011 17:33:23 +0200 (CEST)
Received: from [192.168.1.2] (host-2-100-23-117.as13285.net [2.100.23.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 80A6722780EC for ; Sat, 13 Aug 2011 17:33:23 +0200 (CEST)
Message-ID: <4E469943.4060509@skoberne.net>
Date: Sat, 13 Aug 2011 16:33:23 +0100
From: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Aug 2011 15:32:44 -0000

Dear Reinaldo,

> This could be a separate table. The good thing about this table is that is
> clean and focused.

I don't think that extending this table on another page will make it less 
clean and focused.

Nejc

From washam.fan@gmail.com  Sun Aug 14 05:51:38 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806B421F87D3 for ; Sun, 14 Aug 2011 05:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.463
X-Spam-Level: 
X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5L3jzDTvuFX for ; Sun, 14 Aug 2011 05:51:38 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C704B21F8779 for ; Sun, 14 Aug 2011 05:51:37 -0700 (PDT)
Received: by wyg8 with SMTP id 8so3464417wyg.31 for ; Sun, 14 Aug 2011 05:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=g5rIgFEi+SGwpIzcoxQpIaMqv4Qol35Mtrn2Uo8i1ak=; b=lVfya4hig2nDa9gZlrk9RH6ApWDH/rp14jo7LST0d4EVTI5wiCw3rP0fxEt/ToakCl iaU+i2fm7l587UdHQBkZQYxXzFsStk4AzDaG5whY3ti3EvEzSTS8YgRlWS90lQqRXUvk gQNy1AeftufCZBwcxAfyM1JddWVCKpws1c7DQ=
MIME-Version: 1.0
Received: by 10.216.131.134 with SMTP id m6mr1966559wei.78.1313326338299; Sun, 14 Aug 2011 05:52:18 -0700 (PDT)
Received: by 10.216.71.133 with HTTP; Sun, 14 Aug 2011 05:52:18 -0700 (PDT)
Date: Sun, 14 Aug 2011 20:52:18 +0800
Message-ID: 
From: Washam Fan 
To: Softwires 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Aug 2011 12:51:38 -0000

Hi,

It seems to me only one domain IPv6 prefix is allowed, per
draft-murakami-softwire-4rd-00. But I see no issue if we allow
multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a
outbound IPv4 package, the matched rule can tell which domain ipv6
prefix can be used for building outer IPv6 destination address.

Thanks,
washam

From jacni@jacni.com  Sun Aug 14 18:07:23 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACE021F87E2 for ; Sun, 14 Aug 2011 18:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level: 
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.339,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFIO0-pPLW+O for ; Sun, 14 Aug 2011 18:07:23 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3F21F8782 for ; Sun, 14 Aug 2011 18:07:22 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 397CF38008C for ; Sun, 14 Aug 2011 21:08:05 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id A9D27340090 for ; Mon, 15 Aug 2011 09:08:01 +0800 (CST)
Received: from [172.19.96.207] (unknown [112.64.190.54]) by app (Coremail) with SMTP id +AWowJAb7ANhcUhOCkdOAA--.50755S2; Mon, 15 Aug 2011 09:07:49 +0800 (CST)
Message-ID: <4E4871AA.6010404@jacni.com>
Date: Mon, 15 Aug 2011 09:08:58 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Washam Fan 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090609060807080706020907"
X-CM-TRANSID: +AWowJAb7ANhcUhOCkdOAA--.50755S2
X-Coremail-Antispam: 1UD129KBjvdXoWrtw18uF4UuF1fCw43Gw1rJFb_yoWxKwb_uF 4DWwnakrWjyayIqayIyr95Ar9xWr4UWr1jqryUXr1vgw1UArs8trs7CrW0kw1UGrWUCry3 W3WkGr18u34YgjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUj5kYjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6F4UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_JFC_Wr1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1ln4vEIxkG6c02xx0F6c8GOVWUtr18Jw1lnx0Ec2IEnICE548m6r1D JrWUZwAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64 vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij 64vIr41l4IxY624lx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrbIYCTnIWIevJa 73UjIFyTuYvjxUs0PSUUUUU
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEOEko7lM+GRgBjsV
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2011 01:07:24 -0000

This is a multi-part message in MIME format.
--------------090609060807080706020907
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hi,

I guess you mean multiple rules, then it'll be one CEconnected to 
multiple domains.
That has been mentioned in the current version but no more elaboration. ;-)


Cheers,
Jacni

On 8/14/2011 8:52 PM, Washam Fan wrote:
> Hi,
>
> It seems to me only one domain IPv6 prefix is allowed, per
> draft-murakami-softwire-4rd-00. But I see no issue if we allow
> multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a
> outbound IPv4 package, the matched rule can tell which domain ipv6
> prefix can be used for building outer IPv6 destination address.
>
> Thanks,
> washam
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--------------090609060807080706020907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    hi,

      

      I guess you mean multiple rules, then it'll be one CE connected to multiple domains.

      That has been mentioned in the current version but no more
      elaboration. ;-)

      

      

      Cheers,

      Jacni

    

    On 8/14/2011 8:52 PM, Washam Fan wrote:
    

      
Hi,

It seems to me only one domain IPv6 prefix is allowed, per
draft-murakami-softwire-4rd-00. But I see no issue if we allow
multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a
outbound IPv4 package, the matched rule can tell which domain ipv6
prefix can be used for building outer IPv6 destination address.

Thanks,
washam
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



    

  


--------------090609060807080706020907--


From washam.fan@gmail.com  Sun Aug 14 19:03:08 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D1C21F8B01 for ; Sun, 14 Aug 2011 19:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGPIQbWrO72z for ; Sun, 14 Aug 2011 19:03:08 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB821F8B00 for ; Sun, 14 Aug 2011 19:03:07 -0700 (PDT)
Received: by wwf5 with SMTP id 5so3015982wwf.13 for ; Sun, 14 Aug 2011 19:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PRKqylaZdyxRjMprpIyH+Oc1iJRtZkKh9SmiCl1krrk=; b=AJJ9V+HiCQN0kpFbpsTLZb/PfTxstCNyhmM+X0PzszFO43BUhlNnORGstFx/XJ8YA+ aMhBxv4mQR37/7Uk+UXWAv0DyS8amECczpBiw4kCkx1Q7IqKE3B5PJRWWdUg9RznR2Vr H5/x6Wu1quGyCtJT3FNPLiqpFCRhGtLCxebo8=
MIME-Version: 1.0
Received: by 10.216.14.41 with SMTP id c41mr2812927wec.108.1313373827191; Sun, 14 Aug 2011 19:03:47 -0700 (PDT)
Received: by 10.216.71.133 with HTTP; Sun, 14 Aug 2011 19:03:47 -0700 (PDT)
In-Reply-To: <4E4871AA.6010404@jacni.com>
References:  <4E4871AA.6010404@jacni.com>
Date: Mon, 15 Aug 2011 10:03:47 +0800
Message-ID: 
From: Washam Fan 
To: Jacni Qin 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2011 02:03:08 -0000

> I guess you mean multiple rules, then it'll be one CE connected to multiple
> domains.

Actually, I mean one 4rd domain can accommodate multiple domain ipv6
prefixes. I don't understand why the current draft mandate one 4rd
domain has only one domain ipv6 prefix.

Thanks,
washam

> That has been mentioned in the current version but no more elaboration. ;-)
>
>
> Cheers,
> Jacni
>
> On 8/14/2011 8:52 PM, Washam Fan wrote:
>
> Hi,
>
> It seems to me only one domain IPv6 prefix is allowed, per
> draft-murakami-softwire-4rd-
> 00. But I see no issue if we allow
> multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a
> outbound IPv4 package, the matched rule can tell which domain ipv6
> prefix can be used for building outer IPv6 destination address.
>
> Thanks,
> washam
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>

From wdec.ietf@gmail.com  Mon Aug 15 01:06:48 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA5C21F89BE for ; Mon, 15 Aug 2011 01:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.364
X-Spam-Level: 
X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdgRKlqDlCiV for ; Mon, 15 Aug 2011 01:06:47 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3F21F8782 for ; Mon, 15 Aug 2011 01:06:47 -0700 (PDT)
Received: by pzk33 with SMTP id 33so4592855pzk.18 for ; Mon, 15 Aug 2011 01:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=etFmPIBBcgFDeKXwous/EvqPbkbDO+z2lJFQhcpisCU=; b=VXHyIyLWGOQphA/TH4z867VA4+qUwqQ1JNMMqJrsKPHpqJIH0GgyncSpNhvWn9wCrh aH+8Py6L+RX2XR45KPiNQQZLjmXTdBEENjOVx6p2CtoyVY5tflCSsUCrLmYhPopvhvs0 cazWi2US7cf9i4s5YvYE7Wavq/7c/0qMlC2Ec=
MIME-Version: 1.0
Received: by 10.142.136.9 with SMTP id j9mr27997wfd.311.1313395652244; Mon, 15 Aug 2011 01:07:32 -0700 (PDT)
Received: by 10.142.194.6 with HTTP; Mon, 15 Aug 2011 01:07:32 -0700 (PDT)
In-Reply-To: <4E469886.9040201@skoberne.net>
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>   <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si>  <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca>  <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> <4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E4434D2.1080801@skoberne.net> <4E45322E.9050700@viagenie.ca> <4E469886.9040201@skoberne.net>
Date: Mon, 15 Aug 2011 10:07:32 +0200
Message-ID: 
From: Wojciech Dec 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: multipart/alternative; boundary=000e0cd3135a4d35e004aa86c19d
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2011 08:06:48 -0000

--000e0cd3135a4d35e004aa86c19d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Nejc,

your comparison does not appear to include:
http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00

Also, feel free to use/refer to the table in:
http://tools.ietf.org/html/draft-dec-stateless-4v6-02#section-4.1 , which
although being specific to the stateless variants, has material applicable
to the wider comparison that includes stateful.

Regards,
Wojciech.

2011/8/13 Nejc =C5=A0koberne 

> Dear Simon,
>
> >> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
> >
> > VERY nice!
>
> Thanks.
>
> > One comment I would have is that maybe colour could be used to indicate
> > good/bad instead of yes/no.
> >
> > Then we just pick the column with the less red on it and we're done. ;)
>
> Well, I was thinking about this, but it's not really easy to make such
> judgements. I mean, a lot of preassumptions are needed to make this
> consistent. So perhaps I'll try to change red-green to something less
> "judging". This table doesn't want to judge, it just want's to document
> current status. At least that was my idea.
>
> Nejc
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--000e0cd3135a4d35e004aa86c19d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Nejc,

your comparison does not appear to include:
=
http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00

Also, feel free to use/refer to the table in: http://tools.ietf.org/=
html/draft-dec-stateless-4v6-02#section-4.1 , which although being spec=
ific to the stateless variants, has material applicable to the wider compar=
ison that includes stateful. 


Regards,
Wojciech.

2011/8/13 Nejc =
=C5=A0koberne <ne=
jc@skoberne.net>

Dear Simon,




>> The PDF document: http://nejc.skoberne.net/transfer/mechanisms=
.pdf

>

> VERY nice!




Thanks.




> One comment I would have is that maybe colour could be used to indicat=
e

> good/bad instead of yes/no.

>

> Then we just pick the column with the less red on it and we're don=
e. ;)




Well, I was thinking about this, but it's not really easy to make=
 such

judgements. I mean, a lot of preassumptions are needed to make this

consistent. So perhaps I'll try to change red-green to something less
"judging". This table doesn't want to judge, it just want'=
;s to document

current status. At least that was my idea.



Nejc




_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--000e0cd3135a4d35e004aa86c19d--

From nejc@skoberne.net  Mon Aug 15 03:06:01 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4570921F8B19 for ; Mon, 15 Aug 2011 03:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPLmm1KE5SiC for ; Mon, 15 Aug 2011 03:06:00 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8221F8B1A for ; Mon, 15 Aug 2011 03:06:00 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id C562822780C6; Mon, 15 Aug 2011 12:06:43 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+ttcPfcxzKz; Mon, 15 Aug 2011 12:06:27 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 15C5422780C3; Mon, 15 Aug 2011 12:06:27 +0200 (CEST)
Message-ID: <4E48EFA4.9010704@skoberne.net>
Date: Mon, 15 Aug 2011 11:06:28 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Wojciech Dec 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <201107302126309348102@csnet1.cs.tsinghua.edu.cn> <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> <4E36713C.904@go6.si>  <4E36B9F0.3070607@go6.si> <4E36BBF9.9070709@viagenie.ca>  <4E370ABB.30200@go6.si> <37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com> <4E37FA9A.5070909@viagenie.ca> <4E38019D.3090206@viagenie.ca> <067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E4434D2.1080801@skoberne.net> <4E45322E.9050700@viagenie.ca> <4E469886.9040201@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2011 10:06:01 -0000

Dear Wojciech,

> your comparison does not appear to include:
> http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00

Interesting. I guess the idea is the same as in draft-xli-behave-divi-03? Could
you please elaborate a bit on the differences? 

> Also, feel free to use/refer to the table in: 
> http://tools.ietf.org/html/draft-dec-stateless-4v6-02#section-4.1 , 
> which although being specific to the stateless variants, has material 
> applicable to the wider comparison that includes stateful.

I am aware of this table, thanks. I think it's a great work! I am definitely
considering it.

Thanks,
Nejc

From xiaohong.deng@orange-ftgroup.com  Mon Aug 15 03:22:30 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B6921F8B00 for ; Mon, 15 Aug 2011 03:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.705
X-Spam-Level: 
X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=0.544,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGZTw6ailp5n for ; Mon, 15 Aug 2011 03:22:29 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 77CC621F8AF4 for ; Mon, 15 Aug 2011 03:22:26 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A04D36FCC10; Mon, 15 Aug 2011 12:31:44 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8DA5D6FCC0D; Mon, 15 Aug 2011 12:31:44 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 15 Aug 2011 12:19:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 15 Aug 2011 18:19:34 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195B286@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <4E452D57.6090501@viagenie.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Clarification of the stateles/stateful discussion
Thread-Index: AcxY9W+kKs4ILsB1QfKz9BaLjQdBeACOQnvA
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E43CD23.9060308@viagenie.ca> <0962B0BEF842A24191AD9BE41A8DD2FC0195B02C@ch-mailsrv.rd.francetelecom.fr> <4E4528ED.205 0500@via genie.ca> <0962B0BEF842A24191AD9BE41A8DD2FC0195B02E@ch-mailsrv.rd.francetelecom.fr> <4E452D57.6090501@viageni e.ca>
From: 
To: 
X-OriginalArrivalTime: 15 Aug 2011 10:19:38.0622 (UTC) FILETIME=[D6BFC1E0:01CC5B34]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2011 10:22:30 -0000

=20

|-----Original Message-----
|From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20
|Sent: Friday, August 12, 2011 9:41 PM
|To: DENG Xiaohong ESP/PEK
|Cc: rajiva@cisco.com; despres.remi@laposte.net; softwires@ietf.org
|Subject: Re: [Softwires] Clarification of the=20
|stateles/stateful discussion
|
|On 2011-08-12 09:25, xiaohong.deng@orange-ftgroup.com wrote:
|> |In your experiments, do you measure port and session usage on the=20
|> |NAT, on the internal host, or both? It's not clear to me=20
|when reading=20
|> |your experiment results at=20
|> |http://opensourcev6transtechnologies.weebly.com/experiments-res
|> |ults.html
|>=20
|> The data shows there are only the port and session usage on the NAT.
|
|Ok. Thanks.
|
|Then I think we're missing an important piece of data: port=20
|and session usage on the host. Here's why, with an example.

Nice examples. More below.

|
|
|Suppose I run an app on my host that creates two sessions=20
|using two different source ports:
|
|192.168.0.10:65000 --> 1.2.3.4:80
|192.168.0.10:65001 --> 5.6.7.8:80
|
|An EIM NAT will always map these two sessions to two different=20
|external ports, let's say like this:
|
|4.4.4.4:65000 --> 1.2.3.4:80
|4.4.4.4:65001 --> 5.6.7.8:80
|
|A non-EIM NAT could instead conserve ports by reusing the same=20
|external port for the two sessions:
|
|4.4.4.4:65000 --> 1.2.3.4:80
|4.4.4.4:65000 --> 5.6.7.8:80
|
|------------------------------
|
|Suppose now that a different app creates two sessions using=20
|the same source port:

Very perceptive example. We did run into this case during PCP-UPnP
Interworking work when we're struggling how PCP handle internal ports=20
conflicts.

It's quiet common that different apps share the same source port
(at least ) on Windows XP (observed).=20

This case *exactly* shows how comes more sessions than ports
even with EIM NAT, so I wonder if you have this vision why still=20
surprised by the results?

|
|192.168.0.10:65000 --> 1.2.3.4:80
|192.168.0.10:65000 --> 5.6.7.8:80
|
|Both the EIM NAT and the non-EIM NAT would map them to the=20
|same external
|port:
|
|4.4.4.4:65000 --> 1.2.3.4:80
|4.4.4.4:65000 --> 5.6.7.8:80
|
|--------------------------------------



|
|
|So, conclusion: unless your extremely certain of the NAT=20
|behaviour (we rarely are, especially in edge cases), just by=20
|looking at the NAT port and session usage says nothing about=20
|what happens on the host. We don't know whether BitTorrent,=20

1. Looking at the NAT usage indeed says something about what
happens on the host. More reasons below.

2. Port and session usages on NAT are exactly what we're concerning
about, are they?

As far as BitTorrent concerned, it is the case that incomming
sessions are established by different destinations connecting to
the same internal port (listening port), which leads to more sessions
than ports on the host.

That's one reason,  among others, why sessions are more than=20
ports on both the host and the NAT for BT applications.

(b) Second, tcp and udp sharing the same internal port to establish
different sessions is another reason results in more sessions. =20

(c) Third, as you listed above, different applications share the same
internal port to establish different sessions.

=20

|Skype, or Firefox reuse source ports for different=20
|destinations or whether they simply use additional internal=20
|source ports.
|
|Usually, if an application just uses the usual BSD sockets API=20
|to initiate each new session (socket() then connect()), the OS=20
|will assign a different source ports (for all common consumer=20
|OSes). It could be possible that the application does it=20
|otherwise, but the straightforward way to do it just consumes=20
|another port.

Consider how  socket RESUME option works. ;)

|
|So your observations on the NAT, where significantly more=20

Just for BT and skype cases, it is significantly more. For firefox
and IE, I would say it's a bit more, given that http requests are=20
always acommpany with DNS UDP queries, which hopefully=20
could you explain why, according to reason (b) and (c) above,
If you also agree with (b), since you already agreed with (c).

|sessions were active than there were ports, mean that either=20
|of these is true:

Niether, IMHO.

|
|a) Firefox, the BitTorrent client you tested, and Skype do not=20
|create new sessions with the usual socket() then connect()=20
|sequence. (That would be quite strange for Firefox and=20
|BitTorrent, not so much for Skype.)

See above. Hope it's clear stated and be stay open to hear your
comments.=20

|
|b) The NAT you tested was not EIM. (This would not be=20
|surprising since there are many non-EIM consumer grade NATs out there.)

IMHO. A linux knernal 2.6.32 ,which we used for A+P NAT, provide an EIM, =

yet corret me if wrong.


|
|Thoughts?

All above.

Cheers,
Xiaohong

|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca
|

From nejc@skoberne.net  Mon Aug 15 06:43:02 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455A021F8B40 for ; Mon, 15 Aug 2011 06:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUgSxPCoIsjP for ; Mon, 15 Aug 2011 06:43:01 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9A21F8B1B for ; Mon, 15 Aug 2011 06:43:01 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id CC09822780C3; Mon, 15 Aug 2011 15:43:45 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2llUtGxPSe80; Mon, 15 Aug 2011 15:43:43 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id EDFBD22780C6; Mon, 15 Aug 2011 15:43:41 +0200 (CEST)
Message-ID: <4E49228F.2040705@skoberne.net>
Date: Mon, 15 Aug 2011 14:43:43 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Naoki Matsuhira 
References: <6D93B4F87F5667499B9104BA798D637A046A13F2@STAFFMBX-1.lunet.lboro.ac.uk> <6D93B4F87F5667499B9104BA798D637A0C5FE3B25F@STAFFMBX-1.lunet.lboro.ac.uk>
In-Reply-To: <6D93B4F87F5667499B9104BA798D637A0C5FE3B25F@STAFFMBX-1.lunet.lboro.ac.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" 
Subject: [Softwires] SA46T questions (was: Re: FW: SA46T implementation)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2011 13:43:02 -0000

Dear Naoki,

>> 1. Since we are analyzing IPv4 address sharing mechanisms in general (mostly 4over6 mechanisms), we are interested in the variant of your design, which also includes a NAT somewhere in the network. As far as I understand, the only plance where you can put a NAT device is the core - so with your design, you can only provide "classic" CGN-type of address sharing, is this correct?
> 
> SA46T is just a tunneling technology, that mean, usage of simple
> tunneling technology may possible, and usage with combination with NAT
> may possible.
> 
> As you mentions, SA46T may use CGN-type method, however, I want say
> "address reusable mechanism", not "address sharing mechanism".
> 
> DS-Lite is the technology which combined CGN and tunnel. SA46T may be
> used as tunneling technology in DS-Lite. In such case, SA46T provide
> address reuse mechanisms with SA46T plane ID. Using SA46T plane ID, same
> IPv4 address can be used with different plane ID value.
> 
> I think SA46T may use other than access network. For example, SA46T may
> provide IPv4 VPN service over IPv6 only backbone. I feel softwire WG
> focus access network too much.
> 
> SA46T does not have address sharing mechanism. However, SA46T-AS have
> address sharing mechanism. That is A+P like mechanism.
> 
> SA46T-AS is documented in
> http://tools.ietf.org/html/draft-matsuhira-sa46t-as-01
> 
> In this version, two usages is discussed, one is clients environments,
> and other is server environments.

As far as I can see from the SA46T-AS draft, you just embed 16-bit port
number in the SA46T-AS address, is this correct? This means, you cannot
have a port range, but only 1 port per CPE allocated. I guess I am
missing something here?

Also, you say in the 5th section, that ICMPv4 doesn't work. But for
for this, you can make an ALG, like with other address sharing mechanisms?
I think having ICMPv4 work is quite a crucial thing in such a mechanism.

---

Question to others: what do you think about this? Should I also include
this one into the table of IPv4 address sharing mechanisms?

Thanks,
Nejc

From tetsuya@ipinfusion.com  Mon Aug 15 17:03:06 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01611E80DD for ; Mon, 15 Aug 2011 17:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.411
X-Spam-Level: 
X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.188,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1hhlESJcRZw for ; Mon, 15 Aug 2011 17:03:05 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBCE11E8091 for ; Mon, 15 Aug 2011 17:03:05 -0700 (PDT)
Received: by gwb20 with SMTP id 20so3967812gwb.31 for ; Mon, 15 Aug 2011 17:03:52 -0700 (PDT)
Received: by 10.236.193.106 with SMTP id j70mr13862517yhn.86.1313453030324; Mon, 15 Aug 2011 17:03:50 -0700 (PDT)
Received: from [10.70.2.100] ([12.248.239.142]) by mx.google.com with ESMTPS id c63sm3892374yhe.46.2011.08.15.17.03.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Aug 2011 17:03:49 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Tetsuya Murakami 
In-Reply-To: 
Date: Mon, 15 Aug 2011 17:03:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com>
References: 
To: Washam Fan 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 00:03:06 -0000

Hi Washam,

We can allow to use multiple mapping rules in a 4rd domain. In this =
case, there are several mapping rules and one mapping rule consists of =
the following parameters.

Domain IPv6 prefix
Domain 4rd prefix
CE IPv6 prefix length
Domain IPv6 suffix (optional)

When delegating an IPv6 prefix from the network, the corresponding =
mapping rule whose domain ipv6 prefix has the longest match with the =
delegated ipv6 prefix, can be selected.

Also, when forwarding an IPv4 packet to another CE, the corresponding =
mapping rule whose domain 4rd prefix has the longest match with the the =
destination ipv4 address, can be selected.

It is stated in section 5.1.1 and section 7 a little bit in the draft.

Thanks,
Tetsuya Murakami

On 2011/08/14, at 5:52, Washam Fan wrote:

> Hi,
>=20
> It seems to me only one domain IPv6 prefix is allowed, per
> draft-murakami-softwire-4rd-00. But I see no issue if we allow
> multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a
> outbound IPv4 package, the matched rule can tell which domain ipv6
> prefix can be used for building outer IPv6 destination address.
>=20
> Thanks,
> washam
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From despres.remi@laposte.net  Mon Aug 15 23:17:34 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9178021F871C for ; Mon, 15 Aug 2011 23:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ynh4oUmMu8P for ; Mon, 15 Aug 2011 23:17:32 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3AE21F86EA for ; Mon, 15 Aug 2011 23:17:31 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id E100F70010C7; Tue, 16 Aug 2011 08:18:18 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 5B4517000F2E; Tue, 16 Aug 2011 08:18:14 +0200 (CEST)
X-SFR-UUID: 20110816061816373.5B4517000F2E@msfrf2313.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4E4434D2.1080801@skoberne.net>
Date: Tue, 16 Aug 2011 08:18:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <89B39994-0371-4B6A-860D-C4B27665757A@laposte.net>
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, , 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E4434D2.1080801@skoberne.net>
To: =?windows-1252?Q?Nejc_=8Akoberne?= 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org, Olaf Maennel , Iain Phillips , Roshan Mosaheb , Jozef Woods 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 06:17:34 -0000

Hi Nejc,

Thanks for this contribution.
+1 to have it pursued.

Maybe it would be better to only cover specifications for which drafts =
are available.
(I found the two "DSlite?" columns confusing, with no document to check =
their validity.)

Also, some of us are currently working on separating the 4rd "stateless =
address mapping" from its possible application to various encapsulation =
and translation mechanisms.=20
When done, hopefully soon, this could influence the way to structure =
your comparison table.

Regards,
RD


Le 11 ao=FBt 2011 =E0 22:00, Nejc =8Akoberne a =E9crit :

> Hello all,
>=20
> I am working on a trade-off analysis of IPv4 address sharing =
mechanisms. I am=20
> replying to Remi's e-mail (sent before I subscribed to the list):
>=20
>> I therefore worked out a way to present the range of solutions to be =
compared,=20
>> with the following taken in consideration:
>> - The stateless/stateful IPv4 across IPv6 comparison isn't limited to =
IPv4=20
>>  shared addresses (applies also to exclusive IPv4 customer =
addresses).
>> - If there is, in BR/AFBR's, no Customer state (i.e. no states =
referring to=20
>>  individual IPv6 prefixes), there can't be per-transport-connection =
state either.
>> - CE-CE direct paths are possible only if IPv4/IPv6 mappings of =
BR/AFBR's don't=20
>>  depend on Customer state.
>>=20
>> The proposed document structure is as follows, with pros and cons for =
each section:
>> a) Stateful per transport connection (and also stateful per customer =
IPv6 prefix)
>>   e.g. DS-lite with CGN
>> b) Stateful per customer IPv6 prefix (but Stateless per transport =
connection)
>>   e.g. draft-cui-softwire-host-4over6-06
>> c) Stateless per customer IPv6 prefix (and also stateless per =
transport connection)
>>  - Hub-an-spoke
>>     TBD
>>   - Direct CE-CE paths (mesh)
>>     . Encapsulation based
>>       e.g. draft-murakami-softwire-4rd-00 alias
>>     . Translation based
>>       e.g. draft-murakami-softwire-4v6-translation-00
>=20
> I think we really need such a comparison document. As a newcomer I =
spent a lot
> of time digging up all the scattered documents here and it wasn't easy =
grasp the=20
> "big picture" of what has been proposed. I think we also need a =
trade-off analysis=20
> document, which I am writing at the moment.
>=20
> Anyway, I am not sure I agree with the structure suggested. I think we =
should try
> to be even more general and try to abstract all packet manipulations. =
I have prepared
> a table which tries to document all so-far implemented combinations =
(IPv4 address sharing
> mechanisms + 4via6 mechanisms, the intersection includes all but =
NAT444, which is
> only IPv4 address sharing mechanism and Public 4over6 which is only a =
4via6 mechanism).=20
> It would be useful to know if any of the missing combinations might be =
useful in=20
> practice as well, I hope this table will help in determining that.
>=20
> I will be very happy to hear any comments on the comparison. It's only =
a 1-page table.
>=20
> The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf
>=20
> Thanks,
> Nejc
>=20
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires



From matsuhira@jp.fujitsu.com  Tue Aug 16 00:09:30 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB83F21F8906 for ; Tue, 16 Aug 2011 00:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.94
X-Spam-Level: 
X-Spam-Status: No, score=-103.94 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJkjI04YAuM8 for ; Tue, 16 Aug 2011 00:09:29 -0700 (PDT)
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9C13C21F86C0 for ; Tue, 16 Aug 2011 00:09:28 -0700 (PDT)
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 628993EE0B5 for ; Tue, 16 Aug 2011 16:10:14 +0900 (JST)
Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 48A4045DE58 for ; Tue, 16 Aug 2011 16:10:14 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 308F545DE54 for ; Tue, 16 Aug 2011 16:10:14 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 22FC9E08001 for ; Tue, 16 Aug 2011 16:10:14 +0900 (JST)
Received: from m002.s.css.fujitsu.com (m002.s.css.fujitsu.com [10.23.4.32]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id E2A181DB8049 for ; Tue, 16 Aug 2011 16:10:13 +0900 (JST)
Received: from m002.css.fujitsu.com (m002 [127.0.0.1]) by m002.s.css.fujitsu.com (Postfix) with ESMTP id 092502E069D; Tue, 16 Aug 2011 16:10:13 +0900 (JST)
Received: from [127.0.0.1] (fj86077803.kh0110-194.dhcp.css.fujitsu.com [10.17.194.90]) by m002.s.css.fujitsu.com (Postfix) with ESMTP id 081122E06C7; Tue, 16 Aug 2011 16:10:12 +0900 (JST)
X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1
Message-ID: <4E4A17CD.8030807@jp.fujitsu.com>
Date: Tue, 16 Aug 2011 16:10:05 +0900
From: Naoki Matsuhira 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
References: <6D93B4F87F5667499B9104BA798D637A046A13F2@STAFFMBX-1.lunet.lboro.ac.uk> <6D93B4F87F5667499B9104BA798D637A0C5FE3B25F@STAFFMBX-1.lunet.lboro.ac.uk> <4E49228F.2040705@skoberne.net>
In-Reply-To: <4E49228F.2040705@skoberne.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] SA46T questions
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 07:09:30 -0000

Hi. Hejc,

(2011/08/15 22:43), Nejc Ĺ koberne wrote:

>> SA46T does not have address sharing mechanism. However, SA46T-AS have
>> address sharing mechanism. That is A+P like mechanism.
>>
>> SA46T-AS is documented in
>> http://tools.ietf.org/html/draft-matsuhira-sa46t-as-01
>>
>> In this version, two usages is discussed, one is clients environments,
>> and other is server environments.
>
> As far as I can see from the SA46T-AS draft, you just embed 16-bit port
> number in the SA46T-AS address, is this correct? This means, you cannot
> have a port range, but only 1 port per CPE allocated. I guess I am
> missing something here?

That's depend on prefix length. If prefix length is 128bits, only one 
port per SA46T-AS tunnel endpoint is allocated. However, If prefix 
length is 128 - 8 = 120bit, 2^8 = 256 ports per SA46T-AS tunnel endpoint 
are allocated. And also, if prefix length is 128 - 16 =112bit, 2~16 = 
65536 ports per SA46T-AS tunnel endpoint are allocated, and this case 
dose not share one IP address.

Number of ports can be selected by prefix length.

> Also, you say in the 5th section, that ICMPv4 doesn't work. But for
> for this, you can make an ALG, like with other address sharing mechanisms?
> I think having ICMPv4 work is quite a crucial thing in such a mechanism.

Yes, your comment is correct. I merely describe a general rule. And I 
agree your point.

>
> ---
>
> Question to others: what do you think about this? Should I also include
> this one into the table of IPv4 address sharing mechanisms?
>
> Thanks,
> Nejc
>
>


From despres.remi@laposte.net  Tue Aug 16 01:27:22 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0734121F8B0E for ; Tue, 16 Aug 2011 01:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level: 
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4cAJyVfpVJN for ; Tue, 16 Aug 2011 01:27:21 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CD21F8AD1 for ; Tue, 16 Aug 2011 01:27:20 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id ACD6B7000988; Tue, 16 Aug 2011 10:28:07 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 685207000749; Tue, 16 Aug 2011 10:27:59 +0200 (CEST)
X-SFR-UUID: 20110816082803427.685207000749@msfrf2206.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com>
Date: Tue, 16 Aug 2011 10:27:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com>
To: Tetsuya Murakami 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 08:27:22 -0000

Hi Tetsuya-san,

I agree, of course, on the need to support several mapping rules.
But IMHO one point needs clarification (see below).


Le 16 ao=FBt 2011 =E0 02:03, Tetsuya Murakami a =E9crit :

> Hi Washam,
>=20
> We can allow to use multiple mapping rules in a 4rd domain.
...
> When delegating an IPv6 prefix from the network, the corresponding =
mapping rule whose domain ipv6 prefix has the longest match with the =
delegated ipv6 prefix, can be selected.

As already discussed privately, I don't know realistic cases where two =
rules would have IPv6 or IPv4 overlapping prefixes.
Consequently, it seems that "longest" match, while being permitted, =
doesn't need to be a requirement.
Would you have such use cases to share?

Regards,
RD

>=20
> Also, when forwarding an IPv4 packet to another CE, the corresponding =
mapping rule whose domain 4rd prefix has the longest match with the the =
destination ipv4 address, can be selected.
>=20
> It is stated in section 5.1.1 and section 7 a little bit in the draft.
>=20
> Thanks,
> Tetsuya Murakami
>=20
> On 2011/08/14, at 5:52, Washam Fan wrote:
>=20
>> Hi,
>>=20
>> It seems to me only one domain IPv6 prefix is allowed, per
>> draft-murakami-softwire-4rd-00. But I see no issue if we allow
>> multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a
>> outbound IPv4 package, the matched rule can tell which domain ipv6
>> prefix can be used for building outer IPv6 destination address.
>>=20
>> Thanks,
>> washam
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires



From nejc@skoberne.net  Tue Aug 16 02:23:17 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603EF21F8AF7 for ; Tue, 16 Aug 2011 02:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7kmvRTtthCO for ; Tue, 16 Aug 2011 02:23:16 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 41A9621F8ACC for ; Tue, 16 Aug 2011 02:23:16 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 9B15D22780EE; Tue, 16 Aug 2011 11:23:56 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlIqbvVQntCZ; Tue, 16 Aug 2011 11:23:56 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 0389B22780C2; Tue, 16 Aug 2011 11:23:55 +0200 (CEST)
Message-ID: <4E4A372F.50603@skoberne.net>
Date: Tue, 16 Aug 2011 10:23:59 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: =?windows-1252?Q?R=E9mi_Despr=E9s?= 
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E4434D2.1080801@skoberne.net> <89B39994-0371-4B6A-860D-C4B27665757A@laposte.net>
In-Reply-To: <89B39994-0371-4B6A-860D-C4B27665757A@laposte.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: softwires@ietf.org, Olaf Maennel , Iain Phillips , Roshan Mosaheb , Jozef Woods 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 09:23:17 -0000

Dear Rémi,

> Maybe it would be better to only cover specifications for which drafts are available.
> (I found the two "DSlite?" columns confusing, with no document to check their validity.)

I considered this, but then decided to do it this way since as far as I 
understand, DS-Lite RFC doesn't say what IPv4 address and UDP/TCP port
allocation policy must be supported. The same goes for provisioning
additional IPv4 addresses and port ranges. Is this correct?

> Also, some of us are currently working on separating the 4rd "stateless address mapping" from its possible application to various encapsulation and translation mechanisms.
> When done, hopefully soon, this could influence the way to structure your comparison table.

This would indeed be very useful. I will certainly work on it as soon as the document is
publicly available.

Thanks,
Nejc

From despres.remi@laposte.net  Tue Aug 16 03:05:39 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFAD21F8A58 for ; Tue, 16 Aug 2011 03:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.928
X-Spam-Level: 
X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBwRWrrhzqNg for ; Tue, 16 Aug 2011 03:05:38 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 251F721F8A36 for ; Tue, 16 Aug 2011 03:05:37 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id B1A2D7006812; Tue, 16 Aug 2011 12:06:24 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id 1A0D0700654E; Tue, 16 Aug 2011 12:06:21 +0200 (CEST)
X-SFR-UUID: 20110816100622106.1A0D0700654E@msfrf2112.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4E4A372F.50603@skoberne.net>
Date: Tue, 16 Aug 2011 12:06:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D6F87D7-F84A-431A-AF03-928240A3FBE6@laposte.net>
References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, 	<201107302126309348102@csnet1.cs.tsinghua.edu.cn>	<51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com>	<4E36713C.904@go6.si>		<4E36B9F0.3070607@go6.si>	<4E36BBF9.9070709@viagenie.ca>		<4E370ABB.30200@go6.si>	<37038E4B-9E49-4AD2-B869-C79125B33E8F@gmail.com><4E37FA9A.5070909@viagenie.ca><4E38019D.3090206@viagenie.ca><067E6CE33034954AAC05C9EC85E2577C0599B280@XMB-RCD-111.cisco.com>  <0962B0BEF842A24191AD9BE41A8DD2FC0195AC12@ch-mailsrv.rd.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C05A6F831@XMB-RCD-111.cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC0195AE6B@ch-mailsrv.rd.francetelecom.fr> <4E4434D2.1080801@skoberne.net> <89B39994-0371-4B6A-860D-C4B27665757A@laposte.net> <4E4A372F.50603@skoberne.net>
To: =?windows-1252?Q?Nejc_=8Akoberne?= 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org, Olaf Maennel , Iain Phillips , Roshan Mosaheb , Jozef Woods 
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 10:05:39 -0000

Le 16 ao=FBt 2011 =E0 11:23, Nejc =8Akoberne a =E9crit :

> Dear R=E9mi,
>=20
>> Maybe it would be better to only cover specifications for which =
drafts are available.
>> (I found the two "DSlite?" columns confusing, with no document to =
check their validity.)
>=20
> I considered this, but then decided to do it this way since as far as =
I=20
> understand, DS-Lite RFC doesn't say what IPv4 address and UDP/TCP port
> allocation policy must be supported.

I see.
Then "unspecified" in the DS-lite column might be another way to express =
it.

BTW, colors don't seem necessary.
Without them, one avoids having to decide whether "IPv4 address and =
UDP/TCP port allocation policy" is red or green ;-).


> The same goes for provisioning
> additional IPv4 addresses and port ranges. Is this correct?
>=20
>> Also, some of us are currently working on separating the 4rd =
"stateless address mapping" from its possible application to various =
encapsulation and translation mechanisms.
>> When done, hopefully soon, this could influence the way to structure =
your comparison table.
>=20
> This would indeed be very useful. I will certainly work on it as soon =
as the document is
> publicly available.

Excellent.
Look forward to it.

RD


>=20
> Thanks,
> Nejc



From nejc@skoberne.net  Tue Aug 16 03:23:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219B721F8ADE for ; Tue, 16 Aug 2011 03:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIARey8JfsZq for ; Tue, 16 Aug 2011 03:23:53 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3930721F8AD3 for ; Tue, 16 Aug 2011 03:23:52 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id B8A9B22780C6; Tue, 16 Aug 2011 12:24:39 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgwdfRLsODiD; Tue, 16 Aug 2011 12:24:39 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 3C9CA2278005; Tue, 16 Aug 2011 12:24:39 +0200 (CEST)
Message-ID: <4E4A4569.8030706@skoberne.net>
Date: Tue, 16 Aug 2011 11:24:41 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" 
Subject: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 10:23:54 -0000

Hello,

I have some comments on your draft, see inline.

Regards,
Nejc

---------------
   2. Terminology



   This document makes use of the following terms:

   Stateful 4/6 solution  (or stateful solution in short): denotes a
                       solution where the network maintains user-session
                       states relying on the activation of a NAT
                       function in the Service Providers' network
                       [I-D.ietf-behave-lsn-requirements].  The NAT
                       function is responsible for sharing the same IPv4
                       address among several subscribers and to maintain
                       user-session state.

   Stateless  4/6 solution  (or stateless solution in short): denotes a
                       solution which does not require any user-session
                       state (seeSection 2.3 of [RFC1958]) to be
                       maintained by any IP address sharing function in
                       the Service Provider's network.  This category of
                       solutions assumes a dependency between an IPv6
                       prefix and IPv4 address.  In an IPv4 address
                       sharing context, dedicated functions are required
                       to be enabled in the CPE router to restrict the
                       source IPv4 port numbers.  Within this document,
                       "port set" and "port range" terms are used
                       interchangeably.

[NS: If we consider a "stateful A+P" solution, we don't necessarily
have a dependency between an IPv6 prefix and IPv4 address. Also, we
don't have any user-session state in the Service Provider's network.
We do, however, have some user state (in order to do stateful tunneling,
for example). Maybe this is included in "user-session" in your
terminology, but then I think it would be appropriate to define the
term "user-session" clearly.]

...

       3.1.5. Bandwidth Saving



   In same particular network scenarios (e.g., wireless network ),
   spectrum is very valuable and scarce resource.  Service providers
   usually wish to eliminate unnecessary overhead to save bandwidth
   consumption in such environment.  Service providers need to consider
   optimizing the form of packet processing when encapsulation is used.
   Since existing header compression techniques are stateful, it is
   expected that stateless solution minimize overhead introduced by the
   solution.

[NS: I don't understand this section, but that may be just me.
Maybe is there a better way to explain the point?]

...


       3.3.1. Implicit Host Identification



   Service Providers do not offer only IP connectivity services but also
   added value services (a.k.a., internal services).  Upgrading these
   services to be IPv6-enabled is not sufficient because of legacy
   devices.  In some deployments, the delivery of these added-value
   services relies on implicit identification mechanism based on the
   source IPv4 address.  Due to address sharing, implicit identification
   will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing
   implicit identification with explicit authentication will be seen as
   a non acceptable service regression by the end users (less Quality of
   Experience (QoE)).

   When a stateless solution is deployed, implicit identification for
   internal services is likely to be easier to implement: the implicit
   identification should be updated to take into account the port range
   and the IPv4 address.  Techniques as those analyzed in
   [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the
   delivery of these internal services if a stateless solution is
   deployed.

[NS: I don't think this is true only for stateless
solutions. If we have a stateful solution with static port allocation
(as you mention in section 3.1.3), then implementing such an implicit
host identification which uses also port information, is doable as
well.]

From mohamed.boucadair@orange-ftgroup.com  Tue Aug 16 04:47:59 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6899021F889A for ; Tue, 16 Aug 2011 04:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level: 
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt2e--fya3rM for ; Tue, 16 Aug 2011 04:47:58 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 78D2E21F886D for ; Tue, 16 Aug 2011 04:47:58 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 932D222C7B0; Tue, 16 Aug 2011 13:48:45 +0200 (CEST)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7625E4C07E; Tue, 16 Aug 2011 13:48:45 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 16 Aug 2011 13:48:45 +0200
From: 
To: =?utf-8?B?TmVqYyDFoGtvYmVybmU=?= , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Date: Tue, 16 Aug 2011 13:48:43 +0200
Thread-Topic: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Thread-Index: Acxb/rmMrsOQA4SWTVOZZMOA3ZtQnAACcZAg
Message-ID: <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr>
References: <4E4A4569.8030706@skoberne.net>
In-Reply-To: <4E4A4569.8030706@skoberne.net>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.16.111515
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 11:47:59 -0000

RGVhciBOZWpjLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIHNlZSBteSBh
bnN3ZXJzIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQogDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdp
bmUtLS0tLQ0KRGUgOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJl
cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5lamMgxaBrb2Jlcm5lDQpFbnZvecOp
IDogbWFyZGkgMTYgYW/Du3QgMjAxMSAxMjoyNQ0Kw4AgOiBkcmFmdC1vcGVyYXRvcnMtc29mdHdp
cmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uQHRvb2xzLmlldGYub3JnDQpDYyA6IHNvZnR3aXJl
c0BpZXRmLm9yZw0KT2JqZXQgOiBbU29mdHdpcmVzXSBkcmFmdC1vcGVyYXRvcnMtc29mdHdpcmUt
c3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uDQoNCkhlbGxvLA0KDQpJIGhhdmUgc29tZSBjb21tZW50
cyBvbiB5b3VyIGRyYWZ0LCBzZWUgaW5saW5lLg0KDQpSZWdhcmRzLA0KTmVqYw0KDQotLS0tLS0t
LS0tLS0tLS0NCiAgIDIuIFRlcm1pbm9sb2d5DQoNCg0KDQogICBUaGlzIGRvY3VtZW50IG1ha2Vz
IHVzZSBvZiB0aGUgZm9sbG93aW5nIHRlcm1zOg0KDQogICBTdGF0ZWZ1bCA0LzYgc29sdXRpb24g
IChvciBzdGF0ZWZ1bCBzb2x1dGlvbiBpbiBzaG9ydCk6IGRlbm90ZXMgYQ0KICAgICAgICAgICAg
ICAgICAgICAgICBzb2x1dGlvbiB3aGVyZSB0aGUgbmV0d29yayBtYWludGFpbnMgdXNlci1zZXNz
aW9uDQogICAgICAgICAgICAgICAgICAgICAgIHN0YXRlcyByZWx5aW5nIG9uIHRoZSBhY3RpdmF0
aW9uIG9mIGEgTkFUDQogICAgICAgICAgICAgICAgICAgICAgIGZ1bmN0aW9uIGluIHRoZSBTZXJ2
aWNlIFByb3ZpZGVycycgbmV0d29yaw0KICAgICAgICAgICAgICAgICAgICAgICBbSS1ELmlldGYt
YmVoYXZlLWxzbi1yZXF1aXJlbWVudHNdLiAgVGhlIE5BVA0KICAgICAgICAgICAgICAgICAgICAg
ICBmdW5jdGlvbiBpcyByZXNwb25zaWJsZSBmb3Igc2hhcmluZyB0aGUgc2FtZSBJUHY0DQogICAg
ICAgICAgICAgICAgICAgICAgIGFkZHJlc3MgYW1vbmcgc2V2ZXJhbCBzdWJzY3JpYmVycyBhbmQg
dG8gbWFpbnRhaW4NCiAgICAgICAgICAgICAgICAgICAgICAgdXNlci1zZXNzaW9uIHN0YXRlLg0K
DQogICBTdGF0ZWxlc3MgIDQvNiBzb2x1dGlvbiAgKG9yIHN0YXRlbGVzcyBzb2x1dGlvbiBpbiBz
aG9ydCk6IGRlbm90ZXMgYQ0KICAgICAgICAgICAgICAgICAgICAgICBzb2x1dGlvbiB3aGljaCBk
b2VzIG5vdCByZXF1aXJlIGFueSB1c2VyLXNlc3Npb24NCiAgICAgICAgICAgICAgICAgICAgICAg
c3RhdGUgKHNlZVNlY3Rpb24gMi4zIG9mIFtSRkMxOTU4XSkgdG8gYmUNCiAgICAgICAgICAgICAg
ICAgICAgICAgbWFpbnRhaW5lZCBieSBhbnkgSVAgYWRkcmVzcyBzaGFyaW5nIGZ1bmN0aW9uIGlu
DQogICAgICAgICAgICAgICAgICAgICAgIHRoZSBTZXJ2aWNlIFByb3ZpZGVyJ3MgbmV0d29yay4g
IFRoaXMgY2F0ZWdvcnkgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgc29sdXRpb25zIGFzc3Vt
ZXMgYSBkZXBlbmRlbmN5IGJldHdlZW4gYW4gSVB2Ng0KICAgICAgICAgICAgICAgICAgICAgICBw
cmVmaXggYW5kIElQdjQgYWRkcmVzcy4gIEluIGFuIElQdjQgYWRkcmVzcw0KICAgICAgICAgICAg
ICAgICAgICAgICBzaGFyaW5nIGNvbnRleHQsIGRlZGljYXRlZCBmdW5jdGlvbnMgYXJlIHJlcXVp
cmVkDQogICAgICAgICAgICAgICAgICAgICAgIHRvIGJlIGVuYWJsZWQgaW4gdGhlIENQRSByb3V0
ZXIgdG8gcmVzdHJpY3QgdGhlDQogICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZSBJUHY0IHBv
cnQgbnVtYmVycy4gIFdpdGhpbiB0aGlzIGRvY3VtZW50LA0KICAgICAgICAgICAgICAgICAgICAg
ICAicG9ydCBzZXQiIGFuZCAicG9ydCByYW5nZSIgdGVybXMgYXJlIHVzZWQNCiAgICAgICAgICAg
ICAgICAgICAgICAgaW50ZXJjaGFuZ2VhYmx5Lg0KDQpbTlM6IElmIHdlIGNvbnNpZGVyIGEgInN0
YXRlZnVsIEErUCIgc29sdXRpb24sIHdlIGRvbid0IG5lY2Vzc2FyaWx5DQpoYXZlIGEgZGVwZW5k
ZW5jeSBiZXR3ZWVuIGFuIElQdjYgcHJlZml4IGFuZCBJUHY0IGFkZHJlc3MuIEFsc28sIHdlDQpk
b24ndCBoYXZlIGFueSB1c2VyLXNlc3Npb24gc3RhdGUgaW4gdGhlIFNlcnZpY2UgUHJvdmlkZXIn
cyBuZXR3b3JrLg0KDQpNZWQ6IEZ1bGx5IGFncmVlLiBGV0lXLCB0aGlzIGlzIHdoYXQgd2UgY2Fs
bGVkICJCaW5kaW5nIFRhYmxlIEErUCBNb2RlIiBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC15bWJrLWFwbHVzcC0xMCNzZWN0aW9uLTQuNC4NCg0KV2UgZG8sIGhvd2V2ZXIsIGhh
dmUgc29tZSB1c2VyIHN0YXRlIChpbiBvcmRlciB0byBkbyBzdGF0ZWZ1bCB0dW5uZWxpbmcsDQpm
b3IgZXhhbXBsZSkuIE1heWJlIHRoaXMgaXMgaW5jbHVkZWQgaW4gInVzZXItc2Vzc2lvbiIgaW4g
eW91cg0KdGVybWlub2xvZ3ksIGJ1dCB0aGVuIEkgdGhpbmsgaXQgd291bGQgYmUgYXBwcm9wcmlh
dGUgdG8gZGVmaW5lIHRoZQ0KdGVybSAidXNlci1zZXNzaW9uIiBjbGVhcmx5Ll0NCg0KTWVkOiBX
ZSBhc3N1bWVkIHRoZSBkZWZpbml0aW9uIG9mIHN0YXRlIGFzIG1lbnRpb25lZCBpbiBSRkMxOTU4
OyBidXQgSSBhZ3JlZSB0aGUgdGVybWlub2xvZ3kgc2hvdWxkIGJlIG11Y2ggbW9yZSBjbGVhcmVy
Lg0KDQouLi4NCg0KICAgICAgIDMuMS41LiBCYW5kd2lkdGggU2F2aW5nDQoNCg0KDQogICBJbiBz
YW1lIHBhcnRpY3VsYXIgbmV0d29yayBzY2VuYXJpb3MgKGUuZy4sIHdpcmVsZXNzIG5ldHdvcmsg
KSwNCiAgIHNwZWN0cnVtIGlzIHZlcnkgdmFsdWFibGUgYW5kIHNjYXJjZSByZXNvdXJjZS4gIFNl
cnZpY2UgcHJvdmlkZXJzDQogICB1c3VhbGx5IHdpc2ggdG8gZWxpbWluYXRlIHVubmVjZXNzYXJ5
IG92ZXJoZWFkIHRvIHNhdmUgYmFuZHdpZHRoDQogICBjb25zdW1wdGlvbiBpbiBzdWNoIGVudmly
b25tZW50LiAgU2VydmljZSBwcm92aWRlcnMgbmVlZCB0byBjb25zaWRlcg0KICAgb3B0aW1pemlu
ZyB0aGUgZm9ybSBvZiBwYWNrZXQgcHJvY2Vzc2luZyB3aGVuIGVuY2Fwc3VsYXRpb24gaXMgdXNl
ZC4NCiAgIFNpbmNlIGV4aXN0aW5nIGhlYWRlciBjb21wcmVzc2lvbiB0ZWNobmlxdWVzIGFyZSBz
dGF0ZWZ1bCwgaXQgaXMNCiAgIGV4cGVjdGVkIHRoYXQgc3RhdGVsZXNzIHNvbHV0aW9uIG1pbmlt
aXplIG92ZXJoZWFkIGludHJvZHVjZWQgYnkgdGhlDQogICBzb2x1dGlvbi4NCg0KW05TOiBJIGRv
bid0IHVuZGVyc3RhbmQgdGhpcyBzZWN0aW9uLCBidXQgdGhhdCBtYXkgYmUganVzdCBtZS4NCk1h
eWJlIGlzIHRoZXJlIGEgYmV0dGVyIHdheSB0byBleHBsYWluIHRoZSBwb2ludD9dDQoNCk1lZDog
V2UgaGF2ZSBzZXZlcmFsIGNvLWF1dGhvcnMgd2hvIGFyZSBub3QgZWl0aGVyIGluIGZhdm91ciBv
ciBtYWludGFpbmluZyB0aGlzIHNlY3Rpb24uIFRoaXMgdGV4dCB3aWxsIGJlIHJlbW92ZWQuDQoN
Ci4uLg0KDQoNCiAgICAgICAzLjMuMS4gSW1wbGljaXQgSG9zdCBJZGVudGlmaWNhdGlvbg0KDQoN
Cg0KICAgU2VydmljZSBQcm92aWRlcnMgZG8gbm90IG9mZmVyIG9ubHkgSVAgY29ubmVjdGl2aXR5
IHNlcnZpY2VzIGJ1dCBhbHNvDQogICBhZGRlZCB2YWx1ZSBzZXJ2aWNlcyAoYS5rLmEuLCBpbnRl
cm5hbCBzZXJ2aWNlcykuICBVcGdyYWRpbmcgdGhlc2UNCiAgIHNlcnZpY2VzIHRvIGJlIElQdjYt
ZW5hYmxlZCBpcyBub3Qgc3VmZmljaWVudCBiZWNhdXNlIG9mIGxlZ2FjeQ0KICAgZGV2aWNlcy4g
IEluIHNvbWUgZGVwbG95bWVudHMsIHRoZSBkZWxpdmVyeSBvZiB0aGVzZSBhZGRlZC12YWx1ZQ0K
ICAgc2VydmljZXMgcmVsaWVzIG9uIGltcGxpY2l0IGlkZW50aWZpY2F0aW9uIG1lY2hhbmlzbSBi
YXNlZCBvbiB0aGUNCiAgIHNvdXJjZSBJUHY0IGFkZHJlc3MuICBEdWUgdG8gYWRkcmVzcyBzaGFy
aW5nLCBpbXBsaWNpdCBpZGVudGlmaWNhdGlvbg0KICAgd2lsbCBmYWlsIFtJLUQuaWV0Zi1pbnRh
cmVhLXNoYXJlZC1hZGRyZXNzaW5nLWlzc3Vlc107IHJlcGxhY2luZw0KICAgaW1wbGljaXQgaWRl
bnRpZmljYXRpb24gd2l0aCBleHBsaWNpdCBhdXRoZW50aWNhdGlvbiB3aWxsIGJlIHNlZW4gYXMN
CiAgIGEgbm9uIGFjY2VwdGFibGUgc2VydmljZSByZWdyZXNzaW9uIGJ5IHRoZSBlbmQgdXNlcnMg
KGxlc3MgUXVhbGl0eSBvZg0KICAgRXhwZXJpZW5jZSAoUW9FKSkuDQoNCiAgIFdoZW4gYSBzdGF0
ZWxlc3Mgc29sdXRpb24gaXMgZGVwbG95ZWQsIGltcGxpY2l0IGlkZW50aWZpY2F0aW9uIGZvcg0K
ICAgaW50ZXJuYWwgc2VydmljZXMgaXMgbGlrZWx5IHRvIGJlIGVhc2llciB0byBpbXBsZW1lbnQ6
IHRoZSBpbXBsaWNpdA0KICAgaWRlbnRpZmljYXRpb24gc2hvdWxkIGJlIHVwZGF0ZWQgdG8gdGFr
ZSBpbnRvIGFjY291bnQgdGhlIHBvcnQgcmFuZ2UNCiAgIGFuZCB0aGUgSVB2NCBhZGRyZXNzLiAg
VGVjaG5pcXVlcyBhcyB0aG9zZSBhbmFseXplZCBpbg0KICAgW0ktRC5ib3VjYWRhaXItaW50YXJl
YS1uYXQtcmV2ZWFsLWFuYWx5c2lzXSBhcmUgbm90IHJlcXVpcmVkIGZvciB0aGUNCiAgIGRlbGl2
ZXJ5IG9mIHRoZXNlIGludGVybmFsIHNlcnZpY2VzIGlmIGEgc3RhdGVsZXNzIHNvbHV0aW9uIGlz
DQogICBkZXBsb3llZC4NCg0KW05TOiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdHJ1ZSBvbmx5IGZv
ciBzdGF0ZWxlc3MNCnNvbHV0aW9ucy4gSWYgd2UgaGF2ZSBhIHN0YXRlZnVsIHNvbHV0aW9uIHdp
dGggc3RhdGljIHBvcnQgYWxsb2NhdGlvbg0KKGFzIHlvdSBtZW50aW9uIGluIHNlY3Rpb24gMy4x
LjMpLCB0aGVuIGltcGxlbWVudGluZyBzdWNoIGFuIGltcGxpY2l0DQpob3N0IGlkZW50aWZpY2F0
aW9uIHdoaWNoIHVzZXMgYWxzbyBwb3J0IGluZm9ybWF0aW9uLCBpcyBkb2FibGUgYXMNCndlbGwu
XQ0KDQpNZWQ6IEkgQWdyZWUuIEJ1dCB0aGVuIHlvdSBsb29zZSBvdGhlciBiZW5lZml0cyBvZiB0
aGUgc3RhdGVmdWw6IGhhdmUgYW4gYWdncmVzc2l2ZSBhZGRyZXNzIHNoYXJpbmcgcmF0aW8u

From nejc@skoberne.net  Tue Aug 16 05:00:02 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E58C21F8ABD for ; Tue, 16 Aug 2011 05:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level: 
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQvyd6qgfc8e for ; Tue, 16 Aug 2011 05:00:01 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 19DCC21F8A55 for ; Tue, 16 Aug 2011 05:00:00 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 860A622780EE; Tue, 16 Aug 2011 14:00:47 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6g5FM8KNTjS; Tue, 16 Aug 2011 14:00:44 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id CB24822780D2; Tue, 16 Aug 2011 14:00:43 +0200 (CEST)
Message-ID: <4E4A5BEE.3030708@skoberne.net>
Date: Tue, 16 Aug 2011 13:00:46 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: mohamed.boucadair@orange-ftgroup.com
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 12:00:02 -0000

Dear Med,

> [NS: If we consider a "stateful A+P" solution, we don't necessarily
> have a dependency between an IPv6 prefix and IPv4 address. Also, we
> don't have any user-session state in the Service Provider's network.
> 
> Med: Fully agree. FWIW, this is what we called "Binding Table A+P Mode" in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4.

This is exactly what I had in mind.

> We do, however, have some user state (in order to do stateful tunneling,
> for example). Maybe this is included in "user-session" in your
> terminology, but then I think it would be appropriate to define the
> term "user-session" clearly.]
> 
> Med: We assumed the definition of state as mentioned in RFC1958; but I agree the terminology should be much more clearer.

Yes, "state" is implicitly defined there, however "user-session" is not
defined anywhere.

> [NS: I don't think this is true only for stateless
> solutions. If we have a stateful solution with static port allocation
> (as you mention in section 3.1.3), then implementing such an implicit
> host identification which uses also port information, is doable as
> well.]
> 
> Med: I Agree. But then you loose other benefits of the stateful: have an aggressive address sharing ratio.

You indeed loose agressive sharnig ratio, but you have somewhat more
flexible addressing. Also, the CPEs can be then really simple devices,
excluding any of the NAPT functionality, doing only stateless encapsulation.
However, what you loose/gain is irrelevant for my point. I think this
section should be modified in a way like the logging section or any
other appropriate way, which explains, that this is not the benefit of
the stateless nature, but rather the benefit of the static port allocation.

Thanks,
Nejc

From mohamed.boucadair@orange-ftgroup.com  Tue Aug 16 05:51:12 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC621F8ACE for ; Tue, 16 Aug 2011 05:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.023
X-Spam-Level: 
X-Spam-Status: No, score=-3.023 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6dfgG8LLyYG for ; Tue, 16 Aug 2011 05:51:11 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB8121F8ABB for ; Tue, 16 Aug 2011 05:51:11 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B955A3243DA; Tue, 16 Aug 2011 14:51:58 +0200 (CEST)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A003E238099; Tue, 16 Aug 2011 14:51:58 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 16 Aug 2011 14:51:58 +0200
From: 
To: =?utf-8?B?TmVqYyDFoGtvYmVybmU=?= 
Date: Tue, 16 Aug 2011 14:51:56 +0200
Thread-Topic: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Thread-Index: AcxcDCTWrd5Z85u4QxKeKRJiI7HJKwABbX7g
Message-ID: <94C682931C08B048B7A8645303FDC9F33E54A62CFC@PUEXCB1B.nanterre.francetelecom.fr>
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <4E4A5BEE.3030708@skoberne.net>
In-Reply-To: <4E4A5BEE.3030708@skoberne.net>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.16.121514
Cc: "softwires@ietf.org" , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 12:51:12 -0000

UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzDQpNZWQgDQoNCi0tLS0tTWVzc2Fn
ZSBkJ29yaWdpbmUtLS0tLQ0KRGUgOiBOZWpjIMWga29iZXJuZSBbbWFpbHRvOm5lamNAc2tvYmVy
bmUubmV0XSANCkVudm95w6kgOiBtYXJkaSAxNiBhb8O7dCAyMDExIDE0OjAxDQrDgCA6IEJPVUNB
REFJUiBNb2hhbWVkIE9MTkMvTkFEL1RJUA0KQ2MgOiBkcmFmdC1vcGVyYXRvcnMtc29mdHdpcmUt
c3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uQHRvb2xzLmlldGYub3JnOyBzb2Z0d2lyZXNAaWV0Zi5v
cmcNCk9iamV0IDogUmU6IFtTb2Z0d2lyZXNdIGRyYWZ0LW9wZXJhdG9ycy1zb2Z0d2lyZS1zdGF0
ZWxlc3MtNHY2LW1vdGl2YXRpb24NCg0KRGVhciBNZWQsDQoNCltTTklQXQ0KDQo+IFtOUzogSSBk
b24ndCB0aGluayB0aGlzIGlzIHRydWUgb25seSBmb3Igc3RhdGVsZXNzDQo+IHNvbHV0aW9ucy4g
SWYgd2UgaGF2ZSBhIHN0YXRlZnVsIHNvbHV0aW9uIHdpdGggc3RhdGljIHBvcnQgYWxsb2NhdGlv
bg0KPiAoYXMgeW91IG1lbnRpb24gaW4gc2VjdGlvbiAzLjEuMyksIHRoZW4gaW1wbGVtZW50aW5n
IHN1Y2ggYW4gaW1wbGljaXQNCj4gaG9zdCBpZGVudGlmaWNhdGlvbiB3aGljaCB1c2VzIGFsc28g
cG9ydCBpbmZvcm1hdGlvbiwgaXMgZG9hYmxlIGFzDQo+IHdlbGwuXQ0KPiANCj4gTWVkOiBJIEFn
cmVlLiBCdXQgdGhlbiB5b3UgbG9vc2Ugb3RoZXIgYmVuZWZpdHMgb2YgdGhlIHN0YXRlZnVsOiBo
YXZlIGFuIGFnZ3Jlc3NpdmUgYWRkcmVzcyBzaGFyaW5nIHJhdGlvLg0KDQpZb3UgaW5kZWVkIGxv
b3NlIGFncmVzc2l2ZSBzaGFybmlnIHJhdGlvLCBidXQgeW91IGhhdmUgc29tZXdoYXQgbW9yZQ0K
ZmxleGlibGUgYWRkcmVzc2luZy4gQWxzbywgdGhlIENQRXMgY2FuIGJlIHRoZW4gcmVhbGx5IHNp
bXBsZSBkZXZpY2VzLA0KZXhjbHVkaW5nIGFueSBvZiB0aGUgTkFQVCBmdW5jdGlvbmFsaXR5LCBk
b2luZyBvbmx5IHN0YXRlbGVzcyBlbmNhcHN1bGF0aW9uLg0KSG93ZXZlciwgd2hhdCB5b3UgbG9v
c2UvZ2FpbiBpcyBpcnJlbGV2YW50IGZvciBteSBwb2ludC4gSSB0aGluayB0aGlzDQpzZWN0aW9u
IHNob3VsZCBiZSBtb2RpZmllZCBpbiBhIHdheSBsaWtlIHRoZSBsb2dnaW5nIHNlY3Rpb24gb3Ig
YW55DQpvdGhlciBhcHByb3ByaWF0ZSB3YXksIHdoaWNoIGV4cGxhaW5zLCB0aGF0IHRoaXMgaXMg
bm90IHRoZSBiZW5lZml0IG9mDQp0aGUgc3RhdGVsZXNzIG5hdHVyZSwgYnV0IHJhdGhlciB0aGUg
YmVuZWZpdCBvZiB0aGUgc3RhdGljIHBvcnQgYWxsb2NhdGlvbi4NCg0KTWVkOiBZb3VyIHBvaW50
IGlzIHZhbGlkIGFuZCB0aGUgdGV4dCBzaG91bGQgYmUgdXBkYXRlZCBhY2NvcmRpbmdseS4gTXkg
Y29tbWVudCBhaW1zIHRvIHNob3cgdGhhdCB0aGUgY29tcGFyaXNvbiBpcyBub3Qgc28gdGhhdCB0
cml2aWFsLiBXZSBjYW4gY2xhaW0gdGhlIHN0YXRlZnVsIHdpdGggcG9ydCByYW5nZXMgY2FuIHBy
b3ZpZGUgc2ltaWxhciBmZWF0dXJlcyBhcyB0aGUgc3RhdGVsZXNzIG9yIHRoZSBiaW5kaW5nIG1v
ZGUgYnV0IHdlIGFsd2F5cyBmb3JnZXQgdG8gbWVudGlvbiB0aGlzIGxlYWQgdG8gbG9vc2Ugb25l
IG9mIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHN0YXRlZnVsLiBXZSBjYXB0dXJlZCBhIHNp
bWlsYXIgZGlzY3Vzc2lvbiBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVy
YXRvcnMtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTAxI3NlY3Rpb24tNC4yOg0K
DQoiNS4yLiAgUG9ydCBVdGlsaXNhdGlvbiBFZmZpY2llbmN5DQoNCiAgIENHTi1iYXNlZCBzb2x1
dGlvbnMsIGJlY2F1c2UgdGhleSBjYW4gZHluYW1pY2FsbHkgYXNzaWduIHBvcnRzLA0KICAgcHJv
dmlkZSBiZXR0ZXIgSVB2NCBhZGRyZXNzIHNoYXJpbmcgcmF0aW8gdGhhbiBzdGF0ZWxlc3Mgc29s
dXRpb25zDQogICAoaS5lLiwgY2FuIHNoYXJlIHRoZSBzYW1lIElQIGFkZHJlc3MgYW1vbmcgYSBs
YXJnZXIgbnVtYmVyIG9mDQogICBjdXN0b21lcnMpLiAgRm9yIFNlcnZpY2UgUHJvdmlkZXJzIHdo
byBkZXNpcmUgYW4gYWdncmVzc2l2ZSBJUHY0DQogICBhZGRyZXNzIHNoYXJpbmcsIGEgQ0dOLWJh
c2VkIHNvbHV0aW9uIGlzIG1vcmUgc3VpdGFibGUgdGhhbiB0aGUNCiAgIHN0YXRlbGVzcy4NCg0K
ICAgICAgSWYgYSBTZXJ2aWNlIFByb3ZpZGVyIGFkb3B0cyBhbiBhZ2dyZXNzaXZlIGFkZHJlc3Mg
c2hhcmluZyByYXRpbywNCiAgICAgIGl0IGlzIGxpa2VseSB0byBiZSBhdHRlbXB0ZWQgYnkgZW5m
b3JjaW5nIGEgTkFUIHBvcnQgb3ZlcmxvYWRpbmcNCiAgICAgIG1vZGUgYW5kIGFzIGEgY29uc2Vx
dWVuY2Ugc29tZSBhcHBsaWNhdGlvbnMgd2lsbCBicmVhay4NCg0KICAgSG93ZXZlciwgYXMgbW9y
ZSBhbmQgbW9yZSBob3N0cyBiZWNvbWUgZHVhbC1zdGFjayBlbmFibGVkLCB0aGUgbmVlZA0KICAg
Zm9yIHBvcnRzIGluIElQdjQgaXMgbGlrZWx5IHRvIGRlY3JlYXNlLiAgVGhlIGluc3VyYW5jZSB0
byBoYXZlIHRoZQ0KICAgZnVsbCBzZXQgb2YgNjRLIHBvcnRzIHBlciBob3N0IHdpbGwgYmUgb25l
IG9mIHRoZSBpbmNlbnRpdmVzIHRvIGhhdmUNCiAgIHRoZW0gSVB2NiBjYXBhYmxlLiAgTW9yZW92
ZXIsIFNlcnZpY2UgUHJvdmlkZXJzIHNob3VsZCBvZmZsb2FkIHNvbWUNCiAgIHNlcnZpY2VzIHRv
IElQdjYgKGUuZy4sIEROUywgVm9JUCkuIg0KDQoNCg0KDQo=

From washam.fan@gmail.com  Tue Aug 16 07:05:32 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D022A21F8B26 for ; Tue, 16 Aug 2011 07:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.338
X-Spam-Level: 
X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYCe6MwS+7oe for ; Tue, 16 Aug 2011 07:05:32 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA8D921F8B37 for ; Tue, 16 Aug 2011 07:05:31 -0700 (PDT)
Received: by wyg8 with SMTP id 8so112374wyg.31 for ; Tue, 16 Aug 2011 07:06:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eruuA8kF7bWUEYclyz5zHILyPfYjEifHX3SkXL13XRQ=; b=XJk28L0cUZyWfej1bXYaxrmtix5Gy8yCA/xw3QB+eojV1cP1oLXgLpwmXLUH32wnpZ o1MAeXGyWNOlrWCdWLnJI4l+ouRWEihUREOWV4eHhKRkXQy4fzvlxlMtG7Rzus4JgaJZ rLvc/IBACmGOF0hj65r1Zaj2cEuyKcAf7f9mc=
MIME-Version: 1.0
Received: by 10.216.131.134 with SMTP id m6mr3872372wei.78.1313503579668; Tue, 16 Aug 2011 07:06:19 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Tue, 16 Aug 2011 07:06:19 -0700 (PDT)
In-Reply-To: <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net>
Date: Tue, 16 Aug 2011 22:06:19 +0800
Message-ID: 
From: Washam Fan 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 14:05:32 -0000

Hi,

2011/8/16 R=E9mi Despr=E9s :
> Hi Tetsuya-san,
>
> I agree, of course, on the need to support several mapping rules.

Is there anywhere in the draft to mention how to deliver these rules?
As my understanding, the provisions described in section 4 only can
generate a mapping rule, how about deliver multiple mapping rules.

> But IMHO one point needs clarification (see below).
>
>
> Le 16 ao=FBt 2011 =E0 02:03, Tetsuya Murakami a =E9crit :
>
>> Hi Washam,
>>
>> We can allow to use multiple mapping rules in a 4rd domain.
> ...
>> When delegating an IPv6 prefix from the network, the corresponding mappi=
ng rule whose domain ipv6 prefix has the longest match with the delegated i=
pv6 prefix, can be selected.
>
> As already discussed privately, I don't know realistic cases where two ru=
les would have IPv6 or IPv4 overlapping prefixes.
> Consequently, it seems that "longest" match, while being permitted, doesn=
't need to be a requirement.

Have the same feeling, ipv4 prefixes/addresses/port-set don't overlap,
per my understanding.

Thanks,
washam
> Would you have such use cases to share?
>
> Regards,
> RD
>
>>
>> Also, when forwarding an IPv4 packet to another CE, the corresponding ma=
pping rule whose domain 4rd prefix has the longest match with the the desti=
nation ipv4 address, can be selected.
>>
>> It is stated in section 5.1.1 and section 7 a little bit in the draft.
>>
>> Thanks,
>> Tetsuya Murakami
>>
>> On 2011/08/14, at 5:52, Washam Fan wrote:
>>
>>> Hi,
>>>
>>> It seems to me only one domain IPv6 prefix is allowed, per
>>> draft-murakami-softwire-4rd-00. But I see no issue if we allow
>>> multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a
>>> outbound IPv4 package, the matched rule can tell which domain ipv6
>>> prefix can be used for building outer IPv6 destination address.
>>>
>>> Thanks,
>>> washam
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
>
>

From despres.remi@laposte.net  Tue Aug 16 07:20:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41EE21F888A for ; Tue, 16 Aug 2011 07:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.931
X-Spam-Level: 
X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02BKcaNUU-zA for ; Tue, 16 Aug 2011 07:20:44 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id BF49F21F8B65 for ; Tue, 16 Aug 2011 07:20:43 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 405D67000223; Tue, 16 Aug 2011 16:21:31 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 093FB7000221; Tue, 16 Aug 2011 16:21:26 +0200 (CEST)
X-SFR-UUID: 20110816142127379.093FB7000221@msfrf2217.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Tue, 16 Aug 2011 16:21:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> 
To: Washam Fan 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 14:20:45 -0000

Le 16 ao=FBt 2011 =E0 16:06, Washam Fan a =E9crit :

> Hi,
>=20
> 2011/8/16 R=E9mi Despr=E9s :
>> Hi Tetsuya-san,
>>=20
>> I agree, of course, on the need to support several mapping rules.
>=20
> Is there anywhere in the draft to mention how to deliver these rules?

You can look at draft-mrugalski-dhc-dhcpv6-4rd-00.
Some update will be necessary, AFAIK, but this gives an idea of what can =
be done once parameters are agreed on.
=20
> As my understanding, the provisions described in section 4 only can
> generate a mapping rule, how about deliver multiple mapping rules.
>=20
>> But IMHO one point needs clarification (see below).
>>=20
>>=20
>> Le 16 ao=FBt 2011 =E0 02:03, Tetsuya Murakami a =E9crit :
>>=20
>>> Hi Washam,
>>>=20
>>> We can allow to use multiple mapping rules in a 4rd domain.
>> ...
>>> When delegating an IPv6 prefix from the network, the corresponding =
mapping rule whose domain ipv6 prefix has the longest match with the =
delegated ipv6 prefix, can be selected.
>>=20
>> As already discussed privately, I don't know realistic cases where =
two rules would have IPv6 or IPv4 overlapping prefixes.
>> Consequently, it seems that "longest" match, while being permitted, =
doesn't need to be a requirement.
>=20
> Have the same feeling, ipv4 prefixes/addresses/port-set don't overlap,
> per my understanding.

Thanks,
RD



From despres.remi@laposte.net  Tue Aug 16 07:29:06 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EC821F8BA9 for ; Tue, 16 Aug 2011 07:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level: 
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb-HLbGOG2r5 for ; Tue, 16 Aug 2011 07:29:05 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 22A4D21F8BA6 for ; Tue, 16 Aug 2011 07:29:04 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 973057000076; Tue, 16 Aug 2011 16:29:52 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id E52FC70001E9; Tue, 16 Aug 2011 16:29:47 +0200 (CEST)
X-SFR-UUID: 20110816142947938.E52FC70001E9@msfrf2217.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr>
Date: Tue, 16 Aug 2011 16:29:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net>
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr>
To:  
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 14:29:06 -0000

Hi Med,

At the last meeting, a vote was taken to decide whether this draft =
should become a WG draft.
The answer has been a crystal clear yes, with the common understanding =
that, as such, it would have to be improved and competed based on WG =
reactions.

IMHO, making it a WG document asap will facilitate discussions like this =
one: thet will point to the right document.

Is there any sort term plan to do what was approved?

Kind regards,
RD




Le 16 ao=FBt 2011 =E0 13:48,  =
 a =E9crit :

> Dear Nejc,
>=20
> Thank you for the comments. Please see my answers inline.
>=20
> Cheers,
> Med
>=20
>=20
> -----Message d'origine-----
> De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De =
la part de Nejc =8Akoberne
> Envoy=E9 : mardi 16 ao=FBt 2011 12:25
> =C0 : draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
> Cc : softwires@ietf.org
> Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation
>=20
> Hello,
>=20
> I have some comments on your draft, see inline.
>=20
> Regards,
> Nejc
>=20
> ---------------
>   2. Terminology
>=20
>=20
>=20
>   This document makes use of the following terms:
>=20
>   Stateful 4/6 solution  (or stateful solution in short): denotes a
>                       solution where the network maintains =
user-session
>                       states relying on the activation of a NAT
>                       function in the Service Providers' network
>                       [I-D.ietf-behave-lsn-requirements].  The NAT
>                       function is responsible for sharing the same =
IPv4
>                       address among several subscribers and to =
maintain
>                       user-session state.
>=20
>   Stateless  4/6 solution  (or stateless solution in short): denotes a
>                       solution which does not require any user-session
>                       state (seeSection 2.3 of [RFC1958]) to be
>                       maintained by any IP address sharing function in
>                       the Service Provider's network.  This category =
of
>                       solutions assumes a dependency between an IPv6
>                       prefix and IPv4 address.  In an IPv4 address
>                       sharing context, dedicated functions are =
required
>                       to be enabled in the CPE router to restrict the
>                       source IPv4 port numbers.  Within this document,
>                       "port set" and "port range" terms are used
>                       interchangeably.
>=20
> [NS: If we consider a "stateful A+P" solution, we don't necessarily
> have a dependency between an IPv6 prefix and IPv4 address. Also, we
> don't have any user-session state in the Service Provider's network.
>=20
> Med: Fully agree. FWIW, this is what we called "Binding Table A+P =
Mode" in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4.
>=20
> We do, however, have some user state (in order to do stateful =
tunneling,
> for example). Maybe this is included in "user-session" in your
> terminology, but then I think it would be appropriate to define the
> term "user-session" clearly.]
>=20
> Med: We assumed the definition of state as mentioned in RFC1958; but I =
agree the terminology should be much more clearer.
>=20
> ...
>=20
>       3.1.5. Bandwidth Saving
>=20
>=20
>=20
>   In same particular network scenarios (e.g., wireless network ),
>   spectrum is very valuable and scarce resource.  Service providers
>   usually wish to eliminate unnecessary overhead to save bandwidth
>   consumption in such environment.  Service providers need to consider
>   optimizing the form of packet processing when encapsulation is used.
>   Since existing header compression techniques are stateful, it is
>   expected that stateless solution minimize overhead introduced by the
>   solution.
>=20
> [NS: I don't understand this section, but that may be just me.
> Maybe is there a better way to explain the point?]
>=20
> Med: We have several co-authors who are not either in favour or =
maintaining this section. This text will be removed.
>=20
> ...
>=20
>=20
>       3.3.1. Implicit Host Identification
>=20
>=20
>=20
>   Service Providers do not offer only IP connectivity services but =
also
>   added value services (a.k.a., internal services).  Upgrading these
>   services to be IPv6-enabled is not sufficient because of legacy
>   devices.  In some deployments, the delivery of these added-value
>   services relies on implicit identification mechanism based on the
>   source IPv4 address.  Due to address sharing, implicit =
identification
>   will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing
>   implicit identification with explicit authentication will be seen as
>   a non acceptable service regression by the end users (less Quality =
of
>   Experience (QoE)).
>=20
>   When a stateless solution is deployed, implicit identification for
>   internal services is likely to be easier to implement: the implicit
>   identification should be updated to take into account the port range
>   and the IPv4 address.  Techniques as those analyzed in
>   [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the
>   delivery of these internal services if a stateless solution is
>   deployed.
>=20
> [NS: I don't think this is true only for stateless
> solutions. If we have a stateful solution with static port allocation
> (as you mention in section 3.1.3), then implementing such an implicit
> host identification which uses also port information, is doable as
> well.]
>=20
> Med: I Agree. But then you loose other benefits of the stateful: have =
an aggressive address sharing ratio.
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires



From mohamed.boucadair@orange-ftgroup.com  Tue Aug 16 08:02:18 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BAA21F8B25 for ; Tue, 16 Aug 2011 08:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hijsWZfg+hpv for ; Tue, 16 Aug 2011 08:02:17 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id E257121F8B15 for ; Tue, 16 Aug 2011 08:02:16 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 5309A2AC701; Tue, 16 Aug 2011 17:03:04 +0200 (CEST)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 3973EC806C; Tue, 16 Aug 2011 17:03:04 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 16 Aug 2011 17:03:04 +0200
From: 
To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= 
Date: Tue, 16 Aug 2011 17:03:02 +0200
Thread-Topic: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Thread-Index: AcxcIPbl6WA9XklfRFuvtsag14ifDQAAMvkg
Message-ID: <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net>
In-Reply-To: <1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.16.135415
Cc: "softwires@ietf.org" , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 15:02:18 -0000

SGkgUsOpbWksDQoNClllcywgdGhlcmUgd2FzIGEgdm90ZSBpbiBmYXZvdXIgb2YgYWRvcHRpbmcg
dGhpcyBkb2N1bWVudCBhcyBhIFdHIGRvY3VtZW50IGJ1dCBhcyB5b3Uga25vdyB0aGlzIHZvdGUg
c2hvdWxkIGJlIGNvbmZpcm1lZCBpbiB0aGUgTUwuIEEgY2FsbCBmb3IgYWRvcHRpb24gc2hvdWxk
IG5vcm1hbGx5IGJlIGlzc3VlZCBieSB0aGUgY2hhaXJzIGFjY29yZGluZyB0byB0aGUgSUVURiBw
cm9jZWR1cmUuDQoNCkFzIGZvciB0aGUgY29udGVudCBvZiB0aGUgbmV4dCBpdGVyYXRpb24gb2Yg
dGhlIGRvY3VtZW50LCB3ZSBoYXZlIHR3byBvcHRpb25zIHNvIGZhcjoNCg0KKDEpIFB1dCBiYWNr
IHNvbWUgc2VjdGlvbnMgd2hpY2ggaGF2ZSBiZWVuIHJlbW92ZWQgaW4gLTAyLCBhZGQgYSBuZXcg
c2VjdGlvbiB0byBkaXNjdXNzIGR5bmFtaWMgdnMuIHN0YXRpYywgaGFuZGxlIHRoZSBjb21tZW50
cyByZWNlaXZlZCBmcm9tIEouIEFya2tvLCBldGMuIA0KDQpPciANCg0KMikgQW4gYWx0ZXJuYXRp
dmUgc3RydWN0dXJlIGhhcyBiZWVuIHByb3Bvc2VkIG9mZi1saW5lIGJ5IEEuIER1cmFuZDogZGlz
Y3VzcyBkeW5hbWljIHZzLiBzdGF0aWMgYW5kIHN0YXRlZnVsIHZzLiBkeW5hbWljLiBUaGUgYW5h
bHlzaXMgd291bGQgZWxhYm9yYXRlIHRoZSBwcm9zIGFuZCBjb25zIG9mIGVhY2ggc29sdXRpb24g
KHN0YXRpYyBzdGF0ZWxlc3MsIHN0YXRpYyBzdGF0ZWZ1bCwgZHluYW1pYyBzdGF0ZWZ1bCwuLi4p
LiBUaGlzIGRvY3VtZW50IHdvdWxkIGJlIGFuIGFuYWx5c2lzIGRvY3VtZW50IGFuZCBub3QgYSBt
b3RpdmF0aW9uIGRvY3VtZW50IGFueW1vcmUuIFRoaXMgZG9jdW1lbnQgaGFzIG5vIG1pbGVzdG9u
ZSBpbiB0aGUgY2hhcnRlciBJTUhPLiBOb3RlIHRoZSBjaGFydGVyIG1lbnRpb25zIHRoZSBmb2xs
b3dpbmc6IA0KDQoiQXVnIDIwMTEgLSBBZG9wdCBzdGF0ZWxlc3MgbGVnYWN5IElQdjQgc29sdXRp
b24gbW90aXZhdGlvbiBkb2N1bWVudCBhcyBhIFdvcmtpbmcgR3JvdXAgZG9jdW1lbnQiDQoNCg0K
SSBwZXJzb25hbGx5IHRoaW5rIHRoZSBmaXJzdCBvcHRpb24gaXMgc3RyYWlnaHRmb3J3YXJkIGJ1
dCBJJ20gb3BlbiB0byB0aGUgb3BpbmlvbnMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgbWVtYmVycyBv
biBob3cgdG8gcHJvY2VlZC4NCg0KQ2hlZXJzLA0KTWVkDQogDQoNCi0tLS0tTWVzc2FnZSBkJ29y
aWdpbmUtLS0tLQ0KRGUgOiBSw6ltaSBEZXNwcsOpcyBbbWFpbHRvOmRlc3ByZXMucmVtaUBsYXBv
c3RlLm5ldF0gDQpFbnZvecOpIDogbWFyZGkgMTYgYW/Du3QgMjAxMSAxNjozMA0Kw4AgOiBCT1VD
QURBSVIgTW9oYW1lZCBPTE5DL05BRC9USVANCkNjIDogTmVqYyDFoGtvYmVybmU7IGRyYWZ0LW9w
ZXJhdG9ycy1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb25AdG9vbHMuaWV0Zi5vcmc7
IHNvZnR3aXJlc0BpZXRmLm9yZw0KT2JqZXQgOiBSZTogW1NvZnR3aXJlc10gZHJhZnQtb3BlcmF0
b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlvbg0KDQpIaSBNZWQsDQoNCkF0IHRo
ZSBsYXN0IG1lZXRpbmcsIGEgdm90ZSB3YXMgdGFrZW4gdG8gZGVjaWRlIHdoZXRoZXIgdGhpcyBk
cmFmdCBzaG91bGQgYmVjb21lIGEgV0cgZHJhZnQuDQpUaGUgYW5zd2VyIGhhcyBiZWVuIGEgY3J5
c3RhbCBjbGVhciB5ZXMsIHdpdGggdGhlIGNvbW1vbiB1bmRlcnN0YW5kaW5nIHRoYXQsIGFzIHN1
Y2gsIGl0IHdvdWxkIGhhdmUgdG8gYmUgaW1wcm92ZWQgYW5kIGNvbXBldGVkIGJhc2VkIG9uIFdH
IHJlYWN0aW9ucy4NCg0KSU1ITywgbWFraW5nIGl0IGEgV0cgZG9jdW1lbnQgYXNhcCB3aWxsIGZh
Y2lsaXRhdGUgZGlzY3Vzc2lvbnMgbGlrZSB0aGlzIG9uZTogdGhldCB3aWxsIHBvaW50IHRvIHRo
ZSByaWdodCBkb2N1bWVudC4NCg0KSXMgdGhlcmUgYW55IHNvcnQgdGVybSBwbGFuIHRvIGRvIHdo
YXQgd2FzIGFwcHJvdmVkPw0KDQpLaW5kIHJlZ2FyZHMsDQpSRA0KDQoNCg0KDQpMZSAxNiBhb8O7
dCAyMDExIMOgIDEzOjQ4LCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLWZ0Z3JvdXAuY29tPiA8
bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLWZ0Z3JvdXAuY29tPiBhIMOpY3JpdCA6DQoNCj4gRGVh
ciBOZWpjLA0KPiANCj4gVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkg
YW5zd2VycyBpbmxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gDQo+IC0tLS0tTWVz
c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFtt
YWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmVqYyDFoGtv
YmVybmUNCj4gRW52b3nDqSA6IG1hcmRpIDE2IGFvw7t0IDIwMTEgMTI6MjUNCj4gw4AgOiBkcmFm
dC1vcGVyYXRvcnMtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uQHRvb2xzLmlldGYu
b3JnDQo+IENjIDogc29mdHdpcmVzQGlldGYub3JnDQo+IE9iamV0IDogW1NvZnR3aXJlc10gZHJh
ZnQtb3BlcmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlvbg0KPiANCj4gSGVs
bG8sDQo+IA0KPiBJIGhhdmUgc29tZSBjb21tZW50cyBvbiB5b3VyIGRyYWZ0LCBzZWUgaW5saW5l
Lg0KPiANCj4gUmVnYXJkcywNCj4gTmVqYw0KPiANCj4gLS0tLS0tLS0tLS0tLS0tDQo+ICAgMi4g
VGVybWlub2xvZ3kNCj4gDQo+IA0KPiANCj4gICBUaGlzIGRvY3VtZW50IG1ha2VzIHVzZSBvZiB0
aGUgZm9sbG93aW5nIHRlcm1zOg0KPiANCj4gICBTdGF0ZWZ1bCA0LzYgc29sdXRpb24gIChvciBz
dGF0ZWZ1bCBzb2x1dGlvbiBpbiBzaG9ydCk6IGRlbm90ZXMgYQ0KPiAgICAgICAgICAgICAgICAg
ICAgICAgc29sdXRpb24gd2hlcmUgdGhlIG5ldHdvcmsgbWFpbnRhaW5zIHVzZXItc2Vzc2lvbg0K
PiAgICAgICAgICAgICAgICAgICAgICAgc3RhdGVzIHJlbHlpbmcgb24gdGhlIGFjdGl2YXRpb24g
b2YgYSBOQVQNCj4gICAgICAgICAgICAgICAgICAgICAgIGZ1bmN0aW9uIGluIHRoZSBTZXJ2aWNl
IFByb3ZpZGVycycgbmV0d29yaw0KPiAgICAgICAgICAgICAgICAgICAgICAgW0ktRC5pZXRmLWJl
aGF2ZS1sc24tcmVxdWlyZW1lbnRzXS4gIFRoZSBOQVQNCj4gICAgICAgICAgICAgICAgICAgICAg
IGZ1bmN0aW9uIGlzIHJlc3BvbnNpYmxlIGZvciBzaGFyaW5nIHRoZSBzYW1lIElQdjQNCj4gICAg
ICAgICAgICAgICAgICAgICAgIGFkZHJlc3MgYW1vbmcgc2V2ZXJhbCBzdWJzY3JpYmVycyBhbmQg
dG8gbWFpbnRhaW4NCj4gICAgICAgICAgICAgICAgICAgICAgIHVzZXItc2Vzc2lvbiBzdGF0ZS4N
Cj4gDQo+ICAgU3RhdGVsZXNzICA0LzYgc29sdXRpb24gIChvciBzdGF0ZWxlc3Mgc29sdXRpb24g
aW4gc2hvcnQpOiBkZW5vdGVzIGENCj4gICAgICAgICAgICAgICAgICAgICAgIHNvbHV0aW9uIHdo
aWNoIGRvZXMgbm90IHJlcXVpcmUgYW55IHVzZXItc2Vzc2lvbg0KPiAgICAgICAgICAgICAgICAg
ICAgICAgc3RhdGUgKHNlZVNlY3Rpb24gMi4zIG9mIFtSRkMxOTU4XSkgdG8gYmUNCj4gICAgICAg
ICAgICAgICAgICAgICAgIG1haW50YWluZWQgYnkgYW55IElQIGFkZHJlc3Mgc2hhcmluZyBmdW5j
dGlvbiBpbg0KPiAgICAgICAgICAgICAgICAgICAgICAgdGhlIFNlcnZpY2UgUHJvdmlkZXIncyBu
ZXR3b3JrLiAgVGhpcyBjYXRlZ29yeSBvZg0KPiAgICAgICAgICAgICAgICAgICAgICAgc29sdXRp
b25zIGFzc3VtZXMgYSBkZXBlbmRlbmN5IGJldHdlZW4gYW4gSVB2Ng0KPiAgICAgICAgICAgICAg
ICAgICAgICAgcHJlZml4IGFuZCBJUHY0IGFkZHJlc3MuICBJbiBhbiBJUHY0IGFkZHJlc3MNCj4g
ICAgICAgICAgICAgICAgICAgICAgIHNoYXJpbmcgY29udGV4dCwgZGVkaWNhdGVkIGZ1bmN0aW9u
cyBhcmUgcmVxdWlyZWQNCj4gICAgICAgICAgICAgICAgICAgICAgIHRvIGJlIGVuYWJsZWQgaW4g
dGhlIENQRSByb3V0ZXIgdG8gcmVzdHJpY3QgdGhlDQo+ICAgICAgICAgICAgICAgICAgICAgICBz
b3VyY2UgSVB2NCBwb3J0IG51bWJlcnMuICBXaXRoaW4gdGhpcyBkb2N1bWVudCwNCj4gICAgICAg
ICAgICAgICAgICAgICAgICJwb3J0IHNldCIgYW5kICJwb3J0IHJhbmdlIiB0ZXJtcyBhcmUgdXNl
ZA0KPiAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJjaGFuZ2VhYmx5Lg0KPiANCj4gW05TOiBJ
ZiB3ZSBjb25zaWRlciBhICJzdGF0ZWZ1bCBBK1AiIHNvbHV0aW9uLCB3ZSBkb24ndCBuZWNlc3Nh
cmlseQ0KPiBoYXZlIGEgZGVwZW5kZW5jeSBiZXR3ZWVuIGFuIElQdjYgcHJlZml4IGFuZCBJUHY0
IGFkZHJlc3MuIEFsc28sIHdlDQo+IGRvbid0IGhhdmUgYW55IHVzZXItc2Vzc2lvbiBzdGF0ZSBp
biB0aGUgU2VydmljZSBQcm92aWRlcidzIG5ldHdvcmsuDQo+IA0KPiBNZWQ6IEZ1bGx5IGFncmVl
LiBGV0lXLCB0aGlzIGlzIHdoYXQgd2UgY2FsbGVkICJCaW5kaW5nIFRhYmxlIEErUCBNb2RlIiBp
biBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15bWJrLWFwbHVzcC0xMCNzZWN0aW9u
LTQuNC4NCj4gDQo+IFdlIGRvLCBob3dldmVyLCBoYXZlIHNvbWUgdXNlciBzdGF0ZSAoaW4gb3Jk
ZXIgdG8gZG8gc3RhdGVmdWwgdHVubmVsaW5nLA0KPiBmb3IgZXhhbXBsZSkuIE1heWJlIHRoaXMg
aXMgaW5jbHVkZWQgaW4gInVzZXItc2Vzc2lvbiIgaW4geW91cg0KPiB0ZXJtaW5vbG9neSwgYnV0
IHRoZW4gSSB0aGluayBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBkZWZpbmUgdGhlDQo+IHRl
cm0gInVzZXItc2Vzc2lvbiIgY2xlYXJseS5dDQo+IA0KPiBNZWQ6IFdlIGFzc3VtZWQgdGhlIGRl
ZmluaXRpb24gb2Ygc3RhdGUgYXMgbWVudGlvbmVkIGluIFJGQzE5NTg7IGJ1dCBJIGFncmVlIHRo
ZSB0ZXJtaW5vbG9neSBzaG91bGQgYmUgbXVjaCBtb3JlIGNsZWFyZXIuDQo+IA0KPiAuLi4NCj4g
DQo+ICAgICAgIDMuMS41LiBCYW5kd2lkdGggU2F2aW5nDQo+IA0KPiANCj4gDQo+ICAgSW4gc2Ft
ZSBwYXJ0aWN1bGFyIG5ldHdvcmsgc2NlbmFyaW9zIChlLmcuLCB3aXJlbGVzcyBuZXR3b3JrICks
DQo+ICAgc3BlY3RydW0gaXMgdmVyeSB2YWx1YWJsZSBhbmQgc2NhcmNlIHJlc291cmNlLiAgU2Vy
dmljZSBwcm92aWRlcnMNCj4gICB1c3VhbGx5IHdpc2ggdG8gZWxpbWluYXRlIHVubmVjZXNzYXJ5
IG92ZXJoZWFkIHRvIHNhdmUgYmFuZHdpZHRoDQo+ICAgY29uc3VtcHRpb24gaW4gc3VjaCBlbnZp
cm9ubWVudC4gIFNlcnZpY2UgcHJvdmlkZXJzIG5lZWQgdG8gY29uc2lkZXINCj4gICBvcHRpbWl6
aW5nIHRoZSBmb3JtIG9mIHBhY2tldCBwcm9jZXNzaW5nIHdoZW4gZW5jYXBzdWxhdGlvbiBpcyB1
c2VkLg0KPiAgIFNpbmNlIGV4aXN0aW5nIGhlYWRlciBjb21wcmVzc2lvbiB0ZWNobmlxdWVzIGFy
ZSBzdGF0ZWZ1bCwgaXQgaXMNCj4gICBleHBlY3RlZCB0aGF0IHN0YXRlbGVzcyBzb2x1dGlvbiBt
aW5pbWl6ZSBvdmVyaGVhZCBpbnRyb2R1Y2VkIGJ5IHRoZQ0KPiAgIHNvbHV0aW9uLg0KPiANCj4g
W05TOiBJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBzZWN0aW9uLCBidXQgdGhhdCBtYXkgYmUganVz
dCBtZS4NCj4gTWF5YmUgaXMgdGhlcmUgYSBiZXR0ZXIgd2F5IHRvIGV4cGxhaW4gdGhlIHBvaW50
P10NCj4gDQo+IE1lZDogV2UgaGF2ZSBzZXZlcmFsIGNvLWF1dGhvcnMgd2hvIGFyZSBub3QgZWl0
aGVyIGluIGZhdm91ciBvciBtYWludGFpbmluZyB0aGlzIHNlY3Rpb24uIFRoaXMgdGV4dCB3aWxs
IGJlIHJlbW92ZWQuDQo+IA0KPiAuLi4NCj4gDQo+IA0KPiAgICAgICAzLjMuMS4gSW1wbGljaXQg
SG9zdCBJZGVudGlmaWNhdGlvbg0KPiANCj4gDQo+IA0KPiAgIFNlcnZpY2UgUHJvdmlkZXJzIGRv
IG5vdCBvZmZlciBvbmx5IElQIGNvbm5lY3Rpdml0eSBzZXJ2aWNlcyBidXQgYWxzbw0KPiAgIGFk
ZGVkIHZhbHVlIHNlcnZpY2VzIChhLmsuYS4sIGludGVybmFsIHNlcnZpY2VzKS4gIFVwZ3JhZGlu
ZyB0aGVzZQ0KPiAgIHNlcnZpY2VzIHRvIGJlIElQdjYtZW5hYmxlZCBpcyBub3Qgc3VmZmljaWVu
dCBiZWNhdXNlIG9mIGxlZ2FjeQ0KPiAgIGRldmljZXMuICBJbiBzb21lIGRlcGxveW1lbnRzLCB0
aGUgZGVsaXZlcnkgb2YgdGhlc2UgYWRkZWQtdmFsdWUNCj4gICBzZXJ2aWNlcyByZWxpZXMgb24g
aW1wbGljaXQgaWRlbnRpZmljYXRpb24gbWVjaGFuaXNtIGJhc2VkIG9uIHRoZQ0KPiAgIHNvdXJj
ZSBJUHY0IGFkZHJlc3MuICBEdWUgdG8gYWRkcmVzcyBzaGFyaW5nLCBpbXBsaWNpdCBpZGVudGlm
aWNhdGlvbg0KPiAgIHdpbGwgZmFpbCBbSS1ELmlldGYtaW50YXJlYS1zaGFyZWQtYWRkcmVzc2lu
Zy1pc3N1ZXNdOyByZXBsYWNpbmcNCj4gICBpbXBsaWNpdCBpZGVudGlmaWNhdGlvbiB3aXRoIGV4
cGxpY2l0IGF1dGhlbnRpY2F0aW9uIHdpbGwgYmUgc2VlbiBhcw0KPiAgIGEgbm9uIGFjY2VwdGFi
bGUgc2VydmljZSByZWdyZXNzaW9uIGJ5IHRoZSBlbmQgdXNlcnMgKGxlc3MgUXVhbGl0eSBvZg0K
PiAgIEV4cGVyaWVuY2UgKFFvRSkpLg0KPiANCj4gICBXaGVuIGEgc3RhdGVsZXNzIHNvbHV0aW9u
IGlzIGRlcGxveWVkLCBpbXBsaWNpdCBpZGVudGlmaWNhdGlvbiBmb3INCj4gICBpbnRlcm5hbCBz
ZXJ2aWNlcyBpcyBsaWtlbHkgdG8gYmUgZWFzaWVyIHRvIGltcGxlbWVudDogdGhlIGltcGxpY2l0
DQo+ICAgaWRlbnRpZmljYXRpb24gc2hvdWxkIGJlIHVwZGF0ZWQgdG8gdGFrZSBpbnRvIGFjY291
bnQgdGhlIHBvcnQgcmFuZ2UNCj4gICBhbmQgdGhlIElQdjQgYWRkcmVzcy4gIFRlY2huaXF1ZXMg
YXMgdGhvc2UgYW5hbHl6ZWQgaW4NCj4gICBbSS1ELmJvdWNhZGFpci1pbnRhcmVhLW5hdC1yZXZl
YWwtYW5hbHlzaXNdIGFyZSBub3QgcmVxdWlyZWQgZm9yIHRoZQ0KPiAgIGRlbGl2ZXJ5IG9mIHRo
ZXNlIGludGVybmFsIHNlcnZpY2VzIGlmIGEgc3RhdGVsZXNzIHNvbHV0aW9uIGlzDQo+ICAgZGVw
bG95ZWQuDQo+IA0KPiBbTlM6IEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyB0cnVlIG9ubHkgZm9yIHN0
YXRlbGVzcw0KPiBzb2x1dGlvbnMuIElmIHdlIGhhdmUgYSBzdGF0ZWZ1bCBzb2x1dGlvbiB3aXRo
IHN0YXRpYyBwb3J0IGFsbG9jYXRpb24NCj4gKGFzIHlvdSBtZW50aW9uIGluIHNlY3Rpb24gMy4x
LjMpLCB0aGVuIGltcGxlbWVudGluZyBzdWNoIGFuIGltcGxpY2l0DQo+IGhvc3QgaWRlbnRpZmlj
YXRpb24gd2hpY2ggdXNlcyBhbHNvIHBvcnQgaW5mb3JtYXRpb24sIGlzIGRvYWJsZSBhcw0KPiB3
ZWxsLl0NCj4gDQo+IE1lZDogSSBBZ3JlZS4gQnV0IHRoZW4geW91IGxvb3NlIG90aGVyIGJlbmVm
aXRzIG9mIHRoZSBzdGF0ZWZ1bDogaGF2ZSBhbiBhZ2dyZXNzaXZlIGFkZHJlc3Mgc2hhcmluZyBy
YXRpby4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KDQo=

From simon.perreault@viagenie.ca  Tue Aug 16 08:27:09 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A10A21F8754 for ; Tue, 16 Aug 2011 08:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level: 
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMr-TQ0TvGAu for ; Tue, 16 Aug 2011 08:27:08 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B303C21F871C for ; Tue, 16 Aug 2011 08:27:08 -0700 (PDT)
Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 00C2B21F52 for ; Tue, 16 Aug 2011 11:27:56 -0400 (EDT)
Message-ID: <4E4A8C7C.1070705@viagenie.ca>
Date: Tue, 16 Aug 2011 11:27:56 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net> <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 15:27:09 -0000

mohamed.boucadair@orange-ftgroup.com wrote, on 08/16/2011 11:03 AM:
> As for the content of the next iteration of the document, we have two options
> so far:
> 
> (1) Put back some sections which have been removed in -02, add a new section
> to discuss dynamic vs. static, handle the comments received from J. Arkko,
> etc.
> 
> Or
> 
> 2) An alternative structure has been proposed off-line by A. Durand: discuss
> dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the
> pros and cons of each solution (static stateless, static stateful, dynamic
> stateful,...). This document would be an analysis document and not a
> motivation document anymore. This document has no milestone in the charter
> IMHO. Note the charter mentions the following:
> 
> "Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a
> Working Group document"
> 
> 
> I personally think the first option is straightforward but I'm open to the
> opinions of the working group members on how to proceed.

For me, the first option makes more sense.

I also support adoption of this document and am expecting an adoption call soon.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From nejc@skoberne.net  Tue Aug 16 08:52:11 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5338021F8888 for ; Tue, 16 Aug 2011 08:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level: 
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y+liEOnY2aI for ; Tue, 16 Aug 2011 08:52:10 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id B639021F8862 for ; Tue, 16 Aug 2011 08:52:10 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 8E30E22780EE; Tue, 16 Aug 2011 17:52:58 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyvKDsLEm7dZ; Tue, 16 Aug 2011 17:52:58 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 37D1B22780D2; Tue, 16 Aug 2011 17:52:58 +0200 (CEST)
Message-ID: <4E4A925D.2000000@skoberne.net>
Date: Tue, 16 Aug 2011 16:53:01 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Naoki Matsuhira 
References: <6D93B4F87F5667499B9104BA798D637A046A13F2@STAFFMBX-1.lunet.lboro.ac.uk> <6D93B4F87F5667499B9104BA798D637A0C5FE3B25F@STAFFMBX-1.lunet.lboro.ac.uk> <4E49228F.2040705@skoberne.net> <4E4A17CD.8030807@jp.fujitsu.com>
In-Reply-To: <4E4A17CD.8030807@jp.fujitsu.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] SA46T questions
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 15:52:11 -0000

Dear Naoki,

> Number of ports can be selected by prefix length.

I see.

So essentially, SA46T-AS is like 4rd, but with a different port-allocation 
scheme. Also the "IPv4 plane" feature (you also call it "IPv4 VPN service")
can be seen as a variant of multiple 4rd domains in 4rd context.

Do you agree? If this is so, I don't really see why would we need a separate
specification for this? I mean, we could also define various port-allocation
schemes in the 4rd draft (as in RFC 6056, where we have various port
randomization algorithms available for implementation).

Thanks,
Nejc

From despres.remi@laposte.net  Tue Aug 16 09:27:51 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E5321F8B8E for ; Tue, 16 Aug 2011 09:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zYpOiG5XCeb for ; Tue, 16 Aug 2011 09:27:50 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 18C2121F8B7A for ; Tue, 16 Aug 2011 09:27:49 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id B72CA70007BE; Tue, 16 Aug 2011 18:28:36 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id B8EBE700128D; Tue, 16 Aug 2011 18:28:29 +0200 (CEST)
X-SFR-UUID: 20110816162831757.B8EBE700128D@msfrf2212.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
Date: Tue, 16 Aug 2011 18:28:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7998F52F-58E8-4E7D-8327-D64666AF7EFE@laposte.net>
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net> <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
To: Softwires-wg 
X-Mailer: Apple Mail (2.1084)
Cc: draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 16:27:51 -0000

Hello all,

It appears that confirming on this list the vote made in Quebec would be =
useful.
Please see below.

Le 16 ao=FBt 2011 =E0 17:03,  =
 a =E9crit :

>  ... there was a vote in favour of adopting this document as a WG =
document but as you know this vote should be confirmed in the ML.

I have seen drafts becoming WG drafts after votes during meetings but, =
fair enough, let's see if, after the unanimous vote in the meeting, =
there are serious objections to it now.=20


> A call for adoption should normally be issued by the chairs according =
to the IETF procedure.
>=20
> As for the content of the next iteration of the document, we have two =
options so far:
>=20
> (1) Put back some sections which have been removed in -02,

Support.
Some of them were worth having, IMHO.

> add a new section to discuss dynamic vs. static,

> handle the comments received from J. Arkko, etc.=20

Sure.
Doing this while the draft is already a WG draft seems to me normal =
after the vote result (but no objection to doing it right away if found =
better. =20

> Or=20
>=20
> 2) An alternative structure has been proposed off-line by A. Durand: =
discuss dynamic vs. static and stateful vs. dynamic.

Offline discussions are of course completely free, and useful, but a WG =
consensus can only be built in the open, i.e. on the WG mailing list.
I am aware of at least part of the offline discussion you refer to, and =
therefore suppose you meant "dynamic vs static AND stateful vs =
_stateless_".
Several pointed out, in that discussion, that the stateless & dynamic =
combination doesn't really make sense.=20
In any case, this discussion hasn't been pursued on the WG list.

> The analysis would elaborate the pros and cons of each solution =
(static stateless, static stateful, dynamic stateful,...). This document =
would be an analysis document and not a motivation document anymore. =
This document has no milestone in the charter IMHO. Note the charter =
mentions the following:=20
>=20
> "Aug 2011 - Adopt stateless legacy IPv4 solution motivation document =
as a Working Group document"
>=20
>=20
> I personally think the first option is straightforward

So do I, =3D> +1
That is IMHO the only acceptable option in view of the vote result.


> but I'm open to the opinions of the working group members on how to =
proceed.

Let's see then.

Regards to all,
RD


>=20
> Cheers,
> Med
>=20
>=20
> -----Message d'origine-----
> De : R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20
> Envoy=E9 : mardi 16 ao=FBt 2011 16:30
> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : Nejc =8Akoberne; =
draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org; =
softwires@ietf.org
> Objet : Re: [Softwires] =
draft-operators-softwire-stateless-4v6-motivation
>=20
> Hi Med,
>=20
> At the last meeting, a vote was taken to decide whether this draft =
should become a WG draft.
> The answer has been a crystal clear yes, with the common understanding =
that, as such, it would have to be improved and competed based on WG =
reactions.
>=20
> IMHO, making it a WG document asap will facilitate discussions like =
this one: thet will point to the right document.
>=20
> Is there any sort term plan to do what was approved?
>=20
> Kind regards,
> RD
>=20
>=20
>=20
>=20
> Le 16 ao=FBt 2011 =E0 13:48,  =
 a =E9crit :
>=20
>> Dear Nejc,
>>=20
>> Thank you for the comments. Please see my answers inline.
>>=20
>> Cheers,
>> Med
>>=20
>>=20
>> -----Message d'origine-----
>> De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] =
De la part de Nejc =8Akoberne
>> Envoy=E9 : mardi 16 ao=FBt 2011 12:25
>> =C0 : =
draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
>> Cc : softwires@ietf.org
>> Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation
>>=20
>> Hello,
>>=20
>> I have some comments on your draft, see inline.
>>=20
>> Regards,
>> Nejc
>>=20
>> ---------------
>>  2. Terminology
>>=20
>>=20
>>=20
>>  This document makes use of the following terms:
>>=20
>>  Stateful 4/6 solution  (or stateful solution in short): denotes a
>>                      solution where the network maintains =
user-session
>>                      states relying on the activation of a NAT
>>                      function in the Service Providers' network
>>                      [I-D.ietf-behave-lsn-requirements].  The NAT
>>                      function is responsible for sharing the same =
IPv4
>>                      address among several subscribers and to =
maintain
>>                      user-session state.
>>=20
>>  Stateless  4/6 solution  (or stateless solution in short): denotes a
>>                      solution which does not require any user-session
>>                      state (seeSection 2.3 of [RFC1958]) to be
>>                      maintained by any IP address sharing function in
>>                      the Service Provider's network.  This category =
of
>>                      solutions assumes a dependency between an IPv6
>>                      prefix and IPv4 address.  In an IPv4 address
>>                      sharing context, dedicated functions are =
required
>>                      to be enabled in the CPE router to restrict the
>>                      source IPv4 port numbers.  Within this document,
>>                      "port set" and "port range" terms are used
>>                      interchangeably.
>>=20
>> [NS: If we consider a "stateful A+P" solution, we don't necessarily
>> have a dependency between an IPv6 prefix and IPv4 address. Also, we
>> don't have any user-session state in the Service Provider's network.
>>=20
>> Med: Fully agree. FWIW, this is what we called "Binding Table A+P =
Mode" in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4.
>>=20
>> We do, however, have some user state (in order to do stateful =
tunneling,
>> for example). Maybe this is included in "user-session" in your
>> terminology, but then I think it would be appropriate to define the
>> term "user-session" clearly.]
>>=20
>> Med: We assumed the definition of state as mentioned in RFC1958; but =
I agree the terminology should be much more clearer.
>>=20
>> ...
>>=20
>>      3.1.5. Bandwidth Saving
>>=20
>>=20
>>=20
>>  In same particular network scenarios (e.g., wireless network ),
>>  spectrum is very valuable and scarce resource.  Service providers
>>  usually wish to eliminate unnecessary overhead to save bandwidth
>>  consumption in such environment.  Service providers need to consider
>>  optimizing the form of packet processing when encapsulation is used.
>>  Since existing header compression techniques are stateful, it is
>>  expected that stateless solution minimize overhead introduced by the
>>  solution.
>>=20
>> [NS: I don't understand this section, but that may be just me.
>> Maybe is there a better way to explain the point?]
>>=20
>> Med: We have several co-authors who are not either in favour or =
maintaining this section. This text will be removed.
>>=20
>> ...
>>=20
>>=20
>>      3.3.1. Implicit Host Identification
>>=20
>>=20
>>=20
>>  Service Providers do not offer only IP connectivity services but =
also
>>  added value services (a.k.a., internal services).  Upgrading these
>>  services to be IPv6-enabled is not sufficient because of legacy
>>  devices.  In some deployments, the delivery of these added-value
>>  services relies on implicit identification mechanism based on the
>>  source IPv4 address.  Due to address sharing, implicit =
identification
>>  will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing
>>  implicit identification with explicit authentication will be seen as
>>  a non acceptable service regression by the end users (less Quality =
of
>>  Experience (QoE)).
>>=20
>>  When a stateless solution is deployed, implicit identification for
>>  internal services is likely to be easier to implement: the implicit
>>  identification should be updated to take into account the port range
>>  and the IPv4 address.  Techniques as those analyzed in
>>  [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the
>>  delivery of these internal services if a stateless solution is
>>  deployed.
>>=20
>> [NS: I don't think this is true only for stateless
>> solutions. If we have a stateful solution with static port allocation
>> (as you mention in section 3.1.3), then implementing such an implicit
>> host identification which uses also port information, is doable as
>> well.]
>>=20
>> Med: I Agree. But then you loose other benefits of the stateful: have =
an aggressive address sharing ratio.
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20
>=20



From bingxuere@gmail.com  Tue Aug 16 09:28:23 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1F411E80CB for ; Tue, 16 Aug 2011 09:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.52
X-Spam-Level: 
X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMs8+kEHHMa5 for ; Tue, 16 Aug 2011 09:28:22 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 870E711E80C3 for ; Tue, 16 Aug 2011 09:28:22 -0700 (PDT)
Received: by iye1 with SMTP id 1so92900iye.27 for ; Tue, 16 Aug 2011 09:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s2dzddfysdlUZHlzDHxlJJvtvE0kkUO9euQZimpaGwA=; b=QBdwWYQyMZgrURRg6gY/hN6JZkNdDTbpitz/R4NW/sYJM354c3SUVQCSfC4C4W4U+D PrBmgm8OX1cJ1kUxp0AaodJkGcqRGgsA3CNQpCPt3wZf8Eyl8HJrnveFiuVzoGGszOKx paeuCxmmzQ48Oie5d5dquBHFT6umpF2eIpbDM=
Received: by 10.231.47.82 with SMTP id m18mr10828203ibf.54.1313512151161; Tue, 16 Aug 2011 09:29:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.36.8 with HTTP; Tue, 16 Aug 2011 09:28:51 -0700 (PDT)
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62CFC@PUEXCB1B.nanterre.francetelecom.fr>
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <4E4A5BEE.3030708@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CFC@PUEXCB1B.nanterre.francetelecom.fr>
From: Qiong 
Date: Wed, 17 Aug 2011 00:28:51 +0800
Message-ID: 
To: mohamed.boucadair@orange-ftgroup.com
Content-Type: multipart/alternative; boundary=0015177417d62d9b9204aaa1e1b9
Cc: "softwires@ietf.org" , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 16:28:23 -0000

--0015177417d62d9b9204aaa1e1b9
Content-Type: text/plain; charset=UTF-8

Hi, Med, and Nejc,

Please see inline.

>
> You indeed loose agressive sharnig ratio, but you have somewhat more
> flexible addressing. Also, the CPEs can be then really simple devices,
> excluding any of the NAPT functionality, doing only stateless
> encapsulation.
> However, what you loose/gain is irrelevant for my point. I think this
> section should be modified in a way like the logging section or any
> other appropriate way, which explains, that this is not the benefit of
> the stateless nature, but rather the benefit of the static port allocation.
>
> [Qiong]: +1 Agree.


> Med: Your point is valid and the text should be updated accordingly. My
> comment aims to show that the comparison is not so that trivial. We can
> claim the stateful with port ranges can provide similar features as the
> stateless or the binding mode but we always forget to mention this lead to
> loose one of the characteristics of the stateful. We captured a similar
> discussion in
> http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2
> :
>

[Qiong]: In our situation, we do not regard aggressive sharing ratio as a
vital important feature since the static port multiplex ratio is already
enough for us. Besides, even for session-based CGN like ds-lite, we would
still prefer to pre-define port-range for customers because our centralized
log server can not deal with massive session-based log events. So it seems
more reasonable for us to adopt static port arrangement which can largely
reduce the log volume.

Best regards

Qiong Sun


>
> "5.2.  Port Utilisation Efficiency
>
>   CGN-based solutions, because they can dynamically assign ports,
>   provide better IPv4 address sharing ratio than stateless solutions
>   (i.e., can share the same IP address among a larger number of
>   customers).  For Service Providers who desire an aggressive IPv4
>   address sharing, a CGN-based solution is more suitable than the
>   stateless.
>
>      If a Service Provider adopts an aggressive address sharing ratio,
>      it is likely to be attempted by enforcing a NAT port overloading
>      mode and as a consequence some applications will break.
>
>   However, as more and more hosts become dual-stack enabled, the need
>   for ports in IPv4 is likely to decrease.  The insurance to have the
>   full set of 64K ports per host will be one of the incentives to have
>   them IPv6 capable.  Moreover, Service Providers should offload some
>   services to IPv6 (e.g., DNS, VoIP)."
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--0015177417d62d9b9204aaa1e1b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Med, and Nejc,

Please see inline.


You indeed loose agressive sharnig ratio, but you have somewhat more

flexible addressing. Also, the CPEs can be then really simple devices,

excluding any of the NAPT functionality, doing only stateless encapsulation=
.

However, what you loose/gain is irrelevant for my point. I think this

section should be modified in a way like the logging section or any

other appropriate way, which explains, that this is not the benefit of

the stateless nature, but rather the benefit of the static port allocation.=



[Qiong]: +1 Agree.
=C2=A0


Med: Your point is valid and the text should be updated accordingly. =
My comment aims to show that the comparison is not so that trivial. We can =
claim the stateful with port ranges can provide similar features as the sta=
teless or the binding mode but we always forget to mention this lead to loo=
se one of the characteristics of the stateful. We captured a similar discus=
sion in http://tools.ietf.or=
g/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2=
:




[Qiong]: In our situation, we do not regar=
d aggressive=C2=A0sharing ratio=C2=A0as a vital important feature since the=
 static port multiplex ratio is already enough for us. Besides, even for se=
ssion-based CGN like ds-lite, we would still prefer to pre-define port-rang=
e for customers because our centralized log server can not deal with massiv=
e session-based log events. So it seems more reasonable for us to adopt sta=
tic port arrangement which can largely reduce the log=C2=A0volume.




Best regards

Qiong Sun
=C2=A0



"5.2. =C2=A0Port Utilisation Efficiency



 =C2=A0 CGN-based solutions, because they can dynamically assign ports,

 =C2=A0 provide better IPv4 address sharing ratio than stateless solutions<=
br>
 =C2=A0 (i.e., can share the same IP address among a larger number of

 =C2=A0 customers). =C2=A0For Service Providers who desire an aggressive IP=
v4

 =C2=A0 address sharing, a CGN-based solution is more suitable than the

 =C2=A0 stateless.



 =C2=A0 =C2=A0 =C2=A0If a Service Provider adopts an aggressive address sha=
ring ratio,

 =C2=A0 =C2=A0 =C2=A0it is likely to be attempted by enforcing a NAT port o=
verloading

 =C2=A0 =C2=A0 =C2=A0mode and as a consequence some applications will break=
.



 =C2=A0 However, as more and more hosts become dual-stack enabled, the need=


 =C2=A0 for ports in IPv4 is likely to decrease. =C2=A0The insurance to hav=
e the

 =C2=A0 full set of 64K ports per host will be one of the incentives to hav=
e

 =C2=A0 them IPv6 capable. =C2=A0Moreover, Service Providers should offload=
 some

 =C2=A0 services to IPv6 (e.g., DNS, VoIP)."










_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--0015177417d62d9b9204aaa1e1b9--

From jan@go6.si  Tue Aug 16 13:37:08 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32411E80E6 for ; Tue, 16 Aug 2011 13:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2MntFRG+FKf for ; Tue, 16 Aug 2011 13:37:08 -0700 (PDT)
Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB3F11E80DF for ; Tue, 16 Aug 2011 13:37:07 -0700 (PDT)
Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 95EF02378050 for ; Tue, 16 Aug 2011 22:37:53 +0200 (CEST)
Message-ID: <4E4AD521.1050907@go6.si>
Date: Tue, 16 Aug 2011 22:37:53 +0200
From: "Jan Zorz @ go6.si" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net> <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 20:37:08 -0000

On 8/16/11 5:03 PM, mohamed.boucadair@orange-ftgroup.com wrote:
> 2) An alternative structure has been proposed off-line by A. Durand:
> discuss dynamic vs. static and stateful vs. dynamic. The analysis
> would elaborate the pros and cons of each solution (static stateless,
> static stateful, dynamic stateful,...). This document would be an
> analysis document and not a motivation document anymore. This
> document has no milestone in the charter IMHO. Note the charter
> mentions the following:

This sounds like a great idea. Nejc Ĺ koberne, Olaf Maennel, myself and 
some others are already working on something similar, but more in form 
of scientific paper (you know, two columns and so...).

RFC with similar content would also be great.

Cheers, Jan Zorz


From jacni@jacni.com  Tue Aug 16 17:50:30 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE2A11E808A for ; Tue, 16 Aug 2011 17:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.311,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtEih9aTMcWk for ; Tue, 16 Aug 2011 17:50:29 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 94FA011E8087 for ; Tue, 16 Aug 2011 17:50:28 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id E83E53801CE for ; Tue, 16 Aug 2011 20:51:14 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 5FCCE340093 for ; Wed, 17 Aug 2011 08:51:11 +0800 (CST)
Received: from [172.18.221.184] (unknown [112.64.190.45]) by app (Coremail) with SMTP id +AWowJB7gwNpEEtOY55QAA--.38447S2; Wed, 17 Aug 2011 08:50:56 +0800 (CST)
Message-ID: <4E4B10B9.4090406@jacni.com>
Date: Wed, 17 Aug 2011 08:52:09 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: mohamed.boucadair@orange-ftgroup.com
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net> <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: multipart/alternative; boundary="------------080808000902070305020605"
X-CM-TRANSID: +AWowJB7gwNpEEtOY55QAA--.38447S2
X-Coremail-Antispam: 1UD129KBjvdXoW7GrWUJrW5Xr47XFyUuFy3urg_yoWDAFgEvw 18WF98A3yI9F1DKa17Jr13JFn7Xw4UGF1UZw48tw47Za4rtrZ0kayDKF909ryrXws8urnx C3Z7KryFyr12gjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUjbkYjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6w4kM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_JFC_Wr1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1lnx0Ec2IEnICE548m6r1DJrWUZwAv7VC0I7IYx2IY67AKxVWUJVWU GwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMx k0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4IxY624lx4CE17CEb7AF67AK xVWUAVWUtwCIc40Y0x0EwIxGrbIYCTnIWIevJa73UjIFyTuYvjxU2LIDDUUUU
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIBEko7lNBnxAAssq
Cc: "softwires@ietf.org" , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 00:50:30 -0000

This is a multi-part message in MIME format.
--------------080808000902070305020605
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 8/16/2011 11:03 PM, mohamed.boucadair@orange-ftgroup.com wrote:
> ...
>
> As for the content of the next iteration of the document, we have two options so far:
>
> (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc.
>
> Or
>
> 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following:
>
> "Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document"
>
>
> I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed.
In favor of the first.


Cheers,
Jacni


--------------080808000902070305020605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    On 8/16/2011 11:03 PM, mohamed.boucadair@orange-ftgroup.com wrote:
    

      
...

As for the content of the next iteration of the document, we have two options so far:

(1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. 

Or 

2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: 

"Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document"


I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed.

    

    In favor of the first.

    

    

    Cheers,

    Jacni

    

    

    

  


--------------080808000902070305020605--


From jacni@jacni.com  Tue Aug 16 18:09:11 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAE55E8005 for ; Tue, 16 Aug 2011 18:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.138,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvjyOokXktco for ; Tue, 16 Aug 2011 18:09:10 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 44B935E8004 for ; Tue, 16 Aug 2011 18:09:10 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id A7B263800F5 for ; Tue, 16 Aug 2011 21:09:59 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 3D644340059 for ; Wed, 17 Aug 2011 09:09:58 +0800 (CST)
Received: from [172.18.221.184] (unknown [112.64.190.45]) by app (Coremail) with SMTP id +AWowJDrVgbJFEtOwqNQAA--.55446S2; Wed, 17 Aug 2011 09:09:43 +0800 (CST)
Message-ID: <4E4B1519.3030003@jacni.com>
Date: Wed, 17 Aug 2011 09:10:49 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net>
In-Reply-To: <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-CM-TRANSID: +AWowJDrVgbJFEtOwqNQAA--.55446S2
X-Coremail-Antispam: 1UD129KBjvdXoWrCFyDXw47Cw47ArW8Kr1ftFb_yoWxGFb_Zr y7Wryq9w4Igw4fta1Syr4Fyr1xAr4rA3WqgwsYqa48XFW5XrW3ZFsrXFnFva13Gw4UuF90 9as7Zw4jq34S9jkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTC7k042IEc7kJM7k042IE4IxYO2xFxVAqjxCEw4Av424lb7Iv0xC_Zr1l b4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWUuVWrJwAa7VCY0VAaVVAqrcv_Jw 1UWr13Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2 z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20x vY0x0EwIxGrwCFI7vE0wC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVF xhVjvjDU0xZFpf9x07jT4EiUUUUU=
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIBEko7lNBnxAAuso
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 01:09:11 -0000

hi Remi,

On 8/16/2011 4:27 PM, Rémi Després wrote:
> ...
> As already discussed privately, I don't know realistic cases where two rules would have IPv6 or IPv4 overlapping prefixes.
> Consequently, it seems that "longest" match, while being permitted, doesn't need to be a requirement.
If there are multiple ways for CPE to decide the IPv6 prefix, we have to 
specify the order of priority. e.g., firstly check if there is any 
implication assigned along with the rules, no? then choose the "longest" 
match.
BTW, I think the longest match is not bad.


Cheers,
Jacni

> Would you have such use cases to share?
>
> Regards,
> RD
>
>


From matsuhira@jp.fujitsu.com  Tue Aug 16 19:07:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C2F11E808F for ; Tue, 16 Aug 2011 19:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.865
X-Spam-Level: 
X-Spam-Status: No, score=-103.865 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtTS+NAzyVtU for ; Tue, 16 Aug 2011 19:07:37 -0700 (PDT)
Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id E9F4211E8080 for ; Tue, 16 Aug 2011 19:07:36 -0700 (PDT)
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 654A53EE0AE for ; Wed, 17 Aug 2011 11:08:25 +0900 (JST)
Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 087F245DE5A for ; Wed, 17 Aug 2011 11:08:25 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id DF24E45DE58 for ; Wed, 17 Aug 2011 11:08:24 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id B839F1DB8049 for ; Wed, 17 Aug 2011 11:08:24 +0900 (JST)
Received: from m001.s.css.fujitsu.com (m001.s.css.fujitsu.com [10.23.4.39]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 8628F1DB8052 for ; Wed, 17 Aug 2011 11:08:24 +0900 (JST)
Received: from m001.css.fujitsu.com (m001 [127.0.0.1]) by m001.s.css.fujitsu.com (Postfix) with ESMTP id 6F2F12E0249; Wed, 17 Aug 2011 11:08:24 +0900 (JST)
Received: from [127.0.0.1] (fj86077803.kh0110-194.dhcp.css.fujitsu.com [10.17.194.90]) by m001.s.css.fujitsu.com (Postfix) with ESMTP id 40C232E0235; Wed, 17 Aug 2011 11:08:24 +0900 (JST)
X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1
Message-ID: <4E4B228B.4060305@jp.fujitsu.com>
Date: Wed, 17 Aug 2011 11:08:11 +0900
From: Naoki Matsuhira 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
References: <6D93B4F87F5667499B9104BA798D637A046A13F2@STAFFMBX-1.lunet.lboro.ac.uk> <6D93B4F87F5667499B9104BA798D637A0C5FE3B25F@STAFFMBX-1.lunet.lboro.ac.uk> <4E49228F.2040705@skoberne.net> <4E4A17CD.8030807@jp.fujitsu.com> <4E4A925D.2000000@skoberne.net>
In-Reply-To: <4E4A925D.2000000@skoberne.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] SA46T questions
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 02:07:37 -0000

Nejc,

Basically, I think your point is correct, and I agree with you.

However, in my honest opinion, I am confused a little about target 
technology in softwire.

SA46T and SA46T-AS is just a tunneling technology.

The other side, in my understanding, DS-Lite and 4rd is combination 
technology of tunneling and NAT.

In my understanding, DS-Lite is CGN + Tunneling combination, so CGN + 
SA46T combination may possible. I think this combination may say DS-Lite.

To similar, 4rd make NAT in CPE assumption. I don't understand 4rd is 
just tunneling function, or combination with CPE NAT. In the standing 
point of SA46T-AS, as you point out, SA46T-AS + CPE NAT combination may 
possible.

Both DS-Lite and 4rd is the combination technology for access network. 
However, I also have interests to apply SA46T-AS to the server environment.

I think your trade-off analysis is very important. If adding 
SA46T/SA46T-AS technology to your analysis table, I think "DS-Lite + 
SA46T" and "SA46T-AS + CPE NAT" is appropriate.

Regards,
Naoki Matsuhira.


(2011/08/17 0:53), Nejc Ĺ koberne wrote:
> Dear Naoki,
>
>> Number of ports can be selected by prefix length.
>
> I see.
>
> So essentially, SA46T-AS is like 4rd, but with a different port-allocation
> scheme. Also the "IPv4 plane" feature (you also call it "IPv4 VPN service")
> can be seen as a variant of multiple 4rd domains in 4rd context.
>
> Do you agree? If this is so, I don't really see why would we need a separate
> specification for this? I mean, we could also define various port-allocation
> schemes in the 4rd draft (as in RFC 6056, where we have various port
> randomization algorithms available for implementation).
>
> Thanks,
> Nejc
>
>


From xiaohong.deng@orange-ftgroup.com  Tue Aug 16 21:10:08 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7848421F8B08 for ; Tue, 16 Aug 2011 21:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.732
X-Spam-Level: 
X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.517,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvJU+9jDcMci for ; Tue, 16 Aug 2011 21:10:07 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4459F21F8AF5 for ; Tue, 16 Aug 2011 21:09:32 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6E9128C0002; Wed, 17 Aug 2011 06:11:12 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 654D38B8005; Wed, 17 Aug 2011 06:11:12 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 17 Aug 2011 06:10:20 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Aug 2011 12:10:15 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195B4D3@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <7998F52F-58E8-4E7D-8327-D64666AF7EFE@laposte.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Thread-Index: Acxck5EUao2e1PO9TmKjsIufDZ6Xtg==
References: <4E4A4569.8030706@skoberne.net><94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr><1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net><94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr> <7998F52F-58E8-4E7D-8327-D64666AF7EFE@laposte.net>
From: 
To: , 
X-OriginalArrivalTime: 17 Aug 2011 04:10:20.0225 (UTC) FILETIME=[94243310:01CC5C93]
Cc: draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 04:10:08 -0000

Hi all,=20

|-----Original Message-----
|From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20
|Sent: Wednesday, August 17, 2011 12:28 AM
|To: Softwires-wg
|Cc: draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
|Subject: Re: [Softwires]=20
|draft-operators-softwire-stateless-4v6-motivation
|
|Hello all,
|
|It appears that confirming on this list the vote made in=20
|Quebec would be useful.

Agreed.

|Please see below.
|
|Le 16 ao=FBt 2011 =E0 17:03,=20
|=20
| a =E9crit :
|
|>  ... there was a vote in favour of adopting this document as=20
|a WG document but as you know this vote should be confirmed in the ML.
|
|I have seen drafts becoming WG drafts after votes during=20
|meetings but, fair enough, let's see if, after the unanimous=20
|vote in the meeting, there are serious objections to it now.=20
|
|
|> A call for adoption should normally be issued by the chairs=20
|according to the IETF procedure.
|>=20
|> As for the content of the next iteration of the document, we=20
|have two options so far:
|>=20
|> (1) Put back some sections which have been removed in -02,
|
|Support.
|Some of them were worth having, IMHO.
|
|> add a new section to discuss dynamic vs. static,
|
|> handle the comments received from J. Arkko, etc.=20
|
|Sure.
|Doing this while the draft is already a WG draft seems to me=20
|normal after the vote result (but no objection to doing it=20
|right away if found better. =20
|
|> Or
|>=20
|> 2) An alternative structure has been proposed off-line by A.=20
|Durand: discuss dynamic vs. static and stateful vs. dynamic.
|
|Offline discussions are of course completely free, and useful,=20
|but a WG consensus can only be built in the open, i.e. on the=20
|WG mailing list.
|I am aware of at least part of the offline discussion you=20
|refer to, and therefore suppose you meant "dynamic vs static=20
|AND stateful vs _stateless_".
|Several pointed out, in that discussion, that the stateless &=20
|dynamic combination doesn't really make sense.=20
|In any case, this discussion hasn't been pursued on the WG list.
|
|> The analysis would elaborate the pros and cons of each=20
|solution (static stateless, static stateful, dynamic=20
|stateful,...). This document would be an analysis document and=20
|not a motivation document anymore. This document has no=20
|milestone in the charter IMHO. Note the charter mentions the=20
|following:=20
|>=20
|> "Aug 2011 - Adopt stateless legacy IPv4 solution motivation=20
|document as a Working Group document"
|>=20
|>=20
|> I personally think the first option is straightforward
|
|So do I, =3D> +1
|That is IMHO the only acceptable option in view of the vote result.

+1=20
Prefer the first option, as "discussion dynamic allocation vs. static =
allocation"
in a new section other than discussing on the mailing list sounds to me
the more practical and efficient one to meet the Chater milstone.

Cheers,
Xiaohong

|
|
|> but I'm open to the opinions of the working group members on=20
|how to proceed.
|
|Let's see then.
|
|Regards to all,
|RD
|
|
|>=20
|> Cheers,
|> Med
|>=20
|>=20
|> -----Message d'origine-----
|> De : R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] Envoy=E9 :=20
|mardi 16=20
|> ao=FBt 2011 16:30 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc=20
|Skoberne;=20
|> draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org;=20
|> softwires@ietf.org Objet : Re: [Softwires]=20
|> draft-operators-softwire-stateless-4v6-motivation
|>=20
|> Hi Med,
|>=20
|> At the last meeting, a vote was taken to decide whether this=20
|draft should become a WG draft.
|> The answer has been a crystal clear yes, with the common=20
|understanding that, as such, it would have to be improved and=20
|competed based on WG reactions.
|>=20
|> IMHO, making it a WG document asap will facilitate=20
|discussions like this one: thet will point to the right document.
|>=20
|> Is there any sort term plan to do what was approved?
|>=20
|> Kind regards,
|> RD
|>=20
|>=20
|>=20
|>=20
|> Le 16 ao=FBt 2011 =E0 13:48,=20
|=20
| a =E9crit :
|>=20
|>> Dear Nejc,
|>>=20
|>> Thank you for the comments. Please see my answers inline.
|>>=20
|>> Cheers,
|>> Med
|>>=20
|>>=20
|>> -----Message d'origine-----
|>> De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]=20
|>> De la part de Nejc Skoberne Envoy=E9 : mardi 16 ao=FBt 2011 12:25 =
=C0 :=20
|>> draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
|>> Cc : softwires@ietf.org
|>> Objet : [Softwires]=20
|draft-operators-softwire-stateless-4v6-motivation
|>>=20
|>> Hello,
|>>=20
|>> I have some comments on your draft, see inline.
|>>=20
|>> Regards,
|>> Nejc
|>>=20
|>> ---------------
|>>  2. Terminology
|>>=20
|>>=20
|>>=20
|>>  This document makes use of the following terms:
|>>=20
|>>  Stateful 4/6 solution  (or stateful solution in short): denotes a
|>>                      solution where the network maintains=20
|user-session
|>>                      states relying on the activation of a NAT
|>>                      function in the Service Providers' network
|>>                      [I-D.ietf-behave-lsn-requirements].  The NAT
|>>                      function is responsible for sharing=20
|the same IPv4
|>>                      address among several subscribers and=20
|to maintain
|>>                      user-session state.
|>>=20
|>>  Stateless  4/6 solution  (or stateless solution in short):=20
|denotes a
|>>                      solution which does not require any=20
|user-session
|>>                      state (seeSection 2.3 of [RFC1958]) to be
|>>                      maintained by any IP address sharing=20
|function in
|>>                      the Service Provider's network.  This=20
|category of
|>>                      solutions assumes a dependency between an IPv6
|>>                      prefix and IPv4 address.  In an IPv4 address
|>>                      sharing context, dedicated functions=20
|are required
|>>                      to be enabled in the CPE router to restrict the
|>>                      source IPv4 port numbers.  Within this=20
|document,
|>>                      "port set" and "port range" terms are used
|>>                      interchangeably.
|>>=20
|>> [NS: If we consider a "stateful A+P" solution, we don't necessarily=20
|>> have a dependency between an IPv6 prefix and IPv4 address. Also, we=20
|>> don't have any user-session state in the Service Provider's network.
|>>=20
|>> Med: Fully agree. FWIW, this is what we called "Binding=20
|Table A+P Mode" in=20
|http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4.
|>>=20
|>> We do, however, have some user state (in order to do stateful=20
|>> tunneling, for example). Maybe this is included in=20
|"user-session" in=20
|>> your terminology, but then I think it would be appropriate=20
|to define=20
|>> the term "user-session" clearly.]
|>>=20
|>> Med: We assumed the definition of state as mentioned in=20
|RFC1958; but I agree the terminology should be much more clearer.
|>>=20
|>> ...
|>>=20
|>>      3.1.5. Bandwidth Saving
|>>=20
|>>=20
|>>=20
|>>  In same particular network scenarios (e.g., wireless network ), =20
|>> spectrum is very valuable and scarce resource.  Service providers =20
|>> usually wish to eliminate unnecessary overhead to save bandwidth =20
|>> consumption in such environment.  Service providers need to=20
|consider =20
|>> optimizing the form of packet processing when encapsulation is used.
|>>  Since existing header compression techniques are stateful, it is =20
|>> expected that stateless solution minimize overhead=20
|introduced by the =20
|>> solution.
|>>=20
|>> [NS: I don't understand this section, but that may be just me.
|>> Maybe is there a better way to explain the point?]
|>>=20
|>> Med: We have several co-authors who are not either in=20
|favour or maintaining this section. This text will be removed.
|>>=20
|>> ...
|>>=20
|>>=20
|>>      3.3.1. Implicit Host Identification
|>>=20
|>>=20
|>>=20
|>>  Service Providers do not offer only IP connectivity services but=20
|>> also  added value services (a.k.a., internal services).  Upgrading=20
|>> these  services to be IPv6-enabled is not sufficient because of=20
|>> legacy  devices.  In some deployments, the delivery of these=20
|>> added-value  services relies on implicit identification mechanism=20
|>> based on the  source IPv4 address.  Due to address sharing,=20
|implicit=20
|>> identification  will fail=20
|>> [I-D.ietf-intarea-shared-addressing-issues]; replacing  implicit=20
|>> identification with explicit authentication will be seen as  a non=20
|>> acceptable service regression by the end users (less=20
|Quality of  Experience (QoE)).
|>>=20
|>>  When a stateless solution is deployed, implicit=20
|identification for =20
|>> internal services is likely to be easier to implement: the=20
|implicit =20
|>> identification should be updated to take into account the=20
|port range =20
|>> and the IPv4 address.  Techniques as those analyzed in =20
|>> [I-D.boucadair-intarea-nat-reveal-analysis] are not=20
|required for the =20
|>> delivery of these internal services if a stateless solution is =20
|>> deployed.
|>>=20
|>> [NS: I don't think this is true only for stateless solutions. If we=20
|>> have a stateful solution with static port allocation (as=20
|you mention=20
|>> in section 3.1.3), then implementing such an implicit host=20
|>> identification which uses also port information, is doable as well.]
|>>=20
|>> Med: I Agree. But then you loose other benefits of the=20
|stateful: have an aggressive address sharing ratio.
|>> _______________________________________________
|>> Softwires mailing list
|>> Softwires@ietf.org
|>> https://www.ietf.org/mailman/listinfo/softwires
|>=20
|>=20
|
|
|
|

From tetsuya@ipinfusion.com  Tue Aug 16 21:15:52 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF511E80E8 for ; Tue, 16 Aug 2011 21:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzsNFyAtL2gS for ; Tue, 16 Aug 2011 21:15:47 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76E7111E80E4 for ; Tue, 16 Aug 2011 21:15:47 -0700 (PDT)
Received: by yie12 with SMTP id 12so508387yie.31 for ; Tue, 16 Aug 2011 21:16:37 -0700 (PDT)
Received: by 10.42.105.146 with SMTP id v18mr340712ico.429.1313554597284; Tue, 16 Aug 2011 21:16:37 -0700 (PDT)
Received: from [192.168.0.6] (c-76-102-170-116.hsd1.ca.comcast.net [76.102.170.116]) by mx.google.com with ESMTPS id bu8sm478785icb.23.2011.08.16.21.16.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Aug 2011 21:16:36 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=utf-8
From: Tetsuya Murakami 
In-Reply-To: <4E4B1519.3030003@jacni.com>
Date: Tue, 16 Aug 2011 21:16:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C44A1A0-5192-481A-B9F8-994607C56525@ipinfusion.com>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>
To: Jacni Qin 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 04:15:53 -0000

Hi Remi, Jacni,

We are considering the following situation.

Initially, one 4rd mapping rule can be set like {2408:db8::/32, =
10.10.0.0/24, 48}. After that, if renumbering is required, the =
additional mapping rules are just distributed such as

{2408:db8:100::/40, 10.10.1.0/24, 48}
{2408:db8:200::/40, 10.10.2.0/24, 48}
...

In this case, it is useful to have a longest match to find the suitable =
mapping rule.

Thanks,
Tetsuya Murakami

On 2011/08/16, at 18:10, Jacni Qin wrote:

> hi Remi,
>=20
> On 8/16/2011 4:27 PM, R=C3=A9mi Despr=C3=A9s wrote:
>> ...
>> As already discussed privately, I don't know realistic cases where =
two rules would have IPv6 or IPv4 overlapping prefixes.
>> Consequently, it seems that "longest" match, while being permitted, =
doesn't need to be a requirement.
> If there are multiple ways for CPE to decide the IPv6 prefix, we have =
to specify the order of priority. e.g., firstly check if there is any =
implication assigned along with the rules, no? then choose the "longest" =
match.
> BTW, I think the longest match is not bad.
>=20
>=20
> Cheers,
> Jacni
>=20
>> Would you have such use cases to share?
>>=20
>> Regards,
>> RD
>>=20
>>=20
>=20


From tetsuya@ipinfusion.com  Tue Aug 16 21:42:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78C11E808A for ; Tue, 16 Aug 2011 21:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TUdpO-MXpsb for ; Tue, 16 Aug 2011 21:42:36 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 85F5A22830B for ; Tue, 16 Aug 2011 21:42:35 -0700 (PDT)
Received: by iye1 with SMTP id 1so1013062iye.27 for ; Tue, 16 Aug 2011 21:43:26 -0700 (PDT)
Received: by 10.42.176.67 with SMTP id bd3mr420286icb.488.1313556206058; Tue, 16 Aug 2011 21:43:26 -0700 (PDT)
Received: from [192.168.0.6] (c-76-102-170-116.hsd1.ca.comcast.net [76.102.170.116]) by mx.google.com with ESMTPS id a9sm506439icy.6.2011.08.16.21.43.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Aug 2011 21:43:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=utf-8
From: Tetsuya Murakami 
In-Reply-To: <7C44A1A0-5192-481A-B9F8-994607C56525@ipinfusion.com>
Date: Tue, 16 Aug 2011 21:43:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <583306E7-6803-449B-A31A-5AD3961A8E54@ipinfusion.com>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com> <7C44A1A0-5192-481A-B9F8-994607C56525@ipinfusion.com>
To: Tetsuya Murakami 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 04:42:37 -0000

Sorry. I have a typo. The following address has no meaning...

Sorry again.

Tetsuya Murakami

On 2011/08/16, at 21:16, Tetsuya Murakami wrote:

> Hi Remi, Jacni,
>=20
> We are considering the following situation.
>=20
> Initially, one 4rd mapping rule can be set like {2408:db8::/32, =
10.10.0.0/24, 48}. After that, if renumbering is required, the =
additional mapping rules are just distributed such as
>=20
> {2408:db8:100::/40, 10.10.1.0/24, 48}
> {2408:db8:200::/40, 10.10.2.0/24, 48}
> ...
>=20
> In this case, it is useful to have a longest match to find the =
suitable mapping rule.
>=20
> Thanks,
> Tetsuya Murakami
>=20
> On 2011/08/16, at 18:10, Jacni Qin wrote:
>=20
>> hi Remi,
>>=20
>> On 8/16/2011 4:27 PM, R=C3=A9mi Despr=C3=A9s wrote:
>>> ...
>>> As already discussed privately, I don't know realistic cases where =
two rules would have IPv6 or IPv4 overlapping prefixes.
>>> Consequently, it seems that "longest" match, while being permitted, =
doesn't need to be a requirement.
>> If there are multiple ways for CPE to decide the IPv6 prefix, we have =
to specify the order of priority. e.g., firstly check if there is any =
implication assigned along with the rules, no? then choose the "longest" =
match.
>> BTW, I think the longest match is not bad.
>>=20
>>=20
>> Cheers,
>> Jacni
>>=20
>>> Would you have such use cases to share?
>>>=20
>>> Regards,
>>> RD
>>>=20
>>>=20
>>=20
>=20


From despres.remi@laposte.net  Tue Aug 16 22:44:32 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C83721F8A6C for ; Tue, 16 Aug 2011 22:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.937
X-Spam-Level: 
X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxiLKxAzsehf for ; Tue, 16 Aug 2011 22:44:31 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 7A59921F8906 for ; Tue, 16 Aug 2011 22:44:30 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id E3E2F70000F3; Wed, 17 Aug 2011 07:45:17 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 9D8A070000EC; Wed, 17 Aug 2011 07:45:10 +0200 (CEST)
X-SFR-UUID: 20110817054511645.9D8A070000EC@msfrf2401.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4E4B1519.3030003@jacni.com>
Date: Wed, 17 Aug 2011 07:45:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>
To: Jacni Qin 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 05:44:32 -0000

Le 17 ao=FBt 2011 =E0 03:10, Jacni Qin a =E9crit :

> hi Remi,
>=20
> On 8/16/2011 4:27 PM, R=E9mi Despr=E9s wrote:
>> ...
>> As already discussed privately, I don't know realistic cases where =
two rules would have IPv6 or IPv4 overlapping prefixes.
>> Consequently, it seems that "longest" match, while being permitted, =
doesn't need to be a requirement.
> If there are multiple ways for CPE to decide the IPv6 prefix, we have =
to specify the order of priority. e.g., firstly check if there is any =
implication assigned along with the rules, no? then choose the "longest" =
match.
> BTW, I think the longest match is not bad.

It isn't bad, agreed, because it gives the same result as first match =
when prefixes don't overlap.
It shouldn't however be made a _requirement_ if there is no well =
understood use case because that additional complexity, small but real.

Whether there may be realistic configurations where prefix overlap is =
useful remains AFAIK an open question.
I have serious doubts, but no time now to argue in details.
IMHO, It's up to those who argue in favor of longest match to provide at =
least one realistic example (if there is one).
Then we will agree (or discuss).
Is that fair?

Cheers,
RD




From mohamed.boucadair@orange-ftgroup.com  Tue Aug 16 23:45:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B532311E808C for ; Tue, 16 Aug 2011 23:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level: 
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59EWCazbrygQ for ; Tue, 16 Aug 2011 23:45:44 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8869311E8086 for ; Tue, 16 Aug 2011 23:45:43 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id C8D4BC01D3; Wed, 17 Aug 2011 08:46:32 +0200 (CEST)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id A6EC1180042; Wed, 17 Aug 2011 08:46:32 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 17 Aug 2011 08:46:32 +0200
From: 
To: Qiong 
Date: Wed, 17 Aug 2011 08:46:31 +0200
Thread-Topic: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Thread-Index: AcxcMaICsJO0qGodTAaNiJcEC2jtlgAdbuZA
Message-ID: <94C682931C08B048B7A8645303FDC9F33E54A62DD9@PUEXCB1B.nanterre.francetelecom.fr>
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr> <4E4A5BEE.3030708@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CFC@PUEXCB1B.nanterre.francetelecom.fr> 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33E54A62DD9PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.16.143314
Cc: "softwires@ietf.org" , "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" 
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 06:45:44 -0000

--_000_94C682931C08B048B7A8645303FDC9F33E54A62DD9PUEXCB1Bnante_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBRaW9uZywNCg0KWWVzLCBwb3J0IHJhbmdlcyBjYW4gYmUgdXNlZCBpbiBhIENHTi1iYXNl
ZCBhcmNoaXRlY3R1cmUgdG9vIHRvIHJlZHVjZSBsb2cgZmlsZSB2b2x1bWUgYXMgZGlzY3Vzc2Vk
IGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW9wZXJhdG9ycy1zb2Z0d2lyZS1z
dGF0ZWxlc3MtNHY2LW1vdGl2YXRpb24tMDIjc2VjdGlvbi0zLjEuMyBidXQgdGhlbiB5b3Ugc2hv
dWxkIGJlIGF3YXJlIHlvdSAibG9vc2UiIGEgZmVhdHVyZSBvZmZlcmVkIGJ5IHRoZSBDR04gd2hp
Y2ggaXM6DQoNCiogVGhlIHBvc3NpYmlsaXR5IHRvIGxvZyB0aGUgZGVzdGluYXRpb24gSVAgYWRk
cmVzcyBmb3IgbGVnYWwgc3RvcmFnZSBwdXJwb3NlcyBpbiBjYXNlIHRoZSBzZXJ2ZXIgZG9lcyBu
b3QgaW1wbGVtZW50IFJGQzYzMDIuIElmIFJGQzYzMDIgaXMgbGFyZ2VseSBkZXBsb3llZCwgdGhl
biB0aGlzIGZlYXR1cmUgaXMgbm90IG5lZWRlZC4NCg0KVGhlcmUgYXJlIGEgbG90IG9mIHRyYWRl
LW9mZnMgYW5kIHRoZXJlIGlzIG5vIHVuaXZlcnNhbCBhbnN3ZXJzIHRvIHRoZXNlIHRyYWRlLW9m
ZnMuDQoNCkNoZWVycywNCk1lZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
RGUgOiBRaW9uZyBbbWFpbHRvOmJpbmd4dWVyZUBnbWFpbC5jb21dDQpFbnZvecOpIDogbWFyZGkg
MTYgYW/Du3QgMjAxMSAxODoyOQ0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL05BRC9USVAN
CkNjIDogTmVqYyDFoGtvYmVybmU7IHNvZnR3aXJlc0BpZXRmLm9yZzsgZHJhZnQtb3BlcmF0b3Jz
LXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlvbkB0b29scy5pZXRmLm9yZw0KT2JqZXQg
OiBSZTogW1NvZnR3aXJlc10gZHJhZnQtb3BlcmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYt
bW90aXZhdGlvbg0KDQpIaSwgTWVkLCBhbmQgTmVqYywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoN
CllvdSBpbmRlZWQgbG9vc2UgYWdyZXNzaXZlIHNoYXJuaWcgcmF0aW8sIGJ1dCB5b3UgaGF2ZSBz
b21ld2hhdCBtb3JlDQpmbGV4aWJsZSBhZGRyZXNzaW5nLiBBbHNvLCB0aGUgQ1BFcyBjYW4gYmUg
dGhlbiByZWFsbHkgc2ltcGxlIGRldmljZXMsDQpleGNsdWRpbmcgYW55IG9mIHRoZSBOQVBUIGZ1
bmN0aW9uYWxpdHksIGRvaW5nIG9ubHkgc3RhdGVsZXNzIGVuY2Fwc3VsYXRpb24uDQpIb3dldmVy
LCB3aGF0IHlvdSBsb29zZS9nYWluIGlzIGlycmVsZXZhbnQgZm9yIG15IHBvaW50LiBJIHRoaW5r
IHRoaXMNCnNlY3Rpb24gc2hvdWxkIGJlIG1vZGlmaWVkIGluIGEgd2F5IGxpa2UgdGhlIGxvZ2dp
bmcgc2VjdGlvbiBvciBhbnkNCm90aGVyIGFwcHJvcHJpYXRlIHdheSwgd2hpY2ggZXhwbGFpbnMs
IHRoYXQgdGhpcyBpcyBub3QgdGhlIGJlbmVmaXQgb2YNCnRoZSBzdGF0ZWxlc3MgbmF0dXJlLCBi
dXQgcmF0aGVyIHRoZSBiZW5lZml0IG9mIHRoZSBzdGF0aWMgcG9ydCBhbGxvY2F0aW9uLg0KDQpb
UWlvbmddOiArMSBBZ3JlZS4NCg0KTWVkOiBZb3VyIHBvaW50IGlzIHZhbGlkIGFuZCB0aGUgdGV4
dCBzaG91bGQgYmUgdXBkYXRlZCBhY2NvcmRpbmdseS4gTXkgY29tbWVudCBhaW1zIHRvIHNob3cg
dGhhdCB0aGUgY29tcGFyaXNvbiBpcyBub3Qgc28gdGhhdCB0cml2aWFsLiBXZSBjYW4gY2xhaW0g
dGhlIHN0YXRlZnVsIHdpdGggcG9ydCByYW5nZXMgY2FuIHByb3ZpZGUgc2ltaWxhciBmZWF0dXJl
cyBhcyB0aGUgc3RhdGVsZXNzIG9yIHRoZSBiaW5kaW5nIG1vZGUgYnV0IHdlIGFsd2F5cyBmb3Jn
ZXQgdG8gbWVudGlvbiB0aGlzIGxlYWQgdG8gbG9vc2Ugb25lIG9mIHRoZSBjaGFyYWN0ZXJpc3Rp
Y3Mgb2YgdGhlIHN0YXRlZnVsLiBXZSBjYXB0dXJlZCBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBpbiBo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVyYXRvcnMtc29mdHdpcmUtc3RhdGVs
ZXNzLTR2Ni1tb3RpdmF0aW9uLTAxI3NlY3Rpb24tNC4yOg0KDQpbUWlvbmddOiBJbiBvdXIgc2l0
dWF0aW9uLCB3ZSBkbyBub3QgcmVnYXJkIGFnZ3Jlc3NpdmUgc2hhcmluZyByYXRpbyBhcyBhIHZp
dGFsIGltcG9ydGFudCBmZWF0dXJlIHNpbmNlIHRoZSBzdGF0aWMgcG9ydCBtdWx0aXBsZXggcmF0
aW8gaXMgYWxyZWFkeSBlbm91Z2ggZm9yIHVzLiBCZXNpZGVzLCBldmVuIGZvciBzZXNzaW9uLWJh
c2VkIENHTiBsaWtlIGRzLWxpdGUsIHdlIHdvdWxkIHN0aWxsIHByZWZlciB0byBwcmUtZGVmaW5l
IHBvcnQtcmFuZ2UgZm9yIGN1c3RvbWVycyBiZWNhdXNlIG91ciBjZW50cmFsaXplZCBsb2cgc2Vy
dmVyIGNhbiBub3QgZGVhbCB3aXRoIG1hc3NpdmUgc2Vzc2lvbi1iYXNlZCBsb2cgZXZlbnRzLiBT
byBpdCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgZm9yIHVzIHRvIGFkb3B0IHN0YXRpYyBwb3J0IGFy
cmFuZ2VtZW50IHdoaWNoIGNhbiBsYXJnZWx5IHJlZHVjZSB0aGUgbG9nIHZvbHVtZS4NCg0KQmVz
dCByZWdhcmRzDQoNClFpb25nIFN1bg0KDQoNCiI1LjIuICBQb3J0IFV0aWxpc2F0aW9uIEVmZmlj
aWVuY3kNCg0KICBDR04tYmFzZWQgc29sdXRpb25zLCBiZWNhdXNlIHRoZXkgY2FuIGR5bmFtaWNh
bGx5IGFzc2lnbiBwb3J0cywNCiAgcHJvdmlkZSBiZXR0ZXIgSVB2NCBhZGRyZXNzIHNoYXJpbmcg
cmF0aW8gdGhhbiBzdGF0ZWxlc3Mgc29sdXRpb25zDQogIChpLmUuLCBjYW4gc2hhcmUgdGhlIHNh
bWUgSVAgYWRkcmVzcyBhbW9uZyBhIGxhcmdlciBudW1iZXIgb2YNCiAgY3VzdG9tZXJzKS4gIEZv
ciBTZXJ2aWNlIFByb3ZpZGVycyB3aG8gZGVzaXJlIGFuIGFnZ3Jlc3NpdmUgSVB2NA0KICBhZGRy
ZXNzIHNoYXJpbmcsIGEgQ0dOLWJhc2VkIHNvbHV0aW9uIGlzIG1vcmUgc3VpdGFibGUgdGhhbiB0
aGUNCiAgc3RhdGVsZXNzLg0KDQogICAgIElmIGEgU2VydmljZSBQcm92aWRlciBhZG9wdHMgYW4g
YWdncmVzc2l2ZSBhZGRyZXNzIHNoYXJpbmcgcmF0aW8sDQogICAgIGl0IGlzIGxpa2VseSB0byBi
ZSBhdHRlbXB0ZWQgYnkgZW5mb3JjaW5nIGEgTkFUIHBvcnQgb3ZlcmxvYWRpbmcNCiAgICAgbW9k
ZSBhbmQgYXMgYSBjb25zZXF1ZW5jZSBzb21lIGFwcGxpY2F0aW9ucyB3aWxsIGJyZWFrLg0KDQog
IEhvd2V2ZXIsIGFzIG1vcmUgYW5kIG1vcmUgaG9zdHMgYmVjb21lIGR1YWwtc3RhY2sgZW5hYmxl
ZCwgdGhlIG5lZWQNCiAgZm9yIHBvcnRzIGluIElQdjQgaXMgbGlrZWx5IHRvIGRlY3JlYXNlLiAg
VGhlIGluc3VyYW5jZSB0byBoYXZlIHRoZQ0KICBmdWxsIHNldCBvZiA2NEsgcG9ydHMgcGVyIGhv
c3Qgd2lsbCBiZSBvbmUgb2YgdGhlIGluY2VudGl2ZXMgdG8gaGF2ZQ0KICB0aGVtIElQdjYgY2Fw
YWJsZS4gIE1vcmVvdmVyLCBTZXJ2aWNlIFByb3ZpZGVycyBzaG91bGQgb2ZmbG9hZCBzb21lDQog
IHNlcnZpY2VzIHRvIElQdjYgKGUuZy4sIEROUywgVm9JUCkuIg0KDQoNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcg
bGlzdA0KU29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQo=

--_000_94C682931C08B048B7A8645303FDC9F33E54A62DD9PUEXCB1Bnante_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0
PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv
bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTg3MDIiPjwvSEVBRD4NCjxCT0RZPg0KPERJViBkaXI9
bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzUxNTgzMTA2LTE3MDgyMDExPjxGT05UIGNvbG9y
PSMwMDAwZmYgDQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkRlYXIgUWlvbmcsPC9GT05UPjwv
U1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc1MTU4MzEw
Ni0xNzA4MjAxMT48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3
Ij48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ
QU4gY2xhc3M9NzUxNTgzMTA2LTE3MDgyMDExPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpzaXplPTIg
ZmFjZT0iQ291cmllciBOZXciPlllcywgcG9ydCByYW5nZXMgY2FuIGJlIHVzZWQgaW4gYSBDR04t
YmFzZWQgDQphcmNoaXRlY3R1cmUgdG9vIHRvIHJlZHVjZSBsb2cgZmlsZSB2b2x1bWUgYXMgZGlz
Y3Vzc2VkIGluIDxBIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb3Bl
cmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlvbi0wMiNzZWN0aW9uLTMuMS4z
Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVyYXRvcnMtc29mdHdpcmUtc3Rh
dGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTAyI3NlY3Rpb24tMy4xLjM8L0E+Jm5ic3A7YnV0IA0KdGhl
biB5b3Ugc2hvdWxkIGJlIGF3YXJlIHlvdSAibG9vc2UiIGEgZmVhdHVyZSBvZmZlcmVkIGJ5IHRo
ZSBDR04gd2hpY2ggDQppczo8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWdu
PWxlZnQ+PFNQQU4gY2xhc3M9NzUxNTgzMTA2LTE3MDgyMDExPjxGT05UIGNvbG9yPSMwMDAwZmYg
DQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8
RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03NTE1ODMxMDYtMTcwODIwMTE+PEZP
TlQgY29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+KiBUaGUgcG9zc2li
aWxpdHkgdG8gbG9nIHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIA0KZm9yIGxlZ2FsIHN0b3Jh
Z2UgcHVycG9zZXMgaW4gY2FzZSB0aGUgc2VydmVyIGRvZXMgbm90IGltcGxlbWVudCBSRkM2MzAy
LiBJZiANClJGQzYzMDIgaXMgbGFyZ2VseSBkZXBsb3llZCwgdGhlbiB0aGlzIGZlYXR1cmUgaXMg
bm90IA0KbmVlZGVkLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVm
dD48U1BBTiBjbGFzcz03NTE1ODMxMDYtMTcwODIwMTE+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNp
emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYg
ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc1MTU4MzEwNi0xNzA4MjAxMT48Rk9OVCBj
b2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGVyZSBhcmUgYSBsb3Qg
b2YgdHJhZGUtb2ZmcyBhbmQgdGhlcmUgaXMgbm8gDQp1bml2ZXJzYWwgYW5zd2VycyB0byB0aGVz
ZSB0cmFkZS1vZmZzLiA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl
ZnQ+PFNQQU4gY2xhc3M9NzUxNTgzMTA2LTE3MDgyMDExPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpz
aXplPTIgZmFjZT0iQ291cmllciBOZXciPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElW
IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03NTE1ODMxMDYtMTcwODIwMTE+PEZPTlQg
Y29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Q2hlZXJzLDwvRk9OVD48
L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03NTE1ODMx
MDYtMTcwODIwMTE+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5l
dyI+TWVkPC9GT05UPjwvU1BBTj48L0RJVj48QlI+DQo8RElWIGRpcj1sdHIgbGFuZz1mciBjbGFz
cz1PdXRsb29rTWVzc2FnZUhlYWRlciBhbGlnbj1sZWZ0Pg0KPEhSIHRhYkluZGV4PS0xPg0KPEZP
TlQgc2l6ZT0yIGZhY2U9VGFob21hPjxCPkRlJm5ic3A7OjwvQj4gUWlvbmcgW21haWx0bzpiaW5n
eHVlcmVAZ21haWwuY29tXSANCjxCUj48Qj5FbnZvecOpJm5ic3A7OjwvQj4gbWFyZGkgMTYgYW/D
u3QgMjAxMSAxODoyOTxCUj48Qj7DgCZuYnNwOzo8L0I+IEJPVUNBREFJUiANCk1vaGFtZWQgT0xO
Qy9OQUQvVElQPEJSPjxCPkNjJm5ic3A7OjwvQj4gTmVqYyDFoGtvYmVybmU7IHNvZnR3aXJlc0Bp
ZXRmLm9yZzsgDQpkcmFmdC1vcGVyYXRvcnMtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0
aW9uQHRvb2xzLmlldGYub3JnPEJSPjxCPk9iamV0Jm5ic3A7OjwvQj4gDQpSZTogW1NvZnR3aXJl
c10gDQpkcmFmdC1vcGVyYXRvcnMtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uPEJS
PjwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjwvRElWPkhpLCBNZWQsIGFuZCBOZWpjLA0KPERJVj48
QlI+PC9ESVY+DQo8RElWPlBsZWFzZSBzZWUgaW5saW5lLjxCUj4NCjxESVYgY2xhc3M9Z21haWxf
cXVvdGU+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQ7
IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiANCmNsYXNzPWdt
YWlsX3F1b3RlPg0KICA8RElWIGNsYXNzPWltPjxCUj5Zb3UgaW5kZWVkIGxvb3NlIGFncmVzc2l2
ZSBzaGFybmlnIHJhdGlvLCBidXQgeW91IGhhdmUgDQogIHNvbWV3aGF0IG1vcmU8QlI+ZmxleGli
bGUgYWRkcmVzc2luZy4gQWxzbywgdGhlIENQRXMgY2FuIGJlIHRoZW4gcmVhbGx5IHNpbXBsZSAN
CiAgZGV2aWNlcyw8QlI+ZXhjbHVkaW5nIGFueSBvZiB0aGUgTkFQVCBmdW5jdGlvbmFsaXR5LCBk
b2luZyBvbmx5IHN0YXRlbGVzcyANCiAgZW5jYXBzdWxhdGlvbi48QlI+SG93ZXZlciwgd2hhdCB5
b3UgbG9vc2UvZ2FpbiBpcyBpcnJlbGV2YW50IGZvciBteSBwb2ludC4gSSANCiAgdGhpbmsgdGhp
czxCUj5zZWN0aW9uIHNob3VsZCBiZSBtb2RpZmllZCBpbiBhIHdheSBsaWtlIHRoZSBsb2dnaW5n
IHNlY3Rpb24gb3IgDQogIGFueTxCUj5vdGhlciBhcHByb3ByaWF0ZSB3YXksIHdoaWNoIGV4cGxh
aW5zLCB0aGF0IHRoaXMgaXMgbm90IHRoZSBiZW5lZml0IA0KICBvZjxCUj50aGUgc3RhdGVsZXNz
IG5hdHVyZSwgYnV0IHJhdGhlciB0aGUgYmVuZWZpdCBvZiB0aGUgc3RhdGljIHBvcnQgDQogIGFs
bG9jYXRpb24uPEJSPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+DQo8RElWPltRaW9uZ106ICsxIEFn
cmVlLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRF
Ui1MRUZUOiAjY2NjIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElO
Ry1MRUZUOiAxZXgiIA0KY2xhc3M9Z21haWxfcXVvdGU+DQogIDxESVYgY2xhc3M9aW0+PC9ESVY+
TWVkOiBZb3VyIHBvaW50IGlzIHZhbGlkIGFuZCB0aGUgdGV4dCBzaG91bGQgYmUgdXBkYXRlZCAN
CiAgYWNjb3JkaW5nbHkuIE15IGNvbW1lbnQgYWltcyB0byBzaG93IHRoYXQgdGhlIGNvbXBhcmlz
b24gaXMgbm90IHNvIHRoYXQgDQogIHRyaXZpYWwuIFdlIGNhbiBjbGFpbSB0aGUgc3RhdGVmdWwg
d2l0aCBwb3J0IHJhbmdlcyBjYW4gcHJvdmlkZSBzaW1pbGFyIA0KICBmZWF0dXJlcyBhcyB0aGUg
c3RhdGVsZXNzIG9yIHRoZSBiaW5kaW5nIG1vZGUgYnV0IHdlIGFsd2F5cyBmb3JnZXQgdG8gbWVu
dGlvbiANCiAgdGhpcyBsZWFkIHRvIGxvb3NlIG9uZSBvZiB0aGUgY2hhcmFjdGVyaXN0aWNzIG9m
IHRoZSBzdGF0ZWZ1bC4gV2UgY2FwdHVyZWQgYSANCiAgc2ltaWxhciBkaXNjdXNzaW9uIGluIDxB
IA0KICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVyYXRvcnMtc29m
dHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTAxI3NlY3Rpb24tNC4yIiANCiAgdGFyZ2V0
PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVyYXRvcnMtc29mdHdp
cmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTAxI3NlY3Rpb24tNC4yPC9BPjo8QlI+PC9CTE9D
S1FVT1RFPg0KPERJVj48QlI+PC9ESVY+DQo8RElWPltRaW9uZ106IEluIG91ciBzaXR1YXRpb24s
IHdlIGRvIG5vdCByZWdhcmQgYWdncmVzc2l2ZSZuYnNwO3NoYXJpbmcgDQpyYXRpbyZuYnNwO2Fz
IGEgdml0YWwgaW1wb3J0YW50IGZlYXR1cmUgc2luY2UgdGhlIHN0YXRpYyBwb3J0IG11bHRpcGxl
eCByYXRpbyBpcyANCmFscmVhZHkgZW5vdWdoIGZvciB1cy4gQmVzaWRlcywgZXZlbiBmb3Igc2Vz
c2lvbi1iYXNlZCBDR04gbGlrZSBkcy1saXRlLCB3ZSANCndvdWxkIHN0aWxsIHByZWZlciB0byBw
cmUtZGVmaW5lIHBvcnQtcmFuZ2UgZm9yIGN1c3RvbWVycyBiZWNhdXNlIG91ciANCmNlbnRyYWxp
emVkIGxvZyBzZXJ2ZXIgY2FuIG5vdCBkZWFsIHdpdGggbWFzc2l2ZSBzZXNzaW9uLWJhc2VkIGxv
ZyBldmVudHMuIFNvIGl0IA0Kc2VlbXMgbW9yZSByZWFzb25hYmxlIGZvciB1cyB0byBhZG9wdCBz
dGF0aWMgcG9ydCBhcnJhbmdlbWVudCB3aGljaCBjYW4gbGFyZ2VseSANCnJlZHVjZSB0aGUgbG9n
Jm5ic3A7dm9sdW1lLjwvRElWPg0KPERJVj48QlI+PC9ESVY+DQo8RElWPkJlc3QgcmVnYXJkczwv
RElWPg0KPERJVj48QlI+PC9ESVY+DQo8RElWPlFpb25nIFN1bjwvRElWPg0KPERJVj4mbmJzcDs8
L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZDsg
TUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIA0KY2xhc3M9Z21h
aWxfcXVvdGU+PEJSPiI1LjIuICZuYnNwO1BvcnQgVXRpbGlzYXRpb24gRWZmaWNpZW5jeTxCUj48
QlI+Jm5ic3A7IA0KICBDR04tYmFzZWQgc29sdXRpb25zLCBiZWNhdXNlIHRoZXkgY2FuIGR5bmFt
aWNhbGx5IGFzc2lnbiBwb3J0cyw8QlI+Jm5ic3A7IA0KICBwcm92aWRlIGJldHRlciBJUHY0IGFk
ZHJlc3Mgc2hhcmluZyByYXRpbyB0aGFuIHN0YXRlbGVzcyBzb2x1dGlvbnM8QlI+Jm5ic3A7IA0K
ICAoaS5lLiwgY2FuIHNoYXJlIHRoZSBzYW1lIElQIGFkZHJlc3MgYW1vbmcgYSBsYXJnZXIgbnVt
YmVyIG9mPEJSPiZuYnNwOyANCiAgY3VzdG9tZXJzKS4gJm5ic3A7Rm9yIFNlcnZpY2UgUHJvdmlk
ZXJzIHdobyBkZXNpcmUgYW4gYWdncmVzc2l2ZSANCiAgSVB2NDxCUj4mbmJzcDsgYWRkcmVzcyBz
aGFyaW5nLCBhIENHTi1iYXNlZCBzb2x1dGlvbiBpcyBtb3JlIHN1aXRhYmxlIHRoYW4gDQogIHRo
ZTxCUj4mbmJzcDsgc3RhdGVsZXNzLjxCUj48QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtJZiBhIFNl
cnZpY2UgUHJvdmlkZXIgDQogIGFkb3B0cyBhbiBhZ2dyZXNzaXZlIGFkZHJlc3Mgc2hhcmluZyBy
YXRpbyw8QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtpdCBpcyANCiAgbGlrZWx5IHRvIGJlIGF0dGVt
cHRlZCBieSBlbmZvcmNpbmcgYSBOQVQgcG9ydCBvdmVybG9hZGluZzxCUj4mbmJzcDsgJm5ic3A7
IA0KICAmbmJzcDttb2RlIGFuZCBhcyBhIGNvbnNlcXVlbmNlIHNvbWUgYXBwbGljYXRpb25zIHdp
bGwgYnJlYWsuPEJSPjxCUj4mbmJzcDsgDQogIEhvd2V2ZXIsIGFzIG1vcmUgYW5kIG1vcmUgaG9z
dHMgYmVjb21lIGR1YWwtc3RhY2sgZW5hYmxlZCwgdGhlIG5lZWQ8QlI+Jm5ic3A7IA0KICBmb3Ig
cG9ydHMgaW4gSVB2NCBpcyBsaWtlbHkgdG8gZGVjcmVhc2UuICZuYnNwO1RoZSBpbnN1cmFuY2Ug
dG8gaGF2ZSANCiAgdGhlPEJSPiZuYnNwOyBmdWxsIHNldCBvZiA2NEsgcG9ydHMgcGVyIGhvc3Qg
d2lsbCBiZSBvbmUgb2YgdGhlIGluY2VudGl2ZXMgdG8gDQogIGhhdmU8QlI+Jm5ic3A7IHRoZW0g
SVB2NiBjYXBhYmxlLiAmbmJzcDtNb3Jlb3ZlciwgU2VydmljZSBQcm92aWRlcnMgc2hvdWxkIA0K
ICBvZmZsb2FkIHNvbWU8QlI+Jm5ic3A7IHNlcnZpY2VzIHRvIElQdjYgKGUuZy4sIEROUywgVm9J
UCkuIjxCUj4NCiAgPERJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJViANCiAgY2xhc3M9aDU+PEJS
PjxCUj48QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPEJSPlNvZnR3aXJlcyANCiAgbWFpbGluZyBsaXN0PEJSPjxBIA0KICBocmVmPSJtYWlsdG86
U29mdHdpcmVzQGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcyIgDQogIHRh
cmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2ly
ZXM8L0E+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9ESVY+PC9CT0RZ
PjwvSFRNTD4NCg==

--_000_94C682931C08B048B7A8645303FDC9F33E54A62DD9PUEXCB1Bnante_--

From xiaohong.deng@orange-ftgroup.com  Wed Aug 17 00:30:39 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6A21F8A67 for ; Wed, 17 Aug 2011 00:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.153
X-Spam-Level: 
X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[AWL=0.211,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDZX4zyyQHPu for ; Wed, 17 Aug 2011 00:30:38 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B0A9721F8A57 for ; Wed, 17 Aug 2011 00:30:37 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 801007B800D; Wed, 17 Aug 2011 09:32:46 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 6EC0E7B8004; Wed, 17 Aug 2011 09:32:46 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 17 Aug 2011 09:31:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC5CAF.AA31A434"
Date: Wed, 17 Aug 2011 15:31:22 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195B53D@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Thread-Index: Acxcr6mvLNs26fv4RQKjJqPCkUDMZQ==
References: <4E4A4569.8030706@skoberne.net><94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr><4E4A5BEE.3030708@skoberne.net><94C682931C08B048B7A8645303FDC9F33E54A62CFC@PUEXCB1B.nanterre.francetelecom.fr> 
From: 
To: , 
X-OriginalArrivalTime: 17 Aug 2011 07:31:26.0282 (UTC) FILETIME=[AC1262A0:01CC5CAF]
Cc: softwires@ietf.org, draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 07:30:39 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC5CAF.AA31A434
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

IA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCglGcm9tOiBRaW9uZyBb
bWFpbHRvOmJpbmd4dWVyZUBnbWFpbC5jb21dIA0KCVNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE3
LCAyMDExIDEyOjI5IEFNDQoJVG86IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMtTkFELVRJUA0KCUNj
OiBzb2Z0d2lyZXNAaWV0Zi5vcmc7IGRyYWZ0LW9wZXJhdG9ycy1zb2Z0d2lyZS1zdGF0ZWxlc3Mt
NHY2LW1vdGl2YXRpb25AdG9vbHMuaWV0Zi5vcmcNCglTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10g
ZHJhZnQtb3BlcmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlvbg0KCQ0KCQ0K
CUhpLCBNZWQsIGFuZCBOZWpjLCANCg0KCVBsZWFzZSBzZWUgaW5saW5lLg0KCQ0KDQoNCgkJWW91
IGluZGVlZCBsb29zZSBhZ3Jlc3NpdmUgc2hhcm5pZyByYXRpbywgYnV0IHlvdSBoYXZlIHNvbWV3
aGF0IG1vcmUNCgkJZmxleGlibGUgYWRkcmVzc2luZy4gQWxzbywgdGhlIENQRXMgY2FuIGJlIHRo
ZW4gcmVhbGx5IHNpbXBsZSBkZXZpY2VzLA0KCQlleGNsdWRpbmcgYW55IG9mIHRoZSBOQVBUIGZ1
bmN0aW9uYWxpdHksIGRvaW5nIG9ubHkgc3RhdGVsZXNzIGVuY2Fwc3VsYXRpb24uDQoJCUhvd2V2
ZXIsIHdoYXQgeW91IGxvb3NlL2dhaW4gaXMgaXJyZWxldmFudCBmb3IgbXkgcG9pbnQuIEkgdGhp
bmsgdGhpcw0KCQlzZWN0aW9uIHNob3VsZCBiZSBtb2RpZmllZCBpbiBhIHdheSBsaWtlIHRoZSBs
b2dnaW5nIHNlY3Rpb24gb3IgYW55DQoJCW90aGVyIGFwcHJvcHJpYXRlIHdheSwgd2hpY2ggZXhw
bGFpbnMsIHRoYXQgdGhpcyBpcyBub3QgdGhlIGJlbmVmaXQgb2YNCgkJdGhlIHN0YXRlbGVzcyBu
YXR1cmUsIGJ1dCByYXRoZXIgdGhlIGJlbmVmaXQgb2YgdGhlIHN0YXRpYyBwb3J0IGFsbG9jYXRp
b24uIA0KCQkgDQoJCVhpYW9ob25nOiBJdCdzIGEgdHJhZGUtb2ZmIGJldHdlZW4gZWZmaWNpZW5j
eSBvZiBsb2cgYW5kIGFkZHJlc3Mgc2hhcmluZyByYXRpbyBmb3Igc3RhdGVmdWwgc29sdXRpb24u
IEkgZG8gYWdyZWUgaXQncyBhIGdvb2QgdHJhZGUtb2ZmIGZvciBzdGF0ZWZ1bCwgYnV0IG9uZSBt
b3JlIGdvb2Qgb3B0aW9uIGZvciBzdGF0ZWZ1bCBkb2Vzbid0IG1ha2Ugc3RhdGVsZXNzIGxlc3Mg
dmFsdWFibGUsIHNvIG5laXRoZXIgc2VlIGl0IGlzIHRvbyBtdWNoIHRvIGRvIHdpdGggc3RhdGVs
ZXNzIG1vdGl2YXRpb24sICBub3IgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IHRvIGRvY3VtZW50IHRv
byBtdWNoIGluIHRoZSBzdGF0ZWxlc3MgbW90aXZhdGlvbiBkcmFmdCwgYXMgbG9uZyBhcyB0aGUg
c3RhdGVsZXNzIG1vdGl2YXRpb24gaXMgbW9yZSBmb2N1c2VkIG9uIHRoZSByZXF1aXJlbWVudCBv
ZiBzdGF0ZWxlc3Mgb3RoZXIgdGhhbiBjb21wYXJpc29ucyBiZXR3ZWVuIHRoZSB0d28uDQoNCgkJ
DQoJCQ0KCQkgDQoNCglbUWlvbmddOiArMSBBZ3JlZS4gDQoJIA0KCSANCgkgDQoNCgkJTWVkOiBZ
b3VyIHBvaW50IGlzIHZhbGlkIGFuZCB0aGUgdGV4dCBzaG91bGQgYmUgdXBkYXRlZCBhY2NvcmRp
bmdseS4gTXkgY29tbWVudCBhaW1zIHRvIHNob3cgdGhhdCB0aGUgY29tcGFyaXNvbiBpcyBub3Qg
c28gdGhhdCB0cml2aWFsLiBXZSBjYW4gY2xhaW0gdGhlIHN0YXRlZnVsIHdpdGggcG9ydCByYW5n
ZXMgY2FuIHByb3ZpZGUgc2ltaWxhciBmZWF0dXJlcyBhcyB0aGUgc3RhdGVsZXNzIG9yIHRoZSBi
aW5kaW5nIG1vZGUgYnV0IHdlIGFsd2F5cyBmb3JnZXQgdG8gbWVudGlvbiB0aGlzIGxlYWQgdG8g
bG9vc2Ugb25lIG9mIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHN0YXRlZnVsLiBXZSBjYXB0
dXJlZCBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1vcGVyYXRvcnMtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTAxI3NlY3Rp
b24tNC4yOg0KCQkNCg0KCQ0KCQ0KCVtRaW9uZ106IEluIG91ciBzaXR1YXRpb24sIHdlIGRvIG5v
dCByZWdhcmQgYWdncmVzc2l2ZSBzaGFyaW5nIHJhdGlvIGFzIGEgdml0YWwgaW1wb3J0YW50IGZl
YXR1cmUgc2luY2UgdGhlIHN0YXRpYyBwb3J0IG11bHRpcGxleCByYXRpbyBpcyBhbHJlYWR5IGVu
b3VnaCBmb3IgdXMuIEJlc2lkZXMsIGV2ZW4gZm9yIHNlc3Npb24tYmFzZWQgQ0dOIGxpa2UgZHMt
bGl0ZSwgd2Ugd291bGQgc3RpbGwgcHJlZmVyIHRvIHByZS1kZWZpbmUgcG9ydC1yYW5nZSBmb3Ig
Y3VzdG9tZXJzIGJlY2F1c2Ugb3VyIGNlbnRyYWxpemVkIGxvZyBzZXJ2ZXIgY2FuIG5vdCBkZWFs
IHdpdGggbWFzc2l2ZSBzZXNzaW9uLWJhc2VkIGxvZyBldmVudHMuIFNvIGl0IHNlZW1zIG1vcmUg
cmVhc29uYWJsZSBmb3IgdXMgdG8gYWRvcHQgc3RhdGljIHBvcnQgYXJyYW5nZW1lbnQgd2hpY2gg
Y2FuIGxhcmdlbHkgcmVkdWNlIHRoZSBsb2cgdm9sdW1lLiANCgkgDQoJWGlhb2hvbmc6IEkgc3Vw
cG9zZSB5b3UncmUgc2F5aW5nIGl0IGlzIHZhbHVhYmxlIHRvIHlvdSB0byBoYXZlIHRoaXMgdHJh
ZGUtb2ZmIGZvciBzdGF0ZWZ1bC4gUGVyc29uYWxseSwgSSBkbyBzZWUgaXRzIHZhbHVlIHRvbywg
YnV0IGFnYWluIGl0IGlzIG5vdCB0b28gbXVjaCB0byBkbyB3aXRoIHN0YXRlbGVzcyBtb3RpdmF0
aW9uLiANCg0KCSANCg0KCUNoZWVycywNCg0KCVhpYW9ob25nIA0KDQoJIA0KCQ0KCQ0KCUJlc3Qg
cmVnYXJkcw0KDQoJUWlvbmcgU3VuDQoJIA0KDQoNCgkJIjUuMi4gIFBvcnQgVXRpbGlzYXRpb24g
RWZmaWNpZW5jeQ0KCQkNCgkJICBDR04tYmFzZWQgc29sdXRpb25zLCBiZWNhdXNlIHRoZXkgY2Fu
IGR5bmFtaWNhbGx5IGFzc2lnbiBwb3J0cywNCgkJICBwcm92aWRlIGJldHRlciBJUHY0IGFkZHJl
c3Mgc2hhcmluZyByYXRpbyB0aGFuIHN0YXRlbGVzcyBzb2x1dGlvbnMNCgkJICAoaS5lLiwgY2Fu
IHNoYXJlIHRoZSBzYW1lIElQIGFkZHJlc3MgYW1vbmcgYSBsYXJnZXIgbnVtYmVyIG9mDQoJCSAg
Y3VzdG9tZXJzKS4gIEZvciBTZXJ2aWNlIFByb3ZpZGVycyB3aG8gZGVzaXJlIGFuIGFnZ3Jlc3Np
dmUgSVB2NA0KCQkgIGFkZHJlc3Mgc2hhcmluZywgYSBDR04tYmFzZWQgc29sdXRpb24gaXMgbW9y
ZSBzdWl0YWJsZSB0aGFuIHRoZQ0KCQkgIHN0YXRlbGVzcy4NCgkJDQoJCSAgICAgSWYgYSBTZXJ2
aWNlIFByb3ZpZGVyIGFkb3B0cyBhbiBhZ2dyZXNzaXZlIGFkZHJlc3Mgc2hhcmluZyByYXRpbywN
CgkJICAgICBpdCBpcyBsaWtlbHkgdG8gYmUgYXR0ZW1wdGVkIGJ5IGVuZm9yY2luZyBhIE5BVCBw
b3J0IG92ZXJsb2FkaW5nDQoJCSAgICAgbW9kZSBhbmQgYXMgYSBjb25zZXF1ZW5jZSBzb21lIGFw
cGxpY2F0aW9ucyB3aWxsIGJyZWFrLg0KCQkNCgkJICBIb3dldmVyLCBhcyBtb3JlIGFuZCBtb3Jl
IGhvc3RzIGJlY29tZSBkdWFsLXN0YWNrIGVuYWJsZWQsIHRoZSBuZWVkDQoJCSAgZm9yIHBvcnRz
IGluIElQdjQgaXMgbGlrZWx5IHRvIGRlY3JlYXNlLiAgVGhlIGluc3VyYW5jZSB0byBoYXZlIHRo
ZQ0KCQkgIGZ1bGwgc2V0IG9mIDY0SyBwb3J0cyBwZXIgaG9zdCB3aWxsIGJlIG9uZSBvZiB0aGUg
aW5jZW50aXZlcyB0byBoYXZlDQoJCSAgdGhlbSBJUHY2IGNhcGFibGUuICBNb3Jlb3ZlciwgU2Vy
dmljZSBQcm92aWRlcnMgc2hvdWxkIG9mZmxvYWQgc29tZQ0KCQkgIHNlcnZpY2VzIHRvIElQdjYg
KGUuZy4sIEROUywgVm9JUCkuIg0KCQkNCg0KDQoNCg0KCQlfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KCQlTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQoJCVNv
ZnR3aXJlc0BpZXRmLm9yZw0KCQlodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3NvZnR3aXJlcw0KCQkNCg0KDQo=

------_=_NextPart_001_01CC5CAF.AA31A434
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2
LjAwLjYwMDAuMTcwOTUiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPERJViBkaXI9
bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48
L0ZPTlQ+Jm5ic3A7PC9ESVY+PEJSPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURE
SU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4
IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VI
ZWFkZXIgbGFuZz16aC1jbiBkaXI9bHRyIGFsaWduPWxlZnQ+DQogIDxIUiB0YWJJbmRleD0tMT4N
CiAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBRaW9uZyBbbWFpbHRvOmJp
bmd4dWVyZUBnbWFpbC5jb21dIA0KICA8QlI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgQXVndXN0
IDE3LCAyMDExIDEyOjI5IEFNPEJSPjxCPlRvOjwvQj4gQk9VQ0FEQUlSIA0KICBNb2hhbWVkIE9M
TkMtTkFELVRJUDxCUj48Qj5DYzo8L0I+IHNvZnR3aXJlc0BpZXRmLm9yZzsgDQogIGRyYWZ0LW9w
ZXJhdG9ycy1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb25AdG9vbHMuaWV0Zi5vcmc8
QlI+PEI+U3ViamVjdDo8L0I+IA0KICBSZTogW1NvZnR3aXJlc10gDQogIGRyYWZ0LW9wZXJhdG9y
cy1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb248QlI+PC9GT05UPjxCUj48L0RJVj4N
CiAgPERJVj48L0RJVj5IaSwgTWVkLCBhbmQgTmVqYywNCiAgPERJVj48QlI+PC9ESVY+DQogIDxE
SVY+UGxlYXNlIHNlZSBpbmxpbmUuPEJSPg0KICA8RElWIGNsYXNzPWdtYWlsX3F1b3RlPg0KICA8
QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCiAgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4
OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQi
Pg0KICAgIDxESVYgY2xhc3M9aW0+PEJSPllvdSBpbmRlZWQgbG9vc2UgYWdyZXNzaXZlIHNoYXJu
aWcgcmF0aW8sIGJ1dCB5b3UgaGF2ZSANCiAgICBzb21ld2hhdCBtb3JlPEJSPmZsZXhpYmxlIGFk
ZHJlc3NpbmcuIEFsc28sIHRoZSBDUEVzIGNhbiBiZSB0aGVuIHJlYWxseSANCiAgICBzaW1wbGUg
ZGV2aWNlcyw8QlI+ZXhjbHVkaW5nIGFueSBvZiB0aGUgTkFQVCBmdW5jdGlvbmFsaXR5LCBkb2lu
ZyBvbmx5IA0KICAgIHN0YXRlbGVzcyBlbmNhcHN1bGF0aW9uLjxCUj5Ib3dldmVyLCB3aGF0IHlv
dSBsb29zZS9nYWluIGlzIGlycmVsZXZhbnQgZm9yIA0KICAgIG15IHBvaW50LiBJIHRoaW5rIHRo
aXM8QlI+c2VjdGlvbiBzaG91bGQgYmUgbW9kaWZpZWQgaW4gYSB3YXkgbGlrZSB0aGUgDQogICAg
bG9nZ2luZyBzZWN0aW9uIG9yIGFueTxCUj5vdGhlciBhcHByb3ByaWF0ZSB3YXksIHdoaWNoIGV4
cGxhaW5zLCB0aGF0IHRoaXMgDQogICAgaXMgbm90IHRoZSBiZW5lZml0IG9mPEJSPnRoZSBzdGF0
ZWxlc3MgbmF0dXJlLCBidXQgcmF0aGVyIHRoZSBiZW5lZml0IG9mIHRoZSANCiAgICBzdGF0aWMg
cG9ydCBhbGxvY2F0aW9uLjxTUEFOIGNsYXNzPTQ3MDI3NDYwNi0xNzA4MjAxMT48Rk9OVCBmYWNl
PeWui+S9kyANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwv
RElWPg0KICAgIDxESVYgY2xhc3M9aW0+PFNQQU4gY2xhc3M9NDcwMjc0NjA2LTE3MDgyMDExPjwv
U1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWIGNsYXNzPWltPjxTUEFOIGNsYXNzPTQ3MDI3NDYw
Ni0xNzA4MjAxMT4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgc3R5bGU9Ik1BUkdJTjog
MGNtIDBjbSAwcHQ7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBo
YW4iIA0KICAgIGFsaWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCiAgICBzdHlsZT0iRk9OVC1T
SVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IOWui+S9kyI+WGlhb2hvbmc6IEl0
J3MmbmJzcDthIA0KICAgIHRyYWRlLW9mZiBiZXR3ZWVuIGVmZmljaWVuY3kgb2YgbG9nIGFuZCBh
ZGRyZXNzIHNoYXJpbmcgcmF0aW8gZm9yIHN0YXRlZnVsIA0KICAgIHNvbHV0aW9uLiBJIGRvIGFn
cmVlIGl0J3MgYSBnb29kIHRyYWRlLW9mZiBmb3Igc3RhdGVmdWwsIGJ1dCBvbmUgbW9yZSBnb29k
IA0KICAgIG9wdGlvbiBmb3Igc3RhdGVmdWwgZG9lc24ndCBtYWtlIHN0YXRlbGVzcyBsZXNzIHZh
bHVhYmxlLCANCiAgICBzbyZuYnNwO25laXRoZXImbmJzcDtzZWUgaXQgaXMgdG9vIG11Y2ggdG8g
ZG8gd2l0aCBzdGF0ZWxlc3MgDQogICAgbW90aXZhdGlvbiwmbmJzcDsmbmJzcDtub3IgdGhpbmsg
aXQgaXMmbmJzcDtuZWNlc3NhcnkgdG8mbmJzcDtkb2N1bWVudCB0b28gDQogICAgbXVjaCBpbiZu
YnNwO3RoZSBzdGF0ZWxlc3MgbW90aXZhdGlvbiBkcmFmdCwgYXMgbG9uZyBhcyB0aGUgc3RhdGVs
ZXNzIA0KICAgIG1vdGl2YXRpb24gaXMgbW9yZSBmb2N1c2VkIG9uIHRoZSByZXF1aXJlbWVudCBv
ZiBzdGF0ZWxlc3Mgb3RoZXIgdGhhbiANCiAgICBjb21wYXJpc29ucyBiZXR3ZWVuIHRoZSB0d28u
PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgbXNv
LWZvbnQta2VybmluZzogMHB0Ij48P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyANCiAgICA9
ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIC8+PG86cD48L286cD48
L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgICBzdHlsZT0iTUFSR0lOOiAw
Y20gMGNtIDBwdDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhh
biIgDQogICAgYWxpZ249bGVmdD48Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNpemU9
Mj48L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9G
T05UPjwvU1BBTj48QlI+PEJSPiZuYnNwOzwvUD48L0RJVj48L0JMT0NLUVVPVEU+DQogIDxESVY+
W1Fpb25nXTogKzEgQWdyZWUuPFNQQU4gY2xhc3M9NDcwMjc0NjA2LTE3MDgyMDExPjxGT05UIGZh
Y2U95a6L5L2TIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwv
RElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ3MDI3NDYwNi0xNzA4MjAxMT48Rk9OVCBmYWNlPeWu
i+S9kyBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N
CiAgPERJVj48U1BBTiBjbGFzcz00NzAyNzQ2MDYtMTcwODIwMTE+PEZPTlQgZmFjZT3lrovkvZMg
Y29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxE
SVY+PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPiZuYnNwOzwv
RElWPg0KICA8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCiAgc3R5bGU9IlBBRERJTkct
TEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAx
cHggc29saWQiPg0KICAgIDxESVYgY2xhc3M9aW0+PC9ESVY+TWVkOiBZb3VyIHBvaW50IGlzIHZh
bGlkIGFuZCB0aGUgdGV4dCBzaG91bGQgYmUgdXBkYXRlZCANCiAgICBhY2NvcmRpbmdseS4gTXkg
Y29tbWVudCBhaW1zIHRvIHNob3cgdGhhdCB0aGUgY29tcGFyaXNvbiBpcyBub3Qgc28gdGhhdCAN
CiAgICB0cml2aWFsLiBXZSBjYW4gY2xhaW0gdGhlIHN0YXRlZnVsIHdpdGggcG9ydCByYW5nZXMg
Y2FuIHByb3ZpZGUgc2ltaWxhciANCiAgICBmZWF0dXJlcyBhcyB0aGUgc3RhdGVsZXNzIG9yIHRo
ZSBiaW5kaW5nIG1vZGUgYnV0IHdlIGFsd2F5cyBmb3JnZXQgdG8gDQogICAgbWVudGlvbiB0aGlz
IGxlYWQgdG8gbG9vc2Ugb25lIG9mIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHN0YXRlZnVs
LiBXZSANCiAgICBjYXB0dXJlZCBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBpbiA8QSANCiAgICBocmVm
PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVyYXRvcnMtc29mdHdpcmUtc3Rh
dGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTAxI3NlY3Rpb24tNC4yIiANCiAgICB0YXJnZXQ9X2JsYW5r
Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW9wZXJhdG9ycy1zb2Z0d2lyZS1zdGF0
ZWxlc3MtNHY2LW1vdGl2YXRpb24tMDEjc2VjdGlvbi00LjI8L0E+OjxCUj48L0JMT0NLUVVPVEU+
DQogIDxESVY+PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjxC
Uj48L0RJVj4NCiAgPERJVj5bUWlvbmddOiBJbiBvdXIgc2l0dWF0aW9uLCB3ZSBkbyBub3QgcmVn
YXJkIGFnZ3Jlc3NpdmUmbmJzcDtzaGFyaW5nIA0KICByYXRpbyZuYnNwO2FzIGEgdml0YWwgaW1w
b3J0YW50IGZlYXR1cmUgc2luY2UgdGhlIHN0YXRpYyBwb3J0IG11bHRpcGxleCByYXRpbyANCiAg
aXMgYWxyZWFkeSBlbm91Z2ggZm9yIHVzLiBCZXNpZGVzLCBldmVuIGZvciBzZXNzaW9uLWJhc2Vk
IENHTiBsaWtlIGRzLWxpdGUsIHdlIA0KICB3b3VsZCBzdGlsbCBwcmVmZXIgdG8gcHJlLWRlZmlu
ZSBwb3J0LXJhbmdlIGZvciBjdXN0b21lcnMgYmVjYXVzZSBvdXIgDQogIGNlbnRyYWxpemVkIGxv
ZyBzZXJ2ZXIgY2FuIG5vdCBkZWFsIHdpdGggbWFzc2l2ZSBzZXNzaW9uLWJhc2VkIGxvZyBldmVu
dHMuIFNvIA0KICBpdCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgZm9yIHVzIHRvIGFkb3B0IHN0YXRp
YyBwb3J0IGFycmFuZ2VtZW50IHdoaWNoIGNhbiANCiAgbGFyZ2VseSByZWR1Y2UgdGhlIGxvZyZu
YnNwO3ZvbHVtZS48U1BBTiBjbGFzcz00NzAyNzQ2MDYtMTcwODIwMTE+PEZPTlQgDQogIGZhY2U9
5a6L5L2TIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQog
IDxESVY+PFNQQU4gY2xhc3M9NDcwMjc0NjA2LTE3MDgyMDExPjxGT05UIGZhY2U95a6L5L2TIGNv
bG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElW
PjxTUEFOIGNsYXNzPTQ3MDI3NDYwNi0xNzA4MjAxMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0K
ICBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2lu
YXRpb246IHdpZG93LW9ycGhhbiIgDQogIGFsaWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCiAg
c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiDlrovkvZM7
IG1zby1mb250LWtlcm5pbmc6IDBwdCI+WGlhb2hvbmc6IA0KICBJIHN1cHBvc2UgeW91J3JlIHNh
eWluZyBpdCBpcyB2YWx1YWJsZSB0byB5b3UgdG8gaGF2ZSB0aGlzIHRyYWRlLW9mZiBmb3IgDQog
IHN0YXRlZnVsLiBQZXJzb25hbGx5LCBJIGRvIHNlZSBpdHMgdmFsdWUgdG9vLCBidXQgYWdhaW4g
aXQgaXMgbm90IHRvbyBtdWNoIHRvIA0KICBkbyB3aXRoIHN0YXRlbGVzcyBtb3RpdmF0aW9uLjxT
UEFOIA0KICBjbGFzcz00NzAyNzQ2MDYtMTcwODIwMTE+Jm5ic3A7PC9TUEFOPjwvU1BBTj48L1A+
DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFRF
WFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIA0KICBhbGlnbj1s
ZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBi
bHVlOyBGT05ULUZBTUlMWTog5a6L5L2TOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxTUEFOIA0K
ICBjbGFzcz00NzAyNzQ2MDYtMTcwODIwMTE+PC9TUEFOPjwvU1BBTj4mbmJzcDs8L1A+PFNQQU4g
bGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQt
RkFNSUxZOiDlrovkvZM7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PFNQQU4gDQogIGNsYXNzPTQ3
MDI3NDYwNi0xNzA4MjAxMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9y
cGhhbiIgDQogIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDcwMjc0NjA2LTE3MDgyMDExPkNoZWVy
cyw8L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBj
bSAwY20gMHB0OyBURVhULUFMSUdOOiBsZWZ0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFu
IiANCiAgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NzAyNzQ2MDYtMTcwODIwMTE+PC9TUEFOPjxT
UEFOIA0KICBjbGFzcz00NzAyNzQ2MDYtMTcwODIwMTE+WGlhb2hvbmc8L1NQQU4+Jm5ic3A7PC9T
UEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xh
c3M9NDcwMjc0NjA2LTE3MDgyMDExPjxGT05UIGZhY2U95a6L5L2TIGNvbG9yPSMwMDAwZmYgDQog
IHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U95a6L
5L2TIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+QmVzdCBy
ZWdhcmRzPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPlFpb25nIFN1bjwvRElWPg0K
ICA8RElWPiZuYnNwOzwvRElWPg0KICA8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCiAg
c3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JE
RVItTEVGVDogI2NjYyAxcHggc29saWQiPjxCUj4iNS4yLiANCiAgICAmbmJzcDtQb3J0IFV0aWxp
c2F0aW9uIEVmZmljaWVuY3k8QlI+PEJSPiZuYnNwOyBDR04tYmFzZWQgc29sdXRpb25zLCBiZWNh
dXNlIA0KICAgIHRoZXkgY2FuIGR5bmFtaWNhbGx5IGFzc2lnbiBwb3J0cyw8QlI+Jm5ic3A7IHBy
b3ZpZGUgYmV0dGVyIElQdjQgYWRkcmVzcyANCiAgICBzaGFyaW5nIHJhdGlvIHRoYW4gc3RhdGVs
ZXNzIHNvbHV0aW9uczxCUj4mbmJzcDsgKGkuZS4sIGNhbiBzaGFyZSB0aGUgc2FtZSANCiAgICBJ
UCBhZGRyZXNzIGFtb25nIGEgbGFyZ2VyIG51bWJlciBvZjxCUj4mbmJzcDsgY3VzdG9tZXJzKS4g
Jm5ic3A7Rm9yIFNlcnZpY2UgDQogICAgUHJvdmlkZXJzIHdobyBkZXNpcmUgYW4gYWdncmVzc2l2
ZSBJUHY0PEJSPiZuYnNwOyBhZGRyZXNzIHNoYXJpbmcsIGEgDQogICAgQ0dOLWJhc2VkIHNvbHV0
aW9uIGlzIG1vcmUgc3VpdGFibGUgdGhhbiB0aGU8QlI+Jm5ic3A7IA0KICAgIHN0YXRlbGVzcy48
QlI+PEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgYSBTZXJ2aWNlIFByb3ZpZGVyIGFkb3B0cyBh
biANCiAgICBhZ2dyZXNzaXZlIGFkZHJlc3Mgc2hhcmluZyByYXRpbyw8QlI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDtpdCBpcyBsaWtlbHkgdG8gYmUgDQogICAgYXR0ZW1wdGVkIGJ5IGVuZm9yY2luZyBh
IE5BVCBwb3J0IG92ZXJsb2FkaW5nPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7bW9kZSANCiAgICBh
bmQgYXMgYSBjb25zZXF1ZW5jZSBzb21lIGFwcGxpY2F0aW9ucyB3aWxsIGJyZWFrLjxCUj48QlI+
Jm5ic3A7IEhvd2V2ZXIsIGFzIA0KICAgIG1vcmUgYW5kIG1vcmUgaG9zdHMgYmVjb21lIGR1YWwt
c3RhY2sgZW5hYmxlZCwgdGhlIG5lZWQ8QlI+Jm5ic3A7IGZvciBwb3J0cyANCiAgICBpbiBJUHY0
IGlzIGxpa2VseSB0byBkZWNyZWFzZS4gJm5ic3A7VGhlIGluc3VyYW5jZSB0byBoYXZlIHRoZTxC
Uj4mbmJzcDsgDQogICAgZnVsbCBzZXQgb2YgNjRLIHBvcnRzIHBlciBob3N0IHdpbGwgYmUgb25l
IG9mIHRoZSBpbmNlbnRpdmVzIHRvIA0KICAgIGhhdmU8QlI+Jm5ic3A7IHRoZW0gSVB2NiBjYXBh
YmxlLiAmbmJzcDtNb3Jlb3ZlciwgU2VydmljZSBQcm92aWRlcnMgc2hvdWxkIA0KICAgIG9mZmxv
YWQgc29tZTxCUj4mbmJzcDsgc2VydmljZXMgdG8gSVB2NiAoZS5nLiwgRE5TLCBWb0lQKS4iPEJS
Pg0KICAgIDxESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWIA0KICAgIGNsYXNzPWg1PjxC
Uj48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxCUj5Tb2Z0d2lyZXMgDQogICAgbWFpbGluZyBsaXN0PEJSPjxBIA0KICAgIGhyZWY9Im1h
aWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmciPlNvZnR3aXJlc0BpZXRmLm9yZzwvQT48QlI+PEEgDQog
ICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMi
IA0KICAgIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9zb2Z0d2lyZXM8L0E+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9E
SVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo=

------_=_NextPart_001_01CC5CAF.AA31A434--

From xiaohong.deng@orange-ftgroup.com  Wed Aug 17 00:56:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5F221F8B3F for ; Wed, 17 Aug 2011 00:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.756
X-Spam-Level: 
X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=0.493,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaNlyJGkA5q4 for ; Wed, 17 Aug 2011 00:56:36 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id CE68921F8B39 for ; Wed, 17 Aug 2011 00:56:31 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4C7948C0006; Wed, 17 Aug 2011 09:58:12 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 424B38B8006; Wed, 17 Aug 2011 09:58:12 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 17 Aug 2011 09:57:16 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Aug 2011 15:57:03 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0195B55A@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0195B4D3@ch-mailsrv.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Thread-Index: Acxcs0AnwLYilhopTLefHa3L1cBfJg==
References: <4E4A4569.8030706@skoberne.net><94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr><1F763FB8-E528-4080-92A7-E9C983B7425B@laposte.net><94C682931C08B048B7A8645303FDC9F33E54A62D6B@PUEXCB1B.nanterre.francetelecom.fr><7998F52F-58E8-4E7D-8327-D64666AF7EFE@laposte.net> <0962B0BEF842A24191AD9BE41A8DD2FC0195B4D3@ch-mailsrv.rd.francetelecom.fr>
From: 
To: , , 
X-OriginalArrivalTime: 17 Aug 2011 07:57:16.0977 (UTC) FILETIME=[485BAA10:01CC5CB3]
Cc: draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 07:56:37 -0000

More comments below.=20

|-----Original Message-----
|From: DENG Xiaohong ESP/PEK=20
|Sent: Wednesday, August 17, 2011 12:10 PM
|To: despres.remi@laposte.net; softwires@ietf.org
|Cc: draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
|Subject: Re: [Softwires]=20
|draft-operators-softwire-stateless-4v6-motivation
|
|Hi all,=20
|
||-----Original Message-----
||From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]
||Sent: Wednesday, August 17, 2011 12:28 AM
||To: Softwires-wg
||Cc: draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
||Subject: Re: [Softwires]
||draft-operators-softwire-stateless-4v6-motivation
||
||Hello all,
||
||It appears that confirming on this list the vote made in Quebec would=20
||be useful.
|
|Agreed.
|
||Please see below.
||
||Le 16 ao=FBt 2011 =E0 17:03,
||
|| a =E9crit :
||
||>  ... there was a vote in favour of adopting this document as
||a WG document but as you know this vote should be confirmed in the ML.
||
||I have seen drafts becoming WG drafts after votes during=20
|meetings but,=20
||fair enough, let's see if, after the unanimous vote in the meeting,=20
||there are serious objections to it now.
||
||
||> A call for adoption should normally be issued by the chairs
||according to the IETF procedure.
||>=20
||> As for the content of the next iteration of the document, we
||have two options so far:
||>=20
||> (1) Put back some sections which have been removed in -02,
||
||Support.
||Some of them were worth having, IMHO.
||
||> add a new section to discuss dynamic vs. static,
||
||> handle the comments received from J. Arkko, etc.=20
||
||Sure.
||Doing this while the draft is already a WG draft seems to me normal=20
||after the vote result (but no objection to doing it right=20
|away if found=20
||better.
||
||> Or
||>=20
||> 2) An alternative structure has been proposed off-line by A.=20
||Durand: discuss dynamic vs. static and stateful vs. dynamic.
||
||Offline discussions are of course completely free, and=20
|useful, but a WG=20
||consensus can only be built in the open, i.e. on the WG mailing list.
||I am aware of at least part of the offline discussion you=20
|refer to, and=20
||therefore suppose you meant "dynamic vs static AND stateful vs=20
||_stateless_".
||Several pointed out, in that discussion, that the stateless & dynamic=20
||combination doesn't really make sense.



If we look deep into  every combinations of statless/stateful =
allocations for stateless/stateful=20
solutions, first would come up with the stateful allocations with =
stateful solution that's what we discussed
 in the previous emails of this thread, so no more comments  on this =
point, and if you want see more,
 please refer to previous notes where there are plenty of it. ;)

One more new production would be stateless allocations with stateless =
solution, which may make no
 sense at the first glance, but it might also be interesting to  =
consider it as an option, when stateful port=20
allocation doesn't satisfied the port needs. This is something proposed =
by Satoru Matsushima off-line=20
when we're talking about restricted port sets compatibility with  UPnP =
applications and/or even odd pairs
 requirement for other applications, but hopefully it could also be =
addressed by statelss address/port mapping=20
if it would accept a consensus that past applications compatibility is =
worth to be addressed - IMHO it is. ;)


Yet, both analysis above do not have too much do with stateless =
*motivation* draft, IMHO.=20


||In any case, this discussion hasn't been pursued on the WG list.
||
||> The analysis would elaborate the pros and cons of each
||solution (static stateless, static stateful, dynamic stateful,...).=20
||This document would be an analysis document and not a motivation=20
||document anymore. This document has no milestone in the charter IMHO.=20

Exactly, as the stateless motivation is more focused on the requirement =
of stateless other than comparisons
between the two, less comparisons and more *motivations* makes more =
senses to me.


||Note the charter mentions the
||following:=20
||>=20
||> "Aug 2011 - Adopt stateless legacy IPv4 solution motivation
||document as a Working Group document"
||>=20
||>=20
||> I personally think the first option is straightforward
||
||So do I, =3D> +1
||That is IMHO the only acceptable option in view of the vote result.
|
|+1
|Prefer the first option, as "discussion dynamic allocation vs.=20
|static allocation"
|in a new section other than discussing on the mailing list=20
|sounds to me the more practical and efficient one to meet the=20
|Chater milstone.

A slight correction to my previous comment here: It is fair enough
to mention in a new section indicating that  both dynamic allocation=20
and static allocation are applicable to stateless and statful =
approaches,=20
but not focus too much on anlysis the combinations of them, as the
reasons above.

Cheers,
Xiaohong



|
|Cheers,
|Xiaohong
|
||
||
||> but I'm open to the opinions of the working group members on
||how to proceed.
||
||Let's see then.
||
||Regards to all,
||RD
||
||
||>=20
||> Cheers,
||> Med
||>=20
||>=20
||> -----Message d'origine-----
||> De : R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] Envoy=E9 :=20
||mardi 16
||> ao=FBt 2011 16:30 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc
||Skoberne;
||> draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org;
||> softwires@ietf.org Objet : Re: [Softwires]=20
||> draft-operators-softwire-stateless-4v6-motivation
||>=20
||> Hi Med,
||>=20
||> At the last meeting, a vote was taken to decide whether this
||draft should become a WG draft.
||> The answer has been a crystal clear yes, with the common
||understanding that, as such, it would have to be improved and=20
|competed=20
||based on WG reactions.
||>=20
||> IMHO, making it a WG document asap will facilitate
||discussions like this one: thet will point to the right document.
||>=20
||> Is there any sort term plan to do what was approved?
||>=20
||> Kind regards,
||> RD
||>=20
||>=20
||>=20
||>=20
||> Le 16 ao=FBt 2011 =E0 13:48,
||
|| a =E9crit :
||>=20
||>> Dear Nejc,
||>>=20
||>> Thank you for the comments. Please see my answers inline.
||>>=20
||>> Cheers,
||>> Med
||>>=20
||>>=20
||>> -----Message d'origine-----
||>> De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
||>> De la part de Nejc Skoberne Envoy=E9 : mardi 16 ao=FBt 2011 12:25 =
=C0 :=20
||>> draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org
||>> Cc : softwires@ietf.org
||>> Objet : [Softwires]
||draft-operators-softwire-stateless-4v6-motivation
||>>=20
||>> Hello,
||>>=20
||>> I have some comments on your draft, see inline.
||>>=20
||>> Regards,
||>> Nejc
||>>=20
||>> ---------------
||>>  2. Terminology
||>>=20
||>>=20
||>>=20
||>>  This document makes use of the following terms:
||>>=20
||>>  Stateful 4/6 solution  (or stateful solution in short): denotes a
||>>                      solution where the network maintains
||user-session
||>>                      states relying on the activation of a NAT
||>>                      function in the Service Providers' network
||>>                      [I-D.ietf-behave-lsn-requirements].  The NAT
||>>                      function is responsible for sharing
||the same IPv4
||>>                      address among several subscribers and
||to maintain
||>>                      user-session state.
||>>=20
||>>  Stateless  4/6 solution  (or stateless solution in short):=20
||denotes a
||>>                      solution which does not require any
||user-session
||>>                      state (seeSection 2.3 of [RFC1958]) to be
||>>                      maintained by any IP address sharing
||function in
||>>                      the Service Provider's network.  This
||category of
||>>                      solutions assumes a dependency between an IPv6
||>>                      prefix and IPv4 address.  In an IPv4 address
||>>                      sharing context, dedicated functions
||are required
||>>                      to be enabled in the CPE router to=20
|restrict the
||>>                      source IPv4 port numbers.  Within this
||document,
||>>                      "port set" and "port range" terms are used
||>>                      interchangeably.
||>>=20
||>> [NS: If we consider a "stateful A+P" solution, we don't=20
|necessarily=20
||>> have a dependency between an IPv6 prefix and IPv4 address.=20
|Also, we=20
||>> don't have any user-session state in the Service=20
|Provider's network.
||>>=20
||>> Med: Fully agree. FWIW, this is what we called "Binding
||Table A+P Mode" in
||http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4.
||>>=20
||>> We do, however, have some user state (in order to do stateful=20
||>> tunneling, for example). Maybe this is included in
||"user-session" in
||>> your terminology, but then I think it would be appropriate
||to define
||>> the term "user-session" clearly.]
||>>=20
||>> Med: We assumed the definition of state as mentioned in
||RFC1958; but I agree the terminology should be much more clearer.
||>>=20
||>> ...
||>>=20
||>>      3.1.5. Bandwidth Saving
||>>=20
||>>=20
||>>=20
||>>  In same particular network scenarios (e.g., wireless network ),=20
||>> spectrum is very valuable and scarce resource.  Service providers=20
||>> usually wish to eliminate unnecessary overhead to save bandwidth=20
||>> consumption in such environment.  Service providers need to
||consider
||>> optimizing the form of packet processing when=20
|encapsulation is used.
||>>  Since existing header compression techniques are stateful, it is=20
||>> expected that stateless solution minimize overhead
||introduced by the
||>> solution.
||>>=20
||>> [NS: I don't understand this section, but that may be just me.
||>> Maybe is there a better way to explain the point?]
||>>=20
||>> Med: We have several co-authors who are not either in
||favour or maintaining this section. This text will be removed.
||>>=20
||>> ...
||>>=20
||>>=20
||>>      3.3.1. Implicit Host Identification
||>>=20
||>>=20
||>>=20
||>>  Service Providers do not offer only IP connectivity services but=20
||>> also  added value services (a.k.a., internal services).  Upgrading=20
||>> these  services to be IPv6-enabled is not sufficient because of=20
||>> legacy  devices.  In some deployments, the delivery of these=20
||>> added-value  services relies on implicit identification mechanism=20
||>> based on the  source IPv4 address.  Due to address sharing,
||implicit
||>> identification  will fail
||>> [I-D.ietf-intarea-shared-addressing-issues]; replacing  implicit=20
||>> identification with explicit authentication will be seen as  a non=20
||>> acceptable service regression by the end users (less
||Quality of  Experience (QoE)).
||>>=20
||>>  When a stateless solution is deployed, implicit
||identification for
||>> internal services is likely to be easier to implement: the
||implicit
||>> identification should be updated to take into account the
||port range
||>> and the IPv4 address.  Techniques as those analyzed in=20
||>> [I-D.boucadair-intarea-nat-reveal-analysis] are not
||required for the
||>> delivery of these internal services if a stateless solution is=20
||>> deployed.
||>>=20
||>> [NS: I don't think this is true only for stateless=20
|solutions. If we=20
||>> have a stateful solution with static port allocation (as
||you mention
||>> in section 3.1.3), then implementing such an implicit host=20
||>> identification which uses also port information, is doable=20
|as well.]
||>>=20
||>> Med: I Agree. But then you loose other benefits of the
||stateful: have an aggressive address sharing ratio.
||>> _______________________________________________
||>> Softwires mailing list
||>> Softwires@ietf.org
||>> https://www.ietf.org/mailman/listinfo/softwires
||>=20
||>=20
||
||
||
||
|
|

From ichiroumakino@gmail.com  Wed Aug 17 01:07:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874CA21F8A35 for ; Wed, 17 Aug 2011 01:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2gjQMVLiR6H for ; Wed, 17 Aug 2011 01:07:54 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6670621F86AC for ; Wed, 17 Aug 2011 01:07:54 -0700 (PDT)
Received: by wwf5 with SMTP id 5so486713wwf.13 for ; Wed, 17 Aug 2011 01:08:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wq6yk+8uCPUhNdSEVn7ZNxUDCo7Tr+axx5fciU1INZg=; b=m5ZARZAaJEBbbylEQPYEV7xBimGsKNtZI+eCV3GaSUM+H9hGkFUPiUwF7PWL7U82Y9 G30seNQ2xidCsy0CKtvBXjzBpSUyR6pZD8XE3oi0XJ7UUTmQVd19RKsBlm5sn6RnWrZl O3NUtxRalzjn9PD14MV+h/S59QILLPrcsKblY=
Received: by 10.216.68.72 with SMTP id k50mr4076689wed.102.1313568523804; Wed, 17 Aug 2011 01:08:43 -0700 (PDT)
Received: from dhcp-10-61-100-10.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id em16sm694170wbb.33.2011.08.17.01.08.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Aug 2011 01:08:41 -0700 (PDT)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
Date: Wed, 17 Aug 2011 10:08:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org>
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net>
To: Alain Durand 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org list" , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 08:07:55 -0000

Alain,

> Following-up on the Quebec meeting, we would like to organize an =
interim meeting end of September.
> We will focus on so-called stateless solutions and other remaining =
business in the wg (multicast. mibs,...)
> that require more time than we usually have during a normal IETF =
meeting.
> The format will be a 2 day intensive meeting, with white board =
discussions, similar to what we did in the early days of the working =
group.
>=20
> We've got an offer to host the meeting in Beijin on Sept. 26-27th or =
27-28th (right after the Boradband forum meeting in Shanghai).
> Yong and I would like to make a decision soon, please send us email =
directly if you intend to come and tell us which set of dates is more =
convenient.
> Please respond by August 11th, we will formally announce the meeting =
with the logistic information end of next week.

a real life meeting to hash out the stateless solutions is a splendid =
idea.
do you need any help to get this arranged? I'm sure we or others can =
host it too; doodle poll for the dates?
it would be good to have at least 4 weeks notice for travel arrangements =
to be made.

cheers,
Ole=

From despres.remi@laposte.net  Wed Aug 17 01:44:43 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77BD21F884C for ; Wed, 17 Aug 2011 01:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.938
X-Spam-Level: 
X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCorY8YjQCEY for ; Wed, 17 Aug 2011 01:44:43 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 22D5F21F883A for ; Wed, 17 Aug 2011 01:44:43 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id DB48870003ED; Wed, 17 Aug 2011 10:45:32 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id 89D987000443; Wed, 17 Aug 2011 10:45:25 +0200 (CEST)
X-SFR-UUID: 20110817084525564.89D987000443@msfrf2111.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org>
Date: Wed, 17 Aug 2011 10:45:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net> <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org>
To: Alain Durand , Yong Cui 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org list" , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 08:44:43 -0000

Le 17 ao=FBt 2011 =E0 10:08, Ole Troan a =E9crit :
...
>> Yong and I would like to make a decision soon, please send us email =
directly if you intend to come and tell us which set of dates is more =
convenient.
>> Please respond by August 11th, we will formally announce the meeting =
with the logistic information end of next week.
>=20
> a real life meeting to hash out the stateless solutions is a splendid =
idea.

But an expensive one too!

Since the announced deadline for practical organization has already been =
passed, I personally believe that a better approach is to get enough =
Softwire time in Taipei for enough WG work.

In the mean time, it looks like the mailing-list is working well.

Last point, hashing out solutions will be more efficient in Taipei if =
based on available drafts at that time.

Regards,
RD




From nejc@skoberne.net  Wed Aug 17 02:46:02 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1701821F8AFC for ; Wed, 17 Aug 2011 02:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.187
X-Spam-Level: 
X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-1qWp0krBqB for ; Wed, 17 Aug 2011 02:46:01 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1E21F8AA8 for ; Wed, 17 Aug 2011 02:45:59 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 4B016227875E; Wed, 17 Aug 2011 11:46:46 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F3DDiINWsG0; Wed, 17 Aug 2011 11:46:44 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 92F04227875D; Wed, 17 Aug 2011 11:46:44 +0200 (CEST)
Message-ID: <4E4B8E04.1010103@skoberne.net>
Date: Wed, 17 Aug 2011 10:46:44 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Naoki Matsuhira 
References: <6D93B4F87F5667499B9104BA798D637A046A13F2@STAFFMBX-1.lunet.lboro.ac.uk> <6D93B4F87F5667499B9104BA798D637A0C5FE3B25F@STAFFMBX-1.lunet.lboro.ac.uk> <4E49228F.2040705@skoberne.net> <4E4A17CD.8030807@jp.fujitsu.com> <4E4A925D.2000000@skoberne.net> <4E4B228B.4060305@jp.fujitsu.com>
In-Reply-To: <4E4B228B.4060305@jp.fujitsu.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] SA46T questions
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 09:46:02 -0000

Dear Naoki,

> However, in my honest opinion, I am confused a little about target 
> technology in softwire.

Well, me too. This is why I am trying very hard lately to understand
things first.

> SA46T and SA46T-AS is just a tunneling technology.
> 
> The other side, in my understanding, DS-Lite and 4rd is combination 
> technology of tunneling and NAT.

For DS-Lite, I agree. However, for 4rd NAT is not necessary. As 4rd
draft says:

"Although 4rd is designed primarily to support IPv4 deployment to a 
customer site (such as a residential home network) by an SP, it can
equally be applied to an individual host acting as a CE router."

So if you have a host, acting as a CE router, supporting 4rd technology,
you don't need NAPT44 in it. So in this regard, it is completely the
same as SA46T-AS. At least this is how I understand it.

> In my understanding, DS-Lite is CGN + Tunneling combination, so CGN + 
> SA46T combination may possible. I think this combination may say DS-Lite.

I wouldn't use DS-Lite in any other context, since it is now an
independent Proposed Standard. It is as it is. The tunneling there is
clearly specified.

> To similar, 4rd make NAT in CPE assumption. I don't understand 4rd is 
> just tunneling function, or combination with CPE NAT. In the standing 
> point of SA46T-AS, as you point out, SA46T-AS + CPE NAT combination may 
> possible.

See above.

> Both DS-Lite and 4rd is the combination technology for access network. 
> However, I also have interests to apply SA46T-AS to the server environment.

Well, not necessarily, why? It's just a technology, I can't see why you
couldn't use it in an enterprise as well?

> I think your trade-off analysis is very important. If adding 
> SA46T/SA46T-AS technology to your analysis table, I think "DS-Lite + 
> SA46T" and "SA46T-AS + CPE NAT" is appropriate.

Well, I don't agree with DS-Lite + SA46T, I would rather make it
"SA46T + CGN". However, since your SA46T-AS already is an address sharing
solution and it mentions NAT in one of the scenarios (in the draft), I don't
think it needs to be combined with anything. So in the end, we have (regarding
SA46T):

- SA46T (tunneling only)
- SA46T+CGN (NAPT44 placed in the core)
- SA46T-AS (directly implemented in the host or NAPT44 placed in the CPE)

Do you agree?

Nejc


From nejc@skoberne.net  Wed Aug 17 03:23:24 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B54F21F8AFF for ; Wed, 17 Aug 2011 03:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.188
X-Spam-Level: 
X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-qcq9IPwZ1z for ; Wed, 17 Aug 2011 03:23:24 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id C9C9121F8559 for ; Wed, 17 Aug 2011 03:23:23 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id D709A227875E; Wed, 17 Aug 2011 12:24:13 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAppXaTJJbS6; Wed, 17 Aug 2011 12:24:13 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 8FEA92278115; Wed, 17 Aug 2011 12:24:13 +0200 (CEST)
Message-ID: <4E4B96CB.2020004@skoberne.net>
Date: Wed, 17 Aug 2011 11:24:11 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: draft-murakami-softwire-4v6-translation@tools.ietf.org
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" 
Subject: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 10:23:24 -0000

Dear authors,

as far as I can understand your draft, you make NAPT44 in the CE obligatory.
However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight 
4over6 A+P
drafts. So I suggest that you make it optional in 4via6 translation as 
well, since it might
be desired for some environments to connect hosts supporting 4via6 
translation
technology, directly to the IPv6 network. In this case, you don't need 
the translator.

Thanks,
Nejc

From simon.perreault@viagenie.ca  Wed Aug 17 06:08:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B5221F8B53 for ; Wed, 17 Aug 2011 06:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LETnYjSiAF4 for ; Wed, 17 Aug 2011 06:08:55 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 46F3621F8B52 for ; Wed, 17 Aug 2011 06:08:55 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 06FDB20E56 for ; Wed, 17 Aug 2011 09:09:40 -0400 (EDT)
Message-ID: <4E4BBD94.6090204@viagenie.ca>
Date: Wed, 17 Aug 2011 09:09:40 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net> <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org>
In-Reply-To: <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 13:08:55 -0000

On 2011-08-17 04:08, Ole Troan wrote:
> it would be good to have at least 4 weeks notice for travel arrangements to be made.

Not only would it be good, it is required.

http://www.ietf.org/iesg/statement/interim-meetings.html

If we are to meet on September 15-16, the meeting must be announced today.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From phdgang@gmail.com  Wed Aug 17 06:35:59 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FFC21F8B9A for ; Wed, 17 Aug 2011 06:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.332
X-Spam-Level: 
X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb5U+DZ90oMi for ; Wed, 17 Aug 2011 06:35:58 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E98621F8B63 for ; Wed, 17 Aug 2011 06:35:58 -0700 (PDT)
Received: by qyk34 with SMTP id 34so2018193qyk.10 for ; Wed, 17 Aug 2011 06:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EX9wu8CyvmKoKOWcB0IJJ1ECfQeHAUhbMjRhljc9f/o=; b=VI7Lfat6vVYUuuTpGdZhYIqOYE8QbC6prshEuQ8yBfBd0MxTH83Vsn4oqBaK5B8ZEi 4OqyVEKG6fsHMRauwDeRh2VdxmFBjOsCX9YP7NMeBJb14ILD8NQG9ZO8Fh0eUpa+UwLb v2ACB6HHGQ80t+pwkelnxQJc73md3MlMJ5v0Y=
MIME-Version: 1.0
Received: by 10.52.65.168 with SMTP id y8mr547284vds.16.1313588208634; Wed, 17 Aug 2011 06:36:48 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Wed, 17 Aug 2011 06:36:48 -0700 (PDT)
In-Reply-To: <4E4B96CB.2020004@skoberne.net>
References: <4E4B96CB.2020004@skoberne.net>
Date: Wed, 17 Aug 2011 21:36:48 +0800
Message-ID: 
From: GangChen 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 13:35:59 -0000

Dear Nejc,

> as far as I can understand your draft, you make NAPT44 in the CE obligatory.

[Gang] Yes. This is to avoid the problem where there are applications
that attempt
to bind to specific ports that are not part of the allowed port range.

> However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight
> 4over6 A+P drafts.

[Gang] I guess this is always the case for port constrained mechanisms.

>So I suggest that you make it optional in 4via6 translation as
> well, since it might
> be desired for some environments to connect hosts supporting 4via6
> translation
> technology, directly to the IPv6 network. In this case, you don't need
> the translator.

[Gang] Could you help to elaborate the environment ?


Many thanks

Gang

From nejc@skoberne.net  Wed Aug 17 06:57:15 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A181721F84EC for ; Wed, 17 Aug 2011 06:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.115
X-Spam-Level: 
X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.184,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AAAYFQRv8EM for ; Wed, 17 Aug 2011 06:57:14 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8893D21F84EB for ; Wed, 17 Aug 2011 06:57:13 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id AFABA227875E; Wed, 17 Aug 2011 15:58:03 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+f5dCxd+MQW; Wed, 17 Aug 2011 15:58:02 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 59896227875D; Wed, 17 Aug 2011 15:58:02 +0200 (CEST)
Message-ID: <4E4BC8E9.4010703@skoberne.net>
Date: Wed, 17 Aug 2011 14:58:01 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: GangChen 
References: <4E4B96CB.2020004@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 13:57:15 -0000

Dear Gang,

>> as far as I can understand your draft, you make NAPT44 in the CE obligatory.
> 
> [Gang] Yes. This is to avoid the problem where there are applications
> that attempt
> to bind to specific ports that are not part of the allowed port range.

Well, if the application/operating system supports the 
standard/protocol/technology, then it should only bind to the port, which 
CPE would normally use to translate source ports of the packets. If there
is no such operating system/application, NAPT44 must be used, of course.

>> However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight
>> 4over6 A+P drafts.
> 
> [Gang] I guess this is always the case for port constrained mechanisms.

Of course. But you could support various scenarios in the scope of your draft,
not only the common "CPE" one. 

>> So I suggest that you make it optional in 4via6 translation as
>> well, since it might
>> be desired for some environments to connect hosts supporting 4via6
>> translation
>> technology, directly to the IPv6 network. In this case, you don't need
>> the translator.
> 
> [Gang] Could you help to elaborate the environment ?

Sure. I can imagine a Linux implementation of "4via6 translation
support". If enabled, the TCP/IP stack would only bind to specific ports 
(from the range). If you check the section III./C of the following paper: 

http://zhuyc.info/globecom08mivi.pdf

the authors propose a modification "to the system call related to bind()
in the socket library of the operating system".

Then I could just connect my home gateway-server directly to the ISPs
network, providing support for "4via6 translation" and that's it.

Also, I see is as a use case in non-ISP environments, where you could
have IPv6-only, but 4via6 enabled server networks, with servers supporting
"4via6 translation". Like SA46T-AS, for example.

The main advantage of all this is of course that the IPv4 address is then
natively configured on the (virtual) interface.

--

Other than that, I still am very curious what are the differences between
your draft and draft-xli-behave-divi-03. I would be very happy if you could
elaborate on that.

Thanks,
Nejc

From nejc@skoberne.net  Wed Aug 17 08:47:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76921F841D for ; Wed, 17 Aug 2011 08:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.131
X-Spam-Level: 
X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.168,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-YFYaxjcsSB for ; Wed, 17 Aug 2011 08:47:44 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 918C721F8AF0 for ; Wed, 17 Aug 2011 08:47:44 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 21BBD227875E for ; Wed, 17 Aug 2011 17:48:35 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNdX6zErPW4w for ; Wed, 17 Aug 2011 17:48:34 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 46AFC227875D for ; Wed, 17 Aug 2011 17:48:34 +0200 (CEST)
Message-ID: <4E4BE2D1.9050708@skoberne.net>
Date: Wed, 17 Aug 2011 16:48:33 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net> <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 15:47:45 -0000

>> a real life meeting to hash out the stateless solutions is a splendid idea.
>
> But an expensive one too!
>
> Since the announced deadline for practical organization has already been passed, I personally believe that a better approach is to get enough Softwire time in Taipei for enough WG work.

+1

Nejc

From tetsuya@ipinfusion.com  Wed Aug 17 10:06:36 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0860E21F8B46 for ; Wed, 17 Aug 2011 10:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.539
X-Spam-Level: 
X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnZHA-MdcnmB for ; Wed, 17 Aug 2011 10:06:35 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF4021F8B08 for ; Wed, 17 Aug 2011 10:06:35 -0700 (PDT)
Received: by yxp4 with SMTP id 4so988202yxp.31 for ; Wed, 17 Aug 2011 10:07:27 -0700 (PDT)
Received: by 10.42.105.146 with SMTP id v18mr951707ico.429.1313600846553; Wed, 17 Aug 2011 10:07:26 -0700 (PDT)
Received: from [192.168.0.6] (c-76-102-170-116.hsd1.ca.comcast.net [76.102.170.116]) by mx.google.com with ESMTPS id x18sm527683ibe.6.2011.08.17.10.07.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Aug 2011 10:07:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Tetsuya Murakami 
In-Reply-To: <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org>
Date: Wed, 17 Aug 2011 10:07:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <882DE537-BB49-40FD-A681-F0A5FE3C26AE@ipinfusion.com>
References: <5275FBA7-71FE-40B6-A4EE-AC9FEDCB41A9@juniper.net> <075E1A5E-42A6-41A9-8D1F-BE9F6BE1DBAC@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1244.3)
Cc: "softwires@ietf.org list" , Ralph Droms 
Subject: Re: [Softwires] Softwire Interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 17:06:36 -0000

Alain, Ole

On 2011/08/17, at 1:08, Ole Troan wrote:

> Alain,
>=20
>> Following-up on the Quebec meeting, we would like to organize an =
interim meeting end of September.
>> We will focus on so-called stateless solutions and other remaining =
business in the wg (multicast. mibs,...)
>> that require more time than we usually have during a normal IETF =
meeting.
>> The format will be a 2 day intensive meeting, with white board =
discussions, similar to what we did in the early days of the working =
group.
>>=20
>> We've got an offer to host the meeting in Beijin on Sept. 26-27th or =
27-28th (right after the Boradband forum meeting in Shanghai).
>> Yong and I would like to make a decision soon, please send us email =
directly if you intend to come and tell us which set of dates is more =
convenient.
>> Please respond by August 11th, we will formally announce the meeting =
with the logistic information end of next week.
>=20
> a real life meeting to hash out the stateless solutions is a splendid =
idea.
> do you need any help to get this arranged? I'm sure we or others can =
host it too; doodle poll for the dates?
> it would be good to have at least 4 weeks notice for travel =
arrangements to be made.

Agreed. The interim meeting to discuss about the stateless solution is a =
good idea. So, I prefer to have such a meeting in Sep. But I would like =
to fix the date for my travel arrangement. So, could you please announce =
the date and place for this interim meeting as soon as you could?

Thanks,
Tetsuya Murakami

> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From behcetsarikaya@yahoo.com  Wed Aug 17 15:28:59 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DBE21F8B80 for ; Wed, 17 Aug 2011 15:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.75
X-Spam-Level: 
X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-0.310,  BAYES_20=-0.74, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WwBcx1bAMjE for ; Wed, 17 Aug 2011 15:28:59 -0700 (PDT)
Received: from nm3-vm4.bullet.mail.ne1.yahoo.com (nm3-vm4.bullet.mail.ne1.yahoo.com [98.138.91.163]) by ietfa.amsl.com (Postfix) with SMTP id E08DB21F8B7F for ; Wed, 17 Aug 2011 15:28:58 -0700 (PDT)
Received: from [98.138.90.56] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2011 22:29:48 -0000
Received: from [98.138.89.164] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2011 22:29:48 -0000
Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 17 Aug 2011 22:29:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 572397.17317.bm@omp1020.mail.ne1.yahoo.com
Received: (qmail 3805 invoked by uid 60001); 17 Aug 2011 22:29:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313620188; bh=xzRIcOcFwWcQm+h51WEpLidr99zooAe6Vs5jik5rMGA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hIMP7IfeZdcs3CtWyIgiF364cAImwt+cCbrDaM4b845bak1X1o1rkSjnzZoQgKJGd6Gt75WRJCVCh7nMt15HKei15qKiPO0o1KZgSfOY7Bm1CiqLpMNEtvarSImlVLV4/Uu502hpu1WX7UtRCbWNAUM+BEaPyYhFq8L7eMLME/8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xAdnMaggwPqNHeFoe8iMDVv/1yBH6X1lekV1olTEIvBZwZQ2L6YIfPsAYXeqRIc0Xgns/ZkcX+SnbC5Ma5gnxCD/MZZGrrGau7UdYdRh6mMmCwzRqlb1rDUV3Ty0E0LCeqsc5vSV1kkzThyT0uKVsCIw09fEiLNdqy23L/tK7F4=;
X-YMail-OSG: m95NeLUVM1n2bKCmxMaQ1XwYamU5sEH5WsIFALx510WRpuY pBpJP5B9Vq7aIpb..aFA99Ba5Zc_o.HdwwFf__.R8272v9mR2alXakXaGUSx CrI7mPWDnzz69L7zfEtLODrBt4W4LnaM_9ktA6l8iqt4P31.zBjWVVD3d2DD kVd5k3ldmjDCrVDE7xpWGxpOwewy9dBX2ZAWFgHZD35FvL42eJrp_h80kOJ5 Kfn94yhVhJv8XkojVsimxfrtNSAE5uihQ408AP44EBNmDy50dn7caAwybrFj ROMVGUdRyyymYZTS4zdf0HsQ71J619WFYqpB3dv5ehx_gKzkMbgXCqALCxbW 1yj24.94xFujqwijc.xeng2Zhs1He0I0pZh_9MJuiBEqk0f9og6SLS7wy0Ve CCoMygeDTxGgwHW1C26.Rsas8HVBQejUlKYxwuiH9pBZ.vqIhqlRD61uG9M. 81lHUq5c-
Received: from [50.58.7.243] by web111408.mail.gq1.yahoo.com via HTTP; Wed, 17 Aug 2011 15:29:48 PDT
X-Mailer: YahooMailWebService/0.8.113.313619
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net>
Message-ID: <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com>
Date: Wed, 17 Aug 2011 15:29:48 -0700 (PDT)
From: Behcet Sarikaya 
To: =?utf-8?B?TmVqYyDFoGtvYmVybmU=?= , GangChen 
In-Reply-To: <4E4BC8E9.4010703@skoberne.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 22:28:59 -0000

=0A=0A> Dear Gang,=0A> =0A>>>  as far as I can understand your draft, you m=
ake NAPT44 in the CE =0A> obligatory.=0A>> =0A>>  [Gang] Yes. This is to av=
oid the problem where there are applications=0A>>  that attempt=0A>>  to bi=
nd to specific ports that are not part of the allowed port range.=0A> =0A> =
Well, if the application/operating system supports the =0A> standard/protoc=
ol/technology, then it should only bind to the port, which =0A> CPE would n=
ormally use to translate source ports of the packets. If there=0A> is no su=
ch operating system/application, NAPT44 must be used, of course.=0A> =0A>>>=
  However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight=0A>=
>>  4over6 A+P drafts.=0A>> =0A=0A>>  [Gang] I guess this is always the cas=
e for port constrained mechanisms.=0A> =0A> Of course. But you could suppor=
t various scenarios in the scope of your draft,=0A> not only the common "CP=
E" one. =0A> =0A=0A=0ANo.=0A=0Aa+p does not require a NAT44 to be used. Thi=
s is the case here (my guess) because NAT44 is commonly used in the current=
 CE routers and they don't wish to waste public IPv4 addresses.=0A=0AAlso N=
AT44 usage has nothing to do with the port range restrictions of the CE.=0A=
It is normal behavior of NAPT to select a different source port for the out=
going packet and the port range restriction comes into use here,=0ACE has t=
o use a source port from its range.=0A=0A=0ARegards,=0A=0ABehcet=0A

From nejc@skoberne.net  Wed Aug 17 15:35:29 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97B121F8AA8 for ; Wed, 17 Aug 2011 15:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.144
X-Spam-Level: 
X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9Go7+NeKdyF for ; Wed, 17 Aug 2011 15:35:29 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 01BAA21F8997 for ; Wed, 17 Aug 2011 15:35:29 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 2C12C227875C; Thu, 18 Aug 2011 00:36:20 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0j9e8lVWpVx; Thu, 18 Aug 2011 00:36:18 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 53B7122780BF; Thu, 18 Aug 2011 00:36:02 +0200 (CEST)
Message-ID: <4E4C4251.8020407@skoberne.net>
Date: Wed, 17 Aug 2011 23:36:01 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Behcet Sarikaya 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com>
In-Reply-To: <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , Behcet Sarikaya 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 22:35:30 -0000

Dear Behcet,

>> Of course. But you could support various scenarios in the scope of your draft,
>> not only the common "CPE" one.
>>
>
>
> No.
>
> a+p does not require a NAT44 to be used. This is the case here (my guess) because NAT44 is commonly used in the current CE routers and they don't wish to waste public IPv4 addresses.
>
> Also NAT44 usage has nothing to do with the port range restrictions of the CE.
> It is normal behavior of NAPT to select a different source port for the outgoing packet and the port range restriction comes into use here,
> CE has to use a source port from its range.

Sorry, but I didn't get your point. So you think that it is okay as it
is in the draft? You say, that A+P doesn't require a NAT44 to be used.
Exactly. That's why I think it would be great if this was stated in the
draft as well. Currently, NAT is obligatory in the draft.

Thanks,
Nejc

From satoru.matsushima@gmail.com  Wed Aug 17 20:42:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E08411E8090 for ; Wed, 17 Aug 2011 20:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV4OpHOi6fPz for ; Wed, 17 Aug 2011 20:42:36 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id B6E7611E808F for ; Wed, 17 Aug 2011 20:42:36 -0700 (PDT)
Received: by iye1 with SMTP id 1so2826738iye.27 for ; Wed, 17 Aug 2011 20:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UUvt2Q1SKrtrRoiQuFnsIxbN49OpBPSXl7/WBP2ah0Q=; b=j+4UWjXKsum8BGs+6PVUF2jU+bGOkBNHdaybDHk3Sn+Nm6Ikrfv0YYTYunuuMgYjPa QrvgTrXNxMt0aAnayXmLsSW8L1JF8FOv8ecnPAl/BvsHflXIOFupmvoKEsWbqP5EvIjn mZMKOuogRUiKloWJETfPuPWIGDZ0q2G9vYl40=
Received: by 10.43.131.138 with SMTP id hq10mr278516icc.181.1313639007927; Wed, 17 Aug 2011 20:43:27 -0700 (PDT)
Received: from [10.201.81.116] ([202.45.12.174]) by mx.google.com with ESMTPS id ib5sm1518876icc.12.2011.08.17.20.43.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Aug 2011 20:43:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=utf-8
From: Satoru Matsushima 
In-Reply-To: <4E4BC8E9.4010703@skoberne.net>
Date: Thu, 18 Aug 2011 12:43:22 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net>
To: =?utf-8?Q?Nejc_=C5=A0koberne?= 
X-Mailer: Apple Mail (2.1244.3)
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 03:42:37 -0000

Dear Nejc,


On 2011/08/17, at 22:58, Nejc =C5=A0koberne wrote:

> Dear Gang,
>=20
>>> as far as I can understand your draft, you make NAPT44 in the CE =
obligatory.
>>=20
>> [Gang] Yes. This is to avoid the problem where there are applications
>> that attempt
>> to bind to specific ports that are not part of the allowed port =
range.
>=20
> Well, if the application/operating system supports the=20
> standard/protocol/technology, then it should only bind to the port, =
which=20
> CPE would normally use to translate source ports of the packets. If =
there
> is no such operating system/application, NAPT44 must be used, of =
course.
>=20
>>> However, this is not the case for 4rd, dIVI, SA46T-AS and =
Lightweight
>>> 4over6 A+P drafts.
>>=20
>> [Gang] I guess this is always the case for port constrained =
mechanisms.
>=20
> Of course. But you could support various scenarios in the scope of =
your draft,
> not only the common "CPE" one.=20
>=20

We assume that all applications/OSes doesn't aware port restricted =
environment.=20
However, there is a case where an application would be allocated a port =
which is inside of port set occasionally.


>>> So I suggest that you make it optional in 4via6 translation as
>>> well, since it might
>>> be desired for some environments to connect hosts supporting 4via6
>>> translation
>>> technology, directly to the IPv6 network. In this case, you don't =
need
>>> the translator.
>>=20
>> [Gang] Could you help to elaborate the environment ?
>=20
> Sure. I can imagine a Linux implementation of "4via6 translation
> support". If enabled, the TCP/IP stack would only bind to specific =
ports=20
> (from the range). If you check the section III./C of the following =
paper:=20
>=20
> http://zhuyc.info/globecom08mivi.pdf
>=20
> the authors propose a modification "to the system call related to =
bind()
> in the socket library of the operating system".
>=20

The modification of 'to the system call related to bind()' is out of =
scope in our draft.


> Then I could just connect my home gateway-server directly to the ISPs
> network, providing support for "4via6 translation" and that's it.
>=20
> Also, I see is as a use case in non-ISP environments, where you could
> have IPv6-only, but 4via6 enabled server networks, with servers =
supporting
> "4via6 translation". Like SA46T-AS, for example.
>=20
> The main advantage of all this is of course that the IPv4 address is =
then
> natively configured on the (virtual) interface.
>=20
> --
>=20
> Other than that, I still am very curious what are the differences =
between
> your draft and draft-xli-behave-divi-03. I would be very happy if you =
could
> elaborate on that.

IMHO, address mapping rule and port distribution algorithm are the =
difference.
Let me think that if 4rd is configured with 'DomainIPv6Prefix =3D=3D =
2001:db8::/32', 'CEIPv6PrefixLength =3D=3D /72' and 'Domain4rdPrefix =3D=3D=
 0/0' for example. 40bits EA-bits are divided to 32bits IPv4 address =
part and 8bits port-set ID part. The length of the port-set ID expresses =
that address sharing ratio. The bits pattern of the port-set ID =
expresses port-set index of modulo operation, described in the divi.=20

cheers,
--satoru=

From washam.fan@gmail.com  Wed Aug 17 22:18:48 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3604121F85DA for ; Wed, 17 Aug 2011 22:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.334
X-Spam-Level: 
X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNrkfWB2mO3U for ; Wed, 17 Aug 2011 22:18:47 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7559D21F85C4 for ; Wed, 17 Aug 2011 22:18:47 -0700 (PDT)
Received: by wwf5 with SMTP id 5so1121524wwf.13 for ; Wed, 17 Aug 2011 22:19:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CizLlyMp0GJKWgfPL4R5tIRdU/fjYRmF1S/h1dIQO2w=; b=AvVHb50GA3L7/6sZOsO4EYCyCOk9WlT8yxvDGomBNP4ZjXa/BPqRCiFmQr3G8pcIxS ZP2GQZAad23D62CAiGM6AsOMB7NBXQM9rWbSN1UXeQVAYwXTz2Ckfviofgbr2G6rRWMd EKYmUBAWo9S0vHM0l28JTw1Bc3s/qD4QEIZeE=
MIME-Version: 1.0
Received: by 10.216.167.130 with SMTP id i2mr2655826wel.93.1313644779786; Wed, 17 Aug 2011 22:19:39 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Wed, 17 Aug 2011 22:19:39 -0700 (PDT)
In-Reply-To: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com> 
Date: Thu, 18 Aug 2011 13:19:39 +0800
Message-ID: 
From: Washam Fan 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 05:18:48 -0000

It seems to me, when delegating CE ipv6 prefix, a longest match might
be used. But when forwarding a IPv4 packet, a longest match is
useless, because domain 4rd prefixes don't overlap.

Thanks,
washam

2011/8/17 R=E9mi Despr=E9s :
>
> Le 17 ao=FBt 2011 =E0 03:10, Jacni Qin a =E9crit :
>
>> hi Remi,
>>
>> On 8/16/2011 4:27 PM, R=E9mi Despr=E9s wrote:
>>> ...
>>> As already discussed privately, I don't know realistic cases where two =
rules would have IPv6 or IPv4 overlapping prefixes.
>>> Consequently, it seems that "longest" match, while being permitted, doe=
sn't need to be a requirement.
>> If there are multiple ways for CPE to decide the IPv6 prefix, we have to=
 specify the order of priority. e.g., firstly check if there is any implica=
tion assigned along with the rules, no? then choose the "longest" match.
>> BTW, I think the longest match is not bad.
>
> It isn't bad, agreed, because it gives the same result as first match whe=
n prefixes don't overlap.
> It shouldn't however be made a _requirement_ if there is no well understo=
od use case because that additional complexity, small but real.
>
> Whether there may be realistic configurations where prefix overlap is use=
ful remains AFAIK an open question.
> I have serious doubts, but no time now to argue in details.
> IMHO, It's up to those who argue in favor of longest match to provide at =
least one realistic example (if there is one).
> Then we will agree (or discuss).
> Is that fair?
>
> Cheers,
> RD
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

From jacni@jacni.com  Wed Aug 17 23:11:21 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1686821F871E for ; Wed, 17 Aug 2011 23:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.278,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usygnLDPySdV for ; Wed, 17 Aug 2011 23:11:20 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 71FFA21F8713 for ; Wed, 17 Aug 2011 23:11:19 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 165C83801BC for ; Thu, 18 Aug 2011 02:12:10 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 870803400EC for ; Thu, 18 Aug 2011 14:12:06 +0800 (CST)
Received: from [172.26.54.148] (unknown [112.64.191.109]) by app (Coremail) with SMTP id +AWowJD7AAMerUxOpxlSAA--.55744S2; Thu, 18 Aug 2011 14:11:44 +0800 (CST)
Message-ID: <4E4CAD67.3000609@jacni.com>
Date: Thu, 18 Aug 2011 14:12:55 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Washam Fan 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-CM-TRANSID: +AWowJD7AAMerUxOpxlSAA--.55744S2
X-Coremail-Antispam: 1UD129KBjvJXoW7Kry7ZFy3AF45Aw4kJFWfGrg_yoW8Aw1kpF yxJF1YkFW8CF4fuwn7C3W8W3WYyry8XrnxJa4rKr9xKFy5Xrn5JF10krWYkFZ7ur4rJr1a vrWakFyrGryDuFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUcIb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM2kK64x0aVW7Gw IE548m6rI_Jw1UWr17M2kK6IIYrVAqxI0j4VAqrcv_Jw1UGr1DM2vj6xkI62vS6c8GOVWU tr1rJFyl5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I 8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28I cxkI7VAKI48JMxCIbVAxMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvf C2KfnxnUUI43ZEXa7IUnrMa5UUUUU==
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIBEko7lNBnxABSsU
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 06:11:21 -0000

On 8/18/2011 1:19 PM, Washam Fan wrote:
> It seems to me, when delegating CE ipv6 prefix, a longest match might
> be used. But when forwarding a IPv4 packet, a longest match is
> useless, because domain 4rd prefixes don't overlap.
Why? Sorry, I don't follow. The domain IPv4 prefixes can overlap.


Cheers,
Jacni

>
> Thanks,
> washam
>
> 2011/8/17 Rémi Després:
>> Le 17 aoűt 2011 ŕ 03:10, Jacni Qin a écrit :
>>
>>> hi Remi,
>>>
>>> On 8/16/2011 4:27 PM, Rémi Després wrote:
>>>> ...
>>>> As already discussed privately, I don't know realistic cases where two rules would have IPv6 or IPv4 overlapping prefixes.
>>>> Consequently, it seems that "longest" match, while being permitted, doesn't need to be a requirement.
>>> If there are multiple ways for CPE to decide the IPv6 prefix, we have to specify the order of priority. e.g., firstly check if there is any implication assigned along with the rules, no? then choose the "longest" match.
>>> BTW, I think the longest match is not bad.
>> It isn't bad, agreed, because it gives the same result as first match when prefixes don't overlap.
>> It shouldn't however be made a _requirement_ if there is no well understood use case because that additional complexity, small but real.
>>
>> Whether there may be realistic configurations where prefix overlap is useful remains AFAIK an open question.
>> I have serious doubts, but no time now to argue in details.
>> IMHO, It's up to those who argue in favor of longest match to provide at least one realistic example (if there is one).
>> Then we will agree (or discuss).
>> Is that fair?
>>
>> Cheers,
>> RD
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>


From despres.remi@laposte.net  Wed Aug 17 23:15:33 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2668F11E8091 for ; Wed, 17 Aug 2011 23:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Level: 
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.010,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIiIz1XdWhwM for ; Wed, 17 Aug 2011 23:15:32 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD1D21F8785 for ; Wed, 17 Aug 2011 23:15:31 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id A52C570000A7; Thu, 18 Aug 2011 08:16:23 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 9409E7000089; Thu, 18 Aug 2011 08:16:22 +0200 (CEST)
X-SFR-UUID: 20110818061622606.9409E7000089@msfrf2214.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 18 Aug 2011 08:16:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>  
To: Washam Fan 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 06:15:33 -0000

Hi Washam,

Le 18 ao=FBt 2011 =E0 07:19, Washam Fan a =E9crit :

> It seems to me, when delegating CE ipv6 prefix, a longest match might
> be used.

OK, but, again, if a realistic use case is available where longest match =
is indeed REQUIRED, there is no problem to impose longest match.
What is missing so far is this use case.=20

Regards,
RD

"It seems that perfection is attained not when there is nothing more to =
add, but when there is nothing more to remove" (A de St Exup=E9ry)=20





> But when forwarding a IPv4 packet, a longest match is
> useless, because domain 4rd prefixes don't overlap.
>=20
> Thanks,
> washam
>=20
> 2011/8/17 R=E9mi Despr=E9s :
>>=20
>> Le 17 ao=FBt 2011 =E0 03:10, Jacni Qin a =E9crit :
>>=20
>>> hi Remi,
>>>=20
>>> On 8/16/2011 4:27 PM, R=E9mi Despr=E9s wrote:
>>>> ...
>>>> As already discussed privately, I don't know realistic cases where =
two rules would have IPv6 or IPv4 overlapping prefixes.
>>>> Consequently, it seems that "longest" match, while being permitted, =
doesn't need to be a requirement.
>>> If there are multiple ways for CPE to decide the IPv6 prefix, we =
have to specify the order of priority. e.g., firstly check if there is =
any implication assigned along with the rules, no? then choose the =
"longest" match.
>>> BTW, I think the longest match is not bad.
>>=20
>> It isn't bad, agreed, because it gives the same result as first match =
when prefixes don't overlap.
>> It shouldn't however be made a _requirement_ if there is no well =
understood use case because that additional complexity, small but real.
>>=20
>> Whether there may be realistic configurations where prefix overlap is =
useful remains AFAIK an open question.
>> I have serious doubts, but no time now to argue in details.
>> IMHO, It's up to those who argue in favor of longest match to provide =
at least one realistic example (if there is one).
>> Then we will agree (or discuss).
>> Is that fair?
>>=20
>> Cheers,
>> RD
>>=20
>>=20
>>=20
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>=20



From matsuhira@jp.fujitsu.com  Wed Aug 17 23:39:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADE521F8538 for ; Wed, 17 Aug 2011 23:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.84
X-Spam-Level: 
X-Spam-Status: No, score=-103.84 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFvigOvl+ANf for ; Wed, 17 Aug 2011 23:39:37 -0700 (PDT)
Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id F2F6021F8515 for ; Wed, 17 Aug 2011 23:39:36 -0700 (PDT)
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 5ADBA3EE081 for ; Thu, 18 Aug 2011 15:40:28 +0900 (JST)
Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 4601B45DE55 for ; Thu, 18 Aug 2011 15:40:28 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 24C3845DE54 for ; Thu, 18 Aug 2011 15:40:28 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 17D151DB804F for ; Thu, 18 Aug 2011 15:40:28 +0900 (JST)
Received: from m003.s.css.fujitsu.com (m003.s.css.fujitsu.com [10.23.4.33]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id DC0061DB804B for ; Thu, 18 Aug 2011 15:40:27 +0900 (JST)
Received: from m003.css.fujitsu.com (m003 [127.0.0.1]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id BC3F950EBEA; Thu, 18 Aug 2011 15:40:27 +0900 (JST)
Received: from [127.0.0.1] (polaris03.kh0110-194.dhcp.css.fujitsu.com [10.17.194.90]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id 86BB950EBE8; Thu, 18 Aug 2011 15:40:27 +0900 (JST)
X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1
Message-ID: <4E4CB3AD.8050107@jp.fujitsu.com>
Date: Thu, 18 Aug 2011 15:39:41 +0900
From: Naoki Matsuhira 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
References: <6D93B4F87F5667499B9104BA798D637A046A13F2@STAFFMBX-1.lunet.lboro.ac.uk> <6D93B4F87F5667499B9104BA798D637A0C5FE3B25F@STAFFMBX-1.lunet.lboro.ac.uk> <4E49228F.2040705@skoberne.net> <4E4A17CD.8030807@jp.fujitsu.com> <4E4A925D.2000000@skoberne.net> <4E4B228B.4060305@jp.fujitsu.com> <4E4B8E04.1010103@skoberne.net>
In-Reply-To: <4E4B8E04.1010103@skoberne.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] SA46T questions
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 06:39:37 -0000

Nejc,

Your comments are very helpful for me to arrange my confusion. Thank you.

(2011/08/17 18:46), Nejc Ĺ koberne wrote:

>> However, in my honest opinion, I am confused a little about target
>> technology in softwire.
>
> Well, me too. This is why I am trying very hard lately to understand
> things first.

I agree.

>> SA46T and SA46T-AS is just a tunneling technology.
>>
>> The other side, in my understanding, DS-Lite and 4rd is combination
>> technology of tunneling and NAT.
>
> For DS-Lite, I agree. However, for 4rd NAT is not necessary. As 4rd
> draft says:
>
> "Although 4rd is designed primarily to support IPv4 deployment to a
> customer site (such as a residential home network) by an SP, it can
> equally be applied to an individual host acting as a CE router."
>
> So if you have a host, acting as a CE router, supporting 4rd technology,
> you don't need NAPT44 in it. So in this regard, it is completely the
> same as SA46T-AS. At least this is how I understand it.

I understand.

>> In my understanding, DS-Lite is CGN + Tunneling combination, so CGN +
>> SA46T combination may possible. I think this combination may say DS-Lite.
>
> I wouldn't use DS-Lite in any other context, since it is now an
> independent Proposed Standard. It is as it is. The tunneling there is
> clearly specified.

I think that I have a point in your opinion.


>> Both DS-Lite and 4rd is the combination technology for access network.
>> However, I also have interests to apply SA46T-AS to the server environment.
>
> Well, not necessarily, why? It's just a technology, I can't see why you
> couldn't use it in an enterprise as well?

Yes. I also have interests in an enterprise, and P2P environments, too.
As you say, SA46T and SA46T is just a technology. I think SA46T and 
SA46T is just one of the tool for operators and SIers. I hope 
inventiveness should possible in any environments and the future.

>> I think your trade-off analysis is very important. If adding
>> SA46T/SA46T-AS technology to your analysis table, I think "DS-Lite +
>> SA46T" and "SA46T-AS + CPE NAT" is appropriate.
>
> Well, I don't agree with DS-Lite + SA46T, I would rather make it
> "SA46T + CGN". However, since your SA46T-AS already is an address sharing
> solution and it mentions NAT in one of the scenarios (in the draft), I don't
> think it needs to be combined with anything. So in the end, we have (regarding
> SA46T):
>
> - SA46T (tunneling only)
> - SA46T+CGN (NAPT44 placed in the core)
> - SA46T-AS (directly implemented in the host or NAPT44 placed in the CPE)
>
> Do you agree?

Yes. I agree.

> Nejc

Naoki.



From washam.fan@gmail.com  Thu Aug 18 00:17:10 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408D621F8556 for ; Thu, 18 Aug 2011 00:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.332
X-Spam-Level: 
X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WbS6MZWWrAh for ; Thu, 18 Aug 2011 00:17:09 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8821F84CE for ; Thu, 18 Aug 2011 00:17:08 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1370451wyg.31 for ; Thu, 18 Aug 2011 00:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4+5jOS5LMbjL99VmT3uGpblisL6TquwKa1PKJDurWFU=; b=pVL//OSp1eC/suSok/xEQwr/1R9OT0JdganyDawyTqK8YNfuW/Yrw0dfAzpsjH5q85 B1nvGTcXAyJpeG5Za06UGSmY0OpKUncsMR2sISrmqoShMlelsEP3QU83hr2PPGV4W+V/ lwyHoecq2XrWvSZpQ1AGwedlmddQmAyBz9evM=
MIME-Version: 1.0
Received: by 10.216.175.130 with SMTP id z2mr289497wel.63.1313651880846; Thu, 18 Aug 2011 00:18:00 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Thu, 18 Aug 2011 00:18:00 -0700 (PDT)
In-Reply-To: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>   
Date: Thu, 18 Aug 2011 15:18:00 +0800
Message-ID: 
From: Washam Fan 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 07:17:10 -0000

>> It seems to me, when delegating CE ipv6 prefix, a longest match might
>> be used.
>
> OK, but, again, if a realistic use case is available where longest match is indeed REQUIRED, there is no problem to impose longest match.
> What is missing so far is this use case.

can i cite Tetsuya's examples to elaborate that? assume we have three
below rules
1.{2408:db8:100::/40, 10.10.1.0/24, 48}
2.{2408:db8:200::/40, 10.10.2.0/24, 48}
3.{2408:db8::/32, 10.10.0.0/24, 48}

if a 48 CE prefix is delegated, rule 1 and 2 should be checked against
before rule 3. Although in this case, you can not assign 10.10.0.1 and
10.10.0.2 ipv4 addresses to a CE.

Thanks,
washam

From washam.fan@gmail.com  Thu Aug 18 00:23:56 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D5B5E8010 for ; Thu, 18 Aug 2011 00:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.479
X-Spam-Level: 
X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GuCaNeHuRM6 for ; Thu, 18 Aug 2011 00:23:55 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 201CB5E800B for ; Thu, 18 Aug 2011 00:23:54 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1374489wyg.31 for ; Thu, 18 Aug 2011 00:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1xUJb2HMuff7zgiNT6RU8eA3PPj7S6YaILa55ZLsPRc=; b=okxhjPOTnZMMZPKhPz0T1WhRiu4ahgsIMgfDNtAc/gnIwXHUA/Z8XtBix5L6fjM91W Xzf0Redg0/OuiXZtUTu1FZknGxjEF/A28qbzScIxo8zQrk64bzX2OTYqiYkOWLBTiKtQ h7cI/eAq2I1DIXDHv1JEtBqGicLzNtP7HTxDc=
MIME-Version: 1.0
Received: by 10.216.37.16 with SMTP id x16mr278498wea.93.1313652287797; Thu, 18 Aug 2011 00:24:47 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Thu, 18 Aug 2011 00:24:47 -0700 (PDT)
In-Reply-To: <4E4CAD67.3000609@jacni.com>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>   <4E4CAD67.3000609@jacni.com>
Date: Thu, 18 Aug 2011 15:24:47 +0800
Message-ID: 
From: Washam Fan 
To: Jacni Qin 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 07:23:56 -0000

Hi,

>> It seems to me, when delegating CE ipv6 prefix, a longest match might
>> be used. But when forwarding a IPv4 packet, a longest match is
>> useless, because domain 4rd prefixes don't overlap.
>
> Why? Sorry, I don't follow. The domain IPv4 prefixes can overlap.

if domain 4rd prefixes overlap, when a CE forwards a ipv4 package, it
will get confused. because, let's say, two rules matched, it doesn't
know which domain ipv6 prefix is used to build outer ipv6 destination
address.

Thanks,
washam
> Cheers,
> Jacni
>
>>
>> Thanks,
>> washam
>>
>> 2011/8/17 R=E9mi Despr=E9s:
>>>
>>> Le 17 ao=FBt 2011 =E0 03:10, Jacni Qin a =E9crit :
>>>
>>>> hi Remi,
>>>>
>>>> On 8/16/2011 4:27 PM, R=E9mi Despr=E9s wrote:
>>>>>
>>>>> ...
>>>>> As already discussed privately, I don't know realistic cases where tw=
o
>>>>> rules would have IPv6 or IPv4 overlapping prefixes.
>>>>> Consequently, it seems that "longest" match, while being permitted,
>>>>> doesn't need to be a requirement.
>>>>
>>>> If there are multiple ways for CPE to decide the IPv6 prefix, we have =
to
>>>> specify the order of priority. e.g., firstly check if there is any
>>>> implication assigned along with the rules, no? then choose the "longes=
t"
>>>> match.
>>>> BTW, I think the longest match is not bad.
>>>
>>> It isn't bad, agreed, because it gives the same result as first match
>>> when prefixes don't overlap.
>>> It shouldn't however be made a _requirement_ if there is no well
>>> understood use case because that additional complexity, small but real.
>>>
>>> Whether there may be realistic configurations where prefix overlap is
>>> useful remains AFAIK an open question.
>>> I have serious doubts, but no time now to argue in details.
>>> IMHO, It's up to those who argue in favor of longest match to provide a=
t
>>> least one realistic example (if there is one).
>>> Then we will agree (or discuss).
>>> Is that fair?
>>>
>>> Cheers,
>>> RD
>>>
>>>
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>
>

From jacni@jacni.com  Thu Aug 18 00:49:48 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB0121F874F for ; Thu, 18 Aug 2011 00:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.259,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRCBCSv8fuwG for ; Thu, 18 Aug 2011 00:49:48 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7B821F874E for ; Thu, 18 Aug 2011 00:49:47 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 1A04B3800AF for ; Thu, 18 Aug 2011 03:50:40 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 7F48534008C for ; Thu, 18 Aug 2011 15:50:36 +0800 (CST)
Received: from [172.26.54.148] (unknown [112.64.191.109]) by app (Coremail) with SMTP id +AWowJDr2Ajpw0xO2zRSAA--.57261S2; Thu, 18 Aug 2011 15:49:54 +0800 (CST)
Message-ID: <4E4CC433.4080400@jacni.com>
Date: Thu, 18 Aug 2011 15:50:11 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Washam Fan 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>   <4E4CAD67.3000609@jacni.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-CM-TRANSID: +AWowJDr2Ajpw0xO2zRSAA--.57261S2
X-Coremail-Antispam: 1UD129KBjvJXoWxZF1fGw4kAry8Wr4UGF4kWFg_yoW5Gr1fpF W8t3WUKFWUJF4fCwnFk3W8Wr1YvrWrXrnrX34rGry3K3s0qrn5Xr18Kr45Ca4kGr15Jr42 vFW3KFyfGryDZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUcIb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM2kK64x0aVW7Gw IE548m6rI_Jw1UWr17M2kK6IIYrVAqxI0j4VAqrcv_Jw1UGr1DM2vj6xkI62vS6c8GOVWU tr1rJFyl5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I 8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28I cxkI7VAKI48JMxCIbVAxMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvf C2KfnxnUUI43ZEXa7IUnrMa5UUUUU==
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIBEko7lNBnxABXsR
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 07:49:48 -0000

On 8/18/2011 3:24 PM, Washam Fan wrote:
> Hi,
>
>>> It seems to me, when delegating CE ipv6 prefix, a longest match might
>>> be used. But when forwarding a IPv4 packet, a longest match is
>>> useless, because domain 4rd prefixes don't overlap.
>> Why? Sorry, I don't follow. The domain IPv4 prefixes can overlap.
> if domain 4rd prefixes overlap, when a CE forwards a ipv4 package, it
> will get confused. because, let's say, two rules matched, it doesn't
> know which domain ipv6 prefix is used to build outer ipv6 destination
> address.
There could be,
1.{2408:db8:100::/40, 10.10.1.0/24, 48}
2.{2408:db8::/32, 10.10.0.0/16, 48}

just make sure that the ":100" + ".1.0/24" are excluded when assigning 
the CPE IPv6 prefixes to CPEs which will select the second rule to 
calculate the IPv4 prefixes. For traffics to these CPEs, longest match 
of IPv4 prefix will work.


Cheers,
Jacni
> Thanks,
> washam
>> Cheers,
>> Jacni
>>
>>> Thanks,
>>> washam
>>>
>>> 2011/8/17 Rémi Després:
>>>> Le 17 aoűt 2011 ŕ 03:10, Jacni Qin a écrit :
>>>>
>>>>> hi Remi,
>>>>>
>>>>> On 8/16/2011 4:27 PM, Rémi Després wrote:
>>>>>> ...
>>>>>> As already discussed privately, I don't know realistic cases where two
>>>>>> rules would have IPv6 or IPv4 overlapping prefixes.
>>>>>> Consequently, it seems that "longest" match, while being permitted,
>>>>>> doesn't need to be a requirement.
>>>>> If there are multiple ways for CPE to decide the IPv6 prefix, we have to
>>>>> specify the order of priority. e.g., firstly check if there is any
>>>>> implication assigned along with the rules, no? then choose the "longest"
>>>>> match.
>>>>> BTW, I think the longest match is not bad.
>>>> It isn't bad, agreed, because it gives the same result as first match
>>>> when prefixes don't overlap.
>>>> It shouldn't however be made a _requirement_ if there is no well
>>>> understood use case because that additional complexity, small but real.
>>>>
>>>> Whether there may be realistic configurations where prefix overlap is
>>>> useful remains AFAIK an open question.
>>>> I have serious doubts, but no time now to argue in details.
>>>> IMHO, It's up to those who argue in favor of longest match to provide at
>>>> least one realistic example (if there is one).
>>>> Then we will agree (or discuss).
>>>> Is that fair?
>>>>
>>>> Cheers,
>>>> RD
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>
>>


From despres.remi@laposte.net  Thu Aug 18 00:55:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6F221F8AC3 for ; Thu, 18 Aug 2011 00:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Level: 
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.010,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDRUtodvFAZg for ; Thu, 18 Aug 2011 00:55:46 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id D741721F8ABE for ; Thu, 18 Aug 2011 00:55:45 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id CF606700026C; Thu, 18 Aug 2011 09:56:37 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id F070A700025B; Thu, 18 Aug 2011 09:56:34 +0200 (CEST)
X-SFR-UUID: 20110818075634984.F070A700025B@msfrf2209.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 18 Aug 2011 09:56:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>    
To: Washam Fan 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 07:55:46 -0000

Le 18 ao=FBt 2011 =E0 09:18, Washam Fan a =E9crit :

>>> It seems to me, when delegating CE ipv6 prefix, a longest match =
might
>>> be used.
>>=20
>> OK, but, again, if a realistic use case is available where longest =
match is indeed REQUIRED, there is no problem to impose longest match.
>> What is missing so far is this use case.
>=20
> can i cite Tetsuya's examples to elaborate that? assume we have three
> below rules
> 1.{2408:db8:100::/40, 10.10.1.0/24, 48}
> 2.{2408:db8:200::/40, 10.10.2.0/24, 48}
> 3.{2408:db8::/32, 10.10.0.0/24, 48}

To be complete, the example should IMHO show which CPE's have which IPv6 =
prefixes, and with which IPv4 prefixes derived.
OK?

Regards,
RD

>=20
> if a 48 CE prefix is delegated, rule 1 and 2 should be checked against
> before rule 3. Although in this case, you can not assign 10.10.0.1 and
> 10.10.0.2 ipv4 addresses to a CE.
>=20
> Thanks,
> washam



From washam.fan@gmail.com  Thu Aug 18 01:24:31 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2840721F8ADE for ; Thu, 18 Aug 2011 01:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level: 
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da-+L924BQk7 for ; Thu, 18 Aug 2011 01:24:30 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A321F871E for ; Thu, 18 Aug 2011 01:24:24 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1413939wyg.31 for ; Thu, 18 Aug 2011 01:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=joe+tPS75zqAFi+eSJr1dRArjw4YVKgxYCoQ7wWLDZY=; b=kLN/+iBcrM/ekY2rfgQD8kO/d2OURkPJ+Pwofwvy75DK2qjOwtbsX0k+GXfvNlYPWc I8DIywGBkcvwxas9bLJX4hx72TjMExf7NaOZMlLJhxTiUZB51XUsYg1KJ4OCgZeDRUGg dpINrshvFSpurfdS2Og4O70ZI3Eh81rcyzF0Q=
MIME-Version: 1.0
Received: by 10.216.175.130 with SMTP id z2mr338859wel.63.1313655917419; Thu, 18 Aug 2011 01:25:17 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Thu, 18 Aug 2011 01:25:17 -0700 (PDT)
In-Reply-To: <4E4CC433.4080400@jacni.com>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>   <4E4CAD67.3000609@jacni.com>  <4E4CC433.4080400@jacni.com>
Date: Thu, 18 Aug 2011 16:25:17 +0800
Message-ID: 
From: Washam Fan 
To: Jacni Qin 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 08:24:31 -0000

Hi Jacni

2011/8/18 Jacni Qin :
>
> On 8/18/2011 3:24 PM, Washam Fan wrote:
>>
>> Hi,
>>
>>>> It seems to me, when delegating CE ipv6 prefix, a longest match might
>>>> be used. But when forwarding a IPv4 packet, a longest match is
>>>> useless, because domain 4rd prefixes don't overlap.
>>>
>>> Why? Sorry, I don't follow. The domain IPv4 prefixes can overlap.
>>
>> if domain 4rd prefixes overlap, when a CE forwards a ipv4 package, it
>> will get confused. because, let's say, two rules matched, it doesn't
>> know which domain ipv6 prefix is used to build outer ipv6 destination
>> address.
>
> There could be,
> 1.{2408:db8:100::/40, 10.10.1.0/24, 48}
> 2.{2408:db8::/32, 10.10.0.0/16, 48}
>
> just make sure that the ":100" + ".1.0/24" are excluded when assigning th=
e
> CPE IPv6 prefixes to CPEs which will select the second rule to calculate =
the
> IPv4 prefixes. For traffics to these CPEs, longest match of IPv4 prefix w=
ill
> work.
>
Got you now, thanks,
washam
> Cheers,
> Jacni
>>
>> Thanks,
>> washam
>>>
>>> Cheers,
>>> Jacni
>>>
>>>> Thanks,
>>>> washam
>>>>
>>>> 2011/8/17 R=E9mi Despr=E9s:
>>>>>
>>>>> Le 17 ao=FBt 2011 =E0 03:10, Jacni Qin a =E9crit :
>>>>>
>>>>>> hi Remi,
>>>>>>
>>>>>> On 8/16/2011 4:27 PM, R=E9mi Despr=E9s wrote:
>>>>>>>
>>>>>>> ...
>>>>>>> As already discussed privately, I don't know realistic cases where
>>>>>>> two
>>>>>>> rules would have IPv6 or IPv4 overlapping prefixes.
>>>>>>> Consequently, it seems that "longest" match, while being permitted,
>>>>>>> doesn't need to be a requirement.
>>>>>>
>>>>>> If there are multiple ways for CPE to decide the IPv6 prefix, we hav=
e
>>>>>> to
>>>>>> specify the order of priority. e.g., firstly check if there is any
>>>>>> implication assigned along with the rules, no? then choose the
>>>>>> "longest"
>>>>>> match.
>>>>>> BTW, I think the longest match is not bad.
>>>>>
>>>>> It isn't bad, agreed, because it gives the same result as first match
>>>>> when prefixes don't overlap.
>>>>> It shouldn't however be made a _requirement_ if there is no well
>>>>> understood use case because that additional complexity, small but rea=
l.
>>>>>
>>>>> Whether there may be realistic configurations where prefix overlap is
>>>>> useful remains AFAIK an open question.
>>>>> I have serious doubts, but no time now to argue in details.
>>>>> IMHO, It's up to those who argue in favor of longest match to provide
>>>>> at
>>>>> least one realistic example (if there is one).
>>>>> Then we will agree (or discuss).
>>>>> Is that fair?
>>>>>
>>>>> Cheers,
>>>>> RD
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Softwires mailing list
>>>>> Softwires@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>
>>>
>
>

From washam.fan@gmail.com  Thu Aug 18 01:41:50 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A821F8AF1 for ; Thu, 18 Aug 2011 01:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.344
X-Spam-Level: 
X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHydQBPcQ8YO for ; Thu, 18 Aug 2011 01:41:50 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00FAF21F8A64 for ; Thu, 18 Aug 2011 01:41:49 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1426272wyg.31 for ; Thu, 18 Aug 2011 01:42:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JjZp6tWbT/gClpXG2nSlYVhWU4hHN/nW7OU2sxIOklY=; b=Jfje1GfSaxIU9jMD4wV/kZbBV+v2Oqrt/HYg31cWmF7nn7yVGkjmW1NbAUfTs8OwGT QMt2++RkJNQOPJXAgZJVRIYDbco9cG0N6bCVWs5+ZHjIMB4/ndoj9ybdZ6Et4mMvyzaK ZQZRN9XjQlrLwsr/K8v5z/JEXbTJVeDu6FZnk=
MIME-Version: 1.0
Received: by 10.227.156.65 with SMTP id v1mr1511637wbw.78.1313656962739; Thu, 18 Aug 2011 01:42:42 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Thu, 18 Aug 2011 01:42:42 -0700 (PDT)
In-Reply-To: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>     
Date: Thu, 18 Aug 2011 16:42:42 +0800
Message-ID: 
From: Washam Fan 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 08:41:50 -0000

Hi Remi

2011/8/18 R=E9mi Despr=E9s :
>
> Le 18 ao=FBt 2011 =E0 09:18, Washam Fan a =E9crit :
>
>>>> It seems to me, when delegating CE ipv6 prefix, a longest match might
>>>> be used.
>>>
>>> OK, but, again, if a realistic use case is available where longest matc=
h is indeed REQUIRED, there is no problem to impose longest match.
>>> What is missing so far is this use case.
>>
>> can i cite Tetsuya's examples to elaborate that? assume we have three
>> below rules
>> 1.{2408:db8:100::/40, 10.10.1.0/24, 48}
>> 2.{2408:db8:200::/40, 10.10.2.0/24, 48}
>> 3.{2408:db8::/32, 10.10.0.0/24, 48}
>
> To be complete, the example should IMHO show which CPE's have which IPv6 =
prefixes, and with which IPv4 prefixes derived.
> OK?
OK.

    CE prefix                                   derived IPv4
1.{2408:db8:100::/40, 10.10.1.0/24, 48}
2048:db8:101::/48                          10.10.1.1
2.{2408:db8:200::/40, 10.10.2.0/24, 48}
2048:db8:201::/48                         10.10.2.1
3.{2408:db8::/32, 10.10.0.0/24, 48}
2408:db8:301::/48                         10.10.0.3+ports

    2408:db8:302::/48                         10.10.0.3+ports

note that rule 3 responds to many CE prefixes and derived ipv4
addresses (plus ports)

Is that clearer?
Thanks,
washam
> Regards,
> RD
>
>>
>> if a 48 CE prefix is delegated, rule 1 and 2 should be checked against
>> before rule 3. Although in this case, you can not assign 10.10.0.1 and
>> 10.10.0.2 ipv4 addresses to a CE.
>>
>> Thanks,
>> washam
>
>
>

From nejc@skoberne.net  Thu Aug 18 01:49:25 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF421F8AF9 for ; Thu, 18 Aug 2011 01:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level: 
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuudU4bbBKvO for ; Thu, 18 Aug 2011 01:49:24 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 73A4021F8A4D for ; Thu, 18 Aug 2011 01:49:24 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 4E3B7227811A; Thu, 18 Aug 2011 10:50:16 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq333JBqzfJn; Thu, 18 Aug 2011 10:50:15 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id AABF42278119; Thu, 18 Aug 2011 10:50:13 +0200 (CEST)
Message-ID: <4E4CD244.9060500@skoberne.net>
Date: Thu, 18 Aug 2011 09:50:12 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Satoru Matsushima 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 08:49:25 -0000

Dear Satoru,

> We assume that all applications/OSes doesn't aware port restricted environment.

Sure.

> However, there is a case where an application would be allocated a port which is inside of port set occasionally.

Yes. But I am just talking about being open to applications/OSes which
_would_ be aware of port restriction. The problem I see with the fact,
that you don't do this at the moment, is that in a while, anoter I-D 
will pop up, filling this very small gap.

> The modification of 'to the system call related to bind()' is out of scope in our draft.

Of course. I don't think you should be defining the implementation. I just
think that you should leave it open so that if someone is going to implement
such a restricted system, he can then connect directly onto the IPv6 network.

All other A+P drafts do this, I really can't see a valid reason why you
could not do this with "4via6 translation" as well.

> IMHO, address mapping rule and port distribution algorithm are the difference.
> Let me think that if 4rd is configured with 'DomainIPv6Prefix == 2001:db8::/32', 'CEIPv6PrefixLength == /72' and 'Domain4rdPrefix == 0/0' for example. 40bits EA-bits are divided to 32bits IPv4 address part and 8bits port-set ID part. The length of the port-set ID expresses that address sharing ratio. The bits pattern of the port-set ID expresses port-set index of modulo operation, described in the divi.

Yes, this is the difference. Xing Li, one of the authors of dIVI, also points
out that your draft "lacks the difinition of suffix, therefore is not compatible 
to IPv4/IPv6 translation RFCs." How do you see this?

Anyway, are we sure, that we need two different drafts to cover these
differences? I mean, the principle is the same, isn't it? In my opinion, 
there is an inflation of I-Ds and I think that with some additional synchronization
of efforts we could avoid doubling work of each other. But I may be wrong.

I think that the same goes for 4rd and SA46T-AS, for example.

Thanks,
Nejc

From despres.remi@laposte.net  Thu Aug 18 02:05:08 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466E521F8AB8 for ; Thu, 18 Aug 2011 02:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.94
X-Spam-Level: 
X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am2AoFrro-4v for ; Thu, 18 Aug 2011 02:05:07 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB5E21F8AAF for ; Thu, 18 Aug 2011 02:05:07 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id E0663700004F; Thu, 18 Aug 2011 11:05:59 +0200 (CEST)
Received: from [192.168.1.62] (144.204.170.89.rev.sfr.net [89.170.204.144]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 82B3970000AF; Thu, 18 Aug 2011 11:05:58 +0200 (CEST)
X-SFR-UUID: 20110818090558535.82B3970000AF@msfrf2313.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 18 Aug 2011 11:05:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>      
To: Washam Fan 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 09:05:08 -0000

Le 18 ao=FBt 2011 =E0 10:42, Washam Fan a =E9crit :

> Hi Remi
>=20
> 2011/8/18 R=E9mi Despr=E9s :
>>=20
>> Le 18 ao=FBt 2011 =E0 09:18, Washam Fan a =E9crit :
>>=20
>>>>> It seems to me, when delegating CE ipv6 prefix, a longest match =
might
>>>>> be used.
>>>>=20
>>>> OK, but, again, if a realistic use case is available where longest =
match is indeed REQUIRED, there is no problem to impose longest match.
>>>> What is missing so far is this use case.
>>>=20
>>> can i cite Tetsuya's examples to elaborate that? assume we have =
three
>>> below rules
>>> 1.{2408:db8:100::/40, 10.10.1.0/24, 48}
>>> 2.{2408:db8:200::/40, 10.10.2.0/24, 48}
>>> 3.{2408:db8::/32, 10.10.0.0/24, 48}
>>=20
>> To be complete, the example should IMHO show which CPE's have which =
IPv6 prefixes, and with which IPv4 prefixes derived.
>> OK?
> OK.
>=20
>    CE prefix                                   derived IPv4
> 1.{2408:db8:100::/40, 10.10.1.0/24, 48}
> 2048:db8:101::/48                          10.10.1.1
> 2.{2408:db8:200::/40, 10.10.2.0/24, 48}
> 2048:db8:201::/48                         10.10.2.1
> 3.{2408:db8::/32, 10.10.0.0/24, 48}
> 2408:db8:301::/48                         10.10.0.3+ports
>=20
>    2408:db8:302::/48                         10.10.0.3+ports
>=20
> note that rule 3 responds to many CE prefixes and derived ipv4
> addresses (plus ports)
>=20
> Is that clearer?

I will look at it, and see what I think.
Thanks.
RD


> Thanks,
> washam
>> Regards,
>> RD
>>=20
>>>=20
>>> if a 48 CE prefix is delegated, rule 1 and 2 should be checked =
against
>>> before rule 3. Although in this case, you can not assign 10.10.0.1 =
and
>>> 10.10.0.2 ipv4 addresses to a CE.
>>>=20
>>> Thanks,
>>> washam
>>=20
>>=20
>>=20



From phdgang@gmail.com  Thu Aug 18 06:58:28 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944BE21F8B2F for ; Thu, 18 Aug 2011 06:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.329
X-Spam-Level: 
X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke6Ho+UI3KLD for ; Thu, 18 Aug 2011 06:58:28 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9821F85AC for ; Thu, 18 Aug 2011 06:58:27 -0700 (PDT)
Received: by vws12 with SMTP id 12so1901897vws.31 for ; Thu, 18 Aug 2011 06:59:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/vo4S/NjROqQIs8Mm7qp/sG//kElwi07qC/hovTCuBA=; b=Xy2itFWrrvx9tCM8C3q1c5HxhHKPQ1XM8fo5Qf2wRp7JN0YC1oZnLik/w3XW4KGJeK g2P8IJ10eudCQOHa1TwZzF1jI2/5P4mndq3UxZQpZCosev+h+4e64Wryrm06NSPDLMS9 w+dqu4gJjREiNi47loFi2EQ+brFJddfjrFxpk=
MIME-Version: 1.0
Received: by 10.52.66.70 with SMTP id d6mr744022vdt.351.1313675961795; Thu, 18 Aug 2011 06:59:21 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Thu, 18 Aug 2011 06:59:21 -0700 (PDT)
In-Reply-To: <4E4C4251.8020407@skoberne.net>
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net>
Date: Thu, 18 Aug 2011 21:59:21 +0800
Message-ID: 
From: GangChen 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , Behcet Sarikaya 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 13:58:28 -0000

2011/8/18, Nejc =C5=A0koberne :
> Dear Behcet,
>
>>> Of course. But you could support various scenarios in the scope of your
>>> draft,
>>> not only the common "CPE" one.
>>>
>>
>>
>> No.
>>
>> a+p does not require a NAT44 to be used. This is the case here (my guess=
)
>> because NAT44 is commonly used in the current CE routers and they don't
>> wish to waste public IPv4 addresses.
>>
>> Also NAT44 usage has nothing to do with the port range restrictions of t=
he
>> CE.
>> It is normal behavior of NAPT to select a different source port for the
>> outgoing packet and the port range restriction comes into use here,
>> CE has to use a source port from its range.
>
> Sorry, but I didn't get your point. So you think that it is okay as it
> is in the draft? You say, that A+P doesn't require a NAT44 to be used.
> Exactly. That's why I think it would be great if this was stated in the
> draft as well. Currently, NAT is obligatory in the draft.

A+P is the same case if I understand correctly. NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can=E2=80=99t conn=
ect
to legacy end-hosts.

BRs

Gang

From phdgang@gmail.com  Thu Aug 18 07:03:00 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB8B21F8B4B for ; Thu, 18 Aug 2011 07:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJhDciWIeXkt for ; Thu, 18 Aug 2011 07:02:59 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0F621F875E for ; Thu, 18 Aug 2011 07:02:58 -0700 (PDT)
Received: by ewy19 with SMTP id 19so799835ewy.31 for ; Thu, 18 Aug 2011 07:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Oh2j8cEnoNXD3UKQwqNw/TYLOs8LEAri0hp3Me1aHi8=; b=B9MjuNs0/HbtL+VShs2ZAFCr6USblvautnZFhc2urMQpX/5RdXGa93ogh3vyP9BOBj glpStfgXNSNYeH+yfF6p5TOJAJlK6UBArhyl+p4mbtZ1iXsQJDAO5PLe08OOfTkr5wz0 XDS7xk0u6wusVBIGwOA26RNSE72+qK5+JlUAc=
MIME-Version: 1.0
Received: by 10.52.65.168 with SMTP id y8mr721780vds.16.1313676230419; Thu, 18 Aug 2011 07:03:50 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Thu, 18 Aug 2011 07:03:50 -0700 (PDT)
In-Reply-To: <4E4BC8E9.4010703@skoberne.net>
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net>
Date: Thu, 18 Aug 2011 22:03:50 +0800
Message-ID: 
From: GangChen 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 14:03:00 -0000

> Sure. I can imagine a Linux implementation of "4via6 translation
> support". If enabled, the TCP/IP stack would only bind to specific ports
> (from the range). If you check the section III./C of the following paper:
>
> http://zhuyc.info/globecom08mivi.pdf
>
> the authors propose a modification "to the system call related to bind()
> in the socket library of the operating system".

That is not practicable. You can't do such modification on innumerable hosts.

> Then I could just connect my home gateway-server directly to the ISPs
> network, providing support for "4via6 translation" and that's it.
>
> Also, I see is as a use case in non-ISP environments, where you could
> have IPv6-only, but 4via6 enabled server networks, with servers supporting
> "4via6 translation". Like SA46T-AS, for example.
>
> The main advantage of all this is of course that the IPv4 address is then
> natively configured on the (virtual) interface.

Sorry. I still can't see much benefits from that.

Gang

From simon.perreault@viagenie.ca  Thu Aug 18 07:11:30 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90521F8B4F for ; Thu, 18 Aug 2011 07:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyu2xB8jOhLL for ; Thu, 18 Aug 2011 07:11:30 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0136321F8A7A for ; Thu, 18 Aug 2011 07:11:30 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D819321F49 for ; Thu, 18 Aug 2011 10:12:23 -0400 (EDT)
Message-ID: <4E4D1DC7.5030002@viagenie.ca>
Date: Thu, 18 Aug 2011 10:12:23 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net> 
In-Reply-To: 
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 14:11:30 -0000

On 2011-08-18 09:59, GangChen wrote:
> NAT44 is one of three
> fundamental functions in A+P architecture. Otherwise, it can’t connect
> to legacy end-hosts.

What if in my deployment scenario there are no "legacy" end hosts? What
if all hosts implement A+P-style port ranges?

I'm with Nejc here. A+P/4rd/... do not require NAT44.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From nejc@skoberne.net  Thu Aug 18 07:13:30 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5321F8B42 for ; Thu, 18 Aug 2011 07:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level: 
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.135,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDLQ-oV9n62h for ; Thu, 18 Aug 2011 07:13:30 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id D44F821F8AC3 for ; Thu, 18 Aug 2011 07:13:29 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id E0879227876A; Thu, 18 Aug 2011 16:14:22 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AfGU-IyWXGB; Thu, 18 Aug 2011 16:14:22 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 584012278769; Thu, 18 Aug 2011 16:14:22 +0200 (CEST)
Message-ID: <4E4D1E3D.9090509@skoberne.net>
Date: Thu, 18 Aug 2011 15:14:21 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: GangChen 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "softwires@ietf.org" , Behcet Sarikaya 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 14:13:30 -0000

Dear Behcet,

> A+P is the same case if I understand correctly. NAT44 is one of three
> fundamental functions in A+P architecture. Otherwise, it can’t connect
> to legacy end-hosts.

It _is_ fundamental, however it is not mandatory in all scenarios. Please
see draft-ymbk-aplusp-10 (which defines A+P architecture and has been
approved RFC status in June), page 16, Figure 6. It clearly shows two
different customers. Customer2 must use NAT44, naturally, since his hosts
don't support the specific A+P mechanism themselves. Customer1, however,
has his hosts connected directly into the A+P network. This is because
his hosts _have_ native A+P support for the specific mechanism.

And I think that "draft-murakami-softwire-4v6-translation" should also
support these kind of scenarios (as all other A+P mechanism drafts do).

Thanks,
Nejc


From nejc@skoberne.net  Thu Aug 18 07:49:20 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C74F21F8BBA for ; Thu, 18 Aug 2011 07:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level: 
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCiC0LPGs-Ze for ; Thu, 18 Aug 2011 07:49:20 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id E736B21F8BAD for ; Thu, 18 Aug 2011 07:49:19 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 68414227876A; Thu, 18 Aug 2011 16:50:13 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siH-Z5VllQ32; Thu, 18 Aug 2011 16:50:13 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id EDCFE2278769; Thu, 18 Aug 2011 16:50:12 +0200 (CEST)
Message-ID: <4E4D26A3.6030402@skoberne.net>
Date: Thu, 18 Aug 2011 15:50:11 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: GangChen 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 14:49:20 -0000

Dear Gang,

> That is not practicable. You can't do such modification on innumerable hosts.

Who says only "innumerable" hosts will want to have this? My view on this is, 
that these proposals are not meant to solve only a specific
problem for a specific scenario. Why would we want that? If we do proposals this
way, we will lost ourselves among very similar but a bit different standards.
It's more complex to "administer" such set of standards and it is much harder
for the developers to crawl through all these documents in order to implement
what they need.

> Sorry. I still can't see much benefits from that.

I'll try harder to deliver possible real-world scenarios:

1. Home Torrent node.
---------------------

I am a customer of an ISP who deployed one of the A+P mechanisms. I have a home
server which is also able to run Torrent client. And since this is a new server,
it happens to support the A+P mechanism of the ISP. So I can plug it directly
to my ISP-provided link (modem, CPE, switch, whatever), and everything /just 
works/. This way:

- I don't have to deal with static RFC 1918 addressing, 

- I don't have to deal with static NAT configuration on the CPE,

- I don't have to deal with with additional port configuration on my Torrent box. 

- ...

It just works.

2. Enterprise server mode.
--------------------------

I am a network/system administrator for my company, which has a very limited
set of public IPv4 addresses. But as I don't want to maintain a separate IPv4
addressing infrastructure in my network, my server network will be IPv6-only
as well. However, the servers still need IPv4 connectivity, and for that I'd
like to use A+P. This way:

- I don't need any special ALGs for my servers, which I would have to develop
first since I am using my own proprietary protocols, which can't traverse NATs 
well,

- I don't need to maintain IPv4 in my network where I don't want to have it,
especially I don't need to maintain _another_ IPv4 addressing (RFC 1918),

- I get rid of stateful NAT44 in the core, which is very difficult to make
highly available properly (state synchronization).

- ...

----

Can you see the benefits now?

Thanks,
Nejc

From wdec.ietf@gmail.com  Thu Aug 18 10:07:13 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C60F21F8B8E for ; Thu, 18 Aug 2011 10:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFo+Cr8ijA0m for ; Thu, 18 Aug 2011 10:07:12 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id B382221F8B8B for ; Thu, 18 Aug 2011 10:07:12 -0700 (PDT)
Received: by pzk33 with SMTP id 33so5455026pzk.18 for ; Thu, 18 Aug 2011 10:08:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L6HhDNnNRczWVSB/iY+zNc4FHU3joA+oOAclEwJx6ys=; b=oIOw+G43qB59cHNjEK/Sb+OPPgcgl63V1APV7IzFKJo3/EbNcSMkktPw9PckqSWtcg m1PtF7Lurb2QSU9vsFr6AYToPlF0El2vQSv2ewO0Fevxt64VeVgaCTWw9nV6MBwtp+Mj fZrHKlwHxlZ6f8COvJ5Y9qmrpF1qVnAzhbjUE=
MIME-Version: 1.0
Received: by 10.143.26.41 with SMTP id d41mr496455wfj.200.1313687287085; Thu, 18 Aug 2011 10:08:07 -0700 (PDT)
Received: by 10.142.211.4 with HTTP; Thu, 18 Aug 2011 10:08:06 -0700 (PDT)
In-Reply-To: <4E4B96CB.2020004@skoberne.net>
References: <4E4B96CB.2020004@skoberne.net>
Date: Thu, 18 Aug 2011 19:08:06 +0200
Message-ID: 
From: Wojciech Dec 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: multipart/alternative; boundary=001636e0af3217bc9804aacaa8f5
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 17:07:13 -0000

--001636e0af3217bc9804aacaa8f5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2011/8/17 Nejc =C5=A0koberne 

> Dear authors,
>
> as far as I can understand your draft, you make NAPT44 in the CE
> obligatory.
> However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight
> 4over6 A+P
> drafts. So I suggest that you make it optional in 4via6 translation as
> well, since it might
> be desired for some environments to connect hosts supporting 4via6
> translation
> technology, directly to the IPv6 network. In this case, you don't need th=
e
> translator.
>

It's useful to note that the implementation of any A+P based scheme on an
end host has practical challenges, irrespective of what drafts say (just
think of two such host on the same LAN - something that is not allowed)
If it helps think of any of 4rd, 4V6, dIVI-PD, as having the same
applicability, but practically being most suitable for a CE alongside NAPT4=
4
(which all rely on to provide address sharing)

-Wojciech


>
> Thanks,
> Nejc
> ______________________________**_________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/**listinfo/softwires
>

--001636e0af3217bc9804aacaa8f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



2011/8/17 Nejc =C5=A0koberne <nejc@skoberne.net>=


Dear authors,



as far as I can understand your draft, you make NAPT44 in the CE obligatory=
.

However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight 4over=
6 A+P

drafts. So I suggest that you make it optional in 4via6 translation as well=
, since it might

be desired for some environments to connect hosts supporting 4via6 translat=
ion

technology, directly to the IPv6 network. In this case, you don't need =
the translator.

It's useful to note that the i=
mplementation of any A+P based scheme on an end host has practical challeng=
es, irrespective of what drafts say (just think of two such host on the sam=
e LAN - something that is not allowed)

If it helps think of any of 4rd, 4V6, dIVI-PD, as having the same applicabi=
lity, but practically being most suitable for a CE alongside NAPT44 (which =
all rely on to provide address sharing)

-Wojciech
=C2=A0




Thanks,

Nejc

_______________________________________________

Softwires mailing list

Softwires@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/softwires





--001636e0af3217bc9804aacaa8f5--

From jan@go6.si  Thu Aug 18 13:13:13 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595C021F8A7D for ; Thu, 18 Aug 2011 13:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkF0VTA25wGt for ; Thu, 18 Aug 2011 13:13:12 -0700 (PDT)
Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by ietfa.amsl.com (Postfix) with ESMTP id C16A121F8A71 for ; Thu, 18 Aug 2011 13:13:12 -0700 (PDT)
Received: from jan-mac.local (93-136-38-220.adsl.net.t-com.hr [93.136.38.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 3413B2378050 for ; Thu, 18 Aug 2011 22:14:04 +0200 (CEST)
Message-ID: <4E4D728B.8090000@go6.si>
Date: Thu, 18 Aug 2011 22:14:03 +0200
From: "Jan Zorz @ go6.si" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 20:13:13 -0000

On 8/18/11 3:59 PM, GangChen wrote:
> A+P is the same case if I understand correctly. NAT44 is one of three
> fundamental functions in A+P architecture. Otherwise, it can’t connect
> to legacy end-hosts.

Usually yes, but not necessary. PAT could also do the work, if you 
connect behind CPE a host with public IP address, sort of like "bridged 
mode", and PAT in CPE changes ports to ones inside port-range/set.

This way no address translation is needed, just ports needs to be 
"redirected" to right ones.

Cheers, Jan Zorz

From nejc@skoberne.net  Thu Aug 18 16:16:53 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D37C21F8571 for ; Thu, 18 Aug 2011 16:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.18
X-Spam-Level: 
X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is6OBrynGb27 for ; Thu, 18 Aug 2011 16:16:53 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id CC0A921F856B for ; Thu, 18 Aug 2011 16:16:52 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 7DD56227876A; Fri, 19 Aug 2011 01:17:45 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia37vzD3sUyi; Fri, 19 Aug 2011 01:17:44 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 633902278769; Fri, 19 Aug 2011 01:17:44 +0200 (CEST)
Message-ID: <4E4D9D97.1030500@skoberne.net>
Date: Fri, 19 Aug 2011 00:17:43 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Wojciech Dec 
References: <4E4B96CB.2020004@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 23:16:53 -0000

Dear Wojciech,

> It's useful to note that the implementation of any A+P based scheme on 
> an end host has practical challenges, irrespective of what drafts say 
> (just think of two such host on the same LAN - something that is not 
> allowed)

Are these challenges documented anywhere? Also, why would having two
such hosts on the same LAN not be allowed? I mean, yes, if you have 2
hosts having the same IPv4 address configured on the interface, that
won't work. But in "my world", A+P-enabled hosts are connected to the 
IPv6 network directly.

> If it helps think of any of 4rd, 4V6, dIVI-PD, as having the same 
> applicability, but practically being most suitable for a CE alongside 
> NAPT44 (which all rely on to provide address sharing)

I agree that this will be the most common scenario. But that doesn't
mean we should forget about other scenarios.

Thanks,
Nejc

From brian.e.carpenter@gmail.com  Thu Aug 18 16:34:41 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18F611E8073 for ; Thu, 18 Aug 2011 16:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.447
X-Spam-Level: 
X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iouabC337-Z0 for ; Thu, 18 Aug 2011 16:34:40 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A59311E809D for ; Thu, 18 Aug 2011 16:34:40 -0700 (PDT)
Received: by ywm21 with SMTP id 21so1981641ywm.31 for ; Thu, 18 Aug 2011 16:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Kmbikuqzy/TUo3JJbdJv+P3gTl1TJNAZ9QjuSBYdpA8=; b=e4wzMSQUETsHpDqhaN/H9f74ohBwP8dbFw4eugjQi/3To5Y/JH2frxom3XXtaI8G4T dniXV7+PKD5cIdQII9ttCiIUEtJ07IQkxTH1V0zAwGPb9iXIoFy64PsRZDRbF4UPXI1j skRoplLhGSeJYpJgA9XI/GSl6CtdaRocDqySg=
Received: by 10.236.72.233 with SMTP id t69mr2143128yhd.55.1313710535391; Thu, 18 Aug 2011 16:35:35 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id o2sm1715377yhl.1.2011.08.18.16.35.32 (version=SSLv3 cipher=OTHER); Thu, 18 Aug 2011 16:35:34 -0700 (PDT)
Message-ID: <4E4DA1C2.40307@gmail.com>
Date: Fri, 19 Aug 2011 11:35:30 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net>
In-Reply-To: <4E4D9D97.1030500@skoberne.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 23:34:41 -0000

On 2011-08-19 11:17, Nejc =C5=A0koberne wrote:

=2E..
> won't work. But in "my world", A+P-enabled hosts are connected to the=20
> IPv6 network directly.

And how will that support legacy SOHO LANs?

   Brian




From satoru.matsushima@gmail.com  Thu Aug 18 18:07:33 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3288E21F854E for ; Thu, 18 Aug 2011 18:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLUBu9My4FIP for ; Thu, 18 Aug 2011 18:07:32 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id B209721F854C for ; Thu, 18 Aug 2011 18:07:32 -0700 (PDT)
Received: by pzk33 with SMTP id 33so6464944pzk.18 for ; Thu, 18 Aug 2011 18:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=g/oJMs5VhrexvKOCdutu35hGP8UK9w7kEOumqTxiJc4=; b=B7Ft4uGicHkKLlNM+NW6XrKX5E58baoDS+HSIc94hD+C6X40BPRpcgiI8K+QtepRyy 2JjbHepE2eaJVwgwJAzNJY0OT1l1lX5enpuEzz2wGlERlXMzp260jSVTbuG0En64s5RF qn0F9KlcuqIjtS+rnAEmv4cW4UuneMCXo/HcQ=
Received: by 10.142.200.13 with SMTP id x13mr82005wff.287.1313716108090; Thu, 18 Aug 2011 18:08:28 -0700 (PDT)
Received: from [10.201.81.116] ([202.45.12.174]) by mx.google.com with ESMTPS id c4sm1893866pbe.64.2011.08.18.18.08.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 18:08:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=utf-8
From: Satoru Matsushima 
In-Reply-To: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net>
Date: Fri, 19 Aug 2011 10:08:23 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <210E3894-0407-4964-B056-89DC3B502891@gmail.com>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net>
To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires-wg 
Subject: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 01:07:33 -0000

Hello Remi-san,

I've found this mail now.

On 2011/07/16, at 22:55, R=C3=A9mi Despr=C3=A9s wrote:

> Hi all,
>=20
> 1.
> Being active in the IETF community has been overall enjoyable but, for =
various personal reasons including financial,
> I will no longer contribute as much as before on v4/v6 transition =
solutions (6rd, 4rd, 6a44).

I'd happy to see you now on the list, more actively than before.:)

--snip--

> 2.
> Both the proposed translation-based solution =
(draft-murakami-softwire-4v6-translation) and the proposed tunnel-based =
solution (draft-murakami-softwire-4rd) use the v4v6 address mapping =
algorithm, that of 4rd.
>=20
> It would therefore be advantageous to have an autonomous I-D on the =
4rd address mapping, and two I-D's pointing to it (for the =
translation-based and for the tunnel-based solution).
>=20

I think that it is interesting idea. I heard you're personally work on =
that with some authors. On the other hand, I don't heard there is =
consensus among current 4rd authors for the separation. Do you have =
enough discussion on this?=20

Since collided two documents for same specification would make much =
confusion for people, I recommend you to collaborate with your friend.=20=


cheers,
--satoru=

From phdgang@gmail.com  Thu Aug 18 19:02:41 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF4C21F86BE for ; Thu, 18 Aug 2011 19:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level: 
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvQlp0QabuHy for ; Thu, 18 Aug 2011 19:02:40 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94C6221F86B3 for ; Thu, 18 Aug 2011 19:02:40 -0700 (PDT)
Received: by vxi29 with SMTP id 29so2745117vxi.31 for ; Thu, 18 Aug 2011 19:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QTySG4Yb8F3+fte29pVCZGa/OoXPNwCU0bhLlslrO98=; b=ZkfXmFqf+ADrQwXcbmIle1CW6O0Oh2mOpo6RWcodUy+LqASXf1sOcT+yNnG90+Bcde ewIwf7QllWZPtscd20ZspefD9JV6hEnc98fKl3YE6OeeY10kzP8CLzN+jg66P9JWe6br RxAWvm+ofuAWebsMnxOH5P84YB7YZQKDmEDfw=
MIME-Version: 1.0
Received: by 10.52.98.4 with SMTP id ee4mr1555975vdb.485.1313719415501; Thu, 18 Aug 2011 19:03:35 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Thu, 18 Aug 2011 19:03:35 -0700 (PDT)
In-Reply-To: <4E4D1DC7.5030002@viagenie.ca>
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net>  <4E4D1DC7.5030002@viagenie.ca>
Date: Fri, 19 Aug 2011 10:03:35 +0800
Message-ID: 
From: GangChen 
To: Simon Perreault 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: softwires@ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 02:02:41 -0000

2011/8/18, Simon Perreault :
> On 2011-08-18 09:59, GangChen wrote:
>> NAT44 is one of three
>> fundamental functions in A+P architecture. Otherwise, it can=92t connect
>> to legacy end-hosts.
>
> What if in my deployment scenario there are no "legacy" end hosts? What
> if all hosts implement A+P-style port ranges?
>
> I'm with Nejc here. A+P/4rd/... do not require NAT44.

And then, how many hosts could support "what if" in the wild

Gang

From satoru.matsushima@gmail.com  Thu Aug 18 19:16:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E86C21F86BE for ; Thu, 18 Aug 2011 19:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Level: 
X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7Kegf8rfdB5 for ; Thu, 18 Aug 2011 19:16:43 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id B012F21F863E for ; Thu, 18 Aug 2011 19:16:43 -0700 (PDT)
Received: by iye1 with SMTP id 1so4559521iye.27 for ; Thu, 18 Aug 2011 19:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2HahNJA1jSK9n0EsclpNscnrWbBAlyo+jDTtDuAhvNk=; b=EDw3xAP8LYFKQm8AzdlxCrWTxZFgsUDeQMt136OuOxfRJv4zuurPVj5/T13AKtYPnI 7+7V0xzv2BCN/VQC4nzF0jfFniwATqp2tZRj1L8b+y0weBHajh/PuPqRTew0sU4kiNnr qK6EncU5xod7uWpsj4wrlIkbjpK5V+ZYs1Bdw=
Received: by 10.231.6.40 with SMTP id 40mr3052995ibx.80.1313720257641; Thu, 18 Aug 2011 19:17:37 -0700 (PDT)
Received: from [10.201.81.116] ([202.45.12.174]) by mx.google.com with ESMTPS id c3sm316795ibd.19.2011.08.18.19.17.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 19:17:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-2022-jp
From: Satoru Matsushima 
In-Reply-To: <4E4D728B.8090000@go6.si>
Date: Fri, 19 Aug 2011 11:17:30 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A4A47E7-43A5-4AF8-AE75-4982D93445E8@gmail.com>
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net>  <4E4D728B.8090000@go6.si>
To: Jan Zorz @ go6.si 
X-Mailer: Apple Mail (2.1244.3)
Cc: softwires@ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 02:16:45 -0000

On 2011/08/19, at 5:14, Jan Zorz @ go6.si wrote:

> On 8/18/11 3:59 PM, GangChen wrote:
>> A+P is the same case if I understand correctly. NAT44 is one of three
>> fundamental functions in A+P architecture. Otherwise, it can=1B$B!G=1B(=
Bt connect
>> to legacy end-hosts.
>=20
> Usually yes, but not necessary. PAT could also do the work, if you =
connect behind CPE a host with public IP address, sort of like "bridged =
mode", and PAT in CPE changes ports to ones inside port-range/set.
>=20
> This way no address translation is needed, just ports needs to be =
"redirected" to right ones.

It seems to me that no modification for any system call, correct?
AFAIK, Nejc insists some system call modification, bind(), etc.,

cheers,
--satoru=20=

From phdgang@gmail.com  Thu Aug 18 19:51:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D58D21F85C0 for ; Thu, 18 Aug 2011 19:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.333
X-Spam-Level: 
X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1AS4stLVzPy for ; Thu, 18 Aug 2011 19:51:55 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFE0C21F8556 for ; Thu, 18 Aug 2011 19:51:54 -0700 (PDT)
Received: by vws12 with SMTP id 12so2538890vws.31 for ; Thu, 18 Aug 2011 19:52:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zk12po4IIJCGVK+ZCu7JUA4WeAnT5fLR59klLZ+chrY=; b=cxBC4bd096Dy+IPzkiGY55+p3Dp7ae1/8LRTMsNDRkO83+IxpQbmWzDXgq1lWDE4B4 NMtImDjN6NKo7+34jO7VkN+3miMTQk3xj+fz6Bf7O3JSkNpTrdHQQnNKb6lHfaagPN56 QkqgNJd+OYDvj/IltepeousuAvze484snpbXI=
MIME-Version: 1.0
Received: by 10.52.25.65 with SMTP id a1mr1509500vdg.284.1313722370195; Thu, 18 Aug 2011 19:52:50 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Thu, 18 Aug 2011 19:52:50 -0700 (PDT)
In-Reply-To: <4E4D26A3.6030402@skoberne.net>
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net>  <4E4D26A3.6030402@skoberne.net>
Date: Fri, 19 Aug 2011 10:52:50 +0800
Message-ID: 
From: GangChen 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 02:51:55 -0000

2011/8/18, Nejc =C5=A0koberne :
> Dear Gang,
>
>> That is not practicable. You can't do such modification on innumerable
>> hosts.
>
> Who says only "innumerable" hosts will want to have this? My view on this
> is,
> that these proposals are not meant to solve only a specific
> problem for a specific scenario. Why would we want that? If we do proposa=
ls
> this
> way, we will lost ourselves among very similar but a bit different
> standards.
> It's more complex to "administer" such set of standards and it is much
> harder
> for the developers to crawl through all these documents in order to
> implement
> what they need.

"NOT PRACTICABLE" has two meanings.
1) Restricted port aware host is relatively few case
2) Socket need to be modified. That is a practical challenge, not only
bind() but also connect()

>> Sorry. I still can't see much benefits from that.
>
> I'll try harder to deliver possible real-world scenarios:
>
> 1. Home Torrent node.
> ---------------------
>
> I am a customer of an ISP who deployed one of the A+P mechanisms. I have =
a
> home
> server which is also able to run Torrent client. And since this is a new
> server,
> it happens to support the A+P mechanism of the ISP. So I can plug it
> directly
> to my ISP-provided link (modem, CPE, switch, whatever), and everything /j=
ust
> works/. This way:
>
> - I don't have to deal with static RFC 1918 addressing,
>
> - I don't have to deal with static NAT configuration on the CPE,
>
> - I don't have to deal with with additional port configuration on my Torr=
ent
> box.
>
> - ...
>
> It just works.
>
> 2. Enterprise server mode.
> --------------------------
>
> I am a network/system administrator for my company, which has a very limi=
ted
> set of public IPv4 addresses. But as I don't want to maintain a separate
> IPv4
> addressing infrastructure in my network, my server network will be IPv6-o=
nly
> as well. However, the servers still need IPv4 connectivity, and for that =
I'd
> like to use A+P. This way:
>
> - I don't need any special ALGs for my servers, which I would have to
> develop
> first since I am using my own proprietary protocols, which can't traverse
> NATs
> well,
>
> - I don't need to maintain IPv4 in my network where I don't want to have =
it,
> especially I don't need to maintain _another_ IPv4 addressing (RFC 1918),
>
> - I get rid of stateful NAT44 in the core, which is very difficult to mak=
e
> highly available properly (state synchronization).
>
> - ...
>
> ----
>
> Can you see the benefits now?

The consumption is to produce a brand-new network. If that is the
case, I may prefer going to native IPv6 network.


Gang

From despres.remi@laposte.net  Fri Aug 19 00:57:49 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9374821F8829 for ; Fri, 19 Aug 2011 00:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ2CkdoIHtpv for ; Fri, 19 Aug 2011 00:57:49 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id C7EBC21F8AF2 for ; Fri, 19 Aug 2011 00:57:48 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id 21EC670000AE; Fri, 19 Aug 2011 09:58:43 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id E52D870000B0; Fri, 19 Aug 2011 09:58:38 +0200 (CEST)
X-SFR-UUID: 20110819075838938.E52D870000B0@msfrf2316.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <210E3894-0407-4964-B056-89DC3B502891@gmail.com>
Date: Fri, 19 Aug 2011 09:58:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com>
To: Satoru Matsushima 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 07:57:49 -0000

Le 19 ao=FBt 2011 =E0 03:08, Satoru Matsushima a =E9crit :

> Hello Remi-san,
>=20
> I've found this mail now.
>=20
> On 2011/07/16, at 22:55, R=E9mi Despr=E9s wrote:
>=20
>> Hi all,
>>=20
>> 1.
>> Being active in the IETF community has been overall enjoyable but, =
for various personal reasons including financial,
>> I will no longer contribute as much as before on v4/v6 transition =
solutions (6rd, 4rd, 6a44).
>=20
> I'd happy to see you now on the list, more actively than before.:)

Thanks.
(For other personal reasons, which I shared with you privately, I =
decided to come back and to meet meet financial expenses at least until =
the Taipei meeting.

Hope it will be useful to the community.

> --snip--
>=20
>> 2.
>> Both the proposed translation-based solution =
(draft-murakami-softwire-4v6-translation) and the proposed tunnel-based =
solution (draft-murakami-softwire-4rd) use the v4v6 address mapping =
algorithm, that of 4rd.
>>=20
>> It would therefore be advantageous to have an autonomous I-D on the =
4rd address mapping, and two I-D's pointing to it (for the =
translation-based and for the tunnel-based solution).
>>=20
>=20
> I think that it is interesting idea.

Thanks.
Several supports on the list, with no opposition, looks like a good =
start for a rough consensus.

> I heard you're personally work on that with some authors.

Indeed, as I have written to you, a draft is coming, now very soon.

> On the other hand, I don't heard there is consensus among current 4rd =
authors for the separation.

Fair enough.
A draft submitted under responsibility is its authors is a practical =
ways to test consensus.
=20
> Do you have enough discussion on this?=20

I think so.
I know that some, although expressing nothing against the idea, would =
prefer to wait and see.=20
But others believe that, concerning the best way to structure drafts, =
the earlier is the better.


> Since collided two documents for same specification would make much =
confusion for people,

It isn't difficult, in my understanding, to replace sec. 5 of the =
Encapsulation draft by a pointer to the stateless-address-mapping draft.

As you know, I personally believe that the Encapsulation method of a =
sufficient tunneling method for stateless operation. (It is more =
transparent than the double-translation tunneling method, and adds =
header overheads that are small enough in practice).
Yet, I understand that (at least for the time being) there is no =
consensus on that.=20
Both proposals will therefore be discussed.=20

Whether Encapsulation and Double-translation methods will remain in =
separate drafts or might be regrouped in a single one including their =
comparison is, as far as I am concerned, an open question (neither in =
favor nor against).=20


> I recommend you to collaborate with your friend.

No need to recommend it!
I have always worked on subjects I find important with whoever is =
welcoming my cooperation ;-).

To conclude, I do hope you will appreciate the 4rd Address-Mapping draft =
as much as its authors do, and that it will be a good basis for our =
further collaboration.

Cheers,
RD


=20
>=20
>=20
> cheers,
> --satoru



From satoru.matsushima@gmail.com  Fri Aug 19 01:14:26 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9CA21F8A4E for ; Fri, 19 Aug 2011 01:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVqU4gyAD-+V for ; Fri, 19 Aug 2011 01:14:26 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2397D21F8801 for ; Fri, 19 Aug 2011 01:14:25 -0700 (PDT)
Received: by ewy19 with SMTP id 19so1082120ewy.31 for ; Fri, 19 Aug 2011 01:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OD2IihEBGgLdlIcGP6PVRmBRdnfI2dTTByjC1kb1OcE=; b=bbrU0E6aooni33ospdlIKBs0CkklP/9rAoTIuu/jGDUBUUrLzsRdSTRY2VRp3ruDrY 9BXSxmIvfjVbrjNZPd4t/nosFST6WS8MJJTSadUGs3fsEdmgsV+9aO27CYkkMsrV/sj+ TdikowXIOLmMbOYMYZRzdnqCF53m+1VSlOmFc=
MIME-Version: 1.0
Received: by 10.14.151.15 with SMTP id a15mr591861eek.42.1313741721628; Fri, 19 Aug 2011 01:15:21 -0700 (PDT)
Received: by 10.14.95.78 with HTTP; Fri, 19 Aug 2011 01:15:21 -0700 (PDT)
In-Reply-To: <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>
Date: Fri, 19 Aug 2011 17:15:21 +0900
Message-ID: 
From: Satoru Matsushima 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 08:14:27 -0000

2011/8/19 R=E9mi Despr=E9s :
> I think so.
> I know that some, although expressing nothing against the idea, would pre=
fer to wait and see.

I haven't heard so.


> But others believe that, concerning the best way to structure drafts, the=
 earlier is the better.
>

IMHO, document structure is a last discussion item of standardization.



>
>> Since collided two documents for same specification would make much conf=
usion for people,
>
> It isn't difficult, in my understanding, to replace sec. 5 of the Encapsu=
lation draft by a pointer to the stateless-address-mapping draft.
>

The problem is, there's no consensus before you post the draft. Why do
you think they do so?


> As you know, I personally believe that the Encapsulation method of a suff=
icient tunneling method for stateless operation. (It is more transparent th=
an the double-translation tunneling method, and adds header overheads that =
are small enough in practice).
> Yet, I understand that (at least for the time being) there is no consensu=
s on that.
> Both proposals will therefore be discussed.

We can discuss well with current drafts, no need alternatives.
Without collaboration, it must be a troublemaker.

>
> Whether Encapsulation and Double-translation methods will remain in separ=
ate drafts or might be regrouped in a single one including their comparison=
 is, as far as I am concerned, an open question (neither in favor nor again=
st).
>
>
>> I recommend you to collaborate with your friend.
>
> No need to recommend it!
> I have always worked on subjects I find important with whoever is welcomi=
ng my cooperation ;-).
>

Why don't you introduce them to us?


> To conclude, I do hope you will appreciate the 4rd Address-Mapping draft =
as much as its authors do, and that it will be a good basis for our further=
 collaboration.

I don't appreciate. I continue to recommend you to collaborate with
current 4rd draft authors.

cheers,
--satoru

From internet-drafts@ietf.org  Fri Aug 19 01:57:33 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2101221F8781; Fri, 19 Aug 2011 01:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53JBJ3o7e7iX; Fri, 19 Aug 2011 01:57:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4621F85B8; Fri, 19 Aug 2011 01:57:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.59
Message-ID: <20110819085732.7059.60759.idtracker@ietfa.amsl.com>
Date: Fri, 19 Aug 2011 01:57:32 -0700
Cc: softwires@ietf.org
Subject: [Softwires] I-D Action: draft-ietf-softwire-6rd-radius-attrib-03.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 08:57:33 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Softwires Working Group of the IETF.

	Title           : RADIUS Attribute for 6rd
	Author(s)       : Dayong Guo
                          Sheng Jiang
                          Remi Despres
                          Roberta Maglione
	Filename        : draft-ietf-softwire-6rd-radius-attrib-03.txt
	Pages           : 11
	Date            : 2011-08-19

   IPv6 Rapid Deployment (6rd) is one of the most popular methods to
   provide both IPv4 and IPv6 connectivity services simultaneously
   during the IPv4/IPv6 co-existing period. The Dynamic Host
   Configuration Protocol (DHCP) 6rd option has been defined to
   configure 6rd Customer Edge (CE). However, in many networks, the
   configuration information may be stored in Authentication
   Authorization and Accounting (AAA) servers while user configuration
   is mainly from Broadband Network Gateway (BNG) through DHC protocol.
   This document defines a Remote Authentication Dial In User Service
   (RADIUS) attribute that carries 6rd configuration information from
   AAA server to BNG.




A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-0=
3.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-03=
.txt

From despres.remi@laposte.net  Fri Aug 19 02:17:09 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EDD21F8508 for ; Fri, 19 Aug 2011 02:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5xHc5YLwbDy for ; Fri, 19 Aug 2011 02:17:08 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 43E4621F84F3 for ; Fri, 19 Aug 2011 02:17:08 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id DCF74700010A; Fri, 19 Aug 2011 11:18:03 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id A86C570000A9; Fri, 19 Aug 2011 11:17:59 +0200 (CEST)
X-SFR-UUID: 20110819091759689.A86C570000A9@msfrf2319.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Fri, 19 Aug 2011 11:17:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net> 
To: Satoru Matsushima 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 09:17:09 -0000

Le 19 ao=FBt 2011 =E0 10:15, Satoru Matsushima a =E9crit :

> 2011/8/19 R=E9mi Despr=E9s :
>> I think so.
>> I know that some, although expressing nothing against the idea, would =
prefer to wait and see.
>=20
> I haven't heard so.

If I misinterpreted what I saw, that's even better.


>> But others believe that, concerning the best way to structure drafts, =
the earlier is the better.
>>=20
>=20
> IMHO, document structure is a last discussion item of standardization.

Not from my experience, but different views are possible..


>>> Since collided two documents for same specification would make much =
confusion for people,
>>=20
>> It isn't difficult, in my understanding, to replace sec. 5 of the =
Encapsulation draft by a pointer to the stateless-address-mapping draft.
>>=20
>=20
> The problem is, there's no consensus before you post the draft. Why do
> you think they do so?

They do, of course, what they wish.
I certainly don't pretend to impose anything!
I was just making a suggestion.=20

>> As you know, I personally believe that the Encapsulation method of a =
sufficient tunneling method for stateless operation. (It is more =
transparent than the double-translation tunneling method, and adds =
header overheads that are small enough in practice).
>> Yet, I understand that (at least for the time being) there is no =
consensus on that.
>> Both proposals will therefore be discussed.
>=20
> We can discuss well with current drafts, no need alternatives.

Sure, no problem.
=20
> Without collaboration, it must be a troublemaker.
>=20
>>=20
>> Whether Encapsulation and Double-translation methods will remain in =
separate drafts or might be regrouped in a single one including their =
comparison is, as far as I am concerned, an open question (neither in =
favor nor against).
>>=20
>>=20
>>> I recommend you to collaborate with your friend.
>>=20
>> No need to recommend it!
>> I have always worked on subjects I find important with whoever is =
welcoming my cooperation ;-).
>>=20
>=20
> Why don't you introduce them to us?

I suppose you refer to co-authors of the draft.
Since we are very busy closing this phase, wishing to share asap our =
proposal with the WG, I preferred to avoid being distracted from that =
goal until the draft is posted.

It should be now only a matter of hours.


>> To conclude, I do hope you will appreciate the 4rd Address-Mapping =
draft as much as its authors do, and that it will be a good basis for =
our further collaboration.
>=20
> I don't appreciate.

Sorry to hear that before you have seen it.=20


> I continue to recommend you to collaborate with
> current 4rd draft authors.

Now, since you insist, let one point be clear. In Quebec, the presenter =
of the 4rd draft mentioned my contribution to 4rd to only say that the =
previous 4rd draft had been submitted to Intarea "because Remi wanted it =
despite a different view from others". This is as you know completely =
false, and is an offense. Also, one of his slides has "4rd aka Stateless =
DS-lite". He knows, as you know, that I had expressed strong opposition =
to this badly reductive view (DS lite is hub and spoke, has no NAT in =
CPE's, ...). I prefer to collaborate with co-authors who have respect =
for my contributions.

I was hoping not to have to say that, and hope I won't have to expand.
But I am tired of being told what to do, an not to do, by a group that =
accepts my being publicly humiliated.

Your contribution to progress of 4rd in IETF deserves great recognition, =
and nothing will change my mind on this.=20
I deserve respect too.

Sorry to have felt obliged to give this explanation.
Hope future will be brighter.

Regards,
RD
  =20



>=20
> cheers,
> --satoru



From tetsuya@ipinfusion.com  Fri Aug 19 02:18:40 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA5121F899F for ; Fri, 19 Aug 2011 02:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level: 
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH1LPBUfOXk0 for ; Fri, 19 Aug 2011 02:18:40 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0216721F8880 for ; Fri, 19 Aug 2011 02:18:39 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2359392gxk.31 for ; Fri, 19 Aug 2011 02:19:36 -0700 (PDT)
Received: by 10.236.191.69 with SMTP id f45mr5497435yhn.74.1313745576079; Fri, 19 Aug 2011 02:19:36 -0700 (PDT)
Received: from [192.168.0.6] (c-76-102-170-116.hsd1.ca.comcast.net [76.102.170.116]) by mx.google.com with ESMTPS id p11sm1510382ibf.30.2011.08.19.02.19.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 02:19:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=utf-8
From: Tetsuya Murakami 
In-Reply-To: <210E3894-0407-4964-B056-89DC3B502891@gmail.com>
Date: Fri, 19 Aug 2011 02:19:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com>
To: Satoru Matsushima 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 09:18:40 -0000

Hi Satoru-san,

Please see my comments inline.

On 2011/08/18, at 18:08, Satoru Matsushima wrote:

> Hello Remi-san,
>=20
> I've found this mail now.
>=20
> On 2011/07/16, at 22:55, R=C3=A9mi Despr=C3=A9s wrote:
>=20
>> Hi all,
>>=20
>> 1.
>> Being active in the IETF community has been overall enjoyable but, =
for various personal reasons including financial,
>> I will no longer contribute as much as before on v4/v6 transition =
solutions (6rd, 4rd, 6a44).
>=20
> I'd happy to see you now on the list, more actively than before.:)
>=20
> --snip--
>=20
>> 2.
>> Both the proposed translation-based solution =
(draft-murakami-softwire-4v6-translation) and the proposed tunnel-based =
solution (draft-murakami-softwire-4rd) use the v4v6 address mapping =
algorithm, that of 4rd.
>>=20
>> It would therefore be advantageous to have an autonomous I-D on the =
4rd address mapping, and two I-D's pointing to it (for the =
translation-based and for the tunnel-based solution).
>>=20
>=20
> I think that it is interesting idea. I heard you're personally work on =
that with some authors. On the other hand, I don't heard there is =
consensus among current 4rd authors for the separation. Do you have =
enough discussion on this?=20

=46rom my perspective as the co-author of 4rd draft, I don't think we =
have enough discussion on this separation idea. So, I think it is good =
to have some discussion for this before deciding to create a separated =
document for only 4rd mapping rule.

=46rom my perspective, I prefer to create a single document for 4rd =
because it looks for me to be very understandable for everyone.

Also, right now we have two draft as shown below.

draft-murakami-softwire-4rd
draft-murakami-softiwire-4v6-translation

I think it might be good to combine these 2 drafts to create one unified =
document for 4rd specification. Note that this idea has been already =
proposed among authors. Anyway, in order to decide a document structure, =
I think we need to discuss about this more to figure out the pros & cons =
of creating the separated draft for 4rd mapping rule.

> Since collided two documents for same specification would make much =
confusion for people, I recommend you to collaborate with your friend.=20=


 +1
Agreed. We need to discuss about this more.

Thanks,
Tetsuya Murakami

> cheers,
> --satoru
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From despres.remi@laposte.net  Fri Aug 19 02:58:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A6421F8A4B for ; Fri, 19 Aug 2011 02:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA1MT9C2wvMk for ; Fri, 19 Aug 2011 02:58:46 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id EEDEC21F8A30 for ; Fri, 19 Aug 2011 02:58:45 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 6111C700012F; Fri, 19 Aug 2011 11:59:41 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id CA89570000EF; Fri, 19 Aug 2011 11:59:40 +0200 (CEST)
X-SFR-UUID: 20110819095940829.CA89570000EF@msfrf2319.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Fri, 19 Aug 2011 11:59:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <57FE1668-57C6-4282-917A-E5CE7D551292@laposte.net>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>    
To: Washam Fan 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 09:58:46 -0000

Le 18 ao=FBt 2011 =E0 09:18, Washam Fan a =E9crit :

>>> It seems to me, when delegating CE ipv6 prefix, a longest match =
might
>>> be used.
>>=20
>> OK, but, again, if a realistic use case is available where longest =
match is indeed REQUIRED, there is no problem to impose longest match.
>> What is missing so far is this use case.
>=20
> can i cite Tetsuya's examples to elaborate that? assume we have three
> below rules
> 1.{2408:db8:100::/40, 10.10.1.0/24, 48}
> 2.{2408:db8:200::/40, 10.10.2.0/24, 48}
> 3.{2408:db8::/32, 10.10.0.0/24, 48}
>=20
> if a 48 CE prefix is delegated, rule 1 and 2 should be checked against
> before rule 3.


> Although in this case, you can not assign 10.10.0.1 and
> 10.10.0.2 ipv4 addresses to a CE.

Unless I misunderstand, this makes it an unrealistic use case, right?

Cheers,
RD





From cuiyong@tsinghua.edu.cn  Fri Aug 19 05:09:07 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2B821F8A97; Fri, 19 Aug 2011 05:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.793,  BAYES_40=-0.185, DNS_FROM_RFC_DSN=1.495, GB_I_INVITATION=-2, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-gmWc7ChRFe; Fri, 19 Aug 2011 05:09:06 -0700 (PDT)
Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 14AB021F8A30; Fri, 19 Aug 2011 05:09:05 -0700 (PDT)
Received: from [219.143.155.84] (helo=[192.168.0.155]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1QuNtD-0007k1-EC; Fri, 19 Aug 2011 20:09:31 +0800
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Fri, 19 Aug 2011 20:09:23 +0800
From: Yong Cui 
To: 
Message-ID: 
Thread-Topic: Softwire Interim Meeting in Beijing
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: liziye , "Ralph Droms \(rdroms\)" , iesg-secretary@ietf.org, Yong Cui 
Subject: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:09:07 -0000

Hi folks,

We, softwire wg chairs, in agreement with our ADs, are announcing
an interim meeting in Beijing on September 26 & 27. The date has
been chosen adjacent to the BBF meeting in Shangai to minimize
travel and visa issues.

The interim meeting will focus on 'stateless' solutions in general
and 4rd in particular. Expected outcome includes progress on 4rd
spec, packet format, where to put IPv4 bits, port indications, DHCP
option, tunneling vs translation, coexistence with other
technologies, etc...

---------------------------------------
Meeting Location & recommended hotels
Meeting venue: FIT Building, Tsinghua University, Beijing
FIT Building is the first left building inside of the East Gate
of Tsinghua Univeristy
http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798

Recommended hotels:
1. Uniscenter (4 stars, 3 min walk)
http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html

2. Wenjin Hotel (5 stars, 10 min walk)
http://www.wenjin.com.cn/

3. Royal King Hotel (5 stars, 10 min by car)
http://www.royalkinghotel.com/

----------------------------------------
Invitation letter
If you need an invitation letter, please send the following info
to Ms. Ziye Li: .
Surname: 
Given Name: 
Company: 
Address:
Phone: 
Passport Number: 
Passport Exp. Date:
Passport Issuing Country:



-----------------------------------------

Further contact information
Please contact Ms. Ziye Li if you have any question about
Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...



-- Alain, Yong



From simon.perreault@viagenie.ca  Fri Aug 19 05:10:11 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD6921F8A30 for ; Fri, 19 Aug 2011 05:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3QhdR1atLeP for ; Fri, 19 Aug 2011 05:10:11 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7F61C21F85C4 for ; Fri, 19 Aug 2011 05:10:10 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4CA2721BBB; Fri, 19 Aug 2011 08:10:48 -0400 (EDT)
Message-ID: <4E4E52C7.4040103@viagenie.ca>
Date: Fri, 19 Aug 2011 08:10:47 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: GangChen 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net>  <4E4D1DC7.5030002@viagenie.ca> 
In-Reply-To: 
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:10:11 -0000

On 2011-08-18 22:03, GangChen wrote:
> 2011/8/18, Simon Perreault :
>> On 2011-08-18 09:59, GangChen wrote:
>>> NAT44 is one of three
>>> fundamental functions in A+P architecture. Otherwise, it can’t connect
>>> to legacy end-hosts.
>>
>> What if in my deployment scenario there are no "legacy" end hosts? What
>> if all hosts implement A+P-style port ranges?
>>
>> I'm with Nejc here. A+P/4rd/... do not require NAT44.
> 
> And then, how many hosts could support "what if" in the wild

It's your deployment scenario that requires NAT44, not 4rd itself.

I'm not denying that this deployment scenario is important. Many of us
are considering the same scenario. All I'm saying is that there is
another scenario where 4rd would also be applicable that would not
require NAT44.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From washam.fan@gmail.com  Fri Aug 19 05:12:47 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45DE21F85C4 for ; Fri, 19 Aug 2011 05:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.342
X-Spam-Level: 
X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw-rMQS1cPia for ; Fri, 19 Aug 2011 05:12:47 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 397E421F8596 for ; Fri, 19 Aug 2011 05:12:47 -0700 (PDT)
Received: by wwf5 with SMTP id 5so2050757wwf.13 for ; Fri, 19 Aug 2011 05:13:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3WIE/s+0VipKBd31LXeG/RS2nz0W9kHsqKgbr0N3QIM=; b=wB3Ir+TjQQfbDptIJn3vBZgGOM0Yoco0B40DCGKWZ7OaG2ohMJ0tl4/+E51LabPdt+ kV4ZrkHg/WG73dDJuw4ituZQB/mcTWbuYAhmw0tp84L9IOaofJknZ0faGv3haA//l6oi TK715JznbdCx9MpXW4o9grg3rvrDee9Htxepc=
MIME-Version: 1.0
Received: by 10.216.131.134 with SMTP id m6mr1577681wei.78.1313756023251; Fri, 19 Aug 2011 05:13:43 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Fri, 19 Aug 2011 05:13:43 -0700 (PDT)
In-Reply-To: <57FE1668-57C6-4282-917A-E5CE7D551292@laposte.net>
References:  <03C4F232-7962-486F-9EF1-158F7FB9AE1D@ipinfusion.com> <985213AE-05C3-46FD-8320-0736D41CCD50@laposte.net> <4E4B1519.3030003@jacni.com>     <57FE1668-57C6-4282-917A-E5CE7D551292@laposte.net>
Date: Fri, 19 Aug 2011 20:13:43 +0800
Message-ID: 
From: Washam Fan 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires 
Subject: Re: [Softwires] are multiple Domain IPv6 prefixes possible?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:12:48 -0000

2011/8/19 R=E9mi Despr=E9s :
>
> Le 18 ao=FBt 2011 =E0 09:18, Washam Fan a =E9crit :
>
>>>> It seems to me, when delegating CE ipv6 prefix, a longest match might
>>>> be used.
>>>
>>> OK, but, again, if a realistic use case is available where longest matc=
h is indeed REQUIRED, there is no problem to impose longest match.
>>> What is missing so far is this use case.
>>
>> can i cite Tetsuya's examples to elaborate that? assume we have three
>> below rules
>> 1.{2408:db8:100::/40, 10.10.1.0/24, 48}
>> 2.{2408:db8:200::/40, 10.10.2.0/24, 48}
>> 3.{2408:db8::/32, 10.10.0.0/24, 48}
>>
>> if a 48 CE prefix is delegated, rule 1 and 2 should be checked against
>> before rule 3.
>
>
>> Although in this case, you can not assign 10.10.0.1 and
>> 10.10.0.2 ipv4 addresses to a CE.
>
> Unless I misunderstand, this makes it an unrealistic use case, right?

Yeah. but the use case exists in theory. Anyway i can live with
current 'longest match' text.

B.R.
washam
> Cheers,
> RD
>
>
>
>
>

From rajiva@cisco.com  Fri Aug 19 05:15:12 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD67921F86AA; Fri, 19 Aug 2011 05:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Level: 
X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.963,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxMj4Vgh6fhY; Fri, 19 Aug 2011 05:15:11 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9D85D21F85FE; Fri, 19 Aug 2011 05:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2187; q=dns/txt; s=iport; t=1313756168; x=1314965768; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=Ed/7LH6CI7YCU1gsqd0dQvcUs4YjHx77H2Yzggd1df4=; b=fofjMSQNJ4+ptR/8f7JUzYfVzB1evw5lBf4F/jpGDtbsVG+XXbQssuJI ig6ix0cq/wvP5wC/BF3ge/vA8+5hjZNlNRXLYrwWpBwu2AgzT5slycsxQ FvKV65EuugOzb5tKdjzjgoDoMrkdoFxy5SHGhSaEbwdBClexcAkJXQsQY k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmcIAGVTTk6tJV2Y/2dsb2JhbABBDqd5AneBQAEBAQECAQEBAQ8BJzQHBAULAgEIBw0yJzABAQQTGweHTwSZewGPF49jhWlfBJMThRWLKFQ
X-IronPort-AV: E=Sophos;i="4.68,250,1312156800"; d="scan'208";a="14655809"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 19 Aug 2011 12:16:08 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7JCG85P016198;  Fri, 19 Aug 2011 12:16:08 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 19 Aug 2011 07:16:07 -0500
Received: from 72.163.62.204 ([72.163.62.204]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ;  Fri, 19 Aug 2011 12:16:07 +0000
References: 
Content-Transfer-Encoding: 7bit
From: "Rajiv Asati (rajiva)" 
Content-Type: text/plain; charset="us-ascii"
Thread-Topic: [Softwires] Softwire Interim Meeting in Beijing
Thread-Index: AcxeacXgCPMTNpHFQTCJ5g2wCn1ANw==
In-Reply-To: 
Message-ID: <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com>
Date: Fri, 19 Aug 2011 08:16:05 -0400
To: "Yong Cui" 
MIME-Version: 1.0 (iPhone Mail 8K2)
X-OriginalArrivalTime: 19 Aug 2011 12:16:07.0783 (UTC) FILETIME=[C6441770:01CC5E69]
Cc: softwires@ietf.org, liziye , Yong Cui , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:15:12 -0000

Yong,

Why is dIVI not included In the discussion ?

Could you please clarify? 

Cheers,
Rajiv

Sent from Phone....

On Aug 19, 2011, at 8:10 AM, "Yong Cui"  wrote:

> Hi folks,
> 
> We, softwire wg chairs, in agreement with our ADs, are announcing
> an interim meeting in Beijing on September 26 & 27. The date has
> been chosen adjacent to the BBF meeting in Shangai to minimize
> travel and visa issues.
> 
> The interim meeting will focus on 'stateless' solutions in general
> and 4rd in particular. Expected outcome includes progress on 4rd
> spec, packet format, where to put IPv4 bits, port indications, DHCP
> option, tunneling vs translation, coexistence with other
> technologies, etc...
> 
> ---------------------------------------
> Meeting Location & recommended hotels
> Meeting venue: FIT Building, Tsinghua University, Beijing
> FIT Building is the first left building inside of the East Gate
> of Tsinghua Univeristy
> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
> 
> Recommended hotels:
> 1. Uniscenter (4 stars, 3 min walk)
> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
> 
> 2. Wenjin Hotel (5 stars, 10 min walk)
> http://www.wenjin.com.cn/
> 
> 3. Royal King Hotel (5 stars, 10 min by car)
> http://www.royalkinghotel.com/
> 
> ----------------------------------------
> Invitation letter
> If you need an invitation letter, please send the following info
> to Ms. Ziye Li: .
> Surname: 
> Given Name: 
> Company: 
> Address:
> Phone: 
> Passport Number: 
> Passport Exp. Date:
> Passport Issuing Country:
> 
> 
> 
> -----------------------------------------
> 
> Further contact information
> Please contact Ms. Ziye Li if you have any question about
> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
> 
> 
> 
> -- Alain, Yong
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From mark@townsley.net  Fri Aug 19 05:17:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A779B21F8A64 for ; Fri, 19 Aug 2011 05:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.539
X-Spam-Level: 
X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmWkHHvol5HE for ; Fri, 19 Aug 2011 05:17:53 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A75E21F85B8 for ; Fri, 19 Aug 2011 05:17:53 -0700 (PDT)
Received: by vws12 with SMTP id 12so2932402vws.31 for ; Fri, 19 Aug 2011 05:18:49 -0700 (PDT)
Received: by 10.52.89.129 with SMTP id bo1mr1997716vdb.466.1313756329443; Fri, 19 Aug 2011 05:18:49 -0700 (PDT)
Received: from dhcp184-49-96-34.mwp.atl.wayport.net (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id fc7sm500225vdc.36.2011.08.19.05.18.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 05:18:47 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Townsley 
In-Reply-To: <210E3894-0407-4964-B056-89DC3B502891@gmail.com>
Date: Fri, 19 Aug 2011 08:18:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <958CBEE2-564E-4408-9C3B-FAB3811770D8@townsley.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com>
To: Satoru Matsushima 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:17:54 -0000

Particularly when targeting the consumer appliance space,  fewer =
documents are better than many. Softwires should be working to converge =
on a single concise and clear RFC for the "stateless ds-lite" mode of =
operation. =20

- Mark


On Aug 18, 2011, at 9:08 PM, Satoru Matsushima wrote:

> Hello Remi-san,
>=20
> I've found this mail now.
>=20
> On 2011/07/16, at 22:55, R=E9mi Despr=E9s wrote:
>=20
>> Hi all,
>>=20
>> 1.
>> Being active in the IETF community has been overall enjoyable but, =
for various personal reasons including financial,
>> I will no longer contribute as much as before on v4/v6 transition =
solutions (6rd, 4rd, 6a44).
>=20
> I'd happy to see you now on the list, more actively than before.:)
>=20
> --snip--
>=20
>> 2.
>> Both the proposed translation-based solution =
(draft-murakami-softwire-4v6-translation) and the proposed tunnel-based =
solution (draft-murakami-softwire-4rd) use the v4v6 address mapping =
algorithm, that of 4rd.
>>=20
>> It would therefore be advantageous to have an autonomous I-D on the =
4rd address mapping, and two I-D's pointing to it (for the =
translation-based and for the tunnel-based solution).
>>=20
>=20
> I think that it is interesting idea. I heard you're personally work on =
that with some authors. On the other hand, I don't heard there is =
consensus among current 4rd authors for the separation. Do you have =
enough discussion on this?=20
>=20
> Since collided two documents for same specification would make much =
confusion for people, I recommend you to collaborate with your friend.=20=

>=20
> cheers,
> --satoru
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From yong@csnet1.cs.tsinghua.edu.cn  Fri Aug 19 05:24:13 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF11D21F8A36; Fri, 19 Aug 2011 05:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.048
X-Spam-Level: 
X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, GB_I_LETTER=-2, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6TX9A0t4gXc; Fri, 19 Aug 2011 05:24:13 -0700 (PDT)
Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8E20321F86EC; Fri, 19 Aug 2011 05:23:24 -0700 (PDT)
Received: from [192.168.0.155] (unknown [219.143.155.84]) by mail.csnet1.cs.tsinghua.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id 3DB4F1B040443; Fri, 19 Aug 2011 20:24:17 +0800 (CST)
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Fri, 19 Aug 2011 20:24:14 +0800
From: Yong Cui 
To: "Rajiv Asati (rajiva)" , Yong Cui 
Message-ID: 
Thread-Topic: [Softwires] Softwire Interim Meeting in Beijing
In-Reply-To: <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: softwires@ietf.org, liziye , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:24:13 -0000

Rajiv,

I would be very happy to see the progress of dIVI.
However, according to our current Softwire charter and Milestones,
dIVI is not the most urgent thing to do in Softwire.

Yong

-----Original Message-----
From: "Rajiv Asati (rajiva)" 
Date: Fri, 19 Aug 2011 08:16:05 -0400
To: Yong Cui 
Cc: , liziye , Yong
Cui , , "Ralph Droms
(rdroms)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing

>Yong,
>
>Why is dIVI not included In the discussion ?
>
>Could you please clarify?
>
>Cheers,
>Rajiv
>
>Sent from Phone....
>
>On Aug 19, 2011, at 8:10 AM, "Yong Cui"  wrote:
>
>> Hi folks,
>> 
>> We, softwire wg chairs, in agreement with our ADs, are announcing
>> an interim meeting in Beijing on September 26 & 27. The date has
>> been chosen adjacent to the BBF meeting in Shangai to minimize
>> travel and visa issues.
>> 
>> The interim meeting will focus on 'stateless' solutions in general
>> and 4rd in particular. Expected outcome includes progress on 4rd
>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>> option, tunneling vs translation, coexistence with other
>> technologies, etc...
>> 
>> ---------------------------------------
>> Meeting Location & recommended hotels
>> Meeting venue: FIT Building, Tsinghua University, Beijing
>> FIT Building is the first left building inside of the East Gate
>> of Tsinghua Univeristy
>> 
>>http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b9
>>82
>> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
>> 
>> Recommended hotels:
>> 1. Uniscenter (4 stars, 3 min walk)
>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>> 
>> 2. Wenjin Hotel (5 stars, 10 min walk)
>> http://www.wenjin.com.cn/
>> 
>> 3. Royal King Hotel (5 stars, 10 min by car)
>> http://www.royalkinghotel.com/
>> 
>> ----------------------------------------
>> Invitation letter
>> If you need an invitation letter, please send the following info
>> to Ms. Ziye Li: .
>> Surname: 
>> Given Name: 
>> Company: 
>> Address:
>> Phone: 
>> Passport Number:
>> Passport Exp. Date:
>> Passport Issuing Country:
>> 
>> 
>> 
>> -----------------------------------------
>> 
>> Further contact information
>> Please contact Ms. Ziye Li if you have any question about
>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>> 
>> 
>> 
>> -- Alain, Yong
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires
>
>!DSPAM:1,4e4e543c32102249516215!
>
>



From despres.remi@laposte.net  Fri Aug 19 05:40:22 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764BB21F8A97 for ; Fri, 19 Aug 2011 05:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level: 
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TnSgUwadoAY for ; Fri, 19 Aug 2011 05:40:22 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E9F8321F8A7B for ; Fri, 19 Aug 2011 05:40:20 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4E1CC940108 for ; Fri, 19 Aug 2011 14:41:11 +0200 (CEST)
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Aug 2011 14:41:10 +0200
Message-Id: 
To: Softwires-wg 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Softwires] Separated draft on the Stateless Address Mapping part of 4rd
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:40:22 -0000

Hello all,

The draft where the 4rd "Stateless Address Mapping" is separated from =
tunneling and/or translation mechanisms has just been posted:
https://datatracker.ietf.org/doc/draft-despres-softwire-4rd-addmapping/

In addition to this separation, which permits its use in combination =
with several independent solutions, it is intended to be more complete =
and clearer that what there was in previous SAM and 4rd drafts.

Comments are most welcome.
=20
On behalf of the four authors, kind regards,
RD=

From simon.perreault@viagenie.ca  Fri Aug 19 05:56:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104C621F8AF2 for ; Fri, 19 Aug 2011 05:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level: 
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1JXyOHg+84J for ; Fri, 19 Aug 2011 05:56:45 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E964521F8AEA for ; Fri, 19 Aug 2011 05:56:44 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 40CA021BBB for ; Fri, 19 Aug 2011 08:57:41 -0400 (EDT)
Message-ID: <4E4E5DC4.1010104@viagenie.ca>
Date: Fri, 19 Aug 2011 08:57:40 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com>
In-Reply-To: <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 12:56:46 -0000

On 2011-08-19 05:19, Tetsuya Murakami wrote:
> draft-murakami-softwire-4rd
> draft-murakami-softiwire-4v6-translation
> 
> I think it might be good to combine these 2 drafts to create one unified document for 4rd specification.

The problem I see with this is:

- We (the IETF) might need to specify both translation and encapsulation
protocols, because they have different applicability. (Still needs to be
decided.)

- Operators will choose translation or encapsulation for each
deployment, probably not both.

- Implementations of translation vs encapsulation will probably be very
different. I see this as leading to different "products" or "feature
sets" targeted to different markets. For example 3GPP products might
want to implement translation while broadband products might want to
implement encapsulation.

So in the end, I see an operator A needing the 4rd-Translation solution
and operator B needing the 4rd-Encapsulation solution. This fits nicely
with two different RFCs, is more easily cited in RFPs, etc.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From despres.remi@laposte.net  Fri Aug 19 06:03:05 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DD321F8A7B; Fri, 19 Aug 2011 06:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.876
X-Spam-Level: 
X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVkMP+bzwuwP; Fri, 19 Aug 2011 06:03:05 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id E860121F877F; Fri, 19 Aug 2011 06:03:04 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id DB6B17000103; Fri, 19 Aug 2011 15:04:00 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id 2A6FF70000B4; Fri, 19 Aug 2011 15:03:54 +0200 (CEST)
X-SFR-UUID: 20110819130355173.2A6FF70000B4@msfrf2104.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com>
Date: Fri, 19 Aug 2011 15:03:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F532823-5FA7-42C6-A610-5087D8F3E4D2@laposte.net>
References:  <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com>
To: "Rajiv Asati (rajiva)" , Yong Cui 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg , liziye , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 13:03:05 -0000

Yong, Rajiv,

Le 19 ao=FBt 2011 =E0 14:16, Rajiv Asati (rajiva) a =E9crit :

> Yong,
>=20
> Why is dIVI not included In the discussion ?

In my understanding, differences between dIVI and the proposal of =
draft-murakami-softwire-4v6-translation-00 are minimal.
They both use a double-translation tunneling method, with a stateless =
address mapping between A+P and IPv6.=20

It seems therefore that either double-translation tunneling is out of =
scope, or dIVI is also in scope.=20

Did I miss something?

Regards,
RD


From tnadeau@lucidvision.com  Fri Aug 19 06:21:43 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2238B21F8B03 for ; Fri, 19 Aug 2011 06:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EPclSBEQXLs for ; Fri, 19 Aug 2011 06:21:42 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8D621F8AFD for ; Fri, 19 Aug 2011 06:21:42 -0700 (PDT)
Received: from [10.100.68.81] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id E50851D8DD63; Fri, 19 Aug 2011 09:22:33 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Thomas Nadeau 
In-Reply-To: <958CBEE2-564E-4408-9C3B-FAB3811770D8@townsley.net>
Date: Fri, 19 Aug 2011 09:22:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <958CBEE2-564E-4408-9C3B-FAB3811770D8@townsley.net>
To: Mark Townsley 
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 13:21:43 -0000

	I would agree with Mark on this %100.  The v6 space is already =
confusing enough for some due to the number of options; lets not =
continue that.

	--Tom


> Particularly when targeting the consumer appliance space,  fewer =
documents are better than many. Softwires should be working to converge =
on a single concise and clear RFC for the "stateless ds-lite" mode of =
operation. =20
>=20
> - Mark
>=20
>=20
> On Aug 18, 2011, at 9:08 PM, Satoru Matsushima wrote:
>=20
>> Hello Remi-san,
>>=20
>> I've found this mail now.
>>=20
>> On 2011/07/16, at 22:55, R=E9mi Despr=E9s wrote:
>>=20
>>> Hi all,
>>>=20
>>> 1.
>>> Being active in the IETF community has been overall enjoyable but, =
for various personal reasons including financial,
>>> I will no longer contribute as much as before on v4/v6 transition =
solutions (6rd, 4rd, 6a44).
>>=20
>> I'd happy to see you now on the list, more actively than before.:)
>>=20
>> --snip--
>>=20
>>> 2.
>>> Both the proposed translation-based solution =
(draft-murakami-softwire-4v6-translation) and the proposed tunnel-based =
solution (draft-murakami-softwire-4rd) use the v4v6 address mapping =
algorithm, that of 4rd.
>>>=20
>>> It would therefore be advantageous to have an autonomous I-D on the =
4rd address mapping, and two I-D's pointing to it (for the =
translation-based and for the tunnel-based solution).
>>>=20
>>=20
>> I think that it is interesting idea. I heard you're personally work =
on that with some authors. On the other hand, I don't heard there is =
consensus among current 4rd authors for the separation. Do you have =
enough discussion on this?=20
>>=20
>> Since collided two documents for same specification would make much =
confusion for people, I recommend you to collaborate with your friend.=20=

>>=20
>> cheers,
>> --satoru
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>=20


From xing@cernet.edu.cn  Fri Aug 19 06:23:52 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D980E21F8AFD; Fri, 19 Aug 2011 06:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.549
X-Spam-Level: 
X-Spam-Status: No, score=-99.549 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUrjvCqhqv8k; Fri, 19 Aug 2011 06:23:52 -0700 (PDT)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 875E421F8AD9; Fri, 19 Aug 2011 06:23:51 -0700 (PDT)
Received: from [127.0.0.1]([125.34.46.114]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm344e4ea1a8; Fri, 19 Aug 2011 21:24:14 +0800
Message-ID: <4E4E63FC.5000103@cernet.edu.cn>
Date: Fri, 19 Aug 2011 21:24:12 +0800
From: Xing Li 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= 
References: 	<00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com> <0F532823-5FA7-42C6-A610-5087D8F3E4D2@laposte.net>
In-Reply-To: <0F532823-5FA7-42C6-A610-5087D8F3E4D2@laposte.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: ce6DZu0B
Cc: liziye , "Ralph Droms \(rdroms\)" , Yong Cui , iesg-secretary@ietf.org, Softwires-wg 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 13:23:53 -0000

于 2011/8/19 21:03, RĂ©mi DesprĂ©s 写é“:
> Yong, Rajiv,
>
> Le 19 août 2011 à 14:16, Rajiv Asati (rajiva) a écrit :
>
>> Yong,
>>
>> Why is dIVI not included In the discussion ?
> In my understanding, differences between dIVI and the proposal of draft-murakami-softwire-4v6-translation-00 are minimal.
> They both use a double-translation tunneling method, with a stateless address mapping between A+P and IPv6.
>
> It seems therefore that either double-translation tunneling is out of scope, or dIVI is also in scope.

The dIVI is in scope and we would like to present two drafts

https://datatracker.ietf.org/doc/draft-xli-behave-divi/
https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/

Regards,

xing

> Did I miss something?
>
> Regards,
> RD
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>


From rajiva@cisco.com  Fri Aug 19 06:24:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0DD21F8B1E for ; Fri, 19 Aug 2011 06:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.164
X-Spam-Level: *
X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y72n4cVi7lax for ; Fri, 19 Aug 2011 06:24:46 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE2C21F8B1A for ; Fri, 19 Aug 2011 06:24:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1662; q=dns/txt; s=iport; t=1313760343; x=1314969943; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=DuVgG6nQNB15gPgfxXT1Y1eNeO3QfJufHPoKUCLvQLI=; b=DsmGEYwuqm6KuDLa6dV0WopTiiU5Cy8bnuG2lAswNssWtfQ/LM33YqEu HY8SiYKEIFMJTIUMwmF6m9Nulpd/Ha9ISIEf0XNHQLD1GveeNutawEDPz NDGYDTnpoju59CWkbZtO9TO4YZfxljByVqO2g0afU3I6xhvliolHYl3wT w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjcPABtjTk6tJV2b/2dsb2JhbABBoHKBTIRebAJ3gUABAQEBAgEBAQEPARQTNAsFCwIBCBguJzABAQQTGweHTwSaMAGec4VpXwSTE4UVh2KEGg
X-IronPort-AV: E=Sophos;i="4.68,251,1312156800"; d="scan'208";a="14669347"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 19 Aug 2011 13:25:42 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7JDPga7011108;  Fri, 19 Aug 2011 13:25:42 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 19 Aug 2011 08:25:42 -0500
Received: from 144.254.231.93 ([144.254.231.93]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ;  Fri, 19 Aug 2011 13:25:42 +0000
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com> <4E4E5DC4.1010104@viagenie.ca>
Content-Transfer-Encoding: quoted-printable
From: "Rajiv Asati (rajiva)" 
thread-topic: [Softwires] 4rd mapping rule separation
thread-index: Acxec33yb3oCVGKKRQW78faUrDq0jA==
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <4E4E5DC4.1010104@viagenie.ca>
Message-ID: 
Date: Fri, 19 Aug 2011 09:25:37 -0400
To: "Simon Perreault" 
MIME-Version: 1.0 (iPhone Mail 8K2)
X-OriginalArrivalTime: 19 Aug 2011 13:25:42.0032 (UTC) FILETIME=[7E4FF100:01CC5E73]
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 13:24:46 -0000

+1.=20

The RFP angle is an important one, Simon.

Cheers,
Rajiv

Sent from Phone....

On Aug 19, 2011, at 8:57 AM, "Simon Perreault" =
 wrote:

> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>> draft-murakami-softwire-4rd
>> draft-murakami-softiwire-4v6-translation
>>=20
>> I think it might be good to combine these 2 drafts to create one unified d=
ocument for 4rd specification.
>=20
> The problem I see with this is:
>=20
> - We (the IETF) might need to specify both translation and encapsulation
> protocols, because they have different applicability. (Still needs to be
> decided.)
>=20
> - Operators will choose translation or encapsulation for each
> deployment, probably not both.
>=20
> - Implementations of translation vs encapsulation will probably be very
> different. I see this as leading to different "products" or "feature
> sets" targeted to different markets. For example 3GPP products might
> want to implement translation while broadband products might want to
> implement encapsulation.
>=20
> So in the end, I see an operator A needing the 4rd-Translation solution
> and operator B needing the 4rd-Encapsulation solution. This fits nicely
> with two different RFCs, is more easily cited in RFPs, etc.
>=20
> Simon
> --=20
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From xing@cernet.edu.cn  Fri Aug 19 06:29:07 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABE421F8B17 for ; Fri, 19 Aug 2011 06:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.702
X-Spam-Level: 
X-Spam-Status: No, score=-99.702 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9PhjMVnJwge for ; Fri, 19 Aug 2011 06:29:07 -0700 (PDT)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id B021221F8A30 for ; Fri, 19 Aug 2011 06:29:06 -0700 (PDT)
Received: from [127.0.0.1]([125.34.46.114]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1f4e4ea304; Fri, 19 Aug 2011 21:30:02 +0800
Message-ID: <4E4E6559.4000301@cernet.edu.cn>
Date: Fri, 19 Aug 2011 21:30:01 +0800
From: Xing Li 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Simon Perreault 
References: <4E4B96CB.2020004@skoberne.net>		<4E4BC8E9.4010703@skoberne.net>	<1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com>	<4E4C4251.8020407@skoberne.net>		<4E4D1DC7.5030002@viagenie.ca>	 <4E4E52C7.4040103@viagenie.ca>
In-Reply-To: <4E4E52C7.4040103@viagenie.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: cqIJZu0B
Cc: softwires@ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 13:29:07 -0000

于 2011/8/19 20:10, Simon Perreault 写é“:
> On 2011-08-18 22:03, GangChen wrote:
>> 2011/8/18, Simon Perreault:
>>> On 2011-08-18 09:59, GangChen wrote:
>>>> NAT44 is one of three
>>>> fundamental functions in A+P architecture. Otherwise, it can’t connect
>>>> to legacy end-hosts.
>>> What if in my deployment scenario there are no "legacy" end hosts? What
>>> if all hosts implement A+P-style port ranges?
>>>
>>> I'm with Nejc here. A+P/4rd/... do not require NAT44.
>> And then, how many hosts could support "what if" in the wild
> It's your deployment scenario that requires NAT44, not 4rd itself.
>
> I'm not denying that this deployment scenario is important. Many of us
> are considering the same scenario. All I'm saying is that there is
> another scenario where 4rd would also be applicable that would not
> require NAT44.

This is also the case for dIVI, where NAT44 is an option.

Regards,

xing

> Simon


From rajiva@cisco.com  Fri Aug 19 06:31:12 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E90221F8B23; Fri, 19 Aug 2011 06:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.064,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTUH6EAxJzwD; Fri, 19 Aug 2011 06:31:11 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7570F21F8A30; Fri, 19 Aug 2011 06:31:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3554; q=dns/txt; s=iport; t=1313760728; x=1314970328; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=clqU+Z2+xhHTTeVt4AW5CVPVVL24EL3yBfHPNH9uHMY=; b=Smifu4JQJMWAbcrECQe6ZoijKngEzyLm1XbUt8PN0epLrLxOEDOmHcIk U/4xfWq0CXyysdQo035f9Ejl/Y8uJti5Rm3agBaHx5/qVpEjDlSt1mCGv ObEE6bCNnbX5qOW7zfF2zmMt6WoGNXd8jymM7bg+7vfYCMLX+77dUWjAw U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmoIALxkTk6tJXG+/2dsb2JhbABBDqcObAJ3gUABAQEBAgEBAQEPASc0BwQFBwQCAQgHCgMBAgEuJygIAQEEExsHh08Emh0BjxePXIVpXwSTE4UViyhU
X-IronPort-AV: E=Sophos;i="4.68,251,1312156800"; d="scan'208";a="14672927"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 19 Aug 2011 13:32:08 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7JDW7GZ010094;  Fri, 19 Aug 2011 13:32:07 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 19 Aug 2011 08:32:08 -0500
Received: from 72.163.62.205 ([72.163.62.205]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ;  Fri, 19 Aug 2011 13:32:07 +0000
References: 
Content-Transfer-Encoding: quoted-printable
From: "Rajiv Asati (rajiva)" 
Content-Type: text/plain; charset="us-ascii"
thread-topic: [Softwires] Softwire Interim Meeting in Beijing
In-Reply-To: 
thread-index: AcxedGQs4w3rrccqQLC9ev1451HaBg==
Message-ID: 
Date: Fri, 19 Aug 2011 09:32:04 -0400
To: "Yong Cui" 
MIME-Version: 1.0 (iPhone Mail 8K2)
X-OriginalArrivalTime: 19 Aug 2011 13:32:08.0279 (UTC) FILETIME=[64888E70:01CC5E74]
Cc: softwires@ietf.org, liziye , Yong Cui , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 13:31:12 -0000

Yong,

Thanks for the quick response.

This direction seems contrary to what was conveyed during the v6ops meeting.=
 I am a bit puzzled.=20

Cheers,
Rajiv

Sent from Phone....

On Aug 19, 2011, at 8:24 AM, "Yong Cui"  wro=
te:

> Rajiv,
>=20
> I would be very happy to see the progress of dIVI.
> However, according to our current Softwire charter and Milestones,
> dIVI is not the most urgent thing to do in Softwire.
>=20
> Yong
>=20
> -----Original Message-----
> From: "Rajiv Asati (rajiva)" 
> Date: Fri, 19 Aug 2011 08:16:05 -0400
> To: Yong Cui 
> Cc: , liziye , Yong
> Cui , , "Ralph Droms
> (rdroms)" 
> Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
>=20
>> Yong,
>>=20
>> Why is dIVI not included In the discussion ?
>>=20
>> Could you please clarify?
>>=20
>> Cheers,
>> Rajiv
>>=20
>> Sent from Phone....
>>=20
>> On Aug 19, 2011, at 8:10 AM, "Yong Cui"  wrote:
>>=20
>>> Hi folks,
>>>=20
>>> We, softwire wg chairs, in agreement with our ADs, are announcing
>>> an interim meeting in Beijing on September 26 & 27. The date has
>>> been chosen adjacent to the BBF meeting in Shangai to minimize
>>> travel and visa issues.
>>>=20
>>> The interim meeting will focus on 'stateless' solutions in general
>>> and 4rd in particular. Expected outcome includes progress on 4rd
>>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>>> option, tunneling vs translation, coexistence with other
>>> technologies, etc...
>>>=20
>>> ---------------------------------------
>>> Meeting Location & recommended hotels
>>> Meeting venue: FIT Building, Tsinghua University, Beijing
>>> FIT Building is the first left building inside of the East Gate
>>> of Tsinghua Univeristy
>>>=20
>>> http://maps.google.com/maps/ms?msid=3D202779846620144871057.0004aad8ce36=
7b9
>>> 82
>>> 9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798
>>>=20
>>> Recommended hotels:
>>> 1. Uniscenter (4 stars, 3 min walk)
>>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>>=20
>>> 2. Wenjin Hotel (5 stars, 10 min walk)
>>> http://www.wenjin.com.cn/
>>>=20
>>> 3. Royal King Hotel (5 stars, 10 min by car)
>>> http://www.royalkinghotel.com/
>>>=20
>>> ----------------------------------------
>>> Invitation letter
>>> If you need an invitation letter, please send the following info
>>> to Ms. Ziye Li: .
>>> Surname:=20
>>> Given Name:=20
>>> Company:=20
>>> Address:
>>> Phone:=20
>>> Passport Number:
>>> Passport Exp. Date:
>>> Passport Issuing Country:
>>>=20
>>>=20
>>>=20
>>> -----------------------------------------
>>>=20
>>> Further contact information
>>> Please contact Ms. Ziye Li if you have any question about
>>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>>> 
>>>=20
>>>=20
>>> -- Alain, Yong
>>>=20
>>>=20
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>=20
>> !DSPAM:1,4e4e543c32102249516215!
>>=20
>>=20
>=20
>=20

From adurand@juniper.net  Fri Aug 19 06:45:23 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FACA21F86E0; Fri, 19 Aug 2011 06:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.421
X-Spam-Level: 
X-Spam-Status: No, score=-108.421 tagged_above=-999 required=5 tests=[AWL=2.178, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2,  RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqHh-DvDT3PP; Fri, 19 Aug 2011 06:45:22 -0700 (PDT)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBC321F8B31; Fri, 19 Aug 2011 06:45:01 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTk5pB5eKvliBoAI7Wn6whh0e/n3Fy1Yv@postini.com; Fri, 19 Aug 2011 06:46:19 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 19 Aug 2011 06:43:35 -0700
From: Alain Durand 
To: "Rajiv Asati (rajiva)" 
Date: Fri, 19 Aug 2011 06:43:34 -0700
Thread-Topic: [Softwires] Softwire Interim Meeting in Beijing
Thread-Index: Acxedf5YgU1E4VZ5Raet8f2Vo9reOw==
Message-ID: <34F36BB7-28B8-427E-913A-08332FC8D859@juniper.net>
References:  <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com>
In-Reply-To: <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "softwires@ietf.org" , liziye , Yong Cui , "iesg-secretary@ietf.org" , "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 13:45:23 -0000

We mentioned 'tunneling vs translating'. This should cover it.

Alain.

Sent from my iPad

On Aug 19, 2011, at 8:16 AM, "Rajiv Asati (rajiva)"  wrot=
e:

> Yong,
>=20
> Why is dIVI not included In the discussion ?
>=20
> Could you please clarify?=20
>=20
> Cheers,
> Rajiv
>=20
> Sent from Phone....
>=20
> On Aug 19, 2011, at 8:10 AM, "Yong Cui"  wrote:
>=20
>> Hi folks,
>>=20
>> We, softwire wg chairs, in agreement with our ADs, are announcing
>> an interim meeting in Beijing on September 26 & 27. The date has
>> been chosen adjacent to the BBF meeting in Shangai to minimize
>> travel and visa issues.
>>=20
>> The interim meeting will focus on 'stateless' solutions in general
>> and 4rd in particular. Expected outcome includes progress on 4rd
>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>> option, tunneling vs translation, coexistence with other
>> technologies, etc...
>>=20
>> ---------------------------------------
>> Meeting Location & recommended hotels
>> Meeting venue: FIT Building, Tsinghua University, Beijing
>> FIT Building is the first left building inside of the East Gate
>> of Tsinghua Univeristy
>> http://maps.google.com/maps/ms?msid=3D202779846620144871057.0004aad8ce36=
7b982
>> 9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798
>>=20
>> Recommended hotels:
>> 1. Uniscenter (4 stars, 3 min walk)
>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>=20
>> 2. Wenjin Hotel (5 stars, 10 min walk)
>> http://www.wenjin.com.cn/
>>=20
>> 3. Royal King Hotel (5 stars, 10 min by car)
>> http://www.royalkinghotel.com/
>>=20
>> ----------------------------------------
>> Invitation letter
>> If you need an invitation letter, please send the following info
>> to Ms. Ziye Li: .
>> Surname:=20
>> Given Name:=20
>> Company:=20
>> Address:
>> Phone:=20
>> Passport Number:=20
>> Passport Exp. Date:
>> Passport Issuing Country:
>>=20
>>=20
>>=20
>> -----------------------------------------
>>=20
>> Further contact information
>> Please contact Ms. Ziye Li if you have any question about
>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>> 
>>=20
>>=20
>> -- Alain, Yong
>>=20
>>=20
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From rajiva@cisco.com  Fri Aug 19 08:02:53 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3D21F8AFC; Fri, 19 Aug 2011 08:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.629
X-Spam-Level: 
X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=1.970,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnkNexXDCI+B; Fri, 19 Aug 2011 08:02:52 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 44DC921F85A3; Fri, 19 Aug 2011 08:02:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3444; q=dns/txt; s=iport; t=1313766229; x=1314975829; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gaihdqeTlRLAnbrCjjAHK9hkPDWdqemybuiXrlARZ4g=; b=cXgVGohV+jtIb3VbQ2WVttV568bnaThGseWIbI/eQr28Z6JQ+xFv6YpO LhTwclhXSJ1aEgFmNKb8hMLmvAdebL9WbEb607L06q2+uqEu1VpgIGysW f20tBbxEFoNJ2lSTgMPZ5ITbQedbQw7t+c0govc6CSBlGLB7+bKvE34hX Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtYAABB7Tk6tJXHA/2dsb2JhbABCmCyPYXeBQAEBAQEDAQEBDwEdCjQHBAwEAgEIBwcDAwEBAQEKBhcBBgEmHwkIAQEEEwgTB4dTmX4BjxePWoVpXwSHYJBIi34
X-IronPort-AV: E=Sophos;i="4.68,251,1312156800"; d="scan'208";a="14707004"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 19 Aug 2011 15:03:46 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7JF3kuu008463;  Fri, 19 Aug 2011 15:03:46 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 19 Aug 2011 10:03:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Aug 2011 10:03:45 -0500
Message-ID: <067E6CE33034954AAC05C9EC85E2577C05B1B273@XMB-RCD-111.cisco.com>
In-Reply-To: <34F36BB7-28B8-427E-913A-08332FC8D859@juniper.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Softwire Interim Meeting in Beijing
Thread-Index: Acxedf5YgU1E4VZ5Raet8f2Vo9reOwACqjXQ
References:  <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com> <34F36BB7-28B8-427E-913A-08332FC8D859@juniper.net>
From: "Rajiv Asati (rajiva)" 
To: "Alain Durand" 
X-OriginalArrivalTime: 19 Aug 2011 15:03:46.0013 (UTC) FILETIME=[317030D0:01CC5E81]
Cc: softwires@ietf.org, liziye , Yong Cui , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 15:02:53 -0000

It doesn't, IMO. In fact, I beg to say that it is unfair mention
'tunneling vs translating' as a blanket statement, since we have known
all along that a sane 4v6 solution would likely involve translating
(44), no matter what.

Moreover, it is reasonable to call out all stateless 4v6 options, not
just a particular solution.=20

Cheers,
Rajiv


> -----Original Message-----
> From: Alain Durand [mailto:adurand@juniper.net]
> Sent: Friday, August 19, 2011 9:44 AM
> To: Rajiv Asati (rajiva)
> Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secretary@ietf.org;
Ralph Droms
> (rdroms)
> Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
>=20
> We mentioned 'tunneling vs translating'. This should cover it.
>=20
> Alain.
>=20
> Sent from my iPad
>=20
> On Aug 19, 2011, at 8:16 AM, "Rajiv Asati (rajiva)" 
wrote:
>=20
> > Yong,
> >
> > Why is dIVI not included In the discussion ?
> >
> > Could you please clarify?
> >
> > Cheers,
> > Rajiv
> >
> > Sent from Phone....
> >
> > On Aug 19, 2011, at 8:10 AM, "Yong Cui" 
wrote:
> >
> >> Hi folks,
> >>
> >> We, softwire wg chairs, in agreement with our ADs, are announcing
> >> an interim meeting in Beijing on September 26 & 27. The date has
> >> been chosen adjacent to the BBF meeting in Shangai to minimize
> >> travel and visa issues.
> >>
> >> The interim meeting will focus on 'stateless' solutions in general
> >> and 4rd in particular. Expected outcome includes progress on 4rd
> >> spec, packet format, where to put IPv4 bits, port indications, DHCP
> >> option, tunneling vs translation, coexistence with other
> >> technologies, etc...
> >>
> >> ---------------------------------------
> >> Meeting Location & recommended hotels
> >> Meeting venue: FIT Building, Tsinghua University, Beijing
> >> FIT Building is the first left building inside of the East Gate
> >> of Tsinghua Univeristy
> >>
http://maps.google.com/maps/ms?msid=3D202779846620144871057.0004aad8ce367=
b
982
> >> 9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798
> >>
> >> Recommended hotels:
> >> 1. Uniscenter (4 stars, 3 min walk)
> >>
http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
> >>
> >> 2. Wenjin Hotel (5 stars, 10 min walk)
> >> http://www.wenjin.com.cn/
> >>
> >> 3. Royal King Hotel (5 stars, 10 min by car)
> >> http://www.royalkinghotel.com/
> >>
> >> ----------------------------------------
> >> Invitation letter
> >> If you need an invitation letter, please send the following info
> >> to Ms. Ziye Li: .
> >> Surname:
> >> Given Name:
> >> Company:
> >> Address:
> >> Phone:
> >> Passport Number:
> >> Passport Exp. Date:
> >> Passport Issuing Country:
> >>
> >>
> >>
> >> -----------------------------------------
> >>
> >> Further contact information
> >> Please contact Ms. Ziye Li if you have any question about
> >> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
> >> 
> >>
> >>
> >> -- Alain, Yong
> >>
> >>
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires

From mark@townsley.net  Fri Aug 19 08:10:35 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0253121F8AFE for ; Fri, 19 Aug 2011 08:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r42g1xm3EMi for ; Fri, 19 Aug 2011 08:10:34 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9A21F86AA for ; Fri, 19 Aug 2011 08:10:34 -0700 (PDT)
Received: by vws12 with SMTP id 12so3095453vws.31 for ; Fri, 19 Aug 2011 08:11:30 -0700 (PDT)
Received: by 10.52.176.225 with SMTP id cl1mr2258102vdc.166.1313766690388; Fri, 19 Aug 2011 08:11:30 -0700 (PDT)
Received: from dhcp184-49-96-34.mwp.atl.wayport.net (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id l9sm826059vdv.2.2011.08.19.08.11.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 08:11:29 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Townsley 
In-Reply-To: 
Date: Fri, 19 Aug 2011 11:11:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>  
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 15:10:35 -0000

On Aug 19, 2011, at 5:17 AM, R=E9mi Despr=E9s wrote:

> Also, one of his slides has "4rd aka Stateless DS-lite". He knows, as =
you know, that I had expressed strong opposition to this badly reductive =
view (DS lite is hub and spoke, has no NAT in CPE's, ...).=20

Let me fill you in on some history.

The term "Dual Stack Lite" came into being during a discussion at a cafe =
between Alain Durand and I. It was June 2008, and Alain was in Paris for =
the ICANN meeting while still working for Comcast. We had been =
discussing the various pros and cons of tunneling vs. dual-translation =
for a while. Alain was emphasizing that what was of most importance to =
him as an ISP, was that he not be burdened with provisioning IPv4 within =
the ISP network itself. However, in all cases the service to the =
subscriber was intended to be dual-stack. So: "Dual-stack" service but =
"lighter" on the ISP in terms of management and provisioning. Thus the =
term "dual-stack lite" was born.=20

=46rom the beginning the "lite" term was about having less IPv4 in the =
access network for the operator to manage and provision, while still =
providing dual-stack service to the subscriber. 4rd fits that, as does =
RFC 6333. The solution details are just that - details.=20

- Mark





From marshall.eubanks@gmail.com  Fri Aug 19 08:17:56 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A13121F8A91; Fri, 19 Aug 2011 08:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.347
X-Spam-Level: 
X-Spam-Status: No, score=-105.347 tagged_above=-999 required=5 tests=[AWL=2.251, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2,  HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Ga-15HnMpP; Fri, 19 Aug 2011 08:17:55 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE8621F8A7D; Fri, 19 Aug 2011 08:17:54 -0700 (PDT)
Received: by ywm21 with SMTP id 21so2437470ywm.31 for ; Fri, 19 Aug 2011 08:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H27w7Aqu4GPKqFYLzskT1FgP9BtDIjOT7kUnGm8e8p8=; b=wjK8QMKCdkXfrOO9mWSwLQ1MZFnivIbTEYD4QGGbbj0X5gxIsTotsH58ZnU9MKx8+M L6RreOlRj33kSf0RAXodJfqyf3OiFefQ4IVM6eE6s5OyUTcdn1qT3HpiAYaq3iusaaKB GJO4h8hLg+xls8F/eMnYmpLWbTRXaOK9CeeQQ=
MIME-Version: 1.0
Received: by 10.150.240.13 with SMTP id n13mr2343307ybh.183.1313767130883; Fri, 19 Aug 2011 08:18:50 -0700 (PDT)
Received: by 10.150.202.16 with HTTP; Fri, 19 Aug 2011 08:18:50 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 19 Aug 2011 11:18:50 -0400
Message-ID: 
From: Marshall Eubanks 
To: Yong Cui 
Content-Type: multipart/alternative; boundary=000e0cd355a62768ba04aadd3fb3
Cc: softwires@ietf.org, liziye , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 15:17:56 -0000

--000e0cd355a62768ba04aadd3fb3
Content-Type: text/plain; charset=ISO-8859-1

Did you also have the Secretariat announce this on IETF announce ?

Regards
Marshall

On Fri, Aug 19, 2011 at 8:09 AM, Yong Cui  wrote:

> Hi folks,
>
> We, softwire wg chairs, in agreement with our ADs, are announcing
> an interim meeting in Beijing on September 26 & 27. The date has
> been chosen adjacent to the BBF meeting in Shangai to minimize
> travel and visa issues.
>
> The interim meeting will focus on 'stateless' solutions in general
> and 4rd in particular. Expected outcome includes progress on 4rd
> spec, packet format, where to put IPv4 bits, port indications, DHCP
> option, tunneling vs translation, coexistence with other
> technologies, etc...
>
> ---------------------------------------
> Meeting Location & recommended hotels
> Meeting venue: FIT Building, Tsinghua University, Beijing
> FIT Building is the first left building inside of the East Gate
> of Tsinghua Univeristy
> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
>
> Recommended hotels:
> 1. Uniscenter (4 stars, 3 min walk)
> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>
> 2. Wenjin Hotel (5 stars, 10 min walk)
> http://www.wenjin.com.cn/
>
> 3. Royal King Hotel (5 stars, 10 min by car)
> http://www.royalkinghotel.com/
>
> ----------------------------------------
> Invitation letter
> If you need an invitation letter, please send the following info
> to Ms. Ziye Li: .
> Surname:
> Given Name:
> Company:
> Address:
> Phone:
> Passport Number:
> Passport Exp. Date:
> Passport Issuing Country:
>
>
>
> -----------------------------------------
>
> Further contact information
> Please contact Ms. Ziye Li if you have any question about
> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
> 
>
>
> -- Alain, Yong
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--000e0cd355a62768ba04aadd3fb3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Did you also have the Secretariat announce this on IETF announce ?=A0
<=
br>
Regards
Marshall=A0

On Fri, Aug 19, 2011 at 8:09 AM, Yong Cui <cuiyong@tsinghua.edu.cn> =
wrote:


Hi folks,



We, softwire wg chairs, in agreement with our ADs, are announcing

an interim meeting in Beijing on September 26 & 27. The date has

been chosen adjacent to the BBF meeting in Shangai to minimize

travel and visa issues.



The interim meeting will focus on 'stateless' solutions in general<=
br>
and 4rd in particular. Expected outcome includes progress on 4rd

spec, packet format, where to put IPv4 bits, port indications, DHCP

option, tunneling vs translation, coexistence with other

technologies, etc...



---------------------------------------

Meeting Location & recommended hotels

Meeting venue: FIT Building, Tsinghua University, Beijing

FIT Building is the first left building inside of the East Gate

of Tsinghua Univeristy

http://maps.google.com/maps/ms?msid=3D202779846620144871=
057.0004aad8ce367b982

9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798<=
/a>



Recommended hotels:

1. Uniscenter (4 stars, 3 min walk)

http://en.uniscenter.com/newEbiz1/EbizPortalFG/por=
tal/html/index.html



2. Wenjin Hotel (5 stars, 10 min walk)

http://www.wenjin.c=
om.cn/



3. Royal King Hotel (5 stars, 10 min by car)

http://www.roy=
alkinghotel.com/



----------------------------------------

Invitation letter

If you need an invitation letter, please send the following info

to Ms. Ziye Li: <liz=
iye@csnet1.cs.tsinghua.edu.cn>.

Surname:

Given Name:

Company:

Address:

Phone:

Passport Number:

Passport Exp. Date:

Passport Issuing Country:







-----------------------------------------



Further contact information

Please contact Ms. Ziye Li if you have any question about

Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...

<liziye@csnet1.cs.ts=
inghua.edu.cn>





-- Alain, Yong





_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--000e0cd355a62768ba04aadd3fb3--

From mark@townsley.net  Fri Aug 19 08:20:49 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0242C21F8B01 for ; Fri, 19 Aug 2011 08:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.535
X-Spam-Level: 
X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlMht7dUAEGN for ; Fri, 19 Aug 2011 08:20:48 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9ABE21F8B0D for ; Fri, 19 Aug 2011 08:20:46 -0700 (PDT)
Received: by vxi29 with SMTP id 29so3343007vxi.31 for ; Fri, 19 Aug 2011 08:21:43 -0700 (PDT)
Received: by 10.52.93.76 with SMTP id cs12mr2028613vdb.503.1313767301679; Fri, 19 Aug 2011 08:21:41 -0700 (PDT)
Received: from dhcp184-49-96-34.mwp.atl.wayport.net (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id fn5sm2760126vdc.9.2011.08.19.08.21.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 08:21:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: 
Date: Fri, 19 Aug 2011 11:21:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DE881B1-FDDC-4110-B2C4-C3F084587B95@townsley.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com> <4E4E5DC4.1010104@viagenie.ca> 
To: Rajiv Asati (rajiva) 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 15:20:49 -0000

When the RFP is coming from Best Buy for a consumer device, you want =
fewer alternatives.

- Mark

On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote:

> +1.=20
>=20
> The RFP angle is an important one, Simon.
>=20
> Cheers,
> Rajiv
>=20
> Sent from Phone....
>=20
> On Aug 19, 2011, at 8:57 AM, "Simon Perreault" =
 wrote:
>=20
>> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>>> draft-murakami-softwire-4rd
>>> draft-murakami-softiwire-4v6-translation
>>>=20
>>> I think it might be good to combine these 2 drafts to create one =
unified document for 4rd specification.
>>=20
>> The problem I see with this is:
>>=20
>> - We (the IETF) might need to specify both translation and =
encapsulation
>> protocols, because they have different applicability. (Still needs to =
be
>> decided.)
>>=20
>> - Operators will choose translation or encapsulation for each
>> deployment, probably not both.
>>=20
>> - Implementations of translation vs encapsulation will probably be =
very
>> different. I see this as leading to different "products" or "feature
>> sets" targeted to different markets. For example 3GPP products might
>> want to implement translation while broadband products might want to
>> implement encapsulation.
>>=20
>> So in the end, I see an operator A needing the 4rd-Translation =
solution
>> and operator B needing the 4rd-Encapsulation solution. This fits =
nicely
>> with two different RFCs, is more easily cited in RFPs, etc.
>>=20
>> Simon
>> --=20
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> STUN/TURN server               --> http://numb.viagenie.ca
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From simon.perreault@viagenie.ca  Fri Aug 19 08:29:53 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98F921F8AE6 for ; Fri, 19 Aug 2011 08:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB9Duk1qgYxy for ; Fri, 19 Aug 2011 08:29:53 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0A21F8AD9 for ; Fri, 19 Aug 2011 08:29:52 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B742520D0C; Fri, 19 Aug 2011 11:30:47 -0400 (EDT)
Message-ID: <4E4E81A7.2080706@viagenie.ca>
Date: Fri, 19 Aug 2011 11:30:47 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: Mark Townsley 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com> <4E4E5DC4.1010104@viagenie.ca>  <4DE881B1-FDDC-4110-B2C4-C3F084587B95@townsley.net>
In-Reply-To: <4DE881B1-FDDC-4110-B2C4-C3F084587B95@townsley.net>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 15:29:53 -0000

On 2011-08-19 11:21, Mark Townsley wrote:
> 
> When the RFP is coming from Best Buy for a consumer device, you want fewer alternatives.

That's overly simplifying.

I would expect the standard bodies such as Cable Labs, BBF, 3GPP, etc.
to specify applicability of translation vs encapsulation to their
scenarios. In the end, only one would be needed in each case.

I'd be surprised if I ever see a home router implementing both.

Simon

> On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote:
> 
>> +1. 
>>
>> The RFP angle is an important one, Simon.
>>
>> Cheers,
>> Rajiv
>>
>> Sent from Phone....
>>
>> On Aug 19, 2011, at 8:57 AM, "Simon Perreault"  wrote:
>>
>>> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>>>> draft-murakami-softwire-4rd
>>>> draft-murakami-softiwire-4v6-translation
>>>>
>>>> I think it might be good to combine these 2 drafts to create one unified document for 4rd specification.
>>>
>>> The problem I see with this is:
>>>
>>> - We (the IETF) might need to specify both translation and encapsulation
>>> protocols, because they have different applicability. (Still needs to be
>>> decided.)
>>>
>>> - Operators will choose translation or encapsulation for each
>>> deployment, probably not both.
>>>
>>> - Implementations of translation vs encapsulation will probably be very
>>> different. I see this as leading to different "products" or "feature
>>> sets" targeted to different markets. For example 3GPP products might
>>> want to implement translation while broadband products might want to
>>> implement encapsulation.
>>>
>>> So in the end, I see an operator A needing the 4rd-Translation solution
>>> and operator B needing the 4rd-Encapsulation solution. This fits nicely
>>> with two different RFCs, is more easily cited in RFPs, etc.
>>>
>>> Simon
>>> -- 
>>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>>> STUN/TURN server               --> http://numb.viagenie.ca
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires


-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From tnadeau@lucidvision.com  Fri Aug 19 08:43:57 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05DC21F8AEC for ; Fri, 19 Aug 2011 08:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U8OVaXSMCNh for ; Fri, 19 Aug 2011 08:43:57 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA321F8AF9 for ; Fri, 19 Aug 2011 08:43:57 -0700 (PDT)
Received: from [10.100.68.81] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id E43491D8E9A6; Fri, 19 Aug 2011 11:44:53 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Thomas Nadeau 
In-Reply-To: <4DE881B1-FDDC-4110-B2C4-C3F084587B95@townsley.net>
Date: Fri, 19 Aug 2011 11:44:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <16E83532-90BB-4B4C-AB70-5E3E42CCF06D@lucidvision.com>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com> <4E4E5DC4.1010104@viagenie.ca>  <4DE881B1-FDDC-4110-B2C4-C3F084587B95@townsley.net>
To: Mark Townsley 
X-Mailer: Apple Mail (2.1244.3)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 15:43:58 -0000

	Precisely. Fewer alternatives means cheaper, simpler hardware =
that is ultimately required to run the software necessary to support the =
features.   A myriad of options whether complex or not, is not that.

	--Tom


On Aug 19, 2011, at 11:21 AM, Mark Townsley wrote:

>=20
> When the RFP is coming from Best Buy for a consumer device, you want =
fewer alternatives.
>=20
> - Mark
>=20
> On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote:
>=20
>> +1.=20
>>=20
>> The RFP angle is an important one, Simon.
>>=20
>> Cheers,
>> Rajiv
>>=20
>> Sent from Phone....
>>=20
>> On Aug 19, 2011, at 8:57 AM, "Simon Perreault" =
 wrote:
>>=20
>>> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>>>> draft-murakami-softwire-4rd
>>>> draft-murakami-softiwire-4v6-translation
>>>>=20
>>>> I think it might be good to combine these 2 drafts to create one =
unified document for 4rd specification.
>>>=20
>>> The problem I see with this is:
>>>=20
>>> - We (the IETF) might need to specify both translation and =
encapsulation
>>> protocols, because they have different applicability. (Still needs =
to be
>>> decided.)
>>>=20
>>> - Operators will choose translation or encapsulation for each
>>> deployment, probably not both.
>>>=20
>>> - Implementations of translation vs encapsulation will probably be =
very
>>> different. I see this as leading to different "products" or "feature
>>> sets" targeted to different markets. For example 3GPP products might
>>> want to implement translation while broadband products might want to
>>> implement encapsulation.
>>>=20
>>> So in the end, I see an operator A needing the 4rd-Translation =
solution
>>> and operator B needing the 4rd-Encapsulation solution. This fits =
nicely
>>> with two different RFCs, is more easily cited in RFPs, etc.
>>>=20
>>> Simon
>>> --=20
>>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>>> STUN/TURN server               --> http://numb.viagenie.ca
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>=20


From satoru.matsushima@gmail.com  Fri Aug 19 08:47:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138A221F8A36 for ; Fri, 19 Aug 2011 08:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeLzou-ujCLH for ; Fri, 19 Aug 2011 08:47:36 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8D17F21F8AEC for ; Fri, 19 Aug 2011 08:47:36 -0700 (PDT)
Received: by iye1 with SMTP id 1so5282849iye.27 for ; Fri, 19 Aug 2011 08:48:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tdMmSX4zZ0ZnYwGH2PCLSSEKkvVQiX0toZVukEzS6gw=; b=Yy5avLI4GiABtOXgEWSUXFewMmb4vRBvvXKhsy2s78wQSJJYELJBOMDdkK7pJVdewW 7Yp7cDik1o7elHKetNAIXF3Ed2nqXyywMyASPcx6JIVT7O0VLxsc4iO8Jk9c+4abFH7h mImX0L8x8PBpxsti5IJexQofc88e20iOC+1zQ=
Received: by 10.142.49.6 with SMTP id w6mr891846wfw.213.1313768913292; Fri, 19 Aug 2011 08:48:33 -0700 (PDT)
Received: from [192.168.10.54] (softbank221038132005.bbtec.net [221.38.132.5]) by mx.google.com with ESMTPS id p7sm2423508pbn.49.2011.08.19.08.48.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 08:48:31 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Satoru Matsushima 
In-Reply-To: <4E4E5DC4.1010104@viagenie.ca>
Date: Sat, 20 Aug 2011 00:48:28 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com> <4E4E5DC4.1010104@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1244.3)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 15:47:37 -0000

On 2011/08/19, at 21:57, Simon Perreault wrote:

> So in the end, I see an operator A needing the 4rd-Translation =
solution
> and operator B needing the 4rd-Encapsulation solution. This fits =
nicely
> with two different RFCs, is more easily cited in RFPs, etc.

No problem. We usually cite part of RFC section/subsection to specify =
what we want.
Thanks for your much taking care of your customers.

cheers,
--satoru=

From behcetsarikaya@yahoo.com  Fri Aug 19 09:02:27 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA55821F8783 for ; Fri, 19 Aug 2011 09:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.069
X-Spam-Level: 
X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=0.041,  BAYES_05=-1.11]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT3pgQpQIFkm for ; Fri, 19 Aug 2011 09:02:27 -0700 (PDT)
Received: from nm19.bullet.mail.sp2.yahoo.com (nm19.bullet.mail.sp2.yahoo.com [98.139.91.89]) by ietfa.amsl.com (Postfix) with SMTP id 29A5D21F86EE for ; Fri, 19 Aug 2011 09:02:27 -0700 (PDT)
Received: from [98.139.91.65] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2011 16:03:21 -0000
Received: from [98.139.91.55] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2011 16:03:21 -0000
Received: from [127.0.0.1] by omp1055.mail.sp2.yahoo.com with NNFMP; 19 Aug 2011 16:03:21 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 212598.67408.bm@omp1055.mail.sp2.yahoo.com
Received: (qmail 38672 invoked by uid 60001); 19 Aug 2011 16:03:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313769800; bh=yt9xN6JAqEify5x7Q59hYjyTQont9JlWhAflUZeYAbY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1RzgltXCWsoz3/sMsH3gzDUn56nZDIBC+zgiMnJMd5MqYqsmSTyMiefCceW37LF6wXJNLvmQiweJuvz57VVhgRR2y7FCRNSVGwHDjKKBsX8ZFNiLNwycVBAn+MapT9fzo36nSYN3w0WcH7bmxUi8BUW7ztRseav82FsnqI2l5+g=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wCK02dDW1mcXWviuzjXC982dUiS80RGr3VUEXHzX57PbF+9i+z7G93Qy3tN/3JypUV16sNNZz84RcBs62LGi/B2j49kqVtPoC1HNedU+anag9UDZQxOe3YliHbZmmnEmwuCYo+eq668Ro4S+4inv9/EasC/1psRikHFcKQDOwvk=;
X-YMail-OSG: vKTcgw0VM1nsSpqH.gsn1zA6odocjNwTYUGMehYcuYLg5.j 5r50Eni5b0HysJPiwipfDV4SNRF3Lgc9Hwrg5VEa7hwwJFqW8olOLHgzrRPM fj_fkd0hKW1CH6Wf7D80kMk7iiISQA_QjQl4RRe.qOC7VCnUDIve0Cewqee. TodET_5phBM1lI_.mRLkXLyBJEErFIBVceoo3fkq2bOzjqYhgOsK41Le1_DD lmW.DrP.kYX.BZ5loMo54DqKDwJqMmnwn5Q7oms4dwDv44IN72dsloAYq1UK mhjzTXCaU..PTmY8MLJh.EfHDiWoY1IPZVWwS.76DAZ4MBnurevsoR3ZCC3K gkwMwUazEr_XGvVSfzNuAQfFlNsj3jS4eOlzLqdLcoYZn.pb.WPuWfqk4Cxh WkGhGF.x8.hhmP3onOqfLZmkUOz_RNMn53kCp.wDQzUr7A1W8abnzxtlL13N b9i8gbzk-
Received: from [50.58.7.243] by web111401.mail.gq1.yahoo.com via HTTP; Fri, 19 Aug 2011 09:03:20 PDT
X-Mailer: YahooMailWebService/0.8.113.313619
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net>  <4E4D26A3.6030402@skoberne.net> 
Message-ID: <1313769800.36579.YahooMailNeo@web111401.mail.gq1.yahoo.com>
Date: Fri, 19 Aug 2011 09:03:20 -0700 (PDT)
From: Behcet Sarikaya 
To: GangChen 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 16:02:27 -0000

>>  I am a network/system administrator for my company, which has a very 
> limited
>>  set of public IPv4 addresses. But as I don't want to maintain a 
> separate
>>  IPv4
>>  addressing infrastructure in my network, my server network will be 
> IPv6-only
>>  as well. However, the servers still need IPv4 connectivity, and for that 
> I'd
>>  like to use A+P. This way:
>> 
>>  - I don't need any special ALGs for my servers, which I would have to
>>  develop
>>  first since I am using my own proprietary protocols, which can't 
> traverse
>>  NATs
>>  well,
>> 
>>  - I don't need to maintain IPv4 in my network where I don't want to 
> have it,
>>  especially I don't need to maintain _another_ IPv4 addressing (RFC 
> 1918),
>> 
>>  - I get rid of stateful NAT44 in the core, which is very difficult to make
>>  highly available properly (state synchronization).
>> 
>>  - ...
>> 
>>  ----
>> 
>>  Can you see the benefits now?
> 
> The consumption is to produce a brand-new network. If that is the
> case, I may prefer going to native IPv6 network.



+1

Behcet


From behcetsarikaya@yahoo.com  Fri Aug 19 09:35:36 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE43521F8B34 for ; Fri, 19 Aug 2011 09:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.515
X-Spam-Level: 
X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eI0dFgfJTku for ; Fri, 19 Aug 2011 09:35:36 -0700 (PDT)
Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by ietfa.amsl.com (Postfix) with SMTP id 2766421F8B15 for ; Fri, 19 Aug 2011 09:35:36 -0700 (PDT)
Received: from [98.139.91.69] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2011 16:36:30 -0000
Received: from [98.139.91.40] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2011 16:36:30 -0000
Received: from [127.0.0.1] by omp1040.mail.sp2.yahoo.com with NNFMP; 19 Aug 2011 16:36:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 961031.30340.bm@omp1040.mail.sp2.yahoo.com
Received: (qmail 57460 invoked by uid 60001); 19 Aug 2011 16:36:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313771790; bh=mhHETudhY7lcOzRu67QSb84c5FvqZ4q+WSTs9Sgv1X4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2/tMQwskkvmYNqfk24SPIDxE5oaQzkHqvfnNSrs/R3JHxsUbzsSxNJxGFjrX/QD8qp1qKBhMIP0tc6RqxVTzpjdkkuJ5Ze0o0M8ltEgSBENcIPqprXkVdQoVBPPYJSJ2UCLBJD2QXpZY4okUwl/6MOX5ab0kTlnBA4q6d3eT7Ns=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RjOMTZqGOOfEwt9yAXOk7a4VQ8+QTjrmQXySPyZbz8E4PBgZA3SKeV5iR6xNFObLeppC/FtYZ7hIOt/bKvFpBRR6BAz3A6bMf2gQ+Rmib5A4SH++69UjE/mfrzUo9il5zJDbEOtt8M+FWzhfXBBtAssZ0kbarafPawCKQHyMeHE=;
X-YMail-OSG: KGoqrVcVM1mS0e_9zzBR8bAfVe5UBu5quevZFjRzkgLv5eo OEF_X2piVHvQiyEXdUSsi5MK8pl4g9z1zOGFOKracaCp.qFdyqErpvGLpusZ YOoxr41HU0jFa30HbHUde0XrsYWLmGeNgwid5eJ277BZ1U8W_fJ5xOyq7R4j GVvqvzRq4iZvhDkDu3dNVAzFp8xL.ZN6Gp4oHWhucuizcIVmNUB0qBPzylCg X_PLneX3BetMfoCMX4FGjQqXwstYwEM_8edP7ivKx28LHNZzgcHvdqZKiCNB pJ4PhwGPMGQqdVhupUTtbCm5z_Q.MRS9gAGVhwldoc.6mnaTgict_Rxb4zmZ 4wz6C_BufihtvqvgTUT1VF16eNcZyW4brKTixpWY2C5y2WzcK2M8rmeVUwhj S_9JpQU1UNwtcHRlUP7StD2vHr.N5eQeaMqFKgD4lj7WZQzGFN3bVfaiIW1S tysaflo8-
Received: from [50.58.7.243] by web111401.mail.gq1.yahoo.com via HTTP; Fri, 19 Aug 2011 09:36:30 PDT
X-Mailer: YahooMailWebService/0.8.113.313619
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <958CBEE2-564E-4408-9C3B-FAB3811770D8@townsley.net>
Message-ID: <1313771790.56339.YahooMailNeo@web111401.mail.gq1.yahoo.com>
Date: Fri, 19 Aug 2011 09:36:30 -0700 (PDT)
From: Behcet Sarikaya 
To: Mark Townsley 
In-Reply-To: <958CBEE2-564E-4408-9C3B-FAB3811770D8@townsley.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 16:35:36 -0000

Hi Marc,=0AI am having trouble to see how this thing could be stateless?=0A=
Also I don't see why we should, in view of NAT64 which is already standardi=
zed and there are implementations, why not use it?=0A=0AOf course no offens=
e to my friend Xing Li.=0A=0ARegards,=0A=0ABehcet=0A=0A> Particularly when =
targeting the consumer appliance space,=A0 fewer documents are =0A> better =
than many. Softwires should be working to converge on a single concise =0A>=
 and clear RFC for the "stateless ds-lite" mode of operation.=A0 =0A> =0A> =
- Mark=0A> 

From despres.remi@laposte.net  Fri Aug 19 09:36:20 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2214921F8B5F for ; Fri, 19 Aug 2011 09:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level: 
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWNYS48x7sN9 for ; Fri, 19 Aug 2011 09:36:19 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2276621F8B5E for ; Fri, 19 Aug 2011 09:36:19 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id C13E4700013A; Fri, 19 Aug 2011 18:37:12 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id 7A3C37000133; Fri, 19 Aug 2011 18:37:10 +0200 (CEST)
X-SFR-UUID: 20110819163710500.7A3C37000133@msfrf2303.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4DE881B1-FDDC-4110-B2C4-C3F084587B95@townsley.net>
Date: Fri, 19 Aug 2011 18:37:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com> <4E4E5DC4.1010104@viagenie.ca>  <4DE881B1-FDDC-4110-B2C4-C3F084587B95@townsley.net>
To: Mark Townsley 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 16:36:20 -0000

Le 19 ao=FBt 2011 =E0 17:21, Mark Townsley a =E9crit :

>=20
> When the RFP is coming from Best Buy for a consumer device, you want =
fewer alternatives.

Having the address mapping part separated from the tunneling part =
doesn't increase the number of alternatives, does it?

To reduce the number of alternatives, encapsulation, which is completely =
transparent in all cases (shared and non shared addresses) would be the =
natural choice, but if two solutions are found better for different use =
cases, double translation (=E0 la dIVI or 4rd-T which are essentially =
the same) also makes sense.

RD



>=20
> - Mark
>=20
> On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote:
>=20
>> +1.=20
>>=20
>> The RFP angle is an important one, Simon.
>>=20
>> Cheers,
>> Rajiv
>>=20
>> Sent from Phone....
>>=20
>> On Aug 19, 2011, at 8:57 AM, "Simon Perreault" =
 wrote:
>>=20
>>> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>>>> draft-murakami-softwire-4rd
>>>> draft-murakami-softiwire-4v6-translation
>>>>=20
>>>> I think it might be good to combine these 2 drafts to create one =
unified document for 4rd specification.
>>>=20
>>> The problem I see with this is:
>>>=20
>>> - We (the IETF) might need to specify both translation and =
encapsulation
>>> protocols, because they have different applicability. (Still needs =
to be
>>> decided.)
>>>=20
>>> - Operators will choose translation or encapsulation for each
>>> deployment, probably not both.
>>>=20
>>> - Implementations of translation vs encapsulation will probably be =
very
>>> different. I see this as leading to different "products" or "feature
>>> sets" targeted to different markets. For example 3GPP products might
>>> want to implement translation while broadband products might want to
>>> implement encapsulation.
>>>=20
>>> So in the end, I see an operator A needing the 4rd-Translation =
solution
>>> and operator B needing the 4rd-Encapsulation solution. This fits =
nicely
>>> with two different RFCs, is more easily cited in RFPs, etc.
>>>=20
>>> Simon
>>> --=20
>>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>>> STUN/TURN server               --> http://numb.viagenie.ca
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires



From wwwrun@ietfa.amsl.com  Fri Aug 19 09:57:59 2011
Return-Path: 
X-Original-To: softwires@ietf.org
Delivered-To: softwires@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 30) id 1182F21F8B53; Fri, 19 Aug 2011 09:57:59 -0700 (PDT)
From: IESG Secretary 
To: IETF Announcement list 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20110819165759.1182F21F8B53@ietfa.amsl.com>
Date: Fri, 19 Aug 2011 09:57:59 -0700 (PDT)
Cc: softwires@ietf.org
Subject: [Softwires] SOFTWIRE WG Interim Meeting, September 26-27, 2011, Beijing, China
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 16:57:59 -0000

The SOFTWIRE WG will hold a face-to-face interim meeting in Beijing, 
China on September 26-27, 2011.  Below please find more information from 
the SOFTWIRE chairs.

----------

Hi folks,

We, softwire wg chairs, in agreement with our ADs, are announcing
an interim meeting in Beijing on September 26 & 27. The date has
been chosen adjacent to the BBF meeting in Shangai to minimize
travel and visa issues.

The interim meeting will focus on 'stateless' solutions in general
and 4rd in particular. Expected outcome includes progress on 4rd
spec, packet format, where to put IPv4 bits, port indications, DHCP
option, tunneling vs translation, coexistence with other
technologies, etc...

---------------------------------------
Meeting Location & recommended hotels
Meeting venue: FIT Building, Tsinghua University, Beijing
FIT Building is the first left building inside of the East Gate
of Tsinghua Univeristy
http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798

Recommended hotels:
1. Uniscenter (4 stars, 3 min walk)
http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html

2. Wenjin Hotel (5 stars, 10 min walk)
http://www.wenjin.com.cn/

3. Royal King Hotel (5 stars, 10 min by car)
http://www.royalkinghotel.com/

----------------------------------------
Invitation letter
If you need an invitation letter, please send the following info
to Ms. Ziye Li: .
Surname: 
Given Name: 
Company: 
Address:
Phone: 
Passport Number: 
Passport Exp. Date:
Passport Issuing Country:

-----------------------------------------

Further contact information
Please contact Ms. Ziye Li if you have any question about
Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...


-- Alain, Yong


From despres.remi@laposte.net  Fri Aug 19 10:08:10 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA021F8B3D for ; Fri, 19 Aug 2011 10:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.257
X-Spam-Level: 
X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxFWxTJ+3CId for ; Fri, 19 Aug 2011 10:08:09 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6013021F8B38 for ; Fri, 19 Aug 2011 10:08:07 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9601F94015E; Fri, 19 Aug 2011 19:08:59 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net>
Date: Fri, 19 Aug 2011 19:08:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net>
To: Mark Townsley 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 17:08:10 -0000

Le 19 ao=FBt 2011 =E0 17:11, Mark Townsley a =E9crit :

>=20
> On Aug 19, 2011, at 5:17 AM, R=E9mi Despr=E9s wrote:
>=20
>> Also, one of his slides has "4rd aka Stateless DS-lite". He knows, as =
you know, that I had expressed strong opposition to this badly reductive =
view (DS lite is hub and spoke, has no NAT in CPE's, ...).=20
>=20
> Let me fill you in on some history.
>=20
> The term "Dual Stack Lite" came into being during a discussion at a =
cafe between Alain Durand and I. It was June 2008, and Alain was in =
Paris for the ICANN meeting while still working for Comcast. We had been =
discussing the various pros and cons of tunneling vs. dual-translation =
for a while. Alain was emphasizing that what was of most importance to =
him as an ISP, was that he not be burdened with provisioning IPv4 within =
the ISP network itself. However, in all cases the service to the =
subscriber was intended to be dual-stack. So: "Dual-stack" service but =
"lighter" on the ISP in terms of management and provisioning. Thus the =
term "dual-stack lite" was born.=20

That's a good clarification.

But in the mean time, DS-lite got specified in an RFC that won't change.
RFC6333 says:
- "Dual-Stack Lite enables a broadband service provider to share IPv4 =
addresses among customers by combining two well-known technologies: IP =
in IP (IPv4-in-IPv6) and Network Address Translation (NAT)."
- "the Dual-Stack Lite model is  built on IPv4-in-IPv6 tunnels to cross =
the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR),"=20
- etc.

> =46rom the beginning the "lite" term was about having less IPv4 in the =
access network for the operator to manage and provision, while still =
providing dual-stack service to the subscriber. 4rd fits that, as does =
RFC 6333. The solution details are just that - details.=20

The devil is in details.

Too bad 4rd wasn't invented before DS-lite. It would have better =
deserved the "lite" qualifier, but that's not how things happened.

Because of what RFC6333 says, suggesting NOW that solutions that don't =
need NATs are variants of DS-lite is a sure way to confuse people.

I do hope this discussion will now stop: there are so many technical =
"details" that need to reach common understanding, and agreement.=20
In any case thank you for the really interesting explanation on history.

Cheers.
RD



From jan@go6.si  Fri Aug 19 13:22:19 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2268621F8B80 for ; Fri, 19 Aug 2011 13:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViJzyy3H3RwC for ; Fri, 19 Aug 2011 13:22:18 -0700 (PDT)
Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8673C21F8B76 for ; Fri, 19 Aug 2011 13:22:18 -0700 (PDT)
Received: from jan-mac.local (93-138-3-36.adsl.net.t-com.hr [93.138.3.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id F35592378050; Fri, 19 Aug 2011 22:23:11 +0200 (CEST)
Message-ID: <4E4EC62F.1030609@go6.si>
Date: Fri, 19 Aug 2011 22:23:11 +0200
From: "Jan Zorz @ go6.si" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Satoru Matsushima 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net>  <4E4D728B.8090000@go6.si> <9A4A47E7-43A5-4AF8-AE75-4982D93445E8@gmail.com>
In-Reply-To: <9A4A47E7-43A5-4AF8-AE75-4982D93445E8@gmail.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 20:22:19 -0000

On 8/19/11 4:17 AM, Satoru Matsushima wrote:
>> This way no address translation is needed, just ports needs to be
>> "redirected" to right ones.
> 
> It seems to me that no modification for any system call, correct? 
> AFAIK, Nejc insists some system call modification, bind(), etc.,

Yes, if CPE is doing A+P-PAT, then no modification for any system call.
But this goes for 1 host only :)

Cheers, Jan


From Tina.Tsou.Zouting@huawei.com  Fri Aug 19 13:52:48 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4213421F8610 for ; Fri, 19 Aug 2011 13:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.087
X-Spam-Level: 
X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.512,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTMhV3oSn+F7 for ; Fri, 19 Aug 2011 13:52:47 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 48CD421F85FF for ; Fri, 19 Aug 2011 13:52:47 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ700FHY0PJRL@szxga03-in.huawei.com> for softwires@ietf.org; Sat, 20 Aug 2011 04:53:43 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ700JG50PJH2@szxga03-in.huawei.com> for softwires@ietf.org; Sat, 20 Aug 2011 04:53:43 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADI15522; Sat, 20 Aug 2011 04:53:43 +0800 (CST)
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 20 Aug 2011 04:53:33 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Sat, 20 Aug 2011 04:53:38 +0800
Date: Fri, 19 Aug 2011 20:53:36 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.126]
To: "Rajiv Asati (rajiva)" , Simon Perreault 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] 4rd mapping rule separation
Thread-index: AQHMXgyUReWrqs44AkmjMmAPtdnbP5UjYAGAgAA88QCAAAfPgIABAtDg
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <161A94BB-011F-4021-8774-9772583991BF@ipinfusion.com> <4E4E5DC4.1010104@viagenie.ca> 
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 20:52:48 -0000

+1.
It is fair enough.
But the operators will probably meet more difficulties to change v4 CPE than to change v6 CPE. (Maybe irrelevant to this thread.)


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html



-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Rajiv Asati (rajiva)
Sent: Friday, August 19, 2011 6:26 AM
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation

+1. 

The RFP angle is an important one, Simon.

Cheers,
Rajiv

Sent from Phone....

On Aug 19, 2011, at 8:57 AM, "Simon Perreault"  wrote:

> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>> draft-murakami-softwire-4rd
>> draft-murakami-softiwire-4v6-translation
>> 
>> I think it might be good to combine these 2 drafts to create one unified document for 4rd specification.
> 
> The problem I see with this is:
> 
> - We (the IETF) might need to specify both translation and encapsulation
> protocols, because they have different applicability. (Still needs to be
> decided.)
> 
> - Operators will choose translation or encapsulation for each
> deployment, probably not both.
> 
> - Implementations of translation vs encapsulation will probably be very
> different. I see this as leading to different "products" or "feature
> sets" targeted to different markets. For example 3GPP products might
> want to implement translation while broadband products might want to
> implement encapsulation.
> 
> So in the end, I see an operator A needing the 4rd-Translation solution
> and operator B needing the 4rd-Encapsulation solution. This fits nicely
> with two different RFCs, is more easily cited in RFPs, etc.
> 
> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

From nejc@skoberne.net  Fri Aug 19 14:18:01 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EAD21F8BA7 for ; Fri, 19 Aug 2011 14:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.187
X-Spam-Level: 
X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpU3l2244WJD for ; Fri, 19 Aug 2011 14:18:00 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1A81221F8BA6 for ; Fri, 19 Aug 2011 14:17:59 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 19E69227876A; Fri, 19 Aug 2011 23:18:55 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMUMTmaL+vGR; Fri, 19 Aug 2011 23:18:52 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 03A712278769; Fri, 19 Aug 2011 23:18:47 +0200 (CEST)
Message-ID: <4E4ED337.3070100@skoberne.net>
Date: Fri, 19 Aug 2011 22:18:47 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Brian E Carpenter 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com>
In-Reply-To: <4E4DA1C2.40307@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 21:18:01 -0000

Dear Brian,

>> won't work. But in "my world", A+P-enabled hosts are connected to the
>> IPv6 network directly.
>
> And how will that support legacy SOHO LANs?

It will not, because I don't have a legacy SOHO LAN. If I have legacy 
SOHO LAN, I can use (optional) NAT44.

Nejc

From nejc@skoberne.net  Fri Aug 19 14:20:32 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF8A11E80DA for ; Fri, 19 Aug 2011 14:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.193
X-Spam-Level: 
X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUHqjRdXlQxr for ; Fri, 19 Aug 2011 14:20:32 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 03E7A11E80E8 for ; Fri, 19 Aug 2011 14:20:32 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 41111227876A for ; Fri, 19 Aug 2011 23:21:29 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obkj+Lsu1vjs for ; Fri, 19 Aug 2011 23:21:29 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id C3C8E2278769 for ; Fri, 19 Aug 2011 23:21:28 +0200 (CEST)
Message-ID: <4E4ED3D8.7020304@skoberne.net>
Date: Fri, 19 Aug 2011 22:21:28 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net>  <4E4D1DC7.5030002@viagenie.ca> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 21:20:33 -0000

Dear Gang,

>> What if in my deployment scenario there are no "legacy" end hosts? What
>> if all hosts implement A+P-style port ranges?
>>
>> I'm with Nejc here. A+P/4rd/... do not require NAT44.
> 
> And then, how many hosts could support "what if" in the wild

I don't see why this is important. Anyway, the answer is "hopefully
more and more". Isn't encouraging the transition to IPv6 one of the 
major "commandments" of IETF?

Nejc

From nejc@skoberne.net  Fri Aug 19 14:33:29 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14FB11E80F3 for ; Fri, 19 Aug 2011 14:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YwgHQwCjRM1 for ; Fri, 19 Aug 2011 14:33:29 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 233A611E80F2 for ; Fri, 19 Aug 2011 14:33:29 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 71A8D2278760; Fri, 19 Aug 2011 23:34:26 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooAiWioyWbho; Fri, 19 Aug 2011 23:34:26 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id F13A1227875E; Fri, 19 Aug 2011 23:34:25 +0200 (CEST)
Message-ID: <4E4ED6E1.5090402@skoberne.net>
Date: Fri, 19 Aug 2011 22:34:25 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: GangChen 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net>  <4E4D26A3.6030402@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 21:33:29 -0000

Dear Gang,

> "NOT PRACTICABLE" has two meanings.
> 1) Restricted port aware host is relatively few case

Since we are not developing mechanisms for the period of the next few
months, I don't think this argument is relevant. Long term, there
might (hopefully) be more such hosts.

> 2) Socket need to be modified. That is a practical challenge, not only
> bind() but also connect()

This is just one of the ways to implement this. See Jan's mail on PAT.

> The consumption is to produce a brand-new network. If that is the
> case, I may prefer going to native IPv6 network.

I am very sorry, but I don't understand what you mean with your first
sentence. Of course I want/will go to native IPv6 network, but during
the IPv4/IPv6 coexistence, I will need IPv4 connectivity as well! And
this is why I want my hosts, connected to IPv6-only network, to also
support A+P. So I don't need any nat.

If you think my arguments don't hold, please comment on them one-by-one
so that I understand why they don't hold.

Thanks,
Nejc


From nejc@skoberne.net  Fri Aug 19 14:33:33 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCDB11E80F6 for ; Fri, 19 Aug 2011 14:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1SubTZoX+yJ for ; Fri, 19 Aug 2011 14:33:33 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id C746711E80F2 for ; Fri, 19 Aug 2011 14:33:32 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id E872D2278769; Fri, 19 Aug 2011 23:34:29 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT6uV4cFJYcx; Fri, 19 Aug 2011 23:34:29 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 25F3C227875E; Fri, 19 Aug 2011 23:34:29 +0200 (CEST)
Message-ID: <4E4ED6E5.6020505@skoberne.net>
Date: Fri, 19 Aug 2011 22:34:29 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Satoru Matsushima 
References: <4E4B96CB.2020004@skoberne.net>  <4E4BC8E9.4010703@skoberne.net> <1313620188.92723.YahooMailNeo@web111408.mail.gq1.yahoo.com> <4E4C4251.8020407@skoberne.net>  <4E4D728B.8090000@go6.si> <9A4A47E7-43A5-4AF8-AE75-4982D93445E8@gmail.com>
In-Reply-To: <9A4A47E7-43A5-4AF8-AE75-4982D93445E8@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 21:33:33 -0000

Dear Satoru,

>>> A+P is the same case if I understand correctly. NAT44 is one of three
>>> fundamental functions in A+P architecture. Otherwise, it can’t connect
>>> to legacy end-hosts.
>>
>> Usually yes, but not necessary. PAT could also do the work, if you connect behind CPE a host with public IP address, sort of like "bridged mode", and PAT in CPE changes ports to ones inside port-range/set.
>>
>> This way no address translation is needed, just ports needs to be "redirected" to right ones.
> 
> It seems to me that no modification for any system call, correct?
> AFAIK, Nejc insists some system call modification, bind(), etc.,

I don't insist on any specific implementation. I just insist on NAPT44
being optional. It may be done with changing the host, but it might
be also done with the PAT, as Jan says (although in this case, there
are significant other issues). It just doesn't matter how it is done.

Again, all other A+P drafts out there, allow for such a scenario.
"4via6 translation" is the only one which does not.

Thanks,
Nejc


From brian.e.carpenter@gmail.com  Fri Aug 19 16:12:07 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1755A21F8B03 for ; Fri, 19 Aug 2011 16:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.449
X-Spam-Level: 
X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlTBUnIDN6LN for ; Fri, 19 Aug 2011 16:12:06 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E93021F8A30 for ; Fri, 19 Aug 2011 16:12:06 -0700 (PDT)
Received: by fxe6 with SMTP id 6so2450777fxe.31 for ; Fri, 19 Aug 2011 16:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PhbBTX9PkzP+HWgVBnvYBjkLFuOmX0pBRATRh0HCGlU=; b=HOplePaPbGbe1CdAu/yB8bG5wfM61Zf4u/jMZPYgExooWJgBYeGo0itOvkmYRlBdn2 kbrvB4EnKHZ2cvmH9TEJulDx/ZVBOrlFz8KINLynYjJA8kMaXrPoHNb5MvFJz+IUHPXp Y8EJ0CnIyasIDkWs5y7a/lO+5o/VoJoO4ORLE=
Received: by 10.223.62.76 with SMTP id w12mr341349fah.123.1313795578968; Fri, 19 Aug 2011 16:12:58 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id p4sm1656243fah.1.2011.08.19.16.12.54 (version=SSLv3 cipher=OTHER); Fri, 19 Aug 2011 16:12:58 -0700 (PDT)
Message-ID: <4E4EEDF0.5090400@gmail.com>
Date: Sat, 20 Aug 2011 11:12:48 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net>
In-Reply-To: <4E4ED337.3070100@skoberne.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 23:12:07 -0000

On 2011-08-20 09:18, Nejc =C5=A0koberne wrote:
> Dear Brian,
>=20
>>> won't work. But in "my world", A+P-enabled hosts are connected to the=

>>> IPv6 network directly.
>>
>> And how will that support legacy SOHO LANs?
>=20
> It will not, because I don't have a legacy SOHO LAN. If I have legacy
> SOHO LAN, I can use (optional) NAT44.

Exactly, resulting in NAT444 . But if I'm forced to use NAT444
via a 4 in 6 tunnel anyway, A+P is pointless.

    Brian


From nejc@skoberne.net  Fri Aug 19 16:21:19 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DF421F8B79 for ; Fri, 19 Aug 2011 16:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.207
X-Spam-Level: 
X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxuhDW4mZp8w for ; Fri, 19 Aug 2011 16:21:19 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 405E521F8B26 for ; Fri, 19 Aug 2011 16:21:19 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 6CC70227876A for ; Sat, 20 Aug 2011 01:22:15 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL045yw9unsL for ; Sat, 20 Aug 2011 01:22:13 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 082EC2278769 for ; Sat, 20 Aug 2011 01:22:12 +0200 (CEST)
Message-ID: <4E4EF023.2040407@skoberne.net>
Date: Sat, 20 Aug 2011 00:22:11 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>
In-Reply-To: <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 23:21:20 -0000

Dear Rémi,

> Whether Encapsulation and Double-translation methods will remain in separate drafts or might be regrouped in a single one including their comparison is, as far as I am concerned, an open question (neither in favor nor against).

Not being in favor of a wide palette of different documents for very 
similar things, I am very inclined to the idea of merging them into
one document.

Nejc

From nejc@skoberne.net  Fri Aug 19 16:40:06 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6211E80A2 for ; Fri, 19 Aug 2011 16:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.211
X-Spam-Level: 
X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkaLG2YbU7Kq for ; Fri, 19 Aug 2011 16:40:06 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3478D11E8083 for ; Fri, 19 Aug 2011 16:40:06 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id A9D05227876A; Sat, 20 Aug 2011 01:41:03 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeZrQ8zCCQV6; Sat, 20 Aug 2011 01:41:03 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 651132278769; Sat, 20 Aug 2011 01:41:02 +0200 (CEST)
Message-ID: <4E4EF48D.6020500@skoberne.net>
Date: Sat, 20 Aug 2011 00:41:01 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Brian E Carpenter 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com>
In-Reply-To: <4E4EEDF0.5090400@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 23:40:06 -0000

>> It will not, because I don't have a legacy SOHO LAN. If I have legacy
>> SOHO LAN, I can use (optional) NAT44.
> 
> Exactly, resulting in NAT444 . But if I'm forced to use NAT444
> via a 4 in 6 tunnel anyway, A+P is pointless.

I don't think you understood what I was saying. There is no need for NAT444. 

Let me explain again. The provider has an A+P solution in place. They will,
by default, provide me with their CPE, which supports A+P and also does
NAPT44 for my legacy SOHO LAN. In this case, I just plug my computers and
everything will work like today, just with not-so-many ports.

However, there are at least two more possible scenarios I can imagine:

1.) I don't want the provider's CPE since I have my home gateway-server, 
which supports A+P and is connected directly to the ISP. This server will 
have a public IPv4 address configured and if I need, it /can/ then do 
NAPT44 (instead of the CPE) for the rest of my legacy LAN.

2.) I don't want the provider's CPE since my computers actually support
A+P mechanism of the provider. I have IPv6-only network in my LAN and
IPv4 addressing is brought directly to hosts via A+P mechanism. So it
is like "extending" the access network to my home. This scenario is also
shown on page 16, Figure 6 in draft-ymbk-aplusp-10.

Nejc



From nejc@skoberne.net  Fri Aug 19 17:03:16 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9DC21F8880 for ; Fri, 19 Aug 2011 17:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.215
X-Spam-Level: 
X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.084,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAB7c8aiKpUR for ; Fri, 19 Aug 2011 17:03:15 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id B113C21F8862 for ; Fri, 19 Aug 2011 17:03:15 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id F176D227876A for ; Sat, 20 Aug 2011 02:04:12 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydA7XOANl1Jo for ; Sat, 20 Aug 2011 02:04:12 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-227-202.lut.ac.uk [158.125.227.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 78C6D2278769 for ; Sat, 20 Aug 2011 02:04:12 +0200 (CEST)
Message-ID: <4E4EF9FC.8020407@skoberne.net>
Date: Sat, 20 Aug 2011 01:04:12 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net>
In-Reply-To: <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 00:03:16 -0000

> Because of what RFC6333 says, suggesting NOW that solutions that don't need NATs are variants of DS-lite is a sure way to confuse people.

+1

Nejc

From mark@townsley.net  Fri Aug 19 18:54:40 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CF021F8AF0 for ; Fri, 19 Aug 2011 18:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsIsGLwvWIQb for ; Fri, 19 Aug 2011 18:54:39 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4121F8AEA for ; Fri, 19 Aug 2011 18:54:39 -0700 (PDT)
Received: by qyk34 with SMTP id 34so540864qyk.10 for ; Fri, 19 Aug 2011 18:55:36 -0700 (PDT)
Received: by 10.224.188.76 with SMTP id cz12mr46290qab.26.1313805336458; Fri, 19 Aug 2011 18:55:36 -0700 (PDT)
Received: from 72-254-144-97.client.stsn.net (72-254-144-97.client.stsn.net [72.254.144.97]) by mx.google.com with ESMTPS id fl1sm5661522qab.13.2011.08.19.18.55.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 18:55:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-111-490683062
From: Mark Townsley 
In-Reply-To: <4E4EF9FC.8020407@skoberne.net>
Date: Fri, 19 Aug 2011 21:55:31 -0400
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <4E4EF9FC.8020407@skoberne.net>
To: =?windows-1252?Q?Nejc_=8Akoberne?= 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 01:54:40 -0000

--Apple-Mail-111-490683062
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Aug 19, 2011, at 8:04 PM, Nejc =8Akoberne wrote:

>> Because of what RFC6333 says, suggesting NOW that solutions that =
don't need NATs are variants of DS-lite is a sure way to confuse people.

Then we're already confused:

http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03

- Mark

>=20
> +1
>=20
> Nejc
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


--Apple-Mail-111-490683062
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Because of what RFC6333 =
says, suggesting NOW that solutions that don't need NATs are variants of =
DS-lite is a sure way to confuse =
people.

Then =
we're already confused:

http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03

- Mark


+1

Nejc
_________________________________=
______________
Softwires mailing list
Softwires@ietf.org
https://www.i=
etf.org/mailman/listinfo/softwires

=
=

--Apple-Mail-111-490683062--

From mark@townsley.net  Fri Aug 19 19:04:30 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF2F21F85F2 for ; Fri, 19 Aug 2011 19:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFrW0DCUICy2 for ; Fri, 19 Aug 2011 19:04:29 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6DC21F85C6 for ; Fri, 19 Aug 2011 19:04:29 -0700 (PDT)
Received: by gxk19 with SMTP id 19so3030579gxk.31 for ; Fri, 19 Aug 2011 19:05:27 -0700 (PDT)
Received: by 10.236.161.227 with SMTP id w63mr203204yhk.57.1313805927433; Fri, 19 Aug 2011 19:05:27 -0700 (PDT)
Received: from 72-254-144-97.client.stsn.net (72-254-144-97.client.stsn.net [72.254.144.97]) by mx.google.com with ESMTPS id e21sm557042yhn.63.2011.08.19.19.05.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 19:05:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-112-491270752
From: Mark Townsley 
In-Reply-To: <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net>
Date: Fri, 19 Aug 2011 22:05:19 -0400
Message-Id: <9CED3349-22B8-49EC-B72C-77CD52D52427@townsley.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 02:04:30 -0000

--Apple-Mail-112-491270752
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Aug 19, 2011, at 1:08 PM, R=E9mi Despr=E9s wrote:

>=20
> Le 19 ao=FBt 2011 =E0 17:11, Mark Townsley a =E9crit :
>=20
>>=20
>> On Aug 19, 2011, at 5:17 AM, R=E9mi Despr=E9s wrote:
>>=20
>>> Also, one of his slides has "4rd aka Stateless DS-lite". He knows, =
as you know, that I had expressed strong opposition to this badly =
reductive view (DS lite is hub and spoke, has no NAT in CPE's, ...).=20
>>=20
>> Let me fill you in on some history.
>>=20
>> The term "Dual Stack Lite" came into being during a discussion at a =
cafe between Alain Durand and I. It was June 2008, and Alain was in =
Paris for the ICANN meeting while still working for Comcast. We had been =
discussing the various pros and cons of tunneling vs. dual-translation =
for a while. Alain was emphasizing that what was of most importance to =
him as an ISP, was that he not be burdened with provisioning IPv4 within =
the ISP network itself. However, in all cases the service to the =
subscriber was intended to be dual-stack. So: "Dual-stack" service but =
"lighter" on the ISP in terms of management and provisioning. Thus the =
term "dual-stack lite" was born.=20
>=20
> That's a good clarification.
>=20
> But in the mean time, DS-lite got specified in an RFC that won't =
change.

But RFC's get updated all the time, as does terminology. Adding an =
adjective to something that is well understood to indicate that it can =
serve the same purpose but in a different way is quite useful during the =
introduction of that technology. Think "Horseless Carriage"=20

http://en.wikipedia.org/wiki/Retronym

A retronym is a type of neologism that provides a new name for an object =
or concept to differentiate the original form or version of it from a =
more recent form or version.[1] The original name is most often =
augmented with an adjective (rather than being completely displaced) to =
account for later developments of the object or concept itself. Much =
retronymy is driven by advances in technology.

- Mark

> RFC6333 says:
> - "Dual-Stack Lite enables a broadband service provider to share IPv4 =
addresses among customers by combining two well-known technologies: IP =
in IP (IPv4-in-IPv6) and Network Address Translation (NAT)."
> - "the Dual-Stack Lite model is  built on IPv4-in-IPv6 tunnels to =
cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR),"=20
> - etc.
>=20
>> =46rom the beginning the "lite" term was about having less IPv4 in =
the access network for the operator to manage and provision, while still =
providing dual-stack service to the subscriber. 4rd fits that, as does =
RFC 6333. The solution details are just that - details.=20
>=20
> The devil is in details.
>=20
> Too bad 4rd wasn't invented before DS-lite. It would have better =
deserved the "lite" qualifier, but that's not how things happened.
>=20
> Because of what RFC6333 says, suggesting NOW that solutions that don't =
need NATs are variants of DS-lite is a sure way to confuse people.
>=20
> I do hope this discussion will now stop: there are so many technical =
"details" that need to reach common understanding, and agreement.=20
> In any case thank you for the really interesting explanation on =
history.
>=20
> Cheers.
> RD
>=20
>=20


--Apple-Mail-112-491270752
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



Le 19 ao=FBt 2011 =E0 17:11, Mark Townsley a =
=E9crit :


On Aug 19, 2011, at 5:17 AM, R=E9mi Despr=E9s =
wrote:

Also, one of his slides has "4rd aka Stateless DS-lite". =
He knows, as you know, that I had expressed strong opposition to this =
badly reductive view (DS lite is hub and spoke, has no NAT in CPE's, =
...). 

Let me fill you =
in on some history.

The term "Dual =
Stack Lite" came into being during a discussion at a cafe between Alain =
Durand and I. It was June 2008, and Alain was in Paris for the ICANN =
meeting while still working for Comcast. We had been discussing the =
various pros and cons of tunneling vs. dual-translation for a while. =
Alain was emphasizing that what was of most importance to him as an ISP, =
was that he not be burdened with provisioning IPv4 within the ISP =
network itself. However, in all cases the service to the subscriber was =
intended to be dual-stack. So: "Dual-stack" service but "lighter" on the =
ISP in terms of management and provisioning. Thus the term "dual-stack =
lite" was born. 

That's a good =
clarification.

But in the mean time, DS-lite got specified in an =
RFC that won't change.

But =
RFC's get updated all the time, as does terminology. Adding an adjective =
to something that is well understood to indicate that it can serve the =
same purpose but in a different way is quite useful during the =
introduction of that technology. Think "Horseless =
Carriage" 


neologism that provides a new name for an =
object or concept to differentiate the original form or version of it =
from a more recent form or version.
RFC6333 says:
- "Dual-Stack Lite enables a =
broadband service provider to share IPv4 addresses among customers by =
combining two well-known technologies: IP in IP (IPv4-in-IPv6) and =
Network Address Translation (NAT)."
- "the Dual-Stack Lite model is =
 built on IPv4-in-IPv6 tunnels to cross the network to reach a =
carrier-grade IPv4-IPv4 NAT (the AFTR)," 
- etc.

=46rom the beginning the "lite" term was about having less =
IPv4 in the access network for the operator to manage and provision, =
while still providing dual-stack service to the subscriber. 4rd fits =
that, as does RFC 6333. The solution details are just that - details. =


The devil is in details.

Too bad 4rd wasn't =
invented before DS-lite. It would have better deserved the "lite" =
qualifier, but that's not how things happened.

Because of what =
RFC6333 says, suggesting NOW that solutions that don't need NATs are =
variants of DS-lite is a sure way to confuse people.

I do hope =
this discussion will now stop: there are so many technical "details" =
that need to reach common understanding, and agreement. 
In any case =
thank you for the really interesting explanation on =
history.

Cheers.
RD



=

--Apple-Mail-112-491270752--

From brian.e.carpenter@gmail.com  Fri Aug 19 21:14:42 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C61021F8AEE for ; Fri, 19 Aug 2011 21:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.444
X-Spam-Level: 
X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjCtbTLr-5LC for ; Fri, 19 Aug 2011 21:14:41 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF2721F8AEA for ; Fri, 19 Aug 2011 21:14:41 -0700 (PDT)
Received: by fxe6 with SMTP id 6so2530820fxe.31 for ; Fri, 19 Aug 2011 21:15:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=J0LpKbPDL63oqJz9m6bwTG75bFkCoejBO9qLfbZ8zcw=; b=C0UXdJgCLwI7eD6gtMbreOmPbTbCFkMSJfFO7KwiUoXrERAgOsgO6Borqmskc1svlI 3YCtEXUNd2mMiIfU40k80umJoxI0IMrw5FjEhIEkhnNFSHbe4F1s/FSo7TjL4ciPL7/3 uHQfkoVodbHNWZgRMGR3qhA+PMJ70fIYpprcM=
Received: by 10.223.29.9 with SMTP id o9mr205746fac.131.1313813739536; Fri, 19 Aug 2011 21:15:39 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id q3sm3073283faa.15.2011.08.19.21.15.35 (version=SSLv3 cipher=OTHER); Fri, 19 Aug 2011 21:15:38 -0700 (PDT)
Message-ID: <4E4F34E1.3040305@gmail.com>
Date: Sat, 20 Aug 2011 16:15:29 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net>
In-Reply-To: <4E4EF48D.6020500@skoberne.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 04:14:42 -0000

Ahah, you seem to assume that A+P will solve the ISP's shortage
of IPv4 addresses. That may be true for a year or three, but
after that they will discover that they have to CGN their A+P
customers, and then you have NAT444 after all, IMHO.

Regards
   Brian

On 2011-08-20 11:41, Nejc =C5=A0koberne wrote:
>>> It will not, because I don't have a legacy SOHO LAN. If I have legacy=

>>> SOHO LAN, I can use (optional) NAT44.
>> Exactly, resulting in NAT444 . But if I'm forced to use NAT444
>> via a 4 in 6 tunnel anyway, A+P is pointless.
>=20
> I don't think you understood what I was saying. There is no need for NA=
T444.=20
>=20
> Let me explain again. The provider has an A+P solution in place. They w=
ill,
> by default, provide me with their CPE, which supports A+P and also does=

> NAPT44 for my legacy SOHO LAN. In this case, I just plug my computers a=
nd
> everything will work like today, just with not-so-many ports.
>=20
> However, there are at least two more possible scenarios I can imagine:
>=20
> 1.) I don't want the provider's CPE since I have my home gateway-server=
,=20
> which supports A+P and is connected directly to the ISP. This server wi=
ll=20
> have a public IPv4 address configured and if I need, it /can/ then do=20
> NAPT44 (instead of the CPE) for the rest of my legacy LAN.
>=20
> 2.) I don't want the provider's CPE since my computers actually support=

> A+P mechanism of the provider. I have IPv6-only network in my LAN and
> IPv4 addressing is brought directly to hosts via A+P mechanism. So it
> is like "extending" the access network to my home. This scenario is als=
o
> shown on page 16, Figure 6 in draft-ymbk-aplusp-10.
>=20
> Nejc
>=20
>=20
>=20


From cx.cernet@gmail.com  Fri Aug 19 22:01:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A47221F8AFE; Fri, 19 Aug 2011 22:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.971
X-Spam-Level: 
X-Spam-Status: No, score=-4.971 tagged_above=-999 required=5 tests=[AWL=2.627,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ymn70ocpT4z; Fri, 19 Aug 2011 22:01:53 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 242ED21F8ABB; Fri, 19 Aug 2011 22:01:53 -0700 (PDT)
Received: by pzk33 with SMTP id 33so9996635pzk.18 for ; Fri, 19 Aug 2011 22:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=elI98m70lK0R/HIVBSq+Nt6XwN6J87I8YtIztvS8OWQ=; b=OsJKNZuf0Gfm0gINYYvrdGTcQ4B1va+HVqnFtlt5SmfRQ0IRvTxjBZh65goUTJ0aCx Lg9ByQMxVibOU3flkMCh8EoPAEGMpEmb4Dv49QmSay8U9VLgkZnK02Be2EBHZfsiX9Az CPs75csqhE8TLM3TBqPUPhEricIBosu/+rgng=
MIME-Version: 1.0
Received: by 10.142.246.6 with SMTP id t6mr102604wfh.320.1313816570206; Fri, 19 Aug 2011 22:02:50 -0700 (PDT)
Received: by 10.142.213.7 with HTTP; Fri, 19 Aug 2011 22:02:50 -0700 (PDT)
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05B1B273@XMB-RCD-111.cisco.com>
References:  <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com> <34F36BB7-28B8-427E-913A-08332FC8D859@juniper.net> <067E6CE33034954AAC05C9EC85E2577C05B1B273@XMB-RCD-111.cisco.com>
Date: Sat, 20 Aug 2011 13:02:50 +0800
Message-ID: 
From: Congxiao Bao 
To: "Rajiv Asati (rajiva)" 
Content-Type: multipart/alternative; boundary=000e0cd1b1faf79bc504aae8c1d7
Cc: liziye , "Ralph Droms \(rdroms\)" , Yong Cui , iesg-secretary@ietf.org, softwires@ietf.org
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 05:01:54 -0000

--000e0cd1b1faf79bc504aae8c1d7
Content-Type: text/plain; charset=ISO-8859-1

2011/8/19 Rajiv Asati (rajiva) 

> It doesn't, IMO. In fact, I beg to say that it is unfair mention
> 'tunneling vs translating' as a blanket statement, since we have known
> all along that a sane 4v6 solution would likely involve translating
> (44), no matter what.
>
> Moreover, it is reasonable to call out all stateless 4v6 options, not
> just a particular solution.
>

I agree.

Congxiao

>
> Cheers,
> Rajiv
>
>
> > -----Original Message-----
> > From: Alain Durand [mailto:adurand@juniper.net]
> > Sent: Friday, August 19, 2011 9:44 AM
> > To: Rajiv Asati (rajiva)
> > Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secretary@ietf.org;
> Ralph Droms
> > (rdroms)
> > Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
> >
>  > We mentioned 'tunneling vs translating'. This should cover it.
> >
> > Alain.
> >
> > Sent from my iPad
> >
> > On Aug 19, 2011, at 8:16 AM, "Rajiv Asati (rajiva)" 
> wrote:
> >
> > > Yong,
> > >
> > > Why is dIVI not included In the discussion ?
> > >
> > > Could you please clarify?
> > >
> > > Cheers,
> > > Rajiv
> > >
> > > Sent from Phone....
> > >
> > > On Aug 19, 2011, at 8:10 AM, "Yong Cui" 
> wrote:
> > >
> > >> Hi folks,
> > >>
> > >> We, softwire wg chairs, in agreement with our ADs, are announcing
> > >> an interim meeting in Beijing on September 26 & 27. The date has
> > >> been chosen adjacent to the BBF meeting in Shangai to minimize
> > >> travel and visa issues.
> > >>
> > >> The interim meeting will focus on 'stateless' solutions in general
> > >> and 4rd in particular. Expected outcome includes progress on 4rd
> > >> spec, packet format, where to put IPv4 bits, port indications, DHCP
> > >> option, tunneling vs translation, coexistence with other
> > >> technologies, etc...
> > >>
> > >> ---------------------------------------
> > >> Meeting Location & recommended hotels
> > >> Meeting venue: FIT Building, Tsinghua University, Beijing
> > >> FIT Building is the first left building inside of the East Gate
> > >> of Tsinghua Univeristy
> > >>
> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b
> 982
> > >> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
> > >>
> > >> Recommended hotels:
> > >> 1. Uniscenter (4 stars, 3 min walk)
> > >>
> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
> > >>
> > >> 2. Wenjin Hotel (5 stars, 10 min walk)
> > >> http://www.wenjin.com.cn/
> > >>
> > >> 3. Royal King Hotel (5 stars, 10 min by car)
> > >> http://www.royalkinghotel.com/
> > >>
> > >> ----------------------------------------
> > >> Invitation letter
> > >> If you need an invitation letter, please send the following info
> > >> to Ms. Ziye Li: .
> > >> Surname:
> > >> Given Name:
> > >> Company:
> > >> Address:
> > >> Phone:
> > >> Passport Number:
> > >> Passport Exp. Date:
> > >> Passport Issuing Country:
> > >>
> > >>
> > >>
> > >> -----------------------------------------
> > >>
> > >> Further contact information
> > >> Please contact Ms. Ziye Li if you have any question about
> > >> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
> > >> 
> > >>
> > >>
> > >> -- Alain, Yong
> > >>
> > >>
> > >> _______________________________________________
> > >> Softwires mailing list
> > >> Softwires@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/softwires
> > > _______________________________________________
> > > Softwires mailing list
> > > Softwires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--000e0cd1b1faf79bc504aae8c1d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





2011/8/19 Rajiv Asati (rajiva) <rajiva@cisco.com>

It doesn't, IMO. In fact, I =
beg to say that it is unfair mention
'tunneling vs translating' =
as a blanket statement, since we have known

all along that a sane 4v6 solution would likely involve translating
(44)=
, no matter what.

Moreover, it is reasonable to call out all statele=
ss 4v6 options, not
just a particular solution.


=A0


I agree.


=A0


Congxiao



Cheers,
Rajiv




> -----Original Message-----
> From: Ala=
in Durand [mailto:adurand@juniper.ne=
t]
> Sent: Friday, August 19, 2011 9:44 AM
> To: Rajiv Asat=
i (rajiva)

> Cc: Yong Cui; softwires@ietf.org=
; liziye; iesg-secretary@iet=
f.org;
Ralph Droms
> (rdroms)


> Subject: Re: [Softwires] Softwire Interim Meeting in=
 Beijing
>






> We mentioned 'tunneling vs translating'. Thi=
s should cover it.
>
> Alain.
>
> Sent from my iPad=

>
> On Aug 19, 2011, at 8:16 AM, "Rajiv Asati (rajiva)&qu=
ot; <rajiva@cisco.com>

wrote:
>
> > Yong,
> >
> > Why is dIVI not=
 included In the discussion ?
> >
> > Could you please cl=
arify?
> >
> > Cheers,
> > Rajiv
> >
> > Sent from Phone....
> >
> > On Aug 19, 2011, at=
 8:10 AM, "Yong Cui" <cuiyong@tsinghua.edu.cn>
wrote:
> >
> >> =
Hi folks,

> >>
> >> We, softwire wg chairs, in agreement with ou=
r ADs, are announcing
> >> an interim meeting in Beijing on Sep=
tember 26 & 27. The date has
> >> been chosen adjacent to t=
he BBF meeting in Shangai to minimize

> >> travel and visa issues.
> >>
> >> The=
 interim meeting will focus on 'stateless' solutions in general
=
> >> and 4rd in particular. Expected outcome includes progress on =
4rd

> >> spec, packet format, where to put IPv4 bits, port indications=
, DHCP
> >> option, tunneling vs translation, coexistence with =
other
> >> technologies, etc...
> >>
> >&g=
t; ---------------------------------------

> >> Meeting Location & recommended hotels
> >> Me=
eting venue: FIT Building, Tsinghua University, Beijing
> >> FI=
T Building is the first left building inside of the East Gate
> >&=
gt; of Tsinghua Univeristy

> >>
http://maps.google.com/maps/=
ms?msid=3D202779846620144871057.0004aad8ce367b
982
> >> =
9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798<=
br>
> >>
> >> Recommended hotels:
> >> 1. Unis=
center (4 stars, 3 min walk)
> >>
h=
ttp://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
> >>
> >> 2. Wenjin Hotel (5 stars, 10 min walk)
&g=
t; >> http://=
www.wenjin.com.cn/
> >>
> >> 3. Royal King Hote=
l (5 stars, 10 min by car)

> >> =
http://www.royalkinghotel.com/
> >>
> >> ------=
----------------------------------
> >> Invitation letter
&g=
t; >> If you need an invitation letter, please send the following inf=
o

> >> to Ms. Ziye Li: <liziye@csnet1.cs.tsinghua.edu.cn>.
> >> Surna=
me:
> >> Given Name:
> >> Company:
> >>=
 Address:

> >> Phone:
> >> Passport Number:
> >> Pas=
sport Exp. Date:
> >> Passport Issuing Country:
> >>=
;
> >>
> >>
> >> ----------------------=
-------------------

> >>
> >> Further contact information
> >>=
 Please contact Ms. Ziye Li if you have any question about
> >>=
 Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
> >> <liziye@csnet1.cs.tsinghua.=
edu.cn>

> >>
> >>
> >> -- Alain, Yong
> >=
>
> >>
> >> ____________________________________=
___________
> >> Softwires mailing list
> >> Softwires@ietf.org

> >> https://www.ietf.org/mailman/listinfo/softwires
>=
; > _______________________________________________
> > Softwir=
es mailing list

> > Softwires@ietf.org
&=
gt; > https://www.ietf.org/mailman/listinfo/softwires
________=
_______________________________________

Softwires mailing list
Softwires@i=
etf.org
https://www.ietf.org/mailman/listinfo/softwires





--000e0cd1b1faf79bc504aae8c1d7--

From despres.remi@laposte.net  Sat Aug 20 00:15:14 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB8C21F8B25 for ; Sat, 20 Aug 2011 00:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itA-ncg8i0fN for ; Sat, 20 Aug 2011 00:15:11 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id C223921F8B20 for ; Sat, 20 Aug 2011 00:15:09 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id 3EA727006A25; Sat, 20 Aug 2011 09:16:06 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id 9F067700699A; Sat, 20 Aug 2011 09:15:59 +0200 (CEST)
X-SFR-UUID: 20110820071559651.9F067700699A@msfrf2314.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4E4F34E1.3040305@gmail.com>
Date: Sat, 20 Aug 2011 09:15:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net>
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 07:15:14 -0000

Le 20 ao=FBt 2011 =E0 06:15, Brian E Carpenter a =E9crit :

> Ahah, you seem to assume that A+P will solve the ISP's shortage
> of IPv4 addresses. That may be true for a year or three, but
> after that they will discover that they have to CGN their A+P
> customers, and then you have NAT444 after all, IMHO.

Two points:
- There is no claim AFAIK that the stateless solution fits all =
situations. There is only a claim that some will use it alone if they =
can, because of its simplicity, that some will combine it with dynamic =
mechanisms, and that some may prefer dynamic mechanisms alone.
- As IPv6-enablement is generalized, less and less traffic will be in =
IPv4. Thus, each IPv4 address will become sharable among more and more =
customers.

Is this acceptable?

Regards,
RD



>=20
> Regards
>   Brian
>=20
> On 2011-08-20 11:41, Nejc =8Akoberne wrote:
>>>> It will not, because I don't have a legacy SOHO LAN. If I have =
legacy
>>>> SOHO LAN, I can use (optional) NAT44.
>>> Exactly, resulting in NAT444 . But if I'm forced to use NAT444
>>> via a 4 in 6 tunnel anyway, A+P is pointless.
>>=20
>> I don't think you understood what I was saying. There is no need for =
NAT444.=20
>>=20
>> Let me explain again. The provider has an A+P solution in place. They =
will,
>> by default, provide me with their CPE, which supports A+P and also =
does
>> NAPT44 for my legacy SOHO LAN. In this case, I just plug my computers =
and
>> everything will work like today, just with not-so-many ports.
>>=20
>> However, there are at least two more possible scenarios I can =
imagine:
>>=20
>> 1.) I don't want the provider's CPE since I have my home =
gateway-server,=20
>> which supports A+P and is connected directly to the ISP. This server =
will=20
>> have a public IPv4 address configured and if I need, it /can/ then do=20=

>> NAPT44 (instead of the CPE) for the rest of my legacy LAN.
>>=20
>> 2.) I don't want the provider's CPE since my computers actually =
support
>> A+P mechanism of the provider. I have IPv6-only network in my LAN and
>> IPv4 addressing is brought directly to hosts via A+P mechanism. So it
>> is like "extending" the access network to my home. This scenario is =
also
>> shown on page 16, Figure 6 in draft-ymbk-aplusp-10.
>>=20
>> Nejc
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires



From despres.remi@laposte.net  Sat Aug 20 00:19:08 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2547921F8B27 for ; Sat, 20 Aug 2011 00:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj9c5eXvq0kc for ; Sat, 20 Aug 2011 00:19:07 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1121F8B25 for ; Sat, 20 Aug 2011 00:19:07 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id E43627006A67; Sat, 20 Aug 2011 09:20:05 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id AF95F700210D; Sat, 20 Aug 2011 09:20:05 +0200 (CEST)
X-SFR-UUID: 20110820072005719.AF95F700210D@msfrf2314.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-41-510156293
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Sat, 20 Aug 2011 09:20:05 +0200
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <4E4EF9FC.8020407@skoberne.net> 
To: Mark Townsley 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 07:19:08 -0000

--Apple-Mail-41-510156293
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


Le 20 ao=FBt 2011 =E0 03:55, Mark Townsley a =E9crit :

>=20
> On Aug 19, 2011, at 8:04 PM, Nejc =8Akoberne wrote:
>=20
>>> Because of what RFC6333 says, suggesting NOW that solutions that =
don't need NATs are variants of DS-lite is a sure way to confuse people.
>=20
> Then we're already confused:
>=20
> http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03

Could you explain more which confusion you are referring to?

RD





--Apple-Mail-41-510156293
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



On Aug 19, =
2011, at 8:04 PM, Nejc =8Akoberne wrote:

Because of what RFC6333 =
says, suggesting NOW that solutions that don't need NATs are variants of =
DS-lite is a sure way to confuse =
people.

Then =
we're already confused:


Could you explain more =
which confusion you are referring =
to?

RD



=

--Apple-Mail-41-510156293--


From washam.fan@gmail.com  Sat Aug 20 01:43:26 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716BC21F8634 for ; Sat, 20 Aug 2011 01:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.489
X-Spam-Level: 
X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeummxOQQkpP for ; Sat, 20 Aug 2011 01:43:26 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B906321F8772 for ; Sat, 20 Aug 2011 01:43:25 -0700 (PDT)
Received: by wyg8 with SMTP id 8so3019201wyg.31 for ; Sat, 20 Aug 2011 01:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hFMsX4P0eclDzeZ3xvKRMVDO8EjrxXi1f5oAb89F+o0=; b=PoLTNXcEDQNWZukPx9y9Gsy0ca4BhO/ZCx2ISU0ckXW7ze9GeQhlEHAnfBWJNWSIgJ IXmZYwpCebOEZf0D10JdaBzJLCB35+cgO4RgiWw0o70GPn16Kw+SWQ9vKFWYlhdKgBeG 88q91GHmBFvwGVbj/sBaxvjhs9nhV4cn2f3ZA=
MIME-Version: 1.0
Received: by 10.216.231.210 with SMTP id l60mr319794weq.63.1313829864177; Sat, 20 Aug 2011 01:44:24 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Sat, 20 Aug 2011 01:44:24 -0700 (PDT)
Date: Sat, 20 Aug 2011 16:44:24 +0800
Message-ID: 
From: Washam Fan 
To: Softwires 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Softwires] Comments on draft-despres-softwire-4rd-addmapping-00
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 08:43:26 -0000

Hi,

I support the seperation of address mapping from tunneled or
translated 4rd mechanisms. I have some comments as below.
1. Is there any reason you changed 4rd BR to 4rd AFTR?
2. Is 4rd IID for differentiate native ipv6 packets and translated
ipv6 packets? In other words, tunneled 4rd don't need that.
3. For the ICMPv4 containing the copy of error packets, i think
BR/AFTR or CPE can do forwarding based on the copy of error packets
unless the copy didn't cover the complete TCP/UDP header. For ICMP
echo request, you should say the ID field should be within the port
set range. All these topics are in section 5.1.
4. why omit ipv6 suffix in figure 1?
5.don't get why you pad 0 to ipv6 suffix in figure 2?
6. in the paragraphy just below figure 2, shoud you replace 64 with X
in the L=min(14, 64 ...? BTW, it seems to me, the PSID to port sets
mapping is different from draft-murakami-softwire-4rd-00.
7. in example a in section 6, how come a mapping rule responding to 2
cpe ipv6 prefix length? cpe will get confused when it did forwarding.

Thanks,
washam

From mark@townsley.net  Sat Aug 20 02:46:00 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63621F8B0E for ; Sat, 20 Aug 2011 02:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.392
X-Spam-Level: 
X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1OwzsMx1PAN for ; Sat, 20 Aug 2011 02:45:59 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C77D21F889A for ; Sat, 20 Aug 2011 02:45:59 -0700 (PDT)
Received: by vws12 with SMTP id 12so3735164vws.31 for ; Sat, 20 Aug 2011 02:46:58 -0700 (PDT)
Received: by 10.52.67.65 with SMTP id l1mr274187vdt.189.1313833617854; Sat, 20 Aug 2011 02:46:57 -0700 (PDT)
Received: from 72-254-144-97.client.stsn.net (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id w2sm1095453vdv.34.2011.08.20.02.46.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Aug 2011 02:46:57 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-114-518966202
From: Mark Townsley 
In-Reply-To: 
Date: Sat, 20 Aug 2011 05:46:55 -0400
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <4E4EF9FC.8020407@skoberne.net>  
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 09:46:00 -0000

--Apple-Mail-114-518966202
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Aug 20, 2011, at 3:20 AM, R=E9mi Despr=E9s wrote:

>=20
> Le 20 ao=FBt 2011 =E0 03:55, Mark Townsley a =E9crit :
>=20
>>=20
>> On Aug 19, 2011, at 8:04 PM, Nejc =8Akoberne wrote:
>>=20
>>>> Because of what RFC6333 says, suggesting NOW that solutions that =
don't need NATs are variants of DS-lite is a sure way to confuse people.
>>=20
>> Then we're already confused:
>>=20
>> http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
>=20
> Could you explain more which confusion you are referring to?

Nejc suggested that DS-Lite without NATs (which I assumed meant without =
a CGN NAT, aka AFTR) would be confusing at this stage.

The title of the referenced document is "Procedure to bypass DS-Lite =
AFTR"

- Mark



>=20
> RD
>=20
>=20
>=20
>=20


--Apple-Mail-114-518966202
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



Le 20 ao=FBt=
 2011 =E0 03:55, Mark Townsley a =E9crit :


On Aug 19, 2011, =
at 8:04 PM, Nejc =8Akoberne wrote:

Because of what RFC6333 =
says, suggesting NOW that solutions that don't need NATs are variants of =
DS-lite is a sure way to confuse =
people.

Then =
we're already confused:


Could you explain more =
which confusion you are referring =
to?

Nejc suggested =
that DS-Lite without NATs (which I assumed meant without a CGN NAT, aka =
AFTR) would be confusing at this stage.

The =
title of the referenced document is "Procedure to bypass DS-Lite =
AFTR"

- =
Mark



 4. why omit ipv6 suffix in figure 1?

The idea is that the suffix is _after_ the CPE IPv6 suffix, and =
therefore doesn't need to appear in Fig 1.=20


> 5.don't get why you pad 0 to ipv6 suffix in figure 2?

Cases are possible where the previous fields don't reach 64 bits.
An example could be added in a later version. =20

> 6. in the paragraphy just below figure 2, shoud you replace 64 with X
> in the L=3Dmin(14, 64 ...? BTW, it seems to me, the PSID to port sets
> mapping is different from draft-murakami-softwire-4rd-00.

Yes.
This is a consequence of the additional objective of UPnP friendliness.
Xiaohong could probably tell more if you need it.


> 7. in example a in section 6, how come a mapping rule responding to 2
> cpe ipv6 prefix length? cpe will get confused when it did forwarding.

CPE prefix lengths may be different. (It is the Domain prefix length =
that is given in the rule.)
This is key to be able to assign port sets of different sizes (including =
64K) to different customers (at least when the CPE-cascade option isn't =
necessary).


Regards,
RD


From despres.remi@laposte.net  Sat Aug 20 06:03:09 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3521F8754 for ; Sat, 20 Aug 2011 06:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wPgJuMNx0f7 for ; Sat, 20 Aug 2011 06:03:09 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0FD21F871C for ; Sat, 20 Aug 2011 06:03:07 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6FF30940130; Sat, 20 Aug 2011 15:04:01 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-530791270
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Sat, 20 Aug 2011 15:04:00 +0200
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <4E4EF9FC.8020407@skoberne.net>   
To: Mark Townsley 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 13:03:10 -0000

--Apple-Mail-1-530791270
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 20 ao=FBt 2011 =E0 11:46, Mark Townsley a =E9crit :

> On Aug 20, 2011, at 3:20 AM, R=E9mi Despr=E9s wrote:

>> Le 20 ao=FBt 2011 =E0 03:55, Mark Townsley a =E9crit :
...
>>>  we're already confused:
>>>=20
>>> http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
>>=20
>> Could you explain more which confusion you are referring to?
>=20
> Nejc suggested that DS-Lite without NATs (which I assumed meant =
without a CGN NAT, aka AFTR) would be confusing at this stage.
>=20

> The title of the referenced document is "Procedure to bypass DS-Lite =
AFTR"

Indeed, but so what?
(I don't see which confusion would result from using "4rd address =
mapping" to designate the stateless mapping called that way so far.)

RD



--Apple-Mail-1-530791270
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


On Aug 20, 2011, at 3:20 AM, R=E9mi =
Despr=E9s wrote:

Le 20 ao=FBt =
2011 =E0 03:55, Mark Townsley a =E9crit =
:
...

Could you explain more =
which confusion you are referring =
to?

Nejc suggested =
that DS-Lite without NATs (which I assumed meant without a CGN NAT, aka =
AFTR) would be confusing at this =
stage.


The title of =
the referenced document is "Procedure to bypass DS-Lite =
AFTR"

Indeed, but so =
what?
(I don't see which confusion would result from using =
"4rd address mapping" to designate the stateless mapping called that way =
so =
far.)

RD


=

--Apple-Mail-1-530791270--

From cuiyong@tsinghua.edu.cn  Sat Aug 20 07:20:12 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8821F886D for ; Sat, 20 Aug 2011 07:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level: 
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqSG+nDdGKao for ; Sat, 20 Aug 2011 07:20:12 -0700 (PDT)
Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F16321F8828 for ; Sat, 20 Aug 2011 07:20:12 -0700 (PDT)
Received: from [219.143.155.84] (helo=[192.168.0.155]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1QumQ6-0002y7-G8; Sat, 20 Aug 2011 22:21:06 +0800
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Sat, 20 Aug 2011 22:21:02 +0800
From: Yong Cui 
To: 
Message-ID: 
Thread-Topic: New working group documents
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Yong Cui 
Subject: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 14:20:12 -0000

Hi folks,

Following our rough concensus during Quebec City meeting and
according to our charter/milestones, the chairs would like to
ask the mailing list for the confirmation to adopt the following
drafts:

1. Deployment Considerations for Dual-Stack Lite
http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/


2. Public IPv4 over Access IPv6 Network
http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/

3. Softwire Mesh Multicast
http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/

4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/

5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
vation/

Please send your comments by 10am EDT on Aug 27. If you object to
adoption, please also give the detailed reasons.



--Alain & Yong



From despres.remi@laposte.net  Sat Aug 20 08:00:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3223F21F8785 for ; Sat, 20 Aug 2011 08:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.225
X-Spam-Level: 
X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZnESKV2IhhB for ; Sat, 20 Aug 2011 08:00:53 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id AC2ED21F8782 for ; Sat, 20 Aug 2011 08:00:51 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id A0BF9940106; Sat, 20 Aug 2011 17:01:46 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Sat, 20 Aug 2011 17:01:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Yong Cui 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 15:00:54 -0000

Le 20 ao=FBt 2011 =E0 16:21, Yong Cui a =E9crit :

> Hi folks,
>=20
> Following our rough concensus during Quebec City meeting and
> according to our charter/milestones, the chairs would like to
> ask the mailing list for the confirmation to adopt the following
> drafts:
...

> 5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
> =
http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-mot=
i
> vation/

Full support.
+ full agreement on stateless-solutions being the focus oft the interim =
meeting.

Thanks,
RD



From cb.list6@gmail.com  Sat Aug 20 15:22:31 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A2221F854E for ; Sat, 20 Aug 2011 15:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level: 
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeZq4FafQbFp for ; Sat, 20 Aug 2011 15:22:31 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06D1E21F8540 for ; Sat, 20 Aug 2011 15:22:30 -0700 (PDT)
Received: by wyg8 with SMTP id 8so3290542wyg.31 for ; Sat, 20 Aug 2011 15:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IUOAhSXjRRLH4rCHJEj4FjPXKbX9qcEZLI6V2UWzMYE=; b=lQQbdiW/x2rFPZ9kVtbdzXJzIUbJktax8CtAFAZ8u5kwdZ7qudCT5mgMY8kwp7gjrG lTIMKM+Lkq0C9jo/mijZOWZN8FTta7PEZtMYLXN6hwDwaku7wI8zqqFavriJoXD470/p eW5/AKIkT3GiVc9VZi+7QQV/hkM+wY+xsr43I=
MIME-Version: 1.0
Received: by 10.216.46.75 with SMTP id q53mr649951web.65.1313879010970; Sat, 20 Aug 2011 15:23:30 -0700 (PDT)
Received: by 10.216.155.199 with HTTP; Sat, 20 Aug 2011 15:23:30 -0700 (PDT)
In-Reply-To: <4E4F34E1.3040305@gmail.com>
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com>
Date: Sat, 20 Aug 2011 15:23:30 -0700
Message-ID: 
From: Cameron Byrne 
To: Brian E Carpenter 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 22:22:31 -0000

2011/8/19 Brian E Carpenter :
> Ahah, you seem to assume that A+P will solve the ISP's shortage
> of IPv4 addresses. That may be true for a year or three, but
> after that they will discover that they have to CGN their A+P
> customers, and then you have NAT444 after all, IMHO.
>

I share this concern.  While i do agree that IPv6 usage will relieve
some pressure.  IMHO, i believe that static over-subscription ratios
required by A+P will not meaningfully keep pace with the rapid growth
in the number of internet nodes.

Cameron

From brian.e.carpenter@gmail.com  Sat Aug 20 15:53:16 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A73A21F85B9 for ; Sat, 20 Aug 2011 15:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.439
X-Spam-Level: 
X-Spam-Status: No, score=-103.439 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGjtO1lJ2wYK for ; Sat, 20 Aug 2011 15:53:16 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF0A221F85AC for ; Sat, 20 Aug 2011 15:53:15 -0700 (PDT)
Received: by fxe6 with SMTP id 6so2867938fxe.31 for ; Sat, 20 Aug 2011 15:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qrmyC8APT/d38aVprGwQQTas++PcJIXBaHcDz8+8DjU=; b=mPdSPFwJWl/xGQcHEYjbBo3WOZPpH6LShzHJdNdLVZ0mUJv5vaIMpY8dYGaw7Y7sbD xEsHft4UonSB6VGkC6P7kuyyprV2laqdkFmnbJeD/P0jx+xcKquahhJ5r/Pmg/Bkb7Ak ly/NmwMXN69L8cGWAwxRbw8Z+LJxtN5yOiEJI=
Received: by 10.223.18.214 with SMTP id x22mr1257773faa.73.1313880855871; Sat, 20 Aug 2011 15:54:15 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id b14sm3763688fab.19.2011.08.20.15.54.11 (version=SSLv3 cipher=OTHER); Sat, 20 Aug 2011 15:54:14 -0700 (PDT)
Message-ID: <4E503B08.9030800@gmail.com>
Date: Sun, 21 Aug 2011 10:54:00 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net>
In-Reply-To: <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2011 22:53:16 -0000

On 2011-08-20 19:15, R=C3=A9mi Despr=C3=A9s wrote:
> Le 20 ao=C3=BBt 2011 =C3=A0 06:15, Brian E Carpenter a =C3=A9crit :
>=20
>> Ahah, you seem to assume that A+P will solve the ISP's shortage
>> of IPv4 addresses. That may be true for a year or three, but
>> after that they will discover that they have to CGN their A+P
>> customers, and then you have NAT444 after all, IMHO.
>=20
> Two points:
> - There is no claim AFAIK that the stateless solution fits all situatio=
ns. There is only a claim that some will use it alone if they can, becaus=
e of its simplicity, that some will combine it with dynamic mechanisms, a=
nd that some may prefer dynamic mechanisms alone.

Sure. The question is really whether its "market share" would be
enough to justify the effort.

> - As IPv6-enablement is generalized, less and less traffic will be in I=
Pv4. Thus, each IPv4 address will become sharable among more and more cus=
tomers.

If an average IPv4 user is consuming 200 ports (or whatever
value you prefer to assume) with their favourite p2p app, that
is what sets the number of IPv4 users per shared address. It's
the number of simultaneous ports, not the amount of traffic,
that counts.

   Brian


From Tina.Tsou.Zouting@huawei.com  Sat Aug 20 19:07:57 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AFC21F8742 for ; Sat, 20 Aug 2011 19:07:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.948
X-Spam-Level: 
X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.351,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljRQcGVjZ1vI for ; Sat, 20 Aug 2011 19:07:56 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F46321F871C for ; Sat, 20 Aug 2011 19:07:56 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ9001AX9YUB7@szxga03-in.huawei.com> for softwires@ietf.org; Sun, 21 Aug 2011 10:08:54 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ900CQ99YULS@szxga03-in.huawei.com> for softwires@ietf.org; Sun, 21 Aug 2011 10:08:54 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADG88442; Sun, 21 Aug 2011 10:08:49 +0800 (CST)
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 21 Aug 2011 10:08:40 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Sun, 21 Aug 2011 10:08:48 +0800
Date: Sun, 21 Aug 2011 02:08:47 +0000
From: Tina TSOU 
In-reply-to: <4E503B08.9030800@gmail.com>
X-Originating-IP: [10.212.246.45]
To: Brian E Carpenter , =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] draft-murakami-softwire-4v6-translation
Thread-index: AQHMXMhg06jxFzt5Jk+ezVwq/3/A35UiUx4AgABnRYCAAAT4AIABbCKAgAAf2wCAAAfigIAATK+AgAAyb4CAAQYUAIAAu3lg
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net> <4E503B08.9030800@gmail.com>
Cc: "softwires@ietf.org" , "draft-murakami-softwire-4v6-translation@tools.ietf.org" 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 02:07:57 -0000

QnJpYW4sIFJlbWksDQpJbiBsaW5lLg0KDQoNCkJlc3QgUmVnYXJkcywNClRpbmEgVFNPVQ0KaHR0
cDovL3RpbmF0c291LndlZWJseS5jb20vY29udGFjdC5odG1sDQoNCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz
b2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVy
DQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDIwLCAyMDExIDM6NTQgUE0NClRvOiBSw6ltaSBEZXNw
csOpcw0KQ2M6IHNvZnR3aXJlc0BpZXRmLm9yZzsgZHJhZnQtbXVyYWthbWktc29mdHdpcmUtNHY2
LXRyYW5zbGF0aW9uQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gZHJh
ZnQtbXVyYWthbWktc29mdHdpcmUtNHY2LXRyYW5zbGF0aW9uDQoNCk9uIDIwMTEtMDgtMjAgMTk6
MTUsIFLDqW1pIERlc3Byw6lzIHdyb3RlOg0KPiBMZSAyMCBhb8O7dCAyMDExIMOgIDA2OjE1LCBC
cmlhbiBFIENhcnBlbnRlciBhIMOpY3JpdCA6DQo+IA0KPj4gQWhhaCwgeW91IHNlZW0gdG8gYXNz
dW1lIHRoYXQgQStQIHdpbGwgc29sdmUgdGhlIElTUCdzIHNob3J0YWdlDQo+PiBvZiBJUHY0IGFk
ZHJlc3Nlcy4gVGhhdCBtYXkgYmUgdHJ1ZSBmb3IgYSB5ZWFyIG9yIHRocmVlLCBidXQNCj4+IGFm
dGVyIHRoYXQgdGhleSB3aWxsIGRpc2NvdmVyIHRoYXQgdGhleSBoYXZlIHRvIENHTiB0aGVpciBB
K1ANCj4+IGN1c3RvbWVycywgYW5kIHRoZW4geW91IGhhdmUgTkFUNDQ0IGFmdGVyIGFsbCwgSU1I
Ty4NCj4gDQo+IFR3byBwb2ludHM6DQo+IC0gVGhlcmUgaXMgbm8gY2xhaW0gQUZBSUsgdGhhdCB0
aGUgc3RhdGVsZXNzIHNvbHV0aW9uIGZpdHMgYWxsIHNpdHVhdGlvbnMuIFRoZXJlIGlzIG9ubHkg
YSBjbGFpbSB0aGF0IHNvbWUgd2lsbCB1c2UgaXQgYWxvbmUgaWYgdGhleSBjYW4sIGJlY2F1c2Ug
b2YgaXRzIHNpbXBsaWNpdHksIHRoYXQgc29tZSB3aWxsIGNvbWJpbmUgaXQgd2l0aCBkeW5hbWlj
IG1lY2hhbmlzbXMsIGFuZCB0aGF0IHNvbWUgbWF5IHByZWZlciBkeW5hbWljIG1lY2hhbmlzbXMg
YWxvbmUuDQoNClN1cmUuIFRoZSBxdWVzdGlvbiBpcyByZWFsbHkgd2hldGhlciBpdHMgIm1hcmtl
dCBzaGFyZSIgd291bGQgYmUNCmVub3VnaCB0byBqdXN0aWZ5IHRoZSBlZmZvcnQuDQoNCj4gLSBB
cyBJUHY2LWVuYWJsZW1lbnQgaXMgZ2VuZXJhbGl6ZWQsIGxlc3MgYW5kIGxlc3MgdHJhZmZpYyB3
aWxsIGJlIGluIElQdjQuIFRodXMsIGVhY2ggSVB2NCBhZGRyZXNzIHdpbGwgYmVjb21lIHNoYXJh
YmxlIGFtb25nIG1vcmUgYW5kIG1vcmUgY3VzdG9tZXJzLg0KDQpJZiBhbiBhdmVyYWdlIElQdjQg
dXNlciBpcyBjb25zdW1pbmcgMjAwIHBvcnRzIChvciB3aGF0ZXZlcg0KdmFsdWUgeW91IHByZWZl
ciB0byBhc3N1bWUpIHdpdGggdGhlaXIgZmF2b3VyaXRlIHAycCBhcHAsIHRoYXQNCmlzIHdoYXQg
c2V0cyB0aGUgbnVtYmVyIG9mIElQdjQgdXNlcnMgcGVyIHNoYXJlZCBhZGRyZXNzLiBJdCdzDQp0
aGUgbnVtYmVyIG9mIHNpbXVsdGFuZW91cyBwb3J0cywgbm90IHRoZSBhbW91bnQgb2YgdHJhZmZp
YywNCnRoYXQgY291bnRzLg0KW1RpbmE6DQpUaGVzZSBkcmFmdHMgYXR0ZW1wdCB0byBzb2x2ZSB0
aGlzIGlzc3VlLg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdHNvdS1w
Y3AtbmF0Y29vcmQvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aG91
LXNvZnR3aXJlLWI0LW5hdC8NClRoZSBydW5uaW5nIGNvZGUgd2FzIGRlbW9lZCBpbiBJRVRGLTgx
Ll0NCg0KDQogICBCcmlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0K

From despres.remi@laposte.net  Sat Aug 20 22:42:10 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7665221F87FC for ; Sat, 20 Aug 2011 22:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level: 
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkSa-EIuvD0p for ; Sat, 20 Aug 2011 22:42:10 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id CC12321F87FA for ; Sat, 20 Aug 2011 22:42:04 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5DDFA940024; Sun, 21 Aug 2011 07:42:59 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4E503B08.9030800@gmail.com>
Date: Sun, 21 Aug 2011 07:42:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CFF835A-C8AF-40CC-9B4F-37D1C460CDB9@laposte.net>
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net> <4E503B08.9030800@gmail.com>
To: Softwires-wg 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Softwires] Can stateless address sharing be sufficient in some use cases
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 05:42:10 -0000

Le 21 ao=FBt 2011 =E0 00:54, Brian E Carpenter a =E9crit :

> On 2011-08-20 19:15, R=E9mi Despr=E9s wrote:
...
>> - There is no claim AFAIK that the stateless solution fits all =
situations. There is only a claim that some will use it alone if they =
can, because of its simplicity, that some will combine it with dynamic =
mechanisms, and that some may prefer dynamic mechanisms alone.
>=20
> Sure. The question is really whether its "market share" would be
> enough to justify the effort.
>=20
>> - As IPv6-enablement is generalized, less and less traffic will be in =
IPv4. Thus, each IPv4 address will become sharable among more and more =
customers.
>=20
> If an average IPv4 user is consuming 200 ports (or whatever
> value you prefer to assume) with their favourite p2p app, that
> is what sets the number of IPv4 users per shared address.

It _contributes_ to set the number, yes, but with due consideration of =
the following:
- Users behind common CPE's typically don't have their peak consumption =
at the same time.
- More and more of these applications will be possible in IPv6 (thus =
consuming no IPv4 port at all).

(Extending IPv6 availability as widely as possible, including behind =
legacy CPE's, is therefore key. That's exactly why we together submitted =
draft-despres-6a44 ;-))
=20
> It's
> the number of simultaneous ports, not the amount of traffic,
> that counts.

Sure, that was of course well understood.

RD


>=20
>   Brian
>=20


From despres.remi@laposte.net  Sat Aug 20 22:49:39 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F5521F8563 for ; Sat, 20 Aug 2011 22:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level: 
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xglk2WxrjZBM for ; Sat, 20 Aug 2011 22:49:38 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id EBE7A21F8560 for ; Sat, 20 Aug 2011 22:49:36 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 19B34940099; Sun, 21 Aug 2011 07:50:32 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-3-591182862
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <9CED3349-22B8-49EC-B72C-77CD52D52427@townsley.net>
Date: Sun, 21 Aug 2011 07:50:31 +0200
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <9CED3349-22B8-49EC-B72C-77CD52D52427@townsley.net>
To: Mark Townsley 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 05:49:40 -0000

--Apple-Mail-3-591182862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Mark,

Interesting definition of "retronym".

It remains, though, that an analogue clock, the example given in the =
given reference) is a clock variant (a device for measuring time).
A 4rd-encapsulation solution is in no way a DS-lite variant ("built on a =
tunnel to reach a CGN").

It would be nice, therefore, if the idea of using "stateless DS-lite" as =
a valuable substitute to "4rd" would no longer need to be discussed.

Thanks,
RD




Le 20 ao=FBt 2011 =E0 04:05, Mark Townsley a =E9crit :

> Aug 19, 2011, at 1:08 PM, R=E9mi Despr=E9s wrote:
>>=20
>> Le 19 ao=FBt 2011 =E0 17:11, Mark Townsley a =E9crit :
...
>>>=20
>>> Let me fill you in on some history.
>>>=20
>>> The term "Dual Stack Lite" came into being during a discussion at a =
cafe between Alain Durand and I. It was June 2008, and Alain was in =
Paris for the ICANN meeting while still working for Comcast. We had been =
discussing the various pros and cons of tunneling vs. dual-translation =
for a while. Alain was emphasizing that what was of most importance to =
him as an ISP, was that he not be burdened with provisioning IPv4 within =
the ISP network itself. However, in all cases the service to the =
subscriber was intended to be dual-stack. So: "Dual-stack" service but =
"lighter" on the ISP in terms of management and provisioning. Thus the =
term "dual-stack lite" was born.=20
>>=20
>> That's a good clarification.
>>=20
>> But in the mean time, DS-lite got specified in an RFC that won't =
change.
>=20
> But RFC's get updated all the time, as does terminology. Adding an =
adjective to something that is well understood to indicate that it can =
serve the same purpose but in a different way is quite useful during the =
introduction of that technology. Think "Horseless Carriage"=20
>=20
> http://en.wikipedia.org/wiki/Retronym
>=20
> A retronym is a type of neologism that provides a new name for an =
object or concept to differentiate the original form or version of it =
from a more recent form or version.[1] The original name is most often =
augmented with an adjective (rather than being completely displaced) to =
account for later developments of the object or concept itself. Much =
retronymy is driven by advances in technology.
>=20
> - Mark
>=20
>> RFC6333 says:
>> - "Dual-Stack Lite enables a broadband service provider to share IPv4 =
addresses among customers by combining two well-known technologies: IP =
in IP (IPv4-in-IPv6) and Network Address Translation (NAT)."
>> - "the Dual-Stack Lite model is  built on IPv4-in-IPv6 tunnels to =
cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR),"=20
>> - etc.
>>=20
>>> =46rom the beginning the "lite" term was about having less IPv4 in =
the access network for the operator to manage and provision, while still =
providing dual-stack service to the subscriber. 4rd fits that, as does =
RFC 6333. The solution details are just that - details.=20
>>=20
>> The devil is in details.
>>=20
>> Too bad 4rd wasn't invented before DS-lite. It would have better =
deserved the "lite" qualifier, but that's not how things happened.
>>=20
>> Because of what RFC6333 says, suggesting NOW that solutions that =
don't need NATs are variants of DS-lite is a sure way to confuse people.
>>=20
>> I do hope this discussion will now stop: there are so many technical =
"details" that need to reach common understanding, and agreement.=20
>> In any case thank you for the really interesting explanation on =
history.
>>=20
>> Cheers.
>> RD
>>=20
>>=20
>=20


--Apple-Mail-3-591182862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



It remains, though, that an =
analogue clock, the example given in the given reference) is a =
clock variant (a device for measuring time).
A =
4rd-encapsulation solution is in no way a DS-lite variant ("built on a =
tunnel to reach a CGN").

It would be =
nice, therefore, if the idea of using "stateless DS-lite" as a =
valuable substitute to "4rd" would no longer need to be =
discussed.

Thanks,
RD




Le 20 ao=FBt 2011 =E0 =
04:05, Mark Townsley a =E9crit :

Aug 19, 2011, at 1:08 =
PM, R=E9mi Despr=E9s wrote:

Le 19 ao=FBt =
2011 =E0 17:11, Mark Townsley a =E9crit =
:
...

Let me fill you in on some =
history.

The term "Dual =
Stack Lite" came into being during a discussion at a cafe between Alain =
Durand and I. It was June 2008, and Alain was in Paris for the ICANN =
meeting while still working for Comcast. We had been discussing the =
various pros and cons of tunneling vs. dual-translation for a while. =
Alain was emphasizing that what was of most importance to him as an ISP, =
was that he not be burdened with provisioning IPv4 within the ISP =
network itself. However, in all cases the service to the subscriber was =
intended to be dual-stack. So: "Dual-stack" service but "lighter" on the =
ISP in terms of management and provisioning. Thus the term "dual-stack =
lite" was born. 

That's a good =
clarification.

But in the mean time, DS-lite got specified in an =
RFC that won't change.

But =
RFC's get updated all the time, as does terminology. Adding an adjective =
to something that is well understood to indicate that it can serve the =
same purpose but in a different way is quite useful during the =
introduction of that technology. Think "Horseless =
Carriage" 


neologism that provides a new name for an =
object or concept to differentiate the original form or version of it =
from a more recent form or version.
RFC6333 says:
- "Dual-Stack Lite enables a =
broadband service provider to share IPv4 addresses among customers by =
combining two well-known technologies: IP in IP (IPv4-in-IPv6) and =
Network Address Translation (NAT)."
- "the Dual-Stack Lite model is =
 built on IPv4-in-IPv6 tunnels to cross the network to reach a =
carrier-grade IPv4-IPv4 NAT (the AFTR)," 
- etc.

=46rom the beginning the "lite" term was about having less =
IPv4 in the access network for the operator to manage and provision, =
while still providing dual-stack service to the subscriber. 4rd fits =
that, as does RFC 6333. The solution details are just that - details. =


The devil is in details.

Too bad 4rd wasn't =
invented before DS-lite. It would have better deserved the "lite" =
qualifier, but that's not how things happened.

Because of what =
RFC6333 says, suggesting NOW that solutions that don't need NATs are =
variants of DS-lite is a sure way to confuse people.

I do hope =
this discussion will now stop: there are so many technical "details" =
that need to reach common understanding, and agreement. 
In any case =
thank you for the really interesting explanation on =
history.

Cheers.
RD




=

--Apple-Mail-3-591182862--

From washam.fan@gmail.com  Sat Aug 20 23:00:56 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0B921F854C for ; Sat, 20 Aug 2011 23:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.345
X-Spam-Level: 
X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV1Enxxvfc2j for ; Sat, 20 Aug 2011 23:00:55 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78DB821F8715 for ; Sat, 20 Aug 2011 23:00:55 -0700 (PDT)
Received: by wwf5 with SMTP id 5so2809775wwf.13 for ; Sat, 20 Aug 2011 23:01:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=99gMf2y5Z8jBSyZ8aL56Uf+xrCyo3B8xWaz2MSd9y1s=; b=kPKRLJf4mFGA6LTaDIwXVXWk+q+Bb8aNxZkEXjEbJQ341eacZpHYZ39uFb8N3zP6Ln 7rXYo5Jh4T5gWe10DpiU0jyB9perVrYmQle1CTCcldTXKYCUqZBH/Ur2ipYJLELOnoUu osvDKrb+Xh+6+eeBVuSuwxB4fZynvdrTtDXqs=
MIME-Version: 1.0
Received: by 10.216.231.210 with SMTP id l60mr616399weq.63.1313906511693; Sat, 20 Aug 2011 23:01:51 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Sat, 20 Aug 2011 23:01:51 -0700 (PDT)
In-Reply-To: 
References:  
Date: Sun, 21 Aug 2011 14:01:51 +0800
Message-ID: 
From: Washam Fan 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Softwires 
Subject: Re: [Softwires] Comments on draft-despres-softwire-4rd-addmapping-00
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 06:00:56 -0000

Hi Remi,

Please see inline.

>> 7. in example a in section 6, how come a mapping rule responding to 2
>> cpe ipv6 prefix length? cpe will get confused when it did forwarding.
>
> CPE prefix lengths may be different. (It is the Domain prefix length that is given in the rule.)
> This is key to be able to assign port sets of different sizes (including 64K) to different customers (at least when the CPE-cascade option isn't necessary).

Yes. But my concern was, for example, a CPE has the below mapping
rule, cited from the draft:
   +--------------------+--------------------+-------------------------+
   | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) |
   +--------------------+--------------------+-------------------------+
   |     192.32../12    |    2001:db0::/28   | 2001:db0:aaaa:aaaa::/64 |
   +--------------------+--------------------+-------------------------+

when the CPE forwards a IPv4 packet whose destincation address is
within 192.32../12, how the CPE know it will use /48 CE prefix or /52
CE prefix? Or the mapping rule implies the CPE should use the same CE
preifx length as its own delegated prefix?

THanks,
washam

From despres.remi@laposte.net  Sun Aug 21 01:01:20 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63F21F8A23 for ; Sun, 21 Aug 2011 01:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.24
X-Spam-Level: 
X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie7NsEcQsxqz for ; Sun, 21 Aug 2011 01:01:20 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C868521F899F for ; Sun, 21 Aug 2011 01:01:18 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id EEAA19400B5; Sun, 21 Aug 2011 10:02:13 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Sun, 21 Aug 2011 10:02:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: Washam Fan 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires 
Subject: Re: [Softwires] Comments on draft-despres-softwire-4rd-addmapping-00
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 08:01:20 -0000

Hi Washam,

Please see below.

Le 21 ao=FBt 2011 =E0 08:01, Washam Fan a =E9crit :

> Hi Remi,
>=20
> Please see inline.
>=20
>>> 7. in example a in section 6, how come a mapping rule responding to =
2
>>> cpe ipv6 prefix length? cpe will get confused when it did =
forwarding.
>>=20
>> CPE prefix lengths may be different. (It is the Domain prefix length =
that is given in the rule.)
>> This is key to be able to assign port sets of different sizes =
(including 64K) to different customers (at least when the CPE-cascade =
option isn't necessary).
>=20
> Yes. But my concern was, for example, a CPE has the below mapping
> rule, cited from the draft:
>   =
+--------------------+--------------------+-------------------------+
>   | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) =
|
>   =
+--------------------+--------------------+-------------------------+
>   |     192.32../12    |    2001:db0::/28   | 2001:db0:aaaa:aaaa::/64 =
|
>   =
+--------------------+--------------------+-------------------------+
>=20
> when the CPE forwards a IPv4 packet whose destincation address is
> within 192.32../12, how the CPE know it will use /48 CE prefix or /52
> CE prefix? Or the mapping rule implies the CPE should use the same CE
> preifx length as its own delegated prefix?

Ah, I think I better understand your question now.

The SRC CPE _doesn't need to know_ the length of the DST CPE IPv6 prefix =
length.
If this DST length is 48, the DST IPv6 /64 can contain port-derived bits =
that have no effect on the route toward this CPE. (It is reachable at =
its /48, irrespective of bits beyond the /48).=20
The DST CPE simply makes NO USE of these extra bits (except possibly to =
check  their consistency with the L4 payload).

Does this answer you question?

In any case, I believe that a later version of the draft should contain =
an explanation of that kind, preferably more detailed.
I will work on that.

Thanks for your question.
RD


=20

>=20
> THanks,
> washam


From washam.fan@gmail.com  Sun Aug 21 04:42:23 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAAE21F8A97 for ; Sun, 21 Aug 2011 04:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.343
X-Spam-Level: 
X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qf3jQIyQrl4 for ; Sun, 21 Aug 2011 04:42:23 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33D5D21F8A69 for ; Sun, 21 Aug 2011 04:42:22 -0700 (PDT)
Received: by wwf5 with SMTP id 5so2880549wwf.13 for ; Sun, 21 Aug 2011 04:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g1p53lqPu4QKFiKu9gvvUuK4VgxeLtTZip4hyZfV2o8=; b=Ygj3W6E5fZ+gO0gqaCb9Fay80jsECXVdtILqu3Oem3qpOK4br1NhjzqndbsNJQ8lmm xDHczmGQNQvGA9gGNMYiyWLJg5aZ+3D2i8OO8Um40QTbUZsQiXRqx/3l/PeLoxwoSXTD B8kxCxhumM9IJ+sKN366U4PWt7BPL5ozxGU9s=
MIME-Version: 1.0
Received: by 10.216.37.16 with SMTP id x16mr1030501wea.93.1313927004419; Sun, 21 Aug 2011 04:43:24 -0700 (PDT)
Received: by 10.216.242.205 with HTTP; Sun, 21 Aug 2011 04:43:24 -0700 (PDT)
In-Reply-To: 
References:    
Date: Sun, 21 Aug 2011 19:43:24 +0800
Message-ID: 
From: Washam Fan 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires 
Subject: Re: [Softwires] Comments on draft-despres-softwire-4rd-addmapping-00
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 11:42:24 -0000

Got it. Thanks Remi.
washam

2011/8/21 R=E9mi Despr=E9s :
> Hi Washam,
>
> Please see below.
>
> Le 21 ao=FBt 2011 =E0 08:01, Washam Fan a =E9crit :
>
>> Hi Remi,
>>
>> Please see inline.
>>
>>>> 7. in example a in section 6, how come a mapping rule responding to 2
>>>> cpe ipv6 prefix length? cpe will get confused when it did forwarding.
>>>
>>> CPE prefix lengths may be different. (It is the Domain prefix length th=
at is given in the rule.)
>>> This is key to be able to assign port sets of different sizes (includin=
g 64K) to different customers (at least when the CPE-cascade option isn't n=
ecessary).
>>
>> Yes. But my concern was, for example, a CPE has the below mapping
>> rule, cited from the draft:
>> =A0 +--------------------+--------------------+-------------------------=
+
>> =A0 | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) =
|
>> =A0 +--------------------+--------------------+-------------------------=
+
>> =A0 | =A0 =A0 192.32../12 =A0 =A0| =A0 =A02001:db0::/28 =A0 | 2001:db0:a=
aaa:aaaa::/64 |
>> =A0 +--------------------+--------------------+-------------------------=
+
>>
>> when the CPE forwards a IPv4 packet whose destincation address is
>> within 192.32../12, how the CPE know it will use /48 CE prefix or /52
>> CE prefix? Or the mapping rule implies the CPE should use the same CE
>> preifx length as its own delegated prefix?
>
> Ah, I think I better understand your question now.
>
> The SRC CPE _doesn't need to know_ the length of the DST CPE IPv6 prefix =
length.
> If this DST length is 48, the DST IPv6 /64 can contain port-derived bits =
that have no effect on the route toward this CPE. (It is reachable at its /=
48, irrespective of bits beyond the /48).
> The DST CPE simply makes NO USE of these extra bits (except possibly to c=
heck =A0their consistency with the L4 payload).
>
> Does this answer you question?
>
> In any case, I believe that a later version of the draft should contain a=
n explanation of that kind, preferably more detailed.
> I will work on that.
>
> Thanks for your question.
> RD
>
>
>
>
>>
>> THanks,
>> washam
>
>

From mark@townsley.net  Sun Aug 21 06:36:51 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF5121F8A97 for ; Sun, 21 Aug 2011 06:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsopIwbbc73U for ; Sun, 21 Aug 2011 06:36:50 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8466E21F8AA9 for ; Sun, 21 Aug 2011 06:36:50 -0700 (PDT)
Received: by vxi29 with SMTP id 29so4594365vxi.31 for ; Sun, 21 Aug 2011 06:37:52 -0700 (PDT)
Received: by 10.220.107.17 with SMTP id z17mr384811vco.55.1313933872277; Sun, 21 Aug 2011 06:37:52 -0700 (PDT)
Received: from [192.168.2.105] (99-1-176-134.lightspeed.clmasc.sbcglobal.net [99.1.176.134]) by mx.google.com with ESMTPS id h20sm2591413vce.5.2011.08.21.06.37.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Aug 2011 06:37:50 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-116-619219682
From: Mark Townsley 
In-Reply-To: 
Date: Sun, 21 Aug 2011 09:37:48 -0400
Message-Id: <0279288C-AB21-4CAC-8153-1F64B8A8703D@townsley.net>
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <4E4EF9FC.8020407@skoberne.net>    
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 13:36:51 -0000

--Apple-Mail-116-619219682
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Aug 20, 2011, at 9:04 AM, R=E9mi Despr=E9s wrote:

>=20
> Le 20 ao=FBt 2011 =E0 11:46, Mark Townsley a =E9crit :
>=20
>> On Aug 20, 2011, at 3:20 AM, R=E9mi Despr=E9s wrote:
>=20
>>> Le 20 ao=FBt 2011 =E0 03:55, Mark Townsley a =E9crit :
> ...
>>>>  we're already confused:
>>>>=20
>>>> http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
>>>=20
>>> Could you explain more which confusion you are referring to?
>>=20
>> Nejc suggested that DS-Lite without NATs (which I assumed meant =
without a CGN NAT, aka AFTR) would be confusing at this stage.
>>=20
>=20
>> The title of the referenced document is "Procedure to bypass DS-Lite =
AFTR"
>=20
> Indeed, but so what?
> (I don't see which confusion would result from using "4rd address =
mapping" to designate the stateless mapping called that way so far.)

I'm not sure how many ways I can say this.

The comment I was responding to was whether it was "confusing" to take =
ds-lite and remove the centralized CGN portion while still calling it =
ds-lite. The point in referencing the other document is that ds-lite =
itself has already done this by having a mode that removes the CGN.

- Mark

>=20
> RD
>=20
>=20


--Apple-Mail-116-619219682
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



The title of =
the referenced document is "Procedure to bypass DS-Lite =
AFTR"

Indeed, but so =
what?





RD



=

--Apple-Mail-116-619219682--

From mark@townsley.net  Sun Aug 21 07:18:15 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10321F8AA9 for ; Sun, 21 Aug 2011 07:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4GDymtFw9mm for ; Sun, 21 Aug 2011 07:18:14 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07C4521F8A58 for ; Sun, 21 Aug 2011 07:18:13 -0700 (PDT)
Received: by vws12 with SMTP id 12so4369245vws.31 for ; Sun, 21 Aug 2011 07:19:15 -0700 (PDT)
Received: by 10.52.184.40 with SMTP id er8mr1303831vdc.66.1313936355767; Sun, 21 Aug 2011 07:19:15 -0700 (PDT)
Received: from [192.168.2.105] (99-1-176-134.lightspeed.clmasc.sbcglobal.net [99.1.176.134]) by mx.google.com with ESMTPS id c13sm2599566vcp.44.2011.08.21.07.19.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Aug 2011 07:19:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-117-621703440
From: Mark Townsley 
In-Reply-To: 
Date: Sun, 21 Aug 2011 10:19:12 -0400
Message-Id: 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <9CED3349-22B8-49EC-B72C-77CD52D52427@townsley.net> 
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg 
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 14:18:15 -0000

--Apple-Mail-117-621703440
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Remi, I really do not understand the aversion to classifying 4rd as a =
stateless version of ds-lite. I'm not suggesting getting rid of the =
"4rd" name, this is really just a classification.=20

Let's look at the example of "clock" you brought up. The word "clock" =
comes from  "clocc, clokke, cloque, cloch", likely Celtic or Latin =
origin, meaning "bell." If you look at mechanism rather than how people =
actually use the device, it makes no sense whatsoever for a "digital =
time indicator" made with LEDs and run with semiconductors to be called =
something that means "bell". Even so, everyone who knew what a clock was =
at the time could immediately understand what a "digital clock" was the =
moment (no pun intended) they saw one. Teaching the world an entire new =
"Electronic Digital Time Indicator (EDTI)" term would have been futile. =
Hence the "analog clock" retronym was born, and today you have an =
"analog or digital" setting for your clock on your Mac.

It takes me about 30 seconds to describe at a high-level what 4rd is to =
someone who already understands ds-lite by referring to it as "a =
stateless version of ds-lite". That's a good thing.=20

- Mark

Ref: http://www.etymonline.com/index.php?term=3Dclock


On Aug 21, 2011, at 1:50 AM, R=E9mi Despr=E9s wrote:

> Mark,
>=20
> Interesting definition of "retronym".
>=20
> It remains, though, that an analogue clock, the example given in the =
given reference) is a clock variant (a device for measuring time).
> A 4rd-encapsulation solution is in no way a DS-lite variant ("built on =
a tunnel to reach a CGN").
>=20
> It would be nice, therefore, if the idea of using "stateless DS-lite" =
as a valuable substitute to "4rd" would no longer need to be discussed.
>=20
> Thanks,
> RD
>=20
>=20
>=20
>=20
> Le 20 ao=FBt 2011 =E0 04:05, Mark Townsley a =E9crit :
>=20
>> Aug 19, 2011, at 1:08 PM, R=E9mi Despr=E9s wrote:
>>>=20
>>> Le 19 ao=FBt 2011 =E0 17:11, Mark Townsley a =E9crit :
> ...
>>>>=20
>>>> Let me fill you in on some history.
>>>>=20
>>>> The term "Dual Stack Lite" came into being during a discussion at a =
cafe between Alain Durand and I. It was June 2008, and Alain was in =
Paris for the ICANN meeting while still working for Comcast. We had been =
discussing the various pros and cons of tunneling vs. dual-translation =
for a while. Alain was emphasizing that what was of most importance to =
him as an ISP, was that he not be burdened with provisioning IPv4 within =
the ISP network itself. However, in all cases the service to the =
subscriber was intended to be dual-stack. So: "Dual-stack" service but =
"lighter" on the ISP in terms of management and provisioning. Thus the =
term "dual-stack lite" was born.=20
>>>=20
>>> That's a good clarification.
>>>=20
>>> But in the mean time, DS-lite got specified in an RFC that won't =
change.
>>=20
>> But RFC's get updated all the time, as does terminology. Adding an =
adjective to something that is well understood to indicate that it can =
serve the same purpose but in a different way is quite useful during the =
introduction of that technology. Think "Horseless Carriage"=20
>>=20
>> http://en.wikipedia.org/wiki/Retronym
>>=20
>> A retronym is a type of neologism that provides a new name for an =
object or concept to differentiate the original form or version of it =
from a more recent form or version.[1] The original name is most often =
augmented with an adjective (rather than being completely displaced) to =
account for later developments of the object or concept itself. Much =
retronymy is driven by advances in technology.
>>=20
>> - Mark
>>=20
>>> RFC6333 says:
>>> - "Dual-Stack Lite enables a broadband service provider to share =
IPv4 addresses among customers by combining two well-known technologies: =
IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT)."
>>> - "the Dual-Stack Lite model is  built on IPv4-in-IPv6 tunnels to =
cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR),"=20
>>> - etc.
>>>=20
>>>> =46rom the beginning the "lite" term was about having less IPv4 in =
the access network for the operator to manage and provision, while still =
providing dual-stack service to the subscriber. 4rd fits that, as does =
RFC 6333. The solution details are just that - details.=20
>>>=20
>>> The devil is in details.
>>>=20
>>> Too bad 4rd wasn't invented before DS-lite. It would have better =
deserved the "lite" qualifier, but that's not how things happened.
>>>=20
>>> Because of what RFC6333 says, suggesting NOW that solutions that =
don't need NATs are variants of DS-lite is a sure way to confuse people.
>>>=20
>>> I do hope this discussion will now stop: there are so many technical =
"details" that need to reach common understanding, and agreement.=20
>>> In any case thank you for the really interesting explanation on =
history.
>>>=20
>>> Cheers.
>>> RD
>>>=20
>>>=20
>>=20
>=20


--Apple-Mail-117-621703440
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



Let's look at the example =
of "clock" you brought up. The word "clock" comes from =
 "clocc, clokke, cloque, cloch", likely Celtic or Latin =
origin, meaning "bell." If you look at mechanism rather than how =
people actually use the device, it makes no sense whatsoever for a =
"digital time indicator" made with LEDs and run with semiconductors to =
be called something that means "bell". Even so, everyone who knew what a =
clock was at the time could immediately understand what a "digital =
clock" was the moment (no pun intended) they saw one. Teaching the =
world an entire new "Electronic Digital Time Indicator (EDTI)" term =
would have been futile. Hence the "analog clock" retronym was born, and =
today you have an "analog or digital" setting for your clock on your =
Mac.

It takes me about 30 seconds to describe =
at a high-level what 4rd is to someone who already understands ds-lite =
by referring to it as "a stateless version of ds-lite". That's a good =
thing. 

- =
Mark



On =
Aug 21, 2011, at 1:50 AM, R=E9mi Despr=E9s wrote:


It remains, though, that an =
analogue clock, the example given in the given reference) is a =
clock variant (a device for measuring time).
A =
4rd-encapsulation solution is in no way a DS-lite variant ("built on a =
tunnel to reach a CGN").

It would be =
nice, therefore, if the idea of using "stateless DS-lite" as a =
valuable substitute to "4rd" would no longer need to be =
discussed.

Thanks,
RD




Le 20 ao=FBt 2011 =E0 =
04:05, Mark Townsley a =E9crit :

Aug 19, 2011, at 1:08 =
PM, R=E9mi Despr=E9s wrote:

Le 19 ao=FBt =
2011 =E0 17:11, Mark Townsley a =E9crit =
:
...

Let me fill you in on some =
history.

The term "Dual =
Stack Lite" came into being during a discussion at a cafe between Alain =
Durand and I. It was June 2008, and Alain was in Paris for the ICANN =
meeting while still working for Comcast. We had been discussing the =
various pros and cons of tunneling vs. dual-translation for a while. =
Alain was emphasizing that what was of most importance to him as an ISP, =
was that he not be burdened with provisioning IPv4 within the ISP =
network itself. However, in all cases the service to the subscriber was =
intended to be dual-stack. So: "Dual-stack" service but "lighter" on the =
ISP in terms of management and provisioning. Thus the term "dual-stack =
lite" was born. 

That's a good =
clarification.

But in the mean time, DS-lite got specified in an =
RFC that won't change.

But =
RFC's get updated all the time, as does terminology. Adding an adjective =
to something that is well understood to indicate that it can serve the =
same purpose but in a different way is quite useful during the =
introduction of that technology. Think "Horseless =
Carriage" 


neologism The original name is most often =
augmented with an adjective (rather than being completely displaced) to =
account for later developments of the object or concept itself. =
Much 
RFC6333 says:
- "Dual-Stack Lite enables a =
broadband service provider to share IPv4 addresses among customers by =
combining two well-known technologies: IP in IP (IPv4-in-IPv6) and =
Network Address Translation (NAT)."
- "the Dual-Stack Lite model is =
 built on IPv4-in-IPv6 tunnels to cross the network to reach a =
carrier-grade IPv4-IPv4 NAT (the AFTR)," 
- etc.

=46rom the beginning the "lite" term was about having less =
IPv4 in the access network for the operator to manage and provision, =
while still providing dual-stack service to the subscriber. 4rd fits =
that, as does RFC 6333. The solution details are just that - details. =


The devil is in details.

Too bad 4rd wasn't =
invented before DS-lite. It would have better deserved the "lite" =
qualifier, but that's not how things happened.

Because of what =
RFC6333 says, suggesting NOW that solutions that don't need NATs are =
variants of DS-lite is a sure way to confuse people.

I do hope =
this discussion will now stop: there are so many technical "details" =
that need to reach common understanding, and agreement. 
In any case =
thank you for the really interesting explanation on =
history.

Cheers.
RD





=

--Apple-Mail-117-621703440--

From brian.e.carpenter@gmail.com  Sun Aug 21 15:20:34 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEF721F8582 for ; Sun, 21 Aug 2011 15:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.595
X-Spam-Level: 
X-Spam-Status: No, score=-103.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHHtUaUqKVpC for ; Sun, 21 Aug 2011 15:20:34 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9DD21F856B for ; Sun, 21 Aug 2011 15:20:33 -0700 (PDT)
Received: by ywm21 with SMTP id 21so3455578ywm.31 for ; Sun, 21 Aug 2011 15:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AWxTcj/vMyBfy3IUs88AJVheTF3if6/NL4thSkxPZoI=; b=ZpPyUhiktBIbNNZlBt70tj6adimcs+Oa5ivwSJmCugw6uNnXtcPuZCocRy6k5xMidK Sim2aHVHt8IHjmR7Q+mGjRfqy8SkkMn3zL7vF+Zid4gbxQnQHPDlSI4bpq/adXZEIUUC Q9NfxUo2VRgB37FXWgDcBrOPQnlJpkIucKIcU=
Received: by 10.236.78.2 with SMTP id f2mr9762219yhe.46.1313965296039; Sun, 21 Aug 2011 15:21:36 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r28sm5033969yhm.10.2011.08.21.15.21.32 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 15:21:34 -0700 (PDT)
Message-ID: <4E5184E6.9060009@gmail.com>
Date: Mon, 22 Aug 2011 10:21:26 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tina TSOU 
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net> <4E503B08.9030800@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , "draft-murakami-softwire-4v6-translation@tools.ietf.org" 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2011 22:20:34 -0000

Hi Tina,

On 2011-08-21 14:08, Tina TSOU wrote:
...
> If an average IPv4 user is consuming 200 ports (or whatever
> value you prefer to assume) with their favourite p2p app, that
> is what sets the number of IPv4 users per shared address. It's
> the number of simultaneous ports, not the amount of traffic,
> that counts.
> [Tina:
> These drafts attempt to solve this issue.
> https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/

This doesn't create new ports; it just helps to allocate
them more rationally.

> https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/

If I understand this correctly, it avoids NAT444 (which is a
good thing, and would make
draft-weil-shared-transition-space-request unnecessary). But
again, it doesn't create new ports or new public IPv4 addresses,
which was my point.

4rd and 4via6 share this property of course.

   Brian

From jiangsheng@huawei.com  Sun Aug 21 18:05:59 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4421F8686 for ; Sun, 21 Aug 2011 18:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.29
X-Spam-Level: 
X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=0.309,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3+Y4HyUwCKe for ; Sun, 21 Aug 2011 18:05:58 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8D72721F8663 for ; Sun, 21 Aug 2011 18:05:58 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB001R41RO3O@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 22 Aug 2011 09:07:00 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB003HN1ROPG@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 22 Aug 2011 09:07:00 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADI77288; Mon, 22 Aug 2011 09:07:00 +0800 (CST)
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 22 Aug 2011 09:06:59 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Mon, 22 Aug 2011 09:07:00 +0800
Date: Mon, 22 Aug 2011 01:06:58 +0000
From: Sheng Jiang 
In-reply-to: 
X-Originating-IP: [10.110.98.152]
To: Yong Cui , "softwires@ietf.org" 
Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012383F6@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: New working group documents
Thread-index: AQHMX0R/p18OXq3lEkKi6co92/2a8JUoEOBQ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 01:05:59 -0000

> -----Original Message-----
> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
> Behalf Of Yong Cui
> Sent: Saturday, August 20, 2011 10:21 PM
> To: softwires@ietf.org
> Cc: Yong Cui
> Subject: [Softwires] New working group documents
> 
> Hi folks,
> 
> Following our rough concensus during Quebec City meeting and
> according to our charter/milestones, the chairs would like to
> ask the mailing list for the confirmation to adopt the following
> drafts:
> 
> 1. Deployment Considerations for Dual-Stack Lite
> http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
> 
> 
> 2. Public IPv4 over Access IPv6 Network
> http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
> 
> 3. Softwire Mesh Multicast
> http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
> 
> 4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
> 
> 5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
> http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-
> moti
> vation/
> 
> Please send your comments by 10am EDT on Aug 27. If you object to
> adoption, please also give the detailed reasons.
> 
> 
> 
> --Alain & Yong
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From jiangsheng@huawei.com  Sun Aug 21 18:06:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0292621F8686 for ; Sun, 21 Aug 2011 18:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.296
X-Spam-Level: 
X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8VPfxBBsHky for ; Sun, 21 Aug 2011 18:06:53 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 136BC21F86EE for ; Sun, 21 Aug 2011 18:06:53 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB000JG1T7TA@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 22 Aug 2011 09:07:56 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB00LGI1T715@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 22 Aug 2011 09:07:55 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADI77322; Mon, 22 Aug 2011 09:07:55 +0800 (CST)
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 22 Aug 2011 09:07:54 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Mon, 22 Aug 2011 09:07:54 +0800
Date: Mon, 22 Aug 2011 01:07:54 +0000
From: Sheng Jiang 
In-reply-to: 
X-Originating-IP: [10.110.98.152]
To: Yong Cui , "softwires@ietf.org" 
Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201238401@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: New working group documents
Thread-index: AQHMX0R/p18OXq3lEkKi6co92/2a8JUoERWA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 01:06:54 -0000

Support the adoption for 1, 2, 3, 5.

Sheng

> -----Original Message-----
> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
> Behalf Of Yong Cui
> Sent: Saturday, August 20, 2011 10:21 PM
> To: softwires@ietf.org
> Cc: Yong Cui
> Subject: [Softwires] New working group documents
> 
> Hi folks,
> 
> Following our rough concensus during Quebec City meeting and
> according to our charter/milestones, the chairs would like to
> ask the mailing list for the confirmation to adopt the following
> drafts:
> 
> 1. Deployment Considerations for Dual-Stack Lite
> http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
> 
> 
> 2. Public IPv4 over Access IPv6 Network
> http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
> 
> 3. Softwire Mesh Multicast
> http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
> 
> 4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
> 
> 5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
> http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-
> moti
> vation/
> 
> Please send your comments by 10am EDT on Aug 27. If you object to
> adoption, please also give the detailed reasons.
> 
> 
> 
> --Alain & Yong
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From bingxuere@gmail.com  Sun Aug 21 22:02:12 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A95721F86DD for ; Sun, 21 Aug 2011 22:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLd66beta4hv for ; Sun, 21 Aug 2011 22:02:11 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81A5821F8568 for ; Sun, 21 Aug 2011 22:02:11 -0700 (PDT)
Received: by gwb20 with SMTP id 20so3432698gwb.31 for ; Sun, 21 Aug 2011 22:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gN0QbG3taQIf3lUYsre+RW+E3qZpYoje8Fa8NuWdp18=; b=evngugQBkY1OZD9TFiUJ+GRtn7RcHzN0IXr6d2NH2Sj94XgROs/EeImNCocZoM16TE +Yp5RJDxbio0PYmElCtT0XoBiKeez4YmmWUmKHKyUEB31qsXAH2wa+IV0znlF4eryOhx ujuYCUepaeeilNrRlWyXv0Vs3f2dcwrleRrUs=
Received: by 10.42.73.9 with SMTP id q9mr2414648icj.314.1313989395142; Sun, 21 Aug 2011 22:03:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.14.131 with HTTP; Sun, 21 Aug 2011 22:02:54 -0700 (PDT)
In-Reply-To: 
References: 
From: Qiong 
Date: Mon, 22 Aug 2011 13:02:54 +0800
Message-ID: 
To: Yong Cui 
Content-Type: multipart/alternative; boundary=90e6ba6148bc22d99404ab10fff4
Cc: softwires@ietf.org
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 05:02:12 -0000

--90e6ba6148bc22d99404ab10fff4
Content-Type: text/plain; charset=UTF-8

Hi,

I support to adopt all.

Qiong Sun

On Sat, Aug 20, 2011 at 10:21 PM, Yong Cui  wrote:

> Hi folks,
>
> Following our rough concensus during Quebec City meeting and
> according to our charter/milestones, the chairs would like to
> ask the mailing list for the confirmation to adopt the following
> drafts:
>
> 1. Deployment Considerations for Dual-Stack Lite
> http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
>
>
> 2. Public IPv4 over Access IPv6 Network
> http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
>
> 3. Softwire Mesh Multicast
> http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
>
> 4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
>
> 5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
> http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
> vation/
>
> Please send your comments by 10am EDT on Aug 27. If you object to
> adoption, please also give the detailed reasons.
>
>
>
> --Alain & Yong
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--90e6ba6148bc22d99404ab10fff4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0

I support to adopt all.

Qiong Sun

On Sat, Aug 20, 2011 at 10:2=
1 PM, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:



Hi folks,



Following our rough concensus during Quebec City meeting and

according to our charter/milestones, the chairs would like to

ask the mailing list for the confirmation to adopt the following

drafts:



1. Deployment Considerations for Dual-Stack Lite

http://datatracker.ietf.org/doc/draft-lee-softwire=
-dslite-deployment/





2. Public IPv4 over Access IPv6 Network

http://datatracker.ietf.org/doc/draft-cui-softwire-host-=
4over6/



3. Softwire Mesh Multicast

http://datatracker.ietf.org/doc/draft-xu-softwire-mesh=
-multicast/



4. Multicast Extensions to DS-Lite Technique in Broadband Deployments

http://tools.ietf.org/html/draft-qin-softwire-dslite-=
multicast-04/



5. Motivations for Stateless IPv4 over IPv6 Migration Solutions

http://datatracker.ietf.org/doc/draft-operators-=
softwire-stateless-4v6-moti

vation/



Please send your comments by 10am EDT on Aug 27. If you object to

adoption, please also give the detailed reasons.







--Alain & Yong





_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--90e6ba6148bc22d99404ab10fff4--

From jacni@jacni.com  Sun Aug 21 22:06:40 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6959321F859E for ; Sun, 21 Aug 2011 22:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.735
X-Spam-Level: 
X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r62hLOHGNaOU for ; Sun, 21 Aug 2011 22:06:39 -0700 (PDT)
Received: from srv01.olivemail.cn (mx.olivemail.net [202.105.21.229]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5521F8593 for ; Sun, 21 Aug 2011 22:06:39 -0700 (PDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 416C134009E for ; Mon, 22 Aug 2011 13:07:40 +0800 (CST)
Received: from [172.18.230.102] (unknown [112.64.190.46]) by app (Coremail) with SMTP id +AWowJDrVgYL5FFOMOhVAA--.63018S2; Mon, 22 Aug 2011 13:07:34 +0800 (CST)
Message-ID: <4E51E44E.2090002@jacni.com>
Date: Mon, 22 Aug 2011 13:08:30 +0800
From: Jacni Qin 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Qiong 
References:  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030601080101010607080409"
X-CM-TRANSID: +AWowJDrVgYL5FFOMOhVAA--.63018S2
X-Coremail-Antispam: 1UD129KBjvJXoW7Cr4xGryDuFW3ZrW5trWkZwb_yoW8XF1xpa ykGrs8Ww48JF95Jws8u34a9w1vvFyrX3yjy3Zxt3WjvFyUJF18tw1vkw4FyrWUJrW5Gr4x ZF43CrW5Xan5urJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUxqb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjxAI 6IIYrVAFwwAYjsxI4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s 0DM2kK64x0aVW7GwIE548m6rI_Jw1UWr17M2kK6xCIbVAIwIAEc20F6c8GOVW8Jr15Jr4l n4vEIxkG6c02xx0F6c8GOVWUtr18Jw1lnx0Ec2IEnICE548m6r1DJrWUZwAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI 2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4IxY624lx4 CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrbIYCTnIWIevJa73UjIFyTuYvjxU3F4i UUUUU
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIIEko7lNFvMgAEs0
Cc: softwires@ietf.org, Yong Cui 
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 05:06:40 -0000

This is a multi-part message in MIME format.
--------------030601080101010607080409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Re-,

On 8/22/2011 1:02 PM, Qiong wrote:
> Hi,
>
> I support to adopt all.
>

+1


Cheers,
Jacni

> Qiong Sun
>
> On Sat, Aug 20, 2011 at 10:21 PM, Yong Cui  > wrote:
>
>     Hi folks,
>
>     Following our rough concensus during Quebec City meeting and
>     according to our charter/milestones, the chairs would like to
>     ask the mailing list for the confirmation to adopt the following
>     drafts:
>
>     1. Deployment Considerations for Dual-Stack Lite
>     http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
>
>
>     2. Public IPv4 over Access IPv6 Network
>     http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
>
>     3. Softwire Mesh Multicast
>     http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
>
>     4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
>     http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
>
>     5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
>     http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
>     vation/
>     
>
>     Please send your comments by 10am EDT on Aug 27. If you object to
>     adoption, please also give the detailed reasons.
>
>
>
>     --Alain & Yong
>
>
>     _______________________________________________
>     Softwires mailing list
>     Softwires@ietf.org 
>     https://www.ietf.org/mailman/listinfo/softwires
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--------------030601080101010607080409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Re-,

    

    On 8/22/2011 1:02 PM, Qiong wrote:
    
Hi, 
      


      

      
I support to adopt all.

      


      

    

    

    +1

    

    

    Cheers,

    Jacni

    

    

      
Qiong Sun

        

        
On Sat, Aug 20, 2011 at 10:21 PM, Yong
          Cui <cuiyong@tsinghua.edu.cn>
          wrote:

          
Hi folks,

            

            Following our rough concensus during Quebec City meeting and

            according to our charter/milestones, the chairs would like
            to

            ask the mailing list for the confirmation to adopt the
            following

            drafts:

            

            1. Deployment Considerations for Dual-Stack Lite

            http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/

            

            

            2. Public IPv4 over Access IPv6 Network

            http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/

            

            3. Softwire Mesh Multicast

            http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/

            

            4. Multicast Extensions to DS-Lite Technique in Broadband
            Deployments

            http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/

            

            5. Motivations for Stateless IPv4 over IPv6 Migration
            Solutions

            http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti

              vation/

            

            Please send your comments by 10am EDT on Aug 27. If you
            object to

            adoption, please also give the detailed reasons.

            

            

            

            --Alain & Yong

            

            

            _______________________________________________

            Softwires mailing list

            Softwires@ietf.org

            https://www.ietf.org/mailman/listinfo/softwires

          

        

        

      

      

      

      

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


    

  


--------------030601080101010607080409--


From yiu_lee@cable.comcast.com  Sun Aug 21 22:10:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3705821F8686 for ; Sun, 21 Aug 2011 22:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.035
X-Spam-Level: 
X-Spam-Status: No, score=-103.035 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdUV5pBywZ79 for ; Sun, 21 Aug 2011 22:10:43 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 50D6D21F8663 for ; Sun, 21 Aug 2011 22:10:43 -0700 (PDT)
Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.49742466; Sun, 21 Aug 2011 23:17:17 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 22 Aug 2011 01:11:41 -0400
From: "Lee, Yiu" 
To: Qiong 
Thread-Topic: [Softwires] New working group documents
Thread-Index: AQHMYIjAJs5zi4m5Hki7+YvY1/gJlZUoleSA
Date: Mon, 22 Aug 2011 05:11:40 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_C5F5EFA8743C4ABDB93880DF7F1FA0E6CableComcastcom_"
MIME-Version: 1.0
Cc: "softwires@ietf.org" , Yong Cui 
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 05:10:44 -0000

--_000_C5F5EFA8743C4ABDB93880DF7F1FA0E6CableComcastcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhbHNvIHN1cHBvcnQgdG8gYWRvcHQgYWxsLg0KDQoNCk9uIEF1ZyAyMiwgMjAxMSwgYXQgMTow
MyBBTSwgIlFpb25nIiA8YmluZ3h1ZXJlQGdtYWlsLmNvbTxtYWlsdG86YmluZ3h1ZXJlQGdtYWls
LmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KSSBzdXBwb3J0IHRvIGFkb3B0IGFsbC4NCg0KUWlvbmcg
U3VuDQoNCk9uIFNhdCwgQXVnIDIwLCAyMDExIGF0IDEwOjIxIFBNLCBZb25nIEN1aSA8PG1haWx0
bzpjdWl5b25nQHRzaW5naHVhLmVkdS5jbj5jdWl5b25nQHRzaW5naHVhLmVkdS5jbjxtYWlsdG86
Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY24+PiB3cm90ZToNCkhpIGZvbGtzLA0KDQpGb2xsb3dpbmcg
b3VyIHJvdWdoIGNvbmNlbnN1cyBkdXJpbmcgUXVlYmVjIENpdHkgbWVldGluZyBhbmQNCmFjY29y
ZGluZyB0byBvdXIgY2hhcnRlci9taWxlc3RvbmVzLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8N
CmFzayB0aGUgbWFpbGluZyBsaXN0IGZvciB0aGUgY29uZmlybWF0aW9uIHRvIGFkb3B0IHRoZSBm
b2xsb3dpbmcNCmRyYWZ0czoNCg0KMS4gRGVwbG95bWVudCBDb25zaWRlcmF0aW9ucyBmb3IgRHVh
bC1TdGFjayBMaXRlDQo8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZWUt
c29mdHdpcmUtZHNsaXRlLWRlcGxveW1lbnQvPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtbGVlLXNvZnR3aXJlLWRzbGl0ZS1kZXBsb3ltZW50Lw0KDQoNCjIuIFB1YmxpYyBJ
UHY0IG92ZXIgQWNjZXNzIElQdjYgTmV0d29yaw0KPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtY3VpLXNvZnR3aXJlLWhvc3QtNG92ZXI2Lz5odHRwOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aS1zb2Z0d2lyZS1ob3N0LTRvdmVyNi8NCg0KMy4gU29mdHdp
cmUgTWVzaCBNdWx0aWNhc3QNCjxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LXh1LXNvZnR3aXJlLW1lc2gtbXVsdGljYXN0Lz5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LXh1LXNvZnR3aXJlLW1lc2gtbXVsdGljYXN0Lw0KDQo0LiBNdWx0aWNhc3QgRXh0
ZW5zaW9ucyB0byBEUy1MaXRlIFRlY2huaXF1ZSBpbiBCcm9hZGJhbmQgRGVwbG95bWVudHMNCjxo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xaW4tc29mdHdpcmUtZHNsaXRlLW11bHRp
Y2FzdC0wNC8+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcWluLXNvZnR3aXJlLWRz
bGl0ZS1tdWx0aWNhc3QtMDQvDQoNCjUuIE1vdGl2YXRpb25zIGZvciBTdGF0ZWxlc3MgSVB2NCBv
dmVyIElQdjYgTWlncmF0aW9uIFNvbHV0aW9ucw0KPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtb3BlcmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aQ0KdmF0aW9u
Lz5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW9wZXJhdG9ycy1zb2Z0d2ly
ZS1zdGF0ZWxlc3MtNHY2LW1vdGkNCnZhdGlvbi8NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50
cyBieSAxMGFtIEVEVCBvbiBBdWcgMjcuIElmIHlvdSBvYmplY3QgdG8NCmFkb3B0aW9uLCBwbGVh
c2UgYWxzbyBnaXZlIHRoZSBkZXRhaWxlZCByZWFzb25zLg0KDQoNCg0KLS1BbGFpbiAmIFlvbmcN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29m
dHdpcmVzIG1haWxpbmcgbGlzdA0KPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+U29mdHdpcmVz
QGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQo8aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0BpZXRmLm9y
ZzxtYWlsdG86U29mdHdpcmVzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9zb2Z0d2lyZXMNCg==

--_000_C5F5EFA8743C4ABDB93880DF7F1FA0E6CableComcastcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <4B7719CDD106C7438B0DDBB644781064@cable.comcast.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG
RkYiPg0KPGRpdj5JIGFsc28gc3VwcG9ydCB0byBhZG9wdCBhbGwuPGJyPg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQpPbiBBdWcgMjIsIDIwMTEsIGF0IDE6MDMgQU0sICZx
dW90O1Fpb25nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmluZ3h1ZXJlQGdtYWlsLmNvbSI+
YmluZ3h1ZXJlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGRp
dj48L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5IaSwmbmJzcDsNCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgc3VwcG9ydCB0byBhZG9wdCBhbGwuPC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj5RaW9uZyBTdW48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x
dW90ZSI+T24gU2F0LCBBdWcgMjAsIDIwMTEgYXQgMTA6MjEgUE0sIFlvbmcgQ3VpIDxzcGFuIGRp
cj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY24iPjwv
YT48YSBocmVmPSJtYWlsdG86Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY24iPmN1aXlvbmdAdHNpbmdo
dWEuZWR1LmNuPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn
bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj
IHNvbGlkO3BhZGRpbmctbGVmdDoxZXg7Ij4NCkhpIGZvbGtzLDxicj4NCjxicj4NCkZvbGxvd2lu
ZyBvdXIgcm91Z2ggY29uY2Vuc3VzIGR1cmluZyBRdWViZWMgQ2l0eSBtZWV0aW5nIGFuZDxicj4N
CmFjY29yZGluZyB0byBvdXIgY2hhcnRlci9taWxlc3RvbmVzLCB0aGUgY2hhaXJzIHdvdWxkIGxp
a2UgdG88YnI+DQphc2sgdGhlIG1haWxpbmcgbGlzdCBmb3IgdGhlIGNvbmZpcm1hdGlvbiB0byBh
ZG9wdCB0aGUgZm9sbG93aW5nPGJyPg0KZHJhZnRzOjxicj4NCjxicj4NCjEuIERlcGxveW1lbnQg
Q29uc2lkZXJhdGlvbnMgZm9yIER1YWwtU3RhY2sgTGl0ZTxicj4NCjxhIGhyZWY9Imh0dHA6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVlLXNvZnR3aXJlLWRzbGl0ZS1kZXBsb3lt
ZW50LyIgdGFyZ2V0PSJfYmxhbmsiPjwvYT48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWxlZS1zb2Z0d2lyZS1kc2xpdGUtZGVwbG95bWVudC8iPmh0dHA6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVlLXNvZnR3aXJlLWRzbGl0ZS1kZXBsb3lt
ZW50LzwvYT48YnI+DQo8YnI+DQo8YnI+DQoyLiBQdWJsaWMgSVB2NCBvdmVyIEFjY2VzcyBJUHY2
IE5ldHdvcms8YnI+DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWN1aS1zb2Z0d2lyZS1ob3N0LTRvdmVyNi8iIHRhcmdldD0iX2JsYW5rIj48L2E+PGEgaHJl
Zj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jdWktc29mdHdpcmUtaG9z
dC00b3ZlcjYvIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aS1zb2Z0
d2lyZS1ob3N0LTRvdmVyNi88L2E+PGJyPg0KPGJyPg0KMy4gU29mdHdpcmUgTWVzaCBNdWx0aWNh
c3Q8YnI+DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1
LXNvZnR3aXJlLW1lc2gtbXVsdGljYXN0LyIgdGFyZ2V0PSJfYmxhbmsiPjwvYT48YSBocmVmPSJo
dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LXNvZnR3aXJlLW1lc2gtbXVs
dGljYXN0LyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1zb2Z0d2ly
ZS1tZXNoLW11bHRpY2FzdC88L2E+PGJyPg0KPGJyPg0KNC4gTXVsdGljYXN0IEV4dGVuc2lvbnMg
dG8gRFMtTGl0ZSBUZWNobmlxdWUgaW4gQnJvYWRiYW5kIERlcGxveW1lbnRzPGJyPg0KPGEgaHJl
Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcWluLXNvZnR3aXJlLWRzbGl0ZS1t
dWx0aWNhc3QtMDQvIiB0YXJnZXQ9Il9ibGFuayI+PC9hPjxhIGhyZWY9Imh0dHA6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LXFpbi1zb2Z0d2lyZS1kc2xpdGUtbXVsdGljYXN0LTA0LyI+aHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcWluLXNvZnR3aXJlLWRzbGl0ZS1tdWx0aWNh
c3QtMDQvPC9hPjxicj4NCjxicj4NCjUuIE1vdGl2YXRpb25zIGZvciBTdGF0ZWxlc3MgSVB2NCBv
dmVyIElQdjYgTWlncmF0aW9uIFNvbHV0aW9uczxicj4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtb3BlcmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYt
bW90aQ0KdmF0aW9uLyIgdGFyZ2V0PSJfYmxhbmsiPjwvYT48YSBocmVmPSJodHRwOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW9wZXJhdG9ycy1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2
LW1vdGkiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtb3BlcmF0b3JzLXNv
ZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aTwvYT48YnI+DQp2YXRpb24vPGJyPg0KPGJyPg0KUGxl
YXNlIHNlbmQgeW91ciBjb21tZW50cyBieSAxMGFtIEVEVCBvbiBBdWcgMjcuIElmIHlvdSBvYmpl
Y3QgdG88YnI+DQphZG9wdGlvbiwgcGxlYXNlIGFsc28gZ2l2ZSB0aGUgZGV0YWlsZWQgcmVhc29u
cy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLUFsYWluICZhbXA7IFlvbmc8YnI+DQo8YnI+DQo8
YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N
ClNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGll
dGYub3JnIj48L2E+PGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVz
QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vc29mdHdpcmVzIiB0YXJnZXQ9Il9ibGFuayI+PC9hPjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+U29mdHdpcmVzIG1haWxpbmcgbGlzdDwv
c3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIj5Tb2Z0
d2lyZXNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_C5F5EFA8743C4ABDB93880DF7F1FA0E6CableComcastcom_--

From mohamed.boucadair@orange-ftgroup.com  Sun Aug 21 23:30:26 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F73A21F8513; Sun, 21 Aug 2011 23:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.135
X-Spam-Level: 
X-Spam-Status: No, score=-4.135 tagged_above=-999 required=5 tests=[AWL=2.113,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1OTctH3sY8L; Sun, 21 Aug 2011 23:30:25 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4678221F84F6; Sun, 21 Aug 2011 23:30:24 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 3A6B73B42D7; Mon, 22 Aug 2011 08:31:27 +0200 (CEST)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 1DAA6C805C; Mon, 22 Aug 2011 08:31:27 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 22 Aug 2011 08:31:27 +0200
From: 
To: "Rajiv Asati (rajiva)" , Alain Durand 
Date: Mon, 22 Aug 2011 08:31:25 +0200
Thread-Topic: [Softwires] Softwire Interim Meeting in Beijing
Thread-Index: Acxedf5YgU1E4VZ5Raet8f2Vo9reOwACqjXQAIUHcFA=
Message-ID: <94C682931C08B048B7A8645303FDC9F350C9DC4664@PUEXCB1B.nanterre.francetelecom.fr>
References:  <00D528DC-C6EB-4309-A30D-B2651AA9A156@cisco.com> <34F36BB7-28B8-427E-913A-08332FC8D859@juniper.net> <067E6CE33034954AAC05C9EC85E2577C05B1B273@XMB-RCD-111.cisco.com>
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05B1B273@XMB-RCD-111.cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.22.31514
Cc: "softwires@ietf.org" , liziye , Yong Cui , "iesg-secretary@ietf.org" , "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 06:30:26 -0000

Dear all,

I fully agree with Rajiv.=20

I would like to add to the list of stateless solutions the proposal specifi=
ed in: http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04 =
and its companion I-D: http://tools.ietf.org/html/draft-boucadair-dhcpv6-sh=
ared-address-option-01.

Cheers,
Med=20

-----Message d'origine-----
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Rajiv Asati (rajiva)
Envoy=E9 : vendredi 19 ao=FBt 2011 17:04
=C0 : Alain Durand
Cc : softwires@ietf.org; liziye; Yong Cui; iesg-secretary@ietf.org; Ralph D=
roms (rdroms)
Objet : Re: [Softwires] Softwire Interim Meeting in Beijing

It doesn't, IMO. In fact, I beg to say that it is unfair mention
'tunneling vs translating' as a blanket statement, since we have known
all along that a sane 4v6 solution would likely involve translating
(44), no matter what.

Moreover, it is reasonable to call out all stateless 4v6 options, not
just a particular solution.=20

Cheers,
Rajiv


> -----Original Message-----
> From: Alain Durand [mailto:adurand@juniper.net]
> Sent: Friday, August 19, 2011 9:44 AM
> To: Rajiv Asati (rajiva)
> Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secretary@ietf.org;
Ralph Droms
> (rdroms)
> Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
>=20
> We mentioned 'tunneling vs translating'. This should cover it.
>=20
> Alain.
>=20
> Sent from my iPad
>=20
> On Aug 19, 2011, at 8:16 AM, "Rajiv Asati (rajiva)" 
wrote:
>=20
> > Yong,
> >
> > Why is dIVI not included In the discussion ?
> >
> > Could you please clarify?
> >
> > Cheers,
> > Rajiv
> >
> > Sent from Phone....
> >
> > On Aug 19, 2011, at 8:10 AM, "Yong Cui" 
wrote:
> >
> >> Hi folks,
> >>
> >> We, softwire wg chairs, in agreement with our ADs, are announcing
> >> an interim meeting in Beijing on September 26 & 27. The date has
> >> been chosen adjacent to the BBF meeting in Shangai to minimize
> >> travel and visa issues.
> >>
> >> The interim meeting will focus on 'stateless' solutions in general
> >> and 4rd in particular. Expected outcome includes progress on 4rd
> >> spec, packet format, where to put IPv4 bits, port indications, DHCP
> >> option, tunneling vs translation, coexistence with other
> >> technologies, etc...
> >>
> >> ---------------------------------------
> >> Meeting Location & recommended hotels
> >> Meeting venue: FIT Building, Tsinghua University, Beijing
> >> FIT Building is the first left building inside of the East Gate
> >> of Tsinghua Univeristy
> >>
http://maps.google.com/maps/ms?msid=3D202779846620144871057.0004aad8ce367b
982
> >> 9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798
> >>
> >> Recommended hotels:
> >> 1. Uniscenter (4 stars, 3 min walk)
> >>
http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
> >>
> >> 2. Wenjin Hotel (5 stars, 10 min walk)
> >> http://www.wenjin.com.cn/
> >>
> >> 3. Royal King Hotel (5 stars, 10 min by car)
> >> http://www.royalkinghotel.com/
> >>
> >> ----------------------------------------
> >> Invitation letter
> >> If you need an invitation letter, please send the following info
> >> to Ms. Ziye Li: .
> >> Surname:
> >> Given Name:
> >> Company:
> >> Address:
> >> Phone:
> >> Passport Number:
> >> Passport Exp. Date:
> >> Passport Issuing Country:
> >>
> >>
> >>
> >> -----------------------------------------
> >>
> >> Further contact information
> >> Please contact Ms. Ziye Li if you have any question about
> >> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
> >> 
> >>
> >>
> >> -- Alain, Yong
> >>
> >>
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

From xmw@cernet.edu.cn  Sun Aug 21 23:32:18 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F83C21F8514 for ; Sun, 21 Aug 2011 23:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.1
X-Spam-Level: 
X-Spam-Status: No, score=-93.1 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HAS_XAIMC=2.696, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhV1WrKZEnz5 for ; Sun, 21 Aug 2011 23:32:18 -0700 (PDT)
Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 57A5321F86C0 for ; Sun, 21 Aug 2011 23:32:17 -0700 (PDT)
Received: from user-THINK([61.164.107.130]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4e522183; Mon, 22 Aug 2011 14:33:19 +0800
Date: Mon, 22 Aug 2011 14:33:57 +0800
From: "Mingwei Xu" 
To: "Yong Cui" , "softwires@ietf.org" 
References: 
Message-ID: <201108221433542793563@cernet.edu.cn>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
X-AIMC-AUTH: xmw
X-AIMC-MAILFROM: xmw@cernet.edu.cn
X-AIMC-Msg-ID: fj5EYv0B
Cc: Yong Cui 
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 06:32:18 -0000

SSBzdXBwb3J0IHRvIGFkb3B0IGFsbC4NCg0KTWluZ3dlaQ0KDQoJDQoNCj09PT09PT0gMjAxMS0w
OC0yMCAyMjoyMToxNiDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KDQo+SGkgZm9sa3MsDQo+DQo+
Rm9sbG93aW5nIG91ciByb3VnaCBjb25jZW5zdXMgZHVyaW5nIFF1ZWJlYyBDaXR5IG1lZXRpbmcg
YW5kDQo+YWNjb3JkaW5nIHRvIG91ciBjaGFydGVyL21pbGVzdG9uZXMsIHRoZSBjaGFpcnMgd291
bGQgbGlrZSB0bw0KPmFzayB0aGUgbWFpbGluZyBsaXN0IGZvciB0aGUgY29uZmlybWF0aW9uIHRv
IGFkb3B0IHRoZSBmb2xsb3dpbmcNCj5kcmFmdHM6DQo+DQo+MS4gRGVwbG95bWVudCBDb25zaWRl
cmF0aW9ucyBmb3IgRHVhbC1TdGFjayBMaXRlDQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1sZWUtc29mdHdpcmUtZHNsaXRlLWRlcGxveW1lbnQvDQo+DQo+DQo+Mi4gUHVi
bGljIElQdjQgb3ZlciBBY2Nlc3MgSVB2NiBOZXR3b3JrDQo+aHR0cDovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1jdWktc29mdHdpcmUtaG9zdC00b3ZlcjYvDQo+DQo+My4gU29mdHdp
cmUgTWVzaCBNdWx0aWNhc3QNCj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LXh1LXNvZnR3aXJlLW1lc2gtbXVsdGljYXN0Lw0KPg0KPjQuIE11bHRpY2FzdCBFeHRlbnNpb25z
IHRvIERTLUxpdGUgVGVjaG5pcXVlIGluIEJyb2FkYmFuZCBEZXBsb3ltZW50cw0KPmh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXFpbi1zb2Z0d2lyZS1kc2xpdGUtbXVsdGljYXN0LTA0
Lw0KPg0KPjUuIE1vdGl2YXRpb25zIGZvciBTdGF0ZWxlc3MgSVB2NCBvdmVyIElQdjYgTWlncmF0
aW9uIFNvbHV0aW9ucw0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtb3Bl
cmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aQ0KPnZhdGlvbi8NCj4NCj5QbGVhc2Ug
c2VuZCB5b3VyIGNvbW1lbnRzIGJ5IDEwYW0gRURUIG9uIEF1ZyAyNy4gSWYgeW91IG9iamVjdCB0
bw0KPmFkb3B0aW9uLCBwbGVhc2UgYWxzbyBnaXZlIHRoZSBkZXRhaWxlZCByZWFzb25zLg0KPg0K
Pg0KPg0KPi0tQWxhaW4gJiBZb25nDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+U29mdHdpcmVz
QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2ly
ZXMNCj4NCg0KPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0K
oaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogDQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoU1pbmd3
ZWkgWHUNCqGhoaGhoaGhoaGhoaGhoaF4bXdAY2VybmV0LmVkdS5jbg0KoaGhoaGhoaGhoaGhoaGh
oaGhoaEyMDExLTA4LTIyDQo=


From mohamed.boucadair@orange-ftgroup.com  Sun Aug 21 23:41:20 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9221F87C5 for ; Sun, 21 Aug 2011 23:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level: 
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWqGyzkDIRyd for ; Sun, 21 Aug 2011 23:41:20 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id E4C8221F8779 for ; Sun, 21 Aug 2011 23:41:19 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4A2FA2AC178; Mon, 22 Aug 2011 08:42:21 +0200 (CEST)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2B1E915803A; Mon, 22 Aug 2011 08:42:21 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 22 Aug 2011 08:42:21 +0200
From: 
To: Yong Cui , "softwires@ietf.org" 
Date: Mon, 22 Aug 2011 08:42:18 +0200
Thread-Topic: New working group documents
Thread-Index: AcxfRGvpQhOKE3o+RmSwYF9LWJnb/ABUgTSA
Message-ID: <94C682931C08B048B7A8645303FDC9F350C9DC466C@PUEXCB1B.nanterre.francetelecom.fr>
References: 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.22.31514
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 06:41:20 -0000

Dear Yong, all,

I support the adoption of all these I-Ds as softwire WG documents.

Cheers,
Med=20

-----Message d'origine-----
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Yong Cui
Envoy=E9 : samedi 20 ao=FBt 2011 16:21
=C0 : softwires@ietf.org
Cc : Yong Cui
Objet : [Softwires] New working group documents

Hi folks,

Following our rough concensus during Quebec City meeting and
according to our charter/milestones, the chairs would like to
ask the mailing list for the confirmation to adopt the following
drafts:

1. Deployment Considerations for Dual-Stack Lite
http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/


2. Public IPv4 over Access IPv6 Network
http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/

3. Softwire Mesh Multicast
http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/

4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/

5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
vation/

Please send your comments by 10am EDT on Aug 27. If you object to
adoption, please also give the detailed reasons.



--Alain & Yong


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

From eleven.fuyu@huawei.com  Mon Aug 22 01:33:27 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D9F21F88A0 for ; Mon, 22 Aug 2011 01:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.25
X-Spam-Level: 
X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[AWL=2.349,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnMXihOWFPOu for ; Mon, 22 Aug 2011 01:33:26 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5221F8507 for ; Mon, 22 Aug 2011 01:33:26 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB006OWMFZS2@szxga05-in.huawei.com> for softwires@ietf.org; Mon, 22 Aug 2011 16:33:36 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB00KI5MFZWJ@szxga05-in.huawei.com> for softwires@ietf.org; Mon, 22 Aug 2011 16:33:35 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH73660; Mon, 22 Aug 2011 16:33:33 +0800 (CST)
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 22 Aug 2011 16:33:29 +0800
Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.204]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Mon, 22 Aug 2011 16:33:30 +0800
Date: Mon, 22 Aug 2011 08:33:29 +0000
From: "Eleven Fu(Yu)" 
In-reply-to: 
X-Originating-IP: [10.110.98.137]
To: Yong Cui , "softwires@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=Windows-1252
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: New working group documents
Thread-index: AQHMX0R+oih/OB/9bEKHnA3nUmwiB5UoF+aw
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 08:33:27 -0000

Hi,
   
   I support the adoption for draft 1, 2, 3, 5 to WG items.

Regards,
Yu

-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Yong Cui
Sent: Saturday, August 20, 2011 10:21 PM
To: softwires@ietf.org
Cc: Yong Cui
Subject: [Softwires] New working group documents

Hi folks,

Following our rough concensus during Quebec City meeting and
according to our charter/milestones, the chairs would like to
ask the mailing list for the confirmation to adopt the following
drafts:

1. Deployment Considerations for Dual-Stack Lite
http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/


2. Public IPv4 over Access IPv6 Network
http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/

3. Softwire Mesh Multicast
http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/

4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/

5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
vation/

Please send your comments by 10am EDT on Aug 27. If you object to
adoption, please also give the detailed reasons.



--Alain & Yong


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

From hujie.331@gmail.com  Mon Aug 22 02:01:50 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9BD21F8B13 for ; Mon, 22 Aug 2011 02:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.035
X-Spam-Level: ****
X-Spam-Status: No, score=4.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1,  SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFr94BeO0zcx for ; Mon, 22 Aug 2011 02:01:50 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBD9821F8A7D for ; Mon, 22 Aug 2011 02:01:49 -0700 (PDT)
Received: by yxj17 with SMTP id 17so2578448yxj.31 for ; Mon, 22 Aug 2011 02:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=4Qj6HKJqEDw2F9/PxRx0FCsfUVVBYV30y75xk+EkNl4=; b=NqvTembQBXbzWedQQK+zb3SXsAbip6MgSIh5Cy75Fqd0Ww5GdZApn8y9WHBOF3HW9M gKJkZNZ/S7t2eTkFdbClewsE8TKMklwC4n77v+9HnOREM6FN6pa9e8E5tcv5AQReYKVQ EelLZZSlagO5GEKYtxKfQkZfhg8x5KJl2/qiE=
Received: by 10.142.152.34 with SMTP id z34mr1658797wfd.209.1314003771751; Mon, 22 Aug 2011 02:02:51 -0700 (PDT)
Received: from IPv6TeamPC ([219.142.69.78]) by mx.google.com with ESMTPS id s3sm4122508pbg.29.2011.08.22.02.02.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 02:02:50 -0700 (PDT)
From: 
To: "'Yong Cui'" , 
References:  
In-Reply-To: 
Date: Mon, 22 Aug 2011 17:02:34 +0800
Message-ID: <001e01cc60aa$437dda90$ca798fb0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF6c+1fvb/V+L6bDz1BRvhbixJ+UQHLgaANlb4QUTA=
Content-Language: zh-cn
Subject: [Softwires] =?gb2312?b?tPC4tDogIE5ldyB3b3JraW5nIGdyb3VwIGRvY3Vt?= =?gb2312?b?ZW50cw==?=
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 09:01:50 -0000

I support all of them.

Jie Hu

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: softwires-bounces@ietf.org =
[mailto:softwires-bounces@ietf.org] =B4=FA=B1=ED
Eleven Fu(Yu)
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C222=C8=D5 16:33
=CA=D5=BC=FE=C8=CB: Yong Cui; softwires@ietf.org
=D6=F7=CC=E2: Re: [Softwires] New working group documents

Hi,
  =20
   I support the adoption for draft 1, 2, 3, 5 to WG items.

Regards,
Yu

-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
Behalf Of Yong Cui
Sent: Saturday, August 20, 2011 10:21 PM
To: softwires@ietf.org
Cc: Yong Cui
Subject: [Softwires] New working group documents

Hi folks,

Following our rough concensus during Quebec City meeting and according =
to
our charter/milestones, the chairs would like to ask the mailing list =
for
the confirmation to adopt the following
drafts:

1. Deployment Considerations for Dual-Stack Lite
http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/


2. Public IPv4 over Access IPv6 Network
http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/

3. Softwire Mesh Multicast
http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/

4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/

5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-mo=
ti
vation/

Please send your comments by 10am EDT on Aug 27. If you object to =
adoption,
please also give the detailed reasons.



--Alain & Yong


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


From ma.gaofeng@zte.com.cn  Mon Aug 22 02:11:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF6D21F8B0A; Mon, 22 Aug 2011 02:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.906
X-Spam-Level: 
X-Spam-Status: No, score=-91.906 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XboGYEmAriA6; Mon, 22 Aug 2011 02:11:44 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BA94C21F8B0D; Mon, 22 Aug 2011 02:11:43 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131322280236962; Mon, 22 Aug 2011 16:59:30 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 40693.2681393800; Mon, 22 Aug 2011 17:12:36 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p7M9CQrJ070388; Mon, 22 Aug 2011 17:12:26 +0800 (GMT-8) (envelope-from ma.gaofeng@zte.com.cn)
In-Reply-To: 
To: Yong Cui 
MIME-Version: 1.0
X-KeepSent: E1BDC4AE:1C774DDF-482578F4:0031DFD0; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: ma.gaofeng@zte.com.cn
Date: Mon, 22 Aug 2011 17:12:29 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-22 17:12:29, Serialize complete at 2011-08-22 17:12:29
Content-Type: multipart/alternative; boundary="=_alternative 003293EE482578F4_="
X-MAIL: mse01.zte.com.cn p7M9CQrJ070388
Cc: softwires@ietf.org, softwires-bounces@ietf.org, Yong Cui 
Subject: [Softwires] =?gb2312?b?tPC4tDogIE5ldyB3b3JraW5nIGdyb3VwIGRvY3Vt?= =?gb2312?b?ZW50cw==?=
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 09:11:45 -0000

This is a multipart message in MIME format.
--=_alternative 003293EE482578F4_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGksDQogIEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgbXVsdGljYXN0IGFuZCBzdGF0ZWxlc3Mg
bW90aXZhdGlvbiBkcmFmdHM6IDMsIA0KNCBhbmQgNS4NCg0KQ2hlZXJzLA0KICBHYW8gZmVuZw0K
IA0KDQoNCg0KWW9uZyBDdWkgPGN1aXlvbmdAdHNpbmdodWEuZWR1LmNuPiANCreivP7IyzogIHNv
ZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA4LTIwIDIyOjIxDQoNCsrVvP7Iyw0KPHNv
ZnR3aXJlc0BpZXRmLm9yZz4NCrOty80NCllvbmcgQ3VpIDxjdWl5b25nQHRzaW5naHVhLmVkdS5j
bj4NCtb3zOINCltTb2Z0d2lyZXNdIE5ldyB3b3JraW5nIGdyb3VwIGRvY3VtZW50cw0KDQoNCg0K
DQoNCg0KSGkgZm9sa3MsDQoNCkZvbGxvd2luZyBvdXIgcm91Z2ggY29uY2Vuc3VzIGR1cmluZyBR
dWViZWMgQ2l0eSBtZWV0aW5nIGFuZA0KYWNjb3JkaW5nIHRvIG91ciBjaGFydGVyL21pbGVzdG9u
ZXMsIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0bw0KYXNrIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHRo
ZSBjb25maXJtYXRpb24gdG8gYWRvcHQgdGhlIGZvbGxvd2luZw0KZHJhZnRzOg0KDQoxLiBEZXBs
b3ltZW50IENvbnNpZGVyYXRpb25zIGZvciBEdWFsLVN0YWNrIExpdGUNCmh0dHA6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVlLXNvZnR3aXJlLWRzbGl0ZS1kZXBsb3ltZW50Lw0K
DQoNCjIuIFB1YmxpYyBJUHY0IG92ZXIgQWNjZXNzIElQdjYgTmV0d29yaw0KaHR0cDovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jdWktc29mdHdpcmUtaG9zdC00b3ZlcjYvDQoNCjMu
IFNvZnR3aXJlIE1lc2ggTXVsdGljYXN0DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LXh1LXNvZnR3aXJlLW1lc2gtbXVsdGljYXN0Lw0KDQo0LiBNdWx0aWNhc3QgRXh0ZW5z
aW9ucyB0byBEUy1MaXRlIFRlY2huaXF1ZSBpbiBCcm9hZGJhbmQgRGVwbG95bWVudHMNCmh0dHA6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXFpbi1zb2Z0d2lyZS1kc2xpdGUtbXVsdGljYXN0
LTA0Lw0KDQo1LiBNb3RpdmF0aW9ucyBmb3IgU3RhdGVsZXNzIElQdjQgb3ZlciBJUHY2IE1pZ3Jh
dGlvbiBTb2x1dGlvbnMNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtb3Bl
cmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aQ0KDQp2YXRpb24vDQoNClBsZWFzZSBz
ZW5kIHlvdXIgY29tbWVudHMgYnkgMTBhbSBFRFQgb24gQXVnIDI3LiBJZiB5b3Ugb2JqZWN0IHRv
DQphZG9wdGlvbiwgcGxlYXNlIGFsc28gZ2l2ZSB0aGUgZGV0YWlsZWQgcmVhc29ucy4NCg0KDQoN
Ci0tQWxhaW4gJiBZb25nDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZw0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KDQoNCg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh
aW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh
bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBp
ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFy
ZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmlj
YXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdp
dGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m
IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBv
cmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVz
c2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhh
cyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0
ZW0uDQo=
--=_alternative 003293EE482578F4_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTIgZmFj
ZT0izqLI7dHFutoiPkkNCnN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIG11bHRpY2FzdCBhbmQgc3Rh
dGVsZXNzIG1vdGl2YXRpb24gZHJhZnRzOiAzLCA0DQphbmQgNS48L2ZvbnQ+DQo8YnI+DQo8YnI+
PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNoZWVycyw8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBHYW8gZmVuZzwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJy
Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZv
bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPllvbmcgQ3VpICZsdDtjdWl5b25nQHRzaW5n
aHVhLmVkdS5jbiZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt
c2VyaWYiPreivP7IyzogJm5ic3A7c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8
cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wOC0yMCAyMjoyMTwvZm9udD4N
Cjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk
Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL
PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7c29m
dHdpcmVzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh
bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rp
dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+WW9uZyBDdWkgJmx0O2N1aXlv
bmdAdHNpbmdodWEuZWR1LmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp
diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48
L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1NvZnR3aXJlc10gTmV3
IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8
dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8
YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBmb2xrcyw8YnI+DQo8YnI+DQpGb2xsb3dpbmcg
b3VyIHJvdWdoIGNvbmNlbnN1cyBkdXJpbmcgUXVlYmVjIENpdHkgbWVldGluZyBhbmQ8YnI+DQph
Y2NvcmRpbmcgdG8gb3VyIGNoYXJ0ZXIvbWlsZXN0b25lcywgdGhlIGNoYWlycyB3b3VsZCBsaWtl
IHRvPGJyPg0KYXNrIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHRoZSBjb25maXJtYXRpb24gdG8gYWRv
cHQgdGhlIGZvbGxvd2luZzxicj4NCmRyYWZ0czo8YnI+DQo8YnI+DQoxLiBEZXBsb3ltZW50IENv
bnNpZGVyYXRpb25zIGZvciBEdWFsLVN0YWNrIExpdGU8YnI+DQpodHRwOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWxlZS1zb2Z0d2lyZS1kc2xpdGUtZGVwbG95bWVudC88YnI+DQo8
YnI+DQo8YnI+DQoyLiBQdWJsaWMgSVB2NCBvdmVyIEFjY2VzcyBJUHY2IE5ldHdvcms8YnI+DQpo
dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aS1zb2Z0d2lyZS1ob3N0LTRv
dmVyNi88YnI+DQo8YnI+DQozLiBTb2Z0d2lyZSBNZXNoIE11bHRpY2FzdDxicj4NCmh0dHA6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteHUtc29mdHdpcmUtbWVzaC1tdWx0aWNhc3Qv
PGJyPg0KPGJyPg0KNC4gTXVsdGljYXN0IEV4dGVuc2lvbnMgdG8gRFMtTGl0ZSBUZWNobmlxdWUg
aW4gQnJvYWRiYW5kIERlcGxveW1lbnRzPGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtcWluLXNvZnR3aXJlLWRzbGl0ZS1tdWx0aWNhc3QtMDQvPGJyPg0KPGJyPg0KNS4gTW90
aXZhdGlvbnMgZm9yIFN0YXRlbGVzcyBJUHY0IG92ZXIgSVB2NiBNaWdyYXRpb24gU29sdXRpb25z
PGJyPg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vcGVyYXRvcnMtc29m
dHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpPGJyPg0KdmF0aW9uLzxicj4NCjxicj4NClBsZWFzZSBz
ZW5kIHlvdXIgY29tbWVudHMgYnkgMTBhbSBFRFQgb24gQXVnIDI3LiBJZiB5b3Ugb2JqZWN0IHRv
PGJyPg0KYWRvcHRpb24sIHBsZWFzZSBhbHNvIGdpdmUgdGhlIGRldGFpbGVkIHJlYXNvbnMuPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KLS1BbGFpbiAmYW1wOyBZb25nPGJyPg0KPGJyPg0KPGJyPg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTb2Z0
d2lyZXMgbWFpbGluZyBsaXN0PGJyPg0KU29mdHdpcmVzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8YnI+DQo8YnI+DQo8L2ZvbnQ+
PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJp
dHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQm
bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9w
ZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5i
c3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRl
bnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJz
cDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZu
YnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJz
cDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24m
bmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZu
YnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJz
cDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2Zv
ciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw
O29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNw
O2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNw
O3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3Rp
ZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdl
LiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5i
c3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp
dmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVu
Jm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5i
c3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4=
--=_alternative 003293EE482578F4_=--


From xiaohong.deng@orange-ftgroup.com  Mon Aug 22 02:14:52 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88A221F8B1F for ; Mon, 22 Aug 2011 02:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.254
X-Spam-Level: 
X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=-2.055, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNb8dptlYWsV for ; Mon, 22 Aug 2011 02:14:52 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id DB4AB21F8B22 for ; Mon, 22 Aug 2011 02:14:51 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1A3826FCC06; Mon, 22 Aug 2011 11:24:38 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 132FA6FCB07; Mon, 22 Aug 2011 11:24:38 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 22 Aug 2011 11:15:55 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 22 Aug 2011 17:15:51 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01999891@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <201108221433542793563@cernet.edu.cn>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] New working group documents
Thread-Index: AcxgrBaZRaHDnCSTS6ySp/xnDmELbQ==
References:  <201108221433542793563@cernet.edu.cn>
From: 
To: , , 
X-OriginalArrivalTime: 22 Aug 2011 09:15:55.0623 (UTC) FILETIME=[18F4A770:01CC60AC]
Cc: cuiyong@tsinghua.edu.cn
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 09:14:52 -0000

+1, support adopting all.

Xiaohong=20

|-----Original Message-----
|From: Mingwei Xu [mailto:xmw@cernet.edu.cn]=20
|Sent: Monday, August 22, 2011 2:34 PM
|To: Yong Cui; softwires@ietf.org
|Cc: Yong Cui
|Subject: Re: [Softwires] New working group documents
|
|I support to adopt all.
|
|Mingwei
|
|=09
|
|=3D=3D=3D=3D=3D=3D=3D 2011-08-20 22:21:16 =
=C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA=3D=3D=3D=3D=3D=3D=3D
|
|>Hi folks,
|>
|>Following our rough concensus during Quebec City meeting and=20
|according=20
|>to our charter/milestones, the chairs would like to ask the mailing=20
|>list for the confirmation to adopt the following
|>drafts:
|>
|>1. Deployment Considerations for Dual-Stack Lite=20
|>http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
|>
|>
|>2. Public IPv4 over Access IPv6 Network=20
|>http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
|>
|>3. Softwire Mesh Multicast
|>http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
|>
|>4. Multicast Extensions to DS-Lite Technique in Broadband Deployments=20
|>http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
|>
|>5. Motivations for Stateless IPv4 over IPv6 Migration Solutions=20
|>http://datatracker.ietf.org/doc/draft-operators-softwire-state
|less-4v6-
|>moti
|>vation/
|>
|>Please send your comments by 10am EDT on Aug 27. If you object to=20
|>adoption, please also give the detailed reasons.
|>
|>
|>
|>--Alain & Yong
|>
|>
|>_______________________________________________
|>Softwires mailing list
|>Softwires@ietf.org
|>https://www.ietf.org/mailman/listinfo/softwires
|>
|
|=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D
|		=09
|
|=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2
|=C0=F1=A3=A1
|=20
|				=20
|=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Mingwei Xu
|=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1xmw@cernet.edu.cn
|=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12011-08-22
|

From christian.jacquenet@orange-ftgroup.com  Mon Aug 22 03:38:13 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36D21F8AFF for ; Mon, 22 Aug 2011 03:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6xApcyMgKYm for ; Mon, 22 Aug 2011 03:38:13 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B7BE621F84F5 for ; Mon, 22 Aug 2011 03:38:12 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6EDDD26424F; Mon, 22 Aug 2011 12:39:16 +0200 (CEST)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4F8BE23807C; Mon, 22 Aug 2011 12:39:16 +0200 (CEST)
Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 22 Aug 2011 12:39:16 +0200
From: 
To: Yong Cui , "softwires@ietf.org" 
Date: Mon, 22 Aug 2011 12:39:14 +0200
Thread-Topic: New working group documents
Thread-Index: AcxfRGv1UQvKctPgSTK3tUk/j+kTIwABbplw
Message-ID: <23479_1314009556_4E5231D4_23479_133463_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF57865F9@PUEXCB1C.nanterre.francetelecom.fr>
References: 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.22.52415
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 10:38:13 -0000

Dear all,

I'm in favor of adopting the 5 drafts listed below as softwire WG documents.

Cheers,

Christian.=20

-----Message d'origine-----
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Yong Cui
Envoy=E9 : samedi 20 ao=FBt 2011 16:21
=C0 : softwires@ietf.org
Cc : Yong Cui
Objet : [Softwires] New working group documents

Hi folks,

Following our rough concensus during Quebec City meeting and according to o=
ur charter/milestones, the chairs would like to ask the mailing list for th=
e confirmation to adopt the following
drafts:

1. Deployment Considerations for Dual-Stack Lite http://datatracker.ietf.or=
g/doc/draft-lee-softwire-dslite-deployment/


2. Public IPv4 over Access IPv6 Network
http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/

3. Softwire Mesh Multicast
http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/

4. Multicast Extensions to DS-Lite Technique in Broadband Deployments http:=
//tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/

5. Motivations for Stateless IPv4 over IPv6 Migration Solutions http://data=
tracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
vation/

Please send your comments by 10am EDT on Aug 27. If you object to adoption,=
 please also give the detailed reasons.



--Alain & Yong


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

***************************************************************************=
*****
IMPORTANT.Les informations contenues dans ce message electronique y compris=
 les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) men=
tionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve=
uillez immediatement le signaler  a l expediteur et effacer ce message=20
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans=
 ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment=
 s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout vi=
rus.

IMPORTANT.This e-mail message and any attachments are strictly confidential=
 and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(=
s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not b=
e liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
***************************************************************************=
*****


From Olaf.Bonness@telekom.de  Mon Aug 22 03:49:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671FC21F8B1D for ; Mon, 22 Aug 2011 03:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrs34CyQSuew for ; Mon, 22 Aug 2011 03:49:54 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A321F8B1B for ; Mon, 22 Aug 2011 03:49:53 -0700 (PDT)
Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 22 Aug 2011 12:49:52 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.177]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Mon, 22 Aug 2011 12:49:48 +0200
From: 
To: 
Date: Mon, 22 Aug 2011 12:49:48 +0200
Thread-Topic: New working group documents
Thread-Index: AcxfRHPy1mUFdpD+RCuYUOnfdttpdwBdH8ew
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: cuiyong@tsinghua.edu.cn
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 10:49:55 -0000

I'm in favour adopting 1, 4 and 5. No opinion at the moment regarding 2 and=
 3.
Thx
Olaf


> -----Urspr=FCngliche Nachricht-----
> Von: softwires-bounces@ietf.org
> [mailto:softwires-bounces@ietf.org] Im Auftrag von Yong Cui
> Gesendet: Samstag, 20. August 2011 16:21
> An: softwires@ietf.org
> Cc: Yong Cui
> Betreff: [Softwires] New working group documents
>
> Hi folks,
>
> Following our rough concensus during Quebec City meeting and
> according to our charter/milestones, the chairs would like to
> ask the mailing list for the confirmation to adopt the following
> drafts:
>
> 1. Deployment Considerations for Dual-Stack Lite
> http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
>
>
> 2. Public IPv4 over Access IPv6 Network
> http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
>
> 3. Softwire Mesh Multicast
> http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
>
> 4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
>
> 5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
> http://datatracker.ietf.org/doc/draft-operators-softwire-state
less-4v6-moti
> vation/
>
> Please send your comments by 10am EDT on Aug 27. If you object to
> adoption, please also give the detailed reasons.
>
>
>
> --Alain & Yong
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

From phdgang@gmail.com  Mon Aug 22 03:56:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5421F8B00; Mon, 22 Aug 2011 03:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.481
X-Spam-Level: 
X-Spam-Status: No, score=-5.481 tagged_above=-999 required=5 tests=[AWL=2.118,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDEk48jqeLiT; Mon, 22 Aug 2011 03:56:32 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAC1E21F8AF8; Mon, 22 Aug 2011 03:56:31 -0700 (PDT)
Received: by vws12 with SMTP id 12so4939255vws.31 for ; Mon, 22 Aug 2011 03:57:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yUdZJSQ+PSH3Ijz+f1/cWjtqxGHlcZadW3qtja/3CkU=; b=cnvCy8FQqL/R8ipGemp2gLpGUoIcrBkVNlZwPxONE5xMEgc/4XnE/nfWC7UlTOpeh+ FVd+OamXtaBXoKgC5Xrrviaaoyu6YdzNbZ7lHgEm4E6LPutOrUcG+p5lcPWBp02WY42W kA4rlbdRwL0i7xTSg1U8vMWRbdnOQVUevv1fw=
MIME-Version: 1.0
Received: by 10.52.25.65 with SMTP id a1mr1779001vdg.284.1314010656311; Mon, 22 Aug 2011 03:57:36 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Mon, 22 Aug 2011 03:57:36 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 22 Aug 2011 18:57:36 +0800
Message-ID: 
From: GangChen 
To: Yong Cui 
Content-Type: text/plain; charset=ISO-8859-1
Cc: softwires@ietf.org, liziye , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 10:56:37 -0000

Dear Chairs,

I suggest including draft-murakami-softwire-4v6-translation-00 into
the agenda as well.
We already had a presentation in last softwire meeting. It's
reasonable to continue the discussion in the interim meeting

Many thanks

Gang

2011/8/19, Yong Cui :
> Hi folks,
>
> We, softwire wg chairs, in agreement with our ADs, are announcing
> an interim meeting in Beijing on September 26 & 27. The date has
> been chosen adjacent to the BBF meeting in Shangai to minimize
> travel and visa issues.
>
> The interim meeting will focus on 'stateless' solutions in general
> and 4rd in particular. Expected outcome includes progress on 4rd
> spec, packet format, where to put IPv4 bits, port indications, DHCP
> option, tunneling vs translation, coexistence with other
> technologies, etc...
>
> ---------------------------------------
> Meeting Location & recommended hotels
> Meeting venue: FIT Building, Tsinghua University, Beijing
> FIT Building is the first left building inside of the East Gate
> of Tsinghua Univeristy
> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
>
> Recommended hotels:
> 1. Uniscenter (4 stars, 3 min walk)
> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>
> 2. Wenjin Hotel (5 stars, 10 min walk)
> http://www.wenjin.com.cn/
>
> 3. Royal King Hotel (5 stars, 10 min by car)
> http://www.royalkinghotel.com/
>
> ----------------------------------------
> Invitation letter
> If you need an invitation letter, please send the following info
> to Ms. Ziye Li: .
> Surname:
> Given Name:
> Company:
> Address:
> Phone:
> Passport Number:
> Passport Exp. Date:
> Passport Issuing Country:
>
>
>
> -----------------------------------------
>
> Further contact information
> Please contact Ms. Ziye Li if you have any question about
> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
> 
>
>
> -- Alain, Yong
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

From simon.perreault@viagenie.ca  Mon Aug 22 04:25:40 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443CD21F8853 for ; Mon, 22 Aug 2011 04:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzltuZHfAoWh for ; Mon, 22 Aug 2011 04:25:39 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B074421F8782 for ; Mon, 22 Aug 2011 04:25:39 -0700 (PDT)
Received: from banana.viagenie.ca (unknown [75.98.19.132]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 22E6320D35 for ; Mon, 22 Aug 2011 07:26:44 -0400 (EDT)
Message-ID: <4E523CF2.80407@viagenie.ca>
Date: Mon, 22 Aug 2011 07:26:42 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <9CED3349-22B8-49EC-B72C-77CD52D52427@townsley.net>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 11:25:40 -0000

Mark Townsley wrote, on 08/21/2011 10:19 AM:
> It takes me about 30 seconds to describe at a high-level what 4rd is to someone
> who already understands ds-lite by referring to it as "a stateless version of
> ds-lite". That's a good thing. 

To someone who already understands 6rd:

"4rd is to IPv4 what 6rd is to IPv6."

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From nejc@skoberne.net  Mon Aug 22 06:03:59 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5670E21F8B59 for ; Mon, 22 Aug 2011 06:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level: 
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxsIMF3HmPfD for ; Mon, 22 Aug 2011 06:03:58 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id A824921F8B57 for ; Mon, 22 Aug 2011 06:03:58 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 25FA422781BA; Mon, 22 Aug 2011 15:04:58 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzI3IDWe2UV1; Mon, 22 Aug 2011 15:04:57 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 9727D2278182; Mon, 22 Aug 2011 15:04:57 +0200 (CEST)
Message-ID: <4E5253F9.1000206@skoberne.net>
Date: Mon, 22 Aug 2011 14:04:57 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: draft-dec-stateless-4v6@tools.ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" 
Subject: [Softwires] Comments on draft-dec-stateless-4v6-02
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 13:03:59 -0000

Dear authors,

I have some comments on section 5.9 Securty and Port Randomization.

-------------------------------------------------------------------
   Assuming all other information has already been acquired, and also
   the presence of no exploits, the basic security of IP protocols lies
   in the computational cost of guessing a combination of a protocol
   field, eg a TCP sequence number or say a DNS transaction ID,
   multiplied by a the cost of a guess of a source port.  Thus, for a

   TCP brute force attack, the already substantial cost in guessing a
   sequence number (2^32 possibilities) is multiplied by the port range
   guess cost.  In this context a 1K port restricted 4V6 system, is
   costly enough for most practical purposes.  More discussion to
   improve the robustness of TCP against Blind In-Window Attacks can be
   found at [RFC5961].

[NS: The claim, that this is costly enough for most practical purposes,
is not true. This is also the motivation for RFC 5961, as I
understand it. The issue is, that it's not the 2^32 space we need to
search but rather 2^32/W, where W is the window size. And in practice,
W is 32-64k. Which is a huge reduction in complexity. If we know the 
source port, an attacker on a 100Mbit/s link can tear down a TCP session 
between another client and server (if server is at least 100Mbit/s as
well) in cca. 0.8 seconds (on average, see
RFC 5961 and "Slipping in the Window: TCP Reset attacks", Presentation
at 2004 CanSecWest). If we consider 10-bit port space (1024 ports per
customer), the average time increases to ~13.6 minutes, which is still
a very practicable attack for longer-lived-sessions. However, if we
have the whole 16-bit port range, the attack becomes considerably less
practicable (although still practicable with very long-lived sessions),
the average time is 14.5 hours. But that's an amount of time, where
other measures would possibly be triggered in case something strange
is going on.]

   For a UDP/DNS brute force attack, the computational cost required to
   scan/generate the full range of 2^32 possibilities, corresponding to
   a port unrestricted system is relatively low/easy - today's GPUs can
   do so in a few seconds.

[NS: I am not sure I understand the role of GPUs in sending guessing
packets?]

   Beyond the above, in terms of the avoiding a fixed linear or single
   port range allocations, extensions to the 4V6 solution provides
   additional remedy, eg [I-D.bajko-pripaddrassign].

[NS: I-D.bajko-pripaddrassign is expired and AFAIK it defines a DHCPv4
option to signal the port range/mask and a key to the client host/CPE.
I guess this is pretty useless in stateless solutions, where we don't
want to have such signaling. Also, you mention "4V6 solution". How do
you define this term?]
-------------------------------------------------------------------

Regards,
Nejc

From nejc@skoberne.net  Mon Aug 22 07:37:25 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B1121F8B29 for ; Mon, 22 Aug 2011 07:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level: 
X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wHHmM87nUxH for ; Mon, 22 Aug 2011 07:37:25 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEB821F8B10 for ; Mon, 22 Aug 2011 07:37:25 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id B211C227875B; Mon, 22 Aug 2011 16:38:29 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71prvMXtpJBq; Mon, 22 Aug 2011 16:38:29 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 1E1F722788DE; Mon, 22 Aug 2011 16:22:09 +0200 (CEST)
Message-ID: <4E526610.7020208@skoberne.net>
Date: Mon, 22 Aug 2011 15:22:08 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Brian E Carpenter 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com>
In-Reply-To: <4E4F34E1.3040305@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 14:37:25 -0000

Dear Brian,

> Ahah, you seem to assume that A+P will solve the ISP's shortage
> of IPv4 addresses. That may be true for a year or three, but
> after that they will discover that they have to CGN their A+P
> customers, and then you have NAT444 after all, IMHO.

I don't assume A+P an ultimate solution for IPv4 address sharing.
I just think that certain ISPs will (be able) to use it. After all,
considering 1024 ports per user, this means 1:64 sharing ratio,
which is a lot compared to 1 IP per customer. If we forget about
Internet of things, which will not be based on IPv4 anyway, I don't
know many ISPs who could make their user base 64 times the size
it is now. Of course, some will do, but they can then use dynamic
port allocation.

Also, even the userbase for an ISP gets this big, there is still
no need for NAT444 in long term with careful planning. A CPE can
support DS-Lite as well as stateless A+P mechanisms at the same
time. It's not that complex to do this. And if it turns out A+P
is not an option (any more), customer-by-customer migration to
DS-Lite could be considered.

Nejc

From gjshep@gmail.com  Mon Aug 22 07:55:52 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B422D21F8B3A; Mon, 22 Aug 2011 07:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.524
X-Spam-Level: 
X-Spam-Status: No, score=-105.524 tagged_above=-999 required=5 tests=[AWL=2.075, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2,  RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSPrsQkg-2zi; Mon, 22 Aug 2011 07:55:51 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC10E21F8B37; Mon, 22 Aug 2011 07:55:50 -0700 (PDT)
Received: by bkar4 with SMTP id r4so4558368bka.31 for ; Mon, 22 Aug 2011 07:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Xy/LIc0JPEcJ3DaiYRuJmMCDQruOosH8tdkFmNvncwE=; b=tCzvoePiD/DUbunJAxKxE2dv1RA97MgNjY4jV3E7eN3R6w+YTBDY4ljsJk/xM+jOt/ c8F0Oa9RCMBv9VvwYiOSY1LjOXRpILg37O2Wq7xtGKiZ22fY85gkag9YBN+N8UDQnwpF 7sMX4Ai44nxsZUBfQdqHkgQrkGc01L6Mn9vIU=
MIME-Version: 1.0
Received: by 10.204.157.1 with SMTP id z1mr969784bkw.277.1314025013689; Mon, 22 Aug 2011 07:56:53 -0700 (PDT)
Received: by 10.204.135.142 with HTTP; Mon, 22 Aug 2011 07:56:53 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 22 Aug 2011 07:56:53 -0700
Message-ID: 
From: Greg Shepherd 
To: GangChen 
Content-Type: text/plain; charset=ISO-8859-1
Cc: softwires@ietf.org, liziye , Yong Cui , iesg-secretary@ietf.org, "Ralph Droms \(rdroms\)" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gjshep@gmail.com
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 14:55:52 -0000

Are there any plans to discuss solutions for multicast at the interim meeting?

Thanks,
Greg

On Mon, Aug 22, 2011 at 3:57 AM, GangChen  wrote:
> Dear Chairs,
>
> I suggest including draft-murakami-softwire-4v6-translation-00 into
> the agenda as well.
> We already had a presentation in last softwire meeting. It's
> reasonable to continue the discussion in the interim meeting
>
> Many thanks
>
> Gang
>
> 2011/8/19, Yong Cui :
>> Hi folks,
>>
>> We, softwire wg chairs, in agreement with our ADs, are announcing
>> an interim meeting in Beijing on September 26 & 27. The date has
>> been chosen adjacent to the BBF meeting in Shangai to minimize
>> travel and visa issues.
>>
>> The interim meeting will focus on 'stateless' solutions in general
>> and 4rd in particular. Expected outcome includes progress on 4rd
>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>> option, tunneling vs translation, coexistence with other
>> technologies, etc...
>>
>> ---------------------------------------
>> Meeting Location & recommended hotels
>> Meeting venue: FIT Building, Tsinghua University, Beijing
>> FIT Building is the first left building inside of the East Gate
>> of Tsinghua Univeristy
>> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
>> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
>>
>> Recommended hotels:
>> 1. Uniscenter (4 stars, 3 min walk)
>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>
>> 2. Wenjin Hotel (5 stars, 10 min walk)
>> http://www.wenjin.com.cn/
>>
>> 3. Royal King Hotel (5 stars, 10 min by car)
>> http://www.royalkinghotel.com/
>>
>> ----------------------------------------
>> Invitation letter
>> If you need an invitation letter, please send the following info
>> to Ms. Ziye Li: .
>> Surname:
>> Given Name:
>> Company:
>> Address:
>> Phone:
>> Passport Number:
>> Passport Exp. Date:
>> Passport Issuing Country:
>>
>>
>>
>> -----------------------------------------
>>
>> Further contact information
>> Please contact Ms. Ziye Li if you have any question about
>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>> 
>>
>>
>> -- Alain, Yong
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

From adurand@juniper.net  Mon Aug 22 08:36:46 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C89521F8B73 for ; Mon, 22 Aug 2011 08:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.525
X-Spam-Level: 
X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1+l5BN-w9aa for ; Mon, 22 Aug 2011 08:36:46 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 31EEA21F8B74 for ; Mon, 22 Aug 2011 08:36:44 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTlJ3zBBoHbftrcWTieAhMyyfXo1Pss4a@postini.com; Mon, 22 Aug 2011 08:37:51 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 22 Aug 2011 08:37:20 -0700
From: Alain Durand 
To: "softwires@ietf.org" , Yong Cui 
Date: Mon, 22 Aug 2011 08:37:18 -0700
Thread-Topic: Call for presentations for the interim meeting
Thread-Index: Acxg4WCwq1+HJMYYQa2pkv5CahY9GA==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 15:36:46 -0000

As we mentioned earlier, the softwire interim meeting will focus on 'statel=
ess solutions'. If you'd like to present there, please send the chairs a no=
te by Friday this week.

Alain.=

From adurand@juniper.net  Mon Aug 22 08:40:22 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878B521F8742; Mon, 22 Aug 2011 08:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.528
X-Spam-Level: 
X-Spam-Status: No, score=-108.528 tagged_above=-999 required=5 tests=[AWL=2.071, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2,  RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAsIjITkRj5x; Mon, 22 Aug 2011 08:40:21 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0543F21F8B72; Mon, 22 Aug 2011 08:39:38 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTlJ4ejUOPpcN3H0h+lxwzgZuQq6NLbav@postini.com; Mon, 22 Aug 2011 08:41:27 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 22 Aug 2011 08:40:18 -0700
From: Alain Durand 
To: "gjshep@gmail.com" 
Date: Mon, 22 Aug 2011 08:40:16 -0700
Thread-Topic: [Softwires] Softwire Interim Meeting in Beijing
Thread-Index: Acxg4cs62e/8folfQzCH0H+I4A/knw==
Message-ID: <7211CD03-56D2-4EBF-BF59-FDBE490C0728@juniper.net>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: liziye , "Ralph Droms \(rdroms\)" , Yong Cui , "iesg-secretary@ietf.org" , "softwires@ietf.org" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 15:40:22 -0000

So far, I'd like the focus to be on stateless. We will see by the end of th=
e week (end of the call for presentation) if we have time for multicast.

Alain.

Sent from my iPad

On Aug 22, 2011, at 10:57 AM, "Greg Shepherd"  wrote:

> Are there any plans to discuss solutions for multicast at the interim mee=
ting?
>=20
> Thanks,
> Greg
>=20
> On Mon, Aug 22, 2011 at 3:57 AM, GangChen  wrote:
>> Dear Chairs,
>>=20
>> I suggest including draft-murakami-softwire-4v6-translation-00 into
>> the agenda as well.
>> We already had a presentation in last softwire meeting. It's
>> reasonable to continue the discussion in the interim meeting
>>=20
>> Many thanks
>>=20
>> Gang
>>=20
>> 2011/8/19, Yong Cui :
>>> Hi folks,
>>>=20
>>> We, softwire wg chairs, in agreement with our ADs, are announcing
>>> an interim meeting in Beijing on September 26 & 27. The date has
>>> been chosen adjacent to the BBF meeting in Shangai to minimize
>>> travel and visa issues.
>>>=20
>>> The interim meeting will focus on 'stateless' solutions in general
>>> and 4rd in particular. Expected outcome includes progress on 4rd
>>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>>> option, tunneling vs translation, coexistence with other
>>> technologies, etc...
>>>=20
>>> ---------------------------------------
>>> Meeting Location & recommended hotels
>>> Meeting venue: FIT Building, Tsinghua University, Beijing
>>> FIT Building is the first left building inside of the East Gate
>>> of Tsinghua Univeristy
>>> http://maps.google.com/maps/ms?msid=3D202779846620144871057.0004aad8ce3=
67b982
>>> 9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798
>>>=20
>>> Recommended hotels:
>>> 1. Uniscenter (4 stars, 3 min walk)
>>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>>=20
>>> 2. Wenjin Hotel (5 stars, 10 min walk)
>>> http://www.wenjin.com.cn/
>>>=20
>>> 3. Royal King Hotel (5 stars, 10 min by car)
>>> http://www.royalkinghotel.com/
>>>=20
>>> ----------------------------------------
>>> Invitation letter
>>> If you need an invitation letter, please send the following info
>>> to Ms. Ziye Li: .
>>> Surname:
>>> Given Name:
>>> Company:
>>> Address:
>>> Phone:
>>> Passport Number:
>>> Passport Exp. Date:
>>> Passport Issuing Country:
>>>=20
>>>=20
>>>=20
>>> -----------------------------------------
>>>=20
>>> Further contact information
>>> Please contact Ms. Ziye Li if you have any question about
>>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>>> 
>>>=20
>>>=20
>>> -- Alain, Yong
>>>=20
>>>=20
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>=20
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From nejc@skoberne.net  Mon Aug 22 09:18:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFE521F8AED for ; Mon, 22 Aug 2011 09:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level: 
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhcE3MjBiTqK for ; Mon, 22 Aug 2011 09:18:44 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id C5DA521F8A62 for ; Mon, 22 Aug 2011 09:18:43 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 232E7227876E; Mon, 22 Aug 2011 18:19:48 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcJqw3qnoQqt; Mon, 22 Aug 2011 18:19:47 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 53E71227876B; Mon, 22 Aug 2011 18:19:47 +0200 (CEST)
Message-ID: <4E5281A2.5090801@skoberne.net>
Date: Mon, 22 Aug 2011 17:19:46 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Mark Townsley 
References: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> <210E3894-0407-4964-B056-89DC3B502891@gmail.com> <8589DBE2-73F7-47FA-ABBB-4517061F2A11@laposte.net>   <103C6AB4-B9DB-4E0A-8799-D9F601B682F1@townsley.net> <77A38FA6-24D2-4676-98B9-134B4A096A9B@laposte.net> <4E4EF9FC.8020407@skoberne.net>   
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd mapping rule separation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 16:18:44 -0000

Dear Mark,

>>>>> Because of what RFC6333 says, suggesting NOW that solutions that 
>>>>> don't need NATs are variants of DS-lite is a sure way to confuse 
>>>>> people.
>>>
>>> Then we're already confused:
>>>
>>> http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
>>
>> Could you explain more which confusion you are referring to?
> 
> Nejc suggested that DS-Lite without NATs (which I assumed meant without 
> a CGN NAT, aka AFTR) would be confusing at this stage.
> 
> The title of the referenced document is "Procedure to bypass DS-Lite AFTR"

For the record, it was Remi who suggested that, I just +1-ed it.

I don't think that the referenced draft really causes confusion, since it 
clearly states what is the "nominal behavior" of DS-Lite: using NAT44 in
the AFTR.

That said, I would be happy too if we could just make two big groups of
all these mechanisms, like "stateful" and "stateless" DS-Lite. However, I
think that is easier said than done. What about stateful A+P solutions like
draft-cui-softwire-b4-translated-ds-lite-01? Is this then stateful or 
stateless DS-Lite?
Compared to 4rd or dIVI, this one has customer-state in the core and if we
consider static port allocation in CGN with DS-Lite, we end up with RFC6333
and draft-cui-softwire-b4-translated-ds-lite-01 very similar amount
of state for both mechanisms. Just the location of the NAPT44 is different.

Nejc

From nejc@skoberne.net  Mon Aug 22 09:24:25 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB9921F8B4C for ; Mon, 22 Aug 2011 09:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level: 
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqhHYmxAD3fg for ; Mon, 22 Aug 2011 09:24:22 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 97BDF21F8B2D for ; Mon, 22 Aug 2011 09:24:21 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 2DD27227876F; Mon, 22 Aug 2011 18:25:26 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQGMERox8qbo; Mon, 22 Aug 2011 18:25:26 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id A6154227876E; Mon, 22 Aug 2011 18:25:25 +0200 (CEST)
Message-ID: <4E5282F5.6080804@skoberne.net>
Date: Mon, 22 Aug 2011 17:25:25 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Cameron Byrne 
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 16:24:25 -0000

Dear Cameron,

> some pressure.  IMHO, i believe that static over-subscription ratios
> required by A+P will not meaningfully keep pace with the rapid growth
> in the number of internet nodes.

I would be very happy if you elaborated on this. Can you give something
to support this belief?

Thanks,
Nejc

From nejc@skoberne.net  Mon Aug 22 09:30:50 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAEC21F8B85 for ; Mon, 22 Aug 2011 09:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level: 
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUsy2I6xw-m1 for ; Mon, 22 Aug 2011 09:30:50 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 668EA21F8B83 for ; Mon, 22 Aug 2011 09:30:50 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 0FE492278770; Mon, 22 Aug 2011 18:31:55 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1pD47hoHLGy; Mon, 22 Aug 2011 18:31:54 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 92B552278771; Mon, 22 Aug 2011 18:31:53 +0200 (CEST)
Message-ID: <4E528479.1070804@skoberne.net>
Date: Mon, 22 Aug 2011 17:31:53 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Brian E Carpenter 
References: <4E4B96CB.2020004@skoberne.net>	 <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net> <4E503B08.9030800@gmail.com>
In-Reply-To: <4E503B08.9030800@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 16:30:51 -0000

> Sure. The question is really whether its "market share" would be
> enough to justify the effort.

But how can you know what the "market share" is? I mean, it's a 
trade-off between having a smaller sharing ratio and having better
end-to-end (perhaps), direct CPE-CPE communication ... I say let's
give ISPs more solutions to avail, so they can adopt the solution
that suits their needs.

> If an average IPv4 user is consuming 200 ports (or whatever
> value you prefer to assume) with their favourite p2p app, that
> is what sets the number of IPv4 users per shared address. It's
> the number of simultaneous ports, not the amount of traffic,
> that counts.

There was a thread on this list recently, which discussed a research
on port reusage by applications:

|>  For example, BitTorrent established five hundreds of sessions while
|> the port consumption  was under a hundred in the first minute of the
|> communication, because when BitTorrent initiates a downloading, it
|> first uses the same source port to connect to the different
|> destinations (destination IP and port) therefore one source port
|> multiplexing different sessions. Skype is  another example that uses
|> one source port to  multiplex different sessions thereby
|saving source
|> port consumptions on NAT.

So I guess we have some reserves here as well.

Nejc

From gjshep@gmail.com  Mon Aug 22 09:54:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A953021F8C11; Mon, 22 Aug 2011 09:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.731
X-Spam-Level: 
X-Spam-Status: No, score=-105.731 tagged_above=-999 required=5 tests=[AWL=1.868, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2,  RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQMwK5GuXkiy; Mon, 22 Aug 2011 09:54:54 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08FA421F8C07; Mon, 22 Aug 2011 09:54:53 -0700 (PDT)
Received: by bkar4 with SMTP id r4so4651820bka.31 for ; Mon, 22 Aug 2011 09:55:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zauHyW/xn8Ei6jAvb8gXAkxFMj/HslwKuacz7slx39E=; b=upTpEkWeBLYn6Xj1LCZK9jm5gumUUL+OU4TMSA7gXXbG2dZa8E+grBN5boKF4K7vvj wBrAlwNWbhcVt7mtpMoGlk77zLi/i5wuCiK+rWRaUY3xk4ZwF2yWAjNz0Y3n8GuR90IB cAnhsAk2ItELvQpgx7OPJL2E0Ttp3mwaNKSdE=
MIME-Version: 1.0
Received: by 10.204.132.68 with SMTP id a4mr984578bkt.154.1314032128535; Mon, 22 Aug 2011 09:55:28 -0700 (PDT)
Received: by 10.204.135.142 with HTTP; Mon, 22 Aug 2011 09:55:28 -0700 (PDT)
In-Reply-To: <7211CD03-56D2-4EBF-BF59-FDBE490C0728@juniper.net>
References:    <7211CD03-56D2-4EBF-BF59-FDBE490C0728@juniper.net>
Date: Mon, 22 Aug 2011 09:55:28 -0700
Message-ID: 
From: Greg Shepherd 
To: Alain Durand 
Content-Type: text/plain; charset=ISO-8859-1
Cc: liziye , "Ralph Droms \(rdroms\)" , Yong Cui , "iesg-secretary@ietf.org" , "softwires@ietf.org" 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gjshep@gmail.com
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 16:54:55 -0000

Thanks. I won't add to the agenda. The first pass had mcast on the
list so I carved out time to be there. If it comes up I will attend.
Or I suppose more to the point, if you don't want me there keep mcast
off of the agenda. :)

Cheers,
Greg

On Mon, Aug 22, 2011 at 8:40 AM, Alain Durand  wrote:
> So far, I'd like the focus to be on stateless. We will see by the end of the week (end of the call for presentation) if we have time for multicast.
>
> Alain.
>
> Sent from my iPad
>
> On Aug 22, 2011, at 10:57 AM, "Greg Shepherd"  wrote:
>
>> Are there any plans to discuss solutions for multicast at the interim meeting?
>>
>> Thanks,
>> Greg
>>
>> On Mon, Aug 22, 2011 at 3:57 AM, GangChen  wrote:
>>> Dear Chairs,
>>>
>>> I suggest including draft-murakami-softwire-4v6-translation-00 into
>>> the agenda as well.
>>> We already had a presentation in last softwire meeting. It's
>>> reasonable to continue the discussion in the interim meeting
>>>
>>> Many thanks
>>>
>>> Gang
>>>
>>> 2011/8/19, Yong Cui :
>>>> Hi folks,
>>>>
>>>> We, softwire wg chairs, in agreement with our ADs, are announcing
>>>> an interim meeting in Beijing on September 26 & 27. The date has
>>>> been chosen adjacent to the BBF meeting in Shangai to minimize
>>>> travel and visa issues.
>>>>
>>>> The interim meeting will focus on 'stateless' solutions in general
>>>> and 4rd in particular. Expected outcome includes progress on 4rd
>>>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>>>> option, tunneling vs translation, coexistence with other
>>>> technologies, etc...
>>>>
>>>> ---------------------------------------
>>>> Meeting Location & recommended hotels
>>>> Meeting venue: FIT Building, Tsinghua University, Beijing
>>>> FIT Building is the first left building inside of the East Gate
>>>> of Tsinghua Univeristy
>>>> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
>>>> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
>>>>
>>>> Recommended hotels:
>>>> 1. Uniscenter (4 stars, 3 min walk)
>>>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>>>
>>>> 2. Wenjin Hotel (5 stars, 10 min walk)
>>>> http://www.wenjin.com.cn/
>>>>
>>>> 3. Royal King Hotel (5 stars, 10 min by car)
>>>> http://www.royalkinghotel.com/
>>>>
>>>> ----------------------------------------
>>>> Invitation letter
>>>> If you need an invitation letter, please send the following info
>>>> to Ms. Ziye Li: .
>>>> Surname:
>>>> Given Name:
>>>> Company:
>>>> Address:
>>>> Phone:
>>>> Passport Number:
>>>> Passport Exp. Date:
>>>> Passport Issuing Country:
>>>>
>>>>
>>>>
>>>> -----------------------------------------
>>>>
>>>> Further contact information
>>>> Please contact Ms. Ziye Li if you have any question about
>>>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>>>> 
>>>>
>>>>
>>>> -- Alain, Yong
>>>>
>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>

From cb.list6@gmail.com  Mon Aug 22 10:40:50 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4E21F8BB3 for ; Mon, 22 Aug 2011 10:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.295
X-Spam-Level: 
X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVRR+x-Pg70w for ; Mon, 22 Aug 2011 10:40:49 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 22D7021F8BAB for ; Mon, 22 Aug 2011 10:40:48 -0700 (PDT)
Received: by wwe5 with SMTP id 5so2374850wwe.1 for ; Mon, 22 Aug 2011 10:41:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Rqt7QhIRUx8jm9+tfySsBOINexd9gVaz3OAeHEvcxi8=; b=ZNqkIs5hz/je6Po+7ICgwc/GGUx2vTaXpufdFCWIR2SMbvqWv0lA0GWBJMu4IOCcIg Fy3kP8A/rB79hNN0l1NK1smsGWCULNvdAkmvoJmL4ipxxKJymQh6GeMONz8ITGdwJwWR eWF6SMYKMh9UHXRfQFuRrPaqHCcmfNe05lti4=
MIME-Version: 1.0
Received: by 10.216.82.211 with SMTP id o61mr417536wee.65.1314034913966; Mon, 22 Aug 2011 10:41:53 -0700 (PDT)
Received: by 10.216.155.199 with HTTP; Mon, 22 Aug 2011 10:41:53 -0700 (PDT)
In-Reply-To: <4E5282F5.6080804@skoberne.net>
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com>  <4E5282F5.6080804@skoberne.net>
Date: Mon, 22 Aug 2011 10:41:53 -0700
Message-ID: 
From: Cameron Byrne 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2011 17:40:50 -0000

2011/8/22 Nejc =C5=A0koberne :
> Dear Cameron,
>
>> some pressure. =C2=A0IMHO, i believe that static over-subscription ratio=
s
>> required by A+P will not meaningfully keep pace with the rapid growth
>> in the number of internet nodes.
>
> I would be very happy if you elaborated on this. Can you give something
> to support this belief?
>

Easy math version assuming the entire internet moves to this model of
stateless address sharing:

50 Billion Internet nodes [1]

240 Million  IPv4 addresses [2]

208.3 devices per IPv4 address -- by dividing the above numbers

312.5 ports per user -- by dividing by 65k ports

Not a perfect guesstimate on several levels since the "internet" is
not uniform and does move to anything in a uniform, the numbers used
above are suspect, and this is not an internet wide solution, some
nodes may go IPv6 only, and so on ... but sometimes looking at numbers
like this in the macroscopic view helps us understand our little part
of the internet that we are trying to design a solution for.

As stated, some providers may find a benefit here... I believe that is
clear.  My understanding is that in North America many of the
incumbent land line providers have fairly static subscriber bases, not
a lot of growth in users demanding IPv4.  In my world (mobile), AFAIK
approximately half of the service providers globally already do NAT44
/ LSN / CGN.

Areas of the internet that are experiencing or anticipate rapid growth
(mobile, cloud, new ventures) in address consumption will likely not
extend their existing addresses far with a stateless solution.

Regards,
Cameron

[1] http://www.ericsson.com/thecompany/press/releases/2010/04/1403231
[2] http://tools.ietf.org/html/rfc3194


> Thanks,
> Nejc
>

From eleven.fuyu@huawei.com  Mon Aug 22 18:11:33 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA25E21F8AF3 for ; Mon, 22 Aug 2011 18:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.72
X-Spam-Level: 
X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[AWL=3.879,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWtJWlK3t8P7 for ; Mon, 22 Aug 2011 18:11:30 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B0CB821F8AE1 for ; Mon, 22 Aug 2011 18:11:29 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQC007I0WOXGM@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 23 Aug 2011 09:12:33 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQC008JRWOV3J@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 23 Aug 2011 09:12:33 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADI23194; Tue, 23 Aug 2011 09:12:32 +0800 (CST)
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 23 Aug 2011 09:12:29 +0800
Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.204]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Tue, 23 Aug 2011 09:12:32 +0800
Date: Tue, 23 Aug 2011 01:12:31 +0000
From: "Eleven Fu(Yu)" 
In-reply-to: <7211CD03-56D2-4EBF-BF59-FDBE490C0728@juniper.net>
X-Originating-IP: [10.110.98.137]
To: Alain Durand 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=Windows-1252
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [Softwires] Softwire Interim Meeting in Beijing
Thread-index: AQHMXmlUlY52j/cdf0SnSnlY94lmU5UoMasAgABC24CAAAwfAIABIIUQ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    <7211CD03-56D2-4EBF-BF59-FDBE490C0728@juniper.net>
Cc: "softwires@ietf.org" , Yong Cui 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 01:11:33 -0000

Dear Chairs:

    Are there any plans to discuss the MIBs at the interim meeting? According to our softwire WG milestones, our MIBs also need more discussions.

Best Regards
Yu


-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Alain Durand
Sent: Monday, August 22, 2011 11:40 PM
To: gjshep@gmail.com
Cc: liziye; Ralph Droms (rdroms); Yong Cui; iesg-secretary@ietf.org; softwires@ietf.org
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing

So far, I'd like the focus to be on stateless. We will see by the end of the week (end of the call for presentation) if we have time for multicast.

Alain.

Sent from my iPad

On Aug 22, 2011, at 10:57 AM, "Greg Shepherd"  wrote:

> Are there any plans to discuss solutions for multicast at the interim meeting?
> 
> Thanks,
> Greg
> 
> On Mon, Aug 22, 2011 at 3:57 AM, GangChen  wrote:
>> Dear Chairs,
>> 
>> I suggest including draft-murakami-softwire-4v6-translation-00 into
>> the agenda as well.
>> We already had a presentation in last softwire meeting. It's
>> reasonable to continue the discussion in the interim meeting
>> 
>> Many thanks
>> 
>> Gang
>> 
>> 2011/8/19, Yong Cui :
>>> Hi folks,
>>> 
>>> We, softwire wg chairs, in agreement with our ADs, are announcing
>>> an interim meeting in Beijing on September 26 & 27. The date has
>>> been chosen adjacent to the BBF meeting in Shangai to minimize
>>> travel and visa issues.
>>> 
>>> The interim meeting will focus on 'stateless' solutions in general
>>> and 4rd in particular. Expected outcome includes progress on 4rd
>>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>>> option, tunneling vs translation, coexistence with other
>>> technologies, etc...
>>> 
>>> ---------------------------------------
>>> Meeting Location & recommended hotels
>>> Meeting venue: FIT Building, Tsinghua University, Beijing
>>> FIT Building is the first left building inside of the East Gate
>>> of Tsinghua Univeristy
>>> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
>>> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
>>> 
>>> Recommended hotels:
>>> 1. Uniscenter (4 stars, 3 min walk)
>>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>> 
>>> 2. Wenjin Hotel (5 stars, 10 min walk)
>>> http://www.wenjin.com.cn/
>>> 
>>> 3. Royal King Hotel (5 stars, 10 min by car)
>>> http://www.royalkinghotel.com/
>>> 
>>> ----------------------------------------
>>> Invitation letter
>>> If you need an invitation letter, please send the following info
>>> to Ms. Ziye Li: .
>>> Surname:
>>> Given Name:
>>> Company:
>>> Address:
>>> Phone:
>>> Passport Number:
>>> Passport Exp. Date:
>>> Passport Issuing Country:
>>> 
>>> 
>>> 
>>> -----------------------------------------
>>> 
>>> Further contact information
>>> Please contact Ms. Ziye Li if you have any question about
>>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>>> 
>>> 
>>> 
>>> -- Alain, Yong
>>> 
>>> 
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

From Tina.Tsou.Zouting@huawei.com  Mon Aug 22 18:57:27 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F721F8AF8 for ; Mon, 22 Aug 2011 18:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.805
X-Spam-Level: 
X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.194,  BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXLa82WqhBoZ for ; Mon, 22 Aug 2011 18:57:27 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id EC65321F8AFE for ; Mon, 22 Aug 2011 18:57:26 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQC00DR4YTJKR@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 23 Aug 2011 09:58:31 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQC00LY1YT09V@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 23 Aug 2011 09:58:31 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADI27932; Tue, 23 Aug 2011 09:58:30 +0800 (CST)
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 23 Aug 2011 09:58:28 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Tue, 23 Aug 2011 09:58:15 +0800
Date: Tue, 23 Aug 2011 01:58:14 +0000
From: Tina TSOU 
X-Originating-IP: [10.193.34.145]
To: "softwires@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: Comments on draft-qin-softwire-dslite-multicast-04
Thread-index: AQHMYTdUSUw9NjVHm0mqk4ZZAfKXSpUprIKg
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 01:57:28 -0000

Hi all,
In IETF-81, the chairs asked the authors of different drafts on multicast sit together to discuss and compromise. So we did.

Here are some comments on draft-qin-softwire-dslite-multicast-04.

Overall: if this is to be a Standards Track document, the whole document 
has to be reviewed, the normative parts identified, and requirements 
language substituted for the current descriptive language.

Section 1:

Editorial: at the end of the second paragraph, "vastly consumed" reads 
better in English as: "consumed in vast quantities".

Substantive: add the following to the sentence making up the third 
paragraph:

"..., which prevents these consequences by making use of the native 
multicast capabilities of the intervening IPv6 network."

Section 2:

Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply 
aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)".

Substantive(?): In the description of the Multicast B4, it would make 
more sense to change "... which is able to enforce ..." to "... which 
implements ...".

Section 3.2:

Bullet 1: the second sentence jams two unrelated ideas together. It 
needs a little expansion to read properly. The next sentence doesn't 
make sense within the stated scope of the bullet and shouldn't be there. 
The suggested changed text is thus:

   "A viable scenario for this use case in DS-Lite environment: customers
    with legacy receivers must continue to access the IPv4-enabled
    multicast services.  This means the traffic should be accessed
    through IPv4 and additional functions are needed to traverse the
    operator's IPv6- enabled network. It is the purpose of this
    document to describe those functions.  Refer to [I-D.jaclee-behave-
    v4v6-mcast-ps] for the deployment considerations."

Final paragraph: don't you need a final sentence saying something like: 
"Depending on the specific details of the contract, this may mean that 
the specific framing of the content packets (as IPv4 packets) must be 
preserved along with the content within that framing."

Section 4:

First paragraph: the following sentences need to be added after the 
first one to give a full picture of what is required for a solution:

"For multicast, in contrast, separate mechanisms are required to process 
the outgoing multicast signalling packets and the incoming packets of 
content. The multicast signalling needs to be interworked to IPv6 and 
processed as IPv6 signalling. For incoming multicast content, this 
document defines ..."

Middle paragraph: why doesn't it simply read:

"See Section 4.3 for multicast distribution tree establishment and 
Section 4.4 for multicast traffic forwarding."

Section 4.2

Third paragraph typo: mPrefixe64 -> mPrefix64

Section 4.3

Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That 
would cause the native IPv6 multicast infrastructure to be bypassed. It 
is also inconsistent with the architectural figure. Delete the first 
bullet and merge the second one with the next paragraph, like this:

"The mAFTR should process the received PIMv6 Join message for the 
IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join 
message. It creates an entry for the IPv6 multicast group address in its 
multicast Routing Information Base. This entry is used to forward ..."

Section 4.5

It is not clear whether the final paragraph is talking about the mB4+B4 
or the mAFTR+AFTR or both. In fact, it makes good sense to combine the 
mB4 and the B4, but combining the AFTR and mAFTR would be questionable 
for reasons of scalability. There may be routing issues to sort out 
regarding reachability of the IPv4 prefix that is shared by the source 
-- the multicast routers should choose the path leading through the 
mAFTR rather than the one going through the AFTR.

No more comments up to section 7. Maybe more comments from section 7 
onwards in a separate E-mail.

Regards,
Tina

From nejc@skoberne.net  Tue Aug 23 02:14:56 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709D821F8AED for ; Tue, 23 Aug 2011 02:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.232
X-Spam-Level: 
X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJfktYzYbv+a for ; Tue, 23 Aug 2011 02:14:55 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 706C321F84DF for ; Tue, 23 Aug 2011 02:14:55 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 47B442278791; Tue, 23 Aug 2011 11:15:56 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFmKa9wowqOA; Tue, 23 Aug 2011 11:15:53 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 94BA72278790; Tue, 23 Aug 2011 11:15:53 +0200 (CEST)
Message-ID: <4E536FCA.80403@skoberne.net>
Date: Tue, 23 Aug 2011 10:15:54 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Cameron Byrne 
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com>  <4E5282F5.6080804@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 09:14:56 -0000

Dear Cameron,

Thanks for your effort.

> Easy math version assuming the entire internet moves to this model of
> stateless address sharing:
> 
> 50 Billion Internet nodes [1]

As I said, I don't think we should consider "Internet of things" in this
aspect. Quoting the paper:

"As an example of connected devices, Vestberg was joined on stage by 
Peter HĂĄkansson, research engineer, who showed real life mobile health 
applications. HĂĄkansson showed how heart monitoring can be done remotely 
over the mobile networks and explained the benefits for both patients 
and society."

For these new applications, I don't see why they couldn't be deployed
natively over IPv6. So I think this number is way, way too big.

> As stated, some providers may find a benefit here... I believe that is
> clear.  My understanding is that in North America many of the
> incumbent land line providers have fairly static subscriber bases, not
> a lot of growth in users demanding IPv4.  In my world (mobile), AFAIK
> approximately half of the service providers globally already do NAT44
> / LSN / CGN.

Well, as I understand, these (static port allocation) solutions are
predominantly envisioned for resident users and SoHo environments. At
least for mobile environments, I've heard that it is 3GPP's decision
to avoid all host-based transition solutions except dual-stack.

> Areas of the internet that are experiencing or anticipate rapid growth
> (mobile, cloud, new ventures) in address consumption will likely not
> extend their existing addresses far with a stateless solution.

Well, that's why we have dynamic port allocation solutions ready for them.

====

Let me put it again, so it is clear what I wanted to say initially:

I think that draft-murakami-softwire-4v6-translation SHOULD _allow_ for
NAT-less implementations of the mechanism as well. As all other static
port allocation mechanism drafts do. That's all.

Thanks,
Nejc

From wdec.ietf@gmail.com  Tue Aug 23 04:04:31 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223A621F8ABE for ; Tue, 23 Aug 2011 04:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level: 
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cBYW1O5hArL for ; Tue, 23 Aug 2011 04:04:30 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8403A21F8A7B for ; Tue, 23 Aug 2011 04:04:30 -0700 (PDT)
Received: by yie12 with SMTP id 12so5166952yie.31 for ; Tue, 23 Aug 2011 04:05:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=trQrYO4cwYDlSiGYiYzVy33ON4fXr3ttJi1v4Em9JMc=; b=ZhdrD+vZkO18svbfkc9toHt/WN3nDWCGUAqQCN1qnYUa4VW9w1tbJKAC6YjMt5mG0q pCPBgkmfk3BiQ8HTXleC3t1ShRaSXLY5TOYhvTh78jsRIYfB6NFTII0+0TunS4XkM8RI nPuAUuUlu4AOiHQ7k55rDqk1+45WUK9yTRA2k=
MIME-Version: 1.0
Received: by 10.142.128.18 with SMTP id a18mr1809766wfd.257.1314097537689; Tue, 23 Aug 2011 04:05:37 -0700 (PDT)
Received: by 10.142.211.4 with HTTP; Tue, 23 Aug 2011 04:05:37 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 23 Aug 2011 13:05:37 +0200
Message-ID: 
From: Wojciech Dec 
To: Yong Cui 
Content-Type: multipart/alternative; boundary=000e0cd2dc2eef28d004ab2a2ce9
Cc: softwires@ietf.org
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 11:04:31 -0000

--000e0cd2dc2eef28d004ab2a2ce9
Content-Type: text/plain; charset=ISO-8859-1

+1 for Adopting 5.

On 20 August 2011 16:21, Yong Cui  wrote:

> Hi folks,
>
> Following our rough concensus during Quebec City meeting and
> according to our charter/milestones, the chairs would like to
> ask the mailing list for the confirmation to adopt the following
> drafts:
>
> 1. Deployment Considerations for Dual-Stack Lite
> http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
>
>
> 2. Public IPv4 over Access IPv6 Network
> http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
>
> 3. Softwire Mesh Multicast
> http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
>
> 4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
>
> 5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
> http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
> vation/
>
> Please send your comments by 10am EDT on Aug 27. If you object to
> adoption, please also give the detailed reasons.
>
>
>
> --Alain & Yong
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--000e0cd2dc2eef28d004ab2a2ce9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 for Adopting 5. 

On 20 August 2011 16:=
21, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:

Hi folks,



Following our rough concensus during Quebec City meeting and

according to our charter/milestones, the chairs would like to

ask the mailing list for the confirmation to adopt the following

drafts:



1. Deployment Considerations for Dual-Stack Lite

http://datatracker.ietf.org/doc/draft-lee-softwire=
-dslite-deployment/





2. Public IPv4 over Access IPv6 Network

http://datatracker.ietf.org/doc/draft-cui-softwire-host-=
4over6/



3. Softwire Mesh Multicast

http://datatracker.ietf.org/doc/draft-xu-softwire-mesh=
-multicast/



4. Multicast Extensions to DS-Lite Technique in Broadband Deployments

http://tools.ietf.org/html/draft-qin-softwire-dslite-=
multicast-04/



5. Motivations for Stateless IPv4 over IPv6 Migration Solutions

http://datatracker.ietf.org/doc/dr=
aft-operators-softwire-stateless-4v6-moti

vation/



Please send your comments by 10am EDT on Aug 27. If you object to

adoption, please also give the detailed reasons.







--Alain & Yong





_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--000e0cd2dc2eef28d004ab2a2ce9--

From nejc@skoberne.net  Tue Aug 23 05:59:42 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE56C21F8AD2 for ; Tue, 23 Aug 2011 05:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.224
X-Spam-Level: 
X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBR-78-H2Xhf for ; Tue, 23 Aug 2011 05:59:41 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8281B21F8AB8 for ; Tue, 23 Aug 2011 05:59:41 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 8260D2278765; Tue, 23 Aug 2011 15:00:42 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5MTL9YqkQ9s; Tue, 23 Aug 2011 15:00:40 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id AB58F2278759; Tue, 23 Aug 2011 15:00:39 +0200 (CEST)
Message-ID: <4E53A477.6060407@skoberne.net>
Date: Tue, 23 Aug 2011 14:00:39 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: draft-despres-softwire-4rd-addmapping@tools.ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , Olaf Maennel , "Raphael C.-W. Phan" , Iain Phillips 
Subject: [Softwires] draft-despres-softwire-4rd-addmapping
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 12:59:42 -0000

Dear authors,

I have some comments on your draft.

---------------------------------------------------------------------------
3.  Terminology



   4rd IID prefix:       A 32-bit value use to disambiguate what
                         concerns the 4rd address mapping from other
                         address mapping that may coexist it the same
                         AFTRs or CPEs, e.g. with dynamic port
                         assignments.

[NS: It would be nice if you defined what IID stands for. I guess it is
"Interface ID"?]



5.3.  Mapping from IPv4 address or A+P to IPv6 address


   For tunnel-based solutions (encapsulation or double-translation
   based),

[NS: I think we have a terminology problem here. I think double-translation
is not tunnel-based solution, since there is no encapsulation. See below
for further discussion on this.]


   proposed to IANA for the 4rd IID prefix is 200:5efe::/32.  It has bit
   6 of its first octet set to 1, in order to indicate a universal scope
   of the IID ("u" bit of).  Its other bits have, like in [RFC4214],
   IANA OUI in modified EUI format (ref.  [RFC4291]).

[NS: I guess there is a word missing in the parentheses ("u" bit of ??)?]



5.4.  Algorithmic Derivation of a Port Set from a Port-Set ID

   The port set specified by an

[NS: Unfinished sentence? As I can see, the port-set derivation algorithm
has changed. It would be nice to see the motivation why to use this particular
algorithm, so to maybe describe its properties and state why they are
important. For example, why do we need to reverse those bits in step [B](1)
in Figure 4? Also, it is not clear to me what is the "yyyy" part of the
pattern. Why is it separated from the x-es? Finally, it would be great to
show a short table of an example port-pairs obtained using this algorithm.]
---------------------------------------------------------------------------

Other than that, a few more general comments:

1. Terminology
--------------

I think there is confusion regarding to use of terms tunneling and
encapsulation. After some research, I would define the terms as follows:

- Encapsulation. A process of wrapping a packet in another header of the
  same or different network protocol. Decapsulation is therefore the process
  of stripping off the outmost header of the encapsulating packet, which
  brings us back to the encapsulated packet.

- Tunneling. A process of encapsulation, transmission and decapsulation
  of a packet.

So again, double-translation has nothing to do with tunneling. In spirit of
this, I would revise all occurencies of words "tunnel"/"tunneling" and
"encapsulation" in the draft.

2. Separating the mapping mechanism from the port-set calculation algorithm
---------------------------------------------------------------------------

I would say that the address mapping described in the draft is somewhat
orthogonal to the port-set calculation algorithm also proposed. The same
goes for other stateless solutions, so I suggest, that we try to put all
these algorithms into a separate document.

As far as I am aware, the following algorithms have been officially proposed:

 a) Sequential method: port-set is a range of consecutive ports. (See 
    I-D.matsuhira-sa46t-spec-03.)

 b) Modulo method: port-set for 1st CPE is (0, N, 2*N, ...), port-set for 
    2nd CPE is (1, N+1, 2*N+1, ...) and so on, where N is the number of CPEs
    sharing the same IPv4 address. (See I-D.xli-behave-divi-03.)

 d) "New 4rd method" (interleaved port-pairs): port-set for the 1st CPE is
    (0, 1, 2*N, 2*N+1, 4*N, 4*N+1, ...), where N is the number of CPEs
    sharing the same IPv4 address. (See I-D.despres-softwire-4rd-addmapping-00.)

 d) "Old 4rd method" (interleaved port-ranges of different sizes): port-set
    for the 1st CPE is:
    ([4k..4k/N], [8k..8k/N], [16k..16k/N], [32k..32k/N]),
    for the 2nd CPE is:
    ([4k+4k/N..4k+2*4k/N], ..., [32k+32k/N..32k+2*32k/N]),
    where N is the number of CPEs sharing the same IPv4 address. (See 
    I-D.murakami-softwire-4rd-00.)
 
 e) Random method: port-set is a randomly chosen subset of all available ports.
    (See I-D.boucadair-pppext-portrange-option-07.)

 f) Port-range-mask method: port-set is a range of consecutive ports or a
    set of ranges of consecutive ports. (See
    I-D.boucadair-pppext-portrange-option-07.)

If I forgot something, please let me know. It would be also nice to compare
all these algorithms and to identify the trade-offs. The mechanism drafts would
then just pick one of these algorithms (without the need to define it again)
and justify the decision for the specific algorithm.

What do you think about this proposal? With my colleagues we are preparing
another port-selection algorithm, which would enhance the security for
stateless solutions. Something like a stateless-ready counterpart to the 
Random method, specified in I-D.boucadair-pppext-portrange-option-07. This way
we could just add such an algorithm to this "algorithms document" and the
IPv4 address sharing mechanism document authors could then choose the one
which suits them best.

Thanks,
Nejc

From wdec.ietf@gmail.com  Tue Aug 23 07:00:28 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C8A21F8B06 for ; Tue, 23 Aug 2011 07:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.324
X-Spam-Level: 
X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V10Iuv9Z5lkn for ; Tue, 23 Aug 2011 07:00:27 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3CF21F8AFF for ; Tue, 23 Aug 2011 07:00:27 -0700 (PDT)
Received: by qwc23 with SMTP id 23so97210qwc.31 for ; Tue, 23 Aug 2011 07:01:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p5+FPqoqPsUEmnRHkKOeShBTGWCMQy6wwSp69Oi3EvA=; b=symL8Hk1anGTbDTJvWWC9BJn0ZPLD8H5O3L3joRhMo0fFl0c9Qz/Xo7g7x850oxfss KpcsEqrIrZjulcDAYVsHyuP03dFOX6s2QGtEV8y49G8fzEzGo+MXJV62oIKjwylh0NRN +6zXDfhkltR6qrQ/SxkBjtoRzjzrntYJGndmo=
MIME-Version: 1.0
Received: by 10.142.52.17 with SMTP id z17mr1996103wfz.143.1314108093965; Tue, 23 Aug 2011 07:01:33 -0700 (PDT)
Received: by 10.142.211.4 with HTTP; Tue, 23 Aug 2011 07:01:33 -0700 (PDT)
In-Reply-To: <4E5253F9.1000206@skoberne.net>
References: <4E5253F9.1000206@skoberne.net>
Date: Tue, 23 Aug 2011 16:01:33 +0200
Message-ID: 
From: Wojciech Dec 
To: =?ISO-8859-2?Q?Nejc_=A9koberne?= 
Content-Type: multipart/alternative; boundary=000e0cd242e623276e04ab2ca2e4
Cc: "softwires@ietf.org" , draft-dec-stateless-4v6@tools.ietf.org
Subject: Re: [Softwires] Comments on draft-dec-stateless-4v6-02
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 14:00:28 -0000

--000e0cd242e623276e04ab2ca2e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nejc,

we indeed need some wordsmithing on that part of the text, but the message
that it tries to convey looks unaffected:

- If one believes that port unrestriced TCP provides "enough" security, the=
n
the port-restriction does little to alter that in consideration of host/CPE
practices (no randomization). As you point out, such "belief" may be
misplaced, especially with larger widow sizes. Granted, a system with full
random source port selection across the full port range is ideal.
- The security offered by UDP is easily overcome with very modest resources=
.
The CPU/GPU reference is made to illustrate the point that computationally
it is trivial, and it's worth adding that bandwidth wise it is also likely
to be so esp on a high speed link.


The paper you indicated provides a neat summary of the level of security
based on source ports as offered by many implementations still today,
including those of CPEs:

---snip---

Moreover, ephemeral source ports are not actually selected from the full
16-bit range, but a smaller subset range.  Ports 1-1024 are reserved for
privileged processes, and ports 49152-65535 are reserved for private ports.
In some cases, operating systems have even reserved ports 5001-65535 for
private usage, leaving only 3977 ports for dynamic kernel assignment.
Currently, existing source port selection is so predictable as to make
guessing reasonably trivial; even for the blind TCP spoofing attacker.

---snip---

Regards,
Woj.


2011/8/22 Nejc =C5=A0koberne 

> Dear authors,
>
> I have some comments on section 5.9 Securty and Port Randomization.
>
> -------------------------------------------------------------------
>   Assuming all other information has already been acquired, and also
>   the presence of no exploits, the basic security of IP protocols lies
>   in the computational cost of guessing a combination of a protocol
>   field, eg a TCP sequence number or say a DNS transaction ID,
>   multiplied by a the cost of a guess of a source port.  Thus, for a
> 
>   TCP brute force attack, the already substantial cost in guessing a
>   sequence number (2^32 possibilities) is multiplied by the port range
>   guess cost.  In this context a 1K port restricted 4V6 system, is
>   costly enough for most practical purposes.  More discussion to
>   improve the robustness of TCP against Blind In-Window Attacks can be
>   found at [RFC5961].
>
> [NS: The claim, that this is costly enough for most practical purposes,
> is not true. This is also the motivation for RFC 5961, as I
> understand it. The issue is, that it's not the 2^32 space we need to
> search but rather 2^32/W, where W is the window size. And in practice,
> W is 32-64k. Which is a huge reduction in complexity. If we know the
> source port, an attacker on a 100Mbit/s link can tear down a TCP session
> between another client and server (if server is at least 100Mbit/s as
> well) in cca. 0.8 seconds (on average, see
> RFC 5961 and "Slipping in the Window: TCP Reset attacks", Presentation
> at 2004 CanSecWest). If we consider 10-bit port space (1024 ports per
> customer), the average time increases to ~13.6 minutes, which is still
> a very practicable attack for longer-lived-sessions. However, if we
> have the whole 16-bit port range, the attack becomes considerably less
> practicable (although still practicable with very long-lived sessions),
> the average time is 14.5 hours. But that's an amount of time, where
> other measures would possibly be triggered in case something strange
> is going on.]
>
>   For a UDP/DNS brute force attack, the computational cost required to
>   scan/generate the full range of 2^32 possibilities, corresponding to
>   a port unrestricted system is relatively low/easy - today's GPUs can
>   do so in a few seconds.
>
> [NS: I am not sure I understand the role of GPUs in sending guessing
> packets?]
>
>   Beyond the above, in terms of the avoiding a fixed linear or single
>   port range allocations, extensions to the 4V6 solution provides
>   additional remedy, eg [I-D.bajko-pripaddrassign].
>
> [NS: I-D.bajko-pripaddrassign is expired and AFAIK it defines a DHCPv4
> option to signal the port range/mask and a key to the client host/CPE.
> I guess this is pretty useless in stateless solutions, where we don't
> want to have such signaling. Also, you mention "4V6 solution". How do
> you define this term?]
> -------------------------------------------------------------------
>
> Regards,
> Nejc
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--000e0cd242e623276e04ab2ca2e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nejc,

we indeed need some wordsmithing on that part of the text, but=
 the message that it tries to convey looks unaffected:

- If one beli=
eves that port unrestriced TCP provides "enough" security, then t=
he port-restriction does little to alter that in consideration of host/CPE =
practices (no randomization). As you point out, such "belief" may=
 be misplaced, especially with larger widow sizes. Granted, a system with f=
ull random source port selection across the full port range is ideal.

- The security offered by UDP is easily overcome with very modest resources=
. The CPU/GPU reference is made to illustrate the point that computationall=
y it is trivial, and it's worth adding that bandwidth wise it is also l=
ikely to be so esp on a high speed link.



The paper you indicated provides a neat summary of the level of sec=
urity based on source ports as offered by many implementations still today,=
 including those of CPEs:






---snip---



Moreover, ephemeral source ports are not actually =
selected
from the full 16-bit range, but a smaller subset range.=C2=
=A0 Ports 1-1024 are reserved for privileged
processes, and ports 49152-65535 are reserved for private ports.=C2=A0 In some cases, operating systems have even
reserved ports 5001-65535 for private usage, leaving only 3977 ports for
dynamic kernel assignment.


Currently, existing source port selection is so
predictable as to make guessing reasonably trivial; even for the blind TCP
spoofing attacker.=C2=A0 


---snip---

Regards,
Woj.
=C2=A0

2011/8/22 Nejc =C5=A0koberne <nejc@skoberne.net>

Dear authors,



I have some comments on section 5.9 Securty and Port Randomization.



-------------------------------------------------------------------

 =C2=A0 Assuming all other information has already been acquired, and also<=
br>
 =C2=A0 the presence of no exploits, the basic security of IP protocols lie=
s

 =C2=A0 in the computational cost of guessing a combination of a protocol
 =C2=A0 field, eg a TCP sequence number or say a DNS transaction ID,

 =C2=A0 multiplied by a the cost of a guess of a source port. =C2=A0Thus, f=
or a

<snip>

 =C2=A0 TCP brute force attack, the already substantial cost in guessing a<=
br>
 =C2=A0 sequence number (2^32 possibilities) is multiplied by the port rang=
e

 =C2=A0 guess cost. =C2=A0In this context a 1K port restricted 4V6 system, =
is

 =C2=A0 costly enough for most practical purposes. =C2=A0More discussion to=


 =C2=A0 improve the robustness of TCP against Blind In-Window Attacks can b=
e

 =C2=A0 found at [RFC5961].



[NS: The claim, that this is costly enough for most practical purposes,

is not true. This is also the motivation for RFC 5961, as I

understand it. The issue is, that it's not the 2^32 space we need to
search but rather 2^32/W, where W is the window size. And in practice,

W is 32-64k. Which is a huge reduction in complexity. If we know the

source port, an attacker on a 100Mbit/s link can tear down a TCP session
between another client and server (if server is at least 100Mbit/s as

well) in cca. 0.8 seconds (on average, see

RFC 5961 and "Slipping in the Window: TCP Reset attacks", Present=
ation

at 2004 CanSecWest). If we consider 10-bit port space (1024 ports per

customer), the average time increases to ~13.6 minutes, which is still

a very practicable attack for longer-lived-sessions. However, if we

have the whole 16-bit port range, the attack becomes considerably less

practicable (although still practicable with very long-lived sessions),

the average time is 14.5 hours. But that's an amount of time, where

other measures would possibly be triggered in case something strange

is going on.]



 =C2=A0 For a UDP/DNS brute force attack, the computational cost required t=
o

 =C2=A0 scan/generate the full range of 2^32 possibilities, corresponding t=
o

 =C2=A0 a port unrestricted system is relatively low/easy - today's GPU=
s can

 =C2=A0 do so in a few seconds.



[NS: I am not sure I understand the role of GPUs in sending guessing

packets?]



 =C2=A0 Beyond the above, in terms of the avoiding a fixed linear or single=


 =C2=A0 port range allocations, extensions to the 4V6 solution provides

 =C2=A0 additional remedy, eg [I-D.bajko-pripaddrassign].



[NS: I-D.bajko-pripaddrassign is expired and AFAIK it defines a DHCPv4

option to signal the port range/mask and a key to the client host/CPE.

I guess this is pretty useless in stateless solutions, where we don't
want to have such signaling. Also, you mention "4V6 solution". Ho=
w do

you define this term?]

-------------------------------------------------------------------



Regards,

Nejc

_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--000e0cd242e623276e04ab2ca2e4--

From jacniq@gmail.com  Tue Aug 23 07:31:14 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D9121F86C0 for ; Tue, 23 Aug 2011 07:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.104
X-Spam-Level: 
X-Spam-Status: No, score=-3.104 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmqORmHceojb for ; Tue, 23 Aug 2011 07:31:13 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D479121F86C1 for ; Tue, 23 Aug 2011 07:31:12 -0700 (PDT)
Received: by vxi29 with SMTP id 29so172095vxi.31 for ; Tue, 23 Aug 2011 07:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vOxRUvMYm24kv4oSP0a3tAqOb3bHny0RzzbeXKXsGjU=; b=r6tb8fQMoxoConw0rajZH+ZFnFtgk2dY0ZFO0NQoZEBCWKm+ZPIeSDGg2w0Dzlz1I/ mtlklKCIIczJbclI/0nZxhMTEWMxmPHPFqoKraTuTwcGGaPQr775niijnYDVKqR/Grb/ lYcoDOg+On/UTT1/3/TmqtL2pA2Yu8uKEoIFs=
MIME-Version: 1.0
Received: by 10.52.93.243 with SMTP id cx19mr3685991vdb.179.1314109939784; Tue, 23 Aug 2011 07:32:19 -0700 (PDT)
Received: by 10.52.187.161 with HTTP; Tue, 23 Aug 2011 07:32:19 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 23 Aug 2011 22:32:19 +0800
Message-ID: 
From: Jacni Qin 
To: Tina TSOU 
Content-Type: multipart/alternative; boundary=20cf3071c75c281c1804ab2d10f4
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 14:31:14 -0000

--20cf3071c75c281c1804ab2d10f4
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the comments, inline please.

On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU wrote:

> Hi all,
> In IETF-81, the chairs asked the authors of different drafts on multicast
> sit together to discuss and compromise. So we did.
>
> Here are some comments on draft-qin-softwire-dslite-multicast-04.
>
> Overall: if this is to be a Standards Track document, the whole document
> has to be reviewed, the normative parts identified, and requirements
> language substituted for the current descriptive language.
>
Jacni>: I don't see it, while you can post comments.


>

Section 1:
>
> Editorial: at the end of the second paragraph, "vastly consumed" reads
> better in English as: "consumed in vast quantities".
>
> Jacni>: Sorry, EN is not my first language. Maybe we need the help
from a native guy.


> Substantive: add the following to the sentence making up the third
> paragraph:
>
> "..., which prevents these consequences by making use of the native
> multicast capabilities of the intervening IPv6 network."
>
> Jacni>: No objection to add a sentence, but modified as "which preserves
the efficiency of using multicast for traffics forwarding."


> Section 2:
>
> Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply
> aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)".
>
> Jacni>: I think the AFTR is a general item, see the similar comments raised
in another thread about 4rd.


> Substantive(?): In the description of the Multicast B4, it would make
> more sense to change "... which is able to enforce ..." to "... which
> implements ...".
>
> Section 3.2:
>
> Bullet 1: the second sentence jams two unrelated ideas together. It
> needs a little expansion to read properly. The next sentence doesn't
> make sense within the stated scope of the bullet and shouldn't be there.
> The suggested changed text is thus:
>
> Jacni>: Sorry, I don't agree. I think text in the paragraph following the
bullet
explains the scope clearly.


>   "A viable scenario for this use case in DS-Lite environment: customers
>    with legacy receivers must continue to access the IPv4-enabled
>    multicast services.  This means the traffic should be accessed
>    through IPv4 and additional functions are needed to traverse the
>    operator's IPv6- enabled network. It is the purpose of this
>    document to describe those functions.  Refer to [I-D.jaclee-behave-
>    v4v6-mcast-ps] for the deployment considerations."
>
> Final paragraph: don't you need a final sentence saying something like:
> "Depending on the specific details of the contract, this may mean that
> the specific framing of the content packets (as IPv4 packets) must be
> preserved along with the content within that framing."
>
> Jacni>:That's what the current text means.



> Section 4:
>
> First paragraph: the following sentences need to be added after the
> first one to give a full picture of what is required for a solution:
>
> "For multicast, in contrast, separate mechanisms are required to process
> the outgoing multicast signalling packets and the incoming packets of
> content. The multicast signalling needs to be interworked to IPv6 and
> processed as IPv6 signalling. For incoming multicast content, this
> document defines ..."
>

Jacni>: The signalling things will be detailed in the signalling section.
This is just a general description here.


>
> Middle paragraph: why doesn't it simply read:
>
> "See Section 4.3 for multicast distribution tree establishment and
> Section 4.4 for multicast traffic forwarding."
>
> Section 4.2
>
> Third paragraph typo: mPrefixe64 -> mPrefix64
>
Jacni>: Oops, got it, thank you.


>
> Section 4.3
>
> Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That
> would cause the native IPv6 multicast infrastructure to be bypassed. It
> is also inconsistent with the architectural figure. Delete the first
> bullet and merge the second one with the next paragraph, like this:
>
Jacni>: Actually, this is one of the typical cases.
The mAFTR can be embedded in the MLD Querier, which will
not bapass the IPv6 multicast infrastructure.


>
> "The mAFTR should process the received PIMv6 Join message for the
> IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join
> message. It creates an entry for the IPv6 multicast group address in its
> multicast Routing Information Base. This entry is used to forward ..."
>
> Section 4.5
>
> It is not clear whether the final paragraph is talking about the mB4+B4
> or the mAFTR+AFTR or both. In fact, it makes good sense to combine the
> mB4 and the B4, but combining the AFTR and mAFTR would be questionable
> for reasons of scalability.


Jacni>: We don't see the problems so far.


> There may be routing issues to sort out
> regarding reachability of the IPv4 prefix that is shared by the source
> -- the multicast routers should choose the path leading through the
> mAFTR rather than the one going through the AFTR.
>

Jacni>: Sorry, I don't understand the ".. IPv4 prefix that is shared by the
source.."
For multicast routing, multicast routers including mAFTR will deal with that
based on
converged unicast routing.
You can learn more about it in the following sections.


>
> No more comments up to section 7. Maybe more comments from section 7
> onwards in a separate E-mail.
>
Jacni>: Thank again for your comments.


Cheers,
Jacni


>
> Regards,
> Tina
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--20cf3071c75c281c1804ab2d10f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the comments, inline please.
On Tue, Aug 23, 2011 at 9:58 AM, Ti=
na TSOU <Tina.Tsou.Zouting@huawei.com> wrote:


Hi all,

In IETF-81, the chairs asked the authors of different drafts on multicast s=
it together to discuss and compromise. So we did.



Here are some comments on draft-qin-softwire-dslite-multicast-04.



Overall: if this is to be a Standards Track document, the whole document
has to be reviewed, the normative parts identified, and requirements

language substituted for the current descriptive language.


Jacni>: I don't see it, whi=
le=A0you can post comments.
=A0

=A0

Section 1:



Editorial: at the end of the second paragraph, "vastly consumed" =
reads

better in English as: "consumed in vast quantities".


Jacni>: Sorry,=A0EN is not =
my first language.=A0Maybe we need=A0the help from=A0a=A0native=A0guy.
=A0


Substantive: add the following to the sentence making up the third

paragraph:



"..., which prevents these consequences by making use of the native
multicast capabilities of the intervening IPv6 network."


Jacni>: No objection to add=
 a sentence, but modified as "which preserves the efficiency of using =
multicast for traffics forwarding."
=A0



Section 2:



Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that si=
mply

aren't there. Suggestion: "Multicast Transitional Border Gateway (=
mTBG)".


Jacni>: I think the AFTR is=
=A0a general=A0item, see the similar comments raised
in another thread about 4rd.
=A0


Substantive(?): In the description of the Multicast B4, it would make

more sense to change "... which is able to enforce ..." to "=
... which

implements ...".



Section 3.2:



Bullet 1: the second sentence jams two unrelated ideas together. It

needs a little expansion to read properly. The next sentence doesn't
make sense within the stated scope of the bullet and shouldn't be there=
.

The suggested changed text is thus:


Jacni>:=A0Sorry, I=A0don=
9;t agree. I think=A0text in the paragraph following=A0the bullet
explains the=A0scope clearly.
=A0



 =A0 "A viable scenario for this use case in DS-Lite environment: cust=
omers

 =A0 =A0with legacy receivers must continue to access the IPv4-enabled

 =A0 =A0multicast services. =A0This means the traffic should be accessed
 =A0 =A0through IPv4 and additional functions are needed to traverse the
 =A0 =A0operator's IPv6- enabled network. It is the purpose of this

 =A0 =A0document to describe those functions. =A0Refer to [I-D.jaclee-behav=
e-

 =A0 =A0v4v6-mcast-ps] for the deployment considerations."



Final paragraph: don't you need a final sentence saying something like:=


"Depending on the specific details of the contract, this may mean that=


the specific framing of the content packets (as IPv4 packets) must be

preserved along with the content within that framing."


Jacni>:That's what the =
current text means.
=A0
=A0


Section 4:



First paragraph: the following sentences need to be added after the

first one to give a full picture of what is required for a solution:



"For multicast, in contrast, separate mechanisms are required to proce=
ss

the outgoing multicast signalling packets and the incoming packets of

content. The multicast signalling needs to be interworked to IPv6 and

processed as IPv6 signalling. For incoming multicast content, this

document defines ..."
=A0
Jacni>: The signalling things will be detailed in the signalli=
ng section.
This is just a general =
description here.


=A0



Middle paragraph: why doesn't it simply read:



"See Section 4.3 for multicast distribution tree establishment and

Section 4.4 for multicast traffic forwarding."



Section 4.2



Third paragraph typo: mPrefixe64 -> mPrefix64
Jacni>: Oops, got it, thank you.
=A0<=
/div>




Section 4.3



Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That

would cause the native IPv6 multicast infrastructure to be bypassed. It

is also inconsistent with the architectural figure. Delete the first

bullet and merge the second one with the next paragraph, like this:
Jacni>:=A0Actually, this is one of =
the typical cases.
The mAFTR can be=
 embedded in the MLD Querier, which will


not=A0bapass the IPv6 multicast infrastructure.=

=A0




"The mAFTR should process the received PIMv6 Join message for the

IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join

message. It creates an entry for the IPv6 multicast group address in its
multicast Routing Information Base. This entry is used to forward ..."=




Section 4.5



It is not clear whether the final paragraph is talking about the mB4+B4

or the mAFTR+AFTR or both. In fact, it makes good sense to combine the

mB4 and the B4, but combining the AFTR and mAFTR would be questionable

for reasons of scalability. 
=A0
Jacni>: We=A0don't see the problems so far.
=A0

There may be routing issues to sort out

regarding reachability of the IPv4 prefix that is shared by the source

-- the multicast routers should choose the path leading through the

mAFTR rather than the one going through the AFTR.
=A0<=
/div>
Jacni>: Sorry, I don't understand t=
he ".. IPv4 prefix that is shared by the source.."

For multicast routing, multicast routers including m=
AFTR will deal with that based on
c=
onverged unicast routing.
You can l=
earn more about it in the following sections.


=A0



No more comments up to section 7. Maybe more comments from section 7

onwards in a separate E-mail.
J=
acni>: Thank again for your comments.
=A0
=A0=

Cheers,
Jacni


=A0



Regards,

Tina

_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--20cf3071c75c281c1804ab2d10f4--

From nejc@skoberne.net  Tue Aug 23 08:05:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0321F84DC for ; Tue, 23 Aug 2011 08:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.204
X-Spam-Level: 
X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.095,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnBt2W7LG4NA for ; Tue, 23 Aug 2011 08:05:36 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7517321F84D8 for ; Tue, 23 Aug 2011 08:05:35 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 9729F227878B; Tue, 23 Aug 2011 17:06:41 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vIhq55z4qcl; Tue, 23 Aug 2011 17:06:40 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 9D4852278783; Tue, 23 Aug 2011 17:06:40 +0200 (CEST)
Message-ID: <4E53C200.50805@skoberne.net>
Date: Tue, 23 Aug 2011 16:06:40 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Wojciech Dec 
References: <4E5253F9.1000206@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-dec-stateless-4v6@tools.ietf.org
Subject: Re: [Softwires] Comments on draft-dec-stateless-4v6-02
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 15:05:37 -0000

Dear Wojciech,

> - If one believes that port unrestriced TCP provides "enough" security, 
> then the port-restriction does little to alter that in consideration of 
> host/CPE practices (no randomization). As you point out, such "belief" 
> may be misplaced, especially with larger widow sizes. Granted, a system 
> with full random source port selection across the full port range is ideal.

My point was, that this "little" is not as little as some people might
think. This is what I tried to show with my calculation. I still think
the difference is significant in practice and that using port-restricted
systems without any measures (like random port selection in
draft-bajko-pripaddrassign-03) is one of the trade-offs which should be
considered when deciding on a mechanism. That's all.

> - The security offered by UDP is easily overcome with very modest 
> resources. The CPU/GPU reference is made to illustrate the point that 
> computationally it is trivial, and it's worth adding that bandwidth wise 
> it is also likely to be so esp on a high speed link.

But what do you have to compute anyway? It's just trying 2^32 values
until you get "a bingo". So I don't think it is the computational 
complexity which is relevant here, but rather bandwidth or preferrably
packet rate. That's why I would just remove the GPU part.

> The paper you indicated provides a neat summary of the level of security 
> based on source ports as offered by many implementations still today, 
> including those of CPEs:
> 
> ---snip---
> 
> Moreover, ephemeral source ports are not actually selected from the full 
> 16-bit range, but a smaller subset range.Ports 1-1024 are reserved for 
> privileged processes, and ports 49152-65535 are reserved for private 
> ports.In some cases, operating systems have even reserved ports 
> 5001-65535 for private usage, leaving only 3977 ports for dynamic kernel 
> assignment.
> 
> Currently, existing source port selection is so predictable as to make 
> guessing reasonably trivial; even for the blind TCP spoofing attacker.

Indeed. But I think have to consider long-term consequences? I can
imagine that operating systems will start to implement RFC 6056 eventually
and when they do, it will be these NAT-based port-restricted mechanisms,
which will degrade security (of course, only to certain extent). And
people should be aware of this.

Thanks,
Nejc

From nejc@skoberne.net  Tue Aug 23 08:42:35 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A398421F85F2 for ; Tue, 23 Aug 2011 08:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.207
X-Spam-Level: 
X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDXCpgXpE9o3 for ; Tue, 23 Aug 2011 08:42:35 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1F17F21F85CE for ; Tue, 23 Aug 2011 08:42:35 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 481B2227878B; Tue, 23 Aug 2011 17:43:40 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GLaiWqJcuw4; Tue, 23 Aug 2011 17:43:39 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id E0AB02278783; Tue, 23 Aug 2011 17:43:36 +0200 (CEST)
Message-ID: <4E53CAA9.3000702@skoberne.net>
Date: Tue, 23 Aug 2011 16:43:37 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: draft-dec-stateless-4v6-02@tools.ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , draft-xli-behave-divi@tools.ietf.org, Iain Phillips , Olaf Maennel , draft-murakami-softwire-4v6-translation@tools.ietf.org
Subject: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 15:42:35 -0000

Dear authors,

In I-D.dec-stateless-4v6-02 there is a table on page 11, which says that
IPv4 Header Checksum needs to be recalculated in stateless translation
IPv4 address sharing solutions. Does this mean that _only_ the IPv4 header
checksum should be recalculated?

This is how I see it:

Practically, the answer could maybe be yes. In each traversal of a packet through
double stateless translation, there could be just one IPv4 header recalculation,
always in the second translation process, where the IPv4 header is put back
on.

However, RFC 6145 says:

   The original IPv4 header on the
   packet is removed and replaced by an IPv6 header, and the transport
   checksum is updated as needed, if that transport is supported by the
   translator.

This means, since the I-D.dec-stateless-4v6-02 (and the same goes for
I-D.xli-behave-divi-03, of course) refers to RFC 6145, that transport-layer
checksum recalculation should also be performed. Which causes a significant
performance impact (we need to include whole packets including packets to
do checksum recalculation). So in this case, we would have 1 IPv4 checksum
recalculation and 2 TCP/UDP checksum recalculations for every packet
traversal through the mechanism.

But since we know, that these packets will be translated two times in a row,
we could just avoid the TCP/UDP recalculation, I guess? Would this work?

I guess that devices in between the CPE and AFTR then shouldn't do any
transport-layer processing, since this would probably be fatal for such
"invalid" packets. So having any IDS/IPS/stateful firewall devices in the
access network would cause issues?

However, if this is not possible, then I think that I-D.dec-stateless-4v6-02
should also state that UDP/TCP Header Checksum recalculation has to be
performed.

Thanks,
Nejc

From simon.perreault@viagenie.ca  Tue Aug 23 10:01:00 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CDB21F8A4B for ; Tue, 23 Aug 2011 10:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRtVlBcMkldS for ; Tue, 23 Aug 2011 10:00:59 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 92B4121F8742 for ; Tue, 23 Aug 2011 10:00:59 -0700 (PDT)
Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6A2AC21107 for ; Tue, 23 Aug 2011 13:02:07 -0400 (EDT)
Message-ID: <4E53DD0E.3020507@viagenie.ca>
Date: Tue, 23 Aug 2011 13:02:06 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E53CAA9.3000702@skoberne.net>
In-Reply-To: <4E53CAA9.3000702@skoberne.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 17:01:00 -0000

Nejc Škoberne wrote, on 08/23/2011 11:43 AM:
> But since we know, that these packets will be translated two times in a row,
> we could just avoid the TCP/UDP recalculation, I guess? Would this work?

Yes, we've been discussing this internally among co-authors of
draft-despres-softwire-4rd-addmapping. The conclusion was that the transport
checksum does not need to be modified. A consequence is that the 4rd address
scheme does not need to care about checksum neutrality (contrary to e.g. NAT64
and NAT66).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From Tina.Tsou.Zouting@huawei.com  Tue Aug 23 12:22:32 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4EA21F8D0B for ; Tue, 23 Aug 2011 12:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.113
X-Spam-Level: 
X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.486,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abw8+COzJ4TB for ; Tue, 23 Aug 2011 12:22:25 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C321F8C83 for ; Tue, 23 Aug 2011 12:22:25 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00A6DB78RX@szxga05-in.huawei.com> for softwires@ietf.org; Wed, 24 Aug 2011 03:23:32 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00C25B774G@szxga05-in.huawei.com> for softwires@ietf.org; Wed, 24 Aug 2011 03:23:32 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ59639; Wed, 24 Aug 2011 03:23:30 +0800 (CST)
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 03:23:26 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 03:23:24 +0800
Date: Tue, 23 Aug 2011 19:23:24 +0000
From: Tina TSOU 
In-reply-to: <4E5184E6.9060009@gmail.com>
X-Originating-IP: [10.193.34.145]
To: Brian E Carpenter 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] draft-murakami-softwire-4v6-translation
Thread-index: AQHMXMhg06jxFzt5Jk+ezVwq/3/A35UiUx4AgABnRYCAAAT4AIABbCKAgAAf2wCAAAfigIAATK+AgAAyb4CAAQYUAIAAu3lggADNwgCAA3bpoA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net> <4E503B08.9030800@gmail.com>  <4E5184E6.9060009@gmail.com>
Cc: "softwires@ietf.org" , "draft-murakami-softwire-4v6-translation@tools.ietf.org" 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 19:22:32 -0000

RGVhciBCcmlhbiwNClRoYW5rIHlvdSBhbmQgaW4gbGluZS4uLg0KDQoNCkJlc3QgUmVnYXJkcywN
ClRpbmEgVFNPVQ0KaHR0cDovL3RpbmF0c291LndlZWJseS5jb20vY29udGFjdC5odG1sDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls
dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IFN1bmRheSwgQXVndXN0IDIx
LCAyMDExIDM6MjEgUE0NClRvOiBUaW5hIFRTT1UNCkNjOiBSw6ltaSBEZXNwcsOpczsgc29mdHdp
cmVzQGlldGYub3JnOyBkcmFmdC1tdXJha2FtaS1zb2Z0d2lyZS00djYtdHJhbnNsYXRpb25AdG9v
bHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBkcmFmdC1tdXJha2FtaS1zb2Z0
d2lyZS00djYtdHJhbnNsYXRpb24NCg0KSGkgVGluYSwNCg0KT24gMjAxMS0wOC0yMSAxNDowOCwg
VGluYSBUU09VIHdyb3RlOg0KLi4uDQo+IElmIGFuIGF2ZXJhZ2UgSVB2NCB1c2VyIGlzIGNvbnN1
bWluZyAyMDAgcG9ydHMgKG9yIHdoYXRldmVyDQo+IHZhbHVlIHlvdSBwcmVmZXIgdG8gYXNzdW1l
KSB3aXRoIHRoZWlyIGZhdm91cml0ZSBwMnAgYXBwLCB0aGF0DQo+IGlzIHdoYXQgc2V0cyB0aGUg
bnVtYmVyIG9mIElQdjQgdXNlcnMgcGVyIHNoYXJlZCBhZGRyZXNzLiBJdCdzDQo+IHRoZSBudW1i
ZXIgb2Ygc2ltdWx0YW5lb3VzIHBvcnRzLCBub3QgdGhlIGFtb3VudCBvZiB0cmFmZmljLA0KPiB0
aGF0IGNvdW50cy4NCj4gW1RpbmE6DQo+IFRoZXNlIGRyYWZ0cyBhdHRlbXB0IHRvIHNvbHZlIHRo
aXMgaXNzdWUuDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRzb3Ut
cGNwLW5hdGNvb3JkLw0KDQpUaGlzIGRvZXNuJ3QgY3JlYXRlIG5ldyBwb3J0czsgaXQganVzdCBo
ZWxwcyB0byBhbGxvY2F0ZQ0KdGhlbSBtb3JlIHJhdGlvbmFsbHkuDQpbVGluYTogV2hlbiBJIHNl
ZSB5b3VyIGNvbW1lbnRzIGFib3V0IGNvbnN1bWluZyAyMDAgcG9ydHMsIEkgdGhvdWdodCBhYm91
dCB0aGUgbW90aXZhdGlvbiBvZiBOQVQtQ09PUkQgaXMgdG8gc29sdmUgdGhlIGlzc3VlIG9mIG9u
ZSBpVHVuZXMsIEdvb2dsZSBNYXAgYXBwbGljYXRpb24gY29uc3VtZXMgMjAwfjMwMCBwb3J0cyBh
dCBhIHRpbWUuIEkgZGlkIG5vdCB0aGluayBhYm91dCBTdGF0ZWZ1bC9TdGF0ZWxlc3MgYXQgdGhh
dCB0aW1lLg0KDQpJbiB0aGUgdXNlIGNhc2VzIHlvdSBtZW50aW9uZWQgYWJvdmUsIGRvIHlvdSBv
bmx5IG1lYW4gc3RhdGljIHBvcnQgYWxsb2NhdGlvbiBpc3N1ZSB3aXRoIHN0YXRlbGVzcyBtZWNo
YW5pc21zPyBPciBpdCBjYW4gYmUgZWl0aGVyIHN0YXRlZnVsIG9yIHN0YXRlbGVzcz8gDQoNClRo
ZSBzdGF0ZWxlc3MgYWRkcmVzcyBzaGFyaW5nIHNjaGVtZXMgKDRyZCBhbmQgZnJpZW5kcykgYWxs
b2NhdGUgYSBwb3J0IHJhbmdlIHRvIGVhY2ggc3Vic2NyaWJlciBzdGF0aWNhbGx5LiBTdGF0aWMg
YWxsb2NhdGlvbiBpcyBuZWNlc3NhcnkgZm9yIHRoZSBtZWNoYW5pc20gdG8gYmUgc3RhdGVsZXNz
Lg0KVGhlcmUgYXJlIGFsbCB0aGUgYWR2YW50YWdlcyBvZiBhIHN0YXRlbGVzcyBtZWNoYW5pc20g
KHNlZSB0aGUgbW90aXZhdGlvbiBkcmFmdCBmb3IgYSBsaXN0IG9mIHRoZXNlIGFkdmFudGFnZXMp
Lg0KDQpUaGUgcHJvYmxlbSB3aXRoIHN0YXRpYyBhbGxvY2F0aW9uIGlzIHRoYXQgaXQgY2Fubm90
IGFkYXB0IHF1aWNrbHkgdG8gc3Vic2NyaWJlciBkZW1hbmQuIElmIGZvciBleGFtcGxlIHlvdSBo
YXZlIG9uZSBzdWJzY3JpYmVyIHRoYXQgaXMgY29uc3VtaW5nIGEgbG90IG9mIHBvcnRzLCB5b3Ug
Y2Fubm90IGFzc2lnbiBtb3JlIHBvcnRzIHRvIGl0LiBPbmNlIGl0J3MgYXNzaWduZWQsIGl0J3Mg
c3RhdGljIGFuZCBoYXJkIHRvIGNoYW5nZS4NCl0NCg0KPiBodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC16aG91LXNvZnR3aXJlLWI0LW5hdC8NCg0KSWYgSSB1bmRlcnN0YW5k
IHRoaXMgY29ycmVjdGx5LCBpdCBhdm9pZHMgTkFUNDQ0ICh3aGljaCBpcyBhDQpnb29kIHRoaW5n
LCBhbmQgd291bGQgbWFrZQ0KZHJhZnQtd2VpbC1zaGFyZWQtdHJhbnNpdGlvbi1zcGFjZS1yZXF1
ZXN0IHVubmVjZXNzYXJ5KS4gQnV0DQphZ2FpbiwgaXQgZG9lc24ndCBjcmVhdGUgbmV3IHBvcnRz
IG9yIG5ldyBwdWJsaWMgSVB2NCBhZGRyZXNzZXMsDQp3aGljaCB3YXMgbXkgcG9pbnQuDQoNCjRy
ZCBhbmQgNHZpYTYgc2hhcmUgdGhpcyBwcm9wZXJ0eSBvZiBjb3Vyc2UuDQoNCiAgIEJyaWFuDQo=

From brian.e.carpenter@gmail.com  Tue Aug 23 13:52:43 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4487321F8D09 for ; Tue, 23 Aug 2011 13:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.593
X-Spam-Level: 
X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmPwbfXKz0u5 for ; Tue, 23 Aug 2011 13:52:41 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99EC821F8D08 for ; Tue, 23 Aug 2011 13:52:41 -0700 (PDT)
Received: by vxi29 with SMTP id 29so546563vxi.31 for ; Tue, 23 Aug 2011 13:53:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FHWKqCN86oQ0mt+B0tHAmafGhW999v7CuaPErhr+Jes=; b=dlgudI0eXfSxAh8Cuc+74VkvBIR1kNVs2pSMPYzHBJXyoN72ZPUcJQtqpmOFsn8RHY J/JsjZw1f0TMZeBCd+Eo8+rl3M0nrHjCptEQfgAXk04mbhvaM+OG+gnkp0lyDIEr7OWc YeqnoyLND1awIDI9n6SWIxI3JrIcCZrMob9Q4=
Received: by 10.52.29.42 with SMTP id g10mr4196642vdh.36.1314132829725; Tue, 23 Aug 2011 13:53:49 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id c13sm156202vcp.44.2011.08.23.13.53.46 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 13:53:49 -0700 (PDT)
Message-ID: <4E541359.6000004@gmail.com>
Date: Wed, 24 Aug 2011 08:53:45 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tina TSOU 
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net> <4E503B08.9030800@gmail.com>  <4E5184E6.9060009@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , "draft-murakami-softwire-4v6-translation@tools.ietf.org" 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 20:52:43 -0000

Tina,

> The problem with static allocation is that it cannot adapt quickly to s=
ubscriber demand.

Exactly; so it cannot optimise the number of ports in use.

What strikes me in this conversation is that all these solutions are a
tremendous amount of work to deal with legacy equipment, and I have
to wonder whether that is economically rational. That is for the market
to decide, but I don't see that the IETF is obliged to solve each
possible case. In other words I'm not sure where to find the requirements=

analysis that this new burst of activity is based on.

Regards
   Brian

On 2011-08-24 07:23, Tina TSOU wrote:
> Dear Brian,
> Thank you and in line...
>=20
>=20
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
>=20
>=20
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20
> Sent: Sunday, August 21, 2011 3:21 PM
> To: Tina TSOU
> Cc: R=C3=A9mi Despr=C3=A9s; softwires@ietf.org; draft-murakami-softwire=
-4v6-translation@tools.ietf.org
> Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
>=20
> Hi Tina,
>=20
> On 2011-08-21 14:08, Tina TSOU wrote:
> ...
>> If an average IPv4 user is consuming 200 ports (or whatever
>> value you prefer to assume) with their favourite p2p app, that
>> is what sets the number of IPv4 users per shared address. It's
>> the number of simultaneous ports, not the amount of traffic,
>> that counts.
>> [Tina:
>> These drafts attempt to solve this issue.
>> https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/
>=20
> This doesn't create new ports; it just helps to allocate
> them more rationally.
> [Tina: When I see your comments about consuming 200 ports, I thought ab=
out the motivation of NAT-COORD is to solve the issue of one iTunes, Goog=
le Map application consumes 200~300 ports at a time. I did not think abou=
t Stateful/Stateless at that time.
>=20
> In the use cases you mentioned above, do you only mean static port allo=
cation issue with stateless mechanisms? Or it can be either stateful or s=
tateless?=20
>=20
> The stateless address sharing schemes (4rd and friends) allocate a port=
 range to each subscriber statically. Static allocation is necessary for =
the mechanism to be stateless.
> There are all the advantages of a stateless mechanism (see the motivati=
on draft for a list of these advantages).
>=20
> The problem with static allocation is that it cannot adapt quickly to s=
ubscriber demand. If for example you have one subscriber that is consumin=
g a lot of ports, you cannot assign more ports to it. Once it's assigned,=
 it's static and hard to change.
> ]
>=20
>> https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/
>=20
> If I understand this correctly, it avoids NAT444 (which is a
> good thing, and would make
> draft-weil-shared-transition-space-request unnecessary). But
> again, it doesn't create new ports or new public IPv4 addresses,
> which was my point.
>=20
> 4rd and 4via6 share this property of course.
>=20
>    Brian


From nejc@skoberne.net  Tue Aug 23 15:59:27 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A80121F8C9D for ; Tue, 23 Aug 2011 15:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wehZ5sXeFWM for ; Tue, 23 Aug 2011 15:59:27 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id C989F21F8C0F for ; Tue, 23 Aug 2011 15:59:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id E22CE227879B; Wed, 24 Aug 2011 01:00:32 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny-ki-ePmPpE; Wed, 24 Aug 2011 01:00:32 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-131-209-4.lut.ac.uk [131.231.209.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 784882278797; Wed, 24 Aug 2011 01:00:32 +0200 (CEST)
Message-ID: <4E543110.5090108@skoberne.net>
Date: Wed, 24 Aug 2011 00:00:32 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E53CAA9.3000702@skoberne.net> <4E53DD0E.3020507@viagenie.ca>
In-Reply-To: <4E53DD0E.3020507@viagenie.ca>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 22:59:27 -0000

Dear Simon,

> Yes, we've been discussing this internally among co-authors of
> draft-despres-softwire-4rd-addmapping. The conclusion was that the transport
> checksum does not need to be modified. 

OK. But this then means, that if there are any stateful devices like stateful
firewalls, IPS/IDS systems in between, we could have problems, right?

> A consequence is that the 4rd address
> scheme does not need to care about checksum neutrality (contrary to e.g. NAT64
> and NAT66).

Sorry, but I don't understand this. Can you please paraphrase?

Thanks,
Nejc

From simon.perreault@viagenie.ca  Tue Aug 23 16:05:55 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A388D21F8841 for ; Tue, 23 Aug 2011 16:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.404
X-Spam-Level: 
X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyuQnJvDJG6W for ; Tue, 23 Aug 2011 16:05:55 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17D21F87FC for ; Tue, 23 Aug 2011 16:05:55 -0700 (PDT)
Received: from banana.viagenie.ca (unknown [75.98.19.132]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7929F21B86; Tue, 23 Aug 2011 19:06:53 -0400 (EDT)
Message-ID: <4E54327B.4030701@viagenie.ca>
Date: Tue, 23 Aug 2011 19:06:35 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0
MIME-Version: 1.0
To: =?windows-1252?Q?Nejc_=8Akoberne?= 
References: <4E53CAA9.3000702@skoberne.net> <4E53DD0E.3020507@viagenie.ca> <4E543110.5090108@skoberne.net>
In-Reply-To: <4E543110.5090108@skoberne.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 23:05:55 -0000

Nejc Škoberne wrote, on 08/23/2011 07:00 PM:
>> Yes, we've been discussing this internally among co-authors of
>> draft-despres-softwire-4rd-addmapping. The conclusion was that the transport
>> checksum does not need to be modified. 
> 
> OK. But this then means, that if there are any stateful devices like stateful
> firewalls, IPS/IDS systems in between, we could have problems, right?

Right. This would need to be mentioned as well.

>> A consequence is that the 4rd address
>> scheme does not need to care about checksum neutrality (contrary to e.g. NAT64
>> and NAT66).
> 
> Sorry, but I don't understand this. Can you please paraphrase?

Please refer to:
http://tools.ietf.org/html/rfc6052#section-4.1
http://tools.ietf.org/html/rfc6296#section-2.6

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From yiu_lee@cable.comcast.com  Tue Aug 23 16:53:35 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9621F8C71 for ; Tue, 23 Aug 2011 16:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.969
X-Spam-Level: 
X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-1.834, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1MrSbG9NtR9 for ; Tue, 23 Aug 2011 16:53:34 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 35B7521F8C70 for ; Tue, 23 Aug 2011 16:53:34 -0700 (PDT)
Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.50071662; Tue, 23 Aug 2011 18:00:18 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 23 Aug 2011 19:54:39 -0400
From: "Lee, Yiu" 
To: "softwires@ietf.org" 
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMYfAEQt1QJds0iEqgap0blIf57Q==
Date: Tue, 23 Aug 2011 23:54:37 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [24.40.55.71]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2011 23:53:35 -0000

Hi Tina,

Thanks for the review. Comments below:


On 8/22/11 9:58 PM, "Tina TSOU"  wrote:

>
>Section 3.2:
>
>Bullet 1: the second sentence jams two unrelated ideas together. It
>needs a little expansion to read properly. The next sentence doesn't
>make sense within the stated scope of the bullet and shouldn't be there.
>The suggested changed text is thus:
>
>   "A viable scenario for this use case in DS-Lite environment: customers
>    with legacy receivers must continue to access the IPv4-enabled
>    multicast services.  This means the traffic should be accessed
>    through IPv4 and additional functions are needed to traverse the
>    operator's IPv6- enabled network. It is the purpose of this
>    document to describe those functions.  Refer to [I-D.jaclee-behave-
>    v4v6-mcast-ps] for the deployment considerations."

[YL] I don't follow your argument saying "jams two unrelated ideas
together". What we tried to say was an operator could use dual-stack.
However, I would agree we should remove to discuss the dual-stack case
because this is targeted for DS-lite.

>
>Final paragraph: don't you need a final sentence saying something like:
>"Depending on the specific details of the contract, this may mean that
>the specific framing of the content packets (as IPv4 packets) must be
>preserved along with the content within that framing."

[YL] We spoke the same thing. We can clarify in next revision.

>
>Section 4:
>
>First paragraph: the following sentences need to be added after the
>first one to give a full picture of what is required for a solution:
>
>"For multicast, in contrast, separate mechanisms are required to process
>the outgoing multicast signalling packets and the incoming packets of
>content. The multicast signalling needs to be interworked to IPv6 and
>processed as IPv6 signalling. For incoming multicast content, this
>document defines ..."

[YL] We will consider this. I would suggest to the following instead:

"In the original DS-lite specification, an IPv4-in-IPv6 softwire is used
to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. This
document defines an IPv4-in-IPv6 encapsulation scheme to deliver
unidirectional multicast traffic from IPv4 multicast source behind AFTR to
the IPv4 multicast receiver behind B4. This specification defines to
interwork IPv4 multicast and IPv6 multicast protocols (e.g. IGMPv3 <->
MLDv2) and to deliver IPv4 multicast packets in IPv6 encapsulation."

>
>Middle paragraph: why doesn't it simply read:
>
>"See Section 4.3 for multicast distribution tree establishment and
>Section 4.4 for multicast traffic forwarding."
>
>Section 4.2
>
>Third paragraph typo: mPrefixe64 -> mPrefix64

[YL] Fixed

>
>Section 4.3
>
>Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That
>would cause the native IPv6 multicast infrastructure to be bypassed. It
>is also inconsistent with the architectural figure. Delete the first
>bullet and merge the second one with the next paragraph, like this
>
>"The mAFTR should process the received PIMv6 Join message for the
>IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join
>message. It creates an entry for the IPv6 multicast group address in its
>multicast Routing Information Base. This entry is used to forward ..."

[YL] I don't follow this. How would mAFTR bypass native IPv6 multicast
infrastructure? This is another deployment scenario which would allow an
operator to deploy mAFTR in the CPE's default router. However, to
eliminate confusion, we could move this in a different section.

>
>Section 4.5
>
>It is not clear whether the final paragraph is talking about the mB4+B4
>or the mAFTR+AFTR or both. In fact, it makes good sense to combine the
>mB4 and the B4, but combining the AFTR and mAFTR would be questionable
>for reasons of scalability. There may be routing issues to sort out
>regarding reachability of the IPv4 prefix that is shared by the source
>-- the multicast routers should choose the path leading through the
>mAFTR rather than the one going through the AFTR.

[YL] We were talking mAFTR and AFTR, and mB4 and B4. All we were saying
this was possible. We didn't enforce it. I would suggest to remove the
entire section since this is a deployment option, not so much about
specification.

Regards,
Yiu




From Tina.Tsou.Zouting@huawei.com  Tue Aug 23 17:01:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950E021F8C0A for ; Tue, 23 Aug 2011 17:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.135
X-Spam-Level: 
X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.464,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzl6Iz-7Yc1m for ; Tue, 23 Aug 2011 17:01:45 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DC13A21F8C13 for ; Tue, 23 Aug 2011 17:01:44 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00DXZO4SJG@szxga03-in.huawei.com> for softwires@ietf.org; Wed, 24 Aug 2011 08:02:52 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE007YDO4SCI@szxga03-in.huawei.com> for softwires@ietf.org; Wed, 24 Aug 2011 08:02:52 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ16486; Wed, 24 Aug 2011 08:02:52 +0800 (CST)
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 08:02:48 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 08:02:49 +0800
Date: Wed, 24 Aug 2011 00:02:49 +0000
From: Tina TSOU 
X-Originating-IP: [10.193.34.145]
To: "softwires@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: Comments on draft-qin-softwire-dslite-multicast-04
Thread-index: Acxh8St91klaU/mcRO6BhyFk9RPqPQ==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 00:01:45 -0000

Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1 
General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution?

#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as "it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4."



Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html



From jacniq@gmail.com  Tue Aug 23 18:08:02 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADF321F8B8E for ; Tue, 23 Aug 2011 18:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.401
X-Spam-Level: 
X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.197,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOn-dlrqRGJL for ; Tue, 23 Aug 2011 18:08:02 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0169D21F8B8C for ; Tue, 23 Aug 2011 18:08:01 -0700 (PDT)
Received: by vxi29 with SMTP id 29so732592vxi.31 for ; Tue, 23 Aug 2011 18:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cOnNkj1gByFjCPTtkvARQx7relSKQTsH0EaXgT9961k=; b=ZgH31bBDWPuUKbQE7jcqfwKB4IjaTWQ3HxcbYDPyMNrpXE97afWEvcTlGP7RZqrPMD xtCc3G7H1bDILvozZWbyYfUny/kvDvbQJpzFGn5E1Arp+jp56DCRDZEmjk0EDO/sSsLr LKUZpJylUuyT0/Jb5F4AFwyQE8KKJhi3Htcik=
MIME-Version: 1.0
Received: by 10.52.89.146 with SMTP id bo18mr4371124vdb.246.1314148150895; Tue, 23 Aug 2011 18:09:10 -0700 (PDT)
Received: by 10.52.187.161 with HTTP; Tue, 23 Aug 2011 18:09:10 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 24 Aug 2011 09:09:10 +0800
Message-ID: 
From: Jacni Qin 
To: Tina TSOU 
Content-Type: multipart/alternative; boundary=bcaec50162b5b7637404ab35f5aa
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 01:08:02 -0000

--bcaec50162b5b7637404ab35f5aa
Content-Type: text/plain; charset=ISO-8859-1

hi,

On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU wrote:

> Hi all,
> Some more comments on draft-qin-softwire-dslite-multicast-04.
> #1
> General comment: is there any consideration of interaction with unicast
> solutions, e.g., potential collocation or reuse of functions? Do we need
> some mapping or interaction table of the function elements or tunnels
> (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast
> solution?
>

Jacni>: As Yiu mentioned in another email, the co-location with unicast
DS-Lite elements is more deployment specific, and I'm ok to remove the
section 4.5. From the protocol perspective, I don't see there is necessary
interaction with the unicast solution.


> #2
> Section 6.2
> Translation and encapsulation both uses the same mPrefix64 and uPrefix64,
> so mB4 could not determine whether to de-capsulate the packets only based on
> mPrefix64 and uPrefix64. Propose to change as "it checks whether the group
> address is in the range of mPrefix64, the source address is in the range of
> uPrefix64 and whether the next header of IPv6 header is 4."
>

Jacni>:Currently, we only employ the encapsulation for date forwarding in
the main text.


Cheers,
Jacni


>
>
>
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--bcaec50162b5b7637404ab35f5aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi,

On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com&=
gt; wrote:


Hi all,

Some more comments on draft-qin-softwire-dslite-multicast-04.

#1

General comment: is there any consideration of interaction with unicast sol=
utions, e.g., potential collocation or reuse of functions? Do we need some =
mapping or interaction table of the function elements or tunnels (IP-in-IP =
or IP-in-non-IP) to show the relationship with DS-Lite unicast solution?

=A0
Jacni>=
: As Yiu mentioned in another email, the co-location with unicast DS-Lite e=
lements is more deployment specific, and I'm ok to remove the section 4=
.5. From the protocol perspective, I don't see there is necessary inter=
action with the unicast solution.

=A0

#2

Section 6.2

Translation and encapsulation both uses the same mPrefix64 and uPrefix64, s=
o mB4 could not determine whether to de-capsulate the packets only based on=
 mPrefix64 and uPrefix64. Propose to change as "it checks whether the =
group address is in the range of mPrefix64, the source address is in the ra=
nge of uPrefix64 and whether the next header of IPv6 header is 4."



Jacni>:Currently=
, we only employ the encapsulation for date forwarding in the main text.

Cheers,
Jacni
=A0








Best Regards,

Tina TSOU

http:=
//tinatsou.weebly.com/contact.html





_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--bcaec50162b5b7637404ab35f5aa--

From Tina.Tsou.Zouting@huawei.com  Tue Aug 23 19:20:13 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AD921F8B92 for ; Tue, 23 Aug 2011 19:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.143
X-Spam-Level: 
X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.455,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvIuoITFE+m3 for ; Tue, 23 Aug 2011 19:20:11 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8F921F8B98 for ; Tue, 23 Aug 2011 19:20:10 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00EZ8UJIX3@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 24 Aug 2011 10:21:18 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00HX3UJIEU@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 24 Aug 2011 10:21:18 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ69688; Wed, 24 Aug 2011 10:21:17 +0800 (CST)
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 10:21:13 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 10:21:13 +0800
Date: Wed, 24 Aug 2011 02:21:13 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: Jacni Qin 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_bd/4rbYjitJSzHXUsjLsng)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-index: Acxh8St91klaU/mcRO6BhyFk9RPqPf//jGgA//9mLTA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:  
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 02:20:13 -0000

--Boundary_(ID_bd/4rbYjitJSzHXUsjLsng)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Jacni,
Thank you for your early reply. Have a good day.
My replies are below.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: Tuesday, August 23, 2011 6:09 PM
To: Tina TSOU
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

hi,
On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU > wrote:
Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution?

Jacni>: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution.
[TT] Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I strongly suggest add some texts into this section like "the co-location of multicast elements with unicast DS-Lite elements is more deployment specific".


#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as "it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4."

Jacni>:Currently, we only employ the encapsulation for date forwarding in the main text.
[TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not.

Cheers,
Jacni




Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


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


--Boundary_(ID_bd/4rbYjitJSzHXUsjLsng)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT













Hi Jacni,


Thank you for your early reply. Have a good day.


My replies are below.


 


Best Regards,


Tina TSOU


http://tinatsou.weebly.com/contact.html


 


 




From: Jacni
 Qin [mailto:jacniq@gmail.com] 

Sent: Tuesday, August 23, 2011 6:09 PM

To: Tina TSOU

Cc: softwires@ietf.org

Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04




 


hi,




On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:


Hi all,

Some more comments on draft-qin-softwire-dslite-multicast-04.

#1

General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship
 with DS-Lite unicast solution?




 






Jacni>: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective,
 I don't see there is necessary interaction with the unicast solution.


[TT] Section 4.5 is good for the readers to understand the difference between
unicast and multicast DS-Lite. I strongly suggest add some texts into this section like “the co-location of multicast elements with
unicast DS-Lite elements is more deployment specific”.




 






#2

Section 6.2

Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as "it checks whether the group address is in the range of mPrefix64,
 the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4."








Jacni>:Currently, we only employ the encapsulation for date forwarding in the main text.

[TT] 
I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not.



Cheers,

Jacni

 












Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html





_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires






 






--Boundary_(ID_bd/4rbYjitJSzHXUsjLsng)--

From jacniq@gmail.com  Tue Aug 23 19:31:39 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5987321F8B27 for ; Tue, 23 Aug 2011 19:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.407
X-Spam-Level: 
X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.191,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UFHLwc2clMd for ; Tue, 23 Aug 2011 19:31:38 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE63221F8A36 for ; Tue, 23 Aug 2011 19:31:38 -0700 (PDT)
Received: by vws12 with SMTP id 12so770364vws.31 for ; Tue, 23 Aug 2011 19:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jNhBbaEaPNh4rWKSvzAbOcx1b9FOf4RLRlMiRqS41/E=; b=IL74rPh/ewo1GRV11aabYDcr6veq1p3jFMS1d8kKbFzMIY8r6RmT6ah1PHW+qkscYi VzWQkSCoEvAFjAk6QUmDr/pe9E9MJYoXbe8miIEAWOlMbzPRJ3gALz7WqDn10Jwg2Ev1 XMESKyrlcAGIMKCi6fabtKyxXYFjqyPNr0zbo=
MIME-Version: 1.0
Received: by 10.52.89.146 with SMTP id bo18mr4497426vdb.246.1314153167718; Tue, 23 Aug 2011 19:32:47 -0700 (PDT)
Received: by 10.52.187.161 with HTTP; Tue, 23 Aug 2011 19:32:47 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 24 Aug 2011 10:32:47 +0800
Message-ID: 
From: Jacni Qin 
To: Tina TSOU 
Content-Type: multipart/alternative; boundary=bcaec50162b5be076804ab37206c
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 02:31:39 -0000

--bcaec50162b5be076804ab37206c
Content-Type: text/plain; charset=ISO-8859-1

hi,

On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU wrote:

> ...
>
> #2
> Section 6.2
> Translation and encapsulation both uses the same mPrefix64 and uPrefix64,
> so mB4 could not determine whether to de-capsulate the packets only based on
> mPrefix64 and uPrefix64. Propose to change as "it checks whether the group
> address is in the range of mPrefix64, the source address is in the range of
> uPrefix64 and whether the next header of IPv6 header is 4."****
>
>
> Jacni>:Currently, we only employ the encapsulation for date forwarding in
> the main text.
> [TT] I am not talking about translation solution in the main text. Even if
> in the encapsulation case, mB4 needs to determine whether to make
> de-capsulation or not.
>
> Jacni>: In the case of encapsulation, the mB4 can determine that by
checking whether the group address is within the mPrefix64 and the source
address is within the uPrefix64, as what the 6.2 says.


Cheers,
Jacni

--bcaec50162b5be076804ab37206c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi,

On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com=
> wrote:










...







#2

Section 6.2

Translation and encapsulation both uses the same mPrefix64 and uPrefix64, s=
o mB4 could not determine whether to de-capsulate the packets only based on=
 mPrefix64 and uPrefix64. Propose to change as "it checks whether the =
group address is in the range of mPrefix64,
 the source address is in the range of uPrefix64 and whether the next heade=
r of IPv6 header is 4."









Jacni>:Currently, we only employ the =
encapsulation for date forwarding in the main text.


[TT] 
I am not talking about translation solution in the main text. Even if in th=
e encapsulation case, mB4 needs to determine whether to make de-capsulation=
 or not.


Jacni>: In the case of encapsulation, the mB4 can determine =
that by checking whether the group address is within the mPrefix64 and the =
source address is within the uPrefix64, as what the 6.2 says.



Cheers,
Jacni



--bcaec50162b5be076804ab37206c--

From suyuanchao@189.cn  Tue Aug 23 19:40:01 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD2621F8B27 for ; Tue, 23 Aug 2011 19:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.112
X-Spam-Level: **
X-Spam-Status: No, score=2.112 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMkiq7JzLVxl for ; Tue, 23 Aug 2011 19:40:00 -0700 (PDT)
Received: from 189.cn (mta.189.cn [121.14.53.137]) by ietfa.amsl.com (Postfix) with ESMTP id 9630621F857D for ; Tue, 23 Aug 2011 19:40:00 -0700 (PDT)
Received: from ip?64.104.125.217? (as7.inner-189.cn [10.62.8.17]) by 189.cn (HERMES) with ESMTP id A68E83B401A; Wed, 24 Aug 2011 10:40:59 +0800 (CST)
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_IP: wmail.10.62.8.17.2129935781
HMM_SOURCE_TYPE: WEBMAIL
Received: from ip<64.104.125.217> ([64.104.125.217]) by 189CN(Yuwen filter gate 10.62.8.17) with ESMTP id 1314153659.3800 for softwires@ietf.org ; Wed Aug 24 10:41:00 2011
0/X-Total-Score: 13:
X-FILTER-SCORE: to=, score=<1314153660kjjljjljjljjkklllmmqjjVgjegjogjlgjxVeolUBvgj> 
Message-ID: <29869426.9511314153659763.JavaMail.hermes@yt-webmail17>
Date: Wed, 24 Aug 2011 10:40:58 +0800 (CST)
From: suyuanchao@189.cn
To: softwires@ietf.org
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_948_17253235.1314153658960"
HMM_WEBCLN_IP: 64.104.125.217
X-Priority: 3
Cc: cuiyong@tsinghua.edu.cn
Subject: [Softwires]  Re:  New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 02:42:00 -0000

------=_Part_948_17253235.1314153658960
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64

DQo8U1RZTEUgdHlwZT10ZXh0L2Nzcz4NCnAsIGZvbnQsIGRpdiwgbGkge2xpbmUtaGVpZ2h0OjE1
OCU7KmxpbmUtaGVpZ2h0OjE1MCU7IG1hcmdpbjowOyBwYWRkaW5nOjA7fQ0KZGl2OmZvY3VzIHsg
b3V0bGluZTowO30NCjwvU1RZTEU+DQoNCjxUQUJMRSBzdHlsZT0iQk9SREVSLUJPVFRPTS1TVFlM
RTogbm9uZTsgQk9SREVSLVJJR0hULVNUWUxFOiBub25lOyBXSURUSDogMTAwJTsgQk9SREVSLVRP
UC1TVFlMRTogbm9uZTsgVEFCTEUtTEFZT1VUOiBmaXhlZDsgSEVJR0hUOiAxMDAlOyBCT1JERVIt
TEVGVC1TVFlMRTogbm9uZSIgYm9yZGVyPTAgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdp
ZHRoPSIxMDAlIj4NCjxUQk9EWT4NCjxUUj4NCjxURCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVy
OyBWRVJUSUNBTC1BTElHTjogdG9wIiB2QWxpZ249dG9wIHdpZHRoPSIxMDAlIj4NCjxUQUJMRSBz
dHlsZT0iV0lEVEg6IDEwMCU7IFdPUkQtV1JBUDogYnJlYWstd29yZDsgVEFCTEUtTEFZT1VUOiBm
aXhlZDsgSEVJR0hUOiAxMDAlOyBPVkVSRkxPVzogaGlkZGVuIiBib3JkZXI9MCBjZWxsU3BhY2lu
Zz0wIGNlbGxQYWRkaW5nPTA+DQo8VEJPRFk+DQo8VFI+DQo8VEQgc3R5bGU9IldJRFRIOiAwcHg7
IE9WRVJGTE9XOiBoaWRkZW4iIG5vV3JhcD48L1REPg0KPFREIHN0eWxlPSJQQURESU5HLUJPVFRP
TTogMHB4OyBQQURESU5HLUxFRlQ6IDRweDsgV0lEVEg6IDEwMCU7IFBBRERJTkctUklHSFQ6IDRw
eDsgRk9OVC1TSVpFOiAxMnB4OyBPVkVSRkxPVzogaGlkZGVuOyBQQURESU5HLVRPUDogMHB4IiB2
QWxpZ249dG9wIGFsaWduPWxlZnQ+DQo8RElWIGlkPWVkaXREaXYgY2xhc3M9ZWRpdE1haWwgID48
U1BBTiBpZD1ub3REcmFmdD48QlI+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xh
c3M9TXNvUGxhaW5UZXh0PjxGT05UIHNpemU9MyBmYWNlPUNvbnNvbGFzPkhpIGFsbCw8L0ZPTlQ+
PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48
Rk9OVCBzaXplPTMgZmFjZT1Db25zb2xhcz4mbmJzcDsmbmJzcDsmbmJzcDsgKzEgc3VwcG9ydCBh
bGwgb2YgdGhlbSB0byBiZWNvbWUgV0cgZHJhZnQuPC9GT05UPjwvUD4NCjxQIHN0eWxlPSJNQVJH
SU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PD94bWw6bmFtZXNwYWNlIHByZWZp
eCA9IG8gbnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiAvPjxv
OnA+PEZPTlQgc2l6ZT0zIGZhY2U9Q29uc29sYXM+Jm5ic3A7PC9GT05UPjwvbzpwPjwvUD4NCjxQ
IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgc2l6
ZT0zIGZhY2U9Q29uc29sYXM+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZuYnNwO1l1YW5jaGFvIFN1PC9GT05UPjwvUD48QlI+PEJSPjwvU1BBTj48U1BBTiBpZD11bmRl
clNpZ24+PC9TUEFOPjxTUEFOIGlkPWNvbnRlbnRfb2xkPjwvU1BBTj48QlI+PEJSPjxCUj48QlI+
PC9ESVY+PC9URD4NCjxURCBzdHlsZT0iV0lEVEg6IDBweDsgT1ZFUkZMT1c6IGhpZGRlbiIgbm9X
cmFwPjwvVEQ+PC9UUj4NCjxUUj4NCjxURCBjbGFzcz1ib3R0b21MIG5vV3JhcD48L1REPg0KPFRE
IHN0eWxlPSJXSURUSDogMTAwJTsgSEVJR0hUOiAwcHg7IE9WRVJGTE9XOiBoaWRkZW4iIG5vV3Jh
cCBhbGlnbj1taWRkbGU+PC9URD4NCjxURCBjbGFzcz1ib3R0b21SIG5vV3JhcD48L1REPjwvVFI+
PC9UQk9EWT48L1RBQkxFPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQo8U1RZTEUgdHlwZT10
ZXh0L2Nzcz4NCnRkLHAgeyBmb250LXNpemU6MTJweDt9DQo8L1NUWUxFPg==
------=_Part_948_17253235.1314153658960--


From xing@cernet.edu.cn  Tue Aug 23 20:01:10 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9418521F8B5C for ; Tue, 23 Aug 2011 20:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.565
X-Spam-Level: 
X-Spam-Status: No, score=-99.565 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VblZk1QRU4dG for ; Tue, 23 Aug 2011 20:01:10 -0700 (PDT)
Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 97A7521F8B4C for ; Tue, 23 Aug 2011 20:01:09 -0700 (PDT)
Received: from [127.0.0.1]([202.71.135.194]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm444e549305; Wed, 24 Aug 2011 11:02:09 +0800
Message-ID: <4E5469A8.7060000@cernet.edu.cn>
Date: Wed, 24 Aug 2011 11:02:00 +0800
From: Xing Li 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
References: <4E53CAA9.3000702@skoberne.net>
In-Reply-To: <4E53CAA9.3000702@skoberne.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: fFPjDw0B
Cc: draft-dec-stateless-4v6-02@tools.ietf.org, Olaf Maennel , draft-xli-behave-divi@tools.ietf.org, "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org, Iain Phillips 
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 03:01:10 -0000

于 2011/8/23 23:43, Nejc Ĺ koberne 写é“:
> Dear authors,
>
> In I-D.dec-stateless-4v6-02 there is a table on page 11, which says that
> IPv4 Header Checksum needs to be recalculated in stateless translation
> IPv4 address sharing solutions. Does this mean that _only_ the IPv4 header
> checksum should be recalculated?

When we develop and deploy dIVI, for the 1st and 2nd IPv4/IPv6 
translators, we recalculte the transport layer checksum, as stated in 
RFC6145.

(1) In the IPv4/IPv6 translator, the transport layer checksum MUST be 
recalculated during the translation process (exception is using checksum 
neutral address) in order to generate legal IPv6 packets.
(2) The transport layer checksum calculation is acceptable even for the 
performance considerations (compare with LSN, CGN).
(3) Dual translation and single translation can be mixed in some 
deployment scenarios, so the IPv6 packets must contain the right 
transport layer checksum.

Regards,

xing


> This is how I see it:
>
> Practically, the answer could maybe be yes. In each traversal of a packet through
> double stateless translation, there could be just one IPv4 header recalculation,
> always in the second translation process, where the IPv4 header is put back
> on.
>
> However, RFC 6145 says:
>
>     The original IPv4 header on the
>     packet is removed and replaced by an IPv6 header, and the transport
>     checksum is updated as needed, if that transport is supported by the
>     translator.
>
> This means, since the I-D.dec-stateless-4v6-02 (and the same goes for
> I-D.xli-behave-divi-03, of course) refers to RFC 6145, that transport-layer
> checksum recalculation should also be performed. Which causes a significant
> performance impact (we need to include whole packets including packets to
> do checksum recalculation). So in this case, we would have 1 IPv4 checksum
> recalculation and 2 TCP/UDP checksum recalculations for every packet
> traversal through the mechanism.
>
> But since we know, that these packets will be translated two times in a row,
> we could just avoid the TCP/UDP recalculation, I guess? Would this work?
>
> I guess that devices in between the CPE and AFTR then shouldn't do any
> transport-layer processing, since this would probably be fatal for such
> "invalid" packets. So having any IDS/IPS/stateful firewall devices in the
> access network would cause issues?
>
> However, if this is not possible, then I think that I-D.dec-stateless-4v6-02
> should also state that UDP/TCP Header Checksum recalculation has to be
> performed.
>
> Thanks,
> Nejc
>
>


From 13301168516@189.cn  Tue Aug 23 22:28:15 2011
Return-Path: <13301168516@189.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6882421F8BBD for ; Tue, 23 Aug 2011 22:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.457
X-Spam-Level: ***
X-Spam-Status: No, score=3.457 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=1.399, FROM_STARTS_WITH_NUMS=1.499, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2VPHL7MXQ7h for ; Tue, 23 Aug 2011 22:28:14 -0700 (PDT)
Received: from 189.cn (mta.189.cn [121.14.53.137]) by ietfa.amsl.com (Postfix) with ESMTP id BC90A21F8BBB for ; Tue, 23 Aug 2011 22:28:13 -0700 (PDT)
HMM_SOURCE_IP: 10.62.8.17:54766.177661186
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from ctbri-wangqian (as7.inner-189.cn [10.62.8.17]) by 189.cn (HERMES) with ESMTP id F18A62A4012 for ; Wed, 24 Aug 2011 13:29:21 +0800 (CST)
Received: from ctbri-wangqian ([219.142.42.9]) by 189CN(Yuwen filter gate 10.62.8.17) with ESMTP id 1314163759.1237 for softwires@ietf.org. ; Wed Aug 24 13:29:22 2011
0/X-Total-Score: 5:
X-FILTER-SCORE: to=, score=<1314163762QRHIfgPbcdQQgQQPQQbQQciE/th9T7uLii9iiTii7iiu> 
Date: Wed, 24 Aug 2011 13:29:17 +0800
From: "13301168516" <13301168516@189.cn>
To: "softwires" 
Message-ID: <201108241329163125469@189.cn>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon481772681215_====="
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 05:28:15 -0000

This is a multi-part message in MIME format.

--=====003_Dragon481772681215_=====
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi, all 

    I support all of the 5 drafts as softwire WG documents.

Best Regards
Qian Wang 

--=====003_Dragon481772681215_=====
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit







Hi, all 


 


    I support all of the 5 drafts as softwire WG 
documents.


 


Best Regards


Qian Wang 




 


 


 


--=====003_Dragon481772681215_=====--


From mohamed.boucadair@orange-ftgroup.com  Tue Aug 23 23:42:29 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89A21F8B3B for ; Tue, 23 Aug 2011 23:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.888
X-Spam-Level: 
X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4L-vybPcULh for ; Tue, 23 Aug 2011 23:42:28 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 736B921F8B3C for ; Tue, 23 Aug 2011 23:42:27 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D69643B40F1; Wed, 24 Aug 2011 08:43:36 +0200 (CEST)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BADDD35C072; Wed, 24 Aug 2011 08:43:36 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 24 Aug 2011 08:43:36 +0200
From: 
To: Tina TSOU , "softwires@ietf.org" 
Date: Wed, 24 Aug 2011 08:43:35 +0200
Thread-Topic: Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMYTdUSUw9NjVHm0mqk4ZZAfKXSpUprIKggAHhCHA=
Message-ID: <94C682931C08B048B7A8645303FDC9F35166FB809D@PUEXCB1B.nanterre.francetelecom.fr>
References: 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.31.105417
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 06:42:29 -0000

Hi Tina,

Thank you very much for reviewing carefully this document.

Your editorial suggestions will be considered when we will generate the nex=
t revision of the I-D.=20

As for the comment about the co-location of the MLD Querier and mAFTR, this=
 is a deployment scenario among others. The I-D only discusses that case. P=
lease keep in mind this I-D defines "functional elements" and not "nodes".

Cheers,
Med


-----Message d'origine-----
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Tina TSOU
Envoy=E9 : mardi 23 ao=FBt 2011 03:58
=C0 : softwires@ietf.org
Objet : [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi all,
In IETF-81, the chairs asked the authors of different drafts on multicast s=
it together to discuss and compromise. So we did.

Here are some comments on draft-qin-softwire-dslite-multicast-04.

Overall: if this is to be a Standards Track document, the whole document=20
has to be reviewed, the normative parts identified, and requirements=20
language substituted for the current descriptive language.

Section 1:

Editorial: at the end of the second paragraph, "vastly consumed" reads=20
better in English as: "consumed in vast quantities".

Substantive: add the following to the sentence making up the third=20
paragraph:

"..., which prevents these consequences by making use of the native=20
multicast capabilities of the intervening IPv6 network."

Section 2:

Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply=20
aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)".

Substantive(?): In the description of the Multicast B4, it would make=20
more sense to change "... which is able to enforce ..." to "... which=20
implements ...".

Section 3.2:

Bullet 1: the second sentence jams two unrelated ideas together. It=20
needs a little expansion to read properly. The next sentence doesn't=20
make sense within the stated scope of the bullet and shouldn't be there.=20
The suggested changed text is thus:

   "A viable scenario for this use case in DS-Lite environment: customers
    with legacy receivers must continue to access the IPv4-enabled
    multicast services.  This means the traffic should be accessed
    through IPv4 and additional functions are needed to traverse the
    operator's IPv6- enabled network. It is the purpose of this
    document to describe those functions.  Refer to [I-D.jaclee-behave-
    v4v6-mcast-ps] for the deployment considerations."

Final paragraph: don't you need a final sentence saying something like:=20
"Depending on the specific details of the contract, this may mean that=20
the specific framing of the content packets (as IPv4 packets) must be=20
preserved along with the content within that framing."

Section 4:

First paragraph: the following sentences need to be added after the=20
first one to give a full picture of what is required for a solution:

"For multicast, in contrast, separate mechanisms are required to process=20
the outgoing multicast signalling packets and the incoming packets of=20
content. The multicast signalling needs to be interworked to IPv6 and=20
processed as IPv6 signalling. For incoming multicast content, this=20
document defines ..."

Middle paragraph: why doesn't it simply read:

"See Section 4.3 for multicast distribution tree establishment and=20
Section 4.4 for multicast traffic forwarding."

Section 4.2

Third paragraph typo: mPrefixe64 -> mPrefix64

Section 4.3

Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That=20
would cause the native IPv6 multicast infrastructure to be bypassed. It=20
is also inconsistent with the architectural figure. Delete the first=20
bullet and merge the second one with the next paragraph, like this:

"The mAFTR should process the received PIMv6 Join message for the=20
IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join=20
message. It creates an entry for the IPv6 multicast group address in its=20
multicast Routing Information Base. This entry is used to forward ..."

Section 4.5

It is not clear whether the final paragraph is talking about the mB4+B4=20
or the mAFTR+AFTR or both. In fact, it makes good sense to combine the=20
mB4 and the B4, but combining the AFTR and mAFTR would be questionable=20
for reasons of scalability. There may be routing issues to sort out=20
regarding reachability of the IPv4 prefix that is shared by the source=20
-- the multicast routers should choose the path leading through the=20
mAFTR rather than the one going through the AFTR.

No more comments up to section 7. Maybe more comments from section 7=20
onwards in a separate E-mail.

Regards,
Tina
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

From mohamed.boucadair@orange-ftgroup.com  Tue Aug 23 23:53:18 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C745221F8A57 for ; Tue, 23 Aug 2011 23:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level: 
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLirMSws9f04 for ; Tue, 23 Aug 2011 23:53:18 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 997CF21F8A56 for ; Tue, 23 Aug 2011 23:53:16 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D43381B84FD; Wed, 24 Aug 2011 08:54:24 +0200 (CEST)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BE50738404A; Wed, 24 Aug 2011 08:54:24 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 24 Aug 2011 08:54:24 +0200
From: 
To: Tina TSOU , Jacni Qin 
Date: Wed, 24 Aug 2011 08:54:23 +0200
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: Acxh8St91klaU/mcRO6BhyFk9RPqPf//jGgA//9mLTD//oHFwA==
Message-ID: <94C682931C08B048B7A8645303FDC9F35166FB80A9@PUEXCB1B.nanterre.francetelecom.fr>
References:   
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F35166FB80A9PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.24.10015
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 06:53:18 -0000

--_000_94C682931C08B048B7A8645303FDC9F35166FB80A9PUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Tina,

Please see inline.

Cheers,
Med

________________________________
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Tina TSOU
Envoy=E9 : mercredi 24 ao=FBt 2011 04:21
=C0 : Jacni Qin
Cc : softwires@ietf.org
Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Jacni,
Thank you for your early reply. Have a good day.
My replies are below.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: Tuesday, August 23, 2011 6:09 PM
To: Tina TSOU
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

hi,
On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU > wrote:
Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there any consideration of interaction with unicast sol=
utions, e.g., potential collocation or reuse of functions? Do we need some =
mapping or interaction table of the function elements or tunnels (IP-in-IP =
or IP-in-non-IP) to show the relationship with DS-Lite unicast solution?

Jacni>: As Yiu mentioned in another email, the co-location with unicast DS-=
Lite elements is more deployment specific, and I'm ok to remove the section=
 4.5. From the protocol perspective, I don't see there is necessary interac=
tion with the unicast solution.
[TT] Section 4.5 is good for the readers to understand the difference betwe=
en unicast and multicast DS-Lite. I strongly suggest add some texts into th=
is section like "the co-location of multicast elements with unicast DS-Lite=
 elements is more deployment specific".

[Med] OK. We will do.
#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64, s=
o mB4 could not determine whether to de-capsulate the packets only based on=
 mPrefix64 and uPrefix64. Propose to change as "it checks whether the group=
 address is in the range of mPrefix64, the source address is in the range o=
f uPrefix64 and whether the next header of IPv6 header is 4."

Jacni>:Currently, we only employ the encapsulation for date forwarding in t=
he main text.
[TT] I am not talking about translation solution in the main text. Even if =
in the encapsulation case, mB4 needs to determine whether to make de-capsul=
ation or not.

[Med] This excerpt from Section 6.2 explains the rule to follow:

   When the mB4 receives an IPv6 multicast packet, it checks whether the
   group address is in the range of mPrefix64 and the source address is
   in the range of uPrefix64.

Does this answer your question?

--_000_94C682931C08B048B7A8645303FDC9F35166FB80A9PUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Tina,


 


Please see inline.


 


Cheers,


Med






De : softwires-bounces@ietf.org=20
[mailto:softwires-bounces@ietf.org] De la part de Tina=20
TSOU
Envoy=E9 : mercredi 24 ao=FBt 2011 04:21
=C0 =
;:=20
Jacni Qin
Cc : softwires@ietf.org
Objet : Re:=
=20
[Softwires] Comments on=20
draft-qin-softwire-dslite-multicast-04







Hi=20
Jacni,


Thank=20
you for your early reply. Have a good day.


My=20
replies are below.


 =



Best=20
Regards,


Tina=20
TSOU


http://tina=
tsou.weebly.com/contact.html


 =



 



From:=20
Jacni Qin [mailto:jacniq@gmail.com] 
Sent: Tuesday, August 23, 20=
11=20
6:09 PM
To: Tina TSOU
Cc:=20
softwires@ietf.org
Subject: Re: [Softwires] Comments on=20
draft-qin-softwire-dslite-multicast-04


 


hi,




On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com>=20
wrote:


Hi all,
Some more comments on=20
draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there =
any=20
consideration of interaction with unicast solutions, e.g., potential colloc=
ation=20
or reuse of functions? Do we need some mapping or interaction table of the=
=20
function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relatio=
nship=20
with DS-Lite unicast solution?




 




Ja=
cni>:=20
As Yiu mentioned in another email, the co-location with unicast DS-Lite ele=
ments=20
is more deployment specific, and I'm ok to remove the section 4.5. From the=
=20
protocol perspective, I don't see there is necessary interaction with the <=
SPAN=20
class=3DSpellE>unicast solution.


[TT]=20
Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I=20
strongly suggest add some texts into this section like =93the co-location o=
f=20
multicast elements with unicast DS-Lite elements is more deployment=20
specific=94.



[Med] OK. We will do.


  
#2
Section 6.2
Translation and encapsulation b=
oth=20
  uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether=
 to=20
  de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose t=
o=20
  change as "it checks whether the group address is in the range of mPrefix=
64,=20
  the source address is in the range of uPrefix64 and whether the next head=
er of=20
  IPv6 header is 4."





Jacni>:Currently, we only =
employ=20
the encapsulation for date forwarding in the main text.
[TT] I am not talk=
ing=20
about translation solution in the main text. Even if in the encapsulation c=
ase,=20
mB4 needs to determine whether to make de-capsulation or not.

[Med] This excerpt from Section 6.2 explains the =
rule to=20
follow:
   When the mB4 receives an =
IPv6 multicast packet, it checks whether the
   group address is in the range of mPrefix64 and the source address is
   in the range of uPrefix64.
Does this answer your question?
=



--_000_94C682931C08B048B7A8645303FDC9F35166FB80A9PUEXCB1Bnante_--

From nejc@skoberne.net  Wed Aug 24 02:28:26 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB78621F8888 for ; Wed, 24 Aug 2011 02:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.21
X-Spam-Level: 
X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e2-SVyXW4dr for ; Wed, 24 Aug 2011 02:28:26 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2045821F84CB for ; Wed, 24 Aug 2011 02:28:25 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id DB16922787A0; Wed, 24 Aug 2011 11:29:33 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4F5oqPQYoQO; Wed, 24 Aug 2011 11:29:33 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 02C92227879F; Wed, 24 Aug 2011 11:29:32 +0200 (CEST)
Message-ID: <4E54C47E.5090706@skoberne.net>
Date: Wed, 24 Aug 2011 10:29:34 +0100
From: =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Wentao Shang 
References: <4E53CAA9.3000702@skoberne.net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: draft-dec-stateless-4v6-02@tools.ietf.org, Olaf Maennel , draft-xli-behave-divi@tools.ietf.org, "softwires@ietf.org" , draft-murakami-softwire-4v6-translation@tools.ietf.org, Iain Phillips 
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 09:28:27 -0000

Dear Wentao,

> If translator does not touch the TCP/UDP header, yes.
> However, if translator wants to do NAPT, which is not uncommon, then
> at least one recal. is needed (i.e. before the packet is finally
> handed to the receiver).

The idea is, that the NAPT44 is done before the first stateless NAT64
process, so this is a completely separate issue. Of course, recalculation
is mandatory in the NAPT44 part. I am just discussing the stateless
NAT64 part.

> Agree. I think transmitting packets with invalid TCP checksum field is
> dangerous.
> Stateful NAT is ubiquitous nowadays.

Simon? How was the conclusion, "that the transport checksum does not 
need to be modified", reached?

> Besides, the purpose of checksum is to do error checking. So sending
> packets with wrong checksum does not make sense. (How could the
> translator itself checks the integrity of the packet, if it wants to?)

Good point. Anyone?

Thanks,
Nejc

From nejc@skoberne.net  Wed Aug 24 03:20:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D078D21F84F7 for ; Wed, 24 Aug 2011 03:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level: 
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOt2KunMLS4M for ; Wed, 24 Aug 2011 03:20:54 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id D483521F8514 for ; Wed, 24 Aug 2011 03:20:53 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 2B490227879F; Wed, 24 Aug 2011 12:21:59 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApENqclMgY+S; Wed, 24 Aug 2011 12:21:56 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 523DF227878E; Wed, 24 Aug 2011 12:21:56 +0200 (CEST)
Message-ID: <4E54D0C6.2050600@skoberne.net>
Date: Wed, 24 Aug 2011 11:21:58 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Simon Perreault 
References: <4E53CAA9.3000702@skoberne.net> <4E53DD0E.3020507@viagenie.ca> <4E543110.5090108@skoberne.net> <4E54327B.4030701@viagenie.ca>
In-Reply-To: <4E54327B.4030701@viagenie.ca>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 10:20:54 -0000

Dear Simon,

>>> A consequence is that the 4rd address
>>> scheme does not need to care about checksum neutrality (contrary to e.g. NAT64
>>> and NAT66).
>>
>> Sorry, but I don't understand this. Can you please paraphrase?
> 
> Please refer to:
> http://tools.ietf.org/html/rfc6052#section-4.1
> http://tools.ietf.org/html/rfc6296#section-2.6

Please correct me if I am wrong:

- The RFC 6145-compliant stateless NAT64 solutions do not have to 
  recalculate transport-layer checksums if and only if the Well-Known
  Prefix or a checksum-neutral Network-Specific Prefix is used and
  if the suffix is 0.

- All double stateless NAT64 solutions (dIVI, 4via6-T), since they
  can not have checksum-neutral IPv6 addresses (because they also
  encode port-set ID) MUST recalculate transport-layer checksums or
  else they are not RFC 6145-compliant.

So are you saying, that it is OK if we choose to not recalculate
checksums (and therefore violate RFC 6145) in
case we are sure, that there will be no transport-layer processing
between the CPE and AFTR in double stateless NAT64 scenarios?

Thanks,
Nejc

From ichiroumakino@gmail.com  Wed Aug 24 03:56:52 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DC021F8AF1 for ; Wed, 24 Aug 2011 03:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.53
X-Spam-Level: 
X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8GWOrhquzRY for ; Wed, 24 Aug 2011 03:56:51 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95921F87F0 for ; Wed, 24 Aug 2011 03:56:51 -0700 (PDT)
Received: by wyg8 with SMTP id 8so861718wyg.31 for ; Wed, 24 Aug 2011 03:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=iu3CdztBrnWkQ6FrhGDynCTZwIJW2l2EuVn0fihquKs=; b=H2vNo5sCXoNKqfePThwTPPhXT0GUJT2AvculEEYJKNC3umTiDpxQ8D3/jQ3bB4zuiY UgKHGbEp8FPpLTOZ51QJ5W0zwPqxCJz8eakSljgSpun7cJa/4FhCzu2ZpkciT1iqTkQY ixIHDW7IjpuDDTACgC2ekeGWQmWiJ1PRH7Zqw=
Received: by 10.227.42.145 with SMTP id s17mr1219244wbe.95.1314183479779; Wed, 24 Aug 2011 03:57:59 -0700 (PDT)
Received: from ams3-vpn-dhcp6859.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fb2sm741402wbb.11.2011.08.24.03.57.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 03:57:57 -0700 (PDT)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Ole Troan 
In-Reply-To: <4E541359.6000004@gmail.com>
Date: Wed, 24 Aug 2011 12:57:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B079633-3B7E-42F2-9F3F-EEDD86076AB1@employees.org>
References: <4E4B96CB.2020004@skoberne.net>  <4E4D9D97.1030500@skoberne.net> <4E4DA1C2.40307@gmail.com> <4E4ED337.3070100@skoberne.net> <4E4EEDF0.5090400@gmail.com> <4E4EF48D.6020500@skoberne.net> <4E4F34E1.3040305@gmail.com> <769C07F1-588A-4097-9317-771CBD07EFFB@laposte.net> <4E503B08.9030800@gmail.com>  <4E5184E6.9060009@gmail.com>  <4E541359.6000004@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , "draft-murakami-softwire-4v6-translation@tools.ietf.org" 
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 10:56:52 -0000

Brian,

>> The problem with static allocation is that it cannot adapt quickly to =
subscriber demand.
>=20
> Exactly; so it cannot optimise the number of ports in use.
>=20
> What strikes me in this conversation is that all these solutions are a
> tremendous amount of work to deal with legacy equipment, and I have
> to wonder whether that is economically rational. That is for the =
market
> to decide, but I don't see that the IETF is obliged to solve each
> possible case. In other words I'm not sure where to find the =
requirements
> analysis that this new burst of activity is based on.

my assumption is that this is done on a CPE, as a part of the existing =
NAT function.
legacy applications exists behind the NAT.

there are multiple implementations of the encapsulation scheme already.

cheers,
Ole

>> Dear Brian,
>> Thank you and in line...
>>=20
>>=20
>> Best Regards,
>> Tina TSOU
>> http://tinatsou.weebly.com/contact.html
>>=20
>>=20
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20
>> Sent: Sunday, August 21, 2011 3:21 PM
>> To: Tina TSOU
>> Cc: R=E9mi Despr=E9s; softwires@ietf.org; =
draft-murakami-softwire-4v6-translation@tools.ietf.org
>> Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
>>=20
>> Hi Tina,
>>=20
>> On 2011-08-21 14:08, Tina TSOU wrote:
>> ...
>>> If an average IPv4 user is consuming 200 ports (or whatever
>>> value you prefer to assume) with their favourite p2p app, that
>>> is what sets the number of IPv4 users per shared address. It's
>>> the number of simultaneous ports, not the amount of traffic,
>>> that counts.
>>> [Tina:
>>> These drafts attempt to solve this issue.
>>> https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/
>>=20
>> This doesn't create new ports; it just helps to allocate
>> them more rationally.
>> [Tina: When I see your comments about consuming 200 ports, I thought =
about the motivation of NAT-COORD is to solve the issue of one iTunes, =
Google Map application consumes 200~300 ports at a time. I did not think =
about Stateful/Stateless at that time.
>>=20
>> In the use cases you mentioned above, do you only mean static port =
allocation issue with stateless mechanisms? Or it can be either stateful =
or stateless?=20
>>=20
>> The stateless address sharing schemes (4rd and friends) allocate a =
port range to each subscriber statically. Static allocation is necessary =
for the mechanism to be stateless.
>> There are all the advantages of a stateless mechanism (see the =
motivation draft for a list of these advantages).
>>=20
>> The problem with static allocation is that it cannot adapt quickly to =
subscriber demand. If for example you have one subscriber that is =
consuming a lot of ports, you cannot assign more ports to it. Once it's =
assigned, it's static and hard to change.
>> ]
>>=20
>>> https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/
>>=20
>> If I understand this correctly, it avoids NAT444 (which is a
>> good thing, and would make
>> draft-weil-shared-transition-space-request unnecessary). But
>> again, it doesn't create new ports or new public IPv4 addresses,
>> which was my point.
>>=20
>> 4rd and 4via6 share this property of course.
>>=20
>>   Brian
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From simon.perreault@viagenie.ca  Wed Aug 24 05:36:24 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DE421F8801 for ; Wed, 24 Aug 2011 05:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvfq3Eu7ymap for ; Wed, 24 Aug 2011 05:36:24 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 19EFB21F858D for ; Wed, 24 Aug 2011 05:36:24 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4490820CC2 for ; Wed, 24 Aug 2011 08:37:34 -0400 (EDT)
Message-ID: <4E54F08D.9080002@viagenie.ca>
Date: Wed, 24 Aug 2011 08:37:33 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E53CAA9.3000702@skoberne.net>  <4E54C47E.5090706@skoberne.net>
In-Reply-To: <4E54C47E.5090706@skoberne.net>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 12:36:24 -0000

On 2011-08-24 05:29, Nejc Škoberne wrote:
>> Agree. I think transmitting packets with invalid TCP checksum field is
>> dangerous.
>> Stateful NAT is ubiquitous nowadays.
> 
> Simon? How was the conclusion, "that the transport checksum does not 
> need to be modified", reached?

Look, this is a deployment issue. It is simple.

X ----> NAT64 --------> NAT46 ----> Y

(Assume NAT46 is the exact reverse of NAT64.)

There are two cases:

- If there is no layer 4 processing (stateful firewall, DPI, etc.)
taking place between NT64 and NAT46, then there is no need to update the
layer 4 checksum at NAT64 and NAT46.

- Otherwise, then the layer 4 checksum needs updating.

Is there anything worth arguing about this?

>> Besides, the purpose of checksum is to do error checking. So sending
>> packets with wrong checksum does not make sense. (How could the
>> translator itself checks the integrity of the packet, if it wants to?)
> 
> Good point. Anyone?

The translator does not check the layer 4 checksum. Doing so would be
very wrong. It would also imply statefulness because the translator
would need to reassemble fragments. Layer 4 checksum validation is done
end-to-end, not hop-by-hop. Compare this with layer 3 checksum
validation which is done hop-by-hop (and was eliminated with IPv6
because end-to-end checksum is sufficient).

See RFC 6145 for the details for the translation algorithm. There is no
layer 4 checksum validation nor fragment reassembly. Fragment reassembly
is described for the stateful translation algorithm, in RFC 6146. The
translation algorithm we're considering for 4rd is of course stateless
and corresponds to RFC 6145.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From nejc@skoberne.net  Wed Aug 24 05:42:28 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7996B21F8A4D for ; Wed, 24 Aug 2011 05:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.215
X-Spam-Level: 
X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.084,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD68mRvR7R7W for ; Wed, 24 Aug 2011 05:42:28 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id D3B2121F8A35 for ; Wed, 24 Aug 2011 05:42:27 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 52940227878B; Wed, 24 Aug 2011 14:43:37 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlKqPUtK+iFn; Wed, 24 Aug 2011 14:43:36 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 367252278783; Wed, 24 Aug 2011 14:43:36 +0200 (CEST)
Message-ID: <4E54F1F9.9080609@skoberne.net>
Date: Wed, 24 Aug 2011 13:43:37 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: softwires@ietf.org
References: <4E53CAA9.3000702@skoberne.net>  <4E54C47E.5090706@skoberne.net> <4E54F08D.9080002@viagenie.ca>
In-Reply-To: <4E54F08D.9080002@viagenie.ca>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 12:42:28 -0000

Dear Simon,

> Is there anything worth arguing about this?

No, if violating RFC 6145 in such conditions is acceptable, there is
nothing worth arguing about this. I am new here, so I just don't know.

Thanks for your clarifications, it's just that I would like to understand
all these details in order to make as thorough as possible a comparison
of all these mechanisms.

Nejc

From simon.perreault@viagenie.ca  Wed Aug 24 05:50:49 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA0521F85EC for ; Wed, 24 Aug 2011 05:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqw7aA5LrHv7 for ; Wed, 24 Aug 2011 05:50:49 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id F1CB621F856B for ; Wed, 24 Aug 2011 05:50:47 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2FD8121F0A for ; Wed, 24 Aug 2011 08:51:58 -0400 (EDT)
Message-ID: <4E54F3ED.5020701@viagenie.ca>
Date: Wed, 24 Aug 2011 08:51:57 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References: 
In-Reply-To: 
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 12:50:49 -0000

On 2011-08-20 10:21, Yong Cui wrote:
> 4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/

I support this one. It's the right way to do multicast over DS-Lite.
There is a lot of tweaking left to do (I would expect iteration over
many revisions), but the basic idea is right and we should adopt this.

> 5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
> http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
> vation/

I support this one too. The motivation is clearly explained and makes
sense. This working group needs to adopt this draft to make clear that
we acknowledge the need and will work on a solution.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Wed Aug 24 05:58:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C753721F8ABD for ; Wed, 24 Aug 2011 05:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa+-vHtuIhE5 for ; Wed, 24 Aug 2011 05:58:44 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3084621F8876 for ; Wed, 24 Aug 2011 05:58:44 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7A10020CC2; Wed, 24 Aug 2011 08:59:54 -0400 (EDT)
Message-ID: <4E54F5CA.1030106@viagenie.ca>
Date: Wed, 24 Aug 2011 08:59:54 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: =?windows-1252?Q?Nejc_=8Akoberne?= 
References: <4E53CAA9.3000702@skoberne.net> <4E53DD0E.3020507@viagenie.ca> <4E543110.5090108@skoberne.net> <4E54327B.4030701@viagenie.ca> <4E54D0C6.2050600@skoberne.net>
In-Reply-To: <4E54D0C6.2050600@skoberne.net>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: softwires@ietf.org
Subject: Re: [Softwires] Double stateless NAT64 and checksum recalculation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 12:58:44 -0000

On 2011-08-24 06:21, Nejc Škoberne wrote:
> Dear Simon,
> 
>>>> A consequence is that the 4rd address
>>>> scheme does not need to care about checksum neutrality (contrary to e.g. NAT64
>>>> and NAT66).
>>>
>>> Sorry, but I don't understand this. Can you please paraphrase?
>>
>> Please refer to:
>> http://tools.ietf.org/html/rfc6052#section-4.1
>> http://tools.ietf.org/html/rfc6296#section-2.6
> 
> Please correct me if I am wrong:
> 
> - The RFC 6145-compliant stateless NAT64 solutions do not have to 
>   recalculate transport-layer checksums if and only if the Well-Known
>   Prefix or a checksum-neutral Network-Specific Prefix is used and
>   if the suffix is 0.

Right.

> - All double stateless NAT64 solutions (dIVI, 4via6-T), since they
>   can not have checksum-neutral IPv6 addresses (because they also
>   encode port-set ID) MUST recalculate transport-layer checksums or
>   else they are not RFC 6145-compliant.

First, I think it would be feasible to change the 4rd address scheme so
that the IPv6 prefix is checksum-neutral, even with encoding the port
set ID. But it would be super complex, so I'm not pursuing this idea
further.

Second, I don't like the term "RFC 6145-compliant". In the 4rd-T draft
one could specify that the RFC6145 algorithm is used with the exception
that the transport checksum is not updated. There is no "compliance"
involved. We're free to specify that if it makes sense.

> So are you saying, that it is OK if we choose to not recalculate
> checksums (and therefore violate RFC 6145) in
> case we are sure, that there will be no transport-layer processing
> between the CPE and AFTR in double stateless NAT64 scenarios?

Once again, I dislike the "violate" term. If the exception is written in
a hypothetic 4rd-T RFC, then we're fine and nobody's violating anything.

Beyond that remark, yes, that's exactly what I'm saying.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Wed Aug 24 06:04:11 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B4021F8AD9 for ; Wed, 24 Aug 2011 06:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by4mI-hAWaVE for ; Wed, 24 Aug 2011 06:04:11 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1121F8797 for ; Wed, 24 Aug 2011 06:04:10 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 362DD21F50 for ; Wed, 24 Aug 2011 09:05:21 -0400 (EDT)
Message-ID: <4E54F710.6030900@viagenie.ca>
Date: Wed, 24 Aug 2011 09:05:20 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0
MIME-Version: 1.0
To: softwires@ietf.org
References:  <4E54F3ED.5020701@viagenie.ca>
In-Reply-To: <4E54F3ED.5020701@viagenie.ca>
X-Enigmail-Version: 1.2.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 13:04:11 -0000

On 2011-08-24 08:51, Simon Perreault wrote:
> On 2011-08-20 10:21, Yong Cui wrote:
>> 4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
>> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
> 
> I support this one. It's the right way to do multicast over DS-Lite.
> There is a lot of tweaking left to do (I would expect iteration over
> many revisions), but the basic idea is right and we should adopt this.

Actually, I just thought about this a bit more, and I have a question.

As I said, this draft has a lot of tweaking left to do. At the moment it
is very underspecified. IMHO you could not give this to two
implementation teams and obtain interoperable results.

Part of what is left to specify falls squarely within the multrans
proposed charter.

So I would prefer to see the multrans BoF become a WG and see this draft
be adopted by multrans, while softwire focuses on non-multicast stuff.

But this document needs to be adopted somewhere.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From rajiva@cisco.com  Wed Aug 24 08:01:36 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10021F8AFF for ; Wed, 24 Aug 2011 08:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level: 
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy-bhaKTNm4P for ; Wed, 24 Aug 2011 08:01:35 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 934FB21F8AAA for ; Wed, 24 Aug 2011 08:01:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1460; q=dns/txt; s=iport; t=1314198166; x=1315407766; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ZUxDaSe1BZGGXS6Yq7i3/HdYr/QUG7985f7aYkE3Idg=; b=OaacUj+uIgWjmbPBsiJgG3WOkRtsj3pD8Kj5qga/1qIiRAZq+XbupfIE kaUyChRoReucRYwqqIdJwfmFiIeODJWsa4vlf66X5T1R9+u6+eAFEPBUq tqWpOz8nxO/qR7ThhqZ3VFdPBxkdwY6jCGkz2WSPDSL6eYdTWW5I95I2/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtQHAFERVU6tJV2c/2dsb2JhbABCmGKPFXeBQAEBAQECAQEBAQ8BHQo0EAsCAQgYCgYYBgEmMAEBBBMIEweHTwScbQGfO4VqXwSHYZBOjAM
X-IronPort-AV: E=Sophos;i="4.68,275,1312156800"; d="scan'208";a="16069359"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 24 Aug 2011 15:02:46 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7OF2kdD018585 for ; Wed, 24 Aug 2011 15:02:46 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 24 Aug 2011 10:02:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Aug 2011 10:02:45 -0500
Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBCD27@XMB-RCD-111.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] New working group documents
Thread-Index: AcxhhJoRzoO41TxQT+iDOV+DjULHpgA2ontw
References:  
From: "Rajiv Asati (rajiva)" 
To: 
X-OriginalArrivalTime: 24 Aug 2011 15:02:46.0124 (UTC) FILETIME=[E1CE9AC0:01CC626E]
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 15:01:36 -0000

Yes for 5 and 4.


> On 20 August 2011 16:21, Yong Cui  wrote:
>=20
>=20
> 	Hi folks,
>=20
> 	Following our rough concensus during Quebec City meeting and
> 	according to our charter/milestones, the chairs would like to
> 	ask the mailing list for the confirmation to adopt the following
> 	drafts:
>=20
> 	1. Deployment Considerations for Dual-Stack Lite
>
http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
>=20
>=20
> 	2. Public IPv4 over Access IPv6 Network
> 	http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
>=20
> 	3. Softwire Mesh Multicast
>
http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
>=20
> 	4. Multicast Extensions to DS-Lite Technique in Broadband
Deployments
>
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
>=20
> 	5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
>
http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-
> moti
> 	vation/
 stateless-4v6-moti%0Avation/>
>=20
> 	Please send your comments by 10am EDT on Aug 27. If you object
to
> 	adoption, please also give the detailed reasons.
>=20
>=20
>=20
> 	--Alain & Yong
>=20
>=20
> 	_______________________________________________
> 	Softwires mailing list
> 	Softwires@ietf.org
> 	https://www.ietf.org/mailman/listinfo/softwires
>=20
>=20


From Tina.Tsou.Zouting@huawei.com  Wed Aug 24 11:24:39 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADAD21F8B38 for ; Wed, 24 Aug 2011 11:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.195
X-Spam-Level: 
X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.403,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klbVnAsIdeVa for ; Wed, 24 Aug 2011 11:24:35 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BE55721F8997 for ; Wed, 24 Aug 2011 11:24:34 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQG00JMP36WIG@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 25 Aug 2011 02:25:45 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQG00LQU36T44@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 25 Aug 2011 02:25:44 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK07639; Thu, 25 Aug 2011 02:25:44 +0800 (CST)
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 25 Aug 2011 02:24:38 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 25 Aug 2011 02:25:39 +0800
Date: Wed, 24 Aug 2011 18:25:39 +0000
From: Tina TSOU 
In-reply-to: <94C682931C08B048B7A8645303FDC9F35166FB80A9@PUEXCB1B.nanterre.francetelecom.fr>
X-Originating-IP: [10.193.34.145]
To: "mohamed.boucadair@orange-ftgroup.com" , Jacni Qin 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_zOqPq9veZBMAZ2a0GM+0uw)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-index: Acxh8St91klaU/mcRO6BhyFk9RPqPf//jGgA//9mLTD//oHFwP/8QTPQ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    <94C682931C08B048B7A8645303FDC9F35166FB80A9@PUEXCB1B.nanterre.francetelecom.fr>
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 18:24:39 -0000

--Boundary_(ID_zOqPq9veZBMAZ2a0GM+0uw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Bonjour Med,
Ca va? Thank you for your deep insight and reply.
When the IPv6 packet comes, how does mB4 know it should make encapsulation =
or translation if mPrefix64 and uPrefix64 are the same? As defined in secti=
on 6.3 of draft-boucadair-behave-64-multicast-address-format, "there is no need to reserve a bit in the I=
Pv6 multicast address to separate between the translation and the encapsula=
tion schemes." So when mPrefix64 and uPrefix64 are the same for both encaps=
ulation and translation, mB4 could not make decision which operation to mak=
e. In this case, the IPv6 header itself can be used to identify encapsulati=
on or translation. For example, if the next header of IPv6 header is 4, mB4=
 should make de-capsulation because there is IPv4 packet inside. If it is o=
ther value, translation may be needed.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh=
alf Of mohamed.boucadair@orange-ftgroup.com
Sent: Tuesday, August 23, 2011 11:54 PM
To: Tina TSOU; Jacni Qin
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Tina,

Please see inline.

Cheers,
Med

________________________________
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Tina TSOU
Envoy=E9 : mercredi 24 ao=FBt 2011 04:21
=C0 : Jacni Qin
Cc : softwires@ietf.org
Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Jacni,
Thank you for your early reply. Have a good day.
My replies are below.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: Tuesday, August 23, 2011 6:09 PM
To: Tina TSOU
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

hi,
On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU > wrote:
Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there any consideration of interaction with unicast sol=
utions, e.g., potential collocation or reuse of functions? Do we need some =
mapping or interaction table of the function elements or tunnels (IP-in-IP =
or IP-in-non-IP) to show the relationship with DS-Lite unicast solution?

Jacni>: As Yiu mentioned in another email, the co-location with unicast DS-=
Lite elements is more deployment specific, and I'm ok to remove the section=
 4.5. From the protocol perspective, I don't see there is necessary interac=
tion with the unicast solution.
[TT] Section 4.5 is good for the readers to understand the difference betwe=
en unicast and multicast DS-Lite. I strongly suggest add some texts into th=
is section like "the co-location of multicast elements with unicast DS-Lite=
 elements is more deployment specific".

[Med] OK. We will do.
#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64, s=
o mB4 could not determine whether to de-capsulate the packets only based on=
 mPrefix64 and uPrefix64. Propose to change as "it checks whether the group=
 address is in the range of mPrefix64, the source address is in the range o=
f uPrefix64 and whether the next header of IPv6 header is 4."

Jacni>:Currently, we only employ the encapsulation for date forwarding in t=
he main text.
[TT] I am not talking about translation solution in the main text. Even if =
in the encapsulation case, mB4 needs to determine whether to make de-capsul=
ation or not.

[Med] This excerpt from Section 6.2 explains the rule to follow:

   When the mB4 receives an IPv6 multicast packet, it checks whether the

   group address is in the range of mPrefix64 and the source address is

   in the range of uPrefix64.

Does this answer your question?

--Boundary_(ID_zOqPq9veZBMAZ2a0GM+0uw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable













Bonjour Med,


Ca
va? Thank you fo=
r your deep insight and reply.


When the IPv6 packet comes, how does mB4 know it should make encapsul=
ation or translation if mPrefix64 and uPrefix64 are the same?
 As defined in section 6.3 of 
draf=
t-boucadair-behave-64-multicast-address-format, “there
 is no need to reserve a bit in the IPv6 multicast address to separate=
 between the translation and the encapsulation schemes.” So when mPrefix64 and uPrefix64 are the same
 for both encapsulation and translation, mB4 could not make decision which =
operation to make. In this case, the IPv6 header itself can be used to=
 identify encapsulation or translation. For example, if the next header of =
IPv6 header is 4, mB4 should make de-capsulation
 because there is IPv4 packet inside. If it is other value, translation may=
 be needed.  




 


Bes=
t Regards,


Tin=
a TSOU


htt=
p://tinatsou.weebly.com/contact.html


 




 






From: softwires-bounces@ietf.org
 [mailto:softwires-bounces@ietf.org] On Behalf Of mohamed.boucadair@=
orange-ftgroup.com

Sent: Tuesday, August 23, 2011 11:54 PM

To: Tina TSOU; Jacni Qin

Cc: softwires@ietf.org

Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multi=
cast-04






 


Hi Tina,


 


Please see inline.


 


Cheers,


Med


 








De :
 softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la pa=
rt de Tina TSOU

Envoy=E9 : mercredi 24 ao=FBt 2011 04:21

=C0 : Jacni Qin

Cc : softwires@ietf.org

Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-m=
ulticast-04


Hi Jacni,


Thank you for your early =
reply. Have a good day.


My repli=
es are below.


&nb=
sp;


Best Reg=
ards,


Tina TSO=
U


http://t=
inatsou.weebly.com/contact.html


&nb=
sp;


 <=
/p>



From: Jacni
 Qin [mailto:jacniq@gmail.com] 

Sent: Tuesday, August 23, 2011 6:09 PM

To: Tina TSOU

Cc: softwires@ietf.org

Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multi=
cast-04




 


hi,




On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com=
> wrote:


Hi all,

Some more comments on draft-qin-softwire-dslite-multicast-04.

#1

General comment: is there any consideration of interaction with unicast sol=
utions, e.g., potential collocation or reuse of functions? Do we need some =
mapping or interaction table of the function elements or tunnels (IP-in-IP =
or IP-in-non-IP) to show the relationship
 with DS-Lite unicast solution?




 






Jacni>: As Yiu mentioned in another email, the co-loc=
ation with unicast DS-Lite elements is more deployment specific, and I'm ok=
 to remove the section 4.5. From the protocol perspective,
 I don't see there is necessary interaction with the unicast solution.


[TT] Section 4.5 is good =
for the readers to understand the difference between unicast and multicast =
DS-Lite. I strongly suggest add some texts into this section
 like “the co-location of multicast elements with unicast DS-Lite ele=
ments is more deployment specific”.




[Med] OK. We will do.






#2

Section 6.2

Translation and encapsulation both uses the same mPrefix64 and uPrefix64, s=
o mB4 could not determine whether to de-capsulate the packets only based on=
 mPrefix64 and uPrefix64. Propose to change as "it checks whether the =
group address is in the range of mPrefix64,
 the source address is in the range of uPrefix64 and whether the next heade=
r of IPv6 header is 4."








Jacn=
i>:Currently, we only employ the encapsulation for date forwarding in th=
e main text.

[TT] 
I am not talking about translation solution in the main text. Even if in th=
e encapsulation case, mB4 needs to determine whether to make de-capsulation=
 or not.



[Med] This excerpt from Section 6.2 explains the rule to f=
ollow:


 &nbs=
p; When the mB4 receives an IPv6 multicast packet, it checks whether=
 the


 &nbs=
p; group address is in the range of mPrefix64 and the source address=
 is


 &nbs=
p; in the range of uPrefix64.


Does this answer your question?=











--Boundary_(ID_zOqPq9veZBMAZ2a0GM+0uw)--

From Tina.Tsou.Zouting@huawei.com  Wed Aug 24 12:16:11 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D6B21F8B54 for ; Wed, 24 Aug 2011 12:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level: 
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIDkP0LZIUOC for ; Wed, 24 Aug 2011 12:16:09 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id E476121F8B44 for ; Wed, 24 Aug 2011 12:16:08 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQG00DIT5KUE6@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 25 Aug 2011 03:17:18 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQG00CBQ5KUTD@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 25 Aug 2011 03:17:18 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK04806; Thu, 25 Aug 2011 03:17:18 +0800 (CST)
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 25 Aug 2011 03:17:12 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Thu, 25 Aug 2011 03:16:59 +0800
Date: Wed, 24 Aug 2011 19:16:58 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: Jacni Qin 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_JMqSSJUPk853lFyQbyNsBw)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-index: Acxh8St91klaU/mcRO6BhyFk9RPqPf//jGgA//9mLTCAALEwgP/+Yf/g
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 19:16:11 -0000

--Boundary_(ID_JMqSSJUPk853lFyQbyNsBw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Dear Jacni,
Please see in line...

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: Tuesday, August 23, 2011 7:33 PM
To: Tina TSOU
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

hi,
On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU > wrote:
...
#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as "it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4."

Jacni>:Currently, we only employ the encapsulation for date forwarding in the main text.
[TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not.
Jacni>: In the case of encapsulation, the mB4 can determine that by checking whether the group address is within the mPrefix64 and the source address is within the uPrefix64, as what the 6.2 says.
[TT1] When the packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same?  In this case, the next header of IPv6 header could be used for mB4 to determine.

Cheers,
Jacni

--Boundary_(ID_JMqSSJUPk853lFyQbyNsBw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT













Dear Jacni,


Please see in line…


 


Best Regards,


Tina TSOU


http://tinatsou.weebly.com/contact.html


 


 




From: Jacni
 Qin [mailto:jacniq@gmail.com] 

Sent: Tuesday, August 23, 2011 7:33 PM

To: Tina TSOU

Cc: softwires@ietf.org

Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04




 


hi,




On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:






... 








#2

Section 6.2

Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as "it checks whether the group address is in the range of mPrefix64,
 the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4."








 




Jacni>:Currently, we only employ the encapsulation for date forwarding in the main text.




[TT]
I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not.












Jacni>: In the case of encapsulation, the mB4 can determine that by checking whether the group address is within the mPrefix64 and the source address is within
 the uPrefix64, as what the 6.2 says.

[TT1] When the packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same? 
In this case, the next header of IPv6 header could be used for mB4 to determine.



Cheers,

Jacni










--Boundary_(ID_JMqSSJUPk853lFyQbyNsBw)--

From tetsuya@ipinfusion.com  Wed Aug 24 14:25:09 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8D921F8D65 for ; Wed, 24 Aug 2011 14:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzBsZLgv4Aj2 for ; Wed, 24 Aug 2011 14:25:08 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1E1621F8D59 for ; Wed, 24 Aug 2011 14:25:08 -0700 (PDT)
Received: by ywe9 with SMTP id 9so1415278ywe.31 for ; Wed, 24 Aug 2011 14:26:18 -0700 (PDT)
Received: by 10.236.116.194 with SMTP id g42mr34199889yhh.0.1314221178104; Wed, 24 Aug 2011 14:26:18 -0700 (PDT)
Received: from [10.10.25.129] ([12.7.175.5]) by mx.google.com with ESMTPS id c63sm419162yhe.46.2011.08.24.14.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 14:26:13 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Tetsuya Murakami 
In-Reply-To: 
Date: Wed, 24 Aug 2011 14:26:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <831FBC17-51AA-4EA8-BE9A-F8B482A7FDC0@ipinfusion.com>
References: 
To: Alain Durand 
X-Mailer: Apple Mail (2.1244.3)
Cc: Ole Troan , Yong Cui , Softwires-wg list , Townsley Mark 
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 21:25:09 -0000

Hi Chairs,

We would like to have a presentation for draft-murakami-softwire-4rd-00 =
in the interim meeting in order to discuss about the stateless solution. =
Please assign a slot for this.

Thanks,
Tetsuya Murakami

On 2011/08/22, at 8:37, Alain Durand wrote:

> As we mentioned earlier, the softwire interim meeting will focus on =
'stateless solutions'. If you'd like to present there, please send the =
chairs a note by Friday this week.
>=20
> Alain.
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From jacniq@gmail.com  Wed Aug 24 17:45:27 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3227921F8BFE for ; Wed, 24 Aug 2011 17:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.413
X-Spam-Level: 
X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.185,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPkxlj8tHvyL for ; Wed, 24 Aug 2011 17:45:26 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1AB21F8BF8 for ; Wed, 24 Aug 2011 17:45:26 -0700 (PDT)
Received: by vws12 with SMTP id 12so1861922vws.31 for ; Wed, 24 Aug 2011 17:46:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o9SrUMqxqho1wunieO0S6R+tvP3DEJZrYmWvMq8Nbec=; b=PelbVmXn+Ji4oRd8zDCXGNSMUL6QMw868TYHhfr1rtdpYB+OwB5bLUaomgbAWrUTwC LAGYJpEVUvOxZiX0Vt7LTiuBkRcB1BrlGLl1sncvx5NxGrFryxK0KZ/D+s4mcsZoFWlb dLiqSYMUcvAfSkQIVhcpfvkVGVX95mEz0X0tM=
MIME-Version: 1.0
Received: by 10.52.89.146 with SMTP id bo18mr5935775vdb.246.1314233198237; Wed, 24 Aug 2011 17:46:38 -0700 (PDT)
Received: by 10.52.187.161 with HTTP; Wed, 24 Aug 2011 17:46:38 -0700 (PDT)
In-Reply-To: 
References:     
Date: Thu, 25 Aug 2011 08:46:38 +0800
Message-ID: 
From: Jacni Qin 
To: Tina TSOU 
Content-Type: multipart/alternative; boundary=bcaec50162b5eed86004ab49c293
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 00:45:27 -0000

--bcaec50162b5eed86004ab49c293
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 25, 2011 at 3:16 AM, Tina TSOU wrote:

>
>   ...
>
> #2
> Section 6.2
> Translation and encapsulation both uses the same mPrefix64 and uPrefix64,
> so mB4 could not determine whether to de-capsulate the packets only based on
> mPrefix64 and uPrefix64. Propose to change as "it checks whether the group
> address is in the range of mPrefix64, the source address is in the range of
> uPrefix64 and whether the next header of IPv6 header is 4."
>
>
>
> Jacni>:Currently, we only employ the encapsulation for date forwarding in
> the main text.
>
> [TT] I am not talking about translation solution in the main text. Even if
> in the encapsulation case, mB4 needs to determine whether to make
> de-capsulation or not.
>
> Jacni>: In the case of encapsulation, the mB4 can determine that by
> checking whether the group address is within the mPrefix64 and the source
> address is within the uPrefix64, as what the 6.2 says.
> [TT1] When the packet comes, how does mB4 know it should make encapsulation
> or translation if mPrefix64 and uPrefix64 are the same?  In this case, the
> next header of IPv6 header could be used for mB4 to determine.
>
> Jacni>: Please see again my comments above, also your own. Thanks.


Cheers,
Jacni

--bcaec50162b5eed86004ab49c293
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On =
Thu, Aug 25, 2011 at 3:16 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:



















... 








#2

Section 6.2

Translation and encapsulation both uses the same mPrefix64 and uPrefix64, s=
o mB4 could not determine whether to de-capsulate the packets only based on=
 mPrefix64 and uPrefix64. Propose to change as "it checks whether the =
group address is in the range of mPrefix64,
 the source address is in the range of uPrefix64 and whether the next heade=
r of IPv6 header is 4."








=A0




Jacni>:Currently, we only employ the encapsulatio=
n for date forwarding in the main text.




[TT]
I am not talking about translation solution i=
n the main text. Even if in the encapsulation case, mB4 needs to determine =
whether to make de-capsulation or not.












Jacni>: In the case of encapsulation, the mB4 can det=
ermine that by checking whether the group address is within the mPrefix64 a=
nd the source address is within
 the uPrefix64, as what the 6.2 says.


[TT1] When the packet comes, how =
does mB4 know it should make encapsulation or translation if mPrefix64 and =
uPrefix64 are the same?=A0
In this case, the next header of IPv6 header could be used for mB4 t=
o determine.


Jacni>: Please see again my comments above, also your own. Thanks.<=
br>

Cheers,
Jacni



--bcaec50162b5eed86004ab49c293--

From Tina.Tsou.Zouting@huawei.com  Wed Aug 24 19:10:17 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1002221F85AA for ; Wed, 24 Aug 2011 19:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.202
X-Spam-Level: 
X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.396,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09+err2KBh2P for ; Wed, 24 Aug 2011 19:10:16 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0321F85A1 for ; Wed, 24 Aug 2011 19:10:15 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQG005NXOR1SJ@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 25 Aug 2011 10:11:25 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQG006BOOPXMK@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 25 Aug 2011 10:11:25 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK27518; Thu, 25 Aug 2011 10:11:24 +0800 (CST)
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 25 Aug 2011 10:10:17 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Thu, 25 Aug 2011 10:11:19 +0800
Date: Thu, 25 Aug 2011 02:11:18 +0000
From: Tina TSOU 
X-Originating-IP: [10.193.34.145]
To: "softwires@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_xNxBig1e4cKgNyruHzu2zA)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: Comments on draft-qin-softwire-dslite-multicast-04
Thread-index: AQHMYTdUSUw9NjVHm0mqk4ZZAfKXSpUplPOAgAM/pfA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 02:10:17 -0000

--Boundary_(ID_xNxBig1e4cKgNyruHzu2zA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi all,

One more comment on Section 7.4.2.



This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below:

------------
/               \
| IPv4 network |
\                /
------------
: | ^
IPv4 Multicast : | : PIMv4 Join
v | :
+-------------+
|    mAFTR      |
+-------------+
|:| | ^
IPv6 Multicast |:| | : (MLD Report)
(IPv4 embedded) |.| ... .
+-----------+
| MLD proxy/|
| snooping   |
+-----------+
|:| | : MLD Report
|v| | :
+-----------+
|      mB4    |
+-----------+
: | ^
IPv4 Multicast : | : IGMP Report
v | :
+-----------+
|     IPv4   |
|  Receiver |
+-----------+



B. R.

Tina





--Boundary_(ID_xNxBig1e4cKgNyruHzu2zA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT













Hi all,


One more comment on Section 7.4.2.


 


This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below:


 



------------



/               \



| IPv4 network |



\                /



------------



: | ^



IPv4 Multicast : | : PIMv4 Join



v | :



+-------------+



|    mAFTR      |



+-------------+



|:| | ^



IPv6 Multicast |:| | : (MLD Report)



(IPv4 embedded) |.| ... .



+-----------+



| MLD proxy/|



| snooping   |



+-----------+



|:| | : MLD Report



|v| | :



+-----------+



|      mB4    |



+-----------+



: | ^



IPv4 Multicast : | : IGMP Report



v | :



+-----------+



|     IPv4   |



|  Receiver |


+-----------+


 


B. R.


Tina


 


 






--Boundary_(ID_xNxBig1e4cKgNyruHzu2zA)--

From yiu_lee@cable.comcast.com  Wed Aug 24 20:30:20 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF9C21F8BA9 for ; Wed, 24 Aug 2011 20:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.51
X-Spam-Level: 
X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=1.952, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol-LHSKBylcL for ; Wed, 24 Aug 2011 20:30:19 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id E6A1A21F8BA7 for ; Wed, 24 Aug 2011 20:30:18 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.138177084; Wed, 24 Aug 2011 23:31:28 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 24 Aug 2011 23:31:27 -0400
From: "Lee, Yiu" 
To: "softwires@ietf.org" 
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMYtd4Qt1QJds0iEqgap0blIf57Q==
Date: Thu, 25 Aug 2011 03:31:26 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA7B38AA142FAyiuleecablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 03:30:20 -0000

--_000_CA7B38AA142FAyiuleecablecomcastcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Tina,

What do you see new here in this scenario? mAFTR is a logical function, it =
would perform MLD PIMv4-Join interworking. This has been captured. If a ven=
dor wants to make mAFTR also a L2 device, it would perform standard MLD sno=
oping. What else is missing?

Thanks,
Yiu

From: Tina TSOU >
Date: Thu, 25 Aug 2011 02:11:18 +0000
To: "softwires@ietf.org" >
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04


Hi all,

One more comment on Section 7.4.2.



This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need =
to consider the scenario where it is layer 2 network between mAFTR and mB4.=
 The architecture is as below:

------------
/               \
| IPv4 network |
\                /
------------
: | ^
IPv4 Multicast : | : PIMv4 Join
v | :
+-------------+
|    mAFTR      |
+-------------+
|:| | ^
IPv6 Multicast |:| | : (MLD Report)
(IPv4 embedded) |.| ... .
+-----------+
| MLD proxy/|
| snooping   |
+-----------+
|:| | : MLD Report
|v| | :
+-----------+
|      mB4    |
+-----------+
: | ^
IPv4 Multicast : | : IGMP Report
v | :
+-----------+
|     IPv4   |
|  Receiver |
+-----------+



B. R.

Tina





_______________________________________________ Softwires mailing list Soft=
wires@ietf.org https://www.ietf.org/mailman/list=
info/softwires

--_000_CA7B38AA142FAyiuleecablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Tina, 







What do you see new here in this scenario? mAFTR is a logical function=
, it would perform MLD PIMv4-Join interworking. This has been captured. If =
a vendor wants to make mAFTR also a L2 device, it would perform standard ML=
D snooping. What else is missing?







Thanks,


Yiu









From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>

Date: Thu, 25 Aug 2011 02:11:18 =
3;0000

To: "softwires@ietf.org" <softwires@ietf.org>

Subject: [Softwires] Comments on dr=
aft-qin-softwire-dslite-multicast-04



















Hi all,


One more comment on Section 7.4.2.


 


This document only covers IGMP-MLD and PIMv6-PIMv=
4 scenarios. We also need to consider the scenario where it is layer 2 netw=
ork between mAFTR and mB4. The architecture is as below:


 



------------



/   &nb=
sp;           \



| IPv4 network |<=
/o:p>



\   &nb=
sp;            /



------------



: | ^



IPv4 Multicast : | : P=
IMv4 Join



v | :



+-------------+=
;



|    mA=
FTR      |



+-------------+=
;



|:| | ^



IPv6 Multicast |:| | :=
 (MLD Report)



(IPv4 embedded) |.| ..=
. .



+-----------+<=
o:p>



| MLD proxy/|



| snooping  =
 |



+-----------+<=
o:p>



|:| | : MLD Report



|v| | :



+-----------+<=
o:p>



|   &nb=
sp;  mB4    |



+-----------+<=
o:p>



: | ^



IPv4 Multicast : | : I=
GMP Report



v | :



+-----------+<=
o:p>



|   &nb=
sp; IPv4   |



|  Receiver |


+-----------+


 


B. R.


Tina


 


 







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



--_000_CA7B38AA142FAyiuleecablecomcastcom_--

From jiangdong345@gmail.com  Wed Aug 24 20:59:49 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9421F8C63 for ; Wed, 24 Aug 2011 20:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.998
X-Spam-Level: 
X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=2.601,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7uG4n9sO0ul for ; Wed, 24 Aug 2011 20:59:48 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4816C21F8C64 for ; Wed, 24 Aug 2011 20:59:48 -0700 (PDT)
Received: by pzk33 with SMTP id 33so4225389pzk.18 for ; Wed, 24 Aug 2011 21:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=NcJYaAfPmYEstdUwa16eEVgv/c6r0p5r//pPKlRdPjo=; b=YL3/08JKwFeDCCe29BLtTCHdvLilXKQTvhQ+LWP19Ktl1HwnErpZBmqHPFIcJutYsK Ku4TvOJjYZM4zsNy74Zr1EzbqW5RMxvjlDPGig/KIwnvgJWFZkPzhOaKByEA1emD9UCC U0F97IyNdEL5stIUL3MYJuOUWyHsjIdIY0WMs=
Received: by 10.142.50.2 with SMTP id x2mr2402327wfx.115.1314244841740; Wed, 24 Aug 2011 21:00:41 -0700 (PDT)
Received: from DJ-PC ([166.111.68.231]) by mx.google.com with ESMTPS id e8sm867279pbc.8.2011.08.24.21.00.39 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 21:00:40 -0700 (PDT)
Date: Thu, 25 Aug 2011 12:01:15 +0800
From: Jiang Dong 
To: "Eleven Fu(Yu)" , "Alain Durand" 
References: , , , <7211CD03-56D2-4EBF-BF59-FDBE490C0728@juniper.net>, 
Message-ID: <201108251201128230009@gmail.com>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" , Yong Cui 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 03:59:49 -0000

Dear Chairs,
	+1, and we also hope to present the softwire mesh MIB

>Dear Chairs:
>
>    Are there any plans to discuss the MIBs at the interim meeting? According to our softwire WG milestones, our MIBs also need more discussions.
>
>Best Regards
>Yu
>
>
>-----Original Message-----
>From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Alain Durand
>Sent: Monday, August 22, 2011 11:40 PM
>To: gjshep@gmail.com
>Cc: liziye; Ralph Droms (rdroms); Yong Cui; iesg-secretary@ietf.org; softwires@ietf.org
>Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
>
>So far, I'd like the focus to be on stateless. We will see by the end of the week (end of the call for presentation) if we have time for multicast.
>
>Alain.
>
>Sent from my iPad
>
>On Aug 22, 2011, at 10:57 AM, "Greg Shepherd"  wrote:
>
>> Are there any plans to discuss solutions for multicast at the interim meeting?
>> 
>> Thanks,
>> Greg
>> 
>> On Mon, Aug 22, 2011 at 3:57 AM, GangChen  wrote:
>>> Dear Chairs,
>>> 
>>> I suggest including draft-murakami-softwire-4v6-translation-00 into
>>> the agenda as well.
>>> We already had a presentation in last softwire meeting. It's
>>> reasonable to continue the discussion in the interim meeting
>>> 
>>> Many thanks
>>> 
>>> Gang
>>> 
>>> 2011/8/19, Yong Cui :
>>>> Hi folks,
>>>> 
>>>> We, softwire wg chairs, in agreement with our ADs, are announcing
>>>> an interim meeting in Beijing on September 26 & 27. The date has
>>>> been chosen adjacent to the BBF meeting in Shangai to minimize
>>>> travel and visa issues.
>>>> 
>>>> The interim meeting will focus on 'stateless' solutions in general
>>>> and 4rd in particular. Expected outcome includes progress on 4rd
>>>> spec, packet format, where to put IPv4 bits, port indications, DHCP
>>>> option, tunneling vs translation, coexistence with other
>>>> technologies, etc...
>>>> 
>>>> ---------------------------------------
>>>> Meeting Location & recommended hotels
>>>> Meeting venue: FIT Building, Tsinghua University, Beijing
>>>> FIT Building is the first left building inside of the East Gate
>>>> of Tsinghua Univeristy
>>>> http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b982
>>>> 9372&msa=0&ll=39.996906,116.331664&spn=0.004044,0.008798
>>>> 
>>>> Recommended hotels:
>>>> 1. Uniscenter (4 stars, 3 min walk)
>>>> http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>>> 
>>>> 2. Wenjin Hotel (5 stars, 10 min walk)
>>>> http://www.wenjin.com.cn/
>>>> 
>>>> 3. Royal King Hotel (5 stars, 10 min by car)
>>>> http://www.royalkinghotel.com/
>>>> 
>>>> ----------------------------------------
>>>> Invitation letter
>>>> If you need an invitation letter, please send the following info
>>>> to Ms. Ziye Li: .
>>>> Surname:
>>>> Given Name:
>>>> Company:
>>>> Address:
>>>> Phone:
>>>> Passport Number:
>>>> Passport Exp. Date:
>>>> Passport Issuing Country:
>>>> 
>>>> 
>>>> 
>>>> -----------------------------------------
>>>> 
>>>> Further contact information
>>>> Please contact Ms. Ziye Li if you have any question about
>>>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>>>> 
>>>> 
>>>> 
>>>> -- Alain, Yong
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>> 
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


From wwang@juniper.net  Wed Aug 24 21:32:37 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A521F8B1E for ; Wed, 24 Aug 2011 21:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Level: 
X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[AWL=1.083,  BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001,  RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl1Fh2fpcuhc for ; Wed, 24 Aug 2011 21:32:36 -0700 (PDT)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8821F8B13 for ; Wed, 24 Aug 2011 21:32:36 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTlXQq9hpv1chgbZ2nSdLuf5rztZFJm5k@postini.com; Wed, 24 Aug 2011 21:33:49 PDT
Received: from EmailHK1.jnpr.net (172.27.128.41) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 24 Aug 2011 21:32:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC62E0.0EA9D851"
Date: Thu, 25 Aug 2011 12:32:54 +0800
Message-ID: <0C9A234C6CFA4F4F8E2D0E910820D8AB100D57F1@emailhk1.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] New working group documents
Thread-Index: AQF6c+1fvb/V+L6bDz1BRvhbixJ+UQKAkbm9AXlKvueVsQdn4IAAAc2A
From: "Wei Wang(Beijing Sales Office)" 
To: 
Subject: [Softwires] FW:  New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 04:32:37 -0000

------_=_NextPart_001_01CC62E0.0EA9D851
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I support to adopt 3 and 4.

=20

Wei Wang

=20

=20

	=20

	On Sat, Aug 20, 2011 at 10:21 PM, Yong Cui
 wrote:

	Hi folks,
=09
	Following our rough concensus during Quebec City meeting and
	according to our charter/milestones, the chairs would like to
	ask the mailing list for the confirmation to adopt the following
	drafts:
=09
	1. Deployment Considerations for Dual-Stack Lite
=09
http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
=09
=09
	2. Public IPv4 over Access IPv6 Network
	http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
=09
	3. Softwire Mesh Multicast
=09
http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
=09
	4. Multicast Extensions to DS-Lite Technique in Broadband
Deployments
=09
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
=09
	5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
=09
http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-m
oti
	vation/
=09
	Please send your comments by 10am EDT on Aug 27. If you object
to
	adoption, please also give the detailed reasons.
=09
=09
=09
	--Alain & Yong
=09
=09
	_______________________________________________
	Softwires mailing list
	Softwires@ietf.org
	https://www.ietf.org/mailman/listinfo/softwires

	=20

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


------_=_NextPart_001_01CC62E0.0EA9D851
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




















I support =
to adopt 3
and 4.



 <=
/o:p>



Wei Wang



 <=
/span>



 <=
/o:p>















 



On
Sat, Aug 20, 2011 at 10:21 PM, Yong Cui <cuiyong@tsinghua.edu.cn> =
wrote:



Hi
folks,



Following our rough concensus during Quebec
  City meeting and

according to our charter/milestones, the chairs would like to

ask the mailing list for the confirmation to adopt the following

drafts:



1. Deployment Considerations for Dual-Stack Lite

http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deploymen=
t/





2. Public IPv4 over Access IPv6 Network

=
http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/



3. Softwire Mesh Multicast

http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/


4. Multicast Extensions to DS-Lite Technique in Broadband =
Deployments

http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/=




5. Motivations for Stateless IPv4 over IPv6 Migration Solutions

http://datatracker.ietf.org/doc/draft-operators-softwire-stat=
eless-4v6-moti

vation/



Please send your comments by 10am EDT on Aug 27. If you object to

adoption, please also give the detailed reasons.







--Alain & Yong





_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf=
.org/mailman/listinfo/softwires






 


















______________________________________________=
_

Softwires mailing list

Softwires@ietf.org

https://www.ietf=
.org/mailman/listinfo/softwires















------_=_NextPart_001_01CC62E0.0EA9D851--

From ichiroumakino@gmail.com  Wed Aug 24 23:46:56 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9BB21F8AF0 for ; Wed, 24 Aug 2011 23:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.468
X-Spam-Level: 
X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[AWL=2.131,  BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQFlJFaYA4O6 for ; Wed, 24 Aug 2011 23:46:55 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C31F721F8A97 for ; Wed, 24 Aug 2011 23:46:54 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1615880wyg.31 for ; Wed, 24 Aug 2011 23:48:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0RgdiloVIQ81VnrRTZpWAIMlLEdFTqQhSjcsACFGBWM=; b=IXEykwniwTAVm2vsSGR+BAO39unNRIpqQWGX6WYpGBDuvgqFVH6wTyPxmJ2QrLsrrX jtYyROQvt+UKbjxOJ9TJqG5PWCS06nMC8vsGWL0i3Fb8qyTNbSiom4GM3YnjGd5jzgbu 71yr9jZBBuaS6lao0QXmn51mDMYESEQCJxrFk=
Received: by 10.227.202.18 with SMTP id fc18mr2270917wbb.46.1314254882699; Wed, 24 Aug 2011 23:48:02 -0700 (PDT)
Received: from ams3-vpn-dhcp6574.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id et16sm192307wbb.19.2011.08.24.23.47.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 23:48:01 -0700 (PDT)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <201108251201128230009@gmail.com>
Date: Thu, 25 Aug 2011 08:47:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5172B28C-2E40-4F8D-B8C0-95F488D29086@employees.org>
References: , , , <7211CD03-56D2-4EBF-BF59-FDBE490C0728@juniper.net>,  <201108251201128230009@gmail.com>
To: Jiang Dong 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , Yong Cui 
Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 06:46:56 -0000

> 	+1, and we also hope to present the softwire mesh MIB
>=20
>> Dear Chairs:
>>=20
>>   Are there any plans to discuss the MIBs at the interim meeting? =
According to our softwire WG milestones, our MIBs also need more =
discussions.

-1.
MIBs are boring. ;-)

cheers,
Ole




>>=20
>> Best Regards
>> Yu
>>=20
>>=20
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] =
On Behalf Of Alain Durand
>> Sent: Monday, August 22, 2011 11:40 PM
>> To: gjshep@gmail.com
>> Cc: liziye; Ralph Droms (rdroms); Yong Cui; iesg-secretary@ietf.org; =
softwires@ietf.org
>> Subject: Re: [Softwires] Softwire Interim Meeting in Beijing
>>=20
>> So far, I'd like the focus to be on stateless. We will see by the end =
of the week (end of the call for presentation) if we have time for =
multicast.
>>=20
>> Alain.
>>=20
>> Sent from my iPad
>>=20
>> On Aug 22, 2011, at 10:57 AM, "Greg Shepherd"  =
wrote:
>>=20
>>> Are there any plans to discuss solutions for multicast at the =
interim meeting?
>>>=20
>>> Thanks,
>>> Greg
>>>=20
>>> On Mon, Aug 22, 2011 at 3:57 AM, GangChen  wrote:
>>>> Dear Chairs,
>>>>=20
>>>> I suggest including draft-murakami-softwire-4v6-translation-00 into
>>>> the agenda as well.
>>>> We already had a presentation in last softwire meeting. It's
>>>> reasonable to continue the discussion in the interim meeting
>>>>=20
>>>> Many thanks
>>>>=20
>>>> Gang
>>>>=20
>>>> 2011/8/19, Yong Cui :
>>>>> Hi folks,
>>>>>=20
>>>>> We, softwire wg chairs, in agreement with our ADs, are announcing
>>>>> an interim meeting in Beijing on September 26 & 27. The date has
>>>>> been chosen adjacent to the BBF meeting in Shangai to minimize
>>>>> travel and visa issues.
>>>>>=20
>>>>> The interim meeting will focus on 'stateless' solutions in general
>>>>> and 4rd in particular. Expected outcome includes progress on 4rd
>>>>> spec, packet format, where to put IPv4 bits, port indications, =
DHCP
>>>>> option, tunneling vs translation, coexistence with other
>>>>> technologies, etc...
>>>>>=20
>>>>> ---------------------------------------
>>>>> Meeting Location & recommended hotels
>>>>> Meeting venue: FIT Building, Tsinghua University, Beijing
>>>>> FIT Building is the first left building inside of the East Gate
>>>>> of Tsinghua Univeristy
>>>>> =
http://maps.google.com/maps/ms?msid=3D202779846620144871057.0004aad8ce367b=
982
>>>>> 9372&msa=3D0&ll=3D39.996906,116.331664&spn=3D0.004044,0.008798
>>>>>=20
>>>>> Recommended hotels:
>>>>> 1. Uniscenter (4 stars, 3 min walk)
>>>>> =
http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html
>>>>>=20
>>>>> 2. Wenjin Hotel (5 stars, 10 min walk)
>>>>> http://www.wenjin.com.cn/
>>>>>=20
>>>>> 3. Royal King Hotel (5 stars, 10 min by car)
>>>>> http://www.royalkinghotel.com/
>>>>>=20
>>>>> ----------------------------------------
>>>>> Invitation letter
>>>>> If you need an invitation letter, please send the following info
>>>>> to Ms. Ziye Li: .
>>>>> Surname:
>>>>> Given Name:
>>>>> Company:
>>>>> Address:
>>>>> Phone:
>>>>> Passport Number:
>>>>> Passport Exp. Date:
>>>>> Passport Issuing Country:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -----------------------------------------
>>>>>=20
>>>>> Further contact information
>>>>> Please contact Ms. Ziye Li if you have any question about
>>>>> Beijing/Tsinghua/Hotel/Meeting venue/visa/tour...
>>>>> 
>>>>>=20
>>>>>=20
>>>>> -- Alain, Yong
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Softwires mailing list
>>>>> Softwires@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>=20
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>=20
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From mohamed.boucadair@orange-ftgroup.com  Thu Aug 25 00:16:22 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465721F8A66 for ; Thu, 25 Aug 2011 00:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlTeSw5f6+J8 for ; Thu, 25 Aug 2011 00:16:20 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0845B21F8A58 for ; Thu, 25 Aug 2011 00:16:19 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9B7FD264518; Thu, 25 Aug 2011 09:17:28 +0200 (CEST)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 856AA238073; Thu, 25 Aug 2011 09:17:28 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 25 Aug 2011 09:17:28 +0200
From: 
To: "Lee, Yiu" , "softwires@ietf.org" 
Date: Thu, 25 Aug 2011 09:17:26 +0200
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMYtd4Qt1QJds0iEqgap0blIf57ZUtJdwQ
Message-ID: <94C682931C08B048B7A8645303FDC9F35166FB83B9@PUEXCB1B.nanterre.francetelecom.fr>
References:  
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F35166FB83B9PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.25.32414
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 07:16:22 -0000

--_000_94C682931C08B048B7A8645303FDC9F35166FB83B9PUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Tina,

I agree with Yiu. FYI, we had a discussion between co-authors of the draft =
whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-mu=
lticast-04#section-8 or remove it.

You can read in that section:

   " Additionally,
   mechanisms such as MLD Snooping, MLD Proxying, etc., can be
   introduced into the distributed Access Network Nodes (e.g.,
   Aggregation Switches, xPON devices) which then could behave as MLD
   Querier and replicate multicast flows as appropriate.  Thus, the
   multicast replication point is moved downward closer to the
   receivers, so that bandwidth consumption is optimized."

What do you think is missing in that text?

Cheers,
Med


________________________________
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Lee, Yiu
Envoy=E9 : jeudi 25 ao=FBt 2011 05:31
=C0 : softwires@ietf.org
Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Tina,

What do you see new here in this scenario? mAFTR is a logical function, it =
would perform MLD PIMv4-Join interworking. This has been captured. If a ven=
dor wants to make mAFTR also a L2 device, it would perform standard MLD sno=
oping. What else is missing?

Thanks,
Yiu

From: Tina TSOU >
Date: Thu, 25 Aug 2011 02:11:18 +0000
To: "softwires@ietf.org" >
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04


Hi all,

One more comment on Section 7.4.2.

This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need =
to consider the scenario where it is layer 2 network between mAFTR and mB4.=
 The architecture is as below:
------------
/               \
| IPv4 network |
\                /
------------
: | ^
IPv4 Multicast : | : PIMv4 Join
v | :
+-------------+
|    mAFTR      |
+-------------+
|:| | ^
IPv6 Multicast |:| | : (MLD Report)
(IPv4 embedded) |.| ... .
+-----------+
| MLD proxy/|
| snooping   |
+-----------+
|:| | : MLD Report
|v| | :
+-----------+
|      mB4    |
+-----------+
: | ^
IPv4 Multicast : | : IGMP Report
v | :
+-----------+
|     IPv4   |
|  Receiver |
+-----------+

B. R.

Tina

_______________________________________________ Softwires mailing list Soft=
wires@ietf.org https://www.ietf.org/mailman/list=
info/softwires

--_000_94C682931C08B048B7A8645303FDC9F35166FB83B9PUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi Tina, 


 


I agree with Yiu. FYI, we had a discussion betwee=
n=20
co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04=
#section-8 or=20
remove it. 


 


You can read in that section: 


   " Additionally,
   mechanisms such as MLD Snooping, MLD Proxying, etc., can be
   introduced into the distributed Access Network Nodes (e.g.,
   Aggregation Switches, xPON devices) which then could behave as MLD
   Querier and replicate multicast flows as appropriate.  Thus, the
   multicast replication point is moved downward closer to the
   receivers, so that bandwidth consumption is optimized."


What do you think is missing in that=20
text?


 


Cheers,


Med


 






De : softwires-bounces@ietf.org=20
[mailto:softwires-bounces@ietf.org] De la part de Lee,=20
Yiu
Envoy=E9 : jeudi 25 ao=FBt 2011 05:31
=C0 :=20
softwires@ietf.org
Objet : Re: [Softwires] Comments on=20
draft-qin-softwire-dslite-multicast-04





Hi Tina, 





What do you see new here in this scenario? mAFTR is a logical function=
, it=20
would perform MLD PIMv4-Join interworking. This has been captured. If a ven=
dor=20
wants to make mAFTR also a L2 device, it would perform standard MLD snoopin=
g.=20
What else is missing?





Thanks,


Yiu




From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Date: Thu, 25 Aug 2011 02:11:18 +0000To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] Comments on=20
draft-qin-softwire-dslite-multicast-04
















Hi all,


One=20
more comment on Section 7.4.2.




This document only covers IGMP-MLD and PIMv6-PIMv4=
=20
scenarios. We also need to consider the scenario where it is layer 2 networ=
k=20
between mAFTR and mB4. The architecture is as below:




------------


/    &n=
bsp;         =20
\


| IPv4 network=20
|


\    &n=
bsp;          =20
/


------------


: | ^


IPv4 Multicast : | : PIMv4=
=20
Join


v | :


+-------------+<=
/SPAN>


|   =20
mAFTR      |


+-------------+<=
/SPAN>


|:| | ^

IPv6 Multicast |:| | : (MLD=
=20
Report)


(IPv4 embedded) |.| ...=20
.


+-----------+


| MLD=20
proxy/|


| snooping  =20
|


+-----------+


|:| | : MLD=20
Report


|v| | :

+-----------+


|    &n=
bsp;=20
mB4    |


+-----------+


: | ^


IPv4 Multicast : | : IGMP=20
Report


v | :


+-----------+


|    =20
IPv4   |


|  Receiver=20
|


+-----------+




B. R.


Tina




_____________________=
__________________________=20
Softwires mailing list Softwires@ietf.org https://www.ietf.o=
rg/mailman/listinfo/softwires=20


--_000_94C682931C08B048B7A8645303FDC9F35166FB83B9PUEXCB1Bnante_--

From mohamed.boucadair@orange-ftgroup.com  Thu Aug 25 01:10:25 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C63321F8B08 for ; Thu, 25 Aug 2011 01:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.162
X-Spam-Level: 
X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuOTudKyY6pT for ; Thu, 25 Aug 2011 01:10:24 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08421F8B00 for ; Thu, 25 Aug 2011 01:10:23 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 65B5222CAE3; Thu, 25 Aug 2011 10:11:14 +0200 (CEST)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3A7DA27C095; Thu, 25 Aug 2011 10:11:14 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 25 Aug 2011 10:11:13 +0200
From: 
To: "Lee, Yiu" , "softwires@ietf.org" 
Date: Thu, 25 Aug 2011 10:11:12 +0200
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMYtd4Qt1QJds0iEqgap0blIf57ZUtNxzA
Message-ID: <94C682931C08B048B7A8645303FDC9F35166FB840B@PUEXCB1B.nanterre.francetelecom.fr>
References:  
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.31.105417
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 08:10:25 -0000

Hi Tina,=20
=20
I agree with Yiu. FYI, we had a discussion between co-authors of the draft =
whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-mu=
lticast-04#section-8 or remove it.=20
=20
You can read in that section:=20

   " Additionally,
   mechanisms such as MLD Snooping, MLD Proxying, etc., can be
   introduced into the distributed Access Network Nodes (e.g.,
   Aggregation Switches, xPON devices) which then could behave as MLD
   Querier and replicate multicast flows as appropriate.  Thus, the
   multicast replication point is moved downward closer to the
   receivers, so that bandwidth consumption is optimized."

What do you think is missing in that text?
=20
Cheers,
Med

________________________________

De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Lee, Yiu
Envoy=E9 : jeudi 25 ao=FBt 2011 05:31
=C0 : softwires@ietf.org
Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04


Hi Tina,=20

What do you see new here in this scenario? mAFTR is a logical function, it =
would perform MLD PIMv4-Join interworking. This has been captured. If a ven=
dor wants to make mAFTR also a L2 device, it would perform standard MLD sno=
oping. What else is missing?

Thanks,
Yiu

From: Tina TSOU 
Date: Thu, 25 Aug 2011 02:11:18 +0000
To: "softwires@ietf.org" 
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04



Hi all,

One more comment on Section 7.4.2.

This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need =
to consider the scenario where it is layer 2 network between mAFTR and mB4.=
 The architecture is as below:

From shtsuchi@cisco.com  Thu Aug 25 01:11:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB4D21F8B0C for ; Thu, 25 Aug 2011 01:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level: 
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGO1sPJmxrLi for ; Thu, 25 Aug 2011 01:11:45 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CB48E21F8B09 for ; Thu, 25 Aug 2011 01:11:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=705; q=dns/txt; s=iport; t=1314259978; x=1315469578; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=GuhkqnTAU86euV/O5ktnOxlWc0QBjtpGUttpNzr8e4A=; b=XVyhshLtgni09YSBK16JspulFRN4arIjVEDkj6kaKESpYpQ1rYdc3cWX H8EUaOXWxIKZkg2Ap9JKBWmbUsyHrKhOgtC3wUxdVHfvgoD8Dga2C2oT3 evxQzlGiYXoelDZCxF8nnfGCM7l30ZWFsqlTbLY7VtYOC0WcmMDH0H1fb o=;
X-IronPort-AV: E=Sophos;i="4.68,279,1312156800"; d="scan'208";a="112382603"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2011 08:12:55 +0000
Received: from [64.104.9.192] (dhcp-shinjuku-64-104-9-192.cisco.com [64.104.9.192]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7P8Cr2j031060; Thu, 25 Aug 2011 08:12:53 GMT
Message-ID: <4E560404.8080101@cisco.com>
Date: Thu, 25 Aug 2011 17:12:52 +0900
From: Shishio Tsuchiya 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: adurand@juniper.net
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, draft-sakura-6rd-datacenter@tools.ietf.org
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 08:11:46 -0000

Alain
I would like to have a presentation our draft.
http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01
I was assigned time slot on IETF81,but I could not...
This is informative 6rd draft for operators,I think.

Please assign a slot for this.
And if it is possible,please assign faster of time slot.

Regards,
-Shishio

Alain Durand wrote:
> As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week.
> 
> Alain.
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> 



From ichiroumakino@gmail.com  Thu Aug 25 01:23:40 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DFC21F8AD3 for ; Thu, 25 Aug 2011 01:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.293
X-Spam-Level: 
X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0XgVqNHgkRN for ; Thu, 25 Aug 2011 01:23:40 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E667521F8AA9 for ; Thu, 25 Aug 2011 01:23:39 -0700 (PDT)
Received: by wwf5 with SMTP id 5so1417271wwf.13 for ; Thu, 25 Aug 2011 01:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Cgpj9AdriU8TTIDEPMMsQ+Rpwu0BEB4EnkQHLiQRr/A=; b=erENdE7XqW+nLVNRRsndqaZ7DIc6lbJF7izkKFx+EfHoyhq5+sICgoll5O5sYZMHD7 RJ6KxccWqGTDR9fLMCZxv4OKKdHAVIQrVcf0EqmNxNgBaVtG/5z0NpkULtkKpYLD06u+ 77HenpH8FR6ObkzDmTXAXY4LKQV0Ua7dPqTpQ=
Received: by 10.216.229.40 with SMTP id g40mr356978weq.26.1314260692021; Thu, 25 Aug 2011 01:24:52 -0700 (PDT)
Received: from ams3-vpn-dhcp6574.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fd4sm253918wbb.13.2011.08.25.01.24.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Aug 2011 01:24:51 -0700 (PDT)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <4E560404.8080101@cisco.com>
Date: Thu, 25 Aug 2011 10:24:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9920DC61-6CF3-4D15-A950-23AE6EFC35CD@employees.org>
References:  <4E560404.8080101@cisco.com>
To: Shishio Tsuchiya 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, draft-sakura-6rd-datacenter@tools.ietf.org
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 08:23:41 -0000

isn't this interim there to discuss the new stateless approaches. not to =
be overflow meeting for whatever didn't make it on the agenda at the =
last IETF meeting?

if we get time to spare fine, but I would certainly have liked this =
meeting to be focused on the "stateless" solutions. and with the number =
of drafts published I would think we have enough to fill a couple of =
days too.

cheers,
Ole


On Aug 25, 2011, at 10:12 , Shishio Tsuchiya wrote:

> Alain
> I would like to have a presentation our draft.
> http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01
> I was assigned time slot on IETF81,but I could not...
> This is informative 6rd draft for operators,I think.
>=20
> Please assign a slot for this.
> And if it is possible,please assign faster of time slot.
>=20
> Regards,
> -Shishio
>=20
> Alain Durand wrote:
>> As we mentioned earlier, the softwire interim meeting will focus on =
'stateless solutions'. If you'd like to present there, please send the =
chairs a note by Friday this week.
>>=20
>> Alain.
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>=20
>=20
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From shtsuchi@cisco.com  Thu Aug 25 01:57:45 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E2F21F89CC for ; Thu, 25 Aug 2011 01:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.074
X-Spam-Level: 
X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-4.075, BAYES_00=-2.599, J_CHICKENPOX_91=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQTvwnJT+jdl for ; Thu, 25 Aug 2011 01:57:44 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 725ED21F8876 for ; Thu, 25 Aug 2011 01:57:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1715; q=dns/txt; s=iport; t=1314262737; x=1315472337; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/C1AJYs8em51PvbcCGDUsYDBXCHr2bTisV58Qi/gRug=; b=d7CzmX7OwOo0c4UHZ8Bb/lf3Jx0leZaHapCjkyLddfIfIOefc5VsvFfu iQqlCZVESXA0+Z6yBpIMrNhhbX/ut+Icbi9rUg/hO2OlM73+5DKUNEBaB 2Dbis4L56b1cbOOEyjUgisa75p+KrmvSMjGbH68K5TGqGnGvHynM40Xnn A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisHAAQOVk6rRDoG/2dsb2JhbABChEyUIY8Ud4FAAQEBAQMBAQEPAQoEAUwKARALGAEDBRYKAwIJAwIBAgEVMBMBBQIBARcHh1SbNwGNLwGRVIEphA+BFASHX4s6hQ2LfQ
X-IronPort-AV: E=Sophos;i="4.68,280,1312156800"; d="scan'208";a="16340154"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 25 Aug 2011 08:58:56 +0000
Received: from [64.104.9.192] (dhcp-shinjuku-64-104-9-192.cisco.com [64.104.9.192]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7P8wt3a026131; Thu, 25 Aug 2011 08:58:56 GMT
Message-ID: <4E560ECE.5090602@cisco.com>
Date: Thu, 25 Aug 2011 17:58:54 +0900
From: Shishio Tsuchiya 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: otroan@employees.org
References:  <4E560404.8080101@cisco.com> <9920DC61-6CF3-4D15-A950-23AE6EFC35CD@employees.org>
In-Reply-To: <9920DC61-6CF3-4D15-A950-23AE6EFC35CD@employees.org>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, draft-sakura-6rd-datacenter@tools.ietf.org
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 08:57:45 -0000

Ole
Ok.I won't,if this interim will focuses discussion of "new" stateless solution and it is not enough time.
>  > And if it is possible,please assign faster of time slot.
Let's move to lower priority of time slot.

Regards,
-Shishio

Ole Troan wrote:
> isn't this interim there to discuss the new stateless approaches. not to be overflow meeting for whatever didn't make it on the agenda at the last IETF meeting?
> 
> if we get time to spare fine, but I would certainly have liked this meeting to be focused on the "stateless" solutions. and with the number of drafts published I would think we have enough to fill a couple of days too.
> 
> cheers,
> Ole
> 
> 
> On Aug 25, 2011, at 10:12 , Shishio Tsuchiya wrote:
> 
>  > Alain
>  > I would like to have a presentation our draft.
>  > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01
>  > I was assigned time slot on IETF81,but I could not...
>  > This is informative 6rd draft for operators,I think.
>  >
>  > Please assign a slot for this.
>  > And if it is possible,please assign faster of time slot.
>  >
>  > Regards,
>  > -Shishio
>  >
>  > Alain Durand wrote:
>  >> As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week.
>  >>
>  >> Alain.
>  >> _______________________________________________
>  >> Softwires mailing list
>  >> Softwires@ietf.org
>  >> https://www.ietf.org/mailman/listinfo/softwires
>  >>
>  >
>  >
>  > _______________________________________________
>  > Softwires mailing list
>  > Softwires@ietf.org
>  > https://www.ietf.org/mailman/listinfo/softwires
> 



From xing@cernet.edu.cn  Thu Aug 25 02:24:42 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8D421F8761 for ; Thu, 25 Aug 2011 02:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.717
X-Spam-Level: 
X-Spam-Status: No, score=-99.717 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bike43CfBz1 for ; Thu, 25 Aug 2011 02:24:42 -0700 (PDT)
Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 6E33021F8509 for ; Thu, 25 Aug 2011 02:24:41 -0700 (PDT)
Received: from [127.0.0.1]([14.139.9.32]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm164e563e75; Thu, 25 Aug 2011 17:25:52 +0800
Message-ID: <4E56151E.7040109@cernet.edu.cn>
Date: Thu, 25 Aug 2011 17:25:50 +0800
From: Xing Li 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: Alain Durand ,  Yong Cui 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: f1IM6w0B
Cc: "softwires@ietf.org" , Congxiao Bao , Wojciech Dec 
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 09:24:42 -0000

Hi, Alain and Yong,

We would like to have a presentation of two related drafts in the 
interim meeting.

https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/
https://datatracker.ietf.org/doc/draft-xli-behave-divi/

Please assign a slot for this.

Thanks!

Xing Li


于 2011/8/22 23:37, Alain Durand 写é“:
> As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week.
>
> Alain.
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>


From Tina.Tsou.Zouting@huawei.com  Thu Aug 25 19:30:12 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7917E21F87D6 for ; Thu, 25 Aug 2011 19:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.217
X-Spam-Level: 
X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.382,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7f2yFJGnjg8 for ; Thu, 25 Aug 2011 19:30:11 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9B03121F8500 for ; Thu, 25 Aug 2011 19:30:11 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQI004I4KCCRF@szxga05-in.huawei.com> for softwires@ietf.org; Fri, 26 Aug 2011 10:31:24 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQI00IEZKCBOF@szxga05-in.huawei.com> for softwires@ietf.org; Fri, 26 Aug 2011 10:31:24 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK58378; Fri, 26 Aug 2011 10:31:22 +0800 (CST)
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 26 Aug 2011 10:31:13 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Fri, 26 Aug 2011 10:31:17 +0800
Date: Fri, 26 Aug 2011 02:31:17 +0000
From: Tina TSOU 
In-reply-to: <94C682931C08B048B7A8645303FDC9F35166FB840B@PUEXCB1B.nanterre.francetelecom.fr>
X-Originating-IP: [10.193.34.145]
To: "mohamed.boucadair@orange-ftgroup.com" , "Lee, Yiu" , "softwires@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-language: en-US
Content-transfer-encoding: quoted-printable
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-index: AQHMYTdUSUw9NjVHm0mqk4ZZAfKXSpUplPOAgAM/pfD//5HNAIAATioAgAG3aeA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   <94C682931C08B048B7A8645303FDC9F35166FB840B@PUEXCB1B.nanterre.francetelecom.fr>
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 02:30:12 -0000

Bonjour Med,
Thank you for your comments.
What Yiu said is not reflected in figure 3. In the current figure, mAFTR ca=
n receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 netw=
ork is layer 2 network, mAFTR should be able to receive MLD report as well.=
 mAFTR also performs MLD/PIMv4 interworking in this case. So I propose upda=
te figure 3 to be complete. Section 8 does not mention how mAFTR acts in th=
is case.


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh=
alf Of mohamed.boucadair@orange-ftgroup.com
Sent: Thursday, August 25, 2011 1:11 AM
To: Lee, Yiu; softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Tina,=20
=20
I agree with Yiu. FYI, we had a discussion between co-authors of the draft =
whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-mu=
lticast-04#section-8 or remove it.=20
=20
You can read in that section:=20

   " Additionally,
   mechanisms such as MLD Snooping, MLD Proxying, etc., can be
   introduced into the distributed Access Network Nodes (e.g.,
   Aggregation Switches, xPON devices) which then could behave as MLD
   Querier and replicate multicast flows as appropriate.  Thus, the
   multicast replication point is moved downward closer to the
   receivers, so that bandwidth consumption is optimized."

What do you think is missing in that text?
=20
Cheers,
Med

________________________________

De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Lee, Yiu
Envoy=E9 : jeudi 25 ao=FBt 2011 05:31
=C0 : softwires@ietf.org
Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04


Hi Tina,=20

What do you see new here in this scenario? mAFTR is a logical function, it =
would perform MLD PIMv4-Join interworking. This has been captured. If a ven=
dor wants to make mAFTR also a L2 device, it would perform standard MLD sno=
oping. What else is missing?

Thanks,
Yiu

From: Tina TSOU 
Date: Thu, 25 Aug 2011 02:11:18 +0000
To: "softwires@ietf.org" 
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04



Hi all,

One more comment on Section 7.4.2.

This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need =
to consider the scenario where it is layer 2 network between mAFTR and mB4.=
 The architecture is as below:
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

From Tina.Tsou.Zouting@huawei.com  Thu Aug 25 19:35:21 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DA221F8634 for ; Thu, 25 Aug 2011 19:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.23
X-Spam-Level: 
X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf0GFeNycJCJ for ; Thu, 25 Aug 2011 19:35:20 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF8021F862F for ; Thu, 25 Aug 2011 19:35:20 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQI00AALKKX5U@szxga03-in.huawei.com> for softwires@ietf.org; Fri, 26 Aug 2011 10:36:33 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQI00KRXKKXKS@szxga03-in.huawei.com> for softwires@ietf.org; Fri, 26 Aug 2011 10:36:33 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK58602; Fri, 26 Aug 2011 10:36:33 +0800 (CST)
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 26 Aug 2011 10:36:25 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 26 Aug 2011 10:36:29 +0800
Date: Fri, 26 Aug 2011 02:36:29 +0000
From: Tina TSOU 
X-Originating-IP: [10.193.34.145]
To: "softwires@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
Thread-index: AcxjmPgnI5wwISDaTQaEaDW2WODLbg==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Subject: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 02:35:21 -0000

Hi all,
In section 6.3, "To avoid fragmentation, a
   service provider may increase the MTU size by 40 bytes on the IPv6
   network or mAFTR and mB4 may use IPv6 Path MTU discovery."

How to use IPv6 Path MTU discovery to avoid fragmentation?  



Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html




From jacniq@gmail.com  Thu Aug 25 21:38:51 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD0421F8A7E for ; Thu, 25 Aug 2011 21:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level: 
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.179,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhC7fqzukKPP for ; Thu, 25 Aug 2011 21:38:50 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 665A121F8A64 for ; Thu, 25 Aug 2011 21:38:50 -0700 (PDT)
Received: by vxi29 with SMTP id 29so2853291vxi.31 for ; Thu, 25 Aug 2011 21:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JgbwkzWy0velZQoKGvfWb6NjVRTWeoNMfT50pOeZfrY=; b=pKzlNUPOxRS54jT9subxwXHr0Maq5FXeuvytUp76zuvCxQIp+NAExqMUX5QG3MNHGN 9grWBIH/S750Qp7t6+f9czMd399aVdIuW+efwvnxp1DYI3ueiuAWZhuVed3s6dGHF0Kt sGe7iGgv53D98IrtEoIo8F1pebSXx6mx9ML1g=
MIME-Version: 1.0
Received: by 10.52.173.35 with SMTP id bh3mr597732vdc.380.1314333603194; Thu, 25 Aug 2011 21:40:03 -0700 (PDT)
Received: by 10.52.187.161 with HTTP; Thu, 25 Aug 2011 21:40:03 -0700 (PDT)
In-Reply-To: 
References:   <94C682931C08B048B7A8645303FDC9F35166FB840B@PUEXCB1B.nanterre.francetelecom.fr> 
Date: Fri, 26 Aug 2011 12:40:03 +0800
Message-ID: 
From: Jacni Qin 
To: Tina TSOU 
Content-Type: multipart/alternative; boundary=bcaec51b9bfd88e95304ab61235e
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 04:38:51 -0000

--bcaec51b9bfd88e95304ab61235e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi,

On Fri, Aug 26, 2011 at 10:31 AM, Tina TSOU w=
rote:

> Bonjour Med,
> Thank you for your comments.
> What Yiu said is not reflected in figure 3. In the current figure, mAFTR
> can receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6
> network is layer 2 network, mAFTR should be able to receive MLD report as
> well. mAFTR also performs MLD/PIMv4 interworking in this case. So I propo=
se
> update figure 3 to be complete. Section 8 does not mention how mAFTR acts=
 in
> this case.
>
>
Jacni>: Figure 3 illustrates the functional elements, not layer 2 multicast
things, while the "IPv6 Network" in the figure can be layer 2 if you want t=
o
understand it that way, no problem.
What you said concerning two different things,
* The layer 2 multicast mechanisms, like MLD Snooping, this approach is
totally compatible with it. That's what Section 8 is talking about. Please
see Yiu and Med's comments.
* The MLD/PIMv4 is one of the scenarios, as we explained in previous emails=
.
Also in the figure3, if there are "PIMv6 Routers in between", the AFTR will
receive PIMv6 join then do PIMv6/PIMv4, otherwise it will receive MLD
messages then do MLD/PIMv4.


Cheers,
Jacni


> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
>
>
> -----Original Message-----
> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
> Behalf Of mohamed.boucadair@orange-ftgroup.com
> Sent: Thursday, August 25, 2011 1:11 AM
> To: Lee, Yiu; softwires@ietf.org
> Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-=
04
>
> Hi Tina,
>
> I agree with Yiu. FYI, we had a discussion between co-authors of the draf=
t
> whether we maintain
> http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section=
-8or remove it.
>
> You can read in that section:
>
>   " Additionally,
>   mechanisms such as MLD Snooping, MLD Proxying, etc., can be
>   introduced into the distributed Access Network Nodes (e.g.,
>   Aggregation Switches, xPON devices) which then could behave as MLD
>   Querier and replicate multicast flows as appropriate.  Thus, the
>   multicast replication point is moved downward closer to the
>   receivers, so that bandwidth consumption is optimized."
>
> What do you think is missing in that text?
>
> Cheers,
> Med
>
> ________________________________
>
> De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la
> part de Lee, Yiu
> Envoy=E9 : jeudi 25 ao=FBt 2011 05:31
> =C0 : softwires@ietf.org
> Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-0=
4
>
>
> Hi Tina,
>
> What do you see new here in this scenario? mAFTR is a logical function, i=
t
> would perform MLD PIMv4-Join interworking. This has been captured. If a
> vendor wants to make mAFTR also a L2 device, it would perform standard ML=
D
> snooping. What else is missing?
>
> Thanks,
> Yiu
>
> From: Tina TSOU 
> Date: Thu, 25 Aug 2011 02:11:18 +0000
> To: "softwires@ietf.org" 
> Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
>
>
>
> Hi all,
>
> One more comment on Section 7.4.2.
>
> This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also nee=
d
> to consider the scenario where it is layer 2 network between mAFTR and mB=
4.
> The architecture is as below:
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--bcaec51b9bfd88e95304ab61235e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi,

On Fri, Aug 26, 2011 at 10:31 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com=
> wrote:


Bonjour Med,

Thank you for your comments.

What Yiu said is not reflected in figure 3. In the current figure, mAFTR ca=
n receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 netw=
ork is layer 2 network, mAFTR should be able to receive MLD report as well.=
 mAFTR also performs MLD/PIMv4 interworking in this case. So I propose upda=
te figure 3 to be complete. Section 8 does not mention how mAFTR acts in th=
is case.




Jacni>: Figu=
re 3 illustrates the functional elements, not layer 2 multicast things, whi=
le the "IPv6 Network" in the figure can be layer 2 if you want to=
 understand it that way, no problem.

What you said concerning two different things,
* The layer 2 multicast m=
echanisms, like MLD Snooping, this approach is totally compatible with it. =
That's what Section 8 is talking about. Please see Yiu and Med's co=
mments.

* The MLD/PIMv4 is one of the scenarios, as we explained in previous emails=
. Also in the figure3, if there are "PIMv6 Routers in between", t=
he AFTR will receive PIMv6 join then do PIMv6/PIMv4, otherwise it will rece=
ive MLD messages then do MLD/PIMv4.



Cheers,
Jacni




Best Regards,

Tina TSOU

http:=
//tinatsou.weebly.com/contact.html






-----Original Message-----

From: softwires-bounces@ietf.=
org [mailto:softwires-bou=
nces@ietf.org] On Behalf Of mohamed.boucadair@orange-ftgroup.com


Sent: Thursday, August 25, 2011 1:11 AM

To: Lee, Yiu; softwires@ietf.org<=
br>
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04=




Hi Tina,



I agree with Yiu. FYI, we had a discussion between co-authors of the draft =
whether we maintain http://tools.ietf.org/ht=
ml/draft-qin-softwire-dslite-multicast-04#section-8 or remove it.




You can read in that section:



 =A0 " Additionally,

 =A0 mechanisms such as MLD Snooping, MLD Proxying, etc., can be

 =A0 introduced into the distributed Access Network Nodes (e.g.,

 =A0 Aggregation Switches, xPON devices) which then could behave as MLD

 =A0 Querier and replicate multicast flows as appropriate. =A0Thus, the

 =A0 multicast replication point is moved downward closer to the

 =A0 receivers, so that bandwidth consumption is optimized."



What do you think is missing in that text?



Cheers,

Med



________________________________



De : softwires-bounces@ietf.o=
rg [mailto:softwires-boun=
ces@ietf.org] De la part de Lee, Yiu

Envoy=E9 : jeudi 25 ao=FBt 2011 05:31

=C0 : softwires@ietf.org

Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04<=
br>




Hi Tina,



What do you see new here in this scenario? mAFTR is a logical function, it =
would perform MLD PIMv4-Join interworking. This has been captured. If a ven=
dor wants to make mAFTR also a L2 device, it would perform standard MLD sno=
oping. What else is missing?




Thanks,

Yiu



From: Tina TSOU <Tina.Ts=
ou.Zouting@huawei.com>

Date: Thu, 25 Aug 2011 02:11:18 +0000

To: "softwires@ietf.org"=
; <softwires@ietf.org>

Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04







Hi all,



One more comment on Section 7.4.2.



This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need =
to consider the scenario where it is layer 2 network between mAFTR and mB4.=
 The architecture is as below:

_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--bcaec51b9bfd88e95304ab61235e--

From jacniq@gmail.com  Thu Aug 25 21:40:07 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3BB21F8AD1 for ; Thu, 25 Aug 2011 21:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.424
X-Spam-Level: 
X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LRVM1kHqsZE for ; Thu, 25 Aug 2011 21:40:06 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84D9C21F8A7E for ; Thu, 25 Aug 2011 21:40:06 -0700 (PDT)
Received: by vws12 with SMTP id 12so3214460vws.31 for ; Thu, 25 Aug 2011 21:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pOqQCl/2rnw1jjDl2U9Lq2Q252BPXIg2KTL2ul7Ta9Q=; b=Y3PVia9Rn0Mm/Br5zFMle81TDwSQ0cRO6kywycd5les+YL+jb1hKxe7Ln8x9kvgXte bv9iUvDLs/Jd3od31yfRhjmq8/acoUp8gHR/OjiSNcftsukoOklbJL2jZBpzynOPmKUe SlAgDp7+erBXawUicSF7vjzsIZlFS6cmEJwlA=
MIME-Version: 1.0
Received: by 10.52.89.146 with SMTP id bo18mr664233vdb.246.1314333681386; Thu, 25 Aug 2011 21:41:21 -0700 (PDT)
Received: by 10.52.187.161 with HTTP; Thu, 25 Aug 2011 21:41:21 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 26 Aug 2011 12:41:21 +0800
Message-ID: 
From: Jacni Qin 
To: Tina TSOU 
Content-Type: multipart/alternative; boundary=bcaec50162b532067e04ab61283a
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 04:40:07 -0000

--bcaec50162b532067e04ab61283a
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU wrote:

> Hi all,
> In section 6.3, "To avoid fragmentation, a
>   service provider may increase the MTU size by 40 bytes on the IPv6
>   network or mAFTR and mB4 may use IPv6 Path MTU discovery."
>
> How to use IPv6 Path MTU discovery to avoid fragmentation?
>
> Jacni>: You can read RFC1981, thanks.


Cheers,
Jacni


>
>
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--bcaec50162b532067e04ab61283a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com=
> wrote:


Hi all,

In section 6.3, "To avoid fragmentation, a

 =A0 service provider may increase the MTU size by 40 bytes on the IPv6

 =A0 network or mAFTR and mB4 may use IPv6 Path MTU discovery."



How to use IPv6 Path MTU discovery to avoid fragmentation?


Jacni>: You can =
read RFC1981, thanks.


Cheers,
Jacni
=A0






Best Regards,

Tina TSOU

http:=
//tinatsou.weebly.com/contact.html







_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--bcaec50162b532067e04ab61283a--

From phdgang@gmail.com  Thu Aug 25 23:23:36 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA9E21F8B0C for ; Thu, 25 Aug 2011 23:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.592
X-Spam-Level: 
X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj6wDSdY03xa for ; Thu, 25 Aug 2011 23:23:35 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69CD421F8B0B for ; Thu, 25 Aug 2011 23:23:35 -0700 (PDT)
Received: by vws12 with SMTP id 12so3270636vws.31 for ; Thu, 25 Aug 2011 23:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lBEkrAeztHswywAL3WiIia9k3NtJrtENv8DQ99vU+Jk=; b=fLurF1jPZyPJmkI/emcu7Q16kdx7eJfQ/fw23kEfowlka5wOaEYMzd56BrzNKF8JIu q7z+EgnGIH5fri5EFsBBnYbhGjcAom23TcsvM8USbkjZF0W46FwwBCQxGNhAzcROkzi3 0a47zBWBPZMbnybajBEtGKTFL8DwwbMtWtF4o=
MIME-Version: 1.0
Received: by 10.52.27.201 with SMTP id v9mr389805vdg.485.1314339881098; Thu, 25 Aug 2011 23:24:41 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Thu, 25 Aug 2011 23:24:41 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 26 Aug 2011 14:24:41 +0800
Message-ID: 
From: GangChen 
To: Alain Durand 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "softwires@ietf.org" , Yong Cui 
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 06:23:37 -0000

Dear Chairs,

We would like to reserve a time slot for the presentation of
draft-murakami-softwire-4v6-translation in the interim meeting.
Many thanks for your helps

Best Regards

Gang


2011/8/22, Alain Durand :
> As we mentioned earlier, the softwire interim meeting will focus on
> 'stateless solutions'. If you'd like to present there, please send the
> chairs a note by Friday this week.
>
> Alain.
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

From mohamed.boucadair@orange-ftgroup.com  Thu Aug 25 23:47:13 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375121F8A7B for ; Thu, 25 Aug 2011 23:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.173
X-Spam-Level: 
X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vowv-q2u1v76 for ; Thu, 25 Aug 2011 23:47:12 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 89AAF21F8A69 for ; Thu, 25 Aug 2011 23:47:11 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 176052DC147; Fri, 26 Aug 2011 08:48:26 +0200 (CEST)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id F2D4227C087; Fri, 26 Aug 2011 08:48:25 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 26 Aug 2011 08:48:25 +0200
From: 
To: Tina TSOU , Jacni Qin 
Date: Fri, 26 Aug 2011 08:48:24 +0200
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: Acxh8St91klaU/mcRO6BhyFk9RPqPf//jGgA//9mLTD//oHFwP/8QTPQ//evoFD/7hZ1YP/b6DRQ
Message-ID: <94C682931C08B048B7A8645303FDC9F35166FB8651@PUEXCB1B.nanterre.francetelecom.fr>
References:    <94C682931C08B048B7A8645303FDC9F35166FB80A9@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35166FB83B1@PUEXCB1B.nanterre.francetelecom.fr> 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.26.31515
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 06:47:13 -0000

Hi Tina,
=20
Please see inline.

Cheers
Med=20

________________________________

De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20
Envoy=E9 : vendredi 26 ao=FBt 2011 04:35
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin
Cc : softwires@ietf.org
Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04



Hi Med,

In line with [TT2].

Best Regards,

[SNIP]

[Med] Using the same mPrefix64 for both encap and translation is not recomm=
ended in draft-boucadair-* as you can read in the following excerpt:

"   IPv4-IPv6 encapsulator and translator may be embedded in the same
   device or even implemented with the same software module.  In order
   to help the function whether an encapsulated IPv6 multicast packets
   or translated IPv6 ones are to be transferred.  It was tempting to
   define an S-bit for that purpose but this choice has been abandoned
   in favor of the recommendation to use distinct MPREFIX64 for each
   scheme."

I don't see an issue here.=20

[TT2] Since encapsulation and translation use different mPrefix64, it is no=
t an issue in draft-qin-* now. But draft-boucadair-* does not specify how t=
o make mPrefix64 different for encapsulation and translation. Do you think =
it is needed?

Med: I confirm this is not an issue for draft-qin. In draft-boucadair, we c=
an for sure clarify more and state "the operator of the v4/v6 multicast int=
ercinnection nodes configures two distinct mPREFIX64, ..."=

From mohamed.boucadair@orange-ftgroup.com  Thu Aug 25 23:53:09 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930121F8620 for ; Thu, 25 Aug 2011 23:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.181
X-Spam-Level: 
X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t+f28F6O0Yj for ; Thu, 25 Aug 2011 23:53:08 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 04F1B21F8520 for ; Thu, 25 Aug 2011 23:53:08 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1FFE922C777; Fri, 26 Aug 2011 08:54:23 +0200 (CEST)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0574D27C087; Fri, 26 Aug 2011 08:54:23 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 26 Aug 2011 08:54:23 +0200
From: 
To: Tina TSOU , "Lee, Yiu" , "softwires@ietf.org" 
Date: Fri, 26 Aug 2011 08:54:21 +0200
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMYTdUSUw9NjVHm0mqk4ZZAfKXSpUplPOAgAM/pfD//5HNAIAATioAgAG3aeCAAEoLYA==
Message-ID: <94C682931C08B048B7A8645303FDC9F35166FB8656@PUEXCB1B.nanterre.francetelecom.fr>
References:   <94C682931C08B048B7A8645303FDC9F35166FB840B@PUEXCB1B.nanterre.francetelecom.fr> 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.26.31515
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 06:53:09 -0000

Re-,

L2-relatd considerations described in Section 8 of draft-qin does not requi=
re any specific behaviour from the mAFTR.

I suggest we continue this thread off-line.

Cheers,
Med
=20

-----Message d'origine-----
De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20
Envoy=E9 : vendredi 26 ao=FBt 2011 04:31
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Lee, Yiu; softwires@ietf.org
Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Bonjour Med,
Thank you for your comments.
What Yiu said is not reflected in figure 3. In the current figure, mAFTR ca=
n receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 netw=
ork is layer 2 network, mAFTR should be able to receive MLD report as well.=
 mAFTR also performs MLD/PIMv4 interworking in this case. So I propose upda=
te figure 3 to be complete. Section 8 does not mention how mAFTR acts in th=
is case.


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh=
alf Of mohamed.boucadair@orange-ftgroup.com
Sent: Thursday, August 25, 2011 1:11 AM
To: Lee, Yiu; softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Tina,=20
=20
I agree with Yiu. FYI, we had a discussion between co-authors of the draft =
whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-mu=
lticast-04#section-8 or remove it.=20
=20
You can read in that section:=20

   " Additionally,
   mechanisms such as MLD Snooping, MLD Proxying, etc., can be
   introduced into the distributed Access Network Nodes (e.g.,
   Aggregation Switches, xPON devices) which then could behave as MLD
   Querier and replicate multicast flows as appropriate.  Thus, the
   multicast replication point is moved downward closer to the
   receivers, so that bandwidth consumption is optimized."

What do you think is missing in that text?
=20
Cheers,
Med

________________________________

De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p=
art de Lee, Yiu
Envoy=E9 : jeudi 25 ao=FBt 2011 05:31
=C0 : softwires@ietf.org
Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04


Hi Tina,=20

What do you see new here in this scenario? mAFTR is a logical function, it =
would perform MLD PIMv4-Join interworking. This has been captured. If a ven=
dor wants to make mAFTR also a L2 device, it would perform standard MLD sno=
oping. What else is missing?

Thanks,
Yiu

From: Tina TSOU 
Date: Thu, 25 Aug 2011 02:11:18 +0000
To: "softwires@ietf.org" 
Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04



Hi all,

One more comment on Section 7.4.2.

This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need =
to consider the scenario where it is layer 2 network between mAFTR and mB4.=
 The architecture is as below:
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

From yiu_lee@cable.comcast.com  Fri Aug 26 01:20:19 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5621F8B05 for ; Fri, 26 Aug 2011 01:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.633
X-Spam-Level: 
X-Spam-Status: No, score=-106.633 tagged_above=-999 required=5 tests=[AWL=1.830, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o48uxOqgm8i6 for ; Fri, 26 Aug 2011 01:20:18 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4070121F8A55 for ; Fri, 26 Aug 2011 01:20:18 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.138311921; Fri, 26 Aug 2011 04:21:29 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Fri, 26 Aug 2011 04:21:31 -0400
From: "Lee, Yiu" 
To: "softwires@ietf.org" 
Thread-Topic: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMY8koGuv8v1kkfUGydlJkOFu1XA==
Date: Fri, 26 Aug 2011 08:21:27 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [24.40.55.70]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6507E27E294FFD4AB094743CFECE8B96@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 08:20:19 -0000

Hi Tina,

Sure can but IPv6 MTU discovery like IPv4 MTU discovery, it is unreliable.
We can list it as an option but readers should notice this may not work in
all cases.

Regards,
Yiu

On 8/25/11 10:36 PM, "Tina TSOU"  wrote:

>Hi all,
>In section 6.3, "To avoid fragmentation, a
>   service provider may increase the MTU size by 40 bytes on the IPv6
>   network or mAFTR and mB4 may use IPv6 Path MTU discovery."
>
>How to use IPv6 Path MTU discovery to avoid fragmentation?
>
>
>
>Best Regards,
>Tina TSOU
>http://tinatsou.weebly.com/contact.html
>
>
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


From jiangdong345@gmail.com  Fri Aug 26 01:43:34 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDBE21F8B0A for ; Fri, 26 Aug 2011 01:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtOFyTOG5p8I for ; Fri, 26 Aug 2011 01:43:31 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC0B21F8839 for ; Fri, 26 Aug 2011 01:43:26 -0700 (PDT)
Received: by pzk33 with SMTP id 33so9142985pzk.18 for ; Fri, 26 Aug 2011 01:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=WFAYVLMHX6/HvVifcTeyNpFT0s98oSt7OkX+izFEuSU=; b=DvvYnHH4eTq6tDNYiXNq7hRIlEy/RBW2f/mbrzzpu6Oq1SIHLx6YVQRNCeJ8KxZrgC Vlh50sElYzsgKnpdoEfbSP20pD3VD6iuNO51M3QtiBRIzEeGfq53KFxDIRxK0BksR7IH R5YxEKB3tixmrdDDhPmc9jQ1Fx4eCbI1hGBy4=
Received: by 10.142.163.5 with SMTP id l5mr424008wfe.279.1314348279282; Fri, 26 Aug 2011 01:44:39 -0700 (PDT)
Received: from DJ-PC ([166.111.68.231]) by mx.google.com with ESMTPS id e8sm1583168pbc.8.2011.08.26.01.44.36 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 01:44:37 -0700 (PDT)
Date: Fri, 26 Aug 2011 16:45:13 +0800
From: Jiang Dong 
To: "Yong Cui" , "softwires@ietf.org" 
References: 
Message-ID: <201108261645103817565@gmail.com>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
Cc: Yong Cui 
Subject: Re: [Softwires] New working group documents
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 08:43:34 -0000

Hi,
	I support all of them to become WG drafts.
  
Best Regards!
Jiang Dong
>Hi folks,
>
>Following our rough concensus during Quebec City meeting and
>according to our charter/milestones, the chairs would like to
>ask the mailing list for the confirmation to adopt the following
>drafts:
>
>1. Deployment Considerations for Dual-Stack Lite
>http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/
>
>
>2. Public IPv4 over Access IPv6 Network
>http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/
>
>3. Softwire Mesh Multicast
>http://datatracker.ietf.org/doc/draft-xu-softwire-mesh-multicast/
>
>4. Multicast Extensions to DS-Lite Technique in Broadband Deployments
>http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04/
>
>5. Motivations for Stateless IPv4 over IPv6 Migration Solutions
>http://datatracker.ietf.org/doc/draft-operators-softwire-stateless-4v6-moti
>vation/
>
>Please send your comments by 10am EDT on Aug 27. If you object to
>adoption, please also give the detailed reasons.
>
>
>
>--Alain & Yong
>
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


From xiaohong.deng@orange-ftgroup.com  Fri Aug 26 02:30:29 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B6221F8B3B for ; Fri, 26 Aug 2011 02:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.605
X-Spam-Level: 
X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.643,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi7SJ5L9cPnc for ; Fri, 26 Aug 2011 02:30:28 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 04ACD21F8B39 for ; Fri, 26 Aug 2011 02:30:28 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 64AE6FC40D6; Fri, 26 Aug 2011 11:31:06 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9DCF7FC4033; Fri, 26 Aug 2011 11:31:00 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 26 Aug 2011 11:30:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC63D2.D18E3EDC"
Date: Fri, 26 Aug 2011 17:30:39 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0199A142@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Thread-Index: Acxj0tEsnkWBSZdXSPSkRzRcpadtEA==
References:  
From: 
To: , 
X-OriginalArrivalTime: 26 Aug 2011 09:30:43.0105 (UTC) FILETIME=[D396A910:01CC63D2]
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 09:30:29 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC63D2.D18E3EDC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20


________________________________

	From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20
	Sent: Thursday, August 25, 2011 11:31 AM
	To: softwires@ietf.org
	Subject: Re: [Softwires] Comments on
draft-qin-softwire-dslite-multicast-04
=09
=09
	Hi Tina,=20

	What do you see new here in this scenario? mAFTR is a logical
function, it would perform MLD PIMv4-Join interworking. This has been
captured. If a vendor wants to make mAFTR also a L2 device, it would
perform standard MLD snooping. What else is missing?=20
	=20
	Xiaohong: Exactly. I also wonder what's missing to your eyes? ;)
	=20
	Cheers,
	Xiaohong=20

	Thanks,
	Yiu

=09
	From: Tina TSOU 
	Date: Thu, 25 Aug 2011 02:11:18 +0000
	To: "softwires@ietf.org" 
	Subject: [Softwires] Comments on
draft-qin-softwire-dslite-multicast-04
=09


	Hi all,

	One more comment on Section 7.4.2.

=09

	This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We
also need to consider the scenario where it is layer 2 network between
mAFTR and mB4. The architecture is as below:

=09

	------------

	/               \

	| IPv4 network |

	\                /

	------------

	: | ^

	IPv4 Multicast : | : PIMv4 Join

	v | :

	+-------------+

	|    mAFTR      |

	+-------------+

	|:| | ^

	IPv6 Multicast |:| | : (MLD Report)

	(IPv4 embedded) |.| ... .

	+-----------+

	| MLD proxy/|

	| snooping   |

	+-----------+

	|:| | : MLD Report

	|v| | :

	+-----------+

	|      mB4    |

	+-----------+

	: | ^

	IPv4 Multicast : | : IGMP Report

	v | :

	+-----------+

	|     IPv4   |

	|  Receiver |

	+-----------+

=09

	B. R.

	Tina

=09

=09

	_______________________________________________ Softwires
mailing list Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires=20


------_=_NextPart_001_01CC63D2.D18E3EDC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







 



  

  

  From: Lee, Yiu=20
  [mailto:Yiu_Lee@Cable.Comcast.com] 
Sent: Thursday, August =
25, 2011=20
  11:31 AM
To: softwires@ietf.org
Subject: Re: =
[Softwires]=20
  Comments on =
draft-qin-softwire-dslite-multicast-04


  

  
Hi Tina, 

  


  
What do you see new here in this scenario? mAFTR is a logical =
function,=20
  it would perform MLD PIMv4-Join interworking. This has been captured. =
If a=20
  vendor wants to make mAFTR also a L2 device, it would perform standard =
MLD=20
  snooping. What else is missing? 

  
 

  
Xiaohong:=20
  Exactly. I also wonder what's missing to your eyes? =
;)

  
 

  
Cheers,

  
Xiaohong 

  


  
Thanks,

  
Yiu

  


  From: Tina TSOU <Tina.Tsou.Zouting@huawei.com=
>
Date: Thu, 25 Aug 2011 02:11:18=20
  +0000
To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] Comments on=20
  draft-qin-softwire-dslite-multicast-04

  


  

  
  
  
  

  

  

  
Hi all,

  
One=20
  more comment on Section 7.4.2.

  

  
This document only covers IGMP-MLD and =
PIMv6-PIMv4=20
  scenarios. We also need to consider the scenario where it is layer 2 =
network=20
  between mAFTR and mB4. The architecture is as below:

  

  
------------

  
/          &nb=
sp;   =20
  \

  
| =
IPv4 network=20
  |

  
\          &nb=
sp;    =20
  /

  
------------

  
: | =

  ^

  
IPv4 Multicast=20
  : | : PIMv4 Join

  
v | =

  :

  
+-------------+

  
|   =20
  mAFTR      |

  
+-------------+

  
|:| =
|=20
  ^

  
IPv6 Multicast=20
  |:| | : (MLD Report)

  
(IPv4 embedded)=20
  |.| ... .

  
+-----------+

  
| =
MLD=20
  proxy/|

  
|=20
  snooping   |

  
+-----------+

  
|:| =
| : MLD=20
  Report

  
|v| =
|=20
  :

  
+-----------+

  
|     =20
  mB4    |

  
+-----------+

  
: | =

  ^

  
IPv4 Multicast=20
  : | : IGMP Report

  
v | =

  :

  
+-----------+

  
|    =20
  IPv4   |

  
| =20
  Receiver |

  
+-----------+

  

  
B. R.

  
Tina

  

  
___________________=
____________________________=20
  Softwires mailing list Softwires@ietf.org https://www.ietf=
.org/mailman/listinfo/softwires=20
  

------_=_NextPart_001_01CC63D2.D18E3EDC--

From phdgang@gmail.com  Fri Aug 26 04:05:57 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92BB21F8B28 for ; Fri, 26 Aug 2011 04:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.593
X-Spam-Level: 
X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuEwkAWivmxL for ; Fri, 26 Aug 2011 04:05:57 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07BEC21F8726 for ; Fri, 26 Aug 2011 04:05:56 -0700 (PDT)
Received: by vxi29 with SMTP id 29so3105770vxi.31 for ; Fri, 26 Aug 2011 04:07:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hmtVMkkby3ByKSAdomd0KqTzOFkS61ow00R+DP/io9I=; b=ljkrNKwMPnJLyn1ZMLBDCf4ro699G48dsffO3svgQiuq5t91EuDiViXsJW4VgwgkaA xh8ujLLM4KDtqb7b3OajW7v27SY77TKJ8cyG+6CP79uP+PpF34p3O806Nz2qz1UJStGu JdbLNyI0mgKv4EDEB1PzwLm4IgVE8/17RO8IY=
MIME-Version: 1.0
Received: by 10.52.76.134 with SMTP id k6mr913283vdw.418.1314356832717; Fri, 26 Aug 2011 04:07:12 -0700 (PDT)
Received: by 10.52.156.165 with HTTP; Fri, 26 Aug 2011 04:07:12 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 26 Aug 2011 19:07:12 +0800
Message-ID: 
From: GangChen 
To: Alain Durand , Yong Cui 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 11:05:57 -0000

Dear Chairs,

Could you also consider allocating a time slot for draft-chen-softwire-4v6-pd-00
http://www.ietf.org/internet-drafts/draft-chen-softwire-4v6-pd-00.txt

The detailed information could be found as below.
A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : Prefix Delegation in 4V6
       Author(s)       : Gang Chen, Tao Sun, Hui Deng
       Filename        : draft-chen-softwire-4v6-pd-00.txt
       Pages           : 8
       Date            : 2011-08-26

  This draft presents the investigation of 4via6 in the scenario where
  IPv6 prefix delegation is deployed.  A practicable application
  scenarios with IPv6 prefix delegation have been introduced in the
  mobile network environments.  The applicability of 4via6 mechnism has
  been analyzed in term of mapping rules and 4via6 address structure.
  Targeting to alignment with existing 4via6 mapping algorithm and
  RFC6052 recommendation, an alternative 4via6 address structure have
  been proposed to be capable of assigning flexible address/port set to
  4via6 domains.

Many thanks for your kind helps.

Gang


2011/8/26, GangChen :
> Dear Chairs,
>
> We would like to reserve a time slot for the presentation of
> draft-murakami-softwire-4v6-translation in the interim meeting.
> Many thanks for your helps
>
> Best Regards
>
> Gang
>
>
> 2011/8/22, Alain Durand :
>> As we mentioned earlier, the softwire interim meeting will focus on
>> 'stateless solutions'. If you'd like to present there, please send the
>> chairs a note by Friday this week.
>>
>> Alain.
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>

From hisuntao@gmail.com  Fri Aug 26 04:30:21 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8821F89BA for ; Fri, 26 Aug 2011 04:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbmo2Rzvl1Hd for ; Fri, 26 Aug 2011 04:30:21 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1DB021F8584 for ; Fri, 26 Aug 2011 04:30:20 -0700 (PDT)
Received: by vws12 with SMTP id 12so152672vws.31 for ; Fri, 26 Aug 2011 04:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2JuyD4/TQYdEWEwPeG/uiRG4V2V4ZwNIMZrvFQbKaJ4=; b=OYmMdXhZDyR64EXrJXm6mUxyWJ83O6kDMdPhkmO6Q1Ib0VFLS/TfEK1B8vaKmDZb8G 8zGVL15cH6C6VlqvaMg4LV8pQ93LvDsv3u29Q5c0731AgnjkNAY597V9YqyigcqUI8Fl /BHXUosz5tMHmCmrUPVmv7px1m5M6EsmOVF0g=
MIME-Version: 1.0
Received: by 10.52.100.72 with SMTP id ew8mr1013038vdb.247.1314358296699; Fri, 26 Aug 2011 04:31:36 -0700 (PDT)
Received: by 10.220.96.131 with HTTP; Fri, 26 Aug 2011 04:31:36 -0700 (PDT)
In-Reply-To: 
References:   
Date: Fri, 26 Aug 2011 19:31:36 +0800
Message-ID: 
From: Tao Sun 
To: GangChen 
Content-Type: multipart/alternative; boundary=20cf3071cd1c61e21304ab66e3c2
Cc: "softwires@ietf.org" , Yong Cui 
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 11:30:21 -0000

--20cf3071cd1c61e21304ab66e3c2
Content-Type: text/plain; charset=ISO-8859-1

Dear Chairs,

As Gang mentioned, we would like to request for a time slot for the
presentation of
http://www.ietf.org/internet-drafts/draft-chen-softwire-4v6-pd-00.txt
Thanks for your consideration!

Tao

On Fri, Aug 26, 2011 at 7:07 PM, GangChen  wrote:

> Dear Chairs,
>
> Could you also consider allocating a time slot for
> draft-chen-softwire-4v6-pd-00
> http://www.ietf.org/internet-drafts/draft-chen-softwire-4v6-pd-00.txt
>
> The detailed information could be found as below.
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>       Title           : Prefix Delegation in 4V6
>       Author(s)       : Gang Chen, Tao Sun, Hui Deng
>       Filename        : draft-chen-softwire-4v6-pd-00.txt
>       Pages           : 8
>       Date            : 2011-08-26
>
>  This draft presents the investigation of 4via6 in the scenario where
>  IPv6 prefix delegation is deployed.  A practicable application
>  scenarios with IPv6 prefix delegation have been introduced in the
>  mobile network environments.  The applicability of 4via6 mechnism has
>  been analyzed in term of mapping rules and 4via6 address structure.
>  Targeting to alignment with existing 4via6 mapping algorithm and
>  RFC6052 recommendation, an alternative 4via6 address structure have
>  been proposed to be capable of assigning flexible address/port set to
>  4via6 domains.
>
> Many thanks for your kind helps.
>
> Gang
>
>
> 2011/8/26, GangChen :
>  > Dear Chairs,
> >
> > We would like to reserve a time slot for the presentation of
> > draft-murakami-softwire-4v6-translation in the interim meeting.
> > Many thanks for your helps
> >
> > Best Regards
> >
> > Gang
> >
> >
> > 2011/8/22, Alain Durand :
> >> As we mentioned earlier, the softwire interim meeting will focus on
> >> 'stateless solutions'. If you'd like to present there, please send the
> >> chairs a note by Friday this week.
> >>
> >> Alain.
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >>
> >
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--20cf3071cd1c61e21304ab66e3c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Dear Chairs,


=A0


As Gang mentioned, we would like to request for a time slot for the pr=
esentation of 



Thanks for your consideration!


=A0


Tao



On Fri, Aug 26, 2011 at 7:07 PM, GangChen <phdgang@gmail.com&=
gt; wrote:


Dear Chairs,

Could you al=
so consider allocating a time slot for draft-chen-softwire-4v6-pd-00
http://www.ietf.org/internet-drafts/draft-chen-softwi=
re-4v6-pd-00.txt


The detailed information could be found as below.
A New Internet-Dra=
ft is available from the on-line Internet-Drafts directories.

=A0 =
=A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Prefix Delegation in 4V6
=A0 =A0 =A0=
 Author(s) =A0 =A0 =A0 : Gang Chen, Tao Sun, Hui Deng

=A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-chen-softwire-4v6-pd-00.txt
=
=A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 Date =A0 =A0 =A0 =
=A0 =A0 =A0: 2011-08-26

=A0This draft presents the investigation of =
4via6 in the scenario where
=A0IPv6 prefix delegation is deployed. =A0A =
practicable application

=A0scenarios with IPv6 prefix delegation have been introduced in the
=A0=
mobile network environments. =A0The applicability of 4via6 mechnism has
=
=A0been analyzed in term of mapping rules and 4via6 address structure.
=
=A0Targeting to alignment with existing 4via6 mapping algorithm and

=A0RFC6052 recommendation, an alternative 4via6 address structure have
=
=A0been proposed to be capable of assigning flexible address/port set to=A04via6 domains.

Many thanks for your kind helps.

Gang
<=
br>

2011/8/26, GangChen <phdgang@gm=
ail.com>:






> Dear Chairs,
>
> We would like to reserv=
e a time slot for the presentation of
> draft-murakami-softwire-4v6-t=
ranslation in the interim meeting.
> Many thanks for your helps

>
> Best Regards
>
> Gang
>
>
> 2011=
/8/22, Alain Durand <adurand@juni=
per.net>:
>> As we mentioned earlier, the softwire interim =
meeting will focus on

>> 'stateless solutions'. If you'd like to present there,=
 please send the
>> chairs a note by Friday this week.
>>=

>> Alain.
>> ___________________________________________=
____

>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/l=
istinfo/softwires

>>
>
_______________________________________________
Soft=
wires mailing list
Softwires@ietf.=
org
https://www.ietf.org/mailman/listinfo/softwires





--20cf3071cd1c61e21304ab66e3c2--

From wdec.ietf@gmail.com  Fri Aug 26 05:29:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F93721F8B20 for ; Fri, 26 Aug 2011 05:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.473
X-Spam-Level: 
X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ2h5CfhOEzz for ; Fri, 26 Aug 2011 05:29:53 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C321F8B1B for ; Fri, 26 Aug 2011 05:29:53 -0700 (PDT)
Received: by bkar4 with SMTP id r4so2906781bka.31 for ; Fri, 26 Aug 2011 05:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3TirbgA0X/jJvmLWu8Y+r6l9maBV9l8br21zTOjnw4g=; b=wrPSB5NBTgRK/wLfLPsNCyjM+cJGFATN+gwXYgRtnPQchfD8rrk3LNDAI2+WQTguoc iytyIDxhxnHZKQvahnnj+Yqv2ly6Y7xUK4cMRRoRFugYxvxf2OtmKw7y0J5aRr1e3DVY rP7P6FooXCfCxibKR2rP/Z2qLxJxWgU4eo6pk=
MIME-Version: 1.0
Received: by 10.204.148.154 with SMTP id p26mr600625bkv.160.1314361868976; Fri, 26 Aug 2011 05:31:08 -0700 (PDT)
Received: by 10.204.142.213 with HTTP; Fri, 26 Aug 2011 05:31:08 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 26 Aug 2011 14:31:08 +0200
Message-ID: 
From: Wojciech Dec 
To: Alain Durand 
Content-Type: multipart/alternative; boundary=0015175cb4ce4e814c04ab67b813
Cc: "softwires@ietf.org" , Yong Cui 
Subject: Re: [Softwires] Call for presentations for the interim meeting
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 12:29:54 -0000

--0015175cb4ce4e814c04ab67b813
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I would like to ask two slots to present:

1. http://tools.ietf.org/html/draft-dec-stateless-4v6
2. Stateless port mapping algorithms overview

Regards,
Wojciech.



On 22 August 2011 17:37, Alain Durand  wrote:

> As we mentioned earlier, the softwire interim meeting will focus on
> 'stateless solutions'. If you'd like to present there, please send the
> chairs a note by Friday this week.
>
> Alain.
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--0015175cb4ce4e814c04ab67b813
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

I would like to ask two slots to present:

1. http://tools.ietf.o=
rg/html/draft-dec-stateless-4v6
2. Stateless port mapping algorithms=
 overview


Regards,
Wojciech.



On 22 A=
ugust 2011 17:37, Alain Durand <adurand@juniper.net> wrote:

As we mentioned earlier, the softwire interim meeting will focus on 'st=
ateless solutions'. If you'd like to present there, please send the=
 chairs a note by Friday this week.



Alain.

_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--0015175cb4ce4e814c04ab67b813--

From Tina.Tsou.Zouting@huawei.com  Fri Aug 26 11:31:14 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC6021F8663 for ; Fri, 26 Aug 2011 11:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.363,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHka6UNz3qPT for ; Fri, 26 Aug 2011 11:31:12 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2819521F8610 for ; Fri, 26 Aug 2011 11:31:11 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQJ00JECSU2H2@szxga04-in.huawei.com> for softwires@ietf.org; Sat, 27 Aug 2011 02:32:26 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQJ00JFWSU2IG@szxga04-in.huawei.com> for softwires@ietf.org; Sat, 27 Aug 2011 02:32:26 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK88344; Sat, 27 Aug 2011 02:32:26 +0800 (CST)
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 27 Aug 2011 02:32:25 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Sat, 27 Aug 2011 02:32:21 +0800
Date: Fri, 26 Aug 2011 18:32:19 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.212.246.30]
To: Jacni Qin 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_2QoAG5nWhj05Vf1Hy3RBYQ)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
Thread-index: AcxjmPgnI5wwISDaTQaEaDW2WODLbv//nMGA//6SgAA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:  
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 18:31:14 -0000

--Boundary_(ID_2QoAG5nWhj05Vf1Hy3RBYQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Dear Jacni,
Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says, "It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends.  This may result in a packet size that exceeds the Path MTU.
To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header")."

If the node which makes PMTU is the multicast source, it can change the size of message when the size exceeds the PMTU value.
However, mAFTR, as a router, is unable to change the size of the message. Here is an example: An IPv4 packet is sent from the multicast source to mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does mAFTR forward the packet? One possible way is to make IPv6 fragmentation, with two fragments: one is 960 and the other is 40 with "IPv6 Fragment Header".
In addition, there may be also other ways to avoid fragmentation, e.g., cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: Thursday, August 25, 2011 9:41 PM
To: Tina TSOU
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

Hi,
On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU > wrote:
Hi all,
In section 6.3, "To avoid fragmentation, a
  service provider may increase the MTU size by 40 bytes on the IPv6
  network or mAFTR and mB4 may use IPv6 Path MTU discovery."

How to use IPv6 Path MTU discovery to avoid fragmentation?
Jacni>: You can read RFC1981, thanks.


Cheers,
Jacni



Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html



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


--Boundary_(ID_2QoAG5nWhj05Vf1Hy3RBYQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT













Dear Jacni,


Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says, “It is possible that a
packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends. 
This may result in a packet size that exceeds the Path MTU.


To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with
 each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header").”


 


If the node which makes PMTU is the multicast source, it can change the size of message when the size exceeds the PMTU
 value.


However,
mAFTR, as a router, is unable to change the size of the message. Here is an example: An IPv4 packet is sent from the multicast source to
mAFTR with size of 1000, while the IPv6 PMTU for 
mAFTR and mB4 is 960, how does mAFTR forward the packet? One possible way is to make IPv6 fragmentation, with two fragments: one is 960 and the other is 40 with “IPv6 Fragment Header”.


In addition, there may be also other ways to avoid fragmentation, e.g., cache in
mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].


 


 


Best Regards,


Tina TSOU


http://tinatsou.weebly.com/contact.html


 


 




From: Jacni
 Qin [mailto:jacniq@gmail.com] 

Sent: Thursday, August 25, 2011 9:41 PM

To: Tina TSOU

Cc: softwires@ietf.org

Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04




 


Hi,




On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:


Hi all,

In section 6.3, "To avoid fragmentation, a

  service provider may increase the MTU size by 40 bytes on the IPv6

  network or mAFTR and mB4 may use IPv6 Path MTU discovery."



How to use IPv6 Path MTU discovery to avoid fragmentation?




Jacni>: You can read RFC1981, thanks.





Cheers,

Jacni

 










Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html







_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires






 






--Boundary_(ID_2QoAG5nWhj05Vf1Hy3RBYQ)--

From jacniq@gmail.com  Fri Aug 26 18:46:56 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7921F87C9 for ; Fri, 26 Aug 2011 18:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.429
X-Spam-Level: 
X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.169,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU6Sx1eRl-+L for ; Fri, 26 Aug 2011 18:46:56 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3038C21F8785 for ; Fri, 26 Aug 2011 18:46:56 -0700 (PDT)
Received: by vws12 with SMTP id 12so865261vws.31 for ; Fri, 26 Aug 2011 18:48:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yton9bZJHl/tPV4enxbIo1hJHFvyR4TokzVA190GGXI=; b=XRd0RtD26XXhY0IwfrNQRYpJRsVce9BSNAQeDh2CPFLEqGJ2ICS/rUeBnue20U5y+s uAyO+GfHIRO3mFua0obWHF19iH6THKGwUbsmb58A+ZNGb/HhI9p//wOp8HQ1UoG/Vmgf 6EgjW33XM4APojokzLtCjEwZmbpvFnZYxwQ14=
MIME-Version: 1.0
Received: by 10.52.34.171 with SMTP id a11mr1690256vdj.313.1314409692965; Fri, 26 Aug 2011 18:48:12 -0700 (PDT)
Received: by 10.52.187.161 with HTTP; Fri, 26 Aug 2011 18:48:12 -0700 (PDT)
In-Reply-To: 
References:   
Date: Sat, 27 Aug 2011 09:48:12 +0800
Message-ID: 
From: Jacni Qin 
To: Tina TSOU 
Content-Type: multipart/alternative; boundary=20cf307ca0b2d6ac8b04ab72da81
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Aug 2011 01:46:57 -0000

--20cf307ca0b2d6ac8b04ab72da81
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi,

On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU wr=
ote:

>  Dear Jacni,****
>
> Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In
> section 5.1, it says, =93It is possible that a packetization layer, perha=
ps
> a UDP application outside the kernel, is unable to change the size of
> messages it sends.  This may result in a packet size that exceeds the Pat=
h
> MTU.****
>
> To accommodate such situations, IPv6 defines a mechanism that allows larg=
e
> payloads to be divided into fragments, with each fragment sent in a separ=
ate
> packet (see [IPv6-SPEC] section "Fragment Header").=94****
>
> ** **
>
> If the node which makes PMTU is the multicast source, it can change the
> size of message when the size exceeds the PMTU value.****
>
> However, mAFTR, as a router, is unable to change the size of the message.
> Here is an example: An IPv4 packet is sent from the multicast source to
> mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, ho=
w
> does mAFTR forward the packet? One possible way is to make IPv6
> fragmentation, with two fragments: one is 960 and the other is 40 with =
=93IPv6
> Fragment Header=94.****
>
> In addition, there may be also other ways to avoid fragmentation, e.g.,
> cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].****
>
> ** **
>
> **
>
Jacni>: Please see Yiu's comments,
while for the discovery if you really want to do it, this way to help you t=
o
understand, it's the end point of tunnel which seems to "source" the v6
packets. Hope you can get it.


Cheers,
Jacni

--20cf307ca0b2d6ac8b04ab72da81
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi,

On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com&=
gt; wrote:















Dear =
Jacni,


Just =
after reading RFC 1981, I think fragmentation of IPv6 is needed. In section=
 5.1, it says, =93It is possible that a
packetization layer, perhaps a UDP application outside the ker=
nel, is unable to change the size of messages it sends.=A0
This may result in a packet size that exceeds the Path MTU.


To ac=
commodate such situations, IPv6 defines a mechanism that allows large paylo=
ads to be divided into fragments, with
 each fragment sent in a separate packet (see [IPv6-SPEC] section "Fra=
gment Header").=94


=A0


If th=
e node which makes PMTU is the multicast source, it can change the size of =
message when the size exceeds the PMTU
 value.


Howev=
er,
mAFTR, as a router, is unable to change the size of the messag=
e. Here is an example: An IPv4 packet is sent from the multicast source to
mAFTR with size of 1000, while the IPv6 PMTU for 
mAFTR and mB4 is 960, how does mAFTR forward the packet=
? One possible way is to make IPv6 fragmentation, with two fragments: one i=
s 960 and the other is 40 with =93IPv6 Fragment Header=94.



In ad=
dition, there may be also other ways to avoid fragmentation, e.g., cache in
mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].<=
u>


=A0


Jacni>: Please see Yiu's comment=
s,=A0


while fo=
r the discovery if you really want to do it, this way to help you to unders=
tand, it's the end point of tunnel which seems to "source" th=
e v6 packets. Hope you can get it.




Cheers,


Jacni

To: "softwires@ietf.org" 
Thread-Topic: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
Thread-Index: AQHMZZ3WE/W6xmFQcUaXwoqCwuKjXg==
Date: Sun, 28 Aug 2011 16:16:27 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [68.82.30.70]
Content-Type: multipart/alternative; boundary="_000_CA7FE0AF1443Ayiuleecablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Aug 2011 16:15:13 -0000

--_000_CA7FE0AF1443Ayiuleecablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Tina,

To use PMTU in this scenario, this is more complicated than what you explai=
n. First, this traffic flow is from mAFTR to the mB4. In between, there cou=
ld be more than one IPv6 multicast routers. In our spec, mAFTR will replica=
te the packet once in the multicast I/F to the IPv6 MDT, can you explain to=
 me your poropose how PMTU can work here? Does it mean mAFTR will send PMTU=
 to every B4s and take the least common denominator?

Regards,
Yiu

From: Jacni Qin >
Date: Sat, 27 Aug 2011 09:48:12 +0800
To: Tina TSOU >
Cc: "softwires@ietf.org" >
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dsli=
te-multicast-04

hi,

On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU > wrote:
Dear Jacni,
Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In se=
ction 5.1, it says, =93It is possible that a packetization layer, perhaps a=
 UDP application outside the kernel, is unable to change the size of messag=
es it sends.  This may result in a packet size that exceeds the Path MTU.
To accommodate such situations, IPv6 defines a mechanism that allows large =
payloads to be divided into fragments, with each fragment sent in a separat=
e packet (see [IPv6-SPEC] section "Fragment Header").=94

If the node which makes PMTU is the multicast source, it can change the siz=
e of message when the size exceeds the PMTU value.
However, mAFTR, as a router, is unable to change the size of the message. H=
ere is an example: An IPv4 packet is sent from the multicast source to mAFT=
R with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does=
 mAFTR forward the packet? One possible way is to make IPv6 fragmentation, =
with two fragments: one is 960 and the other is 40 with =93IPv6 Fragment He=
ader=94.
In addition, there may be also other ways to avoid fragmentation, e.g., cac=
he in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].

Jacni>: Please see Yiu's comments,
while for the discovery if you really want to do it, this way to help you t=
o understand, it's the end point of tunnel which seems to "source" the v6 p=
ackets. Hope you can get it.


Cheers,
Jacni


_______________________________________________ Softwires mailing list Soft=
wires@ietf.org https://www.ietf.org/mailman/list=
info/softwires

--_000_CA7FE0AF1443Ayiuleecablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Tina,







To use PMTU in this scenario, this is more complicated than what you e=
xplain. First, this traffic flow is from mAFTR to the mB4. In between, ther=
e could be more than one IPv6 multicast routers. In our spec, mAFTR will re=
plicate the packet once in the multicast
 I/F to the IPv6 MDT, can you explain to me your poropose how PMTU can work=
 here? Does it mean mAFTR will send PMTU to every B4s and take the least co=
mmon denominator?







Regards,


Yiu









From: Jacni Qin <jacniq@gmail.com>

Date: Sat, 27 Aug 2011 09:48:12 =
3;0800

To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>

Cc: "softwires@ietf.org" <softwires@ietf.org>

Subject: Re: [Softwires] Comments o=
n section 6.3 of draft-qin-softwire-dslite-multicast-04








hi,




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



--_000_CA7FE0AF1443Ayiuleecablecomcastcom_--

From Tina.Tsou.Zouting@huawei.com  Mon Aug 29 15:53:57 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAB921F8C77 for ; Mon, 29 Aug 2011 15:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.252
X-Spam-Level: 
X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=0.346,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo5eSqDJAMiJ for ; Mon, 29 Aug 2011 15:53:55 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DD7D121F8C5D for ; Mon, 29 Aug 2011 15:53:54 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQP00GZRP08NJ@szxga03-in.huawei.com> for softwires@ietf.org; Tue, 30 Aug 2011 06:55:20 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQP0061MP07DQ@szxga03-in.huawei.com> for softwires@ietf.org; Tue, 30 Aug 2011 06:55:20 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119])	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADM05522; Tue, 30 Aug 2011 06:55:18 +0800 (CST)
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 30 Aug 2011 06:55:15 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Tue, 30 Aug 2011 06:55:16 +0800
Date: Mon, 29 Aug 2011 22:55:14 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.212.244.201]
To: Jacni Qin 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_PrftijI5hVmbomFXAa8NOw)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
Thread-index: AcxjmPgnI5wwISDaTQaEaDW2WODLbv//nMGA//6SgACAAs90AP/688dw
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2011 22:53:57 -0000

--Boundary_(ID_PrftijI5hVmbomFXAa8NOw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Dear Jacni,
Thank you for your reply even you are travelling.
Comments in line with [TT] ...


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: Friday, August 26, 2011 6:48 PM
To: Tina TSOU
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

hi,
On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU > wrote:
Dear Jacni,
Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says, "It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends.  This may result in a packet size that exceeds the Path MTU.
To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header")."

If the node which makes PMTU is the multicast source, it can change the size of message when the size exceeds the PMTU value.
However, mAFTR, as a router, is unable to change the size of the message. Here is an example: An IPv4 packet is sent from the multicast source to mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does mAFTR forward the packet? One possible way is to make IPv6 fragmentation, with two fragments: one is 960 and the other is 40 with "IPv6 Fragment Header".
In addition, there may be also other ways to avoid fragmentation, e.g., cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].

Jacni>: Please see Yiu's comments,
while for the discovery if you really want to do it, this way to help you to understand, it's the end point of tunnel which seems to "source" the v6 packets. Hope you can get it.

[TT] If you want mAFTR to "source" the v6 packet, you need some mechanism like cache to make it happen as I mentioned in my last email. But it is a little bit complicated. Anyway, to be more readable, I suggest specify it clearly in the draft.


Cheers,
Jacni



--Boundary_(ID_PrftijI5hVmbomFXAa8NOw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable













Dear Jacni,


Thank you for your reply even you are travelling.


Comments in line with [TT] …=



 


 


Best Regards,

Tina TSOU


http://tinatsou.weebly.com/contact=
.html


 


 




From: Jacni
 Qin [mailto:jacniq@gmail.com] 

Sent: Friday, August 26, 2011 6:48 PM

To: Tina TSOU

Cc: softwires@ietf.org

Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwi=
re-dslite-multicast-04




 


hi,




On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com=
> wrote:






Dear Jacni,<=
o:p>


Just after reading =
RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says,=
 “It is possible that a packetization
 layer, perhaps a UDP application outside the kernel, is unable to change t=
he size of messages it sends.  This may result in a packet size that e=
xceeds the Path MTU.


To accommodate such=
 situations, IPv6 defines a mechanism that allows large payloads to be divi=
ded into fragments, with each fragment
 sent in a separate packet (see [IPv6-SPEC] section "Fragment Header&q=
uot;).”


 <=
/o:p>


If the node which m=
akes PMTU is the multicast source, it can change the size of message when t=
he size exceeds the PMTU value.


However, mAFTR, as =
a router, is unable to change the size of the message. Here is an example: =
An IPv4 packet is sent from the multicast
 source to mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 i=
s 960, how does mAFTR forward the packet? One possible way is to make IPv6 =
fragmentation, with two fragments: one is 960 and the other is 40 with R=
20;IPv6 Fragment Header”.


In addition, there =
may be also other ways to avoid fragmentation, e.g., cache in mAFTR as defi=
ned in [draft-jiang-behave-v4v6mc-proxy].




 <=
/o:p>










Jacni>: Please see Yiu's comments, <=
/o:p>






while for the discovery if you really want to do it, thi=
s way to help you to understand, it's the end point of tunnel which seems t=
o "source" the v6 packets. Hope you can get it.=







 


[TT] If you want
mAFTR to “source” the v6 packet, =
you need some mechanism like cache to make it happen as I mentioned in my l=
ast email. But it is a little bit complicated. Anyway, to be more readable,=
 I suggest specify it clearly in the draft.


 






 






Cheers,






Jacni






 






 










--Boundary_(ID_PrftijI5hVmbomFXAa8NOw)--

From internet-drafts@ietf.org  Tue Aug 30 00:55:44 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3D21F8B6E; Tue, 30 Aug 2011 00:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.596
X-Spam-Level: 
X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsTf8wfmalbO; Tue, 30 Aug 2011 00:55:43 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DA021F8B3A; Tue, 30 Aug 2011 00:55:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110830075543.19975.8948.idtracker@ietfa.amsl.com>
Date: Tue, 30 Aug 2011 00:55:43 -0700
Cc: softwires@ietf.org
Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-radius-ext-06.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2011 07:55:44 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Softwires Working Group of the IETF.

	Title           : RADIUS Extensions for Dual-Stack Lite
	Author(s)       : Roberta Maglione
                          Alain Durand
	Filename        : draft-ietf-softwire-dslite-radius-ext-06.txt
	Pages           : 12
	Date            : 2011-08-30

   Dual-Stack Lite is a solution to offer both IPv4 and IPv6
   connectivity to customers which are addressed only with an IPv6
   prefix.  Dual-Stack Lite requires to pre-configure the Dual-Stack
   Lite Address Family Transition Router (AFTR) tunnel information on
   the Basic Bridging BroadBand (B4) element.  In many networks, the
   customer profile information may be stored in Authentication
   Authorization and Accounting (AAA) servers while client
   configurations are mainly provided through Dynamic Host Configuration
   Protocol (DHCP).  This document specifies a new Remote Authentication
   Dial In User Service (RADIUS) attribute to carry Dual-Stack Lite
   Address Family Transition Router Tunnel name; the RADIUS attribute is
   defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option.  This
   RADIUS attribute is meant to be used between the RADIUS Server and
   the Network Access Server (NAS), it is not intended to be used
   directly between the Basic Bridging BroadBand element and the RADIUS
   Server.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-radius-ext-0=
6.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-dslite-radius-ext-06=
.txt

From xiaohong.deng@orange-ftgroup.com  Tue Aug 30 02:33:54 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5374821F8B9E for ; Tue, 30 Aug 2011 02:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.634
X-Spam-Level: 
X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.615,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDVMFK170txs for ; Tue, 30 Aug 2011 02:33:53 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 87ACE21F8B7A for ; Tue, 30 Aug 2011 02:33:53 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8DCFF8B8009; Tue, 30 Aug 2011 11:35:46 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 58A968B8069; Tue, 30 Aug 2011 11:32:10 +0200 (CEST)
Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 30 Aug 2011 11:28:39 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Aug 2011 17:28:35 +0800
Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0199A647@ch-mailsrv.rd.francetelecom.fr>
In-Reply-To: <4E53A477.6060407@skoberne.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-despres-softwire-4rd-addmapping
Thread-Index: AcxhmexriT5JSp2ORfCyNnogQsAJxQFUQ7VQ
References: <4E53A477.6060407@skoberne.net>
From: 
To: , 
X-OriginalArrivalTime: 30 Aug 2011 09:28:39.0617 (UTC) FILETIME=[33A2E310:01CC66F7]
Cc: softwires@ietf.org, O.M.Maennel@lboro.ac.uk, raphaelphan.crypt@gmail.com, I.W.Phillips@lboro.ac.uk
Subject: Re: [Softwires] draft-despres-softwire-4rd-addmapping
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2011 09:33:54 -0000

|As far as I am aware, the following algorithms have been=20
|officially proposed:
|
| a) Sequential method: port-set is a range of consecutive ports. (See=20
|    I-D.matsuhira-sa46t-spec-03.)
|
| b) Modulo method: port-set for 1st CPE is (0, N, 2*N, ...),=20
|port-set for=20
|    2nd CPE is (1, N+1, 2*N+1, ...) and so on, where N is the=20
|number of CPEs
|    sharing the same IPv4 address. (See I-D.xli-behave-divi-03.)
|
| d) "New 4rd method" (interleaved port-pairs): port-set for=20
|the 1st CPE is
|    (0, 1, 2*N, 2*N+1, 4*N, 4*N+1, ...), where N is the number of CPEs
|    sharing the same IPv4 address. (See=20
|I-D.despres-softwire-4rd-addmapping-00.)
|
| d) "Old 4rd method" (interleaved port-ranges of different=20
|sizes): port-set
|    for the 1st CPE is:
|    ([4k..4k/N], [8k..8k/N], [16k..16k/N], [32k..32k/N]),
|    for the 2nd CPE is:
|    ([4k+4k/N..4k+2*4k/N], ..., [32k+32k/N..32k+2*32k/N]),
|    where N is the number of CPEs sharing the same IPv4 address. (See=20
|    I-D.murakami-softwire-4rd-00.)
|=20
| e) Random method: port-set is a randomly chosen subset of all=20
|available ports.
|    (See I-D.boucadair-pppext-portrange-option-07.)
|
| f) Port-range-mask method: port-set is a range of consecutive=20
|ports or a
|    set of ranges of consecutive ports. (See
|    I-D.boucadair-pppext-portrange-option-07.)
|
|If I forgot something, please let me know. It would be also=20

One more port allocation method documented in separated documents, by =
which different deployment scenarios and possible provisioning means are =
elaborated :

Deploy this method  in DS-Lite context:
draft-zhou-softwire-b4-nat-02

Deploy in A+P context:=20
draft-deng-v6ops-aplusp-experiment-results-01

A possible provisioning means - PCP:
draft-tsou-pcp-natcoord-03


Cheers,
Xiaohong


|nice to compare all these algorithms and to identify the=20
|trade-offs. The mechanism drafts would then just pick one of=20
|these algorithms (without the need to define it again) and=20
|justify the decision for the specific algorithm.


|
|What do you think about this proposal? With my colleagues we=20
|are preparing another port-selection algorithm, which would=20
|enhance the security for stateless solutions. Something like a=20
|stateless-ready counterpart to the Random method, specified in=20
|I-D.boucadair-pppext-portrange-option-07. This way we could=20
|just add such an algorithm to this "algorithms document" and the
|IPv4 address sharing mechanism document authors could then=20
|choose the one which suits them best.
|
|Thanks,
|Nejc
|

From nejc@skoberne.net  Tue Aug 30 16:22:01 2011
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FCA21F8D04 for ; Tue, 30 Aug 2011 16:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obkSJMkT9p21 for ; Tue, 30 Aug 2011 16:22:00 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2047521F8CFE for ; Tue, 30 Aug 2011 16:21:51 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 1E3BA22780F6; Wed, 31 Aug 2011 01:23:18 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odKWXZuyonWW; Wed, 31 Aug 2011 01:23:17 +0200 (CEST)
Received: from [192.168.15.112] (eduroam-staff-131-209-4.lut.ac.uk [131.231.209.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id 2C50C22780F2; Wed, 31 Aug 2011 01:23:17 +0200 (CEST)
Message-ID: <4E5D70E3.3080700@skoberne.net>
Date: Wed, 31 Aug 2011 00:23:15 +0100
From: =?windows-1252?Q?Nejc_=8Akoberne?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: draft-xli-behave-divi-pd@tools.ietf.org,  "softwires@ietf.org" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: [Softwires] draft-xli-behave-divi-pd
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2011 23:22:01 -0000

Dear authors,

I have some comments and questions regarding draft-xli-behave-divi-pd:

1. If I understand correctly, each CPE is delegated a prefix of length
56 to 64 bits. The CPE can then do SLAAC for the network behind it, using
any of the subprefixes of the delegated prefix. Is this correct?

2. What IPv6 address is/should be configured on the CPE in the access
network? Can this be any IPv6 address?

3. To me it seems that there is redundant information in the address
format - CPE index is encoded in the prefix (as "k" bits of the CPE index)
and in the suffix (as k). If I understand correctly, similar is true for
IPv4 address - the "s" bits in the CPE index uniquely identify one of
the shared IPv4 addresses. What exactly is the motivation for this? I mean,
IPv4 address and the port range are not encoded in the prefix anyway,
so direct CPE-CPE paths are not possible? I miss packet flow diagrams.

4. I can't understand how exactly is "IPv4-converted address block"
supposed to be used. I really miss packet flow diagrams here. Also, you
seem to mix IPv4-converted and IPv6-converted.

5. There is an example in Appendix A, which I cannot completely understand. 
I cannot see how "v" (is this "s" in the CPE index?) is represented in
the IPv4-translatable address?

Since you claim you have been running an implementation in production
successfully, I assume you have all these things sorted out. But I think
that the draft needs some more work to be understandable to others.

Thanks,
Nejc

On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU 
<Tina.Tsou.Zouting@huawe=
i.com> wrote:








Dear =
Jacni,


Just =
after reading RFC 1981, I think fragmentation of IPv6 is needed. In section=
 5.1, it says, =93It is possible that a
packetization layer, perhaps a UDP application outside the ker=
nel, is unable to change the size of messages it sends. 
This may result in a packet size that exceeds the Path MTU.


To ac=
commodate such situations, IPv6 defines a mechanism that allows large paylo=
ads to be divided into fragments, with each fragment sent in a separate pac=
ket (see [IPv6-SPEC] section "Fragment
 Header").=94


 


If th=
e node which makes PMTU is the multicast source, it can change the size of =
message when the size exceeds the PMTU value.


Howev=
er, 
mAFTR, as a router, is unable to change the size of the message. Her=
e is an example: An IPv4 packet is sent from the multicast source to
mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does
mAFTR forward the packet? One possible way is to make IPv6 fra=
gmentation, with two fragments: one is 960 and the other is 40 with =93IPv6=
 Fragment Header=94.


In ad=
dition, there may be also other ways to avoid fragmentation, e.g., cache in
mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].<=
u>




 












Jacni>=
: Please see Yiu's comments, 


while for=
 the discovery if you really want to do it, this way to help you to underst=
and, it's the end point of tunnel which seems to "source" the v6 =
packets. Hope you can get it.












Cheers,


Jacni