From lutchann-behave@litech.org Sat Jan 1 08:27:48 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E693A6823 for ; Sat, 1 Jan 2011 08:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx8zXV8HfE56 for ; Sat, 1 Jan 2011 08:27:47 -0800 (PST) Received: from puck.litech.org (puck.litech.org [IPv6:2001:470:8:6f::229]) by core3.amsl.com (Postfix) with ESMTP id E82983A681D for ; Sat, 1 Jan 2011 08:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=litech.org; s=puck; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=QzmuU7Wswmt1i7wKOB661/uTkOHw2aFQjwk1spgn45k=; b=Z/V/tD9DOAyaRnuDzJ3sbY5/MCECfsLSqqwHAQHtr4sbMb0dnPvHPvSh005AnKveLUYjz8WySCgrXKQI80qQTcqwKBzLDmKjEty6MqXn0Sf6hkRw6jcJ1P/O/a1tGt6pikXxnpnpWd1wczy9/Xru5f0V3P77d1pGEfPKcJ9nIgE=; Received: from lutchann (loopback smtp) by puck.litech.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PZ4L1-0007HH-Nw for behave@ietf.org; Sat, 01 Jan 2011 11:29:51 -0500 Date: Sat, 1 Jan 2011 11:29:50 -0500 From: Nathan Lutchansky To: behave@ietf.org Message-ID: <20110101162950.GD22497@litech.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Litech-Auth-Results: local=pass; local.id=lutchann; local.proto=loopback smtp; Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jan 2011 16:27:48 -0000 [resent with the correct from-address] On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote: > Are there any known limitations or problems with using ULA addresses > as the PREF64? > > I do not want people from outside of my administrative domain to use > my DNS64 and NAT64. Other mechanisms such as access lists will be > used, but in an attempt to have a layered approach to this particular > security issue, it seems to make sense that ULA be used as both the > queried address of the DNS64 as well as the NSP PREF64 that will be > used. > > Any concerns that i am overlooking? There might be some considerations concerning address selection. RFC 3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA addresses to be of global scope, but some implementations (e.g. glibc) deviate from this and consider it to be of site-local scope. This means that the hosts on your network with both native IPv4 and NAT64 connectivity would prioritize one protocol over the other in an implementation-dependent way. >From a more practical viewpoint, you may run into trouble with customer equipment firewalling ULAs by default on the WAN interface. Is there a reason you can't use the non-routable well-known prefix 64:ff9b::/96? Traffic engineering? -Nathan From cb.list6@gmail.com Sat Jan 1 09:03:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA85A3A68D3 for ; Sat, 1 Jan 2011 09:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLmTHfx9Bhvq for ; Sat, 1 Jan 2011 09:03:55 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 76E5C3A6869 for ; Sat, 1 Jan 2011 09:03:55 -0800 (PST) Received: by qwg5 with SMTP id 5so13096505qwg.31 for ; Sat, 01 Jan 2011 09:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yTbl9Ld+NHBLM7+q7aTMyYkgW4T2FZHE3jyOJfVDPc8=; b=GuEnAuMc4iXu/ID8YUm4rGJEC9y49uEEKdRBcXWL/N+ANKSsshc+Ac0jwNBQMxB+dl cjiNppDL/vlN/ulsNQQxUvr4DjcuFfxXkgp5ur5KcsoPWOUG5CAR5slxU1KoE+DzhV0g w6SahKMkh3m27WlzRWD6YnbMTjqcJiPjszssI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZHnb4c1rBOQe5ZzSb3mHKsQFOS3tJ2oWsHqPsgEtddgkJgkH8uYI40nN+x78H6nxvb N6XHnsBwvyg2yoeOiLcWi/PLzmwOw8G4yXAcLOMLMU3EAGN+9C8uJMceAr7BGimJS3Bo yMn/LEQCxIeR47s9OO/85r0kKlIfo/Q9PhAs4= MIME-Version: 1.0 Received: by 10.229.250.135 with SMTP id mo7mr16418242qcb.30.1293901561546; Sat, 01 Jan 2011 09:06:01 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sat, 1 Jan 2011 09:06:01 -0800 (PST) In-Reply-To: <20110101162950.GD22497@litech.org> References: <20110101162950.GD22497@litech.org> Date: Sat, 1 Jan 2011 09:06:01 -0800 Message-ID: From: Cameron Byrne To: Nathan Lutchansky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jan 2011 17:03:56 -0000 On Sat, Jan 1, 2011 at 8:29 AM, Nathan Lutchansky wrote: > [resent with the correct from-address] > > On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote: >> Are there any known limitations or problems with using ULA addresses >> as the PREF64? >> >> I do not want people from outside of my administrative domain to use >> my DNS64 and NAT64. =A0Other mechanisms such as access lists will be >> used, but in an attempt to have a layered approach to this particular >> security issue, it seems to make sense that ULA be used as both the >> queried address of the DNS64 as well as the NSP PREF64 that will be >> used. >> >> Any concerns that i am overlooking? > > There might be some considerations concerning address selection. =A0RFC > 3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA > addresses to be of global scope, but some implementations (e.g. glibc) > deviate from this and consider it to be of site-local scope. =A0This mean= s > that the hosts on your network with both native IPv4 and NAT64 > connectivity would prioritize one protocol over the other in an > implementation-dependent way. > That's an interesting point, but it works in any case still, right? Regarding what is in place today in the address selection space across implementations, the only think that is consistent is the expectation that it will be inconsistent. That said, i prefer single stack implementation that make all these "unhappy eyeball" issues moot. > From a more practical viewpoint, you may run into trouble with customer > equipment firewalling ULAs by default on the WAN interface. > Agreed, more complicated environments have a more dependencies, but in the mobile wireless space, this should not be an issue since i have a good idea on how the CPE / Handset should behave when i sell it to the customer every 18 to 24 months. > Is there a reason you can't use the non-routable well-known prefix > 64:ff9b::/96? =A0Traffic engineering? =A0-Nathan I don't think WKP has much use in a large wireless network due to the need to scale and traffic engineering requirements. My expectation is that there will be anycast DNS servers that have a feedback mechanism with the NAT64, and thus the DNS64 rotates PREF64 to different users based on load and availability of a NAT64 kit. The PREF64 should always be the same for a given user for a given time period of stickiness. When you think of how to implement 10s to 100s of millions of sessions across multiple geographies, this type of feedback and high availability mechanisms are required, and WKP is not possible for N by NAT64 scaling. Cameron > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From lutchann-behave@litech.org Mon Jan 3 08:23:25 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55A93A6857 for ; Mon, 3 Jan 2011 08:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+B5qi3LeJuQ for ; Mon, 3 Jan 2011 08:23:24 -0800 (PST) Received: from puck.litech.org (puck.litech.org [IPv6:2001:470:8:6f::229]) by core3.amsl.com (Postfix) with ESMTP id 200DF3A682D for ; Mon, 3 Jan 2011 08:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=litech.org; s=puck; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=izbXmfMxaIh8ErJqs0aG7kBj/81ZljhlGKuNki4EtfI=; b=GnWPmJsCY9T0fg8RCsi0EUdvMxuEp/+a1DWZKrdtkJdmfgqLJLnkdniXBYmDQW6o+UdcAHzA5oOf4xUtL8epi411uQyLHZRQpBg6jXQ4i64bwLy7bM7Y4uPWhOo0ZgXTFgWv7EgXbQ7pUz8EPYa0JS3AoTlfACw7cYZ7zHq/stI=; Received: from lutchann (loopback smtp) by puck.litech.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PZnDl-0006Vt-AT; Mon, 03 Jan 2011 11:25:21 -0500 Date: Mon, 3 Jan 2011 11:25:20 -0500 From: Nathan Lutchansky To: Cameron Byrne Message-ID: <20110103162520.GA22194@litech.org> References: <20110101162950.GD22497@litech.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Litech-Auth-Results: local=pass; local.id=lutchann; local.proto=loopback smtp; Cc: behave@ietf.org Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:23:26 -0000 On Sat, Jan 01, 2011 at 09:06:01AM -0800, Cameron Byrne wrote: > On Sat, Jan 1, 2011 at 8:29 AM, Nathan Lutchansky wrote: > > On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote: > >> Are there any known limitations or problems with using ULA addresses > >> as the PREF64? > > > > There might be some considerations concerning address selection. ?RFC > > 3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA > > addresses to be of global scope, but some implementations (e.g. glibc) > > deviate from this and consider it to be of site-local scope. ?This means > > that the hosts on your network with both native IPv4 and NAT64 > > connectivity would prioritize one protocol over the other in an > > implementation-dependent way. > > That's an interesting point, but it works in any case still, right? Well, the traffic should still go *somewhere*, but possibly not to where the owner/manufacturer of the device intended. I can imagine that handset manufacturers may set up their address selection rules to always prefer site-scoped addresses. The reason being that carriers might run split-DNS for their internal services, so that devices on their own network could be directed to a customers-only version of the service running on site-local addresses. (I think the T-Mobile "My Account" app for Android works something like this.) Now imagine a handset with both a GPRS data link to your IPv6-only APN and an active WiFi connection to an IPv4-only network. If DNS queries go to the GPRS link, and all queries for IPv4-only hosts are answered with a site-scoped address, no IPv4 traffic will ever go out the WiFi link. > > From a more practical viewpoint, you may run into trouble with customer > > equipment firewalling ULAs by default on the WAN interface. > > Agreed, more complicated environments have a more dependencies, but in > the mobile wireless space, this should not be an issue since i have a > good idea on how the CPE / Handset should behave when i sell it to the > customer every 18 to 24 months. Handsets, sure, but for CPE that the customer doesn't buy from you like laptops or pocket routers, it's harder to predict behavior. -Nathan From cb.list6@gmail.com Mon Jan 3 09:14:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E262E3A6935 for ; Mon, 3 Jan 2011 09:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7McwYANGJu-q for ; Mon, 3 Jan 2011 09:14:21 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id D823F3A68C9 for ; Mon, 3 Jan 2011 09:14:20 -0800 (PST) Received: by qyj19 with SMTP id 19so14555786qyj.10 for ; Mon, 03 Jan 2011 09:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y/Aso7tdPcauJ+63gF3hAcfWGqbRzmvlxzOdaXAnvi8=; b=XWJ1c01ze87M3H+J07nVM2ToM/G6OIUQWUCZpY1FKO1P2n6XZI0Pr801Z/DNjrnJlV 8dl8lqymszuBf3KeRL06IJ1iPo7bZtZwaoLpuyRaWjkmfiwosFt/1nwTJx7Zpv9objjx F3zZT95g3DbuplWIXWddK13ygXIF9F7bbHO1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=b1C8wtb04eAIwSCEROLnj7bCZWUf5EXbcFD9advZFH0s0kS4ntEom+4eU7qxiY+177 yFw0xMkySzbMdzHU8lup/Na+L1Mj4/bcoslSkGH0x3424iqlWG8T7SK2QMstooNSDRx/ fSCTUa1f+3ec4mD7hVLcOgeg3JIYWzBatfrRU= MIME-Version: 1.0 Received: by 10.229.90.196 with SMTP id j4mr17699666qcm.144.1294074987690; Mon, 03 Jan 2011 09:16:27 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 3 Jan 2011 09:16:27 -0800 (PST) In-Reply-To: <20110103162520.GA22194@litech.org> References: <20110101162950.GD22497@litech.org> <20110103162520.GA22194@litech.org> Date: Mon, 3 Jan 2011 09:16:27 -0800 Message-ID: From: Cameron Byrne To: Nathan Lutchansky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:14:22 -0000 On Mon, Jan 3, 2011 at 8:25 AM, Nathan Lutchansky wrote: > On Sat, Jan 01, 2011 at 09:06:01AM -0800, Cameron Byrne wrote: >> On Sat, Jan 1, 2011 at 8:29 AM, Nathan Lutchansky wrote: >> > On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote: >> >> Are there any known limitations or problems with using ULA addresses >> >> as the PREF64? >> > >> > There might be some considerations concerning address selection. ?RFC >> > 3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider UL= A >> > addresses to be of global scope, but some implementations (e.g. glibc) >> > deviate from this and consider it to be of site-local scope. ?This mea= ns >> > that the hosts on your network with both native IPv4 and NAT64 >> > connectivity would prioritize one protocol over the other in an >> > implementation-dependent way. >> >> That's an interesting point, but it works in any case still, right? > > Well, the traffic should still go *somewhere*, but possibly not to where > the owner/manufacturer of the device intended. > Like always, there is a scope to the technology and testing is required, that's business as usual for anything the service providers sells. It has to work out the door. > I can imagine that handset manufacturers may set up their address > selection rules to always prefer site-scoped addresses. =A0The reason > being that carriers might run split-DNS for their internal services, so > that devices on their own network could be directed to a customers-only > version of the service running on site-local addresses. =A0(I think the > T-Mobile "My Account" app for Android works something like this.) > > Now imagine a handset with both a GPRS data link to your IPv6-only APN > and an active WiFi connection to an IPv4-only network. =A0If DNS queries > go to the GPRS link, and all queries for IPv4-only hosts are answered > with a site-scoped address, no IPv4 traffic will ever go out the WiFi > link. > All the handsets i know of don't run multiple interfaces. For example, when Android attaches to WiFi it detaches from GPRS internet access, or at least that has been my experience. I believe the issue you discuss is a more broad one for DNS64 clients having access to NAT64 resources. Part of the motivation for using ULA for DNS64 is to ensure only folks within my domain can access the DNS64 and the paired NAT64 resources. >> > From a more practical viewpoint, you may run into trouble with custome= r >> > equipment firewalling ULAs by default on the WAN interface. >> >> Agreed, more complicated environments have a more dependencies, but in >> the mobile wireless space, this should not be an issue since i have a >> good idea on how the CPE / Handset should behave when i sell it to the >> customer every 18 to 24 months. > > Handsets, sure, but for CPE that the customer doesn't buy from you like > laptops or pocket routers, it's harder to predict behavior. =A0-Nathan Indeed. That is always the case. That said, NAT64/DNS64 will not fit all users in the early stages. As stated many times, there is no silver bullet. Cameron > From lutchann-behave@litech.org Mon Jan 3 10:54:18 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32483A6AA2 for ; Mon, 3 Jan 2011 10:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfxTBnXXprZ9 for ; Mon, 3 Jan 2011 10:54:17 -0800 (PST) Received: from puck.litech.org (puck.litech.org [IPv6:2001:470:8:6f::229]) by core3.amsl.com (Postfix) with ESMTP id 6A5ED3A6AA1 for ; Mon, 3 Jan 2011 10:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=litech.org; s=puck; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=FJnMxyugr00vwpkd8id9jah6+hjalwX3XCizsB5YdM8=; b=KuDcEAI02Hxn4SPesi3QZO6+1zeK5zfGb5gJMvj8nUPf2T69wttHOwHUc65FFyG3nHJeiR0CakgJMmkhzL079Wa2Fu+YOK3YM8xTyyhz5n1vCsKEkf/h2EfBsGmg+3T960mNw0qedmqbTxSr3AswN3+fLIc+0Ng80a8CirzgrG0=; Received: from lutchann (loopback smtp) by puck.litech.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PZpZw-0007os-8o; Mon, 03 Jan 2011 13:56:24 -0500 Date: Mon, 3 Jan 2011 13:56:23 -0500 From: Nathan Lutchansky To: Cameron Byrne Message-ID: <20110103185623.GA29433@litech.org> References: <20110101162950.GD22497@litech.org> <20110103162520.GA22194@litech.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Litech-Auth-Results: local=pass; local.id=lutchann; local.proto=loopback smtp; Cc: behave@ietf.org Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:54:18 -0000 On Mon, Jan 03, 2011 at 09:16:27AM -0800, Cameron Byrne wrote: > On Mon, Jan 3, 2011 at 8:25 AM, Nathan Lutchansky wrote: > > Now imagine a handset with both a GPRS data link to your IPv6-only APN > > and an active WiFi connection to an IPv4-only network. ?If DNS queries > > go to the GPRS link, and all queries for IPv4-only hosts are answered > > with a site-scoped address, no IPv4 traffic will ever go out the WiFi > > link. > > All the handsets i know of don't run multiple interfaces. For > example, when Android attaches to WiFi it detaches from GPRS internet > access, or at least that has been my experience. The network monitor API in Android allows applications to request that their traffic leave over a specific outbound link, which means that both GPRS and WiFi can be active simultaneously under some circumstances. I believe Symbian has the same capability. Android Market insists on having GPRS up for some operations (probably to get access to carrier-specific sections of the Market) which means that it breaks horribly when I try to use it on my home WiFi network with NAT64/DNS64. I haven't looked into the problem in any detail, though. > I believe the issue you discuss is a more broad one for DNS64 clients > having access to NAT64 resources. Or, more generally, it's an issue with split DNS of any sort. -Nathan From dwing@cisco.com Mon Jan 3 12:36:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A553A3A6BAA; Mon, 3 Jan 2011 12:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxFup5SaOUZh; Mon, 3 Jan 2011 12:36:43 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 990C53A6B15; Mon, 3 Jan 2011 12:36:43 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL3CIU2rRN+J/2dsb2JhbACXPYx4c6JvmRKFSgSCen1u X-IronPort-AV: E=Sophos;i="4.60,268,1291593600"; d="scan'208";a="253975600" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2011 20:38:50 +0000 Received: from dwingWS (sjc-vpn6-1124.cisco.com [10.21.124.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p03KcoQ0001358; Mon, 3 Jan 2011 20:38:50 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> In-Reply-To: Date: Mon, 3 Jan 2011 12:38:50 -0800 Message-ID: <015d01cbab86$3aa832a0$aff897e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acui6l3NHck6gDWLR/+iYfvxNL8tqwImxCtA Content-Language: en-us Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' , 'Dave Thaler' Subject: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:36:44 -0000 > Maybe at this point in the discussion it would be good to hear from > implementers. There are already tons of NAT44 FTP ALGs out there, I > wonder how those solve this. For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's IOS, and it does nothing special with LANG (it doesn't block the command nor parse the FEAT response). We have other ALGs in other products (e.g., Linksys, ASA), but I did not check those. Our bug database (which spans all Cisco-branded products) has no customer complaints about FTP's LANG support. -d From mohamed.boucadair@orange-ftgroup.com Wed Jan 5 04:47:18 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3363A6DDC for ; Wed, 5 Jan 2011 04:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.081, 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Fi7Q7AdodxR for ; Wed, 5 Jan 2011 04:47:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 203363A6B74 for ; Wed, 5 Jan 2011 04:47:16 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DA68522C6C8; Wed, 5 Jan 2011 13:49:22 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BF9BF27C05B; Wed, 5 Jan 2011 13:49:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 5 Jan 2011 13:49:22 +0100 From: To: Behave WG Date: Wed, 5 Jan 2011 13:49:21 +0100 Thread-Topic: Multicast IPv4-embedded Address Format Thread-Index: Acus1vlfcQ3nESzYTaKMYbKoCaSMEA== Message-ID: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> 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_94C682931C08B048B7A8645303FDC9F33C3E9FD8ECPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.5.121529 Cc: "draft-boucadair-behave-64-multicast-address-format@tools.ietf.org" Subject: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 12:47:18 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C3E9FD8ECPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Various solutions (e.g., [I-D.venaas-behave-v4v6mc-framework], [I-D.xu-softwire-mesh-multicast] or [I-D.qin-softwire-dslite- multicast]) have been proposed to allow access to IPv4 multicast content from hosts attached to IPv6-enabled domains. Even if these solutions have distinct applicability scopes (translation vs. encapsulation) and target various use cases, they all make use of specific IPv6 multicast addresses to embed an IPv4 multicast address. Particularly, an IPv4-embedded IPv6 multicast address is used as a destination IPv6 address of multicast flows received from the IPv4- enabled domain and injected by the IPv4-IPv6 Interconnection Function into the IPv6-enabled domain. It is also used to build the IPv6 multicast state (*, G6) or (S6,G6) corresponding to their (*, G4) or (S4,G4) IPv4 counterparts by the IPv4-IPv6 Interconnection Function. Together with Yiu and Jacni, we have edited this I-D to define IPv4- embedded IPv6 multicast address format which aims to update RFC4192. Comments, suggestions and contributions are more than welcome. Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_000_94C682931C08B048B7A8645303FDC9F33C3E9FD8ECPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
   Dear all,
 
   Various solutions (e.= g.,=20 [I-D.venaas-behave-v4v6mc-framework],
  =20 [I-D.xu-softwire-mesh-multicast] or [I-D.qin-softwire-dslite-
 &nbs= p;=20 multicast]) have been proposed to allow access to IPv4 multicast
 &= nbsp;=20 content from hosts attached to IPv6-enabled domains.  Even if=20 these
   solutions have distinct applicability scopes (transla= tion=20 vs.
   encapsulation) and target various use cases, they all m= ake=20 use of
   specific IPv6 multicast addresses to embed an IPv4= =20 multicast address.
   Particularly, an IPv4-embedded IPv6 multicast address i= s used=20 as a
   destination IPv6 address of multicast flows received f= rom=20 the IPv4-
   enabled domain and injected by the IPv4-IPv6=20 Interconnection Function
   into the IPv6-enabled domain. = ; It=20 is also used to build the IPv6
   multicast state (*, G6) or= =20 (S6,G6) corresponding to their (*, G4) or
   (S4,G4) IPv4=20 counterparts by the IPv4-IPv6 Interconnection Function.
 
   Together with Yiu and= Jacni,=20 we have edited this I-D to define IPv4-
   embedded IPv6 multi= cast=20 address format which aims to update=20 RFC4192.
 
   Comments,= =20 suggestions and contributions are more than welcome.
 
   Cheers,
 
   Med
=
*********************************
This message and any attachments (the "message") are confidential and inten=
ded solely for the addressees.=20
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.=20
France Telecom Group shall not be liable for the message if altered, change=
d or falsified.
If you are not the intended addressee of this message, please cancel it imm=
ediately and inform the sender.
********************************
--_000_94C682931C08B048B7A8645303FDC9F33C3E9FD8ECPUEXCB1Bnante_-- From iljitsch@muada.com Wed Jan 5 06:17:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFAE3A6C18; Wed, 5 Jan 2011 06:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSHB4a84UTnd; Wed, 5 Jan 2011 06:17:31 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 0F04A3A6C05; Wed, 5 Jan 2011 06:17:30 -0800 (PST) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p05EJIMa061521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jan 2011 15:19:18 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <015d01cbab86$3aa832a0$aff897e0$@com> Date: Wed, 5 Jan 2011 15:19:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' , 'Dave Thaler' Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:17:32 -0000 On 3 jan 2011, at 21:38, Dan Wing wrote: > For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's > IOS, and it does nothing special with LANG (it doesn't block the > command nor parse the FEAT response). We have other ALGs in other > products (e.g., Linksys, ASA), but I did not check those. Our bug=20 > database (which spans all Cisco-branded products) has no customer=20 > complaints about FTP's LANG support. Apparently nobody else can muster up the energy to care about this. I'm ok with adding a SHOULD for supporting LANG in the ALG so that if a = server and client negotiate a non-default language the ALG also = participates. This assumes the ALG supports the negotiated language, but = I'm thinking that if the server and client support a non-default = language, there's a good chance that the ALG vendor either added this = language too, or allowed sufficient customization for the user to do = this. The ALG only has 10 or so responses that it can generate, after = all. But for the reasons I outlined earlier, I'm still very reluctant to make = this a MUST. Seeing as the FTP44 ALG people apparently managed to do = without this, such a requirement runs a big risk of becoming a dead = letter, anyway. There's enough of that when it comes to FTP = specifications... Iljitsch= From dthaler@microsoft.com Wed Jan 5 08:09:36 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BA23A6B89; Wed, 5 Jan 2011 08:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.54 X-Spam-Level: X-Spam-Status: No, score=-111.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAFtwB7+93I8; Wed, 5 Jan 2011 08:09:36 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id F08503A6B78; Wed, 5 Jan 2011 08:09:35 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 5 Jan 2011 08:11:43 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 5 Jan 2011 08:11:43 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 5 Jan 2011 08:11:44 -0800 From: Dave Thaler To: "ftpext@ietf.org" Thread-Topic: FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05] Thread-Index: AQHLq4ZCd3oh0GiYREyEEa+YCsrCvZPC9jCA//+XuqA= Date: Wed, 5 Jan 2011 16:11:40 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> In-Reply-To: <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 16:09:37 -0000 Question to FTPEXT: Given that many NAT44's that have FTP ALG don't allow LANG to work correctl= y, and we haven't seen any responses from FTPEXT folks arguing that it's important, should the Behave WG consider LANG support in RFC 2640 to be=20 unimportant? Is it basically dead? If so, I'm fine with a SHOULD in the FTP64 doc. And I agree with Iljitsch= 's implication that the recommendation for FTP64 ALGs should be the same as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is. -Dave > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, January 05, 2011 6:19 AM > To: Dan Wing > Cc: Dave Thaler; draft-ietf-behave-ftp64@tools.ietf.org; ftpext@ietf.org; > 'Behave WG' > Subject: Re: FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf- > behave-ftp64-05] >=20 > On 3 jan 2011, at 21:38, Dan Wing wrote: >=20 > > For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's > > IOS, and it does nothing special with LANG (it doesn't block the > > command nor parse the FEAT response). We have other ALGs in other > > products (e.g., Linksys, ASA), but I did not check those. Our bug > > database (which spans all Cisco-branded products) has no customer > > complaints about FTP's LANG support. >=20 > Apparently nobody else can muster up the energy to care about this. >=20 > I'm ok with adding a SHOULD for supporting LANG in the ALG so that if a s= erver > and client negotiate a non-default language the ALG also participates. Th= is > assumes the ALG supports the negotiated language, but I'm thinking that i= f the > server and client support a non-default language, there's a good chance t= hat the > ALG vendor either added this language too, or allowed sufficient customiz= ation > for the user to do this. The ALG only has 10 or so responses that it can = generate, > after all. >=20 > But for the reasons I outlined earlier, I'm still very reluctant to make = this a > MUST. Seeing as the FTP44 ALG people apparently managed to do without thi= s, > such a requirement runs a big risk of becoming a dead letter, anyway. The= re's > enough of that when it comes to FTP specifications... >=20 > Iljitsch From fred@cisco.com Wed Jan 5 11:30:30 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7898B3A6C74; Wed, 5 Jan 2011 11:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.415 X-Spam-Level: X-Spam-Status: No, score=-110.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl0pjo4Na55j; Wed, 5 Jan 2011 11:30:29 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F2EF13A6AB5; Wed, 5 Jan 2011 11:30:28 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,278,1291593600"; d="scan'208";a="310715506" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2011 19:32:36 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p05JWVsC021966; Wed, 5 Jan 2011 19:32:35 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 05 Jan 2011 11:32:36 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 05 Jan 2011 11:32:36 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 5 Jan 2011 11:32:19 -0800 Message-Id: References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:30:30 -0000 On Jan 5, 2011, at 8:11 AM, Dave Thaler wrote: > I agree with Iljitsch's implication that the recommendation for FTP64 = ALGs should be the same as whatever the recommendation for other FTP = ALGs (e.g. in NAT44's) is. Yes.= From iljitsch@muada.com Wed Jan 5 13:39:50 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C943A6CD9; Wed, 5 Jan 2011 13:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GecR3pK1KizS; Wed, 5 Jan 2011 13:39:14 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id EEE9A3A67D6; Wed, 5 Jan 2011 13:39:13 -0800 (PST) Received: from [192.168.1.5] (176.Red-83-33-119.dynamicIP.rima-tde.net [83.33.119.176]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p05Lewv1064526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jan 2011 22:40:59 +0100 (CET) (envelope-from iljitsch@muada.com) References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2-276357164 Message-Id: <1BF1B9D6-B649-48A5-BB4A-F31F2BCC4E72@muada.com> X-Mailer: iPhone Mail (8C148) From: Iljitsch van Beijnum Date: Wed, 5 Jan 2011 22:40:45 +0100 To: Dave Thaler Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , Behave WG , Dan Wing Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:39:50 -0000 --Apple-Mail-2-276357164 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 5 jan. 2011, at 17:11, Dave Thaler wrote: > And I agree with Iljitsch's > implication that the recommendation for FTP64 ALGs should be the same > as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is. Failing to quit while I'm ahead... Are there any FTP44 ALG recommendations? --Apple-Mail-2-276357164 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8

On 5 jan. 2011, at 17:11, Dave Thaler <dthaler@microsoft.com> wrote:

And I agree with Iljitsch's
implication that the recommendation for FTP64 ALGs should be the same
as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is.

Failing to quit while I'm ahead...

Are there any FTP44 ALG recommendations?

--Apple-Mail-2-276357164-- From dwing@cisco.com Wed Jan 5 15:40:36 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384173A6E23; Wed, 5 Jan 2011 15:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9W8H-IUB5qU; Wed, 5 Jan 2011 15:40:35 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7F23D3A6D0E; Wed, 5 Jan 2011 15:40:35 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANOQJE2rR7Hu/2dsb2JhbACDd5M3jG5zplGKU41PgSGDN3QEhGg X-IronPort-AV: E=Sophos;i="4.60,280,1291593600"; d="scan'208";a="396523978" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 05 Jan 2011 23:42:42 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p05Nggew006185; Wed, 5 Jan 2011 23:42:42 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Dave Thaler'" References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <1BF1B9D6-B649-48A5-B B4A-F31F2BCC4E72@muada.com> In-Reply-To: <1BF1B9D6-B649-48A5-BB4A-F31F2BCC4E72@muada.com> Date: Wed, 5 Jan 2011 15:42:41 -0800 Message-ID: <097701cbad32$3e8bf200$bba3d600$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutIUtb5iuicnTUQjqT4jyoTusjawAEKWaA Content-Language: en-us Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:40:36 -0000 > On 5 jan. 2011, at 17:11, Dave Thaler wrote: > > > And I agree with Iljitsch's > implication that the recommendation for FTP64 ALGs should be the > same > as whatever the recommendation for other FTP ALGs (e.g. in > NAT44's) is. > > > > Failing to quit while I'm ahead... > > Are there any FTP44 ALG recommendations? I am only aware of http://tools.ietf.org/html/rfc3027#section-4.1 -d From dthaler@microsoft.com Wed Jan 5 17:55:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39DE3A6E52; Wed, 5 Jan 2011 17:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZGiOrDs+R2v; Wed, 5 Jan 2011 17:55:11 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B281B3A6E55; Wed, 5 Jan 2011 17:55:11 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 5 Jan 2011 17:57:19 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 5 Jan 2011 17:57:18 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 5 Jan 2011 17:57:17 -0800 From: Dave Thaler To: Dan Wing , 'Iljitsch van Beijnum' Thread-Topic: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] Thread-Index: AQHLrTJEjnmEF06JX0uY7W1jdnOAoJPDLGvw Date: Thu, 6 Jan 2011 01:57:17 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653448AC5B@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <1BF1B9D6-B649-48A5-B B4A-F31F2BCC4E72@muada.com> <097701cbad32$3e8bf200$bba3d600$@com> In-Reply-To: <097701cbad32$3e8bf200$bba3d600$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , 'Behave WG' Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:55:12 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Dan Wing > Sent: Wednesday, January 05, 2011 3:43 PM > To: 'Iljitsch van Beijnum'; Dave Thaler > Cc: draft-ietf-behave-ftp64@tools.ietf.org; ftpext@ietf.org; 'Behave WG' > Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf- > behave-ftp64-05] >=20 > > On 5 jan. 2011, at 17:11, Dave Thaler wrote: > > > > > > And I agree with Iljitsch's > > implication that the recommendation for FTP64 ALGs should be the > same > > as whatever the recommendation for other FTP ALGs (e.g. in > > NAT44's) is. > > > > Failing to quit while I'm ahead... > > > > Are there any FTP44 ALG recommendations? >=20 > I am only aware of > http://tools.ietf.org/html/rfc3027#section-4.1 In the interest of making progress on FTP64... Given that the LANG/FEAT problem is not specific to FTP64 but applies to 44 ALGs (or any other type of FTP ALG for that matter), I think this proble= m is probably best addressed outside of the FTP64 spec itself, and if an answ= er existed in another doc, the FTP64 spec would just refer to it. As such, I think I am ok with not solving the problem in the FTP64 spec, and leaving it for future work. However, I would like to see a note=20 to that effect added to FTP64. In other words, I can live with it being unspecified in FTP64 as long as FTP64 calls out the issue and says it's lef= t for future work and points out that it's not specific to a 64 case. While that may result in bad behavior, it's no worse than the situation we're already in today where LANG behavior is somewhere between=20 broken and "unexpected". In my opinion, the FTPEXT group should=20 then decide what it wants to do about LANG (rev RFC 2640 or ignore=20 the problem or whatever else). -Dave From dwing@cisco.com Thu Jan 6 08:28:43 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508573A6C4F for ; Thu, 6 Jan 2011 08:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.528 X-Spam-Level: X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFwpeXgaE-FH for ; Thu, 6 Jan 2011 08:28:42 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 749B13A6C2F for ; Thu, 6 Jan 2011 08:28:42 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABN9JU2rR7Hu/2dsb2JhbACXMYxqc6VlmAuFTASEZw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 06 Jan 2011 16:30:49 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p06GUn3g028573; Thu, 6 Jan 2011 16:30:49 GMT From: "Dan Wing" To: "'Behave WG'" Date: Thu, 6 Jan 2011 08:30:48 -0800 Message-ID: <0b9401cbadbf$13a04360$3ae0ca20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutvxNd2EFFz+VLS0SzThE/iE2rkQ== Content-Language: en-us Cc: draft-penno-behave-64-analysis@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] call for adoption, draft-penno-behave-64-analysis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:28:43 -0000 The authors of draft-penno-behave-64-analysis have proposed that their document become the working group document to meet our milestone: Feb 2011 - Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info) The document is at: http://tools.ietf.org/html/draft-penno-behave-64-analysis-06 We received no feedback from my previous post about the scope of the document, http://www.ietf.org/mail-archive/web/behave/current/msg09092.html, so the document scope was left unchanged. I will wait a week to hear technical objections to the document's adoption to meet the milestone. If no objections, we will adopt it. -d From xing@cernet.edu.cn Sat Jan 8 23:34:37 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004673A6949 for ; Sat, 8 Jan 2011 23:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSZy-6vhhVX2 for ; Sat, 8 Jan 2011 23:34:31 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by core3.amsl.com (Postfix) with SMTP id E16B13A6948 for ; Sat, 8 Jan 2011 23:34:30 -0800 (PST) Received: from [172.16.12.91]([202.100.227.19]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm114d29872d; Sun, 09 Jan 2011 15:36:39 +0800 Message-ID: <4D29657C.5050804@cernet.edu.cn> Date: Sun, 09 Jan 2011 15:36:28 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------080007000300060101060607" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: xVZppbZB Cc: Xing Li , congxiao , Behave WG , "draft-boucadair-behave-64-multicast-address-format@tools.ietf.org" Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 07:34:37 -0000 This is a multi-part message in MIME format. --------------080007000300060101060607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ? 2011-1-5 20:49, mohamed.boucadair@orange-ftgroup.com ??: > Dear all, > Various solutions (e.g., [I-D.venaas-behave-v4v6mc-framework], > [I-D.xu-softwire-mesh-multicast] or [I-D.qin-softwire-dslite- > multicast]) have been proposed to allow access to IPv4 multicast > content from hosts attached to IPv6-enabled domains. Even if these > solutions have distinct applicability scopes (translation vs. > encapsulation) and target various use cases, they all make use of > specific IPv6 multicast addresses to embed an IPv4 multicast address. > Particularly, an IPv4-embedded IPv6 multicast address is used as a > destination IPv6 address of multicast flows received from the IPv4- > enabled domain and injected by the IPv4-IPv6 Interconnection Function > into the IPv6-enabled domain. It is also used to build the IPv6 > multicast state (*, G6) or (S6,G6) corresponding to their (*, G4) or > (S4,G4) IPv4 counterparts by the IPv4-IPv6 Interconnection Function. > Together with Yiu and Jacni, we have edited this I-D to define IPv4- > embedded IPv6 multicast address formatwhich aims to update RFC4192. The "http://www.rfc-editor.org/internet-drafts/draft-xli-behave-ivi-07.txt" (currently in RFC queue) proposed a multicast address format for SSM when stateless translation is used. It is in Section "5.1. IVI Multicast" . We have deployed the prototype and it has been tested and used between CERNET (IPv4) and CERNET2 (IPv6). We can add more details in 4.5. SSM of multicast-address-format draft. Regards, xing, congxiao > Comments, suggestions and contributions are more than welcome. > Cheers, > Med > ********************************* > This message and any attachments (the "message") are confidential and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it immediately and inform the sender. > ******************************** > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --------------080007000300060101060607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 于 2011-1-5 20:49, mohamed.boucadair@orange-ftgroup.com 写道:
   Dear all,
 
   Various solutions (e.g., [I-D.venaas-behave-v4v6mc-framework],
   [I-D.xu-softwire-mesh-multicast] or [I-D.qin-softwire-dslite-
   multicast]) have been proposed to allow access to IPv4 multicast
   content from hosts attached to IPv6-enabled domains.  Even if these
   solutions have distinct applicability scopes (translation vs.
   encapsulation) and target various use cases, they all make use of
   specific IPv6 multicast addresses to embed an IPv4 multicast address.
   Particularly, an IPv4-embedded IPv6 multicast address is used as a
   destination IPv6 address of multicast flows received from the IPv4-
   enabled domain and injected by the IPv4-IPv6 Interconnection Function
   into the IPv6-enabled domain.  It is also used to build the IPv6
   multicast state (*, G6) or (S6,G6) corresponding to their (*, G4) or
   (S4,G4) IPv4 counterparts by the IPv4-IPv6 Interconnection Function.
 
   Together with Yiu and Jacni, we have edited this I-D to define IPv4-
   embedded IPv6 multicast address format which aims to update RFC4192.

The "http://www.rfc-editor.org/internet-drafts/draft-xli-behave-ivi-07.txt" (currently in RFC queue) proposed a multicast address format for SSM when stateless translation is used. It is in Section "5.1. IVI Multicast" . We have deployed the prototype and it has been tested and used between  CERNET (IPv4) and CERNET2 (IPv6).  We can add more details in 4.5.  SSM of multicast-address-format draft.

Regards,

xing, congxiao




 
   Comments, suggestions and contributions are more than welcome.
 
   Cheers,
 
   Med
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

--------------080007000300060101060607-- From mohamed.boucadair@orange-ftgroup.com Mon Jan 10 08:01:36 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C2D28C0CF for ; Mon, 10 Jan 2011 08:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc2K2PpQyCIc for ; Mon, 10 Jan 2011 08:01:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id C58713A67ED for ; Mon, 10 Jan 2011 08:01:34 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id C86FA1B83F6; Mon, 10 Jan 2011 17:03:47 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id AD842C805D; Mon, 10 Jan 2011 17:03:47 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 10 Jan 2011 17:03:47 +0100 From: To: Xing Li Date: Mon, 10 Jan 2011 17:03:45 +0100 Thread-Topic: [BEHAVE] Multicast IPv4-embedded Address Format Thread-Index: Acuvz/bJNHONxdxdST2zOLa5hoET6QBD7/ww Message-ID: <29192_1294675427_4D2B2DE3_29192_2652_1_94C682931C08B048B7A8645303FDC9F33C3FD7B2DB@PUEXCB1B.nanterre.francetelecom.fr> References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> In-Reply-To: <4D29657C.5050804@cernet.edu.cn> 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_94C682931C08B048B7A8645303FDC9F33C3FD7B2DBPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.10.143315 Cc: congxiao , Behave WG , "draft-boucadair-behave-64-multicast-address-format@tools.ietf.org" Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:01:37 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C3FD7B2DBPUEXCB1Bnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBYaW5nLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaW50ZXJlc3QgYW5kIGZvciB0aGUgcG9p bnRlciB0byB0aGUgbXVsdGljYXN0IHNlY3Rpb24gaW4gaXZpLg0KDQpJIHdpbGwgY29udGFjdCB5 b3Ugb2ZmbGluZSBmb3IgdGhlIHByZXBhcmF0aW9uIG9mIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhl IEktRC4NCg0KQ2hlZXJzLA0KTWVkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpEZSA6IFhpbmcgTGkgW21haWx0bzp4aW5nQGNlcm5ldC5lZHUuY25dDQpFbnZvecOpIDogZGlt YW5jaGUgOSBqYW52aWVyIDIwMTEgMDg6MzYNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9O QUQvVElQDQpDYyA6IEJlaGF2ZSBXRzsgZHJhZnQtYm91Y2FkYWlyLWJlaGF2ZS02NC1tdWx0aWNh c3QtYWRkcmVzcy1mb3JtYXRAdG9vbHMuaWV0Zi5vcmc7IFhpbmcgTGk7IGNvbmd4aWFvDQpPYmpl dCA6IFJlOiBbQkVIQVZFXSBNdWx0aWNhc3QgSVB2NC1lbWJlZGRlZCBBZGRyZXNzIEZvcm1hdA0K DQrkuo4gMjAxMS0xLTUgMjA6NDksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS1mdGdyb3VwLmNv bTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLWZ0Z3JvdXAuY29tPiDlhpnpgZM6DQog ICBEZWFyIGFsbCwNCg0KICAgVmFyaW91cyBzb2x1dGlvbnMgKGUuZy4sIFtJLUQudmVuYWFzLWJl aGF2ZS12NHY2bWMtZnJhbWV3b3JrXSwNCiAgIFtJLUQueHUtc29mdHdpcmUtbWVzaC1tdWx0aWNh c3RdIG9yIFtJLUQucWluLXNvZnR3aXJlLWRzbGl0ZS0NCiAgIG11bHRpY2FzdF0pIGhhdmUgYmVl biBwcm9wb3NlZCB0byBhbGxvdyBhY2Nlc3MgdG8gSVB2NCBtdWx0aWNhc3QNCiAgIGNvbnRlbnQg ZnJvbSBob3N0cyBhdHRhY2hlZCB0byBJUHY2LWVuYWJsZWQgZG9tYWlucy4gIEV2ZW4gaWYgdGhl c2UNCiAgIHNvbHV0aW9ucyBoYXZlIGRpc3RpbmN0IGFwcGxpY2FiaWxpdHkgc2NvcGVzICh0cmFu c2xhdGlvbiB2cy4NCiAgIGVuY2Fwc3VsYXRpb24pIGFuZCB0YXJnZXQgdmFyaW91cyB1c2UgY2Fz ZXMsIHRoZXkgYWxsIG1ha2UgdXNlIG9mDQogICBzcGVjaWZpYyBJUHY2IG11bHRpY2FzdCBhZGRy ZXNzZXMgdG8gZW1iZWQgYW4gSVB2NCBtdWx0aWNhc3QgYWRkcmVzcy4NCiAgIFBhcnRpY3VsYXJs eSwgYW4gSVB2NC1lbWJlZGRlZCBJUHY2IG11bHRpY2FzdCBhZGRyZXNzIGlzIHVzZWQgYXMgYQ0K ICAgZGVzdGluYXRpb24gSVB2NiBhZGRyZXNzIG9mIG11bHRpY2FzdCBmbG93cyByZWNlaXZlZCBm cm9tIHRoZSBJUHY0LQ0KICAgZW5hYmxlZCBkb21haW4gYW5kIGluamVjdGVkIGJ5IHRoZSBJUHY0 LUlQdjYgSW50ZXJjb25uZWN0aW9uIEZ1bmN0aW9uDQogICBpbnRvIHRoZSBJUHY2LWVuYWJsZWQg ZG9tYWluLiAgSXQgaXMgYWxzbyB1c2VkIHRvIGJ1aWxkIHRoZSBJUHY2DQogICBtdWx0aWNhc3Qg c3RhdGUgKCosIEc2KSBvciAoUzYsRzYpIGNvcnJlc3BvbmRpbmcgdG8gdGhlaXIgKCosIEc0KSBv cg0KICAgKFM0LEc0KSBJUHY0IGNvdW50ZXJwYXJ0cyBieSB0aGUgSVB2NC1JUHY2IEludGVyY29u bmVjdGlvbiBGdW5jdGlvbi4NCg0KICAgVG9nZXRoZXIgd2l0aCBZaXUgYW5kIEphY25pLCB3ZSBo YXZlIGVkaXRlZCB0aGlzIEktRCB0byBkZWZpbmUgSVB2NC0NCiAgIGVtYmVkZGVkIElQdjYgbXVs dGljYXN0IGFkZHJlc3MgZm9ybWF0IHdoaWNoIGFpbXMgdG8gdXBkYXRlIFJGQzQxOTIuDQoNClRo ZSAiaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteGxpLWJl aGF2ZS1pdmktMDcudHh0IjxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC14bGktYmVoYXZlLWl2aS0wNy50eHQ+IChjdXJyZW50bHkgaW4gUkZDIHF1ZXVlKSBw cm9wb3NlZCBhIG11bHRpY2FzdCBhZGRyZXNzIGZvcm1hdCBmb3IgU1NNIHdoZW4gc3RhdGVsZXNz IHRyYW5zbGF0aW9uIGlzIHVzZWQuIEl0IGlzIGluIFNlY3Rpb24gIjUuMS4gSVZJIE11bHRpY2Fz dCIgLiBXZSBoYXZlIGRlcGxveWVkIHRoZSBwcm90b3R5cGUgYW5kIGl0IGhhcyBiZWVuIHRlc3Rl ZCBhbmQgdXNlZCBiZXR3ZWVuICBDRVJORVQgKElQdjQpIGFuZCBDRVJORVQyIChJUHY2KS4gIFdl IGNhbiBhZGQgbW9yZSBkZXRhaWxzIGluIDQuNS4gIFNTTSBvZiBtdWx0aWNhc3QtYWRkcmVzcy1m b3JtYXQgZHJhZnQuDQoNClJlZ2FyZHMsDQoNCnhpbmcsIGNvbmd4aWFvDQoNCg0KDQoNCg0KICAg Q29tbWVudHMsIHN1Z2dlc3Rpb25zIGFuZCBjb250cmlidXRpb25zIGFyZSBtb3JlIHRoYW4gd2Vs Y29tZS4NCg0KICAgQ2hlZXJzLA0KDQogICBNZWQNCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJtZXNzYWdl IikgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vl cy4NCkFueSB1bmF1dGhvcmlzZWQgdXNlIG9yIGRpc3NlbWluYXRpb24gaXMgcHJvaGliaXRlZC4N Ck1lc3NhZ2VzIGFyZSBzdXNjZXB0aWJsZSB0byBhbHRlcmF0aW9uLg0KRnJhbmNlIFRlbGVjb20g R3JvdXAgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgYWx0ZXJlZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgYWRkcmVzc2Vl IG9mIHRoaXMgbWVzc2FnZSwgcGxlYXNlIGNhbmNlbCBpdCBpbW1lZGlhdGVseSBhbmQgaW5mb3Jt IHRoZSBzZW5kZXIuDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJlaGF2ZSBtYWls aW5nIGxpc3QNCkJlaGF2ZUBpZXRmLm9yZzxtYWlsdG86QmVoYXZlQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCg0KDQoKKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqClRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0 aGUgIm1lc3NhZ2UiKSBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSBhZGRyZXNzZWVzLiAKQW55IHVuYXV0aG9yaXNlZCB1c2Ugb3IgZGlzc2VtaW5hdGlvbiBpcyBw cm9oaWJpdGVkLgpNZXNzYWdlcyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gCkZyYW5j ZSBUZWxlY29tIEdyb3VwIHNoYWxsIG5vdCBiZSBsaWFibGUgZm9yIHRoZSBtZXNzYWdlIGlmIGFs dGVyZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg YWRkcmVzc2VlIG9mIHRoaXMgbWVzc2FnZSwgcGxlYXNlIGNhbmNlbCBpdCBpbW1lZGlhdGVseSBh bmQgaW5mb3JtIHRoZSBzZW5kZXIuCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCgo= --_000_94C682931C08B048B7A8645303FDC9F33C3FD7B2DBPUEXCB1Bnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuNTUxMiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAw IGJnQ29sb3I9I2ZmZmZmZj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTAx MTAwMDIxNi0xMDAxMjAxMT48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZm IHNpemU9Mj5EZWFyIFhpbmcsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTAxMTAwMDIxNi0xMDAxMjAxMT48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDExMDAwMjE2LTEwMDEyMDExPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPlRoYW5rIHlvdSBm b3IgeW91ciBpbnRlcmVzdCBhbmQgZm9yIHRoZSBwb2ludGVyIHRvIHRoZSANCm11bHRpY2FzdCBz ZWN0aW9uIGluIGl2aS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9MDExMDAwMjE2LTEwMDEyMDExPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 IiANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wMTEwMDAyMTYtMTAwMTIwMTE+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+SSB3aWxsIGNvbnRhY3Qg eW91IG9mZmxpbmUgZm9yIHRoZSBwcmVwYXJhdGlvbiBvZiB0aGUgbmV4dCANCnZlcnNpb24gb2Yg dGhlIEktRC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ QU4gY2xhc3M9MDExMDAwMjE2LTEwMDEyMDExPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTAxMTAwMDIxNi0xMDAxMjAxMT48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5DaGVlcnMsPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTAxMTAwMDIxNi0x MDAxMjAxMT48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5N ZWQ8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9MDExMDAwMjE2LTEwMDEyMDExPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMw MDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp Z249bGVmdD4NCjxIUiB0YWJJbmRleD0tMT4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5E ZSZuYnNwOzo8L0I+IFhpbmcgTGkgW21haWx0bzp4aW5nQGNlcm5ldC5lZHUuY25dIA0KPEJSPjxC PkVudm95w6kmbmJzcDs6PC9CPiBkaW1hbmNoZSA5IGphbnZpZXIgMjAxMSAwODozNjxCUj48Qj7D gCZuYnNwOzo8L0I+IA0KQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9OQUQvVElQPEJSPjxCPkNjJm5i c3A7OjwvQj4gQmVoYXZlIFdHOyANCmRyYWZ0LWJvdWNhZGFpci1iZWhhdmUtNjQtbXVsdGljYXN0 LWFkZHJlc3MtZm9ybWF0QHRvb2xzLmlldGYub3JnOyBYaW5nIExpOyANCmNvbmd4aWFvPEJSPjxC Pk9iamV0Jm5ic3A7OjwvQj4gUmU6IFtCRUhBVkVdIE11bHRpY2FzdCBJUHY0LWVtYmVkZGVkIEFk ZHJlc3MgDQpGb3JtYXQ8QlI+PC9GT05UPjxCUj48L0RJVj4NCjxESVY+PC9ESVY+5LqOIDIwMTEt MS01IDIwOjQ5LCA8QSBjbGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgDQpocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLWZ0Z3JvdXAuY29tIj5tb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UtZnRncm91cC5jb208L0E+IA0K5YaZ6YGTOiANCjxCTE9DS1FVT1RFIA0KY2l0ZT1t aWQ6MzA1Nl8xMjk0MjMxNzYyXzREMjQ2OEQyXzMwNTZfMzI4MTQ2XzFfOTRDNjgyOTMxQzA4QjA0 OEI3QTg2NDUzMDNGREM5RjMzQzNFOUZEOEVDQFBVRVhDQjFCLm5hbnRlcnJlLmZyYW5jZXRlbGVj b20uZnIgDQp0eXBlPSJjaXRlIj4NCiAgPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC41 NTEyIiBuYW1lPUdFTkVSQVRPUj4NCiAgPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6 ZT0yPiZuYnNwOyZuYnNwOyBEZWFyIGFsbCw8L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9E SVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4mbmJzcDsmbmJzcDsg VmFyaW91cyBzb2x1dGlvbnMgKGUuZy4sIA0KICBbSS1ELnZlbmFhcy1iZWhhdmUtdjR2Nm1jLWZy YW1ld29ya10sPEJSPiZuYnNwOyZuYnNwOyANCiAgW0ktRC54dS1zb2Z0d2lyZS1tZXNoLW11bHRp Y2FzdF0gb3IgW0ktRC5xaW4tc29mdHdpcmUtZHNsaXRlLTxCUj4mbmJzcDsmbmJzcDsgDQogIG11 bHRpY2FzdF0pIGhhdmUgYmVlbiBwcm9wb3NlZCB0byBhbGxvdyBhY2Nlc3MgdG8gSVB2NCANCiAg bXVsdGljYXN0PEJSPiZuYnNwOyZuYnNwOyBjb250ZW50IGZyb20gaG9zdHMgYXR0YWNoZWQgdG8g SVB2Ni1lbmFibGVkIA0KICBkb21haW5zLiZuYnNwOyBFdmVuIGlmIHRoZXNlPEJSPiZuYnNwOyZu YnNwOyBzb2x1dGlvbnMgaGF2ZSBkaXN0aW5jdCANCiAgYXBwbGljYWJpbGl0eSBzY29wZXMgKHRy YW5zbGF0aW9uIHZzLjxCUj4mbmJzcDsmbmJzcDsgZW5jYXBzdWxhdGlvbikgYW5kIA0KICB0YXJn ZXQgdmFyaW91cyB1c2UgY2FzZXMsIHRoZXkgYWxsIG1ha2UgdXNlIG9mPEJSPiZuYnNwOyZuYnNw OyBzcGVjaWZpYyBJUHY2IA0KICBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIGVtYmVkIGFuIElQdjQg bXVsdGljYXN0IGFkZHJlc3MuPEJSPiZuYnNwOyZuYnNwOyANCiAgUGFydGljdWxhcmx5LCZuYnNw OzxTUEFOIGNsYXNzPTI5NDQxMzkxMi0wNTAxMjAxMT5hbiA8L1NQQU4+SVB2NC1lbWJlZGRlZCBJ UHY2IA0KICBtdWx0aWNhc3QgYWRkcmVzcyBpcyB1c2VkIGFzIGE8QlI+Jm5ic3A7Jm5ic3A7IGRl c3RpbmF0aW9uIElQdjYgYWRkcmVzcyBvZiANCiAgbXVsdGljYXN0IGZsb3dzIHJlY2VpdmVkIGZy b20gdGhlIElQdjQtPEJSPiZuYnNwOyZuYnNwOyBlbmFibGVkIGRvbWFpbiBhbmQgDQogIGluamVj dGVkIGJ5IHRoZSBJUHY0LUlQdjYgSW50ZXJjb25uZWN0aW9uIEZ1bmN0aW9uPEJSPiZuYnNwOyZu YnNwOyBpbnRvIHRoZSANCiAgSVB2Ni1lbmFibGVkIGRvbWFpbi4mbmJzcDsgSXQgaXMgYWxzbyB1 c2VkIHRvIGJ1aWxkIHRoZSBJUHY2PEJSPiZuYnNwOyZuYnNwOyANCiAgbXVsdGljYXN0IHN0YXRl ICgqLCBHNikgb3IgKFM2LEc2KSBjb3JyZXNwb25kaW5nIHRvIHRoZWlyICgqLCBHNCkgDQogIG9y PEJSPiZuYnNwOyZuYnNwOyAoUzQsRzQpIElQdjQgY291bnRlcnBhcnRzIGJ5IHRoZSBJUHY0LUlQ djYgSW50ZXJjb25uZWN0aW9uIA0KICBGdW5jdGlvbi48L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5i c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4mbmJzcDsm bmJzcDsgVG9nZXRoZXIgd2l0aCBZaXUgYW5kIEphY25pLCANCiAgd2UgaGF2ZSBlZGl0ZWQgdGhp cyBJLUQgdG8gZGVmaW5lIElQdjQtPEJSPiZuYnNwOyZuYnNwOyBlbWJlZGRlZCBJUHY2IA0KICBt dWx0aWNhc3QgYWRkcmVzcyBmb3JtYXQ8U1BBTiBjbGFzcz0yOTQ0MTM5MTItMDUwMTIwMTE+IHdo aWNoIGFpbXMgdG8gdXBkYXRlIA0KICBSRkM0MTkyPC9TUEFOPi48L0ZPTlQ+PC9ESVY+PC9CTE9D S1FVT1RFPjxCUj5UaGUgPEEgY2xhc3M9bW96LXR4dC1saW5rLXJmYzIzOTZFIA0KaHJlZj0iaHR0 cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteGxpLWJlaGF2ZS1p dmktMDcudHh0Ij4iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQteGxpLWJlaGF2ZS1pdmktMDcudHh0IjwvQT4gDQooY3VycmVudGx5IGluIFJGQyBxdWV1ZSkg cHJvcG9zZWQgYSBtdWx0aWNhc3QgYWRkcmVzcyBmb3JtYXQgZm9yIFNTTSB3aGVuIA0Kc3RhdGVs ZXNzIHRyYW5zbGF0aW9uIGlzIHVzZWQuIEl0IGlzIGluIFNlY3Rpb24gIjUuMS4gSVZJIE11bHRp Y2FzdCIgLiBXZSBoYXZlIA0KZGVwbG95ZWQgdGhlIHByb3RvdHlwZSBhbmQgaXQgaGFzIGJlZW4g dGVzdGVkIGFuZCB1c2VkIGJldHdlZW4mbmJzcDsgQ0VSTkVUIA0KKElQdjQpIGFuZCBDRVJORVQy IChJUHY2KS4mbmJzcDsgV2UgY2FuIGFkZCBtb3JlIGRldGFpbHMgaW4gNC41LiZuYnNwOyBTU00g b2YgDQptdWx0aWNhc3QtYWRkcmVzcy1mb3JtYXQgZHJhZnQuPEJSPjxCUj5SZWdhcmRzLDxCUj48 QlI+eGluZywgDQpjb25neGlhbzxCUj48QlI+PEJSPjxCUj48QlI+DQo8QkxPQ0tRVU9URSANCmNp dGU9bWlkOjMwNTZfMTI5NDIzMTc2Ml80RDI0NjhEMl8zMDU2XzMyODE0Nl8xXzk0QzY4MjkzMUMw OEIwNDhCN0E4NjQ1MzAzRkRDOUYzM0MzRTlGRDhFQ0BQVUVYQ0IxQi5uYW50ZXJyZS5mcmFuY2V0 ZWxlY29tLmZyIA0KdHlwZT0iY2l0ZSI+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZP TlQgc2l6ZT0rMD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PEZPTlQgc2l6ZT0yPiZuYnNwOyZu YnNwOyANCiAgQ29tbWVudHMsIHN1Z2dlc3Rpb25zIGFuZCBjb250cmlidXRpb25zIGFyZSBtb3Jl IHRoYW4gd2VsY29tZTxTUEFOIA0KICBjbGFzcz0yOTQ0MTM5MTItMDUwMTIwMTE+LjwvU1BBTj48 L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZuYnNwOyZuYnNwOyBDaGVlcnMsPC9GT05U PjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiBzaXplPTI+Jm5ic3A7Jm5ic3A7IE1lZDwvRk9OVD48L0RJVj48UFJFPioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg KHRoZSAibWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIGFkZHJlc3NlZXMuIA0KQW55IHVuYXV0aG9yaXNlZCB1c2Ugb3IgZGlzc2VtaW5hdGlvbiBp cyBwcm9oaWJpdGVkLg0KTWVzc2FnZXMgYXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIA0K RnJhbmNlIFRlbGVjb20gR3JvdXAgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2Ug aWYgYWx0ZXJlZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgYWRkcmVzc2VlIG9mIHRoaXMgbWVzc2FnZSwgcGxlYXNlIGNhbmNlbCBpdCBpbW1lZGlh dGVseSBhbmQgaW5mb3JtIHRoZSBzZW5kZXIuDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KPC9QUkU+PFBSRSB3cmFwPSIiPjxGSUVMRFNFVCBjbGFzcz1taW1lQXR0YWNobWVudEhl YWRlcj48L0ZJRUxEU0VUPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkJlaGF2ZSBtYWlsaW5nIGxpc3QNCjxBIGNsYXNzPW1vei10eHQtbGluay1hYmJy ZXZpYXRlZCBocmVmPSJtYWlsdG86QmVoYXZlQGlldGYub3JnIj5CZWhhdmVAaWV0Zi5vcmc8L0E+ DQo8QSBjbGFzcz1tb3otdHh0LWxpbmstZnJlZXRleHQgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYmVoYXZlPC9BPg0KPC9QUkU+PC9CTE9DS1FVT1RFPjxCUj48UFJFPioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50 cyAodGhlICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgYWRkcmVzc2Vlcy4gCkFueSB1bmF1dGhvcmlzZWQgdXNlIG9yIGRpc3NlbWluYXRpb24g aXMgcHJvaGliaXRlZC4KTWVzc2FnZXMgYXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIApG cmFuY2UgVGVsZWNvbSBHcm91cCBzaGFsbCBub3QgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBp ZiBhbHRlcmVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIGFkZHJlc3NlZSBvZiB0aGlzIG1lc3NhZ2UsIHBsZWFzZSBjYW5jZWwgaXQgaW1tZWRpYXRl bHkgYW5kIGluZm9ybSB0aGUgc2VuZGVyLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kgo8L1BSRT48L0JPRFk+PC9IVE1MPg0K --_000_94C682931C08B048B7A8645303FDC9F33C3FD7B2DBPUEXCB1Bnante_-- From behcetsarikaya@yahoo.com Mon Jan 10 15:18:00 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390BC3A6784 for ; Mon, 10 Jan 2011 15:18:00 -0800 (PST) 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.368, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwm9exehgEK4 for ; Mon, 10 Jan 2011 15:17:57 -0800 (PST) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by core3.amsl.com (Postfix) with SMTP id 022493A67F0 for ; Mon, 10 Jan 2011 15:17:56 -0800 (PST) Received: from [98.139.91.69] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 23:20:09 -0000 Received: from [98.139.91.16] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 23:20:09 -0000 Received: from [127.0.0.1] by omp1016.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 23:20:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 786835.74214.bm@omp1016.mail.sp2.yahoo.com Received: (qmail 47691 invoked by uid 60001); 10 Jan 2011 23:20:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294701609; bh=yN/MqujeE0hikm3suYKOXMhIP7mabcyDsMwAv9e4zb0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YkvvsguAY4POtGHEuQZayGFOQzGhu/KMb4a78bsIqlEdLddImJEdL+Yy2q0Iolie1YLqvgxmHPN0zzhfNlmJ9+atDalSM/H3JloRhvMx3GuZ/qtZXp9JJy/NeJ263aM1cdS+S+NzCAM8w8xw2a4dcZXn1i35iaaJH9Kju15bkz0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JhZTBY+5DRk9lKs7okuAG13Tuvp2LJ4BZRl3vL3Nn8dMlo6eDrM6NRWb/h8hwaNgsU8f2HIqS5B4ZYXhdaD1H2CzVivOl/a8ZxmhLHwwwiSVWpqqIrdiJKP9ab8q0/MtxoWtvZUB74Y9Nbbw1HWUrw8746ktHz1fHCNefGmmKq0=; Message-ID: <243598.45466.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: tkNMs.IVM1mdFFpo6jTWxfLZk01C8VbMxOkpAyUN76qIa3v rly.VIks5UbJ7YWYJ3Hk4A_H_0q5IW8xspkPXEdhL7CVydu0ihXQVr6mQUNL RiU_K3W.r4yHevmeJvwHXV8nqtH_3AXgvc.0pndeJhklCmJ5RihTD8XYC9KK ls40b7JzFLC45YsFL7RvD92Pg981qHLT4XGXOjgi0MBxbN8gmPuuHGw7.nUD Xrp8O4dpkr12CuRW8_lRCCM5sjs_QFSUC9H4r8ihZN1LTDaJXnkEPqB2PIbf VdRybuL2h0Fs5dunNzsOe7mm.zYwgfQc3WuyopxZ_Ks2maLzCZRP8Z9vL3Pc uSlUjcidRIuuhKHo3c64gkoKM8ci.bc2yv8NxKTLkeuHlWKIVdRAP1Fke1y1 tT7tdcA91rg-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Mon, 10 Jan 2011 15:20:08 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> Date: Mon, 10 Jan 2011 15:20:08 -0800 (PST) From: Behcet Sarikaya To: Xing Li , mohamed.boucadair@orange-ftgroup.com In-Reply-To: <4D29657C.5050804@cernet.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Harrington , Behave WG Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:18:00 -0000 > Dear all, >> >> Various solutions (e.g., [I-D.venaas-behave-v4v6mc-framework], >> [I-D.xu-softwire-mesh-multicast] or [I-D.qin-softwire-dslite- >> multicast]) have been proposed to allow access to IPv4 multicast >> content from hosts attached to IPv6-enabled domains. Even if >these >> solutions have distinct applicability scopes (translation vs. >> encapsulation) and target various use cases, they all make use of >> specific IPv6 multicast addresses to embed an IPv4 multicast >>address. >> Particularly, an IPv4-embedded IPv6 multicast address is used as a >> destination IPv6 address of multicast flows received from the >IPv4- >> enabled domain and injected by the IPv4-IPv6 Interconnection >>Function >> into the IPv6-enabled domain. It is also used to build the IPv6 >> multicast state (*, G6) or (S6,G6) corresponding to their (*, G4) >>or >> (S4,G4) IPv4 counterparts by the IPv4-IPv6 Interconnection >>Function. >> >> Together with Yiu and Jacni, we have edited this I-D to define >>IPv4- >> embedded IPv6 multicast address formatwhich aims to update RFC4192. The "http://www.rfc-editor.org/internet-drafts/draft-xli-behave-ivi-07.txt"; (currently in RFC queue) proposed a multicast address format for SSM when stateless translation is used. It is in Section "5.1. IVI Multicast" . We have deployed the prototype and it has been tested and used between CERNET (IPv4) and CERNET2 (IPv6). We can add more details in 4.5. SSM of multicast-address-format draft. Hi Xing, I believe multicast should be out of scope for documents like yours. Multicast support is a separate issue which probably needs to be covered in separate drafts. It is not late, I think Section 5.1 can be removed before it becomes an RFC. Regards, Behcet From tom.taylor@huawei.com Mon Jan 17 05:58:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED6B28C0EF for ; Mon, 17 Jan 2011 05:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=1.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exh+j+0cU4Lc for ; Mon, 17 Jan 2011 05:58:16 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3880C28C0D9 for ; Mon, 17 Jan 2011 05:58:15 -0800 (PST) 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 <0LF6009TU6WZGP@szxga04-in.huawei.com> for behave@ietf.org; Mon, 17 Jan 2011 22:00:36 +0800 (CST) Received: from 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 <0LF6002C46WZER@szxga04-in.huawei.com> for behave@ietf.org; Mon, 17 Jan 2011 22:00:35 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF600AI96WWLF@szxml02-in.huawei.com>; Mon, 17 Jan 2011 22:00:35 +0800 (CST) Date: Mon, 17 Jan 2011 09:00:40 -0500 From: Tom Taylor To: behave@ietf.org Message-id: <4D344B88.90708@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 Cc: Cathy Zhou , jihui@chinatelecom.com.cn, Tina TSOU Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:58:17 -0000 A Softwires version of this document using encapsulation will be submitted shortly. A new version of I-D, draft-tsou-behave-translated-multicast-00.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-behave-translated-multicast Revision: 00 Title: A Generic Approach to Multicast Translation In Support of IPv6 Transition Creation_date: 2011-01-17 WG ID: Independent Submission Number_of_pages: 9 Abstract: Consider a situation which will arise in many IPv6 transition scenarios, where Network A, to which a host is attached, supports one IP version, but the host and Network B support a different IP version. Suppose that the host wishes to access a multicast group which is rooted or sourced in Network B. This document specifies a stateful translation mechanism whereby the host can obtain its desired access using the native multicast capabilities of Network A. The IETF Secretariat. From teemu.savolainen@nokia.com Mon Jan 17 07:00:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638073A6C25 for ; Mon, 17 Jan 2011 07:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npor2Ezu8T6b for ; Mon, 17 Jan 2011 07:00:18 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id E9C553A6E3F for ; Mon, 17 Jan 2011 07:00:17 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0HF2nh7003402 for ; Mon, 17 Jan 2011 17:02:51 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 17:02:45 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 17 Jan 2011 16:02:44 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.109]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Mon, 17 Jan 2011 16:02:44 +0100 From: To: Thread-Topic: Local IPv6 address synthesis when non-zero suffixes are used on the network Thread-Index: Acu2V5cZgSG5qC1kSO6NBFE9/gLUEQ== Date: Mon, 17 Jan 2011 15:02:42 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3191DAFFC@008-AM1MPN1-017.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_056B511A55F8AA42A3E492B7DD19A3191DAFFC008AM1MPN1017mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2011 15:02:45.0493 (UTC) FILETIME=[98F71250:01CBB657] X-Nokia-AV: Clean Subject: [BEHAVE] Local IPv6 address synthesis when non-zero suffixes are used on the network X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:00:19 -0000 --_000_056B511A55F8AA42A3E492B7DD19A3191DAFFC008AM1MPN1017mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC6052 defines a suffix field for those IPv4-Embedded IPv6 Address Formats= that use other than 96-bit NSP prefix lengths. In case of the host local IPv6 address synthesis, should the host initializ= e this suffix field to zero or copy the suffix bits it has most likely lear= nt at the same time with NSP? For me initialize to zero sounds more logical choice, but I was not really = following the work that lead to RFC6052.. Best regards, Teemu --_000_056B511A55F8AA42A3E492B7DD19A3191DAFFC008AM1MPN1017mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC6052 defines a suffix field for those IPv4-Embedded= IPv6 Address Formats that use other than 96-bit NSP prefix lengths.

 

In case of the host local IPv6 address synthesis, shou= ld the host initialize this suffix field to zero or copy the suffix bits it has mo= st likely learnt at the same time with NSP?

 

For me initialize to zero sounds more logical choice, = but I was not really following the work that lead to RFC6052..

 

Best regards,

 

Teemu

 

 

--_000_056B511A55F8AA42A3E492B7DD19A3191DAFFC008AM1MPN1017mgdn_-- From huitema@microsoft.com Mon Jan 17 07:10:50 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CDA28C0D7 for ; Mon, 17 Jan 2011 07:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.394 X-Spam-Level: X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wglCpZkOw0cv for ; Mon, 17 Jan 2011 07:10:44 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 0936F28C10A for ; Mon, 17 Jan 2011 07:10:43 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 07:13:18 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.255.3; Mon, 17 Jan 2011 07:13:18 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.137]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 17 Jan 2011 07:13:17 -0800 From: Christian Huitema To: "teemu.savolainen@nokia.com" , "behave@ietf.org" Thread-Topic: [BEHAVE] Local IPv6 address synthesis when non-zero suffixes are used on the network Thread-Index: Acu2V5cZgSG5qC1kSO6NBFE9/gLUEQAARrYg Date: Mon, 17 Jan 2011 15:13:15 +0000 Message-ID: References: <056B511A55F8AA42A3E492B7DD19A3191DAFFC@008-AM1MPN1-017.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3191DAFFC@008-AM1MPN1-017.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CEBCE3CF81D2D441B14B84256C3C46810FF0A4TK5EX14MBXW653win_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Local IPv6 address synthesis when non-zero suffixes are used on the network X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:10:50 -0000 --_000_CEBCE3CF81D2D441B14B84256C3C46810FF0A4TK5EX14MBXW653win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 6052 is actually quite clear. In section 2.2, when discussing the suffi= x, it states that "These bits are reserved for future extension and SHOULD = be set to zero." From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= teemu.savolainen@nokia.com Sent: Monday, January 17, 2011 7:03 AM To: behave@ietf.org Subject: [BEHAVE] Local IPv6 address synthesis when non-zero suffixes are u= sed on the network Hi, RFC6052 defines a suffix field for those IPv4-Embedded IPv6 Address Formats= that use other than 96-bit NSP prefix lengths. In case of the host local IPv6 address synthesis, should the host initializ= e this suffix field to zero or copy the suffix bits it has most likely lear= nt at the same time with NSP? For me initialize to zero sounds more logical choice, but I was not really = following the work that lead to RFC6052.. Best regards, Teemu --_000_CEBCE3CF81D2D441B14B84256C3C46810FF0A4TK5EX14MBXW653win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC 6052 is actually quite clear. In section 2.2, when discus= sing the suffix, it states that “These bits are reserved for future e= xtension and SHOULD be set to zero.”

 

From: behave-bounces@ietf.org [mailto:behave-boun= ces@ietf.org] On Behalf Of teemu.savolainen@nokia.com
Sent: Monday, January 17, 2011 7:03 AM
To: behave@ietf.org
Subj= ect: [BEHAVE] Local IPv6 address synthesis when non-zero suffixes are u= sed on the network

 

Hi,

 

RFC6052 defines a suffix fiel= d for those IPv4-Embedded IPv6 Address Formats that use other than 96-bit N= SP prefix lengths.

 

=

In case of the host local IPv6 address synthesis, shou= ld the host initialize this suffix field to zero or copy the suffix bits it= has most likely learnt at the same time with NSP?

 

For me initialize to= zero sounds more logical choice, but I was not really following the work t= hat lead to RFC6052..

 <= /p>

Best regards,

 

Teemu

 

 

= = --_000_CEBCE3CF81D2D441B14B84256C3C46810FF0A4TK5EX14MBXW653win_-- From Internet-Drafts@ietf.org Wed Jan 19 10:00:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DC73A7013; Wed, 19 Jan 2011 10:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbNT4rbIUp6j; Wed, 19 Jan 2011 10:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B0528C0EB; Wed, 19 Jan 2011 10:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110119180002.20059.62443.idtracker@localhost> Date: Wed, 19 Jan 2011 10:00:02 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Analysis of 64 Translation Author(s) : R. Penno, et al. Filename : draft-ietf-behave-64-analysis-00.txt Pages : 14 Date : 2011-01-18 Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-64-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-19095136.I-D@ietf.org> --NextPart-- From dwing@cisco.com Wed Jan 19 11:04:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EE43A7194 for ; Wed, 19 Jan 2011 11:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKyXqEhZWEzF for ; Wed, 19 Jan 2011 11:04:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3AD923A7077 for ; Wed, 19 Jan 2011 11:04:00 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACLFNk2rRN+J/2dsb2JhbACXVIx0c6RKmwiFUASEbw Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2011 19:06:41 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0JJ6eOr009610; Wed, 19 Jan 2011 19:06:40 GMT From: "Dan Wing" To: "'Tom Taylor'" , References: <4D344B88.90708@huawei.com> In-Reply-To: <4D344B88.90708@huawei.com> Date: Wed, 19 Jan 2011 11:06:40 -0800 Message-ID: <00f701cbb80c$01301dc0$03905940$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu2Tvob02qXqrP7QCim5EGl41aZOABvB7Yg Content-Language: en-us Cc: 'Tina TSOU' , jihui@chinatelecom.com.cn, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:04:01 -0000 Today, multicast IP addresses are learned by hosts using proprietary electronic program guides (EPG) or, sometimes, via SDP conveyed in SIP, SAP, or RTSP. The introduction says: Instead it makes use of the fact that for a given network, it is unnecessary to map the complete universe of IPv6 addresses into IPv4, but only those addresses actually being carried through the network. Because the mapping is not algorithmic it needs to be synchronized with the EPG, SIP, SAP, or RTSP. This synchronization is unique to this proposal, and is an additional operational burden for the network operator. Which makes me wonder: what is the advantage of the dynamic mapping? -d > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Monday, January 17, 2011 6:01 AM > To: behave@ietf.org > Cc: Cathy Zhou; jihui@chinatelecom.com.cn; Tina TSOU > Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave- > translated-multicast-00 > > A Softwires version of this document using encapsulation will be > submitted shortly. > > A new version of I-D, draft-tsou-behave-translated-multicast-00.txt has > been successfully submitted by Tom Taylor and posted to the IETF > repository. > > Filename: draft-tsou-behave-translated-multicast > Revision: 00 > Title: A Generic Approach to Multicast Translation In > Support of IPv6 > Transition > Creation_date: 2011-01-17 > WG ID: Independent Submission > Number_of_pages: 9 > > Abstract: > Consider a situation which will arise in many IPv6 transition > scenarios, where Network A, to which a host is attached, supports one > IP version, but the host and Network B support a different IP > version. Suppose that the host wishes to access a multicast group > which is rooted or sourced in Network B. This document specifies a > stateful translation mechanism whereby the host can obtain its > desired access using the native multicast capabilities of Network A. > > > > > The IETF Secretariat. > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From yiu_lee@cable.comcast.com Wed Jan 19 11:21:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22B83A71A5 for ; Wed, 19 Jan 2011 11:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.166 X-Spam-Level: X-Spam-Status: No, score=-104.166 tagged_above=-999 required=5 tests=[AWL=-2.431, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZfk9gXB0-9q for ; Wed, 19 Jan 2011 11:21:12 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id BC2FD3A7194 for ; Wed, 19 Jan 2011 11:21:11 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.22675987; Wed, 19 Jan 2011 12:30:56 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 14:20:21 -0500 From: "Lee, Yiu" To: Dan Wing , 'Tom Taylor' , "behave@ietf.org" Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 Thread-Index: AQHLuA3pfTV9FUeNREmqsKogLONcGw== Date: Wed, 19 Jan 2011 19:20:20 +0000 Message-ID: In-Reply-To: <00f701cbb80c$01301dc0$03905940$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Cathy Zhou' , "jihui@chinatelecom.com.cn" , 'Tina TSOU' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:21:12 -0000 Good question. If I read the draft correctly, I think this draft tries to do a stateful map in the HMAF and BMAF. The pool is required to pre-configure and the mapping is required to be synchronized between HMAF and BMAF using a TBD OOB protocol. Before we jump to the solution. What exact scenario we want to solve? Do we have a use case where a v4 listener wants to receive v6 content? Regards, Yiu On 1/19/11 2:06 PM, "Dan Wing" wrote: >Today, multicast IP addresses are learned by hosts using proprietary >electronic program guides (EPG) or, sometimes, via SDP conveyed in SIP, >SAP, or RTSP. > >The introduction says: > > Instead it makes use of the fact that for a given network, it is > unnecessary to map the complete universe of IPv6 addresses into IPv4, > but only those addresses actually being carried through the network. > >Because the mapping is not algorithmic it needs to be synchronized with >the=20 >EPG, SIP, SAP, or RTSP. This synchronization is unique to this proposal, >and is an additional operational burden for the network operator. Which >makes me wonder: what is the advantage of the dynamic mapping? > >-d > > > > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Tom Taylor >> Sent: Monday, January 17, 2011 6:01 AM >> To: behave@ietf.org >> Cc: Cathy Zhou; jihui@chinatelecom.com.cn; Tina TSOU >> Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave- >> translated-multicast-00 >>=20 >> A Softwires version of this document using encapsulation will be >> submitted shortly. >>=20 >> A new version of I-D, draft-tsou-behave-translated-multicast-00.txt has >> been successfully submitted by Tom Taylor and posted to the IETF >> repository. >>=20 >> Filename: draft-tsou-behave-translated-multicast >> Revision: 00 >> Title: A Generic Approach to Multicast Translation In >> Support of IPv6 >> Transition >> Creation_date: 2011-01-17 >> WG ID: Independent Submission >> Number_of_pages: 9 >>=20 >> Abstract: >> Consider a situation which will arise in many IPv6 transition >> scenarios, where Network A, to which a host is attached, supports one >> IP version, but the host and Network B support a different IP >> version. Suppose that the host wishes to access a multicast group >> which is rooted or sourced in Network B. This document specifies a >> stateful translation mechanism whereby the host can obtain its >> desired access using the native multicast capabilities of Network A. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From tom111.taylor@bell.net Wed Jan 19 11:29:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AF93A71AC for ; Wed, 19 Jan 2011 11:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-xrgQVWavAa for ; Wed, 19 Jan 2011 11:29:43 -0800 (PST) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by core3.amsl.com (Postfix) with ESMTP id B3B193A71A4 for ; Wed, 19 Jan 2011 11:29:43 -0800 (PST) Received: from BLU0-SMTP14 ([65.55.116.72]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 11:32:24 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP14.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 11:32:23 -0800 Date: Wed, 19 Jan 2011 14:32:31 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <4D344B88.90708@huawei.com> <00f701cbb80c$01301dc0$03905940$@com> In-Reply-To: <00f701cbb80c$01301dc0$03905940$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2011 19:32:23.0942 (UTC) FILETIME=[98E5FA60:01CBB80F] Cc: jihui@chinatelecom.com.cn, behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:29:44 -0000 The synchronization happens automatically. There is no burden on the operator. The host gets the multicast address from the electronic program guide, signals to the HMAF, and the HMAF asks the mapper (mapping function) for allocation of IPvy addresses to map to the signalled IPvx addresses. On 19/01/2011 2:06 PM, Dan Wing wrote: > Today, multicast IP addresses are learned by hosts using proprietary > electronic program guides (EPG) or, sometimes, via SDP conveyed in SIP, > SAP, or RTSP. > > The introduction says: > > Instead it makes use of the fact that for a given network, it is > unnecessary to map the complete universe of IPv6 addresses into IPv4, > but only those addresses actually being carried through the network. > > Because the mapping is not algorithmic it needs to be synchronized with the > EPG, SIP, SAP, or RTSP. This synchronization is unique to this proposal, > and is an additional operational burden for the network operator. Which > makes me wonder: what is the advantage of the dynamic mapping? > > -d > > > > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Tom Taylor >> Sent: Monday, January 17, 2011 6:01 AM >> To: behave@ietf.org >> Cc: Cathy Zhou; jihui@chinatelecom.com.cn; Tina TSOU >> Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave- >> translated-multicast-00 >> >> A Softwires version of this document using encapsulation will be >> submitted shortly. >> >> A new version of I-D, draft-tsou-behave-translated-multicast-00.txt has >> been successfully submitted by Tom Taylor and posted to the IETF >> repository. >> >> Filename: draft-tsou-behave-translated-multicast >> Revision: 00 >> Title: A Generic Approach to Multicast Translation In >> Support of IPv6 >> Transition >> Creation_date: 2011-01-17 >> WG ID: Independent Submission >> Number_of_pages: 9 >> >> Abstract: >> Consider a situation which will arise in many IPv6 transition >> scenarios, where Network A, to which a host is attached, supports one >> IP version, but the host and Network B support a different IP >> version. Suppose that the host wishes to access a multicast group >> which is rooted or sourced in Network B. This document specifies a >> stateful translation mechanism whereby the host can obtain its >> desired access using the native multicast capabilities of Network A. >> >> >> >> >> The IETF Secretariat. >> >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From tom111.taylor@bell.net Wed Jan 19 11:31:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BFF3A71AD for ; Wed, 19 Jan 2011 11:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DvQgJEZrbZ5 for ; Wed, 19 Jan 2011 11:31:51 -0800 (PST) Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by core3.amsl.com (Postfix) with ESMTP id 036013A71A4 for ; Wed, 19 Jan 2011 11:31:50 -0800 (PST) Received: from BLU0-SMTP18 ([65.55.116.72]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 11:34:31 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP18.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 11:34:31 -0800 Date: Wed, 19 Jan 2011 14:34:38 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2011 19:34:31.0439 (UTC) FILETIME=[E4E479F0:01CBB80F] Cc: 'Tom Taylor' , "behave@ietf.org" , "jihui@chinatelecom.com.cn" , 'Cathy Zhou' , Dan Wing , 'Tina TSOU' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:31:51 -0000 That is not covered by this draft. It allows an IPv4 listener to get IPv4 content across an IPv6 network, or an IPv6 listener to get IPv6 content across an IPv4 network. On 19/01/2011 2:20 PM, Lee, Yiu wrote: > Good question. If I read the draft correctly, I think this draft tries to > do a stateful map in the HMAF and BMAF. The pool is required to > pre-configure and the mapping is required to be synchronized between HMAF > and BMAF using a TBD OOB protocol. Before we jump to the solution. What > exact scenario we want to solve? Do we have a use case where a v4 listener > wants to receive v6 content? > > Regards, > Yiu > ... From yiu_lee@cable.comcast.com Wed Jan 19 13:30:06 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E743A71C5 for ; Wed, 19 Jan 2011 13:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.045 X-Spam-Level: X-Spam-Status: No, score=-104.045 tagged_above=-999 required=5 tests=[AWL=-2.310, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZDzkFzyPGNy for ; Wed, 19 Jan 2011 13:30:05 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 4FB813A71BE for ; Wed, 19 Jan 2011 13:30:05 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.22704897; Wed, 19 Jan 2011 14:36:42 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 16:26:07 -0500 From: "Lee, Yiu" To: Tom Taylor Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 Thread-Index: AQHLuB97+OHipuvRPky7042v/H/lDg== Date: Wed, 19 Jan 2011 21:26: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.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <4A84F310C5FD9C47897F0F60155F038F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Tom Taylor' , "behave@ietf.org" , "jihui@chinatelecom.com.cn" , 'Cathy Zhou' , Dan Wing , 'Tina TSOU' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 21:30:06 -0000 But I thought people agree that doubt translation is bad. Why not use softwire for this the 4-6-4 case? On 1/19/11 2:34 PM, "Tom Taylor" wrote: >That is not covered by this draft. It allows an IPv4 listener to get >IPv4 content across an IPv6 network, or an IPv6 listener to get IPv6 >content across an IPv4 network. > >On 19/01/2011 2:20 PM, Lee, Yiu wrote: >> Good question. If I read the draft correctly, I think this draft tries >>to >> do a stateful map in the HMAF and BMAF. The pool is required to >> pre-configure and the mapping is required to be synchronized between >>HMAF >> and BMAF using a TBD OOB protocol. Before we jump to the solution. What >> exact scenario we want to solve? Do we have a use case where a v4 >>listener >> wants to receive v6 content? >> >> Regards, >> Yiu >> >... From tom111.taylor@bell.net Wed Jan 19 14:23:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AD33A716F for ; Wed, 19 Jan 2011 14:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBhc-bmC4+iW for ; Wed, 19 Jan 2011 14:23:16 -0800 (PST) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by core3.amsl.com (Postfix) with ESMTP id 5E45E3A6F5B for ; Wed, 19 Jan 2011 14:23:16 -0800 (PST) Received: from BLU0-SMTP38 ([65.55.116.74]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 14:25:57 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP38.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 14:25:57 -0800 Date: Wed, 19 Jan 2011 17:26:04 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2011 22:25:57.0872 (UTC) FILETIME=[D8159700:01CBB827] Cc: 'Tom Taylor' , "behave@ietf.org" , "jihui@chinatelecom.com.cn" , 'Cathy Zhou' , Dan Wing , 'Tina TSOU' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:23:17 -0000 A softwire draft has been prepared, but I'd like to take up this point. It depends on why double mapping is bad. In this case, the second translation is simply the inverse of the first one. On 19/01/2011 4:26 PM, Lee, Yiu wrote: > But I thought people agree that doubt translation is bad. Why not use > softwire for this the 4-6-4 case? > > > On 1/19/11 2:34 PM, "Tom Taylor" wrote: > >> That is not covered by this draft. It allows an IPv4 listener to get >> IPv4 content across an IPv6 network, or an IPv6 listener to get IPv6 >> content across an IPv4 network. >> >> On 19/01/2011 2:20 PM, Lee, Yiu wrote: >>> Good question. If I read the draft correctly, I think this draft tries >>> to >>> do a stateful map in the HMAF and BMAF. The pool is required to >>> pre-configure and the mapping is required to be synchronized between >>> HMAF >>> and BMAF using a TBD OOB protocol. Before we jump to the solution. What >>> exact scenario we want to solve? Do we have a use case where a v4 >>> listener >>> wants to receive v6 content? >>> >>> Regards, >>> Yiu >>> >> ... > > > From dwing@cisco.com Wed Jan 19 15:53:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833F328C117 for ; Wed, 19 Jan 2011 15:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.531 X-Spam-Level: X-Spam-Status: No, score=-110.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj+RazbUyB47 for ; Wed, 19 Jan 2011 15:53:19 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A05C228C0F1 for ; Wed, 19 Jan 2011 15:53:19 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGcIN02rR7Ht/2dsb2JhbACXVYx0c6MUmnqFUASEbw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2011 23:56:01 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0JNtx3s001082; Wed, 19 Jan 2011 23:56:00 GMT From: "Dan Wing" To: "'Tom Taylor'" , "'Lee, Yiu'" References: In-Reply-To: Date: Wed, 19 Jan 2011 15:55:59 -0800 Message-ID: <037e01cbb834$6c5808b0$45081a10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu4J9xVWzDnsZNPSEqDsF2Zj9yi5AADBe8Q Content-Language: en-us Cc: jihui@chinatelecom.com.cn, 'Tom Taylor' , 'Tina TSOU' , behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 23:53:20 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Wednesday, January 19, 2011 2:26 PM > To: Lee, Yiu > Cc: 'Tom Taylor'; behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy > Zhou'; Dan Wing; 'Tina TSOU' > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > behave-translated-multicast-00 > > A softwire draft has been prepared, but I'd like to take up this point. > It depends on why double mapping is bad. In this case, the second > translation is simply the inverse of the first one. If it is a "lossless translation", that is, the same IP address exists on both sides -- then the two translation functions are equivalent to a tunnel and indistinguishable from a tunnel. The term "inverse" is an accurate term for such a lossless translation. However, the function described in draft-tsou-behave-translated-multicast is not lossless -- the mapped address is chosen from a pool of addresses. From Section 3.1 of draft-tsou-behave-translated-multicast: ... 2. Address Mapping At the HMAF The HMAF checks its cache of mappings to see if it already has a mapping between the IPvx address pair received in the host request and a corresponding pair of IPvy addresses. Failing to find a mapping, it sends a request for the required mapping to the mapping function. The mapping function in turn checks whether it has already created the mapping. If not, it assigns unicast and multicast IPvy addresses from its pool and records the mapping for further use. ... -d > On 19/01/2011 4:26 PM, Lee, Yiu wrote: > > But I thought people agree that doubt translation is bad. Why not use > > softwire for this the 4-6-4 case? > > > > > > On 1/19/11 2:34 PM, "Tom Taylor" wrote: > > > >> That is not covered by this draft. It allows an IPv4 listener to get > >> IPv4 content across an IPv6 network, or an IPv6 listener to get IPv6 > >> content across an IPv4 network. > >> > >> On 19/01/2011 2:20 PM, Lee, Yiu wrote: > >>> Good question. If I read the draft correctly, I think this draft > tries > >>> to > >>> do a stateful map in the HMAF and BMAF. The pool is required to > >>> pre-configure and the mapping is required to be synchronized > between > >>> HMAF > >>> and BMAF using a TBD OOB protocol. Before we jump to the solution. > What > >>> exact scenario we want to solve? Do we have a use case where a v4 > >>> listener > >>> wants to receive v6 content? > >>> > >>> Regards, > >>> Yiu > >>> > >> ... > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Jan 19 16:01:35 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E4028C0E4 for ; Wed, 19 Jan 2011 16:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeutaOLkKRpu for ; Wed, 19 Jan 2011 16:01:33 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A5F2128C0DE for ; Wed, 19 Jan 2011 16:01:33 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIQKN02rR7Ht/2dsb2JhbACXVYx0c6MPmneFUASEbw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2011 00:01:43 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0K01gTY005571; Thu, 20 Jan 2011 00:01:42 GMT From: "Dan Wing" To: "'Tom Taylor'" References: <4D344B88.90708@huawei.com> <00f701cbb80c$01301dc0$03905940$@com> In-Reply-To: Date: Wed, 19 Jan 2011 16:01:41 -0800 Message-ID: <037f01cbb835$382509c0$a86f1d40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu4D5vpZeticB4kTxiTS6T+RUQSewAJQKyQ Content-Language: en-us Cc: jihui@chinatelecom.com.cn, behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:01:35 -0000 > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Wednesday, January 19, 2011 11:33 AM > To: Dan Wing > Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > behave-translated-multicast-00 > > The synchronization happens automatically. There is no burden on the > operator. The host gets the multicast address from the electronic > program guide, signals to the HMAF, and the HMAF asks the mapper > (mapping function) for allocation of IPvy addresses to map to the > signalled IPvx addresses. Thanks. I see now where the draft says: As a result, the host-side multicast adaptation function (HMAF) needs to obtain a mapping between this IPvx address pair and the corresponding IPvy address pair used in the IPvy network to denote the same multicast stream. So -- what is the advantage of this dynamic mapping, and what is the advantage of this round trip before joining a multicast group? Is there an assumption that there are more IPv6 multicast groups than can be mapped to the IPv4 multicast space, _and_ that some (many) of them won't have active listeners? -d > On 19/01/2011 2:06 PM, Dan Wing wrote: > > Today, multicast IP addresses are learned by hosts using proprietary > > electronic program guides (EPG) or, sometimes, via SDP conveyed in > SIP, > > SAP, or RTSP. > > > > The introduction says: > > > > Instead it makes use of the fact that for a given network, it is > > unnecessary to map the complete universe of IPv6 addresses into > IPv4, > > but only those addresses actually being carried through the > network. > > > > Because the mapping is not algorithmic it needs to be synchronized > with the > > EPG, SIP, SAP, or RTSP. This synchronization is unique to this > proposal, > > and is an additional operational burden for the network operator. > Which > > makes me wonder: what is the advantage of the dynamic mapping? > > > > -d > > > > > > > > > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> Behalf Of Tom Taylor > >> Sent: Monday, January 17, 2011 6:01 AM > >> To: behave@ietf.org > >> Cc: Cathy Zhou; jihui@chinatelecom.com.cn; Tina TSOU > >> Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou- > behave- > >> translated-multicast-00 > >> > >> A Softwires version of this document using encapsulation will be > >> submitted shortly. > >> > >> A new version of I-D, draft-tsou-behave-translated-multicast-00.txt > has > >> been successfully submitted by Tom Taylor and posted to the IETF > >> repository. > >> > >> Filename: draft-tsou-behave-translated-multicast > >> Revision: 00 > >> Title: A Generic Approach to Multicast Translation In > >> Support of IPv6 > >> Transition > >> Creation_date: 2011-01-17 > >> WG ID: Independent Submission > >> Number_of_pages: 9 > >> > >> Abstract: > >> Consider a situation which will arise in many IPv6 transition > >> scenarios, where Network A, to which a host is attached, supports > one > >> IP version, but the host and Network B support a different IP > >> version. Suppose that the host wishes to access a multicast group > >> which is rooted or sourced in Network B. This document specifies a > >> stateful translation mechanism whereby the host can obtain its > >> desired access using the native multicast capabilities of Network A. > >> > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > From tom111.taylor@bell.net Wed Jan 19 17:49:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE23C3A700F for ; Wed, 19 Jan 2011 17:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.496 X-Spam-Level: X-Spam-Status: No, score=-101.496 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zXllZupyyqg for ; Wed, 19 Jan 2011 17:49:20 -0800 (PST) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by core3.amsl.com (Postfix) with ESMTP id 109913A6F73 for ; Wed, 19 Jan 2011 17:49:19 -0800 (PST) Received: from BLU0-SMTP17 ([65.55.116.73]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 17:52:01 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP17.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 17:52:00 -0800 Date: Wed, 19 Jan 2011 20:52:07 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <037e01cbb834$6c5808b0$45081a10$@com> In-Reply-To: <037e01cbb834$6c5808b0$45081a10$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2011 01:52:00.0573 (UTC) FILETIME=[A0D40ED0:01CBB844] Cc: 'Tom Taylor' , behave@ietf.org, jihui@chinatelecom.com.cn, 'Cathy Zhou' , "'Lee, Yiu'" , 'Tina TSOU' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:49:21 -0000 The mapping is lossless. I think what we failed to make clear in the draft is that the "Mapping Function" is a centralized entity. It could be collocated with the border gateway, as one possibility (which I suspect has problems), or it could be a standalone device. Thus the mapping the HMAF receives from the Mapper (let's call it that) is the same mapping the BMAF will receive when it in turn consults the Mapper. As a result, the second translation will truly be an inversion, both for outgoing signalling and incoming content. On 19/01/2011 6:55 PM, Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Tom Taylor >> Sent: Wednesday, January 19, 2011 2:26 PM >> To: Lee, Yiu >> Cc: 'Tom Taylor'; behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy >> Zhou'; Dan Wing; 'Tina TSOU' >> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >> behave-translated-multicast-00 >> >> A softwire draft has been prepared, but I'd like to take up this point. >> It depends on why double mapping is bad. In this case, the second >> translation is simply the inverse of the first one. > > If it is a "lossless translation", that is, the same IP address > exists on both sides -- then the two translation functions are > equivalent to a tunnel and indistinguishable from a tunnel. The > term "inverse" is an accurate term for such a lossless > translation. > > However, the function described in draft-tsou-behave-translated-multicast > is not lossless -- the mapped address is chosen from a pool of > addresses. From Section 3.1 of draft-tsou-behave-translated-multicast: > > ... > 2. Address Mapping At the HMAF > > The HMAF checks its cache of mappings to see if it already has a > mapping between the IPvx address pair received in the > host request and a corresponding pair of IPvy addresses. Failing to > find a mapping, it sends a request for the required mapping to the > mapping function. The mapping function in turn checks whether it has > already created the mapping. If not, it assigns unicast and > multicast IPvy addresses from its pool and records the mapping for > further use. > ... > > -d > > >> On 19/01/2011 4:26 PM, Lee, Yiu wrote: >>> But I thought people agree that doubt translation is bad. Why not use >>> softwire for this the 4-6-4 case? >>> >>> >>> On 1/19/11 2:34 PM, "Tom Taylor" wrote: >>> >>>> That is not covered by this draft. It allows an IPv4 listener to get >>>> IPv4 content across an IPv6 network, or an IPv6 listener to get IPv6 >>>> content across an IPv4 network. >>>> >>>> On 19/01/2011 2:20 PM, Lee, Yiu wrote: >>>>> Good question. If I read the draft correctly, I think this draft >> tries >>>>> to >>>>> do a stateful map in the HMAF and BMAF. The pool is required to >>>>> pre-configure and the mapping is required to be synchronized >> between >>>>> HMAF >>>>> and BMAF using a TBD OOB protocol. Before we jump to the solution. >> What >>>>> exact scenario we want to solve? Do we have a use case where a v4 >>>>> listener >>>>> wants to receive v6 content? >>>>> >>>>> Regards, >>>>> Yiu >>>>> >>>> ... >>> >>> >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > > From tom111.taylor@bell.net Wed Jan 19 17:51:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2CB3A700F for ; Wed, 19 Jan 2011 17:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.721 X-Spam-Level: X-Spam-Status: No, score=-101.721 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUj9Ff5wpiar for ; Wed, 19 Jan 2011 17:51:54 -0800 (PST) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by core3.amsl.com (Postfix) with ESMTP id A0E013A6F73 for ; Wed, 19 Jan 2011 17:51:54 -0800 (PST) Received: from BLU0-SMTP19 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 17:54:35 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP19.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 17:54:35 -0800 Date: Wed, 19 Jan 2011 20:54:42 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <4D344B88.90708@huawei.com> <00f701cbb80c$01301dc0$03905940$@com> <037f01cbb835$382509c0$a86f1d40$@com> In-Reply-To: <037f01cbb835$382509c0$a86f1d40$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2011 01:54:35.0512 (UTC) FILETIME=[FD2DDF80:01CBB844] Cc: jihui@chinatelecom.com.cn, behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:51:56 -0000 Yes, that is precisely the assumption. I have in mind that Network B does not necessarily have any relationship to the intermediate Network A, so we're really contemplating a selection from the whole wide world, not just the provider's own content sources. On 19/01/2011 7:01 PM, Dan Wing wrote: >> -----Original Message----- >> From: Tom Taylor [mailto:tom111.taylor@bell.net] >> Sent: Wednesday, January 19, 2011 11:33 AM >> To: Dan Wing >> Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' >> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >> behave-translated-multicast-00 >> >> The synchronization happens automatically. There is no burden on the >> operator. The host gets the multicast address from the electronic >> program guide, signals to the HMAF, and the HMAF asks the mapper >> (mapping function) for allocation of IPvy addresses to map to the >> signalled IPvx addresses. > > Thanks. I see now where the draft says: > > As a result, the host-side multicast adaptation function (HMAF) needs > to obtain a mapping between this IPvx address pair and the > corresponding IPvy address pair used in the IPvy network to denote > the same multicast stream. > > So -- what is the advantage of this dynamic mapping, and what is the > advantage of this round trip before joining a multicast group? > > Is there an assumption that there are more IPv6 multicast groups > than can be mapped to the IPv4 multicast space, _and_ that some > (many) of them won't have active listeners? > > -d > > >> On 19/01/2011 2:06 PM, Dan Wing wrote: >>> Today, multicast IP addresses are learned by hosts using proprietary >>> electronic program guides (EPG) or, sometimes, via SDP conveyed in >> SIP, >>> SAP, or RTSP. >>> >>> The introduction says: >>> >>> Instead it makes use of the fact that for a given network, it is >>> unnecessary to map the complete universe of IPv6 addresses into >> IPv4, >>> but only those addresses actually being carried through the >> network. >>> >>> Because the mapping is not algorithmic it needs to be synchronized >> with the >>> EPG, SIP, SAP, or RTSP. This synchronization is unique to this >> proposal, >>> and is an additional operational burden for the network operator. >> Which >>> makes me wonder: what is the advantage of the dynamic mapping? >>> >>> -d >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of Tom Taylor >>>> Sent: Monday, January 17, 2011 6:01 AM >>>> To: behave@ietf.org >>>> Cc: Cathy Zhou; jihui@chinatelecom.com.cn; Tina TSOU >>>> Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou- >> behave- >>>> translated-multicast-00 >>>> >>>> A Softwires version of this document using encapsulation will be >>>> submitted shortly. >>>> >>>> A new version of I-D, draft-tsou-behave-translated-multicast-00.txt >> has >>>> been successfully submitted by Tom Taylor and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-tsou-behave-translated-multicast >>>> Revision: 00 >>>> Title: A Generic Approach to Multicast Translation In >>>> Support of IPv6 >>>> Transition >>>> Creation_date: 2011-01-17 >>>> WG ID: Independent Submission >>>> Number_of_pages: 9 >>>> >>>> Abstract: >>>> Consider a situation which will arise in many IPv6 transition >>>> scenarios, where Network A, to which a host is attached, supports >> one >>>> IP version, but the host and Network B support a different IP >>>> version. Suppose that the host wishes to access a multicast group >>>> which is rooted or sourced in Network B. This document specifies a >>>> stateful translation mechanism whereby the host can obtain its >>>> desired access using the native multicast capabilities of Network A. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> > > > From dwing@cisco.com Wed Jan 19 18:31:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D020E3A6F07 for ; Wed, 19 Jan 2011 18:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.533 X-Spam-Level: X-Spam-Status: No, score=-110.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siPcaqHAyzTe for ; Wed, 19 Jan 2011 18:31:47 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 778813A6DA7 for ; Wed, 19 Jan 2011 18:31:47 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG4tN02rR7Hu/2dsb2JhbACXVox0c6IpmnuFUASEbw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2011 02:34:29 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0K2YS39019123; Thu, 20 Jan 2011 02:34:28 GMT From: "Dan Wing" To: "'Tom Taylor'" References: <4D344B88.90708@huawei.com> <00f701cbb80c$01301dc0$03905940$@com> <037f01cbb835$382509c0$a86f1d40$@com> In-Reply-To: Date: Wed, 19 Jan 2011 18:34:27 -0800 Message-ID: <041a01cbb84a$8f329a60$ad97cf20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu4RQGkI+6x67P0S4aigZkfn5t8bgABSj6Q Content-Language: en-us Cc: jihui@chinatelecom.com.cn, behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 02:31:49 -0000 > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Wednesday, January 19, 2011 5:55 PM > To: Dan Wing > Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > behave-translated-multicast-00 > > Yes, that is precisely the assumption. I have in mind that Network B > does not necessarily have any relationship to the intermediate Network > A, so we're really contemplating a selection from the whole wide world, > not just the provider's own content sources. But that can only work with IPv6 receivers, otherwise there will be IPv4 conflicts with the IPv4 multicast space (exactly the same as IPv4 conflicts with RFC1918 space). And there also isn't IPv4 on the Internet (the whole world) which does not appear to be changing with IPv6. -d > On 19/01/2011 7:01 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >> Sent: Wednesday, January 19, 2011 11:33 AM > >> To: Dan Wing > >> Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' > >> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > >> behave-translated-multicast-00 > >> > >> The synchronization happens automatically. There is no burden on the > >> operator. The host gets the multicast address from the electronic > >> program guide, signals to the HMAF, and the HMAF asks the mapper > >> (mapping function) for allocation of IPvy addresses to map to the > >> signalled IPvx addresses. > > > > Thanks. I see now where the draft says: > > > > As a result, the host-side multicast adaptation function (HMAF) > needs > > to obtain a mapping between this IPvx address pair and the > > corresponding IPvy address pair used in the IPvy network to > denote > > the same multicast stream. > > > > So -- what is the advantage of this dynamic mapping, and what is the > > advantage of this round trip before joining a multicast group? > > > > Is there an assumption that there are more IPv6 multicast groups > > than can be mapped to the IPv4 multicast space, _and_ that some > > (many) of them won't have active listeners? > > > > -d > > > > > >> On 19/01/2011 2:06 PM, Dan Wing wrote: > >>> Today, multicast IP addresses are learned by hosts using > proprietary > >>> electronic program guides (EPG) or, sometimes, via SDP conveyed in > >> SIP, > >>> SAP, or RTSP. > >>> > >>> The introduction says: > >>> > >>> Instead it makes use of the fact that for a given network, it > is > >>> unnecessary to map the complete universe of IPv6 addresses > into > >> IPv4, > >>> but only those addresses actually being carried through the > >> network. > >>> > >>> Because the mapping is not algorithmic it needs to be synchronized > >> with the > >>> EPG, SIP, SAP, or RTSP. This synchronization is unique to this > >> proposal, > >>> and is an additional operational burden for the network operator. > >> Which > >>> makes me wonder: what is the advantage of the dynamic mapping? > >>> > >>> -d > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >>>> Behalf Of Tom Taylor > >>>> Sent: Monday, January 17, 2011 6:01 AM > >>>> To: behave@ietf.org > >>>> Cc: Cathy Zhou; jihui@chinatelecom.com.cn; Tina TSOU > >>>> Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou- > >> behave- > >>>> translated-multicast-00 > >>>> > >>>> A Softwires version of this document using encapsulation will be > >>>> submitted shortly. > >>>> > >>>> A new version of I-D, draft-tsou-behave-translated-multicast- > 00.txt > >> has > >>>> been successfully submitted by Tom Taylor and posted to the IETF > >>>> repository. > >>>> > >>>> Filename: draft-tsou-behave-translated-multicast > >>>> Revision: 00 > >>>> Title: A Generic Approach to Multicast Translation In > >>>> Support of IPv6 > >>>> Transition > >>>> Creation_date: 2011-01-17 > >>>> WG ID: Independent Submission > >>>> Number_of_pages: 9 > >>>> > >>>> Abstract: > >>>> Consider a situation which will arise in many IPv6 transition > >>>> scenarios, where Network A, to which a host is attached, supports > >> one > >>>> IP version, but the host and Network B support a different IP > >>>> version. Suppose that the host wishes to access a multicast group > >>>> which is rooted or sourced in Network B. This document specifies a > >>>> stateful translation mechanism whereby the host can obtain its > >>>> desired access using the native multicast capabilities of Network > A. > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Behave mailing list > >>>> Behave@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/behave > >>> > >>> _______________________________________________ > >>> Behave mailing list > >>> Behave@ietf.org > >>> https://www.ietf.org/mailman/listinfo/behave > >>> > >>> > > > > > > From yiu_lee@cable.comcast.com Wed Jan 19 18:41:06 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2FF3A7047 for ; Wed, 19 Jan 2011 18:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.299 X-Spam-Level: X-Spam-Status: No, score=-107.299 tagged_above=-999 required=5 tests=[AWL=1.164, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGMAqjsJV1MT for ; Wed, 19 Jan 2011 18:41:05 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 2877E3A6FAB for ; Wed, 19 Jan 2011 18:41:05 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.111308494; Wed, 19 Jan 2011 21:43:02 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 21:43:02 -0500 From: "Lee, Yiu" To: Tom Taylor , Dan Wing Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 Thread-Index: AQHLuEvB+OHipuvRPky7042v/H/lDg== Date: Thu, 20 Jan 2011 02:43:01 +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.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <0524938C96800A438A78A163EF3BE7EE@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , "jihui@chinatelecom.com.cn" , 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 02:41:06 -0000 Is this similar to what draft-xu-softwire-mesh-multicast-00 tries to solve?=20 On 1/19/11 8:54 PM, "Tom Taylor" wrote: >Yes, that is precisely the assumption. I have in mind that Network B >does not necessarily have any relationship to the intermediate Network >A, so we're really contemplating a selection from the whole wide world, >not just the provider's own content sources. > From tom111.taylor@bell.net Wed Jan 19 19:19:16 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700773A7097 for ; Wed, 19 Jan 2011 19:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.736 X-Spam-Level: X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwEisTDhL5UN for ; Wed, 19 Jan 2011 19:19:15 -0800 (PST) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by core3.amsl.com (Postfix) with ESMTP id EB1A13A7089 for ; Wed, 19 Jan 2011 19:19:14 -0800 (PST) Received: from BLU0-SMTP31 ([65.55.116.74]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 19:21:56 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP31.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 19:21:56 -0800 Date: Wed, 19 Jan 2011 22:22:02 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <4D344B88.90708@huawei.com> <00f701cbb80c$01301dc0$03905940$@com> <037f01cbb835$382509c0$a86f1d40$@com> <041a01cbb84a$8f329a60$ad97cf20$@com> In-Reply-To: <041a01cbb84a$8f329a60$ad97cf20$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2011 03:21:56.0192 (UTC) FILETIME=[30DE2E00:01CBB851] Cc: jihui@chinatelecom.com.cn, behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 03:19:16 -0000 I'm not sure I follow. I'm an IPv4 user attached to an IPv6 network. I want to listen to a multicast of an IETF meeting. Are you saying there will be an address conflict? On 19/01/2011 9:34 PM, Dan Wing wrote: >> -----Original Message----- >> From: Tom Taylor [mailto:tom111.taylor@bell.net] >> Sent: Wednesday, January 19, 2011 5:55 PM >> To: Dan Wing >> Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' >> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >> behave-translated-multicast-00 >> >> Yes, that is precisely the assumption. I have in mind that Network B >> does not necessarily have any relationship to the intermediate Network >> A, so we're really contemplating a selection from the whole wide world, >> not just the provider's own content sources. > > But that can only work with IPv6 receivers, otherwise there will be > IPv4 conflicts with the IPv4 multicast space (exactly the same as IPv4 > conflicts with RFC1918 space). And there also isn't IPv4 on the > Internet (the whole world) which does not appear to be changing with > IPv6. > > -d ... From tom111.taylor@bell.net Wed Jan 19 19:38:18 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CF828C0E3 for ; Wed, 19 Jan 2011 19:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xbkIr5FAqEa for ; Wed, 19 Jan 2011 19:38:18 -0800 (PST) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by core3.amsl.com (Postfix) with ESMTP id F1D8128B797 for ; Wed, 19 Jan 2011 19:38:17 -0800 (PST) Received: from BLU0-SMTP69 ([65.55.116.74]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 19:40:59 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP69.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 19:40:59 -0800 Date: Wed, 19 Jan 2011 22:41:06 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2011 03:40:59.0600 (UTC) FILETIME=[DA646500:01CBB853] Cc: "behave@ietf.org" , "jihui@chinatelecom.com.cn" , Dan Wing , 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 03:38:18 -0000 I think the Xu paper goes more deeply into the problem, by considering the topology required to serve many multicast groups. We aren't trying to do better than what PIM can accomplish. On 19/01/2011 9:43 PM, Lee, Yiu wrote: > Is this similar to what draft-xu-softwire-mesh-multicast-00 tries to > solve? > > > On 1/19/11 8:54 PM, "Tom Taylor" wrote: > >> Yes, that is precisely the assumption. I have in mind that Network B >> does not necessarily have any relationship to the intermediate Network >> A, so we're really contemplating a selection from the whole wide world, >> not just the provider's own content sources. >> > > > From remi.despres@free.fr Thu Jan 20 01:15:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E9C28C129 for ; Thu, 20 Jan 2011 01:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ2U4wgxH0TA for ; Thu, 20 Jan 2011 01:15:28 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by core3.amsl.com (Postfix) with ESMTP id 5EF0728C0EC for ; Thu, 20 Jan 2011 01:15:28 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id 918BF700008B; Thu, 20 Jan 2011 10:18:10 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id 2D25E700008E; Thu, 20 Jan 2011 10:18:10 +0100 (CET) X-SFR-UUID: 20110120091810185.2D25E700008E@msfrf2307.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20110119180002.20059.62443.idtracker@localhost> Date: Thu, 20 Jan 2011 10:18:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E3495CC-B66A-4F45-93D6-71C9760B2E95@free.fr> References: <20110119180002.20059.62443.idtracker@localhost> To: Reinaldo Penno X-Mailer: Apple Mail (2.1082) Cc: Behave WG Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 09:15:29 -0000 Hi all, This draft is clearly important and IMHO deserves fast progress. There is however a point in the Introduction which I find important (and = easy to fix). The first sentence of 1.2 says: "The current 64 proposal is widely seen as the next step in the = evolution of interconnection techniques enabling communications between = IPv6-only and IPv4-only networks." As a matter of fact, 4 ISPs in Japan have announced their plans to = deploy 4rd as their approach to interconnection of IPv6-only and = IPv4-only networks. =20 = http://www.ietf.org/mail-archive/web/v4tov6transition/current/msg00157.htm= l = http://www.ietf.org/mail-archive/web/v4tov6transition/current/msg00269.htm= l There are indeed important experiments going on with NAT64, but this = cannot justify that it be seen as "THE next step". If I may suggest a wording that would better reflect the current = situation, it could become: "The current 64 proposal is a major interconnection technique designed = to enable communications between IPv6-only and IPv4-only networks." Regards, RD Le 19 janv. 2011 =E0 19:00, internet-drafts@ietf.org a =E9crit : > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. >=20 >=20 > Title : Analysis of 64 Translation > Author(s) : R. Penno, et al. > Filename : draft-ietf-behave-64-analysis-00.txt > Pages : 14 > Date : 2011-01-18 >=20 > Due to specific problems, NAT-PT was deprecated by the IETF as a > mechanism to perform IPv6-IPv4 translation. Since then, new efforts > have been undertaken within IETF to standardize alternative > mechanisms to perform IPv6-IPv4 translation. This document evaluates > how the new translation mechanisms avoid the problems that caused the > IETF to deprecate NAT-PT. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From jouni.nospam@gmail.com Thu Jan 20 04:45:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74133A6FD5 for ; Thu, 20 Jan 2011 04:45:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-x73PAPh5rp for ; Thu, 20 Jan 2011 04:45:39 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A04673A6F6E for ; Thu, 20 Jan 2011 04:45:39 -0800 (PST) Received: by ewy8 with SMTP id 8so206000ewy.31 for ; Thu, 20 Jan 2011 04:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=B1S5By26NrN2srVN2+cRn5MrjKHKB3eBUNn8CKP6hcc=; b=lM3Jxim+flWZDDVsiREt1cgxt2QxAk4nOUEfF38nFXhc4tlvAyyQp9POM6XBVnrJvQ /qLhEzq7DmJkovfz50fiQXUdEMjOw6BQsGwmfdkjr9HSVmuZujv04BhQhgONRnUtFivP Xb8+UdVqV/LVS6JUdcV2VbAo+jtUsD1NlHgQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=MsCYA2k/nLmi9nXpnA4EjOF5Q6y1kPGAeDkJlEIxR8i+KwOnrXmpCJ2WLSGLNi9FZb HHXNc1VdX8XJZpi7UCvQS316/rJB28QvcUO1h4J3/Dt6kbF/p+M/GfBTgeqR9ye8nkiG oHD0rRsWUL/dkvKxWdLoBZtvGU3zYEZt4nlzQ= Received: by 10.213.33.67 with SMTP id g3mr2884246ebd.91.1295527701480; Thu, 20 Jan 2011 04:48:21 -0800 (PST) Received: from [192.168.141.77] ([213.246.198.210]) by mx.google.com with ESMTPS id b52sm6514525eei.19.2011.01.20.04.48.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Jan 2011 04:48:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: jouni korhonen In-Reply-To: <20110119180002.20059.62443.idtracker@localhost> Date: Thu, 20 Jan 2011 14:48:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07F70959-3C2E-43DD-90E5-7654B3FA69AF@gmail.com> References: <20110119180002.20059.62443.idtracker@localhost> To: "'behave' (behave@ietf.org)" X-Mailer: Apple Mail (2.1078) Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:45:40 -0000 Folks, We have (finally) updated the I-D. Sorry that it took slightly longer = than planned. This version should address Dave's comments and the = feedback we received in Beijing. Comments and feedback is solicited. - Jouni On Jan 19, 2011, at 8:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. >=20 >=20 > Title : Analysis of 64 Translation > Author(s) : R. Penno, et al. > Filename : draft-ietf-behave-64-analysis-00.txt > Pages : 14 > Date : 2011-01-18 >=20 > Due to specific problems, NAT-PT was deprecated by the IETF as a > mechanism to perform IPv6-IPv4 translation. Since then, new efforts > have been undertaken within IETF to standardize alternative > mechanisms to perform IPv6-IPv4 translation. This document evaluates > how the new translation mechanisms avoid the problems that caused the > IETF to deprecate NAT-PT. >=20 From dwing@cisco.com Thu Jan 20 08:07:34 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3753A7141 for ; Thu, 20 Jan 2011 08:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QbpFj1hwGnK for ; Thu, 20 Jan 2011 08:07:33 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 368D13A713E for ; Thu, 20 Jan 2011 08:07:32 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ/tN02rR7Hu/2dsb2JhbACXXIx1c6NBmxmFUASEbw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2011 16:10:11 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0KGABhF008348; Thu, 20 Jan 2011 16:10:11 GMT From: "Dan Wing" To: "'Tom Taylor'" References: <4D344B88.90708@huawei.com> <00f701cbb80c$01301dc0$03905940$@com> <037f01cbb835$382509c0$a86f1d40$@com> <041a01cbb84a$8f329a60$ad97cf20$@com> In-Reply-To: Date: Thu, 20 Jan 2011 08:10:10 -0800 Message-ID: <099201cbb8bc$838ab860$8aa02920$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu4UTTsWEqype30RV239JTgU1T6hAAauXrA Content-Language: en-us Cc: jihui@chinatelecom.com.cn, behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 16:07:34 -0000 > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Wednesday, January 19, 2011 7:22 PM > To: Dan Wing > Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > behave-translated-multicast-00 > > I'm not sure I follow. I'm an IPv4 user attached to an IPv6 network. I > want to listen to a multicast of an IETF meeting. Are you saying there > will be an address conflict? * Multicast does not generally exist on the IPv4 Internet. Yes, I know that a few times a year an organization called the IETF has a week-long multicast feed. * Multicast generally exists within private networks, which assign their own multicast IPv4 addresses to whatever streams they like. * A network, such as an ISP's network, cannot successfully interconnect their multicast network with "the whole wide world" because of that IPv4 multicast address overlap. -d > On 19/01/2011 9:34 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >> Sent: Wednesday, January 19, 2011 5:55 PM > >> To: Dan Wing > >> Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' > >> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > >> behave-translated-multicast-00 > >> > >> Yes, that is precisely the assumption. I have in mind that Network B > >> does not necessarily have any relationship to the intermediate > Network > >> A, so we're really contemplating a selection from the whole wide > world, > >> not just the provider's own content sources. > > > > But that can only work with IPv6 receivers, otherwise there will be > > IPv4 conflicts with the IPv4 multicast space (exactly the same as > IPv4 > > conflicts with RFC1918 space). And there also isn't IPv4 on the > > Internet (the whole world) which does not appear to be changing with > > IPv6. > > > > -d > ... From mohamed.boucadair@orange-ftgroup.com Thu Jan 20 08:21:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F339D3A7141 for ; Thu, 20 Jan 2011 08:21:28 -0800 (PST) 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.024, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzEM1cpop7g7 for ; Thu, 20 Jan 2011 08:21:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 38AFE3A7011 for ; Thu, 20 Jan 2011 08:21:27 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 6790B1B81C8; Thu, 20 Jan 2011 17:24:09 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 491501800B3; Thu, 20 Jan 2011 17:24:09 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 20 Jan 2011 17:24:09 +0100 From: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Reinaldo Penno Date: Thu, 20 Jan 2011 17:24:07 +0100 Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-00.txt Thread-Index: Acu4gvjWADkfuuXFT3i0DOtSZb/gjwAOz4hQ Message-ID: <27290_1295540649_4D3861A9_27290_1876_1_94C682931C08B048B7A8645303FDC9F33C413CE0D5@PUEXCB1B.nanterre.francetelecom.fr> References: <20110119180002.20059.62443.idtracker@localhost> <4E3495CC-B66A-4F45-93D6-71C9760B2E95@free.fr> In-Reply-To: <4E3495CC-B66A-4F45-93D6-71C9760B2E95@free.fr> 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: 2010.12.28.90317 Cc: Behave WG Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 16:21:29 -0000 Dear R=E9mi, What about the following wording: "The current 64 proposal is widely seen as a major next step in the evolution of interconnection techniques enabling communications between IPv6-only and IPv4-only networks. One of the building blocks of this proposal is decoupling the DNS functionality from the protocol translation itself." ? If this is OK with you, I can modify the I-D accordingly. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= R=E9mi Despr=E9s Envoy=E9 : jeudi 20 janvier 2011 10:18 =C0 : Reinaldo Penno Cc : Behave WG Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-00.txt Hi all, This draft is clearly important and IMHO deserves fast progress. There is however a point in the Introduction which I find important (and ea= sy to fix). The first sentence of 1.2 says: "The current 64 proposal is widely seen as the next step in the evolution o= f interconnection techniques enabling communications between IPv6-only and = IPv4-only networks." As a matter of fact, 4 ISPs in Japan have announced their plans to deploy 4= rd as their approach to interconnection of IPv6-only and IPv4-only networks= .=20=20 http://www.ietf.org/mail-archive/web/v4tov6transition/current/msg00157.ht= ml http://www.ietf.org/mail-archive/web/v4tov6transition/current/msg00269.ht= ml There are indeed important experiments going on with NAT64, but this cannot= justify that it be seen as "THE next step". If I may suggest a wording that would better reflect the current situation,= it could become: "The current 64 proposal is a major interconnection technique designed to e= nable communications between IPv6-only and IPv4-only networks." Regards, RD Le 19 janv. 2011 =E0 19:00, internet-drafts@ietf.org a =E9crit : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Behavior Engineering for Hindrance Avoid= ance Working Group of the IETF. >=20 >=20 > Title : Analysis of 64 Translation > Author(s) : R. Penno, et al. > Filename : draft-ietf-behave-64-analysis-00.txt > Pages : 14 > Date : 2011-01-18 >=20 > Due to specific problems, NAT-PT was deprecated by the IETF as a > mechanism to perform IPv6-IPv4 translation. Since then, new efforts > have been undertaken within IETF to standardize alternative > mechanisms to perform IPv6-IPv4 translation. This document evaluates > how the new translation mechanisms avoid the problems that caused the > IETF to deprecate NAT-PT. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From jacniq@gmail.com Thu Jan 20 09:20:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A796C3A703D for ; Thu, 20 Jan 2011 09:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMH8zQW2eCXH for ; Thu, 20 Jan 2011 09:20:44 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 780173A6FDE for ; Thu, 20 Jan 2011 09:20:44 -0800 (PST) Received: by bwz12 with SMTP id 12so837498bwz.31 for ; Thu, 20 Jan 2011 09:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lWXfS66jP7PmFMDI5rZZ/78ginqzKShpgM97TDFTBUw=; b=RRQJu+eSfTzpUfM0fYXdlbQ6htK1gzD8wZXK7g3FL1pd4ttRCW8BdrpSpyshpqpDKO caJWSPvSmXVRB0xjrpukhTVIZWBHwZleO7g73AOa0gza8hu4RGYl+xTpoMSIDzVmngmY 6x+s2ng6XrK41keOX7P/ywnFMI3Ss9NeV5CQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Gqpz/hNkjNWT2JkO4svOnYwgwD0TSwjBL6kuUXzdp7OjZZZC0DtN1x+xPRm7WDyI4U q81gkp/z2bPZnrAod9h6bsKq0KAbIgY4p2mM55Eg6TVy/bTd7+dJ2NC0uL6RC7ZuH0i6 3l20rifpvydv8pQx4Awj08UX9OZfzvd7Qvy1c= MIME-Version: 1.0 Received: by 10.204.76.131 with SMTP id c3mr2196530bkk.110.1295544199583; Thu, 20 Jan 2011 09:23:19 -0800 (PST) Received: by 10.204.152.11 with HTTP; Thu, 20 Jan 2011 09:23:19 -0800 (PST) In-Reply-To: <4D344B88.90708@huawei.com> References: <4D344B88.90708@huawei.com> Date: Fri, 21 Jan 2011 01:23:19 +0800 Message-ID: From: Jacni Qin To: Tom Taylor Content-Type: multipart/alternative; boundary=00163645890ece992c049a4a6374 Cc: jihui@chinatelecom.com.cn, Tina TSOU , behave@ietf.org, Cathy Zhou Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:20:46 -0000 --00163645890ece992c049a4a6374 Content-Type: text/plain; charset=ISO-8859-1 Re-, The scenarios proposed in Abstract are confusing, IPvx -> IPvy? It seems to conflict with later sections in the draft. On Mon, Jan 17, 2011 at 10:00 PM, Tom Taylor wrote: > A Softwires version of this document using encapsulation will be submitted > shortly. > > A new version of I-D, draft-tsou-behave-translated-multicast-00.txt has > been successfully submitted by Tom Taylor and posted to the IETF repository. > > Filename: draft-tsou-behave-translated-multicast > Revision: 00 > Title: A Generic Approach to Multicast Translation In Support of > IPv6 Transition > Creation_date: 2011-01-17 > WG ID: Independent Submission > Number_of_pages: 9 > > Abstract: > Consider a situation which will arise in many IPv6 transition > scenarios, where Network A, to which a host is attached, supports one > IP version, but the host and Network B support a different IP > version. Suppose that the host wishes to access a multicast group > which is rooted or sourced in Network B. This document specifies a > stateful translation mechanism whereby the host can obtain its > desired access using the native multicast capabilities of Network A. > > > > > The IETF Secretariat. > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --00163645890ece992c049a4a6374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

The scenarios proposed in Abs= tract are confusing, IPvx -> IPvy? It seems to conflict with later secti= ons in the draft.

On Mon, Jan 17, = 2011 at 10:00 PM, Tom Taylor <tom.taylor@huawei.com> wrote:
A Softwires versi= on of this document using encapsulation will be submitted shortly.

A new version of I-D, draft-tsou-behave-translated-multicast-00.txt has bee= n successfully submitted by Tom Taylor and posted to the IETF repository.
Filename: =A0 =A0 =A0 =A0draft-tsou-behave-translated-multicast
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 A Generic Approach to Multicast Translation In S= upport of IPv6 Transition
Creation_date: =A0 2011-01-17
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 9

Abstract:
Consider a situation which will arise in many IPv6 transition
scenarios, where Network A, to which a host is attached, supports one
IP version, but the host and Network B support a different IP
version. =A0Suppose that the host wishes to access a multicast group
which is rooted or sourced in Network B. This document specifies a
stateful translation mechanism whereby the host can obtain its
desired access using the native multicast capabilities of Network A.




The IETF Secretariat.




_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--00163645890ece992c049a4a6374-- From jacniq@gmail.com Thu Jan 20 09:25:11 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 290FF3A7150 for ; Thu, 20 Jan 2011 09:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsjOaelzO660 for ; Thu, 20 Jan 2011 09:25:10 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 7A0083A713A for ; Thu, 20 Jan 2011 09:25:09 -0800 (PST) Received: by eyd10 with SMTP id 10so432191eyd.31 for ; Thu, 20 Jan 2011 09:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tZ4Uo3HXXITMwTtRfaItiPAHrzLQ1gB5yXTGDXawoj0=; b=pJVb+C5Qwxmt4LGIzov47+cK4zBQ0Dlui32d2K/uI5il5vS/apIuZxBIHu+rPvKhkb v9WNopXTdYRsrSJmvnaONthLCx6LUJh80XINA34a+jGsLPhQazDAeo2Cmp5hkizx0edg VHOailL2HLG+DetvTw8P1mDM9+sB/KhXof9pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QdVwsC6lZviUJDSJrxOL2Ql0cwXEbBWPhYoCgnY0gMCCxFsiIlYdE46Is+TmNxbp9b ivcPdMlRVCf/dR3BinI8GrKz96313UxFH5JP0p96ZsHyrscw4HiINyM9Mik5VuYNt0wg wrhQEnd+xBHh4MDSwLIhCg6eDWv0lLpybcPXw= MIME-Version: 1.0 Received: by 10.216.17.204 with SMTP id j54mr4101488wej.32.1295544462383; Thu, 20 Jan 2011 09:27:42 -0800 (PST) Received: by 10.216.36.149 with HTTP; Thu, 20 Jan 2011 09:27:41 -0800 (PST) In-Reply-To: <037e01cbb834$6c5808b0$45081a10$@com> References: <037e01cbb834$6c5808b0$45081a10$@com> Date: Fri, 21 Jan 2011 01:27:41 +0800 Message-ID: From: Jacni Qin To: Dan Wing Content-Type: multipart/alternative; boundary=00163649a3e3789c2c049a4a7325 Cc: Tom Taylor , Tom Taylor , behave@ietf.org, jihui@chinatelecom.com.cn, Cathy Zhou , "Lee, Yiu" , Tina TSOU Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:25:11 -0000 --00163649a3e3789c2c049a4a7325 Content-Type: text/plain; charset=ISO-8859-1 Re-, On Thu, Jan 20, 2011 at 7:55 AM, Dan Wing wrote: > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Tom Taylor > > Sent: Wednesday, January 19, 2011 2:26 PM > > To: Lee, Yiu > > Cc: 'Tom Taylor'; behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy > > Zhou'; Dan Wing; 'Tina TSOU' > > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > > behave-translated-multicast-00 > > > > A softwire draft has been prepared, but I'd like to take up this point. > > It depends on why double mapping is bad. In this case, the second > > translation is simply the inverse of the first one. > > If it is a "lossless translation", that is, the same IP address > exists on both sides -- then the two translation functions are > equivalent to a tunnel and indistinguishable from a tunnel. The > term "inverse" is an accurate term for such a lossless > translation. > Jacni>: May be equivalent if it is the "lossless translation". :-) But not sure if the reconstructing of packets during the translations brings impacts. I'm trying to check this out while it is difficult in most cases, since many algorithms used for pretecting DRM, integrity are of property. Maybe someone can help. > However, the function described in draft-tsou-behave-translated-multicast > is not lossless -- the mapped address is chosen from a pool of > addresses. From Section 3.1 of draft-tsou-behave-translated-multicast: > Jacni>: Agree, the stateful translation specified in the document is not lossless. > ... > 2. Address Mapping At the HMAF > > The HMAF checks its cache of mappings to see if it already has a > mapping between the IPvx address pair received in the > host request and a corresponding pair of IPvy addresses. Failing to > find a mapping, it sends a request for the required mapping to the > mapping function. The mapping function in turn checks whether it has > already created the mapping. If not, it assigns unicast and > multicast IPvy addresses from its pool and records the mapping for > further use. > ... > > -d > > > > --00163649a3e3789c2c049a4a7325 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

On Thu, Jan 20, 2011 at 7:55 AM, Dan Wing <dwing@cisco.com> wrote:
> -----Original Message-----
> From: behave-bounces@ietf.o= rg [mailto:behave-bounces@ie= tf.org] On
> Behalf Of Tom Taylor
> Sent: Wednesday, January 19, 2011 2:26 PM
> To: Lee, Yiu
> Cc: 'Tom Taylor'; behave@ie= tf.org; jihui@chinatelecom= .com.cn; 'Cathy
> Zhou'; Dan Wing; 'Tina TSOU'
> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > behave-translated-multicast-00
>
> A softwire draft has been prepared, but I'= d like to take up this point.
> It depends on why double mapping is bad. In this case, the second
> translation is simply the inverse of the first one.

If it is a "lossless translation", that is, the same IP add= ress
exists on both sides -- then the two translation functions are
equivalent to a tunnel and indistinguishable from a tunnel. =A0The
term "inverse" is an accurate term for such a lossless
translation.

Jac= ni>: May be equivalent if it is the "lossless translation". :-= )
But not sure if the reconstructing of packets during the translations = brings impacts. I'm trying to check this out while it is difficult in m= ost cases, since many algorithms used for pretecting DRM, integrity are of = property. Maybe someone can help.


However, the function described in draft-tsou-behave-translated-multicast is not lossless -- the mapped address is chosen from a pool of
addresses. =A0From Section 3.1 of draft-tsou-behave-translated-multicast:

Jacni>: Agree,= the stateful translation specified in the document is not lossless.

...
=A0 2. <Source, Group> Address Mapping At the HMAF

=A0 The HMAF checks its cache of mappings to see if it already has a
=A0 mapping between the IPvx <Source, Group> address pair received i= n the
=A0 host request and a corresponding pair of IPvy addresses. =A0Failing to=
=A0 find a mapping, it sends a request for the required mapping to the
=A0 mapping function. =A0The mapping function in turn checks whether it ha= s
=A0 already created the mapping. =A0If not, it assigns unicast and
=A0 multicast IPvy addresses from its pool and records the mapping for
=A0 further use.
...

-d




--00163649a3e3789c2c049a4a7325-- From jacniq@gmail.com Thu Jan 20 09:29:10 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F613A7155 for ; Thu, 20 Jan 2011 09:29:10 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m15N6c-QMqwU for ; Thu, 20 Jan 2011 09:29:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E66763A703D for ; Thu, 20 Jan 2011 09:29:08 -0800 (PST) Received: by wwa36 with SMTP id 36so938255wwa.13 for ; Thu, 20 Jan 2011 09:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CZUPfNa3cmliyjbc9svDQASM3OSafjwz/C/m0M4dJoQ=; b=UKA4gp/qlcfcObu4zyTP6Pjap42R68IMWm09QAT6y01bEhfa1pT08aLzu6TznZyjwT y+m7HJyWlLr3AmL6ixAeK1HPDs32XwPUsXu/NKwjYJ3iTQISYyC7a9XRqCnhr93i61jM d1uMyzgm0h9vPVqCfLMmbCsTaFgzICQz+6UsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rxdkKTv7oTIKwpZ32eaAyBNEmc1guD3wu/EerLlZbT3mkI1q5IKVzJ2jNj3RKXoHij OSAEKENWv6NKWnwoW1RbWG2zwiia8aU1DjYtYS8dLHpxwA+g1yS63M1L6T2nyXBFzB83 WAqaXOba7pOKcvICY4edX0LvCX7I9jW6r3yW4= MIME-Version: 1.0 Received: by 10.216.176.142 with SMTP id b14mr2253638wem.32.1295544711726; Thu, 20 Jan 2011 09:31:51 -0800 (PST) Received: by 10.216.36.149 with HTTP; Thu, 20 Jan 2011 09:31:51 -0800 (PST) In-Reply-To: References: <037e01cbb834$6c5808b0$45081a10$@com> Date: Fri, 21 Jan 2011 01:31:51 +0800 Message-ID: From: Jacni Qin To: Tom Taylor Content-Type: multipart/alternative; boundary=0016e65842465548e8049a4a82c2 Cc: Tom Taylor , behave@ietf.org, jihui@chinatelecom.com.cn, Cathy Zhou , Dan Wing , "Lee, Yiu" , Tina TSOU Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:29:10 -0000 --0016e65842465548e8049a4a82c2 Content-Type: text/plain; charset=ISO-8859-1 Dear Tom, Sorry I don't follow the point, does the centrally controlled mapping make a difference? Cheers, Jacni On Thu, Jan 20, 2011 at 9:52 AM, Tom Taylor wrote: > The mapping is lossless. I think what we failed to make clear in the draft > is that the "Mapping Function" is a centralized entity. It could be > collocated with the border gateway, as one possibility (which I suspect has > problems), or it could be a standalone device. Thus the mapping the HMAF > receives from the Mapper (let's call it that) is the same mapping the BMAF > will receive when it in turn consults the Mapper. As a result, the second > translation will truly be an inversion, both for outgoing signalling and > incoming content. > > > >> >> _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --0016e65842465548e8049a4a82c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Tom,

Sorry I don't follow= the point, does the centrally controlled mapping make a difference?

Cheers,
Jacni

On Thu, Jan = 20, 2011 at 9:52 AM, Tom Taylor <tom111.taylor@bell.net> wrote:
The mapping is lo= ssless. I think what we failed to make clear in the draft is that the "= ;Mapping Function" is a centralized entity. It could be collocated wit= h the border gateway, as one possibility (which I suspect has problems), or= it could be a standalone device. Thus the mapping the HMAF receives from t= he Mapper (let's call it that) is the same mapping the BMAF will receiv= e when it in turn consults the Mapper. =A0As a result, the second translati= on will truly be an inversion, both for outgoing signalling and incoming co= ntent.




_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--0016e65842465548e8049a4a82c2-- From jacniq@gmail.com Thu Jan 20 09:31:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF983A7168 for ; Thu, 20 Jan 2011 09:31:20 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SINqA6vlRroh for ; Thu, 20 Jan 2011 09:31:19 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3791D3A7155 for ; Thu, 20 Jan 2011 09:31:19 -0800 (PST) Received: by wwa36 with SMTP id 36so940715wwa.13 for ; Thu, 20 Jan 2011 09:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tLCl4oQiciTirIxAfugflg1UE8ltwofCmN5eioqKGWo=; b=Od3Wer1VHlfD4Strud8TmT6LHL7FdNWcdO9bfAQCNgRJNn038hn3oL7nsrtgqc4RSO 5MmGPGObvtKLaV2D0k+h6iLxnPd3HpaXUg7aMmPSIRxtEV9m7rEaw4zVWMuiM0utPJeA ObgqdLle7P9OTuEGwUPBjzeNiCxyaotgUKO4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=luBr+wyaxJJTx4nUc3EVMfSbeYsoTNxrpweXFcQKpy0DjvsDuNY/3YrGsZmWI05fjq c8Q9Ha41ldE7L2g8oeyGGkRqN+Mvt8xfMMCTcAiBjwfyfh446jLY1rKfOkTnVHrrRsvv qkef7le2YkHwVxdipM156QuXBTd7+lIwTFblY= MIME-Version: 1.0 Received: by 10.216.176.142 with SMTP id b14mr2256797wem.32.1295544841950; Thu, 20 Jan 2011 09:34:01 -0800 (PST) Received: by 10.216.36.149 with HTTP; Thu, 20 Jan 2011 09:34:01 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Jan 2011 01:34:01 +0800 Message-ID: From: Jacni Qin To: Tom Taylor Content-Type: multipart/alternative; boundary=0016e6584246185805049a4a8ad5 Cc: "jihui@chinatelecom.com.cn" , Cathy Zhou , "behave@ietf.org" , Dan Wing , "Lee, Yiu" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:31:20 -0000 --0016e6584246185805049a4a8ad5 Content-Type: text/plain; charset=ISO-8859-1 Dear Tom, On Thu, Jan 20, 2011 at 11:41 AM, Tom Taylor wrote: > I think the Xu paper goes more deeply into the problem, by considering the > topology required to serve many multicast groups. We aren't trying to do > better than what PIM can accomplish. Jacni>: Can you please elaborate it, not sure I understand the sentence? Thanks. :-) Cheers, Jacni > > > On 19/01/2011 9:43 PM, Lee, Yiu wrote: > >> Is this similar to what draft-xu-softwire-mesh-multicast-00 tries to >> solve? >> >> >> On 1/19/11 8:54 PM, "Tom Taylor" wrote: >> >> Yes, that is precisely the assumption. I have in mind that Network B >>> does not necessarily have any relationship to the intermediate Network >>> A, so we're really contemplating a selection from the whole wide world, >>> not just the provider's own content sources. >>> >>> >> >> >> _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --0016e6584246185805049a4a8ad5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Tom,

On Thu, Jan 20, 2011 at 11:41 AM, Tom Taylor &l= t;tom111.taylor@bell.net><= /span> wrote:
I think the Xu pa= per goes more deeply into the problem, by considering the topology required= to serve many multicast groups. We aren't trying to do better than wha= t PIM can accomplish.

Jacni>: Can you please elabor= ate it, not sure I understand the sentence? Thanks. :-)


Cheers,<= br>Jacni
=A0


On 19/01/2011 9:43 PM, Lee, Yiu wrote:
Is this similar to what draft-xu-softwire-mesh-multicast-00 tries to
solve?


On 1/19/11 8:54 PM, "Tom Taylor"<tom111.taylor@bell.net> =A0wrote:

Yes, that is precisely the assumption. I have in mind that Network B
does not necessarily have any relationship to the intermediate Network
A, so we're really contemplating a selection from the whole wide world,=
not just the provider's own content sources.




_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--0016e6584246185805049a4a8ad5-- From jouni.nospam@gmail.com Thu Jan 20 10:50:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9ED3A7183 for ; Thu, 20 Jan 2011 10:50:10 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hsl79A1eMHXy for ; Thu, 20 Jan 2011 10:50:01 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 385043A7046 for ; Thu, 20 Jan 2011 10:50:01 -0800 (PST) Received: by ewy8 with SMTP id 8so492086ewy.31 for ; Thu, 20 Jan 2011 10:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=U+KfscaX3Dp7s+3HzYxehpcSErw8n4kZy03fQhnoNQM=; b=Cg16KExjIWFWFz8HQnTaifS6gIMpRSckhHf8k6bZNFdr34q+s+P3CBS1cMnvtsoVZ1 oM1pDrju89EwaqcZAipV6aMllLrYxK6z4me5ZxeiXAk+oyCxUSSlqiq4hOqXWOmKQkoW P2Mpo903gDhWlyd4R7Z4+4Q5ixmhqW6HYJfAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=TvxiVveuo+tu0lSBA2H84iwc01PecdfXk0EcZGQSMHw+p/RQfv2WC7iB9+IiMbsvDh iMvM+sgsIsrQuvXGJDDo6jMFD2y6IxgCjt6fu/38ntK7mk+XM7P9UD5lZO7j+xmu/W8E 5IEKiuzyMZLtR0l4a4KTCtw8RnWkAfAlb42fw= Received: by 10.14.37.138 with SMTP id y10mr2891655eea.43.1295549543853; Thu, 20 Jan 2011 10:52:23 -0800 (PST) Received: from [10.0.3.137] (217.64.252.30.mactelecom.net [217.64.252.30]) by mx.google.com with ESMTPS id t12sm406723eeh.3.2011.01.20.10.52.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Jan 2011 10:52:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: jouni korhonen In-Reply-To: <07F70959-3C2E-43DD-90E5-7654B3FA69AF@gmail.com> Date: Thu, 20 Jan 2011 20:52:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110119180002.20059.62443.idtracker@localhost> <07F70959-3C2E-43DD-90E5-7654B3FA69AF@gmail.com> To: "'behave' (behave@ietf.org)" X-Mailer: Apple Mail (2.1078) Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 18:50:16 -0000 Heck.. I must have been eating bad mushrooms or something today ;) My = "notification" was meant for a completely different draft. Sorry for the = confusion.. - Jouni On Jan 20, 2011, at 2:48 PM, jouni korhonen wrote: > Folks, >=20 > We have (finally) updated the I-D. Sorry that it took slightly longer = than planned. This version should address Dave's comments and the = feedback we received in Beijing. Comments and feedback is solicited. >=20 > - Jouni >=20 >=20 > On Jan 19, 2011, at 8:00 PM, Internet-Drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. >>=20 >>=20 >> Title : Analysis of 64 Translation >> Author(s) : R. Penno, et al. >> Filename : draft-ietf-behave-64-analysis-00.txt >> Pages : 14 >> Date : 2011-01-18 >>=20 >> Due to specific problems, NAT-PT was deprecated by the IETF as a >> mechanism to perform IPv6-IPv4 translation. Since then, new efforts >> have been undertaken within IETF to standardize alternative >> mechanisms to perform IPv6-IPv4 translation. This document evaluates >> how the new translation mechanisms avoid the problems that caused the >> IETF to deprecate NAT-PT. >>=20 From tom111.taylor@bell.net Thu Jan 20 21:08:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F663A68B8 for ; Thu, 20 Jan 2011 21:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.753 X-Spam-Level: X-Spam-Status: No, score=-101.753 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN2A7akD1YNs for ; Thu, 20 Jan 2011 21:08:22 -0800 (PST) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by core3.amsl.com (Postfix) with ESMTP id B9B513A68B7 for ; Thu, 20 Jan 2011 21:08:22 -0800 (PST) Received: from BLU0-SMTP86 ([65.55.116.73]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:11:07 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP86.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:11:07 -0800 Date: Fri, 21 Jan 2011 00:11:14 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <4D344B88.90708@huawei.com> <00f701cbb80c$01301dc0$03905940$@com> <037f01cbb835$382509c0$a86f1d40$@com> <041a01cbb84a$8f329a60$ad97cf20$@com> <099201cbb8bc$838ab860$8aa02920$@com> In-Reply-To: <099201cbb8bc$838ab860$8aa02920$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2011 05:11:07.0435 (UTC) FILETIME=[9C2047B0:01CBB929] Cc: jihui@chinatelecom.com.cn, behave@ietf.org, 'Cathy Zhou' Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 05:08:23 -0000 Not sure what this means. Are you saying a 4-6-4 scenario won't happen, or simply that an IPv4 user requesting connection to a multicast channel may get a surprise if an IPv4 network nearer the user than the intended one uses the same multicast address? On 20/01/2011 11:10 AM, Dan Wing wrote: >> -----Original Message----- >> From: Tom Taylor [mailto:tom111.taylor@bell.net] >> Sent: Wednesday, January 19, 2011 7:22 PM >> To: Dan Wing >> Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' >> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >> behave-translated-multicast-00 >> >> I'm not sure I follow. I'm an IPv4 user attached to an IPv6 network. I >> want to listen to a multicast of an IETF meeting. Are you saying there >> will be an address conflict? > > * Multicast does not generally exist on the IPv4 Internet. Yes, I know > that a few times a year an organization called the IETF has a week-long > multicast feed. > * Multicast generally exists within private networks, which assign their > own multicast IPv4 addresses to whatever streams they like. > * A network, such as an ISP's network, cannot successfully interconnect > their multicast network with "the whole wide world" because of that > IPv4 multicast address overlap. > > -d > > >> On 19/01/2011 9:34 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>> Sent: Wednesday, January 19, 2011 5:55 PM >>>> To: Dan Wing >>>> Cc: behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy Zhou' >>>> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >>>> behave-translated-multicast-00 >>>> >>>> Yes, that is precisely the assumption. I have in mind that Network B >>>> does not necessarily have any relationship to the intermediate >> Network >>>> A, so we're really contemplating a selection from the whole wide >> world, >>>> not just the provider's own content sources. >>> >>> But that can only work with IPv6 receivers, otherwise there will be >>> IPv4 conflicts with the IPv4 multicast space (exactly the same as >> IPv4 >>> conflicts with RFC1918 space). And there also isn't IPv4 on the >>> Internet (the whole world) which does not appear to be changing with >>> IPv6. >>> >>> -d >> ... > > > From tom111.taylor@bell.net Thu Jan 20 21:11:24 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37A13A68BB for ; Thu, 20 Jan 2011 21:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.459 X-Spam-Level: X-Spam-Status: No, score=-101.459 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzYI+nGNghUt for ; Thu, 20 Jan 2011 21:11:19 -0800 (PST) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by core3.amsl.com (Postfix) with ESMTP id 77D6B3A68B7 for ; Thu, 20 Jan 2011 21:11:18 -0800 (PST) Received: from BLU0-SMTP76 ([65.55.116.74]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:14:03 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP76.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:14:02 -0800 Date: Fri, 21 Jan 2011 00:14:10 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jacni Qin References: <037e01cbb834$6c5808b0$45081a10$@com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2011 05:14:02.0916 (UTC) FILETIME=[04B88E40:01CBB92A] Cc: Tom Taylor , behave@ietf.org, jihui@chinatelecom.com.cn, Cathy Zhou , Dan Wing , "Lee, Yiu" , Tina TSOU Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 05:11:25 -0000 I assure you, the mapping is lossless. One thing the whole discussion makes clear: we'd better add some numerical examples to the document to make it easier for people to see what is going on. On 20/01/2011 12:27 PM, Jacni Qin wrote: > Re-, > > On Thu, Jan 20, 2011 at 7:55 AM, Dan Wing wrote: > >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of Tom Taylor >>> Sent: Wednesday, January 19, 2011 2:26 PM >>> To: Lee, Yiu >>> Cc: 'Tom Taylor'; behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy >>> Zhou'; Dan Wing; 'Tina TSOU' >>> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >>> behave-translated-multicast-00 >>> >>> A softwire draft has been prepared, but I'd like to take up this point. >>> It depends on why double mapping is bad. In this case, the second >>> translation is simply the inverse of the first one. >> >> If it is a "lossless translation", that is, the same IP address >> exists on both sides -- then the two translation functions are >> equivalent to a tunnel and indistinguishable from a tunnel. The >> term "inverse" is an accurate term for such a lossless >> translation. >> > > Jacni>: May be equivalent if it is the "lossless translation". :-) > But not sure if the reconstructing of packets during the translations brings > impacts. I'm trying to check this out while it is difficult in most cases, > since many algorithms used for pretecting DRM, integrity are of property. > Maybe someone can help. > > >> However, the function described in draft-tsou-behave-translated-multicast >> is not lossless -- the mapped address is chosen from a pool of >> addresses. From Section 3.1 of draft-tsou-behave-translated-multicast: >> > > Jacni>: Agree, the stateful translation specified in the document is not > lossless. > > >> ... >> 2. Address Mapping At the HMAF >> >> The HMAF checks its cache of mappings to see if it already has a >> mapping between the IPvx address pair received in the >> host request and a corresponding pair of IPvy addresses. Failing to >> find a mapping, it sends a request for the required mapping to the >> mapping function. The mapping function in turn checks whether it has >> already created the mapping. If not, it assigns unicast and >> multicast IPvy addresses from its pool and records the mapping for >> further use. >> ... >> >> -d >> >> >> >> > From tom111.taylor@bell.net Thu Jan 20 21:12:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044063A68BE for ; Thu, 20 Jan 2011 21:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wtd23gkN3Ej7 for ; Thu, 20 Jan 2011 21:12:21 -0800 (PST) Received: from blu0-omc1-s18.blu0.hotmail.com (blu0-omc1-s18.blu0.hotmail.com [65.55.116.29]) by core3.amsl.com (Postfix) with ESMTP id CA98F3A68BB for ; Thu, 20 Jan 2011 21:12:21 -0800 (PST) Received: from BLU0-SMTP55 ([65.55.116.9]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:15:06 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP55.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:15:06 -0800 Date: Fri, 21 Jan 2011 00:15:13 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jacni Qin References: <037e01cbb834$6c5808b0$45081a10$@com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2011 05:15:06.0446 (UTC) FILETIME=[2A9676E0:01CBB92A] Cc: Tom Taylor , behave@ietf.org, jihui@chinatelecom.com.cn, Cathy Zhou , Dan Wing , "Lee, Yiu" , Tina TSOU Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 05:12:23 -0000 It ensures that the HMAF and BMAF receive the same mapping, thus ensuring that one performs the inverse translation relative to the other. On 20/01/2011 12:31 PM, Jacni Qin wrote: > Dear Tom, > > Sorry I don't follow the point, does the centrally controlled mapping make a > difference? > > > Cheers, > Jacni > > On Thu, Jan 20, 2011 at 9:52 AM, Tom Taylor wrote: > >> The mapping is lossless. I think what we failed to make clear in the draft >> is that the "Mapping Function" is a centralized entity. It could be >> collocated with the border gateway, as one possibility (which I suspect has >> problems), or it could be a standalone device. Thus the mapping the HMAF >> receives from the Mapper (let's call it that) is the same mapping the BMAF >> will receive when it in turn consults the Mapper. As a result, the second >> translation will truly be an inversion, both for outgoing signalling and >> incoming content. >> >> >> >>> >>> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tom111.taylor@bell.net Thu Jan 20 21:14:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634303A68BB for ; Thu, 20 Jan 2011 21:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.736 X-Spam-Level: X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttTUbQSTsVpo for ; Thu, 20 Jan 2011 21:14:22 -0800 (PST) Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by core3.amsl.com (Postfix) with ESMTP id 59C163A68B7 for ; Thu, 20 Jan 2011 21:14:22 -0800 (PST) Received: from BLU0-SMTP22 ([65.55.116.7]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:17:07 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP22.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 21:17:06 -0800 Date: Fri, 21 Jan 2011 00:17:14 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jacni Qin References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2011 05:17:06.0535 (UTC) FILETIME=[722A9770:01CBB92A] Cc: "jihui@chinatelecom.com.cn" , Cathy Zhou , "behave@ietf.org" , Dan Wing , "Lee, Yiu" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 05:14:23 -0000 PIM deals with one multicast group at a time. The Xu paper tries to define a structure to deal with all the multicast groups that a network might carry. On 20/01/2011 12:34 PM, Jacni Qin wrote: > Dear Tom, > > On Thu, Jan 20, 2011 at 11:41 AM, Tom Taylor wrote: > >> I think the Xu paper goes more deeply into the problem, by considering the >> topology required to serve many multicast groups. We aren't trying to do >> better than what PIM can accomplish. > > > Jacni>: Can you please elaborate it, not sure I understand the sentence? > Thanks. :-) > > > Cheers, > Jacni > > >> >> >> On 19/01/2011 9:43 PM, Lee, Yiu wrote: >> >>> Is this similar to what draft-xu-softwire-mesh-multicast-00 tries to >>> solve? >>> >>> >>> On 1/19/11 8:54 PM, "Tom Taylor" wrote: >>> >>> Yes, that is precisely the assumption. I have in mind that Network B >>>> does not necessarily have any relationship to the intermediate Network >>>> A, so we're really contemplating a selection from the whole wide world, >>>> not just the provider's own content sources. >>>> >>>> >>> >>> >>> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From jouni.nospam@gmail.com Fri Jan 21 00:13:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D083A68E9 for ; Fri, 21 Jan 2011 00:13:49 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdvvEew1qDcI for ; Fri, 21 Jan 2011 00:13:47 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4863D3A68E0 for ; Fri, 21 Jan 2011 00:13:47 -0800 (PST) Received: by ewy8 with SMTP id 8so798302ewy.31 for ; Fri, 21 Jan 2011 00:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=mxN9xNzCfzbTRcoRosIcClRU+J4FX8JDJ592/WrUHHg=; b=ryKkVNluB2zhbB8F7U3zapIQ8BTGvtWv5RUx8c7MW4kkk4Y+GQ4J9Z5SUMzAkL1IH5 5r1PFf4TldTxDHijdi0ruHJHYL94xnnR727uoDpMuVH8Llu0k9403MBJX9o5Y0VWKb6K wB4enwVsJ5MJWax4DRFF1SYbyZY2q9JQsOXF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=hMQhFdX7WmhLdRsuuB/qKVpXBELkXEgQbi6tFNg42RiYwKLmrnOXgM4y4O/VeBdW5i rjUl6mYSlG9mOGGPnJVc9xZ9IK5pMxHY/jXeLGqNCe9/3rxwaQckqWGqjTGf87I2HL2r 0Niqe/wkGHnblzLpoe4/f0rUBsAoyMmjaprRk= Received: by 10.213.29.210 with SMTP id r18mr418076ebc.62.1295597792018; Fri, 21 Jan 2011 00:16:32 -0800 (PST) Received: from [192.168.141.77] ([213.246.198.210]) by mx.google.com with ESMTPS id t50sm7291542eeh.0.2011.01.21.00.16.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 00:16:30 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jan 2011 10:16:28 +0200 References: <20110120104501.23103.95922.idtracker@localhost> To: "'behave' (behave@ietf.org)" Message-Id: <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 08:13:49 -0000 Folks, Now citing a proper I-D ;-) We have (finally) updated the analysis I-D. = Sorry that it took somewhat longer than planned. This version should = address Dave's comments and the feedback we received in Beijing. = Comments and feedback is solicited. - Jouni Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: January 20, 2011 12:45:01 PM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Analysis of solution proposals for hosts to = learn NAT64 prefix > Author(s) : J. Korhonen, T. Savolainen > Filename : = draft-korhonen-behave-nat64-learn-analysis-01.txt > Pages : 25 > Date : 2011-01-20 >=20 From simon.perreault@viagenie.ca Fri Jan 21 06:07:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0C728C0D9 for ; Fri, 21 Jan 2011 06:07:38 -0800 (PST) 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.078, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzQLtCoc580X for ; Fri, 21 Jan 2011 06:07:37 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 016EB28C0D6 for ; Fri, 21 Jan 2011 06:07:37 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6CF9920DC2; Fri, 21 Jan 2011 09:10:22 -0500 (EST) Message-ID: <4D3993CD.90309@viagenie.ca> Date: Fri, 21 Jan 2011 09:10:21 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: jouni korhonen References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> In-Reply-To: <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'behave' \(behave@ietf.org\)" Subject: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:07:38 -0000 I'm very happy to see that this new version addresses the issue of multiple prefixes. Here are some specific comments on this issue... This text appears in a few sections: > + Can partially solve issue #5 if multiple synthetic AAAA records > are included in the response and all use same format. I don't understand this. For the load-balancing use-case I have in mind, the DNS64 will pick just one of the prefixes and use it for the synthesis. It will not use all of them for constructing the answer section. So a client cannot determine whether there is a single prefix or many just by looking at the DNS answer section. There is also: > - This method is only able to find one NSP even if a network is > utilizing multiple NSPs (issue #5) (unless DNS64 includes multiple > synthetic AAAA records in response). This seems to contradict the previous quotation. Section 4.4 (on the A64 record) says: > + Can be used to solve Issue #1 and #5. Could you please explain how it solves issue #5? Section 4.6 (on DHCPv6) says: > If DHCPv6 would include multiple NSPs issue #5 could be solved as > well, but only if nodes as a group would select different NSPs hence > supporting load-balancing. As this is not clear this item is not yet > listed under PRO nor CON. (There is similar text in section 4.7 (on RAs).) I disagree with this viewpoint. The DNS64 server would still be responsible for load-balancing because it would be used for the vast majority of cases. As long as the host is able to recognize all the prefixes, and picks one prefix when it needs to initiate connections (e.g. to IPv4 literals), we're fine. It wouldn't be the end of the world if a host would always pick the same prefix because we're assuming that the DNS would be used for the vast majority of cases. Furthermore, the DHCPv6 server could assist by e.g. randomizing the prefixes it gives out so that even client implementations that always pick the first prefix would tend to use all prefixes equally (considering a large client population). Another viewpoint would be to consider the DHCPv6 server itself as responsible for load balancing, assigning a single prefix to each client according to a load-balancing algorithm. Each client would always use the same prefix, and therefore would not need to know about the other prefixes. So I think it would be correct to say that DHCPv6 and RAs do solve issue #5 satisfactorily. Section 5 (Conclusion) says: > Issue #5 is considered to be mostly insignificant as > even if individual hosts would use only one NSP at a time, different > hosts would be using different NSPs, hence supporting load-balancing > targets. I agree on the load-balancing issue, but I think this is missing the point. If a host does not know about all prefixes, how can it achieve issue #1? In other words, how can it recognize synthetic addresses using prefixes it does not know about? I see solving issue #5 as a prerequisite to solving #1. 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 mohamed.boucadair@orange-ftgroup.com Fri Jan 21 06:28:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059243A69A5 for ; Fri, 21 Jan 2011 06:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1vsVleyLAbf for ; Fri, 21 Jan 2011 06:28:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id A5FBA3A695C for ; Fri, 21 Jan 2011 06:28:10 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id C84903B440D; Fri, 21 Jan 2011 15:30:55 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AF209238062; Fri, 21 Jan 2011 15:30:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 21 Jan 2011 15:30:55 +0100 From: To: jouni korhonen Date: Fri, 21 Jan 2011 15:30:53 +0100 Thread-Topic: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt Thread-Index: Acu5Q4rwLZFOCFd+ThCw4GYCFBUx5wAM1A5Q Message-ID: <3287_1295620255_4D39989F_3287_77487_1_94C682931C08B048B7A8645303FDC9F33C413CE542@PUEXCB1B.nanterre.francetelecom.fr> References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> In-Reply-To: <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.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.1.21.135416 Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:28:12 -0000 Hi Jouni, It would useful if you provide in the I-D more elaboration why the followin= g points are considered as "issues"; " Issue #4 The problem of supporting changing NSP. Issue #5 The problem of supporting multiple NSPs." Do you have in mind load-balancing scenarios as what is described in Sectio= n 6.2 of http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing= -00? Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= jouni korhonen Envoy=E9 : vendredi 21 janvier 2011 09:16 =C0 : 'behave' (behave@ietf.org) Objet : [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis= -01.txt Folks, Now citing a proper I-D ;-) We have (finally) updated the analysis I-D. Sor= ry that it took somewhat longer than planned. This version should address D= ave's comments and the feedback we received in Beijing. Comments and feedba= ck is solicited. - Jouni Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: January 20, 2011 12:45:01 PM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : Analysis of solution proposals for hosts to learn NAT6= 4 prefix > Author(s) : J. Korhonen, T. Savolainen > Filename : draft-korhonen-behave-nat64-learn-analysis-01.txt > Pages : 25 > Date : 2011-01-20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From dwing@cisco.com Fri Jan 21 07:53:54 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DD13A6A29 for ; Fri, 21 Jan 2011 07:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbEMfYD4t6Ai for ; Fri, 21 Jan 2011 07:53:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 032673A6A24 for ; Fri, 21 Jan 2011 07:53:54 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACI7OU2rR7Ht/2dsb2JhbACXbox3c6JVmxmFUASEbw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 21 Jan 2011 15:56:40 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0LFuebA029572; Fri, 21 Jan 2011 15:56:40 GMT From: "Dan Wing" To: "'Simon Perreault'" , "'jouni korhonen'" References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> <4D3993CD.90309@viagenie.ca> In-Reply-To: <4D3993CD.90309@viagenie.ca> Date: Fri, 21 Jan 2011 07:56:39 -0800 Message-ID: <101f01cbb983$caa338e0$5fe9aaa0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu5dPga+LGsMthHTz2GivGEtH4xFgADhsaw Content-Language: en-us Cc: ''behave'' Subject: Re: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 15:53:54 -0000 ... > I disagree with this viewpoint. The DNS64 server would still be > responsible for load-balancing because it would be used for the vast > majority of cases. As long as the host is able to recognize all the > prefixes, and picks one prefix when it needs to initiate connections > (e.g. to IPv4 literals), we're fine. It wouldn't be the end of the > world > if a host would always pick the same prefix because we're assuming that > the DNS would be used for the vast majority of cases. You're right, for today's networks. But in the future the hosts will do their own DNSSEC validation and (thus) their own DNS64 synthesis. At that point in the future, the load balancing is done by the host and how it learned the prefix(es), and is no longer done by the DNS64. Of course, that future is years away. With that in mind, the solutions you suggested in the next two paragraphs seem good suggestions for a solution document: > Furthermore, the DHCPv6 server could assist by e.g. randomizing the > prefixes it gives out so that even client implementations that always > pick the first prefix would tend to use all prefixes equally > (considering a large client population). > > Another viewpoint would be to consider the DHCPv6 server itself as > responsible for load balancing, assigning a single prefix to each > client > according to a load-balancing algorithm. Each client would always use > the same prefix, and therefore would not need to know about the other > prefixes. > > So I think it would be correct to say that DHCPv6 and RAs do solve > issue #5 satisfactorily. -d From huitema@microsoft.com Fri Jan 21 11:30:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD8C28C0E4 for ; Fri, 21 Jan 2011 11:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np4tWlelXjmo for ; Fri, 21 Jan 2011 11:30:45 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 05E563A67B8 for ; Fri, 21 Jan 2011 11:30:44 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 11:33:25 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.255.3; Fri, 21 Jan 2011 11:33:24 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 21 Jan 2011 11:33:24 -0800 From: Christian Huitema To: Dan Wing , 'Simon Perreault' , 'jouni korhonen' Thread-Topic: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt) Thread-Index: AQHLuYP6sEF4nAWWZkSw4C8FOEUk0pPbz8KQ Date: Fri, 21 Jan 2011 19:33:22 +0000 Message-ID: References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> <4D3993CD.90309@viagenie.ca> <101f01cbb983$caa338e0$5fe9aaa0$@com> In-Reply-To: <101f01cbb983$caa338e0$5fe9aaa0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ''behave'' Subject: Re: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 19:30:46 -0000 > You're right, for today's networks. But in the future the hosts will=20 > do their own DNSSEC validation and (thus) their own DNS64 synthesis. =20 > At that point in the future, the load balancing is done by the host and=20 > how it learned the prefix(es), and is no longer done by the DNS64. > > Of course, that future is years away. I don't think it is years away. I have worked with various implementations = of instant messaging, VoIP, or distributed games. They all have dedicated s= oftware modules for NAT and firewall traversal. They do ICE, UPNP, and all = kinds of other tricks. They will indeed incorporate prefix discovery as soo= n as NAT64 gets deployed in the network. It will certainly not take "years.= " -- Christian Huitema From dwing@cisco.com Fri Jan 21 12:43:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E6F3A6802 for ; Fri, 21 Jan 2011 12:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTHuVk-fb7mO for ; Fri, 21 Jan 2011 12:43:17 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DACE73A67FB for ; Fri, 21 Jan 2011 12:43:15 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJJ/OU2rR7H+/2dsb2JhbACXc4x3c6FYmxeFUASEbw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 21 Jan 2011 20:46:02 +0000 Received: from dwingWS ([128.107.106.236]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0LKk2cx020015; Fri, 21 Jan 2011 20:46:02 GMT From: "Dan Wing" To: "'Christian Huitema'" , "'Simon Perreault'" , "'jouni korhonen'" References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> <4D3993CD.90309@viagenie.ca> <101f01cbb983$caa338e0$5fe9aaa0$@com> In-Reply-To: Date: Fri, 21 Jan 2011 12:46:02 -0800 Message-ID: <11f401cbb9ac$37888b40$a699a1c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLuYP6sEF4nAWWZkSw4C8FOEUk0pPbz8KQgAAVS/A= Content-Language: en-us Cc: ''behave'' Subject: Re: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 20:43:17 -0000 > -----Original Message----- > From: Christian Huitema [mailto:huitema@microsoft.com] > Sent: Friday, January 21, 2011 11:33 AM > To: Dan Wing; 'Simon Perreault'; 'jouni korhonen' > Cc: ''behave'' > Subject: RE: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D > Action:draft-korhonen-behave-nat64-learn-analysis-01.txt) > > > You're right, for today's networks. But in the future the hosts will > > do their own DNSSEC validation and (thus) their own DNS64 synthesis. > > At that point in the future, the load balancing is done by the host > and > > how it learned the prefix(es), and is no longer done by the DNS64. > > > > Of course, that future is years away. > > I don't think it is years away. I have worked with various > implementations of instant messaging, VoIP, or distributed games. They > all have dedicated software modules for NAT and firewall traversal. > They do ICE, UPNP, and all kinds of other tricks. They will indeed > incorporate prefix discovery as soon as NAT64 gets deployed in the > network. It will certainly not take "years." What about DNSSEC validation on the host? It's only after DNS64 and DNSSEC validation on the host are both deployed that it becomes necessary for the host to take on all of the DNS64 functions itself. Prior to that, DNS64 (and DNSSEC validation) can be done by a DNS64 device in the network. -d From cb.list6@gmail.com Sat Jan 22 20:00:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2F43A6AB0 for ; Sat, 22 Jan 2011 20:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6zmPBGhk6pb for ; Sat, 22 Jan 2011 20:00:22 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 5B0093A67F4 for ; Sat, 22 Jan 2011 20:00:22 -0800 (PST) Received: by qyk34 with SMTP id 34so1804968qyk.10 for ; Sat, 22 Jan 2011 20:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fpeZHsGiVlwhHveqZDdKsrOsAMEriM/uMbsMqf/+wjY=; b=ucQJ7yLtvvRSl6LD7GBoiLBIUE9+P2BAL1fYZIIuAc2n01TYvq5X1mHvEAjj2+DiSa 3q0RlNnVzSHd1BhfxqtsGHCd2ap9clIGWO533yyIHJEgLd+abk5vC6lRrdO+JNYZNDVt tjPct9s9ODZe8vvwe7cCEM9YQNg33Rwr1bpYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O3c9W6n6jCIKDziP6s1mp6LdecK8ZKK8RSzTmurcKsp/XYcG17NzCxNVqJNox4gva8 nCAE8f54TqBmVGbWuMPApJ6LxA9oE408Kd2YuVukK5ntb9cXBEWYM3pNqwnNYlSGLguI HXpNCP/2oFfmOXVqcs/BWm4mSn/NTcgIrlBMg= MIME-Version: 1.0 Received: by 10.229.218.210 with SMTP id hr18mr2257316qcb.220.1295755392638; Sat, 22 Jan 2011 20:03:12 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sat, 22 Jan 2011 20:03:12 -0800 (PST) In-Reply-To: <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> Date: Sat, 22 Jan 2011 20:03:12 -0800 Message-ID: From: Cameron Byrne To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 04:00:23 -0000 "Firstly, finding out whether a particular address is synthetic and therefore learning the presence of a NAT64. For example, a Dual- Stack (DS) host with IPv4 connectivity could use this information to bypass NAT64 and use native IPv4 transport for destinations that are reachable through IPv4. We will refer this as 'Issue #1' throughout the document." Do we believe this will be a common case, where there is a dual-stack network with DNS64 in it? It is not covered in draft-ietf-behave-v6v4-framework or draft-arkko-ipv6-transition-guidelines. Not to say it won't happen, but is this design that is likely to happen and needs consideration here? Section 3 references SDP and SIP using IP literals, they may also use FQDNs, so they may not be the best example. In this sense, they are just like HTTP or FTP, which may use literals and FQDNs. I am not sure what issue #5 is. Can you provide more clarification? I plan on having many NSPs in my network, but i plan on users only have a view of one. AFAIK, NSP = PREF64, and there is a tight coupling of PREF64 and NAT64 system. So, there is a tight coupling between NSP and a NAT64 system. The load balancing i prefer is based on the DNS64 having access to multiple NAT64 systems for load balancing traffic to them via control of the NSP/PREF64 that a client has access to. But, there is a requirement that the client alway have the same NSP/PREF64 so that the users has a "sticky" public IP that represents the IPv6 client via the NAT64 to the IPv4 internet. Things break when the user is represented by multiple public IPv4 address across TCP sessions (VPNs ....) I prefer "4.3. DNS Query for a Well-Known Name" since it can be deployed today. A lot of the appeal about DNS64 and NAT64 is that end systems don't have impacts and the solution can be gracefully put in place without much fiddling or new standards work. I believe the EDNS0 solutions require modifying the end systems and thus spoils some of the benefits of the NAT64 based solutions. Another option not captured is the manual PREF64 configuration. The NAT46 implementation here uses that today http://code.google.com/p/n900ipv6/wiki/Nat64D Generally for this solution of dealing with literals, it is perhaps beneficial to state some guidance that the application can just attempt to use the WKP if nothing else works. I think it is also reasonable to have guidance that /96 NSP prefixes will be easier to derive with the heuristic method and therefor network operators should generally use them as opposed to the other size prefixes. Cameron From Internet-Drafts@ietf.org Sun Jan 23 12:30:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F023A6973; Sun, 23 Jan 2011 12:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLcZFwb5-5TU; Sun, 23 Jan 2011 12:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773B83A6949; Sun, 23 Jan 2011 12:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110123203002.26726.93478.idtracker@localhost> Date: Sun, 23 Jan 2011 12:30:02 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Author(s) : B. Huang, et al. Filename : draft-ietf-behave-v4v6-bih-02.txt Pages : 24 Date : 2011-01-23 Bump-In-the-Host (BIH) is a host based IPv4 to IPv6 protocol translation mechanism that allows class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host applications are running on may be connected to IPv6-only or dual- stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthetization of A records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v4v6-bih-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-23122916.I-D@ietf.org> --NextPart-- From teemu.savolainen@nokia.com Sun Jan 23 12:32:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4543A6989 for ; Sun, 23 Jan 2011 12:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eolRD1nIXzuJ for ; Sun, 23 Jan 2011 12:32:09 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id ADAAB3A6932 for ; Sun, 23 Jan 2011 12:32:06 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0NKYwLW027783 for ; Sun, 23 Jan 2011 22:34:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 23 Jan 2011 22:34:53 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 23 Jan 2011 21:34:52 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.27]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Sun, 23 Jan 2011 21:34:52 +0100 From: To: Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-02.txt Thread-Index: AQHLuzy9NojWnDr/cUu+la8ARz0u1pPfAxcQ Date: Sun, 23 Jan 2011 20:34:51 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A319281EDC@008-AM1MPN1-015.mgdnok.nokia.com> References: <20110123203002.26726.93478.idtracker@localhost> In-Reply-To: <20110123203002.26726.93478.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jan 2011 20:34:53.0257 (UTC) FILETIME=[FD510B90:01CBBB3C] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:32:10 -0000 Behave, Here is -02 iteration of BIH. Comments to modified section 1. Introduction = are most expected, but please feel free to provide comments and improvement= suggestions for other sections as well. Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext Internet-Drafts@ietf.org > Sent: 23. tammikuuta 2011 22:30 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. >=20 >=20 > Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) > Author(s) : B. Huang, et al. > Filename : draft-ietf-behave-v4v6-bih-02.txt > Pages : 24 > Date : 2011-01-23 >=20 > Bump-In-the-Host (BIH) is a host based IPv4 to IPv6 protocol > translation mechanism that allows class of IPv4-only applications that > work through NATs to communicate with IPv6-only peers. The host > applications are running on may be connected to IPv6-only or dual- > stack access networks. BIH hides IPv6 and makes the IPv4-only > applications think they are talking with IPv4 peers by local > synthetization of A records. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From simon.perreault@viagenie.ca Sun Jan 23 12:51:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6781A3A697E for ; Sun, 23 Jan 2011 12:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNgnRYs+P40W for ; Sun, 23 Jan 2011 12:51:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1EE8A3A6932 for ; Sun, 23 Jan 2011 12:51:19 -0800 (PST) Received: from [IPv6:2001:470:1f11:783:9868:c412:591:6f86] (unknown [IPv6:2001:470:1f11:783:9868:c412:591:6f86]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 004C520D21; Sun, 23 Jan 2011 15:54:10 -0500 (EST) Message-ID: <4D3C9571.7090403@viagenie.ca> Date: Sun, 23 Jan 2011 15:54:09 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Cameron Byrne References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jouni korhonen , "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:51:21 -0000 On 2011-01-22 23:03, Cameron Byrne wrote: > I prefer "4.3. DNS Query for a Well-Known Name" since it can be > deployed today. A lot of the appeal about DNS64 and NAT64 is that end > systems don't have impacts and the solution can be gracefully put in > place without much fiddling or new standards work. I believe the > EDNS0 solutions require modifying the end systems and thus spoils some > of the benefits of the NAT64 based solutions. Well, if you want the host to use the learned prefix for anything useful, you need to add code on the host. Therefore, all proposed solution need to modify the host, and could be considered equivalent on this aspect. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jouni.nospam@gmail.com Sun Jan 23 13:24:15 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7069A3A6998 for ; Sun, 23 Jan 2011 13:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 926qw7XZ3go6 for ; Sun, 23 Jan 2011 13:24:14 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 044BB3A6990 for ; Sun, 23 Jan 2011 13:24:13 -0800 (PST) Received: by fxm9 with SMTP id 9so3734881fxm.31 for ; Sun, 23 Jan 2011 13:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Jey/kpldArQ7xhYmSZMU0Hz6vlBoHi+x9idn6J33BhY=; b=kefw/39hrKialkoac3jkj1LRVcFPLtRmOTg7IQoqnpbuy5WlpSp0CM9wCwdikT6PDe jNLfEfHh5brWtHPWlAof9GFTbx11RhWrnsziUjZ8qBFOZKLrOQg2VlZbHlQcbwmwkb7d AAB8fkNu7zYCUtgTYQwcqy0OygYDK+Z7kCCWM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=RxhnVDqYbO3KWhxwDAS7kqwJ6g44H0wCc3ONOBAXqzp+UlwvfUv6FQW2leZSVXZ1XQ FRhZK0ho4tEnLlbNeSBKDT8W7MQWhlppNmhPEUmnXS9iIQIE0UXJx8xpTOGZQq8du9pY cXxYXUv5QKWXPshVRjoiOKZWXatIl/DEwqDi0= Received: by 10.103.214.6 with SMTP id r6mr975420muq.0.1295818024334; Sun, 23 Jan 2011 13:27:04 -0800 (PST) Received: from a88-114-173-187.elisa-laajakaista.fi (a88-114-173-187.elisa-laajakaista.fi [88.114.173.187]) by mx.google.com with ESMTPS id l3sm631057fan.0.2011.01.23.13.27.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Jan 2011 13:27:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <3287_1295620255_4D39989F_3287_77487_1_94C682931C08B048B7A8645303FDC9F33C413CE542@PUEXCB1B.nanterre.francetelecom.fr> Date: Sun, 23 Jan 2011 23:26:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> <3287_1295620255_4D39989F_3287_77487_1_94C682931C08B048B7A8645303FDC9F33C413CE542@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1078) Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 21:24:15 -0000 Hi, On Jan 21, 2011, at 4:30 PM, = wrote: > Hi Jouni, >=20 > It would useful if you provide in the I-D more elaboration why the = following points are considered as "issues"; >=20 > " Issue #4 >=20 > The problem of supporting changing NSP. Right. We should say a bit more here. How about: The problem of supporting changing NSP. The NSP learned by the host may become stale for multiple reasons. For example, the host might move to a new network that uses different NSP, thus making the previously learned NSP stale. Also, the NSP used in the network may be changed due administrative reasons, thus again making previously learned NSP stale. >=20 > Issue #5 >=20 > The problem of supporting multiple NSPs." Right. We should say a bit more here. How about: The problem of supporting multiple NSPs. A network may be configured with multiple NSPs for address synthesis. For example, for load-balancing purposes each NAT64 device in the same network could be assigned with their own NSP. >=20 >=20 > Do you have in mind load-balancing scenarios as what is described in = Section 6.2 of = http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-00? Actually no.. our load-balancing reference was generic as it was pointed = out in Beijing meeting as a reason for having multiple NSPs. - JOuni >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la = part de jouni korhonen > Envoy=E9 : vendredi 21 janvier 2011 09:16 > =C0 : 'behave' (behave@ietf.org) > Objet : [BEHAVE] Fwd: I-D = Action:draft-korhonen-behave-nat64-learn-analysis-01.txt >=20 > Folks, >=20 > Now citing a proper I-D ;-) We have (finally) updated the analysis = I-D. Sorry that it took somewhat longer than planned. This version = should address Dave's comments and the feedback we received in Beijing. = Comments and feedback is solicited. >=20 > - Jouni >=20 > Begin forwarded message: >=20 >> From: Internet-Drafts@ietf.org >> Date: January 20, 2011 12:45:01 PM GMT+02:00 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt >> Reply-To: internet-drafts@ietf.org >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >> Title : Analysis of solution proposals for hosts to = learn NAT64 prefix >> Author(s) : J. Korhonen, T. Savolainen >> Filename : = draft-korhonen-behave-nat64-learn-analysis-01.txt >> Pages : 25 >> Date : 2011-01-20 >>=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 > ********************************* > This message and any attachments (the "message") are confidential and = intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if altered, = changed or falsified. > If you are not the intended addressee of this message, please cancel = it immediately and inform the sender. > ******************************** >=20 From jouni.nospam@gmail.com Sun Jan 23 13:48:54 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303A73A69A3 for ; Sun, 23 Jan 2011 13:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S-JCIZaTLBU for ; Sun, 23 Jan 2011 13:48:52 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2D2553A69A1 for ; Sun, 23 Jan 2011 13:48:52 -0800 (PST) Received: by fxm9 with SMTP id 9so3747181fxm.31 for ; Sun, 23 Jan 2011 13:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=9HLvlZsUrNHyglK1HfWkG8KmaHDlHvFrM7jWGXcvONM=; b=ZbqzGAD4GRHt4Nc8ddsf91v8StYVskJ/XGsG/DK8G5aXbKfr1jDUlB+1BIz0tfMLwZ hSF2c8efBeI1HGSAG1hGBJmbZYTUs96yUiXJr2GVkrL4vPw3aSe+TFPsKtA/ltxkNwhr +ILRYYYMNARTkfQq1iwvKbGIqhtsQzmABs1qo= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=GW6MKX6GdBjGx9BPB0bhNouaS/bndKjyEeIZFcw9b+IbVH+R1vFnZg2CwNYs2yST8L Nwh+PrlgX7PfMAhZF6f5Zn2lsAvnaL8D8tF9AdDA0XzK0CHz1kca3c4ajpa8QybyPIbA 3/tn6MMm+rp1SQIgNc1XktEee3i5lLmmeLbtQ= Received: by 10.223.96.195 with SMTP id i3mr3428933fan.77.1295819504238; Sun, 23 Jan 2011 13:51:44 -0800 (PST) Received: from a88-114-173-187.elisa-laajakaista.fi (a88-114-173-187.elisa-laajakaista.fi [88.114.173.187]) by mx.google.com with ESMTPS id f24sm4307213fak.24.2011.01.23.13.51.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Jan 2011 13:51:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4D3993CD.90309@viagenie.ca> Date: Sun, 23 Jan 2011 23:51:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> <4D3993CD.90309@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1078) Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 21:48:54 -0000 Hi Simon, On Jan 21, 2011, at 4:10 PM, Simon Perreault wrote: > I'm very happy to see that this new version addresses the issue of > multiple prefixes. Here are some specific comments on this issue... Thanks for spending time and reading this I-D. > > This text appears in a few sections: > >> + Can partially solve issue #5 if multiple synthetic AAAA records >> are included in the response and all use same format. > > I don't understand this. For the load-balancing use-case I have in mind, Based on your description below you did seem to understand it.. > the DNS64 will pick just one of the prefixes and use it for the > synthesis. It will not use all of them for constructing the answer > section. So a client cannot determine whether there is a single prefix > or many just by looking at the DNS answer section. > Right, the model of working what we had in mind was that one does typical DNS round-robin style load balancing. There the host would receive multiple synthesized AAAAs (with NSPs of different NAT64s) and in the three cases where the above wording is used, the "solution" works if the synthesized AAAAs have NSPs of the same prefix length. If the DNS64 only responses with one synthesized AAAA, then yes, the above text could/should be rephrased differently. > There is also: > >> - This method is only able to find one NSP even if a network is >> utilizing multiple NSPs (issue #5) (unless DNS64 includes multiple >> synthetic AAAA records in response). > > This seems to contradict the previous quotation. I Don't think so. The thing that should be clarified here is what support for multiple prefixes means. For me it just means the network having multiple NAT64s just have multiple NSPs out there. How DNS64 then synthesizes AAAAs in replies does not really matter. And the DNS replies may contain one or more AAAAs with different NSPs. > > Section 4.4 (on the A64 record) says: > >> + Can be used to solve Issue #1 and #5. > > Could you please explain how it solves issue #5? DNS round-robin with multiple NSPs? Of course the DNS server that gets provisioned with A64s has to know adequate NSPs and the synthesized addresses. > > Section 4.6 (on DHCPv6) says: > >> If DHCPv6 would include multiple NSPs issue #5 could be solved as >> well, but only if nodes as a group would select different NSPs hence >> supporting load-balancing. As this is not clear this item is not yet >> listed under PRO nor CON. > > (There is similar text in section 4.7 (on RAs).) > > I disagree with this viewpoint. The DNS64 server would still be > responsible for load-balancing because it would be used for the vast > majority of cases. As long as the host is able to recognize all the > prefixes, and picks one prefix when it needs to initiate connections > (e.g. to IPv4 literals), we're fine. It wouldn't be the end of the world > if a host would always pick the same prefix because we're assuming that > the DNS would be used for the vast majority of cases. Ok. > > Furthermore, the DHCPv6 server could assist by e.g. randomizing the > prefixes it gives out so that even client implementations that always > pick the first prefix would tend to use all prefixes equally > (considering a large client population). > > Another viewpoint would be to consider the DHCPv6 server itself as > responsible for load balancing, assigning a single prefix to each client > according to a load-balancing algorithm. Each client would always use > the same prefix, and therefore would not need to know about the other > prefixes. > > So I think it would be correct to say that DHCPv6 and RAs do solve issue > #5 satisfactorily. > > Section 5 (Conclusion) says: > >> Issue #5 is considered to be mostly insignificant as >> even if individual hosts would use only one NSP at a time, different >> hosts would be using different NSPs, hence supporting load-balancing >> targets. > > I agree on the load-balancing issue, but I think this is missing the > point. If a host does not know about all prefixes, how can it achieve > issue #1? In other words, how can it recognize synthetic addresses using > prefixes it does not know about? I see solving issue #5 as a > prerequisite to solving #1. Hmm.. For spotting the presence of NAT64 in a network, the host needs to learn minimum one NSP or an indication of a NAT64. One does not need full coverage of NSPs for that. On the other hand, if a (dual-stack) host wants to be absolutely sure that none of the IPv6 addresses it has learned are synthesized then the host needs to know all NSPs used in that network. - JOuni > > 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 Internet-Drafts@ietf.org Sun Jan 23 23:15:02 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25183A6A7F; Sun, 23 Jan 2011 23:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRUS2rGj1Fds; Sun, 23 Jan 2011 23:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3659C3A6A4A; Sun, 23 Jan 2011 23:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124071502.21788.35409.idtracker@localhost> Date: Sun, 23 Jan 2011 23:15:02 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 07:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Analysis of 64 Translation Author(s) : R. Penno, et al. Filename : draft-ietf-behave-64-analysis-01.txt Pages : 14 Date : 2011-01-23 Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-64-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-23230241.I-D@ietf.org> --NextPart-- From mohamed.boucadair@orange-ftgroup.com Sun Jan 23 23:57:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B2C3A6955 for ; Sun, 23 Jan 2011 23:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G9hszgLj1mS for ; Sun, 23 Jan 2011 23:57:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 32DC23A6A88 for ; Sun, 23 Jan 2011 23:57:30 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 2D99BC01AF; Mon, 24 Jan 2011 09:00:23 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 0B9EE38404A; Mon, 24 Jan 2011 09:00:23 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 24 Jan 2011 09:00:23 +0100 From: To: jouni korhonen Date: Mon, 24 Jan 2011 09:00:22 +0100 Thread-Topic: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt Thread-Index: Acu7REp96u/606o4QIG0xVkoPqTgiAAdAXmw Message-ID: <13430_1295856023_4D3D3197_13430_71883_1_94C682931C08B048B7A8645303FDC9F33C413CE798@PUEXCB1B.nanterre.francetelecom.fr> References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> <3287_1295620255_4D39989F_3287_77487_1_94C682931C08B048B7A8645303FDC9F33C413CE542@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.1.24.73315 Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 07:57:32 -0000 Hi Jouni, The proposed text for issues 4 and 5 is fine. Thanks. I'm wondering whether issues 1, 2 or 3 can be extended to cover the case of= a host receiving referral objects. Even if DNS is supported by the receivi= ng host, it can not distinguish between an IPv4-embedded IPv6 address and a= "native" IPv6 address.=20=20 Cheers, Med=20 -----Message d'origine----- De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Envoy=E9 : dimanche 23 janvier 2011 22:27 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : 'behave' (behave@ietf.org) Objet : Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-anal= ysis-01.txt Hi, On Jan 21, 2011, at 4:30 PM, wrote: > Hi Jouni, >=20 > It would useful if you provide in the I-D more elaboration why the follow= ing points are considered as "issues"; >=20 > " Issue #4 >=20 > The problem of supporting changing NSP. Right. We should say a bit more here. How about: The problem of supporting changing NSP. The NSP learned by the host may become stale for multiple reasons. For example, the host might move to a new network that uses different NSP, thus making the previously learned NSP stale. Also, the NSP used in the network may be changed due administrative reasons, thus again making previously learned NSP stale. >=20 > Issue #5 >=20 > The problem of supporting multiple NSPs." Right. We should say a bit more here. How about: The problem of supporting multiple NSPs. A network may be configured with multiple NSPs for address synthesis. For example, for load-balancing purposes each NAT64 device in the same network could be assigned with their own NSP. >=20 >=20 > Do you have in mind load-balancing scenarios as what is described in Sect= ion 6.2 of http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balanci= ng-00? Actually no.. our load-balancing reference was generic as it was pointed ou= t in Beijing meeting as a reason for having multiple NSPs. - JOuni >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de jouni korhonen > Envoy=E9 : vendredi 21 janvier 2011 09:16 > =C0 : 'behave' (behave@ietf.org) > Objet : [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analys= is-01.txt >=20 > Folks, >=20 > Now citing a proper I-D ;-) We have (finally) updated the analysis I-D. S= orry that it took somewhat longer than planned. This version should address= Dave's comments and the feedback we received in Beijing. Comments and feed= back is solicited. >=20 > - Jouni >=20 > Begin forwarded message: >=20 >> From: Internet-Drafts@ietf.org >> Date: January 20, 2011 12:45:01 PM GMT+02:00 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt >> Reply-To: internet-drafts@ietf.org >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >> Title : Analysis of solution proposals for hosts to learn NAT= 64 prefix >> Author(s) : J. Korhonen, T. Savolainen >> Filename : draft-korhonen-behave-nat64-learn-analysis-01.txt >> Pages : 25 >> Date : 2011-01-20 >>=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 > ********************************* > This message and any attachments (the "message") are confidential and int= ended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if altered, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From behcetsarikaya@yahoo.com Mon Jan 24 09:58:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24053A6B0B for ; Mon, 24 Jan 2011 09:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm80dcXA6z8d for ; Mon, 24 Jan 2011 09:58:45 -0800 (PST) Received: from nm26-vm0.bullet.mail.sp2.yahoo.com (nm26-vm0.bullet.mail.sp2.yahoo.com [98.139.91.230]) by core3.amsl.com (Postfix) with SMTP id 1C6283A6ADC for ; Mon, 24 Jan 2011 09:58:45 -0800 (PST) Received: from [98.139.91.65] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 18:01:37 -0000 Received: from [98.139.91.12] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 18:01:37 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 18:01:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 886088.27991.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 43843 invoked by uid 60001); 24 Jan 2011 18:01:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295892097; bh=GFTLJsfI42TGXtufM6bBjzMkpwyqC2ReA0yTJweqS6s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S2Qrj3Yui0hEOgkwBzVPa0iHFo0k/ojbbmWyBlOFyqnzRV1xtDueLo5nn3OIrVqOEChPp60l9a3LfrVSPrrUv1IWXAiYR4PVyYpziR3bBnqTiipNAUv/N8I7N5khhKSE9R5mYVIG4eH4TiVYi2VvKrdomohPGza8shfYcI/mNi8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ON3+eFkMr33J4biv8Z1tBgQhcgZSGjU0gMCYqmzapH1OU/a/oEO20izHn/7My4235MAqXkP+oK0Uiwqzis0sIURv2sxtKjKo6wcw71oKasR0q5tXsx5eMLFL6d/82vX6gziNUjnWKVtlqDgszrfPH9SFmZImaNkXYPunEo++KNs=; Message-ID: <283593.42539.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: x39Cnm8VM1nvB8FMN86ZWgXlfqMRuA_MWwFJUO4DkODF.t8 Nlw4RICd5ddnNqntmbY9hYKp0Bjwf0CIZKfMHeAyVqex7Mb27ibyRqsaUzt. 19E4cgksDhZflnl9bO4KathnrdWX3Ramoy04PDneMNhPH1qiDubP3oN6gya_ p7LgefzQuWxxu1ciq_XMU.JLft_vnq5EOz34pu7Le9dEsOb6DSYYuK5sXqFh A4E0aXQ7NfUgi3mRZKs6XUnQtca_ikXSrAwiQuODtRU14bZ50NZroNiSw65Q iFdYcmwWc.9g1OkSU2s_VOw.7gSWXP7Vwn2Dg9CTlVT8a.xIf5dvfQYfIJie 2R9NM4YBwh9yrPX6twmVqPNAI8vZ3mTMYkeJZLsFFuqA.p7cqY2a4NAUS2vU bELYjtbBXuTv2 Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Mon, 24 Jan 2011 10:01:37 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> Date: Mon, 24 Jan 2011 10:01:37 -0800 (PST) From: Behcet Sarikaya To: Xing Li In-Reply-To: <4D3A76EB.2030806@cernet.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: congxiao , behave@ietf.org Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:58:47 -0000 > The stateless translation document is >https://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate/?include_text=1, > > >which clearly mentions the applicability and limitations of IPv4/IPv6 > translation for the multicast packets. Hi Xing, I did not know this. Now I checked, you are right. However the stateless translation document does not really state much about multicast. I still believe that any multicast related text in the current unicast NAT64 documents should be removed, including some sporadic text in draft-ietf-behave-v6v4-xlate-23. I am not sure if they have been reviewed. Regards, Behcet From behcetsarikaya@yahoo.com Mon Jan 24 10:55:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34E63A6B2D for ; Mon, 24 Jan 2011 10:55:47 -0800 (PST) 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.378, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3XviUR6IMMb for ; Mon, 24 Jan 2011 10:55:46 -0800 (PST) Received: from nm30-vm1.bullet.mail.sp2.yahoo.com (nm30-vm1.bullet.mail.sp2.yahoo.com [98.139.91.239]) by core3.amsl.com (Postfix) with SMTP id E0A7C3A6B31 for ; Mon, 24 Jan 2011 10:55:46 -0800 (PST) Received: from [98.139.91.64] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 18:58:42 -0000 Received: from [98.139.91.30] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 18:58:42 -0000 Received: from [127.0.0.1] by omp1030.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 18:58:42 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 296128.9214.bm@omp1030.mail.sp2.yahoo.com Received: (qmail 52764 invoked by uid 60001); 24 Jan 2011 18:58:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295895522; bh=rSCqqmu09zbG6th5R45gwY5yRtJVaE4BBMmIEmQxke0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n8hAhA8VpG+8J3Qgo5XrJ/Xl6vq+dICxzo6ljRsXgqmhJf0A3CQ9mk3XFS3SgO8EKnJKVuR3KeJHAHw3CzOv421mogZW8t2HB354jSRVNzs+Z3n6vUy9j79SPdqhdTsmynehLzxlMhkn0kXwiZJd14yJw1jCBTm159EAh9QuTSY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QIzCM2nkWTEWGF2m65t467MwyhbaKtbwPb2HwHxwbGZXqhueSRM34rkSjAhcEylLVJhKHpeJXj17tGTCNh7uJ9JOjcoazUebj/83scNpvuky+LEJGeUN4LOhG/SdjustKHfQ9N+2PrKPqVH9qB+GmG/5s2FKouz0lUrXRivXTRo=; Message-ID: <6880.51257.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: gaBnls4VM1muwQAtjLNYMvm4D2tPGMShxwK8H9gMY3rvYoY U8qQNNdPlvUzQC1IeSdcCq64uXpsNGPP8JZh86nWpsSGorUXIWyFuI7o_huA 2HS4pikvGfvufMEs7cpvwaWnQk9cxVKqAe.X_VXaFTVisB7uPaTwIBhUmE.3 RV4RMFP9xDarBTy2Vx7tZ5CpcyYrhY9ZAauUYBortGaimLhUHfnoRi2rRoBx TAuEhlbWSyhsLAU9HV7aZAi2k_NmjvrLlX95Ey7nGyw9PCgN6BwodAibMO50 Px68VdAMoXo2fnEMloZ_H5ueTSohjBRoyqE5Ki0KjDFiadYxl5h.wi.7unD9 3CBrmEhYhE3ZKRtqCXu5T4m8IndVRbjHiuVbgH0atUBIwreJNvJbjnKpMDyk WCUoEOVFw_Lv1 Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 24 Jan 2011 10:58:41 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <20110120104501.23103.95922.idtracker@localhost> <59F99B4F-CC29-4DB5-B0E3-5FE995FE9BEA@gmail.com> <3287_1295620255_4D39989F_3287_77487_1_94C682931C08B048B7A8645303FDC9F33C413CE542@PUEXCB1B.nanterre.francetelecom.fr> <13430_1295856023_4D3D3197_13430_71883_1_94C682931C08B048B7A8645303FDC9F33C413CE798@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 24 Jan 2011 10:58:41 -0800 (PST) From: Behcet Sarikaya To: mohamed.boucadair@orange-ftgroup.com, jouni korhonen In-Reply-To: <13430_1295856023_4D3D3197_13430_71883_1_94C682931C08B048B7A8645303FDC9F33C413CE798@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 18:55:47 -0000 These two issues are covered in our drafts draft-sarikaya-behave-mext-nat64-dsmip and draft-sarikaya-behave-mext-nat64-pmip We will submit revised versions soon. > > The problem of supporting changing NSP. > > Right. We should say a bit more here. How about: > > The problem of supporting changing NSP. The NSP learned by the > host may become stale for multiple reasons. For example, the host > might move to a new network that uses different NSP, thus making > the previously learned NSP stale. Also, the NSP used in the > network may be changed due administrative reasons, thus again > making previously learned NSP stale. > > > > > > Issue #5 > > > > The problem of supporting multiple NSPs." > > Right. We should say a bit more here. How about: > > The problem of supporting multiple NSPs. A network may be > configured with multiple NSPs for address synthesis. For example, > for load-balancing purposes each NAT64 device in the same network > could be assigned with their own NSP. > > Regards, Behcet From jacniq@gmail.com Mon Jan 24 23:44:24 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA463A6A60 for ; Mon, 24 Jan 2011 23:44:24 -0800 (PST) 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.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJdOhRa1L7FQ for ; Mon, 24 Jan 2011 23:44:23 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C17753A6A73 for ; Mon, 24 Jan 2011 23:44:22 -0800 (PST) Received: by yxt33 with SMTP id 33so1876426yxt.31 for ; Mon, 24 Jan 2011 23:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y8hyJD0ODA0gu6K++bo+N71vyOcUOC5YFcALRhPOxJE=; b=HIyAQ2ydh49RlxceUQa3G4LBYjhM1A9tNbLRuqbbjgNf9GxgkzcqGM2DN4eZyl9TlU Tkbj09JrFpUssm3F2XbmWXlmzJLX8Z2EdRxs2yHCnBM+Mj4t9FHFmYfcT+EX/JR53T+1 DJhiYBydz9EDCqM5wYE3New/oCEcG+chBtaeU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YVqXZ5prD/FAX1EVNkVhNdg7cegTvSVrRYMRPmxKyGsZOOc9M8tqDUNXHdgtV2lSyc P++dYH3uYHrr8lJJuJRda/34lARuOs8BBGGV6jWb4rxz7ox+2K21EkgTRX7HcrNxLVIv Kje7OVEE5oJL5zzyUtlEWhh/Xv9Z/dWjQFJhU= MIME-Version: 1.0 Received: by 10.151.44.20 with SMTP id w20mr5722193ybj.177.1295941639338; Mon, 24 Jan 2011 23:47:19 -0800 (PST) Received: by 10.147.33.20 with HTTP; Mon, 24 Jan 2011 23:47:19 -0800 (PST) In-Reply-To: References: <037e01cbb834$6c5808b0$45081a10$@com> Date: Tue, 25 Jan 2011 15:47:19 +0800 Message-ID: From: Jacni Qin To: Tom Taylor Content-Type: multipart/alternative; boundary=00151750d9a40ffb22049aa6ed9a Cc: Tom Taylor , behave@ietf.org, jihui@chinatelecom.com.cn, Cathy Zhou , Dan Wing , "Lee, Yiu" , Tina TSOU Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:44:24 -0000 --00151750d9a40ffb22049aa6ed9a Content-Type: text/plain; charset=ISO-8859-1 Re-, ok, we can wait for your updates to see the details, thanks. Cheers, Jacni On Fri, Jan 21, 2011 at 1:14 PM, Tom Taylor wrote: > I assure you, the mapping is lossless. One thing the whole discussion makes > clear: we'd better add some numerical examples to the document to make it > easier for people to see what is going on. > > > On 20/01/2011 12:27 PM, Jacni Qin wrote: > >> Re-, >> >> On Thu, Jan 20, 2011 at 7:55 AM, Dan Wing wrote: >> >> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of Tom Taylor >>>> Sent: Wednesday, January 19, 2011 2:26 PM >>>> To: Lee, Yiu >>>> Cc: 'Tom Taylor'; behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy >>>> Zhou'; Dan Wing; 'Tina TSOU' >>>> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >>>> behave-translated-multicast-00 >>>> >>>> A softwire draft has been prepared, but I'd like to take up this point. >>>> It depends on why double mapping is bad. In this case, the second >>>> translation is simply the inverse of the first one. >>>> >>> >>> If it is a "lossless translation", that is, the same IP address >>> exists on both sides -- then the two translation functions are >>> equivalent to a tunnel and indistinguishable from a tunnel. The >>> term "inverse" is an accurate term for such a lossless >>> translation. >>> >>> >> Jacni>: May be equivalent if it is the "lossless translation". :-) >> But not sure if the reconstructing of packets during the translations >> brings >> impacts. I'm trying to check this out while it is difficult in most cases, >> since many algorithms used for pretecting DRM, integrity are of property. >> Maybe someone can help. >> >> >> However, the function described in draft-tsou-behave-translated-multicast >>> is not lossless -- the mapped address is chosen from a pool of >>> addresses. From Section 3.1 of draft-tsou-behave-translated-multicast: >>> >>> >> Jacni>: Agree, the stateful translation specified in the document is not >> lossless. >> >> >> ... >>> 2. Address Mapping At the HMAF >>> >>> The HMAF checks its cache of mappings to see if it already has a >>> mapping between the IPvx address pair received in the >>> host request and a corresponding pair of IPvy addresses. Failing to >>> find a mapping, it sends a request for the required mapping to the >>> mapping function. The mapping function in turn checks whether it has >>> already created the mapping. If not, it assigns unicast and >>> multicast IPvy addresses from its pool and records the mapping for >>> further use. >>> ... >>> >>> -d >>> >>> >>> >>> >>> >> --00151750d9a40ffb22049aa6ed9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

ok, we can wait for your upda= tes to see the details, thanks.


Cheers,
Jacni

<= div class=3D"gmail_quote">On Fri, Jan 21, 2011 at 1:14 PM, Tom Taylor <tom111.taylor@be= ll.net> wrote:
I assure you, the= mapping is lossless. One thing the whole discussion makes clear: we'd = better add some numerical examples to the document to make it easier for pe= ople to see what is going on.


On 20/01/2011 12:27 PM, Jacni Qin wrote:
Re-,

On Thu, Jan 20, 2011 at 7:55 AM, Dan Wing<dwing@cisco.com> =A0wrote:

-----Original Message-----
From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf Of Tom Taylor
Sent: Wednesday, January 19, 2011 2:26 PM
To: Lee, Yiu
Cc: 'Tom Taylor'; behave@ietf.org; jihui@chinatelecom.com.cn; 'Cathy
Zhou'; Dan Wing; 'Tina TSOU'
Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-
behave-translated-multicast-00

A softwire draft has been prepared, but I'd like to take up this point.=
It depends on why double mapping is bad. In this case, the second
translation is simply the inverse of the first one.

If it is a "lossless translation", that is, the same IP address exists on both sides -- then the two translation functions are
equivalent to a tunnel and indistinguishable from a tunnel. =A0The
term "inverse" is an accurate term for such a lossless
translation.


Jacni>: May be equivalent if it is the "lossless translation".= :-)
But not sure if the reconstructing of packets during the translations bring= s
impacts. I'm trying to check this out while it is difficult in most cas= es,
since many algorithms used for pretecting DRM, integrity are of property. Maybe someone can help.


However, the function described in draft-tsou-behave-translated-multicast is not lossless -- the mapped address is chosen from a pool of
addresses. =A0From Section 3.1 of draft-tsou-behave-translated-multicast:

Jacni>: Agree, the stateful translation specified in the document is not=
lossless.


...
=A0 2.<Source, Group> =A0Address Mapping At the HMAF

=A0 The HMAF checks its cache of mappings to see if it already has a
=A0 mapping between the IPvx<Source, Group> =A0address pair received= in the
=A0 host request and a corresponding pair of IPvy addresses. =A0Failing to=
=A0 find a mapping, it sends a request for the required mapping to the
=A0 mapping function. =A0The mapping function in turn checks whether it ha= s
=A0 already created the mapping. =A0If not, it assigns unicast and
=A0 multicast IPvy addresses from its pool and records the mapping for
=A0 further use.
...

-d






--00151750d9a40ffb22049aa6ed9a-- From dwing@cisco.com Tue Jan 25 17:27:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9C03A68B0 for ; Tue, 25 Jan 2011 17:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.533 X-Spam-Level: X-Spam-Status: No, score=-110.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuHh0bQ-CX5a for ; Tue, 25 Jan 2011 17:27:45 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 595083A68AC for ; Tue, 25 Jan 2011 17:27:45 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF8IP02rR7Ht/2dsb2JhbACXeIx5c55Hm0KFTwSFF5Md Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2011 01:30:44 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0Q1Ui8b009131; Wed, 26 Jan 2011 01:30:44 GMT From: "Dan Wing" To: "'Behcet Sarikaya'" , "'Xing Li'" References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> <283593.42539.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <283593.42539.qm@web111412.mail.gq1.yahoo.com> Date: Tue, 25 Jan 2011 17:30:43 -0800 Message-ID: <008a01cbbcf8$a696e7d0$f3c4b770$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu78MrZkIEQm1EXR5GPnGoQ8aoxAwBB4T4A Content-Language: en-us Cc: 'congxiao' , behave@ietf.org Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 01:27:46 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Monday, January 24, 2011 10:02 AM > To: Xing Li > Cc: congxiao; behave@ietf.org > Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format > > > > > The stateless translation document is > >https://datatracker.ietf.org/doc/draft-ietf-behave-v6v4- > xlate/?include_text=1, > > > > > >which clearly mentions the applicability and limitations of > IPv4/IPv6 > > translation for the multicast packets. > > Hi Xing, > > I did not know this. Now I checked, you are right. > > However the stateless translation document does not really state much > about > multicast. > I still believe that any multicast related text in the current unicast > NAT64 > documents should be removed, including some sporadic text in > draft-ietf-behave-v6v4-xlate-23. > > I am not sure if they have been reviewed. draft-ietf-behave-v6v4-xlate has been in the RFC Editor's queue since October, 2010, because it had completed BEHAVE working group last call, IETF last call, and IESG review. Dates are here: https://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate/history/ -d From behcetsarikaya@yahoo.com Wed Jan 26 07:45:11 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327753A6881 for ; Wed, 26 Jan 2011 07:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNl0lMEKH4+C for ; Wed, 26 Jan 2011 07:45:10 -0800 (PST) Received: from nm30-vm0.bullet.mail.sp2.yahoo.com (nm30-vm0.bullet.mail.sp2.yahoo.com [98.139.91.238]) by core3.amsl.com (Postfix) with SMTP id 376CF3A67F6 for ; Wed, 26 Jan 2011 07:45:10 -0800 (PST) Received: from [98.139.91.64] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jan 2011 15:48:08 -0000 Received: from [98.139.91.1] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jan 2011 15:48:08 -0000 Received: from [127.0.0.1] by omp1001.mail.sp2.yahoo.com with NNFMP; 26 Jan 2011 15:48:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 690246.11311.bm@omp1001.mail.sp2.yahoo.com Received: (qmail 20332 invoked by uid 60001); 26 Jan 2011 15:48:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296056888; bh=fITYbhHrCAh4pzSlJIeXtsmlWZhjSCxtYI9NQxcCA/0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cd2qKUEgbVOKZd1gQQje8h9hByNXEgW6OCggJlDOf3ZST07Qrqt/a6uji9OAJh7TQc0XFdn7EEwxek1MdrPwst60PlOcAPKzyHotGiQVeQFz8lZ83uQ11PQWjntEN/GC4LpZWxnLVgTNJ4OBAOfwl9AUfaS+8qTQ9Ex+2gqyzN4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=e+fnoaKZ+nmmRWh9mccC/98W/7KOE1VbdgZm6jgQtq78H74Ffam/IwY0wxiNppcXOtlx2lLmu62RIX7RV0z8eq5N+D8Io38N1wYPpRPoDSObPIqdUxNiAZ4mavkIgP8X3I5C78euU4qJ1gkjc6p71YFTuxc5FWz5Sy0pcK9BFuw=; Message-ID: <197335.19755.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: kzqM1fsVM1n2oyrL4buDgwB7XHFOoj3qQl2IwTgzrWX4OT6 .3Vwtyx9D9vd2pHKOgn1g6MyFsrZDCAlIJmG4tpsvJZ6ARduGBP.MZCutGQ5 y2O2.KoP27YIxRaLBhu4Xd.puSKdB.erpmrr0tnRlpSAGzcAZLtXMOgeHJIA d1MBo922dqK9RrPhYzrT8a_bLSwV6SapGgZ_7Pmoi0rFUu6MEJAxUiAsOVdb PNf755mIdcBo_.9MNwgvEs.iwxgTunvh7qB54R7.uRhlxuAnni590IkHVAPl 77wyr4Y5kZbvVsWxAGpnxDBrak69hNBnxYQW.CP6EuWSv.U32GR53UB8lzlK X6El8Oc4X86n5lBMLn.BiobU.mlcNwfhSaQfPV4N4hGWfyDPfcGAzsFuzEvm P69qi2ThtG9Uf Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Wed, 26 Jan 2011 07:48:08 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> <283593.42539.qm@web111412.mail.gq1.yahoo.com> <008a01cbbcf8$a696e7d0$f3c4b770$@com> Date: Wed, 26 Jan 2011 07:48:08 -0800 (PST) From: Behcet Sarikaya To: Dan Wing , Xing Li In-Reply-To: <008a01cbbcf8$a696e7d0$f3c4b770$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: congxiao , behave@ietf.org Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:45:11 -0000 Hi Dan, I realize that it is probably late to do something on this document. But I hope you agree with me on what I said below :-) --b > > > > > > > The stateless translation document is > > >https://datatracker.ietf.org/doc/draft-ietf-behave-v6v4- > > xlate/?include_text=1, > > > > > > > > >which clearly mentions the applicability and limitations of > > IPv4/IPv6 > > > translation for the multicast packets. > > > > Hi Xing, > > > > I did not know this. Now I checked, you are right. > > > > However the stateless translation document does not really state much > > about > > multicast. > > I still believe that any multicast related text in the current unicast > > NAT64 > > documents should be removed, including some sporadic text in > > draft-ietf-behave-v6v4-xlate-23. > > > > I am not sure if they have been reviewed. > > draft-ietf-behave-v6v4-xlate has been in the RFC Editor's queue > since October, 2010, because it had completed BEHAVE working group > last call, IETF last call, and IESG review. Dates are here: > > https://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate/history/ > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From behcetsarikaya@yahoo.com Wed Jan 26 07:59:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19FC23A679C for ; Wed, 26 Jan 2011 07:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg1BgF9oWiwB for ; Wed, 26 Jan 2011 07:59:50 -0800 (PST) Received: from nm14.bullet.mail.sp2.yahoo.com (nm14.bullet.mail.sp2.yahoo.com [98.139.91.84]) by core3.amsl.com (Postfix) with SMTP id 709413A6784 for ; Wed, 26 Jan 2011 07:59:50 -0800 (PST) Received: from [98.139.91.61] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jan 2011 16:02:51 -0000 Received: from [98.139.91.1] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jan 2011 16:02:51 -0000 Received: from [127.0.0.1] by omp1001.mail.sp2.yahoo.com with NNFMP; 26 Jan 2011 16:02:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 576169.84011.bm@omp1001.mail.sp2.yahoo.com Received: (qmail 82181 invoked by uid 60001); 26 Jan 2011 16:02:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296057770; bh=aa8Q5T5xDA9vAnB6MBDW4Un3lXOr7/Tq9bIqMO+NKlc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wntyy+Z47yDk8Oic5QPUUhRavHP6+Ve1aC8IwsM4bFse5tTr2bcS+afJ5A05m6XrBFWFvfB49ecEKfh+nkymV+js8kdFkCj9U7iKR+1V3OxdaXedIzMfxO88lDOBQ9jqqkqsvIlweyrMqHHzVu9B++bi4/f+KJMEfjtXBpTJCSk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wQqAi+LftsM1dqqOJJ5YQEQ2LI0ZgWb9MxzSgqXrsBi2fa3tDo3/caLZ+mLSuIaY60sr1IF1ZeKgL066yS00uTqp2SmCTwAFWA1jDS5BU+HFj9/65JD0DWg6eoDzyfPZsb9wesF8PPQsUoJCQG4LMqSxXTy86NRJjr0qvAd5GlA=; Message-ID: <755619.81691.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: A4J9erQVM1kr.yvTqiPnIeoFxz4EJJBntuUAQ2ZmSRqLWyh wWvwR8D8ekGHLFKupavOddXq5t1LI8r742JSFVbA4vChSrRmoHUOWVRjv606 SaoqKe56jglOg4ihhUnL5FpLnw6RAAVSg8jIUa3yS3O0LgRx9OqXE1aChcy6 hzIlzItyhjuD7A2pGuFIrYryycg34OjJ2qdSatttoie0X0slHV73X1L5awDd xulYg9.TjvwGJr1V6xC6AWIC9OFyLovfNLlO5cNXFoWArN7HKzlsSqCxVxQJ 8EChxEA4BTu.k11ki_J6bZRoawpN6Aq6to_aaIK7BTetEItKmlz0aXmW0eNB w_1YyMgbIIJRnqFHf5d.TIBlpZVRw.xf7tA.WGTUehI8WTMMBNPZw1Woq1qy VQpn37F_ZJes- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Wed, 26 Jan 2011 08:02:50 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 Date: Wed, 26 Jan 2011 08:02:50 -0800 (PST) From: Behcet Sarikaya To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BEHAVE] New Version Notification X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:59:51 -0000 We submitted -01 version of Multicast Support for NAT64 draft at: http://tools.ietf.org/id/draft-sarikaya-behave-mcast4nat64-01.txt This draft addresses only supporting multicast in NAT64 protocol using translation techniques. Regards, Behcet From dwing@cisco.com Wed Jan 26 08:36:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209A23A67EF for ; Wed, 26 Jan 2011 08:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnrBg9b5MmeF for ; Wed, 26 Jan 2011 08:36:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3B4083A63D3 for ; Wed, 26 Jan 2011 08:36:54 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGrdP02rR7Ht/2dsb2JhbACWJoFXjHpzoQmbU4VPBIUXjW+FMg Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2011 16:39:54 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0QGdsxr006524; Wed, 26 Jan 2011 16:39:54 GMT From: "Dan Wing" To: "'Behcet Sarikaya'" , "'Xing Li'" References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> <283593.42539.qm@web111412.mail.gq1.yahoo.com> <008a01cbbcf8$a696e7d0$f3c4b770$@com> <197335.19755.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <197335.19755.qm@web111406.mail.gq1.yahoo.com> Date: Wed, 26 Jan 2011 08:39:53 -0800 Message-ID: <020101cbbd77$a8a53bb0$f9efb310$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu9cHBneN2ztU/fSxuIgnLcbf2nrAABxBdw Content-Language: en-us Cc: 'congxiao' , behave@ietf.org Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:36:55 -0000 > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Wednesday, January 26, 2011 7:48 AM > To: Dan Wing; Xing Li > Cc: congxiao; behave@ietf.org > Subject: Re: [BEHAVE] Multicast IPv4-embedded Address Format > > Hi Dan, > > I realize that it is probably late to do something on this document. > > But I hope you agree with me on what I said below :-) We can correct / augment the information with follow-on documents, including -- if we find it necessary -- doing an "Update:" of draft-ietf-behave-v6v4-xlate. -d > --b > > > > > > > > > > > > > > The stateless translation document is > > > >https://datatracker.ietf.org/doc/draft-ietf-behave-v6v4- > > > xlate/?include_text=1, > > > > > > > > > > > >which clearly mentions the applicability and limitations of > > > IPv4/IPv6 > > > > translation for the multicast packets. > > > > > > Hi Xing, > > > > > > I did not know this. Now I checked, you are right. > > > > > > However the stateless translation document does not really state > much > > > about > > > multicast. > > > I still believe that any multicast related text in the current > unicast > > > NAT64 > > > documents should be removed, including some sporadic text in > > > draft-ietf-behave-v6v4-xlate-23. > > > > > > I am not sure if they have been reviewed. > > > > draft-ietf-behave-v6v4-xlate has been in the RFC Editor's queue > > since October, 2010, because it had completed BEHAVE working group > > last call, IETF last call, and IESG review. Dates are here: > > > > https://datatracker.ietf.org/doc/draft-ietf-behave-v6v4- > xlate/history/ > > > > -d > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > > From iljitsch@muada.com Fri Jan 28 08:26:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C563A68E9 for ; Fri, 28 Jan 2011 08:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.562 X-Spam-Level: X-Spam-Status: No, score=-101.562 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ixx5S0eH9-S for ; Fri, 28 Jan 2011 08:26:50 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 82AFD3A68C0 for ; Fri, 28 Jan 2011 08:26:50 -0800 (PST) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p0SGTPel088038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 28 Jan 2011 17:29:26 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 17:29:53 +0100 Message-Id: <2D552E77-4591-4DBE-A7AC-148FF44D02F6@muada.com> To: Behave WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [BEHAVE] FTP64 LANG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:26:51 -0000 I've added the following text to the FTP64 draft. If there are no = complaints by Monday, I'll submit the draft. 5.1. Language negotiation [RFC2640] specifies the ability for clients and servers to negotiate the language used between the two of them in the descriptive text that accompanies server response codes. Ideally, IPv6-to-IPv4 FTP ALGs would support this feature, so that if a non-default language is negotiated by a client and a server, the ALG also transmits its text messages for translated responses in the negotiated language. However, even if the ALG supports negotiation of the feature, there is no way to make sure that the ALG has text strings for all possible languages. So the situation where the client and server try to negotiate a language that the ALG doesn't support can't be avoided. The proper behavior for an FTP ALG in this situation may be addressed in a future specification, as the same issue is present in IPv4-to- IPv4 FTP ALGs. For the time being, ALG implementations may employ one of the following strategies regarding LANG negotiation: 1. Monitor LANG negotiation, and send text in the negotiated language if text in that language is available. If not, text is sent in the default language. 2. Not monitor LANG negotiation. Text is sent in the default language. 3. Block LANG negotiation by translating the LANG command to a NOOP command, and translating the resulting 200 response into a response appropriate for unsupported commands, such as 500. Text is sent in the default language. In the first two cases, if a language is negotiated, text transmitted by the client or the server MUST be assumed to be encoded in UTF-8 rather than be limited to 7-bit ASCII. An ALG that implements the first or second option MUST translate and/or forward commands and responses containing UTF-8 encoded text when those occur. The ALG itself MUST NOT generate characters outside the 7-bit ASCII range unless it implements the first option and a language was negotiated. Note that [RFC2640] section 3.1 specifies new handling for spaces and the CR character in path names. ALGs that don't block LANG negotiation SHOULD comply with the specified rules for path handling. Implementers should especially note that the NUL (%x00) character is used as an escape whenever a CR character occurs in a pathname. From Internet-Drafts@ietf.org Mon Jan 31 12:15:03 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2EB3A6C4D; Mon, 31 Jan 2011 12:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnVHx4uCRLfU; Mon, 31 Jan 2011 12:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2843A6C6C; Mon, 31 Jan 2011 12:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110131201501.6269.14138.idtracker@localhost> Date: Mon, 31 Jan 2011 12:15:01 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-ftp64-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : An FTP ALG for IPv6-to-IPv4 translation Author(s) : I. van Beijnum Filename : draft-ietf-behave-ftp64-07.txt Pages : 16 Date : 2011-01-31 The File Transfer Protocol (FTP) has a very long history, and despite the fact that today, other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators as best it can. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-ftp64-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-ftp64-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-31120327.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Mon Jan 31 12:26:33 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375E93A6C71 for ; Mon, 31 Jan 2011 12:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giuZAuOfpGQD for ; Mon, 31 Jan 2011 12:26:31 -0800 (PST) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by core3.amsl.com (Postfix) with ESMTP id 7C3473A6C5E for ; Mon, 31 Jan 2011 12:26:31 -0800 (PST) Received: from BLU0-SMTP101 ([65.55.116.73]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 12:29:42 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP101.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 12:29:42 -0800 Date: Mon, 31 Jan 2011 15:29:52 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2011 20:29:42.0119 (UTC) FILETIME=[972B2770:01CBC185] Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:26:33 -0000 I added a section giving numerical examples. Tom T -------- Original Message -------- Subject: New Version Notification for draft-tsou-behave-translated-multicast-01 Date: Thu, 27 Jan 2011 18:55:07 -0800 (PST) From: IETF I-D Submission Tool To: tom111.taylor@bell.net CC: tena@huawei.com,cathyzhou@huawei.com,jihui@chinatelecom.com.cn A new version of I-D, draft-tsou-behave-translated-multicast-01.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-behave-translated-multicast Revision: 01 Title: A Generic Approach to Multicast Translation In Support of IPv6 Transition Creation_date: 2011-01-28 WG ID: Independent Submission Number_of_pages: 12 Abstract: Consider a situation which will arise in many IPv6 transition scenarios, where Network A, to which a host is attached, supports one IP version, but the host and Network B support a different IP version. Suppose that the host wishes to access a multicast group which is rooted or sourced in Network B. This document specifies a stateful translation mechanism whereby the host can obtain its desired access using the native multicast capabilities of Network A. The IETF Secretariat. From dwing@cisco.com Mon Jan 31 13:37:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12C63A6C92 for ; Mon, 31 Jan 2011 13:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJDz+1pEsuMX for ; Mon, 31 Jan 2011 13:37:43 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A24B73A6C8F for ; Mon, 31 Jan 2011 13:37:43 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAGAMK6Rk2rR7H+/2dsb2JhbACWWIEmjHtzojebI4VOBIUT Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2011 21:40:59 +0000 Received: from dwingWS (dhcp-171-70-230-162.cisco.com [171.70.230.162]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0VLewg8003330; Mon, 31 Jan 2011 21:40:59 GMT From: "Dan Wing" To: Date: Mon, 31 Jan 2011 13:40:58 -0800 Message-ID: <135101cbc18f$8c5f48d0$a51dda70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvBj4wzt6NE2PsoT2mCf1eJxs2iwg== Content-Language: en-us Cc: eburger@standardstrack.com Subject: [BEHAVE] SIPNOC call for papers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:37:44 -0000 This announcement may be interesting to members of BEHAVE. Please followup with Eric at eburger@standardstrack.com. -d ----- The SIP Forum is holding its first SIP Network Operators Conference (SIPNOC) on April 25th to the 27th, 2011, at the Hyatt Dulles Hotel in Herndon, Virginia - a few minutes from Dulles International Airport. SIPNOC is a technical conference developed for service providers and carriers to gather and discuss the challenges of deploying and implementing SIP-based communications technology, and to share the best-practices and strategies that enable the successful and profitable operation of SIP-based services and applications in fixed and mobile IP network environments. Unlike other events, this conference is for SIP network operations personnel, such as NOC engineers, rather than a high-level conference for executives. For more information about SIPNOC, including the preliminary schedule of events and other important details about the conference, please visit http://www.sipnoc.org. The SIPNOC Program Committee is seeking proposals for presentations, panels, or BOFs (Birds-Of-a-Feather sessions) for the SIPNOC 2011 program. We invite presentations highlighting issues relating to SIP network deployments. Operators are encouraged to present on successes, issues, and concerns found in their deployments. Vendors are encouraged to work with operators to present real-world deployment experiences. The deadline for submission of presentation/paper abstracts and draft slides is February 21, 2011. Full details of the submission process and policies, as well as other SIPNOC 2011 dates of interest, can be found at: http://www.sipforum.org/content/view/374/275/ I look forward to seeing you at the event! Best Wishes, Eric Burger SIPNOC Chair From dwing@cisco.com Mon Jan 31 15:36:05 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7C83A6C92 for ; Mon, 31 Jan 2011 15:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRwfVHxpTGx9 for ; Mon, 31 Jan 2011 15:36:04 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 66EB03A6C78 for ; Mon, 31 Jan 2011 15:36:04 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHDWRk2rR7H+/2dsb2JhbACYAIx7c6FMmy2FTgSFEw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2011 23:39:20 +0000 Received: from dwingWS ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0VNdJ6B017706 for ; Mon, 31 Jan 2011 23:39:19 GMT From: "Dan Wing" To: "'Behave WG'" Date: Mon, 31 Jan 2011 15:39:18 -0800 Message-ID: <001301cbc1a0$14df55a0$3e9e00e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvBoBQNY0jcItbtSbmQXdL0gxe7wA== Content-Language: en-us Subject: [BEHAVE] naming a big NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:36:05 -0000 At IETF79 we were asked to run a survey on naming a big NAT. So here it is, http://www.surveymonkey.com/s/DJSB7ZM Please vote so we can finally close this issue. Note: Unfortunately, due to limitations of the SurveyMonkey tool, write-ins won't show up for others and if I add a write-in after the survey has started, it invalidates (destroys) all recorded tallies. -d From townsley@cisco.com Mon Jan 31 15:48:14 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80AE43A6C64 for ; Mon, 31 Jan 2011 15:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.231 X-Spam-Level: X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svNi26go6W2g for ; Mon, 31 Jan 2011 15:48:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 393A73A68B1 for ; Mon, 31 Jan 2011 15:48:13 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2011 23:51:28 +0000 Received: from ams-townsley-8711.cisco.com (ams-townsley-8711.cisco.com [10.55.233.226]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0VNpSDR008716; Mon, 31 Jan 2011 23:51:28 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <001301cbc1a0$14df55a0$3e9e00e0$@com> Date: Tue, 1 Feb 2011 00:51:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001301cbc1a0$14df55a0$3e9e00e0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) Cc: 'Behave WG' Subject: Re: [BEHAVE] naming a big NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:48:14 -0000 I voted CGN. I believe I have seen this and LSN most often in various = documents and presentations to date. I'd rather settle on something that = is already in circulation, rather than adding another acronym into the = mix. In terms of LSN vs. CGN, I think the location in the network and how it = is operated is more important architecturally rather than scale per se. = Also, I wouldn't want to imply that this kind of NAT was somehow = inherently scalable by putting that in the name. I'm sure there are at least as many different views on this as there are = members on the list though. - Mark PS. Apropos as the last two /8s just went to apnic... On Feb 1, 2011, at 12:39 AM, Dan Wing wrote: > At IETF79 we were asked to run a survey on naming a big NAT. So here = it is, > http://www.surveymonkey.com/s/DJSB7ZM >=20 > Please vote so we can finally close this issue. >=20 > Note: Unfortunately, due to limitations of the SurveyMonkey=20 > tool, write-ins won't show up for others and if I=20 > add a write-in after the survey has started, it=20 > invalidates (destroys) all recorded tallies. >=20 > -d >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tena@huawei.com Mon Jan 31 16:19:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE033A6C95 for ; Mon, 31 Jan 2011 16:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daJSqxw5vIVH for ; Mon, 31 Jan 2011 16:19:53 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B5B343A68E7 for ; Mon, 31 Jan 2011 16:19:53 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFW00FQRX2KS2@usaga04-in.huawei.com> for behave@ietf.org; Mon, 31 Jan 2011 18:23:08 -0600 (CST) Received: from TingZousc1 ([10.212.245.170]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFW000ZEX2GJC@usaga04-in.huawei.com> for behave@ietf.org; Mon, 31 Jan 2011 18:23:08 -0600 (CST) Date: Mon, 31 Jan 2011 16:23:05 -0800 From: Tina Tsou In-reply-to: To: 'Mark Townsley' , 'Dan Wing' Message-id: <001801cbc1a6$3285ea00$9791be00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvBoc1kzZkXCpOOTkGXqFU9yye1RgABCi8g References: <001301cbc1a0$14df55a0$3e9e00e0$@com> Cc: 'Behave WG' Subject: Re: [BEHAVE] naming a big NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:19:55 -0000 I chatted with Dan in another thread, I almost thought the decision was already made using LSN. Though, many operators still use CGN. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Monday, January 31, 2011 3:51 PM To: Dan Wing Cc: 'Behave WG' Subject: Re: [BEHAVE] naming a big NAT I voted CGN. I believe I have seen this and LSN most often in various documents and presentations to date. I'd rather settle on something that is already in circulation, rather than adding another acronym into the mix. In terms of LSN vs. CGN, I think the location in the network and how it is operated is more important architecturally rather than scale per se. Also, I wouldn't want to imply that this kind of NAT was somehow inherently scalable by putting that in the name. I'm sure there are at least as many different views on this as there are members on the list though. - Mark PS. Apropos as the last two /8s just went to apnic... On Feb 1, 2011, at 12:39 AM, Dan Wing wrote: > At IETF79 we were asked to run a survey on naming a big NAT. So here it is, > http://www.surveymonkey.com/s/DJSB7ZM > > Please vote so we can finally close this issue. > > Note: Unfortunately, due to limitations of the SurveyMonkey > tool, write-ins won't show up for others and if I > add a write-in after the survey has started, it > invalidates (destroys) all recorded tallies. > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Mon Jan 31 22:41:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24A33A687B for ; Mon, 31 Jan 2011 22:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZLHLKhZM-4G for ; Mon, 31 Jan 2011 22:41:57 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 42B083A695D for ; Mon, 31 Jan 2011 22:41:57 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (86.31.18.95.dynamic.jazztel.es [95.18.31.86]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 244D387219A for ; Tue, 1 Feb 2011 07:45:11 +0100 (CET) Message-ID: <4D47ABF8.5010301@it.uc3m.es> Date: Tue, 01 Feb 2011 07:45:12 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <001301cbc1a0$14df55a0$3e9e00e0$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17928.003 Subject: Re: [BEHAVE] naming a big NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 06:41:59 -0000 agree with mark El 01/02/11 0:51, Mark Townsley escribió: > I voted CGN. I believe I have seen this and LSN most often in various documents and presentations to date. I'd rather settle on something that is already in circulation, rather than adding another acronym into the mix. > > In terms of LSN vs. CGN, I think the location in the network and how it is operated is more important architecturally rather than scale per se. Also, I wouldn't want to imply that this kind of NAT was somehow inherently scalable by putting that in the name. > > I'm sure there are at least as many different views on this as there are members on the list though. > > - Mark > > PS. Apropos as the last two /8s just went to apnic... > > On Feb 1, 2011, at 12:39 AM, Dan Wing wrote: > >> At IETF79 we were asked to run a survey on naming a big NAT. So here it is, >> http://www.surveymonkey.com/s/DJSB7ZM >> >> Please vote so we can finally close this issue. >> >> Note: Unfortunately, due to limitations of the SurveyMonkey >> tool, write-ins won't show up for others and if I >> add a write-in after the survey has started, it >> invalidates (destroys) all recorded tallies. >> >> -d >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From huitema@microsoft.com Mon Jan 31 22:56:42 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2513A695D for ; Mon, 31 Jan 2011 22:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVv2FzB50xqn for ; Mon, 31 Jan 2011 22:56:41 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 183DE3A6907 for ; Mon, 31 Jan 2011 22:56:41 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Jan 2011 22:59:57 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 31 Jan 2011 22:59:57 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 31 Jan 2011 22:59:56 -0800 From: Christian Huitema To: marcelo bagnulo braun , "behave@ietf.org" Thread-Topic: [BEHAVE] naming a big NAT Thread-Index: AcvBoBQNY0jcItbtSbmQXdL0gxe7wAARMGGAAA5y6gAAEEHSYA== Date: Tue, 1 Feb 2011 06:59:55 +0000 Message-ID: References: <001301cbc1a0$14df55a0$3e9e00e0$@com> <4D47ABF8.5010301@it.uc3m.es> In-Reply-To: <4D47ABF8.5010301@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] naming a big NAT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 06:56:42 -0000 Is GNAT an option? -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= marcelo bagnulo braun Sent: Monday, January 31, 2011 10:45 PM To: behave@ietf.org Subject: Re: [BEHAVE] naming a big NAT agree with mark El 01/02/11 0:51, Mark Townsley escribi=F3: > I voted CGN. I believe I have seen this and LSN most often in various doc= uments and presentations to date. I'd rather settle on something that is al= ready in circulation, rather than adding another acronym into the mix. > > In terms of LSN vs. CGN, I think the location in the network and how it i= s operated is more important architecturally rather than scale per se. Also= , I wouldn't want to imply that this kind of NAT was somehow inherently sca= lable by putting that in the name. > > I'm sure there are at least as many different views on this as there are = members on the list though. > > - Mark > > PS. Apropos as the last two /8s just went to apnic... > > On Feb 1, 2011, at 12:39 AM, Dan Wing wrote: > >> At IETF79 we were asked to run a survey on naming a big NAT. So here it= is, >> http://www.surveymonkey.com/s/DJSB7ZM >> >> Please vote so we can finally close this issue. >> >> Note: Unfortunately, due to limitations of the SurveyMonkey >> tool, write-ins won't show up for others and if I >> add a write-in after the survey has started, it >> invalidates (destroys) all recorded tallies. >> >> -d >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave