From tom111.taylor@bell.net Sat Jan 1 08:41:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8D53A68D3 for ; Sat, 1 Jan 2011 08:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_13=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 DSaSjUHVMm9h for ; Sat, 1 Jan 2011 08:41:47 -0800 (PST) Received: from blu0-omc1-s8.blu0.hotmail.com (blu0-omc1-s8.blu0.hotmail.com [65.55.116.19]) by core3.amsl.com (Postfix) with ESMTP id E610E3A6914 for ; Sat, 1 Jan 2011 08:41:18 -0800 (PST) Received: from BLU0-SMTP22 ([65.55.116.7]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Jan 2011 08:43:25 -0800 X-Originating-IP: [70.26.23.173] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([70.26.23.173]) by BLU0-SMTP22.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Jan 2011 08:43:24 -0800 Date: Sat, 1 Jan 2011 11:43:27 -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: Guillaume.Leclanche@swisscom.com References: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F58EC451F@sg2019z.corproot.net> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F58EC45CA@sg2019z.corproot.net> In-Reply-To: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F58EC45CA@sg2019z.corproot.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jan 2011 16:43:24.0850 (UTC) FILETIME=[0217D120:01CBA9D3] Cc: v6ops@ietf.org Subject: Re: [v6ops] CPE Prefix Sub-Delegation on LAN X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jan 2011 16:41:48 -0000 Sorry to be a little late on this. Just regarding your final point, RFC 5969 provides a DHCPv4 option for configuration of the 6rd CE, including the prefix. On 22/12/2010 1:27 PM, Guillaume.Leclanche@swisscom.com wrote: >> -----Original Message----- From: Fred Baker >> [mailto:fred@cisco.com] Sent: Wednesday, December 22, 2010 6:12 PM >> ... > > There might be some work to do to say how the dhcpv6 server in the > CPE should get the prefix received from the ISP, also when the ISP is > not using DHCPv6. For example, with 6rd. However, since the 6rd > parameters have to be pre-provisioned or given via DHCP(v4), I can > imagine that there's a way to sort this out without too much pain. > > Guillaume _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From jess8882003@yahoo.com Sun Jan 2 07:33:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7D23A6994 for ; Sun, 2 Jan 2011 07:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_60=1, 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 aw1pmk9YTAM0 for ; Sun, 2 Jan 2011 07:33:55 -0800 (PST) Received: from web114718.mail.gq1.yahoo.com (web114718.mail.gq1.yahoo.com [98.136.183.145]) by core3.amsl.com (Postfix) with SMTP id 368E73A6992 for ; Sun, 2 Jan 2011 07:33:55 -0800 (PST) Received: (qmail 34839 invoked by uid 60001); 2 Jan 2011 15:35:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1293982559; bh=4qSUlkC0NN5kRtbM7A5xQjvvIY08yPpPiTs2joFmdeY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=aIg0PNDnwg3GsnTBjfJwHL0PPXRomPrbcL8euaMyyu2yDe5QH1vd9V5J2gxrXXkCJCqiqyXOhAIbNQfz3/JvC7ysazDkjHh3DMZ+3lFSYP0YXtYEwPe5xr2E27mJ29TIVtdfDd6JbLbcUvcD6g4vZcLPpysI6UqlhWcStHFbhMw= 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:Subject:To:MIME-Version:Content-Type; b=Vlt22+S6Dvr5A3NRQZtKATsU+e20IwNHGDJ/qqqyWZ44tj44l68FPiE+xKt3W5vWM2a7/p1reneXeSfPhKRkbmu3jfcrvY1UfHsQ+CXZPRtnRHEEx0Esnotbtuq1af4iMe6wxSWETUoA4lL68XG2vsDFSzWVxzpSrHj6BNbE9tg=; Message-ID: <267538.34669.qm@web114718.mail.gq1.yahoo.com> X-YMail-OSG: uizuG.YVM1mHTsIo2_1951RueeE4xs4RF5c78yetYZ2erlM 3Wv1IBrMbNRh2Z3yrcvMgm8TDIoE2nIgGzVva8ey479P0anr4c9ccd06syql z9kk4EbYm_SCCN6GwbrqXEQDEDh6Jq4WeFU5aWgGMfLAy5MbapZ7PJlvRjjm OjP.VPf_F_ubJE36.isP5OV6H3bADk3G8cQdaMwA6xfxHXKa.wgpl.oolUts bi.OixtictGh17KQ6jMI2PBA_xSM4H_hovZM3utOcFvr.pdpknCw1Vhfdfe5 jE595TCQssI03tDm6Ul82rXo0_zLmveplSXwgHC0J09xtZYDPJlr9wfmbOz. Ogt2Gv2_oPsbutE5Wrsp83pxKszv6yNFoZNxiskX5DtPZVCb7B8Ax97ydO.G tEaGFUnUN3AuqWfr0 Received: from [99.91.43.47] by web114718.mail.gq1.yahoo.com via HTTP; Sun, 02 Jan 2011 07:35:59 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Sun, 2 Jan 2011 07:35:59 -0800 (PST) From: Jess Ger To: v6ops@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-213292375-1293982559=:34669" Subject: [v6ops] unscribe from the email list X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 15:33:56 -0000 --0-213292375-1293982559=:34669 Content-Type: text/plain; charset=us-ascii Hi please unscribe my email from the email list Jess --0-213292375-1293982559=:34669 Content-Type: text/html; charset=us-ascii
Hi

please unscribe my email from the email list

Jess


--0-213292375-1293982559=:34669-- From joelja@bogus.com Sun Jan 2 07:43:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25293A6991 for ; Sun, 2 Jan 2011 07:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 GBlXnf6+lzd9 for ; Sun, 2 Jan 2011 07:43:57 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 241473A696A for ; Sun, 2 Jan 2011 07:43:56 -0800 (PST) Received: from joelja-mac.local ([12.97.37.130]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p02Fk1dV020961 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 2 Jan 2011 15:46:02 GMT (envelope-from joelja@bogus.com) Message-ID: <4D209DB9.8060300@bogus.com> Date: Sun, 02 Jan 2011 07:46:01 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jess Ger References: <267538.34669.qm@web114718.mail.gq1.yahoo.com> In-Reply-To: <267538.34669.qm@web114718.mail.gq1.yahoo.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] unscribe from the email list X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 15:43:59 -0000 Each message sent to the v6ops mailing list contains the following url. https://www.ietf.org/mailman/listinfo/v6ops which you may use to unsubcribe. On 1/2/11 7:35 AM, Jess Ger wrote: > Hi > > please unscribe my email from the email list > > Jess > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From edward.jankiewicz@sri.com Mon Jan 3 08:48:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0873A69BE for ; Mon, 3 Jan 2011 08:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 IYHa+glO8n5u for ; Mon, 3 Jan 2011 08:48:14 -0800 (PST) Received: from mail1.sri.com (mail1.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id C612D3A68C9 for ; Mon, 3 Jan 2011 08:48:11 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LEG00O5AHFU9Q12@mail.sri.com> for v6ops@ietf.org; Mon, 03 Jan 2011 08:50:19 -0800 (PST) Message-id: <4D21FE53.5090702@sri.com> Date: Mon, 03 Jan 2011 11:50:27 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: IPv6 Ops WG Subject: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:48:17 -0000 Excellent survey article with a realistic view of the motivations for IPv6 and the downside of the delay in implementation. http://www.fcc.gov/Daily_Releases/Daily_Business/2010/db1230/DOC-303870A1.pdf -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From Internet-Drafts@ietf.org Mon Jan 3 10:00:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA4C3A6A13; Mon, 3 Jan 2011 10:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, 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 Yt6XEfwy+SvL; Mon, 3 Jan 2011 10:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C754C3A69DA; Mon, 3 Jan 2011 10:00: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.10 Message-ID: <20110103180001.11829.835.idtracker@localhost> Date: Mon, 03 Jan 2011 10:00:01 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-3177bis-end-sites-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Address Assignment to End Sites Author(s) : T. Narten, et al. Filename : draft-ietf-v6ops-3177bis-end-sites-01.txt Pages : 10 Date : 2011-01-03 RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. Moreover, the document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document obsoletes RFC 3177. Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3177bis-end-sites-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-v6ops-3177bis-end-sites-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-03094633.I-D@ietf.org> --NextPart-- From randy@psg.com Mon Jan 3 15:33:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7B83A6D77 for ; Mon, 3 Jan 2011 15:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 9NYrNuEEsUpq for ; Mon, 3 Jan 2011 15:33:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 1373D3A6D76 for ; Mon, 3 Jan 2011 15:33:17 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PZtvu-0000qo-Nk; Mon, 03 Jan 2011 23:35:22 +0000 Date: Tue, 04 Jan 2011 08:35:21 +0900 Message-ID: From: Randy Bush To: Ed Jankiewicz In-Reply-To: <4D21FE53.5090702@sri.com> References: <4D21FE53.5090702@sri.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:33:19 -0000 > http://www.fcc.gov/Daily_Releases/Daily_Business/2010/db1230/DOC-303870A1.pdf "The Internet Protocol version 4 (IPv4) developed in the late 1970s has the capacity for about 4 billion unique addresses. It would have been hard to imagine in the 1970s that 4 billion addresses were not going to be enough. But by the early 1990s, Internet engineers recognized that the supply of addresses was relatively limited compared to likely demand, and they set to work designing a successor to IPv4. They developed a new Internet Protocol, IPv6, with a vastly increased address space: 340 trillion trillion trillion addresses." it should have added " It would have been hard to imagine in the 1990s that 340 trillion trillion trillion addresses were not going to be enough." i wish i could remember the quote and attribution that no fixed address size has ever been enough. randy From ocl@gih.com Mon Jan 3 16:02:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D553A6E04 for ; Mon, 3 Jan 2011 16:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKehr047bXOO for ; Mon, 3 Jan 2011 16:02:31 -0800 (PST) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2a00:19e8:10:5::b]) by core3.amsl.com (Postfix) with ESMTP id D79373A6E03 for ; Mon, 3 Jan 2011 16:02:30 -0800 (PST) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id E9CB918F3AD; Tue, 4 Jan 2011 00:04:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=BmyrGziCZ W8xjxpPTiuuUrgUq9Y=; b=RDV7irHg1OftLyIV8NcxA1zD0Frp4zwj0SSVa3VKe PaCDY2lw7xcS+cNizkc33lAmSAycA+c7m7NiWrexe3OGlP02ZsjjENadI18IjFJZ YhPQFNahiEQwtKfE1mi8HrEIKuBfH/NQh1/yE/k6jXP3KyRnLwc9WJG7Yhq08ZGR xs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mahalo1; b=kQI LtWQ9iuu214Vep4LYLBuU379m9vG+eKYlkX87p9NAWEi4vbgG89Nqg+uPGJwj7m1 NuzXJY+PvLtcyoKq9l30d9YFH6BE3onfnxNlF8euL4YVFFQabU1/3lDXCebLeJ4l x+GszBhsO4dGQTUcl20bA9mZoU7e7BQMpJka++Yw= Received: from [192.168.1.11] (ANice-151-1-29-177.w83-113.abo.wanadoo.fr [83.113.223.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 2935318F3AC; Tue, 4 Jan 2011 00:04:35 +0000 (GMT) Message-ID: <4D226413.1000608@gih.com> Date: Tue, 04 Jan 2011 01:04:35 +0100 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D21FE53.5090702@sri.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 00:02:32 -0000 On 04/01/2011 00:35, Randy Bush wrote : > i wish i could remember the quote and attribution that no fixed address > size has ever been enough. > So Internet addressing is a gas: it will diffuse readily, spreading apart in order to uniformly fill the space of any container. :-) --=20 Olivier MJ Cr=E9pin-Leblond, PhD http://www.gih.com/ocl.html From randy@psg.com Mon Jan 3 16:04:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD5B3A6E0C for ; Mon, 3 Jan 2011 16:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 oYQIYGQ7dvME for ; Mon, 3 Jan 2011 16:04:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id EE8613A6E0B for ; Mon, 3 Jan 2011 16:04:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PZuPy-0001B3-KF; Tue, 04 Jan 2011 00:06:27 +0000 Date: Tue, 04 Jan 2011 09:06:25 +0900 Message-ID: From: Randy Bush To: Olivier MJ Crepin-Leblond In-Reply-To: <4D226413.1000608@gih.com> References: <4D21FE53.5090702@sri.com> <4D226413.1000608@gih.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 00:04:22 -0000 >> i wish i could remember the quote and attribution that no fixed address >> size has ever been enough. > So Internet addressing is a gas: it will diffuse readily, spreading > apart in order to uniformly fill the space of any container. :-) and the /32s the rirs are allocating to anything that walks are pretty big molecules randy From joelja@bogus.com Mon Jan 3 17:06:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD203A6824 for ; Mon, 3 Jan 2011 17:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.092 X-Spam-Level: X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 KHQk-KgxTnqJ for ; Mon, 3 Jan 2011 17:06:46 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 7595F3A6823 for ; Mon, 3 Jan 2011 17:06:45 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0418nI4023741 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 4 Jan 2011 01:08:49 GMT (envelope-from joelja@bogus.com) Message-ID: <4D227320.1090808@bogus.com> Date: Mon, 03 Jan 2011 17:08:48 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D21FE53.5090702@sri.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 01:06:47 -0000 On 1/3/11 3:35 PM, Randy Bush wrote: >> http://www.fcc.gov/Daily_Releases/Daily_Business/2010/db1230/DOC-303870A1.pdf > > "The Internet Protocol version 4 (IPv4) developed in the late 1970s has > the capacity for about 4 billion unique addresses. It would have been > hard to imagine in the 1970s that 4 billion addresses were not going to > be enough. But by the early 1990s, Internet engineers recognized that > the supply of addresses was relatively limited compared to likely > demand, and they set to work designing a successor to IPv4. They > developed a new Internet Protocol, IPv6, with a vastly increased address > space: 340 trillion trillion trillion addresses." > > it should have added " It would have been hard to imagine in the 1990s > that 340 trillion trillion trillion addresses were not going to be > enough." > > i wish i could remember the quote and attribution that no fixed address > size has ever been enough. There's ~10^80 atoms in the observable universe... some constraints are harder than others to work around. I'm pretty confident that by the time I'm the age you are now that we will have had to do something else, 1982 was a while ago. > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From edward.jankiewicz@sri.com Mon Jan 3 19:29:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588EE3A69B3 for ; Mon, 3 Jan 2011 19:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 QiZo3w-3fV4X for ; Mon, 3 Jan 2011 19:29:28 -0800 (PST) Received: from mail1.sri.com (newmail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id C18043A69B8 for ; Mon, 3 Jan 2011 19:29:28 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LEH00A4LB4KA3N0@mail.sri.com> for v6ops@ietf.org; Mon, 03 Jan 2011 19:31:32 -0800 (PST) Message-id: <4D22949C.3040001@sri.com> Date: Mon, 03 Jan 2011 22:31:40 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: Randy Bush References: <4D21FE53.5090702@sri.com> In-reply-to: Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:29:30 -0000 right up there with: "I think there is a world market for maybe 5 computers" Thomas Watson, Chair IBM, 1943 "There is no reason anyone would want a computer in their home" Ken Olsen, Chairman and founder Digital, 1977 "We don't like their sound, and guitar groups are going out" Decca Records, rejecting the Beatles in 1962 "640K should be more than enough for anybody" Bill Gates, 1981 what is the old quote about "never been a weapon built that hasn't been used"? or the generalization of Parkinson's law: "The demand upon a resource tends to expand as much as the supply of the resource" We can only hope that 340 trillion trillion trillion is enough for a while... On 1/3/2011 6:35 PM, Randy Bush wrote: >> http://www.fcc.gov/Daily_Releases/Daily_Business/2010/db1230/DOC-303870A1.pdf > "The Internet Protocol version 4 (IPv4) developed in the late 1970s has > the capacity for about 4 billion unique addresses. It would have been > hard to imagine in the 1970s that 4 billion addresses were not going to > be enough. But by the early 1990s, Internet engineers recognized that > the supply of addresses was relatively limited compared to likely > demand, and they set to work designing a successor to IPv4. They > developed a new Internet Protocol, IPv6, with a vastly increased address > space: 340 trillion trillion trillion addresses." > > it should have added " It would have been hard to imagine in the 1990s > that 340 trillion trillion trillion addresses were not going to be > enough." > > i wish i could remember the quote and attribution that no fixed address > size has ever been enough. > > randy -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From yiu_lee@cable.comcast.com Mon Jan 3 19:33:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7BE13A69B3 for ; Mon, 3 Jan 2011 19:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.103 X-Spam-Level: X-Spam-Status: No, score=-108.103 tagged_above=-999 required=5 tests=[AWL=0.360, 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 1xut+gyDj4Xf for ; Mon, 3 Jan 2011 19:33:37 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id E33B63A681E for ; Mon, 3 Jan 2011 19:33:36 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.109889967; Mon, 03 Jan 2011 22:36:36 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Mon, 3 Jan 2011 22:35:41 -0500 From: "Lee, Yiu" To: Ed Jankiewicz , Randy Bush Thread-Topic: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC Thread-Index: AQHLq8B1KJpvCMSBwkS+8cpcTTyV6w== Date: Tue, 4 Jan 2011 03:35:40 +0000 Message-ID: In-Reply-To: <4D22949C.3040001@sri.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.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <17F25C11F1916147BC3A566D42CF8768@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:33:38 -0000 >We can only hope that 340 trillion trillion trillion is enough for a >while... > > >Amen!=20 From yiu_lee@cable.comcast.com Mon Jan 3 20:00:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8070F3A69B8 for ; Mon, 3 Jan 2011 20:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.469 X-Spam-Level: X-Spam-Status: No, score=-104.469 tagged_above=-999 required=5 tests=[AWL=-3.334, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, 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 TkEJPT286W+p for ; Mon, 3 Jan 2011 20:00:08 -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 868033A69B5 for ; Mon, 3 Jan 2011 20:00:08 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.20879423; Mon, 03 Jan 2011 21:12:15 -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; Mon, 3 Jan 2011 23:02:10 -0500 From: "Lee, Yiu" To: Tom Taylor Thread-Topic: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC Thread-Index: AQHLq8B1KJpvCMSBwkS+8cpcTTyV65PAgv8A//+tzoA= Date: Tue, 4 Jan 2011 04:02:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <697737FF8BB5A041A7126808FAAD673D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 04:00:09 -0000 Well, when DHCPv6 is getting more popular, we may be able to work around this limitation. However, 18 trillion^2 addresses are still a lot^2. On 1/3/11 10:56 PM, "Tom Taylor" wrote: >But isn't it only 18 trillion trillion because everyone is getting at >least a /64? > >On 03/01/2011 10:35 PM, Lee, Yiu wrote: >> >>> We can only hope that 340 trillion trillion trillion is enough for a >>> while... >>> >>> >>> Amen! >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> From drc@virtualized.org Tue Jan 4 00:45:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C673A6B53 for ; Tue, 4 Jan 2011 00:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSFYvO8xgSnb for ; Tue, 4 Jan 2011 00:45:16 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 4A9403A6B5C for ; Tue, 4 Jan 2011 00:45:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 56086FFCBEF; Tue, 4 Jan 2011 00:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VAu12DxIGsV; Tue, 4 Jan 2011 00:47:20 -0800 (PST) Received: from [10.0.1.3] (cpe-72-130-197-233.hawaii.res.rr.com [72.130.197.233]) by virtualized.org (Postfix) with ESMTP id DDEB4FFCBDE; Tue, 4 Jan 2011 00:47:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Mon, 3 Jan 2011 22:47:17 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <694163C9-D39C-40F5-9544-3FB1FD6733F3@virtualized.org> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 08:45:17 -0000 On Jan 3, 2011, at 6:02 PM, Lee, Yiu wrote: > Well, when DHCPv6 is getting more popular, we may be able to work = around > this limitation. However, 18 trillion^2 addresses are still a lot^2. This is sort of missing the point. Absolute numbers are pretty much = irrelevant. What matters is the rate of consumption. For example, let's say the amount of IPv6 address space that can be = assigned is 2^45 (using the minimum /48 and chopping off 3 bits because = we're only supposed to use 1/8th of the IPv6 address space for global = unicast). If you take the current IPv4 address consumption rate (call = it 200 million a year for sake of argument) and map that into /48s, = you'll see that the current 1/8th of IPv6 address space will last = 2^45/200,000,000 =3D 175,921 years. Even if you increase the rate of = consumption by 1000, it's still 176 years.=20 But this sort of analysis assumes rational (that is, technically = justified) assignment policies. Current RIR policies suggest /48s as = the minimum recommended assignment size. However, as Randy mentions, = current allocations to ISPs (and others) are a minimum of /32, and many = folks are able to justify more. There have been a number of allocations = made by the RIRs according to policy that are shorter than /20. One = might note that there are the same number of /20s in IPv6 as there are = in IPv4. And this is the result of policy processes that are influenced = primarily by technical folks. There is increasing pressure from the = non-technical world (e.g., governments) to use non-technical = justification for IPv6 address space (e.g., "we demand our IPv6 /12 = because we're a nation-state"). I still believe it's unfortunate that we focused on the "32" instead of = the "fixed" part in "fixed 32-bit address" when IPv6 was being defined, = but that's water under the bridge. It does, however, mean technical = folks need to be vigilant about how address policy is defined and by = whom. 640K really wasn't enough for everyone. Regards, -drc From gert@space.net Tue Jan 4 03:50:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099113A6B7A for ; Tue, 4 Jan 2011 03:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 HGVKmeKbj2V8 for ; Tue, 4 Jan 2011 03:50:32 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id DC6463A6B7E for ; Tue, 4 Jan 2011 03:50:29 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id BBA0FF816A for ; Tue, 4 Jan 2011 12:52:35 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 99993F81A2 for ; Tue, 4 Jan 2011 12:52:35 +0100 (CET) Received: (qmail 89168 invoked by uid 1007); 4 Jan 2011 12:52:35 +0100 Date: Tue, 4 Jan 2011 12:52:35 +0100 From: Gert Doering To: David Conrad Message-ID: <20110104115235.GL3695@Space.Net> References: <694163C9-D39C-40F5-9544-3FB1FD6733F3@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <694163C9-D39C-40F5-9544-3FB1FD6733F3@virtualized.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG , "Lee, Yiu" Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 11:50:34 -0000 Hi, On Mon, Jan 03, 2011 at 10:47:17PM -1000, David Conrad wrote: > It does, however, mean technical folks need to be vigilant about how > address policy is defined and by whom. Indeed. OTOH, I'm deeply convinced that the address space in IPv6 is there to be *used*. Bringing over the "conservation is holy!" IPv4 mindset to IPv6 will not do IPv6 any good. So - if we indeed are too wasteful, we'll notice when we have burned FP 001, and then we have 6 more tries to follow the conservationists' advice. Until then, I'd like to enjoy the new freedom. (Yes, /32 is a huge chunk of addresses. OTOH, there's 2^29 /32s in FP001, and I don't see 500 million LIRs appear any time soon. Even if we take up-to-/20-assignments into account, I still do not see a large enough number of correspondingly-sized enterprises around to make this a serious problem - just how many Telcos are there that can warrant a /20? More than 10.000? There's 130.000 /20 in FP001...) Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ietfc@btconnect.com Tue Jan 4 04:12:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE723A6BAF for ; Tue, 4 Jan 2011 04:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 jzbrJSsFL3RZ for ; Tue, 4 Jan 2011 04:12:57 -0800 (PST) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 5333A3A6B7A for ; Tue, 4 Jan 2011 04:12:56 -0800 (PST) Received: from host86-172-77-68.range86-172.btcentralplus.com (HELO pc6) ([86.172.77.68]) by c2bthomr13.btconnect.com with SMTP id BEY22264; Tue, 04 Jan 2011 12:14:57 +0000 (GMT) Message-ID: <008701cbac00$2f387e00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Lee, Yiu" , "Tom Taylor" References: Date: Tue, 4 Jan 2011 12:11:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D230F41.0043, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4D230F44.0221,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 12:12:58 -0000 ----- Original Message ----- From: "Lee, Yiu" To: "Tom Taylor" Cc: "IPv6 Ops WG" Sent: Tuesday, January 04, 2011 5:02 AM > Well, when DHCPv6 is getting more popular, we may be able to work around > this limitation. However, 18 trillion^2 addresses are still a lot^2. True but not necessarily relevant. When I first studied IPv6 all those years ago, I was also active in ATM and it immediately struck me that IPv6 had not left enough room in the interface part for an ATM address, so that an IPv6 address would always be too small. Tom Petch > On 1/3/11 10:56 PM, "Tom Taylor" wrote: > > >But isn't it only 18 trillion trillion because everyone is getting at > >least a /64? > > > >On 03/01/2011 10:35 PM, Lee, Yiu wrote: > >> > >>> We can only hope that 340 trillion trillion trillion is enough for a > >>> while... > >>> > >>> > >>> Amen! > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Internet-Drafts@ietf.org Tue Jan 4 09:45:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559D73A6C1A; Tue, 4 Jan 2011 09:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 TLrU2gxHRtsI; Tue, 4 Jan 2011 09:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8763A6CFD; Tue, 4 Jan 2011 09:45: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: <20110104174502.24487.30214.idtracker@localhost> Date: Tue, 04 Jan 2011 09:45:02 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-incremental-cgn-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 17:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition Author(s) : S. Jiang, B. Carpenter, D. Guo Filename : draft-ietf-v6ops-incremental-cgn-03.txt Pages : 15 Date : 2011-1-4 Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period. This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts, while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive Home Gateway (HG) device are described. Both are re-usable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-incremental-cgn-03.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-v6ops-incremental-cgn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-1-4093852.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Jan 4 11:15:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAC63A6D0E; Tue, 4 Jan 2011 11:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 4LpzeZTtQw80; Tue, 4 Jan 2011 11:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B95C3A6A74; Tue, 4 Jan 2011 11: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.10 Message-ID: <20110104191501.14710.28012.idtracker@localhost> Date: Tue, 04 Jan 2011 11:15:01 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-v6-in-mobile-networks-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Mobile Networks Considerations for IPv6 Deployment Author(s) : R. Koodli Filename : draft-ietf-v6ops-v6-in-mobile-networks-03.txt Pages : 18 Date : 2011-01-04 Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-in-mobile-networks-03.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-v6ops-v6-in-mobile-networks-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-04111303.I-D@ietf.org> --NextPart-- From fred@cisco.com Tue Jan 4 17:18:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562153A679C for ; Tue, 4 Jan 2011 17:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.849 X-Spam-Level: X-Spam-Status: No, score=-109.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, 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 dIjh6JbRL4Ud for ; Tue, 4 Jan 2011 17:18:42 -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 B12A63A66B4 for ; Tue, 4 Jan 2011 17:18:42 -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: Av0EAFxOI02rR7H+/2dsb2JhbACDd6A2c6QKilGOGYEggWUIBQaBPnQEhGiGH4MdgnU X-IronPort-AV: E=Sophos;i="4.60,275,1291593600"; d="scan'208";a="310319037" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2011 01:20:48 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p051Kh7V014404 for ; Wed, 5 Jan 2011 01:20:47 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 04 Jan 2011 17:20:47 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 04 Jan 2011 17:20:47 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <20110104162156.414BC3A6CCE@core3.amsl.com> Date: Tue, 4 Jan 2011 17:20:33 -0800 Message-Id: References: <20110104162156.414BC3A6CCE@core3.amsl.com> To: v6ops v6ops X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] 80th IETF - Working Group/BOF Scheduling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 01:18:44 -0000 It looks like we are starting scheduling for Prague. I have signed us up = for our usual 2.5 and 2 hour meetings. As usual, the ground rules for = getting time on the agenda include=20 - a speaker showing up at the meeting - relevance to the charter, and=20 - a posted internet draft that is new since IETF 79. There is also a sense on the IESG, I'm told, that we should be able to = get agendas together a lot earlier than we have in the past. One comment = I heard asked for an agenda to be posted with the request for a meeting = slot. At this point, I am expecting draft-ietf-v6ops-multihoming-without-nat66 draft-ietf-v6ops-v4v6tran-framework draft-ietf-v6ops-v6-aaaa-whitelisting-implications draft-v6ops-multihoming-without-nat66 draft-wbeebee-v6ops-ipv6-cpe-router-bis draft-wing-v6ops-happy-eyeballs-ipv6 draft-korhonen-v6ops-3gpp-eps draft-v6ops-multihoming-without-nat66, = draft-wing-v6ops-happy-eyeballs-ipv6 should be reposted as = draft-ietf-v6ops-*, please - working group draft. I expect that at this = coming meeting we will find enough meat in cpe-router-bis to adopt it as = well. We collectively need to decide what to do with = draft-korhonen-v6ops-3gpp-eps; of the respondents in the survey, most = felt it was something to work on, but we didn't have a clear consensus = on whether or not to adopt it. I'll start that discussing in a separate = thread in a few moments. At this point, we also have 15 other drafts posted. One will for sure = die (mine); it has accomplished its purpose. Another is likely to be = folded into cpe-router-bis. There was a sense at IETF 79 that there was = value in draft-jankiewicz-v6ops-v4v6biblio, but no clear direction on = where Ed should take it - some thought it should be a working group = document and some thought it should be abandoned. I'll leave that to Ed = for the moment. The comments made in the survey, which I emailed to the = list on 20 November, were inconclusive with respect to the others; I'll = leave it to the authors to tell v6ops-chairs@tools.ietf.org how they = would like to proceed with their drafts. On Jan 4, 2011, at 8:21 AM, IETF Agenda wrote: > ----------------------------------------------------------------- > 80th IETF =CB=86 Prague, Czech Republic > Meeting Dates: March 27-April 1, 2011 > Host: CZ.NIC > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday = mid-afternoon > (15:15). >=20 > We are accepting scheduling requests for all Working Groups and BOFs > starting today. The milestones and deadlines for scheduling-related > activities are as follows: >=20 > NOTE: cutoff dates are subject to change. >=20 > =EF=A3=BF 2010-12-27 (Monday): Working Group and BOF scheduling = begins. To > request a Working Group session, use the IETF Meeting Session Request > Tool.=20 > =EF=A3=BF 2011- 01-31 (Monday): Cutoff date for BOF proposal requests = to Area > Directors at 17:00 PT (01:00 Tuesday, February 1 UTC). To request a = BOF, > please see instructions on Requesting a BOF.=20 > =EF=A3=BF 2011-02-14 (Monday): Cutoff date for requests to schedule = Working Group > meetings at 17:00 PT (01:00 Tuesday, February 15 UTC). To request a > Working Group session, use the IETF Meeting Session Request Tool.=20 > =EF=A3=BF 2011-02-14 (Monday): Cutoff date for Area Directors to = approve BOFs at > 17:00 PT (01:00 Tuesday, February 15 UTC).=20 > =EF=A3=BF 2011-02-24 (Thursday): Preliminary agenda published for = comment.=20 > =EF=A3=BF 2011-02-28 (Monday): Cutoff date for requests to reschedule = Working > Group and BOF meetings 17:00 PT (01:00 Tuesday, March 1 UTC).=20 > =EF=A3=BF 2011-02-28 (Monday): Working Group Chair approval for = initial document > (Version -00) submissions appreciated by 17:00 PT (01:00 Tuesday, = March 1 > UTC).=20 > =EF=A3=BF 2011-03-04 (Friday): Final agenda to be published.=20 > =EF=A3=BF 2011-03-16 (Wednesday): Draft Working Group agendas due by = 17:00 PT > (01:00 Thursday, March 17 UTC), upload using IETF Meeting Materials > Management Tool.=20 > =EF=A3=BF 2011-03-21 (Monday): Revised Working Group agendas due by = 17:00 PT > (01:00 Tuesday, March 22 UTC), upload using IETF Meeting Materials > Management Tool. >=20 > Submitting Requests for Working Group and BOF Sessions >=20 > Please submit requests to schedule your Working Group sessions using = the > "IETF Meeting Session Request Tool," a Web-based tool for submitting = all > of the information that the Secretariat requires to schedule your > sessions. >=20 > The URL for the tool is: >=20 > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi >=20 > Instructions for using the tool are available at: >=20 > http://www.ietf.org/instructions/session_request_tool_instruction.html >=20 > Please send requests to schedule your BOF sessions to agenda@ietf.org.=20= > Please include the acronym of your BOF in the subject line of the = message, > and include all of the information specified in item (4) of = "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) >=20 > Submitting Session Agendas >=20 > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, March 16, 2011 by 17:00 PT = (01:00 > Thursday, March 17 UTC). Revised Working Group agendas are due no = later > than Monday, March 21, 2011 at 17:00 PT (01:00 Tuesday, March 22 UTC).=20= > The proposed agenda for a BOF session should be submitted along with = your > request for a session. Please be sure to copy your Area Director on = that > message. >=20 > Please submit the agendas for your Working Group sessions using the = "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. >=20 > The URL for the tool is: >=20 > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi >=20 > Additional information about this tool is available at: >=20 > http://www.ietf.org/instructions/meeting_materials_tool.html >=20 > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. >=20 > The URL for the "IETF 80 Meeting Materials" Web page is: >=20 > = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D80= >=20 > If you are a Working Group chair, then you already have accounts on = the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both = tools. > If you are a BOF chair who is not also a Working Group chair, then = you > will be given an account on the "IETF Meeting Materials Management = Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience, comprehensive information on requesting meeting > sessions at IETF 80 is presented below: >=20 > 1. Requests to schedule Working Group sessions should be submitted = using > the "IETF Meeting Session Request Tool," a Web-based tool for = submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: >=20 > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi >=20 > Instructions for using the tool are available at: >=20 > http://www.ietf.org/instructions/session_request_tool_instruction.html >=20 > If you require an account on this tool, or assistance in using it, = then > please send a message to ietf-action@ietf.org. If you are unable to = use > the tool, then you may send your request via e-mail to = agenda@ietf.org, > with a copy to the appropriate Area Director(s). >=20 > Requests to schedule BOF sessions must be sent to agenda@ietf.org with = a > copy to the appropriate Area Director(s). >=20 > When submitting a Working Group or BOF session request by e-mail, = please > include the Working Group or BOF acronym in the Subject line. >=20 > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, = CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please read = the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) >=20 > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request must = be > approved by an Area Director. Additional sessions will be assigned, = based > on availability, after Monday, February 28, 2011 at 17:00 PT (01:00 > Tuesday, March 1 UTC), the cut-off date for requests to reschedule a > session. >=20 > 4. You MUST provide the following information before a Working Group = or > BOF session will be scheduled: >=20 > a. Working Group or BOF full name with acronym in brackets:=20 >=20 > b. AREA under which Working Group or BOF appears: >=20 > c. CONFLICTS you wish to avoid, please be as specific as possible: >=20 > d. Expected Attendance: >=20 > e. Special requests: >=20 > f. Number of sessions: >=20 > g. Length of session:=20 > - 1 hour=20 > - 1 1/2 hours > - 2 hours=20 > - 2 1/2 hours >=20 > For more information on scheduling Working Group and BOF sessions, = please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and = Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience please find here a list of the IETF Area = Directors > with their e-mail addresses: >=20 > IETF Chair=20 > Russ Housley >=20 > Applications Area (app) > Alexey Melnikov > Peter Saint-Andre =20 >=20 > Internet Area (int)=20 > Jari Arkko > Ralph Droms =20 >=20 > Operations & Management Area (ops)=20 > Ronald Bonica > Dan Romascanu >=20 > Real-time Applications and Infrastructure Area (rai) > Gonzalo Camarillo > Robert Sparks =20 >=20 > Routing Area (rtg)=20 > Stewart Bryant > Adrian Farrel =20 >=20 > Security Area (sec)=20 > Tim Polk > Sean Turner =20 >=20 > Transport Area (tsv)=20 > Lars Eggert > David Harrington =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 79th IETF Meeting Attendance Number >=20 > Working Group=09 >=20 > 6lowpan - 108 > 6man - 178 > abfab - 50 > alto - 110 > ancp - 26 > apparea (AG) - 74 > armd BOF - 70 > atoca - 37 > autoconf - 29 > avt - 82 > avt (2nd session) - 55 > behave - 103 > bmwg - 15 > ccamp - 100 > ccamp (2nd session) - 79 > codec - 59 > conex - 43 > core - 81 > core (2nd session) - 67 > cuss - 14 > decade - 59 > dhc - 28 > dime - 14 > dispatch - 61 > dnsext - 99 > dnsop - 96 > drinks - 37 > dtnrg (RG) - 22 > eai - 31 > ecrit - 37 > eman - 56 > emu - 21 > fecframe - 8 > forces - 23 > geopriv - 39 > grow - 44 > hiprg (RG) - 44 > hokey - 22 > iddtspec - 13 > idr - 80 > intarea (AG) - 111 > ipfix - 37 > ippm - 23 > ipsecme - 28 > iri - 18 > isis - 52 > isms - 14 > karp - 50 > kidns - 122 > kitten - 31 > krb-wg - 12 > l2vpn - 119 > l3vpn - 92 > lisp - 69 > lwip - 156 > manet - 35 > martini - 36 > mboned - 18 > mext - 69 > mext (second session) - 64 > mif - 114 > mip4 - 10 > mmusic - 50 > mpls - 150 > mpls (2nd session) - 158 > mptcp - 101 > mptcp (2nd session) - 64 > msec - 33 > multimob - 61 > nbs BPF - 101 > nea - 30 > netconf - 42 > netext - 52 > netmod - 28 > nfsv4 - 25 > nfsv4 (second session) - NO SHEETS > opsarea (AG) - 40 > opsawg - 51 > ospf - 53 > p2psip - 58 > pcp - 59 > pim - 47 > pkix - 30 > ppsp - 38 > precis - 31 > pwe3 - 140 > radext - 20 > roll - 72 > rtgarea (AG) - 135 > rtgwg - 56 > saag (AG) - 90 > samrg (RG) - 20 > savi - 67 > scap BOF - 44 > sidr - 68 > sipclf - 19 > sipcore - 57 > siprec - 44 > softwire - 110 > tcpm - 25 > tictoc - 17 > trill - 72 > tsvarea (AG) - 33 > tsvwg - 65 > v6ops - 203 > v6ops (second session) - 159 > vcarddav - 13 > vnrg (RG) - 48 > websec - 101 >=20 From fred@cisco.com Tue Jan 4 17:26:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42803A679C for ; Tue, 4 Jan 2011 17:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.445 X-Spam-Level: X-Spam-Status: No, score=-110.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 LDAX59UZUj8W for ; Tue, 4 Jan 2011 17:26:18 -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 974F43A67B4 for ; Tue, 4 Jan 2011 17:26:18 -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: AkMHAFxOI02rR7H+/2dsb2JhbACWEI4dc6QKmGqFSgSEaIYfgx0 X-IronPort-AV: E=Sophos;i="4.60,275,1291593600"; d="scan'208";a="310321679" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2011 01:28:21 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p051SGd5017975 for ; Wed, 5 Jan 2011 01:28:21 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 04 Jan 2011 17:28:21 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 04 Jan 2011 17:28:21 -0800 From: Fred Baker Date: Tue, 4 Jan 2011 17:28:07 -0800 Message-Id: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 01:26:50 -0000 Question for the assembled throng: What do people want to see happen in = draft-korhonen-v6ops-3gpp-eps? In the SurveyMonkey data, about 37% felt = it was reasonable to work on but should be an individual effort, and = about 58% were willing to take it as a working group draft. Several = people said they had comments and would post them to the list. Please post comments on the list, and if only to tell us how to proceed.= From joelja@bogus.com Tue Jan 4 20:47:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D763A6803 for ; Tue, 4 Jan 2011 20:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=0.462, 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 yLGuywI2U0Tq for ; Tue, 4 Jan 2011 20:47:18 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id EADEE3A67E6 for ; Tue, 4 Jan 2011 20:47:17 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p054nMMJ010613 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 5 Jan 2011 04:49:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4D23F852.20708@bogus.com> Date: Tue, 04 Jan 2011 20:49:22 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 Ops WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 04:47:19 -0000 -------- Original Message -------- Subject: NIST IPv6 document Date: Tue, 04 Jan 2011 20:35:48 -0800 From: Kevin Oberman To: nanog@nanog.org NIST has released SP800-119, "Guidelines for the Secure Deployment of IPv6". While I don't agree with everything in it, it is an excellent overview of IPv6, differences from IPv4, and security advice. While the title sounds like a security document, the security implications are only a part of it. I've not finished reading it, but my first reaction is that this is a good source of information. Well written, fairly detailed (at 188 pages) with lots of references. The PDF is available at: http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From cb.list6@gmail.com Tue Jan 4 21:16:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F483A695B for ; Tue, 4 Jan 2011 21:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, J_CHICKENPOX_13=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 z3-1+o0B9shd for ; Tue, 4 Jan 2011 21:16:55 -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 757C53A67A2 for ; Tue, 4 Jan 2011 21:16:55 -0800 (PST) Received: by qyk34 with SMTP id 34so17039146qyk.10 for ; Tue, 04 Jan 2011 21:19:02 -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=9zRTNylX6SbSmJLY6BtTf1+6OiI3eLYhTzbtsDJQN1I=; b=o4McN9yfv/DdkX89ZxoPeFa16hStQTvPm0avm1G5zZVdJbg7pisVcj6Qt4jfrc6AMN +Lsw09FeQJqxoCNjJ8V3M/33YqlWnKuC7uyW/yV1kyUj7bsMJwjGZOj7oj6i7V58vWqR oIwsUdhYbDVYIJwnrN2XZUFgtG6pCQ5qnaXo8= 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=i+RtOKj0ZsSbUmoQfYzBFv/dC1uxI2aWHqONxds+Cyu7dk0KpKlzIxlG9v8v9T2LKl upbAjj+sEfENLV4Lm9aFv0n8vJcCRJnNdVvxDXrH/7SEd9lXC8QUU0dni0FF3u0RjfBQ HnGK9+/Twb+5rpcJ9us3FIsP/sLZ3MJ2cTZK0= MIME-Version: 1.0 Received: by 10.229.91.145 with SMTP id n17mr992751qcm.258.1294204741905; Tue, 04 Jan 2011 21:19:01 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 4 Jan 2011 21:19:01 -0800 (PST) In-Reply-To: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> Date: Tue, 4 Jan 2011 21:19:01 -0800 Message-ID: From: Cameron Byrne To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , Basavaraj.Patil@nokia.com Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 05:16:56 -0000 I think it should be taken in as a WG doc, it is good for the folks in this group to be involved with 3GPP model. The draft does need a lot of work and does not represent the current world as i see it. If the draft cannot be fixed, it should be abandoned. It may be best if the document simply explains the 3GPP model in IETF terms and stays away from service deployment recommendations. If it must make service deployment recommendations, then it should reference the joint 3GPP-IETF in meeting in SF where the conclusions was that DS and IPv6-only were the correct paths for moving forward, not just DS. Notes on the draft: 1. In the introduction section "However, the support for IPv6 in commercially deployed networks is nearly non-existent." This is now not true. Verizon Wireless in the USA has production IPv6 for their LTE network. Furthermore, others like T-Mobile USA have substantial beta deployments ... but the crux of the issue is that Verizon is big, they have it deployed for every LTE device they sell in their stores today and support. I suggest changing the wording to something more representative of the world I see. Perhaps use : "However, deployment have been limited in the last 10 years with GSM and UMTS. LTE represents a fresh deployment and new challenges to be solved. The IPv4 exhaust issue and relevance of always-on any-to-any communication is driving the real business need for IPv6 and IPv6 is actively being deployed in some of the first and largest LTE networks." 2. In section 6.1, this statement is made without any qualification or explanation: "The approach of having parallel IPv4 and IPv6 type of PDP contexts open is not optimal, because two PDP contexts require double the signaling and consume more network resources than a single PDP context. However, these costs and complexities are lesser than what other transition solutions would incur" Please explain this cost and complexity comparison you have done, reverse it, or remove it. I have a pretty clean real money case for single stack + NAT being the same cost regardless of IPv4-only or IPv6-only and NAT44 or NAT64. Dual stack still requires NAT44 and double the PDP in this context. 3. In section 7 "This can be achieved by upgrading the network to support = IPv6 while continuing to maintain IPv4 legacy. Dual-stack capability in the network and devices for the foreseeable future at least is a pragmatic solution." I agree with the first sentence, but not with the 2nd. These 2 sentences are not as tightly coupled as it sounds. And, perhaps the detail is that the operator can support IPv4-only services to support existing users and can support IPv6-only services for new users / services. But, i don't see the benefit to users (they don't care, as long as facebook works), operators (who are not willing to pay 2x PDP or extra support costs), or the internet at large (as long as v4 works, no change/investment/support for v6 on the applications end). 4. Section 8 "Direct host to host connectivity becomes complicated, unless the hosts are within the same private address range pool and/or anchored to the same gateway, referrals using IP addresses will have issues and so forth" Yep. "Standard NAT44 functionality enables the communication between hosts that are assigned the same IPv4 address but belong to different zones, yet are part of the same operator domain." Nope. Remeber, VoLTE? And many LTE providers are staying v4 only. This works well with IMS? Or can i only call people in my region who are also on 4G and on ipv6? Also, sometimes mobile operators do billing and authentication based on the IP address, so there's snag when there is one billing system and 2x ipv4 =3D 10.99.88.88 users. 5. section 8.3, you may want to reference the happy eyeballs and AAAA whitelisting work as challenges to supporting a dual-stack network 6. section 11 " The authors believe that transitioning to IPv6 in 3GPP networks can be achieved without disruption to legacy devices, networks and services only by taking a dual-stack approach to deployment." Have you seen Jari's work on IPv6-only? Or the T-Mobile USA beta ipv6-only? My concern here is that you are saying the dual-stack services is the "only" way, which is clearly not the case. I highly object to this wording as it is simply not true and i run a network that is testament to that. Further "Enabling IPv6 connectivity in the 3GPP networks by itself will provide some degree of relief to the IPv4 address space as many of the applications and services can start to work over IPv6 right away." How does my web page loading over IPv6 on a dual-stack phone provide "relief to the IPv4 address space"? I still am using an IPv4 address. Please elaborate. And, "However without comprehensive testing of different applications and solutions that exist today and are widely used, for their ability to operate over IPv6 PDN connections, an IPv6 only access would cause disruptions. Hence we recommend adopting the dual-stack approach to IPv6 transition in 3GPP networks." Raj, you have the phone that is IPv6-only for 9 months now. Do the comprehensive testing and let us know. This statement directly contradicts Jari's work on Symbian in draft-arkko-ipv6-only-experience. Cameron On Tue, Jan 4, 2011 at 5:28 PM, Fred Baker wrote: > Question for the assembled throng: What do people want to see happen in d= raft-korhonen-v6ops-3gpp-eps? In the SurveyMonkey data, about 37% felt it w= as reasonable to work on but should be an individual effort, and about 58% = were willing to take it as a working group draft. Several people said they = had comments and would post them to the list. > > Please post comments on the list, and if only to tell us how to proceed. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Tue Jan 4 23:12:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E923A6B45 for ; Tue, 4 Jan 2011 23:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 ctTyLEy0sLjS for ; Tue, 4 Jan 2011 23:12:41 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id DFE843A6B42 for ; Tue, 4 Jan 2011 23:12:40 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F23489C; Wed, 5 Jan 2011 08:14:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EF6889A; Wed, 5 Jan 2011 08:14:45 +0100 (CET) Date: Wed, 5 Jan 2011 08:14:45 +0100 (CET) From: Mikael Abrahamsson To: Cameron Byrne In-Reply-To: Message-ID: References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Basavaraj.Patil@nokia.com Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 07:12:42 -0000 On Tue, 4 Jan 2011, Cameron Byrne wrote: > And, "However without > comprehensive testing of different applications and solutions that > exist today and are widely used, for their ability to operate over > IPv6 PDN connections, an IPv6 only access would cause disruptions. > Hence we recommend adopting the dual-stack approach to IPv6 > transition in 3GPP networks." > > Raj, you have the phone that is IPv6-only for 9 months now. Do the > comprehensive testing and let us know. This statement directly > contradicts Jari's work on Symbian in > draft-arkko-ipv6-only-experience. My opinion right now is that we're going to have to do it all to support different type of mobile devices. IPv6 only access with: NAT64+DNS64, NAT64+BIH, 4RD+NAT44 IPv4 only access with: 6RD+NAT44 Dual PDP (since we can control that within our own network): The bad thing here is that the failure mode we've seen so far on dual PDP context is that both contexts just stop forwarding traffic, they don't get torn down when you roam into a network that doesn't support it. IPv6 only access doesn't work in real life. It does work for quite a few things on Symbian and fewer other things on Maemo and I guess also few things on Windows 7 (if looking at the whole program ecosystem). I have yet to test Windows 7, but since Skype doesn't work, you have a very important application right there. I do agree that dual stack by means of dual PDP context is really hard in real life to do in the current mobile ecosystem. It can be compared to deploying a solution based on /25 IPv4 space in todays Internet routing system, it works for some, but you won't be able to talk to everybody because of general /24 filtering. -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Wed Jan 5 05:07:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6558B3A6E2A for ; Wed, 5 Jan 2011 05:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 XrApO+TckgNT for ; Wed, 5 Jan 2011 05:07:47 -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 85FA93A6BBB for ; Wed, 5 Jan 2011 05:07:47 -0800 (PST) Received: by qyj19 with SMTP id 19so16586165qyj.10 for ; Wed, 05 Jan 2011 05:09:54 -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=ZtNS3I4sVinCNp8ezruqaar6H/vHc7hB2+blJ+UgtvE=; b=VsgWKp5HmmN2Z8mlbbY5tpoc9Vkxcspp7e2ehRNWxnyxJLkhN5uRy4A7OQHKHwAEik 9Gka5IUUHj8sqy3LKsvHlZ7DBCwqQWGVz+Zbdx7tNYyY6ZUcpPa0xNc9TXiY0mBHDWQg FmnRCsS9SfO097eIWUz1B8te1yednfYR9inC4= 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=cmqFvgeFAlZVN5KvxccD+cJhCvOlYwdbLj3LbrX33G3DNG8Pb97LAs9bAYb1yzqgfl 4Kz7nWltDkVV2QfKsnj6JVtomWc4kl3lPNiG0KKfZi8o/Z8F8D7qNeHCoiPEkSsdoGPj UKIwPN1OSULqnjogeLIcTXIMa9Tpo7d0uteL4= MIME-Version: 1.0 Received: by 10.229.250.135 with SMTP id mo7mr20151870qcb.30.1294232994002; Wed, 05 Jan 2011 05:09:54 -0800 (PST) Received: by 10.229.224.79 with HTTP; Wed, 5 Jan 2011 05:09:53 -0800 (PST) In-Reply-To: References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> Date: Wed, 5 Jan 2011 05:09:53 -0800 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , Basavaraj.Patil@nokia.com Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 13:07:49 -0000 On Tue, Jan 4, 2011 at 11:14 PM, Mikael Abrahamsson wrot= e: > On Tue, 4 Jan 2011, Cameron Byrne wrote: > >> And, "However without >> =A0comprehensive testing of different applications and solutions that >> =A0exist today and are widely used, for their ability to operate over >> =A0IPv6 PDN connections, an IPv6 only access would cause disruptions. >> =A0Hence we recommend adopting the dual-stack approach to IPv6 >> =A0transition in 3GPP networks." >> >> Raj, you have the phone that is IPv6-only for 9 months now. =A0Do the >> comprehensive testing and let us know. =A0This statement directly >> contradicts Jari's work on Symbian in >> draft-arkko-ipv6-only-experience. > > My opinion right now is that we're going to have to do it all to support > different type of mobile devices. > +1. As many have noted, there is no silver bullet, including dual-stack. Some methods fit better than others for different, users, apps, OSs, operators. Trade-off's MUST be made. > IPv6 only access with: > NAT64+DNS64, NAT64+BIH, 4RD+NAT44 > > IPv4 only access with: > 6RD+NAT44 > > Dual PDP (since we can control that within our own network): The bad thin= g > here is that the failure mode we've seen so far on dual PDP context is th= at > both contexts just stop forwarding traffic, they don't get torn down when > you roam into a network that doesn't support it. > > IPv6 only access doesn't work in real life. It does work for quite a few > things on Symbian and fewer other things on Maemo and I guess also few > things on Windows 7 (if looking at the whole program ecosystem). I have y= et > to test Windows 7, but since Skype doesn't work, you have a very importan= t > application right there. > > I do agree that dual stack by means of dual PDP context is really hard in > real life to do in the current mobile ecosystem. It can be compared to > deploying a solution based on /25 IPv4 space in todays Internet routing > system, it works for some, but you won't be able to talk to everybody > because of general /24 filtering. > > -- > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se > From kaeo@merike.com Wed Jan 5 09:18:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6423A6C07 for ; Wed, 5 Jan 2011 09:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_NUMERIC_HELO=2.067] 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 hQGLIoIttARl for ; Wed, 5 Jan 2011 09:18:13 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by core3.amsl.com (Postfix) with ESMTP id D0A1A3A6AF4 for ; Wed, 5 Jan 2011 09:18:12 -0800 (PST) Received: from 23.118.247.10.in-addr.arpa (mba0f36d0.tmodns.net [208.54.15.186]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p05HKIor012737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jan 2011 09:20:19 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Merike Kaeo In-Reply-To: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> Date: Wed, 5 Jan 2011 09:20:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 17:18:14 -0000 It seems to me to be a useful document for updating what was described = in RFC 3574 - Transition Scenarios for 3GPP Networks. Would this doc be = considered an update and obsolete RFC 3574? I would hope any deployment recommendations and/or description be fully = vetted by the folks deploying in these environments...some comments have = already been started by operators which is great to see. I am mildly wondering about the intersection between this draft and with = draft-ietf-v6ops-v6-in-mobile-networks-03.txt. The latter doesn't seem = to be referenced at all and I would hope that the text in this new draft = would not have any conflicts with existing working group document. I = haven't had time to compare in detail but will offer some comments later = in the week if still warranted. Main jist - I would encourage this work to become working group item. - merike On Jan 4, 2011, at 5:28 PM, Fred Baker wrote: > Question for the assembled throng: What do people want to see happen = in draft-korhonen-v6ops-3gpp-eps? In the SurveyMonkey data, about 37% = felt it was reasonable to work on but should be an individual effort, = and about 58% were willing to take it as a working group draft. Several = people said they had comments and would post them to the list. >=20 > Please post comments on the list, and if only to tell us how to = proceed. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Wed Jan 5 09:44:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390893A6C69 for ; Wed, 5 Jan 2011 09:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 vPPtT4F157Ih for ; Wed, 5 Jan 2011 09:44:23 -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 2B69E3A6AF4 for ; Wed, 5 Jan 2011 09:44:23 -0800 (PST) Received: by qyk34 with SMTP id 34so17682662qyk.10 for ; Wed, 05 Jan 2011 09:46:30 -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=/+qTfm10aJuD9xNVKos4vhueSS5GjbP/ok5xV/FokuY=; b=nP1ZZX2mbpQ0nArf3PU61P2gl+leB5amO/pbwkGXYxM6GFYJsb1ewnh71wMcV5r7PW GhQtVObkN4axOrNvUIU+vVcXJTOcykS7X5noqBQzY1vfxkpLqueUnN5eMzmMoOGFhdWY NZcI1I7xJNDfBOXmvlDnHKPJgVds3qTJqNiHE= 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=MbfikowWHxTplSnwKWnQq/go9C6gVT+L6KmL+TL8STOnmr1YOfklgUGNevzu5ooh92 o+sT+SKz03SdEM+O3OEEExQOzHH6UAYTZEQddD5MMLLdCz4toh5NdX8L/CwcnELhJKLH gjs4iOy8ygeQgFxRH4cTFemjWMLfPqoxJQt9M= MIME-Version: 1.0 Received: by 10.229.128.228 with SMTP id l36mr19774992qcs.296.1294249589768; Wed, 05 Jan 2011 09:46:29 -0800 (PST) Received: by 10.229.224.79 with HTTP; Wed, 5 Jan 2011 09:46:29 -0800 (PST) In-Reply-To: References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> Date: Wed, 5 Jan 2011 09:46:29 -0800 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , Basavaraj.Patil@nokia.com Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 17:44:24 -0000 On Tue, Jan 4, 2011 at 11:14 PM, Mikael Abrahamsson wrot= e: > On Tue, 4 Jan 2011, Cameron Byrne wrote: > >> And, "However without >> =A0comprehensive testing of different applications and solutions that >> =A0exist today and are widely used, for their ability to operate over >> =A0IPv6 PDN connections, an IPv6 only access would cause disruptions. >> =A0Hence we recommend adopting the dual-stack approach to IPv6 >> =A0transition in 3GPP networks." >> >> Raj, you have the phone that is IPv6-only for 9 months now. =A0Do the >> comprehensive testing and let us know. =A0This statement directly >> contradicts Jari's work on Symbian in >> draft-arkko-ipv6-only-experience. > > My opinion right now is that we're going to have to do it all to support > different type of mobile devices. > > IPv6 only access with: > NAT64+DNS64, NAT64+BIH, 4RD+NAT44 > > IPv4 only access with: > 6RD+NAT44 > > Dual PDP (since we can control that within our own network): The bad thin= g > here is that the failure mode we've seen so far on dual PDP context is th= at > both contexts just stop forwarding traffic, they don't get torn down when > you roam into a network that doesn't support it. > > IPv6 only access doesn't work in real life. It does work for quite a few > things on Symbian and fewer other things on Maemo and I guess also few > things on Windows 7 (if looking at the whole program ecosystem). I have y= et > to test Windows 7, but since Skype doesn't work, you have a very importan= t > application right there. > Here is some IPv6-only win7 testing i did about 9 months ago Common application http://www.youtube.com/watch?v=3DczDvrNKKzpU Common web sites http://www.youtube.com/watch?v=3DczDvrNKKzpU I don't use Skype, so i did not test it. This is obviously not comprehensive testing, but i wanted to share some of the basic capabilities. Regarding Skype, we cannot let applications hold back progress. IMHO, we cannot let "a good service" be the enemy of a "perfect service". Cameron > I do agree that dual stack by means of dual PDP context is really hard in > real life to do in the current mobile ecosystem. It can be compared to > deploying a solution based on /25 IPv4 space in todays Internet routing > system, it works for some, but you won't be able to talk to everybody > because of general /24 filtering. > > -- > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se > From remi.despres@free.fr Wed Jan 5 09:59:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1132B3A6C39 for ; Wed, 5 Jan 2011 09:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 xnZWxNB+Gz1V for ; Wed, 5 Jan 2011 09:59:04 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id E71D93A681C for ; Wed, 5 Jan 2011 09:59:03 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 26AD5700009B; Wed, 5 Jan 2011 19:01:10 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id B8641700008B; Wed, 5 Jan 2011 19:01:09 +0100 (CET) X-SFR-UUID: 20110105180109755.B8641700008B@msfrf2319.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: Date: Wed, 5 Jan 2011 19:01:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06E8E52B-AC77-4006-B552-8AA71AD8D694@free.fr> References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) Cc: Laurent Toutain Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 17:59:05 -0000 Hi all, 1. Le 5 janv. 2011 =E0 08:14, Mikael Abrahamsson a =E9crit : > ... > My opinion right now is that we're going to have to do it all to = support different type of mobile devices. >=20 > IPv6 only access with: > NAT64+DNS64, NAT64+BIH, 4RD+NAT44 >=20 > IPv4 only access with: > 6RD+NAT44 +1 Yet, this isn't the current 3GPP view. Consequently, IMHO: - EITHER draft-Korhonen proceeds as purely informational on 3GPP current = architecture, - OR it proceeds with authors' opinion on what to do =3D> it should tell = HOW to offer DS service to mobile devices. =20 2. > Dual PDP (since we can control that within our own network): The bad = thing here is that the failure mode we've seen so far on dual PDP = context is that both contexts just stop forwarding traffic, they don't = get torn down when you roam into a network that doesn't support it. >=20 > IPv6 only access doesn't work in real life. It does work for quite a = few things on Symbian and fewer other things on Maemo and I guess also = few things on Windows 7 (if looking at the whole program ecosystem). I = have yet to test Windows 7, but since Skype doesn't work, you have a = very important application right there. >=20 > I do agree that dual stack by means of dual PDP context is really hard = in real life to do in the current mobile ecosystem. It can be compared = to deploying a solution based on /25 IPv4 space in todays Internet = routing system, it works for some, but you won't be able to talk to = everybody because of general /24 filtering. If these 3 points do describe constraints to be faced, they can be = summarized as: - v4PDP + v6PDP has significant problems - v6PDP + NAT64 has significant limitations for mobile devices that need = the DS service - v4v6PDP is significantly hard in real life=20 Then, the solution that remains for rapid DS service in mobile hosts is: - v4PDP + 6rd=20 (With my apologies to those who don't like my comments about what 6rd = does) For a early v4PDP + 6rd trial, AFAIK: - Some host OS supporting 6rd should soon be available (at least with = Linux Ubuntu at Telecom Bretagne).=20 - Using these in PCs having 3G USB keys should be feasible - These mobile PCs can then have a DS service with any operator that . supports at least one 6rd relay . then configures the 6rd option in its DHCP server(s). For production, adding 6rd support in DS-capable phones shouldn't be = difficult if there is the will. Regards, RD =20 =20 From brian.e.carpenter@gmail.com Wed Jan 5 11:56:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FFAE3A6C78 for ; Wed, 5 Jan 2011 11:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.37 X-Spam-Level: X-Spam-Status: No, score=-103.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 S2TFv08qzIHb for ; Wed, 5 Jan 2011 11:56:34 -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 4923D3A6C17 for ; Wed, 5 Jan 2011 11:56:34 -0800 (PST) Received: by fxm9 with SMTP id 9so15428572fxm.31 for ; Wed, 05 Jan 2011 11:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=llBN+0acOE4ReOZLFmh+kaZpKO2IqijTyn7ZOYHnyAo=; b=cZeF6JYAeTtRjk1sqjwl3Qjtdm1tUzeLo4L+0sQjYkY4WGWXl8PrnKukiAEgGr2sik Xbv4l+YwvIPgr2BE1zPI+MsjkWMblDQnHs801m14blSOZyMNWnE58VQKOszC/RcUL+Rd YmvfrrSSzghIc6sTp9RlqP3nckpzVa2IxbRLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=HQaB/RKK2mrCobU8RO6FqPoAGZwUC58q1DKX93vNE02Zjzu9LYcBvX11eRVVzeQbrs M60d9tsudN+QQqdFmX9O6ZjbifK7j2FJ5hAT9j8mg6axFCIF5b40+S+8MW1bAjFdVcP0 e358y/WDd+yIkZNzqujsfsYhEkzHUDwF6ta7o= Received: by 10.223.79.6 with SMTP id n6mr2559929fak.122.1294257520757; Wed, 05 Jan 2011 11:58:40 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n1sm5620913fam.16.2011.01.05.11.58.37 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 11:58:39 -0800 (PST) Message-ID: <4D24CD6C.1090209@gmail.com> Date: Thu, 06 Jan 2011 08:58:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel Jaeggli References: <4D23F852.20708@bogus.com> In-Reply-To: <4D23F852.20708@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:56:35 -0000 Hmm. This is the document of which I wrote a few months ago on another list: > Except that this is truly obnoxious and paranoid: > >> > Organizations that are not yet deploying IPv6 should implement the following recommendations: >> > >> > * Block all IPv6 traffic, native and tunneled, at the organization's firewall. Both incoming and outgoing traffic should be blocked. Regards Brian On 2011-01-05 17:49, Joel Jaeggli wrote: > > -------- Original Message -------- > Subject: NIST IPv6 document > Date: Tue, 04 Jan 2011 20:35:48 -0800 > From: Kevin Oberman > To: nanog@nanog.org > > NIST has released SP800-119, "Guidelines for the Secure Deployment of > IPv6". While I don't agree with everything in it, it is an excellent > overview of IPv6, differences from IPv4, and security advice. While the > title sounds like a security document, the security implications are > only a part of it. > > I've not finished reading it, but my first reaction is that this is a > good source of information. Well written, fairly detailed (at 188 pages) > with lots of references. > > The PDF is available at: > http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf From behcetsarikaya@yahoo.com Wed Jan 5 12:06:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5568D3A6D01 for ; Wed, 5 Jan 2011 12:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 3bTPVSJVHZQS for ; Wed, 5 Jan 2011 12:06:46 -0800 (PST) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by core3.amsl.com (Postfix) with SMTP id 507A43A6C78 for ; Wed, 5 Jan 2011 12:06:46 -0800 (PST) Received: from [98.139.91.67] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 20:08:50 -0000 Received: from [98.139.91.24] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 20:08:50 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 20:08:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 919550.87793.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 79202 invoked by uid 60001); 5 Jan 2011 20:08:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294258130; bh=dEa5V7y0q+cZuaM5AdZQDiNPC7+8dDDNDh3xyvZqzaI=; 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=SgiapZv4m9OTYYFopMTtZeXDTpIYvkIZ9uPk/BZMmfMf5LvhtFD+iScBfds2gUC2hqgx5bbJ35mo+WP8ngoc1rMECuGvLaGxMNO8DntqIOum5yM/Lti1bORr5WTQc9ugU0LJ5z2Hv+PsF/4OsCuBk8mfj115cDyPjWlfw8g80/0= 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=NGmlj0GQjnxHKMZa01t6BnxMtzildFM3ipzj3764i3CxBNCBZHGRKzEWWFq8+ijuVHScgJYqX3Y3ThU9xcukyHX0484bMge3xtuD1mn7d7fbW/2EaNtczo/w/10oWOMS2cr4+Lk0f1qYDdy46jx0e7JAlLJeJgQtLrSV5aYsUyw=; Message-ID: <622469.77868.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: FzyZ1uMVM1nezcJmkjm8x9qWcEBZOlRvl1mkkaR322SAcnp kxunYcHEWz23bgaQ3qBQDUUAzXO28TPlmG7Pj7wJA0XR7KMEtMYI18AVjw7e nQVaGkmYfVbSPdNwoQ9B..vAYHn8_m8WgriveV67eToNFpZPvP6agfT0I18F wlpcBcri_BinnyuMZymaOVQE8Gn5v.4r.08QGVjoPCNid9paJdUc75YtnOPX ZnAZ7tMHgK7kWMfC4NPFMFkAD.pvbSQ0oggHD4ajdbf5HJLfw5Q_UckW9jpq trOuBpf7zAt8Mfrr6UOZ94_7ftYm69sPaW0fGp4SOD7MrFNIyXcDufPpQbg1 Ybk5vSUW5qsXFDg6rPiD8F5vAlT8w0tVBjJtbPs9TZei2nwiZk1eJwBH91pZ N_tKVPu0Bm9lZ Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 05 Jan 2011 12:08:50 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> Date: Wed, 5 Jan 2011 12:08:50 -0800 (PST) From: Behcet Sarikaya To: Cameron Byrne , Mikael Abrahamsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:06:47 -0000 To my knowledge, this draft (and also draft-sarikaya-v6ops-prefix-delegation ) is in AD-sponsored track. Of course, reviews are always welcome. Behcet ----- Original Message ---- > From: Cameron Byrne > To: Mikael Abrahamsson > Cc: IPv6 Ops WG ; Basavaraj.Patil@nokia.com > Sent: Wed, January 5, 2011 11:46:29 AM > Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here > > On Tue, Jan 4, 2011 at 11:14 PM, Mikael Abrahamsson wrote: > > On Tue, 4 Jan 2011, Cameron Byrne wrote: > > > >> And, "However without > >> comprehensive testing of different applications and solutions that > >> exist today and are widely used, for their ability to operate over > >> IPv6 PDN connections, an IPv6 only access would cause disruptions. > >> Hence we recommend adopting the dual-stack approach to IPv6 > >> transition in 3GPP networks." > >> > >> Raj, you have the phone that is IPv6-only for 9 months now. Do the > >> comprehensive testing and let us know. This statement directly > >> contradicts Jari's work on Symbian in > >> draft-arkko-ipv6-only-experience. > > > > My opinion right now is that we're going to have to do it all to support > > different type of mobile devices. > > > > IPv6 only access with: > > NAT64+DNS64, NAT64+BIH, 4RD+NAT44 > > > > IPv4 only access with: > > 6RD+NAT44 > > > > Dual PDP (since we can control that within our own network): The bad thing > > here is that the failure mode we've seen so far on dual PDP context is that > > both contexts just stop forwarding traffic, they don't get torn down when > > you roam into a network that doesn't support it. > > > > IPv6 only access doesn't work in real life. It does work for quite a few > > things on Symbian and fewer other things on Maemo and I guess also few > > things on Windows 7 (if looking at the whole program ecosystem). I have yet > > to test Windows 7, but since Skype doesn't work, you have a very important > > application right there. > > > > Here is some IPv6-only win7 testing i did about 9 months ago > > Common application http://www.youtube.com/watch?v=czDvrNKKzpU > > Common web sites http://www.youtube.com/watch?v=czDvrNKKzpU > > I don't use Skype, so i did not test it. This is obviously not > comprehensive testing, but i wanted to share some of the basic > capabilities. Regarding Skype, we cannot let applications hold back > progress. IMHO, we cannot let "a good service" be the enemy of a > "perfect service". > > Cameron > > > I do agree that dual stack by means of dual PDP context is really hard in > > real life to do in the current mobile ecosystem. It can be compared to > > deploying a solution based on /25 IPv4 space in todays Internet routing > > system, it works for some, but you won't be able to talk to everybody > > because of general /24 filtering. > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Wed Jan 5 19:32:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B29E3A6DD5 for ; Wed, 5 Jan 2011 19:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.389 X-Spam-Level: X-Spam-Status: No, score=-103.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 HUM5AT97DJ9P for ; Wed, 5 Jan 2011 19:32:50 -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 5D3C93A67E2 for ; Wed, 5 Jan 2011 19:32:50 -0800 (PST) Received: by qyj19 with SMTP id 19so17331978qyj.10 for ; Wed, 05 Jan 2011 19:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MWN6fl2LTzNIHL5b9NkNhkTMOQDlRNcPuATnr+NFXF8=; b=sf+piSZZ6Ce+sNiPg0a0jJHsjB5omBOsU4mu22lzYmKIurAn3p4GjT6+oDULcOC/6W ZEVb8NWSiumgxeWRDa/1D9M2m6K+5rokRTEAWF4q3o2wkVa4eVRZZTINYxB5EFagglLc R2xskFL+m2eXhDMIJyTnZLfMxYt5mTTCJ10vs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=TsN9xcxM66rnmPH3CVvR0x8eioiIocjYRCC6DrYRHiVgjO3I7Oxffdpt/Wsu9HbFDq Bqa3CQlw3LUAOpAXr1mWX4xqU8iEcKpwxf2Xo8h7jbalvTm1FmLB5uIlOdGM+peUIlRD ZcL03yX/+ixc56devL0ZWDHquYo/W3iLCSGKc= Received: by 10.224.61.10 with SMTP id r10mr22365686qah.105.1294284896989; Wed, 05 Jan 2011 19:34:56 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g28sm14075863qck.13.2011.01.05.19.34.54 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 19:34:56 -0800 (PST) Message-ID: <4D25384E.40501@gmail.com> Date: Thu, 06 Jan 2011 16:34:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <20110104162156.414BC3A6CCE@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops Subject: Re: [v6ops] 80th IETF - Working Group/BOF Scheduling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 03:32:51 -0000 Hi Fred, I and a couple of others are working on something that starts like this: draft-carpenter-v6ops-6to4-teredo-advisory-00 Abstract This document provides advice to network operators about deployment of two techniques for automatic tunneling of IPv6 over IPv4, namely 6to4 and Teredo. It is principally addressed to Internet Service Providers, including those that do not yet support IPv6. Content providers are also covered. The intention of the advice is to minimise both user dissatisfaction and help desk calls. I'm afraid I don't have more to offer at this time (the document is mainly empty beyond that point) but assuming we can get it out before the cutoff, I'd like to ask for a slot. I have no doubt it will cross reference draft-ietf-v6ops-v6-aaaa-whitelisting-implications and draft-wing-v6ops-happy-eyeballs-ipv6, but it is a distinct topic. Brian From fred@cisco.com Wed Jan 5 19:49:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133943A6E58 for ; Wed, 5 Jan 2011 19:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 FhjolCXfoDQU for ; Wed, 5 Jan 2011 19:49:43 -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 A3A113A6896 for ; Wed, 5 Jan 2011 19:49:43 -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: AvsEAHDLJE2rR7Ht/2dsb2JhbACkHXOmGpg+hUwEhGiGIoMf X-IronPort-AV: E=Sophos;i="4.60,281,1291593600"; d="scan'208";a="396577813" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Jan 2011 03:51:50 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p063pjIi013518; Thu, 6 Jan 2011 03:51:50 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 05 Jan 2011 19:51:50 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 05 Jan 2011 19:51:50 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D25384E.40501@gmail.com> Date: Wed, 5 Jan 2011 19:51:31 -0800 Message-Id: <7E3D96A9-8784-4563-B283-3C8D7F61D561@cisco.com> References: <20110104162156.414BC3A6CCE@core3.amsl.com> <4D25384E.40501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops Subject: Re: [v6ops] 80th IETF - Working Group/BOF Scheduling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 03:49:46 -0000 Do we really need a fourth document on the subject of teredo stuff? What = are you covering that hasn't already been covered? On Jan 5, 2011, at 7:34 PM, Brian E Carpenter wrote: > Hi Fred, >=20 > I and a couple of others are working on something that starts like = this: >=20 > draft-carpenter-v6ops-6to4-teredo-advisory-00 >=20 > Abstract >=20 > This document provides advice to network operators about deployment of = two > techniques for automatic tunneling of IPv6 over IPv4, namely 6to4 and = Teredo. > It is principally addressed to Internet Service Providers, including = those > that do not yet support IPv6. Content providers are also covered. The > intention of the advice is to minimise both user dissatisfaction and = help > desk calls. >=20 > I'm afraid I don't have more to offer at this time (the document is > mainly empty beyond that point) but assuming we can get it out > before the cutoff, I'd like to ask for a slot. >=20 > I have no doubt it will cross reference > draft-ietf-v6ops-v6-aaaa-whitelisting-implications and > draft-wing-v6ops-happy-eyeballs-ipv6, but it is a distinct > topic. >=20 > Brian From gvandeve@cisco.com Thu Jan 6 03:09:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA31C3A6DCD for ; Thu, 6 Jan 2011 03:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.08 X-Spam-Level: X-Spam-Status: No, score=-9.08 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, 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 tgCF+iwYIopY for ; Thu, 6 Jan 2011 03:09:48 -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 349353A6CE0 for ; Thu, 6 Jan 2011 03:09:47 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAE4yJU2Q/khMgWdsb2JhbACDd59CXxUBARYiJKVYilONWIEhgWYIBQaBPnQEjiyCcA X-IronPort-AV: E=Sophos;i="4.60,282,1291593600"; d="scan'208";a="72992506" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 06 Jan 2011 11:11:52 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p06BBpq3031619 for ; Thu, 6 Jan 2011 11:11:52 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 12:11:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 6 Jan 2011 12:11:44 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E502DF194F@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 80th IETF - Working Group/BOF Scheduling Thread-Index: AcusdtM/+Ro91j+6SoCytsSLWjFynwBG2/qw References: <20110104162156.414BC3A6CCE@core3.amsl.com> From: "Gunter Van de Velde (gvandeve)" To: "Fred Baker (fred)" , "v6ops v6ops" X-OriginalArrivalTime: 06 Jan 2011 11:11:45.0040 (UTC) FILETIME=[80F28900:01CBAD92] Subject: Re: [v6ops] 80th IETF - Working Group/BOF Scheduling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:09:49 -0000 T2xlIGFuZCBtZSBhcmUgd29ya2luZyBvbiBhIHVwZGF0ZSBiYXNlZCB1cG9uIGZlZWRiYWNrIG9m IHRoZSBXRyBjb21tZW50cyBvbiB0aGUgaGFybWZ1bCB0dW5uZWxzIGRyYWZ0Lg0KU28sIGFzIHJl c3VsdCBhIHNob3J0IHNsb3QgZm9yIGV4cGxhaW5pbmcgdGhvc2UgZG9jIGNoYW5nZXMgd291bGQg YmUgdXNlZnVsLg0KDQpHLw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZv cHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBGcmVkIEJha2VyIChmcmVkKQ0KU2VudDogd29lbnNkYWcgNSBqYW51YXJpIDIwMTEg MjoyMQ0KVG86IHY2b3BzIHY2b3BzDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSA4MHRoIElFVEYgLSBX b3JraW5nIEdyb3VwL0JPRiBTY2hlZHVsaW5nDQoNCkl0IGxvb2tzIGxpa2Ugd2UgYXJlIHN0YXJ0 aW5nIHNjaGVkdWxpbmcgZm9yIFByYWd1ZS4gSSBoYXZlIHNpZ25lZCB1cyB1cCBmb3Igb3VyIHVz dWFsIDIuNSBhbmQgMiBob3VyIG1lZXRpbmdzLiBBcyB1c3VhbCwgdGhlIGdyb3VuZCBydWxlcyBm b3IgZ2V0dGluZyB0aW1lIG9uIHRoZSBhZ2VuZGEgaW5jbHVkZSANCiAtIGEgc3BlYWtlciBzaG93 aW5nIHVwIGF0IHRoZSBtZWV0aW5nDQogLSByZWxldmFuY2UgdG8gdGhlIGNoYXJ0ZXIsIGFuZCAN CiAtIGEgcG9zdGVkIGludGVybmV0IGRyYWZ0IHRoYXQgaXMgbmV3IHNpbmNlIElFVEYgNzkuDQoN ClRoZXJlIGlzIGFsc28gYSBzZW5zZSBvbiB0aGUgSUVTRywgSSdtIHRvbGQsIHRoYXQgd2Ugc2hv dWxkIGJlIGFibGUgdG8gZ2V0IGFnZW5kYXMgdG9nZXRoZXIgYSBsb3QgZWFybGllciB0aGFuIHdl IGhhdmUgaW4gdGhlIHBhc3QuIE9uZSBjb21tZW50IEkgaGVhcmQgYXNrZWQgZm9yIGFuIGFnZW5k YSB0byBiZSBwb3N0ZWQgd2l0aCB0aGUgcmVxdWVzdCBmb3IgYSBtZWV0aW5nIHNsb3QuIEF0IHRo aXMgcG9pbnQsIEkgYW0gZXhwZWN0aW5nDQoNCglkcmFmdC1pZXRmLXY2b3BzLW11bHRpaG9taW5n LXdpdGhvdXQtbmF0NjYNCglkcmFmdC1pZXRmLXY2b3BzLXY0djZ0cmFuLWZyYW1ld29yaw0KCWRy YWZ0LWlldGYtdjZvcHMtdjYtYWFhYS13aGl0ZWxpc3RpbmctaW1wbGljYXRpb25zDQoJZHJhZnQt djZvcHMtbXVsdGlob21pbmctd2l0aG91dC1uYXQ2Ng0KCWRyYWZ0LXdiZWViZWUtdjZvcHMtaXB2 Ni1jcGUtcm91dGVyLWJpcw0KCWRyYWZ0LXdpbmctdjZvcHMtaGFwcHktZXllYmFsbHMtaXB2Ng0K CWRyYWZ0LWtvcmhvbmVuLXY2b3BzLTNncHAtZXBzDQoNCmRyYWZ0LXY2b3BzLW11bHRpaG9taW5n LXdpdGhvdXQtbmF0NjYsIGRyYWZ0LXdpbmctdjZvcHMtaGFwcHktZXllYmFsbHMtaXB2NiBzaG91 bGQgYmUgcmVwb3N0ZWQgYXMgIGRyYWZ0LWlldGYtdjZvcHMtKiwgcGxlYXNlIC0gd29ya2luZyBn cm91cCBkcmFmdC4gSSBleHBlY3QgdGhhdCBhdCB0aGlzIGNvbWluZyBtZWV0aW5nIHdlIHdpbGwg ZmluZCBlbm91Z2ggbWVhdCBpbiBjcGUtcm91dGVyLWJpcyB0byBhZG9wdCBpdCBhcyB3ZWxsLiBX ZSBjb2xsZWN0aXZlbHkgbmVlZCB0byBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIGRyYWZ0LWtvcmhv bmVuLXY2b3BzLTNncHAtZXBzOyBvZiB0aGUgcmVzcG9uZGVudHMgaW4gdGhlIHN1cnZleSwgbW9z dCBmZWx0IGl0IHdhcyBzb21ldGhpbmcgdG8gd29yayBvbiwgYnV0IHdlIGRpZG4ndCBoYXZlIGEg Y2xlYXIgY29uc2Vuc3VzIG9uIHdoZXRoZXIgb3Igbm90IHRvIGFkb3B0IGl0LiBJJ2xsIHN0YXJ0 IHRoYXQgZGlzY3Vzc2luZyBpbiBhIHNlcGFyYXRlIHRocmVhZCBpbiBhIGZldyBtb21lbnRzLg0K DQpBdCB0aGlzIHBvaW50LCB3ZSBhbHNvIGhhdmUgMTUgb3RoZXIgZHJhZnRzIHBvc3RlZC4gT25l IHdpbGwgZm9yIHN1cmUgZGllIChtaW5lKTsgaXQgaGFzIGFjY29tcGxpc2hlZCBpdHMgcHVycG9z ZS4gQW5vdGhlciBpcyBsaWtlbHkgdG8gYmUgZm9sZGVkIGludG8gY3BlLXJvdXRlci1iaXMuIFRo ZXJlIHdhcyBhIHNlbnNlIGF0IElFVEYgNzkgdGhhdCB0aGVyZSB3YXMgdmFsdWUgaW4gZHJhZnQt amFua2lld2ljei12Nm9wcy12NHY2YmlibGlvLCBidXQgbm8gY2xlYXIgZGlyZWN0aW9uIG9uIHdo ZXJlIEVkIHNob3VsZCB0YWtlIGl0IC0gc29tZSB0aG91Z2h0IGl0IHNob3VsZCBiZSBhIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnQgYW5kIHNvbWUgdGhvdWdodCBpdCBzaG91bGQgYmUgYWJhbmRvbmVk LiBJJ2xsIGxlYXZlIHRoYXQgdG8gRWQgZm9yIHRoZSBtb21lbnQuIFRoZSBjb21tZW50cyBtYWRl IGluIHRoZSBzdXJ2ZXksIHdoaWNoIEkgZW1haWxlZCB0byB0aGUgbGlzdCBvbiAyMCBOb3ZlbWJl ciwgd2VyZSBpbmNvbmNsdXNpdmUgd2l0aCByZXNwZWN0IHRvIHRoZSBvdGhlcnM7IEknbGwgbGVh dmUgaXQgdG8gdGhlIGF1dGhvcnMgdG8gdGVsbCB2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcg aG93IHRoZXkgd291bGQgbGlrZSB0byBwcm9jZWVkIHdpdGggdGhlaXIgZHJhZnRzLg0KDQoNCk9u IEphbiA0LCAyMDExLCBhdCA4OjIxIEFNLCBJRVRGIEFnZW5kYSB3cm90ZToNCg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA4MHRoIElFVEYgy4YgUHJhZ3VlLCBDemVjaCBSZXB1YmxpYw0KPiBNZWV0aW5nIERhdGVz OiBNYXJjaCAyNy1BcHJpbCAxLCAyMDExDQo+IEhvc3Q6IENaLk5JQw0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJ RVRGIG1lZXRpbmdzIHN0YXJ0IE1vbmRheSBtb3JuaW5nIGFuZCBydW4gdGhyb3VnaCBGcmlkYXkg bWlkLWFmdGVybm9vbg0KPiAoMTU6MTUpLg0KPiANCj4gV2UgYXJlIGFjY2VwdGluZyBzY2hlZHVs aW5nIHJlcXVlc3RzIGZvciBhbGwgV29ya2luZyBHcm91cHMgYW5kIEJPRnMNCj4gc3RhcnRpbmcg dG9kYXkuICBUaGUgbWlsZXN0b25lcyBhbmQgZGVhZGxpbmVzIGZvciBzY2hlZHVsaW5nLXJlbGF0 ZWQNCj4gYWN0aXZpdGllcyBhcmUgYXMgZm9sbG93czoNCj4gDQo+IE5PVEU6IGN1dG9mZiBkYXRl cyBhcmUgc3ViamVjdCB0byBjaGFuZ2UuDQo+IA0KPiDvo78gIDIwMTAtMTItMjcgKE1vbmRheSk6 IFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBzY2hlZHVsaW5nIGJlZ2lucy4gVG8NCj4gcmVxdWVzdCBh IFdvcmtpbmcgR3JvdXAgc2Vzc2lvbiwgdXNlIHRoZSBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1 ZXN0DQo+IFRvb2wuIA0KPiDvo78gIDIwMTEtIDAxLTMxIChNb25kYXkpOiBDdXRvZmYgZGF0ZSBm b3IgQk9GIHByb3Bvc2FsIHJlcXVlc3RzIHRvIEFyZWENCj4gRGlyZWN0b3JzIGF0IDE3OjAwIFBU ICgwMTowMCBUdWVzZGF5LCBGZWJydWFyeSAxIFVUQykuIFRvIHJlcXVlc3QgYSBCT0YsDQo+IHBs ZWFzZSBzZWUgaW5zdHJ1Y3Rpb25zIG9uIFJlcXVlc3RpbmcgYSBCT0YuIA0KPiDvo78gIDIwMTEt MDItMTQgKE1vbmRheSk6IEN1dG9mZiBkYXRlIGZvciByZXF1ZXN0cyB0byBzY2hlZHVsZSBXb3Jr aW5nIEdyb3VwDQo+IG1lZXRpbmdzIGF0IDE3OjAwIFBUICgwMTowMCBUdWVzZGF5LCBGZWJydWFy eSAxNSBVVEMpLiBUbyByZXF1ZXN0IGENCj4gV29ya2luZyBHcm91cCBzZXNzaW9uLCB1c2UgdGhl IElFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbC4gDQo+IO+jvyAgMjAxMS0wMi0xNCAo TW9uZGF5KTogQ3V0b2ZmIGRhdGUgZm9yIEFyZWEgRGlyZWN0b3JzIHRvIGFwcHJvdmUgQk9GcyBh dA0KPiAxNzowMCBQVCAoMDE6MDAgVHVlc2RheSwgRmVicnVhcnkgMTUgVVRDKS4gDQo+IO+jvyAg MjAxMS0wMi0yNCAoVGh1cnNkYXkpOiBQcmVsaW1pbmFyeSBhZ2VuZGEgcHVibGlzaGVkIGZvciBj b21tZW50LiANCj4g76O/ICAyMDExLTAyLTI4IChNb25kYXkpOiBDdXRvZmYgZGF0ZSBmb3IgcmVx dWVzdHMgdG8gcmVzY2hlZHVsZSBXb3JraW5nDQo+IEdyb3VwIGFuZCBCT0YgbWVldGluZ3MgMTc6 MDAgUFQgKDAxOjAwIFR1ZXNkYXksIE1hcmNoIDEgVVRDKS4gDQo+IO+jvyAgMjAxMS0wMi0yOCAo TW9uZGF5KTogV29ya2luZyBHcm91cCBDaGFpciBhcHByb3ZhbCBmb3IgaW5pdGlhbCBkb2N1bWVu dA0KPiAoVmVyc2lvbiAtMDApIHN1Ym1pc3Npb25zIGFwcHJlY2lhdGVkIGJ5IDE3OjAwIFBUICgw MTowMCBUdWVzZGF5LCBNYXJjaCAxDQo+IFVUQykuIA0KPiDvo78gIDIwMTEtMDMtMDQgKEZyaWRh eSk6IEZpbmFsIGFnZW5kYSB0byBiZSBwdWJsaXNoZWQuIA0KPiDvo78gIDIwMTEtMDMtMTYgKFdl ZG5lc2RheSk6IERyYWZ0IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgMTc6MDAgUFQNCj4g KDAxOjAwIFRodXJzZGF5LCBNYXJjaCAxNyBVVEMpLCB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5n IE1hdGVyaWFscw0KPiBNYW5hZ2VtZW50IFRvb2wuIA0KPiDvo78gIDIwMTEtMDMtMjEgKE1vbmRh eSk6IFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSAxNzowMCBQVA0KPiAoMDE6 MDAgVHVlc2RheSwgTWFyY2ggMjIgVVRDKSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRl cmlhbHMNCj4gTWFuYWdlbWVudCBUb29sLg0KPiANCj4gU3VibWl0dGluZyBSZXF1ZXN0cyBmb3Ig V29ya2luZyBHcm91cCBhbmQgQk9GIFNlc3Npb25zDQo+IA0KPiBQbGVhc2Ugc3VibWl0IHJlcXVl c3RzIHRvIHNjaGVkdWxlIHlvdXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyB1c2luZyB0aGUNCj4g IklFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCwiIGEgV2ViLWJhc2VkIHRvb2wgZm9y IHN1Ym1pdHRpbmcgYWxsDQo+IG9mIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHRoZSBTZWNyZXRhcmlh dCByZXF1aXJlcyB0byBzY2hlZHVsZSB5b3VyDQo+IHNlc3Npb25zLg0KPiANCj4gVGhlIFVSTCBm b3IgdGhlIHRvb2wgaXM6DQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2NnaS1i aW4vd2cvd2dfc2Vzc2lvbl9yZXF1ZXN0ZXIuY2dpDQo+IA0KPiBJbnN0cnVjdGlvbnMgZm9yIHVz aW5nIHRoZSB0b29sIGFyZSBhdmFpbGFibGUgYXQ6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3Jn L2luc3RydWN0aW9ucy9zZXNzaW9uX3JlcXVlc3RfdG9vbF9pbnN0cnVjdGlvbi5odG1sDQo+IA0K PiBQbGVhc2Ugc2VuZCByZXF1ZXN0cyB0byBzY2hlZHVsZSB5b3VyIEJPRiBzZXNzaW9ucyB0byBh Z2VuZGFAaWV0Zi5vcmcuIA0KPiBQbGVhc2UgaW5jbHVkZSB0aGUgYWNyb255bSBvZiB5b3VyIEJP RiBpbiB0aGUgc3ViamVjdCBsaW5lIG9mIHRoZSBtZXNzYWdlLA0KPiBhbmQgaW5jbHVkZSBhbGwg b2YgdGhlIGluZm9ybWF0aW9uIHNwZWNpZmllZCBpbiBpdGVtICg0KSBvZiAiUmVxdWVzdGluZw0K PiBNZWV0aW5nIFNlc3Npb25zIGF0IElFVEYgTWVldGluZ3MiIGluIHRoZSBib2R5LiAgKFRoaXMg ZG9jdW1lbnQgaXMNCj4gaW5jbHVkZWQgYmVsb3cuKQ0KPiANCj4gU3VibWl0dGluZyBTZXNzaW9u IEFnZW5kYXMNCj4gDQo+IEZvciB0aGUgY29udmVuaWVuY2Ugb2YgbWVldGluZyBhdHRlbmRlZXMs IHdlIGFzayB0aGF0IHlvdSBzdWJtaXQgdGhlDQo+IGFnZW5kYXMgZm9yIHlvdXIgV29ya2luZyBH cm91cCBzZXNzaW9ucyBhcyBlYXJseSBhcyBwb3NzaWJsZS4gIERyYWZ0DQo+IFdvcmtpbmcgR3Jv dXAgYWdlbmRhcyBhcmUgZHVlIFdlZG5lc2RheSwgTWFyY2ggMTYsIDIwMTEgYnkgMTc6MDAgUFQg KDAxOjAwDQo+IFRodXJzZGF5LCBNYXJjaCAxNyBVVEMpLiAgUmV2aXNlZCBXb3JraW5nIEdyb3Vw IGFnZW5kYXMgYXJlIGR1ZSBubyBsYXRlcg0KPiB0aGFuIE1vbmRheSwgTWFyY2ggMjEsIDIwMTEg YXQgMTc6MDAgUFQgKDAxOjAwIFR1ZXNkYXksIE1hcmNoIDIyIFVUQykuIA0KPiBUaGUgcHJvcG9z ZWQgYWdlbmRhIGZvciBhIEJPRiBzZXNzaW9uIHNob3VsZCBiZSBzdWJtaXR0ZWQgYWxvbmcgd2l0 aCB5b3VyDQo+IHJlcXVlc3QgZm9yIGEgc2Vzc2lvbi4gIFBsZWFzZSBiZSBzdXJlIHRvIGNvcHkg eW91ciBBcmVhIERpcmVjdG9yIG9uIHRoYXQNCj4gbWVzc2FnZS4NCj4gDQo+IFBsZWFzZSBzdWJt aXQgdGhlIGFnZW5kYXMgZm9yIHlvdXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyB1c2luZyB0aGUg IklFVEYNCj4gTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLCIgYSBXZWItYmFzZWQg dG9vbCBmb3IgbWFraW5nIHlvdXINCj4gbWVldGluZyBhZ2VuZGEsIG1pbnV0ZXMsIGFuZCBwcmVz ZW50YXRpb24gc2xpZGVzIGF2YWlsYWJsZSB0byB0aGUNCj4gY29tbXVuaXR5IGJlZm9yZSwgZHVy aW5nLCBhbmQgYWZ0ZXIgYW4gSUVURiBtZWV0aW5nLiAgSWYgeW91IGFyZSBhIEJPRg0KPiBjaGFp ciwgdGhlbiB5b3UgbWF5IHVzZSB0aGUgdG9vbCB0byBzdWJtaXQgYSByZXZpc2VkIGFnZW5kYSBh cyB3ZWxsIGFzDQo+IG90aGVyIG1hdGVyaWFscyBmb3IgeW91ciBCT0Ygb25jZSB0aGUgQk9GIGhh cyBiZWVuIGFwcHJvdmVkLg0KPiANCj4gVGhlIFVSTCBmb3IgdGhlIHRvb2wgaXM6DQo+IA0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2NnaS1iaW4vd2cvd2dfcHJvY2VlZGluZ3MuY2dp DQo+IA0KPiBBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgdG9vbCBpcyBhdmFpbGFi bGUgYXQ6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2luc3RydWN0aW9ucy9tZWV0aW5nX21h dGVyaWFsc190b29sLmh0bWwNCj4gDQo+IEFnZW5kYXMgc3VibWl0dGVkIHZpYSB0aGUgdG9vbCB3 aWxsIGJlIGF2YWlsYWJsZSB0byB0aGUgcHVibGljIG9uIHRoZQ0KPiAiSUVURiBNZWV0aW5nIE1h dGVyaWFscyIgV2ViIHBhZ2UgYXMgc29vbiBhcyB0aGV5IGFyZSBzdWJtaXR0ZWQuDQo+IA0KPiBU aGUgVVJMIGZvciB0aGUgIklFVEYgODAgTWVldGluZyBNYXRlcmlhbHMiIFdlYiBwYWdlIGlzOg0K PiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9wdWJsaWMvbWVldGluZ19tYXRlcmlh bHMuY2dpP21lZXRpbmdfbnVtPTgwDQo+IA0KPiBJZiB5b3UgYXJlIGEgV29ya2luZyBHcm91cCBj aGFpciwgdGhlbiB5b3UgYWxyZWFkeSBoYXZlIGFjY291bnRzIG9uIHRoZQ0KPiAiSUVURiBNZWV0 aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sIiBhbmQgdGhlICJJRVRGIE1lZXRpbmcgTWF0ZXJpYWxz DQo+IE1hbmFnZW1lbnQgVG9vbC4iICBUaGUgc2FtZSBVc2VyIElEIGFuZCBwYXNzd29yZCB3aWxs IHdvcmsgZm9yIGJvdGggdG9vbHMuDQo+ICBJZiB5b3UgYXJlIGEgQk9GIGNoYWlyIHdobyBpcyBu b3QgYWxzbyBhIFdvcmtpbmcgR3JvdXAgY2hhaXIsIHRoZW4geW91DQo+IHdpbGwgYmUgZ2l2ZW4g YW4gYWNjb3VudCBvbiB0aGUgIklFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29s Ig0KPiB3aGVuIHlvdXIgQk9GIGhhcyBiZWVuIGFwcHJvdmVkLiAgSWYgeW91IHJlcXVpcmUgYXNz aXN0YW5jZSBpbiB1c2luZw0KPiBlaXRoZXIgdG9vbCwgb3Igd2lzaCB0byByZXBvcnQgYSBidWcs IHRoZW4gcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvOg0KPiBpZXRmLWFjdGlvbkBpZXRmLm9yZy4N Cj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo+IEZvciB5b3VyIGNvbnZlbmllbmNlLCBjb21wcmVoZW5zaXZlIGluZm9ybWF0 aW9uIG9uIHJlcXVlc3RpbmcgbWVldGluZw0KPiBzZXNzaW9ucyBhdCBJRVRGIDgwIGlzIHByZXNl bnRlZCBiZWxvdzoNCj4gDQo+IDEuIFJlcXVlc3RzIHRvIHNjaGVkdWxlIFdvcmtpbmcgR3JvdXAg c2Vzc2lvbnMgc2hvdWxkIGJlIHN1Ym1pdHRlZCB1c2luZw0KPiB0aGUgIklFVEYgTWVldGluZyBT ZXNzaW9uIFJlcXVlc3QgVG9vbCwiIGEgV2ViLWJhc2VkIHRvb2wgZm9yIHN1Ym1pdHRpbmcNCj4g YWxsIG9mIHRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZCBieSB0aGUgU2VjcmV0YXJpYXQgdG8gc2No ZWR1bGUgeW91cg0KPiBzZXNzaW9ucy4gIFRoZSBVUkwgZm9yIHRoZSB0b29sIGlzOg0KPiANCj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9jZ2ktYmluL3dnL3dnX3Nlc3Npb25fcmVxdWVz dGVyLmNnaQ0KPiANCj4gSW5zdHJ1Y3Rpb25zIGZvciB1c2luZyB0aGUgdG9vbCBhcmUgYXZhaWxh YmxlIGF0Og0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnN0cnVjdGlvbnMvc2Vzc2lvbl9y ZXF1ZXN0X3Rvb2xfaW5zdHJ1Y3Rpb24uaHRtbA0KPiANCj4gSWYgeW91IHJlcXVpcmUgYW4gYWNj b3VudCBvbiB0aGlzIHRvb2wsIG9yIGFzc2lzdGFuY2UgaW4gdXNpbmcgaXQsIHRoZW4NCj4gcGxl YXNlIHNlbmQgYSBtZXNzYWdlIHRvIGlldGYtYWN0aW9uQGlldGYub3JnLiAgSWYgeW91IGFyZSB1 bmFibGUgdG8gdXNlDQo+IHRoZSB0b29sLCB0aGVuIHlvdSBtYXkgc2VuZCB5b3VyIHJlcXVlc3Qg dmlhIGUtbWFpbCB0byBhZ2VuZGFAaWV0Zi5vcmcsDQo+IHdpdGggYSBjb3B5IHRvIHRoZSBhcHBy b3ByaWF0ZSBBcmVhIERpcmVjdG9yKHMpLg0KPiANCj4gUmVxdWVzdHMgdG8gc2NoZWR1bGUgQk9G IHNlc3Npb25zIG11c3QgYmUgc2VudCB0byBhZ2VuZGFAaWV0Zi5vcmcgd2l0aCBhDQo+IGNvcHkg dG8gdGhlIGFwcHJvcHJpYXRlIEFyZWEgRGlyZWN0b3IocykuDQo+IA0KPiBXaGVuIHN1Ym1pdHRp bmcgYSBXb3JraW5nIEdyb3VwIG9yIEJPRiBzZXNzaW9uIHJlcXVlc3QgYnkgZS1tYWlsLCBwbGVh c2UNCj4gaW5jbHVkZSB0aGUgV29ya2luZyBHcm91cCBvciBCT0YgYWNyb255bSBpbiB0aGUgU3Vi amVjdCBsaW5lLg0KPiANCj4gMi4gQk9GcyB3aWxsIE5PVCBiZSBzY2hlZHVsZWQgdW5sZXNzIHRo ZSBBcmVhIERpcmVjdG9yKHMpIGFwcHJvdmVkDQo+IHJlcXVlc3QgaXMgYWNjb21wYW5pZWQgYnkg YSBCT0YnUyBGVUxMIE5BTUUgQU5EIEFDUk9OWU0sIEFSRUEsIENIQUlSKFMpDQo+IE5BTUUoUykg KGdpdmVuIHRvZ2V0aGVyIHdpdGggZS1tYWlsIGFkZHJlc3MoZXMpKSwgQU4gQUdFTkRBIEFORCBG VUxMDQo+IERFU0NSSVBUSU9OLCBhbmQgdGhlIGluZm9ybWF0aW9uIHJlcXVlc3RlZCBpbiAoNCkg YmVsb3cuIChQbGVhc2UgcmVhZCB0aGUNCj4gQk9GIFByb2NlZHVyZSBhdDogaHR0cDovL3d3dy5p ZXRmLm9yZy9pZXRmLzFib2YtcHJvY2VkdXJlcy50eHQgYmVmb3JlDQo+IHJlcXVlc3RpbmcgYSBz ZXNzaW9uIGZvciBhIEJPRi4pDQo+IA0KPiAzLiBBIFdvcmtpbmcgR3JvdXAgbWF5IHJlcXVlc3Qg ZWl0aGVyIG9uZSBvciB0d28gc2Vzc2lvbnMuICBJZiB5b3VyDQo+IFdvcmtpbmcgR3JvdXAgcmVx dWlyZXMgbW9yZSB0aGFuIHR3byBzZXNzaW9ucywgdGhlbiB5b3VyIHJlcXVlc3QgbXVzdCBiZQ0K PiBhcHByb3ZlZCBieSBhbiBBcmVhIERpcmVjdG9yLiAgQWRkaXRpb25hbCBzZXNzaW9ucyB3aWxs IGJlIGFzc2lnbmVkLCBiYXNlZA0KPiBvbiBhdmFpbGFiaWxpdHksIGFmdGVyIE1vbmRheSwgRmVi cnVhcnkgMjgsIDIwMTEgYXQgMTc6MDAgUFQgKDAxOjAwDQo+IFR1ZXNkYXksIE1hcmNoIDEgVVRD KSwgdGhlIGN1dC1vZmYgZGF0ZSBmb3IgcmVxdWVzdHMgdG8gcmVzY2hlZHVsZSBhDQo+IHNlc3Np b24uDQo+IA0KPiA0LiBZb3UgTVVTVCBwcm92aWRlIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24g YmVmb3JlIGEgV29ya2luZyBHcm91cCBvcg0KPiBCT0Ygc2Vzc2lvbiB3aWxsIGJlIHNjaGVkdWxl ZDoNCj4gDQo+ICAgIGEuIFdvcmtpbmcgR3JvdXAgb3IgQk9GIGZ1bGwgbmFtZSB3aXRoIGFjcm9u eW0gaW4gYnJhY2tldHM6IA0KPiANCj4gICAgYi4gQVJFQSB1bmRlciB3aGljaCBXb3JraW5nIEdy b3VwIG9yIEJPRiBhcHBlYXJzOg0KPiANCj4gICAgYy4gQ09ORkxJQ1RTIHlvdSB3aXNoIHRvIGF2 b2lkLCBwbGVhc2UgYmUgYXMgc3BlY2lmaWMgYXMgcG9zc2libGU6DQo+IA0KPiAgICBkLiBFeHBl Y3RlZCBBdHRlbmRhbmNlOg0KPiANCj4gICAgZS4gU3BlY2lhbCByZXF1ZXN0czoNCj4gDQo+ICAg IGYuIE51bWJlciBvZiBzZXNzaW9uczoNCj4gDQo+ICAgIGcuIExlbmd0aCBvZiBzZXNzaW9uOiAN Cj4gICAgICAgLSAxIGhvdXIgDQo+ICAgICAgIC0gMSAxLzIgaG91cnMNCj4gICAgICAgLSAyIGhv dXJzIA0KPiAgICAgICAtIDIgMS8yIGhvdXJzDQo+IA0KPiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBv biBzY2hlZHVsaW5nIFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBzZXNzaW9ucywgcGxlYXNlDQo+IHJl ZmVyIHRvIFJGQyAyNDE4IChCQ1AgMjUpLCAiSUVURiBXb3JraW5nIEdyb3VwIEd1aWRlbGluZXMg YW5kIFByb2NlZHVyZXMiDQo+IChodHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmMyNDE4LnR4dCku DQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KPiBGb3IgeW91ciBjb252ZW5pZW5jZSBwbGVhc2UgZmluZCBoZXJlIGEgbGlz dCBvZiB0aGUgSUVURiBBcmVhIERpcmVjdG9ycw0KPiB3aXRoIHRoZWlyIGUtbWFpbCBhZGRyZXNz ZXM6DQo+IA0KPiBJRVRGIENoYWlyIA0KPiBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMu Y29tPg0KPiANCj4gQXBwbGljYXRpb25zIEFyZWEgKGFwcCkNCj4gQWxleGV5IE1lbG5pa292IDxh bGV4ZXkubWVsbmlrb3ZAaXNvZGUuY29tPg0KPiBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBz dHBldGVyLmltPiANCj4gDQo+IEludGVybmV0IEFyZWEgKGludCkgDQo+IEphcmkgQXJra28gPGph cmkuYXJra29AcGl1aGEubmV0Pg0KPiBSYWxwaCBEcm9tcyA8cmRyb21zLmlldGZAZ21haWwuY29t PiANCj4gDQo+IE9wZXJhdGlvbnMgJiBNYW5hZ2VtZW50IEFyZWEgKG9wcykgDQo+IFJvbmFsZCBC b25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQo+IERhbiBSb21hc2NhbnUgPGRyb21hc2NhQGF2 YXlhLmNvbT4NCj4gDQo+IFJlYWwtdGltZSBBcHBsaWNhdGlvbnMgYW5kIEluZnJhc3RydWN0dXJl IEFyZWEgKHJhaSkNCj4gR29uemFsbyBDYW1hcmlsbG8gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNz c29uLmNvbT4NCj4gUm9iZXJ0IFNwYXJrcyA8cmpzcGFya3NAbm9zdHJ1bS5jb20+IA0KPiANCj4g Um91dGluZyBBcmVhIChydGcpIA0KPiBTdGV3YXJ0IEJyeWFudCA8c3RicnlhbnRAY2lzY28uY29t Pg0KPiBBZHJpYW4gRmFycmVsIDxhZHJpYW4uZmFycmVsQGh1YXdlaS5jb20+IA0KPiANCj4gU2Vj dXJpdHkgQXJlYSAoc2VjKSANCj4gVGltIFBvbGsgPHRpbS5wb2xrQG5pc3QuZ292Pg0KPiBTZWFu IFR1cm5lciA8dHVybmVyc0BpZWNhLmNvbT4gDQo+IA0KPiBUcmFuc3BvcnQgQXJlYSAodHN2KSAN Cj4gTGFycyBFZ2dlcnQgPGxhcnMuZWdnZXJ0QG5va2lhLmNvbT4NCj4gRGF2aWQgSGFycmluZ3Rv biA8aWV0ZmRiaEBjb21jYXN0Lm5ldD4gDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IDc5dGggSUVURiBNZWV0aW5nIEF0dGVu ZGFuY2UgTnVtYmVyDQo+IA0KPiBXb3JraW5nIEdyb3VwCQ0KPiANCj4gNmxvd3BhbiAtIDEwOA0K PiA2bWFuIC0gMTc4DQo+IGFiZmFiIC0gNTANCj4gYWx0byAtIDExMA0KPiBhbmNwIC0gMjYNCj4g YXBwYXJlYSAoQUcpIC0gNzQNCj4gYXJtZCBCT0YgLSA3MA0KPiBhdG9jYSAtIDM3DQo+IGF1dG9j b25mIC0gMjkNCj4gYXZ0IC0gODINCj4gYXZ0ICgybmQgc2Vzc2lvbikgLSA1NQ0KPiBiZWhhdmUg LSAxMDMNCj4gYm13ZyAtIDE1DQo+IGNjYW1wIC0gMTAwDQo+IGNjYW1wICgybmQgc2Vzc2lvbikg LSA3OQ0KPiBjb2RlYyAtIDU5DQo+IGNvbmV4IC0gNDMNCj4gY29yZSAtIDgxDQo+IGNvcmUgKDJu ZCBzZXNzaW9uKSAtIDY3DQo+IGN1c3MgLSAxNA0KPiBkZWNhZGUgLSA1OQ0KPiBkaGMgLSAyOA0K PiBkaW1lIC0gMTQNCj4gZGlzcGF0Y2ggLSA2MQ0KPiBkbnNleHQgLSA5OQ0KPiBkbnNvcCAtIDk2 DQo+IGRyaW5rcyAtIDM3DQo+IGR0bnJnIChSRykgLSAyMg0KPiBlYWkgLSAzMQ0KPiBlY3JpdCAt IDM3DQo+IGVtYW4gLSA1Ng0KPiBlbXUgLSAyMQ0KPiBmZWNmcmFtZSAtIDgNCj4gZm9yY2VzIC0g MjMNCj4gZ2VvcHJpdiAtIDM5DQo+IGdyb3cgLSA0NA0KPiBoaXByZyAoUkcpIC0gNDQNCj4gaG9r ZXkgLSAyMg0KPiBpZGR0c3BlYyAtIDEzDQo+IGlkciAtIDgwDQo+IGludGFyZWEgKEFHKSAtIDEx MQ0KPiBpcGZpeCAtIDM3DQo+IGlwcG0gLSAyMw0KPiBpcHNlY21lIC0gMjgNCj4gaXJpIC0gMTgN Cj4gaXNpcyAtIDUyDQo+IGlzbXMgLSAxNA0KPiBrYXJwIC0gNTANCj4ga2lkbnMgLSAxMjINCj4g a2l0dGVuIC0gMzENCj4ga3JiLXdnIC0gMTINCj4gbDJ2cG4gLSAxMTkNCj4gbDN2cG4gLSA5Mg0K PiBsaXNwIC0gNjkNCj4gbHdpcCAtIDE1Ng0KPiBtYW5ldCAtIDM1DQo+IG1hcnRpbmkgLSAzNg0K PiBtYm9uZWQgLSAxOA0KPiBtZXh0IC0gNjkNCj4gbWV4dCAoc2Vjb25kIHNlc3Npb24pIC0gNjQN Cj4gbWlmIC0gMTE0DQo+IG1pcDQgLSAxMA0KPiBtbXVzaWMgLSA1MA0KPiBtcGxzIC0gMTUwDQo+ IG1wbHMgKDJuZCBzZXNzaW9uKSAtIDE1OA0KPiBtcHRjcCAtIDEwMQ0KPiBtcHRjcCAoMm5kIHNl c3Npb24pIC0gNjQNCj4gbXNlYyAtIDMzDQo+IG11bHRpbW9iIC0gNjENCj4gbmJzIEJQRiAtIDEw MQ0KPiBuZWEgLSAzMA0KPiBuZXRjb25mIC0gNDINCj4gbmV0ZXh0IC0gNTINCj4gbmV0bW9kIC0g MjgNCj4gbmZzdjQgLSAyNQ0KPiBuZnN2NCAoc2Vjb25kIHNlc3Npb24pIC0gTk8gU0hFRVRTDQo+ IG9wc2FyZWEgKEFHKSAtIDQwDQo+IG9wc2F3ZyAtIDUxDQo+IG9zcGYgLSA1Mw0KPiBwMnBzaXAg LSA1OA0KPiBwY3AgLSA1OQ0KPiBwaW0gLSA0Nw0KPiBwa2l4IC0gMzANCj4gcHBzcCAtIDM4DQo+ IHByZWNpcyAtIDMxDQo+IHB3ZTMgLSAxNDANCj4gcmFkZXh0IC0gMjANCj4gcm9sbCAtIDcyDQo+ IHJ0Z2FyZWEgKEFHKSAtIDEzNQ0KPiBydGd3ZyAtIDU2DQo+IHNhYWcgKEFHKSAtIDkwDQo+IHNh bXJnIChSRykgLSAyMA0KPiBzYXZpIC0gNjcNCj4gc2NhcCBCT0YgLSA0NA0KPiBzaWRyIC0gNjgN Cj4gc2lwY2xmIC0gMTkNCj4gc2lwY29yZSAtIDU3DQo+IHNpcHJlYyAtIDQ0DQo+IHNvZnR3aXJl IC0gMTEwDQo+IHRjcG0gLSAyNQ0KPiB0aWN0b2MgLSAxNw0KPiB0cmlsbCAtIDcyDQo+IHRzdmFy ZWEgKEFHKSAtIDMzDQo+IHRzdndnIC0gNjUNCj4gdjZvcHMgLSAyMDMNCj4gdjZvcHMgKHNlY29u ZCBzZXNzaW9uKSAtIDE1OQ0KPiB2Y2FyZGRhdiAtIDEzDQo+IHZucmcgKFJHKSAtIDQ4DQo+IHdl YnNlYyAtIDEwMQ0KPiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From rkoodli@cisco.com Thu Jan 6 09:35:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C025D3A6BC5 for ; Thu, 6 Jan 2011 09:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.334 X-Spam-Level: X-Spam-Status: No, score=-110.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 AxqXmq8nPV2A for ; Thu, 6 Jan 2011 09:35:01 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 144CA3A68D5 for ; Thu, 6 Jan 2011 09:35:01 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIqMJU2tJV2b/2dsb2JhbACkHnOlcJgXhUwEhGeGIoMjgnA Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2011 17:37:07 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p06Hb7FB002301; Thu, 6 Jan 2011 17:37:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 11:37:07 -0600 Received: from 10.21.149.100 ([10.21.149.100]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Jan 2011 17:37:06 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 06 Jan 2011 09:54:02 -0800 From: Rajeev Koodli To: Cameron Byrne , Fred Baker Message-ID: Thread-Topic: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here Thread-Index: AcutyrOyztoRzbNoR0i9AIkT3UNUaw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jan 2011 17:37:07.0024 (UTC) FILETIME=[56B94D00:01CBADC8] Cc: IPv6 Ops WG , Basavaraj.Patil@nokia.com Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:35:03 -0000 Hi, On 1/4/11 9:19 PM, "Cameron Byrne" wrote: > I think it should be taken in as a WG doc, it is good for the folks in > this group to be involved with 3GPP model. The draft does need a lot > of work and does not represent the current world as i see it. If the > draft cannot be fixed, it should be abandoned. It may be best if the > document simply explains the 3GPP model in IETF terms and stays away > from service deployment recommendations. If it must make service > deployment recommendations, then it should reference the joint > 3GPP-IETF in meeting in SF where the conclusions was that DS and > IPv6-only were the correct paths for moving forward, not just DS. I agree, that the draft is useful with explanation of the 3GPP model and its working. I also think that the draft scope should be just that, and not involve any deployment recommendations etc. Regards, -Rajeev From jhw@apple.com Thu Jan 6 10:17:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E383A6F38 for ; Thu, 6 Jan 2011 10:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 RqLU5LPg08w7 for ; Thu, 6 Jan 2011 10:17:41 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 98C5E3A6F37 for ; Thu, 6 Jan 2011 10:17:41 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id AE320C520561 for ; Thu, 6 Jan 2011 10:19:48 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-95-4d2607c4d797 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 05.4D.06193.4C7062D4; Thu, 6 Jan 2011 10:19:48 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.53.221] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEM00DXL5L0FJ60@elliott.apple.com> for v6ops@ietf.org; Thu, 06 Jan 2011 10:19:48 -0800 (PST) From: james woodyatt In-reply-to: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> Date: Thu, 06 Jan 2011 10:19:47 -0800 Message-id: References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:17:42 -0000 On Jan 4, 2011, at 17:28, Fred Baker wrote: > > Question for the assembled throng: What do people want to see happen in draft-korhonen-v6ops-3gpp-eps? In the SurveyMonkey data, about 37% felt it was reasonable to work on but should be an individual effort, and about 58% were willing to take it as a working group draft. Several people said they had comments and would post them to the list. I have no well-formed opinion about whether the working group should adopt the draft, but I do think it's worth hammering on it until it's ready for publication. The information it contains doesn't appear to be presented as concisely anywhere else. I think I still have some questions that the draft should answer, but I need to read it more carefully to be sure they aren't already answered adequately. If the working group adopts the draft, then I'm prepared to pitch in and help sort its editorial issues. -- james woodyatt member of technical staff, communications engineering From Basavaraj.Patil@nokia.com Thu Jan 6 09:41:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4E43A6CF7 for ; Thu, 6 Jan 2011 09:41:00 -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.000, 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 TXmik9jiiwVy for ; Thu, 6 Jan 2011 09:40:59 -0800 (PST) Received: from mgw-da02.nokia.com (mgw-da02.ext.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id BD6723A6F26 for ; Thu, 6 Jan 2011 09:40:59 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p06HgUHh001276; Thu, 6 Jan 2011 19:42:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 19:42:37 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 6 Jan 2011 18:42:37 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.162]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Thu, 6 Jan 2011 18:42:37 +0100 From: To: , , Thread-Topic: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here Thread-Index: AQHLrJgp7maRS092iUy/kQ/Vw9u7NJPEK3MA//+YNwA= Date: Thu, 6 Jan 2011 17:42:34 +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 Content-Type: text/plain; charset="us-ascii" Content-ID: <72ecc1ac-ec6f-4654-bf13-feac6f2cf73f> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jan 2011 17:42:37.0754 (UTC) FILETIME=[1BDAB1A0:01CBADC9] X-Nokia-AV: Clean X-Mailman-Approved-At: Thu, 06 Jan 2011 11:04:11 -0800 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:41:00 -0000 We are working on revising the draft based on comments received. I do agree that the I-D is intended to provide an understanding of the 3GPP EPC architecture and the operating model and not recommend any approach for transition. -Raj On 1/6/11 11:54 AM, "ext Rajeev Koodli" wrote: > >Hi, > > >On 1/4/11 9:19 PM, "Cameron Byrne" wrote: > >> I think it should be taken in as a WG doc, it is good for the folks in >> this group to be involved with 3GPP model. The draft does need a lot >> of work and does not represent the current world as i see it. If the >> draft cannot be fixed, it should be abandoned. It may be best if the >> document simply explains the 3GPP model in IETF terms and stays away >> from service deployment recommendations. If it must make service >> deployment recommendations, then it should reference the joint >> 3GPP-IETF in meeting in SF where the conclusions was that DS and >> IPv6-only were the correct paths for moving forward, not just DS. > >I agree, that the draft is useful with explanation of the 3GPP model and >its >working. I also think that the draft scope should be just that, and not >involve any deployment recommendations etc. > >Regards, > >-Rajeev > > > > > From brian.e.carpenter@gmail.com Thu Jan 6 11:17:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B20F3A6F41 for ; Thu, 6 Jan 2011 11:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 plNNRTnz9tAf for ; Thu, 6 Jan 2011 11:17:03 -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 2C17A3A6CDA for ; Thu, 6 Jan 2011 11:16:56 -0800 (PST) Received: by wwa36 with SMTP id 36so16741146wwa.13 for ; Thu, 06 Jan 2011 11:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gpDlvzslkcfP1OVE2Zd5ZRhcNWXe/mIWJ5+6YTV1D7k=; b=CrKxHlwc+sfL7lyup/twzglxc/JbVi2wCbS/os2bnjKACm/7bsVfd3IPdFUrzfAlP9 0fObWWB0BaSPCbVGDL/2zp6Aoqq1liv1o0S1vBg+fT5r8MKtwuQz6gcCX22E15xPzVlS 6oj2iWODLILa+bzxRdpjzhkP/qhVGK7As5D7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nv9U5ZoLia21CbTJ+RA08y5heTEsvP13BFwkcrkbQOai+EU/6AmYqRUWjBU+PJR6Mw x1iXL/2UqHUUxmF0rfdo817gaRFMFFvo9gOPOU5h6nQAUPIAQWqYyDX2Ut1jCVfSZxwb prLRbLRjMMowSKJln6rvYdgIg/xZl395vLGy8= Received: by 10.227.132.206 with SMTP id c14mr14743806wbt.124.1294341515899; Thu, 06 Jan 2011 11:18:35 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id m13sm17046164wbz.21.2011.01.06.11.18.29 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 11:18:32 -0800 (PST) Message-ID: <4D26157F.70702@gmail.com> Date: Fri, 07 Jan 2011 08:18:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <20110104162156.414BC3A6CCE@core3.amsl.com> <4D25384E.40501@gmail.com> <7E3D96A9-8784-4563-B283-3C8D7F61D561@cisco.com> In-Reply-To: <7E3D96A9-8784-4563-B283-3C8D7F61D561@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops Subject: Re: [v6ops] 80th IETF - Working Group/BOF Scheduling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:17:04 -0000 1. It's 6to4 as well as Teredo. 2. It will cover concrete operational recommendations for ISPs. I'm not aware of any document that does that, rather than pointing out problems. -whitelisting and -happy-eyeballs are workarounds, not fixes. I believe it will fill a gap, but those are just words until the text is ready. Regards Brian On 2011-01-06 16:51, Fred Baker wrote: > Do we really need a fourth document on the subject of teredo stuff? What are you covering that hasn't already been covered? > > On Jan 5, 2011, at 7:34 PM, Brian E Carpenter wrote: > >> Hi Fred, >> >> I and a couple of others are working on something that starts like this: >> >> draft-carpenter-v6ops-6to4-teredo-advisory-00 >> >> Abstract >> >> This document provides advice to network operators about deployment of two >> techniques for automatic tunneling of IPv6 over IPv4, namely 6to4 and Teredo. >> It is principally addressed to Internet Service Providers, including those >> that do not yet support IPv6. Content providers are also covered. The >> intention of the advice is to minimise both user dissatisfaction and help >> desk calls. >> >> I'm afraid I don't have more to offer at this time (the document is >> mainly empty beyond that point) but assuming we can get it out >> before the cutoff, I'd like to ask for a slot. >> >> I have no doubt it will cross reference >> draft-ietf-v6ops-v6-aaaa-whitelisting-implications and >> draft-wing-v6ops-happy-eyeballs-ipv6, but it is a distinct >> topic. >> >> Brian > > From jouni.nospam@gmail.com Thu Jan 6 11:23:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD0A3A6C9B for ; Thu, 6 Jan 2011 11:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 KrWZpftx8Fc0 for ; Thu, 6 Jan 2011 11:23:16 -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 622E03A6C40 for ; Thu, 6 Jan 2011 11:23:16 -0800 (PST) Received: by fxm9 with SMTP id 9so16427678fxm.31 for ; Thu, 06 Jan 2011 11:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=BmJhYYKTRAquSkG3JZWds0yPsbCI9B/639K/jECEQwk=; b=Ut4XdVKv4UjMCx69Xq//dR1IC+uPyQynOuu3yBMGoCJzdEM3dAYqH+2FwNe95Qo4Qq X4JcdN3pmBROJeqYoNctef6pPEGshkJytXgk1xRmxAWU6xsm1mIbHE1GOQx/cHH4rC/k xQyFoTZmJsuLkR5+0jWO3DucWxMoHPKK3s2wM= 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=oJ45GjjdLnbA24oyx7wYn/RHLVbWtkhbuc10gY+Syzvi+de5rd42kmU6vuK3e7h492 6gePmWMiEh3YdmknokjITbr1N5cU6309gWkpg/xT1v1xs/60qSv0f4JUFnvv0rvDcYR6 fuakt0oed4UcVXVlv4fGSztICq6UUoKI+TdfA= Received: by 10.223.79.66 with SMTP id o2mr5014039fak.80.1294341922714; Thu, 06 Jan 2011 11:25:22 -0800 (PST) Received: from a83-245-210-9.elisa-laajakaista.fi (a83-245-210-9.elisa-laajakaista.fi [83.245.210.9]) by mx.google.com with ESMTPS id r24sm5946433fax.27.2011.01.06.11.25.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 11:25:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 6 Jan 2011 21:25:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29B5341B-3095-4926-9DCE-139331872989@gmail.com> References: To: Rajeev Koodli X-Mailer: Apple Mail (2.1078) Cc: Basavaraj.Patil@nokia.com, IPv6 Ops WG Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:23:17 -0000 Right, agree as well on the scope. It is no problem to strip out parts = that currently try to go beyond explaining the 3GPP model and its = working. - Jouni On Jan 6, 2011, at 7:54 PM, Rajeev Koodli wrote: >=20 > Hi, >=20 >=20 > On 1/4/11 9:19 PM, "Cameron Byrne" wrote: >=20 >> I think it should be taken in as a WG doc, it is good for the folks = in >> this group to be involved with 3GPP model. The draft does need a lot >> of work and does not represent the current world as i see it. If the >> draft cannot be fixed, it should be abandoned. It may be best if the >> document simply explains the 3GPP model in IETF terms and stays away >> from service deployment recommendations. If it must make service >> deployment recommendations, then it should reference the joint >> 3GPP-IETF in meeting in SF where the conclusions was that DS and >> IPv6-only were the correct paths for moving forward, not just DS. >=20 > I agree, that the draft is useful with explanation of the 3GPP model = and its > working. I also think that the draft scope should be just that, and = not > involve any deployment recommendations etc. >=20 > Regards, >=20 > -Rajeev >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jan@pragma.si Thu Jan 6 15:05:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D2E3A6F71 for ; Thu, 6 Jan 2011 15:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_20=-0.74] 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 8HRrYyNfd6Zk for ; Thu, 6 Jan 2011 15:05:14 -0800 (PST) Received: from nety.net (mail.nety.net [193.77.29.18]) by core3.amsl.com (Postfix) with ESMTP id 083873A6D23 for ; Thu, 6 Jan 2011 15:05:13 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=::ffff:213.250.27.221; Message-ID: <4D264B26.7040406@pragma.si> Date: Fri, 07 Jan 2011 00:07:18 +0100 From: Jan Zorz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <1F71C65E-B7F2-408B-963D-DBF94BFEAA53@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: jan@pragma.si X-Info: aspam skipped due to (g_smite_skip_trusted) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=3 Good=0 Friend=2 Surbl=0 Catch=0 r=0.015 ip=::ffff:213.250.27.221 X-IP-stats: Notspam Incoming Outgoing Last 0, First 232, in=14591, out=66, spam=0 Known=true ip=::ffff:213.250.27.221 Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:05:16 -0000 On 5.1.2011 18:20, Merike Kaeo wrote: > Main jist - I would encourage this work to become working group item. +1 I think that's good document. I'm willing to contribute, will talk to authors. Jan Zorz go6.si From gvandeve@cisco.com Fri Jan 7 04:03:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD543A682A for ; Fri, 7 Jan 2011 04:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.405 X-Spam-Level: X-Spam-Status: No, score=-9.405 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 T1YCUaMIi+0i for ; Fri, 7 Jan 2011 04:03:19 -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 144183A6828 for ; Fri, 7 Jan 2011 04:03:18 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALOQJk2Q/khNgWdsb2JhbACkJhYBFiIkpBGYM4VMBI4t Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2011 12:05:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p07C5PB1001705; Fri, 7 Jan 2011 12:05:25 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 13:05:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 13:05:23 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E502DF1C02@XMB-AMS-101.cisco.com> In-Reply-To: <4D26157F.70702@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 80th IETF - Working Group/BOF Scheduling Thread-Index: Acut171TTlkzHngbR+es6wkl3Sm5WwAicAFQ References: <20110104162156.414BC3A6CCE@core3.amsl.com><4D25384E.40501@gmail.com><7E3D96A9-8784-4563-B283-3C8D7F61D561@cisco.com> <4D26157F.70702@gmail.com> From: "Gunter Van de Velde (gvandeve)" To: "Brian E Carpenter" , "Fred Baker (fred)" X-OriginalArrivalTime: 07 Jan 2011 12:05:24.0989 (UTC) FILETIME=[2A9982D0:01CBAE63] Cc: v6ops v6ops Subject: Re: [v6ops] 80th IETF - Working Group/BOF Scheduling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:03:20 -0000 I am one of the folks amongst others helping Brian out with text around Teredo. The way I see it is that it is not a fix, but recommendations=20 to improve the user IPv6 experience at any cost, and deliver recommendations to ISP's.=20 As Brian mentioned "the tooth paste is out of the=20 tube and can not be put back in again easily". Hence we should use the lost=20 elements in the best possible way. Imho the solution is to run dual stack, and forget out non-managed tunnels imho. (which is btw a different draft of work I am working upon -harmful-tunnels-) G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: donderdag 6 januari 2011 20:18 To: Fred Baker (fred) Cc: v6ops v6ops Subject: Re: [v6ops] 80th IETF - Working Group/BOF Scheduling 1. It's 6to4 as well as Teredo. 2. It will cover concrete operational recommendations for ISPs. I'm not aware of any document that does that, rather than pointing out problems. -whitelisting and -happy-eyeballs are workarounds, not fixes. I believe it will fill a gap, but those are just words until the text is ready. Regards Brian On 2011-01-06 16:51, Fred Baker wrote: > Do we really need a fourth document on the subject of teredo stuff? What are you covering that hasn't already been covered? >=20 > On Jan 5, 2011, at 7:34 PM, Brian E Carpenter wrote: >=20 >> Hi Fred, >> >> I and a couple of others are working on something that starts like this: >> >> draft-carpenter-v6ops-6to4-teredo-advisory-00 >> >> Abstract >> >> This document provides advice to network operators about deployment of two >> techniques for automatic tunneling of IPv6 over IPv4, namely 6to4 and Teredo. >> It is principally addressed to Internet Service Providers, including those >> that do not yet support IPv6. Content providers are also covered. The >> intention of the advice is to minimise both user dissatisfaction and help >> desk calls. >> >> I'm afraid I don't have more to offer at this time (the document is >> mainly empty beyond that point) but assuming we can get it out >> before the cutoff, I'd like to ask for a slot. >> >> I have no doubt it will cross reference >> draft-ietf-v6ops-v6-aaaa-whitelisting-implications and >> draft-wing-v6ops-happy-eyeballs-ipv6, but it is a distinct >> topic. >> >> Brian >=20 >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Wesley.E.George@sprint.com Fri Jan 7 10:50:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04BE3A6935; Fri, 7 Jan 2011 10:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.98 X-Spam-Level: X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2bfaobSBRsX; Fri, 7 Jan 2011 10:50:40 -0800 (PST) Received: from TX2EHSOBE009.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 9C2393A67A1; Fri, 7 Jan 2011 10:50:40 -0800 (PST) Received: from mail113-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.8; Fri, 7 Jan 2011 18:52:46 +0000 Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2-R.bigfish.com (Postfix) with ESMTP id D6820658340; Fri, 7 Jan 2011 18:52:46 +0000 (UTC) X-SpamScore: -42 X-BigFish: VS-42(zz936eK542N1370I4015L9371Pzz1202hzz8275bh8275dh1033ILz2fh2a8h668h34h62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2 (MessageSwitch) id 1294426366598892_4969; Fri, 7 Jan 2011 18:52:46 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.241]) by mail113-tx2.bigfish.com (Postfix) with ESMTP id 8DEAC3F0050; Fri, 7 Jan 2011 18:52:46 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 7 Jan 2011 18:52:45 +0000 Received: from PLSWEH02.ad.sprint.com (PLSWEH02.corp.sprint.com [144.226.242.131]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p07IqWoe016105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jan 2011 12:52:43 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH02.ad.sprint.com ([2002:90e2:f283::90e2:f283]) with mapi id 14.01.0255.000; Fri, 7 Jan 2011 12:52:34 -0600 From: "George, Wes E [NTK]" To: "int-area@ietf.org" , "v6ops@ietf.org" Thread-Topic: IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AQHLrpjrZ6ocuhICBkqv8r6Er4RibpPF1QWA Date: Fri, 7 Jan 2011 18:52:33 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.29] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A3_01CBAE72.20256EE0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "Howard, Lee" , Christopher LILJENSTOLPE Subject: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:50:42 -0000 ------=_NextPart_000_00A3_01CBAE72.20256EE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit As a direct result of discussions after Beijing about the hotly-contested draft regarding IANA allocating a new shared IPv4 address space, the authors of this draft realized that the root problem is actually the lack of IPv6 support in existing devices, which is adding a barrier to wider deployment in many networks. This is being made worse due to two things: lack of interest by vendors in back-porting true IPv6 support into devices that are software-upgradeable and could otherwise support it, and the fact that some vendors are still churning out devices which do not support IPv6 even as we stare down the imminent exhaustion of the IANA free IPv4 pool. This draft attempts to address this problem by updating the definition of an "IP-capable" node to require support for IPv6. The authors are fully aware that this is not going to solve the problem of legacy installed-base, nor is it going to prevent people from continuing to release hardware that is IPv4-only. However, we believe that the IETF is overdue to acknowledge that IPv6 will be a requirement going forward, and not just optional. We'd appreciate your support in adopting this as an int-area draft, or possibly a v6ops draft. We'd be happy to discuss the draft in either meeting at IETF 80 if the WG chair feels that it is appropriate. Thanks, Wes George -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Friday, January 07, 2011 1:28 PM To: George, Wes E [NTK] Cc: C.Donley@cablelabs.com; cdl@asgaard.org; lee.howard@twcable.com Subject: New Version Notification for draft-george-ipv6-required-00 A new version of I-D, draft-george-ipv6-required-00.txt has been successfully submitted by Wesley George and posted to the IETF repository. https://datatracker.ietf.org/doc/draft-george-ipv6-required/ Filename: draft-george-ipv6-required Revision: 00 Title: IPv6 Support Required for all IP-capable nodes Creation_date: 2011-01-06 WG ID: Independent Submission Number_of_pages: 7 Abstract: Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document deprecates the concept that an IP-capable node MAY support IPv4 _only_, and redefines an IP-capable node as one which supports either IPv6 _only_ or IPv4/IPv6 dual-stack. This document updates RFC1812 and 1122 to reflect the change in requirements. The IETF Secretariat. ------=_NextPart_000_00A3_01CBAE72.20256EE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMDcxODUyMjlaMCMGCSqGSIb3DQEJBDEWBBSBJzqi61IO vFGA4d/VOc54eNDm9TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYCqQ4N8/g1fPi8n k0DPVVlatskIu+seW98hpdf3TAYUpkQ5FwUaDTMh186lMm4ICgJjfHOjAbTIZjeX/wEdkAsaz/cb mZnRr4v0at1dbAQtEcfy3u9TrNrebInBHmSMHja1B5YKttMjkO0R2txttgS9wCuGRv1LVR/gG34o LklHTgAAAAAAAA== ------=_NextPart_000_00A3_01CBAE72.20256EE0-- From fred@cisco.com Fri Jan 7 13:14:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5C03A6948; Fri, 7 Jan 2011 13:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.451 X-Spam-Level: X-Spam-Status: No, score=-110.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 SaehjoLP9xhv; Fri, 7 Jan 2011 13:14:09 -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 E54B23A68C5; Fri, 7 Jan 2011 13:14:09 -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: AvsEAJoRJ02rR7H+/2dsb2JhbACkK3OjBpd9hUwEhGeGIoMeiBE Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 07 Jan 2011 21:16:16 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p07LGBdD017534; Fri, 7 Jan 2011 21:16:16 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 07 Jan 2011 13:16:16 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 07 Jan 2011 13:16:16 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D277EA5.9080304@isi.edu> Date: Fri, 7 Jan 2011 13:16:02 -0800 Message-Id: <4F35055C-659C-4757-AC2C-F99932EB09FD@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops , Internet Area Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:14:10 -0000 It looks like Ed, when he reformatted his reply to remove the draft = authors, managed to change v6ops@ietf.org to v6ops@ops.ietf.org. The old = address no longer works... Anyhow, my comment to Joe's response to Ed's response... On Jan 7, 2011, at 12:59 PM, Joe Touch wrote: > IMO, IPv6 support, or IPv6-capable, isn't going to cut it. >=20 > The IETF doesn't have an enforcement or validation arm, like = Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, = would be: >=20 > - IPv6 MUST be enabled by default > - all advertized/claimed IP capabilities MUST be enabled by default = using IPv6 >=20 > I.e., whatever the device supports in IP, it MUST be ready and = available in a default configuration for IPv6. I'm very sympathetic to your viewpoint, but on equipment I'm familiar = with it poses a few problems. For example, telling me that I have to = support IPv6 routing in all my IP routing protocols, and if they run on = IP they have to be able to run on IPv6, makes sense. Did you want all of = my routing protocols on, on all interfaces, by default? If not, which, = and why did you make that choice? Yes, we have IPv6 ACLs. Which ACL did = you want on by default? And so on. And then there is the principle of least surprise. Any idea what happens = when one of my customers finds something running on my equipment in his = network that he didn't plan on being there? I'll give you a hint: PSIRT = winds up making comments... For hosts, such as Linux/MacOSX/Windows, yes I would recommend that IPv6 = be on by default in an RFC-specified configuration. Not sure I want that = for the infrastructure. > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From Wesley.E.George@sprint.com Fri Jan 7 13:17:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25243A695C; Fri, 7 Jan 2011 13:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 igOSuToL6gw5; Fri, 7 Jan 2011 13:17:51 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by core3.amsl.com (Postfix) with ESMTP id 056993A6974; Fri, 7 Jan 2011 13:17:48 -0800 (PST) Received: from mail45-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.8; Fri, 7 Jan 2011 21:19:55 +0000 Received: from mail45-db3 (localhost.localdomain [127.0.0.1]) by mail45-db3-R.bigfish.com (Postfix) with ESMTP id 6958D1068545; Fri, 7 Jan 2011 21:25:45 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz542N1432N9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail45-db3 (localhost.localdomain [127.0.0.1]) by mail45-db3 (MessageSwitch) id 1294435545171702_27030; Fri, 7 Jan 2011 21:25:45 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.244]) by mail45-db3.bigfish.com (Postfix) with ESMTP id 1AFA04A804D; Fri, 7 Jan 2011 21:25:45 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 7 Jan 2011 21:19:53 +0000 Received: from PLSWEH01.ad.sprint.com (PLSWEH01.corp.sprint.com [144.226.242.129]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p07LD3ZI027075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jan 2011 15:13:05 -0600 Received: from PDAWEH04.ad.sprint.com (144.226.111.59) by PLSWEH01.ad.sprint.com (144.226.242.129) with Microsoft SMTP Server (TLS) id 14.1.255.0; Fri, 7 Jan 2011 15:19:49 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH04.ad.sprint.com ([2002:90e2:6f3b::90e2:6f3b]) with mapi id 14.01.0255.000; Fri, 7 Jan 2011 15:19:48 -0600 From: "George, Wes E [NTK]" To: Joe Touch , Ed Jankiewicz Thread-Topic: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AQHLrq3iI6Iy3pLjcUWdTPLcKiedQ5PGAa2A Date: Fri, 7 Jan 2011 21:19:47 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E049E93@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> In-Reply-To: <4D277EA5.9080304@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.29] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E5_01CBAE86.B346BF80" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" , "int-area@ietf.org" Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:17:52 -0000 ------=_NextPart_000_00E5_01CBAE86.B346BF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Friday, January 07, 2011 3:59 PM > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft- > george-ipv6-required > > > - IPv6 MUST be enabled by default > - all advertized/claimed IP capabilities MUST be enabled by default > using IPv6 > > I.e., whatever the device supports in IP, it MUST be ready and > available > in a default configuration for IPv6. [WES] That "default" keyword is one third-rail that I'd rather not touch. I understand the idea - if the (non-technical) customer must do something to enable it, it may as well not be there... But ultimately this is meant to be a generic doc that refers you to other docs that cover the more specifics about what should and should not be on by default, etc. And those subtending documents is where specifics like that should be covered. I'm open to discussion on adding something like your second statement clarifying that IPv6 support translates to feature parity between IPv4 and IPv6, but I hesitate to add too much complexity. Propose text? Wes ------=_NextPart_000_00E5_01CBAE86.B346BF80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMDcyMTE5NDZaMCMGCSqGSIb3DQEJBDEWBBQHSIGJPuiZ fWL/KyuDb4G7s31HwDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAWPlGnDD7Sx5DC Ndgw8RmSpimwo+dp0TPinzuDHYPRx/PPa0vggJe9tpce7xZP9Dn1us4zD9TbfYpT5d198vZHHnpu sWWVbWzi4ovUxEVWePeVmnkGHTtH71jUCCJu2vhe1W9FmMcpSIVv8ssNDBFJ+WivupVfvmKn1+xa 29fqpgAAAAAAAA== ------=_NextPart_000_00E5_01CBAE86.B346BF80-- From brian.e.carpenter@gmail.com Fri Jan 7 14:37:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD33E3A6987; Fri, 7 Jan 2011 14:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.444 X-Spam-Level: X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 o0qS9TDY6lYB; Fri, 7 Jan 2011 14:37:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3C3413A6948; Fri, 7 Jan 2011 14:37:44 -0800 (PST) Received: by vws7 with SMTP id 7so7106934vws.31 for ; Fri, 07 Jan 2011 14:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q4HiF/0F8eyLwfx84b8WX+8mZeGRtijEFGL0G3VjUps=; b=v+hk2ybduezB9gunkvWekXRX80x+x8modUQBVpaXv4bKVqugmZGYpvZXAkzkRlLRhB 8rpZtsHkpeOthHioEOyKyPYlV0TpseNRmzzQVptCyIu3/b97Za1T44Jy6OWIuOiQcLru SEVcC1LmPDcyFPx4mOmOMYB25Oyd9+b0RduX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nfA6/akJUJJV6W6MeOm3n4u6hOi2HhkqlZD+Bd412o5DokgkMNzgTdi283VnKOwbWR WZiqwFx9LLT8WEJZzbvi/14eTvlNkG285bY0IKzIzMpqg/6VKGgZhATcPlp0fcOZa95W o9dge3r5A5FD6o4nasuvQBQsYZmjYcbmWMgPI= Received: by 10.220.184.66 with SMTP id cj2mr7580310vcb.140.1294439990811; Fri, 07 Jan 2011 14:39:50 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id fl9sm10014028vbb.0.2011.01.07.14.39.48 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 14:39:50 -0800 (PST) Message-ID: <4D27962F.9030005@gmail.com> Date: Sat, 08 Jan 2011 11:39:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> In-Reply-To: <4D278B93.8050903@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:37:48 -0000 On 2011-01-08 10:54, Joe Touch wrote: > > > On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >> Ok. So just to verify, if a box that is sold today that does NAT44 >> out-of-the-box (I have one here on my desk, does DHCP client on the >> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >> when first powered up) wants to comply with this it would need to also >> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >> when initially powered up? > > IMO, yes. IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, and many related discussions. Brian From brian.e.carpenter@gmail.com Fri Jan 7 15:21:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AD628C11F; Fri, 7 Jan 2011 15:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 N5vJHMHSPQ1D; Fri, 7 Jan 2011 15:21:22 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 98F5B3A6995; Fri, 7 Jan 2011 15:18:40 -0800 (PST) Received: by vws7 with SMTP id 7so7118141vws.31 for ; Fri, 07 Jan 2011 15:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=r6FhRfmsok4UUkIwTiE6HzpCJbvxgbq6r0J6hAQKm7M=; b=GDeJ5J3vzcq0cHAYR0sh5qErBPMze0tn+RktEwYomT4vvI2yyxOdmvekp0ok6mg0Ri TgnNfCQcp7a8EjnjVY4EpUX4LkKo01K9hkE/9dWGJo77SlTqs0nm/emsbPo0k9mh16oi fDgE5+Bt4K2wB2R6qt1Znyk0h+Xtwf8QJjQnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=m1/nDufk0VCuXeFp8ljCCdpHOpoW/i+3BMsL6gHmRci89Fo7JmMdkIaow1MoSWRLX1 7FWXbkiechJ+9Y2kzdO9CLAgcHTDZRtGqrdyQAydmi5hH4h0SZTjOasc4BvmssX3Tumx cg/RbFyYWJQGiYw1gOuJETGNt7rtQ+2uQ0LQ4= Received: by 10.220.201.1 with SMTP id ey1mr7803914vcb.61.1294442446971; Fri, 07 Jan 2011 15:20:46 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id bq5sm5873571vcb.32.2011.01.07.15.20.43 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 15:20:45 -0800 (PST) Message-ID: <4D279FC7.3000904@gmail.com> Date: Sat, 08 Jan 2011 12:20:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> In-Reply-To: <4D279717.1050602@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:21:23 -0000 > PS - these docs also ignore a valid reason for a NAT - which is to be a > "single IP address front end to a set of back-end IP-capable devices". > Such devices are important when a cluster of devices is intended to act > as a single device on the Internet, and a NAT can be an effective way to > implement that front-end. Yes, that's the one described in US patent 5371852. I don't think the IETF has strayed into that territory. Brian From fernando.gont.netbook.win@gmail.com Fri Jan 7 19:27:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFED53A6987; Fri, 7 Jan 2011 19:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.668, 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 We5WY8LSgw2N; Fri, 7 Jan 2011 19:27:01 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id E54633A695C; Fri, 7 Jan 2011 19:26:54 -0800 (PST) Received: by yxd5 with SMTP id 5so3968264yxd.1 for ; Fri, 07 Jan 2011 19:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=mIQ1/GBTO0haJ1kcr0+sVPIXqFc1BngWLsblw2OZHYw=; b=Y9doJBH41gmlb9EpLaicrberwZ1EB7I3kk5zhpS5fjMmNqT6Qp9/v4IlepppIGooq+ gIVfpjrbCNz4kb1Qa3cYaM8B5q+cKZPgx52hw+wqszfvXQWZdV5okBk3DKkjvSc0Q9BM 1qNzpzQ7voracOKcd7NgF5MI2tznP9t8VeNGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=E4GFiHFzV4OGIhnJLE91E66ZafFJNBxcmODB5vzj0Zc5mLT6YjS4Aj5Bi+pPMerh4a i0klqxRwmKM+/TCcClk6+ZttyiHnbqygc4jJJxB8MmdhVsVjH8+w601QbJ7vlVNEC3z/ BMRmBBn10E5xgKBjMo2hS5uLhXodfmtZ3oAK4= Received: by 10.150.202.7 with SMTP id z7mr23933416ybf.436.1294457339716; Fri, 07 Jan 2011 19:28:59 -0800 (PST) Received: from [192.168.123.100] ([190.48.240.140]) by mx.google.com with ESMTPS id v4sm850696ybe.17.2011.01.07.19.28.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 19:28:58 -0800 (PST) Sender: Fernando Gont Message-ID: <4D27D9EB.4010209@gont.com.ar> Date: Sat, 08 Jan 2011 00:28:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Josh Rambo References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org, Joe Touch Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 03:27:23 -0000 On 07/01/2011 07:42 p.m., Josh Rambo wrote: > That seems at odds with the goal of end-to-end transparency on the Internet. > If it boots up with NAT66 out of the box, then it requires user intervention > to remove that NAT66. You'd end up with NAT66 on every residential gateway > in the world. End-to-end transparency in the sense that every node will be reachable from every node? -- IMHO, forget about it (see slide 13 of: http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From edward.jankiewicz@sri.com Fri Jan 7 21:01:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A743A698A; Fri, 7 Jan 2011 21:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 ovVNa9wZZGyR; Fri, 7 Jan 2011 21:01:36 -0800 (PST) Received: from mail1.sri.com (newmail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id 58CB33A6985; Fri, 7 Jan 2011 21:01:36 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LEO009F9G641440@mail.sri.com>; Fri, 07 Jan 2011 16:03:42 -0800 (PST) Message-id: <4D27A9DB.9020302@sri.com> Date: Fri, 07 Jan 2011 19:03:39 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: "Rajiv Asati (rajiva)" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> In-reply-to: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> Cc: IPv6 Operations , int-area@ietf.org, Joe Touch Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 05:01:37 -0000 there is a list of IPv6 requirements in RFC 4294, although it is only Informational, and is currently being replaced by draft-6man-node-req-bis (in process). It was not intended to be an absolute statement of the IPv6 requirements, so it may not completely satisfy the need for a standards track analog to RFC 1122 et al. I think we should be careful not to let this degenerate into yet another "tastes great/less filling" debate on NAT, but when we aim for IPv6 parity with IPv4 features we could distinguish between the standards for internetworking embodied in IPv4 and the things that were added on in non-standard ways. On 1/7/2011 6:19 PM, Rajiv Asati (rajiva) wrote: > Joe, > >> Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, >> 1123, and 1812 (and their supplementary RFCs). > Ditto. I am sure that we could come up with few more. > >> But there's a broader issue - >> the point that "if IPv4 is supported better, in any way, than IPv6, on >> a device, then there is incentive to not use IPv6". > This broader issue in conjunction with all that exists on an IPv4 > gateway may not be needed on an IPv6 gateway, warrants the set of MUST > and SHOULD/MAY IPv6 features. That was the intent of my suggestion. > > Cheers, > Rajiv > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, January 07, 2011 5:58 PM >> To: Rajiv Asati (rajiva) >> Cc: Josh Rambo; IPv6 Operations; int-area@ietf.org >> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- >> george-ipv6-required >> >> >> >> On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: >>> It is imperative that the draft specify what basic IPv6 >> functionalities >>> must be supported on every node. >> I'm not sure what that means, though. Nobody would *require* a router >> to >> support a GUI for management, but, IMO, if the GUI supplied works only >> for IPv4, it's a killer. >> >> Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, >> 1123, >> and 1812 (and their supplementary RFCs). But there's a broader issue - >> the point that "if IPv4 is supported better, in any way, than IPv6, on >> a >> device, then there is incentive to not use IPv6". >> >> Joe > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From randy@psg.com Sat Jan 8 02:54:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EB63A69CD; Sat, 8 Jan 2011 02:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 0vPkEgueYwS0; Sat, 8 Jan 2011 02:53:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 2E11E3A69CB; Sat, 8 Jan 2011 02:53:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PbWRA-000HtI-EJ; Sat, 08 Jan 2011 10:54:20 +0000 Date: Sat, 08 Jan 2011 19:54:19 +0900 Message-ID: From: Randy Bush To: Wes George In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , int-area@ietf.org Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 10:54:08 -0000 > We'd appreciate your support in adopting this as an int-area draft, or > possibly a v6ops draft. i support this being adopted some place so it can be discussed and move forward randy From lee@asgard.org Sat Jan 8 07:30:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30CA73A6943 for ; Sat, 8 Jan 2011 07:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CcMBEIlpiDZ for ; Sat, 8 Jan 2011 07:30:19 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id 48BC83A6908 for ; Sat, 8 Jan 2011 07:30:18 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p08FWQUo027919 for ; Sat, 8 Jan 2011 10:32:26 -0500 Authentication-Results: cm-omr10 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [96.255.55.40] ([96.255.55.40:1596] helo=HDC00027112) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 57/AB-09637-ADE782D4; Sat, 08 Jan 2011 10:12:26 -0500 From: "Lee Howard" To: "'Joe Touch'" , "'Rajiv Asati \(rajiva\)'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> In-Reply-To: <4D279A91.2040300@isi.edu> Date: Sat, 8 Jan 2011 10:12:23 -0500 Message-ID: <000201cbaf46$742a93b0$5c7fbb10$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuuxEXqmQLPo0NsRA6Mzbv1ltrjvAAgBEig Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:30:20 -0000 > > On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: > > It is imperative that the draft specify what basic IPv6 functionalities > > must be supported on every node. > > I'm not sure what that means, though. Nobody would *require* a router to > support a GUI for management, but, IMO, if the GUI supplied works only > for IPv4, it's a killer. > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, 1123, > and 1812 (and their supplementary RFCs). See rfc4294, IPv6 Node Requirements, and draft-ietf-v6ops-cpe-router, Basic Requirements for IPv6 Customer Edge Routers, both of which are cited in draft-george. Including requirements by reference is the right way to go, here. If there are additional requirements, they should be in separate drafts updating those requirements documents. > But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on a > device, then there is incentive to not use IPv6". If IPv6 isn't supported at all, it doesn't matter what the incentive is. I believe there is consensus that NAT66 should not be defined, or on by default (I don't see it in the BEHAVE charter, for instance). Therefore, requiring NAT66 is equivalent to prohibiting IPv6. Lee From touch@isi.edu Fri Jan 7 13:32:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3105F3A6935; Fri, 7 Jan 2011 13:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 rzA9R0FKm4mV; Fri, 7 Jan 2011 13:32:19 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2D8BF3A698A; Fri, 7 Jan 2011 13:28:58 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07LRjPE016127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 13:27:45 -0800 (PST) Message-ID: <4D278551.5070608@isi.edu> Date: Fri, 07 Jan 2011 13:27:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "George, Wes E [NTK]" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <54E900DC635DAB4DB7A6D799B3C4CD8E049E93@PLSWM12A.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E049E93@PLSWM12A.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: "v6ops@ietf.org" , "int-area@ietf.org" Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:32:21 -0000 On 1/7/2011 1:19 PM, George, Wes E [NTK] wrote: >> -----Original Message----- >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Joe Touch >> Sent: Friday, January 07, 2011 3:59 PM >> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft- >> george-ipv6-required >> >> >> - IPv6 MUST be enabled by default >> - all advertized/claimed IP capabilities MUST be enabled by default >> using IPv6 >> >> I.e., whatever the device supports in IP, it MUST be ready and >> available >> in a default configuration for IPv6. > > [WES] That "default" keyword is one third-rail that I'd rather not touch. I > understand the idea - if the (non-technical) customer must do something to > enable it, it may as well not be there... But ultimately this is meant to be > a generic doc that refers you to other docs that cover the more specifics > about what should and should not be on by default, etc. And those subtending > documents is where specifics like that should be covered. > > I'm open to discussion on adding something like your second statement > clarifying that IPv6 support translates to feature parity between IPv4 and > IPv6, but I hesitate to add too much complexity. Propose text? The basic idea is that: - capabilities supported for IPv4 MUST be supported for IPv6 - defaults enabled for IPv4 MUST be enabled for IPv6 not sure whether this is "instead of for IPv4", or just in addition Joe From touch@isi.edu Fri Jan 7 13:32:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB3E3A6969; Fri, 7 Jan 2011 13:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Df2xE7XR-76e; Fri, 7 Jan 2011 13:32:24 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 686363A6996; Fri, 7 Jan 2011 13:29:05 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07LQH66016009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 13:26:17 -0800 (PST) Message-ID: <4D2784F9.8000502@isi.edu> Date: Fri, 07 Jan 2011 13:26:17 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4F35055C-659C-4757-AC2C-F99932EB09FD@cisco.com> In-Reply-To: <4F35055C-659C-4757-AC2C-F99932EB09FD@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: v6ops v6ops , Internet Area Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:32:26 -0000 On 1/7/2011 1:16 PM, Fred Baker wrote: > It looks like Ed, when he reformatted his reply to remove the draft authors, managed to change v6ops@ietf.org to v6ops@ops.ietf.org. The old address no longer works... > > Anyhow, my comment to Joe's response to Ed's response... > > On Jan 7, 2011, at 12:59 PM, Joe Touch wrote: > >> IMO, IPv6 support, or IPv6-capable, isn't going to cut it. >> >> The IETF doesn't have an enforcement or validation arm, like Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, would be: >> >> - IPv6 MUST be enabled by default >> - all advertized/claimed IP capabilities MUST be enabled by default using IPv6 >> >> I.e., whatever the device supports in IP, it MUST be ready and available in a default configuration for IPv6. > > I'm very sympathetic to your viewpoint, but on equipment I'm > familiar with it poses a few problems. For example, telling me that I > have to support IPv6 routing in all my IP routing protocols, and if > they run on IP they have to be able to run on IPv6, makes sense. Did > you want all of my routing protocols on, on all interfaces, by > default? If not, which, and why did you make that choice? Yes, we > have IPv6 ACLs. Which ACL did you want on by default? And so on. Basically, if it's on by default for IPv4, it MUST be on by default for IPv6. I appreciate that not everything is on by default, esp in routers. > And then there is the principle of least surprise. Any idea what > happens when one of my customers finds something running on my equipment > in his network that he didn't plan on being there? I'll give you a hint: > PSIRT winds up making comments... See above; the idea is just to bring IPv6 to the level that people currently enjoy support for Ipv4, not to force them into it per se. > For hosts, such as Linux/MacOSX/Windows, yes I would recommend that > IPv6 be on by default in an RFC-specified configuration. Not sure I > want that for the infrastructure. At least one significant problem with deployment is IPv6 support for network management and monitoring tools. If that's not available from the start - when purchased - the equipment is unlikely to ever be used for IPv6. Regardless, I proposed what I think is a more useful metric. Yes, there are some nuances (i.e., what does "on by default" mean), but the general intent is: don't claim a capability works for IP unless it works for IPv6 out of the box Joe From touch@isi.edu Fri Jan 7 13:52:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6513A6961; Fri, 7 Jan 2011 13:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 l9fH1Xx+nCAA; Fri, 7 Jan 2011 13:52:36 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9B2B23A6948; Fri, 7 Jan 2011 13:52:36 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07LsRWl020749 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 13:54:29 -0800 (PST) Message-ID: <4D278B93.8050903@isi.edu> Date: Fri, 07 Jan 2011 13:54:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: matthew@matthew.at References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> In-Reply-To: <4D278AE7.4080502@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:52:37 -0000 On 1/7/2011 1:51 PM, Matthew Kaufman wrote: > Ok. So just to verify, if a box that is sold today that does NAT44 > out-of-the-box (I have one here on my desk, does DHCP client on the > "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports > when first powered up) wants to comply with this it would need to also > do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) > when initially powered up? IMO, yes. Joe From touch@isi.edu Fri Jan 7 14:40:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD0E28C13D; Fri, 7 Jan 2011 14:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 Qas-BbkDuY8X; Fri, 7 Jan 2011 14:40:09 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DE1C63A6935; Fri, 7 Jan 2011 14:40:09 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07Mg7Tp027819 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:42:07 -0800 (PST) Message-ID: <4D2796BF.1030700@isi.edu> Date: Fri, 07 Jan 2011 14:42:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> In-Reply-To: <4D27962F.9030005@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:40:10 -0000 On 1/7/2011 2:39 PM, Brian E Carpenter wrote: > On 2011-01-08 10:54, Joe Touch wrote: >> >> >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >>> Ok. So just to verify, if a box that is sold today that does NAT44 >>> out-of-the-box (I have one here on my desk, does DHCP client on the >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >>> when first powered up) wants to comply with this it would need to also >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >>> when initially powered up? >> >> IMO, yes. > > IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, > and many related discussions. You're arguing against the need for 6-to-6 NAT. That's not my point at all. If it works for v6, it needs to work for v6. Period. Anything less than that *has been* and will continue to be used as a reason not to enable v6. Je From touch@isi.edu Fri Jan 7 14:42:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6133A69A2; Fri, 7 Jan 2011 14:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 BQjc31VEWFGb; Fri, 7 Jan 2011 14:42:21 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7F7653A6992; Fri, 7 Jan 2011 14:41:47 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07MhYF8027999 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:43:34 -0800 (PST) Message-ID: <4D279717.1050602@isi.edu> Date: Fri, 07 Jan 2011 14:43:35 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> In-Reply-To: <4D27962F.9030005@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:42:22 -0000 On 1/7/2011 2:39 PM, Brian E Carpenter wrote: > On 2011-01-08 10:54, Joe Touch wrote: >> >> >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >>> Ok. So just to verify, if a box that is sold today that does NAT44 >>> out-of-the-box (I have one here on my desk, does DHCP client on the >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >>> when first powered up) wants to comply with this it would need to also >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >>> when initially powered up? >> >> IMO, yes. > > IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, > and many related discussions. PS - these docs also ignore a valid reason for a NAT - which is to be a "single IP address front end to a set of back-end IP-capable devices". Such devices are important when a cluster of devices is intended to act as a single device on the Internet, and a NAT can be an effective way to implement that front-end. Joe From touch@isi.edu Fri Jan 7 14:45:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D90A28C0E3; Fri, 7 Jan 2011 14:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 WdXg4GnSur6h; Fri, 7 Jan 2011 14:45:41 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5226128B797; Fri, 7 Jan 2011 14:45:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07Mj6H8028509 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:45:06 -0800 (PST) Message-ID: <4D279773.30102@isi.edu> Date: Fri, 07 Jan 2011 14:45:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Josh Rambo References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:45:42 -0000 On 1/7/2011 2:42 PM, Josh Rambo wrote: > On Fri, Jan 7, 2011 at 4:54 PM, Joe Touch wrote: >> >> >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >>> >>> Ok. So just to verify, if a box that is sold today that does NAT44 >>> out-of-the-box (I have one here on my desk, does DHCP client on the >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >>> when first powered up) wants to comply with this it would need to also >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >>> when initially powered up? >> >> IMO, yes. > > That seems at odds with the goal of end-to-end transparency on the Internet. > If it boots up with NAT66 out of the box, then it requires user intervention > to remove that NAT66. You'd end up with NAT66 on every residential gateway > in the world. Again, you're arguing against NAT. That's not what I'm suggesting. If you really can make the case that a capability needs to be enabled for IPv4, but should never be enabled for V6, then *maybe* - but, again, that *will* be used as an excuse not to adopt the device in a V6 environment, IMO. If the box is a NAT, it's a NAT. If that's not what you want to sell, then don't include a NAT. Joe From touch@isi.edu Fri Jan 7 14:53:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CBD3A697E; Fri, 7 Jan 2011 14:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 1zHau3Y-G9LO; Fri, 7 Jan 2011 14:53:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6E8FF3A6985; Fri, 7 Jan 2011 14:53:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07MtgMv000417 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:55:42 -0800 (PST) Message-ID: <4D2799EF.2070504@isi.edu> Date: Fri, 07 Jan 2011 14:55:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Josh Rambo References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D279773.30102@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:53:56 -0000 On 1/7/2011 2:47 PM, Josh Rambo wrote: > On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch wrote: >> >> >> On 1/7/2011 2:42 PM, Josh Rambo wrote: >>> That seems at odds with the goal of end-to-end transparency on the >>> Internet. >>> If it boots up with NAT66 out of the box, then it requires user >>> intervention >>> to remove that NAT66. You'd end up with NAT66 on every residential gateway >>> in the world. >> >> Again, you're arguing against NAT. That's not what I'm suggesting. >> >> If you really can make the case that a capability needs to be enabled for >> IPv4, but should never be enabled for V6, then *maybe* - but, again, that >> *will* be used as an excuse not to adopt the device in a V6 environment, >> IMO. >> >> If the box is a NAT, it's a NAT. If that's not what you want to sell, then >> don't include a NAT. > > I'm arguing that there are some features of v4 that are not appropriate to > enable by default in v6. NAT is one of those features. A home, residential > gateway is a gateway. That is it's true purpose. It's not a NAT box, it just > has to perform that function to operate in the limited v4 address space. That's one viewpoint; in that case, then the NAT would not need to support IPv6. However, some places expect the NAT for various reasons: - limits incoming connections (disrupting use of home net connections for business uses, or as a way to block viruses - not a great way, but it's one reason it's on even when not necessary) - enables better tracking of customer behavior (need to track only one IP address) - no need to run DHCP back to the CO (no impact on CO DHCP when users add/remove devices inside their house) - protect intra-house networking (again, not the best way to do this, but also can make it easier to prevent leakage of LAN-intended protocols into the CO, without requiring CO equipment to filter) > So, the true function of a gateway should be to be a gateway, which > doesn't involve a NAT66. > Just because v4 needs it by default doesn't mean v6 does or should. Understood. Caveats do apply. But the overall point is still valid - in general - with few, specific, and *deliberate* exceptions, if it works for IPv4, it ought to work for IPv6 too. Right now, e.g., many devices work fine to transit IPv6, but their net mgt needs IPv4. That's insufficient, IMO, to claim "IPv6" on a box. Joe From touch@isi.edu Fri Jan 7 14:57:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D33728C179; Fri, 7 Jan 2011 14:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 VU+UBDiqvZ3i; Fri, 7 Jan 2011 14:57:01 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E15C728C176; Fri, 7 Jan 2011 14:57:00 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07MwP06000772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:58:25 -0800 (PST) Message-ID: <4D279A91.2040300@isi.edu> Date: Fri, 07 Jan 2011 14:58:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Sat, 08 Jan 2011 08:16:52 -0800 Cc: int-area@ietf.org, IPv6 Operations Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:57:01 -0000 On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: > It is imperative that the draft specify what basic IPv6 functionalities > must be supported on every node. I'm not sure what that means, though. Nobody would *require* a router to support a GUI for management, but, IMO, if the GUI supplied works only for IPv4, it's a killer. Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, 1123, and 1812 (and their supplementary RFCs). But there's a broader issue - the point that "if IPv4 is supported better, in any way, than IPv6, on a device, then there is incentive to not use IPv6". Joe From matthew@matthew.at Fri Jan 7 13:49:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F463A694E; Fri, 7 Jan 2011 13:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 C+YB+45Ji41P; Fri, 7 Jan 2011 13:49:32 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id 9067C3A6948; Fri, 7 Jan 2011 13:49:29 -0800 (PST) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 7CDB425010D; Fri, 7 Jan 2011 13:51:36 -0800 (PST) Message-ID: <4D278AE7.4080502@matthew.at> Date: Fri, 07 Jan 2011 13:51:35 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> In-Reply-To: <4D2789AF.1050903@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Jan 2011 08:17:43 -0800 Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:49:33 -0000 On 1/7/2011 1:46 PM, Joe Touch wrote: > > > On 1/7/2011 1:40 PM, Matthew Kaufman wrote: >> On 1/7/2011 12:59 PM, Joe Touch wrote: >>> >>> I.e., whatever the device supports in IP, it MUST be ready and >>> available in a default configuration for IPv6. >> >> Like NAT? > > Well, if you have a device that NATs, and it only supports it for > IPv4, and that's a behavior you want (for privacy or other reasons), > then yes, it should support it for IPv6. > > Sure, I'd hope that if IPv6 were ubiquitous that less people would > buy/use NATs, but I don't want the existence of IPv4-only NATs to > inhibit that ubiquity. > > Joe Ok. So just to verify, if a box that is sold today that does NAT44 out-of-the-box (I have one here on my desk, does DHCP client on the "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports when first powered up) wants to comply with this it would need to also do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) when initially powered up? Matthew Kaufman From fltemplin@yahoo.com Fri Jan 7 14:17:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328903A6961 for ; Fri, 7 Jan 2011 14:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 p0eiehOARkGp for ; Fri, 7 Jan 2011 14:17:55 -0800 (PST) Received: from web56701.mail.re3.yahoo.com (web56701.mail.re3.yahoo.com [66.196.97.60]) by core3.amsl.com (Postfix) with SMTP id 919593A6992 for ; Fri, 7 Jan 2011 14:17:52 -0800 (PST) Received: (qmail 75113 invoked by uid 60001); 7 Jan 2011 22:19:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294438796; bh=lfGdoMsXlCJWcPCp2P5rtKLV4KA/gswh1Il5NSjhSyo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j7rzrK5hQdhS9ms0viDhRh58ZW3lgt8wvueO4EOldJSGMkaWVufFzIP6W2fXZ0aQ2F8uXoVoFb17dMPkB9mTE6FTg4S2wa/96lWCFXIAEzuB5Xsg1Uco2dbNqq+EO9MnmpuxkSNqXItn3mFQilu1MBPEheCq7zYEfe6AdkYq+6s= 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:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h3cS9LT04M1sjsTp5Rk9X+wgUKVFZpG3oChsYT8ZVws/qgUzyMEOX7MQuWn5x4kkfVXGv/x/2zu0aJxi8mTzmltug41lJGyP2TIFWvkTkUGHadi4HQZvhCd6g4u6rFlxmNpE2uJSd9p02uHLPrjXlf9v5hVepnTdgaRnKKMQwtc=; Message-ID: <615031.74637.qm@web56701.mail.re3.yahoo.com> X-YMail-OSG: CEPu1r0VM1lC7UFPdG3lOna3z8STGmWYi_XKVyFGmIDpQz0 WGMxZfBX.74phsd8xVU04DdWBVsRa0SZv_5AFzxmZ6NLMuoADrf4TCAFy.we LGkhMHvOTL6klnqiQb9gW35CoZTPi_B7My_rO_98BF.Em2D1Nq7k5clmex88 04.WkEH1KbhWKRaqB6ER6zOi8PkDAq6GVsbs6fFT9C23xX1XlxiWC64hM1ek q5RzyWKsV1qjneyMgNImZO47v_1CEFQw4UwWGPwIYbOAqPiWjcCcaabXgeMI MXzhgCYQ_6ftnGj8cg4NE0TDlzMgTWgTtfF.yYYJ04DqBm.r.ItxB5McsS5G 6bq_h.pz6DdswhELML8R5egOZuk6Xt2D.BX8jcLKrWU0- Received: from [130.76.32.198] by web56701.mail.re3.yahoo.com via HTTP; Fri, 07 Jan 2011 14:19:56 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <4D1A59F2.4010606@joelhalpern.com> <723770.66310.qm@web56706.mail.re3.yahoo.com> <4D277C6D.5040708@joelhalpern.com> Date: Fri, 7 Jan 2011 14:19:56 -0800 (PST) From: Fred Templin To: "Joel M. Halpern" In-Reply-To: <4D277C6D.5040708@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-480863324-1294438796=:74637" X-Mailman-Approved-At: Sat, 08 Jan 2011 08:17:43 -0800 Cc: IPv6 Operations , draft-ietf-v6ops-tunnel-loops@tools.ietf.org, gen-art@ietf.org, Mary Barnes Subject: Re: [v6ops] [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:17:56 -0000 --0-480863324-1294438796=:74637 Content-Type: text/plain; charset=us-ascii Hi Joel, In response to your questions below, 6rd can only be handled by explicit configuration of known 6rd prefixes. As you indeed mention, there is no meaningful rule that captures all 6rd prefixes. Regarding ISATAP, indeed there is a chance of 2^-32 that a non-ISATAP address will be recognized as an ISATAP-address. In this case, an erroneous drop will occur only if the lower 32 bits of the IID will be equal to the IP address of the current host. The chance of that happening is 2^-32, if the IID is random. This means that an erroneous drop will occur with a chance of 2^-64, which is very slim (albeit possible). Fred and Gabi ________________________________ From: Joel M. Halpern To: Fred Templin Cc: Mary Barnes ; gen-art@ietf.org; Joel Jaeggli ; Ron Bonica ; draft-ietf-v6ops-tunnel-loops@tools.ietf.org; IPv6 Operations Sent: Fri, January 7, 2011 12:49:49 PM Subject: Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt I do not see how 6rd can be handled. There is not really any meaningful "domain" to use to figure out who is using what 6rd prefix. And what token does ISATAP use? I presume that I missed something when the only token I could find was in the lower 64 bits (and tehrefore could be accidentally duplicated elsewhere. Thanks, Joel On 1/7/2011 3:43 PM, Fred Templin wrote: > Hi Joel, > > Thank you for your time in reviewing this work. In Section 3.1, under > this proposed > mitigation the tunnel router ideally indeed must check for all > encapsulation formats in > which an IPv4 address may be embedded within an IPv6 address. This means > that > the router must check for all known protocol-41 encapsulation formats > and must be > modified to check for any new formats should new ones be specified. In > practice, if > a router is configured to check only a subset of encapsulation formats, > then it will be > immune only to attacks in which the attacker uses the configured > encapsulation > formats in the source/destination address of the attack packet. > > Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a well-known > "token" indicating that an IPv4 address is embedded. Other formats > (e.g., 6rd) > do not include such a token and hence would require special configuration at > the router to indicate which IPv6 prefixes within the routing domain are > 6rd ones. > > Do you feel there are any additional clarifications on this needed > beyond what > already appears in Section 3.1? > > Fred and Gabi > > *From:* Joel M. Halpern > *To:* Mary Barnes > *Cc:* gen-art@ietf.org; Joel Jaeggli ; Ron Bonica > ; draft-ietf-v6ops-tunnel-loops@tools.ietf.org; > IPv6 Operations > *Sent:* Tue, December 28, 2010 1:43:14 PM > *Subject:* [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-v6ops-tunnel-loops-01.txt > Routing Loop Attack using IPv6 Automatic Tunnels: > Problem Statement and Proposed Mitigations > Reviewer: Joel M. Halpern > Review Date: 28-Dec-2010 > IETF LC End Date: 29-Dec-2010 > IESG Telechat date: 06-Jan-2011) > > Summary: Nearly ready for publication as an Informational RFC > > Major issues: It is unclear in the document what assumptions section 3.1 > makes about the relationship between supported tunnels and checked > embedded addresses. Is there an assumption that the router only has to > check for addresses in the format and prefix it supports? I hope so. > Otherwise, a router seems to be expected to look at an arbitrary IPv6 > addresses, guess whether it has an embedded IPv4 addresses, and perform > filter checks on that guessed addresses against its own addresses. > If indeed their is a relationship, then it would really help if section > 3.1 said that. > Unfortunately, I am afraid no such relationship is assumed. If not, I > would like to see significantly better explanation of how the router is > to reliably know that there is a 6rd or ISATAP address embedded in the > v6 address. > > Minor issues: > > Nits/editorial comments: --0-480863324-1294438796=:74637 Content-Type: text/html; charset=us-ascii
Hi Joel,

In response to your questions below, 6rd can only be handled by explicit
configuration of known 6rd prefixes. As you  indeed mention, there is no
meaningful rule that captures all 6rd prefixes. Regarding ISATAP, indeed
there is a chance of 2^-32 that a non-ISATAP address  will be recognized
as an ISATAP-address. In this case, an erroneous drop  will occur only if
the lower 32 bits of the IID will be equal to the IP address of the current host.
The chance of that happening is 2^-32, if the IID is random. This means that
an erroneous drop will occur with a chance of 2^-64,  which is very slim
(albeit possible).

Fred and Gabi

From: Joel M. Halpern <jmh@joelhalpern.com>
To: Fred Templin <fltemplin@yahoo.com>
Cc: Mary Barnes <mary.ietf.barnes@gmail.com>; gen-art@ietf.org; Joel Jaeggli <joelja@bogus.com>; Ron Bonica <rbonica@juniper.net>; draft-ietf-v6ops-tunnel-loops@tools.ietf.org; IPv6 Operations <v6ops@ops.ietf.org>
Sent: Fri, January 7, 2011 12:49:49 PM
Subject: Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt

I do not see how 6rd can be handled.  There is not really any meaningful
"domain" to use to figure out who is using what 6rd prefix.

And what token does ISATAP use?  I presume that I missed something when
the only token I could find was in the lower 64 bits (and tehrefore
could be accidentally duplicated elsewhere.

Thanks,
Joel

On 1/7/2011 3:43 PM, Fred Templin wrote:
> Hi Joel,
>
> Thank you for your time in reviewing this work. In Section 3.1, under
> this proposed
> mitigation the tunnel router ideally indeed must check for all
> encapsulation formats in
> which an IPv4 address may be embedded within an IPv6 address. This means
> that
> the router must check for all known protocol-41 encapsulation formats
> and must be
> modified to check for any new formats should new ones be specified. In
> practice, if
> a router is configured to check only a subset of encapsulation formats,
> then it will be
> immune only to attacks in which the attacker uses the configured
> encapsulation
> formats in the source/destination address of the attack packet.
>
> Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a well-known
> "token" indicating that an IPv4 address is embedded. Other formats
> (e.g., 6rd)
> do not include such a token and hence would require special configuration at
> the router to indicate which IPv6 prefixes within the routing domain are
> 6rd ones.
>
> Do you feel there are any additional clarifications on this needed
> beyond what
> already appears in Section 3.1?
>
> Fred and Gabi
>
> *From:* Joel M. Halpern <jmh@joelhalpern.com>
> *To:* Mary Barnes <mary.ietf.barnes@gmail.com>
> *Cc:* gen-art@ietf.org; Joel Jaeggli <joelja@bogus.com>; Ron Bonica
> <rbonica@juniper.net>; draft-ietf-v6ops-tunnel-loops@tools.ietf.org;
> IPv6 Operations <v6ops@ops.ietf.org>
> *Sent:* Tue, December 28, 2010 1:43:14 PM
> *Subject:* [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-v6ops-tunnel-loops-01.txt
> Routing Loop Attack using IPv6 Automatic Tunnels:
> Problem Statement and Proposed Mitigations
> Reviewer: Joel M. Halpern
> Review Date: 28-Dec-2010
> IETF LC End Date: 29-Dec-2010
> IESG Telechat date: 06-Jan-2011)
>
> Summary: Nearly ready for publication as an Informational RFC
>
> Major issues: It is unclear in the document what assumptions section 3.1
> makes about the relationship between supported tunnels and checked
> embedded addresses. Is there an assumption that the router only has to
> check for addresses in the format and prefix it supports? I hope so.
> Otherwise, a router seems to be expected to look at an arbitrary IPv6
> addresses, guess whether it has an embedded IPv4 addresses, and perform
> filter checks on that guessed addresses against its own addresses.
> If indeed their is a relationship, then it would really help if section
> 3.1 said that.
> Unfortunately, I am afraid no such relationship is assumed. If not, I
> would like to see significantly better explanation of how the router is
> to reliably know that there is a 6rd or ISATAP address embedded in the
> v6 address.
>
> Minor issues:
>
> Nits/editorial comments:
--0-480863324-1294438796=:74637-- From dragoniz3r@gmail.com Fri Jan 7 14:40:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605323A6992; Fri, 7 Jan 2011 14:40:08 -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 OQafWKG7rksD; Fri, 7 Jan 2011 14:40:07 -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 EDB883A6985; Fri, 7 Jan 2011 14:40:06 -0800 (PST) Received: by wwa36 with SMTP id 36so17954611wwa.13 for ; Fri, 07 Jan 2011 14:42:13 -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=annqkEjHZL9vrW4C1KLkTeU5HAqD6gP5QFk9yz9eTQ0=; b=nT8vBhAIL6ggSm+Dl939yq2MB+iar2j1v24x/wlf6HnUevbXGK+91gNN5Dxj66DQNg f0qx9WlvJqfSNDtgtNEPu76p+HZJbVwoSbWyg+ANyMsJzG6dwvAIAg8mfeTWe3SxNEgx NnvcoKK1qChumUD/E/qQrjMOqyg3fv615720k= 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=ctxnnFLzFJA7IVpSyNts31OMIBOuOZI83q27BRSeJSUusBsByv/bi5nRM17aqRfTYZ lD07WpWIYnZXDLtla6OQ0UUYpFOYF0pQRyjyD2hEFJ1IO48kb88l6UqJwjxU0K/jTxAd AldFICdaJSPBdZgy5TVsuCIY3Idv+yqnrHw5I= MIME-Version: 1.0 Received: by 10.227.129.9 with SMTP id m9mr16403675wbs.1.1294440133215; Fri, 07 Jan 2011 14:42:13 -0800 (PST) Received: by 10.216.244.131 with HTTP; Fri, 7 Jan 2011 14:42:13 -0800 (PST) In-Reply-To: <4D278B93.8050903@isi.edu> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> Date: Fri, 7 Jan 2011 17:42:13 -0500 Message-ID: From: Josh Rambo To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 08 Jan 2011 08:17:43 -0800 Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:40:08 -0000 On Fri, Jan 7, 2011 at 4:54 PM, Joe Touch wrote: > > > On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >> >> Ok. So just to verify, if a box that is sold today that does NAT44 >> out-of-the-box (I have one here on my desk, does DHCP client on the >> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >> when first powered up) wants to comply with this it would need to also >> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >> when initially powered up? > > IMO, yes. That seems at odds with the goal of end-to-end transparency on the Internet= . If it boots up with NAT66 out of the box, then it requires user interventio= n to=A0remove that NAT66. You'd end up with NAT66 on every residential gatewa= y in the world. From jmh@joelhalpern.com Fri Jan 7 14:42:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AA528C129; Fri, 7 Jan 2011 14:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 gfTu+1xB7KNS; Fri, 7 Jan 2011 14:42:29 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id D679E28C13D; Fri, 7 Jan 2011 14:42:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 04CA832280DD; Fri, 7 Jan 2011 14:44:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-169.clppva.btas.verizon.net [71.161.51.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 8EF74324590A; Fri, 7 Jan 2011 14:44:34 -0800 (PST) Message-ID: <4D279750.5090300@joelhalpern.com> Date: Fri, 07 Jan 2011 17:44:32 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Templin References: <4D1A59F2.4010606@joelhalpern.com> <723770.66310.qm@web56706.mail.re3.yahoo.com> <4D277C6D.5040708@joelhalpern.com> <615031.74637.qm@web56701.mail.re3.yahoo.com> In-Reply-To: <615031.74637.qm@web56701.mail.re3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Jan 2011 08:17:43 -0800 Cc: IPv6 Operations , draft-ietf-v6ops-tunnel-loops@tools.ietf.org, gen-art@ietf.org, Mary Barnes Subject: Re: [v6ops] [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:42:30 -0000 I am sorry, but what you have just said translates to me as 1) This proposal can not handle 6rd 2) It is a heuristic, with decent odds, for this to avoid false positives on other schemes, such as ISATAP, since most of these techniques are not designed to allow an arbitrary device elsewhere in the net to detect and accurately extract the IPv4 address from the embedding. Russ may decide it is acceptable, but from where I sit this does not represent solving the problem. Advising folks to configure every 6rd prefix in use anywhere is simply not acceptable. Yours, Joel On 1/7/2011 5:19 PM, Fred Templin wrote: > Hi Joel, > > In response to your questions below, 6rd can only be handled by explicit > configuration of known 6rd prefixes. As you indeed mention, there is no > meaningful rule that captures all 6rd prefixes. Regarding ISATAP, indeed > there is a chance of 2^-32 that a non-ISATAP address will be recognized > as an ISATAP-address. In this case, an erroneous drop will occur only if > the lower 32 bits of the IID will be equal to the IP address of the > current host. > The chance of that happening is 2^-32, if the IID is random. This means that > an erroneous drop will occur with a chance of 2^-64, which is very slim > (albeit possible). > > Fred and Gabi > > *From:* Joel M. Halpern > *To:* Fred Templin > *Cc:* Mary Barnes ; gen-art@ietf.org; Joel > Jaeggli ; Ron Bonica ; > draft-ietf-v6ops-tunnel-loops@tools.ietf.org; IPv6 Operations > > *Sent:* Fri, January 7, 2011 12:49:49 PM > *Subject:* Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt > > I do not see how 6rd can be handled. There is not really any meaningful > "domain" to use to figure out who is using what 6rd prefix. > > And what token does ISATAP use? I presume that I missed something when > the only token I could find was in the lower 64 bits (and tehrefore > could be accidentally duplicated elsewhere. > > Thanks, > Joel > > On 1/7/2011 3:43 PM, Fred Templin wrote: > > Hi Joel, > > > > Thank you for your time in reviewing this work. In Section 3.1, under > > this proposed > > mitigation the tunnel router ideally indeed must check for all > > encapsulation formats in > > which an IPv4 address may be embedded within an IPv6 address. This means > > that > > the router must check for all known protocol-41 encapsulation formats > > and must be > > modified to check for any new formats should new ones be specified. In > > practice, if > > a router is configured to check only a subset of encapsulation formats, > > then it will be > > immune only to attacks in which the attacker uses the configured > > encapsulation > > formats in the source/destination address of the attack packet. > > > > Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a > well-known > > "token" indicating that an IPv4 address is embedded. Other formats > > (e.g., 6rd) > > do not include such a token and hence would require special > configuration at > > the router to indicate which IPv6 prefixes within the routing domain are > > 6rd ones. > > > > Do you feel there are any additional clarifications on this needed > > beyond what > > already appears in Section 3.1? > > > > Fred and Gabi > > > > *From:* Joel M. Halpern > > > *To:* Mary Barnes > > > *Cc:* gen-art@ietf.org ; Joel Jaeggli > >; Ron Bonica > > >; > draft-ietf-v6ops-tunnel-loops@tools.ietf.org > ; > > IPv6 Operations > > > *Sent:* Tue, December 28, 2010 1:43:14 PM > > *Subject:* [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at >> . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-v6ops-tunnel-loops-01.txt > > Routing Loop Attack using IPv6 Automatic Tunnels: > > Problem Statement and Proposed Mitigations > > Reviewer: Joel M. Halpern > > Review Date: 28-Dec-2010 > > IETF LC End Date: 29-Dec-2010 > > IESG Telechat date: 06-Jan-2011) > > > > Summary: Nearly ready for publication as an Informational RFC > > > > Major issues: It is unclear in the document what assumptions section 3.1 > > makes about the relationship between supported tunnels and checked > > embedded addresses. Is there an assumption that the router only has to > > check for addresses in the format and prefix it supports? I hope so. > > Otherwise, a router seems to be expected to look at an arbitrary IPv6 > > addresses, guess whether it has an embedded IPv4 addresses, and perform > > filter checks on that guessed addresses against its own addresses. > > If indeed their is a relationship, then it would really help if section > > 3.1 said that. > > Unfortunately, I am afraid no such relationship is assumed. If not, I > > would like to see significantly better explanation of how the router is > > to reliably know that there is a 6rd or ISATAP address embedded in the > > v6 address. > > > > Minor issues: > > > > Nits/editorial comments: From dragoniz3r@gmail.com Fri Jan 7 14:46:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969193A6935; Fri, 7 Jan 2011 14:46:53 -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 urE8pL6RJUTw; Fri, 7 Jan 2011 14:46:52 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 625B028B797; Fri, 7 Jan 2011 14:46:52 -0800 (PST) Received: by wwi17 with SMTP id 17so946874wwi.1 for ; Fri, 07 Jan 2011 14:48:58 -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; bh=ymLODk/MkYHOKqIna2e9zuUhJQb8P/EzFKUud2W6k0Y=; b=jvzpTAchuWYb90Kkq2V4pXRlamcgaDf7bdKrhHLD2Nd5+apx3HsbNmWepxkpUkd8M7 ioMFPRDZ4msEPT3WYq2poiLU4i6Afd72d9Gm+QOug9bBl2L6wgHBaJ1EzQZZTyoUu9tc FiVsKSNSwojP4tH/WQUDxsUFbJbCPXJ7l8cSk= 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=Yb5/dOFvrHb1FvCGSqCOcIJCOvoQQ+x5Wv2d+Vf7fWFbsNpP54DcCoLCP9m0EF0mEG JiYEN26sP/uo2gW5T8dcVeEBjnfXPMjvxEN0ad69AY7KGFzX/hTo/ULLlk4hXmTA1Kqk 4zo/9KIgKWcrEO6jMGoZOGCtuqvBv9ie6MLvM= MIME-Version: 1.0 Received: by 10.227.146.130 with SMTP id h2mr106140wbv.117.1294440475462; Fri, 07 Jan 2011 14:47:55 -0800 (PST) Received: by 10.216.244.131 with HTTP; Fri, 7 Jan 2011 14:47:55 -0800 (PST) In-Reply-To: <4D279773.30102@isi.edu> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D279773.30102@isi.edu> Date: Fri, 7 Jan 2011 17:47:55 -0500 Message-ID: From: Josh Rambo To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 08 Jan 2011 08:17:43 -0800 Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:46:53 -0000 On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch wrote: > > > On 1/7/2011 2:42 PM, Josh Rambo wrote: >> That seems at odds with the goal of end-to-end transparency on the >> Internet. >> If it boots up with NAT66 out of the box, then it requires user >> intervention >> to remove that NAT66. You'd end up with NAT66 on every residential gateway >> in the world. > > Again, you're arguing against NAT. That's not what I'm suggesting. > > If you really can make the case that a capability needs to be enabled for > IPv4, but should never be enabled for V6, then *maybe* - but, again, that > *will* be used as an excuse not to adopt the device in a V6 environment, > IMO. > > If the box is a NAT, it's a NAT. If that's not what you want to sell, then > don't include a NAT. I'm arguing that there are some features of v4 that are not appropriate to enable by default in v6. NAT is one of those features. A home, residential gateway is a gateway. That is it's true purpose. It's not a NAT box, it just has to perform that function to operate in the limited v4 address space. So, the true function of a gateway should be to be a gateway, which doesn't involve a NAT66. Just because v4 needs it by default doesn't mean v6 does or should. From rajiva@cisco.com Fri Jan 7 14:51:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3895F28C12E; Fri, 7 Jan 2011 14:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.193 X-Spam-Level: X-Spam-Status: No, score=-10.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 BBL1TAdgPyoD; Fri, 7 Jan 2011 14:51:49 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B887428C127; Fri, 7 Jan 2011 14:51:48 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABsoJ02tJXG9/2dsb2JhbACkMHOjMpd/hUwEhGeJRogL Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 07 Jan 2011 22:53:55 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p07MrsbK016083; Fri, 7 Jan 2011 22:53:54 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 16:53:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 16:53:52 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required Thread-Index: AcuuvUgvIz7V8uGRRWuj+VcqmEIoCwAAEMpg References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> From: "Rajiv Asati (rajiva)" To: "Josh Rambo" , "Joe Touch" X-OriginalArrivalTime: 07 Jan 2011 22:53:54.0663 (UTC) FILETIME=[C2929770:01CBAEBD] X-Mailman-Approved-At: Sat, 08 Jan 2011 08:17:53 -0800 Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:51:50 -0000 It is imperative that the draft specify what basic IPv6 functionalities must be supported on every node. =20 I agree that there isn't any need for 1:1 mapping of IPv4 and IPv6 functionalities to be supported and/or enabled on the node. Cheers, Rajiv > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Josh Rambo > Sent: Friday, January 07, 2011 5:48 PM > To: Joe Touch > Cc: IPv6 Operations; int-area@ietf.org > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- > george-ipv6-required >=20 > On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch wrote: > > > > > > On 1/7/2011 2:42 PM, Josh Rambo wrote: > >> That seems at odds with the goal of end-to-end transparency on the > >> Internet. > >> If it boots up with NAT66 out of the box, then it requires user > >> intervention > >> to remove that NAT66. You'd end up with NAT66 on every residential > gateway > >> in the world. > > > > Again, you're arguing against NAT. That's not what I'm suggesting. > > > > If you really can make the case that a capability needs to be enabled > for > > IPv4, but should never be enabled for V6, then *maybe* - but, again, > that > > *will* be used as an excuse not to adopt the device in a V6 > environment, > > IMO. > > > > If the box is a NAT, it's a NAT. If that's not what you want to sell, > then > > don't include a NAT. >=20 > I'm arguing that there are some features of v4 that are not appropriate > to > enable by default in v6. NAT is one of those features. A home, > residential > gateway is a gateway. That is it's true purpose. It's not a NAT box, it > just > has to perform that function to operate in the limited v4 address > space. > So, the true function of a gateway should be to be a gateway, which > doesn't involve a NAT66. > Just because v4 needs it by default doesn't mean v6 does or should. > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From rajiva@cisco.com Fri Jan 7 15:19:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56603A69BF; Fri, 7 Jan 2011 15:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 iZLAbkOVOvAh; Fri, 7 Jan 2011 15:19:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4604228B56A; Fri, 7 Jan 2011 15:17:21 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALstJ02tJXG//2dsb2JhbACkM3OjTJd+hUwEhGeJRogL Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2011 23:19:27 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p07NJR2t004210; Fri, 7 Jan 2011 23:19:27 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 17:19:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 17:19:25 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> In-Reply-To: <4D279A91.2040300@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required Thread-Index: Acuuvn4iydAPseQ4RmSPGhg/38uBdQAAmU8g References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> From: "Rajiv Asati (rajiva)" To: "Joe Touch" X-OriginalArrivalTime: 07 Jan 2011 23:19:27.0370 (UTC) FILETIME=[54231EA0:01CBAEC1] X-Mailman-Approved-At: Sat, 08 Jan 2011 08:17:53 -0800 Cc: int-area@ietf.org, IPv6 Operations Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:19:31 -0000 Joe, > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > 1123, and 1812 (and their supplementary RFCs).=20 Ditto. I am sure that we could come up with few more. > But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on > a device, then there is incentive to not use IPv6". This broader issue in conjunction with all that exists on an IPv4 gateway may not be needed on an IPv6 gateway, warrants the set of MUST and SHOULD/MAY IPv6 features. That was the intent of my suggestion. =09 Cheers, Rajiv > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, January 07, 2011 5:58 PM > To: Rajiv Asati (rajiva) > Cc: Josh Rambo; IPv6 Operations; int-area@ietf.org > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- > george-ipv6-required >=20 >=20 >=20 > On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: > > It is imperative that the draft specify what basic IPv6 > functionalities > > must be supported on every node. >=20 > I'm not sure what that means, though. Nobody would *require* a router > to > support a GUI for management, but, IMO, if the GUI supplied works only > for IPv4, it's a killer. >=20 > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > 1123, > and 1812 (and their supplementary RFCs). But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on > a > device, then there is incentive to not use IPv6". >=20 > Joe From fernando.gont.netbook.win@gmail.com Sat Jan 8 11:38:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BC23A6814; Sat, 8 Jan 2011 11:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 eleornPtidc1; Sat, 8 Jan 2011 11:38:55 -0800 (PST) Received: from mail-yw0-f66.google.com (mail-yw0-f66.google.com [209.85.213.66]) by core3.amsl.com (Postfix) with ESMTP id 5B55F3A6813; Sat, 8 Jan 2011 11:38:54 -0800 (PST) Received: by ywi6 with SMTP id 6so4047929ywi.1 for ; Sat, 08 Jan 2011 11:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=B1f5GvnzvC6+CBHarPTu8IQjtZ0OKPg8kUG+h2lSW8g=; b=SjhI/FcoHtowblp6vPzLb2GczWKF1FXQSTZO8Dv8HKu0gZ9gzuE4aG7RSnBQTvl7Fd 7LL/my9rBjHpzPBezaRn9A5T1ijPO1Ec+BMRDpcpJOAg/iowx827akjRoi8jka+7ihMQ ljqwyQW8/6nXBg3fTbHcEcQnAcAVoy1OHH9Xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ZcWQs74I0VgJGg7D8t5OE6yApVqYWCDAuKNPPYVB0Mlkbb4bwcpPuopfEIjncyIFB+ ICtV4GgSx0tFEYB1cxr/sqC+6mxTbe4GirtGhdmknyaXdn2SyUxnpLY1Su9FhtMYeiZq Ri3XbRwDE6Ew6j494BYMI4RK8HxYUBPkAowus= Received: by 10.91.83.18 with SMTP id k18mr4622283agl.79.1294515662551; Sat, 08 Jan 2011 11:41:02 -0800 (PST) Received: from [192.168.0.127] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id z12sm3825655anp.19.2011.01.08.11.40.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 11:41:01 -0800 (PST) Sender: Fernando Gont Message-ID: <4D27D7A6.8040506@gont.com.ar> Date: Sat, 08 Jan 2011 00:19:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> In-Reply-To: <4D279717.1050602@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:38:55 -0000 On 07/01/2011 07:43 p.m., Joe Touch wrote: >> IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, >> and many related discussions. > > PS - these docs also ignore a valid reason for a NAT - which is to be a > "single IP address front end to a set of back-end IP-capable devices". > Such devices are important when a cluster of devices is intended to act > as a single device on the Internet, and a NAT can be an effective way to > implement that front-end. ... and don't forget about "renumbering". Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From joelja@bogus.com Sat Jan 8 12:35:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9603A682A; Sat, 8 Jan 2011 12:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 XznzUHkrvKBw; Sat, 8 Jan 2011 12:35:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 0CCB03A6820; Sat, 8 Jan 2011 12:35:29 -0800 (PST) Received: from joelja-mac.local ([216.9.106.63]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p08KbRNk088580 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Jan 2011 20:37:30 GMT (envelope-from joelja@bogus.com) Message-ID: <4D28CB08.2070805@bogus.com> Date: Sat, 08 Jan 2011 12:37:28 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <4D27D7A6.8040506@gont.com.ar> In-Reply-To: <4D27D7A6.8040506@gont.com.ar> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org, Joe Touch Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:35:32 -0000 On 1/7/11 7:19 PM, Fernando Gont wrote: > On 07/01/2011 07:43 p.m., Joe Touch wrote: > >>> IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, >>> and many related discussions. >> >> PS - these docs also ignore a valid reason for a NAT - which is to be a >> "single IP address front end to a set of back-end IP-capable devices". >> Such devices are important when a cluster of devices is intended to act >> as a single device on the Internet, and a NAT can be an effective way to >> implement that front-end. Oddly enough load-balancers that support ipv6 support nat66 and nat64... 1 to 1 and 1 to n dnat are basic and essential functions of service abstraction. joel > ... and don't forget about "renumbering". > > Thanks, From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jan 8 16:07:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBC628C14F; Sat, 8 Jan 2011 16:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 8suTef+x9sZV; Sat, 8 Jan 2011 16:07:54 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id B243E28C120; Sat, 8 Jan 2011 16:07:53 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pbir7-0001EJ-BD; Sun, 09 Jan 2011 10:39:57 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 872F03B31E; Sun, 9 Jan 2011 10:39:56 +1030 (CST) Date: Sun, 9 Jan 2011 10:39:56 +1030 From: Mark Smith To: Joe Touch Message-ID: <20110109103956.383b2284@opy.nosense.org> In-Reply-To: <4D279717.1050602@isi.edu> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 00:07:55 -0000 On Fri, 07 Jan 2011 14:43:35 -0800 Joe Touch wrote: > > > On 1/7/2011 2:39 PM, Brian E Carpenter wrote: > > On 2011-01-08 10:54, Joe Touch wrote: > >> > >> > >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: > >>> Ok. So just to verify, if a box that is sold today that does NAT44 > >>> out-of-the-box (I have one here on my desk, does DHCP client on the > >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports > >>> when first powered up) wants to comply with this it would need to also > >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) > >>> when initially powered up? > >> > >> IMO, yes. > > > > IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, > > and many related discussions. > > PS - these docs also ignore a valid reason for a NAT - which is to be a > "single IP address front end to a set of back-end IP-capable devices". > Such devices are important when a cluster of devices is intended to act > as a single device on the Internet, and a NAT can be an effective way to > implement that front-end. > It sounds like you're adopting the "Law of the instrument" regarding NAT - "It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." NAT may have been the only tool in IPv4 for these problems, because there wasn't enough address space to solve them any other way. That constraint doesn't exist in IPv6, so other solutions which don't have the limitations NAT creates may now be possible. If you just blindly assume NAT is the only way to solve these problems, how will you discover better ones? > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From newbery@gmail.com Sun Jan 9 17:30:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8AE3A6870 for ; Sun, 9 Jan 2011 17:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 gFs2ubSASHQt for ; Sun, 9 Jan 2011 17:30:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id EE00A3A6868 for ; Sun, 9 Jan 2011 17:30:23 -0800 (PST) Received: by iyi42 with SMTP id 42so18933772iyi.31 for ; Sun, 09 Jan 2011 17:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:mime-version :content-type:subject:date:in-reply-to:to:references:message-id :x-mailer; bh=PJD9gHWFXxu6x2zxdHIznsB5vflQfwvhoIBo8EaJTaE=; b=Ty9CBlvevZAFriYEoHqi0AmRA67y8uB1WgDkLbU8FaK50Xd1VLeNg9Pbi8TZPDNqVn 1rRql1y0zTcoScEI4YhmcLcZbOli/0M/fXF+36As/2TrXG+Jq9M2FA5XnUq+wVCkJdkX GsFd1xcu4BszaEoa1G58cW+vE8omDnZ5L816g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=QnNiah9FZ2A/+ZuZ7iThWDqQy2mXpaOEp+7ypVXeZiflrqPDZ1L5kDveqvFqcUmGcd Xvupn6zzVjZNKt6VGKVEJNeIjPVEfMaYlnSQaBnuP9P+hEqag3dmkK+9ZIYvNHnMGS5o 6wgCRiYDnZFirTzrpQywxm5xmEQrSS5tzcpMI= Received: by 10.42.175.69 with SMTP id az5mr3628213icb.381.1294623155966; Sun, 09 Jan 2011 17:32:35 -0800 (PST) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id k38sm3161767ick.21.2011.01.09.17.32.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 17:32:34 -0800 (PST) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-1-635854545; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 10 Jan 2011 14:32:30 +1300 In-Reply-To: <4D24CD6C.1090209@gmail.com> To: IPv6 Ops WG References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> Message-Id: <2C80AE52-7E95-437A-B83C-892FAA8E0114@gmail.com> X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:30:25 -0000 --Apple-Mail-1-635854545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6/01/2011, at 8:58 AM, Brian E Carpenter wrote: > Hmm. This is the document of which I wrote a few months ago > on another list: >=20 >> Except that this is truly obnoxious and paranoid: >>=20 >>>> Organizations that are not yet deploying IPv6 should implement the = following recommendations: >>>>=20 >>>> * Block all IPv6 traffic, native and tunneled, at the = organization's firewall. Both incoming and outgoing traffic should be = blocked.=20 >=20 Leading to further fulfillment of Robb's Dictum: "It's the firewall" [An = observation on the most likely source of network breakage and poor = performance] --Apple-Mail-1-635854545 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwkApTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA4MDQwOTAyMDJaFw0x MTAxMzEwOTAyMDJaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQAnLrV/tlijoNa/suGtpIadLDK04lh+Q/UC83u+9MSPnGnuuFHy9q2f 7NMBphu0Zr/WaYf5Wxuol4InPJVUNhcEUNWrIs1xCGd+t6cXxv00/9EpdwGaCw1LMSjAS0V3Ghuj eGTLYccUX/KoWz7COOs/ZpeuhikCNGaj+QlWx3f5x+OLUZEF9j61FrgwEHzr/r44uHnD41bY4LAT yRaAv3AzcHq2DRfxk5SMLcU5Ets8JFrunuYIsmrujbZ6/QdJrdPu1OrhpjEc7C+tr1jLJWbKWezz 2YF7tX7z2KYxMhM7M3d5XwoCnMiURVrQfvZkLvlJZ2LXrNTrrdgvp/CLXMFbgGJ0QVynsZekNNMB /16xEAbnA3ULKsM0gyo9JSdIW3+GvqWa3kMbwoCk25YAM3J8ijAxz1FUqmOw63Vrcv6OUihpu895 iGsZjYotaxj6IWxPfQbHxeUOsiSKrHgOkGCA6HBiZJKyiw/B9kLKtfFm72JoQfwqQTNB8PQbGIS2 NQRWj883xVMvt5SlKoUaxdeuDnSZekQWnaev5NEJB4WYBm70QLDgOWZGTEHAS6a9e04pvhCEczfS ueIffnNsFzZCUCrep5ynjxoJbe6+blZxQVqiyeU7jlAlX3GVLLExoCCwGDE/Vz5eadkhzKNDh2IE wUk8McTtEQ60CVrauuDjjTGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJAKUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMTEwMDEzMjMx WjAjBgkqhkiG9w0BCQQxFgQUzho+RpJ/P5Z1lZF+zUdXd9f4MXYwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCQClMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCQClMA0GCSqG SIb3DQEBAQUABIIBAEqOzyhkVGByRGzwB5YswLKP+EYIs+spaI8YuDJr35fduNanPOyoqngbin5M Ga7h7GOYk3x3hJKq8UmNwIWwfRWIc8h+T/Xb+HBLAm9qAo84k/xOixQlMMk9p/GNgemc0k5/mzab UtDCiWLJ1c4l+VRaHOUIbBEg+WeIIlzotnGh9g0K2zo4XsKRPOXcD73Ayu8g0vcZVYbDCif+49MN BQCo0F/UAHQ7faaQMHtBDUyVZHUp1zvPSCajksc5lnv8iN59fQlYqjFrdhYnSnCVdUBTT+6jnltE 7lw5Ji/AUxA5PoVIXS8wgGD5i/cOpe4KFQolnIjoA4h8JQUiEhkVMnIAAAAAAAA= --Apple-Mail-1-635854545-- From remi.despres@free.fr Mon Jan 10 00:28:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2EC28C0F5; Mon, 10 Jan 2011 00:28:02 -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 SpwQH+DcG5fZ; Mon, 10 Jan 2011 00:28:01 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by core3.amsl.com (Postfix) with ESMTP id 5915A28C0DF; Mon, 10 Jan 2011 00:28:01 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 6244070015A1; Mon, 10 Jan 2011 09:30:13 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id EC3C070016CB; Mon, 10 Jan 2011 09:30:12 +0100 (CET) X-SFR-UUID: 20110110083012967.EC3C070016CB@msfrf2301.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: <4D27D9EB.4010209@gont.com.ar> Date: Mon, 10 Jan 2011 09:30:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> To: Fernando Gont , Josh Rambo X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Internet Area Subject: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 08:28:02 -0000 Le 8 janv. 2011 =E0 04:28, Fernando Gont a =E9crit : > On 07/01/2011 07:42 p.m., Josh Rambo wrote: >> That seems at odds with the goal of end-to-end transparency on the = Internet. >> If it boots up with NAT66 out of the box, then it requires user = intervention >> to remove that NAT66. You'd end up with NAT66 on every residential = gateway >> in the world. >=20 > End-to-end transparency in the sense that every node will be reachable > from every node? The e2e transparency that IPv4 had lost, and IPv6 restores, is ADDRESS = transparency: source and destination addresses seen by a destination are = the same as those set by the source.=20 - This is needed in particular for Header Authentication of IPsec. - Also, it permits a host to advertise its source address in the DNS and = in referrals. It is preserved between two hosts using ULA's in a common customer site. It should remain possible between hosts in two independent customer = sites. =20 Restricting reachability, where needed, is Firewall's function. Firewalls DON'T NEED to sacrifice in address transparency do do what = they have to do.=20 Regards, RD=20 From fred@cisco.com Mon Jan 10 00:37:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3E828C104 for ; Mon, 10 Jan 2011 00:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.454 X-Spam-Level: X-Spam-Status: No, score=-110.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Lqjnyab-U0mO for ; Mon, 10 Jan 2011 00:37:05 -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 72E9628C103 for ; Mon, 10 Jan 2011 00:37:05 -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: AmkHADtUKk2rR7Hu/2dsb2JhbACCOZN4jg5zo1yXL4VMBIRnhiODIA Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Jan 2011 08:39:18 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0A8dDam023631 for ; Mon, 10 Jan 2011 08:39:18 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 10 Jan 2011 00:39:18 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 10 Jan 2011 00:39:18 -0800 From: Fred Baker Date: Mon, 10 Jan 2011 00:39:04 -0800 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: multipart/alternative; boundary=Apple-Mail-122-661448011 Subject: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 08:37:06 -0000 --Apple-Mail-122-661448011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Question for the assembled throng: What do people want to see happen in = draft-ietf-v6ops-v6-aaaa-whitelisting-implications? We had a reasonable discussion on this at IETF 79, and people seemed = pretty supportive. Does it need updates? What comments do people have? Comments to the list, please.= --Apple-Mail-122-661448011 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Question for the assembled throng: What = do people want to see happen = in draft-ietf-v6ops-v6-aaaa-whitelisting-implications?
We had a = reasonable discussion on this at IETF 79, and people seemed pretty = supportive. Does it need updates? What comments do people = have?

Comments to the list, please.
= = --Apple-Mail-122-661448011-- From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 00:43:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE1828C0F2; Mon, 10 Jan 2011 00:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6, 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 L4wXq20jN72A; Mon, 10 Jan 2011 00:43:40 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id C321928C0DF; Mon, 10 Jan 2011 00:43:39 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcDNg-0000o4-Ru; Mon, 10 Jan 2011 19:15:36 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 1712E3B335; Mon, 10 Jan 2011 19:15:36 +1030 (CST) Date: Mon, 10 Jan 2011 19:15:35 +1030 From: Mark Smith To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Message-ID: <20110110191535.3c32bc4b@opy.nosense.org> In-Reply-To: <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Internet Area , IPv6 Operations Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 08:43:41 -0000 On Mon, 10 Jan 2011 09:30:12 +0100 R=C3=A9mi Despr=C3=A9s wrote: >=20 > Le 8 janv. 2011 =C3=A0 04:28, Fernando Gont a =C3=A9crit : > > On 07/01/2011 07:42 p.m., Josh Rambo wrote: > >> That seems at odds with the goal of end-to-end transparency on the Int= ernet. > >> If it boots up with NAT66 out of the box, then it requires user interv= ention > >> to remove that NAT66. You'd end up with NAT66 on every residential gat= eway > >> in the world. > >=20 > > End-to-end transparency in the sense that every node will be reachable > > from every node? >=20 > The e2e transparency that IPv4 had lost, and IPv6 restores, is ADDRESS tr= ansparency: source and destination addresses seen by a destination are the = same as those set by the source.=20 > - This is needed in particular for Header Authentication of IPsec. > - Also, it permits a host to advertise its source address in the DNS and = in referrals. >=20 > It is preserved between two hosts using ULA's in a common customer site. > It should remain possible between hosts in two independent customer sites. > =20 > Restricting reachability, where needed, is Firewall's function. And can also be a host's decision and function. It actually has to be if there is no assurance of existence or confidence in the operation of a network located upstream firewall - and as more and more multi-homed mobile hosts become popular (a.k.a. smartphones, laptops, tablets, netbooks - everybody has got at least one of those haven't they?) - assurance of or confidence in an upstream firewall is naturally going to become reduced over time. > Firewalls DON'T NEED to sacrifice in address transparency do do what they= have to do.=20 >=20 > Regards, > RD=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Mon Jan 10 02:31:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F173A695B; Mon, 10 Jan 2011 02:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.747 X-Spam-Level: X-Spam-Status: No, score=-9.747 tagged_above=-999 required=5 tests=[AWL=0.852, 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 QQlcXup5eelk; Mon, 10 Jan 2011 02:31:45 -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 E58F53A694F; Mon, 10 Jan 2011 02:31:45 -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: AvsEAO9uKk2rR7H+/2dsb2JhbACkPnOkBZdRhUwEjjCICw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2011 10:33:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0AAXgvf005500; Mon, 10 Jan 2011 10:33:59 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 11:33:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 11:33:56 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E502DF203B@XMB-AMS-101.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: Acuuvn4iydAPseQ4RmSPGhg/38uBdQAAmU8gAHwiuuA= References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com><4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at><4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at><4D278B93.8050903@isi.edu><4D279773.30102@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com><4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Rajiv Asati (rajiva)" , "Joe Touch" X-OriginalArrivalTime: 10 Jan 2011 10:33:57.0661 (UTC) FILETIME=[E322F4D0:01CBB0B1] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:31:47 -0000 <>start snip<> > the point that "if IPv4 is supported better, in any way, than IPv6, on > a device, then there is incentive to not use IPv6". This broader issue in conjunction with all that exists on an IPv4 gateway may not be needed on an IPv6 gateway, warrants the set of MUST and SHOULD/MAY IPv6 features. That was the intent of my suggestion. <>end snip<> I am interested to understand 'how' you want to quantify the IPv6 vs IPv4 service experience. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Rajiv Asati (rajiva) Sent: zaterdag 8 januari 2011 0:19 To: Joe Touch Cc: int-area@ietf.org; IPv6 Operations Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Joe, > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > 1123, and 1812 (and their supplementary RFCs).=20 Ditto. I am sure that we could come up with few more. > But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on > a device, then there is incentive to not use IPv6". This broader issue in conjunction with all that exists on an IPv4 gateway may not be needed on an IPv6 gateway, warrants the set of MUST and SHOULD/MAY IPv6 features. That was the intent of my suggestion. =09 Cheers, Rajiv From carlosm3011@gmail.com Mon Jan 10 04:02:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD5D28C134; Mon, 10 Jan 2011 04:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_13=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 nnY7CStWtxGe; Mon, 10 Jan 2011 04:02:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 405B228C10E; Mon, 10 Jan 2011 04:02:03 -0800 (PST) Received: by iyi42 with SMTP id 42so19294225iyi.31 for ; Mon, 10 Jan 2011 04:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=5fgRjPtF1LXKwPSYED8XqAsh9ppGWlSGix5InNe3RcY=; b=hPjU3Eu6bBt8bSzMT8+VmExd4QsGSU+9qeiQVSNnNjOnMPBehJvYow4/IL24B6KU5E /MlU7jz60voQJMRSCGJi9t65SGWQzwo5qrWEaTP2ravxH6I0nU/UaUIb5ko7kvcGTwTb xjSQyprbX4uRrVvU+LvZfAO19ZUHrUR8uzHrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=IQS+F0BXEc6gdvs6atIhp7XqFX4dnZTf8xozNiU1FqFeha8VEntSaTQaqS+YArVJ// 0SaRdNAkrRgxgeqDD/Y19ZcvuFtDmD3+7r2LtZvH1dAw2LuvfLrL++rNN5ajFCSQGw5V wIFeAgyjiIWsUAAlF4uCbnN+VmrCQF63ETSJo= MIME-Version: 1.0 Received: by 10.42.174.198 with SMTP id w6mr4176183icz.135.1294661056328; Mon, 10 Jan 2011 04:04:16 -0800 (PST) Received: by 10.42.170.201 with HTTP; Mon, 10 Jan 2011 04:04:16 -0800 (PST) In-Reply-To: <20110110191535.3c32bc4b@opy.nosense.org> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <20110110191535.3c32bc4b@opy.nosense.org> Date: Mon, 10 Jan 2011 10:04:16 -0200 Message-ID: From: Carlos Martinez-Cagnazzo To: Mark Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 12:02:04 -0000 We already have that today with IPv4, not at protocol level, but any operating system can operate a packet filter. Having host-based firewalls also does not mean that we have to sacrifice address transparency. On Mon, Jan 10, 2011 at 6:45 AM, Mark Smith wrote: > On Mon, 10 Jan 2011 09:30:12 +0100 > R=E9mi Despr=E9s wrote: > >> >> Le 8 janv. 2011 =E0 04:28, Fernando Gont a =E9crit : >> > On 07/01/2011 07:42 p.m., Josh Rambo wrote: >> >> That seems at odds with the goal of end-to-end transparency on the In= ternet. >> >> If it boots up with NAT66 out of the box, then it requires user inter= vention >> >> to remove that NAT66. You'd end up with NAT66 on every residential ga= teway >> >> in the world. >> > >> > End-to-end transparency in the sense that every node will be reachable >> > from every node? >> >> The e2e transparency that IPv4 had lost, and IPv6 restores, is ADDRESS t= ransparency: source and destination addresses seen by a destination are the= same as those set by the source. >> - This is needed in particular for Header Authentication of IPsec. >> - Also, it permits a host to advertise its source address in the DNS and= in referrals. >> >> It is preserved between two hosts using ULA's in a common customer site. >> It should remain possible between hosts in two independent customer site= s. >> >> Restricting reachability, where needed, is Firewall's function. > > And can also be a host's decision and function. It actually has to be if > there is no assurance of existence or confidence in the operation of a > network located upstream firewall - and as more and more multi-homed > mobile hosts become popular (a.k.a. smartphones, laptops, tablets, > netbooks - everybody has got at least one of those haven't they?) - > assurance of or confidence in an upstream firewall is naturally going > to become reduced over time. > > >> Firewalls DON'T NEED to sacrifice in address transparency do do what the= y have to do. >> >> Regards, >> RD >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From remi.despres@free.fr Mon Jan 10 05:15:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D065E28C15E; Mon, 10 Jan 2011 05:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=0.517, 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 uSJ9ta-lGpuu; Mon, 10 Jan 2011 05:15:18 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 0A6CE3A698A; Mon, 10 Jan 2011 05:15:18 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id 226D5700008C; Mon, 10 Jan 2011 14:17:31 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id AB5CA7000086; Mon, 10 Jan 2011 14:17:30 +0100 (CET) X-SFR-UUID: 20110110131730702.AB5CA7000086@msfrf2404.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: Date: Mon, 10 Jan 2011 14:17:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <20110110191535.3c32bc4b@opy.nosense.org> To: carlos@lacnic.net X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 13:15:18 -0000 Le 10 janv. 2011 =E0 13:04, Carlos Martinez-Cagnazzo a =E9crit : > We already have that today with IPv4, not at protocol level, but any > operating system can operate a packet filter. Having host-based > firewalls also does not mean that we have to sacrifice address > transparency. Right. > On Mon, Jan 10, 2011 at 6:45 AM, Mark Smith > wrote: >> On Mon, 10 Jan 2011 09:30:12 +0100 >> R=E9mi Despr=E9s wrote: >>> ... >>> Restricting reachability, where needed, is Firewall's function. >>=20 >> And can also be a host's decision and function. It actually has to be = if >> there is no assurance of existence or confidence in the operation of = a >> network located upstream firewall=20 Agreed: hosts already restrict reachability by themselves, and this is a = must-have function. (Note that, this being done by their integrated firewall, it still is a = "firewall" function ;-).)=20 Regards, RD From Ted.Lemon@nominum.com Mon Jan 10 06:22:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F21C3A6AFE for ; Mon, 10 Jan 2011 06:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 8sgN8xkRjCpT for ; Mon, 10 Jan 2011 06:22:38 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 319B33A6AFD for ; Mon, 10 Jan 2011 06:22:38 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTSsWs3yNkUqOWqVZlaLbqqZNo7+X1cbg@postini.com; Mon, 10 Jan 2011 06:24:52 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4FB881B8295 for ; Mon, 10 Jan 2011 06:24:51 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1F564190054; Mon, 10 Jan 2011 06:24:51 -0800 (PST) Received: from [192.168.0.65] (96.39.66.70) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 Jan 2011 06:24:50 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D22949C.3040001@sri.com> Date: Mon, 10 Jan 2011 09:24:47 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6EBF7C86-8E2D-4CC3-ABCB-D3A741872F2B@nominum.com> References: <4D21FE53.5090702@sri.com> <4D22949C.3040001@sri.com> To: Ed Jankiewicz X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 14:22:39 -0000 On Jan 3, 2011, at 10:31 PM, Randy Bush wrote: > We can only hope that 340 trillion trillion trillion is enough for a=20= > while... It's frustrating that people describe the situation this way. The = problem with IPv4 and IPv6 is not that there aren't enough addresses to = address all the devices that need to be addressed (although in the case = of IPv4, that is a true statement). It's that a one-to-one mapping of = devices to addresses is not, and never can be, possible, and so the = address needs to be large enough to account for the necessarily less = efficient mapping that is required in the real world. The "number of atoms in the universe" comparison is hopelessly = misleading, and should not be repeated by people who understand the = problem. It leads to things like people advocating the use of = broadcast networks with host address numbering narrower than 64 bits. From Wesley.E.George@sprint.com Mon Jan 10 07:47:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95093A67ED; Mon, 10 Jan 2011 07:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.804 X-Spam-Level: X-Spam-Status: No, score=-3.804 tagged_above=-999 required=5 tests=[AWL=-0.205, 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 mtsQZ8a5mmld; Mon, 10 Jan 2011 07:47:30 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by core3.amsl.com (Postfix) with ESMTP id 39DF83A682A; Mon, 10 Jan 2011 07:47:30 -0800 (PST) Received: from mail47-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.8; Mon, 10 Jan 2011 15:49:43 +0000 Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3-R.bigfish.com (Postfix) with ESMTP id 4D72B17A0105; Mon, 10 Jan 2011 15:49:43 +0000 (UTC) X-SpamScore: -60 X-BigFish: VS-60(zz542N1418M1432N1455M1447R9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3 (MessageSwitch) id 1294674582965328_5400; Mon, 10 Jan 2011 15:49:42 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.247]) by mail47-db3.bigfish.com (Postfix) with ESMTP id E6CB14E8001; Mon, 10 Jan 2011 15:49:42 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 10 Jan 2011 15:49:41 +0000 Received: from PLSWEH02.ad.sprint.com (PLSWEH02.corp.sprint.com [144.226.242.131]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0AFgjOf028090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jan 2011 09:42:48 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH02.ad.sprint.com ([2002:90e2:f283::90e2:f283]) with mapi id 14.01.0255.000; Mon, 10 Jan 2011 09:49:34 -0600 From: "George, Wes E [NTK]" To: "Rajiv Asati (rajiva)" , Joe Touch Thread-Topic: [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: AQHLrr3OZ1PupmJS+kufkXHyVXljfpPGg+GAgAAF3oCAA8NuYA== Date: Mon, 10 Jan 2011 15:49:33 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.27] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004F_01CBB0B4.10AFF540" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: IPv6 Operations , "int-area@ietf.org" Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:47:32 -0000 ------=_NextPart_000_004F_01CBB0B4.10AFF540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Rajiv Asati (rajiva) > Sent: Friday, January 07, 2011 6:19 PM > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- > george-ipv6-required > > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > > 1123, and 1812 (and their supplementary RFCs). > > Ditto. I am sure that we could come up with few more. > [WES] I think that those lists already exist for IPv6, but not always in exactly the same form as the IPv4 specs you reference above. I assume that the IPv6 specifications aren't listed as updates to the above IPv4 RFCs because IPv6 was considered optional, not a direct replacement for IPv4. I wasn't about to go so far as to deprecate the appropriate IPv4 spec in favor of the IPv6 one... baby steps :-) Either way, this draft is meant to be a generic update informing those who are considering putting an IP stack on their device, whether dumb or smart, simple or complex, that they need to stop considering IPv6 optional. We intentionally kept it generic so that it could be adopted more quickly - the sooner we correct the lack of IPv6 support in devices and software, the better off we are. That said, it may be helpful to write a draft comparing IPv4 and IPv6 for feature parity to identify future work items for IETF and point to the appropriate RFCs where equivalent features exist, but I view that as complimentary to this draft, not part of it. I agree that the more specific information about what we mean by "support IPv6" should be made available, but as references, not text in the draft itself. The draft already references ietf-v6ops-ipv6-cpe-router, and RFC 4294, which I've been informed will soon be replaced by a BIS version (currently draft-ietf-6man-node-req-bis). I will update that reference in the next version of the draft. The draft also formally updates 1812 and 1122. I can add 1123 to that list of updated drafts if there is consensus that it should be added. Brian Carpenter also recommended (offlist) that we might want to consider adding RFC4084 to the update list, specifically, moving "Version" from section 4 (additional terminology) to section 2 (general terminology). What are your thoughts on that? What else is missing as a reference? Keep in mind that the existing referenced drafts and RFCs have multiple normative and informative references of their own which we didn't see the need to duplicate here. Thanks for the support thus far. Wes George ------=_NextPart_000_004F_01CBB0B4.10AFF540 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTAxNTQ5MzNaMCMGCSqGSIb3DQEJBDEWBBTfLywac5aA tFdEuI3PHZBSrlqyUjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAporoOQFLGC/dW 16DgJmB9tRMSA8Bnog4TJnMnRfcuJElj5fSas0oLrq1Y9xtZbZsiGqOQJhnY+1O2U/IyjoKRKgT1 y6lup1rbzIn0L4xH9AzJH8qE9XymyojS2vAOYDEpksWq29fH821rgnwdzetXqa6++iLa2vJzsYaJ XzksAQAAAAAAAA== ------=_NextPart_000_004F_01CBB0B4.10AFF540-- From Wesley.E.George@sprint.com Mon Jan 10 08:10:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420D13A6808 for ; Mon, 10 Jan 2011 08:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXXlu+t0veEt for ; Mon, 10 Jan 2011 08:09:58 -0800 (PST) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id AE82F3A6805 for ; Mon, 10 Jan 2011 08:09:57 -0800 (PST) Received: from mail138-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Mon, 10 Jan 2011 16:12:11 +0000 Received: from mail138-va3 (localhost.localdomain [127.0.0.1]) by mail138-va3-R.bigfish.com (Postfix) with ESMTP id 649ED5403E0; Mon, 10 Jan 2011 16:12:11 +0000 (UTC) X-SpamScore: -23 X-BigFish: VS-23(z4562mz9371Pzz1202hzz8275bh8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail138-va3 (localhost.localdomain [127.0.0.1]) by mail138-va3 (MessageSwitch) id 129467593114950_18952; Mon, 10 Jan 2011 16:12:11 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.240]) by mail138-va3.bigfish.com (Postfix) with ESMTP id F39AEA2805A; Mon, 10 Jan 2011 16:12:10 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 10 Jan 2011 16:12:03 +0000 Received: from PLSWEH05.ad.sprint.com (PLSWEH05.corp.sprint.com [144.226.251.23]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0AGC2TX029871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jan 2011 10:12:02 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.01.0255.000; Mon, 10 Jan 2011 10:12:02 -0600 From: "George, Wes E [NTK]" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications - where to go from here Thread-Index: AQHLsKHmbGlZveapd0a/Y2EG3BAwsJPKYK3g Date: Mon, 10 Jan 2011 16:12:01 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04B8DE@PLSWM12A.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.27] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0054_01CBB0B7.33D12780" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:10:01 -0000 ------=_NextPart_000_0054_01CBB0B7.33D12780 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0055_01CBB0B7.33D12780" ------=_NextPart_001_0055_01CBB0B7.33D12780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Let's see the next version of the draft that incorporates the suggestions and comments from the initial review (which I know Jason is working on currently), then we'll go from there. Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Monday, January 10, 2011 3:39 AM To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications - where to go from here Question for the assembled throng: What do people want to see happen in draft-ietf-v6ops-v6-aaaa-whitelisting-implications? We had a reasonable discussion on this at IETF 79, and people seemed pretty supportive. Does it need updates? What comments do people have? Comments to the list, please. ------=_NextPart_001_0055_01CBB0B7.33D12780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Let’s see the next version of the draft that incorporates the = suggestions and comments from the initial review (which I know Jason is = working on currently), then we’ll go from = there.

=  

= Wes George

=  

=  

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Fred Baker
Sent: Monday, January 10, 2011 3:39 = AM
To: v6ops@ietf.org
Subject: [v6ops] = draft-ietf-v6ops-v6-aaaa-whitelisting-implications - where to go from = here

 

Question = for the assembled throng: What do people want to see happen = in draft-ietf-v6ops-v6-aaaa-whitelisting-implications?

 = ;

We had a = reasonable discussion on this at IETF 79, and people seemed pretty = supportive. Does it need updates? What comments do people = have?

 = ;

Comments = to the list, = please.

------=_NextPart_001_0055_01CBB0B7.33D12780-- ------=_NextPart_000_0054_01CBB0B7.33D12780 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTAxNjEyMDBaMCMGCSqGSIb3DQEJBDEWBBTWYShwuwFf Ifi9kk5opc05+Stk9jBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBqPwhe8W2LeBvF PgdF+UeZ3ytW6wcxheZmTtbrP+7kHPWTvMQcKvQsmXuhdDZmgsavQ4TIZ/VB+iYndiLU1N8+63w2 iS3xnvuPYUP40p1eFajzFmC3zH6Lbo1aqBQD58l0pRw4v+/4aDXxC73CR45vLHCVA/YYeYVe8VYx T3FG4AAAAAAAAA== ------=_NextPart_000_0054_01CBB0B7.33D12780-- From fernando.gont.netbook.win@gmail.com Mon Jan 10 08:49:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6823A6B07; Mon, 10 Jan 2011 08:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Zz5Wvs-u7-Z6; Mon, 10 Jan 2011 08:49:58 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id 2BFC43A67FA; Mon, 10 Jan 2011 08:49:58 -0800 (PST) Received: by yxd5 with SMTP id 5so4314720yxd.1 for ; Mon, 10 Jan 2011 08:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=UqpVGxSF20tFrAa65IWWKUFo1iAJCo3YfxdGdCaT41Q=; b=CK3Kex7pL2+wg89UFh/ifaRQ253r0VjWTSONEMxN2AoTtMSBNgwJhuMztGot9Vl830 lxRqdHztdTk30sBwZOOAaXwBe7orOFwA7zz2pl5ZQvPXejvDYNdsZavnQnFZhSaswQgv xO0cEMabVgQy8XaRmZHPUbz23FXytRQ4g3R+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=BqDHgr0nmEPiMkLDu+KCpeSheBABiEeO6jrvAtYKu+fJb8mZBwZhXiF5COtX7T12kv B48oF9L+tmE3UcCrU/CAUU3GFUSBwz05zKkGen0BJjXJfZeVrgGnNGbBd4lCiMiu6kTH tcuN6LMTUAUOamWEMf2zx13TnYbmnUA1AZiUI= Received: by 10.151.45.21 with SMTP id x21mr27942374ybj.429.1294678331789; Mon, 10 Jan 2011 08:52:11 -0800 (PST) Received: from [192.168.2.4] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id r6sm2258719yba.23.2011.01.10.08.51.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 08:52:10 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B3928.8050508@gont.com.ar> Date: Mon, 10 Jan 2011 13:51:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> In-Reply-To: <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Internet Area , IPv6 Operations Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:49:59 -0000 Hi, Remi, On 10/01/2011 05:30 a.m., Rémi Després wrote: >> End-to-end transparency in the sense that every node will be >> reachable from every node? > > The e2e transparency that IPv4 had lost, and IPv6 restores, is > ADDRESS transparency: source and destination addresses seen by a > destination are the same as those set by the source. IPv6 restores this to the extent that NAT66 is not deployed. My take is that NAT66 *will* be deployed. -- So, I don't think you can rely IPv6 on restoring "address transparency". > - This is needed > in particular for Header Authentication of IPsec. But you can still use UDP encapsulation. > - Also, it permits > a host to advertise its source address in the DNS and in referrals. Firstly, using network addresses in the application layer is generally a bad idea, and one would hope that we have already learnt that lesson. Secondly, for the an address published in the DNS to be useful, it needs to be reachable (that's why you advertise the address in the DNS after all, right?). And for it to be reachable, the stateful firewall tht's in fron of the host (or within the host), needs to have state for that "incoming connection". -- In general, there won't be such state, *or* the firewall would need to be smart enough to understand the application protocol to create such state before it's needed (so, again, forget about the "dumb network"). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Mon Jan 10 09:09:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B543A67FA for ; Mon, 10 Jan 2011 09:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 acR82vM7kMDD for ; Mon, 10 Jan 2011 09:09:39 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id 1F9BC3A67ED for ; Mon, 10 Jan 2011 09:09:39 -0800 (PST) Received: by yxd5 with SMTP id 5so4317710yxd.1 for ; Mon, 10 Jan 2011 09:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=vBsV5eHla5U4Uffx5kHreNKVtbt9o5gQb2VK+eDhIqw=; b=mXYNKmUYcKo/S2K9uQuLGLPVIWdx5K7xSXRrHabzyq6QPlmSVb4RW3JwRpywwe9vC0 svpwGd+lOYUtG8v8Rg79SGRoorGSb1KnkKJMHp67QsKhc6RUfrCRYh8uWZyvj3kB9pJQ RBP9QXKjTZ57gq3QbQ4c6Z+kw53bOVfgi/HwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=j8ZbjQIUUIZZZZ8p5Ack3OxIjT4W2enjHfPMtLJHfY7BoOl1HaoVNzrOFxMuRVp9OX MPhnNlXtrOrfUNjalGpcAXw3odbzh0/IkuCw9Y2uffnEIeSyp2FMb8WzRtccrThutdM+ 1L3EW1IHv/5xlOvnPIZSCJ/3HRL2+eEtSnxHg= Received: by 10.90.118.2 with SMTP id q2mr6390129agc.11.1294679513070; Mon, 10 Jan 2011 09:11:53 -0800 (PST) Received: from [192.168.2.4] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id b27sm37774609ana.8.2011.01.10.09.11.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 09:11:51 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B3DCE.7010102@gont.com.ar> Date: Mon, 10 Jan 2011 14:11:42 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> In-Reply-To: <4D24CD6C.1090209@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:09:40 -0000 On 05/01/2011 04:58 p.m., Brian E Carpenter wrote: > Hmm. This is the document of which I wrote a few months ago on > another list: > >> Except that this is truly obnoxious and paranoid: >> >>>> Organizations that are not yet deploying IPv6 should implement >>>> the following recommendations: >>>> >>>> * Block all IPv6 traffic, native and tunneled, at the >>>> organization's firewall. Both incoming and outgoing traffic >>>> should be blocked. Well, if the firewall is meant to allow only traffic that is deemed as necessary, and the organization has not decided to deploy v6... why should it be allowed? And.. what would be the point of firewalling v4 when you could bypass the firewall with v6? (Note: there's stuff in the NIST document with which I don't agree. But this particular recommendation is, IMO, as paranoid as it *needs* to be) Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jan 10 09:45:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E197C28C101; Mon, 10 Jan 2011 09:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU9YGFsxRurK; Mon, 10 Jan 2011 09:45:29 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E4A9028C0FF; Mon, 10 Jan 2011 09:45:28 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0AHl47n026672 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 09:47:05 -0800 (PST) Message-ID: <4D2B4618.6050703@isi.edu> Date: Mon, 10 Jan 2011 09:47:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> In-Reply-To: <20110109103956.383b2284@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:45:30 -0000 On 1/8/2011 4:09 PM, Mark Smith wrote: ... > It sounds like you're adopting the "Law of the instrument" regarding > NAT - > > "It is tempting, if the only tool you have is a hammer, to treat > everything as if it were a nail." Maslow's law is not the motivation. I'm simply making a few observations: 1) anything a device supports for IPv4 that it cannot support for IPv6 will be taken as an excuse not to migrate to IPv6 2) it's better to remove that hurdle than to debate every capability. 3) NATs are useful even where addresses are plentiful Joe From behcetsarikaya@yahoo.com Mon Jan 10 10:03:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2063A684C for ; Mon, 10 Jan 2011 10:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, 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 ZDPVwQQPyIvE for ; Mon, 10 Jan 2011 10:03:40 -0800 (PST) Received: from nm27-vm0.bullet.mail.ne1.yahoo.com (nm27-vm0.bullet.mail.ne1.yahoo.com [98.138.91.63]) by core3.amsl.com (Postfix) with SMTP id 125B83A69CB for ; Mon, 10 Jan 2011 10:03:39 -0800 (PST) Received: from [98.138.90.54] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jan 2011 18:05:51 -0000 Received: from [98.138.89.164] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jan 2011 18:05:51 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 10 Jan 2011 18:05:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 578939.23591.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 56530 invoked by uid 60001); 10 Jan 2011 18:05:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294682751; bh=BMPb4pV4hPB9TlWDx3KAtYkxVx6xcKzHJdd/PUxi6BI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=e7VYz4yrfJRX8wVXq4Z5yGTHf5EcQfHeXb0YplNEWTWuJ3TrPv6pP6O1XxhdvBVGKWes9xh4NYPC02XsyoGDEjUUlWubKgWd9BIwJ1y2z6AEJrO8yjZH23wsv4hyIiZQyoWDzLDIRBhSxbVUT0wLyl8qiU/LRPcU1ZD7xm/B+Xs= 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:Content-Transfer-Encoding; b=hgsHw/g8RLww/tKSISvtHpYKL+5126Tn2W6VmAQzOyXD26mbiXPQFjxh64bL4G1Vrfw+DMV+PDFg6NdZI2rLyI98lKPkGWCIcy7SrhFbfP6IRf7PeEibtQ+Y7mUBI1zbminr128WhWhqlbxjdPVZhCgg+XM8ALZnm2mnKS3dL8s=; Message-ID: <201912.52088.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: E.iFFEsVM1l6CF01.MS7l4zDLZfyngOkmn375GvVh4XquVt A_84ugOO88WMK4rAa8tnVKnQQbj1OtOsfCrwNr_oOndkpDokUtfkcvhTbyQ3 MXNAPm73QvC0gFdvvq2JNAMVTgfihMSlyHKMP3_Nx3pT3JRBKJiOv9.1oK.n fexEb9QWO8IPNoPZXDatAAPQloVI.mf2NI2Dtigv06hFw2R053XOSOtuDrsy C3VDBl.9Mg_NxAemQjl9DVI63Jv1yUMBNWCH.BcYtfWjiu0eZtq2nH12cHqr vqFvhxGACie4wfh4jvuXWCuPlT7O0fTH4J6D.T915wz2q2nmmJ7z0lxugRyc rxk6gwSCE6oObRpzRL9vvEhtAlEAXEBRBvw1jy9RyoThrAmWjj0h8hNwy1xb X.OFUeFJmHP8T Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Mon, 10 Jan 2011 10:05:51 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> Date: Mon, 10 Jan 2011 10:05:51 -0800 (PST) From: Behcet Sarikaya To: Fernando Gont , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D2B3928.8050508@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:03:41 -0000 =0A=0A> Hi, Remi,=0A> =0A> On 10/01/2011 05:30 a.m., R=E9mi Despr=E9s wrote= :=0A> =0A> >> End-to-end transparency in the sense that every node will be= =0A> >> reachable from every node?=0A> > =0A> > The e2e transparency that = IPv4 had lost, and IPv6 restores, is=0A> > ADDRESS transparency: source an= d destination addresses seen by a=0A> > destination are the same as those = set by the source. =0A> =0A> IPv6 restores this to the extent that NAT66 is= not deployed. My take is=0A> that NAT66 *will* be deployed. -- So, I don'= t think you can rely IPv6 on=0A> restoring "address transparency".=0A=0A+1= .=0A=0AWe can only reply on public IPv4 address depletion. Period.=0A=0A> = =0A> =0A> > - This is needed=0A> > in particular for Header Authentication= of IPsec. =0A> =0A> But you can still use UDP encapsulation.=0A> =0A> =0A= > =0A> > - Also, it permits=0A> > a host to advertise its source address i= n the DNS and in referrals.=0A> =0A> Firstly, using network addresses in t= he application layer is generally a=0A> bad idea, and one would hope that = we have already learnt that lesson.=0A> =0A> Secondly, for the an address = published in the DNS to be useful, it needs=0A> to be reachable (that's wh= y you advertise the address in the DNS after=0A> all, right?). And for it t= o be reachable, the stateful firewall tht's in=0A> fron of the host (or wi= thin the host), needs to have state for that=0A> "incoming connection". --= In general, there won't be such state, *or*=0A> the firewall would need t= o be smart enough to understand the application=0A> protocol to create suc= h state before it's needed (so, again, forget=0A> about the "dumb network"= ).=0A> =0A> Thanks,=0A> -- =0A> Fernando Gont=0A> e-mail: fernando@gont.com= .ar || fgont@acm.org=0A> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96= EE A9EF D076 FFF1=0A> =0A> =0A> =0A> =0A> ________________________________= _______________=0A> Int-area mailing list=0A> Int-area@ietf.org=0A> https:= //www.ietf.org/mailman/listinfo/int-area=0A> =0A=0A=0A From bs7652@att.com Mon Jan 10 10:10:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553243A6B00; Mon, 10 Jan 2011 10:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 GxOBa2c32eBe; Mon, 10 Jan 2011 10:10:28 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 3DB103A6AFF; Mon, 10 Jan 2011 10:10:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1294683161!35169153!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 25100 invoked from network); 10 Jan 2011 18:12:41 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jan 2011 18:12:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0AIBqn9032193; Mon, 10 Jan 2011 13:11:52 -0500 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p0AIBm8D032157; Mon, 10 Jan 2011 13:11:49 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 13:12:32 -0500 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 13:12:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 13:12:29 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F18FBADC4@crexc50p> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: AQHLrr3OZ1PupmJS+kufkXHyVXljfpPGg+GAgAAF3oCAA8NuYIAANIiw References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com><4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at><4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at><4D278B93.8050903@isi.edu><4D279773.30102@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com><4D279A91.2040300@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> From: "STARK, BARBARA H (ATTSI)" To: "George, Wes E [NTK]" , "Rajiv Asati (rajiva)" , "Joe Touch" X-OriginalArrivalTime: 10 Jan 2011 18:12:32.0041 (UTC) FILETIME=[F2FC2990:01CBB0F1] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:10:29 -0000 Thank you for putting this draft together. I like its message, and I like its simplicity. I agree with the philosophy of minimizing references, and not redundantly referencing RFCs that are referenced by the references. I'm not aware of additional references that would be needed. Barbara From edward.jankiewicz@sri.com Mon Jan 10 10:34:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B499F3A6A67; Mon, 10 Jan 2011 10:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_27=0.6] 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 QZYmbcV8kA8X; Mon, 10 Jan 2011 10:34:09 -0800 (PST) Received: from mail1.sri.com (srimail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id C62E13A69CC; Mon, 10 Jan 2011 10:34:09 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LET007NUL0LQJ80@mail.sri.com>; Mon, 10 Jan 2011 10:36:22 -0800 (PST) Message-id: <4D2B51A8.3050405@sri.com> Date: Mon, 10 Jan 2011 13:36:24 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: "George, Wes E [NTK]" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04B941@PLSWM12A.ad.sprint.com> In-reply-to: <54E900DC635DAB4DB7A6D799B3C4CD8E04B941@PLSWM12A.ad.sprint.com> Cc: IPv6 Ops WG , "int-area@ietf.org" Subject: Re: [v6ops] draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:34:10 -0000 upon reflection, I agree that it would be unnecessary and inappropriate to generate a petition within IETF. The process is built on consensus, not name-checking. Suffice it to say I support this work being discussed within Intarea and v6ops, including time on the agenda in Prague, and eventual adoption as a WG or IAB publication. I also agree with a previous comment that this draft should be kept very simple with a small number of essential references, e.g. to the IPv6 Node Requirements (as revised). That is the current best definition of what is "required" for IPv6. If it is insufficient as is, and needs to be replaced by a standards track definition, that would take some effort, and that can be discussed as well. I would prefer that we publish the current RFC 4294 update draft before we open that can of worms. The question of parity is very complex and difficult to define. The concerns that some things are not directly comparable, or that there are things that have become accepted in IPv4 that some don't want to replicate in IPv6, versus the sense that the lack of any feature (standard or not) will be a disincentive to IPv6 adoption - it's not clear how these can be reconciled. On 1/10/2011 11:29 AM, George, Wes E [NTK] wrote: > Shortened the subject line a bit > > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf > Of Ed Jankiewicz > Sent: Friday, January 07, 2011 3:11 PM > To: int-area@ietf.org; IPv6 Operations > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new > draft-george-ipv6-required > >> I agree so strenuously that I half-jokiningly would like to be listed as a >> coauthor, and I bet there are a>number of other folks on these lists that >> would feel the same way. Perhaps a better suggestion would be to>include an >> appendix with the name and affiliation of everyone who is willing to sign-on >> to ratify this>recommendation. > [WES] If I'm interpreting this right, this would sort of be like a petition > with lots of signatures, or one of those open letters to the > $government_functionary signed by lots of "important people" you see published > in full-page newspaper ads? I assume that this is generally a way of more > concretely documenting support for this proposal beyond the IETF's standard > rough consensus in a WG meeting or on-list. > I'm open to this, but is there any precedent for it? Do we want to set a > precedent that if we *really* mean something, we take steps to more thoroughly > document that support within a draft? Those in support can already have their > support immortalized in the pages of the email list archives complete with > their choice of editorialization... > And regarding affiliation - IETF typically shies away from making a big deal > of affiliation, since most of its members are not really authorized to > represent the company that pays the bills in any official public capacity. > Yes, they are representatives of that company, but they are mostly speaking > for themselves with the interests of their company informing those comments - > it's not like there's a way to get every email and comment at the mic approved > by PR first :-) > > An IAB statement of support would perhaps be a good way to add weight to this > recommendation, but I'm content to start with statements of support for WG > adoption and advancement to RFC status and see where it goes from there. > > Wes George -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From rajiva@cisco.com Mon Jan 10 10:46:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D343A69C5; Mon, 10 Jan 2011 10:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.309 X-Spam-Level: X-Spam-Status: No, score=-10.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 PYxDmtaDZsGT; Mon, 10 Jan 2011 10:46:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EDF523A6B04; Mon, 10 Jan 2011 10:46:30 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEDjKk2tJV2Z/2dsb2JhbACkR3OjC5guhUwEhGeJSYgL Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 18:48:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0AImi3W031186; Mon, 10 Jan 2011 18:48:44 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 12:48:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 12:48:40 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D205F0@XMB-RCD-111.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E502DF203B@XMB-AMS-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: Acuuvn4iydAPseQ4RmSPGhg/38uBdQAAmU8gAHwiuuAAEVzPoA== References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com><4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at><4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at><4D278B93.8050903@isi.edu><4D279773.30102@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com><4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> <4269EA985EACD24987D82DAE2FEC62E502DF203B@XMB-AMS-101.cisco.com> From: "Rajiv Asati (rajiva)" To: "Gunter Van de Velde (gvandeve)" , "Joe Touch" X-OriginalArrivalTime: 10 Jan 2011 18:48:44.0467 (UTC) FILETIME=[01DA1030:01CBB0F7] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:46:32 -0000 Hi Gunter, Good question. Are you intending to suggest that this draft should consider the IPv6 vs. Ipv4 service experience while making the recommendation? Cheers, Rajiv > -----Original Message----- > From: Gunter Van de Velde (gvandeve) > Sent: Monday, January 10, 2011 5:34 AM > To: Rajiv Asati (rajiva); Joe Touch > Cc: int-area@ietf.org; IPv6 Operations > Subject: RE: [v6ops] [Int-area] IP-capable nodes must support IPv6 - > newdraft-george-ipv6-required >=20 > <>start snip<> > > the point that "if IPv4 is supported better, in any way, than IPv6, > on > > a device, then there is incentive to not use IPv6". > This broader issue in conjunction with all that exists on an IPv4 > gateway may not be needed on an IPv6 gateway, warrants the set of MUST > and SHOULD/MAY IPv6 features. That was the intent of my suggestion. > <>end snip<> >=20 > I am interested to understand 'how' you want to quantify the IPv6 vs > IPv4 service experience. >=20 > G/ >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Rajiv Asati (rajiva) > Sent: zaterdag 8 januari 2011 0:19 > To: Joe Touch > Cc: int-area@ietf.org; IPv6 Operations > Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - > newdraft-george-ipv6-required >=20 > Joe, >=20 > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > > 1123, and 1812 (and their supplementary RFCs). >=20 > Ditto. I am sure that we could come up with few more. >=20 > > But there's a broader issue - > > the point that "if IPv4 is supported better, in any way, than IPv6, > on > > a device, then there is incentive to not use IPv6". >=20 > This broader issue in conjunction with all that exists on an IPv4 > gateway may not be needed on an IPv6 gateway, warrants the set of MUST > and SHOULD/MAY IPv6 features. That was the intent of my suggestion. >=20 > Cheers, > Rajiv From lee@asgard.org Mon Jan 10 10:46:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E36028C0E4 for ; Mon, 10 Jan 2011 10:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtAMbcZIpBEw for ; Mon, 10 Jan 2011 10:46:42 -0800 (PST) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by core3.amsl.com (Postfix) with ESMTP id 4698128C0CF for ; Mon, 10 Jan 2011 10:46:39 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0AImqlB025297 for ; Mon, 10 Jan 2011 13:48:52 -0500 Authentication-Results: cm-omr2 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:51707] helo=HDC00027112) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1E/F7-06971-4945B2D4; Mon, 10 Jan 2011 13:48:52 -0500 From: "Lee Howard" To: "'Joe Touch'" , "'Mark Smith'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> In-Reply-To: <4D2B4618.6050703@isi.edu> Date: Mon, 10 Jan 2011 13:48:47 -0500 Message-ID: <001101cbb0f7$06cc8af0$1465a0d0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuw7roI0HzxOeq1R2GrYHnU5guCwAABVUCg Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:46:42 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > I'm simply making a few observations: > > 1) anything a device supports for IPv4 that it cannot support for IPv6 > will be taken as an excuse not to migrate to IPv6 > 2) it's better to remove that hurdle than to debate every capability. > 3) NATs are useful even where addresses are plentiful This sounds like a WG chartering debate, rather than a debate about whether all IP-capable devices SHOULD support IPv6. It sounds like your support for draft-george-ipv6-required is dependent on rechartering BEHAVE, defining NAT66, and updating draft-ietf-v6ops-cpe-router to require NAT66. In other words, you will not support the statement, "IPv6 is required in IP-capable devices" until that statement specifically includes feature parity, and explicitly includes NAT66. Is that right? Lee From rajiva@cisco.com Mon Jan 10 10:51:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57083A6B0D; Mon, 10 Jan 2011 10:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.345 X-Spam-Level: X-Spam-Status: No, score=-10.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 3Un+86P5Ikdn; Mon, 10 Jan 2011 10:51:21 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 30D983A6B08; Mon, 10 Jan 2011 10:51:21 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFzkKk2tJXG9/2dsb2JhbACkR3OjDZgugnSCWASEZ4lJiAs Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 18:53:35 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0AIrYLq022982; Mon, 10 Jan 2011 18:53:34 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 12:53:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 12:53:33 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D205FD@XMB-RCD-111.cisco.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: AQHLrr3OZ1PupmJS+kufkXHyVXljfpPGg+GAgAAF3oCAA8NuYIAAQ14g References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com><4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at><4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at><4D278B93.8050903@isi.edu><4D279773.30102@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com><4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> From: "Rajiv Asati (rajiva)" To: "George, Wes E [NTK]" , "Joe Touch" X-OriginalArrivalTime: 10 Jan 2011 18:53:34.0704 (UTC) FILETIME=[AED8B700:01CBB0F7] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:51:22 -0000 Wes, > sooner we correct the lack of IPv6 support in devices and software, the > better off we are. +1 > That said, it may be helpful to write a draft comparing IPv4 and IPv6 > for=09 > feature parity to identify future work items for IETF and point to the > appropriate RFCs where equivalent features exist, but I view that as > complimentary to this draft, not part of it. That's reasonable as long as we add appropriate references. > I agree that the more specific information about what we mean by > "support > IPv6" should be made available, but as references, not text in the > draft itself. +1 > The draft also formally updates 1812 and 1122. I can add 1123 to that > list > of updated drafts if there is consensus that it should be added. > Brian Carpenter also recommended (offlist) that we might want to > consider > adding RFC4084 to the update list, specifically, moving "Version" from > section 4 (additional terminology) to section 2 (general terminology). > What are your thoughts on that? +1 > What else is missing as a reference? Keep in mind that the existing > referenced drafts and RFCs have multiple normative and informative > references of their own which we didn't see the need to duplicate here. Indeed. Cheers, Rajiv > -----Original Message----- > From: George, Wes E [NTK] [mailto:Wesley.E.George@sprint.com] > Sent: Monday, January 10, 2011 10:50 AM > To: Rajiv Asati (rajiva); Joe Touch > Cc: int-area@ietf.org; IPv6 Operations > Subject: RE: [Int-area] IP-capable nodes must support IPv6 -newdraft- > george-ipv6-required >=20 > > -----Original Message----- > > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > > Behalf Of Rajiv Asati (rajiva) > > Sent: Friday, January 07, 2011 6:19 PM > > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - > newdraft- > > george-ipv6-required > > > > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > > > 1123, and 1812 (and their supplementary RFCs). > > > > Ditto. I am sure that we could come up with few more. > > > [WES] I think that those lists already exist for IPv6, but not always > in > exactly the same form as the IPv4 specs you reference above. I assume > that > the IPv6 specifications aren't listed as updates to the above IPv4 RFCs > because IPv6 was considered optional, not a direct replacement for > IPv4. I > wasn't about to go so far as to deprecate the appropriate IPv4 spec in > favor > of the IPv6 one... baby steps :-) > Either way, this draft is meant to be a generic update informing those > who > are considering putting an IP stack on their device, whether dumb or > smart, > simple or complex, that they need to stop considering IPv6 optional. We > intentionally kept it generic so that it could be adopted more quickly > - the > sooner we correct the lack of IPv6 support in devices and software, the > better off we are. >=20 > That said, it may be helpful to write a draft comparing IPv4 and IPv6 > for=09 > feature parity to identify future work items for IETF and point to the > appropriate RFCs where equivalent features exist, but I view that as > complimentary to this draft, not part of it. >=20 > I agree that the more specific information about what we mean by > "support > IPv6" should be made available, but as references, not text in the > draft > itself. > The draft already references ietf-v6ops-ipv6-cpe-router, and RFC 4294, > which > I've been informed will soon be replaced by a BIS version (currently > draft-ietf-6man-node-req-bis). I will update that reference in the next > version of the draft. > The draft also formally updates 1812 and 1122. I can add 1123 to that > list > of updated drafts if there is consensus that it should be added. > Brian Carpenter also recommended (offlist) that we might want to > consider > adding RFC4084 to the update list, specifically, moving "Version" from > section 4 (additional terminology) to section 2 (general terminology). > What > are your thoughts on that? >=20 > What else is missing as a reference? Keep in mind that the existing > referenced drafts and RFCs have multiple normative and informative > references of their own which we didn't see the need to duplicate here. >=20 > Thanks for the support thus far. >=20 > Wes George From touch@isi.edu Mon Jan 10 11:01:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612B828C0CE; Mon, 10 Jan 2011 11:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 CKItpUcaTj32; Mon, 10 Jan 2011 11:01:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6E1723A6B0E; Mon, 10 Jan 2011 11:01:20 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0AJ2rd1020377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 11:02:53 -0800 (PST) Message-ID: <4D2B57DD.5030908@isi.edu> Date: Mon, 10 Jan 2011 11:02:53 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lee Howard References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> In-Reply-To: <001101cbb0f7$06cc8af0$1465a0d0$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'IPv6 Operations' , int-area@ietf.org, matthew@matthew.at Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:01:21 -0000 On 1/10/2011 10:48 AM, Lee Howard wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Joe Touch >> I'm simply making a few observations: >> >> 1) anything a device supports for IPv4 that it cannot support for IPv6 >> will be taken as an excuse not to migrate to IPv6 >> 2) it's better to remove that hurdle than to debate every capability. >> 3) NATs are useful even where addresses are plentiful > > This sounds like a WG chartering debate, rather than a debate about whether > all IP-capable devices SHOULD support IPv6. > It sounds like your support for draft-george-ipv6-required is dependent on > rechartering BEHAVE, defining NAT66, and updating > draft-ietf-v6ops-cpe-router > to require NAT66. In other words, you will not support the statement, "IPv6 > > is required in IP-capable devices" until that statement specifically > includes > feature parity, and explicitly includes NAT66. > Is that right? I support the idea that new devices should be IPv6 capable. I recognize the irrelevance of such an assertion. IMO, if we can't assert that "new devices need to support IPv6 as much as they support IPv4", there's simply no point. We'll be where we are now. Many organizations won't buy a device without the IPV6 label, but since most such devices have services that won't run on v6, v6 isn't enabled. I.e., what's the point, unless we say "support IPv6 at least as well as IPv4"? Joe From townsley@cisco.com Mon Jan 10 12:40:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF9928C135 for ; Mon, 10 Jan 2011 12:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 s7nqFJY0qDvX for ; Mon, 10 Jan 2011 12:40:00 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 155173A6844 for ; Mon, 10 Jan 2011 12:39:59 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFACP+Kk2Q/khNgWdsb2JhbACWO44QFQEBFiIkowCYTYVMBIsK Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Jan 2011 20:42:14 +0000 Received: from ams-townsley-8712.cisco.com (ams-townsley-8712.cisco.com [10.55.233.227]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0AKgDlt023521 for ; Mon, 10 Jan 2011 20:42:14 GMT Message-ID: <4D2B6F25.8070502@cisco.com> Date: Mon, 10 Jan 2011 21:42:13 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> In-Reply-To: <4D2B3DCE.7010102@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:40:01 -0000 On 1/10/11 6:11 PM, Fernando Gont wrote: > On 05/01/2011 04:58 p.m., Brian E Carpenter wrote: > >> Hmm. This is the document of which I wrote a few months ago on >> another list: >> >>> Except that this is truly obnoxious and paranoid: >>> >>>>> Organizations that are not yet deploying IPv6 should implement >>>>> the following recommendations: >>>>> >>>>> * Block all IPv6 traffic, native and tunneled, at the >>>>> organization's firewall. Both incoming and outgoing traffic >>>>> should be blocked. > > Well, if the firewall is meant to allow only traffic that is deemed as > necessary, and the organization has not decided to deploy v6... why > should it be allowed? Classic "traffic blocking" measures for v6 can affect v4. For example, there is a recommendation to block IPv6 over IPv4 tunneling in the NIST profile as well. That of course can be done, but one must understand that this could cause noticeable timeouts and such for users with operating systems which automatically try and establish such tunnels. So, the enterprise needs to either have the ability to actively turn off IPv6 on the hosts, or perhaps filter out all AAAAs at the border and be sure to control the DNS configured in all hosts, etc. in order to avoid these kinds of problems (or deal with annoyed users and lost productivity, or hope that happy-eyeballs appears RSN, ...). > And.. what would be the point of firewalling v4 > when you could bypass the firewall with v6? Modern Macs and PCs come with firewalls enabled by default that are regularly updated by the manufacturer. They also happen to be the ones with IPv6 capability. Pre XP-SP2, win 95, etc. devices shipped without a local firewall on by default and themselves were not developed well enough to exist on the open Internet without a network-based firewall. Good thing they don't run IPv6 without special intervention. Not to say for a moment that there no conceivable ways to breech security of an IPv6 enabled host for which a firewall might otherwise provide protection, but I do think there is a difference between setting up a firewall in front of hosts which already have their own firewalls vs. those that do not. - Mark > > (Note: there's stuff in the NIST document with which I don't agree. But > this particular recommendation is, IMO, as paranoid as it *needs* to be) > > Thanks! > > Best regards, From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 12:41:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97EA3A63C9; Mon, 10 Jan 2011 12:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 XkhKobd-nyKK; Mon, 10 Jan 2011 12:41:29 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id A474B3A635F; Mon, 10 Jan 2011 12:41:28 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcOaP-0004Ik-KA; Tue, 11 Jan 2011 07:13:29 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 355A03B31E; Tue, 11 Jan 2011 07:13:29 +1030 (CST) Date: Tue, 11 Jan 2011 07:13:29 +1030 From: Mark Smith To: Fernando Gont Message-ID: <20110111071329.109df03f@opy.nosense.org> In-Reply-To: <4D2B3928.8050508@gont.com.ar> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:41:29 -0000 On Mon, 10 Jan 2011 13:51:52 -0300 Fernando Gont wrote: > Hi, Remi, >=20 > On 10/01/2011 05:30 a.m., R=C3=A9mi Despr=C3=A9s wrote: >=20 > >> End-to-end transparency in the sense that every node will be > >> reachable from every node? > >=20 > > The e2e transparency that IPv4 had lost, and IPv6 restores, is > > ADDRESS transparency: source and destination addresses seen by a > > destination are the same as those set by the source.=20 >=20 > IPv6 restores this to the extent that NAT66 is not deployed. My take is > that NAT66 *will* be deployed.=20 How do you know? What evidence do you have? >-- So, I don't think you can rely IPv6 on > restoring "address transparency". >=20 >=20 > > - This is needed > > in particular for Header Authentication of IPsec.=20 >=20 > But you can still use UDP encapsulation. >=20 UDP encapsulation of IPsec is a work around, specifically to get around the problems of lack of IPv4 address transparency i.e. NAT. It isn't an acceptable answer when NAT doesn't need to exist. >=20 >=20 > > - Also, it permits > > a host to advertise its source address in the DNS and in referrals. >=20 > Firstly, using network addresses in the application layer is generally a > bad idea, and one would hope that we have already learnt that lesson. >=20 > Secondly, for the an address published in the DNS to be useful, it needs > to be reachable (that's why you advertise the address in the DNS after > all, right?). And for it to be reachable, the stateful firewall tht's in > fron of the host (or within the host), needs to have state for that > "incoming connection". -- In general, there won't be such state, *or* > the firewall would need to be smart enough to understand the application > protocol to create such state before it's needed (so, again, forget > about the "dumb network"). >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lee@asgard.org Mon Jan 10 12:47:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAB23A6405 for ; Mon, 10 Jan 2011 12:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUvDfWVRoi7D for ; Mon, 10 Jan 2011 12:47:49 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 852F73A659C for ; Mon, 10 Jan 2011 12:47:48 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0AKo0m8027634 for ; Mon, 10 Jan 2011 15:50:02 -0500 Authentication-Results: cm-omr2 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:46150] helo=HDC00027112) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 23/95-06971-6F07B2D4; Mon, 10 Jan 2011 15:50:00 -0500 From: "Lee Howard" To: "'Joe Touch'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> In-Reply-To: <4D2B57DD.5030908@isi.edu> Date: Mon, 10 Jan 2011 15:49:51 -0500 Message-ID: <000001cbb107$f27a2650$d76e72f0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuw+RQOmfUdFdP+QbyFYQHwa/cI+QADJNBQ Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:47:50 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > > This sounds like a WG chartering debate, rather than a debate about whether > > all IP-capable devices SHOULD support IPv6. > > It sounds like your support for draft-george-ipv6-required is dependent on > > rechartering BEHAVE, defining NAT66, and updating > > draft-ietf-v6ops-cpe-router > > to require NAT66. In other words, you will not support the statement, "IPv6 > > > > is required in IP-capable devices" until that statement specifically > > includes > > feature parity, and explicitly includes NAT66. > > Is that right? > > I support the idea that new devices should be IPv6 capable. > > I recognize the irrelevance of such an assertion. IMO, if we can't > assert that "new devices need to support IPv6 as much as they support > IPv4", there's simply no point. We'll be where we are now. Many > organizations won't buy a device without the IPV6 label, but since most > such devices have services that won't run on v6, v6 isn't enabled. This document is targeted at node implementors, not deployers. If specific operators have a need for specific features, they may specify those features to their vendors, or bring them to the IETF for definition. IPv6 is not operator-specific, though; all new implementations must support IPv6. > I.e., what's the point, unless we say "support IPv6 at least as well as > IPv4"? I could live with that statement. What I can't accept is that IPv6 must not be required until everything in IPv6 works the same as in IPv4. Does this language cover the case where a vendor can't implement a feature because the IETF hasn't defined it yet? It is expected that many existing devices and implementations will not be able to support IPv6 for one or more valid technical reasons, but for maximum flexibility and compatibility, a best effort SHOULD be made to update existing hardware and software to enable IPv6 support. If that language doesn't work, but you agree with the intended statement in the draft, can you propose language that does not make the draft dependent on publication of a NAT66 RFC? Lee From fernando.gont.netbook.win@gmail.com Mon Jan 10 12:49:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0323A672F; Mon, 10 Jan 2011 12:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 u4DyinO8YDHZ; Mon, 10 Jan 2011 12:49:07 -0800 (PST) Received: from mail-gx0-f194.google.com (mail-gx0-f194.google.com [209.85.161.194]) by core3.amsl.com (Postfix) with ESMTP id 315503A67C0; Mon, 10 Jan 2011 12:48:37 -0800 (PST) Received: by gxk1 with SMTP id 1so4531931gxk.1 for ; Mon, 10 Jan 2011 12:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=fCoyZ+Qo00fN107iIl1kQlSDHHKfGHKZNKH3q9glNjw=; b=nj1/ndTjLStZl4ODXjUpZvUN3mX0ZT+NgDP+LPh7ii1a4w2Xl46NW8sJ14nCUFmEBT Ub9m5fmthX48U2h3Njlr/xmyJd1i0I1EVLzRLZk0BPzStEhWMwuTT8Bpl9JH2yrxhx2P 7NQM2W9uOo9wstIhXz4+n7QAahT0IWSehGP40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=msF6X7n5PWKFuplObMpM6FvTMDzAlY+DWXlNKGphTmLp5EpNhA06jzGlDgzxr6wuG4 SUA0S3eh2Z/jnWCKRbJShTAYFMAIVnHVW1dS5ICBhCLI2VxZYx2HRyN1Iz/iyazqQVQm FDwhiUjI7t5DQKIfYLV5E6Opvd5s7ha1tUonw= Received: by 10.151.154.15 with SMTP id g15mr29675121ybo.87.1294692651214; Mon, 10 Jan 2011 12:50:51 -0800 (PST) Received: from [192.168.2.4] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id k1sm14932320ybj.0.2011.01.10.12.50.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 12:50:49 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B711F.9000705@gont.com.ar> Date: Mon, 10 Jan 2011 17:50:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> In-Reply-To: <20110111071329.109df03f@opy.nosense.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:49:08 -0000 On 10/01/2011 05:43 p.m., Mark Smith wrote: >>> The e2e transparency that IPv4 had lost, and IPv6 restores, is >>> ADDRESS transparency: source and destination addresses seen by a >>> destination are the same as those set by the source. >> >> IPv6 restores this to the extent that NAT66 is not deployed. My take is >> that NAT66 *will* be deployed. > > How do you know? What evidence do you have? Talking to vendors, some operators, etc. Google for "ipv6 nat" or the like, and you'll see some of the people that are publicly interested in this feature. >> -- So, I don't think you can rely IPv6 on >> restoring "address transparency". >> >>> - This is needed >>> in particular for Header Authentication of IPsec. >> >> But you can still use UDP encapsulation. > > UDP encapsulation of IPsec is a work around, specifically to get around > the problems of lack of IPv4 address transparency i.e. NAT. It isn't an > acceptable answer when NAT doesn't need to exist. You're assuming that the only motivation to have NATs is address exhaustion -- but IMO, it isn't. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 13:13:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9DA3A67DA; Mon, 10 Jan 2011 13:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 OIGGluYKuI9Z; Mon, 10 Jan 2011 13:13:05 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id E32843A67EF; Mon, 10 Jan 2011 13:13:04 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcP56-0005oX-Ia; Tue, 11 Jan 2011 07:45:12 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0D0703B31E; Tue, 11 Jan 2011 07:45:12 +1030 (CST) Date: Tue, 11 Jan 2011 07:45:11 +1030 From: Mark Smith To: "George, Wes E [NTK]" Message-ID: <20110111074511.022d29bf@opy.nosense.org> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Howard, Lee" , Christopher, "v6ops@ietf.org" , "int-area@ietf.org" , LILJENSTOLPE Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:13:06 -0000 On Fri, 7 Jan 2011 18:52:33 +0000 "George, Wes E [NTK]" wrote: > As a direct result of discussions after Beijing about the hotly-contested > draft regarding IANA allocating a new shared IPv4 address space, the authors > of this draft realized that the root problem is actually the lack of IPv6 > support in existing devices, which is adding a barrier to wider deployment in > many networks. This is being made worse due to two things: lack of interest by > vendors in back-porting true IPv6 support into devices that are > software-upgradeable and could otherwise support it, and the fact that some > vendors are still churning out devices which do not support IPv6 even as we > stare down the imminent exhaustion of the IANA free IPv4 pool. This draft > attempts to address this problem by updating the definition of an "IP-capable" > node to require support for IPv6. > I don't think I really agree with the root cause. IPv6 doesn't exist in equipment because customers, or representatives of customers (e.g ISPs for CPE) haven't made it a "must have", and refused to buy the equipment when it doesn't support IPv6. Making it a requirement in an IETF document still won't make it happen unless customers demand compliance with that IETF document. They haven't done that with the group of IPv6 RFCs, so I don't see why a single RFC going to be any different. My recent experience has been that a CPE vendor, once they know that you require IPv6 support, starts caring not about whether to implement it or not, but what specific requirements you have. For example, our recent focus has just been basic IPv6 connectivity i.e. so the CPE can connect customers to the IPv6 Internet. Out of the blue, the vendor asked us if we considered SIP over IPv6 for the ATA inside the CPE to be a must have or not. They wouldn't be thinking about that level of feature implementation detail if we hadn't made "IPv6" a fundamental requirement. I've also seen rapid improvement in an IPv6 implementation over a six week period once the vendor realised that they were going to miss out on 100s if not 1000s of CPE sales. (It's very impressive when you report a bug on one day and you've got firmware fresh out of the compiler a day or two later that addresses it). > The authors are fully aware that this is not going to solve the problem of > legacy installed-base, nor is it going to prevent people from continuing to > release hardware that is IPv4-only. However, we believe that the IETF is > overdue to acknowledge that IPv6 will be a requirement going forward, and not > just optional. > I think a different and better approach would be to officially deprecate IPv4, declaring it obsolete. That doesn't mean people can't use it, but it is the IETF saying that it is past it's used-by date, and people should be using IPv6 in preference. I think if the inventors/maintainers of IPv4 were to say people should try to avoid using IPv4, people will pay more attention than continuing to think that it is fine to use IPv4, and IPv6 is an optional feature they can compromise on if they need to. There is a bit of psychology in that - people generally don't like choosing to use obsolete technologies (social proof), and also place significant value on when somebody says "I invented it, but don't use it anymore, you'll have problems." (authority) Regards, Mark. > We'd appreciate your support in adopting this as an int-area draft, or > possibly a v6ops draft. > > We'd be happy to discuss the draft in either meeting at IETF 80 if the WG > chair feels that it is appropriate. > > Thanks, > Wes George > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, January 07, 2011 1:28 PM > To: George, Wes E [NTK] > Cc: C.Donley@cablelabs.com; cdl@asgaard.org; lee.howard@twcable.com > Subject: New Version Notification for draft-george-ipv6-required-00 > > > A new version of I-D, draft-george-ipv6-required-00.txt has been successfully > submitted by Wesley George and posted to the IETF repository. > > https://datatracker.ietf.org/doc/draft-george-ipv6-required/ > > Filename: draft-george-ipv6-required > Revision: 00 > Title: IPv6 Support Required for all IP-capable nodes > Creation_date: 2011-01-06 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > Given the global lack of available IPv4 space, and limitations in > IPv4 extension and transition technologies, this document deprecates > the concept that an IP-capable node MAY support IPv4 _only_, and > redefines an IP-capable node as one which supports either IPv6 _only_ > or IPv4/IPv6 dual-stack. This document updates RFC1812 and 1122 to > reflect the change in requirements. > > > > The IETF Secretariat. > > > From brian.e.carpenter@gmail.com Mon Jan 10 13:43:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CDE3A6840; Mon, 10 Jan 2011 13:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.108 X-Spam-Level: X-Spam-Status: No, score=-103.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, 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 iSSkjdM8Rk6L; Mon, 10 Jan 2011 13:43:29 -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 078473A6841; Mon, 10 Jan 2011 13:43:28 -0800 (PST) Received: by fxm9 with SMTP id 9so19631358fxm.31 for ; Mon, 10 Jan 2011 13:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=k6Gwa89mdCEoiIWHBtbC51tptznzM9gVqAE6WFOwE6w=; b=sncz/grnJQ2Bt1siuhU0B1ZWH25gkYi2lXJppvu1muROWvuAjcl+4i9SgxWpbBdYb/ NmYQL5fEJTflcV2zbwOULREXkvLi76t/wRltrZBThQyodTxmq/EeBzUu4cw587U58tBj 8QAHf/u0oULidW1FVJLp5oECblelPi07nAtys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=szW5GZwUnIqR911nL7adu+IcRaiXxM1Xa6VxYiH6BpiNV80kKqs2o6lnYORHpqQyg+ OGNzPpDooavwoCNvPriq8b8U2loOMOzmLIa41LNF7DpFuVXkhGzP0K1P0pkr6ajIpDOu RUcvoh8BL5n+mBoPuDCREaVZC5nXgCxcKvbkk= Received: by 10.223.95.203 with SMTP id e11mr1246988fan.60.1294695943235; Mon, 10 Jan 2011 13:45:43 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r24sm7163487fax.3.2011.01.10.13.45.39 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 13:45:42 -0800 (PST) Message-ID: <4D2B7E00.6020106@gmail.com> Date: Tue, 11 Jan 2011 10:45:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> In-Reply-To: <4D2B3928.8050508@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:43:30 -0000 On 2011-01-11 05:51, Fernando Gont wrote: > Hi, Remi, >=20 > On 10/01/2011 05:30 a.m., R=C3=A9mi Despr=C3=A9s wrote: >=20 >>> End-to-end transparency in the sense that every node will be >>> reachable from every node? >> The e2e transparency that IPv4 had lost, and IPv6 restores, is >> ADDRESS transparency: source and destination addresses seen by a >> destination are the same as those set by the source.=20 >=20 > IPv6 restores this to the extent that NAT66 is not deployed. My take is= > that NAT66 *will* be deployed. -- So, I don't think you can rely IPv6 o= n > restoring "address transparency". IPv4 intrinsically destroys address transparency by not having enough addresses. The good news is that IPv6 doesn't have this property. So although some vendors and users will ignore this good news for reasons of their own, e2e address+port transparency remains available and will in due time be seen as desirable. Patience is needed, though; it will probably be many years before this perception filters through everywhere and NAT66 becomes a curiosity of history. Brian From sthaug@nethelp.no Mon Jan 10 13:45:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002423A679C for ; Mon, 10 Jan 2011 13:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 IVsjMnblGzmP for ; Mon, 10 Jan 2011 13:45:25 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by core3.amsl.com (Postfix) with SMTP id A29F03A67F9 for ; Mon, 10 Jan 2011 13:45:22 -0800 (PST) Received: (qmail 42957 invoked from network); 10 Jan 2011 21:47:35 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Jan 2011 21:47:35 -0000 Date: Mon, 10 Jan 2011 22:47:35 +0100 (CET) Message-Id: <20110110.224735.41641090.sthaug@nethelp.no> To: fernando@gont.com.ar From: sthaug@nethelp.no In-Reply-To: <4D2B711F.9000705@gont.com.ar> References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, int-area@ietf.org Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:45:26 -0000 > > UDP encapsulation of IPsec is a work around, specifically to get around > > the problems of lack of IPv4 address transparency i.e. NAT. It isn't an > > acceptable answer when NAT doesn't need to exist. > > You're assuming that the only motivation to have NATs is address > exhaustion -- but IMO, it isn't. Provider independence is a huge motivation. People have it with IPv4 and NAT today, at least to some degree - and don't see why they should be tied to a specific provider's PA space, *or* have to jump through hoops, to get IPv6 PI space. Thus the desire for IPv6 stateless NAT. [If you don't think IPv6 PI space requires jumping through hoops - consider http://www.ripe.net/ripe/policies/proposals/2006-01.html which is the RIPE requirements for PI space. Note that I'm *not* saying these requirements are bad - I'm just saying they are more than a lot of companies, used to IPv4 NAT, will be willing to deal with...] Steinar Haug, Nethelp consulting, sthaug@nethelp.no From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 13:48:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22E43A6856; Mon, 10 Jan 2011 13:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 enQigBuzN0Y7; Mon, 10 Jan 2011 13:48:16 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id A1B603A6859; Mon, 10 Jan 2011 13:48:14 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcPdC-0008Ld-4W; Tue, 11 Jan 2011 08:20:26 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 765993B31E; Tue, 11 Jan 2011 08:20:23 +1030 (CST) Date: Tue, 11 Jan 2011 08:20:23 +1030 From: Mark Smith To: "Lee Howard" Message-ID: <20110111082023.209f0497@opy.nosense.org> In-Reply-To: <000001cbb107$f27a2650$d76e72f0$@org> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 'IPv6 Operations' , int-area@ietf.org, 'Joe Touch' Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:48:17 -0000 On Mon, 10 Jan 2011 15:49:51 -0500 "Lee Howard" wrote: > > > > -----Original Message----- > > From: Joe Touch [mailto:touch@isi.edu] > > > This sounds like a WG chartering debate, rather than a debate about > whether > > > all IP-capable devices SHOULD support IPv6. > > > It sounds like your support for draft-george-ipv6-required is dependent > on > > > rechartering BEHAVE, defining NAT66, and updating > > > draft-ietf-v6ops-cpe-router > > > to require NAT66. In other words, you will not support the statement, > "IPv6 > > > > > > is required in IP-capable devices" until that statement specifically > > > includes > > > feature parity, and explicitly includes NAT66. > > > Is that right? > > > > I support the idea that new devices should be IPv6 capable. > > > > I recognize the irrelevance of such an assertion. IMO, if we can't > > assert that "new devices need to support IPv6 as much as they support > > IPv4", there's simply no point. We'll be where we are now. Many > > organizations won't buy a device without the IPV6 label, but since most > > such devices have services that won't run on v6, v6 isn't enabled. > > This document is targeted at node implementors, not deployers. > If specific operators have a need for specific features, they may specify > those features to their vendors, or bring them to the IETF for > definition. IPv6 is not operator-specific, though; all new implementations > must support IPv6. > > > I.e., what's the point, unless we say "support IPv6 at least as well as > > IPv4"? > > I could live with that statement. What I can't accept is that IPv6 must > not be required until everything in IPv6 works the same as in IPv4. I agree, and I think the following post a few months ago was very insightful regarding requiring complete IPv4/IPv6 parity - http://lists.cluenet.de/pipermail/ipv6-ops/2010-June/003650.html > Does this language cover the case where a vendor can't implement a > feature because the IETF hasn't defined it yet? > It is expected that many existing devices and implementations will > not be able to support IPv6 for one or more valid technical > reasons, but for maximum flexibility and compatibility, a best > effort SHOULD be made to update existing hardware and software to > enable IPv6 support. > > If that language doesn't work, but you agree with the intended > statement in the draft, can you propose language that does not > make the draft dependent on publication of a NAT66 RFC? > > Lee > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From touch@isi.edu Mon Jan 10 13:59:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341A93A67A2; Mon, 10 Jan 2011 13:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 xKxJxAXnwtJy; Mon, 10 Jan 2011 13:59:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 3305A3A6820; Mon, 10 Jan 2011 13:59:28 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0AM1Tck017435 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 14:01:29 -0800 (PST) Message-ID: <4D2B81B8.70008@isi.edu> Date: Mon, 10 Jan 2011 14:01:28 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lee Howard References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> In-Reply-To: <000001cbb107$f27a2650$d76e72f0$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:59:29 -0000 Hi, Lee, On 1/10/2011 12:49 PM, Lee Howard wrote: ... >> I.e., what's the point, unless we say "support IPv6 at least as well as >> IPv4"? > > I could live with that statement. What I can't accept is that IPv6 must > not be required until everything in IPv6 works the same as in IPv4. AOK; I don't want to get hung up on specifics. Again, the point is that "support IPv6 at least as well as IPv4" is better than "support IPv6". > Does this language cover the case where a vendor can't implement a > feature because the IETF hasn't defined it yet? Well, if there are such features, then they're clearly going to be an issue. That needs to be fixed. Sure, you can't expect an implementation to support IPv6 for protocols that have no IPv6 variant yet. That means we have work to do before we ought to be jumping up and down expecting everyone to use IPv6, though. > It is expected that many existing devices and implementations will > not be able to support IPv6 for one or more valid technical > reasons, but for maximum flexibility and compatibility, a best > effort SHOULD be made to update existing hardware and software to > enable IPv6 support. I don't like this language. It was true for Windows and MacOS previous to the 2005 IPv6 IETF test, and we saw how that worked out (not). IMO, you shouldn't be able to claim IPv6 just by "best effort". There is no SHOULD, enable or support. There is only "do". I.e., either a system supports IPv6 - for all IP communications - or not. That might be sufficient, if you want different language: "A system that supports IPv6 MUST support IPv6 for all IP communications in the absence of any other version of IP communications (including IPv4). That system MUST provide IPv6 communications services to the same or greater extent than are available for IPv4." and "All new systems SHOULD support IPv6 as per above. All existing systems SHOULD support IPv6 as per above as soon as possible" > If that language doesn't work, but you agree with the intended > statement in the draft, can you propose language that does not > make the draft dependent on publication of a NAT66 RFC? That's one you want to exclude. I'm sure there are others that other people want to exclude. Any that are excluded *will* (IMO) be an excuse for not using IPv6. I would prefer to ensure that IPv6 has the same or greater services than IPv4, and separately state that: "Note that not all IPv4 services are recommended or even defined in an IPv6-only environment. To the extent that such services are not meaningful (e.g., NAT66 solely for address space extension), they are not required by the above." Joe From brian.e.carpenter@gmail.com Mon Jan 10 14:00:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6197F3A6804 for ; Mon, 10 Jan 2011 14:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 K+q4wXGZi2sX for ; Mon, 10 Jan 2011 14:00:08 -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 358D73A687C for ; Mon, 10 Jan 2011 14:00:08 -0800 (PST) Received: by fxm9 with SMTP id 9so19646266fxm.31 for ; Mon, 10 Jan 2011 14:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RBO3JIALrYRS8OTmSvBKgCfYYk/Qid4sWump0Z/+AD0=; b=WFgHye4IKyMgLpUceedy+w4/ecLlU9pEWXWDXAPIgK74lo8QOn1wHyYVvxHN20mZIA w8Ilwy6bV98z8L12KkZJrQattP5eKg5vSzVpDzFtzLNw0FQ4RWSeNgVgmK0AZsdA2joT IizGi2vmO49fOojGrqsjIqfLQOgLIDJqSVaeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=OfTjTYy5+Uwz0/jgHhSYpnCD5nlpsgcNbLleuHy0xZuKmszqu2fzZBffPJBeSavc84 mOU1ViNEuOiuCmihNH2/A08iHMSU+CAVmD9beAsOHzsfoXC8CnjgUGFdUkfTzU35XCem r5QOdv1lJ0Ci0N40opVO6ZaVrrxsJUx8h0oVo= Received: by 10.223.72.202 with SMTP id n10mr2299051faj.74.1294696936114; Mon, 10 Jan 2011 14:02:16 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k6sm7167403faa.30.2011.01.10.14.01.31 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 14:01:34 -0800 (PST) Message-ID: <4D2B81B9.3070608@gmail.com> Date: Tue, 11 Jan 2011 11:01:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> In-Reply-To: <4D2B3DCE.7010102@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 22:00:09 -0000 Hi Fernando, On 2011-01-11 06:11, Fernando Gont wrote: > On 05/01/2011 04:58 p.m., Brian E Carpenter wrote: > >> Hmm. This is the document of which I wrote a few months ago on >> another list: >> >>> Except that this is truly obnoxious and paranoid: >>> >>>>> Organizations that are not yet deploying IPv6 should implement >>>>> the following recommendations: >>>>> >>>>> * Block all IPv6 traffic, native and tunneled, at the >>>>> organization's firewall. Both incoming and outgoing traffic >>>>> should be blocked. > > Well, if the firewall is meant to allow only traffic that is deemed as > necessary, and the organization has not decided to deploy v6... why > should it be allowed? Because it blocks experiment and innovation by people within the organization. In general, that's a bad thing for any organization that wishes to develop and grow. The precautionary approach is the enemy of progress. Enough philosophy... for the rest, see Mark Townsley's reply. Brian And.. what would be the point of firewalling v4 > when you could bypass the firewall with v6? > > (Note: there's stuff in the NIST document with which I don't agree. But > this particular recommendation is, IMO, as paranoid as it *needs* to be) > > Thanks! > > Best regards, From behcetsarikaya@yahoo.com Mon Jan 10 15:00:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA103A672F for ; Mon, 10 Jan 2011 15:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 vluqP3ocChTw for ; Mon, 10 Jan 2011 15:00:27 -0800 (PST) Received: from nm28.bullet.mail.sp2.yahoo.com (nm28.bullet.mail.sp2.yahoo.com [98.139.91.98]) by core3.amsl.com (Postfix) with SMTP id 7D02B3A6403 for ; Mon, 10 Jan 2011 15:00:27 -0800 (PST) Received: from [98.139.91.70] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 23:02:40 -0000 Received: from [98.139.91.4] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 23:02:40 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 23:02:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 244799.91220.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 73484 invoked by uid 60001); 10 Jan 2011 23:02:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294700559; bh=BpudBETQRNPgqQhBqC8p6/AcRPvtjh2VZ8Qb7ZFsGdc=; 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=0lc5PIVg1B4uqDHMrWUFaAYnpk7yaVUsCXENC4YPBvWkkBXg9bO9ZfdnS+dQViw99yYoA7nspEpOf1O/fwMrSrKAk+ss+yDDIWZpxy3hwoWxs7nt8z/Y7u0CMtfhBTM3D9+TktwEJjc9PcIu2vROy3U/nzyreEi9GwoQ3PdZ3BQ= 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=jeyehoYBN7YHws5uCVpqaehfrw9ZiAUNEkZ5NavkmWEDIpULK7aT2JsxUbTCGTQS+qYZFQR/0DaC2MRliI4+V+r402n55W8sRYJoObq+bnZdhph/0qegtZjjTPcEgLNRlrNkhysqVgUAQ0KRLuVXcZj7eSfdZ2PWo7Dkm91FKL8=; Message-ID: <913371.73213.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: pGbnEWYVM1kiiQNTAW2_R3aThswjnZT7DyheLhcd3uN7LXZ 09OQ7I6T_LJe3adVnxfaAq5NTEA3MvIOsLbyJLMDW.RKVMXwvgJhRwVlVWwz PDLPL0uTRGF02AUYhlAyuEIXQps5JISBCpfmdm7OzzwICqisIAt2ISOtrvvY PnRB__qhCvTEZEWxlQRTNdGnZ3flDRDLPmptv8k7v079592b10js03mWNWd3 eD_zLPod1boXqXDfq9mujF7nDbiD6Aeeu7upyWanxVQNrB_VcXoulD0SO_RL x6UVDRIUHzunKahcPvM6pzV30fUHq_Cj7q40RkExW8GRAJ4dfBIHAXQMHK_s rM_V89jPInO1EpJ6XORI.Z7GGwjZhl1cFYmIiuUbWOTHuEeLCy1BP2C8VOEu e_JbvLOcTpL6v Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Mon, 10 Jan 2011 15:02:39 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> Date: Mon, 10 Jan 2011 15:02:39 -0800 (PST) From: Behcet Sarikaya To: Mark Smith In-Reply-To: <20110111074511.022d29bf@opy.nosense.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:00:28 -0000 > I think a different and better approach would be to officially deprecate > IPv4, declaring it obsolete. That doesn't mean people can't use it, > but it is the IETF saying that it is past it's used-by date, and people > should be using IPv6 in preference. I think if the > inventors/maintainers of IPv4 were to say people should try to avoid > using IPv4, people will pay more attention than continuing to think > that it is fine to use IPv4, and IPv6 is an optional feature they can > compromise on if they need to. There is a bit of psychology in that - > people generally don't like choosing to use obsolete technologies > (social proof), and also place significant value on when somebody says > "I invented it, but don't use it anymore, you'll have > problems." (authority) > +1 I love this proposal. From brian.e.carpenter@gmail.com Mon Jan 10 15:09:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECB63A6778 for ; Mon, 10 Jan 2011 15:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.423 X-Spam-Level: X-Spam-Status: No, score=-103.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 rb09fK07vQ03 for ; Mon, 10 Jan 2011 15:09:18 -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 D1D1D3A6403 for ; Mon, 10 Jan 2011 15:09:17 -0800 (PST) Received: by ewy8 with SMTP id 8so9237764ewy.31 for ; Mon, 10 Jan 2011 15:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nGiHiaVr4BYWJVx6/6J2lxIpxytfPfiS0oxX8H3szZc=; b=fL7Blm7llVS7Cb0pPZkXqvRnOfXKraX3KWyEOqnZMZSVV66Obio7W/wJ9KWgp2L9BL yt1mFP+Ec3TtAgGd4j7zWFyHp0mamNCG+OztOHT922K4b0NKjuStu80a0QduU95SaxQd PwTNoqd4Hdjzjy+8qrt63qF8/UPWTCFXMbZxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=cXjTI3cSzzxuYcWC/Izw4AxQsp3dyf9Az4oSSJ2rW0BOGydwMoJd40bzuauTufXQB3 YtdZzBE7iEUqLV3pwkeOHbm2eO2CKbTqZODLcODhGzMQXQR2JDAIA2zcRdb+PYI32i0o celIyM8fiWR0FbJFTy96dk+MDdBEroEUzpGko= Received: by 10.213.19.7 with SMTP id y7mr439901eba.23.1294701092045; Mon, 10 Jan 2011 15:11:32 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id v59sm3493469eeh.15.2011.01.10.15.11.28 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 15:11:31 -0800 (PST) Message-ID: <4D2B921D.4000102@gmail.com> Date: Tue, 11 Jan 2011 12:11:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behcet Sarikaya References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> In-Reply-To: <913371.73213.qm@web111411.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:09:19 -0000 On 2011-01-11 12:02, Behcet Sarikaya wrote: > >> I think a different and better approach would be to officially deprecate >> IPv4, declaring it obsolete. That doesn't mean people can't use it, >> but it is the IETF saying that it is past it's used-by date, and people >> should be using IPv6 in preference. I think if the >> inventors/maintainers of IPv4 were to say people should try to avoid >> using IPv4, people will pay more attention than continuing to think >> that it is fine to use IPv4, and IPv6 is an optional feature they can >> compromise on if they need to. There is a bit of psychology in that - >> people generally don't like choosing to use obsolete technologies >> (social proof), and also place significant value on when somebody says >> "I invented it, but don't use it anymore, you'll have >> problems." (authority) >> > > > +1 > > I love this proposal. It would have the immediate implication that the IETF stops work on all IPv4-only specifications (except, presumably, for operational issues including sceurity). Sounds like a plan... Brian From fernando.gont.netbook.win@gmail.com Mon Jan 10 15:41:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88EB23A67B2 for ; Mon, 10 Jan 2011 15:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 2y9dui1AsD9d for ; Mon, 10 Jan 2011 15:41:50 -0800 (PST) Received: from mail-yi0-f66.google.com (mail-yi0-f66.google.com [209.85.218.66]) by core3.amsl.com (Postfix) with ESMTP id 6A0A83A6807 for ; Mon, 10 Jan 2011 15:41:50 -0800 (PST) Received: by yic24 with SMTP id 24so2916603yic.1 for ; Mon, 10 Jan 2011 15:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=jkdaj2D1rEPA+i36ZHnQhha9kEzeDEFBde2M3lXRO0g=; b=bBf8Bz5j3kbQQ+OsRHjYcIP94VSJ0LDwvfMTEp7/QVKU43xWiM3TCjfSKM+H6NKLPF 9k3XzZXWto6UMcfWOrzBzPWJyiYJH3knGyomybGAB4entqdPRKO561r9f5jqF4ChfKLd xdq1LvULUJLP8NHT+qa5xtq8H1kZ4FeNXEgus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=lN6g6jk2++0Tdh4yFWOHS2wm4U2fHGkotpPS/nTIdgP9dClMaqTZtgt7COnup5I5xR Qvu9EdwZgWKFh2j/IepIfDboBuKXLiihcAHANgbCQTNEqDmPXGpmae5wcSgGtMDK7MWC EvJLhdB+WDCQ9TAL1/avibtvPzDdVErfia5rs= Received: by 10.100.110.13 with SMTP id i13mr17125836anc.221.1294703045249; Mon, 10 Jan 2011 15:44:05 -0800 (PST) Received: from [192.168.2.5] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id 17sm22353581anx.13.2011.01.10.15.44.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 15:44:04 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B99BB.9080904@gont.com.ar> Date: Mon, 10 Jan 2011 20:43:55 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Townsley References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> <4D2B6F25.8070502@cisco.com> In-Reply-To: <4D2B6F25.8070502@cisco.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:41:51 -0000 On 10/01/2011 05:42 p.m., Mark Townsley wrote: >> Well, if the firewall is meant to allow only traffic that is deemed as >> necessary, and the organization has not decided to deploy v6... why >> should it be allowed? > > Classic "traffic blocking" measures for v6 can affect v4. For example, > there is a recommendation to block IPv6 over IPv4 tunneling in the NIST > profile as well. Good for them. (this is okay unless the admin really wanted transition traffic in his network) > That of course can be done, but one must understand > that this could cause noticeable timeouts and such for users with > operating systems which automatically try and establish such tunnels. If transition traffic is properly blocked, those host would never be able to configure such tunnels (e.g., Teredo) > So, the enterprise needs to either have the ability to actively turn off > IPv6 on the hosts, or perhaps filter out all AAAAs at the border and be > sure to control the DNS configured in all hosts, etc. in order to avoid > these kinds of problems (or deal with annoyed users and lost > productivity, or hope that happy-eyeballs appears RSN, ...). Users will be usually already be annoyed when experiencing the performance of some transition mechanisms... >> And.. what would be the point of firewalling v4 >> when you could bypass the firewall with v6? > [....] > > Not to say for a moment that there no conceivable ways to breech > security of an IPv6 enabled host for which a firewall might otherwise > provide protection, but I do think there is a difference between setting > up a firewall in front of hosts which already have their own firewalls > vs. those that do not. Yep: the admin is more likely to have control over the organizational firewall rather than over the "personal firewall" on hosts. Not to mention that a typical Windows user will use the Admin account to surf the net, in which case the personal firewall could be trivially disabled by malware. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dragoniz3r@gmail.com Mon Jan 10 16:06:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D2B3A681D for ; Mon, 10 Jan 2011 16:06:38 -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 7LYrps9pBYT7 for ; Mon, 10 Jan 2011 16:06:37 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7FD573A6812 for ; Mon, 10 Jan 2011 16:06:37 -0800 (PST) Received: by wyf23 with SMTP id 23so21029493wyf.31 for ; Mon, 10 Jan 2011 16:08:51 -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=wk+FAhsuYk/07r8BqMyIF1SVR2Pj7x80V/dlXD7XiKw=; b=L0RjWI+XIGlnEKbxzsN9v0e5R76ZR0Ah2v6+xWQbdNfotx3rqC1vWsA6wKRS4QTH1C zACsH8agN+MmUa7tOjDVsk6L10uLQTEobkkLxXSJnuUo1qYqbL3D/Tss/lZUAxvDUbVE xRk6YsyKLEnzm0+ulnWeUO9th8opEbYmHlXbk= 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=M11z8tEYBFTgDGxUIMEOlNaLAIalLOcUNf4JNq+oPK/7mPQZxufLqdepaIWLyrxO+V 3NrNoiqQ2Z4Sl1iUvrB7bRu+Erwlz6ojxFKC8X5/y5pPBcuqI3r3ND4SQRfyFgscHLPp uWUmQeiw+ix4Vx99rJ/EzUJNnrnLvXAwXSuiQ= MIME-Version: 1.0 Received: by 10.216.150.134 with SMTP id z6mr28104754wej.27.1294704531759; Mon, 10 Jan 2011 16:08:51 -0800 (PST) Received: by 10.216.244.131 with HTTP; Mon, 10 Jan 2011 16:08:51 -0800 (PST) In-Reply-To: <913371.73213.qm@web111411.mail.gq1.yahoo.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> Date: Mon, 10 Jan 2011 19:08:51 -0500 Message-ID: From: Josh Rambo To: Behcet Sarikaya Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:06:38 -0000 On Mon, Jan 10, 2011 at 6:02 PM, Behcet Sarikaya wrote: > > >> I think a different and better approach would be to =A0officially deprec= ate >> IPv4, declaring it obsolete. That doesn't mean people =A0can't use it, >> but it is the IETF saying that it is past it's used-by date, =A0and peop= le >> should be using IPv6 in preference. I think if =A0the >> inventors/maintainers of IPv4 were to say people should try to =A0avoid >> using IPv4, people will pay more attention than continuing to =A0think >> that it is fine to use IPv4, and IPv6 is an optional feature they =A0can >> compromise on if they need to. There is a bit of psychology in that =A0- >> people generally don't like choosing to use obsolete =A0technologies >> (social proof), and also place significant value on when =A0somebody say= s >> "I invented it, but don't use it anymore, you'll =A0have >> problems." (authority) >> > > > +1 > > I love this proposal. > I am not in favor of this at all. IPv4 still accounts for 99% of the world's traffic. Declaring it "deprecated" and "obsolete" makes a mockery of the words. IPv4 still has a place. Honestly, I don't think IPv6 has been sufficiently developed to take over from IPv4 in every role, and various softwares and appliances certainly have not. I understand the motivation to put pressure on manufacturers and developers, but I don't think we should pretend that IPv4 won't be necessary to conduct day-to-day business for quite some time now. From lee@asgard.org Mon Jan 10 16:41:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584873A682E for ; Mon, 10 Jan 2011 16:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSwcq2m3CSvX for ; Mon, 10 Jan 2011 16:41:27 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by core3.amsl.com (Postfix) with ESMTP id 34E4A3A6825 for ; Mon, 10 Jan 2011 16:41:27 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0B0hgdG017922 for ; Mon, 10 Jan 2011 19:43:42 -0500 Authentication-Results: cm-omr14 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:63440] helo=HDC00027112) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 32/8D-03534-DB7AB2D4; Mon, 10 Jan 2011 19:43:42 -0500 From: "Lee Howard" To: "'Joe Touch'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> In-Reply-To: <4D2B81B8.70008@isi.edu> Date: Mon, 10 Jan 2011 19:43:41 -0500 Message-ID: <000001cbb128$9826d100$c8747300$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuxEfcx4/VuoFNNTUyOdRIqnLR0DAAEy5qA Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:41:28 -0000 > > Does this language cover the case where a vendor can't implement a > > feature because the IETF hasn't defined it yet? > > Well, if there are such features, then they're clearly going to be an > issue. That needs to be fixed. Well, again in the case of NAT66 (which you haven't argued is a bad example), it isn't needed in the home gateway. Can we not require IPv6 in the home gateway, because NAT66 is not supported? > Sure, you can't expect an implementation to support IPv6 for protocols > that have no IPv6 variant yet. That means we have work to do before we > ought to be jumping up and down expecting everyone to use IPv6, though. You argued that NAT66 was required for presenting a cluster a single address (like a load balancer), just like in IPv4. Can you point me to the RFC defining that behavior? > > It is expected that many existing devices and implementations will > > not be able to support IPv6 for one or more valid technical > > reasons, but for maximum flexibility and compatibility, a best > > effort SHOULD be made to update existing hardware and software to > > enable IPv6 support. > > I don't like this language. It was true for Windows and MacOS previous > to the 2005 IPv6 IETF test, and we saw how that worked out (not). > > IMO, you shouldn't be able to claim IPv6 just by "best effort". There is > no SHOULD, enable or support. There is only "do". I.e., either a system > supports IPv6 - for all IP communications - or not. > > That might be sufficient, if you want different language: > > "A system that supports IPv6 MUST support IPv6 for all > IP communications in the absence of any other version of IP > communications (including IPv4). That system MUST provide > IPv6 communications services to the same or greater > extent than are available for IPv4." We could take this off-list if we're getting too detailed in wordsmithing. Is this not the equivalent of, "IP networking implementations MUST NOT require IPv4 for proper and complete function."? If an implementation is missing required functionality, then it does not have "proper and complete function." If it's missing unrequired functionality, there's no reason to require it. > > and > "All new systems SHOULD support IPv6 as per above. > All existing systems SHOULD support IPv6 as per above > as soon as possible" Not MUST for new systems? > > If that language doesn't work, but you agree with the intended > > statement in the draft, can you propose language that does not > > make the draft dependent on publication of a NAT66 RFC? > > That's one you want to exclude. I'm sure there are others that other > people want to exclude. Any that are excluded *will* (IMO) be an excuse > for not using IPv6. Yes, people can find excuses. Ignorance can be fixed (only stupidity is forever). For clueful people to withhold support for IPv6 because ignorant people think they want ponies doesn't make sense to me. > I would prefer to ensure that IPv6 has the same or greater services than > IPv4, and separately state that: > > "Note that not all IPv4 services are recommended or even defined > in an IPv6-only environment. To the extent that such services > are not meaningful (e.g., NAT66 solely for address space > extension), they are not required by the above." Sounds like a disclaimer. Maybe more wordsmithing, but on this one I understand the intent. Lee > Joe From touch@isi.edu Mon Jan 10 16:47:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7463A684D; Mon, 10 Jan 2011 16:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 XoRm9OqffBuv; Mon, 10 Jan 2011 16:47:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E94583A67ED; Mon, 10 Jan 2011 16:47:31 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0B0nWHe022158 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 16:49:32 -0800 (PST) Message-ID: <4D2BA91A.8040804@isi.edu> Date: Mon, 10 Jan 2011 16:49:30 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lee Howard References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> <000001cbb128$9826d100$c8747300$@org> In-Reply-To: <000001cbb128$9826d100$c8747300$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:47:33 -0000 On 1/10/2011 4:43 PM, Lee Howard wrote: >>> Does this language cover the case where a vendor can't implement a >>> feature because the IETF hasn't defined it yet? >> >> Well, if there are such features, then they're clearly going to be an >> issue. That needs to be fixed. > > Well, again in the case of NAT66 (which you haven't argued is a bad > example), it isn't needed in the home gateway. Can we not require IPv6 > in the home gateway, because NAT66 is not supported? > >> Sure, you can't expect an implementation to support IPv6 for protocols >> that have no IPv6 variant yet. That means we have work to do before we >> ought to be jumping up and down expecting everyone to use IPv6, though. > > You argued that NAT66 was required for presenting a cluster a single > address (like a load balancer), just like in IPv4. Can you point me to the > RFC defining that behavior? That's what it does. Any of the NAT doc defines that behavior. ... >> That might be sufficient, if you want different language: >> >> "A system that supports IPv6 MUST support IPv6 for all >> IP communications in the absence of any other version of IP >> communications (including IPv4). That system MUST provide >> IPv6 communications services to the same or greater >> extent than are available for IPv4." > > We could take this off-list if we're getting too detailed in wordsmithing. > Is this not the equivalent of, "IP networking implementations > MUST NOT require IPv4 for proper and complete function."? That's better. > If an implementation is missing required functionality, then it > does not have "proper and complete function." > If it's missing unrequired functionality, there's no reason to require > it. Agreed. The definition of complete would then be in the eye of the beholder (or consumer)... >> and >> "All new systems SHOULD support IPv6 as per above. >> All existing systems SHOULD support IPv6 as per above >> as soon as possible" > > Not MUST for new systems? Sure, if you prefer. ... >> I would prefer to ensure that IPv6 has the same or greater services than >> IPv4, and separately state that: >> >> "Note that not all IPv4 services are recommended or even defined >> in an IPv6-only environment. To the extent that such services >> are not meaningful (e.g., NAT66 solely for address space >> extension), they are not required by the above." > > Sounds like a disclaimer. Maybe more wordsmithing, but on this > one I understand the intent. You might not need that given the variant you suggested; there's enough wiggle room in "proper" and "complete" being something undefined by the IETF anyway. Joe From brian.e.carpenter@gmail.com Mon Jan 10 17:45:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775093A6901; Mon, 10 Jan 2011 17:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 PPGiYAco41Eq; Mon, 10 Jan 2011 17:45:30 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 787493A68FF; Mon, 10 Jan 2011 17:45:30 -0800 (PST) Received: by vws7 with SMTP id 7so8161693vws.31 for ; Mon, 10 Jan 2011 17:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QtXCOwIgtFy6mqWbeq2wpaF8+oqKjxZP4ZwN0joo9Yk=; b=et/KEmC+1n9140iSC5MsAkK4GDqIKDBhltBFqWcbQlOCvRPQhf1GZDh1xU8ptotP6R LjHmqQPdjaXqkOoVOh4P8wnIe6beT6C3CxiAO+mzCmYtQWjA6lLy4SRWVrBiTqKItUGM 7tU5bb9s9urFx1z9mV+zGLbm3zKQnp3ZCHAr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=byK7ooV4jt6Lo+uRxyylE6y9K91AzrOGN9MrjnotTjYBQOR2eBHRGmqt+nxaw73lwL CulC6462J7JtSTBSyRMU2ceVxgK3K+X56RbIOU1P2j//GVyurh+Lkg4aJPuH8ijuot8X s58AM75trywmaY27yY/IsOchyMAwu1LZFjkSw= Received: by 10.220.175.135 with SMTP id ba7mr8926768vcb.79.1294710465266; Mon, 10 Jan 2011 17:47:45 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k39sm6556884vcr.2.2011.01.10.17.47.42 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 17:47:44 -0800 (PST) Message-ID: <4D2BB6C6.3050104@gmail.com> Date: Tue, 11 Jan 2011 14:47:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> <000001cbb128$9826d100$c8747300$@org> <4D2BA91A.8040804@isi.edu> In-Reply-To: <4D2BA91A.8040804@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org, 'IPv6 Operations' Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 01:45:31 -0000 On 2011-01-11 13:49, Joe Touch wrote: > > > On 1/10/2011 4:43 PM, Lee Howard wrote: >>>> Does this language cover the case where a vendor can't implement a >>>> feature because the IETF hasn't defined it yet? >>> >>> Well, if there are such features, then they're clearly going to be an >>> issue. That needs to be fixed. >> >> Well, again in the case of NAT66 (which you haven't argued is a bad >> example), it isn't needed in the home gateway. Can we not require IPv6 >> in the home gateway, because NAT66 is not supported? >> >>> Sure, you can't expect an implementation to support IPv6 for protocols >>> that have no IPv6 variant yet. That means we have work to do before we >>> ought to be jumping up and down expecting everyone to use IPv6, though. >> >> You argued that NAT66 was required for presenting a cluster a single >> address (like a load balancer), just like in IPv4. Can you point me >> to the >> RFC defining that behavior? > > That's what it does. Any of the NAT doc defines that behavior. I don't think so, if you're trying to load-balance traffic to and from Port 80. Stateful NAPT can't do this. And as I already said, such usage is patented. https://datatracker.ietf.org/ipr/208/ Brian From ek@google.com Mon Jan 10 19:09:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2BF28C211 for ; Mon, 10 Jan 2011 19:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.841 X-Spam-Level: X-Spam-Status: No, score=-105.841 tagged_above=-999 required=5 tests=[AWL=-2.864, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 JDSd17hziwQB for ; Mon, 10 Jan 2011 19:09:26 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8380528C20D for ; Mon, 10 Jan 2011 19:09:26 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p0B3Bede024662 for ; Mon, 10 Jan 2011 19:11:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294715501; bh=i5udMWOfcoFrZx8P71rqGm7frb4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XCQd30Vd0yTYGWMaw/jFoMhlWi5xmEr5ombuJE6Du4ghZ01OfTRS6s2v5gCmmAmUg r9Oj3S0lusMwthwRGpCBA== Received: from qyj19 (qyj19.prod.google.com [10.241.83.83]) by kpbe19.cbf.corp.google.com with ESMTP id p0B3BcWl027438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Jan 2011 19:11:39 -0800 Received: by qyj19 with SMTP id 19so21088926qyj.3 for ; Mon, 10 Jan 2011 19:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M/P/bQ4WIxxO78ZZ0gps8KOooLajQWHxk7oSCYbUXSA=; b=oHOeohiYkv9idPyRvN05MJlzcQhH3TROVueDgkMPJl2U/6Q48JLWSxz3GSjO7cb5mS aoOhJVxdzEbpQMHvIMQw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a4z+ropuzk18pvMJymNgbVD+MBcUPyQB3yMP9c0QTgeJhk/vDmpkI6FSWnO/h2EmXL oU5rfo8BXFr8FVBjFxFw== MIME-Version: 1.0 Received: by 10.229.213.80 with SMTP id gv16mr7914801qcb.181.1294715498612; Mon, 10 Jan 2011 19:11:38 -0800 (PST) Received: by 10.229.106.201 with HTTP; Mon, 10 Jan 2011 19:11:38 -0800 (PST) In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> Date: Tue, 11 Jan 2011 03:11:38 +0000 Message-ID: From: Erik Kline To: Josh Rambo Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 03:09:27 -0000 >> +1 >> >> I love this proposal. >> > > I am not in favor of this at all. IPv4 still accounts for 99% of the > world's traffic. Declaring it "deprecated" and "obsolete" makes a > mockery of the words. IPv4 still has a place. Honestly, I don't think > IPv6 has been sufficiently developed to take over from IPv4 in every > role, and various softwares and appliances certainly have not. I think the proper term would be "historic". +1 to marking IPv4 historic, if it hasn't been already From fred@cisco.com Mon Jan 10 21:13:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146BB28C260; Mon, 10 Jan 2011 21:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 bCyQHf9FWpID; Mon, 10 Jan 2011 21:13:01 -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 5736228C20D; Mon, 10 Jan 2011 21:13:01 -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: AvsEAKt1K02rR7Ht/2dsb2JhbACkOHOiS5hwhUwEhGeGI4Mg Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2011 05:15:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0B5FBM0014792; Tue, 11 Jan 2011 05:15:16 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 10 Jan 2011 21:15:17 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 10 Jan 2011 21:15:17 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <000001cbb128$9826d100$c8747300$@org> Date: Mon, 10 Jan 2011 21:15:01 -0800 Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> <000001cbb128$9826d100$c8747300$@org> To: "Lee Howard" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Operations' , int-area@ietf.org, 'Joe Touch' Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 05:13:02 -0000 On Jan 10, 2011, at 4:43 PM, Lee Howard wrote: > You argued that NAT66 was required for presenting a cluster a single > address (like a load balancer), just like in IPv4. Can you point me = to the > RFC defining that behavior? I can show you an internet draft. It doesn't use a single address; it is = prefix translation. But it does have the unfortunate term "nat66" in its = moniker. http://tools.ietf.org/html/draft-mrw-nat66 "IPv6-to-IPv6 Network Prefix Translation", Margaret Wasserman, Fred Baker, 4-Jan-11= From lee.howard@twcable.com Mon Jan 10 16:57:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8348A3A6835; Mon, 10 Jan 2011 16:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 M5SLpD16dV3k; Mon, 10 Jan 2011 16:57:20 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id 04C763A67D6; Mon, 10 Jan 2011 16:57:19 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.60,303,1291611600"; d="scan'208";a="165994861" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 10 Jan 2011 19:59:46 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 10 Jan 2011 19:59:34 -0500 From: "Howard, Lee" To: Mark Smith , "George, Wes E [NTK]" Date: Mon, 10 Jan 2011 19:59:33 -0500 Thread-Topic: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AcuxC3/rsWoU8AoNQcqSpDOWTI/8EAAHejXg Message-ID: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> In-Reply-To: <20110111074511.022d29bf@opy.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Jan 2011 21:20:59 -0800 Cc: "v6ops@ietf.org" , "int-area@ietf.org" , Christopher LILJENSTOLPE Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:57:23 -0000 > -----Original Message----- > From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.or= g] > Sent: Monday, January 10, 2011 4:15 PM > I don't think I really agree with the root cause. IPv6 doesn't exist in > equipment because customers, or representatives of customers (e.g ISPs > for CPE) haven't made it a "must have", and refused to buy the equipment > when it doesn't support IPv6.=20 What about ISPs who don't buy CPE? =20 Retail stores in the U.S. make a lot of money selling gateways to retail customers. Consumers get more choice of what gateway they want to buy. Surely we don't expect consumers to provide CPE requirements? That's why we wrote cpe-router. > I think a different and better approach would be to officially deprecate > IPv4, declaring it obsolete.=20 I've been thinking about writing that draft (it sounds really good on the last day of IETF, over beers). =20 After the recent thread on "Old transport-layer protocols to Historic" I'm confused about what the right word would be. The list of=20 dependent RFCs would be long, and it might make an interesting career for someone to submit new drafts to obsolete all of the then-deprecated drafts. But I'll write it if you want. Lee From joelja@bogus.com Mon Jan 10 21:50:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CBF83A6992 for ; Mon, 10 Jan 2011 21:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.051 X-Spam-Level: X-Spam-Status: No, score=-102.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ybhZ-V0MtPYX for ; Mon, 10 Jan 2011 21:50:51 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4C7B33A698D for ; Mon, 10 Jan 2011 21:50:51 -0800 (PST) Received: from 58b035843c84.netpoint.com ([213.221.117.228]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0B5r1VL076487 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 11 Jan 2011 05:53:04 GMT (envelope-from joelja@bogus.com) Message-ID: <4D2BF038.9070703@bogus.com> Date: Tue, 11 Jan 2011 06:52:56 +0100 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 05:50:52 -0000 On 1/10/11 9:39 AM, Fred Baker wrote: > Question for the assembled throng: What do people want to see happen > in draft-ietf-v6ops-v6-aaaa-whitelisting-implications? my impression is that it's probably ready for last call. > We had a reasonable discussion on this at IETF 79, and people seemed > pretty supportive. Does it need updates? What comments do people have? > > Comments to the list, please. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gnakibly@yahoo.com Mon Jan 10 22:58:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B4C3A69B6 for ; Mon, 10 Jan 2011 22:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 doQC3CnK4Uf0 for ; Mon, 10 Jan 2011 22:58:53 -0800 (PST) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by core3.amsl.com (Postfix) with SMTP id 5A07F3A6765 for ; Mon, 10 Jan 2011 22:58:53 -0800 (PST) Received: from [98.139.91.69] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 07:01:06 -0000 Received: from [98.139.91.14] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 07:01:06 -0000 Received: from [127.0.0.1] by omp1014.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 07:01:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 680284.49090.bm@omp1014.mail.sp2.yahoo.com Received: (qmail 22292 invoked by uid 60001); 11 Jan 2011 07:01:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294729266; bh=4ced6VJ3oFs4Mj+hetTKTVvBoiRxuYc4T1a+2jAngEk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4bghC8pwzZXy1xQnGSvPYQCIEEbCtnToXbF1q3C8Em0zggYLB+0tCKL9DV1hmUwf8XCeYrPXr/D83OyFk6gKnlwrJiKodGRpdQGMhaLNB71t0+41AFtzshlCf3YIlTjkqPwUXlzcUaenU5T28i8cHlqUExjvX9ZsdCfPgZsGxN4= 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:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=p0+jjWQaNSqta/LMaVG7A8Lg5oiRcrOHkOrziF9t0nLZZ+sn1FwClSeB8/Bgg4JFBv47f1C5sDDxn7uGKx/z8dg1QJKdht3h2qfih/DWhDxTopCa77OIg0uuiHBOxp7okVbniPK2xHnjS4V8u4gR6na53JgN1cKMJL6M8+QAZfA=; Message-ID: <404191.21335.qm@web45506.mail.sp1.yahoo.com> X-YMail-OSG: P3SYrxsVM1mhw9Y.x.4K6omJCA6vysQc8je22sEG8EuzE28 Zp4eQMJVwbu0F6OEVsRLloXnKYJOHQLoXOvKOwc882BlyXTrMF6hnuTaBKmV NOhzcjrqd_fL3NAjU8YPIWjCT6OkHz1e6aSbEnU34PgGRv0PWsxatcQj325D fgwEgBW0ptdQAQFF5H5xzJOuY5anc1hLWm312lX24t8bDjt3i1DIV4UztxTB 2FKHwfFDECkyumkOSmrITz17EcN6gMUc3cCzSqeM_S_bIaqAUeve_vL1A7jh vo7sgGc_SxTnf60jGeKLD Received: from [93.172.151.94] by web45506.mail.sp1.yahoo.com via HTTP; Mon, 10 Jan 2011 23:01:06 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <4D1A59F2.4010606@joelhalpern.com> <723770.66310.qm@web56706.mail.re3.yahoo.com> <4D277C6D.5040708@joelhalpern.com> <615031.74637.qm@web56701.mail.re3.yahoo.com> <4D279750.5090300@joelhalpern.com> Date: Mon, 10 Jan 2011 23:01:06 -0800 (PST) From: Gabi Nakibly To: "Joel M. Halpern" , Fred Templin In-Reply-To: <4D279750.5090300@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mary Barnes , IPv6 Operations , draft-ietf-v6ops-tunnel-loops@tools.ietf.org, gen-art@ietf.org Subject: Re: [v6ops] [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 06:58:56 -0000 Hi Joel,=0A=0AWe are in agreement regarding the 6rd issue. Indeed, in pract= ice this specific =0Ameasure can not handle 6rd. We only suggested the conf= iguration option=A0so the =0Adraft=A0will be complete. Nonetheless, we thin= k that this measure is useful in =0Aother cases such as=A0ISATAP and especi= ally 6to4. So we think it still has a place =0A=0Ain the draft. =0A=0AThis = mitigation measure has some=A0drawbacks which are explicitly described in t= he =0A=0Adraft.=A0We can make the wording on the 6rd=A0drawback stronger an= d drop the =0Aconfiguration suggestion, if this=A0will make you feel more c= omfortable.=A0=0A=0AGabi=0A=0A=0A=0A=0A----- Original Message ----=0A> From= : Joel M. Halpern =0A> To: Fred Templin =0A> Cc: IPv6 Operations ; =0A>draft-ietf-v6ops-tunn= el-loops@tools.ietf.org; gen-art@ietf.org; Mary Barnes =0A>=0A> Sent: Sat, January 8, 2011 12:44:32 AM=0A> Subject: Re: [v= 6ops] [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt=0A> =0A> I am = sorry, but what you have just said translates to me as=0A> 1) This proposal= can not handle 6rd=0A> 2) It is a heuristic, with decent odds, for this to= avoid false =0A> positives on other schemes, such as ISATAP, since most of= these =0A> techniques are not designed to allow an arbitrary device elsewh= ere in =0A> the net to detect and accurately extract the IPv4 address from = the =0A> embedding.=0A> =0A> Russ may decide it is acceptable, but from whe= re I sit this does not =0A> represent solving the problem.=A0 Advising folk= s to configure every 6rd =0A> prefix in use anywhere is simply not acceptab= le.=0A> =0A> Yours,=0A> Joel=0A> =0A> On 1/7/2011 5:19 PM, Fred Templin wro= te:=0A> > Hi Joel,=0A> >=0A> > In response to your questions below, 6rd can= only be handled by explicit=0A> > configuration of known 6rd prefixes. As = you indeed mention, there is no=0A> > meaningful rule that captures all 6rd= prefixes. Regarding ISATAP, indeed=0A> > there is a chance of 2^-32 that a= non-ISATAP address will be recognized=0A> > as an ISATAP-address. In this = case, an erroneous drop will occur only if=0A> > the lower 32 bits of the I= ID will be equal to the IP address of the=0A> > current host.=0A> > The cha= nce of that happening is 2^-32, if the IID is random. This means that=0A> >= an erroneous drop will occur with a chance of 2^-64, which is very slim=0A= > > (albeit possible).=0A> >=0A> > Fred and Gabi=0A> >=0A> > *From:* Joel M= . Halpern =0A> > *To:* Fred Templin =0A> > *Cc:* Mary Barnes ; gen-art@ietf.org;= Joel=0A> > Jaeggli ; Ron Bonica ;= =0A> > draft-ietf-v6ops-tunnel-loops@tools.ietf.org; IPv6 Operations=0A> > = =0A> > *Sent:* Fri, January 7, 2011 12:49:49 PM=0A> > *= Subject:* Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt=0A> >= =0A> > I do not see how 6rd can be handled. There is not really any meaning= ful=0A> > "domain" to use to figure out who is using what 6rd prefix.=0A> >= =0A> > And what token does ISATAP use? I presume that I missed something wh= en=0A> > the only token I could find was in the lower 64 bits (and tehrefor= e=0A> > could be accidentally duplicated elsewhere.=0A> >=0A> > Thanks,=0A>= > Joel=0A> >=0A> > On 1/7/2011 3:43 PM, Fred Templin wrote:=0A> >=A0 > Hi = Joel,=0A> >=A0 >=0A> >=A0 > Thank you for your time in reviewing this work.= In Section 3.1, under=0A> >=A0 > this proposed=0A> >=A0 > mitigation the t= unnel router ideally indeed must check for all=0A> >=A0 > encapsulation for= mats in=0A> >=A0 > which an IPv4 address may be embedded within an IPv6 add= ress. This means=0A> >=A0 > that=0A> >=A0 > the router must check for all k= nown protocol-41 encapsulation formats=0A> >=A0 > and must be=0A> >=A0 > mo= dified to check for any new formats should new ones be specified. In=0A> >= =A0 > practice, if=0A> >=A0 > a router is configured to check only a subset= of encapsulation formats,=0A> >=A0 > then it will be=0A> >=A0 > immune onl= y to attacks in which the attacker uses the configured=0A> >=A0 > encapsula= tion=0A> >=A0 > formats in the source/destination address of the attack pac= ket.=0A> >=A0 >=0A> >=A0 > Certain IPv6 address formats (e.g., 6to4, ISATAP= , etc.) include a=0A> > well-known=0A> >=A0 > "token" indicating that an IP= v4 address is embedded. Other formats=0A> >=A0 > (e.g., 6rd)=0A> >=A0 > do = not include such a token and hence would require special=0A> > configuratio= n at=0A> >=A0 > the router to indicate which IPv6 prefixes within the routi= ng domain are=0A> >=A0 > 6rd ones.=0A> >=A0 >=0A> >=A0 > Do you feel there = are any additional clarifications on this needed=0A> >=A0 > beyond what=0A>= >=A0 > already appears in Section 3.1?=0A> >=A0 >=0A> >=A0 > Fred and Gabi= =0A> >=A0 >=0A> >=A0 > *From:* Joel M. Halpern > <= mailto:jmh@joelhalpern.com>>=0A> >=A0 > *To:* Mary Barnes > >=0A> >=A0 > *Cc:* gen-= art@ietf.org ; Joel Jaeggli=0A> > >; Ron Bonica=0A> >=A0 > >;=0A> > draft-ietf-v6ops-tunnel-loops@tools.ietf= .org=0A> > ;=0A> >=A0 = > IPv6 Operations >=0A> >=A0= > *Sent:* Tue, December 28, 2010 1:43:14 PM=0A> >=A0 > *Subject:* [Gen-art= ] review: draft-ietf-v6ops-tunnel-loops-01.txt=0A> >=A0 >=0A> >=A0 > I am t= he assigned Gen-ART reviewer for this draft. For background on=0A> >=A0 > G= en-ART, please see the FAQ at=0A> >>=A0 .=0A> >=A0 >=0A> >=A0 > Please resolve these comments= along with any other Last Call comments=0A> >=A0 > you may receive.=0A> >= =A0 >=0A> >=A0 > Document: draft-ietf-v6ops-tunnel-loops-01.txt=0A> >=A0 > = Routing Loop Attack using IPv6 Automatic Tunnels:=0A> >=A0 > Problem Statem= ent and Proposed Mitigations=0A> >=A0 > Reviewer: Joel M. Halpern=0A> >=A0 = > Review Date: 28-Dec-2010=0A> >=A0 > IETF LC End Date: 29-Dec-2010=0A> >= =A0 > IESG Telechat date: 06-Jan-2011)=0A> >=A0 >=0A> >=A0 > Summary: Nearl= y ready for publication as an Informational RFC=0A> >=A0 >=0A> >=A0 > Major= issues: It is unclear in the document what assumptions section 3.1=0A> >= =A0 > makes about the relationship between supported tunnels and checked=0A= > >=A0 > embedded addresses. Is there an assumption that the router only ha= s to=0A> >=A0 > check for addresses in the format and prefix it supports? I= hope so.=0A> >=A0 > Otherwise, a router seems to be expected to look at an= arbitrary IPv6=0A> >=A0 > addresses, guess whether it has an embedded IPv4= addresses, and perform=0A> >=A0 > filter checks on that guessed addresses = against its own addresses.=0A> >=A0 > If indeed their is a relationship, th= en it would really help if section=0A> >=A0 > 3.1 said that.=0A> >=A0 > Unf= ortunately, I am afraid no such relationship is assumed. If not, I=0A> >=A0= > would like to see significantly better explanation of how the router is= =0A> >=A0 > to reliably know that there is a 6rd or ISATAP address embedded= in the=0A> >=A0 > v6 address.=0A> >=A0 >=0A> >=A0 > Minor issues:=0A> >=A0= >=0A> >=A0 > Nits/editorial comments:=0A> ________________________________= _______________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.i= etf.org/mailman/listinfo/v6ops=0A> =0A=0A=0A From fred@cisco.com Tue Jan 11 00:35:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC643A6A1D for ; Tue, 11 Jan 2011 00:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 fCUIwNgPmzcN for ; Tue, 11 Jan 2011 00:35:44 -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 DB5AE3A6A1B for ; Tue, 11 Jan 2011 00:35:44 -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: AtYFAD+lK02rR7Ht/2dsb2JhbACWJo4Qc6I/mHSFTASEaIYmgyA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 11 Jan 2011 08:38:01 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0B8bBG1013752 for ; Tue, 11 Jan 2011 08:38:01 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 11 Jan 2011 00:38:01 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 11 Jan 2011 00:38:01 -0800 From: Fred Baker Date: Tue, 11 Jan 2011 00:38:00 -0800 Message-Id: <21C4C296-601B-4E11-A629-0EE87C8F9018@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] draft-ietf-v6ops-v4v6tran-framework - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:35:45 -0000 Another question for the assembled throng: What do people want to see = happen in draft-ietf-v6ops-v4v6tran-framework? This came out of the v4v6tran effort. There seemed to be a fair support = for the draft. What needs to happen with it? Comments to the list, please.= From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 11 00:56:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AB23A6A1D; Tue, 11 Jan 2011 00:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 m8g5sB4C48TA; Tue, 11 Jan 2011 00:56:33 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 859203A63EB; Tue, 11 Jan 2011 00:56:33 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pca3u-00017I-Ng; Tue, 11 Jan 2011 19:28:42 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 78A9A3B335; Tue, 11 Jan 2011 19:28:41 +1030 (CST) Date: Tue, 11 Jan 2011 19:28:41 +1030 From: Mark Smith To: "Howard, Lee" Message-ID: <20110111192841.1022911e@opy.nosense.org> In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" , "v6ops@ietf.org" , LILJENSTOLPE , Christopher Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:56:34 -0000 Hi Lee, On Mon, 10 Jan 2011 19:59:33 -0500 "Howard, Lee" wrote: > > -----Original Message----- > > From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] > > Sent: Monday, January 10, 2011 4:15 PM > > I don't think I really agree with the root cause. IPv6 doesn't exist in > > equipment because customers, or representatives of customers (e.g ISPs > > for CPE) haven't made it a "must have", and refused to buy the equipment > > when it doesn't support IPv6. > > What about ISPs who don't buy CPE? > Retail stores in the U.S. make a lot of money selling gateways to retail > customers. Consumers get more choice of what gateway they want to > buy. Surely we don't expect consumers to provide CPE requirements? > That's why we wrote cpe-router. I'm all for that draft, and want to see it published as soon as it can be. The shame if it is though that it wasn't written and published 5 or more years ago. Right when we need to be deploying (or trying to convince customers to buy and deploy) IPv6 capable residential CPE at a rapid pace, only months before IANA run out of IPv4 addresses, and probably no more than 12 to 18 months before ISPs run out of IPv4 addresses, very little of it exists. LSN/CGN might stretch the deployment period we have available, but I think it is going to get really ugly operationally behind the scenes at ISPs. > > > I think a different and better approach would be to officially deprecate > > IPv4, declaring it obsolete. > > I've been thinking about writing that draft (it sounds really good on the > last day of IETF, over beers). > > After the recent thread on "Old transport-layer protocols to Historic" > I'm confused about what the right word would be. The list of > dependent RFCs would be long, and it might make an interesting career > for someone to submit new drafts to obsolete all of the then-deprecated > drafts. > > But I'll write it if you want. > I think there would be a lot of symbolic value in it. If people don't have an interest in the details, symbolic gestures, without resorting to FUD, can be effective in influencing people's buying choices. Regards, Mark. From gert@space.net Tue Jan 11 01:01:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019063A6A13 for ; Tue, 11 Jan 2011 01:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 xZoAf9o651SV for ; Tue, 11 Jan 2011 01:01:51 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id D3AE63A63EB for ; Tue, 11 Jan 2011 01:01:50 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 91DC4F8182 for ; Tue, 11 Jan 2011 10:04:05 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 60524F816A for ; Tue, 11 Jan 2011 10:04:05 +0100 (CET) Received: (qmail 97955 invoked by uid 1007); 11 Jan 2011 10:04:05 +0100 Date: Tue, 11 Jan 2011 10:04:05 +0100 From: Gert Doering To: Erik Kline Message-ID: <20110111090405.GO3695@Space.Net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:01:52 -0000 Hi, On Tue, Jan 11, 2011 at 03:11:38AM +0000, Erik Kline wrote: > +1 to marking IPv4 historic, if it hasn't been already +1 ("People still use RIPv1, but it's still marked historic for good reasons") Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From remi.despres@free.fr Tue Jan 11 02:52:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9586728C114; Tue, 11 Jan 2011 02:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_50=0.001, 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 6Qzd3BLd2OFs; Tue, 11 Jan 2011 02:52:09 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id D0F0B28C275; Tue, 11 Jan 2011 02:52:07 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id DE1167000342; Tue, 11 Jan 2011 11:54:23 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id AD1277000339; Tue, 11 Jan 2011 11:54:23 +0100 (CET) X-SFR-UUID: 20110111105423708.AD1277000339@msfrf2118.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: <4D2B3928.8050508@gont.com.ar> Date: Tue, 11 Jan 2011 11:54:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F9EDE1C-BA6C-4DB0-8756-F725B318F4BE@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1082) Cc: Internet Area , IPv6 Operations Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 10:52:10 -0000 Le 10 janv. 2011 =E0 17:51, Fernando Gont a =E9crit : > ... My take is that NAT66 *will* be deployed. For clarification, which NAT66 do you have in mind? - stateful NAPTv6? - stateless NPTv6? - both? > -- So, I don't think you can rely IPv6 on > restoring "address transparency". IMHO, at least some customers will insist on having address = transparency. These customers will need ways to avoid NAT66's (but, of course, without = having to sacrifice any FW function for this). Regards, RD From remi.despres@free.fr Tue Jan 11 03:15:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0146728C100; Tue, 11 Jan 2011 03:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.520, 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 bu-nJZskeK4C; Tue, 11 Jan 2011 03:15:42 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF0F28C26F; Tue, 11 Jan 2011 03:15:42 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 35C0B7000342; Tue, 11 Jan 2011 12:17:58 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id B94557000340; Tue, 11 Jan 2011 12:17:57 +0100 (CET) X-SFR-UUID: 20110111111757758.B94557000340@msfrf2118.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: <20110110.224735.41641090.sthaug@nethelp.no> Date: Tue, 11 Jan 2011 12:17:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> To: Steinar Haug X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, int-area@ietf.org Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 11:15:43 -0000 Le 10 janv. 2011 =E0 22:47, sthaug@nethelp.no a =E9crit : >>> UDP encapsulation of IPsec is a work around, specifically to get = around >>> the problems of lack of IPv4 address transparency i.e. NAT. It isn't = an >>> acceptable answer when NAT doesn't need to exist. >>=20 >> You're assuming that the only motivation to have NATs is address >> exhaustion -- but IMO, it isn't. >=20 > Provider independence is a huge motivation. Agreed. That's why, IMHO, it should be more useful to look for solutions that = combine provider independence with address transparency, than accepting = without effort to sacrifice address transparency for provider = independence. Although I know some readers don't like my repeating that I worked on = such a solution, this is IMHO relevant to the point being discussed. Ref: www.ietf.org/id/draft-despres-softwire-sam-01, in particular sec. = 3.3. (As this draft is about to expire, I should work in some future on a = revised version.)=20 Regards, RD From tjc@ecs.soton.ac.uk Tue Jan 11 04:07:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F0C28C0F0 for ; Tue, 11 Jan 2011 04:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD2Lc1mWZUMO for ; Tue, 11 Jan 2011 04:07:05 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 28A9B28C273 for ; Tue, 11 Jan 2011 04:07:04 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p0BC9GhK030195 for ; Tue, 11 Jan 2011 12:09:16 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p0BC9GhK030195 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1294747756; bh=Ypc0bKJ0J9j5HhPL9HCfVb/GREQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=gy1i8Y6cBb4CWHOAemHjf0QxdRr/+0DRoIJrHluCoAE3WB3sS2MnHjyxmfrB7kRr9 b9q3Ibykv5KBtYI4Z+goFX/98DVH3YKJkN3DHa6V1xYydvrRcdYLRvYxU89DncEm7j muqEJSFO4swZJ7Pc/Or0U4TK1vNR/u9jEDuRaKxY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n0AC9G2308224798g0 ret-id none; Tue, 11 Jan 2011 12:09:16 +0000 Received: from dhcp-152-78-94-255.ecs.soton.ac.uk (dhcp-152-78-94-255.ecs.soton.ac.uk [152.78.94.255]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p0BC9EmO010328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jan 2011 12:09:14 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Tim Chown In-Reply-To: <4D2B921D.4000102@gmail.com> Date: Tue, 11 Jan 2011 12:09:13 +0000 Content-Transfer-Encoding: 7bit Message-ID: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> <4D2B921D.4000102@gmail.com> <235B67C9-D15B-42B8-9FCD-351C95A6AF48@ecs.soton.ac.uk> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n0AC9G230822479800; tid=n0AC9G2308224798g0; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p0BC9GhK030195 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 12:07:06 -0000 On 10 Jan 2011, at 23:11, Brian E Carpenter wrote: > > It would have the immediate implication that the IETF stops work > on all IPv4-only specifications (except, presumably, for > operational issues including sceurity). Sounds like a plan... How much IPv4-only work is happening? Tim From remi.despres@free.fr Tue Jan 11 05:36:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B37B28C148 for ; Tue, 11 Jan 2011 05:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_05=-1.11, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 FJmNxjko43jQ for ; Tue, 11 Jan 2011 05:36:45 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by core3.amsl.com (Postfix) with ESMTP id 50B6328C298 for ; Tue, 11 Jan 2011 05:36:45 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 368B97000084; Tue, 11 Jan 2011 14:39:01 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id C8C1D700008D; Tue, 11 Jan 2011 14:39:00 +0100 (CET) X-SFR-UUID: 20110111133900822.C8C1D700008D@msfrf2416.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: <913371.73213.qm@web111411.mail.gq1.yahoo.com> Date: Tue, 11 Jan 2011 14:38:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35B5BBF2-1079-42EA-B81E-E29454A71170@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 13:36:46 -0000 Hi Behcet, -1 (I am afraid I have to seriously disagree) The important is to ENABLE IPv6, not to disable IPv4 (for what it does = which, despite its NATs hacks etc., still has great value. Any impression that enabling IPv6 might go with losing some IPv4 = connectivity is an IPv6 deterrent. Dual-stack service remains the most pragmatic approach for IPv6 to be = welcome (which is badly needed). Regards, RD=20 Le 11 janv. 2011 =E0 00:02, Behcet Sarikaya a =E9crit : >=20 >=20 >> I think a different and better approach would be to officially = deprecate >> IPv4, declaring it obsolete. That doesn't mean people can't use it, >> but it is the IETF saying that it is past it's used-by date, and = people >> should be using IPv6 in preference. I think if the >> inventors/maintainers of IPv4 were to say people should try to avoid >> using IPv4, people will pay more attention than continuing to think >> that it is fine to use IPv4, and IPv6 is an optional feature they = can >> compromise on if they need to. There is a bit of psychology in that = - >> people generally don't like choosing to use obsolete technologies >> (social proof), and also place significant value on when somebody = says >> "I invented it, but don't use it anymore, you'll have >> problems." (authority) >>=20 >=20 >=20 > +1 >=20 > I love this proposal. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jmh@joelhalpern.com Tue Jan 11 05:46:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04FC28C2A1; Tue, 11 Jan 2011 05:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.791 X-Spam-Level: X-Spam-Status: No, score=-102.791 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 tHS8GwGi7ygL; Tue, 11 Jan 2011 05:46:48 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BA2FB28C14B; Tue, 11 Jan 2011 05:46:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A28D24300DF; Tue, 11 Jan 2011 05:49:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-169.clppva.btas.verizon.net [71.161.51.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 216084300CD; Tue, 11 Jan 2011 05:49:04 -0800 (PST) Message-ID: <4D2C5FCB.8010600@joelhalpern.com> Date: Tue, 11 Jan 2011 08:48:59 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gabi Nakibly References: <4D1A59F2.4010606@joelhalpern.com> <723770.66310.qm@web56706.mail.re3.yahoo.com> <4D277C6D.5040708@joelhalpern.com> <615031.74637.qm@web56701.mail.re3.yahoo.com> <4D279750.5090300@joelhalpern.com> <404191.21335.qm@web45506.mail.sp1.yahoo.com> In-Reply-To: <404191.21335.qm@web45506.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mary Barnes , IPv6 Operations , Fred Templin , draft-ietf-v6ops-tunnel-loops@tools.ietf.org, gen-art@ietf.org Subject: Re: [v6ops] [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 13:46:50 -0000 Yes, I think that the drawback needs to be stated more clearly and thus this choice removed from the recommendations. Thank you, Joel On 1/11/2011 2:01 AM, Gabi Nakibly wrote: > Hi Joel, > > We are in agreement regarding the 6rd issue. Indeed, in practice this specific > measure can not handle 6rd. We only suggested the configuration option so the > draft will be complete. Nonetheless, we think that this measure is useful in > other cases such as ISATAP and especially 6to4. So we think it still has a place > > in the draft. > > This mitigation measure has some drawbacks which are explicitly described in the > > draft. We can make the wording on the 6rd drawback stronger and drop the > configuration suggestion, if this will make you feel more comfortable. > > Gabi > > > > > ----- Original Message ---- >> From: Joel M. Halpern >> To: Fred Templin >> Cc: IPv6 Operations; >> draft-ietf-v6ops-tunnel-loops@tools.ietf.org; gen-art@ietf.org; Mary Barnes >> >> Sent: Sat, January 8, 2011 12:44:32 AM >> Subject: Re: [v6ops] [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt >> >> I am sorry, but what you have just said translates to me as >> 1) This proposal can not handle 6rd >> 2) It is a heuristic, with decent odds, for this to avoid false >> positives on other schemes, such as ISATAP, since most of these >> techniques are not designed to allow an arbitrary device elsewhere in >> the net to detect and accurately extract the IPv4 address from the >> embedding. >> >> Russ may decide it is acceptable, but from where I sit this does not >> represent solving the problem. Advising folks to configure every 6rd >> prefix in use anywhere is simply not acceptable. >> >> Yours, >> Joel >> >> On 1/7/2011 5:19 PM, Fred Templin wrote: >>> Hi Joel, >>> >>> In response to your questions below, 6rd can only be handled by explicit >>> configuration of known 6rd prefixes. As you indeed mention, there is no >>> meaningful rule that captures all 6rd prefixes. Regarding ISATAP, indeed >>> there is a chance of 2^-32 that a non-ISATAP address will be recognized >>> as an ISATAP-address. In this case, an erroneous drop will occur only if >>> the lower 32 bits of the IID will be equal to the IP address of the >>> current host. >>> The chance of that happening is 2^-32, if the IID is random. This means that >>> an erroneous drop will occur with a chance of 2^-64, which is very slim >>> (albeit possible). >>> >>> Fred and Gabi >>> >>> *From:* Joel M. Halpern >>> *To:* Fred Templin >>> *Cc:* Mary Barnes; gen-art@ietf.org; Joel >>> Jaeggli; Ron Bonica; >>> draft-ietf-v6ops-tunnel-loops@tools.ietf.org; IPv6 Operations >>> >>> *Sent:* Fri, January 7, 2011 12:49:49 PM >>> *Subject:* Re: [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt >>> >>> I do not see how 6rd can be handled. There is not really any meaningful >>> "domain" to use to figure out who is using what 6rd prefix. >>> >>> And what token does ISATAP use? I presume that I missed something when >>> the only token I could find was in the lower 64 bits (and tehrefore >>> could be accidentally duplicated elsewhere. >>> >>> Thanks, >>> Joel >>> >>> On 1/7/2011 3:43 PM, Fred Templin wrote: >>> > Hi Joel, >>> > >>> > Thank you for your time in reviewing this work. In Section 3.1, under >>> > this proposed >>> > mitigation the tunnel router ideally indeed must check for all >>> > encapsulation formats in >>> > which an IPv4 address may be embedded within an IPv6 address. This means >>> > that >>> > the router must check for all known protocol-41 encapsulation formats >>> > and must be >>> > modified to check for any new formats should new ones be specified. In >>> > practice, if >>> > a router is configured to check only a subset of encapsulation formats, >>> > then it will be >>> > immune only to attacks in which the attacker uses the configured >>> > encapsulation >>> > formats in the source/destination address of the attack packet. >>> > >>> > Certain IPv6 address formats (e.g., 6to4, ISATAP, etc.) include a >>> well-known >>> > "token" indicating that an IPv4 address is embedded. Other formats >>> > (e.g., 6rd) >>> > do not include such a token and hence would require special >>> configuration at >>> > the router to indicate which IPv6 prefixes within the routing domain are >>> > 6rd ones. >>> > >>> > Do you feel there are any additional clarifications on this needed >>> > beyond what >>> > already appears in Section 3.1? >>> > >>> > Fred and Gabi >>> > >>> > *From:* Joel M. Halpern>> > >>> > *To:* Mary Barnes>> > >>> > *Cc:* gen-art@ietf.org; Joel Jaeggli >>> >; Ron Bonica >>> > >; >>> draft-ietf-v6ops-tunnel-loops@tools.ietf.org >>> ; >>> > IPv6 Operations> >>> > *Sent:* Tue, December 28, 2010 1:43:14 PM >>> > *Subject:* [Gen-art] review: draft-ietf-v6ops-tunnel-loops-01.txt >>> > >>> > I am the assigned Gen-ART reviewer for this draft. For background on >>> > Gen-ART, please see the FAQ at >>>> . >>> > >>> > Please resolve these comments along with any other Last Call comments >>> > you may receive. >>> > >>> > Document: draft-ietf-v6ops-tunnel-loops-01.txt >>> > Routing Loop Attack using IPv6 Automatic Tunnels: >>> > Problem Statement and Proposed Mitigations >>> > Reviewer: Joel M. Halpern >>> > Review Date: 28-Dec-2010 >>> > IETF LC End Date: 29-Dec-2010 >>> > IESG Telechat date: 06-Jan-2011) >>> > >>> > Summary: Nearly ready for publication as an Informational RFC >>> > >>> > Major issues: It is unclear in the document what assumptions section 3.1 >>> > makes about the relationship between supported tunnels and checked >>> > embedded addresses. Is there an assumption that the router only has to >>> > check for addresses in the format and prefix it supports? I hope so. >>> > Otherwise, a router seems to be expected to look at an arbitrary IPv6 >>> > addresses, guess whether it has an embedded IPv4 addresses, and perform >>> > filter checks on that guessed addresses against its own addresses. >>> > If indeed their is a relationship, then it would really help if section >>> > 3.1 said that. >>> > Unfortunately, I am afraid no such relationship is assumed. If not, I >>> > would like to see significantly better explanation of how the router is >>> > to reliably know that there is a 6rd or ISATAP address embedded in the >>> > v6 address. >>> > >>> > Minor issues: >>> > >>> > Nits/editorial comments: >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > From Wesley.E.George@sprint.com Tue Jan 11 06:35:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C857028C183; Tue, 11 Jan 2011 06:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.393 X-Spam-Level: X-Spam-Status: No, score=-5.393 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBkyMDNoAL0V; Tue, 11 Jan 2011 06:35:19 -0800 (PST) Received: from TX2EHSOBE009.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 91E8228C179; Tue, 11 Jan 2011 06:35:19 -0800 (PST) Received: from mail84-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.8; Tue, 11 Jan 2011 14:37:36 +0000 Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2-R.bigfish.com (Postfix) with ESMTP id 26ED91C061E; Tue, 11 Jan 2011 14:37:36 +0000 (UTC) X-SpamScore: -13 X-BigFish: VS-13(zz542N1432N10d1Izz1202hzzz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2 (MessageSwitch) id 1294756655679573_24718; Tue, 11 Jan 2011 14:37:35 +0000 (UTC) Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.250]) by mail84-tx2.bigfish.com (Postfix) with ESMTP id 8149FEE8057; Tue, 11 Jan 2011 14:37:35 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 11 Jan 2011 14:37:34 +0000 Received: from PLSWEH05.ad.sprint.com (PLSWEH05.corp.sprint.com [144.226.251.23]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0BEbQ9H029769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jan 2011 08:37:32 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.01.0255.000; Tue, 11 Jan 2011 08:37:32 -0600 From: "George, Wes E [NTK]" To: "Howard, Lee" , Mark Smith Thread-Topic: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AcuxC3/rsWoU8AoNQcqSpDOWTI/8EAAHejXgABr1PnA= Date: Tue, 11 Jan 2011 14:37:31 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04C472@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0020_01CBB173.2A9A1ED0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" , "int-area@ietf.org" , Christopher LILJENSTOLPE Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 14:35:23 -0000 ------=_NextPart_000_0020_01CBB173.2A9A1ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > -----Original Message----- > > From: Mark Smith > > I don't think I really agree with the root cause. IPv6 doesn't exist in > > equipment because customers, or representatives of customers (e.g ISPs > > for CPE) haven't made it a "must have", and refused to buy the > > equipment when it doesn't support IPv6. > > -----Original Message----- > From: Howard, Lee [mailto:lee.howard@twcable.com] > What about ISPs who don't buy CPE? > Retail stores in the U.S. make a lot of money selling gateways to > retail > customers. Consumers get more choice of what gateway they want to > buy. Surely we don't expect consumers to provide CPE requirements? > That's why we wrote cpe-router. [WES] Let's not forget that this is not just about residential gateways. We have TVs that connect to one or more streaming-video and social media services, appliances that talk either to the smart grid, or your home energy monitor, or a website, or all of the above; nevermind things like gaming consoles, standalone streaming media boxes, eReaders with Wifi... should I go on? If you could find someone at $consumer_electronics_manufacturer of any of the above products that we could provide those requirements to (who would actually...you know... listen to us and do something about it), I know of several representatives from large cable companies that represent a large fraction of their consumer base who would *love* to make IPv6 a must-have and explain to them how badly their product might potentially function behind NAT444. ARIN has been trying at places like CES, and ISOC has also tried to reach out to representatives of these industries, both with what I would consider to be only marginal success thus far. > > > I think a different and better approach would be to officially > > deprecate IPv4, declaring it obsolete. > > I've been thinking about writing that draft (it sounds really good on > the last day of IETF, over beers). > > After the recent thread on "Old transport-layer protocols to Historic" > I'm confused about what the right word would be. [WES] We started out that way with this draft, actually. But as Lee says, we couldn't determine whether deprecate or historic was the right choice, and we realized that honestly it's not that simple. I expect that we'll get much wider support for "IPv6 is required for devices that want to call themselves IP-capable" than for IPv4 deprecation when IPv4 is still the dominant protocol in use. This is at least partially because there are plenty of places where IPv4 will *never* go away or won't go away until the device using it is retired, where it is functioning acceptably and there is no issue with a lack of IPv4 addresses because that application isn't growing. Will those IPv4-only networks start becoming islands connected by IPv6 with ALG at some point? Likely, but if they're completely closed networks, we probably can't say that IPv4 isn't acceptable. My view is that the deprecation/historic discussion is one to have once we've reached critical mass on IPv6, or at least when we've exhausted the RIR free pools. Either way, this is a multistep process. The first step is to make sure that those manufacturers who don't have a clueful and influential customer providing them requirements understand that they need to stop grunting out widgets that don't understand IPv6, and to help apply pressure to those who are on the fence. We aren't going to be able to force them to do anything, only provide guidance, but I would hope that the IETF has some influence here. However, I imagine your average consumer is going to be a lot angrier when we tell them that the shiny new internet-connected device that they just got for $winter_gift-giving_holiday 2010 is basically obsolete, or at best functioning in a degraded fashion, due to a problem that we've known about for many years. The vendor of said device shares some blame for being short-sighted, greedy or both, especially if they don't update their software-updatable devices with an IPv6 stack, but I still don't know how IETF is going to answer the question as to why we didn't require IPv6 sooner. Wes George ------=_NextPart_000_0020_01CBB173.2A9A1ED0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTExNDM3MzBaMCMGCSqGSIb3DQEJBDEWBBTGou7slZ03 Iue0+7/L1ss2QpNuWzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBKUj3noPXis+vB RLqPsscIRK30xWPGdjxfywK2vk4/sDPhzCjwEUDzWB9lb1GGtVRWVjim5Emo1RmFYOIKnwh+StM5 2ljXMODn9vVkaT8rJhaPwcJ4ucAOeAFZLMS59ltYiNx03iDFlwv58kSZGXoUFnJDwSV21E4eEjlP DPYF5wAAAAAAAA== ------=_NextPart_000_0020_01CBB173.2A9A1ED0-- From Wesley.E.George@sprint.com Tue Jan 11 06:55:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2075028C18B for ; Tue, 11 Jan 2011 06:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7h12IaEidce for ; Tue, 11 Jan 2011 06:55:23 -0800 (PST) Received: from TX2EHSOBE003.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 1E09728C17D for ; Tue, 11 Jan 2011 06:55:23 -0800 (PST) Received: from mail75-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.8; Tue, 11 Jan 2011 14:57:39 +0000 Received: from mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2-R.bigfish.com (Postfix) with ESMTP id 9E0E519906DA; Tue, 11 Jan 2011 14:57:39 +0000 (UTC) X-SpamScore: -34 X-BigFish: VS-34(zz542N9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2 (MessageSwitch) id 1294757859331620_20139; Tue, 11 Jan 2011 14:57:39 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.248]) by mail75-tx2.bigfish.com (Postfix) with ESMTP id 4437A178005C; Tue, 11 Jan 2011 14:57:39 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 11 Jan 2011 14:57:36 +0000 Received: from PDAWEH02.ad.sprint.com (PDAWEH02.corp.sprint.com [144.226.111.42]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0BEvPAE011899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jan 2011 08:57:35 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH02.ad.sprint.com ([2002:90e2:6f2a::90e2:6f2a]) with mapi id 14.01.0255.000; Tue, 11 Jan 2011 08:57:29 -0600 From: "George, Wes E [NTK]" To: Brian E Carpenter , Behcet Sarikaya Thread-Topic: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AQHLsRu/rbswOQiRTUKKnyUbAkW3hJPL3F5w Date: Tue, 11 Jan 2011 14:57:28 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04C517@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> <4D2B921D.4000102@gmail.com> In-Reply-To: <4D2B921D.4000102@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0034_01CBB175.F3C2A1E0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 14:55:24 -0000 ------=_NextPart_000_0034_01CBB175.F3C2A1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Monday, January 10, 2011 6:11 PM > It would have the immediate implication that the IETF stops work > on all IPv4-only specifications (except, presumably, for > operational issues including sceurity). Sounds like a plan... > I believe that the following section of draft-george would cover this: Within the IETF, further protocol development on applications _exclusive_ to IPv4 SHOULD cease in order to concentrate on additional refinements and enhancements to IP version 6, with the goal of bringing IPv6 to complete parity with IPv4. This does not mean that further work SHOULD NOT have support for IPv4, merely that it MUST happen as a part of an IP version-agnostic implementation, or as an implementation that explicitly supports both IPv4 and IPv6. New features and protocols SHOULD NOT be introduced for use as IPv4- only unless they are specifically in support of IPv6 transition or IPv4-IPv6 interworking. A comprehensive list of these parity items and enhancements is outside the scope of this document, but this document recommends that the charters and work items of currently active IETF Working Groups (WGs) be evaluated to ensure that they are supporting the goal of full parity for IPv6. ------=_NextPart_000_0034_01CBB175.F3C2A1E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTExNDU3MjZaMCMGCSqGSIb3DQEJBDEWBBSZF14Vn+27 4/gDBDriXDueyrv1HDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAN1ew+0VYJYAmM da7ggD3ZieRba8jvbZ5+R3Lr1TZblB0sUgDnrZinQfduwNbrm1z6n1pl0VLJ6x52Jl+AVaMzXg1m UqKYnCy7Rvyj3A3tab8GKDN4cVXuWPfoeBUL847CDzDgS2fmiwKTHpTWBW6vnWDKs5apHU4Z79o8 DhCH0gAAAAAAAA== ------=_NextPart_000_0034_01CBB175.F3C2A1E0-- From cb.list6@gmail.com Tue Jan 11 08:12:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A4228C2BF; Tue, 11 Jan 2011 08:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK5fA0p+C8ON; Tue, 11 Jan 2011 08:12:45 -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 5A2F93A6A4E; Tue, 11 Jan 2011 08:12:45 -0800 (PST) Received: by qwi2 with SMTP id 2so5452622qwi.31 for ; Tue, 11 Jan 2011 08:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=of4Xq2XgjRPfVlAFLkgpRePF1D2mDrGrsiwc3U9+yvs=; b=NkSmIp1CBBGuEOdECkD6Ww+6FSYbnOYbZHs5qwifJg2efEumfuvKpcqTEO4cisJC4Y Mn4u+qRnnCVElxlzqI+pKnAvxmQd1hvmOiExVD/Cir29DAw6iEmnDzD4Bj9KTgEcl/cr eh7aJv73nfq2BBLjZUdQNciOUao59uy9ByjJg= 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=i5I5PHEbE4D3EjKdDHpqUF07PxC0tNdkRUzE7IAPsCI6MAQtKE3jqU6VquIqlDpmjw G4K9EvH9AmwYyL3MaK45/5Usv9HGjvakd0JX8Cq0QCZio4ff+5oL/efOuFQ99uTuqreF PBZz5WieyUZob6m/aTtxqAMLLf0PTJ8Fivtyw= MIME-Version: 1.0 Received: by 10.229.96.83 with SMTP id g19mr25689960qcn.106.1294762501880; Tue, 11 Jan 2011 08:15:01 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 11 Jan 2011 08:15:01 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 11 Jan 2011 08:15:01 -0800 (PST) In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E04C472@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <54E900DC635DAB4DB7A6D799B3C4CD8E04C472@PLSWM12A.ad.sprint.com> Date: Tue, 11 Jan 2011 08:15:01 -0800 Message-ID: From: Cameron Byrne To: "George, Wes E [NTK]" Content-Type: multipart/alternative; boundary=001636aa2b8efe3c700499946245 Cc: "Howard, Lee" , "v6ops@ietf.org" , "int-area@ietf.org" , Christopher LILJENSTOLPE Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 16:12:47 -0000 --001636aa2b8efe3c700499946245 Content-Type: text/plain; charset=ISO-8859-1 On Jan 11, 2011 6:37 AM, "George, Wes E [NTK]" wrote: > > > > -----Original Message----- > > > From: Mark Smith > > > I don't think I really agree with the root cause. IPv6 doesn't exist in > > > equipment because customers, or representatives of customers (e.g ISPs > > > for CPE) haven't made it a "must have", and refused to buy the > > > equipment when it doesn't support IPv6. > > > > -----Original Message----- > > From: Howard, Lee [mailto:lee.howard@twcable.com] > > What about ISPs who don't buy CPE? > > Retail stores in the U.S. make a lot of money selling gateways to > > retail > > customers. Consumers get more choice of what gateway they want to > > buy. Surely we don't expect consumers to provide CPE requirements? > > That's why we wrote cpe-router. > > [WES] Let's not forget that this is not just about residential gateways. We > have TVs that connect to one or more streaming-video and social media > services, appliances that talk either to the smart grid, or your home energy > monitor, or a website, or all of the above; nevermind things like gaming > consoles, standalone streaming media boxes, eReaders with Wifi... should I > go on? > If you could find someone at $consumer_electronics_manufacturer of any of > the above products that we could provide those requirements to (who would > actually...you know... listen to us and do something about it), I know of > several representatives from large cable companies that represent a large > fraction of their consumer base who would *love* to make IPv6 a must-have > and explain to them how badly their product might potentially function > behind NAT444. ARIN has been trying at places like CES, and ISOC has also > tried to reach out to representatives of these industries, both with what I > would consider to be only marginal success thus far. > > > > > I think a different and better approach would be to officially > > > deprecate IPv4, declaring it obsolete. > > > > I've been thinking about writing that draft (it sounds really good on > > the last day of IETF, over beers). > > > > After the recent thread on "Old transport-layer protocols to Historic" > > I'm confused about what the right word would be. > > [WES] We started out that way with this draft, actually. But as Lee says, we > couldn't determine whether deprecate or historic was the right choice, and > we realized that honestly it's not that simple. I expect that we'll get much > wider support for "IPv6 is required for devices that want to call themselves > IP-capable" than for IPv4 deprecation when IPv4 is still the dominant > protocol in use. This is at least partially because there are plenty of > places where IPv4 will *never* go away or won't go away until the device > using it is retired, where it is functioning acceptably and there is no > issue with a lack of IPv4 addresses because that application isn't growing. > Will those IPv4-only networks start becoming islands connected by IPv6 with > ALG at some point? Likely, but if they're completely closed networks, we > probably can't say that IPv4 isn't acceptable. My view is that the > deprecation/historic discussion is one to have once we've reached critical > mass on IPv6, or at least when we've exhausted the RIR free pools. > +1 for having something to reference in time for rir exhaust. The people living in a hole will really start panicking at that point and having clear guidance that ipv4 is dead will really help in creating order from the impending chaos. Cb > Either way, this is a multistep process. The first step is to make sure that > those manufacturers who don't have a clueful and influential customer > providing them requirements understand that they need to stop grunting out > widgets that don't understand IPv6, and to help apply pressure to those who > are on the fence. We aren't going to be able to force them to do anything, > only provide guidance, but I would hope that the IETF has some influence > here. However, I imagine your average consumer is going to be a lot angrier > when we tell them that the shiny new internet-connected device that they > just got for $winter_gift-giving_holiday 2010 is basically obsolete, or at > best functioning in a degraded fashion, due to a problem that we've known > about for many years. The vendor of said device shares some blame for being > short-sighted, greedy or both, especially if they don't update their > software-updatable devices with an IPv6 stack, but I still don't know how > IETF is going to answer the question as to why we didn't require IPv6 > sooner. > > Wes George > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001636aa2b8efe3c700499946245 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 11, 2011 6:37 AM, "George, Wes E [NTK]" <Wesley.E.George@sprint.com> wrote: >
> =A0> > -----Original Message-----
> > > From: Mark Smith
> > > I don't think I really agree with the root cause. IPv6 d= oesn't exist in
> > > equipment because customers, or representatives of customers= (e.g ISPs
> > > for CPE) haven't made it a "must have", and re= fused to buy the
> > > equipment when it doesn't support IPv6.
> >
> > -----Original Message-----
> > From: Howard, Lee [mailto:lee.howard@twcable.com]
> > What about ISPs who don't buy CPE?
> > Retail stores in the U.S. make a lot of money selling gateways to=
> > retail
> > customers. =A0Consumers get more choice of what gateway they want= to
> > buy. =A0Surely we don't expect consumers to provide CPE requi= rements?
> > That's why we wrote cpe-router.
>
> [WES] Let's not forget that this is not just about residential gat= eways. We
> have TVs that connect to one or more streaming-video and social media<= br> > services, appliances that talk either to the smart grid, or your home = energy
> monitor, or a website, or all of the above; nevermind things like gami= ng
> consoles, standalone streaming media boxes, eReaders with Wifi... shou= ld I
> go on?
> If you could find someone at $consumer_electronics_manufacturer of any= of
> the above products that we could provide those requirements to (who wo= uld
> actually...you know... listen to us and do something about it), I know= of
> several representatives from large cable companies that represent a la= rge
> fraction of their consumer base who would *love* to make IPv6 a must-h= ave
> and explain to them how badly their product might potentially function=
> behind NAT444. ARIN has been trying at places like CES, and ISOC has a= lso
> tried to reach out to representatives of these industries, both with w= hat I
> would consider to be only marginal success thus far.
> >
> > > I think a different and better approach would be to official= ly
> > > deprecate IPv4, declaring it obsolete.
> >
> > I've been thinking about writing that draft (it sounds really= good on
> > the last day of IETF, over beers).
> >
> > After the recent thread on "Old transport-layer protocols to= Historic"
> > I'm confused about what the right word would be.
>
> [WES] We started out that way with this draft, actually. But as Lee sa= ys, we
> couldn't determine whether deprecate or historic was the right cho= ice, and
> we realized that honestly it's not that simple. I expect that we&#= 39;ll get much
> wider support for "IPv6 is required for devices that want to call= themselves
> IP-capable" than for IPv4 deprecation when IPv4 is still the domi= nant
> protocol in use. This is at least partially because there are plenty o= f
> places where IPv4 will *never* go away or won't go away until the = device
> using it is retired, where it is functioning acceptably and there is n= o
> issue with a lack of IPv4 addresses because that application isn't= growing.
> Will those IPv4-only networks start becoming islands connected by IPv6= with
> ALG at some point? Likely, but if they're completely closed networ= ks, we
> probably can't say that IPv4 isn't acceptable. My view is that= the
> deprecation/historic discussion is one to have once we've reached = critical
> mass on IPv6, or at least when we've exhausted the RIR free pools.=
>

+1 for having something to reference in time for rir exhaust.

The people living in a hole will really start panicking at that point an= d having clear guidance that ipv4 is dead will really help in creating orde= r from the impending chaos.

Cb
> Either way, this is a multistep process. The first step is to make sur= e that
> those manufacturers who don't have a clueful and influential custo= mer
> providing them requirements understand that they need to stop grunting= out
> widgets that don't understand IPv6, and to help apply pressure to = those who
> are on the fence. We aren't going to be able to force them to do a= nything,
> only provide guidance, but I would hope that the IETF has some influen= ce
> here. However, I imagine your average consumer is going to be a lot an= grier
> when we tell them that the shiny new internet-connected device that th= ey
> just got for $winter_gift-giving_holiday 2010 is basically obsolete, o= r at
> best functioning in a degraded fashion, due to a problem that we'v= e known
> about for many years. The vendor of said device shares some blame for = being
> short-sighted, greedy or both, especially if they don't update the= ir
> software-updatable devices with an IPv6 stack, but I still don't k= now how
> IETF is going to answer the question as to why we didn't require I= Pv6
> sooner.
>
> Wes George
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001636aa2b8efe3c700499946245-- From jnc@mercury.lcs.mit.edu Tue Jan 11 08:44:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE173A67FD; Tue, 11 Jan 2011 08:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v53vBBTASsO6; Tue, 11 Jan 2011 08:44:57 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A13383A6A1F; Tue, 11 Jan 2011 08:44:57 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CA1956BE595; Tue, 11 Jan 2011 11:47:13 -0500 (EST) To: int-area@ietf.org, v6ops@ietf.org Message-Id: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> Date: Tue, 11 Jan 2011 11:47:13 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Tue, 11 Jan 2011 08:58:51 -0800 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 16:44:58 -0000 > From: "George, Wes E [NTK]" > I imagine your average consumer is going to be a lot angrier when we > tell them that the shiny new internet-connected device that they just > got for $winter_gift-giving_holiday 2010 is basically obsolete .. due to > a problem that we've known about for many years. The vendor of said > device shares some blame for being short-sighted, greedy or both .. but > I still don't know how IETF is going to answer the question as to why we > didn't require IPv6 sooner. The IETF is not the Protocol Police. All it can do is design stuff, put it out there, try and make sure everyone knows about it, and hope people use it. If there is more than a minute handful of people involved in the networking world who doesn't know what IPv6 is, I would be totally astonished. So the IETF has done what it can. If manufacturers aren't doing it (whether because they don't think their customers have any use for it, or whatever), that's their informed (to whatever degree) choice. People aren't children, you can't order them around like 5-year olds to eat their broccoli. Noel From remi.despres@free.fr Tue Jan 11 09:42:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C7E3A6A5E; Tue, 11 Jan 2011 09:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 YkMjntnZDSt2; Tue, 11 Jan 2011 09:42:34 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by core3.amsl.com (Postfix) with ESMTP id A41B33A6A60; Tue, 11 Jan 2011 09:42:34 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 8A8CA70000A2; Tue, 11 Jan 2011 18:44:51 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 400A5700009D; Tue, 11 Jan 2011 18:44:51 +0100 (CET) X-SFR-UUID: 20110111174451262.400A5700009D@msfrf2416.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: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> Date: Tue, 11 Jan 2011 18:44:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <28944986-243F-4C19-A998-4BCE3DED0496@free.fr> References: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, int-area@ietf.org Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:42:35 -0000 +1 What IETF must provide is specifications of what is meant by IPv6, = ICMPv6, SLAAC, IPsec, ... Then, vendors that claim they support any of these know what they are = committed to. But they remain free to decide what they support. RD Le 11 janv. 2011 =E0 17:47, Noel Chiappa a =E9crit : >> From: "George, Wes E [NTK]" >=20 >> I imagine your average consumer is going to be a lot angrier when we >> tell them that the shiny new internet-connected device that they just >> got for $winter_gift-giving_holiday 2010 is basically obsolete .. due = to >> a problem that we've known about for many years. The vendor of said >> device shares some blame for being short-sighted, greedy or both .. = but >> I still don't know how IETF is going to answer the question as to why = we >> didn't require IPv6 sooner. >=20 > The IETF is not the Protocol Police. All it can do is design stuff, = put it out > there, try and make sure everyone knows about it, and hope people use = it. If > there is more than a minute handful of people involved in the = networking world > who doesn't know what IPv6 is, I would be totally astonished. So the = IETF has > done what it can. >=20 > If manufacturers aren't doing it (whether because they don't think = their > customers have any use for it, or whatever), that's their informed (to > whatever degree) choice. People aren't children, you can't order them = around > like 5-year olds to eat their broccoli. >=20 > Noel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Wesley.E.George@sprint.com Tue Jan 11 09:54:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830713A681A; Tue, 11 Jan 2011 09:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.954 X-Spam-Level: X-Spam-Status: No, score=-4.954 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, GB_I_LETTER=-2, 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 XsTskKG+d6nC; Tue, 11 Jan 2011 09:54:40 -0800 (PST) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by core3.amsl.com (Postfix) with ESMTP id DF3DF3A6A76; Tue, 11 Jan 2011 09:54:39 -0800 (PST) Received: from mail3-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.8; Tue, 11 Jan 2011 17:56:56 +0000 Received: from mail3-db3 (localhost.localdomain [127.0.0.1]) by mail3-db3-R.bigfish.com (Postfix) with ESMTP id 8EBAA290360; Tue, 11 Jan 2011 17:56:56 +0000 (UTC) X-SpamScore: -21 X-BigFish: VS-21(zz542N1432N9371P10d1Izz1202hzzz2fh2a8h668h34h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail3-db3 (localhost.localdomain [127.0.0.1]) by mail3-db3 (MessageSwitch) id 1294768616220330_31571; Tue, 11 Jan 2011 17:56:56 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.248]) by mail3-db3.bigfish.com (Postfix) with ESMTP id 331AE18A804B; Tue, 11 Jan 2011 17:56:56 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 11 Jan 2011 17:56:53 +0000 Received: from PLSWEH02.ad.sprint.com (PLSWEH02.corp.sprint.com [144.226.242.131]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0BHudjn028626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jan 2011 11:56:51 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH02.ad.sprint.com ([2002:90e2:f283::90e2:f283]) with mapi id 14.01.0255.000; Tue, 11 Jan 2011 11:56:45 -0600 From: "George, Wes E [NTK]" To: Noel Chiappa , "int-area@ietf.org" , "v6ops@ietf.org" Thread-Topic: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AQHLsa85dhvAbzlInEG5ONA6M5aa2ZPL/W5g Date: Tue, 11 Jan 2011 17:56:44 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04C8CD@PLSWM12A.ad.sprint.com> References: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> In-Reply-To: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0088_01CBB18E.FCE1A5F0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:54:41 -0000 ------=_NextPart_000_0088_01CBB18E.FCE1A5F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Tuesday, January 11, 2011 11:47 AM > > The IETF is not the Protocol Police. All it can do is design stuff, put > it out > there, try and make sure everyone knows about it, and hope people use > it. [WES] There's no enforcement being proposed here. It's a guideline just like anything else that IETF (or any of the myriad standards bodies that we might name) generates. However, plenty of companies cite RFCs and drafts as shorthand for the features and services that they want to have work on a device or network specification with the full expectation that they'll be updated as necessary to remain current. Updating them to reflect changes and evolution is part of what we do at IETF. Distilling this down, you're basically saying "you can lead a horse to water, but you can't make him drink." I'm merely recommending that we be a bit more forceful in our leadership to the water, instead of being neutral on the question of whether you should implement IPv6 on your device or software. > If there is more than a minute handful of people involved in the > networking world > who doesn't know what IPv6 is, I would be totally astonished. So the > IETF has > done what it can. [WES] The degree of IPv6 awareness varies vastly by area of focus. There are plenty of folks who refer to IETF standards or need to know about IPv6 that are not within the networking world (and its little bubble of IPv6 cognoscenti) per se. And even if the networking folks understand that it's necessary, sometimes things like "it's an IETF standard, we need to do it to comply with the standard" is enough to push a justification through the business folks who probably don't. > > If manufacturers aren't doing it (whether because they don't think > their > customers have any use for it, or whatever), that's their informed (to > whatever degree) choice. People aren't children, you can't order them > around > like 5-year olds to eat their broccoli. [WES] Yet we generate standards all day long with words like MUST that we expect the same manufacturers to follow to the letter. This argument can be made about any standard we generate! So is IETF's collective opinion relevant or not? I am under no illusion that adoption of this draft will *solve* the lack of IPv6 support in consumer electronics (or anywhere else), and I am fully aware that businesses will make their own decisions. That doesn't remove IETF from any responsibility to make a recommendation as to the current reality, which is that IPv4 *only* isn't going to keep working indefinitely, at least not in exactly the same way that it did before IANA exhaustion. I as an operator am asking for them to do so in order to make my job (trying to keep my customers' service functional) easier. This means trying to give me some help in the space where there are lots of devices that I don't have any control over, even if it's just a nudge in the right direction. Wes George ------=_NextPart_000_0088_01CBB18E.FCE1A5F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTExNzU2MzlaMCMGCSqGSIb3DQEJBDEWBBSNSUi3W6mp dSQnZnuB80n0F4sGIzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBc0oN3Ou55y+95 Zh5uoUTb95TlBtJ/tObVrcFroAkSDx7Xx+X0uakVSQAnVVsjdAd69XqtN7LcSpOUyTq40fGktS54 LMKU4DGyP/d5s+l/SbAkis+dWkHP8V5EfWmUahKZ+mNDfGAPea3xqdIg6gPO++pdULSuZNx5vZp+ Bl5wxwAAAAAAAA== ------=_NextPart_000_0088_01CBB18E.FCE1A5F0-- From brian.e.carpenter@gmail.com Tue Jan 11 12:28:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32E728C2E2; Tue, 11 Jan 2011 12:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 XLYCttBqbz8j; Tue, 11 Jan 2011 12:28:45 -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 7C68828C113; Tue, 11 Jan 2011 12:28:44 -0800 (PST) Received: by ewy8 with SMTP id 8so9754615ewy.31 for ; Tue, 11 Jan 2011 12:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L773aZhHUY+bkM1SdL9ryPibA1myaptS6kQNSHKk33I=; b=WjM/Y0i6TKev+urLRKYM9uQt9qUiWJ3d/EZi0v5EKP4k+2yRSDb83d7MYPUhone3Wg XAO5GY7GuGmGQ6Jc27xI67fPkd9nGb1LxQfkO8Oq0n1yTsnL6fRqiwauBV6+re4x7hg8 v0iGwBPEA7jbdHc3J3woQ1nMZUSfF0uyFB1LM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=tVhzXdRbhp5NGV+97z0Z9EiXiYNA9uk9JBue9XZnXMI07nYzXeE+qn1+gxtOVTN0Qh 4TamwzAngOkdFfqBeqRmbt2G7E7hxFXTuRcTGUP/a9HJlDKLG0ThcGG2dIPFvjqgTyoJ kds/kP9nMa+aZMTq0LZQUMb1i9bkaMHo7+amA= Received: by 10.223.81.70 with SMTP id w6mr71909fak.62.1294777861241; Tue, 11 Jan 2011 12:31:01 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b7sm4671251faa.42.2011.01.11.12.30.57 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 12:31:00 -0800 (PST) Message-ID: <4D2CBDFE.30902@gmail.com> Date: Wed, 12 Jan 2011 09:30:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, int-area@ietf.org Subject: Re: [v6ops] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 20:28:45 -0000 On 2011-01-12 00:17, R=C3=A9mi Despr=C3=A9s wrote: > Le 10 janv. 2011 =C3=A0 22:47, sthaug@nethelp.no a =C3=A9crit : >=20 >>>> UDP encapsulation of IPsec is a work around, specifically to get aro= und >>>> the problems of lack of IPv4 address transparency i.e. NAT. It isn't= an >>>> acceptable answer when NAT doesn't need to exist. >>> You're assuming that the only motivation to have NATs is address >>> exhaustion -- but IMO, it isn't. >> Provider independence is a huge motivation. >=20 > Agreed. >=20 > That's why, IMHO, it should be more useful to look for solutions that c= ombine provider independence with address transparency, than accepting wi= thout effort to sacrifice address transparency for provider independence.= Indeed; we already have one of those standardised, which also has the pro= perty of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC 5535. The LISP WG is standardising another solution with those properties, that doesn't even require the user site to operate multiple prefixes. Brian > Although I know some readers don't like my repeating that I worked on s= uch a solution, this is IMHO relevant to the point being discussed. > Ref: www.ietf.org/id/draft-despres-softwire-sam-01, in particular sec. = 3.3. > (As this draft is about to expire, I should work in some future on a re= vised version.)=20 >=20 > Regards, > RD >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From brian.e.carpenter@gmail.com Tue Jan 11 12:44:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D625B28C117 for ; Tue, 11 Jan 2011 12:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.129 X-Spam-Level: X-Spam-Status: No, score=-103.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 Tr63oouGxFMq for ; Tue, 11 Jan 2011 12:44:01 -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 E06E328C0F9 for ; Tue, 11 Jan 2011 12:44:00 -0800 (PST) Received: by fxm9 with SMTP id 9so20759856fxm.31 for ; Tue, 11 Jan 2011 12:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QNUXFg1TAvAW5sdaJ7DACfdePQuH3fZGcJes9j3MXSw=; b=eLyFj+DF5biSg+7WRlfppSVjEgueDvgkTyygLYbSUNq7l5io4Q8MyVGAu5v4pkoBXM 0Ub+Dj+EvVOGnRmn9lfe7Uw99a20UHFQtC/2OXhsHrsb4gnIzcH92pM0nCqp061r2dG9 +IV+nUX91sWTjroPq+OetKuqOHRaN3HEpyy4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=cKQ5JaVSKhdUYk7jtQ48sFKxn+DWgdq95cW9C3hhVTJ9qphrs6KfksFOyUbE7Hrh1M 743tV0ygdr0DBx9T01w99s+TYdFNGWjdksRGmHeKmQxqroaHhLvU663m0ZO7JFIEQwiN i/FSNqKSFhxfIT7XILh5v3XlUhWPJgFcLZALo= Received: by 10.223.96.66 with SMTP id g2mr87706fan.61.1294778777728; Tue, 11 Jan 2011 12:46:17 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y1sm7572573fak.15.2011.01.11.12.46.14 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 12:46:16 -0800 (PST) Message-ID: <4D2CC193.2030904@gmail.com> Date: Wed, 12 Jan 2011 09:46:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel Jaeggli References: <4D2BF038.9070703@bogus.com> In-Reply-To: <4D2BF038.9070703@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 20:44:01 -0000 On 2011-01-11 18:52, Joel Jaeggli wrote: > On 1/10/11 9:39 AM, Fred Baker wrote: >> Question for the assembled throng: What do people want to see happen >> in draft-ietf-v6ops-v6-aaaa-whitelisting-implications? > > my impression is that it's probably ready for last call. Agreed. I find it clear and useful. Brian > >> We had a reasonable discussion on this at IETF 79, and people seemed >> pretty supportive. Does it need updates? What comments do people have? >> >> Comments to the list, please. >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Tue Jan 11 12:54:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC96F28C0F9 for ; Tue, 11 Jan 2011 12:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.427 X-Spam-Level: X-Spam-Status: No, score=-103.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 2hCHRbGJqNSQ for ; Tue, 11 Jan 2011 12:54:20 -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 531483A67B5 for ; Tue, 11 Jan 2011 12:54:20 -0800 (PST) Received: by fxm9 with SMTP id 9so20769768fxm.31 for ; Tue, 11 Jan 2011 12:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lLsOfvcQ+MnR4uYDTBtjfFzj7H9YvKoIMromS/CJ//c=; b=F9i7vTYSiyo6dbWlaeGZ5p6I636keINGtz5OGWMCmzRBHJTPjYAyuAlK/M1YFisoUf cSzN+77HTfhKh8x6umZRyOwuoldIAKMiQj42ucK3kVko3Ag29tJYiLqFbe41l3A6Fsxh XOjqJaWq9QoDHOrf7tPWlSrbOsfY1uWXyn+7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=vPELaziZpvJADSDzJtLsFd1m5kHNHUYb8eAS2S+72dIsDzzIixh12jb9oIOKejSlyS oughsQKuAxGTTHqfLLGFTpzx4OdnGvepybFX1kDVpyelNJ4XgFq402g4r4E6bDVK7jKG 02QL0u1V5gXPiD3dcU0rxsaTB1dhEDvdwk8H4= Received: by 10.223.79.6 with SMTP id n6mr74353fak.122.1294779396278; Tue, 11 Jan 2011 12:56:36 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id e17sm7577280fak.34.2011.01.11.12.56.32 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 12:56:35 -0800 (PST) Message-ID: <4D2CC3FD.6010908@gmail.com> Date: Wed, 12 Jan 2011 09:56:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "George, Wes E [NTK]" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> <4D2B921D.4000102@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04C517@PLSWM12A.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E04C517@PLSWM12A.ad.sprint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 20:54:22 -0000 On 2011-01-12 01:09, Tim Chown wrote: > How much IPv4-only work is happening? Probably not much; this is a symbolic action in some ways. On 2011-01-12 03:57, George, Wes E [NTK] wrote: > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Brian E Carpenter >> Sent: Monday, January 10, 2011 6:11 PM > >> It would have the immediate implication that the IETF stops work >> on all IPv4-only specifications (except, presumably, for >> operational issues including sceurity). Sounds like a plan... >> > I believe that the following section of draft-george would cover this: > > Within the IETF, further protocol development on applications OK, but how about s/applications/protocols or applications/ ? And I suspect an exmption for vital operational or security issues is required. Brian > _exclusive_ to IPv4 SHOULD cease in order to concentrate on > additional refinements and enhancements to IP version 6, with the > goal of bringing IPv6 to complete parity with IPv4. This does not > mean that further work SHOULD NOT have support for IPv4, merely that > it MUST happen as a part of an IP version-agnostic implementation, or > as an implementation that explicitly supports both IPv4 and IPv6. > New features and protocols SHOULD NOT be introduced for use as IPv4- > only unless they are specifically in support of IPv6 transition or > IPv4-IPv6 interworking. A comprehensive list of these parity items > and enhancements is outside the scope of this document, but this > document recommends that the charters and work items of currently > active IETF Working Groups (WGs) be evaluated to ensure that they are > supporting the goal of full parity for IPv6. From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 11 13:14:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519F53A659A for ; Tue, 11 Jan 2011 13:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 0RjS2Qmtl2ck for ; Tue, 11 Jan 2011 13:14:21 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 201053A67AA for ; Tue, 11 Jan 2011 13:14:20 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pcla1-0007E3-5q; Wed, 12 Jan 2011 07:46:37 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id DFDA63B31E; Wed, 12 Jan 2011 07:46:36 +1030 (CST) Date: Wed, 12 Jan 2011 07:46:36 +1030 From: Mark Smith To: Brian E Carpenter Message-ID: <20110112074636.7d61d62d@opy.nosense.org> In-Reply-To: <4D2CC3FD.6010908@gmail.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> <4D2B921D.4000102@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04C517@PLSWM12A.ad.sprint.com> <4D2CC3FD.6010908@gmail.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 21:14:22 -0000 On Wed, 12 Jan 2011 09:56:29 +1300 Brian E Carpenter wrote: > On 2011-01-12 01:09, Tim Chown wrote: > > > How much IPv4-only work is happening? > > Probably not much; this is a symbolic action in some ways. > I agree. I think it is quite reasonable and expected for the manufacturer of a tool (or two generations of tool) to advise end-users of when and how they should be best used. If some end-users choose ignore that advice, that is up to them, but that doesn't mean the advice is therefore invalid and unnecessary. Considering the issues that are going to be encountered with IPv4 after large scale address sharing is deployed, I think a stronger statement of manufacturer advice on using IPv6 in preference to IPv4 would be useful. > On 2011-01-12 03:57, George, Wes E [NTK] wrote: > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > >> Of Brian E Carpenter > >> Sent: Monday, January 10, 2011 6:11 PM > > > >> It would have the immediate implication that the IETF stops work > >> on all IPv4-only specifications (except, presumably, for > >> operational issues including sceurity). Sounds like a plan... > >> > > I believe that the following section of draft-george would cover this: > > > > Within the IETF, further protocol development on applications > > OK, but how about s/applications/protocols or applications/ ? > And I suspect an exmption for vital operational or security > issues is required. > > Brian > > > _exclusive_ to IPv4 SHOULD cease in order to concentrate on > > additional refinements and enhancements to IP version 6, with the > > goal of bringing IPv6 to complete parity with IPv4. This does not > > mean that further work SHOULD NOT have support for IPv4, merely that > > it MUST happen as a part of an IP version-agnostic implementation, or > > as an implementation that explicitly supports both IPv4 and IPv6. > > New features and protocols SHOULD NOT be introduced for use as IPv4- > > only unless they are specifically in support of IPv6 transition or > > IPv4-IPv6 interworking. A comprehensive list of these parity items > > and enhancements is outside the scope of this document, but this > > document recommends that the charters and work items of currently > > active IETF Working Groups (WGs) be evaluated to ensure that they are > > supporting the goal of full parity for IPv6. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Jan 11 17:19:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD373A6827 for ; Tue, 11 Jan 2011 17:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 3LWt6NcMfgzE for ; Tue, 11 Jan 2011 17:19:15 -0800 (PST) Received: from mail-vw0-f66.google.com (mail-vw0-f66.google.com [209.85.212.66]) by core3.amsl.com (Postfix) with ESMTP id 55D0B3A680F for ; Tue, 11 Jan 2011 17:19:15 -0800 (PST) Received: by vws15 with SMTP id 15so12597vws.1 for ; Tue, 11 Jan 2011 17:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zKoKAbSxsYsw9iHQ6ypy8wTv8SqYqveo9aJZQS5kpZY=; b=KJIyI+0YS2F60vigzck17VC72tGN7IghqCpc4h4I0la++oEPb3xHSSjwDT4Kp20c0o uDoWf4zrkLZdB3nbDQ3ZL5En31NFuRT4QdHUytiG8uFrKDFj2ZXJKUqKXDi8+vBDFonV AUqA3dqHPOI0mki2hSqzeHRNJJHf0eYxUy0bQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=ftw7V67AutKxWhvg8QOqe45jcWtpZZJ/QNlqr88I7eGwZyP5RSx1lZ2SIxthSy0n7Y M4Q8bV2TVJRtHY4hJHNCIgEXiCSEKQ2Y6j3rWIAl2nnbzq5yYrHC0ik0Na7m6z9t1xka DTZDPKW54sbFjn9avOJcwx9x4ZNA8aLl/bo14= Received: by 10.220.71.81 with SMTP id g17mr75505vcj.184.1294795291085; Tue, 11 Jan 2011 17:21:31 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id fl9sm40274vbb.10.2011.01.11.17.21.29 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 17:21:30 -0800 (PST) Message-ID: <4D2D0221.7060609@gmail.com> Date: Wed, 12 Jan 2011 14:21:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <21C4C296-601B-4E11-A629-0EE87C8F9018@cisco.com> In-Reply-To: <21C4C296-601B-4E11-A629-0EE87C8F9018@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-v4v6tran-framework - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 01:19:16 -0000 I've got one suggested additional point from Randy: > documents should describe scenarios for real transition to ipv6, not life > extensions to ipv4 or other things best handled in other wgs. which I fully agree with. Apart from that, I haven't seen any further suggestions since Beijing. Regards Brian On 2011-01-11 21:38, Fred Baker wrote: > Another question for the assembled throng: What do people want to see happen in draft-ietf-v6ops-v4v6tran-framework? > > This came out of the v4v6tran effort. There seemed to be a fair support for the draft. What needs to happen with it? > > Comments to the list, please. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From gvandeve@cisco.com Wed Jan 12 04:03:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714D628C10C for ; Wed, 12 Jan 2011 04:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.804 X-Spam-Level: X-Spam-Status: No, score=-9.804 tagged_above=-999 required=5 tests=[AWL=0.795, 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 XOjv+NcOfghx for ; Wed, 12 Jan 2011 04:03:39 -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 C26DF28C100 for ; Wed, 12 Jan 2011 04:03:39 -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: AvsEADMoLU2rR7H+/2dsb2JhbACkPnOjV5h8hUwEjjaICw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 12 Jan 2011 12:05:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0CC5bO4028556; Wed, 12 Jan 2011 12:05:58 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jan 2011 13:04:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2011 13:04:19 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E502E77C13@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] IP-capable nodes must support IPv6 -new draft-george-ipv6-required Thread-Index: AcuxiGpHEC6yI7DLROex4a9hUWLJVAAyDk5g References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org><913371.73213.qm@web111411.mail.gq1.yahoo.com><4D2B921D.4000102@gmail.com><235B67C9-D15B-42B8-9FCD-351C95A6AF48@ecs.soton.ac.uk> From: "Gunter Van de Velde (gvandeve)" To: "Tim Chown" , "IPv6 Operations" X-OriginalArrivalTime: 12 Jan 2011 12:04:20.0551 (UTC) FILETIME=[D841CD70:01CBB250] Subject: Re: [v6ops] IP-capable nodes must support IPv6 -new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 12:03:40 -0000 > How much IPv4-only work is happening? You would be surprised :-) ... maybe not at IETF, but for sure at vendors and this would be a crystal=20 clear signal to people still believing in the v4 only world. G/ From remi.despres@free.fr Wed Jan 12 04:17:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D65428C0E9 for ; Wed, 12 Jan 2011 04:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_50=0.001, 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 eXU8jcpq3g6B for ; Wed, 12 Jan 2011 04:17:15 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id 7EEF928C0D0 for ; Wed, 12 Jan 2011 04:17:14 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 9576F7000087; Wed, 12 Jan 2011 13:19:32 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id EF4957000091; Wed, 12 Jan 2011 13:19:31 +0100 (CET) X-SFR-UUID: 20110112121931980.EF4957000091@msfrf2304.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: <4D23F852.20708@bogus.com> Date: Wed, 12 Jan 2011 11:44:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3A14A3E0-EBAC-4043-8E05-37D86F6BB633@free.fr> References: <4D23F852.20708@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 12:17:16 -0000 Le 5 janv. 2011 =E0 05:49, Joel Jaeggli a =E9crit : > ... my first reaction is that this is a > good source of information. Well written, fairly detailed (at 188 = pages) > with lots of references. +1 I noted however an error in section 6.5.7 on Teredo: "The 6to4 and 6rd protocols require public IPv4 addresses" This isn't right for 6rd (RFCs 5569 and 5969)=20 > ... The PDF is available at: > http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf Regards, RD From iesg-secretary@ietf.org Wed Jan 12 11:50:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F473A6A87; Wed, 12 Jan 2011 11:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 h96gD9Z0lqmj; Wed, 12 Jan 2011 11:50:44 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623783A6A9C; Wed, 12 Jan 2011 11:50:42 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110112195042.11440.88026.idtracker@localhost> Date: Wed, 12 Jan 2011 11:50:42 -0800 Cc: v6ops mailing list , Internet Architecture Board , v6ops chair , RFC Editor Subject: [v6ops] Protocol Action: 'IPv6 Address Assignment to End Sites' to BCP (draft-ietf-v6ops-3177bis-end-sites-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 19:50:45 -0000 The IESG has approved the following document: - 'IPv6 Address Assignment to End Sites' (draft-ietf-v6ops-3177bis-end-sites-01.txt) as a BCP This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ Technical Summary RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document revisits and updates the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. Moreover, the document clarifies that a one- size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document updates and replaces RFC 3177. Working Group Summary The IPv6 Operations Working Group very solidly supported the specific changes in proposed policy from RFC 3177. These are: 1) It is no longer recommended that /128s be given out. While ther may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices. 2) RFC 3177 specifically recommended using prefix lengths of /48, /64 and /128. Specifying a small number of fixed boundaries has raised concerns that implementations and operational practices might become "hard-coded" to recognize only those fixed boundaries (i.e., a return to "classful addressing"). The actual intention has always been that there be no hard-coded boundaries within addresses, and that CIDR continues to apply to all bits of the routing prefixes. 3) This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate. This document does, however, reaffirm an important assumption behind RFC 3177: A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. Document Quality The document appears to be of very high quality and essentially unanimous support. Personnel Fred Baker is shepherd for this document. From fernando.gont.netbook.win@gmail.com Thu Jan 13 13:05:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F97D3A6BC9 for ; Thu, 13 Jan 2011 13:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 nDYWzemaC9Aj for ; Thu, 13 Jan 2011 13:05:16 -0800 (PST) Received: from mail-gw0-f66.google.com (mail-gw0-f66.google.com [74.125.83.66]) by core3.amsl.com (Postfix) with ESMTP id 26ED03A6B4A for ; Thu, 13 Jan 2011 13:05:16 -0800 (PST) Received: by gwj18 with SMTP id 18so491262gwj.1 for ; Thu, 13 Jan 2011 13:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=lQxrmM0NVPddxa/ull6U+aXZxyA57jPTiY2LXNx3g1A=; b=KlPGHpF0GiYf59OMyX/IvdbrGAGnFazOfo5GDggyd0r7cTA9542tDkEZ8wnUlDg8IJ YyeiFdTufk7QxIhDnPASW9vgdS33EhaYfZcp8L5ko84+pvYna5XDSW/rPVei9xTUsGMh agwE7V9I6bnoXUE0WGd5zWwWPj64N20fflsCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=r+HuhGf1mkytMTmZlH5AzGF0KrkPmnq15gVBwJMUA4zkITmn1xZdYVTv5Kvge7rfAW wIu1wJ9qrZFsaIPjjJp46gyMkIgHXsH9paMNQUshv9UM6G4gw8UTsKebwrpGfEpyzrjr 59r3Rurb8MQtP+FgNX6fzxH8TocdiTqCwo2Z4= Received: by 10.150.200.19 with SMTP id x19mr262078ybf.139.1294952859003; Thu, 13 Jan 2011 13:07:39 -0800 (PST) Received: from [192.168.1.145] (154-141-17-190.fibertel.com.ar [190.17.141.154]) by mx.google.com with ESMTPS id v6sm253677ybk.8.2011.01.13.13.07.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 13:07:35 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2F5BC4.60508@gont.com.ar> Date: Thu, 13 Jan 2011 17:08:36 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> <4D2B81B9.3070608@gmail.com> In-Reply-To: <4D2B81B9.3070608@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:05:17 -0000 On 10/01/2011 07:01 p.m., Brian E Carpenter wrote: >> Well, if the firewall is meant to allow only traffic that is deemed as >> necessary, and the organization has not decided to deploy v6... why >> should it be allowed? > > Because it blocks experiment and innovation by people within the > organization. In general, that's a bad thing for any organization > that wishes to develop and grow. The precautionary approach is > the enemy of progress. I think the flaw in this reasoning is that it assumes the raison detre of most organizational networks is "innovation" and "experiment", when it is not. Their raison detre is to help the organization in the process of making profit. In practice, this means allowing some of their employes doing email, surf the web, instant messaging and so on. If they are able to do this, then their network has served its purpose. And good security practice is "if you don't *need* to do it, then *don't*". So if the org has decided not to deploy v6 for the time being (the reason being irrelevant in this case), it's IMO perfectly understandable that they block it. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian.e.carpenter@gmail.com Thu Jan 13 15:56:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D30D3A6C12 for ; Thu, 13 Jan 2011 15:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 6HTl3XVqaUlJ for ; Thu, 13 Jan 2011 15:56:05 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6C5313A6C22 for ; Thu, 13 Jan 2011 15:56:05 -0800 (PST) Received: by vws7 with SMTP id 7so814363vws.31 for ; Thu, 13 Jan 2011 15:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BZxwKWG3lVvkFel+EOf3NENWgUz4kETRqHxRJR4QReU=; b=QHUR/QKuLuD9E3O2BZ1cFE1Du5eo6azVSSLeBsyrPX0wCz3UyfgT1WBHnQS6Dx9dug lCbiVV1YQlrsMr7vXqj9ZqQ2FzYXwZY7CSHPW5YmfptrDMtVquHEU3JN6G7chnS7ITGG VvdsTllRAK+GGjpBUlji3kyHQn511bHeVLPF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QH7lA/V4AXrurMsdXWYKsQ7h0KTQoz2f9BBxFEyQxF5BnWMOiCOdwomOlNlt6TCtIn xzkU987wJPHhe3qxEPJq8kSB5F6KqOumT9cWl2IPuTVpnu+WalYJDjPtioCEyTlZURc2 rPPpAXAEwlvreeLaO5kjyASSmobWzldhgY9Ac= Received: by 10.220.112.18 with SMTP id u18mr46282vcp.261.1294963108640; Thu, 13 Jan 2011 15:58:28 -0800 (PST) Received: from [10.1.1.3] ([121.98.190.33]) by mx.google.com with ESMTPS id k39sm239889vcr.2.2011.01.13.15.58.25 (version=SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 15:58:27 -0800 (PST) Message-ID: <4D2F919A.10103@gmail.com> Date: Fri, 14 Jan 2011 12:58:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> <4D2B81B9.3070608@gmail.com> <4D2F5BC4.60508@gont.com.ar> In-Reply-To: <4D2F5BC4.60508@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:56:06 -0000 On 2011-01-14 09:08, Fernando Gont wrote: > On 10/01/2011 07:01 p.m., Brian E Carpenter wrote: > >>> Well, if the firewall is meant to allow only traffic that is deemed as >>> necessary, and the organization has not decided to deploy v6... why >>> should it be allowed? >> Because it blocks experiment and innovation by people within the >> organization. In general, that's a bad thing for any organization >> that wishes to develop and grow. The precautionary approach is >> the enemy of progress. > > I think the flaw in this reasoning is that it assumes the raison detre > of most organizational networks is "innovation" and "experiment", when > it is not. Their raison detre is to help the organization in the process > of making profit. In the long term, both profit and even survival of a company depend on innovation. I think it's well established that exclusive pursuit of the current quarter's profit is the best way to miss seeing both massive opportunities and massive roadblocks. In our world, telcos missing the Internet is a great example worth untold billions. So philosophically, we disagree. In terms of standards recommendations, whether from the IETF or from NIST, either extreme should be avoided. If you want to allow innovation, do this:... If you want to block innovation, do that:... Enough said, I think. Brian In practice, this means allowing some of their > employes doing email, surf the web, instant messaging and so on. If they > are able to do this, then their network has served its purpose. > > And good security practice is "if you don't *need* to do it, then > *don't*". So if the org has decided not to deploy v6 for the time being > (the reason being irrelevant in this case), it's IMO perfectly > understandable that they block it. > > Thanks, From fernando.gont.netbook.win@gmail.com Thu Jan 13 22:21:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212463A6956 for ; Thu, 13 Jan 2011 22:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 WxJrbm2+oTdg for ; Thu, 13 Jan 2011 22:21:43 -0800 (PST) Received: from mail-yi0-f67.google.com (mail-yi0-f67.google.com [209.85.218.67]) by core3.amsl.com (Postfix) with ESMTP id 1D5413A6AA3 for ; Thu, 13 Jan 2011 22:21:42 -0800 (PST) Received: by yib18 with SMTP id 18so941399yib.2 for ; Thu, 13 Jan 2011 22:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=WgdIs5xCao0YtuKEp1X1lxmMUrFqy6/ldhsiK2TfstU=; b=POhEvSx69v3NthSbkYQgkUtmFYdq8n2yqqwnF3sQZ7HxsIg2BfbSMnPs6qtAronvtc gX96j7zqja1KYors6ROC4oEAOpXXSaT53e1dWbUkDQVBsXPBe3Xs8dBiXrKTLQ+JCKxI L62OAhGz0VTSGoNPzf9ei/64psWkb0UbtxJ6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=tfecui8x5kvT90Gu6l/93DLwMxjjFsWVp97omtIzp2GzIh2/6LhZSxSGSum6RnAVTK c1pYUA35EylfHb+Ws8ZplCJZhqWLFKqEqR/vkAqZ/rLIxYWUq3nYrKDRLEoVJsDqv3d4 xiwPatX2azZ5EbyEBxB4+zmD4pDPsc7j2AlF0= Received: by 10.236.108.41 with SMTP id p29mr799916yhg.21.1294986247098; Thu, 13 Jan 2011 22:24:07 -0800 (PST) Received: from [192.168.2.7] (11-130-17-190.fibertel.com.ar [190.17.130.11]) by mx.google.com with ESMTPS id i21sm590759yha.41.2011.01.13.22.24.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 22:24:05 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2FEBFF.4040809@gont.com.ar> Date: Fri, 14 Jan 2011 03:23:59 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> <4D2B81B9.3070608@gmail.com> <4D2F5BC4.60508@gont.com.ar> <4D2F919A.10103@gmail.com> In-Reply-To: <4D2F919A.10103@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 06:21:44 -0000 On 13/01/2011 08:58 p.m., Brian E Carpenter wrote: >> I think the flaw in this reasoning is that it assumes the raison detre >> of most organizational networks is "innovation" and "experiment", when >> it is not. Their raison detre is to help the organization in the process >> of making profit. > > In the long term, both profit and even survival of a company depend > on innovation. Do you expect innovation to be pursued in e.g. commercial department network or the like? The NIST IPV6 document is not "guidelines for deploying v6 in the engineering lab" or the like. It's about IPv6 deployment in general networks. -- And most networks (an administrative office network, marketing department network, whatever) do not pursue networking innovation. That aside, in all fairness one could possibly argue that most "innovation" (in terms of real impact on people's everyday life) has mostly happened at the app layer rather than in the lower layers. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dragoniz3r@gmail.com Fri Jan 14 08:45:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2194528C104 for ; Fri, 14 Jan 2011 08:45:25 -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 7qmcADsTFHLN for ; Fri, 14 Jan 2011 08:45:23 -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 EEFD028C10B for ; Fri, 14 Jan 2011 08:45:22 -0800 (PST) Received: by ewy8 with SMTP id 8so1579102ewy.31 for ; Fri, 14 Jan 2011 08:47:48 -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 :content-transfer-encoding; bh=Y3ECASPfkZbrYWbO2JD9P7Qq3QJFnI9TSgqB1aL8bXY=; b=Lwox1U97S1Be7EGw06RdiNUsKu1O5Vmph6Us34J7P4q0BQ5lzkrSwVfWPsoaF0qz6x Hsq3pPyqDHELHEogTqRZ3p6BAezfiv/HrCi05xtXq3eLV8UMVdjPgndmNQYyEr/JAbKR /zK0+c1iL1qtNMAaU188bpdvEtZxoY2Z/9f2A= 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=qJ/1M7T14R0HF5LaUQXtrmMPs+GbjVMcDL+ISyNtH+Lu7SI6iieX2oF5+K3q0YkMrx ycJyBmYS5Z1KFdW+EUNgCmidiGB/3R0i0VpTbXhg/2nc5cofGkD9561LlncACsg7Hxep xbr5LpOnJXg75DWvVw2XDPO+g6a26OGkD7T1Y= MIME-Version: 1.0 Received: by 10.216.155.75 with SMTP id i53mr1943347wek.27.1295023667845; Fri, 14 Jan 2011 08:47:47 -0800 (PST) Received: by 10.216.244.131 with HTTP; Fri, 14 Jan 2011 08:47:47 -0800 (PST) In-Reply-To: <4D2F919A.10103@gmail.com> References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> <4D2B81B9.3070608@gmail.com> <4D2F5BC4.60508@gont.com.ar> <4D2F919A.10103@gmail.com> Date: Fri, 14 Jan 2011 11:47:47 -0500 Message-ID: From: Josh Rambo To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:45:25 -0000 On Thu, Jan 13, 2011 at 6:58 PM, Brian E Carpenter wrote: > On 2011-01-14 09:08, Fernando Gont wrote: >> On 10/01/2011 07:01 p.m., Brian E Carpenter wrote: >> >>>> Well, if the firewall is meant to allow only traffic that is deemed as >>>> necessary, and the organization has not decided to deploy v6... why >>>> should it be allowed? >>> Because it blocks experiment and innovation by people within the >>> organization. In general, that's a bad thing for any organization >>> that wishes to develop and grow. The precautionary approach is >>> the enemy of progress. >> >> I think the flaw in this reasoning is that it assumes the raison detre >> of most organizational networks is "innovation" and "experiment", when >> it is not. Their raison detre is to help the organization in the process >> of making profit. > > In the long term, both profit and even survival of a company depend > on innovation. I think it's well established that exclusive pursuit > of the current quarter's profit is the best way to miss seeing both massi= ve > opportunities and massive roadblocks. In our world, telcos missing the > Internet is a great example worth untold billions. Unless you can get your management team to buy into this pitch, it doesn't matter what your personal philosophy of innovation is. The fact is that companies exist to make money. If they think innovation will help them do so, then great, but innovation for the sake of innovation is not a pitch that would be accepted at my own place of business, and I doubt I'm alone on that front. > So philosophically, we disagree. In terms of standards recommendations, > whether from the IETF or from NIST, either extreme should be avoided. > > =A0If you want to allow innovation, do this:... > =A0If you want to block innovation, do that:... You've entirely missed the point. I counterpoint with the following alternate phrasing: If you want to allow traffic that your internal infrastructure has not been built to audit and filter, do this: If you want to have a secure network, do that: The NIST isn't advocating "blocking innovation", they're advocating blocking tunneled IPv6 traffic. Blocking innovation is something that, you feel, is a necessary side effect of that. But don't try to construe it as NIST being the big bad guy who's trying to stop you from being creative in your workplace. From brian.e.carpenter@gmail.com Fri Jan 14 13:18:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9350B3A6C91 for ; Fri, 14 Jan 2011 13:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 gS4Gp-SHveVO for ; Fri, 14 Jan 2011 13:18:22 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 66E563A6C89 for ; Fri, 14 Jan 2011 13:18:22 -0800 (PST) Received: by wyf23 with SMTP id 23so3396605wyf.31 for ; Fri, 14 Jan 2011 13:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Fm8Ay8E1P6l1cs2bdtesPXQ1T5zyWLKWF+WD6cwihcU=; b=EUW8t0Onut2jXik56cM84L8jvx9VwJX9gE/T7axn2Lzt57g5UUlzKhVxGFDVwhfKC7 60GpLaHd3gzZgH4DtInlViBdlb0vueBpPbzJ0SxeF2Tgy5G6tu1qbBBhtC2+xj9GhwmF Htie59LJ1o/kF+6ZifTmxLGjZGUZC7GWNxUb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=q2N8a+NWWiiu3Aher5WVCju/wTRFfFj0+5O69kPjxvHXWwTo/t4FNwbx8potymcWo7 qYNzIWZKYEuyPox/2fag1lW6XpSLT0xwqXHElhTzS7wHW7EkMbTB9xUgkB/tPJInHtrL CFrEz7QI9KMEPaeTXQ2mVrjLkBAJTXIJpXoeg= Received: by 10.227.132.209 with SMTP id c17mr1193511wbt.135.1295040047618; Fri, 14 Jan 2011 13:20:47 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id 7sm921473wet.0.2011.01.14.13.20.42 (version=SSLv3 cipher=RC4-MD5); Fri, 14 Jan 2011 13:20:45 -0800 (PST) Message-ID: <4D30BE2A.1030401@gmail.com> Date: Sat, 15 Jan 2011 10:20:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Josh Rambo References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> <4D2B81B9.3070608@gmail.com> <4D2F5BC4.60508@gont.com.ar> <4D2F919A.10103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 21:18:23 -0000 On 2011-01-15 05:47, Josh Rambo wrote: ... >> If you want to allow innovation, do this:... >> If you want to block innovation, do that:... > > You've entirely missed the point. I counterpoint with the following > alternate phrasing: > > If you want to allow traffic that your internal infrastructure has not > been built to audit and filter, do this: > If you want to have a secure network, do that: Obviously, serious standards text from any SDO should not be at either of these extremes. But it should present the alternatives fairly, so that an individual network operator can decide according to their own needs. The NIST text doesn't do that, and the IETF can do better. Brian From dragoniz3r@gmail.com Fri Jan 14 14:07:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D663A6C97 for ; Fri, 14 Jan 2011 14:07:59 -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 9rVKvZrGtCHd for ; Fri, 14 Jan 2011 14:07:58 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 42AC63A6BD0 for ; Fri, 14 Jan 2011 14:07:57 -0800 (PST) Received: by wyf23 with SMTP id 23so3446224wyf.31 for ; Fri, 14 Jan 2011 14:10:24 -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 :content-transfer-encoding; bh=oF3aEq+w1BfFkxOaO13Jk48JF08Bd3GJ5ZlEHc/9ev8=; b=vM5VoeBQ0AGN44JqG4nqVTUdDMJBrF8wfP/llJtLfYz1C2kp136/L3CojdSZUaEVVu Yi+ClwYVSR1pHj8UqRivAdZzZrlXrBMh3PCYd2ROzUI7pu4BrsmsIj4a1nOmKmtlzubH 51fERa2FdJLhNpMwrUPdd8ufnQ6AFqV7Kj/0E= 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=MXy3tsrxJfh6Nb0hY9/dM82ZAixarsIp0dbrs9M+kaMX9UDT7ZPRY3phOZj1IsRMfR Co7PipuRlDjsxwM8dVJQDS+mLLLV0MtdhbU5DwgZP5TU7/Ctw3cEORmeWAPMcmx7sVrB Bj84TFSTNzMDZoZ0McXNa4ec4B+QVmGGCkUUg= MIME-Version: 1.0 Received: by 10.216.154.8 with SMTP id g8mr39075wek.12.1295042775163; Fri, 14 Jan 2011 14:06:15 -0800 (PST) Received: by 10.216.244.131 with HTTP; Fri, 14 Jan 2011 14:06:15 -0800 (PST) In-Reply-To: <4D30BE2A.1030401@gmail.com> References: <4D23F852.20708@bogus.com> <4D24CD6C.1090209@gmail.com> <4D2B3DCE.7010102@gont.com.ar> <4D2B81B9.3070608@gmail.com> <4D2F5BC4.60508@gont.com.ar> <4D2F919A.10103@gmail.com> <4D30BE2A.1030401@gmail.com> Date: Fri, 14 Jan 2011 17:06:15 -0500 Message-ID: From: Josh Rambo To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: NIST IPv6 document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 22:07:59 -0000 On Fri, Jan 14, 2011 at 4:20 PM, Brian E Carpenter wrote: > On 2011-01-15 05:47, Josh Rambo wrote: > ... >>> =A0If you want to allow innovation, do this:... >>> =A0If you want to block innovation, do that:... >> >> You've entirely missed the point. I counterpoint with the following >> alternate phrasing: >> >> If you want to allow traffic that your internal infrastructure has not >> been built to audit and filter, do this: >> If you want to have a secure network, do that: > > Obviously, serious standards text from any SDO should not > be at either of these extremes. But it should present the > alternatives fairly, so that an individual network operator > can decide according to their own needs. The NIST text > doesn't do that, and the IETF can do better. You are correct that both wordings are overly inflammatory, but my real point is what followed the part you quoted, wherein I explained NIST's motivations. I agree with you that the IETF should spell out some alternative deployment scenarios in matters such as these. From joelja@bogus.com Sun Jan 16 06:12:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADFF3A6C5D; Sun, 16 Jan 2011 06:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_27=0.6, 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 fSlPoNqtVaNg; Sun, 16 Jan 2011 06:12:06 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 56BED3A6BD7; Sun, 16 Jan 2011 06:12:05 -0800 (PST) Received: from joelja-mac.local (62-50-219-60.client.stsn.net [62.50.219.60]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0GEETot091797 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 16 Jan 2011 14:14:32 GMT (envelope-from joelja@bogus.com) Message-ID: <4D32D58A.8020605@bogus.com> Date: Sun, 16 Jan 2011 12:24:58 +0100 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ed Jankiewicz References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04B941@PLSWM12A.ad.sprint.com> <4D2B51A8.3050405@sri.com> In-Reply-To: <4D2B51A8.3050405@sri.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" , IPv6 Ops WG Subject: Re: [v6ops] [Int-area] draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 14:12:07 -0000 On 1/10/11 7:36 PM, Ed Jankiewicz wrote: > upon reflection, I agree that it would be unnecessary and inappropriate > to generate a petition within IETF. The process is built on consensus, > not name-checking. > > Suffice it to say I support this work being discussed within Intarea and > v6ops, including time on the agenda in Prague, and eventual adoption as > a WG or IAB publication. > > I also agree with a previous comment that this draft should be kept very > simple with a small number of essential references, e.g. to the IPv6 > Node Requirements (as revised). That is the current best definition of > what is "required" for IPv6. If it is insufficient as is, and needs to > be replaced by a standards track definition, that would take some > effort, and that can be discussed as well. I would prefer that we > publish the current RFC 4294 update draft before we open that can of worms. > > The question of parity is very complex and difficult to define. more to the point consensus on what constitutes is a discussion that's pretty easy to rathole. A statement that is simplistic and open to interpretation may not achieve all that you want at the same time the resulting statement may be more readily achievable and we have documents like for example the cpe drafts to addresses. Idealy this document is: 1. discussed now both here and the int-area. 2. presented in prague 3. accepted as a wg document where we deem appropiate 4. last called > The > concerns that some things are not directly comparable, or that there are > things that have become accepted in IPv4 that some don't want to > replicate in IPv6, versus the sense that the lack of any feature > (standard or not) will be a disincentive to IPv6 adoption - it's not > clear how these can be reconciled. > > On 1/10/2011 11:29 AM, George, Wes E [NTK] wrote: >> Shortened the subject line a bit >> >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf >> Of Ed Jankiewicz >> Sent: Friday, January 07, 2011 3:11 PM >> To: int-area@ietf.org; IPv6 Operations >> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new >> draft-george-ipv6-required >> >>> I agree so strenuously that I half-jokiningly would like to be listed >>> as a >>> coauthor, and I bet there are a>number of other folks on these lists >>> that >>> would feel the same way. Perhaps a better suggestion would be >>> to>include an >>> appendix with the name and affiliation of everyone who is willing to >>> sign-on >>> to ratify this>recommendation. >> [WES] If I'm interpreting this right, this would sort of be like a >> petition >> with lots of signatures, or one of those open letters to the >> $government_functionary signed by lots of "important people" you see >> published >> in full-page newspaper ads? I assume that this is generally a way of more >> concretely documenting support for this proposal beyond the IETF's >> standard >> rough consensus in a WG meeting or on-list. >> I'm open to this, but is there any precedent for it? Do we want to set a >> precedent that if we *really* mean something, we take steps to more >> thoroughly >> document that support within a draft? Those in support can already >> have their >> support immortalized in the pages of the email list archives complete >> with >> their choice of editorialization... >> And regarding affiliation - IETF typically shies away from making a >> big deal >> of affiliation, since most of its members are not really authorized to >> represent the company that pays the bills in any official public >> capacity. >> Yes, they are representatives of that company, but they are mostly >> speaking >> for themselves with the interests of their company informing those >> comments - >> it's not like there's a way to get every email and comment at the mic >> approved >> by PR first :-) >> >> An IAB statement of support would perhaps be a good way to add weight >> to this >> recommendation, but I'm content to start with statements of support >> for WG >> adoption and advancement to RFC status and see where it goes from there. >> >> Wes George > From joelja@bogus.com Sun Jan 16 06:12:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56ECC3A6C5E; Sun, 16 Jan 2011 06:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 PBSuUkSWHUPM; Sun, 16 Jan 2011 06:12:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 252BE3A6D43; Sun, 16 Jan 2011 06:12:38 -0800 (PST) Received: from joelja-mac.local (62-50-219-60.client.stsn.net [62.50.219.60]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0GEEkfO091804 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 16 Jan 2011 14:14:50 GMT (envelope-from joelja@bogus.com) Message-ID: <4D32E673.8010409@bogus.com> Date: Sun, 16 Jan 2011 13:37:07 +0100 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> In-Reply-To: <4D2B711F.9000705@gont.com.ar> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 14:12:40 -0000 On 1/10/11 9:50 PM, Fernando Gont wrote: > On 10/01/2011 05:43 p.m., Mark Smith wrote: > >>>> The e2e transparency that IPv4 had lost, and IPv6 restores, is >>>> ADDRESS transparency: source and destination addresses seen by a >>>> destination are the same as those set by the source. >>> >>> IPv6 restores this to the extent that NAT66 is not deployed. My take is >>> that NAT66 *will* be deployed. >> >> How do you know? What evidence do you have? > > Talking to vendors, some operators, etc. > > Google for "ipv6 nat" or the like, and you'll see some of the people > that are publicly interested in this feature. It's a basic and necessary feature of ipv6-supporting loadbalancer devices. Given that header rewriting, and state-tracking are basic firewall functions for v4 and v6 you really aren't very far conceptually or implementation-wise from a nat66 feature. The question is what's it a point solution for. If the problem is, "you gave me one ip address and i need more than that" something is badly wrong. > > >>> -- So, I don't think you can rely IPv6 on >>> restoring "address transparency". >>> >>>> - This is needed >>>> in particular for Header Authentication of IPsec. >>> >>> But you can still use UDP encapsulation. >> >> UDP encapsulation of IPsec is a work around, specifically to get around >> the problems of lack of IPv4 address transparency i.e. NAT. It isn't an >> acceptable answer when NAT doesn't need to exist. > > You're assuming that the only motivation to have NATs is address > exhaustion -- but IMO, it isn't. > > Thanks, From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jan 16 12:50:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EDC3A6E5A; Sun, 16 Jan 2011 12:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 3CWA7FzKy6il; Sun, 16 Jan 2011 12:50:43 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 4726B3A6E60; Sun, 16 Jan 2011 12:50:43 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PeZav-0004Fv-FK; Mon, 17 Jan 2011 07:23:01 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id AEF603B31E; Mon, 17 Jan 2011 07:23:00 +1030 (CST) Date: Mon, 17 Jan 2011 07:22:58 +1030 From: Mark Smith To: Joel Jaeggli Message-ID: <20110117072258.35fe843d@opy.nosense.org> In-Reply-To: <4D32E673.8010409@bogus.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 20:50:45 -0000 On Sun, 16 Jan 2011 13:37:07 +0100 Joel Jaeggli wrote: > On 1/10/11 9:50 PM, Fernando Gont wrote: > > On 10/01/2011 05:43 p.m., Mark Smith wrote: > > > >>>> The e2e transparency that IPv4 had lost, and IPv6 restores, is > >>>> ADDRESS transparency: source and destination addresses seen by a > >>>> destination are the same as those set by the source. > >>> > >>> IPv6 restores this to the extent that NAT66 is not deployed. My take is > >>> that NAT66 *will* be deployed. > >> > >> How do you know? What evidence do you have? > > > > Talking to vendors, some operators, etc. > > > > Google for "ipv6 nat" or the like, and you'll see some of the people > > that are publicly interested in this feature. > > It's a basic and necessary feature of ipv6-supporting loadbalancer devices. > I don't think that is necessarily the case either. A group of hosts with the same downstream address (the global one announced in DNS), and a router-type device (i.e. isn't assigned the global address announced in DNS) spreading traffic across them such that the same session landed on the same downstream host would provide "load balancing" without NAT - effectively a more advanced version of anycast where all hosts are active, and there is more intelligence in the selection of to which anycast host the traffic is sent by the upstream router, spreading the load. > Given that header rewriting, and state-tracking are basic firewall > functions for v4 and v6 you really aren't very far conceptually or > implementation-wise from a nat66 feature. > > The question is what's it a point solution for. If the problem is, "you > gave me one ip address and i need more than that" something is badly wrong. > > > > > > >>> -- So, I don't think you can rely IPv6 on > >>> restoring "address transparency". > >>> > >>>> - This is needed > >>>> in particular for Header Authentication of IPsec. > >>> > >>> But you can still use UDP encapsulation. > >> > >> UDP encapsulation of IPsec is a work around, specifically to get around > >> the problems of lack of IPv4 address transparency i.e. NAT. It isn't an > >> acceptable answer when NAT doesn't need to exist. > > > > You're assuming that the only motivation to have NATs is address > > exhaustion -- but IMO, it isn't. > > > > Thanks, > From jbates@brightok.net Mon Jan 17 06:37:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A223A6F37; Mon, 17 Jan 2011 06:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] 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 xkTi4vcMCFpa; Mon, 17 Jan 2011 06:37:04 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id DC7383A6E62; Mon, 17 Jan 2011 06:37:03 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0HEdRTe008684; Mon, 17 Jan 2011 08:39:27 -0600 (CST) Message-ID: <4D34549F.4020601@brightok.net> Date: Mon, 17 Jan 2011 08:39:27 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> In-Reply-To: <20110117072258.35fe843d@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:37:04 -0000 On 1/16/2011 2:52 PM, Mark Smith wrote: >> It's a basic and necessary feature of ipv6-supporting loadbalancer devices. >> > > I don't think that is necessarily the case either. A group of hosts > with the same downstream address (the global one announced in DNS), and > a router-type device (i.e. isn't assigned the global address announced > in DNS) spreading traffic across them such that the same session landed > on the same downstream host would provide "load balancing" without NAT - > effectively a more advanced version of anycast where all hosts are > active, and there is more intelligence in the selection of to which > anycast host the traffic is sent by the upstream router, spreading the > load. Current methods commonly used are NAT and DSR. v6 implementations of traditional devices have been using NAT only, and still working on DSR support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR support. By strictest definition, NAT66 has been implemented and deployed already. It is not so much NAT66 which is the danger, but where it is deployed. Having NAT66 in CPE for residential users would be extremely bad. Special use cases, or environments where the breaking of communications (certain corporate firewalls), should be considered completely acceptable. IPv6 gives us the ability to not REQUIRE NAT66, but it does not remove the market demand for NAT66, though it does lessen it. Jack From remi.despres@free.fr Mon Jan 17 08:23:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039313A6F51; Mon, 17 Jan 2011 08:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 lYfEgydFYZ7U; Mon, 17 Jan 2011 08:23:12 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id D45CE3A6E4D; Mon, 17 Jan 2011 08:23:11 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id AFE31700009C; Mon, 17 Jan 2011 17:25:45 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 0E79E700008E; Mon, 17 Jan 2011 17:25:44 +0100 (CET) X-SFR-UUID: 20110117162545593.0E79E700008E@msfrf2102.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: <4D34549F.4020601@brightok.net> Date: Mon, 17 Jan 2011 17:25:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:23:13 -0000 Le 17 janv. 2011 =E0 15:39, Jack Bates a =E9crit : > On 1/16/2011 2:52 PM, Mark Smith wrote: >>> It's a basic and necessary feature of ipv6-supporting loadbalancer = devices. >>> > >> I don't think that is necessarily the case either. A group of hosts >> with the same downstream address (the global one announced in DNS), = and >> a router-type device (i.e. isn't assigned the global address = announced >> in DNS) spreading traffic across them such that the same session = landed >> on the same downstream host would provide "load balancing" without = NAT - >> effectively a more advanced version of anycast where all hosts are >> active, and there is more intelligence in the selection of to which >> anycast host the traffic is sent by the upstream router, spreading = the >> load. >=20 > Current methods commonly used are NAT and DSR. v6 implementations of = traditional devices have been using NAT only, and still working on DSR = support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR = support. >=20 > By strictest definition, NAT66 has been implemented and deployed = already. For clarification, could you be more specific: - NAT66 according to which specification? - where (for example)? >=20 > It is not so much NAT66 which is the danger, but where it is deployed. = Having NAT66 in CPE for residential users would be extremely bad. Full agreement. > Special use cases, or environments where the breaking of = communications (certain corporate firewalls), should be considered = completely acceptable. IPv6 gives us the ability to not REQUIRE NAT66, = but > it does not remove the market demand for NAT66, This demand you see may not remain when: - It is better understood that: . Firewalls can filter restrict reachability as efficiently without = NATs as with them. . Privacy can be achieved by other means than NATs and can be lost even = across NATs. . More complete multihoming support is made available without NATs than = feasible across NATs=20 BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) = NPTv6 (being noted that the latter doesn't improve privacy)? Regards, RD =20 > though it does lessen it. >=20 >=20 > Jack >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jbates@brightok.net Mon Jan 17 08:47:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5751E28C112; Mon, 17 Jan 2011 08:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ED0itwM3Pd3p; Mon, 17 Jan 2011 08:47:18 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 8C42828C0F6; Mon, 17 Jan 2011 08:47:18 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0HGnhlp015195; Mon, 17 Jan 2011 10:49:43 -0600 (CST) Message-ID: <4D347327.9040501@brightok.net> Date: Mon, 17 Jan 2011 10:49:43 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> In-Reply-To: <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:47:19 -0000 On 1/17/2011 10:25 AM, Rémi Després wrote: >> Current methods commonly used are NAT and DSR. v6 implementations of traditional devices have been using NAT only, and still working on DSR support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR support. >> >> By strictest definition, NAT66 has been implemented and deployed already. > > For clarification, could you be more specific: > - NAT66 according to which specification? > - where (for example)? I thought this was answered. It's deployed by load balancers which use NAT. >> it does not remove the market demand for NAT66, > > This demand you see may not remain when: > - It is better understood that: > . Firewalls can filter restrict reachability as efficiently without NATs as with them. > . Privacy can be achieved by other means than NATs and can be lost even across NATs. > . More complete multihoming support is made available without NATs than feasible across NATs > I agree, but I suspect the demand will remain for a long time, though at a much smaller market pressure than we've had in v4. Operations community still argues over NAPT uses within a firewall over state-only firewalls. Discussion with a variety of corporate admins has also shown a split between those who welcome global addressing internally (open educational networks) and those who wish to continue utilizing NAPT (draconian corporate admins). > BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) NPTv6 (being noted that the latter doesn't improve privacy)? NAPTv6 in corporate and load balancers. Jack Bates From remi.despres@free.fr Mon Jan 17 09:24:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE36628C1A2; Mon, 17 Jan 2011 09:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_50=0.001, 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 9PDYBr1EBrJC; Mon, 17 Jan 2011 09:24:29 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id C342428C199; Mon, 17 Jan 2011 09:24:28 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id CBF0C7000091; Mon, 17 Jan 2011 18:27:02 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 727807000092; Mon, 17 Jan 2011 18:27:02 +0100 (CET) X-SFR-UUID: 20110117172702468.727807000092@msfrf2102.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: <4D347327.9040501@brightok.net> Date: Mon, 17 Jan 2011 18:27:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:24:30 -0000 Le 17 janv. 2011 =E0 17:49, Jack Bates a =E9crit : > On 1/17/2011 10:25 AM, R=E9mi Despr=E9s wrote: >>> Current methods commonly used are NAT and DSR. v6 implementations of = traditional devices have been using NAT only, and still working on DSR = support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR = support. >>>=20 >>> By strictest definition, NAT66 has been implemented and deployed = already. >>=20 >> For clarification, could you be more specific: >> - NAT66 according to which specification? >> - where (for example)? >=20 > I thought this was answered. It's deployed by load balancers which use = NAT. - An informational document on such a deployment would IMHO be useful. - =46rom your answer below, one can derive that the NAT66 spec you refer = to is NAPTv6 (for which there is so far no draft), and not = draft-mrw-nat66 (the only draft so far that specifies a NAT66). =20 =20 >>> it does not remove the market demand for NAT66, >> ... >> BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) = NPTv6 (being noted that the latter doesn't improve privacy)? >=20 > NAPTv6 in corporate and load balancers. Thanks. IMHO, a lot of confusion will be avoided if "NAPTv6" is used rather than = "NAT66" when what is meant is NAPTv6. Regards, RD From fred@cisco.com Mon Jan 17 09:52:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA74028C1E7; Mon, 17 Jan 2011 09:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 cy1qoiO+cB8e; Mon, 17 Jan 2011 09:52:10 -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 7999D28C1A2; Mon, 17 Jan 2011 09:52:06 -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: AvsEAH8RNE2rR7Hu/2dsb2JhbACkU3OoQZkfhVAEhHCGL4Mk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 17 Jan 2011 17:54:41 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0HHsaOQ018286; Mon, 17 Jan 2011 17:54:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 17 Jan 2011 09:54:41 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 17 Jan 2011 09:54:41 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Mon, 17 Jan 2011 09:54:26 -0800 Message-Id: <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:52:13 -0000 On Jan 17, 2011, at 9:27 AM, R=E9mi Despr=E9s wrote: >=20 > Le 17 janv. 2011 =E0 17:49, Jack Bates a =E9crit : >=20 >> On 1/17/2011 10:25 AM, R=E9mi Despr=E9s wrote: >>>> Current methods commonly used are NAT and DSR. v6 implementations = of traditional devices have been using NAT only, and still working on = DSR support. A quick search shows IPVS (linux) for IPv6 with both NAT = and DR support. >>>>=20 >>>> By strictest definition, NAT66 has been implemented and deployed = already. >>>=20 >>> For clarification, could you be more specific: >>> - NAT66 according to which specification? >>> - where (for example)? >>=20 >> I thought this was answered. It's deployed by load balancers which = use NAT. >=20 > - An informational document on such a deployment would IMHO be useful. There's not much to write. It is pretty much standard practice.=20 Case 1: it's literally a NAT; it redirects TCP sessions sent to a common = address to one of a number of servers. How it measures server load = varies; the server may inform it of what it considers its load to be (a = server with a few CPUs might get "loaded" more quickly than one with = many CPUs), the NAT box may try to keep a roughly equal number of TCP = sessions to each of several servers, or the NAT box might try to = maintain roughly equal traffic flow from each of several servers, = redirecting new sessions to whichever server currently has the lowest = load.=20 Case 2: It's an application layer gateway that uses NAT technology to = accomplish its goals. The most common case is HTTP. The ALG may operate = by maintaining a pool of open TCP sessions with each of a set of (or = several discrete sets of) servers, or it may open up new sessions as = needed. In any event, it terminates an incoming HTTP session and goes = through an on/off pattern - it collects a "GET", determines which server = to send that to, obtains (opens or allocates) a TCP session to the = server, forwards the "GET" to the server, and uses NAT techniques to = maintain traffic flow between the server and the client. When the server = terminates the session, it does *not* pass that along; it instead awaits = the next GET. Note that different GET targets may be sent to different = servers or pools of servers. > - =46rom your answer below, one can derive that the NAT66 spec you = refer to is NAPTv6 (for which there is so far no draft), and not = draft-mrw-nat66 (the only draft so far that specifies a NAT66). It could be, but it doesn't have to be. It is solving a different = problem. It is doing data center load balancing, which 6man is very = carefully avoiding looking at in its load balancing draft. >>>> it does not remove the market demand for NAT66, >>> ... >>> BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) = NPTv6 (being noted that the latter doesn't improve privacy)? >>=20 >> NAPTv6 in corporate and load balancers. >=20 > Thanks. > IMHO, a lot of confusion will be avoided if "NAPTv6" is used rather = than "NAT66" when what is meant is NAPTv6. >=20 > Regards, > RD >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From behcetsarikaya@yahoo.com Mon Jan 17 09:57:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA31528C1F6 for ; Mon, 17 Jan 2011 09:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 PJpkOAC7pvNB for ; Mon, 17 Jan 2011 09:57:13 -0800 (PST) Received: from nm11-vm1.bullet.mail.sp2.yahoo.com (nm11-vm1.bullet.mail.sp2.yahoo.com [98.139.91.241]) by core3.amsl.com (Postfix) with SMTP id EE40A28C1F5 for ; Mon, 17 Jan 2011 09:57:12 -0800 (PST) Received: from [98.139.91.62] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2011 17:59:45 -0000 Received: from [98.139.91.4] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2011 17:59:45 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 17 Jan 2011 17:59:45 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 161925.37029.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 98658 invoked by uid 60001); 17 Jan 2011 17:59:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295287184; bh=z6By4QtKzNhPvOBY4hHBxeL+fK3XpISw6uCUgfIfI2I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uq2O+dYrSQPbN/QvjwT09BiQ+jyJhwCh4BHCBoAVeaCL5lARUq4PXkeaTuL7sJxQK5S1fqv/qgy3IYwamhu4oZv0DdrW5TUVJ9HT1WnuPPqT4qeNvdKLOIvwdt31fEqZ81Cr+ksOhWouCBaDVXqvDDqoUVRkhe3L5+HNioN1WOY= 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:Content-Transfer-Encoding; b=GRIHeX5NU3mmSW1gueh3wMRGE3Na6ibtJeo3+1OSVsGektzEd98KHj/xZ+63Tq7rBy5y3qDmOhN7b48nP1qs6Lws6wTz1eWiv14ZMatbL6Cf+IBptKba/CQ08CpAhUdtbH9DJ2fWInarMKvaafeULR6f8X0LvMgUBFOygFasA9M=; Message-ID: <234286.96570.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: 6KPB3EoVM1lOeU_C3_qQomQ3I3LBrqPBNtkTsk5AMg4p.kr 3xWSVSOFU2a4NfoVQIZhVuE5LYvBGWCNpGFX.Rf6FuOV.jW7APOB1VwlUlKk C7QOj9u4rp9hO9vTTV.jrnXamtopVNEyNkCF5LR_amzUJZrJTcQENauWxGOr JZ.avy2aOCSpyM4KIV7wGXFRykh9V6NEW0dsIdmF231GaZUMVpk4QdhJdFSr DVjgitHmtaPFdsJ.IQT8onMsihAwA21ZcJeeed7dA58kZYvA2Ku4LpRa.QST NOk7TKA8mpVmUxayh2hdFpRo4GOeU2wTyI8VKucg11_5S5b2C4FiBqmy1bR2 Jiyv5CUgwKC3UZQD9DUCHKibyfR_qQMvgGY7jTPlIgdI1.EYLTh9lzXzmtwE V7oYBnUbjkjzk Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 17 Jan 2011 09:59:44 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> Date: Mon, 17 Jan 2011 09:59:44 -0800 (PST) From: Behcet Sarikaya To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Jack Bates In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:57:14 -0000 =0A=0A=0A=0AI thought NAT66 which is stateless fits much better into IPv6.= =0A=0A=0A> >>> Current methods commonly used are NAT and DSR. v6 implement= ations of =0A>traditional devices have been using NAT only, and still work= ing on DSR support. =0A>A quick search shows IPVS (linux) for IPv6 with bo= th NAT and DR support.=0A> >>> =0A> >>> By strictest definition, NAT66 has= been implemented and deployed already.=0A> >> =0A> >> For clarification, c= ould you be more specific:=0A> >> - NAT66 according to which specification= ?=0A> >> - where (for example)?=0A> > =0A> > I thought this was answered. I= t's deployed by load balancers which use NAT.=0A> =0A> - An informational = document on such a deployment would IMHO be useful.=0A> - From your answer= below, one can derive that the NAT66 spec you refer to is =0A>NAPTv6 (for= which there is so far no draft), and not draft-mrw-nat66 (the only =0A>dr= aft so far that specifies a NAT66).=0A> =0A> =0A> =0A> >>> it does not = remove the market demand for NAT66,=0A> >> ...=0A> >> BTW, is this demand = you see for (stateful) NAPTv6 or for (stateless) NPTv6 =0A>(being noted th= at the latter doesn't improve privacy)?=0A> > =0A> > NAPTv6 in corporate an= d load balancers.=0A> =0A> Thanks.=0A> IMHO, a lot of confusion will be av= oided if "NAPTv6" is used rather than =0A>"NAT66" when what is meant is N= APTv6.=0A> =0A> Regards,=0A> RD=0A> =0A> =0A> =0A> ________________________= _______________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> http= s://www.ietf.org/mailman/listinfo/v6ops=0A> =0A=0A=0A From fred@cisco.com Mon Jan 17 10:11:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D0A28C136 for ; Mon, 17 Jan 2011 10:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.141 X-Spam-Level: X-Spam-Status: No, score=-110.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 VyrLYzCrGEzJ for ; Mon, 17 Jan 2011 10:11:06 -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 3A74828C13F for ; Mon, 17 Jan 2011 10:11:04 -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: AvsEAHsVNE2rRN+J/2dsb2JhbACkU3OoNJkfhVAEhHCGL4Mk Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 17 Jan 2011 18:13:39 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0HIDYlo010768; Mon, 17 Jan 2011 18:13:38 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 17 Jan 2011 10:13:38 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 17 Jan 2011 10:13:38 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <234286.96570.qm@web111403.mail.gq1.yahoo.com> Date: Mon, 17 Jan 2011 10:13:24 -0800 Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <234286.96570.qm@web111403.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 18:11:15 -0000 On Jan 17, 2011, at 9:59 AM, Behcet Sarikaya wrote: >=20 >=20 >=20 >=20 > I thought NAT66 which is stateless fits much better into IPv6. This is why I ask people for precision in the use of the term. The = current nat66 draft is not a filter, and it is stateless. Read = draft-mrw-nat66. Jack is using the term NAT66 to refer to what we do = with IPv4/IPv4 NAPT, as Remi points out. >>>>> Current methods commonly used are NAT and DSR. v6 implementations = of=20 >> traditional devices have been using NAT only, and still working on = DSR support.=20 >> A quick search shows IPVS (linux) for IPv6 with both NAT and DR = support. >>>>>=20 >>>>> By strictest definition, NAT66 has been implemented and deployed = already. >>>>=20 >>>> For clarification, could you be more specific: >>>> - NAT66 according to which specification? >>>> - where (for example)? >>>=20 >>> I thought this was answered. It's deployed by load balancers which = use NAT. >>=20 >> - An informational document on such a deployment would IMHO be = useful. >> - =46rom your answer below, one can derive that the NAT66 spec you = refer to is=20 >> NAPTv6 (for which there is so far no draft), and not draft-mrw-nat66 = (the only=20 >> draft so far that specifies a NAT66). >>=20 >>=20 >>=20 >>>>> it does not remove the market demand for NAT66, >>>> ... >>>> BTW, is this demand you see for (stateful) NAPTv6 or for = (stateless) NPTv6=20 >> (being noted that the latter doesn't improve privacy)? >>>=20 >>> NAPTv6 in corporate and load balancers. >>=20 >> Thanks. >> IMHO, a lot of confusion will be avoided if "NAPTv6" is used rather = than=20 >> "NAT66" when what is meant is NAPTv6. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jbates@brightok.net Mon Jan 17 10:44:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4234428C1DD for ; Mon, 17 Jan 2011 10:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 9lqGszrOIG-t for ; Mon, 17 Jan 2011 10:44:58 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 8307128C16B for ; Mon, 17 Jan 2011 10:44:58 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0HIlSm6010173; Mon, 17 Jan 2011 12:47:28 -0600 (CST) Message-ID: <4D348EC0.4000801@brightok.net> Date: Mon, 17 Jan 2011 12:47:28 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <234286.96570.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?R=E9mi_Despr=E9?=, IPv6 Operations Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 18:44:59 -0000 On 1/17/2011 12:13 PM, Fred Baker wrote: > This is why I ask people for precision in the use of the term. The > current nat66 draft is not a filter, and it is stateless. Read > draft-mrw-nat66. Jack is using the term NAT66 to refer to what we do > with IPv4/IPv4 NAPT, as Remi points out. Sorry. My mistake. I consider NAT66 (like others will) to be a family of protocols (of which, IPv6 has NPTv6 drafted so far). I should have been more specific, though in practice, a load balancer could utilize NAPTv6, NPTv6, or variations of NAT64/46 (generic termed, not actual draft specification). If the standards/drafts don't support what the vendor needs, this is an area where they will just implement what works. Jack From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 17 12:19:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAF828C132; Mon, 17 Jan 2011 12:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 PUiyDYB-8Vk7; Mon, 17 Jan 2011 12:19:47 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id CE41C3A6F51; Mon, 17 Jan 2011 12:19:46 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pevai-0007Lt-MG; Tue, 18 Jan 2011 06:52:16 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A4DCF3B31E; Tue, 18 Jan 2011 06:52:15 +1030 (CST) Date: Tue, 18 Jan 2011 06:52:15 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110118065215.14f55f5a@opy.nosense.org> In-Reply-To: <4D34549F.4020601@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:19:48 -0000 On Mon, 17 Jan 2011 08:39:27 -0600 Jack Bates wrote: > On 1/16/2011 2:52 PM, Mark Smith wrote: > >> It's a basic and necessary feature of ipv6-supporting loadbalancer devices. > >> > > > I don't think that is necessarily the case either. A group of hosts > > with the same downstream address (the global one announced in DNS), and > > a router-type device (i.e. isn't assigned the global address announced > > in DNS) spreading traffic across them such that the same session landed > > on the same downstream host would provide "load balancing" without NAT - > > effectively a more advanced version of anycast where all hosts are > > active, and there is more intelligence in the selection of to which > > anycast host the traffic is sent by the upstream router, spreading the > > load. > > Current methods commonly used are NAT and DSR. v6 implementations of > traditional devices have been using NAT only, and still working on DSR > support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR > support. > I think that is unfortunate and a missed opportunity. However, I suspect these people haven't been on the other side of those sorts of devices very often, trying to troubleshoot problems through them. They might then appreciate how useful end-to-end transparency between the actual communicating end-nodes is after trying to do that a dozen or so times. > By strictest definition, NAT66 has been implemented and deployed already. > > It is not so much NAT66 which is the danger, but where it is deployed. > Having NAT66 in CPE for residential users would be extremely bad. > Special use cases, or environments where the breaking of communications > (certain corporate firewalls), should be considered completely > acceptable. IPv6 gives us the ability to not REQUIRE NAT66, but it does > not remove the market demand for NAT66, though it does lessen it. > > > Jack > From behcetsarikaya@yahoo.com Mon Jan 17 15:04:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058193A6ED7 for ; Mon, 17 Jan 2011 15:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 qE6ldIqalCTf for ; Mon, 17 Jan 2011 15:04:05 -0800 (PST) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by core3.amsl.com (Postfix) with SMTP id 2F59D28C11A for ; Mon, 17 Jan 2011 15:04:05 -0800 (PST) Received: from [98.139.91.68] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2011 23:06:38 -0000 Received: from [98.139.91.13] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2011 23:06:38 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 17 Jan 2011 23:06:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 209006.64004.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 83055 invoked by uid 60001); 17 Jan 2011 23:06:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295305597; bh=lNQ63qX3Dx2GAKGf5q93CrScRh8/oFiThg+PXtZeN8c=; 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=PUIaa1wVRFtPPxN01VR3E0vKtwmw721zeG9chyz/hIc85VS4kCC1l1zjwJVz7GuZS1ZGkM1sEz8e4dEjruup5TXPBLr7EVT5+lwYoT8O7buF4lAx4DS326cmQvXqOK88bM8CVTKE+EdgkQPuG25OUc1B1pXWvcyKyvvgtg0Vorg= 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=tH5Ewnbm2/Ih3L6EL7D9+OYk+pMjXZpA4zzqejP2pO/lwMA6nqHdd+CtY3giCNvj9G/+Noqs3pZ0fRdna9Lkw5GYj4rr2wQfzxE+uygijxqeRAY5lZb80yd9pVfT8pGf1jCW+4k61Dhz+Hx815IBRo1DoCLwrDWC2SRAYdPjzM8=; Message-ID: <803326.82249.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: X2AV0JEVM1mshs7uU2OqpXysnQwX_kJbxDugOCsg.N2kqWQ ywjppVguUSfHokBgGk81TlHtDW5x7EcEuJyBqXctjWah5cHTOHSwZdgWcgcU 9mWOBUwlBzNJBVmg35P0jmMqBfBjbG.zW0NyWfbJGWOVk3e2v0TJ4Xx_uHLW f36FVDBEodFebQ.TGrVVeA4A48FoFs6TPgwPWbI.gEqGlNe3LSUuNggukFth rHZYSvCCwTIS9ALlgjiWRzMKDqPxSpAh4O1WvDVldu19RVJsKiqurohfGnne 9slXPuwIo6vfBwUvctK_GuaPYeldhOpdSQJLmX50V6y6v63fIGHMaMxz2yC4 HYUQYl4morYW2Ospyz4S1kUqlW9nIAPq.yGsIkhgsz0tAZcAJiuNTvJHgNe4 7FXdaUe4.SjIX Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Mon, 17 Jan 2011 15:06:37 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <234286.96570.qm@web111403.mail.gq1.yahoo.com> <4D348EC0.4000801@brightok.net> Date: Mon, 17 Jan 2011 15:06:37 -0800 (PST) From: Behcet Sarikaya To: Jack Bates In-Reply-To: <4D348EC0.4000801@brightok.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IPv6 Operations Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:04:06 -0000 > On 1/17/2011 12:13 PM, Fred Baker wrote: > > This is why I ask people for precision in the use of the term. The > > current nat66 draft is not a filter, and it is stateless. Read > > draft-mrw-nat66. Jack is using the term NAT66 to refer to what we do > > with IPv4/IPv4 NAPT, as Remi points out. > > Sorry. My mistake. I consider NAT66 (like others will) to be a family of >protocols (of which, IPv6 has NPTv6 drafted so far). I should have been more >specific, though in practice, a load balancer could utilize NAPTv6, NPTv6, or >variations of NAT64/46 (generic termed, not actual draft specification). If the >standards/drafts don't support what the vendor needs, this is an area where >they will just implement what works. > I am curious what do they use for 10. and 192.168 blocks which are standardized? In NAT66, ULAs are used. From remi.despres@free.fr Tue Jan 18 02:48:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A963A6F7C; Tue, 18 Jan 2011 02:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.524, 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 PFXXlqNBohDy; Tue, 18 Jan 2011 02:48:26 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by core3.amsl.com (Postfix) with ESMTP id D7B523A6F6B; Tue, 18 Jan 2011 02:48:25 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 949B8700008D; Tue, 18 Jan 2011 11:51:01 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 02EBC7000088; Tue, 18 Jan 2011 11:51:00 +0100 (CET) X-SFR-UUID: 20110118105101120.02EBC7000088@msfrf2413.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: <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> Date: Tue, 18 Jan 2011 11:50:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 10:48:27 -0000 Fred. That's very much clarifying. Thank you. More comments in line. Le 17 janv. 2011 =E0 18:54, Fred Baker a =E9crit : > On Jan 17, 2011, at 9:27 AM, R=E9mi Despr=E9s wrote : > ... >>>>> By strictest definition, NAT66 has been implemented and deployed = already. >>>>=20 >>>> For clarification, could you be more specific: >>>> - NAT66 according to which specification? >>>> - where (for example)? >>>=20 >>> I thought this was answered. It's deployed by load balancers which = use NAT. >>=20 >> - An informational document on such a deployment would IMHO be = useful. >=20 > There's not much to write. It is pretty much standard practice.=20 >=20 > Case 1: it's literally a NAT; it redirects TCP sessions sent to a = common address to one of a number of servers. How it measures server = load varies; the server may inform it of what it considers its load to = be (a server with a few CPUs might get "loaded" more quickly than one = with many CPUs), the NAT box may try to keep a roughly equal number of = TCP sessions to each of several servers, or the NAT box might try to = maintain roughly equal traffic flow from each of several servers, = redirecting new sessions to whichever server currently has the lowest = load.=20 >=20 > Case 2: It's an application layer gateway that uses NAT technology to = accomplish its goals. The most common case is HTTP. The ALG may operate = by maintaining a pool of open TCP sessions with each of a set of (or = several discrete sets of) servers, or it may open up new sessions as = needed. In any event, it terminates an incoming HTTP session and goes = through an on/off pattern - it collects a "GET", determines which server = to send that to, obtains (opens or allocates) a TCP session to the = server, forwards the "GET" to the server, and uses NAT techniques to = maintain traffic flow between the server and the client. When the server = terminates the session, it does *not* pass that along; it instead awaits = the next GET. Note that different GET targets may be sent to different = servers or pools of servers. It's now clear that: (a) These scenarios differ from classical NAT scenarios (incoming = connections are THE subject, rather than having to be blocked).=20 (b) These NATs, to exercise their load-balancing function, do 1:n = mappings.=20 >> - =46rom your answer below, one can derive that the NAT66 spec you = refer to is NAPTv6 (for which there is so far no draft), and not = draft-mrw-nat66 (the only draft so far that specifies a NAT66). >=20 > It could be, but it doesn't have to be. In my understanding, because NAT mappings of *web-server load balancing* = need to be 1:n (point (b) above), this excludes in IPv6 that the NAT be = an NPTv6. (NPTv6 is inherently 1:1.) Contrary to what I wrote, this point isn't a matter of preference. It's = simply a technical obligation. > It is solving a different problem. > It is doing data center load balancing, which 6man is very carefully = avoiding looking at in its load balancing draft. That's, I guess, where I was confused. The conclusion then seems to be that: - So far, the *data-center load balancing* application isn't described = in any RFC, or even in any draft, but does exist and, in IPv6, uses some = NAT66. - For this application, which inherently needs 1:n mappings, the NAT66 = cannot be NPTv6. - If tunneling between the load balancer and servers would be used = instead of NAT66, load balancing would be achieved without sacrificing = e2e address transparency but this isn't the deployed approach. Regards, RD =20 From remi.despres@free.fr Tue Jan 18 02:56:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B593A6FE3 for ; Tue, 18 Jan 2011 02:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_05=-1.11, 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 nwsOdHWn8aue for ; Tue, 18 Jan 2011 02:56:06 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by core3.amsl.com (Postfix) with ESMTP id 68EB53A6FDB for ; Tue, 18 Jan 2011 02:56:06 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id F0325700008A; Tue, 18 Jan 2011 11:58:42 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id A71997000083; Tue, 18 Jan 2011 11:58:42 +0100 (CET) X-SFR-UUID: 20110118105842684.A71997000083@msfrf2413.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: <4D348EC0.4000801@brightok.net> Date: Tue, 18 Jan 2011 11:58:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91ACC1F5-C971-404C-AB7A-D10F2C5911DE@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <234286.96570.qm@web111403.mail.gq1.yahoo.com> <4D348EC0.4000801@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 10:56:07 -0000 Le 17 janv. 2011 =E0 19:47, Jack Bates a =E9crit : ... > in practice, a load balancer could utilize NAPTv6, NPTv6, Not in my understanding (see my more detailed answer to Fred). For NAT-based data-center load balancing, NAT mappings have to be 1:n =3D>= this excludes NPTv6. RD From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 18 04:31:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F553A6ED0; Tue, 18 Jan 2011 04:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 B+e-p7dZw0rR; Tue, 18 Jan 2011 04:31:29 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 4C58A3A6F2F; Tue, 18 Jan 2011 04:31:29 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PfAl4-0001Ez-AT; Tue, 18 Jan 2011 23:03:58 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 7B2143B335; Tue, 18 Jan 2011 23:03:57 +1030 (CST) Date: Tue, 18 Jan 2011 23:03:57 +1030 From: Mark Smith To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Message-ID: <20110118230357.49ec2b52@opy.nosense.org> In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Operations , IPv6, Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:31:30 -0000 On Tue, 18 Jan 2011 11:50:55 +0100 R=C3=A9mi Despr=C3=A9s wrote: > Fred. > That's very much clarifying. > Thank you. >=20 > More comments in line. >=20 > Le 17 janv. 2011 =C3=A0 18:54, Fred Baker a =C3=A9crit : > > On Jan 17, 2011, at 9:27 AM, R=C3=A9mi Despr=C3=A9s wrote : > > ... > >>>>> By strictest definition, NAT66 has been implemented and deployed al= ready. > >>>>=20 > >>>> For clarification, could you be more specific: > >>>> - NAT66 according to which specification? > >>>> - where (for example)? > >>>=20 > >>> I thought this was answered. It's deployed by load balancers which us= e NAT. > >>=20 > >> - An informational document on such a deployment would IMHO be useful. > >=20 > > There's not much to write. It is pretty much standard practice.=20 > >=20 > > Case 1: it's literally a NAT; it redirects TCP sessions sent to a commo= n address to one of a number of servers. How it measures server load varies= ; the server may inform it of what it considers its load to be (a server wi= th a few CPUs might get "loaded" more quickly than one with many CPUs), the= NAT box may try to keep a roughly equal number of TCP sessions to each of = several servers, or the NAT box might try to maintain roughly equal traffic= flow from each of several servers, redirecting new sessions to whichever s= erver currently has the lowest load.=20 > >=20 > > Case 2: It's an application layer gateway that uses NAT technology to a= ccomplish its goals. The most common case is HTTP. The ALG may operate by m= aintaining a pool of open TCP sessions with each of a set of (or several di= screte sets of) servers, or it may open up new sessions as needed. In any e= vent, it terminates an incoming HTTP session and goes through an on/off pat= tern - it collects a "GET", determines which server to send that to, obtain= s (opens or allocates) a TCP session to the server, forwards the "GET" to t= he server, and uses NAT techniques to maintain traffic flow between the ser= ver and the client. When the server terminates the session, it does *not* p= ass that along; it instead awaits the next GET. Note that different GET tar= gets may be sent to different servers or pools of servers. >=20 > It's now clear that: > (a) These scenarios differ from classical NAT scenarios (incoming connect= ions are THE subject, rather than having to be blocked).=20 > (b) These NATs, to exercise their load-balancing function, do 1:n mapping= s.=20 >=20 > >> - From your answer below, one can derive that the NAT66 spec you refer= to is NAPTv6 (for which there is so far no draft), and not draft-mrw-nat66= (the only draft so far that specifies a NAT66). > >=20 > > It could be, but it doesn't have to be. >=20 > In my understanding, because NAT mappings of *web-server load balancing* = need to be 1:n I don't think NAPT is necessary to achieve that.=20 The fundamental goal of (web-)server "load balancing" is to represent externally a number of internal hosts as though they were a single host with a single address. Anycast achieves sharing a single address among multiple hosts, with the difference being that the load is sent to the host that the routing protocol determines is closest to the traffic source. "load balancing" can be achieved with a few fairly minor architectural modifications - place all the hosts effectively equidistant from the client(s), and have an upstream forwarding device (likely the hop directly before the hosts) use candidate destination host load as the metric to select one of the paths towards one of the hosts for new connections, and ensure all latter traffic for the same session/connection follows the same path towards the same previously selected host. This isn't functionally much different to per-session packet load balancing routers perform today when there are multiple FIB entries for the same destination out different interfaces. > (point (b) above), this excludes in IPv6 that the NAT be an NPTv6. > (NPTv6 is inherently 1:1.) > Contrary to what I wrote, this point isn't a matter of preference. It's s= imply a technical obligation. >=20 > > It is solving a different problem. > > It is doing data center load balancing, which 6man is very carefully av= oiding looking at in its load balancing draft. >=20 > That's, I guess, where I was confused. >=20 > The conclusion then seems to be that: > - So far, the *data-center load balancing* application isn't described in= any RFC, or even in any draft, but does exist and, in IPv6, uses some NAT6= 6. > - For this application, which inherently needs 1:n mappings, the NAT66 ca= nnot be NPTv6. > - If tunneling between the load balancer and servers would be used instea= d of NAT66, load balancing would be achieved without sacrificing e2e addres= s transparency but this isn't the deployed approach. >=20 I don't think tunnelling is necessary between the load balancer and the servers. All that is required is to be able to have the upstream forwarding device uniquely distinguish between the hosts despite them sharing the same IP address. Separate outbound interfaces directly attached to hosts, or separate destination link layer addresses that aren't determined via resolution of the load balanced anycast address would be adequate. (Tunnels is really just a form of the separate outbound interface method.) One method to achieve the separate destination link layer address method would be to have the load balanced anycast address configured on a loopback interface within the servers, and have the servers forward traffic between their external interface and the loopback (and make sure proxy-arp is off). The upstream load balancing forwarding device would use (load-balancing) routes with the hosts' external interface addresses as the next hops. Regards, Mark. From jbates@brightok.net Tue Jan 18 05:34:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458D43A6FE6; Tue, 18 Jan 2011 05:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jozv85H27ccp; Tue, 18 Jan 2011 05:34:00 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 6EC513A6FB6; Tue, 18 Jan 2011 05:34:00 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0IDaRL9003705; Tue, 18 Jan 2011 07:36:27 -0600 (CST) Message-ID: <4D359757.5030409@brightok.net> Date: Tue, 18 Jan 2011 07:36:23 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> In-Reply-To: <20110118230357.49ec2b52@opy.nosense.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:34:01 -0000 On 1/18/2011 6:33 AM, Mark Smith wrote: > > I don't think NAPT is necessary to achieve that. > It's not. There is also DSR (Direct Server Return). However, neither is technically address transparent, as anycasting is anything but transparent in this case. > and ensure all latter > traffic for the same session/connection follows the same path towards > the same previously selected host. With some applications, it's also necessary to forward all traffic from the original sender towards the same selected host. This is usually optimized by only considering hosts with existing open mappings, so it doesn't utilize more memory than your method. One common application which needs this is imap. Depending on the web application and cross server session management, it also may require it. > One method to achieve the separate destination link layer address > method would be to have the load balanced anycast address > configured on a loopback interface within the servers, and have the > servers forward traffic between their external interface and the > loopback (and make sure proxy-arp is off). The upstream load balancing > forwarding device would use (load-balancing) routes with the hosts' > external interface addresses as the next hops. > There is no arp in v6. However, you've described DSR as it currently is. Jack (no coffee yet, so while it makes sense to me, forgive any mistakes) From fred@cisco.com Tue Jan 18 10:15:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C6C3A7075; Tue, 18 Jan 2011 10:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 sZ+svzHjh1tD; Tue, 18 Jan 2011 10:15:37 -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 D9E8B3A6FE2; Tue, 18 Jan 2011 10:15:37 -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: AvsEAOpnNU2rR7Ht/2dsb2JhbACkVHOoNZoJhVAEhG+GL4Mk Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Jan 2011 18:18:15 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IIIAdb017620; Tue, 18 Jan 2011 18:18:15 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 18 Jan 2011 10:18:15 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 18 Jan 2011 10:18:15 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 18 Jan 2011 10:18:00 -0800 Message-Id: <936466CA-1532-4634-A13C-A29BCA71E829@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:15:38 -0000 On Jan 18, 2011, at 2:50 AM, R=E9mi Despr=E9s wrote: > (a) These scenarios differ from classical NAT scenarios (incoming = connections are THE subject, rather than having to be blocked).=20 Well, they differ from NAT scenarios that the IETF has considered. I = would object to the assertion that what you're calling a "traditional = NAT" has as its primary function to block sessions. A Network Address = Translator, in any usage, has as it primary function the translation of = network layer addresses. What you're pointing out is that any stateful = NAT (as opposed to that described in SIIT for example) has a "translated = from" and a "translated to" side and an algorithm by which it creates = its translation state. What you're calling a "traditional NAT" = translates "from" in "inside" domain and doesn't change the "outside" = destination address. A load balancer - which is in no sense a new use of = NAT technology, its just one the IETF hasn't focused on - translates = "from" the great wide world, and the algorithm by which it creates = translation state is more complex. > (b) These NATs, to exercise their load-balancing function, do 1:n = mappings.=20 That is certainly one way to do it. What I have tried to point out is = that there is a class of widely-used products that do.= From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 18 12:53:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCA628C142; Tue, 18 Jan 2011 12:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_BAYES_5x7=0.6] 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 EDl1z3c38MeE; Tue, 18 Jan 2011 12:53:17 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 1870528C156; Tue, 18 Jan 2011 12:53:17 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PfIaX-0005Gt-5S; Wed, 19 Jan 2011 07:25:37 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 7A6F03B31E; Wed, 19 Jan 2011 07:25:36 +1030 (CST) Date: Wed, 19 Jan 2011 07:25:36 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110119072536.6a5c150b@opy.nosense.org> In-Reply-To: <4D359757.5030409@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:53:23 -0000 Hi Jack, On Tue, 18 Jan 2011 07:36:23 -0600 Jack Bates wrote: > On 1/18/2011 6:33 AM, Mark Smith wrote: > > > > I don't think NAPT is necessary to achieve that. > > > It's not. There is also DSR (Direct Server Return). However, neither is > technically address transparent, as anycasting is anything but > transparent in this case. The e2e transparency being talked about is that packets travel between the communication end-points without the end-point identifiers or the payloads being modified i.e. at the layer 3 devices between the end-points packets are conventionally forwarded rather than being both modified and forwarded. There are issues with anycast, mainly because anycast doesn't absolutely uniquely identify one (or both) of the communication end-points. That is no worse than NAT based load balancing. What is better with "anycast LB" is that there is no interference with the packets as they traverse the network. That interference has been the origin of some of the faults I've had to troubleshoot involving NAT based load balancers. My fundamental personal preference would be for people to deploy proper clustered operating systems (i.e. single system image) for their applications such that the server is truely one single system and end-point from the network's point of view, and there is no need to resort to networking tricks within the network to try to simulate that for external clients. That would mean no NAT and no anycast. I realise that may be an ideal, however the closer to that ideal the solutions are the less complexity and unconventional behaviour I as a networking person has to deal with. > > and ensure all latter > > traffic for the same session/connection follows the same path towards > > the same previously selected host. > With some applications, it's also necessary to forward all traffic from > the original sender towards the same selected host. This is usually > optimized by only considering hosts with existing open mappings, so it > doesn't utilize more memory than your method. One common application > which needs this is imap. Depending on the web application and cross > server session management, it also may require it. > > > One method to achieve the separate destination link layer address > > method would be to have the load balanced anycast address > > configured on a loopback interface within the servers, and have the > > servers forward traffic between their external interface and the > > loopback (and make sure proxy-arp is off). The upstream load balancing > > forwarding device would use (load-balancing) routes with the hosts' > > external interface addresses as the next hops. > > > > There is no arp in v6. Sure - proxy-arp was rush used word, I should have used proxy-neighbor discovery. > However, you've described DSR as it currently is. > If DSR is what is described at this web page, then not quite - http://lbwiki.com/index.php/DSR If the load balancer acts more like a router, and the router above it announces the best path towards the anycast LB address, then there is no need for the anycast LB address to be configured on the load balancing router itself. That might sound like a me being pedantic about the difference, however routers already forward packets in the way I'm describing (the difference is the policy applied to forwarding decisions), and therefore makes the networking component simper and more conventional. Regards, Mark. From jbates@brightok.net Tue Jan 18 13:14:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3253A6F58; Tue, 18 Jan 2011 13:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_BAYES_5x7=0.6] 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 eBj7Po84RZkW; Tue, 18 Jan 2011 13:14:04 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 58F253A6E7B; Tue, 18 Jan 2011 13:14:03 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0ILGVmJ001864; Tue, 18 Jan 2011 15:16:31 -0600 (CST) Message-ID: <4D36032E.7020006@brightok.net> Date: Tue, 18 Jan 2011 15:16:30 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> In-Reply-To: <20110119072536.6a5c150b@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:14:05 -0000 On 1/18/2011 2:55 PM, Mark Smith wrote: > My fundamental personal preference would be for people to deploy proper > clustered operating systems (i.e. single system image) for their > applications such that the server is truely one single system and > end-point from the network's point of view, and there is no need to > resort to networking tricks within the network to try to simulate that > for external clients. That would mean no NAT and no anycast. I realise > that may be an ideal, however the closer to that ideal the solutions > are the less complexity and unconventional behaviour I as a networking > person has to deal with. While I agree, I've yet to see a cost effective clustering mechanism for proper load distribution for simple things such as http/smtp/imap. This may be my own ignorance of current clustering functionality. > If the load balancer acts more like a router, and the router above it > announces the best path towards the anycast LB address, then there is > no need for the anycast LB address to be configured on the load > balancing router itself. That might sound like a me being pedantic > about the difference, however routers already forward packets in the > way I'm describing (the difference is the policy applied to forwarding > decisions), and therefore makes the networking component simper and more > conventional. I believe you are talking about my original mechanism for load balancing, which was to utilize routing protocols on the servers to announce to the router that a server was available. In general principle, it was effective, but only on a per flow basis (standard flow based balancing of routers insured that a connection held to a single server so long as it was active). I didn't see any options in current routers to support utilizing a single path for all packets from a source (required for when current state is only stored on one server and not shared by all servers). This last part was the deciding point for me to shift to DSR with a specialized load balancer. That being said, there are several things that NAT can do, which DSR cannot. This is one reason NAT is still often deployed over DSR in load balancing hardware. This has been magnified with the introduction of IPv6 to large scale production networks, where there is a need to run mixed environments supporting v6->v6 v6->v4 v4->v6 v4->v4 depending on the systems supported and the IP protocols used both public and internal. Jack From fred@cisco.com Tue Jan 18 13:46:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D3628C0FC for ; Tue, 18 Jan 2011 13:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 1wRlvC4INwnr for ; Tue, 18 Jan 2011 13:46:14 -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 55C5D28C0E0 for ; Tue, 18 Jan 2011 13:46:14 -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: AvsEAKmZNU2rRN+K/2dsb2JhbACkXXOoJ5o3hVAEhG+GL4Mk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2011 21:48:52 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0ILmldJ007250; Tue, 18 Jan 2011 21:48:52 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 18 Jan 2011 13:48:52 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 18 Jan 2011 13:48:52 -0800 From: Fred Baker Date: Tue, 18 Jan 2011 13:48:38 -0800 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: [v6ops] draft-ietf-v6ops-v4v6tran-framework WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:46:15 -0000 Oops. I managed to send this to v6ops@ops.ietf.org instead of = v6ops@ietf.org. This is to initiate a two week working group last call of=20 http://tools.ietf.org/html/draft-ietf-v6ops-v4v6tran-framework "Framework for IP Version Transition Scenarios", Brian Carpenter, = Sheng Jiang, Victor Kuarsingh, 30-Nov-10 Please read it now. If you find nits (spelling errors, minor suggested = wording changes, etc), comment to the authors; if you find greater = issues, such as disagreeing with a statement or finding additional = issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. Note that there is one outstanding update, per http://www.ietf.org/mail-archive/web/v6ops/current/msg06239.html This and any other comments that come in will be wrapped up in a = post-WGLC update.= From ek@google.com Tue Jan 18 16:44:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107D03A6FDB for ; Tue, 18 Jan 2011 16:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KXKnIt-q8hyq for ; Tue, 18 Jan 2011 16:44:40 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5A1503A6DB6 for ; Tue, 18 Jan 2011 16:44:40 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p0J0lIHG001413 for ; Tue, 18 Jan 2011 16:47:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295398038; bh=yKLngDS8L0v525ztj7m6TDbsK+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=l26DPBxt/poo5i5ScnMF5ab5Owa+XYDXZpPYDfgZn7pQWxomXHEHZND0ZecrEay0X SXvFe3WNCOBZgyZG1WAKg== Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by kpbe18.cbf.corp.google.com with ESMTP id p0J0jtFs000941 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 16:47:16 -0800 Received: by qyk34 with SMTP id 34so3605585qyk.10 for ; Tue, 18 Jan 2011 16:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IFGfe+DmQcS0Q2ghQXBpcTfDCGtA1Vy848YO3d3hVUg=; b=VM/lLrzEppI700Fj0BOlBKRCdApjCV5yIkQJWxk2+/qS9+ZvUA8ENj0RPGiC7zxWyq MKs3Zs63+wjJBeJjfpLA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n+cGZ1PNiUiXlJuHXCluJKWtcfOumXhj5JutIt0sWEJDhHd04y+tyQBS1wg2FMA600 qiJJBbAxs4QTQd65HgdQ== MIME-Version: 1.0 Received: by 10.229.97.68 with SMTP id k4mr40353qcn.29.1295398036647; Tue, 18 Jan 2011 16:47:16 -0800 (PST) Received: by 10.229.106.201 with HTTP; Tue, 18 Jan 2011 16:47:16 -0800 (PST) In-Reply-To: <4D36032E.7020006@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> Date: Wed, 19 Jan 2011 09:47:16 +0900 Message-ID: From: Erik Kline To: Jack Bates Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 00:44:43 -0000 > I believe you are talking about my original mechanism for load balancing, > which was to utilize routing protocols on the servers to announce to the > router that a server was available. In general principle, it was effective, > but only on a per flow basis (standard flow based balancing of routers > insured that a connection held to a single server so long as it was active). > I didn't see any options in current routers to support utilizing a single > path for all packets from a source (required for when current state is only > stored on one server and not shared by all servers). This last part was the > deciding point for me to shift to DSR with a specialized load balancer. Depending on the architecture, ECMP may help. From joelja@bogus.com Tue Jan 18 19:41:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B259F28C0FD; Tue, 18 Jan 2011 19:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.905 X-Spam-Level: X-Spam-Status: No, score=-101.905 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 LOuqJAFaYJKZ; Tue, 18 Jan 2011 19:41:48 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 904C128C0F7; Tue, 18 Jan 2011 19:41:48 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0J3iCFM089522 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 19 Jan 2011 03:44:13 GMT (envelope-from joelja@bogus.com) Message-ID: <4D365E0C.3050405@bogus.com> Date: Tue, 18 Jan 2011 19:44:12 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F58EC451F@sg2019z.corproot.net> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F58EC45CA@sg2019z.corproot.net> <129F694F-9979-45EC-B3D3-35AD5EBCC3F1@employees.org> <20101223231240.6fda94fd@opy.nosense.org> In-Reply-To: <20101223231240.6fda94fd@opy.nosense.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Guillaume.Leclanche@swisscom.com, IPv6 Operations , homegate@ietf.org Subject: Re: [v6ops] CPE Prefix Sub-Delegation on LAN X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 03:41:49 -0000 On 12/23/10 4:42 AM, Mark Smith wrote: > On Thu, 23 Dec 2010 13:06:23 +0100 Ole Troan > wrote: > >> [included the homenet list] >> >>> There might be some work to do to say how the dhcpv6 server in >>> the CPE should get the prefix received from the ISP, also when >>> the ISP is not using DHCPv6. For example, with 6rd. However, >>> since the 6rd parameters have to be pre-provisioned or given via >>> DHCP(v4), I can imagine that there's a way to sort this out >>> without too much pain. >> >> with regards to 6rd, there is nothing special. a 6rd delegated >> prefix is just like an DHCP PD prefix, for the purpose of internal >> prefix assignment. >> >> this problem within the charter of the (rejected) homenet WG >> effort. >> >> there are many ways internal prefix assignment and distribution of >> other configuration information can be done. many of the ideas were >> discussed during the zerouter BOF (which also failed making it into >> a WG). >> >> - Multi-link subnet routing (a shared off link /64 among all nodes. >> host routes in OSPF) - ND proxy (restricted topology) - >> hierarchical DHCP prefix delegation (restricted topology) - zOSPF >> (https://datatracker.ietf.org/doc/draft-dimitri-zospf/) using a new >> LSA in OSPF to distribute the site prefix plus a mechanism for >> collision detection. >> > > Another possible addition to the list could be some of the mesh > routing protocols that have/are being developed for wireless and/or > sensor networks. As laptops have overtaken desktops in sales, and > they usually come with wired and wireless interfaces, it probably > wouldn't be much of an unacceptable burden for them to also act mesh > routers. They'll do more throughput and have faster CPUs than most > routers that would be present in most residential and SOHO > environments. Lateish commentary on this... I suspect that the operational experience with v6 mesh networks is a little shallow to produce great recomendations there... In addition to zerorouter here has been if I recall real discussion of this in manet and autoconf. > Regards, Mark. > >> in my view this requires new work. >> >> cheers, Ole _______________________________________________ v6ops >> mailing list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Tue Jan 18 20:02:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3799E28C121; Tue, 18 Jan 2011 20:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 XzbgK6jA5Rnj; Tue, 18 Jan 2011 20:02:24 -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 2C4D028C101; Tue, 18 Jan 2011 20:02:24 -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: AvsEAH/xNU2rR7Hu/2dsb2JhbACkQnOnMZo+hVAEhG+GL4Mk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2011 04:05:03 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0J44wtd025547; Wed, 19 Jan 2011 04:05:02 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 18 Jan 2011 20:05:03 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 18 Jan 2011 20:05:03 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D36032E.7020006@brightok.net> Date: Tue, 18 Jan 2011 20:04:48 -0800 Message-Id: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 04:02:25 -0000 On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > I didn't see any options in current routers to support utilizing a = single path for all packets from a source (required for when current = state is only stored on one server and not shared by all servers).=20 This confuses me. Let me give you two references, both found via Google. = http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/= html/ip-config11.html search for the word "hash". "Hashed - uses hashing of source and destination addresses to determine = which of the available paths in the ECMP set to use" = http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a00= 80094806.shtml (for some reason, if you look at Google you would think we only do this = for IBGP or only for multicast; it applies to all routing protocols as = it is an attribute of CEF) "The session-to-path assignment is done using a hash function that takes = the source and destination IP addresses and, in recent releases of Cisco = IOS, a unique hash ID that randomizes the assignment across the = end-to-end path." I imagine you could find similar statements from any IP router vendor = out there. If your destination address (the address of the system you are routing = towards) is constant (the sessions are all with the same server = address), then any hash of the source and destination address should = come up with the same number for all sessions from any given source = address. Barring a change in routing, that would send them all down the = same path. Did I miss something?= From ek@google.com Tue Jan 18 20:09:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274FC28C12C for ; Tue, 18 Jan 2011 20:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.905 X-Spam-Level: X-Spam-Status: No, score=-105.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 VDD5couWhJ7b for ; Tue, 18 Jan 2011 20:09:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 09C2228C119 for ; Tue, 18 Jan 2011 20:09:10 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p0J4Bnhp024226 for ; Tue, 18 Jan 2011 20:11:49 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295410309; bh=dNH8NTCiUBrM25dVqY+Waf8AeIQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=XN9qzUvYqRxtpf6dkpTHVDL9afMdQWI0/QLGRXBEx5kiAHFjzmxs9aXe08orx5Dhr y7GAOrN994LIAIYUXmt/Q== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq12.eem.corp.google.com with ESMTP id p0J497Tp025587 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 20:11:47 -0800 Received: by qwj9 with SMTP id 9so402618qwj.8 for ; Tue, 18 Jan 2011 20:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x0bZeF1Fu1W7ZII06ubL4nWkosBcbdN6gzOAEeO7vhU=; b=JQsTtye/f2+uz30bRe3cxaqrdEFIOwmTIeIJkLrlBT8Ts6s3yj4kghYmI4B0dXlgdW tazby1yTWdC36/8MNHJw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e7D3gPu4PzCEJw1cPYTzZDUSQFF0Wvn8XHhGaVGUE1o4ohvfQcTaGNIzJ2qKm18BPY lEBl7wM0+1d+j649Oo1A== MIME-Version: 1.0 Received: by 10.229.82.14 with SMTP id z14mr165425qck.257.1295410307044; Tue, 18 Jan 2011 20:11:47 -0800 (PST) Received: by 10.229.106.201 with HTTP; Tue, 18 Jan 2011 20:11:46 -0800 (PST) In-Reply-To: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> Date: Wed, 19 Jan 2011 13:11:46 +0900 Message-ID: From: Erik Kline To: Fred Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 04:09:12 -0000 On 19 January 2011 13:04, Fred Baker wrote: > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > >> I didn't see any options in current routers to support utilizing a singl= e path for all packets from a source (required for when current state is on= ly stored on one server and not shared by all servers). > > This confuses me. Let me give you two references, both found via Google. > > http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1= /html/ip-config11.html > search for the word "hash". > "Hashed - uses hashing of source and destination addresses to determine w= hich of the available paths in the ECMP set to use" > > http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a0= 080094806.shtml > (for some reason, if you look at Google you would think we only do this f= or IBGP or only for multicast; it applies to all routing protocols as it is= an attribute of CEF) > "The session-to-path assignment is done using a hash function that takes = the source and destination IP addresses and, in recent releases of Cisco IO= S, a unique hash ID that randomizes the assignment across the end-to-end pa= th." > > I imagine you could find similar statements from any IP router vendor out= there. > > If your destination address (the address of the system you are routing to= wards) is constant (the sessions are all with the same server address), the= n any hash of the source and destination address should come up with the sa= me number for all sessions from any given source address. Barring a change = in routing, that would send them all down the same path. > > Did I miss something? There are load balancing systems that (IIRC) work pretty much exactly this = way. From fred@cisco.com Tue Jan 18 21:03:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539C53A7084; Tue, 18 Jan 2011 21:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.464 X-Spam-Level: X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 F7BAycTZxNf7; Tue, 18 Jan 2011 21:03:04 -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 102263A6F5F; Tue, 18 Jan 2011 21:03:04 -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: AvsEAI//NU2rR7Hu/2dsb2JhbACkQnOnKZo9hVAEhG+GL4Mk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2011 05:05:42 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0J55WiS006987; Wed, 19 Jan 2011 05:05:42 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 18 Jan 2011 21:05:42 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 18 Jan 2011 21:05:42 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 18 Jan 2011 21:05:21 -0800 Message-Id: <91B76858-C7AA-403D-AFB0-171B56F457CB@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA 4A1EA9DE9@cisco.com> To: Erik Kline X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 05:03:05 -0000 On Jan 18, 2011, at 8:11 PM, Erik Kline wrote: > On 19 January 2011 13:04, Fred Baker wrote: >>=20 >> On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: >>=20 >>> I didn't see any options in current routers to support utilizing a = single path for all packets from a source (required for when current = state is only stored on one server and not shared by all servers). >>=20 >> This confuses me. Let me give you two references, both found via = Google. >>=20 >> = http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/= html/ip-config11.html >> search for the word "hash". >> "Hashed - uses hashing of source and destination addresses to = determine which of the available paths in the ECMP set to use" >>=20 >> = http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a00= 80094806.shtml >> (for some reason, if you look at Google you would think we only do = this for IBGP or only for multicast; it applies to all routing protocols = as it is an attribute of CEF) >> "The session-to-path assignment is done using a hash function that = takes the source and destination IP addresses and, in recent releases of = Cisco IOS, a unique hash ID that randomizes the assignment across the = end-to-end path." >>=20 >> I imagine you could find similar statements from any IP router vendor = out there. >>=20 >> If your destination address (the address of the system you are = routing towards) is constant (the sessions are all with the same server = address), then any hash of the source and destination address should = come up with the same number for all sessions from any given source = address. Barring a change in routing, that would send them all down the = same path. >>=20 >> Did I miss something? >=20 > There are load balancing systems that (IIRC) work pretty much exactly = this way. Um. Yes. That's what these web pages describe...= From joelja@bogus.com Tue Jan 18 21:20:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC9D3A6EEB; Tue, 18 Jan 2011 21:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 p+oGJQ55IBTb; Tue, 18 Jan 2011 21:20:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 9EC7C3A6E40; Tue, 18 Jan 2011 21:20:34 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0J5N8Ru094710 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 19 Jan 2011 05:23:09 GMT (envelope-from joelja@bogus.com) Message-ID: <4D36753C.8070407@bogus.com> Date: Tue, 18 Jan 2011 21:23:08 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> In-Reply-To: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 05:20:36 -0000 On 1/18/11 8:04 PM, Fred Baker wrote: > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > >> I didn't see any options in current routers to support utilizing a >> single path for all packets from a source (required for when >> current state is only stored on one server and not shared by all >> servers). stateless layer 3 load balancer is what one is is looking for. in a former life we used one (built on an off the self l3 ethernet switch asic as the front-end for a cluster of firewalls). one such example of a product specfically for this purpose is: http://www.bladenetwork.net/iFlow.html > This confuses me. Let me give you two references, both found via > Google. > > http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/html/ip-config11.html > > search for the word "hash". > "Hashed - uses hashing of source and destination addresses to > determine which of the available paths in the ECMP set to use" > > http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a0080094806.shtml > > (for some reason, if you look at Google you would think we only do this for IBGP or only for multicast; it applies to all routing protocols as it is an attribute of CEF) > "The session-to-path assignment is done using a hash function that > takes the source and destination IP addresses and, in recent releases > of Cisco IOS, a unique hash ID that randomizes the assignment across > the end-to-end path." > > I imagine you could find similar statements from any IP router vendor > out there. > > If your destination address (the address of the system you are > routing towards) is constant (the sessions are all with the same > server address), then any hash of the source and destination address > should come up with the same number for all sessions from any given > source address. Barring a change in routing, that would send them all > down the same path. > > Did I miss something? > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From remi.despres@free.fr Wed Jan 19 04:39:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C666E3A7102; Wed, 19 Jan 2011 04:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[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 8iCKHWP5ibLg; Wed, 19 Jan 2011 04:39:10 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 5EACE3A6FD9; Wed, 19 Jan 2011 04:39:10 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id F2089700008B; Wed, 19 Jan 2011 13:41:49 +0100 (CET) Received: from [192.168.103.200] (pat46-invites.rennes.enst-bretagne.fr [192.44.77.46]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 68DA17000087; Wed, 19 Jan 2011 13:41:49 +0100 (CET) X-SFR-UUID: 20110119124149429.68DA17000087@msfrf2217.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: <936466CA-1532-4634-A13C-A29BCA71E829@cisco.com> Date: Wed, 19 Jan 2011 13:41:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <936466CA-1532-4634-A13C-A29BCA71E829@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 12:39:11 -0000 Le 18 janv. 2011 =E0 19:18, Fred Baker a =E9crit : >=20 > On Jan 18, 2011, at 2:50 AM, R=E9mi Despr=E9s wrote: >> (a) These scenarios differ from classical NAT scenarios (incoming = connections are THE subject, rather than having to be blocked).=20 >=20 > Well, they differ from NAT scenarios that the IETF has considered. OK > I would object to the assertion that what you're calling a = "traditional NAT" has as its primary function to block sessions. I didn't say is was their "primary" function, only that they had this = function. =3D> no reason to object (we agree). > A Network Address Translator, in any usage, has as it primary function = the translation of network layer addresses. > What you're pointing out is that any stateful NAT (as opposed to that = described in SIIT for example) has a "translated from" and a "translated = to" side and an algorithm by which it creates its translation state. If "translation from" is synonymous with "mappings initiated by outgoing = connections", we agree. > What you're calling a "traditional NAT" translates "from" in "inside" = domain and doesn't change the "outside" destination address. I only meant that traditional NAT's initiate their mappings with = outgoing connections, . > A load balancer - which is in no sense a new use of NAT technology, Not "new", I agree, but still different from IETF documented uses of = NATs. Again, thanks for having clarified that "data-center load balancing" was = THE scenario being discussed on this thread. > its just one the IETF hasn't focused on - translates "from" the great = wide world, and the algorithm by which it creates translation state is = more complex. OK >> (b) These NATs, to exercise their load-balancing function, do 1:n = mappings.=20 >=20 > That is certainly one way to do it. What I have tried to point out is = that there is a class of widely-used products that do. The point I made (important IMHO) is that, for data-center load = balancing, NPTv6 isn't applicable because its mappings are 1:1 while the = application requires 1:n. Can we agree on this too? Regards, RD =20 =20 From jbates@brightok.net Wed Jan 19 07:07:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A583A7155; Wed, 19 Jan 2011 07:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 F4LvUkzGmBE4; Wed, 19 Jan 2011 07:07:15 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id D46C53A713E; Wed, 19 Jan 2011 07:07:15 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0JF9jbI015755; Wed, 19 Jan 2011 09:09:45 -0600 (CST) Message-ID: <4D36FEB9.4010803@brightok.net> Date: Wed, 19 Jan 2011 09:09:45 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> In-Reply-To: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:07:16 -0000 On 1/18/2011 10:04 PM, Fred Baker wrote: > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > >> I didn't see any options in current routers to support utilizing a single path for all packets from a source (required for when current state is only stored on one server and not shared by all servers). > > This confuses me. Let me give you two references, both found via Google. > > I imagine you could find similar statements from any IP router vendor out there. > > If your destination address (the address of the system you are routing towards) is constant (the sessions are all with the same server address), then any hash of the source and destination address should come up with the same number for all sessions from any given source address. Barring a change in routing, that would send them all down the same path. > > Did I miss something? My erroneous use of the word "current" and vendor neutrality. My routers don't always use sourceIP/destIP as the only pieces of a hash. Even the cisco page mentions inclusion of a session ID and today supports 3 algorithms at the global level for cef load-sharing. We checked traffic decisions in the production network at the time we were looking for a solution and had various behaviors and few knobs. We deemed using routing tricks to be too unreliable and dangerous in the face of having to upgrade code regularly for better IPv6 support. Today, I utilize on a per service basis multiple policies. There are cases where I do not want a source address locked to a single server. The load balancer allows a much granular configuration over routing tricks. Jack From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Jan 19 12:59:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51763A71C9; Wed, 19 Jan 2011 12:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 kmTqWaqk3oTH; Wed, 19 Jan 2011 12:59:00 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 78DCA3A71C6; Wed, 19 Jan 2011 12:59:00 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pff9o-0004fW-PS; Thu, 20 Jan 2011 07:31:32 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C6D3B3B31E; Thu, 20 Jan 2011 07:31:31 +1030 (CST) Date: Thu, 20 Jan 2011 07:31:31 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110120073131.462d3218@opy.nosense.org> In-Reply-To: <4D36FEB9.4010803@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> <4D36FEB9.4010803@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:59:01 -0000 On Wed, 19 Jan 2011 09:09:45 -0600 Jack Bates wrote: > On 1/18/2011 10:04 PM, Fred Baker wrote: > > > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > > > >> I didn't see any options in current routers to support utilizing a single path for all packets from a source (required for when current state is only stored on one server and not shared by all servers). > > > > This confuses me. Let me give you two references, both found via Google. > > > > > > > I imagine you could find similar statements from any IP router vendor out there. > > > > If your destination address (the address of the system you are routing towards) is constant (the sessions are all with the same server address), then any hash of the source and destination address should come up with the same number for all sessions from any given source address. Barring a change in routing, that would send them all down the same path. > > > > Did I miss something? > > My erroneous use of the word "current" and vendor neutrality. > > My routers don't always use sourceIP/destIP as the only pieces of a > hash. Even the cisco page mentions inclusion of a session ID and today > supports 3 algorithms at the global level for cef load-sharing. We > checked traffic decisions in the production network at the time we were > looking for a solution and had various behaviors and few knobs. We > deemed using routing tricks to be too unreliable and dangerous in the > face of having to upgrade code regularly for better IPv6 support. > > Today, I utilize on a per service basis multiple policies. There are > cases where I do not want a source address locked to a single server. > The load balancer allows a much granular configuration over routing tricks. > When I mentioned what current routers are capable of doing regarding sessions, I was thinking about hashing. However, that was more of an example to show that routers are already capable of sending traffic with the same destination over more than one route in a session aware manner. I think though that the drawback of a simple hash is that it isn't load sensitive. So a forwarding method that actively chooses a destination server based on load is needed, and then subsequently all packets with the same source address and port need to be sent to the same selected server. I've realised that is describing policy routing/forwarding, where the source address and port as well as the destination address is used as a fib entry selector - when ever a new connection comes in, and a server is selected, then a policy route is installed to forward all subsequent traffic to the same server. I was hoping that it might be possible to avoid having to look at the traffic stream after that, and let the policy route take care of it, however those policy routes need to be removed when the session is finished, and I think the only way to know when remove them correctly would be to watch for e.g. TCP FIN/ACKs. Regards, Mark. From rashmi@kth.se Wed Jan 19 14:21:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3ADB3A71E1 for ; Wed, 19 Jan 2011 14:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBTUW+xJvUpW for ; Wed, 19 Jan 2011 14:21:50 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id CE11D3A6F66 for ; Wed, 19 Jan 2011 14:21:49 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 8AB031558EE for ; Wed, 19 Jan 2011 23:23:59 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 2I09HqEUKJTc for ; Wed, 19 Jan 2011 23:23:58 +0100 (CET) X-KTH-Auth: rashmi [213.103.214.20] X-KTH-mail-from: rashmi@kth.se X-KTH-rcpt-to: v6ops@ietf.org Received: from [127.0.0.1] (s213-103-214-20.cust.tele2.se [213.103.214.20]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 5D119154136 for ; Wed, 19 Jan 2011 23:23:58 +0100 (CET) Message-ID: <4D376481.3010406@kth.se> Date: Wed, 19 Jan 2011 23:24:01 +0100 From: Rashmi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 19 Jan 2011 14:32:11 -0800 Subject: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:21:51 -0000 Hello, I am Rashmi, a Master thesis student at KTH, Stockholm. I studied "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts draft-wing-v6ops-happy-eyeballs-ipv6-00" and I am very interested to know if there is any current implementation of "Happy Eyeballs". -- Regards, Rashmi Purushothama From Ted.Lemon@nominum.com Wed Jan 19 14:54:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985513A7021 for ; Wed, 19 Jan 2011 14:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 agqy-CdfYbcN for ; Wed, 19 Jan 2011 14:54:37 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 926EE3A6E5E for ; Wed, 19 Jan 2011 14:54:37 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTTdsTgYJNnu7qTXaSmCksLpH1JIwfwJ5@postini.com; Wed, 19 Jan 2011 14:57:19 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 861281B8194 for ; Wed, 19 Jan 2011 14:57:18 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 52587190059; Wed, 19 Jan 2011 14:57:18 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 14:57:17 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D376481.3010406@kth.se> Date: Wed, 19 Jan 2011 17:57:14 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> References: <4D376481.3010406@kth.se> To: Rashmi X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:54:38 -0000 On Jan 19, 2011, at 5:24 PM, Rashmi wrote: > I am Rashmi, a Master thesis student at KTH, Stockholm. I studied = "Happy=20 > Eyeballs: Trending Towards Success with Dual-Stack Hosts=20 > draft-wing-v6ops-happy-eyeballs-ipv6-00" and I am very interested to=20= > know if there is any current implementation of "Happy Eyeballs". I've done a somewhat aggressive Happy Eyeballs implementation for an = iPad ssh app that I use. Its behavior is quite satisfactory. It does = not delay startup on either protocol--it just launches connections on = both protocols at once, and uses the connection that comes back first. = This is usually IPv6 within the house, and often IPv4 when I'm out and = abroad. My implementation is not a generic library, though--it's part of the = application. From carlosm3011@gmail.com Wed Jan 19 14:59:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB7728C123 for ; Wed, 19 Jan 2011 14:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_13=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 VF1c9GIglbQI for ; Wed, 19 Jan 2011 14:59:08 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A2BA228C0F1 for ; Wed, 19 Jan 2011 14:59:08 -0800 (PST) Received: by iwn40 with SMTP id 40so1391577iwn.31 for ; Wed, 19 Jan 2011 15:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IoFMQgizdhcuWm6LFJ1PJTeuIzcr7yovbDHHeAbnFUU=; b=p5OyDIH+CnM696OonTfNS36TSN+7XVrgjiYZHd5RGzVuu6y428bkeuCYcnOon2ww91 OTkHGxg7NUn0e87slqWWkmvdbTrZWsLNpJwLEuRQneQt9uiRny5muowjfsFXjQig5NV9 Rj/EykdrrRtsi2vvLnkWtf/mrRXaRu0n1uIQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=JrpVNW/uWdMNSqgJLM1aEXIXOzlx8deSx+j8ttuks1tGkFy1LA/DJ57SYQUzlv6MQh OxVuFUAuoNVzjcILW3inYWypD3fQwPilZqJGw6BlAsE9dnhyGJJceRkDkuDGsijGNnnt dKkldla3MfqJ0r9YwOevpJE06v/Z75xp53eS8= MIME-Version: 1.0 Received: by 10.42.218.5 with SMTP id ho5mr1650330icb.403.1295478109736; Wed, 19 Jan 2011 15:01:49 -0800 (PST) Received: by 10.42.170.201 with HTTP; Wed, 19 Jan 2011 15:01:49 -0800 (PST) In-Reply-To: <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> Date: Wed, 19 Jan 2011 21:01:49 -0200 Message-ID: From: Carlos Martinez-Cagnazzo To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Rashmi Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:59:10 -0000 I would be willing to collaborate in writing a generic implementation. regards Carlos On Wed, Jan 19, 2011 at 8:57 PM, Ted Lemon wrote: > On Jan 19, 2011, at 5:24 PM, Rashmi wrote: >> I am Rashmi, a Master thesis student at KTH, Stockholm. I studied "Happy >> Eyeballs: Trending Towards Success with Dual-Stack Hosts >> draft-wing-v6ops-happy-eyeballs-ipv6-00" and I am very interested to >> know if there is any current implementation of "Happy Eyeballs". > > I've done a somewhat aggressive Happy Eyeballs implementation for an iPad= ssh app that I use. =A0 Its behavior is quite satisfactory. =A0 It does no= t delay startup on either protocol--it just launches connections on both pr= otocols at once, and uses the connection that comes back first. =A0 This is= usually IPv6 within the house, and often IPv4 when I'm out and abroad. > > My implementation is not a generic library, though--it's part of the appl= ication. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From Ted.Lemon@nominum.com Wed Jan 19 15:03:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8AB3A71D4 for ; Wed, 19 Jan 2011 15:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 a5yR4kXfVJxi for ; Wed, 19 Jan 2011 15:03:57 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id D1BE93A6E5E for ; Wed, 19 Jan 2011 15:03:57 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTTduf/AKtc5dkkHmutRUPMX09FXOaqih@postini.com; Wed, 19 Jan 2011 15:06:39 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2515F1B82B4 for ; Wed, 19 Jan 2011 15:06:39 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1EDD5190059; Wed, 19 Jan 2011 15:06:39 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 15:06:38 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 19 Jan 2011 18:06:33 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> To: "carlos@lacnic.net" X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" , Rashmi Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 23:03:58 -0000 On Jan 19, 2011, at 6:01 PM, Carlos Martinez-Cagnazzo wrote: > I would be willing to collaborate in writing a generic implementation. It's a bit challenging; I used the Apple event-driven socket API, which = made it easy, but to deliver functionality equivalent to the BSD socket = API that did happy eyeballs would be quite challenging, I think. You = would have to make a lot of assumptions about how the application = interacts with the network layer that would restrict the set of = applications that could use your library. What I'd really like to see would be happy eyeballs in Google Chrome and = Firefox, neither of which currently appears to do it. These are the = applications that seem to me to suffer the most when they guess wrong on = which stack to try first. From carlosm3011@gmail.com Wed Jan 19 15:08:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5337F3A71E9 for ; Wed, 19 Jan 2011 15:08:34 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=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 FSsdlUCvL9EA for ; Wed, 19 Jan 2011 15:08:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 79E613A71D4 for ; Wed, 19 Jan 2011 15:08:33 -0800 (PST) Received: by iyi42 with SMTP id 42so1424433iyi.31 for ; Wed, 19 Jan 2011 15:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ltgnQHerlzJIfF6znsTDdEmm1MNua705zTTmSYnMjrc=; b=l6R5j2c7A7nbKQJQUuB8I6qp4kXWuL8UmCAa+8GI156An77zMdSYtYb0bNMbDvcJ+6 L/XD0uc+xsph1aG0p+wb474cwQJL9nmGMyKK3m68sWUWBAU0NELn1zzN/Ykin/ely8w/ Tqksagex6GxOHl3Oewa/J02+GlF+Ns8caeswQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=fiNFFKjrtIdLWeauYeWilAjzAUn4HO+wdiLV+iw2aU60HkJW8pwP7wmtS6cS6wjI8S W1eo5f5QGJG9YUopYvHgi0p9Lf8iz/dDNrgyXku0SIReOCBvvyB5fgwkecUHefxaGXbm TK0dNvklip/+ja0s8VNh++fSOtNSPtYLd0UIw= MIME-Version: 1.0 Received: by 10.42.220.69 with SMTP id hx5mr1675149icb.336.1295478673340; Wed, 19 Jan 2011 15:11:13 -0800 (PST) Sender: carlosm3011@gmail.com Received: by 10.42.170.201 with HTTP; Wed, 19 Jan 2011 15:11:13 -0800 (PST) In-Reply-To: <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> Date: Wed, 19 Jan 2011 21:11:13 -0200 X-Google-Sender-Auth: Q4cqeD4vDBlLvp4-iVGjXSO3USI Message-ID: From: Carlos Martinez-Cagnazzo To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 23:08:34 -0000 I was thinking more along the lines of a socket wrapper, similar to what some "socksifiers" (software that makes your network client "socks aware") do I agree that modifying the BSD socket API would be quite a large job, and probably it's too early to think about that and having a user-mode implementation would help in gaining experience that could be applied to changing kernel-level APIs later on warm regards Carlos On Wed, Jan 19, 2011 at 9:06 PM, Ted Lemon wrote: > On Jan 19, 2011, at 6:01 PM, Carlos Martinez-Cagnazzo wrote: >> I would be willing to collaborate in writing a generic implementation. > > It's a bit challenging; I used the Apple event-driven socket API, which m= ade it easy, but to deliver functionality equivalent to the BSD socket API = that did happy eyeballs would be quite challenging, I think. =A0 You would = have to make a lot of assumptions about how the application interacts with = the network layer that would restrict the set of applications that could us= e your library. > > What I'd really like to see would be happy eyeballs in Google Chrome and = Firefox, neither of which currently appears to do it. =A0 These are the app= lications that seem to me to suffer the most when they guess wrong on which= stack to try first. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Ted.Lemon@nominum.com Wed Jan 19 16:15:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795E73A71F4 for ; Wed, 19 Jan 2011 16:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 D0xv-mjhZ5Cz for ; Wed, 19 Jan 2011 16:15:06 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 1CF8A3A71F3 for ; Wed, 19 Jan 2011 16:15:05 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTTd/K+bLZzHULI6Ud2+1KiCxRYl5B8rL@postini.com; Wed, 19 Jan 2011 16:17:47 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 52C461B8276 for ; Wed, 19 Jan 2011 16:17:47 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3E240190059; Wed, 19 Jan 2011 16:17:47 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 16:17:46 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 19 Jan 2011 19:17:43 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> To: Carlos Martinez-Cagnazzo X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:15:07 -0000 On Jan 19, 2011, at 6:11 PM, Carlos Martinez-Cagnazzo wrote: > I agree that modifying the BSD socket API would be quite a large job, > and probably it's too early to think about that and having a user-mode > implementation would help in gaining experience that could be applied > to changing kernel-level APIs later on Actually, the problem is that it's simply not as easy as you suggest, = because the BSD sockets API is essentially synchronous at connection = time. Most applications are not prepared to deal with asynchronous = behavior on connect. This is not to say that doing an in-kernel implementation is = easier--there are serious problems with burying the functionality in the = kernel, and I actually think it's a bad idea. What I _am_ saying is = that you might get the most bang for the buck from fixing a couple of = really high-profile applications, rather than trying to come up with a = generic solution. From carlosm3011@gmail.com Wed Jan 19 16:32:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585C028C117 for ; Wed, 19 Jan 2011 16:32:34 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=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 A9s6f86PGAwY for ; Wed, 19 Jan 2011 16:32:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 3FF5028C0CF for ; Wed, 19 Jan 2011 16:32:33 -0800 (PST) Received: by iyi42 with SMTP id 42so11427iyi.31 for ; Wed, 19 Jan 2011 16:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rEWMRmFXPSkoUOWDqEttBU6dtX3+JEdTs3eQ9L3otGk=; b=dDyya8XWQwlCiv7OpdIaJDUDMSPIfd+/qrMNFOQyF+7X8L/LjBy7NEcbLopdKTWLTx JzvBc3bJ7nOJswXGVX96c9mkb6WWP5QIuMrFutsZptpooLCqRIWVAmCW6BWYnYZ4EARx lehz1w5rbXnBe3fiDELzvZQ+Xv/4dXUdm2jPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vGWM/iXH6+ebLL7bCBQBwLz6bnWJR2w3vzA58H9ogNFOAGlaZG6jn9W5NnTWpktY2a 2lTlYUitTPUtYDHfiGQvpHMG8eV01r7Wv510zwG/dtU2cyXN71Ng1oYhHpKW3UzAmCT5 xAd06aasYv5ZwNZhFq7RAro1p2tNSMGKisFSo= MIME-Version: 1.0 Received: by 10.42.174.198 with SMTP id w6mr1768122icz.135.1295483714491; Wed, 19 Jan 2011 16:35:14 -0800 (PST) Sender: carlosm3011@gmail.com Received: by 10.42.170.201 with HTTP; Wed, 19 Jan 2011 16:35:14 -0800 (PST) In-Reply-To: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> Date: Wed, 19 Jan 2011 22:35:14 -0200 X-Google-Sender-Auth: el66AUp4sQqqag0Do2Zo1kUc7DI Message-ID: From: Carlos Martinez-Cagnazzo To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:32:34 -0000 I see your point, and I mostly agree. We can further discuss the idea. (BTW I never suggested it was easy :-) ) warm regards Carlos On Wed, Jan 19, 2011 at 10:17 PM, Ted Lemon wrote: > On Jan 19, 2011, at 6:11 PM, Carlos Martinez-Cagnazzo wrote: >> I agree that modifying the BSD socket API would be quite a large job, >> and probably it's too early to think about that and having a user-mode >> implementation would help in gaining experience that could be applied >> to changing kernel-level APIs later on > > Actually, the problem is that it's simply not as easy as you suggest, bec= ause the BSD sockets API is essentially synchronous at connection time. =A0= Most applications are not prepared to deal with asynchronous behavior on c= onnect. > > This is not to say that doing an in-kernel implementation is easier--ther= e are serious problems with burying the functionality in the kernel, and I = actually think it's a bad idea. =A0 What I _am_ saying is that you might ge= t the most bang for the buck from fixing a couple of really high-profile ap= plications, rather than trying to come up with a generic solution. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Wed Jan 19 16:36:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2440D28C0CF for ; Wed, 19 Jan 2011 16:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 5sdKehkyiG26 for ; Wed, 19 Jan 2011 16:36:10 -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 0CF4B3A6F57 for ; Wed, 19 Jan 2011 16:36:10 -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: AvsEAH0SN02rR7H+/2dsb2JhbACkSXOicJp9hVAEhG+GL4Mk Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2011 00:38:51 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0K0ckiF027138; Thu, 20 Jan 2011 00:38:51 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Wed, 19 Jan 2011 16:38:51 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Wed, 19 Jan 2011 16:38:51 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Wed, 19 Jan 2011 16:38:36 -0800 Message-Id: <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:36:11 -0000 On Jan 19, 2011, at 4:17 PM, Ted Lemon wrote: > On Jan 19, 2011, at 6:11 PM, Carlos Martinez-Cagnazzo wrote: >> I agree that modifying the BSD socket API would be quite a large job, >> and probably it's too early to think about that and having a = user-mode >> implementation would help in gaining experience that could be applied >> to changing kernel-level APIs later on >=20 > Actually, the problem is that it's simply not as easy as you suggest, = because the BSD sockets API is essentially synchronous at connection = time. Most applications are not prepared to deal with asynchronous = behavior on connect. >=20 > This is not to say that doing an in-kernel implementation is = easier--there are serious problems with burying the functionality in the = kernel, and I actually think it's a bad idea. What I _am_ saying is = that you might get the most bang for the buck from fixing a couple of = really high-profile applications, rather than trying to come up with a = generic solution. very possibly. That said, a generic solution in application space might = well have the effect of testing out a kernel solution that was deployed = later. In other words, put in a library function in that has an API = similar to unsigned int connect_by_name (char *name, socket *socket, ...) and returns either an open connection to the named system with an error = code of zero or returns some other error code. Viola - not a kernel function, but it could be, if appropriate, = something that spawns several threads and then closes all except the one = that gave it an open socket first, and finally (apparently = synchronously) returns. If the right thing happens - if random unnamed vendors all fix their = OS's and applications - except in the case of OpenBSD, in time that = problem will correct itself...= From carlos@lacnic.net Wed Jan 19 16:17:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0211A28C0E4 for ; Wed, 19 Jan 2011 16:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 UpKp8lMzmxvv for ; Wed, 19 Jan 2011 16:17:43 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id B3A233A71F3 for ; Wed, 19 Jan 2011 16:17:42 -0800 (PST) Received: from Oberon.local (r190-134-230-216.dialup.adsl.anteldata.net.uy [190.134.230.216]) by mail.lacnic.net.uy (Postfix) with ESMTP id 73BC03084DF; Wed, 19 Jan 2011 22:20:10 -0200 (UYST) Message-ID: <4D377FBA.7010600@lacnic.net> Date: Wed, 19 Jan 2011 22:20:10 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> In-Reply-To: X-Enigmail-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050606020507090500000701" X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: carlos@lacnic.net X-Mailman-Approved-At: Wed, 19 Jan 2011 16:44:39 -0800 Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:27:28 -0000 This is a multi-part message in MIME format. --------------050606020507090500000701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I see your point, and I mostly agree. We can further discuss the idea. (I never suggested it was easy :-) ) warm regards Carlos On 1/19/11 10:17 PM, Ted Lemon wrote: > On Jan 19, 2011, at 6:11 PM, Carlos Martinez-Cagnazzo wrote: >> I agree that modifying the BSD socket API would be quite a large job, >> and probably it's too early to think about that and having a user-mode >> implementation would help in gaining experience that could be applied >> to changing kernel-level APIs later on > Actually, the problem is that it's simply not as easy as you suggest, because the BSD sockets API is essentially synchronous at connection time. Most applications are not prepared to deal with asynchronous behavior on connect. > > This is not to say that doing an in-kernel implementation is easier--there are serious problems with burying the functionality in the kernel, and I actually think it's a bad idea. What I _am_ saying is that you might get the most bang for the buck from fixing a couple of really high-profile applications, rather than trying to come up with a generic solution. -- Carlos M. Martinez LACNIC I+D PGP KeyID 0xD51507A2 Phone: +598-2604-2222 ext. 4419 --------------050606020507090500000701 Content-Type: text/x-vcard; charset=utf-8; name="carlos.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="carlos.vcf" begin:vcard fn:Carlos Martinez Cagnazzo n:Martinez Cagnazzo;Carlos email;internet:carlos@lacnic.net tel;work:+598-2604-2222 tel;cell:+598-9-9245009 x-mozilla-html:FALSE version:2.1 end:vcard --------------050606020507090500000701-- From Ted.Lemon@nominum.com Wed Jan 19 16:54:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD4C3A6F78 for ; Wed, 19 Jan 2011 16:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 o4CMudI3jwrp for ; Wed, 19 Jan 2011 16:54:14 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 9AC3C3A7052 for ; Wed, 19 Jan 2011 16:54:14 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTTeIWAVHmNF7VFCENub+w/WnAfmqX1GJ@postini.com; Wed, 19 Jan 2011 16:56:56 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1388B1B826F for ; Wed, 19 Jan 2011 16:56:55 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B817419004B; Wed, 19 Jan 2011 16:56:55 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 16:56:55 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> Date: Wed, 19 Jan 2011 19:56:51 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:54:15 -0000 On Jan 19, 2011, at 7:38 PM, Fred Baker wrote: > very possibly. That said, a generic solution in application space = might well have the effect of testing out a kernel solution that was = deployed later. In other words, put in a library function in that has an = API similar to >=20 > unsigned int connect_by_name (char *name, socket *socket, ...) >=20 > and returns either an open connection to the named system with an = error code of zero or returns some other error code. >=20 > Viola - not a kernel function, but it could be, if appropriate, = something that spawns several threads and then closes all except the one = that gave it an open socket first, and finally (apparently = synchronously) returns. I think this is a reasonable idea, but it actually brings up the reason = why I think pushing this down into the kernel is a bad idea. In the = case of my ssh application, what I really want is to get all the way to = mutual authentication before I give up on the other connection. If all = I get back from the kernel is the first connection to complete a mutual = handshake, I can't do that. Strictly speaking, there's no reason to use threads for this, by the = way--you can just use select/poll/whatever. I don't know precisely = what Mac OS X is doing under the covers to give me my event-driven = connects, but I don't get the impression that it's forking threads. = It's probably better not to use threads unless you're sure that the = application is going to be threaded anyway. But you could certainly do = precisely what you suggested either with or without threads, and I think = it would be a useful exercise. From ayourtch@cisco.com Wed Jan 19 16:55:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58D63A7052 for ; Wed, 19 Jan 2011 16:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 agfMY23sqdQy for ; Wed, 19 Jan 2011 16:55:46 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 518C73A6F78 for ; Wed, 19 Jan 2011 16:55:46 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K0sg43009147; Thu, 20 Jan 2011 01:54:42 +0100 (CET) Received: from sweet-brew-6.cisco.com (sweet-brew-6.cisco.com [144.254.10.207]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K0sdCi029580; Thu, 20 Jan 2011 01:54:39 +0100 (CET) Date: Thu, 20 Jan 2011 01:54:39 +0100 (CET) From: Andrew Yourtchenko To: Rashmi In-Reply-To: <4D376481.3010406@kth.se> Message-ID: References: <4D376481.3010406@kth.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:55:47 -0000 Hi Rashmi, On Wed, 19 Jan 2011, Rashmi wrote: > Hello, > > I am Rashmi, a Master thesis student at KTH, Stockholm. I studied "Happy > Eyeballs: Trending Towards Success with Dual-Stack Hosts > draft-wing-v6ops-happy-eyeballs-ipv6-00" and I am very interested to know if > there is any current implementation of "Happy Eyeballs". I've done the initial prototyping for the idea as part of the links browser. To minimize the changes, I had tried the following approach: 1) using the posix threads to start two threads of execution ("v4" and "v6" one - both doing lookups and connect attempts) 2) in order to fool the rest of the code that the "connection has not happened yet", I initially returned the non-writable file descriptor from the pair that pipe(2) returns, and then when the connection succeeded, then I used dup2(2) to impose the successfully connected socket onto the old file descriptor. (1) is a big no-no in a well-behaved library, and the (2), while initially it seemed to be a good parlor trick, turned out to be nonportable and incompatible with the behavior of the "true" not-connected-yet socket file descriptor - so I never bothered to let it see the light. I think a LD_PRELOAD-style variation of the happy eyeballs can be made, with some ugly jumps over the hoops, here are my napkin notes: a) as part of the initialization, fork a separate process that would do the "monitoring" part using threads, so that the threading structure of the client process were not altered. b) intercept all the socket calls, and return the socket of the type (INET or INET6) that you think will most likely succeed (based on the current value of P). c) Here be dragons: intercept all name resolutions. Thanks to blocking nature of the resolver functions, there are quite a few async resolver libs - so merely intercepting the syscalls would not be enough, you'd need to intercept and parse the udp/53 packets. Not too easy and very ugly hack. d) the forked "miscellaneous" process would check whether the returned socket was indeed the correct one and if not - then would force the correct one upon the client by means of an injected signal handler + sendmsg. This is also a very ugly hack. So in summary - I think it is technically possible, but the resulting code at least in my estimates may cause severe indigestion. I'm not sure how well that is doable on Windows, but I know that antivirus programs are generally very sensitive to most of the actions I've described above, so it'd be a tough game to make it abstract enough. A challenge in doing it in user space is gracefully gluing it into the different process and I/O handling models of the existing apps that assume the two separate stages "lookup the address(es)" and "connect to address" - they can be quite far apart in the applications sometimes. cheers, andrew > > -- > Regards, > Rashmi Purushothama > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Ted.Lemon@nominum.com Wed Jan 19 17:14:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32C228C103 for ; Wed, 19 Jan 2011 17:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 rbjR677rA-gs for ; Wed, 19 Jan 2011 17:14:53 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 1DE9428C0FF for ; Wed, 19 Jan 2011 17:14:52 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTTeNLln6wU2Spk4AS6eHxGF73FyL5Rap@postini.com; Wed, 19 Jan 2011 17:17:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 667531B82B6 for ; Wed, 19 Jan 2011 17:17:34 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 605C7190055; Wed, 19 Jan 2011 17:17:34 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 17:17:33 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 19 Jan 2011 20:17:29 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4D376481.3010406@kth.se> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" , Rashmi Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:14:54 -0000 On Jan 19, 2011, at 7:54 PM, Andrew Yourtchenko wrote: > A challenge in doing it in user space is gracefully gluing it into the = different=20 > process and I/O handling models of the existing apps that assume the = two=20 > separate stages "lookup the address(es)" and "connect to address" - = they can be=20 > quite far apart in the applications sometimes. I don't see the point of this. No matter how hard you try, your = solution is going to be rickety. Why not just fix the application? From ayourtch@cisco.com Wed Jan 19 17:17:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050EF28C106 for ; Wed, 19 Jan 2011 17:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, 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 BR0Q9amTJOn0 for ; Wed, 19 Jan 2011 17:17:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 1B55B3A7201 for ; Wed, 19 Jan 2011 17:17:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K1GVmd010751; Thu, 20 Jan 2011 02:16:31 +0100 (CET) Received: from sweet-brew-6.cisco.com (sweet-brew-6.cisco.com [144.254.10.207]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K1GTua015742; Thu, 20 Jan 2011 02:16:29 +0100 (CET) Date: Thu, 20 Jan 2011 02:16:28 +0100 (CET) From: Andrew Yourtchenko To: Ted Lemon In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:17:37 -0000 On Wed, 19 Jan 2011, Ted Lemon wrote: > On Jan 19, 2011, at 7:38 PM, Fred Baker wrote: >> very possibly. That said, a generic solution in application space might well have the effect of testing out a kernel solution that was deployed later. In other words, put in a library function in that has an API similar to >> >> unsigned int connect_by_name (char *name, socket *socket, ...) >> >> and returns either an open connection to the named system with an error code of zero or returns some other error code. >> >> Viola - not a kernel function, but it could be, if appropriate, something that spawns several threads and then closes all except the one that gave it an open socket first, and finally (apparently synchronously) returns. > > I think this is a reasonable idea, but it actually brings up the reason why I >think pushing this down into the kernel is a bad idea. In the case of my ssh >application, what I really want is to get all the way to mutual authentication >before I give up on the other connection. If all I get back from the kernel >is the first connection to complete a mutual handshake, I can't do that. > > Strictly speaking, there's no reason to use threads for this, by the way--you >can just use select/poll/whatever. I don't know precisely what Mac OS X is >doing under the covers to give me my event-driven connects, but I don't get the >impression that it's forking threads. It's probably better not to use threads >unless you're sure that the application is going to be threaded anyway. But >you could certainly do precisely what you suggested either with or without >threads, and I think it would be a useful exercise. The reason I used threads in my proof-of-concept code was that I wanted to stick to getaddrinfo() which does not lend itself to more than one in-progress lookup at a time. The motivation for sticking to getaddrinfo() was that non-RFC1035 things like EDNS0, DNSSEC, etc. are Operating System Problem. But assuming the host who just needs to know the IPv4 or IPv6 address of a hostname can survive with simpler resolver, it may be beneficial to roll one's own. During the new year's holidays I looked at existing resolvers - and the resulting frustration resulted in the rubber duckie at https://github.com/ayourtch/ydns - which does not do anything terribly useful now apart from asking questions and parsing answers, but with some more work I think can be used as part of such a "connect_by_name" api that would be eventloop-compatible. cheers, andrew From jhw@apple.com Wed Jan 19 17:25:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA9C3A7201 for ; Wed, 19 Jan 2011 17:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Rgz4a-HnGVRX for ; Wed, 19 Jan 2011 17:25:22 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 32F9E3A7200 for ; Wed, 19 Jan 2011 17:25:22 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id E2919CCC3F1D for ; Wed, 19 Jan 2011 17:28:03 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-51-4d378fa3819f Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id C1.3A.06193.3AF873D4; Wed, 19 Jan 2011 17:28:03 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from il0602f-dhcp196.apple.com (il0602f-dhcp196.apple.com [17.206.50.196]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LFA00M5LS2R08B0@elliott.apple.com> for v6ops@ietf.org; Wed, 19 Jan 2011 17:28:03 -0800 (PST) From: james woodyatt In-reply-to: Date: Wed, 19 Jan 2011 17:28:03 -0800 Message-id: <28D74606-ACAC-4F5F-A6C4-732AB09F098F@apple.com> References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:25:23 -0000 On Jan 19, 2011, at 16:56, Ted Lemon wrote: > > I don't know precisely what Mac OS X is doing under the covers to give me my event-driven connects, but I don't get the impression that it's forking threads. As the source code is open, this shouldn't be a mystery. The answer for the impatient is that it's a stack of abstractions built around a distinguished set of operations on file descriptors with the O_NONBLOCK flag set and judicious use of the kevent(2) system call. -- james woodyatt member of technical staff, communications engineering From ayourtch@cisco.com Wed Jan 19 17:26:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F113628C13D for ; Wed, 19 Jan 2011 17:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 4rznL2tI6XDJ for ; Wed, 19 Jan 2011 17:26:19 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EE33E28C0FA for ; Wed, 19 Jan 2011 17:26:18 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K1SxiC011589; Thu, 20 Jan 2011 02:28:59 +0100 (CET) Received: from sweet-brew-6.cisco.com (sweet-brew-6.cisco.com [144.254.10.207]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K1SvbM024831; Thu, 20 Jan 2011 02:28:57 +0100 (CET) Date: Thu, 20 Jan 2011 02:28:57 +0100 (CET) From: Andrew Yourtchenko To: Ted Lemon In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Rashmi Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:26:20 -0000 On Wed, 19 Jan 2011, Ted Lemon wrote: > On Jan 19, 2011, at 7:54 PM, Andrew Yourtchenko wrote: >> A challenge in doing it in user space is gracefully gluing it into the different >> process and I/O handling models of the existing apps that assume the two >> separate stages "lookup the address(es)" and "connect to address" - they can be >> quite far apart in the applications sometimes. > > I don't see the point of this. No matter how hard you try, your solution is >going to be rickety. Why not just fix the application? > Because sometimes the fix can require a massive refactoring. For starters - a nonblocking DNS lookup. Like I wrote, I could not find an async resolver library that does not try to surreptitiously launch interstellar shuttles from behind my back. cheers, andrew From ayourtch@cisco.com Wed Jan 19 17:29:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1AD28C131 for ; Wed, 19 Jan 2011 17:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 zVolhzVnEvkw for ; Wed, 19 Jan 2011 17:29:34 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id C180628C0FF for ; Wed, 19 Jan 2011 17:29:33 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K19FgJ010250; Thu, 20 Jan 2011 02:09:15 +0100 (CET) Received: from sweet-brew-6.cisco.com (sweet-brew-6.cisco.com [144.254.10.207]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0K19C6F010385; Thu, 20 Jan 2011 02:09:13 +0100 (CET) Date: Thu, 20 Jan 2011 02:09:12 +0100 (CET) From: Andrew Yourtchenko To: Ted Lemon In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:29:35 -0000 On Wed, 19 Jan 2011, Ted Lemon wrote: > On Jan 19, 2011, at 6:11 PM, Carlos Martinez-Cagnazzo wrote: >> I agree that modifying the BSD socket API would be quite a large job, >> and probably it's too early to think about that and having a user-mode >> implementation would help in gaining experience that could be applied >> to changing kernel-level APIs later on > > Actually, the problem is that it's simply not as easy as you suggest, because >the BSD sockets API is essentially synchronous at connection time. Most >applications are not prepared to deal with asynchronous behavior on connect. well, actually if you set O_NONBLOCK then you get EINPROGRESS on connect and have to keep poll()-ing/select()-ing - which most of the apps that deal with more than one socket do just fine. In my experience the problem was less with the asynchronous behaviour per se, but with: 1) giving back a "neigher v4-nor-v6" fd back to socket() - since the connect() was far far far away yet. 2) convincing the resolver-du-jour that I can do it instead. 3) fabricating the "connection in progress" condition on that fake fd from (1) while I do the lookups and connection attempts. As I wrote to Rashmi - I think (1) and (3) might be mitigated by overriding the domain of the socket requested by the app with the one that you *think* may likely succeed based on the past behaviour, and if it does not, then shoehorning the one that does using dup2() call, but I haven't tried this yet. > > This is not to say that doing an in-kernel implementation is easier--there > are serious problems with burying the functionality in the kernel, and I > actually think it's a bad idea. yes and no. Doing anything than the blocking 'hello world' style enumeration of addresses (after the slow-ish getaddrinfo succeeds, oh by the way, it also does not seem to cache the addresses) is a royal pain. And the async DNS resolvers out there all imagine that they are the most important part of the program. Maybe there's just no other solution. > What I _am_ saying is that you might get the > most bang for the buck from fixing a couple of really high-profile > applications, rather than trying to come up with a generic solution. Absolutely agree. I think putting this into FF + Chrom(e|ium) would bring a lot of value. cheers, andrew From fred@cisco.com Wed Jan 19 18:16:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E873A70F1 for ; Wed, 19 Jan 2011 18:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 UiR5IgGI1sWa for ; Wed, 19 Jan 2011 18:16:32 -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 5BAC33A704C for ; Wed, 19 Jan 2011 18:16:32 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 20 Jan 2011 02:19:14 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0K2J8P7001751; Thu, 20 Jan 2011 02:19:13 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Wed, 19 Jan 2011 18:19:14 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Wed, 19 Jan 2011 18:19:14 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Wed, 19 Jan 2011 18:18:57 -0800 Message-Id: References: <4D376481.3010406@kth.se> To: Ted Lemon X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Rashmi Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 02:16:33 -0000 On Jan 19, 2011, at 5:17 PM, Ted Lemon wrote: > On Jan 19, 2011, at 7:54 PM, Andrew Yourtchenko wrote: >> A challenge in doing it in user space is gracefully gluing it into = the different=20 >> process and I/O handling models of the existing apps that assume the = two=20 >> separate stages "lookup the address(es)" and "connect to address" - = they can be=20 >> quite far apart in the applications sometimes. >=20 > I don't see the point of this. No matter how hard you try, your = solution is going to be rickety. Why not just fix the application? Because if we fix the application, we have to fix every application = individually. If we can get it into the OS or into a library that looks = like the OS, we still have to convince existing applications to to use = it, but we can debug it once and future applications don't need to ask = the question.= From Ted.Lemon@nominum.com Wed Jan 19 18:32:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726113A7002 for ; Wed, 19 Jan 2011 18:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 3nKmemzvgjlQ for ; Wed, 19 Jan 2011 18:32:38 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 261B43A6DA7 for ; Wed, 19 Jan 2011 18:32:37 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTTefZ1eqQLvAQFsrEmlv0AI/lIoTEmRb@postini.com; Wed, 19 Jan 2011 18:35:20 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 642451B82B6 for ; Wed, 19 Jan 2011 18:35:19 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 49816190059; Wed, 19 Jan 2011 18:35:19 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 18:35:18 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 19 Jan 2011 21:35:13 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <3945AC5B-807C-43FE-8A3E-F180206D2EF6@nominum.com> References: <4D376481.3010406@kth.se> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" , Rashmi Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 02:32:39 -0000 On Jan 19, 2011, at 9:18 PM, Fred Baker wrote: > Because if we fix the application, we have to fix every application = individually. If we can get it into the OS or into a library that looks = like the OS, we still have to convince existing applications to to use = it, but we can debug it once and future applications don't need to ask = the question. I think you and I are talking about different things. I think you are = talking here about your connect_by_name() api, right? I don't entirely = agree that that's the right API, but I agree in principle that an API is = a good idea, for just the reason you've stated. What I'm arguing probably isn't going to work is a shim that works with = an application that calls gethostbyname() and then connect(). I can = imagine it working in some cases, but it would almost certainly also = cause instability. From fernando.gont.netbook.win@gmail.com Wed Jan 19 19:34:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A061228B797 for ; Wed, 19 Jan 2011 19:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 Zfag3NCyG1tI for ; Wed, 19 Jan 2011 19:34:42 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 7824E3A7099 for ; Wed, 19 Jan 2011 19:34:42 -0800 (PST) Received: by gwb20 with SMTP id 20so37255gwb.31 for ; Wed, 19 Jan 2011 19:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=0rsWhFTkz2j8d9UBqBa7qfVdzbDR8JQaFDkjuh8M4OA=; b=HZZmjl7QX0IFD6FQXcRKxfiYa8eFf74uqn3+DFN1DKd9nqo4Dg1grKpj4zqpZRWzQl SxYQbZgrV4tUvYKlaAgS55GQopQhuNzxi1biabeOXV6kBLx5tOpQN46ESUjrjUAHfEWw bc/y6KlxnIf5tA5LB0dWuGPSg/MpPoXwA5Tf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=GVk56N8Pmk0xUcRncMfh5A/eP01K4qm6RBivBb5RxupZhAay7riSOwmI/yrdy7Rq6o /08vSi0RsvuEZ92CUgmN2SkO5sohsYVn8+ZRVGJFwB7COgOibw1OaumePGZ5KekUK8fc iYr06VxZBdcwkXH27FqsspvMq32eJasTQ7CCM= Received: by 10.90.37.28 with SMTP id k28mr1935389agk.53.1295494644033; Wed, 19 Jan 2011 19:37:24 -0800 (PST) Received: from [192.168.0.120] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id i10sm9311036anh.12.2011.01.19.19.37.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Jan 2011 19:37:22 -0800 (PST) Sender: Fernando Gont Message-ID: <4D377F96.8010205@gont.com.ar> Date: Wed, 19 Jan 2011 21:19:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <234286.96570.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Int-area] End-to-end "address transparency" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 03:34:43 -0000 Hi, Fred, On 17/01/2011 03:13 p.m., Fred Baker wrote: >> I thought NAT66 which is stateless fits much better into IPv6. > > This is why I ask people for precision in the use of the term. The > current nat66 draft is not a filter, and it is stateless. The stateless-ness assumes that ALGs are *not* implemented for applications that send IPv6 addresses in the application data stream. (Althought I do agree your assessment that NAT66 is not a filter). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From simon.perreault@viagenie.ca Thu Jan 20 05:44:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771623A6ED4 for ; Thu, 20 Jan 2011 05:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 yLOp1NiE4sZa for ; Thu, 20 Jan 2011 05:44:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4B8603A70F4 for ; Thu, 20 Jan 2011 05:44:04 -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 7DED120D24; Thu, 20 Jan 2011 08:46:46 -0500 (EST) Message-ID: <4D383CC5.3080603@viagenie.ca> Date: Thu, 20 Jan 2011 08:46:45 -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: Andrew Yourtchenko References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:44:05 -0000 On 2011-01-19 20:16, Andrew Yourtchenko wrote: > The reason I used threads in my proof-of-concept code was that I wanted > to stick to getaddrinfo() which does not lend itself to more than one > in-progress lookup at a time. Strictly speaking, it is impossible to properly implement happy eyeballs in terms of getaddrinfo() (with or without threads). That's because in case getaddrinfo() performs multiple queries (e.g. a DNS A query and a DNS AAAA query), it will only return when all queries have completed. This prevents you from initiating connections as soon as you have any answer. With or without threads, a good happy eyeballs implementation needs something less synchronous than getaddrinfo(). 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 ayourtch@cisco.com Thu Jan 20 09:27:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF69D3A7150 for ; Thu, 20 Jan 2011 09:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.395, 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 Sx-j4gNeWS5K for ; Thu, 20 Jan 2011 09:27:37 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 5D6743A703D for ; Thu, 20 Jan 2011 09:27:36 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0KHQY53026510; Thu, 20 Jan 2011 18:26:34 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0KHQVAl019595; Thu, 20 Jan 2011 18:26:31 +0100 (CET) Date: Thu, 20 Jan 2011 18:26:31 +0100 (CET) From: Andrew Yourtchenko To: Simon Perreault In-Reply-To: <4D383CC5.3080603@viagenie.ca> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:27:39 -0000 On Thu, 20 Jan 2011, Simon Perreault wrote: > On 2011-01-19 20:16, Andrew Yourtchenko wrote: >> The reason I used threads in my proof-of-concept code was that I wanted >> to stick to getaddrinfo() which does not lend itself to more than one >> in-progress lookup at a time. > > Strictly speaking, it is impossible to properly implement happy eyeballs > in terms of getaddrinfo() (with or without threads). That's because in > case getaddrinfo() performs multiple queries (e.g. a DNS A query and a > DNS AAAA query), it will only return when all queries have completed. > This prevents you from initiating connections as soon as you have any > answer. What I was doing was firing up two threads: thread 1: af = AF_INET thread 2: af = AF_INET6; both threads, after: hints.ai_family = af; hints.ai_socktype = SOCK_STREAM; hints.ai_flags = 0; hints.ai_protocol = 0; s = getaddrinfo(node, service, &hints, &result); // try to connect here. Could be that I was wrong in my tests that showed the two lookups in two threads were running ok. But setting the hints does appear to limit the lookups to only one AF. (here's the above snippet wrapped into the proper main(): https://gist.github.com/788223) > With or without threads, a good happy eyeballs implementation needs > something less synchronous than getaddrinfo(). Definitely cleaner that way, yes. Not that one can't abstract away the getaddrinfo() by having a pool of fork()ed blocking workers, but that design would not win the beauty contests. cheers, andrew > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > From simon.perreault@viagenie.ca Thu Jan 20 09:59:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B0A3A7170 for ; Thu, 20 Jan 2011 09:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 N5E0VYtkE1ep for ; Thu, 20 Jan 2011 09:59:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 813933A7162 for ; Thu, 20 Jan 2011 09:59:30 -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 8073A20EFE; Thu, 20 Jan 2011 13:02:13 -0500 (EST) Message-ID: <4D3878A5.8080905@viagenie.ca> Date: Thu, 20 Jan 2011 13:02:13 -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: Andrew Yourtchenko References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:59:32 -0000 On 2011-01-20 12:26, Andrew Yourtchenko wrote: > What I was doing was firing up two threads: > > thread 1: > af = AF_INET > thread 2: > af = AF_INET6; > > both threads, after: > hints.ai_family = af; > hints.ai_socktype = SOCK_STREAM; > hints.ai_flags = 0; > hints.ai_protocol = 0; > s = getaddrinfo(node, service, &hints, &result); > > // try to connect here. It's a good approximation. But, again strictly speaking, it doesn't take into account the fact that getaddrinfo() will potentially look into places other than DNS. For example, the well known /etc/hosts file will return results much faster than DNS. Or other sources, as configured in e.g. /etc/nsswitch.conf (e.g. SMB names). Even only considering DNS there is the possibility that the answer section could span multiple packets. So it's all these corner cases that speak to the need for a truly asynchronous getaddrinfo(), one that could be used with or without threads. 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 ayourtch@cisco.com Thu Jan 20 11:00:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B433A67AB for ; Thu, 20 Jan 2011 11:00:40 -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 2CYR-z-3OpNt for ; Thu, 20 Jan 2011 11:00:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 2F7BB3A67AA for ; Thu, 20 Jan 2011 11:00:39 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0KJ3M1c003513; Thu, 20 Jan 2011 20:03:22 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0KJ3Kjs003123; Thu, 20 Jan 2011 20:03:21 +0100 (CET) Date: Thu, 20 Jan 2011 20:03:20 +0100 (CET) From: Andrew Yourtchenko To: Simon Perreault In-Reply-To: <4D3878A5.8080905@viagenie.ca> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <4D3878A5.8080905@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 19:00:40 -0000 On Thu, 20 Jan 2011, Simon Perreault wrote: > On 2011-01-20 12:26, Andrew Yourtchenko wrote: >> What I was doing was firing up two threads: >> >> thread 1: >> af = AF_INET >> thread 2: >> af = AF_INET6; >> >> both threads, after: >> hints.ai_family = af; >> hints.ai_socktype = SOCK_STREAM; >> hints.ai_flags = 0; >> hints.ai_protocol = 0; >> s = getaddrinfo(node, service, &hints, &result); >> >> // try to connect here. > > It's a good approximation. > > But, again strictly speaking, it doesn't take into account the fact that > getaddrinfo() will potentially look into places other than DNS. For > example, the well known /etc/hosts file will return results much faster > than DNS. Or other sources, as configured in e.g. /etc/nsswitch.conf > (e.g. SMB names). Even only considering DNS there is the possibility > that the answer section could span multiple packets. Well, in this case it'd be the getaddrinfo()'s problem, not mine ? (that's precisely why I hoped to offload all these details to getaddrinfo which is already supposed to take care of them.) > > So it's all these corner cases that speak to the need for a truly > asynchronous getaddrinfo(), one that could be used with or without threads. Ideally, asynchronous connect_by_name(), yes. Async getaddrinfo() could be a good start to that - though it would solve half of the problem. cheers, andrew > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > From simon.perreault@viagenie.ca Thu Jan 20 11:12:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDFC3A67D1 for ; Thu, 20 Jan 2011 11:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.087, 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 5QA+lqcwwQqT for ; Thu, 20 Jan 2011 11:12:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 00B2E3A67CF for ; Thu, 20 Jan 2011 11:12:33 -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 E195321BC0; Thu, 20 Jan 2011 14:15:15 -0500 (EST) Message-ID: <4D3889C3.4060603@viagenie.ca> Date: Thu, 20 Jan 2011 14:15:15 -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: Andrew Yourtchenko References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <4D3878A5.8080905@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 19:12:34 -0000 On 2011-01-20 14:03, Andrew Yourtchenko wrote: >> But, again strictly speaking, it doesn't take into account the fact that >> getaddrinfo() will potentially look into places other than DNS. For >> example, the well known /etc/hosts file will return results much faster >> than DNS. Or other sources, as configured in e.g. /etc/nsswitch.conf >> (e.g. SMB names). Even only considering DNS there is the possibility >> that the answer section could span multiple packets. > > Well, in this case it'd be the getaddrinfo()'s problem, not mine ? > (that's precisely why I hoped to offload all these details to > getaddrinfo which is already supposed to take care of them.) My point is that getaddrinfo() will only return once it has *all* the results it could get, from *all* possible sources. What we'd like instead is to be notified of results as they come in so that we can initiate connections as soon as possible. > Ideally, asynchronous connect_by_name(), yes. Async getaddrinfo() could > be a good start to that - though it would solve half of the problem. Agreed. (But I think the async getaddrinfo() is the hard part. The rest is already possible (and fairly easy) using regular BSD sockets.) 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 ayourtch@cisco.com Thu Jan 20 12:03:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6003A680E for ; Thu, 20 Jan 2011 12:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 r8l9qxnrz1y1 for ; Thu, 20 Jan 2011 12:03:18 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id D24DF3A67EB for ; Thu, 20 Jan 2011 12:03:17 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0KJY9AL005635; Thu, 20 Jan 2011 20:34:09 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0KJY0Sm001732; Thu, 20 Jan 2011 20:34:00 +0100 (CET) Date: Thu, 20 Jan 2011 20:34:00 +0100 (CET) From: Andrew Yourtchenko To: Simon Perreault In-Reply-To: <4D3889C3.4060603@viagenie.ca> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <4D3878A5.8080905@viagenie.ca> <4D3889C3.4060603@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 20:03:20 -0000 On Thu, 20 Jan 2011, Simon Perreault wrote: > On 2011-01-20 14:03, Andrew Yourtchenko wrote: >>> But, again strictly speaking, it doesn't take into account the fact that >>> getaddrinfo() will potentially look into places other than DNS. For >>> example, the well known /etc/hosts file will return results much faster >>> than DNS. Or other sources, as configured in e.g. /etc/nsswitch.conf >>> (e.g. SMB names). Even only considering DNS there is the possibility >>> that the answer section could span multiple packets. >> >> Well, in this case it'd be the getaddrinfo()'s problem, not mine ? >> (that's precisely why I hoped to offload all these details to >> getaddrinfo which is already supposed to take care of them.) > > My point is that getaddrinfo() will only return once it has *all* the > results it could get, from *all* possible sources. What we'd like > instead is to be notified of results as they come in so that we can > initiate connections as soon as possible. Not for the Happy Eyeballs case - there we'd want two two threads. Blue pill thread where the getaddrinfo() does only the IPv4-related lookups and then connects, and red pill, where the getaddrinfo() does only IPv6-related lookups and then connects. Within each of these parallel worlds the reply should come in a single packet - so we can start connecting. The fact that we want two lookups is dictated by trying to avoid an extra lookup and a connection attempt if we have a reasonable assurance it won't work anyway. > >> Ideally, asynchronous connect_by_name(), yes. Async getaddrinfo() could >> be a good start to that - though it would solve half of the problem. > > Agreed. > > (But I think the async getaddrinfo() is the hard part. The rest is > already possible (and fairly easy) using regular BSD sockets.) Yes. The only detail (which I feel we also agree on) is that it is boring to have to write the code to start the connection attempt after the async DNS lookup result comes back. I have a hostname in the config or entered by the user, and I want to get a working connection. I'd be happy to get an fd that is "EINPROGRESS" until what needs to happen happens somewhere in the background. cheers, andrew > > 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 mohacsi@niif.hu Fri Jan 21 00:02:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E48B3A68E9 for ; Fri, 21 Jan 2011 00:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] 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 3f0u020M+y5i for ; Fri, 21 Jan 2011 00:02:48 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id BD4363A68D9 for ; Fri, 21 Jan 2011 00:02:47 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id E8820853C5; Fri, 21 Jan 2011 09:05:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id HFek8lIXC5Oa; Fri, 21 Jan 2011 09:05:15 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 3A16A87203; Fri, 21 Jan 2011 09:05:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 348DC87202; Fri, 21 Jan 2011 09:05:15 +0100 (CET) Date: Fri, 21 Jan 2011 09:05:15 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Andrew Yourtchenko In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 08:02:49 -0000 On Thu, 20 Jan 2011, Andrew Yourtchenko wrote: > > > On Thu, 20 Jan 2011, Simon Perreault wrote: > >> On 2011-01-19 20:16, Andrew Yourtchenko wrote: >>> The reason I used threads in my proof-of-concept code was that I wanted >>> to stick to getaddrinfo() which does not lend itself to more than one >>> in-progress lookup at a time. >> >> Strictly speaking, it is impossible to properly implement happy eyeballs >> in terms of getaddrinfo() (with or without threads). That's because in >> case getaddrinfo() performs multiple queries (e.g. a DNS A query and a >> DNS AAAA query), it will only return when all queries have completed. >> This prevents you from initiating connections as soon as you have any >> answer. > > What I was doing was firing up two threads: > > thread 1: > af = AF_INET > thread 2: > af = AF_INET6; > > both threads, after: > hints.ai_family = af; > hints.ai_socktype = SOCK_STREAM; > hints.ai_flags = 0; > hints.ai_protocol = 0; > s = getaddrinfo(node, service, &hints, &result); > > // try to connect here. > > Could be that I was wrong in my tests that showed the two lookups in two > threads were running ok. But setting the hints does appear to limit the > lookups to only one AF. (here's the above snippet wrapped into the proper > main(): https://gist.github.com/788223) > > >> With or without threads, a good happy eyeballs implementation needs >> something less synchronous than getaddrinfo(). > > Definitely cleaner that way, yes. Not that one can't abstract away the > getaddrinfo() by having a pool of fork()ed blocking workers, but that design > would not win the beauty contests. > > cheers, > andrew I don't see the point in your implementation. The speed of the DNS lookup for specific records does not have any relation to speed of connectivity or responsiveness for any specific protocol. I think what can help: 1. do DNS lookup via getaddrinfo() 2. do parallel connection for all the IPv4 and IPv6 address returned. 3. first succesful - keep it. terminate all connection attempts for the others. Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > >> >> 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 >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ayourtch@cisco.com Fri Jan 21 02:29:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40843A6909 for ; Fri, 21 Jan 2011 02:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 WCC0UsI6zwM3 for ; Fri, 21 Jan 2011 02:29:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 8042D3A6902 for ; Fri, 21 Jan 2011 02:29:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0L9lhqN008403; Fri, 21 Jan 2011 10:47:43 +0100 (CET) Received: from sweet-brew-3.cisco.com (sweet-brew-3.cisco.com [144.254.10.204]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0L9ld8s026471; Fri, 21 Jan 2011 10:47:39 +0100 (CET) Date: Fri, 21 Jan 2011 10:47:39 +0100 (CET) From: Andrew Yourtchenko To: Mohacsi Janos In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 10:29:36 -0000 On Fri, 21 Jan 2011, Mohacsi Janos wrote: > > I don't see the point in your implementation. The speed of the DNS lookup for > specific records does not have any relation to speed of connectivity or > responsiveness for any specific protocol. I think what can help: Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=505105 for an example why. cheers, andrew > 1. do DNS lookup via getaddrinfo() > 2. do parallel connection for all the IPv4 and IPv6 address returned. > 3. first succesful - keep it. terminate all connection attempts for the > others. > > Best Regards, > > Janos Mohacsi > Head of HBONE+ project > Network Engineer, Deputy Director of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > >> >> >>> >>> 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 >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jan 21 02:47:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BB83A691E for ; Fri, 21 Jan 2011 02:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 dF+cRnmdXXYN for ; Fri, 21 Jan 2011 02:47:30 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 733F13A68DC for ; Fri, 21 Jan 2011 02:47:30 -0800 (PST) Received: from 219-90-172-134.ip.adam.com.au ([219.90.172.134] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PgEZD-0006L4-6N; Fri, 21 Jan 2011 21:20:07 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 8B3BF3B335; Fri, 21 Jan 2011 21:20:06 +1030 (CST) Date: Fri, 21 Jan 2011 21:20:06 +1030 From: Mark Smith To: Andrew Yourtchenko Message-ID: <20110121212006.63d6d2d7@opy.nosense.org> In-Reply-To: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Martinez-Cagnazzo , Carlos Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 10:47:31 -0000 SCTP being attempted / used in any of these implementations? I'm dealing with a few IPv6 residential CPE implementations who's firewalls still believe the only transport protocols are TCP and UDP. It'd be nice to be able to show that other transport protocols are available and useful once NAT isn't in the picture. Thanks, Mark. From jouni.nospam@gmail.com Fri Jan 21 03:00:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F243A691E for ; Fri, 21 Jan 2011 03:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 S5PhtZel9459 for ; Fri, 21 Jan 2011 03:00:19 -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 2B5BA3A6926 for ; Fri, 21 Jan 2011 03:00:16 -0800 (PST) Received: by eyd10 with SMTP id 10so843461eyd.31 for ; Fri, 21 Jan 2011 03:03:01 -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=kWAKfmckwa3OYmMjU2J+6TerXVIVobyMHpd+KKWF8wk=; b=OCN5tlO16wmJOWeU8Ifxq25mHAIQtcVCqSk4GHQoZ7Z/Dpd3snMwFkv7ogShEPzW3+ y5IMs0ARJentg6bbODbk98gMkRlN6g3fAHXoFcUQFCGUvStjzbf4tcCwnzKqYCL0Smq/ 5iEMWpQydEwk1R//jGl1hz1r70zfSPW1gV2Zg= 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=udg4kxqPrAjiUwuAB5apLA+ETbUQMNvJHUkh7f0pHYTD+8zcLcFCqNwfamVGVqcwoN 9/HKLoDqAAWJi60BzeZWuj/KO4/Ie2+ub0XJqyNbaVKyHeEqBRq2btFdKW3GcrWf2rid rUuWOOSbviDggF2veM7BQXbdm55fu/QJ6Sb0Q= Received: by 10.213.10.143 with SMTP id p15mr699915ebp.0.1295607781154; Fri, 21 Jan 2011 03:03:01 -0800 (PST) Received: from [192.168.141.77] ([213.246.198.210]) by mx.google.com with ESMTPS id x54sm7397618eeh.5.2011.01.21.03.02.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 03:03:00 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jan 2011 13:02:57 +0200 References: <20110121104801.07EDE3A6923@core3.amsl.com> To: IPv6 Ops WG Message-Id: <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 11:00:20 -0000 Folks, We have updated the I-D and tried to reflect the recent discussion in = the V6OPS list as well we could for the time being. Thanks to everybody = who provided constructive feedback. The attempt has been making the I-D = just a description of the existing architecture. I hope we can move I-D = forward rather soon as it has been around for quite some time already. = Additional comments and feedback are of course solicited. - Jouni Begin forwarded message: > From: IETF I-D Submission Tool > Date: January 21, 2011 12:48:01 PM GMT+02:00 > To: jouni.nospam@gmail.com > Cc: = jonne.soininen@nsn.com,basavaraj.patil@nokia.com,teemu.savolainen@nokia.co= m,gabor.bajko@nokia.com,kaisu.iisakkila@renesasmobile.com > Subject: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05=20= >=20 >=20 > A new version of I-D, draft-korhonen-v6ops-3gpp-eps-05.txt has been = successfully submitted by Jouni Korhonen and posted to the IETF = repository. >=20 > Filename: draft-korhonen-v6ops-3gpp-eps > Revision: 05 > Title: IPv6 in 3GPP Evolved Packet System > Creation_date: 2011-01-21 > WG ID: Independent Submission > Number_of_pages: 26 >=20 > Abstract: > Internet connectivity and use of data services in 3GPP based mobile > networks has increased rapidly as a result of smart phones, broadband > service via HSPA and HSPA+ networks, competitive service offerings by > operators and a large number of applications. Operators who have > deployed networks based on 3GPP architectures are facing IPv4 address > shortages. With the impending exhaustion of available IPv4 addresses > from the registries there is an increased emphasis for operators to > migrate to IPv6. This document describes the support for IPv6 in > 3GPP network architectures. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From mohacsi@niif.hu Fri Jan 21 03:26:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C00D3A6930 for ; Fri, 21 Jan 2011 03:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] 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 LFkAmhcead3I for ; Fri, 21 Jan 2011 03:26:23 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id F035E3A6928 for ; Fri, 21 Jan 2011 03:26:22 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id C3A5E86DA2; Fri, 21 Jan 2011 12:29:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id NJmFH9q4pZDV; Fri, 21 Jan 2011 12:28:52 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 4BADD8720C; Fri, 21 Jan 2011 12:28:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 44D7A87203; Fri, 21 Jan 2011 12:28:52 +0100 (CET) Date: Fri, 21 Jan 2011 12:28:52 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Andrew Yourtchenko In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 11:26:25 -0000 Dear Andrew, On Fri, 21 Jan 2011, Andrew Yourtchenko wrote: > > > On Fri, 21 Jan 2011, Mohacsi Janos wrote: >> >> I don't see the point in your implementation. The speed of the DNS lookup >> for specific records does not have any relation to speed of connectivity or >> responsiveness for any specific protocol. I think what can help: > > Take a look at > > https://bugzilla.redhat.com/show_bug.cgi?id=505105 > > for an example why. For example: - Broken Fedora Core 11 gai implementation using same source port- Fedora needs to be fixed. - Broken stateful inspection of the DNS UDP traffic in some firewalls/load-balancers - broken firewalls/load-balancers needs to be fixed. But beware brokenness of AAAA DNS resolution nothing to do with brokenness of IPv6 connectivity - which is is the original intention of happy eyeball draft. Best Regards, Janos > > cheers, > andrew > >> 1. do DNS lookup via getaddrinfo() >> 2. do parallel connection for all the IPv4 and IPv6 address returned. >> 3. first succesful - keep it. terminate all connection attempts for the >> others. >> >> Best Regards, >> >> Janos Mohacsi >> Head of HBONE+ project >> Network Engineer, Deputy Director of Network Planning and Projects >> NIIF/HUNGARNET, HUNGARY >> Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 >> >> >>> >>> >>>> >>>> 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 >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> > From pekkas@netcore.fi Fri Jan 21 03:51:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2843A693B for ; Fri, 21 Jan 2011 03:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 6OzAZsaJkmIf for ; Fri, 21 Jan 2011 03:51:49 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 1C7AB3A693A for ; Fri, 21 Jan 2011 03:51:48 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p0LBsSiO007705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 13:54:28 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p0LBsSsk007702; Fri, 21 Jan 2011 13:54:28 +0200 Date: Fri, 21 Jan 2011 13:54:28 +0200 (EET) From: Pekka Savola To: Mohacsi Janos In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 11:51:51 -0000 On Fri, 21 Jan 2011, Mohacsi Janos wrote: > But beware brokenness of AAAA DNS resolution nothing to do with brokenness of > IPv6 connectivity - which is is the original intention of happy eyeball > draft. The eyeball won't be happy when s/he tries to connect to an IPv4-only destination, it fails. But I agree that multiple and different mitigation methods for various error conditions is another and possibly useful approach to tackle the overall problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From bzeeb-lists@lists.zabbadoz.net Fri Jan 21 03:52:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75EB3A693A for ; Fri, 21 Jan 2011 03:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=-2.349, BAYES_00=-2.599, GB_SUMOF=5] 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 CMhgw1Pr0m8T for ; Fri, 21 Jan 2011 03:52:23 -0800 (PST) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by core3.amsl.com (Postfix) with ESMTP id A2D943A693C for ; Fri, 21 Jan 2011 03:52:22 -0800 (PST) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D024641C6B4; Fri, 21 Jan 2011 12:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id pNvVV1zI0AfP; Fri, 21 Jan 2011 12:55:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E169541C6A1; Fri, 21 Jan 2011 12:55:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AFF034448F3; Fri, 21 Jan 2011 11:53:12 +0000 (UTC) Date: Fri, 21 Jan 2011 11:53:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrew Yourtchenko In-Reply-To: Message-ID: <20110121113401.K3489@maildrop.int.zabbadoz.net> References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 11:52:23 -0000 On Fri, 21 Jan 2011, Andrew Yourtchenko wrote: Dear Andrew, > On Fri, 21 Jan 2011, Mohacsi Janos wrote: >> >> I don't see the point in your implementation. The speed of the DNS lookup >> for specific records does not have any relation to speed of connectivity or >> responsiveness for any specific protocol. I think what can help: > > Take a look at > > https://bugzilla.redhat.com/show_bug.cgi?id=505105 > > for an example why. That is a rather bad example to show people for your case. Do you really want to 1) have people having a good experience, 2) work around obvious brokeness in device for standards compliant queries, 3) show that despite how much people (grudgingly) try to work around brokeness, brokeness will stay, and 4) at the same time add more complexity to the procotol/standards just asking for more problems? The result of that will be obvious. Ignoring the above sample, I see the point that people think that the sum of DNS lookup time + connect time is a good metric for better user experience. I am not saying I confirm that. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From ayourtch@cisco.com Fri Jan 21 04:02:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C513A693B for ; Fri, 21 Jan 2011 04:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 vNlNCBDl1xpe for ; Fri, 21 Jan 2011 04:02:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 2294E3A683E for ; Fri, 21 Jan 2011 04:02:38 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0LC5OCd020064; Fri, 21 Jan 2011 13:05:24 +0100 (CET) Received: from sweet-brew-3.cisco.com (sweet-brew-3.cisco.com [144.254.10.204]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0LC5Nuh014164; Fri, 21 Jan 2011 13:05:23 +0100 (CET) Date: Fri, 21 Jan 2011 13:05:23 +0100 (CET) From: Andrew Yourtchenko To: Mohacsi Janos In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 12:02:40 -0000 Dear Mohacsi, On Fri, 21 Jan 2011, Mohacsi Janos wrote: > For example: > > - Broken Fedora Core 11 gai implementation using same source port- Fedora > needs to be fixed. > > - Broken stateful inspection of the DNS UDP traffic in some > firewalls/load-balancers - broken firewalls/load-balancers needs to be fixed. > > But beware brokenness of AAAA DNS resolution nothing to do with brokenness of > IPv6 connectivity - which is is the original intention of happy eyeball > draft. No, the original intent of the happy eyeballs is improving the end-user experience. As a user I do not care if it is the AAAA lookup that fails or the connect() that fails. They are done in sequence, and the end result is exactly the same, right ? cheers, andrew > Best Regards, > Janos > > >> >> cheers, >> andrew >> >>> 1. do DNS lookup via getaddrinfo() >>> 2. do parallel connection for all the IPv4 and IPv6 address returned. >>> 3. first succesful - keep it. terminate all connection attempts for the >>> others. >>> >>> Best Regards, >>> >>> Janos Mohacsi >>> Head of HBONE+ project >>> Network Engineer, Deputy Director of Network Planning and Projects >>> NIIF/HUNGARNET, HUNGARY >>> Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 >>> >>> >>>> >>>> >>>>> >>>>> 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 >>>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >> > From ayourtch@cisco.com Fri Jan 21 04:17:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3625E3A694E for ; Fri, 21 Jan 2011 04:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 TtlyvJSGjBRK for ; Fri, 21 Jan 2011 04:17:55 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id E83DE3A6944 for ; Fri, 21 Jan 2011 04:17:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0LCDA46020683; Fri, 21 Jan 2011 13:13:10 +0100 (CET) Received: from sweet-brew-3.cisco.com (sweet-brew-3.cisco.com [144.254.10.204]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0LCDAlZ023951; Fri, 21 Jan 2011 13:13:10 +0100 (CET) Date: Fri, 21 Jan 2011 13:13:10 +0100 (CET) From: Andrew Yourtchenko To: Mark Smith In-Reply-To: <20110121212006.63d6d2d7@opy.nosense.org> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121212006.63d6d2d7@opy.nosense.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 12:17:56 -0000 On Fri, 21 Jan 2011, Mark Smith wrote: > > SCTP being attempted / used in any of these implementations? I'm dealing > with a few IPv6 residential CPE implementations who's firewalls still > believe the only transport protocols are TCP and UDP. It'd be nice to > be able to show that other transport protocols are available and > useful once NAT isn't in the picture. > SCTP was not in the proof of concept code that I was doing - but there was a separate effort on it that was demoed right after the happy eyeballs presentation at IETF75 - if my memory serves me well, it was in the TSVAREA meeting. cheers, andrew From Ted.Lemon@nominum.com Fri Jan 21 06:16:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8DA3A6992 for ; Fri, 21 Jan 2011 06:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 KGwES46tOJ1B for ; Fri, 21 Jan 2011 06:16:38 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 25F553A6990 for ; Fri, 21 Jan 2011 06:16:38 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTTmV7FJxS4//TYwzrRqt8+SxirGw30Aj@postini.com; Fri, 21 Jan 2011 06:19:24 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0B8721B828F for ; Fri, 21 Jan 2011 06:19:24 -0800 (PST) Received: from webmail.nominum.com (exchange-10.nominum.com [64.89.228.57]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "exchange-10.win.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id ED634190052; Fri, 21 Jan 2011 06:19:23 -0800 (PST) Received: from CAS-01.WIN.NOMINUM.COM (64.89.228.131) by exchange-10.WIN.NOMINUM.COM (64.89.228.57) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 06:19:24 -0800 Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0255.000; Fri, 21 Jan 2011 06:19:24 -0800 From: Ted Lemon To: Andrew Yourtchenko Thread-Topic: [v6ops] Happy eyeballs implementation Thread-Index: Acu4yMYPDre3Rgv7TUaO8OwP1AB4TQAvDdyAAAOTh4AAA4jyAAABRnyA//+fU3A= Date: Fri, 21 Jan 2011 14:19:22 +0000 Message-ID: <77B62572-6771-4C66-B523-7DA50C0432B2@nominum.com> References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> , In-Reply-To: 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: IPv6 Ops WG , Martinez-Cagnazzo , Carlos Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:16:38 -0000 On Jan 21, 2011, at 7:05 AM, "Andrew Yourtchenko" wrot= e: > As a user I do not care if it is the AAAA lookup that fails or the connec= t() that fails. They are done in sequence, and the end result is exactly th= e same, right ? Right. My reaction to this bug report (which is based on skimming it, so I = may have missed some detail) is to use a different socket for every query t= o avoid triggering broken middleboxes. Of course, this creates new brokenne= ss. But the bottom line is that all we can ever do is try to make things w= ork, and observe the ways they fail to work, and try again. = From mohacsi@niif.hu Fri Jan 21 07:11:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24FB53A6A0D for ; Fri, 21 Jan 2011 07:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] 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 MfVroNaOIamJ for ; Fri, 21 Jan 2011 07:11:38 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 36A623A6A05 for ; Fri, 21 Jan 2011 07:11:37 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 5BE2A84E5C; Fri, 21 Jan 2011 16:14:22 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id yA9lejuiUvXr; Fri, 21 Jan 2011 16:14:06 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id BE4638721C; Fri, 21 Jan 2011 16:14:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id B236B871D9; Fri, 21 Jan 2011 16:14:06 +0100 (CET) Date: Fri, 21 Jan 2011 16:14:06 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Andrew Yourtchenko In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 15:11:39 -0000 On Fri, 21 Jan 2011, Andrew Yourtchenko wrote: > Dear Mohacsi, > > On Fri, 21 Jan 2011, Mohacsi Janos wrote: > >> For example: >> >> - Broken Fedora Core 11 gai implementation using same source port- Fedora >> needs to be fixed. >> >> - Broken stateful inspection of the DNS UDP traffic in some >> firewalls/load-balancers - broken firewalls/load-balancers needs to be >> fixed. >> >> But beware brokenness of AAAA DNS resolution nothing to do with brokenness >> of IPv6 connectivity - which is is the original intention of happy eyeball >> draft. > > No, the original intent of the happy eyeballs is improving the end-user > experience. Does you intention also to improve IPv4 copnnectivity brokenness? > > As a user I do not care if it is the AAAA lookup that fails or the connect() > that fails. They are done in sequence, and the end result is exactly the > same, right ? Then I think the algorithm is slighlty more complex: 1. define list_of_sockaddr 2. do_parallel lookup for_each address_family with timeout < tolerable_for end_users/2 ---- if (found_result) list_of_sockaddr.append(lookup_result) 3. do_parallel connect() for_each list_of_sockaddr with timout < tolerable_for_end_users/2 ---- if (connected) terminate all other_connect_threads 4. communication as usual Also causes problem of not possible to honor RFC 3484 policy tables.... Best Regards, Janos Mohacsi > > > >> Best Regards, >> Janos >> >> >>> >>> cheers, >>> andrew >>> >>>> 1. do DNS lookup via getaddrinfo() >>>> 2. do parallel connection for all the IPv4 and IPv6 address returned. >>>> 3. first succesful - keep it. terminate all connection attempts for the >>>> others. >>>> >>>> Best Regards, >>>> >>>> Janos Mohacsi >>>> Head of HBONE+ project >>>> Network Engineer, Deputy Director of Network Planning and Projects >>>> NIIF/HUNGARNET, HUNGARY >>>> Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> >>> >> > From jbates@brightok.net Fri Jan 21 07:36:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB97E3A6A1A for ; Fri, 21 Jan 2011 07:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 y8W-t05F3vFm for ; Fri, 21 Jan 2011 07:36:45 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 262BA3A6A18 for ; Fri, 21 Jan 2011 07:36:44 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0LFdTtA004406; Fri, 21 Jan 2011 09:39:29 -0600 (CST) Message-ID: <4D39A8B1.5080809@brightok.net> Date: Fri, 21 Jan 2011 09:39:29 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mohacsi Janos References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 15:36:46 -0000 On 1/21/2011 9:14 AM, Mohacsi Janos wrote: > 1. define list_of_sockaddr > 2. do_parallel lookup for_each address_family with timeout < > tolerable_for end_users/2 > ---- if (found_result) list_of_sockaddr.append(lookup_result) > 3. do_parallel connect() for_each list_of_sockaddr with timout < > tolerable_for_end_users/2 > ---- if (connected) terminate all other_connect_threads > 4. communication as usual Actually, 2/3 should be combined. What should be parallel is the combined lookup/connect. First protocol to make connect wins. > Also causes problem of not possible to honor RFC 3484 policy tables.... While it will circumvent the v4/v6 policy, it should still follow the v6 policy itself. Not sure if this can be done with the mechanism you're wanting to do, but the v6 address selection should be utilized. Jack From fred@cisco.com Fri Jan 21 08:43:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310C83A6A58 for ; Fri, 21 Jan 2011 08:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.147 X-Spam-Level: X-Spam-Status: No, score=-110.147 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 l6dTVi4RO82S for ; Fri, 21 Jan 2011 08:43:13 -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 66C033A6A47 for ; Fri, 21 Jan 2011 08:43:13 -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: AvsEAOtGOU2rRN+K/2dsb2JhbACkZXOiQpsahVAEhG+GMIMl Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2011 16:45:59 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0LGjt9B014603 for ; Fri, 21 Jan 2011 16:45:59 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Fri, 21 Jan 2011 08:45:59 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Fri, 21 Jan 2011 08:45:59 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> Date: Fri, 21 Jan 2011 08:45:45 -0800 Message-Id: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 16:43:14 -0000 On Jan 21, 2011, at 3:02 AM, jouni korhonen wrote: > We have updated the I-D and tried to reflect the recent discussion in = the V6OPS list as well we could for the time being. Thanks to everybody = who provided constructive feedback. The attempt has been making the I-D = just a description of the existing architecture. I hope we can move I-D = forward rather soon as it has been around for quite some time already. = Additional comments and feedback are of course solicited. OK, different question for the group. At IETF-79, we asked (in the = survey) whether this should become a working group draft, and opinion = was supportive of the draft but divided on status. In my opinion, we = should adopt this as a working group draft at this time, run it around = the block at IETF-80, and then ship it to the IESG. Opinions? Shall we: - tell the chairs to send it to the IESG now as an individual = submission? - adopt it as a working group draft and immediately WGLC it? - adopt it as a working group draft and continue discussion?= From joelja@bogus.com Fri Jan 21 09:40:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A2A3A6A67 for ; Fri, 21 Jan 2011 09:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 mye5xL730LRf for ; Fri, 21 Jan 2011 09:40:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4B8B53A6A58 for ; Fri, 21 Jan 2011 09:40:35 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0LHgd2V093500 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 21 Jan 2011 17:42:39 GMT (envelope-from joelja@bogus.com) Message-ID: <4D39C591.80600@bogus.com> Date: Fri, 21 Jan 2011 09:42:41 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 17:40:36 -0000 On 1/21/11 8:45 AM, Fred Baker wrote: > > On Jan 21, 2011, at 3:02 AM, jouni korhonen wrote: > >> We have updated the I-D and tried to reflect the recent discussion >> in the V6OPS list as well we could for the time being. Thanks to >> everybody who provided constructive feedback. The attempt has been >> making the I-D just a description of the existing architecture. I >> hope we can move I-D forward rather soon as it has been around for >> quite some time already. Additional comments and feedback are of >> course solicited. > > > OK, different question for the group. At IETF-79, we asked (in the > survey) whether this should become a working group draft, and opinion > was supportive of the draft but divided on status. In my opinion, we > should adopt this as a working group draft at this time, run it > around the block at IETF-80, and then ship it to the IESG. > > Opinions? Shall we: - tell the chairs to send it to the IESG now as > an individual submission? - adopt it as a working group draft and > immediately WGLC it? given the recently updated status, I favor this... if wghlc produces new feeback then an ammended draft may be forwarded to the iesg. joel > - adopt it as a working group draft and continue > discussion? _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Fri Jan 21 21:56:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CD53A68BF for ; Fri, 21 Jan 2011 21:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 3-rqngIOd9fX for ; Fri, 21 Jan 2011 21:56:06 -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 397D73A68BD for ; Fri, 21 Jan 2011 21:56:06 -0800 (PST) Received: by qyk34 with SMTP id 34so1275528qyk.10 for ; Fri, 21 Jan 2011 21:58:53 -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=2jW6YzBdJjQnwNF3VnCQU0SyRDlfKPSpYc8v08fZOu4=; b=VPUsym32/e6znpuN1f/yPJ92y2QjZntPwNW/XVCy0FmRc+F71UvIVJpKTys2VKjaVZ +LCI8Tpk5tyK09WwCVb+HzNy1+NI2K5u7bDO4V/DDCZQelDWQm9pEBOfr4YN/wU9TAO2 TILhEsMI+9EKhGOjFGd7jW3OU2IvCNwmbc/5U= 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=fPJMKe6CqVommOM3ejTdrOsukjbvb7E7JgAGbMnzZ5/yuDoO8HmEFn/31utQ7yMKEN XteAdUeO+IBtHgPSPpLE8mag+fzg+TwiYq5XQyEZAjG58PosE3+TEnkKbo7qbZDxunFV k5znaTj8YDgMvy/KuUdDMYjcMybsK6hlkzKzY= MIME-Version: 1.0 Received: by 10.229.91.145 with SMTP id n17mr1272577qcm.258.1295675933758; Fri, 21 Jan 2011 21:58:53 -0800 (PST) Received: by 10.229.224.79 with HTTP; Fri, 21 Jan 2011 21:58:53 -0800 (PST) In-Reply-To: <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> Date: Fri, 21 Jan 2011 21:58:53 -0800 Message-ID: From: Cameron Byrne To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 05:56:07 -0000 " If the visited network to which outbound roamers attach to does not support PDP/PDN Type IPv6, then there needs to be a fallback option." This is also relevant to v4v6 since v4v6 is much newer and thus much less widely deployed than IPv6 PDP. Can you provide some more guidance about what the fall back mechanism may be? This is quite a hot topic. One of the things we have discussed deploying is having PCRF rules that reject PDP Type IPv6 from Gp (if MNC == my MNC ok, else reject) until roaming agreements are ratified and engineered for. Today, IPv6 roaming is revenue leakage in most case. To fix this, IPv6 roaming should be rejected until fixed and billed properly. Given that prcess will take a long time and IPv6 deployments are rolling out now in various 3G and 4G networks, what will be the fall back? Should the device have multiple APNs with priorities set (IPv6 = p1, ipv4 = p2)? What are the proper failure codes that the UE should expect to advance the through the priority list and retry the next APN. Thanks, Cameron From mohacsi@niif.hu Sat Jan 22 00:44:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DD43A6B34 for ; Sat, 22 Jan 2011 00:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] 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 tBiMnsrEGa58 for ; Sat, 22 Jan 2011 00:44:48 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id B498B3A68E6 for ; Sat, 22 Jan 2011 00:44:47 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id C6CFC8723D; Sat, 22 Jan 2011 09:47:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id FNReyAimUOvD; Sat, 22 Jan 2011 09:47:18 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 2E8F887219; Sat, 22 Jan 2011 09:47:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 2621186D75; Sat, 22 Jan 2011 09:47:18 +0100 (CET) Date: Sat, 22 Jan 2011 09:47:18 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Jack Bates In-Reply-To: <4D39A8B1.5080809@brightok.net> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <4D39A8B1.5080809@brightok.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 08:44:48 -0000 On Fri, 21 Jan 2011, Jack Bates wrote: > On 1/21/2011 9:14 AM, Mohacsi Janos wrote: >> 1. define list_of_sockaddr >> 2. do_parallel lookup for_each address_family with timeout < >> tolerable_for end_users/2 >> ---- if (found_result) list_of_sockaddr.append(lookup_result) >> 3. do_parallel connect() for_each list_of_sockaddr with timout < >> tolerable_for_end_users/2 >> ---- if (connected) terminate all other_connect_threads >> 4. communication as usual > > Actually, 2/3 should be combined. What should be parallel is the combined > lookup/connect. First protocol to make connect wins. You can't, since more than one IP address per address family possible. E.g if a particular name has 5 A record and 2 AAAA, then the point 3 should be done in 7 thread, while point 2 only in 2 threads. > >> Also causes problem of not possible to honor RFC 3484 policy tables.... > > While it will circumvent the v4/v6 policy, it should still follow the v6 > policy itself. Not sure if this can be done with the mechanism you're wanting > to do, but the v6 address selection should be utilized. RC 3484 is protocol independent. You can setup RFC 3484 policy table for prefer ipv4 for dual-stack servers .... Best Regards, Janos Mohacsi From jouni.nospam@gmail.com Sat Jan 22 02:19:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCFC93A68F5 for ; Sat, 22 Jan 2011 02:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO411QoUiifA for ; Sat, 22 Jan 2011 02:19:11 -0800 (PST) Received: from vs12.mail.saunalahti.fi (vs12.mail.saunalahti.fi [195.197.172.107]) by core3.amsl.com (Postfix) with ESMTP id 65EE23A68EA for ; Sat, 22 Jan 2011 02:19:11 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs12.mail.saunalahti.fi (Postfix) with SMTP id 4A7651A9058; Sat, 22 Jan 2011 12:21:58 +0200 (EET) Received: from vs12.mail.saunalahti.fi ([127.0.0.1]) by vs12.mail.saunalahti.fi ([195.197.172.107]) with SMTP (gateway) id A04272480C5; Sat, 22 Jan 2011 12:21:58 +0200 Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs12.mail.saunalahti.fi (Postfix) with ESMTP id 3C7D01A9058; Sat, 22 Jan 2011 12:21:58 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id D6C6015188D; Sat, 22 Jan 2011 12:21:55 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Sat, 22 Jan 2011 12:21:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 10:19:12 -0000 Hi, Thanks for the quick feedback. On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: > " If the > visited network to which outbound roamers attach to does not > support PDP/PDN Type IPv6, then there needs to be a fallback > option." >=20 > This is also relevant to v4v6 since v4v6 is much newer and thus much > less widely deployed than IPv6 PDP. Right. I definitely should add few words around that. >=20 > Can you provide some more guidance about what the fall back mechanism > may be? This is quite a hot topic. One of the things we have I am afraid there is no solution that would please all parties. And = given the wished stricter scope of the I-D, we don't really have 3GPP TS = level defined fallback mechanisms. Using S2c comes to my mind.. but.. > discussed deploying is having PCRF rules that reject PDP Type IPv6 > from Gp (if MNC =3D=3D my MNC ok, else reject) until roaming = agreements > are ratified and engineered for. Good point. I have been a bit hesitant to add anything PCC related so = far as PCC is an optional functionality. One could probably do that also = in a MME/SGSN level using the grey blob "roaming restrictions". However, = in that case the responsibility falls into the visited operator.. >=20 > Today, IPv6 roaming is revenue leakage in most case. To fix this, > IPv6 roaming should be rejected until fixed and billed properly. The formal practicalities are of course up to the operator community to = decide. > Given that prcess will take a long time and IPv6 deployments are > rolling out now in various 3G and 4G networks, what will be the fall > back? Should the device have multiple APNs with priorities set (IPv6 > =3D p1, ipv4 =3D p2)? What are the proper failure codes that the UE > should expect to advance the through the priority list and retry the > next APN. Above priority based mechanisms are being implemented (or partially = already implemented) to devices, at least to some of them. Some guidance = is already there in 23.401 that relate to return codes received from the = network and how the mobile device should act after based on those. The = operator can affect those by tuning the subscription profile/PDN-GW = configuration. Unfortunately, there is also a grey area that is mostly = left for mobile device implementers to come up with their innovative = ways to handle the situation. Would it make sense to list some of the possible ways that are possible = strictly following the 23.401 "toolbox"? That would probably be a new = section 8.x. - Jouni >=20 > Thanks, > Cameron From jbates@brightok.net Sat Jan 22 10:02:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A383A699F for ; Sat, 22 Jan 2011 10:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 KBYdJE-iibDp for ; Sat, 22 Jan 2011 10:02:46 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 5B6D53A6996 for ; Sat, 22 Jan 2011 10:02:46 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0MI5XVA011589; Sat, 22 Jan 2011 12:05:34 -0600 (CST) Message-ID: <4D3B1C64.3040909@brightok.net> Date: Sat, 22 Jan 2011 12:05:24 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mohacsi Janos References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <4D39A8B1.5080809@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 18:02:47 -0000 On 1/22/2011 2:47 AM, Mohacsi Janos wrote: > RC 3484 is protocol independent. You can setup RFC 3484 policy table > for prefer ipv4 for dual-stack servers .... > It can, but it should still be taken into account. Address selection is critical in IPv6 within the protocol itself, not counting address selection cross protocol. Ignoring it completely will break some IPv6 connections that otherwise might have succeeded faster than IPv4. Jack From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jan 22 13:50:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CDD3A6A86 for ; Sat, 22 Jan 2011 13:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 ZoYpSil7ZrPm for ; Sat, 22 Jan 2011 13:50:47 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 435943A682D for ; Sat, 22 Jan 2011 13:50:47 -0800 (PST) Received: from 219-90-172-134.ip.adam.com.au ([219.90.172.134] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PglOj-0000Pg-Kc; Sun, 23 Jan 2011 08:23:29 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id AF7D13B31E; Sun, 23 Jan 2011 08:23:28 +1030 (CST) Date: Sun, 23 Jan 2011 08:23:28 +1030 From: Mark Smith To: Ted Lemon Message-ID: <20110123082328.307f77bc@opy.nosense.org> In-Reply-To: <3945AC5B-807C-43FE-8A3E-F180206D2EF6@nominum.com> References: <4D376481.3010406@kth.se> <3945AC5B-807C-43FE-8A3E-F180206D2EF6@nominum.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Rashmi Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 21:50:48 -0000 On Wed, 19 Jan 2011 21:35:13 -0500 Ted Lemon wrote: > On Jan 19, 2011, at 9:18 PM, Fred Baker wrote: > > Because if we fix the application, we have to fix every application individually. If we can get it into the OS or into a library that looks like the OS, we still have to convince existing applications to to use it, but we can debug it once and future applications don't need to ask the question. > > I think you and I are talking about different things. I think you are talking here about your connect_by_name() api, right? I don't entirely agree that that's the right API, but I agree in principle that an API is a good idea, for just the reason you've stated. > > What I'm arguing probably isn't going to work is a shim that works with an application that calls gethostbyname() and then connect(). I can imagine it working in some cases, but it would almost certainly also cause instability. > It may not be ideal, however if hiding it behind getaddrinfo() et al. and connect() provides a better experience than the vanilla versions would today, then it is worth while I think. Regards, Mark. From bzeeb-lists@lists.zabbadoz.net Sat Jan 22 14:07:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE773A6B47 for ; Sat, 22 Jan 2011 14:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 vImkWVn-U85u for ; Sat, 22 Jan 2011 14:07:18 -0800 (PST) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by core3.amsl.com (Postfix) with ESMTP id B2BAA3A6B46 for ; Sat, 22 Jan 2011 14:07:17 -0800 (PST) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 51F9741C6FC; Sat, 22 Jan 2011 23:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id DKtTmJoLTvbh; Sat, 22 Jan 2011 23:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id BA03F41C6F2; Sat, 22 Jan 2011 23:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7DA814448F3; Sat, 22 Jan 2011 22:09:18 +0000 (UTC) Date: Sat, 22 Jan 2011 22:09:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Ted Lemon In-Reply-To: <3945AC5B-807C-43FE-8A3E-F180206D2EF6@nominum.com> Message-ID: <20110122215754.G3489@maildrop.int.zabbadoz.net> References: <4D376481.3010406@kth.se> <3945AC5B-807C-43FE-8A3E-F180206D2EF6@nominum.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 22:07:19 -0000 On Wed, 19 Jan 2011, Ted Lemon wrote: > I think you and I are talking about different things. I think you are talking here about your connect_by_name() api, right? I don't entirely agree that that's the right API, but I agree in principle that an API is a good idea, for just the reason you've stated. > > What I'm arguing probably isn't going to work is a shim that works with an application that calls gethostbyname() and then connect(). I can imagine it working in some cases, but it would almost certainly also cause instability. Yes, that certainly will not work as gethostbyname() [usually] is IPv4 only and should probably not be used in any new code. Thanks. [1] /bz References: [1] http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap03.html#tag_22_03_01_08 -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From cb.list6@gmail.com Sat Jan 22 20:26:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CF63A6BE9 for ; Sat, 22 Jan 2011 20:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 1JK7ylC9C5L7 for ; Sat, 22 Jan 2011 20:26:37 -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 755623A6BE8 for ; Sat, 22 Jan 2011 20:26:37 -0800 (PST) Received: by qyk34 with SMTP id 34so1811578qyk.10 for ; Sat, 22 Jan 2011 20:29:28 -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 :content-transfer-encoding; bh=r9zlYAuvOuMwJjItofY3ZTESPXPj6gKbps6RHV5gmVQ=; b=Wym47S1vZyuaINi+ebjEyV4tApfdUJ0U1yuNQMhakLGzHUkbS1zRxa1rbl9mKR+Biz lG9cYgBkTcawM7OlK9DuRWwY0zE1B0c7KrxeW1Lhl/eJi7MN/wM8t5BM7mU8RFzrcJVP W6phRAJH6HYMO3pILOWY1EtWkkMrIypLpvJvU= 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=I/1OsHz/XoOnB3izn/IXP2JP5SVApihydJpKkZ8vjGrl1L5CC5QgSEE9e/QkTH4jP5 C3ZBEGmWMbDllruohEtZQc6iaGkcypxRI5zsHdpMU5Nq5j8AxzRyaGdNq6nrdNvxOwNm 7EvqSWu9BsTvffydyFWAPHDopn/33zjwTyJfg= MIME-Version: 1.0 Received: by 10.229.90.196 with SMTP id j4mr2282911qcm.144.1295756967925; Sat, 22 Jan 2011 20:29:27 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sat, 22 Jan 2011 20:29:27 -0800 (PST) In-Reply-To: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> Date: Sat, 22 Jan 2011 20:29:27 -0800 Message-ID: From: Cameron Byrne To: Jouni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 04:26:38 -0000 On Sat, Jan 22, 2011 at 2:21 AM, Jouni wrote: > > Hi, > > Thanks for the quick feedback. > > On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: > >> " If the >> =A0 =A0 =A0visited network to which outbound roamers attach to does not >> =A0 =A0 =A0support PDP/PDN Type IPv6, then there needs to be a fallback >> =A0 =A0 =A0option." >> >> This is =A0also relevant to v4v6 since v4v6 is much newer and thus much >> less widely deployed than IPv6 PDP. > > Right. I definitely should add few words around that. > >> >> Can you provide some more guidance about what the fall back mechanism >> may be? =A0This is quite a hot topic. =A0 One of the things we have > > I am afraid there is no solution that would please all parties. And given= the wished stricter scope of the I-D, we don't really have 3GPP TS level d= efined fallback mechanisms. Using S2c comes to my mind.. but.. > Right, agreed regarding stricter scope and 3GPP failing to provide real world guidance to operators in this situation ... as well as GSMA ... >> discussed deploying is having PCRF rules that reject PDP Type IPv6 >> from Gp (if MNC =3D=3D my MNC ok, else reject) until roaming agreements >> are ratified and engineered for. > > Good point. I have been a bit hesitant to add anything PCC related so far= as PCC is an optional functionality. One could probably do that also in a = MME/SGSN level using the grey blob "roaming restrictions". However, in that= case the responsibility falls into the visited operator.. > I cannot assume the visited network even knows what an IPv6 PDP is, right? And, if the visited network does allow the IPv6 PDP, they will want to charge for it. They will want to charge the home network for it. So, if i host an IPv6 capable APN across GRX/IPX, i am liable for the billing of it ... yet ZERO billing arrangements account for IPv6 today. So, the home network MUST block the IPv6 PDP across the roaming until it is possible to bill for it, which involves complexities that nobody believes will be solved before IPv6 is rolled out to users. So, if the home network must block the IPv6 PDP, it must be done on the GGSN/P-GW via GGSN/P-GW features or PCRF rules. >> >> Today, IPv6 roaming is revenue leakage in most case. =A0To fix this, >> IPv6 roaming should be rejected until fixed and billed properly. > > The formal practicalities are of course up to the operator community to d= ecide. > Right now, operators are looking to cover revenue leakage that is happening via IPv6. They are not looking to enable it across roaming. >> Given that prcess will take a long time and IPv6 deployments are >> rolling out now in various 3G and 4G networks, what will be the fall >> back? =A0Should the device have multiple APNs with priorities set (IPv6 >> =3D p1, ipv4 =3D p2)? =A0What are the proper failure codes that the UE >> should expect to advance the through the priority list and retry the >> next APN. > > Above priority based mechanisms are being implemented (or partially alrea= dy implemented) to devices, at least to some of them. Some guidance is alre= ady there in 23.401 that relate to return codes received from the network a= nd how the mobile device should act after based on those. The operator can = affect those by tuning the subscription profile/PDN-GW configuration. Unfor= tunately, there is also a grey area that is mostly left for mobile device i= mplementers to come up with their innovative ways to handle the situation. > Can you provide a pointer in 23.401? I could not find this text. > Would it make sense to list some of the possible ways that are possible s= trictly following the 23.401 "toolbox"? That would probably be a new sectio= n 8.x. > I believe that would be a great addition to the draft as this is a real problem and the community should have a good discussion on it across the various stakeholders. As i mentioned, my operating assumption is that the home network must reject IPv6 PDP from Gp as long as there is not a roaming agreement and billing infrastructure to support it. Today, there is nothing for roaming with IPv6, so it should not be supported anywhere via roaming. That said, the home network must reject the PDP, and the UE must react by retrying with IPv4. Cameron > - Jouni > > >> >> Thanks, >> Cameron > > From ayourtch@cisco.com Sun Jan 23 01:54:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182B33A6839 for ; Sun, 23 Jan 2011 01:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] 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 QASkGt-oQEFG for ; Sun, 23 Jan 2011 01:54:42 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0913F3A6835 for ; Sun, 23 Jan 2011 01:54:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0N9vWnS009134; Sun, 23 Jan 2011 10:57:32 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0N9vVg0006918; Sun, 23 Jan 2011 10:57:31 +0100 (CET) Date: Sun, 23 Jan 2011 10:57:31 +0100 (CET) From: Andrew Yourtchenko To: "Bjoern A. Zeeb" In-Reply-To: <20110121113401.K3489@maildrop.int.zabbadoz.net> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 09:54:43 -0000 Dear Bjoern, On Fri, 21 Jan 2011, Bjoern A. Zeeb wrote: > On Fri, 21 Jan 2011, Andrew Yourtchenko wrote: > > Dear Andrew, > >> On Fri, 21 Jan 2011, Mohacsi Janos wrote: >>> >>> I don't see the point in your implementation. The speed of the DNS lookup >>> for specific records does not have any relation to speed of connectivity >>> or responsiveness for any specific protocol. I think what can help: >> >> Take a look at >> >> https://bugzilla.redhat.com/show_bug.cgi?id=505105 >> >> for an example why. > > That is a rather bad example to show people for your case. Do you > really want to > > 1) have people having a good experience, > 2) work around obvious brokeness in device for standards compliant > queries, > 3) show that despite how much people (grudgingly) try to work around > brokeness, brokeness will stay, and > 4) at the same time add more complexity to the procotol/standards > just asking for more problems? > > The result of that will be obvious. This case only shows that by doing the parallel threads of DNS+connect within the address family we avoid that sort of nastiness for free. The reason it came to my mind because I was helping to fix the box in the middle that was dropping the AAAAs. Re. the complexity and brokenness - I think Ted summed it up great in his other mail. > > > Ignoring the above sample, I see the point that people think that the > sum of DNS lookup time + connect time is a good metric for better user > experience. I am not saying I confirm that. What metric would you have in mind ? cheers, andrew From ayourtch@cisco.com Sun Jan 23 02:31:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8FF3A683F for ; Sun, 23 Jan 2011 02:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 fIqAzD4uOeKC for ; Sun, 23 Jan 2011 02:31:56 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id AED953A67FD for ; Sun, 23 Jan 2011 02:31:55 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0NAYjw6011783; Sun, 23 Jan 2011 11:34:46 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0NAYjER028189; Sun, 23 Jan 2011 11:34:45 +0100 (CET) Date: Sun, 23 Jan 2011 11:34:45 +0100 (CET) From: Andrew Yourtchenko To: Mohacsi Janos In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <4D39A8B1.5080809@brightok.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 10:31:57 -0000 On Sat, 22 Jan 2011, Mohacsi Janos wrote: > > On Fri, 21 Jan 2011, Jack Bates wrote: > >> On 1/21/2011 9:14 AM, Mohacsi Janos wrote: >>> 1. define list_of_sockaddr >>> 2. do_parallel lookup for_each address_family with timeout < >>> tolerable_for end_users/2 >>> ---- if (found_result) list_of_sockaddr.append(lookup_result) >>> 3. do_parallel connect() for_each list_of_sockaddr with timout < >>> tolerable_for_end_users/2 >>> ---- if (connected) terminate all other_connect_threads >>> 4. communication as usual >> >> Actually, 2/3 should be combined. What should be parallel is the combined >> lookup/connect. First protocol to make connect wins. > > You can't, since more than one IP address per address family possible. E.g if > a particular name has 5 A record and 2 AAAA, then the point 3 should be done > in 7 thread, while point 2 only in 2 threads. We are not making ourself the point to connect with *the* specific address family. We are making the point to have a working TCP connection, be it IPv4 or IPv6. But above is an interesting idea - I am though curious how, if 16 addresses are returned, you avoid opening 16 connections. A suggestion. Since this thread started with a question about running code, yesterday I had a little fun and made eyewear for happy eyeballs: https://github.com/ayourtch/gncci : "general network connections contortion interface". It gives the ability to do anything in the middle between the application and the Linux socket layer. In a high-level language that Lua is. So prototyping something Happy Eyeballs-like in this middle layer is not too difficult. The other reasons that I made it this way one can induce the "intentional breakage" via this middle layer and see how the application behaves, or do parental control proxy, or whatever else shiny. It's just an eyewear. Feel free to play with it and send me the pointer to the code you come up with. There may still be bugs of course since I've done the entire thing in a single sitting - the fixes are appreciated. > >> >>> Also causes problem of not possible to honor RFC 3484 policy tables.... >> >> While it will circumvent the v4/v6 policy, it should still follow the v6 >> policy itself. Not sure if this can be done with the mechanism you're >> wanting to do, but the v6 address selection should be utilized. > > RC 3484 is protocol independent. You can setup RFC 3484 policy table for > prefer ipv4 for dual-stack servers .... I tried to do it on my linux box, but failed... Do you have any advise ? (short of disabling the IPv6 of course:) cheers, andrew From mohacsi@niif.hu Sun Jan 23 05:31:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0023A68D8 for ; Sun, 23 Jan 2011 05:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.221 X-Spam-Level: X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] 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 Mw6aB81uZh7B for ; Sun, 23 Jan 2011 05:31:06 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 718343A68D6 for ; Sun, 23 Jan 2011 05:31:05 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 0170C871F9; Sun, 23 Jan 2011 14:33:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id YWjm2r7f7mfh; Sun, 23 Jan 2011 14:33:39 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 98BFB8721B; Sun, 23 Jan 2011 14:33:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 9098187218; Sun, 23 Jan 2011 14:33:39 +0100 (CET) Date: Sun, 23 Jan 2011 14:33:39 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Andrew Yourtchenko In-Reply-To: Message-ID: References: <4D376481.3010406@kth.se> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <4D39A8B1.5080809@brightok.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 13:31:06 -0000 >>> >>>> Also causes problem of not possible to honor RFC 3484 policy tables.... >>> >>> While it will circumvent the v4/v6 policy, it should still follow the v6 >>> policy itself. Not sure if this can be done with the mechanism you're >>> wanting to do, but the v6 address selection should be utilized. >> >> RC 3484 is protocol independent. You can setup RFC 3484 policy table for >> prefer ipv4 for dual-stack servers .... > > I tried to do it on my linux box, but failed... Do you have any advise ? Try to setup ::ffff:0:0/96 with higher precedence than any ipv6 precedence. Typically 50 is the largest precedence if they use the default RFC 3484 policy table, therefore 60 or 100 will suffice. Best Regards, Janos Mohacsi From Roman.Arcea@orange.md Sun Jan 23 10:19:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD403A6930 for ; Sun, 23 Jan 2011 10:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_13=0.6, MIME_HTML_ONLY=1.457] 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 jjcL5h2d10Fz for ; Sun, 23 Jan 2011 10:19:58 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id E13143A6935 for ; Sun, 23 Jan 2011 10:19:57 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id C1624C09D7E; Sun, 23 Jan 2011 20:22:41 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id AAD45C09D3D; Sun, 23 Jan 2011 20:22:41 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: cb.list6@gmail.com Message-ID: Date: Sun, 23 Jan 2011 20:22:42 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 20:22:42, Serialize complete at 01/23/2011 20:22:42, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 20:22:42, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 20:22:42 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 18:19:59 -0000 Hi Cameron,

I am not sure that "So, the home network MUST blo= ck the IPv6 PDP across the roaming until it is possible to bill for it<= /tt>"  is a proper statement for an IPv6 PDP. I have tried IPv6 = PDP in roaming in 3 different countries without any prior testing arrangeme= nts and have been billed correctly in every case. Obviously I can not assum= e it will be perfect for any country I visit and we need a mechanism indeed= to define it on a formal level.

"which involves complexities that nobody bel= ieves will be solved before IPv6 is rolled out to users." - = so, you believe it will be easier and faster to create fallback mechanism t= hat will most likely come as a part of a major release years from now, rath= er then correct the billing, which in most cases may disconsider the IP add= ress anyway and does not care about IP version?

At this point I am s= omehow seeing the light at the end of the tunnel with the IPv6 only PDP and= believe that the roaming partners should simply check their capabilities i= n this regards.
Regarding the v4v6 PDP the issue is more complex indeed = as it will take years for operators to upgrade to supporting releases. In t= hat specific case the fallback mechanisms should be in place and they might= arrive just in time before the issues are widespread.

Best,
Roma= n




-----v6ops-bounces@ietf= .org wrote: -----
To: Jouni <jouni.nospam@gmail.com>
From: Cameron Byrne <= cb.list6@gmail.com>
Sent by: v6ops-bounces@ietf.org
Date: 01/2= 3/2011 06:29AM
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6op= s] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05
On Sat, Jan 2= 2, 2011 at 2:21 AM, Jouni <jouni.nospam@gmail.com> wrote:
>
= >= ; Hi,
>
> Thanks for the quick feedback.
>
> On = Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote:
>
>> " If the<= br>= >>      visited network to which outbound roamers= attach to does not
>>      support PDP/PDN Type = IPv6, then there needs to be a fallback
>>      o= ption."
>>
>> This is  also relevant to v4v6 since v4= v6 is much newer and thus much
>> less widely deployed than IPv6= PDP.
>
> Right. I definitely should add few words around that.=
>
>>
>> Can you provide some more guidance about what= the fall back mechanism
>> may be?  This is quite a hot to= pic.   One of the things we have
>
> I am afraid there is n= o solution that would please all parties. And given the wished stricter sco= pe of the I-D, we don't really have 3GPP TS level defined fallback mechanis= ms. Using S2c comes to my mind.. but..
>

Right, agreed regarding str= icter scope and 3GPP failing to provide
real world guidance to operators in= this situation ... as well as GSMA
...

>> discussed deplo= ying is having PCRF rules that reject PDP Type IPv6
>> from Gp (= if MNC =3D=3D my MNC ok, else reject) until roaming agreements
>>&nbs= p;are ratified and engineered for.
>
> Good point. I have been a= bit hesitant to add anything PCC related so far as PCC is an optional func= tionality. One could probably do that also in a MME/SGSN level using the gr= ey blob "roaming restrictions". However, in that case the responsibility fa= lls into the visited operator..
>

I cannot assume the visited networ= k even knows what an IPv6 PDP is,
right?  And, if the visited network = does allow the IPv6 PDP, they will
want to charge for it.  They will w= ant to charge the home network for
it.  So, if i host an IPv6 capable = APN across GRX/IPX, i am liable for
the billing of it ... yet ZERO billing = arrangements account for IPv6
today.  So, the home network MUST block = the IPv6 PDP across the
roaming until it is possible to bill for it, which = involves
complexities that nobody believes will be solved before IPv6 is ro= lled
out to users.

So, if the home network must block the IPv6 PDP, i= t must be done on
the GGSN/P-GW via GGSN/P-GW features or PCRF rules.

&= gt;>
>> Today, IPv6 roaming is revenue leakage in most case. =  To fix this,
>> IPv6 roaming should be rejected until fixe= d and billed properly.
>
> The formal practicalities are of cour= se up to the operator community to decide.
>

Right now, operators ar= e looking to cover revenue leakage that is
happening via IPv6.  They a= re not looking to enable it across roaming.

>> Given that pr= cess will take a long time and IPv6 deployments are
>> rolling o= ut now in various 3G and 4G networks, what will be the fall
= >> b= ack?  Should the device have multiple APNs with priorities set (IPv6&= gt;> =3D p1, ipv4 =3D p2)?  What are the proper failure codes = that the UE
>> should expect to advance the through the priority= list and retry the
>> next APN.
>
> Above priority= based mechanisms are being implemented (or partially already implemented) = to devices, at least to some of them. Some guidance is already there in 23.= 401 that relate to return codes received from the network and how the mobil= e device should act after based on those. The operator can affect those by = tuning the subscription profile/PDN-GW configuration. Unfortunately, there = is also a grey area that is mostly left for mobile device implementers to c= ome up with their innovative ways to handle the situation.
>

Can y= ou provide a pointer in 23.401? I could not find this text.
=
> W= ould it make sense to list some of the possible ways that are possible stri= ctly following the 23.401 "toolbox"? That would probably be a new section 8= .x.
>

I believe that would be a great addition to the draft as this = is a
real problem and the community should have a good discussion on ita= cross the various stakeholders.

As i mentioned, my operating assumption= is that the home network must
reject IPv6 PDP from Gp as long as there is = not a roaming agreement
and billing infrastructure to support it.   To= day, there is nothing
for roaming with IPv6, so it should not be supported = anywhere via
roaming.  That said, the home network must reject the PDP= , and the UE
must react by retrying with IPv4.

Cameron
<= br>> - = Jouni
>
>
>>
>> Thanks,
>> Cameron
><= br>= >
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
= From cb.list6@gmail.com Sun Jan 23 10:30:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9AD3A6935 for ; Sun, 23 Jan 2011 10:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, J_CHICKENPOX_13=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 e03lU4uW9vz5 for ; Sun, 23 Jan 2011 10:30:57 -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 31F0D3A6932 for ; Sun, 23 Jan 2011 10:30:57 -0800 (PST) Received: by qyk34 with SMTP id 34so2132775qyk.10 for ; Sun, 23 Jan 2011 10:33:46 -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 :content-transfer-encoding; bh=2rHc9uJJD7/RGTqOdCxL7mnpymWxfMPIt6Ac4xY8Fwk=; b=Nt89PfIHPjW99rX7pm99bScYCPJ23hkK++KaAVcjv2HeY5kpEAQvtKpPHgf1kcgGO0 pZxUtt7heZkBpunR1QocAhyI86FbTqTKbHTzb2OLeMAkX2G2lylzPkr4WO/pVfuRdpy4 aVgDPlru8/Uz1Q9rC1BVu0tL3q/j+nizw99CM= 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=V17qZuyc/dRncdEmjCgPfSadht6hPx2ForTKOZiUsPgmb0+lT0tL7/yr+KaODvM3uF 2W3WBfi3ep0K3lA/OXVht/vU6VXF5oP5aY4ZEFI2Uk+BTlSd/AlEOyDU0TPWKvT9OcC4 4a9I/ovIv8fUGAuMXnIY11StXP48LllaUonGo= MIME-Version: 1.0 Received: by 10.229.227.8 with SMTP id iy8mr2963235qcb.182.1295807625132; Sun, 23 Jan 2011 10:33:45 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sun, 23 Jan 2011 10:33:45 -0800 (PST) In-Reply-To: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> Date: Sun, 23 Jan 2011 10:33:45 -0800 Message-ID: From: Cameron Byrne To: Roman.Arcea@orange.md Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 18:30:59 -0000 On Sun, Jan 23, 2011 at 10:22 AM, wrote: > Hi Cameron, > > I am not sure that "So, the home network MUST block the IPv6 PDP across t= he > roaming until it is possible to bill for it"=A0 is a proper statement for= an > IPv6 PDP. I have tried IPv6 PDP in roaming in 3 different countries witho= ut > any prior testing arrangements and have been billed correctly in every ca= se. > Obviously I can not assume it will be perfect for any country I visit and= we > need a mechanism indeed to define it on a formal level. > This is surprising. You were billed for the proper international roaming usage? We have reached out to many roaming partners and they have explicitly said they do not have plans to support this. So, is your information based on what you have tried or what various operators have contractually agreed to? I agree there is a difference between the 2, but both must be clearly supported before we can allow customers to do it. Furthermore, Ericsson has relayed a situation where they did ipv6 pdp in Japan recently and it crashed the Japanese billing system since there was unexpected data in the CDRs.... 128 bit Severed PDP field instead of 32 crashed the CDR batch processing. > "which involves complexities that nobody believes will be solved before I= Pv6 > is rolled out to users." - so, you believe it will be easier and faster t= o > create fallback mechanism that will most likely come as a part of a major > release years from now, rather then correct the billing, which in most ca= ses > may disconsider the IP address anyway and does not care about IP version? > Yes. I believe fall back is required since the official word from our roaming partners is that they do not support it. Without official support, we cannot take it to production. And, with so many roaming partners running different software for billing and different hardware in their networks, it is a very complicated environment to drive change. > At this point I am somehow seeing the light at the end of the tunnel with > the IPv6 only PDP and believe that the roaming partners should simply che= ck > their capabilities in this regards. I am sorry to be pessimistic just as you are becoming optimistic ! I too believe IPv6-only is good, but the roaming part .... it is a challenge to make "officially" work while i am aware that in some places it does unofficially work. I can tell you today that Ericsson has done IPv6 roaming on the T-Mobile USA back to Telia as the home network. It was not billed from T-Mobile to Telia ... the IPv6 CDRs are discarded as part of CDR data validation. So it technically works for the user, but it will not be billed... which is bad for the operator. > Regarding the v4v6 PDP the issue is more complex indeed as it will take > years for operators to upgrade to supporting releases. In that specific c= ase > the fallback mechanisms should be in place and they might arrive just in > time before the issues are widespread. > > Best, > Roman > > > > > -----v6ops-bounces@ietf.org wrote: ----- > > To: Jouni > From: Cameron Byrne > Sent by: v6ops-bounces@ietf.org > Date: 01/23/2011 06:29AM > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Fwd: New Version Notification for > draft-korhonen-v6ops-3gpp-eps-05 > > On Sat, Jan 22, 2011 at 2:21 AM, Jouni wrote: >> >>=A0Hi, >> >>=A0Thanks for the quick feedback. >> >>=A0On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: >> >>>=A0" If the >>>=A0=A0 =A0 =A0visited network to which outbound roamers attach to does n= ot >>>=A0=A0 =A0 =A0support PDP/PDN Type IPv6, then there needs to be a fallba= ck >>>=A0=A0 =A0 =A0option." >>> >>>=A0This is =A0also relevant to v4v6 since v4v6 is much newer and thus mu= ch >>>=A0less widely deployed than IPv6 PDP. >> >>=A0Right. I definitely should add few words around that. >> >>> >>>=A0Can you provide some more guidance about what the fall back mechanism >>>=A0may be? =A0This is quite a hot topic. =A0 One of the things we have >> >>=A0I am afraid there is no solution that would please all parties. And gi= ven >> the wished stricter scope of the I-D, we don't really have 3GPP TS level >> defined fallback mechanisms. Using S2c comes to my mind.. but.. >> > > Right, agreed regarding stricter scope and 3GPP failing to provide > real world guidance to operators in this situation ... as well as GSMA > ... > >>>=A0discussed deploying is having PCRF rules that reject PDP Type IPv6 >>>=A0from Gp (if MNC =3D=3D my MNC ok, else reject) until roaming agreemen= ts >>>=A0are ratified and engineered for. >> >>=A0Good point. I have been a bit hesitant to add anything PCC related so = far >> as PCC is an optional functionality. One could probably do that also in = a >> MME/SGSN level using the grey blob "roaming restrictions". However, in t= hat >> case the responsibility falls into the visited operator.. >> > > I cannot assume the visited network even knows what an IPv6 PDP is, > right? =A0And, if the visited network does allow the IPv6 PDP, they will > want to charge for it. =A0They will want to charge the home network for > it. =A0So, if i host an IPv6 capable APN across GRX/IPX, i am liable for > the billing of it ... yet ZERO billing arrangements account for IPv6 > today. =A0So, the home network MUST block the IPv6 PDP across the > roaming until it is possible to bill for it, which involves > complexities that nobody believes will be solved before IPv6 is rolled > out to users. > > So, if the home network must block the IPv6 PDP, it must be done on > the GGSN/P-GW via GGSN/P-GW features or PCRF rules. > >>> >>>=A0Today, IPv6 roaming is revenue leakage in most case. =A0To fix this, >>>=A0IPv6 roaming should be rejected until fixed and billed properly. >> >>=A0The formal practicalities are of course up to the operator community t= o >> decide. >> > > Right now, operators are looking to cover revenue leakage that is > happening via IPv6. =A0They are not looking to enable it across roaming. > >>>=A0Given that prcess will take a long time and IPv6 deployments are >>>=A0rolling out now in various 3G and 4G networks, what will be the fall >>>=A0back? =A0Should the device have multiple APNs with priorities set (IP= v6 >>>=A0=3D p1, ipv4 =3D p2)? =A0What are the proper failure codes that the U= E >>>=A0should expect to advance the through the priority list and retry the >>>=A0next APN. >> >>=A0Above priority based mechanisms are being implemented (or partially >> already implemented) to devices, at least to some of them. Some guidance= is >> already there in 23.401 that relate to return codes received from the >> network and how the mobile device should act after based on those. The >> operator can affect those by tuning the subscription profile/PDN-GW >> configuration. Unfortunately, there is also a grey area that is mostly l= eft >> for mobile device implementers to come up with their innovative ways to >> handle=A0the situation. >> > > Can you provide a pointer in 23.401? I could not find this text. > >>=A0Would it make sense to list some of the possible ways that are possibl= e >> strictly following the 23.401 "toolbox"? That would probably be a new >> section 8.x. >> > > I believe that would be a great addition to the draft as this is a > real problem and the community should have a good discussion on it > across the various stakeholders. > > As i mentioned, my operating assumption is that the home network must > reject IPv6 PDP from Gp as long as there is not a roaming agreement > and billing infrastructure to support it. =A0 Today, there is nothing > for roaming with IPv6, so it should not be supported anywhere via > roaming. =A0That said, the home network must reject the PDP, and the UE > must react by retrying with IPv4. > > Cameron > >>=A0- Jouni >> >> >>> >>>=A0Thanks, >>>=A0Cameron >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Roman.Arcea@orange.md Sun Jan 23 10:48:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA713A6938 for ; Sun, 23 Jan 2011 10:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_13=0.6, MIME_HTML_ONLY=1.457] 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 zaXwWOnmQZER for ; Sun, 23 Jan 2011 10:48:07 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 0DC353A6930 for ; Sun, 23 Jan 2011 10:48:06 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id ED1E7C09E7C; Sun, 23 Jan 2011 20:50:57 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id C314EC09D45; Sun, 23 Jan 2011 20:50:57 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: cb.list6@gmail.com Message-ID: Date: Sun, 23 Jan 2011 20:50:58 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 20:50:58, Serialize complete at 01/23/2011 20:50:58, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 20:50:58, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 20:50:58 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 18:48:08 -0000 Yes,

Properly billed for international usage in 3 Europ= ean countries. Have checked with billing on that.
The information is bas= ed on what I have tried. No prior official arrangements have been made.
=
The case with E/// is interesting and it might have been the case. Inde= ed, the prior change of the IP field to 128 bits should be made. We had a s= imilar issue, however it has been solved in less then 2 weeks.

Now I= am not saying that a fallback mechanism is something we do not need. All I= am suggesting is as long as timing is involved, we are unlikely to see it = in 3-5 years from now in all the networks we have roaming arrangements with= . While, IPv6 PDP is there starting from R99, so it might be easier to ask = the partners to have a look in their billing now then try and explain our c= ustomers for the next 5 years that we are still waiting for a fallback mech= anism, this is why they should manually select another APN to use when they= are going abroad. The question is either in 5 years from now we might have= customers with IPv6/v4v6 only APNs?

So, the problem is really compl= ex here. I would rather start working on what we have now and still hope fo= r the fallback, rather then sabotage the proper IPv6 deployment for years i= n hope that country X will have their network elements upgraded.

Rom= an


-----Cameron Byrne <cb.list6@gma= il.com> wrote: -----
To: Roman.Arcea@orange.md
From: Cameron Byrne <cb.li= st6@gmail.com>
Date: 01/23/2011 08:33PM
Cc: jouni.nospam@gma= il.com, v6ops@ietf.org
Subject: Re: [v6ops] Fwd: New Version Notificat= ion for draft-korhonen-v6ops-3gpp-eps-05

On Sun, Jan 23, 2011 at 10:22 AM,  <= Roman.Arcea@orange.md> wrote:
> Hi Cameron,
<= tt>>
<= /tt>> I= am not sure that "So, the home network MUST block the IPv6 PDP across the<= br>= > roaming until it is possible to bill for it"  is a proper st= atement for an
> IPv6 PDP. I have tried IPv6 PDP in roaming in 3 di= fferent countries without
> any prior testing arrangements and have= been billed correctly in every case.
> Obviously I can not assume = it will be perfect for any country I visit and we
> need a mechanis= m indeed to define it on a formal level.
>

This is surprising.  = ;You were billed for the proper international
roaming usage?  We have = reached out to many roaming partners and they
have explicitly said they do = not have plans to support this.

So, is your information based on what y= ou have tried or what various
operators have contractually agreed to?  = ;I agree there is a difference
between the 2, but both must be clearly supp= orted before we can allow
customers to do it.

Furthermore, Ericsson has= relayed a situation where they did ipv6 pdp
in Japan recently and it cras= hed the Japanese billing system since
there was unexpected data in the CDRs= .... 128 bit Severed PDP field
instead of 32 crashed the CDR batch processi= ng.

> "which involves complexities that nobody believes will be= solved before IPv6
> is rolled out to users." - so, you believe it= will be easier and faster to
> create fallback mechanism that will= most likely come as a part of a major
> release years from now, ra= ther then correct the billing, which in most cases
> may disconside= r the IP address anyway and does not care about IP version?
= >
=
Yes. &= nbsp;I believe fall back is required since the official word from our
roami= ng partners is that they do not support it.  Without official
support,= we cannot take it to production.  And, with so many roaming
partners = running different software for billing and different hardware
in their netw= orks, it is a very complicated environment to drive
change.
=
> A= t this point I am somehow seeing the light at the end of the tunnel with&g= t; the IPv6 only PDP and believe that the roaming partners should simp= ly check
> their capabilities in this regards.

<= tt>I am sorry to be= pessimistic just as you are becoming optimistic !  I
<= tt>too believe IPv6= -only is good, but the roaming part .... it is a
challenge to make "officia= lly" work while i am aware that in some
places it does unofficially work. &= nbsp;I can tell you today that Ericsson
has done IPv6 roaming on the T-Mobi= le USA back to Telia as the home
network.  It was not billed from T-Mo= bile to Telia ... the IPv6 CDRs
are discarded as part of CDR data validatio= n.  So it technically works
for the user, but it will not be billed...= which is bad for the
operator.

> Regarding the v4v6 PDP the is= sue is more complex indeed as it will take
> years for operators to= upgrade to supporting releases. In that specific case
<= font face=3D"Courier New,Courier,monospace" size=3D"2">> the fallba= ck mechanisms should be in place and they might arrive just in
> ti= me before the issues are widespread.
>
> Best,
> Roman&= gt;
>
>
>
> -----v6ops-bounces@ietf.org wrote: -----
><= br>= > To: Jouni <jouni.nospam@gmail.com>
> From: Camer= on Byrne
> Sent by: v6ops-bounces@ietf.org
> Date: 01= /23/2011 06:29AM
> Cc: IPv6 Ops WG <v6ops@ietf.org>
> Subj= ect: Re: [v6ops] Fwd: New Version Notification for
> draft-korhonen= -v6ops-3gpp-eps-05
>
> On Sat, Jan 22, 2011 at 2:21 AM, Jouni <= ;jouni.nospam@gmail.com> wrote:
>>
>> Hi,
>><= br>= >> Thanks for the quick feedback.
>>
<= font face=3D"Courier New,Courier,monospace" size=3D"2">>> On Jan= 22, 2011, at 7:58 AM, Cameron Byrne wrote:
>>
<= font face=3D"Courier New,Courier,monospace" size=3D"2">>>> " = If the
>>>      visited network to which outbo= und roamers attach to does not
>>>      suppor= t PDP/PDN Type IPv6, then there needs to be a fallback
<= font face=3D"Courier New,Courier,monospace" size=3D"2">>>> &n= bsp;    option."
>>>
>>> This is  als= o relevant to v4v6 since v4v6 is much newer and thus much
>>> = ;less widely deployed than IPv6 PDP.
>>
>> Right. I defini= tely should add few words around that.
>>
>>>
>>>&n= bsp;Can you provide some more guidance about what the fall back mechanism&= gt;>> may be?  This is quite a hot topic.   One of the= things we have
>>
>> I am afraid there is no solution tha= t would please all parties. And given
>> the wished stricter sco= pe of the I-D, we don't really have 3GPP TS level
>> defined fal= lback mechanisms. Using S2c comes to my mind.. but..
>>
>
>&nbs= p;Right, agreed regarding stricter scope and 3GPP failing to provide
>&n= bsp;real world guidance to operators in this situation ... as well as GSMA<= br>= > ...
>
>>> discussed deploying is having PCRF rul= es that reject PDP Type IPv6
>>> from Gp (if MNC =3D=3D my MN= C ok, else reject) until roaming agreements
>>> are ratifie= d and engineered for.
>>
>> Good point. I have been a bit = hesitant to add anything PCC related so far
>> as PCC is an op= tional functionality. One could probably do that also in a
<= tt>>> MM= E/SGSN level using the grey blob "roaming restrictions". However, in that&= gt;> case the responsibility falls into the visited operator..
<= /font>>= >
>
> I cannot assume the visited network even knows what a= n IPv6 PDP is,
> right?  And, if the visited network does allo= w the IPv6 PDP, they will
> want to charge for it.  They will = want to charge the home network for
> it.  So, if i host an IP= v6 capable APN across GRX/IPX, i am liable for
> the billing of it = ... yet ZERO billing arrangements account for IPv6
> today.  S= o, the home network MUST block the IPv6 PDP across the
<= font face=3D"Courier New,Courier,monospace" size=3D"2">> roaming un= til it is possible to bill for it, which involves
> complexities th= at nobody believes will be solved before IPv6 is rolled
= > out to us= ers.
>
> So, if the home network must block the IPv6 PDP, it m= ust be done on
> the GGSN/P-GW via GGSN/P-GW features or PCRF rules= .
>
>>>
>>> Today, IPv6 roaming is revenue leakag= e in most case.  To fix this,
>>> IPv6 roaming should be= rejected until fixed and billed properly.
>>
>> The forma= l practicalities are of course up to the operator community to
>>&nbs= p;decide.
>>
>
> Right now, operators are looking to cover= revenue leakage that is
> happening via IPv6.  They are not l= ooking to enable it across roaming.
>
>>> Given that prces= s will take a long time and IPv6 deployments are
>>> rolling = out now in various 3G and 4G networks, what will be the fall
>>>&n= bsp;back?  Should the device have multiple APNs with priorities set (I= Pv6
>>> =3D p1, ipv4 =3D p2)?  What are the proper failu= re codes that the UE
>>> should expect to advance the through= the priority list and retry the
>>> next APN.
>>
>&= gt; Above priority based mechanisms are being implemented (or partiall= y
>> already implemented) to devices, at least to some of them. = Some guidance is
>> already there in 23.401 that relate to retur= n codes received from the
>> network and how the mobile device s= hould act after based on those. The
>> operator can affect those= by tuning the subscription profile/PDN-GW
>> configuration. Unf= ortunately, there is also a grey area that is mostly left
>> for= mobile device implementers to come up with their innovative ways to
>&g= t; handle the situation.
>>
>
> Can you provid= e a pointer in 23.401? I could not find this text.
>
= >> Would= it make sense to list some of the possible ways that are possible
>>=  strictly following the 23.401 "toolbox"? That would probably be a new=
>> section 8.x.
>>
>
> I believe that would be= a great addition to the draft as this is a
> real problem and th= e community should have a good discussion on it
> across the variou= s stakeholders.
>
> As i mentioned, my operating assumption is t= hat the home network must
> reject IPv6 PDP from Gp as long as ther= e is not a roaming agreement
> and billing infrastructure to suppor= t it.   Today, there is nothing
> for roaming with IPv6, so it= should not be supported anywhere via
> roaming.  That said, t= he home network must reject the PDP, and the UE
> must react by ret= rying with IPv4.
>
> Cameron
>
>> - Jouni
>>= ;
>>
>>>
>>> Thanks,
>>> Cameron=
>>
>>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
> v6ops mailing list
> v6ops@ietf.org&= gt; https://ww= w.ietf.org/mailman/listinfo/v6ops
= From jan@go6.si Sun Jan 23 10:56:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B570F3A6938 for ; Sun, 23 Jan 2011 10:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Jthx2z8y12 for ; Sun, 23 Jan 2011 10:56:37 -0800 (PST) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by core3.amsl.com (Postfix) with ESMTP id 2AEC33A6930 for ; Sun, 23 Jan 2011 10:56:36 -0800 (PST) Received: from jan-mac.local (unknown [213.250.27.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id EFD8A237803C for ; Sun, 23 Jan 2011 19:59:26 +0100 (CET) Message-ID: <4D3C7A8E.40403@go6.si> Date: Sun, 23 Jan 2011 19:59:26 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 18:56:38 -0000 On 1/23/11 7:50 PM, Roman.Arcea@orange.md wrote: > Yes, > > Properly billed for international usage in 3 European countries. Have > checked with billing on that. > The information is based on what I have tried. No prior official > arrangements have been made. > Hi We deployed IPv6 at two Slovenian mobile operators in April 2010, since then I tested IPv6 PDP in roaming from various places around the world - most intensively from July to October last year. Received bills from operators - none. We received a bill for v6 traffic in November, but just from one operator (you would never guess which, but sorry, no names...) I agree that billing needs to be fixed (and here goes away my free mobile communication), but this can't be basis for refusing IPv6 PDP context in roaming mode. If you can't charge it, then it's free. If you can or want to charge it, charge it. But please don't suggest people to drop PDP contexts. Cheers, Jan Zorz go6.si From cb.list6@gmail.com Sun Jan 23 11:09:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02593A693F for ; Sun, 23 Jan 2011 11:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.96 X-Spam-Level: X-Spam-Status: No, score=-2.96 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, J_CHICKENPOX_13=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 z6vGyNMJ8pqX for ; Sun, 23 Jan 2011 11:09:26 -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 0493C3A693C for ; Sun, 23 Jan 2011 11:09:25 -0800 (PST) Received: by qyj19 with SMTP id 19so3481537qyj.10 for ; Sun, 23 Jan 2011 11:12:18 -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 :content-transfer-encoding; bh=h8HO6RdkorCEjy+VgHWEkVypihzEt9N1DyrSinJK2KU=; b=oCvhTP6ZpMptSIr0BAQ/fuIAPmqkHxw3yXYHSDWQ71/mkoCsIWUABxLVsOIscWDsff tPjVy6xvb15Y/9T5Z2iAs46Rge8Duswc2rSwIEEAxKQA9kdTbEfbazIj0CkYUvIgE6Rf hPE6604NEluClvd9JbR6VRnjNk3hYp8kdi0YU= 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=AbLxPksB3BZNEQQNk9L2f3cihnUySS2TGknIPVpwGHaV2kjJK6OKQckLkh/uoaX8ac 28F6Mm1d7fcRT3xUUBTeSN7Fh5gKlgBZxi5/yNWSrBd/hL1t1q4FPWR+Hz9gnoDzyGHt 3tj/MOSwPZnDwb9cXvV1zmNEWPArmBLWO+HQs= MIME-Version: 1.0 Received: by 10.229.128.228 with SMTP id l36mr2975287qcs.296.1295809937820; Sun, 23 Jan 2011 11:12:17 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sun, 23 Jan 2011 11:12:17 -0800 (PST) In-Reply-To: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> Date: Sun, 23 Jan 2011 11:12:17 -0800 Message-ID: From: Cameron Byrne To: Roman.Arcea@orange.md Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:09:27 -0000 Roman, On Sun, Jan 23, 2011 at 10:50 AM, wrote: > Yes, > > Properly billed for international usage in 3 European countries. Have > checked with billing on that. > The information is based on what I have tried. No prior official > arrangements have been made. > Good. But, the bilateral roaming contracts need to be updated likely. This is the policy issues that has us most concerned. The technical pieces have available technical solutions. > The case with E/// is interesting and it might have been the case. Indeed= , > the prior change of the IP field to 128 bits should be made. We had a > similar issue, however it has been solved in less then 2 weeks. > For some it will be easy to solve. Others, it will not be easy to solve. And, you are progressive and savvy with IPv6. Not all operators have IPv6 on the their near term roadmap and billing systems tend to be very inflexible and hard to update for many operators. Yet, we both have to support the roaming partners and assume they do not have ipv6 until they explicitly tell us in the roaming contracts that IPv6 is ok. If we assume IPv6 works, i can lead to billing systems crashing and revenue leakage where customers are not billed. Trial and error is not good enough here, as the business folks have very little tolerance for these problems. > Now I am not saying that a fallback mechanism is something we do not need= . > All I am suggesting is as long as timing is involved, we are unlikely to = see > it in 3-5 years from now in all the networks we have roaming arrangements > with. While, IPv6 PDP is there starting from R99, so it might be easier t= o > ask the partners to have a look in their billing now then try and explain Agreed. This seems something GSMA should prioritize. > our customers for the next 5 years that we are still waiting for a fallba= ck > mechanism, this is why they should manually select another APN to use whe= n > they are going abroad. The question is either in 5 years from now we migh= t > have customers with IPv6/v4v6 only APNs? > > So, the problem is really complex here. I would rather start working on w= hat > we have now and still hope for the fallback, rather then sabotage the pro= per > IPv6 deployment for years in hope that country X will have their network > elements upgraded. > I agree. We do not want to sabotage IPv6 roaming adoption. This needs to be pushed, but even as a high priority in GSMA, a fallback will be required for 5+ years at least since we both have over 100 roaming partners all around the globe. The fall back i have suggested works well, in my mind. The UE always tries IPv6 first. The home network will reject or accept the PDP based on PCRF rule. For example, "Mobile Network Code" =3D=3D "MNC whitelist of IPv6 roaming partners" then OK, else reject. And upon reject, the UE tries IPv4 This way, IPv6 is always first and allowed when possible. The fallback is IPv4, which always works. Fallback for a given roaming partner will end when they support IPv6 in the roaming contracts and are added to the whitelist. The PCRF supports this logic very easy today. Cameron > Roman > > > -----Cameron Byrne wrote: ----- > > To: Roman.Arcea@orange.md > From: Cameron Byrne > Date: 01/23/2011 08:33PM > Cc: jouni.nospam@gmail.com, v6ops@ietf.org > Subject: Re: [v6ops] Fwd: New Version Notification for > draft-korhonen-v6ops-3gpp-eps-05 > > On Sun, Jan 23, 2011 at 10:22 AM, =A0 wrote: >>=A0Hi Cameron, >> >>=A0I am not sure that "So, the home network MUST block the IPv6 PDP acros= s >> the >>=A0roaming until it is possible to bill for it"=A0 is a proper statement = for an >>=A0IPv6 PDP. I have tried IPv6 PDP in roaming in 3 different countries >> without >>=A0any prior testing arrangements and have been billed correctly in every >> case. >>=A0Obviously I can not assume it will be perfect for any country I visit = and >> we >>=A0need a mechanism indeed to define it on a formal level. >> > > This is surprising. =A0You were billed for the proper international > roaming usage? =A0We have reached out to many roaming partners and they > have explicitly said they do not have plans to support this. > > So, is your information based on what you have tried or what various > operators have contractually agreed to? =A0I agree there is a difference > between the 2, but both must be clearly supported before we can allow > customers to do it. > > Furthermore, Ericsson has relayed a situation where they did ipv6 pdp > in Japan recently and it crashed the Japanese billing system since > there was unexpected data in the CDRs.... 128 bit Severed PDP field > instead of 32 crashed the CDR batch processing. > >>=A0"which involves complexities that nobody believes will be solved befor= e >> IPv6 >>=A0is rolled out to users." - so, you believe it will be easier and faste= r to >>=A0create fallback mechanism that will most likely come as a part of a ma= jor >>=A0release years from now, rather then correct the billing, which in most >> cases >>=A0may disconsider the IP address anyway and does not care about IP versi= on? >> > > Yes. =A0I believe fall back is required since the official word from our > roaming partners is that they do not support it. =A0Without official > support, we cannot take it to production. =A0And, with so many roaming > partners running different software for billing and different hardware > in their networks, it is a very complicated environment to drive > change. > >>=A0At this point I am somehow seeing the light at the end of the tunnel w= ith >>=A0the IPv6 only PDP and believe that the roaming partners should simply >> check >>=A0their capabilities in this regards. > > I am sorry to be pessimistic just as you are becoming optimistic !=A0 I > too believe IPv6-only is good, but the roaming part .... it is a > challenge to make "officially" work while i am aware that in some > places it does unofficially work. =A0I can tell you today that Ericsson > has done IPv6 roaming on the T-Mobile USA back to Telia as the home > network. =A0It was not billed from T-Mobile to Telia ... the IPv6 CDRs > are discarded as part of CDR data validation. =A0So it technically works > for the user, but it will not be billed... which is bad for the > operator. > >>=A0Regarding the v4v6 PDP the issue is more complex indeed as it will tak= e >>=A0years for operators to upgrade to supporting releases. In that specifi= c >> case >>=A0the fallback mechanisms should be in place and they might arrive just = in >>=A0time before the issues are widespread. >> >>=A0Best, >>=A0Roman >> >> >> >> >>=A0-----v6ops-bounces@ietf.org wrote: ----- >> >>=A0To: Jouni >>=A0From: Cameron Byrne >>=A0Sent by: v6ops-bounces@ietf.org >>=A0Date: 01/23/2011 06:29AM >>=A0Cc: IPv6 Ops WG >>=A0Subject: Re: [v6ops] Fwd: New Version Notification for >>=A0draft-korhonen-v6ops-3gpp-eps-05 >> >>=A0On Sat, Jan 22, 2011 at 2:21 AM, Jouni wrote: >>> >>>=A0Hi, >>> >>>=A0Thanks for the quick feedback. >>> >>>=A0On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: >>> >>>>=A0" If the >>>>=A0=A0 =A0 =A0visited network to which outbound roamers attach to does = not >>>>=A0=A0 =A0 =A0support PDP/PDN Type IPv6, then there needs to be a fallb= ack >>>>=A0=A0 =A0 =A0option." >>>> >>>>=A0This is =A0also relevant to v4v6 since v4v6 is much newer and thus m= uch >>>>=A0less widely deployed than IPv6 PDP. >>> >>>=A0Right. I definitely should add few words around that. >>> >>>> >>>>=A0Can you provide some more guidance about what the fall back mechanis= m >>>>=A0may be? =A0This is quite a hot topic. =A0 One of the things we have >>> >>>=A0I am afraid there is no solution that would please all parties. And g= iven >>>=A0the wished stricter scope of the I-D, we don't really have 3GPP TS le= vel >>>=A0defined fallback mechanisms. Using S2c comes to my mind.. but.. >>> >> >>=A0Right, agreed regarding stricter scope and 3GPP failing to provide >>=A0real world guidance to operators in this situation ... as well as GSMA >>=A0... >> >>>>=A0discussed deploying is having PCRF rules that reject PDP Type IPv6 >>>>=A0from Gp (if MNC =3D=3D my MNC ok, else reject) until roaming agreeme= nts >>>>=A0are ratified and engineered for. >>> >>>=A0Good point. I have been a bit hesitant to add anything PCC related so= far >>>=A0as PCC is an optional functionality. One could probably do that also = in a >>>=A0MME/SGSN level using the grey blob "roaming restrictions". However, i= n >>> that >>>=A0case the responsibility falls into the visited operator.. >>> >> >>=A0I cannot assume the visited network even knows what an IPv6 PDP is, >>=A0right? =A0And, if the visited network does allow the IPv6 PDP, they wi= ll >>=A0want to charge for it. =A0They will want to charge the home network fo= r >>=A0it. =A0So, if i host an IPv6 capable APN across GRX/IPX, i am liable f= or >>=A0the billing of it ... yet ZERO billing arrangements account for IPv6 >>=A0today. =A0So, the home network MUST block the IPv6 PDP across the >>=A0roaming until it is possible to bill for it, which involves >>=A0complexities that nobody believes will be solved before IPv6 is rolled >>=A0out to users. >> >>=A0So, if the home network must block the IPv6 PDP, it must be done on >>=A0the GGSN/P-GW via GGSN/P-GW features or PCRF rules. >> >>>> >>>>=A0Today, IPv6 roaming is revenue leakage in most case. =A0To fix this, >>>>=A0IPv6 roaming should be rejected until fixed and billed properly. >>> >>>=A0The formal practicalities are of course up to the operator community = to >>>=A0decide. >>> >> >>=A0Right now, operators are looking to cover revenue leakage that is >>=A0happening via IPv6. =A0They are not looking to enable it across roamin= g. >> >>>>=A0Given that prcess will take a long time and IPv6 deployments are >>>>=A0rolling out now in various 3G and 4G networks, what will be the fall >>>>=A0back? =A0Should the device have multiple APNs with priorities set (I= Pv6 >>>>=A0=3D p1, ipv4 =3D p2)? =A0What are the proper failure codes that the = UE >>>>=A0should expect to advance the through the priority list and retry the >>>>=A0next APN. >>> >>>=A0Above priority based mechanisms are being implemented (or partially >>>=A0already implemented) to devices, at least to some of them. Some guida= nce >>> is >>>=A0already there in 23.401 that relate to return codes received from the >>>=A0network and how the mobile device should act after based on those. Th= e >>>=A0operator can affect those by tuning the subscription profile/PDN-GW >>>=A0configuration. Unfortunately, there is also a grey area that is mostl= y >>> left >>>=A0for mobile device implementers to come up with their innovative ways = to >>>=A0handle=A0the situation. >>> >> >>=A0Can you provide a pointer in 23.401? I could not find this text. >> >>>=A0Would it make sense to list some of the possible ways that are possib= le >>>=A0strictly following the 23.401 "toolbox"? That would probably be a new >>>=A0section 8.x. >>> >> >>=A0I believe that would be a great addition to the draft as this is a >>=A0real problem and the community should have a good discussion on it >>=A0across the various stakeholders. >> >>=A0As i mentioned, my operating assumption is that the home network must >>=A0reject IPv6 PDP from Gp as long as there is not a roaming agreement >>=A0and billing infrastructure to support it. =A0 Today, there is nothing >>=A0for roaming with IPv6, so it should not be supported anywhere via >>=A0roaming. =A0That said, the home network must reject the PDP, and the U= E >>=A0must react by retrying with IPv4. >> >>=A0Cameron >> >>>=A0- Jouni >>> >>> >>>> >>>>=A0Thanks, >>>>=A0Cameron >>> >>> >>=A0_______________________________________________ >>=A0v6ops mailing list >>=A0v6ops@ietf.org >>=A0https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Sun Jan 23 11:10:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C693A6945 for ; Sun, 23 Jan 2011 11:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 pvuJTj8O3asR for ; Sun, 23 Jan 2011 11:10:16 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 037E73A6941 for ; Sun, 23 Jan 2011 11:10:15 -0800 (PST) Received: from joelja-mac.local (adsl-99-191-195-38.dsl.pltn13.sbcglobal.net [99.191.195.38]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0NJD4Gc049588 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 23 Jan 2011 19:13:04 GMT (envelope-from joelja@bogus.com) Message-ID: <4D3C7DBF.4070508@bogus.com> Date: Sun, 23 Jan 2011 11:13:03 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cameron Byrne References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:10:18 -0000 On 1/23/11 10:33 AM, Cameron Byrne wrote: > On Sun, Jan 23, 2011 at 10:22 AM, wrote: >> Hi Cameron, >> >> I am not sure that "So, the home network MUST block the IPv6 PDP across the >> roaming until it is possible to bill for it" is a proper statement for an >> IPv6 PDP. I have tried IPv6 PDP in roaming in 3 different countries without >> any prior testing arrangements and have been billed correctly in every case. >> Obviously I can not assume it will be perfect for any country I visit and we >> need a mechanism indeed to define it on a formal level. >> > > This is surprising. You were billed for the proper international > roaming usage? We have reached out to many roaming partners and they > have explicitly said they do not have plans to support this. I'm not sure that the level of granularity around whether or why ipv6 roaming/billing does or does not work is wholly appropiate to an ietf document. certainly such information is has a level of timelyness that may or may not be releveant by the time the document arrives at the publication stage. > So, is your information based on what you have tried or what various > operators have contractually agreed to? I agree there is a difference > between the 2, but both must be clearly supported before we can allow > customers to do it. > > Furthermore, Ericsson has relayed a situation where they did ipv6 pdp > in Japan recently and it crashed the Japanese billing system since > there was unexpected data in the CDRs.... 128 bit Severed PDP field > instead of 32 crashed the CDR batch processing. > >> "which involves complexities that nobody believes will be solved before IPv6 >> is rolled out to users." - so, you believe it will be easier and faster to >> create fallback mechanism that will most likely come as a part of a major >> release years from now, rather then correct the billing, which in most cases >> may disconsider the IP address anyway and does not care about IP version? >> > > Yes. I believe fall back is required since the official word from our > roaming partners is that they do not support it. Without official > support, we cannot take it to production. And, with so many roaming > partners running different software for billing and different hardware > in their networks, it is a very complicated environment to drive > change. > >> At this point I am somehow seeing the light at the end of the tunnel with >> the IPv6 only PDP and believe that the roaming partners should simply check >> their capabilities in this regards. > > I am sorry to be pessimistic just as you are becoming optimistic ! I > too believe IPv6-only is good, but the roaming part .... it is a > challenge to make "officially" work while i am aware that in some > places it does unofficially work. I can tell you today that Ericsson > has done IPv6 roaming on the T-Mobile USA back to Telia as the home > network. It was not billed from T-Mobile to Telia ... the IPv6 CDRs > are discarded as part of CDR data validation. So it technically works > for the user, but it will not be billed... which is bad for the > operator. > >> Regarding the v4v6 PDP the issue is more complex indeed as it will take >> years for operators to upgrade to supporting releases. In that specific case >> the fallback mechanisms should be in place and they might arrive just in >> time before the issues are widespread. >> >> Best, >> Roman >> >> >> >> >> -----v6ops-bounces@ietf.org wrote: ----- >> >> To: Jouni >> From: Cameron Byrne >> Sent by: v6ops-bounces@ietf.org >> Date: 01/23/2011 06:29AM >> Cc: IPv6 Ops WG >> Subject: Re: [v6ops] Fwd: New Version Notification for >> draft-korhonen-v6ops-3gpp-eps-05 >> >> On Sat, Jan 22, 2011 at 2:21 AM, Jouni wrote: >>> >>> Hi, >>> >>> Thanks for the quick feedback. >>> >>> On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: >>> >>>> " If the >>>> visited network to which outbound roamers attach to does not >>>> support PDP/PDN Type IPv6, then there needs to be a fallback >>>> option." >>>> >>>> This is also relevant to v4v6 since v4v6 is much newer and thus much >>>> less widely deployed than IPv6 PDP. >>> >>> Right. I definitely should add few words around that. >>> >>>> >>>> Can you provide some more guidance about what the fall back mechanism >>>> may be? This is quite a hot topic. One of the things we have >>> >>> I am afraid there is no solution that would please all parties. And given >>> the wished stricter scope of the I-D, we don't really have 3GPP TS level >>> defined fallback mechanisms. Using S2c comes to my mind.. but.. >>> >> >> Right, agreed regarding stricter scope and 3GPP failing to provide >> real world guidance to operators in this situation ... as well as GSMA >> ... >> >>>> discussed deploying is having PCRF rules that reject PDP Type IPv6 >>>> from Gp (if MNC == my MNC ok, else reject) until roaming agreements >>>> are ratified and engineered for. >>> >>> Good point. I have been a bit hesitant to add anything PCC related so far >>> as PCC is an optional functionality. One could probably do that also in a >>> MME/SGSN level using the grey blob "roaming restrictions". However, in that >>> case the responsibility falls into the visited operator.. >>> >> >> I cannot assume the visited network even knows what an IPv6 PDP is, >> right? And, if the visited network does allow the IPv6 PDP, they will >> want to charge for it. They will want to charge the home network for >> it. So, if i host an IPv6 capable APN across GRX/IPX, i am liable for >> the billing of it ... yet ZERO billing arrangements account for IPv6 >> today. So, the home network MUST block the IPv6 PDP across the >> roaming until it is possible to bill for it, which involves >> complexities that nobody believes will be solved before IPv6 is rolled >> out to users. >> >> So, if the home network must block the IPv6 PDP, it must be done on >> the GGSN/P-GW via GGSN/P-GW features or PCRF rules. >> >>>> >>>> Today, IPv6 roaming is revenue leakage in most case. To fix this, >>>> IPv6 roaming should be rejected until fixed and billed properly. >>> >>> The formal practicalities are of course up to the operator community to >>> decide. >>> >> >> Right now, operators are looking to cover revenue leakage that is >> happening via IPv6. They are not looking to enable it across roaming. >> >>>> Given that prcess will take a long time and IPv6 deployments are >>>> rolling out now in various 3G and 4G networks, what will be the fall >>>> back? Should the device have multiple APNs with priorities set (IPv6 >>>> = p1, ipv4 = p2)? What are the proper failure codes that the UE >>>> should expect to advance the through the priority list and retry the >>>> next APN. >>> >>> Above priority based mechanisms are being implemented (or partially >>> already implemented) to devices, at least to some of them. Some guidance is >>> already there in 23.401 that relate to return codes received from the >>> network and how the mobile device should act after based on those. The >>> operator can affect those by tuning the subscription profile/PDN-GW >>> configuration. Unfortunately, there is also a grey area that is mostly left >>> for mobile device implementers to come up with their innovative ways to >>> handle the situation. >>> >> >> Can you provide a pointer in 23.401? I could not find this text. >> >>> Would it make sense to list some of the possible ways that are possible >>> strictly following the 23.401 "toolbox"? That would probably be a new >>> section 8.x. >>> >> >> I believe that would be a great addition to the draft as this is a >> real problem and the community should have a good discussion on it >> across the various stakeholders. >> >> As i mentioned, my operating assumption is that the home network must >> reject IPv6 PDP from Gp as long as there is not a roaming agreement >> and billing infrastructure to support it. Today, there is nothing >> for roaming with IPv6, so it should not be supported anywhere via >> roaming. That said, the home network must reject the PDP, and the UE >> must react by retrying with IPv4. >> >> Cameron >> >>> - Jouni >>> >>> >>>> >>>> Thanks, >>>> Cameron >>> >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Roman.Arcea@orange.md Sun Jan 23 11:11:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF27F3A6945 for ; Sun, 23 Jan 2011 11:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_13=0.6, MIME_HTML_ONLY=1.457] 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 vBkxs-ppJzzl for ; Sun, 23 Jan 2011 11:11:29 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 2CC473A6941 for ; Sun, 23 Jan 2011 11:11:29 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id B9B60B48006; Sun, 23 Jan 2011 21:14:14 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id A81EDB48002; Sun, 23 Jan 2011 21:14:14 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4D3C7A8E.40403@go6.si> References: <4D3C7A8E.40403@go6.si>, , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: jan@go6.si Message-ID: Date: Sun, 23 Jan 2011 21:14:15 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 21:14:15, Serialize complete at 01/23/2011 21:14:15, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 21:14:15, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 21:14:15 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:11:31 -0000 Hi Jan,

"but this can't be basis for refusing IPv6 PDP<= /tt> context in= roaming mode." - yes, I can't imagine that either from a= purely user experience perspective. Especially if we project ourselves 2-3= years into the future. Obviously from business perspective it makes sense.=

I will recheck once again the CDRs with the billing, however I am a= bsolutely sure in October 2010 the IPv6 PDP was working in roaming and we h= ave received the bills. Was it a coincidence? I have no idea. Probably it m= ight make sense to ask the billing folks select randomly 10 partners and as= k them to give a spin for the IPv6 PDP and recheck on that on a broader sca= le.

On the Slovenian part, how do you plan to solve the billing issu= es? Do you think it should this be more broadly reflected in the existing d= rafts and how?

Best,
Roman


-----v6ops-bounces@ietf.org wrote: -----
To: v6ops@ietf.org
From: "Jan Zorz @ g= o6.si"
Sent by: v6ops-bounces@ietf.org
Date: 01/2= 3/2011 09:00PM
Subject: Re: [v6ops] Fwd: New Version Notification for dr= aft-korhonen-v6ops-3gpp-eps-05

On 1/23/11 7:50 PM, Roman.Arcea@orange.md wrote= :
> Yes,
>
> Properly billed for international usage in = 3 European countries. Have
> checked with billing on that.
>&nbs= p;The information is based on what I have tried. No prior official
>&nbs= p;arrangements have been made.
>
Hi

We deployed IPv6 at two Slovenia= n mobile operators in April 2010, since
then I tested IPv6 PDP in roaming f= rom various places around the world -
most intensively from July to October= last year.

Received bills from operators - none.

We received a bil= l for v6 traffic in November, but just from one
operator (you would never g= uess which, but sorry, no names...)

I agree that billing needs to be fi= xed (and here goes away my free
mobile communication), but this can't be ba= sis for refusing IPv6 PDP
context in roaming mode. If you can't charge it, = then it's free. If you
can or want to charge it, charge it. But please don'= t suggest people to
drop PDP contexts.

Cheers, Jan Zorz
= go6.si
=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
= From cb.list6@gmail.com Sun Jan 23 11:24:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FEC03A6930 for ; Sun, 23 Jan 2011 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 3hKlLKQcqas6 for ; Sun, 23 Jan 2011 11:24:30 -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 5578D3A6942 for ; Sun, 23 Jan 2011 11:24:30 -0800 (PST) Received: by qwi2 with SMTP id 2so3538785qwi.31 for ; Sun, 23 Jan 2011 11:27:22 -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=B6z7gTk6wIesAo70vzGJfjp4LKYMlThbY/UnFwea8j0=; b=MLQYcDF/J5gCwaPdGMdpI8gkQVSTJT9LzWJHyrwflSRA7/po3o0Jag/W0gQWyIONsg QD3ApFKiFRGDCSNRVjn9TdG+J94H5LGzLm+Vw0oGiPstHiU7rUrsQtJWdVZ1XT2LeGld reWfTTjp++RF8HdF5RY3Ov6DocRenRWzfqM24= 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=FpJCtQJjs+jMKNEMtemns3/GHefYaJhdmUNkRREAWeoKMiSh8tS8nKCK8Xh2IPWe50 KPzATc35wirLMx+zgoC8w35PKIiRhv6025wP7zaHIBt4XqNkMZHF3vxqX/Q/t4Agqelr 5FVQ47VskaVzor9j3e5Yer7LUYnjEYkf6nRLc= MIME-Version: 1.0 Received: by 10.229.250.135 with SMTP id mo7mr3005731qcb.30.1295810842333; Sun, 23 Jan 2011 11:27:22 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sun, 23 Jan 2011 11:27:22 -0800 (PST) In-Reply-To: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C7A8E.40403@go6.si> Date: Sun, 23 Jan 2011 11:27:22 -0800 Message-ID: From: Cameron Byrne To: Roman.Arcea@orange.md Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, jan@go6.si Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:24:31 -0000 Jan, ========== "I agree that billing needs to be fixed (and here goes away my free mobile communication), but this can't be basis for refusing IPv6 PDP context in roaming mode. If you can't charge it, then it's free. If you can or want to charge it, charge it. But please don't suggest people to drop PDP contexts." ========== Sorry, the business folks believe otherwise. No free rides. The only reason it is free for you today is that the mobile providers don't know what i happening. Today, our beta IPv6 APN is not announced to roamers at all. As we go to production, we will be rejecting IPv6 PDP from roaming partners that have not explicitly updated the roaming agreements to include IPv6, which validates that the end to end billing process will work correctly. Cameron From cb.list6@gmail.com Sun Jan 23 11:26:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC993A6946 for ; Sun, 23 Jan 2011 11:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, J_CHICKENPOX_13=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 NGFD94tGNOA0 for ; Sun, 23 Jan 2011 11:26:15 -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 CD66A3A6942 for ; Sun, 23 Jan 2011 11:26:14 -0800 (PST) Received: by qyj19 with SMTP id 19so3490528qyj.10 for ; Sun, 23 Jan 2011 11:29:07 -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 :content-transfer-encoding; bh=tJFIGoyt+GEvWCzOPzTeOw1N5sMR8EkDY/xO9FmZXNY=; b=RMuTxAHMMchmL6FqLb7anRUNkrCFnvHE/XuLBmqXKzn/B60MQGA8rMXYdMHlfWvvt8 +snRe8Ve9DukgAXIAS6HqT13cJ+QJ2y492Lm3Gnksh7WY6z4dN3NaDyz0lYH0yKS/FJL 8rP7jvof8gTQUItGS/DL2xW2/1TSXbcc8FDpQ= 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=swUPjStbsKVPwaMJaQEIJ4RQuT3Vkgy3yu5tU/vrg7U0lR5Sm3pKvtuf6IGCQhtwKq jeZ2KvDLb8qUvfy+XN10PnpyeDsW0MTduDC3zx+WxrFJJae9uH2V10YLCQYlAgDi18OJ CTv5QLFUP/fCWGyI4tXKuVHDMuB1popgGtclY= MIME-Version: 1.0 Received: by 10.229.250.135 with SMTP id mo7mr3007278qcb.30.1295810945594; Sun, 23 Jan 2011 11:29:05 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sun, 23 Jan 2011 11:29:05 -0800 (PST) In-Reply-To: <4D3C7DBF.4070508@bogus.com> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C7DBF.4070508@bogus.com> Date: Sun, 23 Jan 2011 11:29:05 -0800 Message-ID: From: Cameron Byrne To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:26:17 -0000 On Sun, Jan 23, 2011 at 11:13 AM, Joel Jaeggli wrote: > On 1/23/11 10:33 AM, Cameron Byrne wrote: >> On Sun, Jan 23, 2011 at 10:22 AM, =A0 wrote: >>> Hi Cameron, >>> >>> I am not sure that "So, the home network MUST block the IPv6 PDP across= the >>> roaming until it is possible to bill for it" =A0is a proper statement f= or an >>> IPv6 PDP. I have tried IPv6 PDP in roaming in 3 different countries wit= hout >>> any prior testing arrangements and have been billed correctly in every = case. >>> Obviously I can not assume it will be perfect for any country I visit a= nd we >>> need a mechanism indeed to define it on a formal level. >>> >> >> This is surprising. =A0You were billed for the proper international >> roaming usage? =A0We have reached out to many roaming partners and they >> have explicitly said they do not have plans to support this. > > I'm not sure that the level of granularity around whether or why ipv6 > roaming/billing does or does not work is wholly appropiate to an ietf > document. certainly such information is has a level of timelyness that > may or may not be releveant by the time the document arrives at the > publication stage. Agreed. But this conversation is needed to scope the problem and outline the applicability of fallback mechanisms that are available today and specified in 3GPP. cameron > >> So, is your information based on what you have tried or what various >> operators have contractually agreed to? =A0I agree there is a difference >> between the 2, but both must be clearly supported before we can allow >> customers to do it. >> >> =A0Furthermore, Ericsson has relayed a situation where they did ipv6 pdp >> in Japan recently and it crashed the Japanese billing system since >> there was unexpected data in the CDRs.... 128 bit Severed PDP field >> instead of 32 crashed the CDR batch processing. >> >>> "which involves complexities that nobody believes will be solved before= IPv6 >>> is rolled out to users." - so, you believe it will be easier and faster= to >>> create fallback mechanism that will most likely come as a part of a maj= or >>> release years from now, rather then correct the billing, which in most = cases >>> may disconsider the IP address anyway and does not care about IP versio= n? >>> >> >> Yes. =A0I believe fall back is required since the official word from our >> roaming partners is that they do not support it. =A0Without official >> support, we cannot take it to production. =A0And, with so many roaming >> partners running different software for billing and different hardware >> in their networks, it is a very complicated environment to drive >> change. >> >>> At this point I am somehow seeing the light at the end of the tunnel wi= th >>> the IPv6 only PDP and believe that the roaming partners should simply c= heck >>> their capabilities in this regards. >> >> I am sorry to be pessimistic just as you are becoming optimistic ! =A0I >> too believe IPv6-only is good, but the roaming part .... it is a >> challenge to make "officially" work while i am aware that in some >> places it does unofficially work. =A0I can tell you today that Ericsson >> has done IPv6 roaming on the T-Mobile USA back to Telia as the home >> network. =A0It was not billed from T-Mobile to Telia ... the IPv6 CDRs >> are discarded as part of CDR data validation. =A0So it technically works >> for the user, but it will not be billed... which is bad for the >> operator. >> >>> Regarding the v4v6 PDP the issue is more complex indeed as it will take >>> years for operators to upgrade to supporting releases. In that specific= case >>> the fallback mechanisms should be in place and they might arrive just i= n >>> time before the issues are widespread. >>> >>> Best, >>> Roman >>> >>> >>> >>> >>> -----v6ops-bounces@ietf.org wrote: ----- >>> >>> To: Jouni >>> From: Cameron Byrne >>> Sent by: v6ops-bounces@ietf.org >>> Date: 01/23/2011 06:29AM >>> Cc: IPv6 Ops WG >>> Subject: Re: [v6ops] Fwd: New Version Notification for >>> draft-korhonen-v6ops-3gpp-eps-05 >>> >>> On Sat, Jan 22, 2011 at 2:21 AM, Jouni wrote: >>>> >>>> =A0Hi, >>>> >>>> =A0Thanks for the quick feedback. >>>> >>>> =A0On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: >>>> >>>>> =A0" If the >>>>> =A0 =A0 =A0 visited network to which outbound roamers attach to does = not >>>>> =A0 =A0 =A0 support PDP/PDN Type IPv6, then there needs to be a fallb= ack >>>>> =A0 =A0 =A0 option." >>>>> >>>>> =A0This is =A0also relevant to v4v6 since v4v6 is much newer and thus= much >>>>> =A0less widely deployed than IPv6 PDP. >>>> >>>> =A0Right. I definitely should add few words around that. >>>> >>>>> >>>>> =A0Can you provide some more guidance about what the fall back mechan= ism >>>>> =A0may be? =A0This is quite a hot topic. =A0 One of the things we hav= e >>>> >>>> =A0I am afraid there is no solution that would please all parties. And= given >>>> the wished stricter scope of the I-D, we don't really have 3GPP TS lev= el >>>> defined fallback mechanisms. Using S2c comes to my mind.. but.. >>>> >>> >>> Right, agreed regarding stricter scope and 3GPP failing to provide >>> real world guidance to operators in this situation ... as well as GSMA >>> ... >>> >>>>> =A0discussed deploying is having PCRF rules that reject PDP Type IPv6 >>>>> =A0from Gp (if MNC =3D=3D my MNC ok, else reject) until roaming agree= ments >>>>> =A0are ratified and engineered for. >>>> >>>> =A0Good point. I have been a bit hesitant to add anything PCC related = so far >>>> as PCC is an optional functionality. One could probably do that also i= n a >>>> MME/SGSN level using the grey blob "roaming restrictions". However, in= that >>>> case the responsibility falls into the visited operator.. >>>> >>> >>> I cannot assume the visited network even knows what an IPv6 PDP is, >>> right? =A0And, if the visited network does allow the IPv6 PDP, they wil= l >>> want to charge for it. =A0They will want to charge the home network for >>> it. =A0So, if i host an IPv6 capable APN across GRX/IPX, i am liable fo= r >>> the billing of it ... yet ZERO billing arrangements account for IPv6 >>> today. =A0So, the home network MUST block the IPv6 PDP across the >>> roaming until it is possible to bill for it, which involves >>> complexities that nobody believes will be solved before IPv6 is rolled >>> out to users. >>> >>> So, if the home network must block the IPv6 PDP, it must be done on >>> the GGSN/P-GW via GGSN/P-GW features or PCRF rules. >>> >>>>> >>>>> =A0Today, IPv6 roaming is revenue leakage in most case. =A0To fix thi= s, >>>>> =A0IPv6 roaming should be rejected until fixed and billed properly. >>>> >>>> =A0The formal practicalities are of course up to the operator communit= y to >>>> decide. >>>> >>> >>> Right now, operators are looking to cover revenue leakage that is >>> happening via IPv6. =A0They are not looking to enable it across roaming= . >>> >>>>> =A0Given that prcess will take a long time and IPv6 deployments are >>>>> =A0rolling out now in various 3G and 4G networks, what will be the fa= ll >>>>> =A0back? =A0Should the device have multiple APNs with priorities set = (IPv6 >>>>> =A0=3D p1, ipv4 =3D p2)? =A0What are the proper failure codes that th= e UE >>>>> =A0should expect to advance the through the priority list and retry t= he >>>>> =A0next APN. >>>> >>>> =A0Above priority based mechanisms are being implemented (or partially >>>> already implemented) to devices, at least to some of them. Some guidan= ce is >>>> already there in 23.401 that relate to return codes received from the >>>> network and how the mobile device should act after based on those. The >>>> operator can affect those by tuning the subscription profile/PDN-GW >>>> configuration. Unfortunately, there is also a grey area that is mostly= left >>>> for mobile device implementers to come up with their innovative ways t= o >>>> handle the situation. >>>> >>> >>> Can you provide a pointer in 23.401? I could not find this text. >>> >>>> =A0Would it make sense to list some of the possible ways that are poss= ible >>>> strictly following the 23.401 "toolbox"? That would probably be a new >>>> section 8.x. >>>> >>> >>> I believe that would be a great addition to the draft as this is a >>> real problem and the community should have a good discussion on it >>> across the various stakeholders. >>> >>> As i mentioned, my operating assumption is that the home network must >>> reject IPv6 PDP from Gp as long as there is not a roaming agreement >>> and billing infrastructure to support it. =A0 Today, there is nothing >>> for roaming with IPv6, so it should not be supported anywhere via >>> roaming. =A0That said, the home network must reject the PDP, and the UE >>> must react by retrying with IPv4. >>> >>> Cameron >>> >>>> =A0- Jouni >>>> >>>> >>>>> >>>>> =A0Thanks, >>>>> =A0Cameron >>>> >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From Roman.Arcea@orange.md Sun Jan 23 11:43:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CB23A6968 for ; Sun, 23 Jan 2011 11:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 b9yD8xrBKmNy for ; Sun, 23 Jan 2011 11:43:43 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id DF3203A6967 for ; Sun, 23 Jan 2011 11:43:42 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 4A3C0C0A263; Sun, 23 Jan 2011 21:46:28 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 342E0C0A167; Sun, 23 Jan 2011 21:46:28 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4D3C7DBF.4070508@bogus.com> References: <4D3C7DBF.4070508@bogus.com>, <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: joelja@bogus.com Message-ID: Date: Sun, 23 Jan 2011 21:46:28 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 21:46:28, Serialize complete at 01/23/2011 21:46:28, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 21:46:28, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 21:46:28 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:43:46 -0000 I partially agree here. However it is important that we address roaming iss= ues. Roaming is one of the major things that differentiates a fixed line de= ployment from a mobile network deployment. Roaming might be both within the= same country and international. From what I see it is a thing that is over= looked quite often. This might be well demonstrated by the fact that Jan fo= r instance has free service worldwide. Now, if we speak in details regarding applications that do/don't work here = (draft-arkko-ipv6-only-experience-02), I believe we should also address the= issues related to IPv6 in the mobile networks from all the aspects. Best, Roman -----Joel Jaeggli wrote: ----- To: Cameron Byrne From: Joel Jaeggli Date: 01/23/2011 09:13PM Cc: Roman.Arcea@orange.md, v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops= -3gpp-eps-05 On 1/23/11 10:33 AM, Cameron Byrne wrote: >=A0On Sun, Jan 23, 2011 at 10:22 AM, =A0 wrote: >>=A0Hi Cameron, >> >>=A0I am not sure that "So, the home network MUST block the IPv6 PDP acros= s the >>=A0roaming until it is possible to bill for it" =A0is a proper statement = for an >>=A0IPv6 PDP. I have tried IPv6 PDP in roaming in 3 different countries wi= thout >>=A0any prior testing arrangements and have been billed correctly in every= case. >>=A0Obviously I can not assume it will be perfect for any country I visit = and we >>=A0need a mechanism indeed to define it on a formal level. >> > >=A0This is surprising. =A0You were billed for the proper international >=A0roaming usage? =A0We have reached out to many roaming partners and they >=A0have explicitly said they do not have plans to support this. I'm not sure that the level of granularity around whether or why ipv6 roaming/billing does or does not work is wholly appropiate to an ietf document. certainly such information is has a level of timelyness that may or may not be releveant by the time the document arrives at the publication stage. >=A0So, is your information based on what you have tried or what various >=A0operators have contractually agreed to? =A0I agree there is a difference >=A0between the 2, but both must be clearly supported before we can allow >=A0customers to do it. > >=A0 Furthermore, Ericsson has relayed a situation where they did ipv6 pdp >=A0in Japan recently and it crashed the Japanese billing system since >=A0there was unexpected data in the CDRs.... 128 bit Severed PDP field >=A0instead of 32 crashed the CDR batch processing. > >>=A0"which involves complexities that nobody believes will be solved befor= e IPv6 >>=A0is rolled out to users." - so, you believe it will be easier and faste= r to >>=A0create fallback mechanism that will most likely come as a part of a ma= jor >>=A0release years from now, rather then correct the billing, which in most= cases >>=A0may disconsider the IP address anyway and does not care about IP versi= on? >> > >=A0Yes. =A0I believe fall back is required since the official word from our >=A0roaming partners is that they do not support it. =A0Without official >=A0support, we cannot take it to production. =A0And, with so many roaming >=A0partners running different software for billing and different hardware >=A0in their networks, it is a very complicated environment to drive >=A0change. > >>=A0At this point I am somehow seeing the light at the end of the tunnel w= ith >>=A0the IPv6 only PDP and believe that the roaming partners should simply = check >>=A0their capabilities in this regards. > >=A0I am sorry to be pessimistic just as you are becoming optimistic !=A0 I >=A0too believe IPv6-only is good, but the roaming part .... it is a >=A0challenge to make "officially" work while i am aware that in some >=A0places it does unofficially work. =A0I can tell you today that Ericsson >=A0has done IPv6 roaming on the T-Mobile USA back to Telia as the home >=A0network. =A0It was not billed from T-Mobile to Telia ... the IPv6 CDRs >=A0are discarded as part of CDR data validation. =A0So it technically works >=A0for the user, but it will not be billed... which is bad for the >=A0operator. > >>=A0Regarding the v4v6 PDP the issue is more complex indeed as it will take >>=A0years for operators to upgrade to supporting releases. In that specifi= c case >>=A0the fallback mechanisms should be in place and they might arrive just = in >>=A0time before the issues are widespread. >> >>=A0Best, >>=A0Roman >> >> >> >> >>=A0-----v6ops-bounces@ietf.org wrote: ----- >> >>=A0To: Jouni >>=A0From: Cameron Byrne >>=A0Sent by: v6ops-bounces@ietf.org >>=A0Date: 01/23/2011 06:29AM >>=A0Cc: IPv6 Ops WG >>=A0Subject: Re: [v6ops] Fwd: New Version Notification for >>=A0draft-korhonen-v6ops-3gpp-eps-05 >> >>=A0On Sat, Jan 22, 2011 at 2:21 AM, Jouni wrote: >>> >>>=A0 Hi, >>> >>>=A0 Thanks for the quick feedback. >>> >>>=A0 On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: >>> >>>>=A0 "=A0If the >>>>=A0 =A0 =A0 =A0visited network to which outbound roamers attach to does= not >>>>=A0 =A0 =A0 =A0support PDP/PDN Type IPv6, then there needs to be a fall= back >>>>=A0 =A0 =A0 =A0option." >>>> >>>>=A0 This is =A0also relevant to v4v6 since v4v6 is much newer and thus = much >>>>=A0 less widely deployed than IPv6 PDP. >>> >>>=A0 Right. I definitely should add few words around that. >>> >>>> >>>>=A0 Can you provide some more guidance about what the fall back mechani= sm >>>>=A0 may be? =A0This is quite a hot topic. =A0 One of the things we have >>> >>>=A0 I am afraid there is no solution that would please all parties. And = given >>>=A0the wished stricter scope of the I-D, we don't really have 3GPP TS le= vel >>>=A0defined fallback mechanisms. Using S2c comes to my mind.. but.. >>> >> >>=A0Right, agreed regarding stricter scope and 3GPP failing to provide >>=A0real world guidance to operators in this situation ... as well as GSMA >>=A0... >> >>>>=A0 discussed deploying is having PCRF rules that reject PDP Type IPv6 >>>>=A0 from Gp (if MNC =3D=3D my MNC ok, else reject) until roaming agreem= ents >>>>=A0 are ratified and engineered for. >>> >>>=A0 Good point. I have been a bit hesitant to add anything PCC related s= o far >>>=A0as PCC is an optional functionality. One could probably do that also = in a >>>=A0MME/SGSN level using the grey blob "roaming restrictions". However, i= n that >>>=A0case the responsibility falls into the visited operator.. >>> >> >>=A0I cannot assume the visited network even knows what an IPv6 PDP is, >>=A0right? =A0And, if the visited network does allow the IPv6 PDP, they wi= ll >>=A0want to charge for it. =A0They will want to charge the home network for >>=A0it. =A0So, if i host an IPv6 capable APN across GRX/IPX, i am liable f= or >>=A0the billing of it ... yet ZERO billing arrangements account for IPv6 >>=A0today. =A0So, the home network MUST block the IPv6 PDP across the >>=A0roaming until it is possible to bill for it, which involves >>=A0complexities that nobody believes will be solved before IPv6 is rolled >>=A0out to users. >> >>=A0So, if the home network must block the IPv6 PDP, it must be done on >>=A0the GGSN/P-GW via GGSN/P-GW features or PCRF rules. >> >>>> >>>>=A0 Today, IPv6 roaming is revenue leakage in most case. =A0To fix this, >>>>=A0 IPv6 roaming should be rejected until fixed and billed properly. >>> >>>=A0 The formal practicalities are of course up to the operator community= to >>>=A0decide. >>> >> >>=A0Right now, operators are looking to cover revenue leakage that is >>=A0happening via IPv6. =A0They are not looking to enable it across roamin= g. >> >>>>=A0 Given that prcess will take a long time and IPv6 deployments are >>>>=A0 rolling out now in various 3G and 4G networks, what will be the fall >>>>=A0 back? =A0Should the device have multiple APNs with priorities set (= IPv6 >>>>=A0 =3D p1, ipv4 =3D p2)? =A0What are the proper failure codes that the= UE >>>>=A0 should expect to advance the through the priority list and retry the >>>>=A0 next APN. >>> >>>=A0 Above priority based mechanisms are being implemented (or partially >>>=A0already implemented) to devices, at least to some of them. Some guida= nce is >>>=A0already there in 23.401 that relate to return codes received from the >>>=A0network and how the mobile device should act after based on those. The >>>=A0operator can affect those by tuning the subscription profile/PDN-GW >>>=A0configuration. Unfortunately, there is also a grey area that is mostl= y left >>>=A0for mobile device implementers to come up with their innovative ways = to >>>=A0handle the situation. >>> >> >>=A0Can you provide a pointer in 23.401? I could not find this text. >> >>>=A0 Would it make sense to list some of the possible ways that are possi= ble >>>=A0strictly following the 23.401 "toolbox"? That would probably be a new >>>=A0section 8.x. >>> >> >>=A0I believe that would be a great addition to the draft as this is a >>=A0real problem and the community should have a good discussion on it >>=A0across the various stakeholders. >> >>=A0As i mentioned, my operating assumption is that the home network must >>=A0reject IPv6 PDP from Gp as long as there is not a roaming agreement >>=A0and billing infrastructure to support it. =A0 Today, there is nothing >>=A0for roaming with IPv6, so it should not be supported anywhere via >>=A0roaming. =A0That said, the home network must reject the PDP, and the UE >>=A0must react by retrying with IPv4. >> >>=A0Cameron >> >>>=A0 - Jouni >>> >>> >>>> >>>>=A0 Thanks, >>>>=A0 Cameron >>> >>> >>=A0=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>=A0v6ops mailing list >>=A0v6ops@ietf.org >>=A0https://www.ietf.org/mailman/listinfo/v6ops >=A0=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >=A0v6ops mailing list >=A0v6ops@ietf.org >=A0https://www.ietf.org/mailman/listinfo/v6ops > From Roman.Arcea@orange.md Sun Jan 23 11:59:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021B83A6949 for ; Sun, 23 Jan 2011 11:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_13=0.6, MIME_HTML_ONLY=1.457] 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 rwOpM20jlsFy for ; Sun, 23 Jan 2011 11:59:10 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 069E13A6932 for ; Sun, 23 Jan 2011 11:59:09 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 1C709B48002; Sun, 23 Jan 2011 22:02:01 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id EA6B4B48001; Sun, 23 Jan 2011 22:02:00 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: cb.list6@gmail.com Message-ID: Date: Sun, 23 Jan 2011 22:02:01 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 22:02:01, Serialize complete at 01/23/2011 22:02:01, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 22:02:01, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 22:02:01 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:59:12 -0000 Cameron,

The fallback suggestion is relevant. However i= t does apply only to the operators with a PCRF. As was previously noted by = Jouni this is an optional function. I tend to believe it won't apply to the= majority of deployments today (can't confirm it though with any figures). = I would prefer an SGSN functionality instead. I still can see this to be ne= eded on both core and handset sides - this seems to be really hard.
What= I still don't understand is, if you are going to the production IPv6 PDP a= nd there is an average customer going into roaming without a prior fallback= mechanism, does it imply he will have to figure out he must select another= APN to connect? And in the case in 2 years from now for any reason a custo= mer of yours has an IPv6/v4v6 only PDP, to what exactly will it fallback?
Regarding bilateral agreements, yes, they have to be a must. I fully = agree with you. Trial and error solution is definitely not something that w= ould make the operator happy.

Best,
Roman


-----Cameron Byrne <cb.list6@gmail.com> wrote: ----= -
To: Roma= n.Arcea@orange.md
From: Cameron Byrne <cb.list6@gmail.com>
D= ate: 01/23/2011 09:12PM
Cc: jouni.nospam@gmail.com, v6ops@ietf.org=
Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v= 6ops-3gpp-eps-05

Roman,

On Sun, Jan 23, 2011 at 10:50 AM,  <Roman.Arcea@o= range.md> wrote:
> Yes,
>
> Properly billed for= international usage in 3 European countries. Have
> checked with b= illing on that.
> The information is based on what I have tried. No= prior official
> arrangements have been made.
<= font face=3D"Courier New,Courier,monospace" size=3D"2">>
=
Good.  = ;But, the bilateral roaming contracts need to be updated likely.
= This is th= e policy issues that has us most concerned.  The technical=
pieces have= available technical solutions.

> The case with E/// is interes= ting and it might have been the case. Indeed,
> the prior change of= the IP field to 128 bits should be made. We had a
> similar issue,= however it has been solved in less then 2 weeks.
>

<= tt>For some it will= be easy to solve. Others, it will not be easy to
solve.  And, you are= progressive and savvy with IPv6.  Not all
operators have IPv6 on the = their near term roadmap and billing systems
tend to be very inflexible an= d hard to update for many operators.
Yet, we both have to support the roami= ng partners and assume they do
not have ipv6 until they explicitly tell us = in the roaming contracts
that IPv6 is ok. If we assume IPv6 works, i can le= ad to billing
systems crashing and revenue leakage where customers are not = billed.
Trial and error is not good enough here, as the business folks have=
very little tolerance for these problems.

> Now I am not sayin= g that a fallback mechanism is something we do not need.
> All I am= suggesting is as long as timing is involved, we are unlikely to see
>&n= bsp;it in 3-5 years from now in all the networks we have roaming arrangemen= ts
> with. While, IPv6 PDP is there starting from R99, so it might = be easier to
> ask the partners to have a look in their billing now= then try and explain

Agreed.  This seems something GSMA should pr= ioritize.


> our customers for the next 5 years that we are = still waiting for a fallback
> mechanism, this is why they should m= anually select another APN to use when
> they are going abroad. The= question is either in 5 years from now we might
> have customers w= ith IPv6/v4v6 only APNs?
>
> So, the problem is really complex h= ere. I would rather start working on what
> we have now and still h= ope for the fallback, rather then sabotage the proper
> IPv6 deploy= ment for years in hope that country X will have their network
> ele= ments upgraded.
>

I agree. We do not want to sabotage IPv6 roaming a= doption.  This needs
to be pushed, but even as a high priority in GSMA= , a fallback will be
required for 5+ years at least since we both have over= 100 roaming
partners all around the globe.

The fall back i have sugges= ted works well, in my mind.  The UE always
tries IPv6 first.  The= home network will reject or accept the PDP
based on PCRF rule.  For= example, "Mobile Network Code" =3D=3D "MNC
whitelist of IPv6 roaming par= tners" then OK, else reject.  And upon
reject, the UE tries IPv4
=
This way, IPv6 is always first and allowed when possible.  The
fallba= ck is IPv4, which always works.  Fallback for a given roaming
partner = will end when they support IPv6 in the roaming contracts and
are added to t= he whitelist.  The PCRF supports this logic very easy
<= tt>today.

Camer= on
> Roman
>
>
> -----Cameron Byrne <cb.list6@gmail.com= > wrote: -----
>
> To: Roman.Arcea@orange.md
>&nb= sp;From: Cameron Byrne <cb.list6@gmail.com>
> Date: 01/23/2011= 08:33PM
> Cc: jouni.nospam@gmail.com, v6ops@ietf.org
> = ;Subject: Re: [v6ops] Fwd: New Version Notification for
= > draft-kor= honen-v6ops-3gpp-eps-05
>
> On Sun, Jan 23, 2011 at 10:22 AM, &n= bsp;<Roman.Arcea@orange.md> wrote:
>> Hi Cameron,
>&g= t;
>> I am not sure that "So, the home network MUST block the IP= v6 PDP across
>> the
>> roaming until it is possible = to bill for it"  is a proper statement for an
>> IPv6 PDP. = I have tried IPv6 PDP in roaming in 3 different countries
>> wit= hout
>> any prior testing arrangements and have been billed co= rrectly in every
>> case.
>> Obviously I can not assu= me it will be perfect for any country I visit and
>> we
>>=  need a mechanism indeed to define it on a formal level.
>>
<= /font>>=
> This is surprising.  You were billed for the proper interna= tional
> roaming usage?  We have reached out to many roaming p= artners and they
> have explicitly said they do not have plans to s= upport this.
>
> So, is your information based on what you have = tried or what various
> operators have contractually agreed to? &nb= sp;I agree there is a difference
> between the 2, but both must be = clearly supported before we can allow
> customers to do it.
>&g= t; Furthermore, Ericsson has relayed a situation where they did ipv6 p= dp
> in Japan recently and it crashed the Japanese billing system s= ince
> there was unexpected data in the CDRs.... 128 bit Severed = PDP field
> instead of 32 crashed the CDR batch processing.
>&g= t;> "which involves complexities that nobody believes will be solve= d before
>> IPv6
>> is rolled out to users." - so, yo= u believe it will be easier and faster to
>> create fallback mec= hanism that will most likely come as a part of a major
<= font face=3D"Courier New,Courier,monospace" size=3D"2">>> releas= e years from now, rather then correct the billing, which in most
= >>&n= bsp;cases
>> may disconsider the IP address anyway and does not = care about IP version?
>>
>
> Yes.  I believe fall ba= ck is required since the official word from our
> roaming partners = is that they do not support it.  Without official
<= font face=3D"Courier New,Courier,monospace" size=3D"2">> support, w= e cannot take it to production.  And, with so many roaming
<= /tt>> p= artners running different software for billing and different hardware
>&= nbsp;in their networks, it is a very complicated environment to drive
>&= nbsp;change.
>
>> At this point I am somehow seeing the light= at the end of the tunnel with
>> the IPv6 only PDP and believe = that the roaming partners should simply
>> check
= >> t= heir capabilities in this regards.
>
> I am sorry to be pessimis= tic just as you are becoming optimistic !  I
> too believe IPv= 6-only is good, but the roaming part .... it is a
> challenge to ma= ke "officially" work while i am aware that in some
> places it does= unofficially work.  I can tell you today that Ericsson
> has = done IPv6 roaming on the T-Mobile USA back to Telia as the home
<= /tt>> n= etwork.  It was not billed from T-Mobile to Telia ... the IPv6 CDRs&g= t; are discarded as part of CDR data validation.  So it technical= ly works
> for the user, but it will not be billed... which is bad = for the
> operator.
>
>> Regarding the v4v6 PDP the i= ssue is more complex indeed as it will take
>> years for opera= tors to upgrade to supporting releases. In that specific
>> case=
>> the fallback mechanisms should be in place and they might ar= rive just in
>> time before the issues are widespread.
>><= br>= >> Best,
>> Roman
>>
>>
>>
>>=
>> -----v6ops-bounces@ietf.org wrote: -----
= >>
= >>&n= bsp;To: Jouni <jouni.nospam@gmail.com>
>> From: Cameron= Byrne
>> Sent by: v6ops-bounces@ietf.org
<= tt>>> Da= te: 01/23/2011 06:29AM
>> Cc: IPv6 Ops WG <v6ops@ietf.org>
<= /font>>= > Subject: Re: [v6ops] Fwd: New Version Notification for
= >>&n= bsp;draft-korhonen-v6ops-3gpp-eps-05
>>
>> On Sat, Jan 22,= 2011 at 2:21 AM, Jouni <jouni.nospam@gmail.com> wrote:
= >>&g= t;
>>> Hi,
>>>
>>> Thanks for the quic= k feedback.
>>>
>>> On Jan 22, 2011, at 7:58 AM, Cam= eron Byrne wrote:
>>>
>>>> " If the
>>>&= gt;      visited network to which outbound roamers atta= ch to does not
>>>>      support PDP/PDN Ty= pe IPv6, then there needs to be a fallback
>>>>   &nb= sp;  option."
>>>>
>>>> This is  als= o relevant to v4v6 since v4v6 is much newer and thus much
>>>>&= nbsp;less widely deployed than IPv6 PDP.
>>>
>>> Rig= ht. I definitely should add few words around that.
>>>
<= /tt>>>>= ;>
>>>> Can you provide some more guidance about what = the fall back mechanism
>>>> may be?  This is quite a= hot topic.   One of the things we have
>>>
<= tt>>>>&nbs= p;I am afraid there is no solution that would please all parties. And given=
>>> the wished stricter scope of the I-D, we don't really ha= ve 3GPP TS level
>>> defined fallback mechanisms. Using S2c c= omes to my mind.. but..
>>>
>>
>> Right, agreed r= egarding stricter scope and 3GPP failing to provide
>> real worl= d guidance to operators in this situation ... as well as GSMA
>> = ;...
>>
>>>> discussed deploying is having PCRF ru= les that reject PDP Type IPv6
>>>> from Gp (if MNC =3D=3D = my MNC ok, else reject) until roaming agreements
>>>> are = ratified and engineered for.
>>>
>>> Good point. I h= ave been a bit hesitant to add anything PCC related so far
<= tt>>>>&nbs= p;as PCC is an optional functionality. One could probably do that also in a=
>>> MME/SGSN level using the grey blob "roaming restrictions= ". However, in
>>> that
>>> case the responsibi= lity falls into the visited operator..
>>>
>>
>> = I cannot assume the visited network even knows what an IPv6 PDP is,
>>= ; right?  And, if the visited network does allow the IPv6 PDP, th= ey will
>> want to charge for it.  They will want to charge= the home network for
>> it.  So, if i host an IPv6 capable= APN across GRX/IPX, i am liable for
>> the billing of it ... ye= t ZERO billing arrangements account for IPv6
>> today.  So= , the home network MUST block the IPv6 PDP across the
>> roaming= until it is possible to bill for it, which involves
>> complexi= ties that nobody believes will be solved before IPv6 is rolled
>>&nbs= p;out to users.
>>
>> So, if the home network must block t= he IPv6 PDP, it must be done on
>> the GGSN/P-GW via GGSN/P-GW f= eatures or PCRF rules.
>>
>>>>
>>>> Toda= y, IPv6 roaming is revenue leakage in most case.  To fix this,
>>= ;>> IPv6 roaming should be rejected until fixed and billed prope= rly.
>>>
>>> The formal practicalities are of cour= se up to the operator community to
>>> decide.
>>>&= gt;>
>> Right now, operators are looking to cover revenue lea= kage that is
>> happening via IPv6.  They are not looking t= o enable it across roaming.
>>
>>>> Given that prces= s will take a long time and IPv6 deployments are
>>>> roll= ing out now in various 3G and 4G networks, what will be the fall
= >>&g= t;> back?  Should the device have multiple APNs with prioritie= s set (IPv6
>>>> =3D p1, ipv4 =3D p2)?  What are the = proper failure codes that the UE
>>>> should expect to adv= ance the through the priority list and retry the
>>>> next= APN.
>>>
>>> Above priority based mechanisms are b= eing implemented (or partially
>>> already implemented) to de= vices, at least to some of them. Some guidance
>>> is
>>= ;> already there in 23.401 that relate to return codes received fro= m the
>>> network and how the mobile device should act after= based on those. The
>>> operator can affect those by tuning = the subscription profile/PDN-GW
>>> configuration. Unfortunat= ely, there is also a grey area that is mostly
>>> left
>&g= t;> for mobile device implementers to come up with their innovative= ways to
>>> handle the situation.
>>>
>>=
>> Can you provide a pointer in 23.401? I could not find this t= ext.
>>
>>> Would it make sense to list some of the p= ossible ways that are possible
>>> strictly following the 23.= 401 "toolbox"? That would probably be a new
>>> section 8.x= .
>>>
>>
>> I believe that would be a great addit= ion to the draft as this is a
>> real problem and the community = should have a good discussion on it
>> across the various stakeh= olders.
>>
>> As i mentioned, my operating assumption is t= hat the home network must
>> reject IPv6 PDP from Gp as long as = there is not a roaming agreement
>> and billing infrastructure t= o support it.   Today, there is nothing
>> for roaming wit= h IPv6, so it should not be supported anywhere via
>> roaming. &= nbsp;That said, the home network must reject the PDP, and the UE
= >>&n= bsp;must react by retrying with IPv4.
>>
>> Cameron
>&g= t;
>>> - Jouni
>>>
>>>
<= font face=3D"Courier New,Courier,monospace" size=3D"2">>>>>
= >= ;>>> Thanks,
>>>> Cameron
>>>
>&= gt;>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
>> v6ops mailing list
>> v6ops@ietf.org=
>> http= s://www.ietf.org/mailman/listinfo/v6ops
<= div>
= From jan@go6.si Sun Jan 23 12:14:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFEC3A6971 for ; Sun, 23 Jan 2011 12:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqCn0uETXltg for ; Sun, 23 Jan 2011 12:14:52 -0800 (PST) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by core3.amsl.com (Postfix) with ESMTP id 404CF3A695B for ; Sun, 23 Jan 2011 12:14:52 -0800 (PST) Received: from jan-mac.local (unknown [213.250.27.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 156FE237803E; Sun, 23 Jan 2011 21:17:43 +0100 (CET) Message-ID: <4D3C8CE6.9080007@go6.si> Date: Sun, 23 Jan 2011 21:17:42 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roman.Arcea@orange.md References: <4D3C7A8E.40403@go6.si>, , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:14:53 -0000 On 1/23/11 8:14 PM, Roman.Arcea@orange.md wrote: > Hi Jan, > > "but this can't be basis for refusing IPv6 PDPcontext in roaming mode." > - yes, I can't imagine that either from a purely user experience > perspective. Especially if we project ourselves 2-3 years into the > future. Obviously from business perspective it makes sense. > > I will recheck once again the CDRs with the billing, however I am > absolutely sure in October 2010 the IPv6 PDP was working in roaming and > we have received the bills. Was it a coincidence? I have no idea. > Probably it might make sense to ask the billing folks select randomly 10 > partners and ask them to give a spin for the IPv6 PDP and recheck on > that on a broader scale. I have test SIM cards from both mobile operators here that has IPv6 APN and I checked with smaller one, if there are was some billing regarding IPv6 incoming for that SIM. > > On the Slovenian part, how do you plan to solve the billing issues? Do > you think it should this be more broadly reflected in the existing > drafts and how? Well, mobile operators charges roaming based on what bills they receive from foreign operators. Local CDRs are only for reference and double check. If there's no bill from foreign operator, no fee is charged. So, we have IPv6 APN and I go around the world. Some operators block IPv6 PDP, some are not able to do dual PDP context (for N900), at least one of them is charging for IPv6 content, others don't have a clue. So, basically, what Cameron is saying - if I have no clue -> block. Wouldn't be better to say "if I have no clue, investigate and fix it?" /jan From swmike@swm.pp.se Sun Jan 23 12:15:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92E03A697A for ; Sun, 23 Jan 2011 12:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 NH4R7ygwVOJL for ; Sun, 23 Jan 2011 12:15:31 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id E36333A695B for ; Sun, 23 Jan 2011 12:15:30 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 543779C; Sun, 23 Jan 2011 21:18:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5282A9A; Sun, 23 Jan 2011 21:18:21 +0100 (CET) Date: Sun, 23 Jan 2011 21:18:21 +0100 (CET) From: Mikael Abrahamsson To: Roman.Arcea@orange.md In-Reply-To: Message-ID: References: , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:15:31 -0000 On Sun, 23 Jan 2011, Roman.Arcea@orange.md wrote: > And in the case in 2 years from now for any reason a customer of yours > has an IPv6/v4v6 only PDP, to what exactly will it fallback? I'd imagine one has to try to make sure the customer terminals have v6 as primary and v4 as secondary (Symbian has this concept anyway). When dual stack ones are working, perhaps v4v6, v6, v4 is going to be 1, 2 and 3 on the list. Getting v6 only to work is mostly a billing (and perhaps licensing) problem, getting v4v6 to work means lifting the whole infrastructure version if I understood correctly. I would very much like to know what thoughts Apple and Google have on this for their future software... -- Mikael Abrahamsson email: swmike@swm.pp.se From jan@go6.si Sun Jan 23 12:18:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208303A697A for ; Sun, 23 Jan 2011 12:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OL6JTCBoGVi for ; Sun, 23 Jan 2011 12:18:02 -0800 (PST) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by core3.amsl.com (Postfix) with ESMTP id 03B5A3A6971 for ; Sun, 23 Jan 2011 12:18:02 -0800 (PST) Received: from jan-mac.local (unknown [213.250.27.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id BCE90237803C; Sun, 23 Jan 2011 21:20:53 +0100 (CET) Message-ID: <4D3C8DA5.1010602@go6.si> Date: Sun, 23 Jan 2011 21:20:53 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cameron Byrne References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C7A8E.40403@go6.si> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:18:03 -0000 On 1/23/11 8:27 PM, Cameron Byrne wrote: > Jan, > ========== > "I agree that billing needs to be fixed (and here goes away my free > mobile communication), but this can't be basis for refusing IPv6 PDP > context in roaming mode. If you can't charge it, then it's free. If you > can or want to charge it, charge it. But please don't suggest people to > drop PDP contexts." > ========== > > Sorry, the business folks believe otherwise. No free rides. The only > reason it is free for you today is that the mobile providers don't > know what i happening. > > Today, our beta IPv6 APN is not announced to roamers at all. Beta APNs of our mobile operators (public pilot testing for users) are annonced to roamers. Why not? If foreign operator sends a bill, it gets charged to customer. Otherwise not :) > > As we go to production, we will be rejecting IPv6 PDP from roaming > partners that have not explicitly updated the roaming agreements to > include IPv6, which validates that the end to end billing process will > work correctly. This might severly speed-up the process of fixing the billing schema around the world. /jan From swmike@swm.pp.se Sun Jan 23 12:20:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25A03A6990 for ; Sun, 23 Jan 2011 12:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 ejfMWuQ17jgB for ; Sun, 23 Jan 2011 12:20:56 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 33EB93A698F for ; Sun, 23 Jan 2011 12:20:56 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 04D7D9C; Sun, 23 Jan 2011 21:23:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0252A9A for ; Sun, 23 Jan 2011 21:23:48 +0100 (CET) Date: Sun, 23 Jan 2011 21:23:47 +0100 (CET) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: <4D3C8CE6.9080007@go6.si> Message-ID: References: <4D3C7A8E.40403@go6.si>, , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C8CE6.9080007@go6.si> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:20:58 -0000 On Sun, 23 Jan 2011, Jan Zorz @ go6.si wrote: > So, we have IPv6 APN and I go around the world. Some operators block > IPv6 PDP, some are not able to do dual PDP context (for N900), at least > one of them is charging for IPv6 content, others don't have a clue. I was told that v6 PDP is an extra license in (some) SGSN, I guess it might be the same in RNC. Dual PDP context is definitely an extra license in RNC. So this is going to be different experience all around the world depending on what each operator has chosen to implement. When we initially started looking into this we (IP guys) discovered that dual PDP context worked on the "new" GSM/EDGE network we were rolling out, it didn't work on the UMTS/HSPA network (when one established the second one, it just silently stopped forwarding traffic on both, didn't tear down any PDP), and our "old" GSM network didn't support it either (don't remember how it behaved). Much confusion before we figured out why it worked "sometimes" :P It's a nightmare to try to get this working properly globally, I can understand why Cameron wants to disable v6 for roaming. -- Mikael Abrahamsson email: swmike@swm.pp.se From Roman.Arcea@orange.md Sun Jan 23 12:40:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FED83A697F for ; Sun, 23 Jan 2011 12:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] 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 SPG8q0PBDLw2 for ; Sun, 23 Jan 2011 12:40:00 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id D041F3A67FC for ; Sun, 23 Jan 2011 12:39:59 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id C0B00B48002; Sun, 23 Jan 2011 22:42:45 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id ABDD1B48001; Sun, 23 Jan 2011 22:42:45 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4D3C8CE6.9080007@go6.si> References: <4D3C8CE6.9080007@go6.si>, <4D3C7A8E.40403@go6.si>, , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: jan@go6.si Message-ID: Date: Sun, 23 Jan 2011 22:42:46 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 22:42:46, Serialize complete at 01/23/2011 22:42:46, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 22:42:46, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 22:42:46 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:40:01 -0000 Interesting. I was not aware of the issue regarding billing. = As I previously mentioned I had the "luck" to be charged. I was supposing t= hat there will be issues for some operators. Will have to further address t= hat aspect of deployment and recheck with billing and roaming folks.
Yes= , I am as well aware of at least 1 operator that blocks IPv6 PDP.

Ro= man



-----"Jan Zorz @ go6.si" = <jan@go6.s= i> wrote: -----
To: Roman.Arcea@orange.md
From: "Jan Zorz @ go6.si" <jan@go6.si&g= t;
Date: 01/23/2011 10:17PM
Cc: v6ops@ietf.org
Subject: Re: [v6o= ps] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05
<= br>On 1/23/11 8= :14 PM, Roman.Arcea@orange.md wrote:
> Hi Jan,
= >
= > = "but this can't be basis for refusing IPv6 PDPcontext in roaming mode."
= >= ; - yes, I can't imagine that either from a purely user experience
= >= ; perspective. Especially if we project ourselves 2-3 years into the&= gt; future. Obviously from business perspective it makes sense.
>&= gt; I will recheck once again the CDRs with the billing, however I am<= br>= > absolutely sure in October 2010 the IPv6 PDP was working in roami= ng and
> we have received the bills. Was it a coincidence? I have n= o idea.
> Probably it might make sense to ask the billing folks sel= ect randomly 10
> partners and ask them to give a spin for the IPv6= PDP and recheck on
> that on a broader scale.

<= tt>I have test SIM = cards from both mobile operators here that has IPv6 APN
= and I checked with = smaller one, if there are was some billing regarding
IPv6 incoming for that= SIM.

>
> = ;On the Slovenian part, how do you plan to solve the billing issues? Do
= >= ; you think it should this be more broadly reflected in the existing&= gt; drafts and how?

Well, mobile operators charges roaming based o= n what bills they receive
from foreign operators. Local CDRs are only for r= eference and double
check. If there's no bill from foreign operator, no fee= is charged.

So, we have IPv6 APN and I go around the world. Some opera= tors block
IPv6 PDP, some are not able to do dual PDP context (for N900), a= t least
one of them is charging for IPv6 content, others don't have a clue.=

So, basically, what Cameron is saying - if I have no clue -> bloc= k.

Wouldn't be better to say "if I have no clue, investigate and fix it= ?"

/jan
= From jouni.nospam@gmail.com Sun Jan 23 12:46:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321B83A6985 for ; Sun, 23 Jan 2011 12:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_13=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 HKZQHbed+HjB for ; Sun, 23 Jan 2011 12:46:48 -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 A4FCC3A6969 for ; Sun, 23 Jan 2011 12:46:47 -0800 (PST) Received: by fxm9 with SMTP id 9so3716856fxm.31 for ; Sun, 23 Jan 2011 12:49:39 -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=qksIdHdPOjpxiIpnl6ZdF8iSGf0U5CPmnKjkffdR6l4=; b=PL/oixDf+X+bntXore7lTQGlba+rsQMtj7NVH04vco4Q3lpDGj5GJDoUkt2B0kLX1X CRu30oQRr7cN84ZEg2ykZ6GSjgEH4h0mQPrVEmFrhem+x3sBLubkJIgiqb4W+f+sj6I9 ZebcylVawOH1vk37HdJrjGcHP1cUlbteATZxQ= 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=xVljypNscL8XzMXvMvmeGxqpVrr8/RXYVGnsi32Wr5dw8WJLs8juh/3S/1DdL/Xgsf jaiWP4HbtTHwc7YQtgESIcr9wItvc6KoN+5fW31cUX1wKm6lOFp9DVz4w4A9tWCaw9kG 1+zsng381qiD5rg01jSRszcKOuU6S2WUcACgA= Received: by 10.223.103.4 with SMTP id i4mr3293377fao.123.1295815776659; Sun, 23 Jan 2011 12:49:36 -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 l3sm627443fan.2.2011.01.23.12.49.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Jan 2011 12:49:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4D3C8CE6.9080007@go6.si> Date: Sun, 23 Jan 2011 22:49:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F69CB9E-4835-4F46-BFF8-EBAA78687CBA@gmail.com> References: <4D3C7A8E.40403@go6.si>, , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C8CE6.9080007@go6.si> To: "Jan Zorz @ go6.si" X-Mailer: Apple Mail (2.1078) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:46:49 -0000 Hi, On Jan 23, 2011, at 10:17 PM, Jan Zorz @ go6.si wrote: > On 1/23/11 8:14 PM, Roman.Arcea@orange.md wrote: >> Hi Jan, >>=20 >=20 [snip] >=20 > Well, mobile operators charges roaming based on what bills they = receive from foreign operators. Local CDRs are only for reference and = double check. If there's no bill from foreign operator, no fee is = charged. >=20 > So, we have IPv6 APN and I go around the world. Some operators block = IPv6 PDP, some are not able to do dual PDP context (for N900), at least = one of them is charging for IPv6 content, others don't have a clue. >=20 > So, basically, what Cameron is saying - if I have no clue -> block. >=20 > Wouldn't be better to say "if I have no clue, investigate and fix it?" I know that some operators whose networks I have roamed to using IPv6, = have contacted Sonera's (whose SIMs I have been using past year) roaming = folks complaining about unknown PDP Types, unknown addresses and such. I = have not verified whether those caused any actions but I doubt as such = "error cases" are rare compared to other stuff.. Anyway, even if this discussion is interesting, it imho would mostly = belong to GSMA something concrete to happen. They have established a = task force for IPv6 transition. - Jouni >=20 > /jan > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jan@go6.si Sun Jan 23 12:50:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFD93A698E for ; Sun, 23 Jan 2011 12:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeKRHTl6Kuxh for ; Sun, 23 Jan 2011 12:50:39 -0800 (PST) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by core3.amsl.com (Postfix) with ESMTP id D2BDA3A6928 for ; Sun, 23 Jan 2011 12:50:38 -0800 (PST) Received: from jan-mac.local (unknown [213.250.27.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id A7243237803C; Sun, 23 Jan 2011 21:53:30 +0100 (CET) Message-ID: <4D3C954A.4000403@go6.si> Date: Sun, 23 Jan 2011 21:53:30 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: jouni korhonen References: <4D3C7A8E.40403@go6.si>, , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C8CE6.9080007@go6.si> <2F69CB9E-4835-4F46-BFF8-EBAA78687CBA@gmail.com> In-Reply-To: <2F69CB9E-4835-4F46-BFF8-EBAA78687CBA@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 20:50:42 -0000 On 1/23/11 9:49 PM, jouni korhonen wrote: > I know that some operators whose networks I have roamed to using > IPv6, have contacted Sonera's (whose SIMs I have been using past > year) roaming folks complaining about unknown PDP Types, unknown > addresses and such. I have not verified whether those caused any > actions but I doubt as such "error cases" are rare compared to other > stuff.. Hey, Yes, if that error rate in unknown PDP type (CDR tickets) is small enough it is ignored. Otherwise it might get manually resolved. The best for operator is to define proper CDR type and get over with it. You don't have to change billing for that, just tell tickets normaliser and billing what that type is. Easy as that. /jan From jan@go6.si Sun Jan 23 13:04:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA2D3A6932 for ; Sun, 23 Jan 2011 13:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAozMs1WgAEN for ; Sun, 23 Jan 2011 13:04:42 -0800 (PST) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by core3.amsl.com (Postfix) with ESMTP id 6E6423A6842 for ; Sun, 23 Jan 2011 13:04:42 -0800 (PST) Received: from jan-mac.local (unknown [213.250.27.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 08D632378032; Sun, 23 Jan 2011 22:07:34 +0100 (CET) Message-ID: <4D3C9895.807@go6.si> Date: Sun, 23 Jan 2011 22:07:33 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cameron Byrne References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C7A8E.40403@go6.si> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 21:04:43 -0000 On 1/23/11 8:27 PM, Cameron Byrne wrote: > As we go to production, we will be rejecting IPv6 PDP from roaming > partners that have not explicitly updated the roaming agreements to > include IPv6, which validates that the end to end billing process will > work correctly. Cameron, So, if I understand correctly, if your customer goes abroad and tries to connect with IPv6 PDP context to your IPv6 APN via roaming, you will block it if paper agreements are not updated, even though roaming remote operator is not blocking it and may or may not send the bill for this IPv6 PDP context, that you can charge to your customer? Not sure I get the point, why complicate? If user can get through with PDP, good for him. If he gets billed, good. If the bill does never come, even better. If user can't connect through, get him to complain and fix this with roaming operator. You as operator can't be harmed or your income leaked :) /jan From Roman.Arcea@orange.md Sun Jan 23 13:05:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CFB3A6939 for ; Sun, 23 Jan 2011 13:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 0amVP8b0eOne for ; Sun, 23 Jan 2011 13:05:20 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 674C73A6842 for ; Sun, 23 Jan 2011 13:05:18 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 3E2D7C09E82; Sun, 23 Jan 2011 23:08:10 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 272BCC09D45; Sun, 23 Jan 2011 23:08:10 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <4D3C7A8E.40403@go6.si>, , <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C8CE6.9080007@go6.si> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: swmike@swm.pp.se Message-ID: Date: Sun, 23 Jan 2011 23:08:10 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 23:08:10, Serialize complete at 01/23/2011 23:08:10, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 23:08:10, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/23/2011 23:08:10 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 21:05:20 -0000 =20 -----v6ops-bounces@ietf.org wrote: ----- To: v6ops@ietf.org From: Mikael Abrahamsson=20 Sent by: v6ops-bounces@ietf.org Date: 01/23/2011 10:24PM Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops= -3gpp-eps-05 On Sun, 23 Jan 2011, Jan Zorz @ go6.si wrote: >=A0So, we have IPv6 APN and I go around the world. Some operators block >=A0IPv6 PDP, some are not able to do dual PDP context (for N900), at least >=A0one of them is charging for IPv6 content, others don't have a clue. I was told that v6 PDP is an extra license in (some) SGSN, I guess it might be the same in RNC. Dual PDP context is definitely an extra license in RNC. So this is going to be different experience all around the world depending on what each operator has chosen to implement. When we initially started looking into this we (IP guys) discovered that dual PDP context worked on the "new" GSM/EDGE network we were rolling out, it didn't work on the UMTS/HSPA network (when one established the second one, it just silently stopped forwarding traffic on both, didn't tear down any PDP), and our "old" GSM network didn't support it either (don't remember how it behaved). Much confusion before we figured out why it worked "sometimes" :P It's a nightmare to try to get this working properly globally, I can understand why Cameron wants to disable v6 for roaming. /* I understand that as well. However something tells me it would be easier= to deal with 100+ roaming partners that are interested to make sure that t= hey don't loose revenue, rather then explain a dozen or so millions of your= customers why a service you have just rolled out as commercial should make= you learn what is an APN and why IPv6 PDP should not be used in roaming. -- Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops= From cb.list6@gmail.com Sun Jan 23 13:57:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E733A69B2 for ; Sun, 23 Jan 2011 13:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 fIB-Xy-0T1iD for ; Sun, 23 Jan 2011 13:57:09 -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 B43153A69A3 for ; Sun, 23 Jan 2011 13:57:09 -0800 (PST) Received: by qyk34 with SMTP id 34so2238602qyk.10 for ; Sun, 23 Jan 2011 14:00: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 :content-transfer-encoding; bh=mocoT4BaW4scnUbnYohMKe5JkvSMQnKl/2oJYERyoAc=; b=KGOD7rtK23olKnOeOZMMhCrlH/8sVAJ+7sdIPhaqR2IMvqVXHn4gnSBoJio/LoE3ZY jVRJfBdMMAFh25Cr55wQAOu8yZdJxNfeeXgH6JgmsDIy5yV3PndfIimMGbInzNdcN+UF L/LRE8qLu9LTxJIppMLp40YpDYq9ljb/CYcIo= 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=OjUzdksLQHuw2rHnyYYnYQAU/71iKrS9XN4Pb7Ec8AHGnuE//r+3SFAuXEQKm/m8NF IAWorcvXeuaDw7osIrG8wnKS9JxLldaBErrzZIYHHHUsAsBxAqZbpSBs7hOiNWYSL5tR Py6SGzYwQ9VW5sChPboMLn4yHu+d9E+kCRxzw= MIME-Version: 1.0 Received: by 10.229.91.145 with SMTP id n17mr3100531qcm.258.1295820001305; Sun, 23 Jan 2011 14:00:01 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sun, 23 Jan 2011 14:00:01 -0800 (PST) In-Reply-To: References: <4D3C7A8E.40403@go6.si> <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C8CE6.9080007@go6.si> Date: Sun, 23 Jan 2011 14:00:01 -0800 Message-ID: From: Cameron Byrne To: Roman.Arcea@orange.md Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 21:57:12 -0000 On Sun, Jan 23, 2011 at 1:08 PM, wrote: > > > > > -----v6ops-bounces@ietf.org wrote: ----- > To: v6ops@ietf.org > From: Mikael Abrahamsson > Sent by: v6ops-bounces@ietf.org > Date: 01/23/2011 10:24PM > Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6o= ps-3gpp-eps-05 > > On Sun, 23 Jan 2011, Jan Zorz @ go6.si wrote: > >>=A0So, we have IPv6 APN and I go around the world. Some operators block >>=A0IPv6 PDP, some are not able to do dual PDP context (for N900), at leas= t >>=A0one of them is charging for IPv6 content, others don't have a clue. > > I was told that v6 PDP is an extra license in (some) SGSN, I guess it > might be the same in RNC. Dual PDP context is definitely an extra license > in RNC. > > So this is going to be different experience all around the world dependin= g > on what each operator has chosen to implement. > > When we initially started looking into this we (IP guys) discovered that > dual PDP context worked on the "new" GSM/EDGE network we were rolling out= , > it didn't work on the UMTS/HSPA network (when one established the second > one, it just silently stopped forwarding traffic on both, didn't tear dow= n > any PDP), and our "old" GSM network didn't support it either (don't > remember how it behaved). > > Much confusion before we figured out why it worked "sometimes" :P > > It's a nightmare to try to get this working properly globally, I can > understand why Cameron wants to disable v6 for roaming. > > /* I understand that as well. However something tells me it would be easi= er to deal with 100+ roaming partners that are interested to make sure that= they don't loose revenue, rather then explain a dozen or so millions of yo= ur customers why a service you have just rolled out as commercial should ma= ke you learn what is an APN and why IPv6 PDP should not be used in roaming. > The expectation is that the handset has the logic to try IPv4 after IPv6 has failed. This should not be something the user has to deal with, the logic is pre-programmed in the handset. I believe Nokia has this working today (Teemu?). My goal is that the users do not know about ipv4 or ipv6, the service just works. If i cannot bill over IPv6, the service is not working and it must be rejected so that a working and billable ipv4 session can be created. Regarding GSMA, yes they are the right group. I am not involved in GSMA, at this point to launch IPv6 we have to engineer around them and the policies that are in place. Regarding SGSN functions, it is the home network that must be responsible for the end to end billing scheme and is hosting the ipv6 apn, so the home network must be able to signal if IPv6 across the roaming network is workable with a PDP reject if it is not workable. The visited SGSN cannot have this end to end logic. The feature can be implemented easily in PCRF or perhaps with some GGSN non-standard logic. Cameron > -- > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Roman.Arcea@orange.md Sun Jan 23 14:47:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766D73A69B8 for ; Sun, 23 Jan 2011 14:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 fuc5kRFD3n1E for ; Sun, 23 Jan 2011 14:47:28 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 5F8F73A69BB for ; Sun, 23 Jan 2011 14:47:28 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 80C3CC0A1DF; Mon, 24 Jan 2011 00:50:13 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 405DEC0A1D8; Mon, 24 Jan 2011 00:50:13 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <4D3C7A8E.40403@go6.si> <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C8CE6.9080007@go6.si> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: cb.list6@gmail.com Message-ID: Date: Mon, 24 Jan 2011 00:50:13 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/24/2011 00:50:13, Serialize complete at 01/24/2011 00:50:13, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/24/2011 00:50:13, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/24/2011 00:50:13 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 22:47:30 -0000 =20 -----Cameron Byrne wrote: ----- To: Roman.Arcea@orange.md From: Cameron Byrne Date: 01/24/2011 12:00AM Cc: swmike@swm.pp.se, v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops= -3gpp-eps-05 On Sun, Jan 23, 2011 at 1:08 PM, =A0 wrote: > > > > >=A0-----v6ops-bounces@ietf.org wrote: ----- >=A0To: v6ops@ietf.org >=A0From: Mikael Abrahamsson >=A0Sent by: v6ops-bounces@ietf.org >=A0Date: 01/23/2011 10:24PM >=A0Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v= 6ops-3gpp-eps-05 > >=A0On Sun, 23 Jan 2011, Jan Zorz @ go6.si wrote: > >>=A0So, we have IPv6 APN and I go around the world. Some operators block >>=A0IPv6 PDP, some are not able to do dual PDP context (for N900), at least >>=A0one of them is charging for IPv6 content, others don't have a clue. > >=A0I was told that v6 PDP is an extra license in (some) SGSN, I guess it >=A0might be the same in RNC. Dual PDP context is definitely an extra licen= se >=A0in RNC. > >=A0So this is going to be different experience all around the world depend= ing >=A0on what each operator has chosen to implement. > >=A0When we initially started looking into this we (IP guys) discovered that >=A0dual PDP context worked on the "new" GSM/EDGE network we were rolling o= ut, >=A0it didn't work on the UMTS/HSPA network (when one established the second >=A0one, it just silently stopped forwarding traffic on both, didn't tear d= own >=A0any PDP), and our "old" GSM network didn't support it either (don't >=A0remember how it behaved). > >=A0Much confusion before we figured out why it worked "sometimes" :P > >=A0It's a nightmare to try to get this working properly globally, I can >=A0understand why Cameron wants to disable v6 for roaming. > >=A0/* I understand that as well. However something tells me it would be ea= sier to deal with 100+ roaming partners that are interested to make sure th= at they don't loose revenue, rather then explain a dozen or so millions of = your customers why a service you have just rolled out as commercial should = make you learn what is an APN and why IPv6 PDP should not be used in roamin= g. > The expectation is that the handset has the logic to try IPv4 after IPv6 has failed. =A0This should not be something the user has to deal with, the logic is pre-programmed in the handset. =A0I believe Nokia has this working today (Teemu?). =A0My goal is that the users do not know about ipv4 or ipv6, the service just works. =A0If i cannot bill over IPv6, the service is not working and it must be rejected so that a working and billable ipv4 session can be created. /// The discussion is forked at this point. The blocking issue we have disc= ussed is related to the current state of things? And the fact that a servic= e provider must be blocking IPv6 PDP for various reasons, with the major on= e being the billing. The fallback mechanisms described are related to R8 and above. The issue is= that as long as your GGSN/P-GW is R8, and on my side I have a lower releas= e, from my understanding there is currently no way SGSN can signal you a fa= llback request as long as I have denied IPv6 PDPs on my network. The resul= t will be an unhappy customer of yours, and lost revenue for both of us. Am= I missing something? I am not sure either this applies to the current draft and should be placed= anywhere, however as long as the draft has a very general overview of curr= ent operational aspects of running an IPv6 only PDP, it might make sense to= have a look at those "commercially deployed networks by the end of 2010 is= nearly non-existent." feedbacks and add the billing issues and free servic= e, along with issues such as lack of business and commercial incentives. Otherwise I am ok with what and how the draft describes things. Regarding GSMA, yes they are the right group. =A0I am not involved in GSMA, at this point to launch IPv6 we have to engineer around them and the policies that are in place. ///Jouni, same here. I understand no action will be triggered as the result= of this draft, however as long as you have decided to go above a pure desc= ription of current state of 3GPP and touched on Operational Aspects, I woul= d say it is a little misleading. To me it looks like the major issue with s= ay roaming today as per this draft is the lack of formal agreements and the= possibility of some operators dropping unnecessarily IPv6 user traffic. Ho= wever, as per today discussion it does not really look like this are the on= ly issues. Regarding SGSN functions, it is the home network that must be responsible for the end to end billing scheme and is hosting the ipv6 apn, so the =A0home network must be able to signal if IPv6 across the roaming network is workable with a PDP reject if it is not workable. The visited SGSN cannot have this end to end logic. =A0The feature can be implemented easily in PCRF or perhaps with some GGSN non-standard logic. ///Agreed. It will take a lot of time until everyone has the logic build in= the core. The question is what do we to till then? Roman Cameron >=A0-- >=A0Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se >=A0=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >=A0v6ops mailing list >=A0v6ops@ietf.org >=A0https://www.ietf.org/mailman/listinfo/v6ops >=A0=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >=A0v6ops mailing list >=A0v6ops@ietf.org >=A0https://www.ietf.org/mailman/listinfo/v6ops >= From jouni.nospam@gmail.com Sun Jan 23 14:52:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E703A69B9 for ; Sun, 23 Jan 2011 14:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqPRinRjxwQ2 for ; Sun, 23 Jan 2011 14:52:55 -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 C510C3A69B8 for ; Sun, 23 Jan 2011 14:52:54 -0800 (PST) Received: by fxm9 with SMTP id 9so3776799fxm.31 for ; Sun, 23 Jan 2011 14:55:47 -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=NgZeQcpCPsktrp+SvISGlRWjS6C8evvSOxVwGCyyp+c=; b=C7klJqZRWVYYEyv1/KplhgNAU/rYVbpt4wAPLOS9zOnWC9NoyIWQH+m/Zn9MKKfEX6 873X3cbcsbwtMZ6fEQnxD8IQSHioHYPgDCkfUfrprS0W2kW1BLNGhOqpa8Ju7NLAT8xx ImsK4MY6bG+B2FUs9QJIHp2wtG9v1d8Ftr0LM= 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=KpURETe9JG6BuqX5fM+gzskW3Hh7RLd3rvBOUWKy4m4CdHTJTH3i6/xp7Z7tjUqSYr w3oDTWjnUq6o3o13SdMNLEzwgRZBfzHr4cf8Gmz71/5VWr23ExVDcrNgpuK7X1uppOXC l7qxCuJfQ8KfAMaIE43RcLx9NFDBnf2subK8g= Received: by 10.223.71.199 with SMTP id i7mr3562203faj.57.1295823347004; Sun, 23 Jan 2011 14:55:47 -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 j12sm231626fax.9.2011.01.23.14.55.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Jan 2011 14:55:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 24 Jan 2011 00:55:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1078) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 22:52:56 -0000 Hi, On Jan 22, 2011, at 7:58 AM, Cameron Byrne wrote: > " If the > visited network to which outbound roamers attach to does not > support PDP/PDN Type IPv6, then there needs to be a fallback > option." >=20 > This is also relevant to v4v6 since v4v6 is much newer and thus much > less widely deployed than IPv6 PDP. >=20 One point on IPv4v6 being unknown/unsupported. A pre-rel-8 SGSN does not = recognize the PDP Type IPv4v6 and therefore should default to IPv4 = (unknown PDP Types _should_ be interpreted as IPv4). PDP Type IPv6 = _should_ always be known and not processed by the "unknown PDP Type = value handling code" ('_should_' as the reality has been different). So, would the behavior be illformed if PDP Type IPv6 gets rejected by = SGSN instead of being changed to IPv4 e.g. because of IPv6 being a = licensable feature?? - JOuni=20 From joelja@bogus.com Sun Jan 23 20:53:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB4D3A6A49 for ; Sun, 23 Jan 2011 20:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 qgpPEadgvRSE for ; Sun, 23 Jan 2011 20:53:23 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id CDBCA3A6A44 for ; Sun, 23 Jan 2011 20:53:22 -0800 (PST) Received: from localhost (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0O4u75I080180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jan 2011 04:56:09 GMT (envelope-from joelja@bogus.com) Date: Sun, 23 Jan 2011 20:56:08 -0800 Message-ID: From: Joel Jaeggli To: "Jan Zorz @ go6.si" , Cameron Byrne MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 04:53:25 -0000 VGhpcyBpcyB0b25ndWUgYW5kIGNoZWVrLCBhbmQsIGxpa2UgbW9zdCBpZXRmIGNvbnRyaWJ1dGlv bnMgaXMgbWUgYXMgYW4gaW5kaXZpZHVhbC4KClRoZSBpcm9ueSB0aGF0IHNvbWVvbmUgaXMgbGVh dmluZyBtb25leSBvbiB0aGUgdGFibGUgaW4gdGhlIGNvbnRleHQgb2YgYW4gaXB2NiBkZXBsb3lt ZW50IHNob3VsZCBiZSBsb3N0IG9uIG5vLW9uZS4gIElmIHRoZXJlJ3Mgb24gdGhlIHRoYXQgbW9i aWxlIG9wZXJhdG9ycyBrbm93IGhvdyB0byBkbyBpdCdzIGJpbGwgZm9yIHN0dWZmLCBzbyBzZW5k IHRoZSBsYXl3ZXJzIG9mZiB0byBuZWdvdGlhdGUgc29tZSBubmkncy4gCgpPbiB0aGUgZHVhbCBs aWNlbnNlIGZyb250IHRoYXQgc291bmRzIGxpa2UgYW4gb3Bwb3J0dW5pdHkgZm9yIGEgZGlzY291 bnQuIAoKSSd2ZSBub3QgYmVlbiBiaWxsZWQgZm9yIGlwdjQgcm9hbWluZyBiZWZvcmUgaW4gZmFj dCBiYWNrIGF0IHRoZSBiZWdpbm5pbmcgaXQgaGFwcGVuZWQgd2l0aCBzb21lIGRlZ3JlZSBvZiBm cmVxdWVuY3ksIEkgZG91YnQgdGhhdCB0aGUgY2FycmllcnMgaW52b2x2ZWQgc2VyaW91c2x5IGlt cGFjdGVkIHRoZWlyIGxvbmcgdGVybSBwcm9maXRhYmlsaXR5IGJ5IGFjY2lkZW50bHkgcHJvdmlk aW5nIGRlY2VudCBzZXJ2aWNlLgoKIkphbiBab3J6IEAgZ282LnNpIiA8amFuQGdvNi5zaT4gd3Jv dGU6Cgo+T24gMS8yMy8xMSA4OjI3IFBNLCBDYW1lcm9uIEJ5cm5lIHdyb3RlOgo+PiBKYW4sCj4+ ID09PT09PT09PT0KPj4gIkkgYWdyZWUgdGhhdCBiaWxsaW5nIG5lZWRzIHRvIGJlIGZpeGVkIChh bmQgaGVyZSBnb2VzIGF3YXkgbXkgZnJlZQo+PiBtb2JpbGUgY29tbXVuaWNhdGlvbiksIGJ1dCB0 aGlzIGNhbid0IGJlIGJhc2lzIGZvciByZWZ1c2luZyBJUHY2IFBEUAo+PiBjb250ZXh0IGluIHJv YW1pbmcgbW9kZS4gSWYgeW91IGNhbid0IGNoYXJnZSBpdCwgdGhlbiBpdCdzIGZyZWUuIElmIHlv dQo+PiBjYW4gb3Igd2FudCB0byBjaGFyZ2UgaXQsIGNoYXJnZSBpdC4gQnV0IHBsZWFzZSBkb24n dCBzdWdnZXN0IHBlb3BsZSB0bwo+PiBkcm9wIFBEUCBjb250ZXh0cy4iCj4+ID09PT09PT09PT0K Pj4KPj4gU29ycnksIHRoZSBidXNpbmVzcyBmb2xrcyBiZWxpZXZlIG90aGVyd2lzZS4gIE5vIGZy ZWUgcmlkZXMuICBUaGUgb25seQo+PiByZWFzb24gaXQgaXMgZnJlZSBmb3IgeW91IHRvZGF5IGlz IHRoYXQgdGhlIG1vYmlsZSBwcm92aWRlcnMgZG9uJ3QKPj4ga25vdyB3aGF0IGkgaGFwcGVuaW5n Lgo+Pgo+PiBUb2RheSwgb3VyIGJldGEgSVB2NiBBUE4gaXMgbm90IGFubm91bmNlZCB0byByb2Ft ZXJzIGF0IGFsbC4KPgo+QmV0YSBBUE5zIG9mIG91ciBtb2JpbGUgb3BlcmF0b3JzIChwdWJsaWMg cGlsb3QgdGVzdGluZyBmb3IgdXNlcnMpIGFyZSAKPmFubm9uY2VkIHRvIHJvYW1lcnMuIFdoeSBu b3Q/IElmIGZvcmVpZ24gb3BlcmF0b3Igc2VuZHMgYSBiaWxsLCBpdCBnZXRzIAo+Y2hhcmdlZCB0 byBjdXN0b21lci4gT3RoZXJ3aXNlIG5vdCA6KQo+Cj4+Cj4+IEFzIHdlIGdvIHRvIHByb2R1Y3Rp b24sIHdlIHdpbGwgYmUgcmVqZWN0aW5nIElQdjYgUERQIGZyb20gcm9hbWluZwo+PiBwYXJ0bmVy cyB0aGF0IGhhdmUgbm90IGV4cGxpY2l0bHkgdXBkYXRlZCB0aGUgcm9hbWluZyBhZ3JlZW1lbnRz IHRvCj4+IGluY2x1ZGUgSVB2Niwgd2hpY2ggdmFsaWRhdGVzIHRoYXQgdGhlIGVuZCB0byBlbmQg YmlsbGluZyBwcm9jZXNzIHdpbGwKPj4gd29yayBjb3JyZWN0bHkuCj4KPlRoaXMgbWlnaHQgc2V2 ZXJseSBzcGVlZC11cCB0aGUgcHJvY2VzcyBvZiBmaXhpbmcgdGhlIGJpbGxpbmcgc2NoZW1hIAo+ YXJvdW5kIHRoZSB3b3JsZC4KPgo+L2phbgo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+djZvcHMgbWFpbGluZyBsaXN0Cj52Nm9wc0BpZXRmLm9yZwo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcwo+Cg== From cb.list6@gmail.com Sun Jan 23 21:30:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8D03A6A50 for ; Sun, 23 Jan 2011 21:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_12=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 X7PuzSPGf3oT for ; Sun, 23 Jan 2011 21:30:47 -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 3A8013A6A51 for ; Sun, 23 Jan 2011 21:30:47 -0800 (PST) Received: by qyj19 with SMTP id 19so3803730qyj.10 for ; Sun, 23 Jan 2011 21:33:40 -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 :content-transfer-encoding; bh=TY//gg20hTRc5VMCPTRqT0FEuoPxAnG4dPNmOmtETlY=; b=viYNeOMV6EI0LmaeG3RG++y1FnXfXBBjt10S7nXAMCgBVyZceiGFOpKg3/eEjicTQ3 ajui4jK0tQLU8e2fnGgkA63mBIcqczvSm0k2Qtnd/DngIJk8e/PD4KCkdThJG2ZflIm6 f9Hj6k86Et7bUr/SC4ZM1CadeaQ+AqFwlrmVc= 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=n3nvfqjd33cNZ0GYBa9c9Y2OEIURixirsjDDIoVPo7AxAZGOf+UvOvEudvkJVGKAFV XErexepkFcLJD7eaxgVbxG4NlCnjeFtHbCLZe7kDsmMLSE3ea11kD7rDJaNCZUrRGlaK 3CdpZJqbHnSxAmTIi/6ktmmKodSfInYM3B/YE= MIME-Version: 1.0 Received: by 10.229.227.8 with SMTP id iy8mr3430949qcb.182.1295847220498; Sun, 23 Jan 2011 21:33:40 -0800 (PST) Received: by 10.229.224.79 with HTTP; Sun, 23 Jan 2011 21:33:40 -0800 (PST) In-Reply-To: References: Date: Sun, 23 Jan 2011 21:33:40 -0800 Message-ID: From: Cameron Byrne To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, "Jan Zorz @ go6.si" Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 05:30:48 -0000 On Sun, Jan 23, 2011 at 8:56 PM, Joel Jaeggli wrote: > This is tongue and cheek, and, like most ietf contributions is me as an i= ndividual. > > The irony that someone is leaving money on the table in the context of an= ipv6 deployment should be lost on no-one. =A0If there's on the that mobile= operators know how to do it's bill for stuff, so send the laywers off to n= egotiate some nni's. > Lawyers cost money. IPv6 does not make money over IPv4. Just like always, there is no business case for ipv6. And i'ts not just lawyers and NNIs, there are massive billing systems that process billions of CDRs a day, changing them to read a 128 bit field instead of a 32 bit field is not easy. Like many things, it may seem easy from a distance. > On the dual license front that sounds like an opportunity for a discount. > Once again, no revenue, no business case, no effort. Furthermore, with roaming, how do i get the SGSNs in South Africa and Columbia and Taiwan to all play nice in the same way at the same time? I can't. Therefore i believe the fallback mechanism is critical. People say there will be no flag day for the Internet, well ... no flag day for mobile roaming either. > I've not been billed for ipv4 roaming before in fact back at the beginnin= g it happened with some degree of frequency, I doubt that the carriers invo= lved seriously impacted their long term profitability by accidently providi= ng decent service. > Data roaming is real money. When it does not bill correctly, it is called "revenue leakage" and it gets the business folks worked up quick, and the business folks will sink any well intentioned IPv6 efforts if they think money will be lost (see AAAA white-listing ...). I would love to provide Jan free IPv6 service, but what i would like to do more is make IPv6 a prime time production service that can take the place of IPv4. To get there, some mobile roaming fallback mechanism will be required. You are right, the revenue leakage on a few beta APNs is nothing today. But, i plan on selling v6 handsets in stores soon. Power it on and go, the customer does not know or care about ipv6. When 500,000 of these phones are live by the end of the year, that is not trivial revenue leakage. And if that number goes to 5 million by the end of 2012... Cameron > "Jan Zorz @ go6.si" wrote: > >>On 1/23/11 8:27 PM, Cameron Byrne wrote: >>> Jan, >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> "I agree that billing needs to be fixed (and here goes away my free >>> mobile communication), but this can't be basis for refusing IPv6 PDP >>> context in roaming mode. If you can't charge it, then it's free. If you >>> can or want to charge it, charge it. But please don't suggest people to >>> drop PDP contexts." >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Sorry, the business folks believe otherwise. =A0No free rides. =A0The o= nly >>> reason it is free for you today is that the mobile providers don't >>> know what i happening. >>> >>> Today, our beta IPv6 APN is not announced to roamers at all. >> >>Beta APNs of our mobile operators (public pilot testing for users) are >>annonced to roamers. Why not? If foreign operator sends a bill, it gets >>charged to customer. Otherwise not :) >> >>> >>> As we go to production, we will be rejecting IPv6 PDP from roaming >>> partners that have not explicitly updated the roaming agreements to >>> include IPv6, which validates that the end to end billing process will >>> work correctly. >> >>This might severly speed-up the process of fixing the billing schema >>around the world. >> >>/jan >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops >> > From ek@google.com Sun Jan 23 21:52:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0591F3A6A59 for ; Sun, 23 Jan 2011 21:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.483 X-Spam-Level: X-Spam-Status: No, score=-105.483 tagged_above=-999 required=5 tests=[AWL=-2.506, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 rB8WmKxLQHDX for ; Sun, 23 Jan 2011 21:52:49 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 840BA3A6A6D for ; Sun, 23 Jan 2011 21:52:49 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p0O5tgtq009859 for ; Sun, 23 Jan 2011 21:55:42 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295848542; bh=QIgytQyrqdrD7kYfpioQ+1rLQeo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=UhiTQZQonaonIt5U3hl5A1AZI/oJ5E4We+H4D6bfCkSn5OFaaFZv+Jt3+G588aIgY eWfGaJ9v/ZD8M7UHArXIQ== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by hpaq1.eem.corp.google.com with ESMTP id p0O5te6G030411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 23 Jan 2011 21:55:41 -0800 Received: by qwe5 with SMTP id 5so3959188qwe.26 for ; Sun, 23 Jan 2011 21:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m8y2/tY3GfrVHJE342paRqddvAIk5hfkH+kjb9aSXeA=; b=UGKMYGRr3rmhP4PsNhjSMI/DzBsu+iUW/YB57Dvb2sDFw2PPuVbWpoQc1Y5dpD7UxA BMUHUJIazIUQwOPpuzzA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sgVeoUt8U+/9UOFvFI2tb8utr4RB/Ofk23/0UcN0WFcmte58RvHrFv2Tz9B8fqiX1R FfqTr/Q558Q9Ku3yxpJA== MIME-Version: 1.0 Received: by 10.229.182.79 with SMTP id cb15mr3409038qcb.219.1295848540230; Sun, 23 Jan 2011 21:55:40 -0800 (PST) Received: by 10.229.106.201 with HTTP; Sun, 23 Jan 2011 21:55:40 -0800 (PST) In-Reply-To: References: Date: Mon, 24 Jan 2011 14:55:40 +0900 Message-ID: From: Erik Kline To: Cameron Byrne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: v6ops@ietf.org, "Jan Zorz @ go6.si" Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 05:52:51 -0000 > Once again, no revenue, no business case, no effort. =C2=A0Furthermore, > with roaming, how do i get the SGSNs in South Africa and Columbia and > Taiwan to all play nice in the same way at the same time? =C2=A0I can't. > Therefore i believe the fallback mechanism is critical. =C2=A0People say > there will be no flag day for the Internet, well ... no flag day for > mobile roaming either. In the abstract... When I think about IPv6 transition things, I think one of the big lessons I'm learning is that controlled, incremental, unilateral deployment has to be possible. There have perhaps been too many scenarios that require either global or "near global" coordinated action. Anything that enables Internet players (access, content, mobile, ...) to deploy IPv6 in a controlled manner, without requiring simultaneous efforts from external entities is essential. Perhaps "it" has high operational cognitive load, or creates more transition work for folks using "it", or temporarily creates fractured IPv6 support. But if the end result is that IPv6 gets rolled out with the extra overhead of having to remove the transition hack, then that's a heck of a lot better than the outcome of the previous 15 years. I don't know what this means in terms of 3GPP architecture, but I suspect I'm agreeing with Cameron (at least in spirit since I don't pretend of have full grasp of 3GPP, despite having read this draft). From Roman.Arcea@orange.md Sun Jan 23 23:07:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D8628C0CF; Sun, 23 Jan 2011 23:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 nDOUeilxUFiC; Sun, 23 Jan 2011 23:07:50 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 19D673A6A81; Sun, 23 Jan 2011 23:07:49 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 9A4FEC0A26D; Mon, 24 Jan 2011 09:10:35 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 79154C09D7E; Mon, 24 Jan 2011 09:10:35 +0200 (EET) In-Reply-To: References: To: Erik Kline MIME-Version: 1.0 X-KeepSent: 2422C503:9D5B0A3B-C2257822:002670BC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Mon, 24 Jan 2011 09:10:35 +0200 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 01/24/2011 09:10:35, Serialize complete at 01/24/2011 09:10:35 Content-Type: multipart/alternative; boundary="=_alternative 00276BDFC2257822_=" Cc: v6ops@ietf.org, v6ops-bounces@ietf.org, "Jan Zorz @ go6.si" Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 07:07:52 -0000 This is a multipart message in MIME format. --=_alternative 00276BDFC2257822_= Content-Type: text/plain; charset="US-ASCII" From: Erik Kline To: Cameron Byrne Cc: v6ops@ietf.org, "Jan Zorz @ go6.si" Date: 24-01-11 07:56 Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 Sent by: v6ops-bounces@ietf.org > Once again, no revenue, no business case, no effort. Furthermore, > with roaming, how do i get the SGSNs in South Africa and Columbia and > Taiwan to all play nice in the same way at the same time? I can't. > Therefore i believe the fallback mechanism is critical. People say > there will be no flag day for the Internet, well ... no flag day for > mobile roaming either. In the abstract... When I think about IPv6 transition things, I think one of the big lessons I'm learning is that controlled, incremental, unilateral deployment has to be possible. There have perhaps been too many scenarios that require either global or "near global" coordinated action. /// True. This does apply to most of the situations. If we had to coordinate anything we made with at least one other operator, neither of us talking here will probably have ever achieved any IPv6 deployment. Anything that enables Internet players (access, content, mobile, ...) to deploy IPv6 in a controlled manner, without requiring simultaneous efforts from external entities is essential. Perhaps "it" has high operational cognitive load, or creates more transition work for folks using "it", or temporarily creates fractured IPv6 support. But if the end result is that IPv6 gets rolled out with the extra overhead of having to remove the transition hack, then that's a heck of a lot better than the outcome of the previous 15 years. /// There is a big difference between a content provider and a mobile operator deployment. For instance you assume that 0.05% of your users might be broken (is it still the case? to what extent are they broken? are they simply slow?) if you announce AAAA worldwide. However you know for sure that if you don't, all the service will be flowing through IPv4. Now, imagine the following. Your operator has rolled out IPv6 service without telling you about that. As the average user you should not care. You go to, say, Japan, where they know there might be billing issues and have blocked the IPv6 PDP instead of looking into their billing issues. Most likely by that time (1-2 years) we will not be using the R8-R9 with dual stack worldwide, and even worse, older core network elements worldwide will still be on R5, R6 without any plans to go further. This folks do have knowledge of IPv6 PDP most likely, however have no idea about any fallback. Your handset does not have knowledge of fallback either. What happens is that you switch on your phone in Japan and see how it unsuccessfully struggles to connect to the data network and fails. There will most likely be no error message, and the only way you can correct things is by manually selecting an IPv4 APN. Now, this IS (not MAY be) broken service for 100% of customers. Best, Roman _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --=_alternative 00276BDFC2257822_= Content-Type: text/html; charset="US-ASCII"





From:        Erik Kline <ek@google.com>
To:        Cameron Byrne <cb.list6@gmail.com>
Cc:        v6ops@ietf.org, "Jan Zorz @ go6.si" <jan@go6.si>
Date:        24-01-11 07:56
Subject:        Re: [v6ops] Fwd: New Version Notification for        draft-korhonen-v6ops-3gpp-eps-05
Sent by:        v6ops-bounces@ietf.org


> Once again, no revenue, no business case, no effort.  Furthermore,
> with roaming, how do i get the SGSNs in South Africa and Columbia and
> Taiwan to all play nice in the same way at the same time?  I can't.
> Therefore i believe the fallback mechanism is critical.  People say
> there will be no flag day for the Internet, well ... no flag day for
> mobile roaming either.
In the abstract...
When I think about IPv6 transition things, I think one of the big
lessons I'm learning is that controlled, incremental, unilateral
deployment has to be possible.  There have perhaps been too many
scenarios that require either global or "near global" coordinated
action.

/// True. This does apply to most of the situations. If we had to coordinate anything we made with at least one other operator, neither of us talking here will probably have ever achieved any IPv6 deployment.
Anything that enables Internet players (access, content, mobile, ...)
to deploy IPv6 in a controlled manner, without requiring simultaneous
efforts from external entities is essential.  Perhaps "it" has high
operational cognitive load, or creates more transition work for folks
using "it", or temporarily creates fractured IPv6 support.  But if the
end result is that IPv6 gets rolled out with the extra overhead of
having to remove the transition hack, then that's a heck of a lot
better than the outcome of the previous 15 years.
/// There is a big difference between a content provider and a mobile operator deployment. For instance you assume that 0.05% of your users might be broken (is it still the case? to what extent are they broken? are they simply slow?) if you announce AAAA worldwide. However you know for sure that if you don't, all the service will be flowing through IPv4.
Now, imagine the following. Your operator has rolled out IPv6 service without telling you about that. As the average user you should not care. You go to, say, Japan, where they know there might be billing issues and have blocked the IPv6 PDP instead of looking into their billing issues. Most likely by that time (1-2 years) we will not be using the R8-R9 with dual stack worldwide, and even worse, older core network elements worldwide will still be on R5, R6 without any plans to go further. This folks do have knowledge of IPv6 PDP most likely, however have no idea about any fallback. Your handset does not have knowledge of fallback either.
What happens is that you switch on your phone in Japan and see how it unsuccessfully struggles to connect to the data network and fails. There will most likely be no error message, and the only way you can correct things is by manually selecting an IPv4 APN.
Now, this IS (not MAY be) broken service for 100% of customers.

Best,
Roman

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

--=_alternative 00276BDFC2257822_=-- From teemu.savolainen@nokia.com Mon Jan 24 01:58:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE44A3A681B for ; Mon, 24 Jan 2011 01:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.035 X-Spam-Level: X-Spam-Status: No, score=-4.035 tagged_above=-999 required=5 tests=[AWL=-0.436, 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 nBsdGT8Ng5km for ; Mon, 24 Jan 2011 01:58:49 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 008C43A67D2 for ; Mon, 24 Jan 2011 01:58:48 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0OA1Y6b019358; Mon, 24 Jan 2011 12:01:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 12:01:34 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 24 Jan 2011 11:01:33 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.27]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Mon, 24 Jan 2011 11:01:32 +0100 From: To: , Thread-Topic: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 Thread-Index: AQHLu0jwy7k8uORvWkO4j9Vay6+nvJPf4flg Date: Mon, 24 Jan 2011 10:01:31 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A319284880@008-AM1MPN1-015.mgdnok.nokia.com> References: <4D3C7A8E.40403@go6.si> <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <4D3C8CE6.9080007@go6.si> In-Reply-To: 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: 24 Jan 2011 10:01:34.0385 (UTC) FILETIME=[AEA31210:01CBBBAD] X-Nokia-AV: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 09:58:50 -0000 > The expectation is that the handset has the logic to try IPv4 after > IPv6 has failed. This should not be something the user has to deal > with, the logic is pre-programmed in the handset. I believe Nokia has > this working today (Teemu?). My goal is that the users do not know > about ipv4 or ipv6, the service just works. If i cannot bill over > IPv6, the service is not working and it must be rejected so that a > working and billable ipv4 session can be created. Right, you can configure that on Symbian.=20 Generally a 3GPP handset should try to do fallback to IPv4 PDP in case the = IPv6 (or IPv4v6) PDP requests result in (any kind of) failure. This failure= can, after all, be caused by visited SGSN not supporting IPv6 PDP type (ou= ght not to be very common, but I've understood such do exist). In the case of well working R8/R9 network the network can instruct handset = to do fallback from IPv4v6 PDP to parallel IPv4 & IPv6 PDPs or to IPv6-only= PDP or to IPv4-only PDP.=20 It would be quite silly functionality on a handset side to bother users abo= ut IPv6 PDP activation failures if the reasons are related these deployment= challenges and an IPv4 connection could be set up instead.=20 After all, there are really no IPv6-only services yet (and those who do pro= vide IPv6-only services also provide tunneling solutions e.g. for cases of = accessing via IPv4-only WLAN). If IPv6-only services were common the handset could maybe show users someth= ing like:"You have only limited internet connectivity":-) Best regards, Teemu From remi.despres@free.fr Mon Jan 24 06:02:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C313A6A7F for ; Mon, 24 Jan 2011 06:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 Vby5KFC7NiK6 for ; Mon, 24 Jan 2011 06:02:24 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by core3.amsl.com (Postfix) with ESMTP id E66573A68D5 for ; Mon, 24 Jan 2011 06:02:23 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id E59827000090; Mon, 24 Jan 2011 15:05:17 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 768387000082; Mon, 24 Jan 2011 15:05:17 +0100 (CET) X-SFR-UUID: 20110124140517485.768387000082@msfrf2417.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: <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> Date: Mon, 24 Jan 2011 15:05:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 14:02:25 -0000 Hi Jouni, As already said, I find this document extremely useful, and hope it can = proceed quickly. In the section on overlapping IPv4 addresses (8.1), I suggest to add a = small clarification. Its purpose is to remind the relationship that exists between = overlapping RFC 1918 IPv4 address spaces and the 6rd of RFC 5969. As you know, RFC 5969 permits a host to derive its native IPv6 prefix = from its assigned IPv4 address, INCLUDING if this address is RFC1918. This point, which is particularly relevant to the mobile environment = where RFC 1918 is already a reality, is unfortunately overlooked. For = example, the otherwise very good document of the NIST on Secure = Deployment of IPv6 states that, like 6to4, 6rd requires public IPv4 = addresses (!). (Ref.: = csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf, sec. 6.5.7, = 2nd sentence).=20 At the end of item 2 of your section 8.1, which says: "Operators with large subscriber bases have multiple gateways and hence = the same [RFC1918] IPv4 address space can be reused across gateways. The = IPv4 address assigned to a host is unique within the scope of a single = gateway." ONE COULD ADD, for example: "If an operator supports 6rd border relays of [RFC5969] in parallel with = its gateways, the host can derive from this [RFC1918] IPv4 address its = globally assigned IPv6 prefix. (Then, to traverse the local [RFC1918] = addressing area, IPv6 packets using this prefix are encapsulated in IPv4 = packets)." =20 First instances of UEs to benefit from this possibility could be PCs = equipped with with 3G dongles, with their 6to4 module extended to = support the RFC 5969 customer-edge function.=20 Next, as some mobile operators start supporting 6rd border relays, it = is likely that some PDPv4-capable mobile phones will also become = RFC-1918-capable (a simple stateless function). Best regards, RD =20 Le 21 janv. 2011 =E0 12:02, jouni korhonen a =E9crit : > Folks, >=20 > We have updated the I-D and tried to reflect the recent discussion in = the V6OPS list as well we could for the time being. Thanks to everybody = who provided constructive feedback. The attempt has been making the I-D = just a description of the existing architecture. I hope we can move I-D = forward rather soon as it has been around for quite some time already. = Additional comments and feedback are of course solicited. >=20 > - Jouni >=20 >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool >> Date: January 21, 2011 12:48:01 PM GMT+02:00 >> To: jouni.nospam@gmail.com >> Cc: = jonne.soininen@nsn.com,basavaraj.patil@nokia.com,teemu.savolainen@nokia.co= m,gabor.bajko@nokia.com,kaisu.iisakkila@renesasmobile.com >> Subject: New Version Notification for = draft-korhonen-v6ops-3gpp-eps-05=20 >>=20 >>=20 >> A new version of I-D, draft-korhonen-v6ops-3gpp-eps-05.txt has been = successfully submitted by Jouni Korhonen and posted to the IETF = repository. >>=20 >> Filename: draft-korhonen-v6ops-3gpp-eps >> Revision: 05 >> Title: IPv6 in 3GPP Evolved Packet System >> Creation_date: 2011-01-21 >> WG ID: Independent Submission >> Number_of_pages: 26 >>=20 >> Abstract: >> Internet connectivity and use of data services in 3GPP based mobile >> networks has increased rapidly as a result of smart phones, broadband >> service via HSPA and HSPA+ networks, competitive service offerings by >> operators and a large number of applications. Operators who have >> deployed networks based on 3GPP architectures are facing IPv4 address >> shortages. With the impending exhaustion of available IPv4 addresses >> from the registries there is an increased emphasis for operators to >> migrate to IPv6. This document describes the support for IPv6 in >> 3GPP network architectures. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon Jan 24 06:25:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543893A68E6; Mon, 24 Jan 2011 06:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.332, 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 0mf-inzwfWVC; Mon, 24 Jan 2011 06:25:18 -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 E17843A68ED; Mon, 24 Jan 2011 06:25:17 -0800 (PST) Received: by qyj19 with SMTP id 19so4282227qyj.10 for ; Mon, 24 Jan 2011 06:28: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=I9b742cbXThDBvGOfIn7tE8ifBxSNhvCJaW93jyvwSI=; b=JpdscgvhLQ3kEDBtR6KGBUjyVWuU1u9izdlO7aXboCouRYHYelUGO716xKHco6kGHr ZfR7gdtpb2ZLgihhUwosyzPZMCVbCEXHUfzC2Aka8DRnHTYsbj1ydKTrLTx05mgWTnsb KgEPdTquPpfpXQKbKfemM23qZ1Ms3cPLMwXqc= 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=k8HFjyHfUxidqyk5ptXx+/n/5uAx9cxGrs9gmW7CvQoOG1W0kWqnF+xIGWGkb39FLH Ar8mlRkOg1ecQdfozNLO1QyckzP7yrYgolHLzTK4pMAWAvQnq0wH5aA/P093Ir7btYQ7 SwU61p51pmTY7Cm+OaXk1HH+hy9FXfqjD0XsU= MIME-Version: 1.0 Received: by 10.229.96.83 with SMTP id g19mr3869919qcn.106.1295879292327; Mon, 24 Jan 2011 06:28:12 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 24 Jan 2011 06:28:12 -0800 (PST) In-Reply-To: <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> Date: Mon, 24 Jan 2011 06:28:12 -0800 Message-ID: From: Cameron Byrne To: Roman.Arcea@orange.md Content-Type: multipart/alternative; boundary=001636aa2b8ee41868049a986867 Cc: v6ops@ietf.org, "Jan Zorz @ go6.si" , v6ops-bounces@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 14:25:19 -0000 --001636aa2b8ee41868049a986867 Content-Type: text/plain; charset=ISO-8859-1 On Jan 23, 2011 11:10 PM, wrote: > > > Now, imagine the following. Your operator has rolled out IPv6 service without telling you about that. As the average user you should not care. You go to, say, Japan, where they know there might be billing issues and have blocked the IPv6 PDP instead of looking into their billing issues. Most likely by that time (1-2 years) we will not be using the R8-R9 with dual stack worldwide, and even worse, older core network elements worldwide will still be on R5, R6 without any plans to go further. This folks do have knowledge of IPv6 PDP most likely, however have no idea about any fallback. Your handset does not have knowledge of fallback either. > What happens is that you switch on your phone in Japan and see how it unsuccessfully struggles to connect to the data network and fails. There will most likely be no error message, and the only way you can correct things is by manually selecting an IPv4 APN. > Now, this IS (not MAY be) broken service for 100% of customers. Nobody would agree to be breaking roaming. Roman, the solution I have proposed always provides access to the user since there is logic in the handset to fall back to ipv4 regardless if the home network rejects based on policy or visited network rejects based on features. I will not roll out features or services that fail as you have described or features that are not billed. Both the "service" MUST work in roaming and MUST be billed. The solution I have proposed does both in all situations using existing 3GPP functions by attempting IPv6 PDP first and fallback to IPv4 on failure. If we cannot do this, it is a road block to deployment where no IPv6 gets deployed until 100s of roaming partners contractually agree to support and bill IPv6.... which will take 5+ years. That is why I want this solution that uses existing 3GPP methods with logic on the handset to be documented here in this draft. In summary of this thread. 1. This draft is good and can benefit from adding a fall back section with the method i have described. As the thread has proven, roaming is broken and operators are at various stages of awareness to this issue. 2. GSMA is the right place to fix roaming, not the IETF or 3GPP. But, the GSMA is slow and we must engineer around them in a way that does not close doors on v6 roaming eventually working. 3. The service to the user, regardless of v4 or v6, must always work and be billed. Neither the operator or user care if the service is v4 or v6 or v4v6, facebook and google must work. I have proposed a solution that works in light of the various constraints of home network policy, visited network features, and providing a path for IPv6 roaming to work when permitted by both the home and visited network. cameron --001636aa2b8ee41868049a986867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 23, 2011 11:10 PM, <Roman.Arcea@orange.md> wrote:
>

>

> Now, imagine the following. Your operator has rolled out IPv6 service = without telling you about that. As the average user you should not care. Yo= u go to, say, Japan, where they know there might be billing issues and have= blocked the IPv6 PDP instead of looking into their billing issues. Most li= kely by that time (1-2 years) we will not be using the R8-R9 with dual stac= k worldwide, and even worse, older core network elements worldwide will sti= ll be on R5, R6 without any plans to go further. This folks do have knowled= ge of IPv6 PDP most likely, however have no idea about any fallback. Your h= andset does not have knowledge of fallback either.
> What happens is that you switch on your phone in Japan and see how it = unsuccessfully struggles to connect to the data network and fails. There wi= ll most likely be no error message, and the only way you can correct things= is by manually selecting an IPv4 APN.
> Now, this IS (not MAY be) broken service for 100% of customers.

Nobody would agree to be breaking roaming. =A0

Roman, t= he solution I have proposed always provides access to the user since there = is logic in the handset to fall back to ipv4 regardless if the home network= rejects based on policy or visited network rejects based on features.=A0 I= will not roll out features or services that fail as you have described or = features that are not billed. Both the "service" MUST work in roa= ming and MUST be billed.=A0 The solution I have proposed does both in all s= ituations using existing 3GPP functions by attempting IPv6 PDP first and fa= llback to IPv4 on failure. =A0If we cannot do this, it is a road block to d= eployment where no IPv6 gets deployed until 100s of roaming partners contra= ctually agree to support and bill IPv6.... which will take 5+ years.

That is why I want this solution that uses existing 3GPP methods with lo= gic on the handset to be documented here in this draft.

In summar= y of this thread.

1. =A0This draft is good and can benefit from addin= g a fall back section with the method i have described. =A0As the thread ha= s proven, roaming is broken and operators are at various stages of awarenes= s to this issue.


2. =A0GSMA is the right place to fix roaming, not the IETF or= 3GPP. But, the GSMA is slow and we must engineer around them in a way that= does not close doors on v6 roaming eventually working.


3. =A0The service to the user, regardless of v4 or v6, must always work and= be billed. =A0Neither the operator or user care if the service is v4 or v6= or v4v6, facebook and google must work. =A0I have proposed a solution that= works in light of the various constraints of home network policy,=A0visite= d=A0network features, and providing a path for IPv6 roaming to work when pe= rmitted by both the home and=A0visited=A0network.


cameron


--001636aa2b8ee41868049a986867-- From jbates@brightok.net Mon Jan 24 06:47:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EBE3A68F1 for ; Mon, 24 Jan 2011 06:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6] 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 6PJcHsVrSd1N for ; Mon, 24 Jan 2011 06:47:34 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id C28E43A68E6 for ; Mon, 24 Jan 2011 06:47:34 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0OEo7F7007271; Mon, 24 Jan 2011 08:50:08 -0600 (CST) Message-ID: <4D3D919F.7050003@brightok.net> Date: Mon, 24 Jan 2011 08:50:07 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Yourtchenko References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 14:47:35 -0000 On 1/23/2011 3:57 AM, Andrew Yourtchenko wrote: > This case only shows that by doing the parallel threads of DNS+connect > within the address family we avoid that sort of nastiness for free. > > The reason it came to my mind because I was helping to fix the box in > the middle that was dropping the AAAAs. > I've contacted three companies who used broken load balancers that returned nxdomain on AAAA but a response for A (ie, when AAAA nxdomained the resolver didn't ask for A). All companies fixed the problem in a reasonable time. I agree and understand connect() reachability and performance. I disagree with circumventing buggy DNS that needs to be fixed. Jack From jeroen@unfix.org Mon Jan 24 07:00:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDE23A68E9 for ; Mon, 24 Jan 2011 07:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 krhV8zNsxILC for ; Mon, 24 Jan 2011 07:00:58 -0800 (PST) Received: from abaddon.unfix.org (abaddon.unfix.org [62.220.146.203]) by core3.amsl.com (Postfix) with ESMTP id DFA8C3A68E6 for ; Mon, 24 Jan 2011 07:00:57 -0800 (PST) Received: from [IPv6:2001:41e0:ff42:99:222:cfff:fe31:ce41] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:99:222:cfff:fe31:ce41]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id ED81721472; Mon, 24 Jan 2011 16:03:28 +0100 (CET) Message-ID: <4D3D94C1.7080502@unfix.org> Date: Mon, 24 Jan 2011 16:03:29 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Bates References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> <4D3D919F.7050003@brightok.net> In-Reply-To: <4D3D919F.7050003@brightok.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:00:58 -0000 On 2011-01-24 15:50, Jack Bates wrote: > > > On 1/23/2011 3:57 AM, Andrew Yourtchenko wrote: >> This case only shows that by doing the parallel threads of DNS+connect >> within the address family we avoid that sort of nastiness for free. >> >> The reason it came to my mind because I was helping to fix the box in >> the middle that was dropping the AAAAs. >> > > I've contacted three companies who used broken load balancers that > returned nxdomain on AAAA but a response for A (ie, when AAAA nxdomained > the resolver didn't ask for A). All companies fixed the problem in a > reasonable time. > > I agree and understand connect() reachability and performance. I > disagree with circumventing buggy DNS that needs to be fixed. That is because you are talking about three companies (the bbc was once also one of them btw ;) People on this list are talking about thousands upon thousands of CPE devices which have the same annoying behavior of just dropping AAAA records to the floor and then you get a time out and then the user thinks it is all broken. One good thing about that problem is that it occurs the moment one IPv6-enables a host, it does not happen because one introduces AAAA records for a host into DNS. As such, except for broken connectivity this whole "World IPv6 day" experiment will not going to break too much unless a lot of people suddenly start enabling IPv6 stacks on their hosts because then the broken connectivity will show up and of course the broken DNS recursors. Greets, Jeroen From jbates@brightok.net Mon Jan 24 07:50:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8043A6ADE for ; Mon, 24 Jan 2011 07:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 B0XxENeaxcE6 for ; Mon, 24 Jan 2011 07:50:01 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 3EC9A3A68E6 for ; Mon, 24 Jan 2011 07:50:01 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0OFqYsZ024328; Mon, 24 Jan 2011 09:52:35 -0600 (CST) Message-ID: <4D3DA041.80309@brightok.net> Date: Mon, 24 Jan 2011 09:52:33 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeroen Massar References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> <4D3D919F.7050003@brightok.net> <4D3D94C1.7080502@unfix.org> In-Reply-To: <4D3D94C1.7080502@unfix.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:50:02 -0000 On 1/24/2011 9:03 AM, Jeroen Massar wrote: > That is because you are talking about three companies (the bbc was once > also one of them btw ;) People on this list are talking about thousands > upon thousands of CPE devices which have the same annoying behavior of > just dropping AAAA records to the floor and then you get a time out and > then the user thinks it is all broken. > I see. I haven't experienced that issue yet, and the helpdesk has a policy of never disabling IPv6 (except for dialups, as v6 screws up dialing into a v4 only modem bank). > One good thing about that problem is that it occurs the moment one > IPv6-enables a host, it does not happen because one introduces AAAA > records for a host into DNS. > I don't see this as a good thing. IPv6 is enabled on Windows Vista and above automatically. At some point, I expect Windows updates to activate all XP machines. > As such, except for broken connectivity this whole "World IPv6 day" > experiment will not going to break too much unless a lot of people > suddenly start enabling IPv6 stacks on their hosts because then the > broken connectivity will show up and of course the broken DNS recursors. > A decent percentage of my customer base is now running Windows Vista/7 with default enabled IPv6. In addition, many of them have walmart special routers. A quick sampling of my recursive resolvers shows roughly a 1:9 ratio AAAA to A. Jack Bates From jeroen@unfix.org Mon Jan 24 08:01:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4113A6905 for ; Mon, 24 Jan 2011 08:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 dRdRFu2hj2aX for ; Mon, 24 Jan 2011 08:01:56 -0800 (PST) Received: from abaddon.unfix.org (abaddon.unfix.org [62.220.146.203]) by core3.amsl.com (Postfix) with ESMTP id B636F3A68FE for ; Mon, 24 Jan 2011 08:01:56 -0800 (PST) Received: from [IPv6:2001:41e0:ff42:99:222:cfff:fe31:ce41] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:99:222:cfff:fe31:ce41]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id ADC0820A8A; Mon, 24 Jan 2011 17:04:27 +0100 (CET) Message-ID: <4D3DA30C.9060301@unfix.org> Date: Mon, 24 Jan 2011 17:04:28 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Bates References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> <4D3D919F.7050003@brightok.net> <4D3D94C1.7080502@unfix.org> <4D3DA041.80309@brightok.net> In-Reply-To: <4D3DA041.80309@brightok.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 16:01:57 -0000 On 2011-01-24 16:52, Jack Bates wrote: [..] >> One good thing about that problem is that it occurs the moment one >> IPv6-enables a host, it does not happen because one introduces AAAA >> records for a host into DNS. >> > I don't see this as a good thing. IPv6 is enabled on Windows Vista and > above automatically. In the case where one enables an IPv6 stack on Windows + receive IPv6 connectivity AAAA resolving starts to happen. As such, this will then directly expose people to the AAAA-resolving bug in their CPE devices. That is a good thing. As it does not depend on a remote site enabling IPv6 in DNS, it all depends on local problems which also can be resolved locally. > At some point, I expect Windows updates to activate all XP machines. As XP is effectively EOL don't expect that to happen. MS wants people to upgrade and I also think that is the right thing to do if you look at the differences in the stacks. >> As such, except for broken connectivity this whole "World IPv6 day" >> experiment will not going to break too much unless a lot of people >> suddenly start enabling IPv6 stacks on their hosts because then the >> broken connectivity will show up and of course the broken DNS recursors. >> > > A decent percentage of my customer base is now running Windows Vista/7 > with default enabled IPv6. In addition, many of them have walmart > special routers. A quick sampling of my recursive resolvers shows > roughly a 1:9 ratio AAAA to A. That might mean that 1:9 of your customers actually have IPv6 connectivity ;) Greets, Jeroen (who is still faithfully using Windows XP ;) From ayourtch@cisco.com Mon Jan 24 08:25:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492313A6B06 for ; Mon, 24 Jan 2011 08:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] 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 bRDXUi3YtP7k for ; Mon, 24 Jan 2011 08:25:45 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 993983A6B04 for ; Mon, 24 Jan 2011 08:25:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0OFnLtQ024230; Mon, 24 Jan 2011 16:49:22 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0OFnLVX016972; Mon, 24 Jan 2011 16:49:21 +0100 (CET) Date: Mon, 24 Jan 2011 16:49:21 +0100 (CET) From: Andrew Yourtchenko To: Jack Bates In-Reply-To: <4D3D919F.7050003@brightok.net> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> <4D3D919F.7050003@brightok.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 16:25:46 -0000 On Mon, 24 Jan 2011, Jack Bates wrote: > > > On 1/23/2011 3:57 AM, Andrew Yourtchenko wrote: >> This case only shows that by doing the parallel threads of DNS+connect >> within the address family we avoid that sort of nastiness for free. >> >> The reason it came to my mind because I was helping to fix the box in >> the middle that was dropping the AAAAs. >> > > I've contacted three companies who used broken load balancers that returned > nxdomain on AAAA but a response for A (ie, when AAAA nxdomained the resolver > didn't ask for A). All companies fixed the problem in a reasonable time. > > I agree and understand connect() reachability and performance. I disagree > with circumventing buggy DNS that needs to be fixed. > Jeroen put it in his mail very well, I'll just add my own 2 cents for what it's worth. The subscribers of this list should have all the possible sharp edges sharpened so they could see what breaks. But the "casual user" folks who type "facebook login" into search engine to get onto facebook (http://www.readwriteweb.com/archives/facebook_wants_to_be_your_one_true_login.php) are not going to fix the DNS. They will either call their SP (who, if they are after a quick cost-savings, will tell then "disable IPv6"), or find themselves on the web "internet slow ? disable IPv6!", and disable it. This is not a large problem support cost-wise, but it increases the end-user resistance towards moving to IPv6 - they have read it on the interwebs that it is harmful and have a proof of it - when they disabled it, it started to work faster. And maybe the ISP got a few calls as well. This is hard to measure from the "far end" by anything other than http://www.google.com/trends?q=disable+ipv6 and handwaving, so treat this for what it is. But it seemed that even if the above were an empty worry, splitting the query into A and AAAA would not be catastrophic (especially since we already have two parallel paths - one for A and one for AAAA). If the above were to be correct, then we would not help too much those users who happen to have the broken CPEs - making this only half as useful. Again, the first passage is guesses all the way down - so any extra clue from ISP folks who have the end-user experience in this area is appreciated. I am not extra strong about this point - just wanted to clarify what went into the decision, FWIW. cheers, andrew From fred@cisco.com Mon Jan 24 09:09:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7433A6AE9 for ; Mon, 24 Jan 2011 09:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cpp1QwhHc87Q for ; Mon, 24 Jan 2011 09:09:30 -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 C784B3A6909 for ; Mon, 24 Jan 2011 09:09:30 -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: AmEGAHJBPU2rR7Hu/2dsb2JhbACCQZQKjh1zoHCbGIVQBIRwhjCDJQ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2011 17:12:25 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0OHCEI9022742 for ; Mon, 24 Jan 2011 17:12:25 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 24 Jan 2011 09:12:25 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 24 Jan 2011 09:12:25 -0800 From: Fred Baker Date: Mon, 24 Jan 2011 09:12:25 -0800 Message-Id: <764E4808-48E5-4720-B989-423768BC5FE2@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1--245634221 Subject: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:09:31 -0000 --Apple-Mail-1--245634221 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Question for the assembled throng: What do people want to see happen in = draft-ietf-v6ops-multihoming-without-nat66? At IETF 79, we had a report on work ongoing in MIF. Tell me - what needs = to be done in this draft? Are there updates needed, or is it ready to = last call? Comments to the list, please. --Apple-Mail-1--245634221 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Question for the assembled throng: What = do people want to see happen in = draft-ietf-v6ops-multihoming-without-nat66?

At IETF = 79, we had a report on work ongoing in MIF. Tell me - what needs to be = done in this draft? Are there updates needed, or is it ready to last = call?

Comments to the list, please.


= = --Apple-Mail-1--245634221-- From jbates@brightok.net Mon Jan 24 10:18:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208423A6B0B for ; Mon, 24 Jan 2011 10:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 UvvXPVnpILwm for ; Mon, 24 Jan 2011 10:18:53 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 4FA053A691C for ; Mon, 24 Jan 2011 10:18:53 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0OILkkY004892; Mon, 24 Jan 2011 12:21:47 -0600 (CST) Message-ID: <4D3DC33A.3080204@brightok.net> Date: Mon, 24 Jan 2011 12:21:46 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeroen Massar References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> <4D3D919F.7050003@brightok.net> <4D3D94C1.7080502@unfix.org> <4D3DA041.80309@brightok.net> <4D3DA30C.9060301@unfix.org> In-Reply-To: <4D3DA30C.9060301@unfix.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 18:18:54 -0000 On 1/24/2011 10:04 AM, Jeroen Massar wrote: > In the case where one enables an IPv6 stack on Windows + receive IPv6 > connectivity AAAA resolving starts to happen. As such, this will then > directly expose people to the AAAA-resolving bug in their CPE devices. > That is a good thing. As it does not depend on a remote site enabling > IPv6 in DNS, it all depends on local problems which also can be resolved > locally. > That might mean that 1:9 of your customers actually have IPv6 > connectivity ;) > I'm not completely sure on this. For example, doesn't the stack query for AAAA to support 6to4, even if 6to4 is broken by a NAT device? This is the only scenario I can think of that would cause a broken CPE to be an issue (ie, why query for AAAA if we can't get a global assignment from the CPE?). It would also break connectivity (which happy eyeballs would fix connection wise) if the remote site had a 6to4 AAAA record (which most policies will choose by default over IPv4). I'm rusty on the RFCs, but a timeout mechanism should have been built into AAAA queries similar to how we stale out bad resolvers. Given current state, I can see how issuing dual queries and taking the first response could be useful, though I recommend that the response be given a window with IPv6 preference (say 50ms?). This would allow for the AAAA response to return slightly slower but still be applicable) and a low enough timeout to not register human perception. Address selection policies, when receiving both responses, or even within a protocol should be taken into account (ie, am I using the 6to4 address, the globally assigned address, the toredo address). It also applies when dealing with IPv4. I disagree with connecting to all addresses within a protocol with all available addressing. It arbitrarily increases load on remote servers. Pick 1 IPv4 address and pick 1 IPv6 address to connect to. Jack From Internet-Drafts@ietf.org Mon Jan 24 13:15:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282043A6989; Mon, 24 Jan 2011 13:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.152, 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 rl6TEnD7aWhG; Mon, 24 Jan 2011 13:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723AF3A6922; Mon, 24 Jan 2011 13: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.10 Message-ID: <20110124211501.32119.87679.idtracker@localhost> Date: Mon, 24 Jan 2011 13:15:01 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations Author(s) : G. Nakibly, F. Templin Filename : draft-ietf-v6ops-tunnel-loops-02.txt Pages : 13 Date : 2011-01-24 This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-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-v6ops-tunnel-loops-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-24130252.I-D@ietf.org> --NextPart-- From dwcarder@wisc.edu Mon Jan 24 13:47:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06B03A6967 for ; Mon, 24 Jan 2011 13:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR7rQzN5Pzt4 for ; Mon, 24 Jan 2011 13:47:54 -0800 (PST) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by core3.amsl.com (Postfix) with ESMTP id 1C9533A68EE for ; Mon, 24 Jan 2011 13:47:54 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LFJ00F1MRCM2T00@smtpauth1.wiscmail.wisc.edu> for v6ops@ietf.org; Mon, 24 Jan 2011 15:50:46 -0600 (CST) Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LFJ002VORCFXW20@smtpauth1.wiscmail.wisc.edu> for v6ops@ietf.org; Mon, 24 Jan 2011 15:50:41 -0600 (CST) Date: Mon, 24 Jan 2011 15:50:39 -0600 From: "Dale W. Carder" To: v6ops@ietf.org Message-id: <20110124215039.GG57584@ricotta.doit.wisc.edu> X-Spam-PmxInfo: Server=avs-9, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.24.214215, SenderIP=144.92.67.161 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:47:55 -0000 My experience in the past 8 or so years of production dual stack v6 service is that clients always try an AAAA record before an A record. This has proved to be easy to troubleshoot and support. After reading draft-wing-v6ops-happy-eyeballs-ipv6-01, I would be concerned about trying to support hosts that do not deterministicly choose an address family to use. Now on top of that, it would be unlikely that every application will implement it or implement it exactly the same way. To an operator such undeterministic behavor is not easy to diagnose, fix, and confirm when resolved. In addition I would think it would be harder to sunset v4 service if this is widely implemented. I think (at some point) people will be watching the v4 traffic approach zero. With happy eyeballs in place it may never get even close. Phased another way, if we had happy eyeballs implementations in place years ago, we would probably still think we had to run IPX and appletalk now. I think more effort should be spent making sure hosts are using RFC 5014, and making v6 actually work. Dale From fred@cisco.com Mon Jan 24 14:21:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB723A682C for ; Mon, 24 Jan 2011 14:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 9fZ8CUMMILQT for ; Mon, 24 Jan 2011 14:21:02 -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 890583A6932 for ; Mon, 24 Jan 2011 14:21:02 -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: AvsEAFGLPU2rR7Ht/2dsb2JhbACka3OgJJsfhVAEhHCGMIMliBo Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2011 22:23:58 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0OMNr1C025792; Mon, 24 Jan 2011 22:23:58 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 24 Jan 2011 14:23:58 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 24 Jan 2011 14:23:58 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <20110124215039.GG57584@ricotta.doit.wisc.edu> Date: Mon, 24 Jan 2011 14:23:44 -0800 Message-Id: <99604715-D25D-4A26-ABA8-E2019A70CDA0@cisco.com> References: <20110124215039.GG57584@ricotta.doit.wisc.edu> To: "Dale W. Carder" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:21:05 -0000 On Jan 24, 2011, at 1:50 PM, Dale W. Carder wrote: > In addition I would think it would be harder to sunset v4 service if = this is widely implemented. I think (at some point) people will be = watching the v4 traffic approach zero.=20 There I disagree. The question we are asked now is "why do I need to = turn on IPv6 at all", and the reason has to do with the availability of = address space and the ability to communicate with a set of peers - = business partners, people one would like to sell to, people one would = like to buy from, and so on. Even at this point, while it is = increasingly obvious to ISPs why *they* need the additional address = space (to deploy new services, meet new customers, etc), I am asked (as = recently as last Friday) "so what business will I be able to transact = that I cannot now transact with IPv4?" and "who are all these peers that = are available on IPv6 and not IPv4?" At some point, I expect the = absolute reverse: "I am operating a dual stack network, IPv4+IPv6. Yes, = I see traffic using IPv4, and I do 50% of my business using it. However, = which of those folks is not also accessible by IPv6, and is the number = of them low enough for me to simply advise them that they need to get = with the program as from some certain date I will no longer support = IPv4?". IPv4 traffic going to zero will come a lot later than the tipping point, = but I expect CIOs to start acting at the tipping point. That's what = makes it a tipping point.= From Ted.Lemon@nominum.com Mon Jan 24 14:25:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6C63A697B for ; Mon, 24 Jan 2011 14:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 WPute+Shk5qW for ; Mon, 24 Jan 2011 14:24:59 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id BBF023A682C for ; Mon, 24 Jan 2011 14:24:59 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTT3862JldTwnQ9s8XoRGUXNnCUm98TXA@postini.com; Mon, 24 Jan 2011 14:27:55 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 746901B82B3 for ; Mon, 24 Jan 2011 14:27:55 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 61474190047; Mon, 24 Jan 2011 14:27:55 -0800 (PST) Received: from [10.1.10.18] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 24 Jan 2011 14:27:55 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110124215039.GG57584@ricotta.doit.wisc.edu> Date: Mon, 24 Jan 2011 17:27:52 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <963C234B-0FB4-480B-AF92-7435DE4DA6EE@nominum.com> References: <20110124215039.GG57584@ricotta.doit.wisc.edu> To: "Dale W. Carder" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:25:00 -0000 On Jan 24, 2011, at 4:50 PM, Dale W. Carder wrote: > After reading draft-wing-v6ops-happy-eyeballs-ipv6-01, I would be = concerned=20 > about trying to support hosts that do not deterministicly choose an = address=20 > family to use. Now on top of that, it would be unlikely that every > application will implement it or implement it exactly the same way. = To an > operator such undeterministic behavor is not easy to diagnose, fix, = and > confirm when resolved. The behavior of devices on the network is never deterministic unless you = have a very constrained network. I think what you mean here is that = which protocol will be chosen is not deterministic. Perhaps so, but = what is deterministic is that happy eyeballs will choose the protocol = that works best at any given moment. So when there is better IPv6 than IPv4 service, you will see IPv4 = traffic drop off. Deterministically. :) From wwwrun@rfc-editor.org Mon Jan 24 17:31:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20273A6B5A; Mon, 24 Jan 2011 17:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, 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 fY3c6eE38+rN; Mon, 24 Jan 2011 17:31:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 464DB3A6B46; Mon, 24 Jan 2011 17:31:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BCA10E0749; Mon, 24 Jan 2011 17:34:52 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110125013452.BCA10E0749@rfc-editor.org> Date: Mon, 24 Jan 2011 17:34:52 -0800 (PST) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6092 on Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 01:31:58 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6092 Title: Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service Author: J. Woodyatt, Ed. Status: Informational Stream: IETF Date: January 2011 Mailbox: jhw@apple.com Pages: 36 Characters: 91729 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-cpe-simple-security-16.txt URL: http://www.rfc-editor.org/rfc/rfc6092.txt This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From cb.list6@gmail.com Mon Jan 24 19:50:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F82E3A6B72 for ; Mon, 24 Jan 2011 19:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.972 X-Spam-Level: X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, J_CHICKENPOX_13=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 QZYWI9dIDLXz for ; Mon, 24 Jan 2011 19:50:25 -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 0815C3A6B6F for ; Mon, 24 Jan 2011 19:50:24 -0800 (PST) Received: by qwi2 with SMTP id 2so5103228qwi.31 for ; Mon, 24 Jan 2011 19:53:21 -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 :content-transfer-encoding; bh=bcuEmgkTU//VH+izpPZ08MZkNcz22oq4tIlwjnR9EuY=; b=AXrhPe9QA+ftY/1RYel1IsqGIrgZ0TBILLnkPH+3KZR21ssUp9MjaLpr1kcp6UKPVh +HsrvJ21MCUMDbA3wxPdD992XhPKbZQWG9XecdC306XuTjs/Phpq3JxLwwrwKQ2it5c1 UR2820U8qSdNr5d6EEd4OGu4bA94TL25fOWNI= 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=n9TipniTiyEwqgF25SarLA1hU6zFtxGwLo7d/5kz/SZiCGhN4aTmJPCVbBGpX3gzwE Q6hl7D87T8552lWwCLHTXJOQduj94p2v4xT5XCdpOC0aOA3ObssZKH0VydQcHJqUuMsS GJVY9sOMAj4XEBbus5fOiy/tjQLWFrNxsoYIY= MIME-Version: 1.0 Received: by 10.229.96.83 with SMTP id g19mr4342758qcn.106.1295927600387; Mon, 24 Jan 2011 19:53:20 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 24 Jan 2011 19:53:20 -0800 (PST) In-Reply-To: <963C234B-0FB4-480B-AF92-7435DE4DA6EE@nominum.com> References: <20110124215039.GG57584@ricotta.doit.wisc.edu> <963C234B-0FB4-480B-AF92-7435DE4DA6EE@nominum.com> Date: Mon, 24 Jan 2011 19:53:20 -0800 Message-ID: From: Cameron Byrne To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 03:50:26 -0000 On Mon, Jan 24, 2011 at 2:27 PM, Ted Lemon wrote: > On Jan 24, 2011, at 4:50 PM, Dale W. Carder wrote: >> After reading draft-wing-v6ops-happy-eyeballs-ipv6-01, I would be concer= ned >> about trying to support hosts that do not deterministicly choose an addr= ess >> family to use. =A0Now on top of that, it would be unlikely that every >> application will implement it or implement it exactly the same way. =A0T= o an >> operator such undeterministic behavor is not easy to diagnose, fix, and >> confirm when resolved. > > The behavior of devices on the network is never deterministic unless you = have a very constrained network. =A0 I think what you mean here is that whi= ch protocol will be chosen is not deterministic. =A0 Perhaps so, but what i= s deterministic is that happy eyeballs will choose the protocol that works = best at any given moment. > > So when there is better IPv6 than IPv4 service, you will see IPv4 traffic= drop off. =A0Deterministically. > I share similar heart burn on this issue to Dale. On one hand, without pushing IPv6, traffic levels may not grow. And if they don't grow, they won't get funded for more development and hacks like tunnels stay in place ... the service is poor, but there is not traffic growth so why invest in more v6 capacity or native v6 capacity? That is the reality of ISP builds. On the other hand, i have a hard time accepting a crappy highly latent poorly peered low MTU IPv6 service .... Yes, thats reality of IPv6 in many places today. Getting to Google via my home 6RD connection involves more than 1 cross country trip ... and no, Youtube does not play well at all in Seattle via this 6RD connection. I wish i could say otherwise. I hear native is on the way at some point for my ISP, but many others will not be so lucky. In fact, my native IPv6 on 3G youtube plays better than my 6RD home connection. I do personally feel happy eyeballs does not help us turn the page on IPv4, even though it has the laudable ideals of choosing better service. Cameron > :) > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From kaeo@merike.com Tue Jan 25 02:40:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688123A6831 for ; Tue, 25 Jan 2011 02:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 vckX3ZUXkQR2 for ; Tue, 25 Jan 2011 02:40:29 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by core3.amsl.com (Postfix) with ESMTP id 7E5B43A6830 for ; Tue, 25 Jan 2011 02:40:28 -0800 (PST) Received: from [192.168.66.55] ([65.102.159.229]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p0PAhIQK019963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jan 2011 02:43:19 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Merike Kaeo In-Reply-To: Date: Tue, 25 Jan 2011 02:43:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, "Jan Zorz @ go6.si" Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:40:30 -0000 On Jan 24, 2011, at 6:28 AM, Cameron Byrne wrote: >=20 >=20 > On Jan 23, 2011 11:10 PM, wrote: > > >=20 > > >=20 > > Now, imagine the following. Your operator has rolled out IPv6 = service without telling you about that. As the average user you should = not care. You go to, say, Japan, where they know there might be billing = issues and have blocked the IPv6 PDP instead of looking into their = billing issues. Most likely by that time (1-2 years) we will not be = using the R8-R9 with dual stack worldwide, and even worse, older core = network elements worldwide will still be on R5, R6 without any plans to = go further. This folks do have knowledge of IPv6 PDP most likely, = however have no idea about any fallback. Your handset does not have = knowledge of fallback either.=20 > > What happens is that you switch on your phone in Japan and see how = it unsuccessfully struggles to connect to the data network and fails. = There will most likely be no error message, and the only way you can = correct things is by manually selecting an IPv4 APN.=20 > > Now, this IS (not MAY be) broken service for 100% of customers.=20 >=20 > Nobody would agree to be breaking roaming. =20 >=20 >=20 > Roman, the solution I have proposed always provides access to the user = since there is logic in the handset to fall back to ipv4 regardless if = the home network rejects based on policy or visited network rejects = based on features. I will not roll out features or services that fail = as you have described or features that are not billed. Both the = "service" MUST work in roaming and MUST be billed. The solution I have = proposed does both in all situations using existing 3GPP functions by = attempting IPv6 PDP first and fallback to IPv4 on failure. If we cannot = do this, it is a road block to deployment where no IPv6 gets deployed = until 100s of roaming partners contractually agree to support and bill = IPv6.... which will take 5+ years. >=20 > That is why I want this solution that uses existing 3GPP methods with = logic on the handset to be documented here in this draft. I have to agree with Cameron that some fallback logic needs to be = documented. =20 After thinking about this for a while I keep coming back to 'what have = mobile vendors implemented that operators can use?' Is there shipping = code and is there concensus amongst some of that code or does everyone = do it differently? (or is everyone in wait-state?) Sifting through 23.401 gave me brain drain but the IP address allocation = section was somewhat useful. Having statement like 'a reason cause = shall be returned to the UE indicating that only the assigned PDN type = is allowed'. Does anyone more familiar with 3GPP know if the reason = causes are explicitly defined somewhere? If the 3GPP standards do not = explicitly define failure modes / notification messages that can cause = fallback to IPv4 or if they are ambiguous, then that fact should be = documented. If they are documented, the details should be enumerated = in this doc. Generally I think this draft is useful and would like to see it = progress. =20 - merike >=20 > In summary of this thread. >=20 > 1. This draft is good and can benefit from adding a fall back section = with the method i have described. As the thread has proven, roaming is = broken and operators are at various stages of awareness to this issue. >=20 >=20 >=20 > 2. GSMA is the right place to fix roaming, not the IETF or 3GPP. But, = the GSMA is slow and we must engineer around them in a way that does not = close doors on v6 roaming eventually working. >=20 >=20 >=20 > 3. The service to the user, regardless of v4 or v6, must always work = and be billed. Neither the operator or user care if the service is v4 = or v6 or v4v6, facebook and google must work. I have proposed a = solution that works in light of the various constraints of home network = policy, visited network features, and providing a path for IPv6 roaming = to work when permitted by both the home and visited network. >=20 >=20 >=20 > cameron >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Tue Jan 25 04:42:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE20B3A6BB2 for ; Tue, 25 Jan 2011 04:42:31 -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 RPalqsTjkdn8 for ; Tue, 25 Jan 2011 04:42:30 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 883DE3A6858 for ; Tue, 25 Jan 2011 04:42:30 -0800 (PST) Received: by wyf23 with SMTP id 23so5668062wyf.31 for ; Tue, 25 Jan 2011 04:45:27 -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=l62R/ZpE6m491Y8TEPGe9rq5G6U2vW5OuraTPyIEbzU=; b=dEIbDCeGo4MoYZO4OHpQ4bCyUyHPN582haxkAklOKjhkq1NoJ+KioPOnR8+Wwpr4oo otUUJkqZDm8YBpVoSykXo+eZYAuVl4DmBREWRh7oE3YYDbFTmVQql1qGEk/CtUgEhozr 2YyeG9Z82QonHSajhzvvoPOU66sER1yxzBTfc= 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=DGBZsRAZN+z4KBwMlAMDgWVYJFeNIlO+0ib5TAW8lETSxWTFQbinFuFIXJdmwNFNKj 24jrgj/s2MOhqr+wav/hx9XU+X+yaEU0r0u8oafDL8Pk17CuE6kAOna5HrCOCbG/r4IC 38EImup18b6PcGScUbeTXIlWNZSnMhLHb3csY= Received: by 10.227.12.209 with SMTP id y17mr5776695wby.154.1295959527550; Tue, 25 Jan 2011 04:45:27 -0800 (PST) Received: from [10.255.138.11] ([192.100.123.77]) by mx.google.com with ESMTPS id q18sm10084774wbe.11.2011.01.25.04.45.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 04:45:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 25 Jan 2011 14:45:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70E95CAB-B8DA-4EB2-86FD-1E3D59F51046@gmail.com> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> To: Merike Kaeo X-Mailer: Apple Mail (2.1078) Cc: v6ops@ietf.org, "Jan Zorz @ go6.si" Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 12:42:31 -0000 Hi, On Jan 25, 2011, at 12:43 PM, Merike Kaeo wrote: >=20 > I have to agree with Cameron that some fallback logic needs to be = documented. =20 There could be some guidance as indicated here: http://www.ietf.org/mail-archive/web/v6ops/current/msg07022.html However, I would keep it strictly in limits what we have in the existing = TS level toolbox. > After thinking about this for a while I keep coming back to 'what have = mobile vendors implemented that operators can use?' Is there shipping = code and is there concensus amongst some of that code or does everyone = do it differently? (or is everyone in wait-state?) >=20 > Sifting through 23.401 gave me brain drain but the IP address = allocation section was somewhat useful. Having statement like 'a reason = cause shall be returned to the UE indicating that only the assigned PDN = type is allowed'. Does anyone more familiar with 3GPP know if the = reason causes are explicitly defined somewhere? If the 3GPP standards = do not explicitly define failure modes / notification messages that can = cause fallback to IPv4 or if they are ambiguous, then that fact should = be documented. If they are documented, the details should be = enumerated in this doc. 24.008 and 24.302. To be honest, I am sure why I have not given = references to these yet ;) - Jouni > Generally I think this draft is useful and would like to see it = progress. =20 >=20 > - merike From jeroen@unfix.org Tue Jan 25 07:29:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68BD3A67EC for ; Tue, 25 Jan 2011 07:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 YmbSE0e3Mcfn for ; Tue, 25 Jan 2011 07:29:57 -0800 (PST) Received: from abaddon.unfix.org (abaddon.unfix.org [62.220.146.203]) by core3.amsl.com (Postfix) with ESMTP id 560333A67E9 for ; Tue, 25 Jan 2011 07:29:57 -0800 (PST) Received: from [IPv6:2001:41e0:ff42:99:222:cfff:fe31:ce41] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:99:222:cfff:fe31:ce41]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 18E6B203C6; Tue, 25 Jan 2011 16:32:28 +0100 (CET) Message-ID: <4D3EED0F.8070200@unfix.org> Date: Tue, 25 Jan 2011 16:32:31 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Bates References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> <4D3D919F.7050003@brightok.net> <4D3D94C1.7080502@unfix.org> <4D3DA041.80309@brightok.net> <4D3DA30C.9060301@unfix.org> <4D3DC33A.3080204@brightok.net> In-Reply-To: <4D3DC33A.3080204@brightok.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 15:29:59 -0000 On 2011-01-24 19:21, Jack Bates wrote: > On 1/24/2011 10:04 AM, Jeroen Massar wrote: >> In the case where one enables an IPv6 stack on Windows + receive IPv6 >> connectivity AAAA resolving starts to happen. As such, this will then >> directly expose people to the AAAA-resolving bug in their CPE devices. >> That is a good thing. As it does not depend on a remote site enabling >> IPv6 in DNS, it all depends on local problems which also can be resolved >> locally. > >> That might mean that 1:9 of your customers actually have IPv6 >> connectivity ;) >> > > I'm not completely sure on this. For example, doesn't the stack query > for AAAA to support 6to4, even if 6to4 is broken by a NAT device? Depends on the stack, afaik Win7 at least does some reachability test to determine if 6to4 can be properly used. > This is the only scenario I can think of that would cause a broken CPE > to be an issue (ie, why query for AAAA if we can't get a global > assignment from the CPE?). 6to4 can be considered a global assignment ;) > It would also break connectivity (which happy eyeballs would fix > connection wise) if the remote site had a 6to4 AAAA record (which most > policies will choose by default over IPv4). Anyone publishing 6to4 AAAA records is doing something they should not be doing. 6to4 is great for temporary connectivity but if anybody wants to do something more long term they should arrange proper connectivity. If one is going to publish AAAA records then one is thinking long term and one should not be using 6to4. (It is just too difficult to debug and there are too many breakage scenarios IMHO) > I'm rusty on the RFCs, but a timeout mechanism should have been built > into AAAA queries similar to how we stale out bad resolvers. There is a timeout, it is about 30 seconds and is general for any DNS queries. This is why 'IPv6 makes the internet slow', because of that timeout. Disabling the IPv6 stack disables the AAAA query and presto 'the internet is fast'... > Given > current state, I can see how issuing dual queries and taking the first > response could be useful, though I recommend that the response be given > a window with IPv6 preference (say 50ms?). 50ms is too much for a site like Google who want instant results.. of course when the DNS record is cached locally the repeats will be coming in at a near zero delay. Thus might be an option but still. The happy eyeballs stuff is all fine, the big problem is getting that code distributed everywhere. Unless all the major vendors push this as a security fix it won't change anything. Oh and don't forget to fix all the code. Of course, patching getaddrinfo() to do this will go quite a long way, except for the connect() time outs in the loop following it. Maybe a longer-term goal is a better API, which is just makeconnect(hostname, service) instead of doing separate resolves? Still, that requires all software to be upgraded, and just check the history of how long it takes to get IPv6 support in a lot of applications, we don't have another 10 years to get this out there. Greets, Jeroen From swmike@swm.pp.se Tue Jan 25 08:38:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2816E3A6800 for ; Tue, 25 Jan 2011 08:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 aRf3b1JdRK80 for ; Tue, 25 Jan 2011 08:38:04 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 3A82C3A682B for ; Tue, 25 Jan 2011 08:38:04 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5D0DCA0; Tue, 25 Jan 2011 17:41:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5BC3D9A; Tue, 25 Jan 2011 17:41:00 +0100 (CET) Date: Tue, 25 Jan 2011 17:41:00 +0100 (CET) From: Mikael Abrahamsson To: Jeroen Massar In-Reply-To: <4D3EED0F.8070200@unfix.org> Message-ID: References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> <9D4FECDA-CC23-4046-833D-D4EFE3066A6A@nominum.com> <05836B69-570F-4514-B955-BE8C4F38A614@cisco.com> <4D383CC5.3080603@viagenie.ca> <20110121113401.K3489@maildrop.int.zabbadoz.net> <4D3D919F.7050003@brightok.net> <4D3D94C1.7080502@unfix.org> <4D3DA041.80309@brightok.net> <4D3DA30C.9060301@unfix.org> <4D3DC33A.3080204@brightok.net> <4D3EED0F.8070200@unfix.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , IPv6 Ops WG Subject: Re: [v6ops] Happy eyeballs implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:38:05 -0000 On Tue, 25 Jan 2011, Jeroen Massar wrote: > Still, that requires all software to be upgraded, and just check the > history of how long it takes to get IPv6 support in a lot of > applications, we don't have another 10 years to get this out there. Since a lot of them still don't have it, perhaps rapidly developing a new API would mean the ones who already don't have it will go for the new one instead? Even if it takes longer and it's not an short term help, I still feel that a new API that does happy eyeballs is of value. -- Mikael Abrahamsson email: swmike@swm.pp.se From remi.despres@free.fr Tue Jan 25 08:39:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5E13A6812 for ; Tue, 25 Jan 2011 08:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_20=-0.74, 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 5thvK6gFdqRB for ; Tue, 25 Jan 2011 08:39:04 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by core3.amsl.com (Postfix) with ESMTP id 6FC0E3A6841 for ; Tue, 25 Jan 2011 08:39:03 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id D21AC700008B; Tue, 25 Jan 2011 17:42:00 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 360727000087; Tue, 25 Jan 2011 17:42:00 +0100 (CET) X-SFR-UUID: 20110125164200221.360727000087@msfrf2409.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: Date: Tue, 25 Jan 2011 17:41:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FFCF0F9-F38A-4CF1-8439-A45E021F18F2@free.fr> References: <20110124215039.GG57584@ricotta.doit.wisc.edu> <963C234B-0FB4-480B-AF92-7435DE4DA6EE@nominum.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:39:05 -0000 Le 25 janv. 2011 =E0 04:53, Cameron Byrne a =E9crit : > On the other hand, i have a hard time accepting a crappy highly latent > poorly peered low MTU IPv6 service .... In IPv6, You must get at least an MTU of 1280. Since the difference with the typical 1500 isn't that large, there must = be another explanation to your problem. > Yes, thats reality of IPv6 in > many places today. Getting to Google via my home 6RD connection > involves more than 1 cross country trip ... Why is it so? > and no, Youtube does not > play well at all in Seattle via this 6RD connection. I wish i could > say otherwise. I hear native is on the way at some point for my ISP, > but many others will not be so lucky. =20 The 6rd of Free works fine, including for Youtube. > In fact, my native IPv6 on 3G > youtube plays better than my 6RD home connection. The hotline for your DSL access should have an explanation, but it = CANNOT BE an intrinsic characteristic of 6rd. > I do personally feel happy eyeballs does not help us turn the page on > IPv4, even though it has the laudable ideals of choosing better > service. I agree with you that IPv6 traffic will grow when offered with good = quality. (As a matter of fact, 6rd has proved to be one way of achieving it = quickly, and on a large scale with regularly growing traffic.) Regards, RD From cb.list6@gmail.com Tue Jan 25 09:22:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0793A684F for ; Tue, 25 Jan 2011 09:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 3AtYKZuNHc+d for ; Tue, 25 Jan 2011 09:22:07 -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 C7E8B3A6842 for ; Tue, 25 Jan 2011 09:22:06 -0800 (PST) Received: by qwi2 with SMTP id 2so5841792qwi.31 for ; Tue, 25 Jan 2011 09:25:03 -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 :content-transfer-encoding; bh=ct908uEXjLken//Pn9Lq4yt5f3cEnWVmrHhGI51OW7E=; b=aqgSntZ3yio6RgawbXz2RtSSBdAfXuOMlojjNDD3U0zlJ+6u3Z56MccqbReWb3Zbr2 tq4QfXcNfZ61CxwqtHkhlj2Ov9KmsHFnuvkNmzCQpPqIKBhzDAVtBgAxBD1osA6XLjHP 4jUtyQ4+aOTxzo0n/7UYkXS8AXQIJoXYFVQsc= 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=u7KNyAxuq8MQK8P4+R9+L0QqDg6uqigi5Akzu/F1T/imUorcxMci2hix8orAoxEnFA 9cV78FW7m7TcvgmRbhmEzdFZ3gsx0MuV2hyJgw0qUth91ZensK8mJeGp1K5VfnCn0JJU j7NCE0PULL6lHpctSgZLbomIUbKqVCjaQ599U= MIME-Version: 1.0 Received: by 10.229.91.145 with SMTP id n17mr4908838qcm.258.1295976303632; Tue, 25 Jan 2011 09:25:03 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 25 Jan 2011 09:25:03 -0800 (PST) In-Reply-To: <0FFCF0F9-F38A-4CF1-8439-A45E021F18F2@free.fr> References: <20110124215039.GG57584@ricotta.doit.wisc.edu> <963C234B-0FB4-480B-AF92-7435DE4DA6EE@nominum.com> <0FFCF0F9-F38A-4CF1-8439-A45E021F18F2@free.fr> Date: Tue, 25 Jan 2011 09:25:03 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 17:22:08 -0000 On Tue, Jan 25, 2011 at 8:41 AM, R=E9mi Despr=E9s wr= ote: > > Le 25 janv. 2011 =E0 04:53, Cameron Byrne a =E9crit : > >> On the other hand, i have a hard time accepting a crappy highly latent >> poorly peered low MTU IPv6 service .... > > In IPv6, You must get at least an MTU of 1280. > Since the difference with the typical 1500 isn't that large, there must b= e another explanation to your problem. > >> Yes, thats reality of IPv6 in >> many places today. =A0Getting to Google via my home 6RD connection >> involves more than 1 cross country trip ... > > Why is it so? > Mostly my performance issues are a result of immature peering issues, v6 is much less well provisioned and peered than v4. I am just sharing my IPv6 home access use case. But, part of me was timing how long before you came to rescue 6RDs good nam= e :) Cameron >> and no, Youtube does not >> play well at all in Seattle via this 6RD connection. =A0 I wish i could >> say otherwise. I hear native is on the way at some point for my ISP, >> but many others will not be so lucky. > > The 6rd of Free works fine, including for Youtube. > >> In fact, my native IPv6 on 3G >> youtube plays better than my 6RD home connection. > > The hotline for your DSL access should have an explanation, but it CANNOT= BE an intrinsic characteristic of 6rd. > >> I do personally feel happy eyeballs does not help us turn the page on >> IPv4, even though it has the laudable ideals of choosing better >> service. > > I agree with you that IPv6 traffic will grow when offered with good quali= ty. > (As a matter of fact, 6rd has proved to be one way of achieving it quickl= y, and on a large scale with regularly growing traffic.) > > Regards, > RD > > > > > From jason_livingood@cable.comcast.com Tue Jan 25 10:51:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D213A6825 for ; Tue, 25 Jan 2011 10:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.272 X-Spam-Level: X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=0.990, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, 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 ZpAZxjfOonoO for ; Tue, 25 Jan 2011 10:51:51 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 145ED3A680E for ; Tue, 25 Jan 2011 10:51:50 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.111779783; Tue, 25 Jan 2011 13:54:42 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 13:54:40 -0500 From: "Livingood, Jason" To: Erik Kline Thread-Topic: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications Thread-Index: AQHLYZZsVCE0+zqIz0+l2xjka9peKJMs6OYAgLXWlQA= Date: Tue, 25 Jan 2011 18:54:39 +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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C943A0321275Ejasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:51:53 -0000 --_000_C943A0321275Ejasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Erik -- Replies inline below and cc'ing the v6ops list since this is now a = WG I-D. The changes you have suggested below will be made shortly in a -01 = update of this draft. Thanks for your feedback! - Jason On 10/1/10 6:03 PM, "Erik Kline" > wrot= e: [Section 2] Your examples/diagrams imply Thanks -- feedback at IETF 79 was also that Figure 2 should be revised. I w= as attempting to do something simple (such as in slide 4 of http://sites.go= ogle.com/site/ipv6implementors/2010/agenda/IPv6_Whitelist_Operations.pdf an= d ended up with a terrible diagram. This will be fixed. [Section 3] "Some parties" requires a reference. Otherwise "some parties" might just be you. Since I know this is not the case, and I also know that references exist, please link to one from here (and elsewhere). [JL] Good point. I have added some references as well as modified the relev= ant text. If you have additional references, please advise (I've only inclu= ded my own). Some parties in the Internet community, including ISPs like Co= mcast, are concerned that this emerging practice of DNS whitelisting for IP= v6 address records could represent a departure from the generally accepted = practices regarding IPv4 address records in the DNS on the Internet. The "model" of DNS described is also not quite the current state of the world. "Everyone", in deliberate quotation marks, employs DNS load balancing and any specific A RR may never be seen by some requesters (usually because of geographic/network latency considerations). Your text implies that DNS for A RRs is currently vastly more egalitarian than it actually is. Perhaps discussion of DNS load balancing and its relationship to whitelisting could supplement section 4, which might then be relabeled "Similarities to other DNS Operations", or something. [JL] Point well taken. I have retitled section 4 to "Similarities to Other = DNS Operations." The first sub-section is the old section 4 on split DNS an= d then I have a new sub-section on DNS Load Balancing. When the next versio= n is released, let me know if you would like to see any changes to that sec= tion. [Section 6] All basically true; it's mostly about the end user experience. This is also the primary motivation behind DNS load balancing, the way CDNs do it. Although I'll add this odd anecdote. In the course of discussing whitelisting with a few different organizations I have actually been told by some operators/administrators that they did not want us to serve them AAAAs. Upon further discussion what became clear is that some folks don't want the full load of youtube traffic to shift to their IPv6 infrastructure until they're ready to support it. So yes, we've had requests from folks to /not/ be served AAAAs. At first I was surprised, but now I understand. [JL] Good example -- I have added that to the draft. [Section 7.1] The end-to-end model does not prevail on the IPv4 Internet today. See previous comment. [JL] I may be misunderstanding your comment but I still think the end-to-en= d model has value. It is not clear how operators of authoritative servers for domains are somehow "in the middle" of the network, except possibly as transit points on the resolution path to subdomains. Perhaps you mean "in the middle" in some social or political sense? In which case you may wish to select a different document, or different subsection, to reference. [JL] I think this section still have value. What I am trying to communicate= (perhaps inelegantly) is that a simpler network architecture is better and= that applying policy controls on a widespread basis in the public DNS coul= d be problematic (and at a minimum would represent a new evolution in how t= he public Internet functions). Nevertheless, your point about what I mean by the "middle" where with respect to authoritative serve= rs is quite well taken and I have made some changes to try to address your = concern in full. [Section 7.2] Again: not true in the IPv4 Internet today where DNS load balancing is employed. Note also that "reachability", in the true sense, is unaffected by the whitelisting you're talking about. It's network "knowledge" or "awareness" that's affected. There is no discussion of ACLs that prevent IPv6 connections from succeeding, just like there is no discussion of ACLs that prevent IPv4 connections from succeeding. Whitelisting, as I believe you're trying to discuss it, only refers to a resolver's awareness that an IPv6 address is associated with a hostname. No barriers to true reachability exist. [JL] I've made changes to address this in the upcoming document. [Section 7.4] What is the definition of an "important domain"? [JL] Those which are a major destination of traffic. I have changes this se= ntence, based on your question, to make this more clear. [Section 7.5] The relationship to governmental censorship seems imprecise, or inapplicable. In the governmental censorship case, logical access to a resource is denied, as mandated by law. In the whitelisting case, logical access to a resource /remains unrestricted/. [JL] I made changes to that section based on your feedback. My intention wa= s not to describe wholesale, government-mandated domain blocking (I can see= the confusion). Rather, I am trying to describe situations where various p= arties may use de-whitelisting as a retaliatory tactic in commercial disput= es, or where parties such as governments may use it (perhaps temporarily) t= o express some dissatisfaction with other governments, etc. By the same tok= en, I can envision whitelisting decisions could be made based on commercial= pressures as well (such as "we'll only whitelist you if you agree to do X = for us, or pay us Y, or break your affiliate agreement with our competitor,= etc.). [Section 7.6] Do you have a reference to anyone who has publicly stated they are not deploying IPv6 and that the principal reason for their not deploying IPv6 is somehow whitelisting-related? [JL] I do not have any public references, which is why I used the speculati= ve "may=85" in the sentence. I can tell you it has been informally discusse= d in this way in network operator circles (networks here not being just ISP= s of course). I did modify the last sentence though, to make clear this is = a possible situation. [Section 9.1] Quite the contrary: any implementation of DNS whitelisting that also seeks to support DNSSEC must be extremely careful in doing so. The implications are very similar to those of DNS64. [JL] Good point. I added some text to explain that an implementing domain m= ust take special care if mixing DNSSEC and whitelisting. Thank you Jason --_000_C943A0321275Ejasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Erik -- Replies inline below and cc'ing the v6ops list since this is n= ow a WG I-D. The changes you have suggested below will be made shortly= in a -01 update of this draft.

Thanks for your feedback!
- Jason

On 10/1/10 6:03 PM, "Erik Kline" <ek@google.com> wrote:
[Section 2]

Your examples/diagrams imply <snip>

Thanks -- feedback at IETF 79 was also that Figure 2 should be revised= . I was attempting to do something simple (such as in slide 4 of = http://sites.google.com/site/ipv6implementors/2010/agenda/IPv6= _Whitelist_Operations.pdf and ended up with a terrible diagram. This will be fixed.

[Section 3]

"Some parties" requires a reference.  Otherwise &q= uot;some parties" might
just be you.  Since I know this is not the case, and I also = know that
references exist, please link to one from here (and elsewhere).

[JL] Good point. I have added some references as well as modified the&= nbsp;relevant text. If you have additional references, please advise (I've = only included my own). Some parties in the Internet community, includi= ng ISPs like Comcast, are concerned that this emerging practice of DNS whitelisting for IPv6 address records could = represent a departure from the generally accepted practices regar= ding IPv4 address records in the DNS on the Internet.


The "model" of DNS described is also not quite the current s= tate of
the world.  "Everyone", in deliberate quotation ma= rks, employs DNS
load balancing and any specific A RR may never be seen by some
requesters (usually because of geographic/network latency
considerations).  Your text implies that DNS for A RRs is cu= rrently
vastly more egalitarian than it actually is.  Perhaps discus= sion of
DNS load balancing and its relationship to whitelisting could
supplement section 4, which might then be relabeled "Similarities= to
other DNS Operations", or something.

[JL] Point well taken. I have retitled section 4 to "Similarities= to Other DNS Operations." The first sub-section is the old secti= on 4 on split DNS and then I have a new sub-section on DNS Load Balanc= ing. When the next version is released, let me know if you would like to see any changes to that section.


[Section 6]

All basically true; it's mostly about the end user experience. &n= bsp;This
is also the primary motivation behind DNS load balancing, the way CDNs=
do it.

Although I'll add this odd anecdote.  In the course of discu= ssing
whitelisting with a few different organizations I have actually been
told by some operators/administrators that they did not want us to
serve them AAAAs.  Upon further discussion what became clear= is that
some folks don't want the full load of youtube traffic to shift to
their IPv6 infrastructure until they're ready to support it.

So yes, we've had requests from folks to /not/ be served AAAAs. &= nbsp;At
first I was surprised, but now I understand.

[JL] Good example -- I have added that to the draft.

[Section 7.1]

The end-to-end model does not prevail on the IPv4 Internet today. = ; See
previous comment.

[JL] I may be misunderstanding your comment but I still think the = ;end-to-end model has value.

It is not clear how operators of authoritative servers for domains are=
somehow "in the middle" of the network, except possibly as t= ransit
points on the resolution path to subdomains.  Perhaps you me= an "in the
middle" in some social or political sense?  In which ca= se you may wish
to select a different document, or different subsection, to reference.=

[JL] I think this section still have value. What I am trying to c= ommunicate (perhaps inelegantly) is that a simpler network architecture&nbs= p;is better and that applying policy controls on a widespread basis in the&= nbsp;public DNS could be problematic (and at a minimum would represent a new evolution in how the public Internet fu= nctions). Nevertheless, your point
about what I mean by the "middle" where with respect to auth= oritative servers is quite well taken and I have made some changes to = try to address your concern in full.

[Section 7.2]

Again: not true in the IPv4 Internet today where DNS load balancing is=
employed.

Note also that "reachability", in the true sense, is unaffec= ted by the
whitelisting you're talking about.  It's network "knowl= edge" or
"awareness" that's affected.  There is no discussi= on of ACLs that
prevent IPv6 connections from succeeding, just like there is no
discussion of ACLs that prevent IPv4 connections from succeeding.
Whitelisting, as I believe you're trying to discuss it, only refers to=
a resolver's awareness that an IPv6 address is associated with a
hostname.  No barriers to true reachability exist.

[JL] I've made changes to address this in the upcoming document.

[Section 7.4]

What is the definition of an "important domain"?

[JL] Those which are a major destination of traffic. I have changes th= is sentence, based on your question, to make this more clear.

[Section 7.5]

The relationship to governmental censorship seems imprecise, or
inapplicable.  In the governmental censorship case, logical = access to
a resource is denied, as mandated by law.  In the whitelisti= ng case,
logical access to a resource /remains unrestricted/.

[JL] I made changes to that section based on your feedback. My intenti= on was not to describe wholesale, government-mandated domain blocking (I ca= n see the confusion). Rather, I am trying to describe situations where vari= ous parties may use de-whitelisting as a retaliatory tactic in commercial disputes, or where parties such as g= overnments may use it (perhaps temporarily) to express some dissatisfaction= with other governments, etc. By the same token, I can envision whitelistin= g decisions could be made based on commercial pressures as well (such as "we'll only whitelist you if= you agree to do X for us, or pay us Y, or break your affiliate agreement w= ith our competitor, etc.).

[Section 7.6]

Do you have a reference to anyone who has publicly stated they are not=
deploying IPv6 and that the principal reason for their not deploying
IPv6 is somehow whitelisting-related?

[JL] I do not have any public references, which is why I used the spec= ulative "may=85" in the sentence. I can tell you it has been info= rmally discussed in this way in network operator circles (networks here not= being just ISPs of course). I did modify the last sentence though, to make clear this is a possible situation.

[Section 9.1]

Quite the contrary: any implementation of DNS whitelisting that also
seeks to support DNSSEC must be extremely careful in doing so. &n= bsp;The
implications are very similar to those of DNS64.

[JL] Good point. I added some text to explain that an implementing dom= ain must take special care if mixing DNSSEC and whitelisting.


Thank you
Jason
--_000_C943A0321275Ejasonlivingoodcablecomcastcom_-- From jouni.nospam@gmail.com Tue Jan 25 10:56:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF8D3A6855 for ; Tue, 25 Jan 2011 10:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 JfmmglCERbk8 for ; Tue, 25 Jan 2011 10:56:57 -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 98D623A6838 for ; Tue, 25 Jan 2011 10:56:56 -0800 (PST) Received: by eyd10 with SMTP id 10so98828eyd.31 for ; Tue, 25 Jan 2011 10:59:54 -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=nqqXtxxR3hr9k0LqWLoG8A+zciaAEhfGfjoXrWHLSXA=; b=iaUZTpzgiazS6JouNL1GT2/2es660TUWRv1/LUjzU4xlN2N6otczHjhwVoPUSVQi6E RbuxsOaJFNcf2+gdT6x9T0k+iNWaD5CNUOHGclqhcM3jau/VIG8qtbe2uBcCg/v1E6Jp yMByOZ4du6sopjvAMt0ExPObrbDkhFRp8Qfk4= 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=q5s+NRxOJiFi1Dx+XyvK9lUq78tdvpJmNfsKkzKKLaXtxOKUisqykvmK99ZHeQdHyj wwccD3o+2h+aPTbFTJwPMK+zt5ZNBeQl2W9WJ6Lm1wxnyRbP283ALJE6caTIG/000mUs 1Lxq7g0gr/wTj76TNskdUtaO2zhGwR4RB/p20= Received: by 10.204.71.82 with SMTP id g18mr5578840bkj.166.1295981993613; Tue, 25 Jan 2011 10:59:53 -0800 (PST) Received: from a88-112-142-31.elisa-laajakaista.fi (a88-112-142-31.elisa-laajakaista.fi [88.112.142.31]) by mx.google.com with ESMTPS id q18sm7033052bka.3.2011.01.25.10.59.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 10:59:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <70E95CAB-B8DA-4EB2-86FD-1E3D59F51046@gmail.com> Date: Tue, 25 Jan 2011 20:59:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55FFB874-C927-431E-803F-C09392AAA40D@gmail.com> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <70E95CAB-B8DA-4EB2-86FD-1E3D59F51046@gmail.com> To: Merike Kaeo X-Mailer: Apple Mail (2.1078) Cc: IPv6 Ops WG , "Jan Zorz @ go6.si" Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:56:58 -0000 On Jan 25, 2011, at 2:45 PM, jouni korhonen wrote: [snip] >>=20 >> Sifting through 23.401 gave me brain drain but the IP address = allocation section was somewhat useful. Having statement like 'a reason = cause shall be returned to the UE indicating that only the assigned PDN = type is allowed'. Does anyone more familiar with 3GPP know if the = reason causes are explicitly defined somewhere? If the 3GPP standards = do not explicitly define failure modes / notification messages that can = cause fallback to IPv4 or if they are ambiguous, then that fact should = be documented. If they are documented, the details should be = enumerated in this doc. >=20 > 24.008 and 24.302. To be honest, I am sure why I have not given = references to these yet ;) 24.301 to be exact.. sorry for the typo. - JOuni >=20 > - Jouni >=20 >> Generally I think this draft is useful and would like to see it = progress. =20 >>=20 >> - merike >=20 From simon.perreault@viagenie.ca Tue Jan 25 11:13:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A5E3A681D for ; Tue, 25 Jan 2011 11:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 pJC5I6z5tt5o for ; Tue, 25 Jan 2011 11:12:42 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 993E03A680A for ; Tue, 25 Jan 2011 11:12:42 -0800 (PST) Received: from [192.168.1.139] (unknown [209.171.96.175]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 52FD620D1F for ; Tue, 25 Jan 2011 14:15:40 -0500 (EST) Message-ID: <4D3F215F.9010300@viagenie.ca> Date: Tue, 25 Jan 2011 14:15:43 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: v6ops@ietf.org References: <20110124215039.GG57584@ricotta.doit.wisc.edu> <963C234B-0FB4-480B-AF92-7435DE4DA6EE@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:13:00 -0000 On 2011-01-24 22:53, Cameron Byrne wrote: > On one hand, without pushing IPv6, traffic levels may not grow. [...] > > On the other hand, i have a hard time accepting a crappy highly latent > poorly peered low MTU IPv6 service [...] So what you're saying is you'd like to prefer IPv6, even if IPv6 is slightly worse than IPv4, but not past a given threshold. Right? Happy eyeballs provides for that. Here's the text: The TCP client application is configured with one value, P. A positive value indicates a preference for IPv6 and a negative value indicates a preference for IPv4. A value of 0 indicates equal weight, which means the A and AAAA queries and associated connection attempts will be sent as quickly as possible. The absolute value of P is the measure of a delay before initiating a connection attempt on the other address family. There are two P values maintained: one is application-wide and the other is specific per each destination (hostname and port). (See section 4.1 for the rest...) Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jason_livingood@cable.comcast.com Tue Jan 25 13:08:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4780F3A68A2 for ; Tue, 25 Jan 2011 13:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=-1.840, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA0x1AFr4SVO for ; Tue, 25 Jan 2011 13:08:30 -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 303103A6875 for ; Tue, 25 Jan 2011 13:08:30 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23381835; Tue, 25 Jan 2011 14:21:56 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:11:22 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 Thread-Index: AQHLvNRqPcxWdjbsU0G4DnccijWfJQ== Date: Tue, 25 Jan 2011 21:11:21 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C96487DC155CCjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:08:31 -0000 --_000_C96487DC155CCjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All =96 Momentarily I will post a new version of this draft, -01, for WG fe= edback. I expect to receive some feedback and quickly incorporate that into= a =9602 which will then hopefully be mature enough to stand for a WGLC. In any case, I will send a few emails related to this draft today. Each wil= l address a specific issue that I am looking for either feedback on or revi= ew of in some manner. I decided to send separate emails as it will make it = easier for me to parse the feedback and make rapid changes. Thanks in advace! Jason --_000_C96487DC155CCjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
All =96 Momentarily I will post a new version of this draft, -01, for = WG feedback. I expect to receive some feedback and quickly incorporate that= into a =9602 which will then hopefully be mature enough to stand for a WGL= C.

In any case, I will send a few emails related to this draft today. Eac= h will address a specific issue that I am looking for either feedback on or= review of in some manner. I decided to send separate emails as it will mak= e it easier for me to parse the feedback and make rapid changes.

Thanks in advace!
Jason
--_000_C96487DC155CCjasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Jan 25 13:12:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6343A6873 for ; Tue, 25 Jan 2011 13:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.459 X-Spam-Level: X-Spam-Status: No, score=-103.459 tagged_above=-999 required=5 tests=[AWL=-1.725, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7eZ5-7HPZoe for ; Tue, 25 Jan 2011 13:12:46 -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 94E6F3A6838 for ; Tue, 25 Jan 2011 13:12:46 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23382709; Tue, 25 Jan 2011 14:26:27 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:15:41 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- References Sought Thread-Index: AQHLvNUER8CUfzVa4kSo84MndeyRFw== Date: Tue, 25 Jan 2011 21:15:40 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C9648D4815600jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- References Sought X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:12:47 -0000 --_000_C9648D4815600jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt I'm looking for any good references which I may include, as follows: 1 =96 Section 3: A reference to the concept of "network effects" 2 =96 Section 4.2: Any good reference to round robin DNS as a load balancin= g technique? 3 =96 Section 4.2: Any good reference to the technical subject of load bala= ncing in general? 4 =96 Section 4.2: Any good reference to the practice of CDNs varying their= query responses based on an estimated geographic location? 5 - Jason --_000_C9648D4815600jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2C052F288C689E4CB91928B2592A4224@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

I'm looking for any good references which I may include, as follows:

1 =96 Section 3: A reference to the concept of "network effects&q= uot;

2 =96 Section 4.2: Any good reference to round robin DNS as a load bal= ancing technique?

3 =96 Section 4.2: Any good reference to the technical subject of load= balancing in general?

4 =96 Section 4.2: Any good reference to the practice of CDNs varying = their query responses based on an estimated geographic location?

5 - 

Jason
--_000_C9648D4815600jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Jan 25 13:13:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03293A68AF for ; Tue, 25 Jan 2011 13:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.721 X-Spam-Level: X-Spam-Status: No, score=-106.721 tagged_above=-999 required=5 tests=[AWL=1.741, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPluY391DcMB for ; Tue, 25 Jan 2011 13:13:04 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CBDED3A68A7 for ; Tue, 25 Jan 2011 13:13:01 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.111801299; Tue, 25 Jan 2011 16:15:58 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:15:58 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- Figure 2 Updated Thread-Index: AQHLvNUORL+88yBKPEipl41h+G5Kpg== Date: Tue, 25 Jan 2011 21:15:57 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C96496C71562Djasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- Figure 2 Updated X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:13:05 -0000 --_000_C96496C71562Djasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt Figure 2 has been updated. As was pointed out at the IETF meeting, this was= a bit lacking in detail (showing both A and AAAA queries). Let me know if = this updated figure is suitable or if it still could use some tweaks. Thanks Jason --_000_C96496C71562Djasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5E846EA406F10243B55E545124BAE8EC@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

Figure 2 has been updated. As was pointed out at the IETF meeting, thi= s was a bit lacking in detail (showing both A and AAAA queries). Let me kno= w if this updated figure is suitable or if it still could use some tweaks.<= /div>

Thanks
Jason
--_000_C96496C71562Djasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Jan 25 13:13:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56F23A68AC for ; Tue, 25 Jan 2011 13:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.454 X-Spam-Level: X-Spam-Status: No, score=-103.454 tagged_above=-999 required=5 tests=[AWL=-1.720, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf0uRVG+JJFa for ; Tue, 25 Jan 2011 13:13:35 -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 C2DB83A689E for ; Tue, 25 Jan 2011 13:13:34 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23382878; Tue, 25 Jan 2011 14:27:16 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:16:29 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- New Section 4.2, DNS Load Balancing Thread-Index: AQHLvNUhepGk//I40kyVa0DgxUOExw== Date: Tue, 25 Jan 2011 21:16:28 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C9648CEE155FCjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- New Section 4.2, DNS Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:13:35 -0000 --_000_C9648CEE155FCjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt Section 4.2 was added at Erik Kline's suggestion. I wanted to specifically = indicate this as a new section, and ask for any suggested modifications. Regards Jason --_000_C9648CEE155FCjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Section 4.2 was added at Erik Kline's suggestion. I wanted to specific= ally indicate this as a new section, and ask for any suggested modification= s.

Regards
Jason
--_000_C9648CEE155FCjasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Jan 25 13:13:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F213A68A0 for ; Tue, 25 Jan 2011 13:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.363 X-Spam-Level: X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=-1.629, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3OqNAAaoiNm for ; Tue, 25 Jan 2011 13:13:56 -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 ED1653A689D for ; Tue, 25 Jan 2011 13:13:55 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23382980; Tue, 25 Jan 2011 14:27:31 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:16:49 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- 6, Reasons for Brokenness Detailed?? Thread-Index: AQHLvNUtb471ucT1+0uLM5M1BH0e2Q== Date: Tue, 25 Jan 2011 21:16:48 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C964954315622jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- 6, Reasons for Brokenness Detailed?? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:13:56 -0000 --_000_C964954315622jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt In Section 6 (and other parts of the document), I make a passing reference = to the causes of IPv6 brokenness. One open question is whether that is fine= OR whether I should list the various causes of IPv6 brokenness (or add mor= e references to documents which may already do so). Thanks Jason --_000_C964954315622jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <61CE5F372E0A7B41AF0E2B64CBDF550A@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

In Section 6 (and other parts of the document), I make a passing refer= ence to the causes of IPv6 brokenness. One open question is whether that is= fine OR whether I should list the various causes of IPv6 brokenness (or ad= d more references to documents which may already do so). 

Thanks
Jason

--_000_C964954315622jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Jan 25 13:14:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6F33A68AD for ; Tue, 25 Jan 2011 13:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.282 X-Spam-Level: X-Spam-Status: No, score=-103.282 tagged_above=-999 required=5 tests=[AWL=-1.548, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofg6jwIdN8PD for ; Tue, 25 Jan 2011 13:14:17 -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 8DDCB3A68CF for ; Tue, 25 Jan 2011 13:14:17 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23383124; Tue, 25 Jan 2011 14:27:59 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:17:12 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- Major Section Update, 7.2, Reachability Thread-Index: AQHLvNU6nROyZrKpoEyjzITWsCxt2g== Date: Tue, 25 Jan 2011 21:17:11 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C9648DFE15606jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- Major Section Update, 7.2, Reachability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:14:18 -0000 --_000_C9648DFE15606jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt Section 7.2 has been expanded with a new concluding paragraph as well as ot= her updates. I wanted to specifically ask for any suggested modifications t= o this new paragraph. Regards Jason --_000_C9648DFE15606jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <262D2BA98931D84C8A1880F46FA995A0@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

Section 7.2 has been expanded with a new concluding paragraph as well = as other updates. I wanted to specifically ask for any suggested modificati= ons to this new paragraph.

Regards
Jason
--_000_C9648DFE15606jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Jan 25 13:14:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1666D3A68AC for ; Tue, 25 Jan 2011 13:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=-1.474, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt4OMcRGbHIm for ; Tue, 25 Jan 2011 13:14:38 -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 414FB3A68D2 for ; Tue, 25 Jan 2011 13:14:38 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23383221; Tue, 25 Jan 2011 14:28:19 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:17:32 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- 7.3, Additional Implications? Thread-Index: AQHLvNVGAdnxj5dfT0KAv4lm3ukaOw== Date: Tue, 25 Jan 2011 21:17:30 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C9648EDB1560Cjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- 7.3, Additional Implications? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:14:39 -0000 --_000_C9648EDB1560Cjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt I removed any editorial notes calling for additional implications (such as = in 7.3.2, 7.3.3, etc.), as I have received no suggestions. As a result, I'd= like to make one last call for anyone to suggest additional operational im= plications for inclusion. Not that I'll complain if no one has any more =97= it's less work for me in producing the -02 update. ;=96) Thanks Jason --_000_C9648EDB1560Cjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <417BE7DF56A37642A2275B956BCB7E62@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

I removed any editorial notes calling for additional implications (suc= h as in 7.3.2, 7.3.3, etc.), as I have received no suggestions. As a result= , I'd like to make one last call for anyone to suggest additional operation= al implications for inclusion. Not that I'll complain if no one has any more =97 it's less work for me in pro= ducing the -02 update. ;=96)

Thanks
Jason
--_000_C9648EDB1560Cjasonlivingoodcablecomcastcom_-- From Internet-Drafts@ietf.org Tue Jan 25 13:15:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEB63A68A3; Tue, 25 Jan 2011 13:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 MOPwGtEewB2B; Tue, 25 Jan 2011 13:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE443A6852; Tue, 25 Jan 2011 13: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.10 Message-ID: <20110125211501.6347.60180.idtracker@localhost> Date: Tue, 25 Jan 2011 13:15:01 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21: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 IPv6 Operations Working Group of the IETF. Title : IPv6 AAAA DNS Whitelisting Implications Author(s) : J. Livingood Filename : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01.txt Pages : 27 Date : 2011-01-25 The objective of this document is to describe what whitelisting of DNS AAAA resource records is, or DNS whitelisting for short, as well as what the implications of this emerging practice are and what alternatives may exist. The audience for this document is the Internet community generally, including the IETF and IPv6 implementers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-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-v6ops-v6-aaaa-whitelisting-implications-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-25130832.I-D@ietf.org> --NextPart-- From jason_livingood@cable.comcast.com Tue Jan 25 13:15:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BBF3A68C0 for ; Tue, 25 Jan 2011 13:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.141 X-Spam-Level: X-Spam-Status: No, score=-103.141 tagged_above=-999 required=5 tests=[AWL=-1.407, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQkNGxQ8YjFJ for ; Tue, 25 Jan 2011 13:15:09 -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 7E18A3A68E0 for ; Tue, 25 Jan 2011 13:15:08 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23383338; Tue, 25 Jan 2011 14:28:42 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:18:02 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- 7.5, Conflict Cases Thread-Index: AQHLvNVY/ximHLeRP0WcqhWmx1iJOQ== Date: Tue, 25 Jan 2011 21:18:01 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C964927115617jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- 7.5, Conflict Cases X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:15:09 -0000 --_000_C964927115617jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt In the final paragraph of 7.5, I changed some of the examples where conflic= ts may develop. The idea here was to describe some of the ways in which con= flicts involving whitelisting and de-whitelisting may develop. Please advis= e if you suggest changes to the conflict cases, or wish to suggest new ones= to be added. Thanks Jason --_000_C964927115617jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <61D0D52A8E795747859E8F6D85360413@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

In the final paragraph of 7.5, I changed some of the examples where co= nflicts may develop. The idea here was to describe some of the ways in= which conflicts involving whitelisting and de-whitelisting may develop.&nb= sp;Please advise if you suggest changes to the conflict cases, or wish to suggest new ones to be added. 

Thanks
Jason
--_000_C964927115617jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Jan 25 13:16:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27F93A6852 for ; Tue, 25 Jan 2011 13:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.08 X-Spam-Level: X-Spam-Status: No, score=-103.08 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wkRmFzIpYUX for ; Tue, 25 Jan 2011 13:16:06 -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 D71853A689E for ; Tue, 25 Jan 2011 13:16:05 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23383550; Tue, 25 Jan 2011 14:29:49 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Tue, 25 Jan 2011 16:19:02 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OA== Date: Tue, 25 Jan 2011 21:19:01 +0000 Message-ID: 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: [24.40.62.125] Content-Type: multipart/alternative; boundary="_000_C9648A02155E4jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:16:07 -0000 --_000_C9648A02155E4jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (This is the final specific request for feedback on this draft.) re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.tx One question raised at the last IETF meeting was whether this draft should = make some statement at the end of the I-D saying whether or not this is a r= ecommended practice. Alternatively, this can be done as a separate document= . However, if the WG believes it useful to make a statement on this practic= e, I think it simpler and more expedient to add it to this document. If the WG agrees, then I propose to add a section saying something along th= e lines of: Section Name: Is DNS Whitelisting a Recommended Practice? or Section Name: Is DNS Whitelisting a Best Practice? Section Content: Opinions in the Internet community concerning whether or n= ot DNS whitelisting is a recommended practice are understandably quite vari= ed. However, there is clear consensus that DNS whitelisting is at best a us= eful temporary measure which a domain may choose to pursue as they prepare = for the transition to IPv6. In particular, major domains such as those oper= ated by Google view DNS whitelisting as one of the few practical and low ri= sk approaches enabling them to prepare for the transition to IPv6. Thus, DN= S whitelisting is not a recommended practice over the long-term. In additio= n, DNS whitelisting should be avoided wherever possible in the short-term a= nd its use is discouraged. Nevertheless, major domains may find DNS whiteli= sting a beneficial temporary tactic in their transition to IPv6. Such tempo= rary use during the transition to IPv6 is broadly accepted within the commu= nity, so long as it does not become a long-term practice over a period of a= year or more past the point when IANA's IPv4 address pool is depleted. -- JL --_000_C9648A02155E4jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
(This is the final specific request for feedback on this draft.)


One question raised at the last IETF meeting was whether this draft sh= ould make some statement at the end of the I-D saying whether or not this i= s a recommended practice. Alternatively, this can be done as a separate doc= ument. However, if the WG believes it useful to make a statement on this practice, I think it simpler and mor= e expedient to add it to this document.

If the WG agrees, then I propose to add a section saying something alo= ng the lines of:

Section Name: Is DNS Whitelisting a Recommended Practice?
or 
Sec= tion Name: Is DNS Whitelisting a Best Practice?

Section Content: Opinions in the Internet community concerning whet= her or not DNS whitelisting is a recommended practice are understandably qu= ite varied. However, there is clear consensus that DNS whitelisting is at b= est a useful temporary measure which a domain may choose to pursue as they prepare for the transition to IPv6. = In particular, major domains such as those operated by Google view DNS whit= elisting as one of the few practical and low risk approaches enabling them = to prepare for the transition to IPv6. Thus, DNS whitelisting is not a recommended practice over the long-t= erm. In addition, DNS whitelisting should be avoided wherever possible in t= he short-term and its use is discouraged. Nevertheless, major domains may f= ind DNS whitelisting a beneficial temporary tactic in their transition to IPv6. Such temporary use during th= e transition to IPv6 is broadly accepted within the community, so long as i= t does not become a long-term practice over a period of a year or more past= the point when IANA's IPv4 address pool is depleted.

-- JL
--_000_C9648A02155E4jasonlivingoodcablecomcastcom_-- From fred@cisco.com Tue Jan 25 13:17:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE503A68B1 for ; Tue, 25 Jan 2011 13:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.169 X-Spam-Level: X-Spam-Status: No, score=-110.169 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 17b4-Pbn8s0V for ; Tue, 25 Jan 2011 13:17:52 -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 C64623A68A8 for ; Tue, 25 Jan 2011 13:17:52 -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: Av0EAIrNPk2rR7Ht/2dsb2JhbACCQKIxc6FVmziFTwSFF4cRg0Y Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 25 Jan 2011 21:20:51 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0PLJiEH022179; Tue, 25 Jan 2011 21:20:51 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 25 Jan 2011 13:20:51 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 25 Jan 2011 13:20:51 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 25 Jan 2011 13:20:51 -0800 Message-Id: <3965D06A-562A-4A19-8F5A-119F000E2017@cisco.com> References: To: "Livingood, Jason" X-Mailer: Apple Mail (2.1082) Content-Type: multipart/alternative; boundary=Apple-Mail-32--144328430 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:17:53 -0000 --Apple-Mail-32--144328430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 25, 2011, at 1:11 PM, Livingood, Jason wrote: > All =96 Momentarily I will post a new version of this draft, -01, for = WG feedback. I expect to receive some feedback and quickly incorporate = that into a =9602 which will then hopefully be mature enough to stand = for a WGLC. Ack. When I see the -02 or a note from you saying you don't plan to file = one, I will open the WGLC. > In any case, I will send a few emails related to this draft today. = Each will address a specific issue that I am looking for either feedback = on or review of in some manner. I decided to send separate emails as it = will make it easier for me to parse the feedback and make rapid changes. >=20 > Thanks in advace! > Jason > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-32--144328430 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
All =96 Momentarily I will post a new version of this draft, -01, = for WG feedback. I expect to receive some feedback and quickly = incorporate that into a =9602 which will then hopefully be mature enough = to stand for a WGLC.

Ack. When I see the -02 or a = note from you saying you don't plan to file one, I will open the = WGLC.

In any case, I will send a few emails related to this draft today. = Each will address a specific issue that I am looking for either feedback = on or review of in some manner. I decided to send separate emails as it = will make it easier for me to parse the feedback and make rapid changes.

Thanks in advace!
Jason
_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-32--144328430-- From ichiroumakino@gmail.com Wed Jan 26 01:20:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537073A68D7 for ; Wed, 26 Jan 2011 01:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, J_CHICKENPOX_13=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 TJRfmJukh6-b for ; Wed, 26 Jan 2011 01:20:28 -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 E56A43A63D2 for ; Wed, 26 Jan 2011 01:20:27 -0800 (PST) Received: by eyd10 with SMTP id 10so381415eyd.31 for ; Wed, 26 Jan 2011 01:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=PhZbgZ23YEAVn/9/das0UiVhnxRhKW2pb4mWgK0slL4=; b=CGeVcQ1Q2wo+sWU/zFSJnCWM6q0q9wmcALF/b3msm0c8YFx+0yqHgB+cQvfuYgfeyN OUD20KC8ao737O5RxRqwWqNlqD2wyIvX7FXkOu8KGKaeYL+ChfpAwaS9odhHG3pjB/e7 iaE9u01Lznj+ikaItf26xz7y+7Dw/HXBO3tAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Hcqwau4WeYpcRa1eBJynCnXo713b3TlkscNZ3drwnWX6gUCsuGL/acOvrYvEP+MB0H ueEdOWw3P0Qr8nkZmcHZSrx9j/Hlh6PX+SMIjCI6HdWobPAiLER0DieKaBmc0WOLzS+D QURaiqHFYB3YY3hiZ8Gl4YzltSbsLlgNn2XUc= Received: by 10.14.126.141 with SMTP id b13mr214310eei.47.1296033807411; Wed, 26 Jan 2011 01:23:27 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-199.cisco.com (dhcp-osl-vl300-64-103-53-199.cisco.com [64.103.53.199]) by mx.google.com with ESMTPS id u1sm11851377eeh.10.2011.01.26.01.23.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 01:23:25 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <20110124211501.32119.87679.idtracker@localhost> Date: Wed, 26 Jan 2011 10:23:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4433A997-446D-436F-ADF4-E1B0508817B1@employees.org> References: <20110124211501.32119.87679.idtracker@localhost> To: Gabi Nakibly , Fred L Templin X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 09:20:31 -0000 Gabi, Fred, with regards to 6rd. - update reference to rfc5969 - reference 5969's looping mitigation text in general, make a difference between global tunneling mechanisms like = 6to4 and local tunnel mechanisms like ISATAP and 6rd. cheers, Ole On Jan 24, 2011, at 22:15 , 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 IPv6 Operations Working Group of the = IETF. >=20 >=20 > Title : Routing Loop Attack using IPv6 Automatic = Tunnels: Problem Statement and Proposed Mitigations > Author(s) : G. Nakibly, F. Templin > Filename : draft-ietf-v6ops-tunnel-loops-02.txt > Pages : 13 > Date : 2011-01-24 >=20 > This document is concerned with security vulnerabilities in IPv6-in- > IPv4 automatic tunnels. These vulnerabilities allow an attacker to > take advantage of inconsistencies between the IPv4 routing state and > the IPv6 routing state. The attack forms a routing loop which can be > abused as a vehicle for traffic amplification to facilitate DoS > attacks. The first aim of this document is to inform on this attack > and its root causes. The second aim is to present some possible > mitigation measures. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-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. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Wed Jan 26 05:10:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CCB3A692D for ; Wed, 26 Jan 2011 05:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, 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 fgeRR8+tEKTm for ; Wed, 26 Jan 2011 05:10:42 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 8A5E33A6857 for ; Wed, 26 Jan 2011 05:10:42 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 86159A0; Wed, 26 Jan 2011 14:13:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 850349A; Wed, 26 Jan 2011 14:13:39 +0100 (CET) Date: Wed, 26 Jan 2011 14:13:39 +0100 (CET) From: Mikael Abrahamsson To: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> Message-ID: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-20665777-1296047619=:13151" Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:10:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-20665777-1296047619=:13151 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 24 Jan 2011, Rémi Després wrote: > In the section on overlapping IPv4 addresses (8.1), I suggest to add a > small clarification. Its purpose is to remind the relationship that > exists between overlapping RFC 1918 IPv4 address spaces and the 6rd of > RFC 5969. I think this is a good idea to point out in the document. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-20665777-1296047619=:13151-- From cb.list6@gmail.com Wed Jan 26 05:20:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164713A692D for ; Wed, 26 Jan 2011 05:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA164OmsxFgt for ; Wed, 26 Jan 2011 05:20:48 -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 818E73A69AE for ; Wed, 26 Jan 2011 05:20:48 -0800 (PST) Received: by qyj19 with SMTP id 19so967499qyj.10 for ; Wed, 26 Jan 2011 05:23:48 -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=iGCuKuWUsZr4frNF6z5RJs8MBwYU9zuKykWUt6D0Now=; b=ox48mg7kwQSiqEPOkPlcAPCeG/+Odnj4vCBVOWozp0Ud2vzXsdbiEKgCgeMGs8koq3 avAgR8vf90IPLi/XJesapBNAT/teBLvSEoXHn4yfsJlqNV+D9fRGsUO9GHLYGXaLqw39 Ac3SczmSanhgOUy6NfUVo6DGEcLVaQwCG0jH4= 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=VUvnX5/J0ud/9IS+YYBL3vf5aaSe/H0EoF2Koo3+VKOR6YfqYDNE7HLeYmRDto6hsC ykXl7tBa3BqCNzpSAHV7M2qWkrqG4XGJovFVYp20eh/R4yLNKnrdDPwhH7147H5UCz3a PlMhDrxxzryw6KDfAB0e9d/rqiGWFZ5vj5rAE= MIME-Version: 1.0 Received: by 10.229.128.228 with SMTP id l36mr362715qcs.296.1296048227902; Wed, 26 Jan 2011 05:23:47 -0800 (PST) Received: by 10.229.224.79 with HTTP; Wed, 26 Jan 2011 05:23:47 -0800 (PST) Received: by 10.229.224.79 with HTTP; Wed, 26 Jan 2011 05:23:47 -0800 (PST) In-Reply-To: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> Date: Wed, 26 Jan 2011 05:23:47 -0800 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001517576eb23c66b5049abfbea0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:20:50 -0000 --001517576eb23c66b5049abfbea0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I disagree. 6rd has been rejected by 3gpp as a transition tool. The scope of this doc is just summarizing existing 3gpp tools and technologies. RD ... please respect the agreed scope and take the 6rd sales pitch off line. Cb On Jan 26, 2011 5:13 AM, "Mikael Abrahamsson" wrote: > > On Mon, 24 Jan 2011, R=E9mi Despr=E9s wrote: > >> In the section on overlapping IPv4 addresses (8.1), I suggest to add a small clarification. Its purpose is to remind the relationship that exists between overlapping RFC 1918 IPv4 address spaces and the 6rd of RFC 5969. > > > I think this is a good idea to point out in the document. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001517576eb23c66b5049abfbea0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


I disagree.=A0 6rd has been rejected by 3gpp as a transition tool. The scop= e of this doc is just summarizing existing 3gpp tools and technologies.

RD ... please respect the agreed scope and take the 6rd sales pitch off = line.

Cb

On Jan 26, 2011 5:13 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Mon, 24 Jan 2011, R=E9mi Despr=E9s wrote:
>
>> In the section on overlapping IPv4 addresses (8.1), I suggest to a= dd a small clarification. Its purpose is to remind the relationship that ex= ists between overlapping RFC 1918 IPv4 address spaces and the 6rd of RFC 59= 69.
>
>
> I think this is a good idea to point out in the document.
>
> --
> Mikael Abrahamsson =A0 =A0email: s= wmike@swm.pp.se
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001517576eb23c66b5049abfbea0-- From Wesley.E.George@sprint.com Wed Jan 26 07:52:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BBD3A659B for ; Wed, 26 Jan 2011 07:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 0DQUM3FU7VhP for ; Wed, 26 Jan 2011 07:52:20 -0800 (PST) Received: from VA3EHSOBE007.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id CE8343A63D3 for ; Wed, 26 Jan 2011 07:52:19 -0800 (PST) Received: from mail172-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.8; Wed, 26 Jan 2011 15:55:19 +0000 Received: from mail172-va3 (localhost.localdomain [127.0.0.1]) by mail172-va3-R.bigfish.com (Postfix) with ESMTP id BD851FC03BA; Wed, 26 Jan 2011 15:55:19 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(z4562mz1418M4015L9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail172-va3 (localhost.localdomain [127.0.0.1]) by mail172-va3 (MessageSwitch) id 1296057319206662_14826; Wed, 26 Jan 2011 15:55:19 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.250]) by mail172-va3.bigfish.com (Postfix) with ESMTP id 2E19C17A0052; Wed, 26 Jan 2011 15:55:19 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 26 Jan 2011 15:55:15 +0000 Received: from PDAWEH02.ad.sprint.com (PDAWEH02.corp.sprint.com [144.226.111.42]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0QFsui6014421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jan 2011 09:55:14 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH02.ad.sprint.com ([2002:90e2:6f2a::90e2:6f2a]) with mapi id 14.01.0270.001; Wed, 26 Jan 2011 09:55:03 -0600 From: "George, Wes E [NTK]" To: "Livingood, Jason" , "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OJPjZw6A Date: Wed, 26 Jan 2011 15:55:01 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E0684D4@PLSWM12A.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.20] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0092_01CBBD47.790FD700" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:52:23 -0000 ------=_NextPart_000_0092_01CBBD47.790FD700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I=92ll give this a better review shortly, but wanted to respond to this = one specifically.=20 I think that overall your proposed recommendation text is a good idea. However, personally I=92d remove the reference to Google. As much as I appreciate the info that Lorenzo and Erik and company have provided and = the work that they=92ve done, let=92s keep this company agnostic =96 = that=92s more appropriate for an IETF draft, and less likely to skew opinions in one direction or the other. You might also want to at least casually mention world IPv6 day as a way = to determine if whitelisting is actually necessary even in the short term. Since this draft will have likely gone to WGLC before that happens, at = least a passing reference to it would allow you to perhaps nudge the reader = into looking for the information that will become available once everyone analyzes the results of enabling unfettered IPv6 access to their content = for the day. Thanks,=20 Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Livingood, Jason Sent: Tuesday, January 25, 2011 4:19 PM To: v6ops@ietf.org Subject: [v6ops] v6-aaaa-whitelisting-implications -- Recommended = Practice? (This is the final specific request for feedback on this draft.) re=A0http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implica= tions -01.tx One question raised at the last IETF meeting was whether this draft = should make some statement at the end of the I-D saying whether or not this is = a recommended practice. Alternatively, this can be done as a separate document. However, if the WG believes it useful to make a statement on = this practice, I think it simpler and more expedient to add it to this = document. If the WG agrees, then I propose to add a section saying something along = the lines of: Section Name: Is DNS Whitelisting a Recommended Practice? or=A0 Section Name: Is DNS Whitelisting a Best Practice? Section Content: Opinions in the Internet community concerning whether = or not DNS whitelisting is a recommended practice are understandably quite varied. However, there is clear consensus that DNS whitelisting is at = best a useful temporary measure which a domain may choose to pursue as they = prepare for the transition to IPv6. In particular, major domains such as those operated by Google view DNS whitelisting as one of the few practical and = low risk approaches enabling them to prepare for the transition to IPv6. = Thus, DNS whitelisting is not a recommended practice over the long-term. In addition, DNS whitelisting should be avoided wherever possible in the short-term and its use is discouraged. Nevertheless, major domains may = find DNS whitelisting a beneficial temporary tactic in their transition to = IPv6. Such temporary use during the transition to IPv6 is broadly accepted = within the community, so long as it does not become a long-term practice over a period of a year or more past the point when IANA's IPv4 address pool is depleted. -- JL ------=_NextPart_000_0092_01CBBD47.790FD700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMjYxNTU0NThaMCMGCSqGSIb3DQEJBDEWBBQM4bYXa2Qy C+Bgc1XQE9ME7wx42DBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYB/nA6dM57Jp0zd tepQuyzx7dN1wY3X2YZ+rYlo4Ftgbp9N2Iq6J0f9bLRO5erZgNp8X53uRxxerFBnruDhF4TseX5o vSuD1Cdm4u43rMsV8ViNnZy9OzWGrRnQPePyw+yds9p/dt5vpMNzWB1F9S5lDH/A69FlVAye4f3D byuTdwAAAAAAAA== ------=_NextPart_000_0092_01CBBD47.790FD700-- From remi.despres@free.fr Wed Jan 26 08:13:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB45A3A67D2 for ; Wed, 26 Jan 2011 08:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 UBM4sjJEo59H for ; Wed, 26 Jan 2011 08:13:58 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id A9D8B3A6768 for ; Wed, 26 Jan 2011 08:13:57 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 2A0777000099; Wed, 26 Jan 2011 17:16:55 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 9AFD57000094; Wed, 26 Jan 2011 17:16:54 +0100 (CET) X-SFR-UUID: 20110126161654634.9AFD57000094@msfrf2319.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: Date: Wed, 26 Jan 2011 17:16:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG , Guillaume Leclanche Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:13:58 -0000 Le 26 janv. 2011 =E0 14:23, Cameron Byrne a =E9crit : > I disagree. 6rd has been rejected by 3gpp as a transition tool. I have doubts that it was considered by 3GPP with enough understanding = that 6rd works also for operators that assign RFC 1918 IPv4 addresses. New ideas are sometimes cause of progress. Someone of Tele2 (not a minor operator), interested in noting that 6rd = can be used in some 3GPP configurations is IMHO very significant. I add Guillaume Leclanche of Swisscom (another operator) as cc, because = I know he also has some interest in 6rd/3GPP. =20 > The scope of this doc is just summarizing existing 3gpp tools and = technologies. The draft "describes the support for IPv6 in 3GPP network = architectures."=20 Noting that, in 3GPP configurations of sec 8.1 (overlapping IPv4 = addresses), 6rd is its own application scope does fit in the document.=20= (That is a "recommendation" to use it that would have been off scope, = several other solutions being described, and none being recommended.) > RD ... please respect the agreed scope and take the 6rd sales pitch = off line. It would be easier if you would keep the anti-6rd pitch offline. And please note that I don't have any product to sell, just the desire = to see the IETF promote rapid deployment of native IPv6 addresses. RD =20 >=20 > Cb >=20 > On Jan 26, 2011 5:13 AM, "Mikael Abrahamsson" = wrote: > > > > On Mon, 24 Jan 2011, R=E9mi Despr=E9s wrote: > > > >> In the section on overlapping IPv4 addresses (8.1), I suggest to = add a small clarification. Its purpose is to remind the relationship = that exists between overlapping RFC 1918 IPv4 address spaces and the 6rd = of RFC 5969. > > > > > > I think this is a good idea to point out in the document. > > > > --=20 > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From ek@google.com Wed Jan 26 08:57:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656BD3A6905 for ; Wed, 26 Jan 2011 08:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.416 X-Spam-Level: X-Spam-Status: No, score=-104.416 tagged_above=-999 required=5 tests=[AWL=-3.279, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, 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 JhXvV+qGxjOp for ; Wed, 26 Jan 2011 08:57:40 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 34A203A6814 for ; Wed, 26 Jan 2011 08:57:40 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p0QH0ekP009276 for ; Wed, 26 Jan 2011 09:00:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296061240; bh=HMefkJsrv2TJWcAeWz6blOiovos=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=nIYWk5S2EqTkokMRduCZMu/tUyigiugRD0NJCtUZHAoAB/GZIMoI7nyGMtDOfwZA8 YGfxPTKP5HnNK+XannzWw== Received: from iwn6 (iwn6.prod.google.com [10.241.68.70]) by wpaz29.hot.corp.google.com with ESMTP id p0QH0SGV025465 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 09:00:39 -0800 Received: by iwn6 with SMTP id 6so1174612iwn.29 for ; Wed, 26 Jan 2011 09:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nAKuHJkUdWZB3bdCzzagX6RD/3NIHDeCcNOmjV1sgG4=; b=ulTJHPaaxE4ane0IMy68CvMtDRF0OJsQ7jb5wumh1QF7uXbSoX/V80cRxtVfWXrsc3 4/t20wVVsJb5tuc4tIBQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FY63lk5okft1FwWo0/LuMxE2HL+HD3B7nSPPAzlKy8JIbF7lp6KEqbzdlS1lhiaA/z Xsu9WSoTV3uKYwmU9PRQ== MIME-Version: 1.0 Received: by 10.231.37.138 with SMTP id x10mr8448279ibd.192.1296061238650; Wed, 26 Jan 2011 09:00:38 -0800 (PST) Received: by 10.231.26.157 with HTTP; Wed, 26 Jan 2011 09:00:38 -0800 (PST) In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E0684D4@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E0684D4@PLSWM12A.ad.sprint.com> Date: Thu, 27 Jan 2011 02:00:38 +0900 Message-ID: From: Erik Kline To: "George, Wes E [NTK]" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "v6ops@ietf.org" , "Livingood, Jason" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:57:41 -0000 You might also want to explain where the SWAG about "one year from IANA runout" comes from. It appears a little arbitrary. Remember: there's 15 years of failed transition to overcome. It will take as long as it takes. On 27 January 2011 00:55, George, Wes E [NTK] wrote: > I=E2=80=99ll give this a better review shortly, but wanted to respond to = this one > specifically. > I think that overall your proposed recommendation text is a good idea. > However, personally I=E2=80=99d remove the reference to Google. As much a= s I > appreciate the info that Lorenzo and Erik and company have provided and t= he > work that they=E2=80=99ve done, let=E2=80=99s keep this company agnostic = =E2=80=93 that=E2=80=99s more > appropriate for an IETF draft, and less likely to skew opinions in one > direction or the other. > > You might also want to at least casually mention world IPv6 day as a way = to > determine if whitelisting is actually necessary even in the short term. > Since this draft will have likely gone to WGLC before that happens, at le= ast > a passing reference to it would allow you to perhaps nudge the reader int= o > looking for the information that will become available once everyone > analyzes the results of enabling unfettered IPv6 access to their content = for > the day. > > Thanks, > Wes George > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Livingood, Jason > Sent: Tuesday, January 25, 2011 4:19 PM > To: v6ops@ietf.org > Subject: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practic= e? > > (This is the final specific request for feedback on this draft.) > > re=C2=A0http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-impl= ications > -01.tx > > One question raised at the last IETF meeting was whether this draft shoul= d > make some statement at the end of the I-D saying whether or not this is a > recommended practice. Alternatively, this can be done as a separate > document. However, if the WG believes it useful to make a statement on th= is > practice, I think it simpler and more expedient to add it to this documen= t. > > If the WG agrees, then I propose to add a section saying something along = the > lines of: > > Section Name: Is DNS Whitelisting a Recommended Practice? > or > Section Name: Is DNS Whitelisting a Best Practice? > > Section Content: Opinions in the Internet community concerning whether or > not DNS whitelisting is a recommended practice are understandably quite > varied. However, there is clear consensus that DNS whitelisting is at bes= t a > useful temporary measure which a domain may choose to pursue as they prep= are > for the transition to IPv6. In particular, major domains such as those > operated by Google view DNS whitelisting as one of the few practical and = low > risk approaches enabling them to prepare for the transition to IPv6. Thus= , > DNS whitelisting is not a recommended practice over the long-term. In > addition, DNS whitelisting should be avoided wherever possible in the > short-term and its use is discouraged. Nevertheless, major domains may fi= nd > DNS whitelisting a beneficial temporary tactic in their transition to IPv= 6. > Such temporary use during the transition to IPv6 is broadly accepted with= in > the community, so long as it does not become a long-term practice over a > period of a year or more past the point when IANA's IPv4 address pool is > depleted. > > -- JL > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From victor.kuarsingh@gmail.com Wed Jan 26 09:54:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7553A67BD for ; Wed, 26 Jan 2011 09:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 fclIcx+awFnz for ; Wed, 26 Jan 2011 09:54:44 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 23AF13A67B3 for ; Wed, 26 Jan 2011 09:54:44 -0800 (PST) Received: by vws7 with SMTP id 7so480090vws.31 for ; Wed, 26 Jan 2011 09:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=Od4TsoElop/yif6YvlqymbgCJrtY87/1cqKW0O2LRuA=; b=TQBKA/OC1rA5opiXQIQMZGRwm+gqU3JYGdxADNcmOw0fMrk/ndFnC7TKFmb0qmJqjk 69WpigCCp6PDN1aBITH7KOp8J65xusgc1BTYNgXmDFD7Q3KxSLNRCHxiH7u7SILRGQ8E 8NPX9RAARphQjplKREefHvWwLVyXRz9cw24yg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; b=G6WxpvBUXlsn2V7h4iL6DIZUAZ5YKtnaflj/l8PMweQHOO6wltoPUEbE4TClhnCj+v FZYh4P+xQp1zz8roEuX7Z8+o2aBjVL6465UvWrzMCgvnj9/ttvrjFb4RwfP1Tl6XZNGU 0TV5NY2jvVX5K/HQpbXXBRuVDX+ZZfrnXpckQ= Received: by 10.220.202.73 with SMTP id fd9mr2065364vcb.8.1296064663260; Wed, 26 Jan 2011 09:57:43 -0800 (PST) Received: from [10.10.19.91] ([66.185.87.27]) by mx.google.com with ESMTPS id u4sm5180808vch.36.2011.01.26.09.57.39 (version=SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 09:57:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 26 Jan 2011 13:02:56 -0500 From: Victor Kuarsingh To: "George, Wes E [NTK]" , "Livingood, Jason" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E0684D4@PLSWM12A.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="Big5" Content-transfer-encoding: 7bit Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 17:54:45 -0000 Jason, I would agree with Wes on this, perhaps we can we can remove Google as a reference and make it generic. I do however like the the overall text and direction of the new section. Regards, Victor K On 26/01/11 10:55 AM, "George, Wes E [NTK]" wrote: >I?ll give this a better review shortly, but wanted to respond to this one >specifically. >I think that overall your proposed recommendation text is a good idea. >However, personally I?d remove the reference to Google. As much as I >appreciate the info that Lorenzo and Erik and company have provided and >the >work that they?ve done, let?s keep this company agnostic ? that?s more >appropriate for an IETF draft, and less likely to skew opinions in one >direction or the other. > >You might also want to at least casually mention world IPv6 day as a way >to >determine if whitelisting is actually necessary even in the short term. >Since this draft will have likely gone to WGLC before that happens, at >least >a passing reference to it would allow you to perhaps nudge the reader into >looking for the information that will become available once everyone >analyzes the results of enabling unfettered IPv6 access to their content >for >the day. > >Thanks, >Wes George > > >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >Livingood, Jason >Sent: Tuesday, January 25, 2011 4:19 PM >To: v6ops@ietf.org >Subject: [v6ops] v6-aaaa-whitelisting-implications -- Recommended >Practice? > >(This is the final specific request for feedback on this draft.) > >re >http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implications >-01.tx > >One question raised at the last IETF meeting was whether this draft should >make some statement at the end of the I-D saying whether or not this is a >recommended practice. Alternatively, this can be done as a separate >document. However, if the WG believes it useful to make a statement on >this >practice, I think it simpler and more expedient to add it to this >document. > >If the WG agrees, then I propose to add a section saying something along >the >lines of: > >Section Name: Is DNS Whitelisting a Recommended Practice? >or >Section Name: Is DNS Whitelisting a Best Practice? > >Section Content: Opinions in the Internet community concerning whether or >not DNS whitelisting is a recommended practice are understandably quite >varied. However, there is clear consensus that DNS whitelisting is at >best a >useful temporary measure which a domain may choose to pursue as they >prepare >for the transition to IPv6. In particular, major domains such as those >operated by Google view DNS whitelisting as one of the few practical and >low >risk approaches enabling them to prepare for the transition to IPv6. Thus, >DNS whitelisting is not a recommended practice over the long-term. In >addition, DNS whitelisting should be avoided wherever possible in the >short-term and its use is discouraged. Nevertheless, major domains may >find >DNS whitelisting a beneficial temporary tactic in their transition to >IPv6. >Such temporary use during the transition to IPv6 is broadly accepted >within >the community, so long as it does not become a long-term practice over a >period of a year or more past the point when IANA's IPv4 address pool is >depleted. > >-- JL >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From martin@millnert.se Wed Jan 26 10:31:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C6B3A687A for ; Wed, 26 Jan 2011 10:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[AWL=-1.820, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, SARE_LWSHORTT=1.24] 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 mNh2S5AP2TK5 for ; Wed, 26 Jan 2011 10:30:16 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 5558E3A67D8 for ; Wed, 26 Jan 2011 10:30:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id D9FBB777E; Wed, 26 Jan 2011 19:36:16 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwMGtZStHzHS; Wed, 26 Jan 2011 19:36:16 +0100 (CET) Received: from [161.44.180.156] (dhcp-161-44-180-156.cisco.com [161.44.180.156]) by ncis.csbnet.se (Postfix) with ESMTPSA id BEC6C76C2; Wed, 26 Jan 2011 19:36:14 +0100 (CET) From: Martin Millnert To: Victor Kuarsingh In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Jan 2011 13:33:06 -0500 Message-ID: <1296066786.6995.33.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "Livingood, Jason" , "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:31:13 -0000 On Wed, 2011-01-26 at 13:02 -0500, Victor Kuarsingh wrote: > Jason, > > I would agree with Wes on this, perhaps we can we can remove Google as a > reference and make it generic. I do however like the the overall text and > direction of the new section. I agree with the above. The Comcast vs Google scent of it right now makes it look, to me at least, a little like a blog post from comcast.com that found its way onto www.ietf.org. I believe the text will work better in generic form. Something doesn't feel right with this sentence: 'As a result, it is worth considering that IPv4-related impairment could exceed that of IPv6-related impairment and that such IPv4-related impairment may have simply been accepted as "background noise" on the Internet for a variety of reasons.' I think it's the "could" there. It comes across (to me) as apparent guesswork, which would do well with more [citations] and references, and pointers/suggestions to further work/research, to find out if this is the case or not. IMHO. Because essentially, this relates to the core motivation behind doing a AAAA whitelist in the first place (introducing AAAA records leading to fewer total users being able to successfully reach a service than not doing it), and would do well with basically an answer to whether or not this is the case. Regards, Martin > On 26/01/11 10:55 AM, "George, Wes E [NTK]" > wrote: > > >I?ll give this a better review shortly, but wanted to respond to this one > >specifically. > >I think that overall your proposed recommendation text is a good idea. > >However, personally I?d remove the reference to Google. As much as I > >appreciate the info that Lorenzo and Erik and company have provided and > >the > >work that they?ve done, let?s keep this company agnostic ? that?s more > >appropriate for an IETF draft, and less likely to skew opinions in one > >direction or the other. > > > >You might also want to at least casually mention world IPv6 day as a way > >to > >determine if whitelisting is actually necessary even in the short term. > >Since this draft will have likely gone to WGLC before that happens, at > >least > >a passing reference to it would allow you to perhaps nudge the reader into > >looking for the information that will become available once everyone > >analyzes the results of enabling unfettered IPv6 access to their content > >for > >the day. > > > >Thanks, > >Wes George > > > > > >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > >Livingood, Jason > >Sent: Tuesday, January 25, 2011 4:19 PM > >To: v6ops@ietf.org > >Subject: [v6ops] v6-aaaa-whitelisting-implications -- Recommended > >Practice? > > > >(This is the final specific request for feedback on this draft.) > > > >re > >http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implications > >-01.tx > > > >One question raised at the last IETF meeting was whether this draft should > >make some statement at the end of the I-D saying whether or not this is a > >recommended practice. Alternatively, this can be done as a separate > >document. However, if the WG believes it useful to make a statement on > >this > >practice, I think it simpler and more expedient to add it to this > >document. > > > >If the WG agrees, then I propose to add a section saying something along > >the > >lines of: > > > >Section Name: Is DNS Whitelisting a Recommended Practice? > >or > >Section Name: Is DNS Whitelisting a Best Practice? > > > >Section Content: Opinions in the Internet community concerning whether or > >not DNS whitelisting is a recommended practice are understandably quite > >varied. However, there is clear consensus that DNS whitelisting is at > >best a > >useful temporary measure which a domain may choose to pursue as they > >prepare > >for the transition to IPv6. In particular, major domains such as those > >operated by Google view DNS whitelisting as one of the few practical and > >low > >risk approaches enabling them to prepare for the transition to IPv6. Thus, > >DNS whitelisting is not a recommended practice over the long-term. In > >addition, DNS whitelisting should be avoided wherever possible in the > >short-term and its use is discouraged. Nevertheless, major domains may > >find > >DNS whitelisting a beneficial temporary tactic in their transition to > >IPv6. > >Such temporary use during the transition to IPv6 is broadly accepted > >within > >the community, so long as it does not become a long-term practice over a > >period of a year or more past the point when IANA's IPv4 address pool is > >depleted. > > > >-- JL > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jason_livingood@cable.comcast.com Wed Jan 26 17:15:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431503A68F6 for ; Wed, 26 Jan 2011 17:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.939 X-Spam-Level: X-Spam-Status: No, score=-104.939 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, 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 gpiTBNl6MCCM for ; Wed, 26 Jan 2011 17:15:47 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id F1D043A68F5 for ; Wed, 26 Jan 2011 17:15:46 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.111934730; Wed, 26 Jan 2011 20:18:46 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 26 Jan 2011 20:18:46 -0500 From: "Livingood, Jason" To: "George, Wes E [NTK]" , "v6ops@ietf.org" Thread-Topic: v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OJPjZw6AgACIYYA= Date: Thu, 27 Jan 2011 01:18:45 +0000 Message-ID: In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E0684D4@PLSWM12A.ad.sprint.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: multipart/alternative; boundary="_000_C9661B6615ADDjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 01:15:48 -0000 --_000_C9661B6615ADDjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 SG93ZXZlciwgcGVyc29uYWxseSBJP2QgcmVtb3ZlIHRoZSByZWZlcmVuY2UgdG8gR29vZ2xlLiBB cyBtdWNoIGFzIEkgYXBwcmVjaWF0ZSB0aGUgaW5mbyB0aGF0IExvcmVuem8gYW5kIEVyaWsgYW5k IGNvbXBhbnkgaGF2ZSBwcm92aWRlZCBhbmQgdGhlIHdvcmsgdGhhdCB0aGV5P3ZlIGRvbmUsIGxl dD9zIGtlZXAgdGhpcyBjb21wYW55IGFnbm9zdGljID8gdGhhdD9zIG1vcmUgYXBwcm9wcmlhdGUg Zm9yIGFuIElFVEYgZHJhZnQsIGFuZCBsZXNzIGxpa2VseSB0byBza2V3IG9waW5pb25zIGluIG9u ZSBkaXJlY3Rpb24gb3IgdGhlIG90aGVyLg0KDQpUaGF0IGlzIGEgZmFpciBwb2ludC4gSSB3YXMg YWN0dWFsbHkgdHJ5aW5nIHRvIHJlYWN0IHRvIGZlZWRiYWNrIGZyb20gRXJpayBoaW1zZWxmIG9u IDEwLzEvMjAxMCB0byB0aGUgbGlzdCB3aGVyZSBJIHBlcmNlaXZlZCBoZSB3YW50ZWQgdG8gaGF2 ZSB0aGUgbnVtZXJvdXMgdmFndWUgInNvbWUgcGFydGllcyIgbWFkZSBtb3JlIHNwZWNpZmljLiBJ IHdhbnQgdG8gYWxzbyBiZSBjbGVhciB0aGF0IEkgd2VudCB0byBwYWlucyBpbiBteSBwcmV2aW91 cyBkcmFmdHMgYW5kIGluIG15IHByZXNlbnRhdGlvbnMgdG8gbm90IGNpdGUgc3BlY2lmaWMgY29t cGFueSBuYW1lcywgYXMgdGhpcyBpcyBhbiBpbmR1c3RyeSBpc3N1ZSBhbmQgbm90IGEgY29tcGFu eSBpc3N1ZS4gSSB3aWxsIGNhcmVmdWxseSBnbyBiYWNrIHRocm91Z2ggbXkgoVYwMSB2ZXJzaW9u IGFuZCBjaGFuZ2UgdGhlc2UgcmVmZXJlbmNlcyBiYWNrLiBJIHdpbGwgYWxzbyBjaGFuZ2UgdGhp cyBhZGRpdGlvbiBhcyB3ZWxsLiAgKFNlZSBiZWxvdykNCg0KWW91IG1pZ2h0IGFsc28gd2FudCB0 byBhdCBsZWFzdCBjYXN1YWxseSBtZW50aW9uIHdvcmxkIElQdjYgZGF5IGFzIGEgd2F5IHRvDQpk ZXRlcm1pbmUgaWYgd2hpdGVsaXN0aW5nIGlzIGFjdHVhbGx5IG5lY2Vzc2FyeSBldmVuIGluIHRo ZSBzaG9ydCB0ZXJtLg0KU2luY2UgdGhpcyBkcmFmdCB3aWxsIGhhdmUgbGlrZWx5IGdvbmUgdG8g V0dMQyBiZWZvcmUgdGhhdCBoYXBwZW5zLCBhdCBsZWFzdA0KYSBwYXNzaW5nIHJlZmVyZW5jZSB0 byBpdCB3b3VsZCBhbGxvdyB5b3UgdG8gcGVyaGFwcyBudWRnZSB0aGUgcmVhZGVyIGludG8NCmxv b2tpbmcgZm9yIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgYmVjb21lIGF2YWlsYWJsZSBvbmNl IGV2ZXJ5b25lDQphbmFseXplcyB0aGUgcmVzdWx0cyBvZiBlbmFibGluZyB1bmZldHRlcmVkIElQ djYgYWNjZXNzIHRvIHRoZWlyIGNvbnRlbnQgZm9yDQp0aGUgZGF5Lg0KDQpHb29kIHN1Z2dlc3Rp b24uIEhlcmUgaXMgdGhlIG5ldyB0ZXh0Og0KDQogICAgICAgICAgICBPcGluaW9ucyBpbiB0aGUg SW50ZXJuZXQgY29tbXVuaXR5IGNvbmNlcm5pbmcgd2hldGhlciBvciBub3QgRE5TIHdoaXRlbGlz dGluZyBpcyBhIHJlY29tbWVuZGVkIHByYWN0aWNlIGFyZSB1bmRlcnN0YW5kYWJseSBxdWl0ZSB2 YXJpZWQuIEhvd2V2ZXIsIHRoZXJlIGlzIGNsZWFyIGNvbnNlbnN1cyB0aGF0IEROUyB3aGl0ZWxp c3RpbmcgaXMgYXQgYmVzdCBhIHVzZWZ1bCB0ZW1wb3JhcnkgbWVhc3VyZSB3aGljaCBhIGRvbWFp biBtYXkgY2hvb3NlIHRvIHB1cnN1ZSBhcyB0aGV5IHByZXBhcmUgZm9yIHRoZSB0cmFuc2l0aW9u IHRvIElQdjYuIEluIHBhcnRpY3VsYXIsIG1ham9yIGRvbWFpbnMgdmlldyBETlMgd2hpdGVsaXN0 aW5nIGFzIG9uZSBvZiB0aGUgZmV3IHByYWN0aWNhbCBhbmQgbG93IHJpc2sgYXBwcm9hY2hlcyBl bmFibGluZyB0aGVtIHRvIHByZXBhcmUgZm9yIHRoZSB0cmFuc2l0aW9uIHRvIElQdjYuIFRodXMs IEROUyB3aGl0ZWxpc3RpbmcgaXMgbm90IGEgcmVjb21tZW5kZWQgcHJhY3RpY2Ugb3ZlciB0aGUg bG9uZy10ZXJtLiBJbiBhZGRpdGlvbiwgRE5TIHdoaXRlbGlzdGluZyBzaG91bGQgYmUgYXZvaWRl ZCB3aGVyZXZlciBwb3NzaWJsZSBpbiB0aGUgc2hvcnQtdGVybSBhbmQgaXRzIHVzZSBpcyBkaXNj b3VyYWdlZC4gTmV2ZXJ0aGVsZXNzLCBtYWpvciBkb21haW5zIG1heSBmaW5kIEROUyB3aGl0ZWxp c3RpbmcgYSBiZW5lZmljaWFsIHRlbXBvcmFyeSB0YWN0aWMgaW4gdGhlaXIgdHJhbnNpdGlvbiB0 byBJUHY2LiBTdWNoIHRlbXBvcmFyeSB1c2UgZHVyaW5nIHRoZSB0cmFuc2l0aW9uIHRvIElQdjYg aXMgYnJvYWRseSBhY2NlcHRlZCB3aXRoaW4gdGhlIGNvbW11bml0eSwgc28gbG9uZyBhcyBpdCBk b2VzIG5vdCBiZWNvbWUgYSBsb25nLXRlcm0gcHJhY3RpY2UuDQoNCiAgICAgICAgICAgIEZpbmFs bHksIFdvcmxkIElQdjYgRGF5LCB3aGljaCBpcyBzcG9uc29yZWQgYnkgdGhlIEludGVybmV0IFNv Y2lldHkgW0FERCBSRUZFUkVOQ0VdIGFuZCBpcyBzY2hlZHVsZWQgdG8gb2NjdXIgb24gSnVuZSA4 LCAyMDExLCB3aWxsIGJlIGFuIG9wcG9ydHVuaXR5IGZvciBkb21haW5zIHRvIGFkZCBBQUFBIHJl c291cmNlIHJlY29yZHMgdG8gdGhlIEROUyB3aXRob3V0IHVzaW5nIEROUyB3aGl0ZWxpc3Rpbmcu IEFzIGEgcmVzdWx0LCB0aGlzIGlzIGxpa2VseSBhbiBleGNlbGxlbnQgb3Bwb3J0dW5pdHkgZm9y IGRvbWFpbnMgdG8gZXZhbHVhdGUgdGhlIHV0aWxpdHkgb3IgbmVjZXNzaXR5IG9mIEROUyB3aGl0 ZWxpc3RpbmcsIGV2ZW4gaW4gdGhlIHNob3J0LXRlcm0uDQoNCi8vDQoNCg0K --_000_C9661B6615ADDjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="big5" Content-ID: <5E11FF54C96FB940A8F592720C3B32F0@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
However, personally I?d remove the reference to Google. As much as I&n= bsp;appreciate the info that Lorenzo and Erik and company have provided and= the work that they?ve done, let?s keep this company agnostic ? that?s= more appropriate for an IETF draft, and less likely to skew opinions in one direction or the other.

That is a fair point. I was actually trying to react to feedback from = Erik himself on 10/1/2010 to the list where I perceived he wanted to have t= he numerous vague "some parties" made more specific. I want to al= so be clear that I went to pains in my previous drafts and in my presentations to not cite specific company names, as this= is an industry issue and not a company issue. I will carefully go back thr= ough my =A1V01 version and change these references back. I will also change= this addition as well.  (See below)

You might also want to at least casually mention world IPv6 day as a w= ay to
determine if whitelisting is actually necessary even in the short term= .
Since this draft will have likely gone to WGLC before that happens, at= least
a passing reference to it would allow you to perhaps nudge the reader = into
looking for the information that will become available once everyone
analyzes the results of enabling unfettered IPv6 access to their conte= nt for
the day.

Good suggestion. Here is the new text:

            Opinions in the Inte= rnet community concerning whether or not DNS whitelisting is a recommended = practice are understandably quite varied. However, there is clear consensus= that DNS whitelisting is at best a useful temporary measure which a domain may choose to pursue as they prepare for the transition to IPv6. = In particular, major domains view DNS whitelisting as one of the few practi= cal and low risk approaches enabling them to prepare for the transition to = IPv6. Thus, DNS whitelisting is not a recommended practice over the long-term. In addition, DNS whitelisti= ng should be avoided wherever possible in the short-term and its use is dis= couraged. Nevertheless, major domains may find DNS whitelisting a beneficia= l temporary tactic in their transition to IPv6. Such temporary use during the transition to IPv6 is broadly accep= ted within the community, so long as it does not become a long-term practic= e.
            
            Finally, World IPv6 = Day, which is sponsored by the Internet Society [ADD REFERENCE] and is sche= duled to occur on June 8, 2011, will be an opportunity for domains to add A= AAA resource records to the DNS without using DNS whitelisting. As a result, this is likely an excellent opportunity for domains to evaluate = the utility or necessity of DNS whitelisting, even in the short-term.

//


--_000_C9661B6615ADDjasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Wed Jan 26 17:15:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31293A68F5 for ; Wed, 26 Jan 2011 17:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=1.985, 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 2TeRF6ZPWRxT for ; Wed, 26 Jan 2011 17:15:47 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 9E4243A68F8 for ; Wed, 26 Jan 2011 17:15:47 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.111934720; Wed, 26 Jan 2011 20:18:41 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 26 Jan 2011 20:18:41 -0500 From: "Livingood, Jason" To: Erik Kline , "George, Wes E [NTK]" Thread-Topic: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OJPjZw6AgABoNQCAABwygA== Date: Thu, 27 Jan 2011 01:18:40 +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: <16C4E92894807F489B8000E331F98EDA@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 01:15:48 -0000 >You might also want to explain where the SWAG about "one year from >IANA runout" comes from. It appears a little arbitrary. Remember: >there's 15 years of failed transition to overcome. It will take as >long as it takes. It was completely arbitrary. I was trying to anticipate a question about how long this should be the case (if I did not use a timeframe), and so put in a near-term date in order to provoke discussion, which seems to have been a successful tactic. ;-) Anyway, how about the following, with no timeframe specified? "Such temporary use during the transition to IPv6 is broadly accepted within the community, so long as it does not become a long-term practice [STRIKE] over a period of a year or more past the point when IANA's IPv4 address pool is depleted[/STRIKE]." Alternatively, I could say "...over a reasonable timeframe." Thoughts? Regards Jason From jason_livingood@cable.comcast.com Wed Jan 26 17:15:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771B128C0EF for ; Wed, 26 Jan 2011 17:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=1.911, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j934VT0evXt7 for ; Wed, 26 Jan 2011 17:15:51 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 6AFD428C0EB for ; Wed, 26 Jan 2011 17:15:50 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.111934732; Wed, 26 Jan 2011 20:18:49 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 26 Jan 2011 20:18:49 -0500 From: "Livingood, Jason" To: Victor Kuarsingh , "George, Wes E [NTK]" , "v6ops@ietf.org" Thread-Topic: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OJPjZw6AgAB5nQCAAA8CgA== Date: Thu, 27 Jan 2011 01:18:48 +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: multipart/alternative; boundary="_000_C9661EBF15AF8jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 01:15:52 -0000 --_000_C9661EBF15AF8jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Done. Thanks, Victor. (And see suggested text in my last email to Wes and t= he list.) Jason On 1/26/11 1:02 PM, "Victor Kuarsingh" > wrote: Jason, I would agree with Wes on this, perhaps we can we can remove Google as a reference and make it generic. I do however like the the overall text and direction of the new section. Regards, Victor K --_000_C9661EBF15AF8jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1D2B2A07BA2A5C4CB57D051C9578263A@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Done. Thanks, Victor. (And see suggested text in my last email to Wes = and the list.)

Jason

On 1/26/11 1:02 PM, "Victor Kuarsingh" <victor.kuarsingh@gmail.com> wrote:

Jason,

I would agree with Wes on this, perhaps we can we can remove Google as= a
reference and make it generic.  I do however like the the ov= erall text and
direction of the new section.

Regards,

Victor K
--_000_C9661EBF15AF8jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Wed Jan 26 17:15:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5995328C0F4 for ; Wed, 26 Jan 2011 17:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.619 X-Spam-Level: X-Spam-Status: No, score=-106.619 tagged_above=-999 required=5 tests=[AWL=1.843, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zyxa-299VlZ for ; Wed, 26 Jan 2011 17:15:54 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BE16B28C0EB for ; Wed, 26 Jan 2011 17:15:53 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.111934734; Wed, 26 Jan 2011 20:18:52 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Wed, 26 Jan 2011 20:18:52 -0500 From: "Livingood, Jason" To: Martin Millnert , Victor Kuarsingh Thread-Topic: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OJPjZw6AgAB5nQCAAAhtAIAACSCA Date: Thu, 27 Jan 2011 01:18:50 +0000 Message-ID: In-Reply-To: <1296066786.6995.33.camel@shakira.millnert.se> 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: multipart/alternative; boundary="_000_C9661EED15AFAjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 01:15:55 -0000 --_000_C9661EED15AFAjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Martin =96 Please see inline below. Thank you, - Jason On 1/26/11 1:33 PM, "Martin Millnert" > wrote: On Wed, 2011-01-26 at 13:02 -0500, Victor Kuarsingh wrote: Jason, I would agree with Wes on this, perhaps we can we can remove Google as a reference and make it generic. I do however like the the overall text and direction of the new section. I agree with the above. The Comcast vs Google scent of it right now makes it look, to me at least, a little like a blog post from comcast.com that found its way onto www.ietf.org. I believe the text will work better in generic form. Please see my note to Wes. This was in no way, shape, or form my intention.= In fact, I was actually trying to be responsive to some old feedback from = Erik himself, and perhaps did so a bit too enthusiastically or inelegantly.= So it will be made more generic (see my post a moment ago to the list with= the new text). I also want to make 110% clear that I am very complimentary= of the work that Google has done on IPv6 and agree that, for them, whiteli= sting was a logical short-term tactic. My interest with this I-D is to focu= s on the long-term of course. :-) Something doesn't feel right with this sentence: 'As a result, it is worth considering that IPv4-related impairment could exceed that of IPv6-related impairment and that such IPv4-related impairment may have simply been accepted as "background noise" on the Internet for a variety of reasons.' I think it's the "could" there. It comes across (to me) as apparent guesswork, which would do well with more [citations] and references, and pointers/suggestions to further work/research, to find out if this is the case or not. IMHO. Because essentially, this relates to the core motivation behind doing a AAAA whitelist in the first place (introducing AAAA records leading to fewer total users being able to successfully reach a service than not doing it), and would do well with basically an answer to whether or not this is the case. Fair point. It is speculative on my part (and as discussed with other ISPs = / operators). Given that, is it best discussed elsewhere in the document as= speculative or removed or something else in your view? Open to suggestions= on how to resolve this. Thanks Jason Regards, Martin --_000_C9661EED15AFAjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8B5416126E98EF4181E13E317A11322C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Martin =96 Please see inline below.

Thank you,
- Jason


On 1/26/11 1:33 PM, "Martin Millnert" <martin@millnert.se> wrote:

On Wed, 2011-01-26 at 13:02 -0500, Victor Kuarsingh wrote:
Jason,
I would agree with Wes on this, perhaps we can we can remove Google as= a
reference and make it generic.  I do however like the the ov= erall text and
direction of the new section.


I agree with the above.  The Comcast vs Google scent of it r= ight now
makes it look, to me at least, a little like a blog post from
comcast.com that found its way onto www.ietf.org.  I believe= the text
will work better in generic form.

Please see my note to Wes. This was in no way, shape, or form my inten= tion. In fact, I was actually trying to be responsive to some old feedback = from Erik himself, and perhaps did so a bit too enthusiastically or inelega= ntly. So it will be made more generic (see my post a moment ago to the list with the new text). I also want to m= ake 110% clear that I am very complimentary of the work that Google has don= e on IPv6 and agree that, for them, whitelisting was a logical short-term t= actic. My interest with this I-D is to focus on the long-term of course. :-)

Something doesn't feel right with this sentence:
   'As a result, it is worth considering that IPv4-related i= mpairment
    could exceed that of IPv6-related impairment a= nd that such
    IPv4-related impairment may have simply been a= ccepted as "background
    noise" on the Internet for a variety of r= easons.'

I think it's the "could" there.  It comes across (= to me) as apparent
guesswork, which would do well with more [citations] and references, a= nd
pointers/suggestions to further work/research, to find out if this is<= /div>
the case or not. IMHO.  
  Because essentially, this relates to the core motivation b= ehind doing
a AAAA whitelist in the first place (introducing AAAA records leading = to
fewer total users being able to successfully reach a service than not<= /div>
doing it), and would do well with basically an answer to whether or no= t
this is the case.

Fair point. It is speculative on my part (and as discussed with other = ISPs / operators). Given that, is it best discussed elsewhere in the docume= nt as speculative or removed or something else in your view? Open to sugges= tions on how to resolve this.

Thanks
Jason


Regards,
Martin

--_000_C9661EED15AFAjasonlivingoodcablecomcastcom_-- From martin@millnert.se Wed Jan 26 18:43:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB0F3A6A5A for ; Wed, 26 Jan 2011 18:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVivgBg1FCdJ for ; Wed, 26 Jan 2011 18:43:47 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id D7D6E3A6906 for ; Wed, 26 Jan 2011 18:43:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 1F625777E; Thu, 27 Jan 2011 03:49:54 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxQw3OBzs2Ap; Thu, 27 Jan 2011 03:49:54 +0100 (CET) Received: from [192.168.88.253] (c-24-147-137-106.hsd1.ma.comcast.net [24.147.137.106]) by ncis.csbnet.se (Postfix) with ESMTPSA id F15F476C2; Thu, 27 Jan 2011 03:49:52 +0100 (CET) From: Martin Millnert To: "Livingood, Jason" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Jan 2011 21:46:42 -0500 Message-ID: <1296096402.2763.20.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 02:43:48 -0000 Jason, On Thu, 2011-01-27 at 01:18 +0000, Livingood, Jason wrote: > Fair point. It is speculative on my part (and as discussed with other > ISPs / operators). Given that, is it best discussed elsewhere in the > document as speculative or removed or something else in your view? > Open to suggestions on how to resolve this. > I don't think I'm the best person on the plane to answer that. :) My 2 cents are, I guess, that the measurements methods deployed, and more specifically the analysis performed, by participants of the World IPv6 day should be able to answer this for us "once and for all^Wmost" So to the participants of World IPv6 day, it would obviously be extremely valuable for the community if you could: 1) Be as open as possible about how you measure the brokenness, state and explain your assumptions and (if possible), verify/refute as many of them as possible (I too am interested in the answer to the question on how many % of Internet users have broken v4 :) ) 2) Publish the brokenness seen. 2) Save logs or similar in ways that data can be compared using the same methods (it wouldn't hurt with a ~simplified w3c-log-parser fed with logs in an appropriate manner, released to the community), so that there is an at least pseudo-standardized way for the industry to measure this, as it conceivably vary between geographical areas/markets, etc. (comparability / "reproducibility" is quite central to scientific work, right?) I believe the industry share an interest in getting the transition off its wheels, so I hope something along the lines of what I suggest above can be done. It would be awesome, simply, IMO. Now with that suggestion out there, I think it is a valid and fair question to raise in the document, but it should perhaps be explicitly clear that it is speculative to minimize the % of careless readers who mistake it for fact? (Make no mistake: I like and want IPv6 deployed!) Not sure if a specific section on ipv6-% brokeness measurement methods is appropriate, as you say it might be better discussed elsewhere (and instead referenced). [While by no means claiming to be any kind of all-knower on the subject, ] I think the goog-v6-quadrett's paper, "Evaluating IPv6 adoption in the Internet" ( http://www.google.com/research/pubs/pub36240.html ) is a good reference to begin with. HTH, Cheers, Martin From martin@millnert.se Wed Jan 26 18:49:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4E328C0E4 for ; Wed, 26 Jan 2011 18:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM0yiMqujWnR for ; Wed, 26 Jan 2011 18:49:41 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 3A4313A6A5E for ; Wed, 26 Jan 2011 18:49:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id DD869777E; Thu, 27 Jan 2011 03:55:48 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3T6FuAZqdhn; Thu, 27 Jan 2011 03:55:48 +0100 (CET) Received: from [192.168.88.253] (c-24-147-137-106.hsd1.ma.comcast.net [24.147.137.106]) by ncis.csbnet.se (Postfix) with ESMTPSA id 240E276C2; Thu, 27 Jan 2011 03:55:47 +0100 (CET) From: Martin Millnert To: "Livingood, Jason" In-Reply-To: <1296096402.2763.20.camel@shakira.millnert.se> References: <1296096402.2763.20.camel@shakira.millnert.se> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Jan 2011 21:52:38 -0500 Message-ID: <1296096758.2763.23.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 02:49:42 -0000 *chuckle* On Wed, 2011-01-26 at 21:46 -0500, Martin Millnert wrote: > getting the transition off its wheels [...] [...] up in the air, through the building storm of v4-clouds, into the clear blue v6 skies above... ;) Cheers, Martin From Guillaume.Leclanche@swisscom.com Wed Jan 26 22:32:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925813A6AED for ; Wed, 26 Jan 2011 22:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkZfQFHePp7A for ; Wed, 26 Jan 2011 22:32:18 -0800 (PST) Received: from mail.swisscom.com (outmail100.swisscom.com [193.222.81.100]) by core3.amsl.com (Postfix) with ESMTP id A6F033A6AE4 for ; Wed, 26 Jan 2011 22:32:17 -0800 (PST) Received: by intmail1.corproot.net; Thu, 27 Jan 2011 07:35:16 +0100 From: To: , Date: Thu, 27 Jan 2011 07:35:13 +0100 Thread-Topic: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 Thread-Index: Acu9dHedVoEIhu6pRRCfX418X1Ki+AAdhB6w Message-ID: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> In-Reply-To: Accept-Language: fr-FR, de-CH Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, de-CH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 06:32:19 -0000 Pj4gSSBkaXNhZ3JlZS4gIDZyZCBoYXMgYmVlbiByZWplY3RlZCBieSAzZ3BwIGFzIGEgdHJhbnNp dGlvbiB0b29sLg0KDQpDb25jZXJuaW5nIHRoZSA2cmQgcXVlc3Rpb24gd3J0IDNncHA6IHNpbmNl IHlvdSBjYW4gZG8gaXQgd2l0aG91dCBtb2RpZnlpbmcgYW55IG9mIHlvdXIgZGV2aWNlcyBpbiB0 aGUgbW9iaWxlIGFjY2Vzcy9jb3JlIG5ldHdvcmsgKHVuZGVyIHZlcmlmaWNhdGlvbiBmb3IgdXMs IHRoZXJlIG1pZ2h0IGJlIHNvbWUgbGVnYWwgaW1wbGljYXRpb25zKSwgdGhlcmUgaXMgbm8gbmVl ZCB0byByZWZlciB0byAzZ3BwLiBJdCBjYW4gZXZlbiBiZSBjb25zaWRlcmVkIGFzIGEgdXNlcnNw YWNlIHNlcnZpY2UuDQoNClRlY2huaWNhbGx5LCBnaXZlbiB0aGF0IHdlIGRlcGxveWVkIHRoZSA2 cmQgbWFjaGluZXJ5IGZvciByZXNpZGVudGlhbCBhY2Nlc3NlcywgaXQncyBhIG5vLWJyYWluZXIg dG8gYWRkIG9uZSBwb3J0IGFuZCBhIGZldyBsaW5lcyBvZiBjb25maWdzIG9uIHRoZSByb3V0ZXJz LiBBbmQgdGhlbiBpdCdzIHVwIHRvIFVFIHRvIHN1cHBvcnQgaXQgaWYgdGhleSB3YW50IHRvLg0K T2YgY291cnNlLCB5b3UgbmVlZCB0byBnZXQgdGhlIHR1bm5lbGxlZCB0cmFmZmljIGp1c3QgYmVm b3JlIHRoZSBJUHY0IE5BVCBwbGF0Zm9ybSwgbWVhbmluZyB0aGF0IGlmIHlvdSBoYXZlIGRpc3Ry aWJ1dGVkIHlvdXIgTkFUIGFjY3Jvc3MgdGhlIGNvdW50cnkgKHRoYXQncyB0aGUgY2FzZSBmb3Ig eW91IENhbWVyb24sIGlpcmMgPyksIGl0IG1ha2VzIGl0IG1vcmUgY29zdGx5Lg0KDQo+IEkgYWRk IEd1aWxsYXVtZSBMZWNsYW5jaGUgb2YgU3dpc3Njb20gKGFub3RoZXIgb3BlcmF0b3IpIGFzIGNj LCBiZWNhdXNlDQo+IEkga25vdyBoZSBhbHNvIGhhcyBzb21lIGludGVyZXN0IGluIDZyZC8zR1BQ Lg0KDQpJJ20gc3Vic2NyaWJlZCB0byB0aGUgbGlzdCBhbHJlYWR5LCBieSB0aGUgd2F5Lg0KDQpH dWlsbGF1bWUNCg0K From swmike@swm.pp.se Wed Jan 26 22:48:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675543A6AFA for ; Wed, 26 Jan 2011 22:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 nQEY3mTXo+m5 for ; Wed, 26 Jan 2011 22:48:54 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 2098E3A6AF0 for ; Wed, 26 Jan 2011 22:48:53 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D04DDA0; Thu, 27 Jan 2011 07:51:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CEF219A; Thu, 27 Jan 2011 07:51:51 +0100 (CET) Date: Thu, 27 Jan 2011 07:51:51 +0100 (CET) From: Mikael Abrahamsson To: Guillaume.Leclanche@swisscom.com In-Reply-To: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> Message-ID: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 06:48:55 -0000 On Thu, 27 Jan 2011, Guillaume.Leclanche@swisscom.com wrote: > Technically, given that we deployed the 6rd machinery for residential > accesses, it's a no-brainer to add one port and a few lines of configs > on the routers. And then it's up to UE to support it if they want to. My thinking is exactly the same. I'm advocating that we should support (perhaps inofficially) "all" transitional mechanisms, because with DSL, ETTH, mobile (both PCs and phones), both for residential and corporate, we're doing "everything" and currently there is no single way to transition all these technologies. Some will get dual stack, some will get native IPv6 only access, some will stay at native IPv4 only. The ones with single native protocol access still need access to the other address family, so... Tunneling to something that'll fix that. NAT64 is of course on the table as well. If Apple iOS and Android devices are going to support 6RD, we're going to support it too. 3GPP might not like tunneling within their tunneling, but personally I don't care. For me it's IP regardless. -- Mikael Abrahamsson email: swmike@swm.pp.se From teemu.savolainen@nokia.com Thu Jan 27 01:16:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E2D28C119 for ; Thu, 27 Jan 2011 01:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 MLG8hFzLXxem for ; Thu, 27 Jan 2011 01:16:03 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 9A06A28C10E for ; Thu, 27 Jan 2011 01:16:02 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0R9J2ki031519; Thu, 27 Jan 2011 11:19:04 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 11:18:40 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 27 Jan 2011 10:18:29 +0100 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.11]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Thu, 27 Jan 2011 10:18:29 +0100 From: To: , Thread-Topic: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 Thread-Index: AQHLve6+xWDY5l66XEyo9DRMwPPMe5PkiS4g Date: Thu, 27 Jan 2011 09:18:26 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A319340665@008-AM1MPN1-017.mgdnok.nokia.com> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> In-Reply-To: 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: 27 Jan 2011 09:18:40.0852 (UTC) FILETIME=[2FEE5940:01CBBE03] X-Nokia-AV: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 09:16:04 -0000 Have you measured whether eyeballs of cellular handset users are happier or= equally happy when accessing content directly over IPv4 or when through 6R= D? In other words, if a host would implement both 6RD and happy eyeballs, whic= h one would it use for download: IPv4 or IPv6? In the case IPv6 would not provide equal latency and host would end up usin= g IPv4 (as IPv4 connection would complete first), what would be the point o= f having 6RD (until the day IPv6-only services emerge)? Best regards, Teemu > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of ext Mikael Abrahamsson > Sent: 27. tammikuuta 2011 08:52 > To: Guillaume.Leclanche@swisscom.com > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen- > v6ops-3gpp-eps-05 >=20 > On Thu, 27 Jan 2011, Guillaume.Leclanche@swisscom.com wrote: >=20 > > Technically, given that we deployed the 6rd machinery for residential > > accesses, it's a no-brainer to add one port and a few lines of > configs > > on the routers. And then it's up to UE to support it if they want to. >=20 > My thinking is exactly the same. I'm advocating that we should support > (perhaps inofficially) "all" transitional mechanisms, because with DSL, > ETTH, mobile (both PCs and phones), both for residential and corporate, > we're doing "everything" and currently there is no single way to > transition all these technologies. Some will get dual stack, some will > get > native IPv6 only access, some will stay at native IPv4 only. The ones > with > single native protocol access still need access to the other address > family, so... Tunneling to something that'll fix that. NAT64 is of > course > on the table as well. >=20 > If Apple iOS and Android devices are going to support 6RD, we're going > to > support it too. >=20 > 3GPP might not like tunneling within their tunneling, but personally I > don't care. For me it's IP regardless. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Guillaume.Leclanche@swisscom.com Thu Jan 27 04:03:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1F828C133 for ; Thu, 27 Jan 2011 04:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkW+Ub2PLM2C for ; Thu, 27 Jan 2011 04:03:00 -0800 (PST) Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) by core3.amsl.com (Postfix) with ESMTP id 57C963A6ADA for ; Thu, 27 Jan 2011 04:02:59 -0800 (PST) Received: by intmail2.corproot.net; Thu, 27 Jan 2011 13:06:01 +0100 From: To: , Date: Thu, 27 Jan 2011 13:05:58 +0100 Thread-Topic: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 Thread-Index: AQHLve6+xWDY5l66XEyo9DRMwPPMe5PkiS4ggAAsppA= Message-ID: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6E95@sg2019z.corproot.net> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> <056B511A55F8AA42A3E492B7DD19A319340665@008-AM1MPN1-017.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A319340665@008-AM1MPN1-017.mgdnok.nokia.com> Accept-Language: fr-FR, de-CH Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, de-CH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:03:01 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0ZWVtdS5zYXZvbGFpbmVuQG5v a2lhLmNvbSBbbWFpbHRvOnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tXQ0KPiBTZW50OiBUaHVy c2RheSwgSmFudWFyeSAyNywgMjAxMSAxMDoxOCBBTQ0KPiANCj4gSGF2ZSB5b3UgbWVhc3VyZWQg d2hldGhlciBleWViYWxscyBvZiBjZWxsdWxhciBoYW5kc2V0IHVzZXJzIGFyZQ0KPiBoYXBwaWVy IG9yIGVxdWFsbHkgaGFwcHkgd2hlbiBhY2Nlc3NpbmcgY29udGVudCBkaXJlY3RseSBvdmVyIElQ djQgb3INCj4gd2hlbiB0aHJvdWdoIDZSRD8NCg0KT2ggd2UndmUgbm90IG1lYXN1cmVkIGFueXRo aW5nIGluIHRoZSBtb2JpbGUsIGl0J3Mgbm90IGRlcGxveWVkIHlldC4gT3VyIGV4cGVyaWVuY2Ug ZnJvbSB0aGUgcmVzaWRlbnRpYWwgYXJlYSBzaG93cyBlcXVhbCBsYXRlbmN5IHByb3ZpZGVkIHRo YXQgdGhlIHNlcnZpY2VzIGFyZSBjb25uZWN0ZWQgaW4gdGhlIHNhbWUgd2F5IGluIHY0IGFuZCB2 Ni4gSXQgY2FuIGV2ZW4gaGFwcGVuIHRoYXQgdGhlIHY2IGNvbm5lY3Rpb24gaXMgZmFzdGVyIGR1 ZSB0byB0aGUgc2ltcGxlIGZhY3QgdGhhdCBpcHY2IHNlcnZlcnMgYXJlIGxlc3MgbG9hZGVkICh3 aGVuIHNlcnZpY2VzIGFyZSBub3QgZHVhbC1zdGFja2VkIGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVy KQ0KDQo+IEluIG90aGVyIHdvcmRzLCBpZiBhIGhvc3Qgd291bGQgaW1wbGVtZW50IGJvdGggNlJE IGFuZCBoYXBweSBleWViYWxscywNCj4gd2hpY2ggb25lIHdvdWxkIGl0IHVzZSBmb3IgZG93bmxv YWQ6IElQdjQgb3IgSVB2Nj8NCg0KSGFwcHkgZXllYmFsbHMgd291bGQgYmUgdGhlIGRlY2lzaXZl IGZhY3RvciBoZXJlLiA2cmQgaXMganVzdCBwcm92aWRpbmcgSVB2NiBjb25uZWN0aXZpdHkuDQoN Cj4gSW4gdGhlIGNhc2UgSVB2NiB3b3VsZCBub3QgcHJvdmlkZSBlcXVhbCBsYXRlbmN5IGFuZCBo b3N0IHdvdWxkIGVuZCB1cA0KPiB1c2luZyBJUHY0IChhcyBJUHY0IGNvbm5lY3Rpb24gd291bGQg Y29tcGxldGUgZmlyc3QpLCB3aGF0IHdvdWxkIGJlIHRoZQ0KPiBwb2ludCBvZiBoYXZpbmcgNlJE ICh1bnRpbCB0aGUgZGF5IElQdjYtb25seSBzZXJ2aWNlcyBlbWVyZ2UpPw0KDQpUaGUgZ29hbCBp cyB0byBhbGxvdyBJUHY2LW9ubHkgc2VydmljZXMgdG8gZW1lcmdlLiBDaGlja2VuIGFuZCBlZ2cu IEl0J3Mgbm90IHNvbHZpbmcgdGhlIHY0IGV4aGF1c3Rpb24gcHJvYmxlbSwgaXQncyBub3Qgc2lt cGxpZnlpbmcgdGhlIGFyY2hpdGVjdHVyZSwgaXQncyBqdXN0IHByb3ZpZGluZyB2NiBjb25uZWN0 aXZpdHkgdG8gd2hhdGV2ZXIgVUUgd291bGQgc3VwcG9ydCBpdCAoTGludXggPiAyLjYuMzMgb25s eSB0b2RheSkuIEFueSBjYXJyaWVyIHRoYXQgaGFzIGFscmVhZHkgNnJkIGZvciByZXNpZGVudGlh bCBicm9hZGJhbmQgY2FuIHNpbXBseSBlbmFibGUgaXQgb24gdGhlIG1vYmlsZSBuZXR3b3JrIHdp dGhvdXQgYSBsb3Qgb2Ygd29yay4NCg0KR3VpbGxhdW1lDQo= From bzeeb-lists@lists.zabbadoz.net Thu Jan 27 06:27:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15AA3A684E for ; Thu, 27 Jan 2011 06:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=-1.686, BAYES_00=-2.599, FRT_STOCK2=3.988] 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 HeU8MTNa36fo for ; Thu, 27 Jan 2011 06:27:05 -0800 (PST) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by core3.amsl.com (Postfix) with ESMTP id F0B573A686D for ; Thu, 27 Jan 2011 06:27:04 -0800 (PST) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B87BA41C64A; Thu, 27 Jan 2011 15:30:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id I3s0ARN4Xxde; Thu, 27 Jan 2011 15:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id B4A9E41C67E; Thu, 27 Jan 2011 15:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id BAF614448F3; Thu, 27 Jan 2011 14:28:14 +0000 (UTC) Date: Thu, 27 Jan 2011 14:28:14 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: dwing@cisco.com, ayourtch@cisco.com Message-ID: <20110127094607.A39951@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: [v6ops] Comments on draft-wing-v6ops-happy-eyeballs-ipv6-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:27:07 -0000 Hi, (ignore the things that have been said since October already) General comments upfront: - I don't like the name of compnay-of-the-days being used as samples in standards, especially when there is no reference attached to it and if it's just one in a zillion. You should generalize this. - I left some private notes (XXX-BZ) in there that I had at the time of reading. They may either provide information or be addressed at the end. > 1. Introduction > > In order to use HTTP successfully over IPv6, it is necessary that the > user enjoys nearly identical performance as compared to IPv4. A > combination of today's applications, IPv6 tunneling and IPv6 service > providers, and some of today's content providers all cause the user > experience to suffer (Section 3). For IPv6, Google ensures a The thing that makes me currently suffer the most wrt to IPv6 is `magic (or call it bug) in a commercial OS resolver tralala` forcing me to flush caches up to 70 times a day to be able to get to ipv6 enabled sites. This comment to my best understanding is very related to the roots of your draft (but I have yet limited understanding of the actual problem causing this bug to show up for people; it's been reported by multiple, yet not fixed). > While the application recommendations in this document are described > in the context of HTTP clients ("web browsers"), but is useful and > applicable to other time-sensitive applications. I'd remove the `other` here as "web browsing" is all but time-sensitive in the classical meaning. The 300ms you will not really notice for a page-load-time can for some other network usage ruin entire entire companies or cost them fortunes. > 3. Problem Statement > .. > As discussed in more detail in Section 3.2, IPv6 connectivity is > sometimes broken entirely or slower than native IPv4 connectivity. Contrary to my findings over the last years, where IPv6 often was faster or more reliable especially on trans-continental links between the same two dual-stack systems (as seen from DE to CA.US, DE to CA and DE to AU). I have even found that going via some 3rd party IPv6 rather than directly into the destination network at the next IXP using their internal IPv4 transport, IPv6 was still faster. I also like the variance, especially as in the following samples the IPv6 is actually tunnelled and still better. (DE - AU) round-trip min/avg/max/stddev = 332.616/357.183/408.802/28.150 ms round-trip min/avg/max/std-dev = 336.952/338.048/340.461/0.973 ms (DE - CA [east coast]) round-trip min/avg/max/stddev = 129.852/136.686/145.283/5.634 ms round-trip min/avg/max/std-dev = 118.636/120.272/121.628/0.996 ms [I wonder if someone may have the data of a lot more probes somewhere?] So I think, even though pointing to the other section, the above should be a lot more precise or limit things to "very special circumstances" as I think it's just the very obvious brokeness you try to address but you'll also catch the 10ms deltas in other areas unfortunately. > 3.2. IPv6 > > ... > Reasons for such failure include no connection to the IPv6 Internet, > broken 6to4 or Teredo tunnels, and broken IPv6 peering. Hmm, if there is no connection you should get the almost instant notification back and move on. Broken IPv6 peering as much in broken IPv4 peering (I don't think the legacy world is any better). > 1. |<--www.example.com A?-----| | > 2. |<--www.example.com AAAA?--| | > 3. |---192.0.2.1------------->| | > 4. |---2001:dba::1----------->| | Hmm, www.example.com has A and AAAA records; either use those or better 2001:db8:: rather than 2001:dba:: (here and throughout the document). The problem described here, really is not that much IPv6 specific and not much different to just multiple-A records, is it? > The client attempts to connect using IPv6 to the server, but the IPv6 > path is broken (6-8), which consumes several seconds of time. The entire thing strikes me as as general TCP behaviour (often tunable by global MIB variables or per socket options depending on the OS) told how to handle since at least RFC1122 (STD3) section 4.2.3.5. > 4.1. IPv6 I think the section title, if not already for 3.2, at least here is misleading. The very best it descripes "Dual Stack" behaviour. > In diagram above, ... Add 'the'. XXX-BZ revisit (what if there is more than one record returned per address family (AF)) > using IPv4. The IPv6 path is retried until the application gives up > (10). I think given the diagram you should s/the application gives up/TCP times out/ here. > The absolute value of > P is the measure of a delay before initiating a connection attempt on > the other address family. A 'connection attempt' in literature seems to be more the one of the real upper layer protocoal (ULP) connection but what you want to say is "the DNS lookup and connection attempt ..." > The TCP client application starts two threads in order to minimize > the user-noticeable delay ("dead time") during the connection > attempts: I think the draft should not enforce how to implement things. Threads are just one way to implement the expected (concurrent) behaviour. I would love to see the word 'thread' to go away from the draft completely or detailed that other ways to implement the expected behaviour may equally be chosen. > * If P<0, wait for absolute value of p*10 milliseconds Mix of 'P' and 'p'. Should be all upper-case? XXX-BZ revist - which P is this - the per destination or the global? (should be disambiguated throughout the entire draft Ps (P socket) and Pa (P application) or similar and one or the other or both mentioned explicitly where appropriate. > The value of P > is incremented (decremented) each time an IPv6 (IPv4) connection is > successfully made. I felt this is inaccurate. Both IPv4 and IPv6 connections could succeed, even before you can cancel the other (connection|thread), so I think you mean s/is successfully made/wins the race/. > When a connection using the less-preferred > address family is successful, it indicates the wrong address family > was used and the P is halved: > ... For the two items: > o If P>0 ... > o If P<0 ... I'd prefer to have the exact same wording with just s/[46]/[64]/ s/[<>]/[><]/. > o If P=0 (indicating equal preference), P is incremented if the > first thread to complete was the IPv6 thread, or decremented if > the first thread to complete was the IPv4 thread. "incremented by 1" "decremented by 1" > which > is similar to the value used by many IPv6-capable TCP client > applications to switch to an alternate A or AAAA record. Again, it's not the application usually (unless using setsockopt) but the intial connection setup timeout of the TCP stack. > Note: Proof of concept tests on fast networks show that even > smaller value (around 0.5 seconds) is practical. More extensive > testing would be useful to find the best upper boundary that still > ensures a good user experience. I think in both cases here and the paragraph above a value of P should not be in seconds but the absolute value of 400 or 50 (given it's |P|==400 [ * 10ms = 4s ] ). I feel that |P|==50 is optimistic given that it can easily be 450+ms from Europe to Australia meaning losing the race twice the application would immediately favour the other AF. XXX-BZ revist and explain the general problem with the maths in here as I understand it; general failover, larger caches, bad expiry XXX-BZ again, what about multiple AAAA or multiple A records and how to count that if the first records wins but we move on to the second for an application failure on that AF? > 4.2.3. Flush or Expire Cache > ... > However, in some instances the > application and the host are unaware the network connectivity has > changed so it is RECOMMENDED that per-destination values expire after > 10 minutes of inactivity. XXX-BZ see further down > 4.2.4. Determining Address Type I would remove that section entirely. It would mean just more magic that might not be needed at all. If replacement transition technolgy would work better than native, so be it;-) > 4.2.5. Debugging and Troubleshooting > ... > mechanism to temporarily use only one address family. The much I'll love once we are there, this is somewhat out of scope I fear as you can write an entire draft about the pros and cons of just that if you have the time. I'd much rather like to see the fallback to revert to the well-known beviour without this draft (whatever it is, mostly usually disabling the concurrency and trying on after the other). If you disable one address family a debug trace will usually only show you half of the information you may want/need. Ok, some of the XXX-BZ to be addressed still in general outside the scope of a specific paragraph: "Which P?" I feel the two 'P's need to be better explained, as in when to update which one and when to pick which one. If I had to guess I would go for a specific implementation but that does not mean anyone else would go for the same. Be more explicit about that. "What about multiple AAAA or A records?" I know the abstract says "dual stack client" to "dual stack server" but while in a majority of the cases that might still be true, it's an ideal world that seems to be especially untrue for the top n sites. What should an application do if it gets back only two AAAA records or 2 AAAA and 4 A records? It may well be one of the machines is in Europe and the other is in the Asia? Do you want to try those in sequence only if one fails or do you also want to measure the 150ms out that the other one could be faster? When, in your model, will you then start more threads? What if the first A wins your match above but the ULP errors? How will the retry work or the moving on to another record? Will we try the other AF then depsite having clsoed the conneciton there? Depsite they usually should do not expect application to behave exactly the same no matter which AF you are using. "general failover, larger caches, bad expiry" Flushing entries from the cache after 10 min. of inactivity has multiple problems: - Say my browser has about the same uptime as my machine. - Say I keep random-modern-ajax-website open in a window all the time. - The website will refresh itself every minute or even have "pseudo" persistent connections (there's a lot of variance in there what you can observe). The result of this will be kind of like: my preference will grow to the max until there is a network hickup. The question then is will it last long enough so the preference will flip or will I just see the 3s delay? Or will it cause the converse and put me on the other address family for the next week despite my conenctivity in my actually prefered address family would be all fine again after a couple of minutes? Next problem is that you are creating a shadow cache in each application on (hostname,port,P,timeout) which can easily get into the thousands in 10 minute sliding window of inactivity depending on the application. That seems wrong to me but I guess people will fix it with a more intelligent purging strategy (depending on application) -- say I close my browser tab for a site, purge the entry if it's the last tab with a connection to the host. Too bad if it was my "home page". People will be creative once they hit an in-application specific "upper bound" of cache size despite memory being cheap. Another thing I am worried is that the experience in the non-"fast" networks in the non-ideal world will kill IPv6 more often than you wished, especially in the early transition time as it will be for most users. The reason for that is: while these days you often get a local A mirror close by for the larger sites, the AAAA machine(s) are more often further away (which can be in another state or country or even continent). This will impose extra delay for IPv6 "lookup+connection attempt" times possibly quickly degrading P to be IPv4 friendly. It's unpredictable how the content will move to IPv6 yet, as I see it but I am almost sure the world wide global "IPv6 day" turn on switch everywhere will not happen. The preference will slowly change towards v6 but in the mean time you want to push it rather than slowing it down. Again, as said at the beginning, it will work well for the really broken cases but it will also affect the "10 ms difference" setups. So will it be a better user experience for me if I'll go through a CGN which may still is quicker than the native IPv6? One way to circumvent the aforementioned weekly flap would be to flush every cached record every n minutes (a time also long enough for a route flap to happen and propagate, or just an hour or a day or worst the TTL of the record returned the application will never learn). It's something that you can spend a year of research on to properly tune that for most places around the globe. Time noone has, which makes this bad. I said that a |P|==50 sounds too optimistic for me. What will be a good absolute value of P? Should the be a static recommendation or not? What about non-TCP? The first mention of TCP is in 4.1 (ignoring the earlier diagram). Should it equally apply to non-TCP or should TCP be mentioned already in the abstract? The very last thing is that the winning address you can connect to fastest does not have to be the address that gives you the best user experience as it could be the least loaded machine for other reasons: the application could hang there, ... the application could still have problems with connections on this address family, ... Will that help user experience? Yes it's another problem domain but "user experience" doesn't see the difference. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From frnkblk@iname.com Thu Jan 27 07:38:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5083A68DB for ; Thu, 27 Jan 2011 07:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, WEIRD_PORT=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 vdGxycs+ydB2 for ; Thu, 27 Jan 2011 07:38:02 -0800 (PST) Received: from premieronline.net (smtp1-5.premieronline.net [96.31.0.25]) by core3.amsl.com (Postfix) with ESMTP id 2B6C53A68C5 for ; Thu, 27 Jan 2011 07:38:01 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from FRANKBULK (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 21677388-1729245 for multiple; Thu, 27 Jan 2011 09:41:02 -0600 From: "Frank Bulk" To: "'Bjoern A. Zeeb'" , , References: <20110127094607.A39951@maildrop.int.zabbadoz.net> In-Reply-To: <20110127094607.A39951@maildrop.int.zabbadoz.net> Date: Thu, 27 Jan 2011 09:41:01 -0600 Message-ID: <005801cbbe38$99ee04f0$cdca0ed0$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acu+LspUVj8DR5pOSl6TLAL+inur4QABIFAA Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=3 Friend=188 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 691, in=10120535, out=49912, spam=0 Known=true ip=199.120.69.26 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-wing-v6ops-happy-eyeballs-ipv6-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 15:38:03 -0000 In regards to IPv6 speed, these sites: http://www.ipv6matrix.org/ (IPv6 Faster? tab) http://speedlab01.cmc.co.ndcwest.comcast.net:8088/monitor/ (choose one of the two download times from the drop down) has something a bit more quantitative. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Bjoern A. Zeeb Sent: Thursday, January 27, 2011 8:28 AM To: dwing@cisco.com; ayourtch@cisco.com Cc: v6ops@ietf.org Subject: [v6ops] Comments on draft-wing-v6ops-happy-eyeballs-ipv6-01 > 3. Problem Statement > .. > As discussed in more detail in Section 3.2, IPv6 connectivity is > sometimes broken entirely or slower than native IPv4 connectivity. Contrary to my findings over the last years, where IPv6 often was faster or more reliable especially on trans-continental links between the same two dual-stack systems (as seen from DE to CA.US, DE to CA and DE to AU). I have even found that going via some 3rd party IPv6 rather than directly into the destination network at the next IXP using their internal IPv4 transport, IPv6 was still faster. I also like the variance, especially as in the following samples the IPv6 is actually tunnelled and still better. (DE - AU) round-trip min/avg/max/stddev = 332.616/357.183/408.802/28.150 ms round-trip min/avg/max/std-dev = 336.952/338.048/340.461/0.973 ms (DE - CA [east coast]) round-trip min/avg/max/stddev = 129.852/136.686/145.283/5.634 ms round-trip min/avg/max/std-dev = 118.636/120.272/121.628/0.996 ms [I wonder if someone may have the data of a lot more probes somewhere?] So I think, even though pointing to the other section, the above should be a lot more precise or limit things to "very special circumstances" as I think it's just the very obvious brokeness you try to address but you'll also catch the 10ms deltas in other areas unfortunately. -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From mtownsley@gmail.com Wed Jan 26 13:36:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C293A68A0 for ; Wed, 26 Jan 2011 13:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 FY+Zd1fucfoG for ; Wed, 26 Jan 2011 13:36:52 -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 D2CC73A68AE for ; Wed, 26 Jan 2011 13:36:51 -0800 (PST) Received: by ewy8 with SMTP id 8so532273ewy.31 for ; Wed, 26 Jan 2011 13:39:52 -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=oc/icTINdvJ5uheboCQFSb+ms5kvUPsdXlyY0oIZ+Q8=; b=VVdSp1iybBb4WrPpWKiV8Vgm5kqxsp1PDSDbbhB3D0NR3mufzgmGFvhvAZ+gZoCVbe ntDOwgJKUPfaU/PEGXDIwMmNqTfVgoJwu8tc8GVYlnbglftY6uAEJtTUXB1sqqyB/5Jr co30JpYDVX0zPW9Fw3rFZ8JBQO6/krTBwWc3c= 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=PeK6bCKshBIUIMCmsnEMNoYuFwfHIW0MXRCsRIUlLQDvwmZYlrJsJxCVPetnu7orlm gnAyer6LViYL7lY4lu0cffA84mHZgdBlCvwsWHVIsXEXBSZpVt3s1KNmGXk0+r4Z0tgu +tY5E+opd2hSxE0lRgM8jN2CTXN3A3a+6QO5s= Received: by 10.14.37.134 with SMTP id y6mr820005eea.45.1296077990689; Wed, 26 Jan 2011 13:39:50 -0800 (PST) Received: from [192.168.0.103] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id t50sm12338940eeh.0.2011.01.26.13.39.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 13:39:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 26 Jan 2011 22:39:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D138836-CCCB-4D68-953D-CEA873B23AAE@gmail.com> References: <20110124215039.GG57584@ricotta.doit.wisc.edu> <963C234B-0FB4-480B-AF92-7435DE4DA6EE@nominum.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 27 Jan 2011 09:37:58 -0800 Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 21:56:01 -0000 On Jan 25, 2011, at 4:53 AM, Cameron Byrne wrote: > On Mon, Jan 24, 2011 at 2:27 PM, Ted Lemon = wrote: >> On Jan 24, 2011, at 4:50 PM, Dale W. Carder wrote: >>> After reading draft-wing-v6ops-happy-eyeballs-ipv6-01, I would be = concerned >>> about trying to support hosts that do not deterministicly choose an = address >>> family to use. Now on top of that, it would be unlikely that every >>> application will implement it or implement it exactly the same way. = To an >>> operator such undeterministic behavor is not easy to diagnose, fix, = and >>> confirm when resolved. >>=20 >> The behavior of devices on the network is never deterministic unless = you have a very constrained network. I think what you mean here is = that which protocol will be chosen is not deterministic. Perhaps so, = but what is deterministic is that happy eyeballs will choose the = protocol that works best at any given moment. >>=20 >> So when there is better IPv6 than IPv4 service, you will see IPv4 = traffic drop off. Deterministically. >>=20 >=20 > I share similar heart burn on this issue to Dale. >=20 > On one hand, without pushing IPv6, traffic levels may not grow. And > if they don't grow, they won't get funded for more development and > hacks like tunnels stay in place ... the service is poor, but there is > not traffic growth so why invest in more v6 capacity or native v6 > capacity? That is the reality of ISP builds. >=20 > On the other hand, i have a hard time accepting a crappy highly latent > poorly peered low MTU IPv6 service .... Yes, thats reality of IPv6 in > many places today. Getting to Google via my home 6RD connection > involves more than 1 cross country trip ... and no, Youtube does not > play well at all in Seattle via this 6RD connection. I wish i could > say otherwise. I hear native is on the way at some point for my ISP, > but many others will not be so lucky. In fact, my native IPv6 on 3G > youtube plays better than my 6RD home connection. It really doesn't have to be that way. Someone isn't enabling 6rd on = enough routers in enough locations.=20 - Mark >=20 > I do personally feel happy eyeballs does not help us turn the page on > IPv4, even though it has the laudable ideals of choosing better > service. >=20 > Cameron >> :) >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From behcetsarikaya@yahoo.com Thu Jan 27 11:52:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398AC3A6A21 for ; Thu, 27 Jan 2011 11:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 0pnWgD9TtkvS for ; Thu, 27 Jan 2011 11:52:15 -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 7404F3A69E5 for ; Thu, 27 Jan 2011 11:52:15 -0800 (PST) Received: from [98.139.91.68] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jan 2011 19:55:20 -0000 Received: from [98.139.91.18] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jan 2011 19:55:20 -0000 Received: from [127.0.0.1] by omp1018.mail.sp2.yahoo.com with NNFMP; 27 Jan 2011 19:55:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 992733.14771.bm@omp1018.mail.sp2.yahoo.com Received: (qmail 20303 invoked by uid 60001); 27 Jan 2011 19:55:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296158119; bh=NWu9PcHFAyeaqXOXBaKi3cvfy0fty6Qt4AS44MEI1sc=; 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=v8h+y3zxVWPtldOdHmbRtnuCX/ejLjz7Apj5FAFWoAusU2XBvszW52W9useBdlv62a4l6bBiK3yiNK0Co89Lj63CMN12dNc9RKcd5BlE53+uDKJNpuQsxn8O5zTr2YR0a2MRGYgFsrnrecoPL535H896eT/m7Anaw0WZGUaEouI= 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=PVBa/8HLQkmWgQOflLsSLv6w2CPK8WNLJlnMoCs1XBdSJDylKRPkeJUg9NzcKw1cXX0WsO/Jc4l4ZCkbkMOnzCPEAyCV1CsDGiIh7kd7fYjJCd6j2mG575dJmsB5+RTTAus3hD+7JjHaj7qkeQ4tiNrJrAdCKSMJ14FxsGfy4/I=; Message-ID: <569544.19828.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: KqAax_IVM1ktpORnPaAC6yedwr3zFp2bDPvl_8OEcvh.jm3 _TtJN1HV2mA9obq6Y1.PvP.FGJjHZX.gq_1TwMc06vCalFZxKwrV6uwAE1g2 nBvjL.rEuSeA4VabblAxMBNwR7YMnu7p48TSrTav.aLBOYq2R5ZQW.e0co2a sPn3FjiQbcWYT.V2HuazMTNk7SKsCnUcLpLvri3TQAzcbRfBCQnbyeOKurBd 2Ur2w5cEbuk4IhfJmMF_4zdPjBqikJQUYPeKqklBLmox9Z030k3.aKmo9QUJ sBAUuLv90jK1Kl06LPdcA45O_1okVyKOf5CaxOxyjWqo_6_4ALj5Kq44zdZ3 BSu0Cgrj_McpAEHGW5G4qEG7rtnDOAbAi5yjw6oI31SnhCdcQjSN4GUQI0dB yXUtmvlMEGqPU Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 27 Jan 2011 11:55:19 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> Date: Thu, 27 Jan 2011 11:55:19 -0800 (PST) From: Behcet Sarikaya To: Guillaume.Leclanche@swisscom.com In-Reply-To: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:52:16 -0000 Guillaume, I think you have some point but I believe Cameron is right. What would change it is 23.975. Currently no standard talks about having 6rd BRs in 3GPP network. So you can of course say that Swisscom have plans to deploy 6RD BRs. No offense to Remi. Regards, Behcet > > >> I disagree. 6rd has been rejected by 3gpp as a transition tool. > > Concerning the 6rd question wrt 3gpp: since you can do it without modifying >any of your devices in the mobile access/core network (under verification for >us, there might be some legal implications), there is no need to refer to 3gpp. >It can even be considered as a userspace service. > > Technically, given that we deployed the 6rd machinery for residential >accesses, it's a no-brainer to add one port and a few lines of configs on the >routers. And then it's up to UE to support it if they want to. > Of course, you need to get the tunnelled traffic just before the IPv4 NAT >platform, meaning that if you have distributed your NAT accross the country >(that's the case for you Cameron, iirc ?), it makes it more costly. > > > I add Guillaume Leclanche of Swisscom (another operator) as cc, because > > I know he also has some interest in 6rd/3GPP. > > I'm subscribed to the list already, by the way. > > Guillaume > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Guillaume.Leclanche@swisscom.com Thu Jan 27 12:13:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F2F3A6A34 for ; Thu, 27 Jan 2011 12:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxaQnfd3TDu7 for ; Thu, 27 Jan 2011 12:13:27 -0800 (PST) Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) by core3.amsl.com (Postfix) with ESMTP id E44D83A6A22 for ; Thu, 27 Jan 2011 12:13:26 -0800 (PST) Received: by intmail2.corproot.net; Thu, 27 Jan 2011 21:16:28 +0100 From: To: Date: Thu, 27 Jan 2011 21:16:27 +0100 Thread-Topic: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 Thread-Index: Acu+XCV3CvmpsJ4TQjS1MzWnRAF1RgAAoZ9A Message-ID: <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C87A67B@sg2019z.corproot.net> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> <569544.19828.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: <569544.19828.qm@web111414.mail.gq1.yahoo.com> Accept-Language: fr-FR, de-CH Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, de-CH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:13:28 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZWhjZXQgU2FyaWtheWEgW21h aWx0bzpiZWhjZXRzYXJpa2F5YUB5YWhvby5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5 IDI3LCAyMDExIDg6NTUgUE0NCj4NCj4gICBJIHRoaW5rIHlvdSBoYXZlIHNvbWUgcG9pbnQgYnV0 IEkgYmVsaWV2ZSBDYW1lcm9uIGlzIHJpZ2h0Lg0KPiBXaGF0IHdvdWxkIGNoYW5nZSBpdCBpcyAy My45NzUuIEN1cnJlbnRseSBubyBzdGFuZGFyZCB0YWxrcyBhYm91dA0KPiBoYXZpbmcgNnJkIEJS cw0KPiBpbiAzR1BQIG5ldHdvcmsuDQo+IFNvIHlvdSBjYW4gb2YgY291cnNlIHNheSB0aGF0IFN3 aXNzY29tIGhhdmUgcGxhbnMgdG8gZGVwbG95IDZSRCBCUnMuDQogDQpJIG11c3QgYXBvbG9naXpl IGZvciBzb21ldGhpbmcgaGVyZTogSSBqdW1wZWQgaW50byB0aGUgdGhyZWFkIHdpdGhvdXQgY2hl Y2tpbmcgdGhlIHN1YmplY3Qgb3IgdGhlIGRyYWZ0IGl0c2VsZi4gSW4gZmFjdCBJIGRvbid0IHJl YWxseSB3YW50IHRvIGluZmx1ZW5jZSB3aGF0ZXZlciB0aGUgZHJhZnQgaXMgc2F5aW5nLCBJIHdh cyBqdXN0IGdpdmluZyBhbiBhZGRpdGlvbm5hbCBwb2ludCBvZiB2aWV3LiBJIGxldCB0aGUgYXV0 aG9ycyBkZWNpZGUgaG93IHJlbGV2YW50IGl0IHdhcyBhbmQgaG93IHRoZXkgd2FudCB0byBkZWFs IHdpdGggaXQuDQoNCkd1aWxsYXVtZQ0K From Fred.L.Templin@boeing.com Thu Jan 27 12:15:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D203A6878 for ; Thu, 27 Jan 2011 12:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prtQFKcWh7He for ; Thu, 27 Jan 2011 12:15:23 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A8BE63A6A47 for ; Thu, 27 Jan 2011 12:15:23 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0RKIJHl001873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jan 2011 14:18:19 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0RKIIcB007737; Thu, 27 Jan 2011 12:18:18 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0RKIIKr007734 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 27 Jan 2011 12:18:18 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 27 Jan 2011 12:18:18 -0800 From: "Templin, Fred L" To: Mark Townsley , Cameron Byrne Date: Thu, 27 Jan 2011 12:18:17 -0800 Thread-Topic: [v6ops] Happy Eyeballs operational issues Thread-Index: Acu+SYKgqV3FU4NkRYugccmxxunK5gAFYzxQ Message-ID: References: <20110124215039.GG57584@ricotta.doit.wisc.edu><963C234B-0FB4-480 B-AF92-7435DE4DA6EE@nominum.com> <6D138836-CCCB-4D68-953D-CEA873B23AAE@gmail.com> In-Reply-To: <6D138836-CCCB-4D68-953D-CEA873B23AAE@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy Eyeballs operational issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:15:24 -0000 =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Mark Townsley > Sent: Wednesday, January 26, 2011 1:40 PM > To: Cameron Byrne > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Happy Eyeballs operational issues >=20 >=20 > On Jan 25, 2011, at 4:53 AM, Cameron Byrne wrote: >=20 > > On Mon, Jan 24, 2011 at 2:27 PM, Ted Lemon=20 > wrote: > >> On Jan 24, 2011, at 4:50 PM, Dale W. Carder wrote: > >>> After reading draft-wing-v6ops-happy-eyeballs-ipv6-01, I=20 > would be concerned > >>> about trying to support hosts that do not deterministicly=20 > choose an address > >>> family to use. Now on top of that, it would be unlikely=20 > that every > >>> application will implement it or implement it exactly the=20 > same way. To an > >>> operator such undeterministic behavor is not easy to=20 > diagnose, fix, and > >>> confirm when resolved. > >>=20 > >> The behavior of devices on the network is never=20 > deterministic unless you have a very constrained network. I=20 > think what you mean here is that which protocol will be=20 > chosen is not deterministic. Perhaps so, but what is=20 > deterministic is that happy eyeballs will choose the protocol=20 > that works best at any given moment. > >>=20 > >> So when there is better IPv6 than IPv4 service, you will=20 > see IPv4 traffic drop off. Deterministically. > >>=20 > >=20 > > I share similar heart burn on this issue to Dale. > >=20 > > On one hand, without pushing IPv6, traffic levels may not grow. And > > if they don't grow, they won't get funded for more development and > > hacks like tunnels stay in place ... the service is poor,=20 > but there is > > not traffic growth so why invest in more v6 capacity or native v6 > > capacity? That is the reality of ISP builds. > >=20 > > On the other hand, i have a hard time accepting a crappy=20 > highly latent > > poorly peered low MTU IPv6 service .... Yes, thats reality=20 > of IPv6 in > > many places today. Getting to Google via my home 6RD connection > > involves more than 1 cross country trip ... and no, Youtube does not > > play well at all in Seattle via this 6RD connection. I=20 > wish i could > > say otherwise. I hear native is on the way at some point for my ISP, > > but many others will not be so lucky. In fact, my native IPv6 on 3G > > youtube plays better than my 6RD home connection. >=20 > It really doesn't have to be that way. Someone isn't=20 > enabling 6rd on enough routers in enough locations. Or maybe they should be deploying a better service than 6RD: http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt Fred fred.l.templin@boeing.com =20 > - Mark >=20 > >=20 > > I do personally feel happy eyeballs does not help us turn=20 > the page on > > IPv4, even though it has the laudable ideals of choosing better > > service. > >=20 > > Cameron > >> :) > >>=20 > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >>=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From remi.despres@free.fr Fri Jan 28 02:09:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58EE43A695A for ; Fri, 28 Jan 2011 02:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.518, 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 uQXF-mfb9hnl for ; Fri, 28 Jan 2011 02:09:43 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 3EC053A6BFB for ; Fri, 28 Jan 2011 02:09:40 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2201.sfr.fr (SMTP Server) with ESMTP id 7DEFC700008D; Fri, 28 Jan 2011 11:12:45 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2201.sfr.fr (SMTP Server) with ESMTP id CD904700008E; Fri, 28 Jan 2011 11:12:44 +0100 (CET) X-SFR-UUID: 20110128101244842.CD904700008E@msfrf2201.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: <569544.19828.qm@web111414.mail.gq1.yahoo.com> Date: Fri, 28 Jan 2011 11:12:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> <569544.19828.qm@web111414.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Guillaume.Leclanche@swisscom.com Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 10:09:44 -0000 Hi Behcet, Le 27 janv. 2011 =E0 20:55, Behcet Sarikaya a =E9crit : > Guillaume,=20 >=20 > I think you have some point but I believe Cameron is right. > What would change it is 23.975. Currently no standard talks about = having 6rd BRs=20 > in 3GPP network. AFAIK, no change to 3GPP 23.975 is needed. It is just noting that 6rd can be combined with 3GPP networks as = specified in 3GPP documents. > So you can of course say that Swisscom have plans to deploy 6RD BRs. > No offense to Remi. There is no offense. Making constructive proposals is legitimate. Objecting to them in good faith is legitimate too. Now, let me explain more. The concern is that readers of the document are led to believe that = significant problems need to be solved BEFORE a dual-stack service can = be used across 3GPP infrastructures, which ISN'T TRUE. Mentioned problems include: - Pre-Release-8: "Deployment and migration cases described in Section = 6.1 for providing dual-stack like capability may mean doubled resource = usage in operator's network. This is a major concern against providing = dual-stack like connectivity using techniques discussed in Section 6.1." - Release-8 and after: "If a network knows a mobile may do handovers = between Release-8 and pre-Release-8 networks (segment), network will = only provide single stack bearers, even if the mobile host requests = dual-stack bearers."=20 Now, before these problems are solved, a solution happens to be = available with 6rd across 3GPP networks:=20 - It works with IPv4 bearers, available before and after release-8=20 - IPv6 addresses used across IPv6/IPv4 tunnels are native (starting with = operator prefixes, no translation needed) I know that 3GPP has defiance against IP/IP tunnels in UEs, and doesn't = propose any in its specifications. But this doesn't change the fact that: - There is nothing to change to 3GPP networks to add 6rd support across = them, - This permits rapid deployment of the dual-stack service in 3GPP UEs = (phones, PCs with dongles,...) This is worth knowing, and can mitigate the frustration of having to = wait a long time before dual-stack services can be available in mobile = devices. If I miss something, thank you for explaining what. Regards, RD =20 >> ... >> Concerning the 6rd question wrt 3gpp: since you can do it without = modifying=20 >> any of your devices in the mobile access/core network (under = verification for=20 >> us, there might be some legal implications), there is no need to = refer to 3gpp.=20 >> It can even be considered as a userspace service. >>=20 >> Technically, given that we deployed the 6rd machinery for = residential=20 >> accesses, it's a no-brainer to add one port and a few lines of = configs on the=20 >> routers. And then it's up to UE to support it if they want to. >> Of course, you need to get the tunnelled traffic just before the IPv4 = NAT =20 >> platform, meaning that if you have distributed your NAT accross the = country =20 >> (that's the case for you Cameron, iirc ?), it makes it more costly. > ... From Fred.L.Templin@boeing.com Fri Jan 28 09:22:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD7E3A67F4 for ; Fri, 28 Jan 2011 09:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acvNySog-Isz for ; Fri, 28 Jan 2011 09:22:08 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 76BD53A67C2 for ; Fri, 28 Jan 2011 09:22:08 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0SHP90e012709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jan 2011 09:25:10 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0SHP7MM011610; Fri, 28 Jan 2011 11:25:08 -0600 (CST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0SHP1Kn011440 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Jan 2011 11:25:05 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 28 Jan 2011 09:25:02 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Behcet Sarikaya Date: Fri, 28 Jan 2011 09:25:01 -0800 Thread-Topic: [v6ops] Fwd: New Version Notification fordraft-korhonen-v6ops-3gpp-eps-05 Thread-Index: Acu+0/CYqqHqIoYnT6mPn2kF4XfRDAAPDPZA Message-ID: References: <20110121104801.07EDE3A6923@core3.amsl.com><760D4800-FB61-4806-9 69E-0B551DE0E276@gmail.com><8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr><7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net><569544.19828.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "Guillaume.Leclanche@swisscom.com" Subject: Re: [v6ops] Fwd: New Version Notification fordraft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:22:09 -0000 =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of R=E9mi Despr=E9s > Sent: Friday, January 28, 2011 2:13 AM > To: Behcet Sarikaya > Cc: v6ops@ietf.org; Guillaume.Leclanche@swisscom.com > Subject: Re: [v6ops] Fwd: New Version Notification=20 > fordraft-korhonen-v6ops-3gpp-eps-05 >=20 > Hi Behcet, >=20 > Le 27 janv. 2011 =E0 20:55, Behcet Sarikaya a =E9crit : >=20 > > Guillaume,=20 > >=20 > > I think you have some point but I believe Cameron is right. > > What would change it is 23.975. Currently no standard talks=20 > about having 6rd BRs=20 > > in 3GPP network. >=20 > AFAIK, no change to 3GPP 23.975 is needed. > It is just noting that 6rd can be combined with 3GPP networks=20 > as specified in 3GPP documents. >=20 >=20 > > So you can of course say that Swisscom have plans to deploy 6RD BRs. >=20 > > No offense to Remi. >=20 > There is no offense. > Making constructive proposals is legitimate. > Objecting to them in good faith is legitimate too. Or maybe they should be deploying a better service than 6RD: http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt Fred fred.l.templin@boeing.com =20 > Now, let me explain more. > The concern is that readers of the document are led to=20 > believe that significant problems need to be solved BEFORE a=20 > dual-stack service can be used across 3GPP infrastructures,=20 > which ISN'T TRUE. > Mentioned problems include: > - Pre-Release-8: "Deployment and migration cases described in=20 > Section 6.1 for providing dual-stack like capability may mean=20 > doubled resource usage in operator's network. This is a major=20 > concern against providing dual-stack like connectivity using=20 > techniques discussed in Section 6.1." > - Release-8 and after: "If a network knows a mobile may do=20 > handovers between Release-8 and pre-Release-8 networks=20 > (segment), network will only provide single stack bearers,=20 > even if the mobile host requests dual-stack bearers."=20 >=20 > Now, before these problems are solved, a solution happens to=20 > be available with 6rd across 3GPP networks:=20 > - It works with IPv4 bearers, available before and after release-8=20 > - IPv6 addresses used across IPv6/IPv4 tunnels are native=20 > (starting with operator prefixes, no translation needed) >=20 > I know that 3GPP has defiance against IP/IP tunnels in UEs,=20 > and doesn't propose any in its specifications. > But this doesn't change the fact that: > - There is nothing to change to 3GPP networks to add 6rd=20 > support across them, > - This permits rapid deployment of the dual-stack service in=20 > 3GPP UEs (phones, PCs with dongles,...) > This is worth knowing, and can mitigate the frustration of=20 > having to wait a long time before dual-stack services can be=20 > available in mobile devices. >=20 > If I miss something, thank you for explaining what. >=20 > Regards, > RD >=20 >=20 >=20 > =20 > >> ... > >> Concerning the 6rd question wrt 3gpp: since you can do it=20 > without modifying=20 > >> any of your devices in the mobile access/core network=20 > (under verification for=20 > >> us, there might be some legal implications), there is no=20 > need to refer to 3gpp.=20 > >> It can even be considered as a userspace service. > >>=20 > >> Technically, given that we deployed the 6rd machinery for =20 > residential=20 > >> accesses, it's a no-brainer to add one port and a few=20 > lines of configs on the=20 > >> routers. And then it's up to UE to support it if they want to. > >> Of course, you need to get the tunnelled traffic just=20 > before the IPv4 NAT =20 > >> platform, meaning that if you have distributed your NAT=20 > accross the country =20 > >> (that's the case for you Cameron, iirc ?), it makes it more costly. > > ... >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From swmike@swm.pp.se Fri Jan 28 13:01:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF81D3A68BD for ; Fri, 28 Jan 2011 13:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 vp0X2iVG1qVh for ; Fri, 28 Jan 2011 13:01:59 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id DF9793A6878 for ; Fri, 28 Jan 2011 13:01:58 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F38B39E; Fri, 28 Jan 2011 22:05:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F1AF99A; Fri, 28 Jan 2011 22:05:01 +0100 (CET) Date: Fri, 28 Jan 2011 22:05:01 +0100 (CET) From: Mikael Abrahamsson To: "Templin, Fred L" In-Reply-To: Message-ID: References: <20110121104801.07EDE3A6923@core3.amsl.com><760D4800-FB61-4806-9 69E-0B551DE0E276@gmail.com><8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr><7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net><569544.19828.qm@web111414.mail.gq1.yahoo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification fordraft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 21:02:00 -0000 On Fri, 28 Jan 2011, Templin, Fred L wrote: > Or maybe they should be deploying a better service than 6RD: > > http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt I see running code in several products for 6RD right now. What is the status of IRON when it comes to actual implementation in software? -- Mikael Abrahamsson email: swmike@swm.pp.se From Fred.L.Templin@boeing.com Fri Jan 28 14:04:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA0C3A6873 for ; Fri, 28 Jan 2011 14:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6ucv3aFJ71g for ; Fri, 28 Jan 2011 14:04:20 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 697053A67EC for ; Fri, 28 Jan 2011 14:04:20 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0SM7M0G018406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jan 2011 14:07:25 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0SM7MrV029124; Fri, 28 Jan 2011 14:07:22 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0SM7Muv029120 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Jan 2011 14:07:22 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 28 Jan 2011 14:07:22 -0800 From: "Templin, Fred L" To: Mikael Abrahamsson Date: Fri, 28 Jan 2011 14:07:20 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfordraft-korhonen-v6ops-3gpp-eps-05 Thread-Index: Acu/LwzvekZhPpZaQqK0+aVaIvoYIAAB1pfw Message-ID: References: <20110121104801.07EDE3A6923@core3.amsl.com><760D4800-FB61-4806-9 69E-0B551DE0E276@gmail.com><8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr>< a lpine.DEB.1.10.1101261412560.13151@uplift.swm.pp.se><7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net ><569544.19828.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 22:04:21 -0000 Hi Mikael, A first-version of the code has been announced and is available for experimentation: http://www.ietf.org/mail-archive/web/int-area/current/msg02472.html I have said that I believe IRON to be a better service than 6RD, and there are several vectors along which I believe this to be true. But, just to mention one within this context is that IRON allows multi-access devices (e.g., a handset with both 3G and WiFi) to connect through any available links of opportunity and still retain a stable IPv6 address/prefix - be it as a mobile host or a mobile router. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 > Sent: Friday, January 28, 2011 1:05 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: New Version=20 > Notificationfordraft-korhonen-v6ops-3gpp-eps-05 >=20 > On Fri, 28 Jan 2011, Templin, Fred L wrote: >=20 > > Or maybe they should be deploying a better service than 6RD: > > > > http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt >=20 > I see running code in several products for 6RD right now. What is the=20 > status of IRON when it comes to actual implementation in software? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > = From joelja@bogus.com Sun Jan 30 12:11:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E0D3A6851 for ; Sun, 30 Jan 2011 12:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 eQ1q9K2KZtTn for ; Sun, 30 Jan 2011 12:11:57 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 3768F3A6814 for ; Sun, 30 Jan 2011 12:11:57 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0UKF1AX092448 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 30 Jan 2011 20:15:02 GMT (envelope-from joelja@bogus.com) Message-ID: <4D45C6C5.408@bogus.com> Date: Sun, 30 Jan 2011 12:15:01 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> <569544.19828.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Guillaume.Leclanche@swisscom.com, v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 20:11:58 -0000 Inline. On 1/28/11 2:12 AM, Rémi Després wrote: > Now, let me explain more. The concern is that readers of the document > are led to believe that significant problems need to be solved BEFORE > a dual-stack service can be used across 3GPP infrastructures, which > ISN'T TRUE. Mentioned problems include: - Pre-Release-8: "Deployment > and migration cases described in Section 6.1 for providing dual-stack > like capability may mean doubled resource usage in operator's > network. This is a major concern against providing dual-stack like > connectivity using techniques discussed in Section 6.1." - Release-8 > and after: "If a network knows a mobile may do handovers between > Release-8 and pre-Release-8 networks (segment), network will only > provide single stack bearers, even if the mobile host requests > dual-stack bearers." > > Now, before these problems are solved, a solution happens to be > available with 6rd across 3GPP networks: - It works with IPv4 > bearers, available before and after release-8 - IPv6 addresses used > across IPv6/IPv4 tunnels are native (starting with operator prefixes, > no translation needed) > > I know that 3GPP has defiance against IP/IP tunnels in UEs, and > doesn't propose any in its specifications. But this doesn't change > the fact that: - There is nothing to change to 3GPP networks to add > 6rd support across them, - This permits rapid deployment of the > dual-stack service in 3GPP UEs (phones, PCs with dongles,...) This is > worth knowing, and can mitigate the frustration of having to wait a > long time before dual-stack services can be available in mobile > devices. This really isn't a productive line of reasoning, the fact that over Ipv4 I can tunnel virtually anything I want is not, a constructive insight for this document. Nor is useful advice to operators per-say. Nothing prevents them from refering to rfc 5969, if they discover a business case for native v6 edges tunneled over ipv4. It appears, for that they may look to wireline isp or mso (with whom they do compete) for examples where it could we be appropriate if they so choose (a wireless router is rather different business case than a handset). As noted in the abstract and from the outset: " This document describes the support for IPv6 in 3GPP network architectures." The authors can and should engage in some editorial proscription what is an is in not in scope for that discussion. Your (RD) contribution from the 24th is noted, but in my opinion not in scope. I hope that we can close off the discussion of this particular point. joel > If I miss something, thank you for explaining what. From fred@cisco.com Sun Jan 30 22:51:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615E03A6B9B for ; Sun, 30 Jan 2011 22:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iGaZzEf0OjMq for ; Sun, 30 Jan 2011 22:51:18 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9638C3A6B9F for ; Sun, 30 Jan 2011 22:51:02 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAFAN/qRU2Q/khLgWdsb2JhbACCQ5QSjiEVAQEWIiSfLJo0hU4EjCGDRQ Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2011 06:54:15 +0000 Received: from Freds-Computer.local (dhcp-10-55-94-243.cisco.com [10.55.94.243]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0V6sASS001302 for ; Mon, 31 Jan 2011 06:54:15 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 31 Jan 2011 06:54:15 +0000 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 31 Jan 2011 06:54:15 +0000 From: Fred Baker Date: Mon, 31 Jan 2011 06:54:01 +0000 Message-Id: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: multipart/alternative; boundary=Apple-Mail-35-322061937 Subject: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 06:51:27 -0000 --Apple-Mail-35-322061937 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Question for the assembled throng: What do people want to see happen in = draft-wbeebee-v6ops-ipv6-cpe-router-bis? Part of the outcome of IETF 79 was a discussion around Tom Herbst's = draft regarding interactions with the Smart Grid's Home Area Network. = This is something that is not mandatory in a next generation residential = router, but I suspect will have utility. Comments to the list, please.= --Apple-Mail-35-322061937 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Question for the assembled throng: What = do people want to see happen = in draft-wbeebee-v6ops-ipv6-cpe-router-bis?

= --Apple-Mail-35-322061937-- From joelja@bogus.com Sun Jan 30 23:06:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2D03A6B9C for ; Sun, 30 Jan 2011 23:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.513 X-Spam-Level: X-Spam-Status: No, score=-100.513 tagged_above=-999 required=5 tests=[AWL=-1.414, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.3, 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 HAX0do92gOUc for ; Sun, 30 Jan 2011 23:06:56 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4DEDC3A6B9B for ; Sun, 30 Jan 2011 23:06:55 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0V7A6AL027443 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 31 Jan 2011 07:10:07 GMT (envelope-from joelja@bogus.com) Message-ID: <4D46604E.30001@bogus.com> Date: Sun, 30 Jan 2011 23:10:06 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> In-Reply-To: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 07:06:58 -0000 On 1/30/11 10:54 PM, Fred Baker wrote: > Question for the assembled throng: What do people want to see happen > in draft-wbeebee-v6ops-ipv6-cpe-router-bis? > > Part of the outcome of IETF 79 was a discussion around Tom Herbst's > draft regarding interactions with the Smart Grid's Home Area Network. > This is something that is not mandatory in a next generation > residential router, but I suspect will have utility. Comments to the > list, please. The operative thing I took away from it is you can't just bridge 802.15.4 to ethernet so if you want ot interconnect them you;r egoing to have to route. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sun Jan 30 23:15:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2617F3A6BA1 for ; Sun, 30 Jan 2011 23:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.149 X-Spam-Level: X-Spam-Status: No, score=-109.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.3, 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 QvA3Psqvc0SJ for ; Sun, 30 Jan 2011 23:15:05 -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 142FC3A6B9B for ; Sun, 30 Jan 2011 23:15:04 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwEAH/wRU2Q/khLgWdsb2JhbACkdhUBARYiJJ8pmjWFTgSMIYNF Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2011 07:18:18 +0000 Received: from Freds-Computer.local (dhcp-10-55-94-243.cisco.com [10.55.94.243]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0V7IDZ5006311; Mon, 31 Jan 2011 07:18:17 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 31 Jan 2011 07:18:18 +0000 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 31 Jan 2011 07:18:18 +0000 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D46604E.30001@bogus.com> Date: Mon, 31 Jan 2011 07:18:04 +0000 Message-Id: References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46604E.30001@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 07:15:06 -0000 On Jan 31, 2011, at 7:10 AM, Joel Jaeggli wrote: > On 1/30/11 10:54 PM, Fred Baker wrote: >> Question for the assembled throng: What do people want to see happen >> in draft-wbeebee-v6ops-ipv6-cpe-router-bis? >>=20 >> Part of the outcome of IETF 79 was a discussion around Tom Herbst's >> draft regarding interactions with the Smart Grid's Home Area Network. >> This is something that is not mandatory in a next generation >> residential router, but I suspect will have utility. Comments to the >> list, please. >=20 > The operative thing I took away from it is you can't just bridge > 802.15.4 to ethernet so if you want ot interconnect them you;r egoing = to > have to route. Pretty much. And there are some interesting issues even in that; an = 802.15.4 device can (due to radio behavior) change from one router to = another and not realize it, or so I'm told. "802" doesn't mean = "Ethernet". It is just the IEEE's way of saying "Local Area = Communication Networks". From remi.despres@free.fr Mon Jan 31 02:18:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3E93A68FE for ; Mon, 31 Jan 2011 02:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_40=-0.185, 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 c38pSYws4DCr for ; Mon, 31 Jan 2011 02:18:44 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by core3.amsl.com (Postfix) with ESMTP id C55E83A68DF for ; Mon, 31 Jan 2011 02:18:43 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id E77A4700008A; Mon, 31 Jan 2011 11:21:56 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id 52D2F7000087; Mon, 31 Jan 2011 11:21:54 +0100 (CET) X-SFR-UUID: 20110131102154339.52D2F7000087@msfrf2112.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: <4D45C6C5.408@bogus.com> Date: Mon, 31 Jan 2011 11:21:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <409C79ED-06FD-4F5D-A8E9-5F709ABDC716@free.fr> References: <20110121104801.07EDE3A6923@core3.amsl.com> <760D4800-FB61-4806-969E-0B551DE0E276@gmail.com> <8AA3C067-8D4E-40FF-9982-6CA61BF267F1@free.fr> <7E338A9A7F416C4AB2BA4D4E2DEBA0844F5C7F6808@sg2019z.corproot.net> <569544.19828.qm@web111414.mail.gq1.yahoo.com> <4D45C6C5.408@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1082) Cc: Guillaume.Leclanche@swisscom.com, v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 10:18:44 -0000 Hi Joel, Le 30 janv. 2011 =E0 21:15, Joel Jaeggli a =E9crit : > Inline. >=20 > On 1/28/11 2:12 AM, R=E9mi Despr=E9s wrote: >=20 >> ... >> I know that 3GPP has defiance against IP/IP tunnels in UEs, and >> doesn't propose any in its specifications. But this doesn't change >> the fact that: - There is nothing to change to 3GPP networks to add >> 6rd support across them, - This permits rapid deployment of the >> dual-stack service in 3GPP UEs (phones, PCs with dongles,...) This is >> worth knowing, and can mitigate the frustration of having to wait a >> long time before dual-stack services can be available in mobile >> devices. >=20 > This really isn't a productive line of reasoning, the fact that over > Ipv4 I can tunnel virtually anything I want is not, a constructive > insight for this document. >=20 > Nor is useful advice to operators per-say. Nothing prevents them from > refering to rfc 5969, if they discover a business case for native v6 > edges tunneled over ipv4. It appears, for that they may look to = wireline > isp or mso (with whom they do compete) for examples where it could we = be > appropriate if they so choose (a wireless router is rather different > business case than a handset). >=20 > As noted in the abstract and from the outset: >=20 > " This document describes the support for IPv6 in 3GPP network > architectures." >=20 > The authors can and should engage in some editorial proscription what = is > an is in not in scope for that discussion. Your (RD) contribution = from > the 24th is noted, but in my opinion not in scope. >=20 > I hope that we can close off the discussion of this particular point. Fair enough. Unless someone revives it, that's a close for me concerning this draft. (Some other means will have to be used for operators that are interested = in quickly offering a dual-stack service to have the 6rd/3GPP approach = documented). Regards, RD =20 > joel >=20 >> If I miss something, thank you for explaining what. From jbates@brightok.net Mon Jan 31 07:04:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672BC3A6C16 for ; Mon, 31 Jan 2011 07:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6] 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 RduGn7QaSFf8 for ; Mon, 31 Jan 2011 07:04:48 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id A29683A6C0C for ; Mon, 31 Jan 2011 07:04:48 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VF7umP002894; Mon, 31 Jan 2011 09:07:56 -0600 (CST) Message-ID: <4D46D04C.9080600@brightok.net> Date: Mon, 31 Jan 2011 09:07:56 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> In-Reply-To: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:04:49 -0000 On 1/31/2011 12:54 AM, Fred Baker wrote: > Question for the assembled throng: What do people want to see happen in > draft-wbeebee-v6ops-ipv6-cpe-router-bis? > 5.4 TBD? Does this apply to the draft itself or that another draft will have to determine the details of multi-router prefix delegation and routing behavior? I ask, as it's the primary reason I joined v6ops, and there is serious concerns dealing with methodology. For example, determining when it's appropriate to run DHCPv6 server or DHCPv6 relay agent (or the worst yet, proxy-ND through multiple routers). An ISP not issuing IA_PD requires multiple proxy-ND. An ISP issuing /60-64 might require DHCPv6 relay agent to feed a new assignment to each router (with /64, each router may need to make multiple requests). An ISP issuing /56 or /48 probably does not want to issue such a large block to multiple routers at the same location, requiring DHCPv6 server to pass them on. Finally, a reasonable mechanism for dividing up a /56 or /48 to get proper width and depth in a network through automated delegation should be documented. I'm personally for an extension in DHCPv6 to support size requests, allowing for DHCPv6 relay if the request is met precisely (or when multiple requests are necessary due to it being answered with a longer length than requested) and DHCPv6 server for when the request is answered with a shorter length. Sorry for being IETF clueless and continuing my bad habit of rambling. Jack From fred@cisco.com Mon Jan 31 07:56:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F78C3A6BFA for ; Mon, 31 Jan 2011 07:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.574 X-Spam-Level: X-Spam-Status: No, score=-109.574 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 xmAmtn8NDNtY for ; Mon, 31 Jan 2011 07:56:00 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6F0583A67F0 for ; Mon, 31 Jan 2011 07:56:00 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEANdqRk2Q/khMgWdsb2JhbACkeRUBARYiJKIpmnqFTgSMIYNF Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2011 15:59:14 +0000 Received: from [192.168.12.236] (dhcp-10-61-100-48.cisco.com [10.61.100.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0VFxERv015636; Mon, 31 Jan 2011 15:59:14 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4D46D04C.9080600@brightok.net> Date: Mon, 31 Jan 2011 15:59:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:56:01 -0000 On Jan 31, 2011, at 3:07 PM, Jack Bates wrote: >=20 >=20 > On 1/31/2011 12:54 AM, Fred Baker wrote: >> Question for the assembled throng: What do people want to see happen = in >> draft-wbeebee-v6ops-ipv6-cpe-router-bis? >>=20 > 5.4 TBD? Does this apply to the draft itself or that another draft = will have to determine the details of multi-router prefix delegation and = routing behavior? In my opinion, a requirements document should specify requirements, not = solutions. Ideally, they could point to an RFC on the topic; if they = want, they could simply say that routers designed for small networks = need a solution to the problem. > I ask, as it's the primary reason I joined v6ops, and there is serious = concerns dealing with methodology. For example, determining when it's = appropriate to run DHCPv6 server or DHCPv6 relay agent (or the worst = yet, proxy-ND through multiple routers). An ISP not issuing IA_PD = requires multiple proxy-ND. An ISP issuing /60-64 might require DHCPv6 = relay agent to feed a new assignment to each router (with /64, each = router may need to make multiple requests). An ISP issuing /56 or /48 = probably does not want to issue such a large block to multiple routers = at the same location, requiring DHCPv6 server to pass them on. Finally, = a reasonable mechanism for dividing up a /56 or /48 to get proper width = and depth in a network through automated delegation should be = documented. I'm personally for an extension in DHCPv6 to support size = requests, allowing for DHCPv6 relay if the request is met precisely (or = when multiple requests are necessary due to it being answered with a = longer length than requested) and DHCPv6 server for when the request is = answered with a shorter length. Maybe you would like to help specify a solution?= From jbates@brightok.net Mon Jan 31 08:01:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA85A3A6BFA for ; Mon, 31 Jan 2011 08:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 0CGqryadsBA8 for ; Mon, 31 Jan 2011 08:01:37 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id DE9E03A67F0 for ; Mon, 31 Jan 2011 08:01:36 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VG4oPN018399; Mon, 31 Jan 2011 10:04:50 -0600 (CST) Message-ID: <4D46DDA2.1090204@brightok.net> Date: Mon, 31 Jan 2011 10:04:50 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> In-Reply-To: <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:01:37 -0000 On 1/31/2011 9:59 AM, Fred Baker wrote: > > On Jan 31, 2011, at 3:07 PM, Jack Bates wrote: > > In my opinion, a requirements document should specify requirements, > not solutions. Ideally, they could point to an RFC on the topic; if > they want, they could simply say that routers designed for small > networks need a solution to the problem. > Okay. This makes sense. We need the solution document to point to with the requirements document. It amazes me that one hasn't been designed this far into the end game. > > Maybe you would like to help specify a solution? If someone is interested, I'll be happy to help. Given my lack of knowledge on writing drafts, I'd absolutely fail at writing it myself in any timely manner. We have to deal with this problem or everyone is going to be stuck with single CPE setups. Jack From fred@cisco.com Mon Jan 31 08:53:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026D13A6C5E for ; Mon, 31 Jan 2011 08:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.016 X-Spam-Level: X-Spam-Status: No, score=-110.016 tagged_above=-999 required=5 tests=[AWL=0.583, 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 IBRYuIadmv9H for ; Mon, 31 Jan 2011 08:53:00 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id DB0973A6C63 for ; Mon, 31 Jan 2011 08:52:59 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAOd4Rk2Q/khLgWdsb2JhbACkeRUBARYiJKI7mwiFTgSMIYNF Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2011 16:56:13 +0000 Received: from [192.168.12.236] (dhcp-10-55-81-209.cisco.com [10.55.81.209]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0VGuDtC012934; Mon, 31 Jan 2011 16:56:13 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4D46DDA2.1090204@brightok.net> Date: Mon, 31 Jan 2011 16:56:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:53:02 -0000 On Jan 31, 2011, at 4:04 PM, Jack Bates wrote: > Okay. This makes sense. We need the solution document to point to with = the requirements document. It amazes me that one hasn't been designed = this far into the end game. There have been a couple of proposals: (1) http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation This is targeted at residential/SOHO networks, and has drawbacks pointed = out in the draft if I recall correctly. (2) http://tools.ietf.org/html/draft-sarikaya-netext-prefix-delegation http://tools.ietf.org/html/draft-sarikaya-int-area-prefix-delegation http://tools.ietf.org/html/draft-sarikaya-intarea-prefix-delegation http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation This is targeted at mobile networks. We have discussed it as recently as = IETF-79. In the SurveyMonkey survey we ran at that meeting, 26.7% of = respondents said that the draft was unsalvageable or uninteresting and = should be abandoned, 53.3% said it should be adopted as a working group = draft. and the remainder said it was in the wrong working group or = should be an individual effort. That's an interesting range of opinion. = I think Mr Sarikaya would be interested to discuss it if you think it is = valuable. (3) I'm not finding it, but IIRC Ralph Droms and others put in a document = saying in essence that the ISP should delegate a prefix to its = customer's CPE router, and other routers in the domain should use RFC = 3633 to get a /64 delegated to their various interfaces from the CPE. = The drawback here is that it is a manual process - the CPE must somehow = know what to tell the various routers that enquire of it, and no = procedure is defined for identifying what routers share a LAN in the = home unless that LAN is directly attached to the CPE. =46rom my perspective, (3) makes the most sense for residential/SOHO = routers, but it needs a disambiguation procedure. If you have a = home/residential network that is structured other than as a tree, what = routers share links in a manner that is invisible to the CPE? You could = solve that with an Alternate Tuesday rule, for example.=20 Imagine: | | | +-----------+ | prefix:1::/64 +--+ His Office+--+ | +-----------+ | | | +-------+ | | ISP --------+ CPE +--+ +-----------+ | prefix:2::/64 | Router| +--+ Her Office+--+ +-------+ | +-----------+ | | | prefix:0::/64 | +-----------+ | +--+ A/V Router+--+ | +-----------+ | prefix:4::/64 | | So the ISP gives the CPE a /60 (say), and the CPE allocates a /64 to = each distinct LAN attached to it (perhaps a wired and a wireless LAN). = The other routers each observe that they have another interface and = don't know what to assign to it, ask the CPE router (the one advertising = an RA to them), and it gives them each another prefix, in the above = tagged as prefix:1::, prefix:2::, prefix:3::, and prefix:4::. Note that = the two offices share connectivity that doesn't go throughout the home, = but we now have two prefixes on it. =46rom one perspective, that's not = really a problem, as IPv6 allows multiple prefixes on a LAN. On the = other hand, it's a bit wasteful, and one could probably find ways to = make things really messy. It would be nice if one of the two gave way to = the other in some predictable way and was returned to the CPE or = re-delegation to some other router should the need arise.= From jbates@brightok.net Mon Jan 31 09:44:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FE03A6AAA for ; Mon, 31 Jan 2011 09:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 xaarD8qPRHKc for ; Mon, 31 Jan 2011 09:44:28 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 029573A6A6F for ; Mon, 31 Jan 2011 09:44:27 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VHlfol017752; Mon, 31 Jan 2011 11:47:41 -0600 (CST) Message-ID: <4D46F5BD.2050704@brightok.net> Date: Mon, 31 Jan 2011 11:47:41 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:44:29 -0000 On 1/31/2011 10:56 AM, Fred Baker wrote: > There have been a couple of proposals: I'll read through them. However, I think we could accomplish most of it (except for the actual algorithm for finding necessary space in a delegation). draft-ietf-v6ops-ipv6-cpe-router-07 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces rounded up to the nearest nibble and MUST be configurable to ask for more. Really needs to be SHOULD, to support proper support and interoperability in a chained environment. It is likely that most providers (though not always) will provide a hard set prefix, while it is better for chained CPE's to support prefix hinting. If a CPE is to be fully interoperable with chaining, this actually would need to be MUST. WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. It should also attempt to do multiple delegation requests to support providers that will happily hand out multiple /64 networks, one per request. Proper methodology would be to use additional IAIDs. Per RFC3633 Section 6, Identity Association for Prefix Delegation " The IAID uniquely identifies the IA_PD and must be chosen to be unique among the IA_PD IAIDs on the requesting router. The IAID is chosen by the requesting router. For any given use of an IA_PD by the requesting router, the IAID for that IA_PD MUST be consistent across restarts of the requesting router. The requesting router may maintain consistency either by storing the IAID in non-volatile storage or by using an algorithm that will consistently produce the same IAID as long as the configuration of the requesting router has not changed. If the requesting router uses only one IAID, it can use a well-known value, e.g., zero. " Items which are missing are the methodology for staging from one topology type to another. Some of this is covered under ipv6-cpe-router-bis, in the form of proxy-ND support. It is my belief that we could expand upon that with existing RFC's, especially with the minor changes to draft-ietf-v6ops-ipv6-cpe-router-07. A likely sequence of determining the appropriate model is, 1) If we receive larger than our HINT, we support subdelegation of what we've received to downstream IA_PD requestors. 2) If we receive exactly the size of our HINT, we perform DHCPv6 Relay for our downstream requestors 3) If we receive smaller than our HINT, we should make additional requests using additonal IAIDs based on the prefix size we did receive (this is for completeness, as it should be in cpe-router). 4) If we do not receive an IA_PD, we perform proxy-ND (which should be able to be infinitely chained, even if extremely ugly) If we are performing subdelegation, we will need to keep certain things in mind: 1) We should limit the size requested downstream (we're a cpe router, so getting a /48 request would be excessive) 2) If a request exceeds what we have available, we need to request with another IAID from upstream for another block (we received a /60, between our assignments and downstream assignments, we can no longer answer a /63 request, so we must ask upstream for another /60). The above creates a model that supports: proxy-nd if the ISP or upstream CPE refuses to do DHCPv6-PD. multiple exact match prefixes for local use and downstream use if ISP supports very small prefixes (at the cost that the ISP will have to support additional routes to the max they will allow the customer network to have). Large delegation from ISP, with all internal network CPEs doing DHCPv6 relay for exact match prefixes. This increases the customer's internal routing table (unless over time CPE's recognize subdelegations and increase their hint?), but allows for extremely efficient use of the space delegated. Thoughts? Opinions? Am I wrong to think that as a whole this could be covered with minor changes to ipv6-cpe-router and ipv6-cpe-router-bis? Jack From gnakibly@yahoo.com Mon Jan 31 10:41:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540D33A6977 for ; Mon, 31 Jan 2011 10:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 aGD71B27alU3 for ; Mon, 31 Jan 2011 10:41:02 -0800 (PST) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by core3.amsl.com (Postfix) with SMTP id 667403A6847 for ; Mon, 31 Jan 2011 10:41:02 -0800 (PST) Received: from [98.139.91.63] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 31 Jan 2011 18:44:15 -0000 Received: from [98.139.91.46] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 31 Jan 2011 18:44:15 -0000 Received: from [127.0.0.1] by omp1046.mail.sp2.yahoo.com with NNFMP; 31 Jan 2011 18:44:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 118384.14751.bm@omp1046.mail.sp2.yahoo.com Received: (qmail 4197 invoked by uid 60001); 31 Jan 2011 18:44:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296499454; bh=jMYiZa1ufKousMTvcVDpZ+tr/LOFhJp6c7YWTnV2waU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zShADXwpwuHK4ru4PgGR1A2CiPxal3BS3ELGlzOnU6tq7t+3uftOC3Q4ofAb33cMieZxcz2DaDzL+lPZSVqWcbL2bxKYGZt7NNBHWFL2IgHIE0MXFPvassMkABbov1ZAdmqLMSUybNWhCS7mayNN7seZtLB5wcrin9rWXcBQoJs= 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:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zOImwAGUMCRdeap9lrlpwRmIrred1wzA0NVHXf0Or5Wy2oOsro2BoXhKUEVVeoIZXli+JHmr41zW1al67CNmgmA45RsUCUB2bAzlwjbFT6TsrjIvW1N3TCP6lEE8HxBYOed+g35lHvsZCu56+h8zTLfnKeq/FD+cxpd3xJP+cwY=; Message-ID: <928191.3448.qm@web45511.mail.sp1.yahoo.com> X-YMail-OSG: r61Kc7UVM1mPNirtjyZ9kP0A._2J28hCBJWUsw2cCWZp.1X B29WcOqPNRwaXT917VYTbKvQSraueXy4MOowHzyiNhrNPFlFK3ic83KUxzb. wzjOQKdqsIPVJ.c4yUZcYRrSh9pOzA9aFZLRfIXbTrjioYQg2FSS292yxmZM PbaDOCdkfpYMx3y.E9YuQ6BnOwR3jNDlgGfs98tzbiz9XEYK3Gz9mRPefQfU lU8N6XXh_yeU.cjsZ9r88ab99YLFhP9PSu_KQOXaJrnWFdUkasiv6hsdubB3 D59xlQ8DhgD.Q2rjcFsNq0jHrHw-- Received: from [85.64.218.22] by web45511.mail.sp1.yahoo.com via HTTP; Mon, 31 Jan 2011 10:44:14 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <20110124211501.32119.87679.idtracker@localhost> <4433A997-446D-436F-ADF4-E1B0508817B1@employees.org> Date: Mon, 31 Jan 2011 10:44:14 -0800 (PST) From: Gabi Nakibly To: Ole Troan , Fred L Templin In-Reply-To: <4433A997-446D-436F-ADF4-E1B0508817B1@employees.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1814870374-1296499454=:3448" Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:41:03 -0000 --0-1814870374-1296499454=:3448 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ole,=0AWe shall reference rfc 5969 with regard to the mitigation text. = =0AWhat do mean by "make a difference"? In what way? The routing loop works= the =0Asame for both types of mechanisms.=0A=0AGabi=0A=0A=0A=0A___________= _____________________=0AFrom: Ole Troan =0ATo: Gabi N= akibly ; Fred L Templin =0A= =0ACc: IPv6 Operations =0ASent: Wed, January 26, 2011 11:23= :22 AM=0ASubject: Re: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-02.t= xt=0A=0AGabi, Fred,=0A=0Awith regards to 6rd.=0A- update reference to rfc59= 69=0A- reference 5969's looping mitigation text=0A=0Ain general, make a dif= ference between global tunneling mechanisms like 6to4 and =0Alocal tunnel m= echanisms like ISATAP and 6rd.=0A=0Acheers,=0AOle=0A=0A=0AOn Jan 24, 2011, = at 22:15 , Internet-Drafts@ietf.org wrote:=0A=0A> A New Internet-Draft is a= vailable from the on-line Internet-Drafts =0Adirectories.=0A> This draft is= a work item of the IPv6 Operations Working Group of the IETF.=0A> =0A> =0A= > =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Routing Loop Attack using IPv6 Autom= atic Tunnels: Problem =0A>Statement and Proposed Mitigations=0A> =A0=A0=A0 = Author(s)=A0 =A0 =A0 : G. Nakibly, F. Templin=0A> =A0=A0=A0 Filename=A0 =A0= =A0 =A0 : draft-ietf-v6ops-tunnel-loops-02.txt=0A> =A0=A0=A0 Pages=A0 =A0 = =A0 =A0 =A0 : 13=0A> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2011-01-24=0A>= =0A> This document is concerned with security vulnerabilities in IPv6-in-= =0A> IPv4 automatic tunnels.=A0 These vulnerabilities allow an attacker to= =0A> take advantage of inconsistencies between the IPv4 routing state and= =0A> the IPv6 routing state.=A0 The attack forms a routing loop which can b= e=0A> abused as a vehicle for traffic amplification to facilitate DoS=0A> a= ttacks.=A0 The first aim of this document is to inform on this attack=0A> a= nd its root causes.=A0 The second aim is to present some possible=0A> mitig= ation measures.=0A> =0A> A URL for this Internet-Draft is:=0A> http://www.i= etf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-02.txt=0A> =0A> Inter= net-Drafts are also available by anonymous FTP at:=0A> ftp://ftp.ietf.org/i= nternet-drafts/=0A> =0A> Below is the data which will enable a MIME complia= nt mail reader=0A> implementation to automatically retrieve the ASCII versi= on of the=0A> Internet-Draft.=0A> ________________________= _______________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https= ://www.ietf.org/mailman/listinfo/v6ops=0A=0A=0A --0-1814870374-1296499454=:3448 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ole,
=0A
We shall reference rfc 5969 with regard to t= he mitigation text.
=0A
What do mean by "make a difference"? In w= hat way? The routing loop works the same for both types of mechanisms.=0A
 
=0A
Gabi
=0A

=0A
=0A
=0AFrom: O= le Troan <otroan@employees.org>
To: Gabi Nakibly <gnakibly@yahoo.com>; Fred L Templin &= lt;Fred.L.Templin@boeing.com>
Cc= : IPv6 Operations <v6ops@ietf.org>
Sent: Wed, January 26, 2011 11:23:22 AM
<= SPAN style=3D"FONT-WEIGHT: bold">Subject: Re: [v6ops] I-D Action= :draft-ietf-v6ops-tunnel-loops-02.txt

Gabi, Fred,

with= regards to 6rd.
- update reference to rfc5969
- reference 5969's loo= ping mitigation text

in general, make a difference between global tu= nneling mechanisms like 6to4 and local tunnel mechanisms like ISATAP and 6r= d.

cheers,
Ole


On Jan 24, 2011, at 22:15 , Internet-Drafts@ietf.org w= rote:

> A New Internet-Draft is available from the on-line Intern= et-Drafts directories.
> This draft is a work item of the IPv6 Operat= ions Working Group of the IETF.
>
>
>    = ; Title          : Routing Loop Attack using IPv6 = Automatic Tunnels: Problem Statement and Proposed Mitigations
>  = ;   Author(s)      : G. Nakibly, F. Templin
>= ;     Filename        : draft-ietf-v6ops= -tunnel-loops-02.txt
>     Pages      &= nbsp;   : 13
>     Date       = ;     : 2011-01-24
>
> This document is concerned wi= th security vulnerabilities in IPv6-in-
> IPv4 automatic tunnels.&nbs= p; These vulnerabilities allow an attacker to
> take advantage of inconsistencies between the IPv4 routing state and
> the IPv6 rou= ting state.  The attack forms a routing loop which can be
> abus= ed as a vehicle for traffic amplification to facilitate DoS
> attacks= .  The first aim of this document is to inform on this attack
> = and its root causes.  The second aim is to present some possible
&g= t; mitigation measures.
>
> A URL for this Internet-Draft is:<= BR>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-0= 2.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 a= utomatically retrieve the ASCII version of the
> Internet-Draft.
&= gt; <Mail Attachment>_______________________________________________
> v6op= s mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listin= fo/v6ops


=0A=0A --0-1814870374-1296499454=:3448-- From jason_livingood@cable.comcast.com Mon Jan 31 10:49:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412893A6A7A for ; Mon, 31 Jan 2011 10:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.683 X-Spam-Level: X-Spam-Status: No, score=-106.683 tagged_above=-999 required=5 tests=[AWL=1.779, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvBWDZw14geJ for ; Mon, 31 Jan 2011 10:49:22 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 771453A6847 for ; Mon, 31 Jan 2011 10:49:22 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.112279522; Mon, 31 Jan 2011 13:52:32 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Mon, 31 Jan 2011 13:52:32 -0500 From: "Livingood, Jason" To: "HUANG, JERRY (ATTSI)" Thread-Topic: [v6ops] v6-aaaa-whitelisting-implications -- 6, Reasons for Brokenness Detailed?? Thread-Index: AQHLvNUtb471ucT1+0uLM5M1BH0e2ZPiNU3ggAlBEAA= Date: Mon, 31 Jan 2011 18:52:30 +0000 Message-ID: In-Reply-To: <2FFFD6E98F51BE43878BFED80215F83808B9DBF8@misout7msgusr7a.ugd.att.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.227.141] Content-Type: multipart/alternative; boundary="_000_C96C6C4F16521jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- 6, Reasons for Brokenness Detailed?? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:49:24 -0000 --_000_C96C6C4F16521jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks =96 I'll add references to the ISOC page and to the Heise trial in t= he =9602 update. Jason On 1/25/11 4:43 PM, "HUANG, JERRY (ATTSI)" > wrote: Jason, Unless you have not seen this, the link http://www.h-online.com/features/The-big-IPv6-experiment-1165042.html is referenced at the IPv6 World Day homepage: http://isoc.org/wp/worldipv= 6day/ www.heise.de dual-stacked their portal 4Q2010 after = a one-day experiment in September and have reported no major issues. The li= nk also discussed some observed cases of IPv6 brokenness. Thanks, Jerry -- Jerry Huang, AT&T Labs, +1 630 719 4389 From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Livingood, Jason Sent: Tuesday, January 25, 2011 15:17 To: v6ops@ietf.org Subject: [v6ops] v6-aaaa-whitelisting-implications -- 6, Reasons for Broken= ness Detailed?? re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt In Section 6 (and other parts of the document), I make a passing reference = to the causes of IPv6 brokenness. One open question is whether that is fine= OR whether I should list the various causes of IPv6 brokenness (or add mor= e references to documents which may already do so). Thanks Jason --_000_C96C6C4F16521jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7114EB4C48B28B40B122A459DEF541C1@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Thanks =96 I'll add references to the ISOC page and to the Heise trial= in the =9602 update.

Jason

On 1/25/11 4:43 PM, "HUANG, JERRY (ATTSI)" <zh1424@att.com> wrote:

Jason,

  Unless you have not seen this, the= link

   http://www.h-online.c= om/features/The-big-IPv6-experiment-1165042.html

  is reference= d at the IPv6 World Day homepage: http://isoc.org/wp/worl= dipv6day/

 

  www.heise.de dual-stacked their portal = 4Q2010 after a one-day experiment in September and have reported no major i= ssues. The link also discussed some observed cases of IPv6 brokenness.

 

Thanks,

Jerry

--

Jerry Huang, AT&T Labs, +1 630 71= 9 4389

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Tuesday, January 25, 2011 15:17
To: v6ops@ietf.org
Subject: [v6ops] v6-aaaa-whitelisting-implications -- 6, Reasons for= Brokenness Detailed??

 

 

In Section 6 (and other parts of the document), I make a passi= ng reference to the causes of IPv6 brokenness. One open question is whether= that is fine OR whether I should list the various causes of IPv6 brokenness (or add more references to documents= which may already do so). 

 

Thanks

Jason

 

 --_000_C96C6C4F16521jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Mon Jan 31 10:57:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791E83A6965 for ; Mon, 31 Jan 2011 10:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.742 X-Spam-Level: X-Spam-Status: No, score=-106.742 tagged_above=-999 required=5 tests=[AWL=1.720, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olzHd6ly9H+r for ; Mon, 31 Jan 2011 10:57:16 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BE31B3A67AA for ; Mon, 31 Jan 2011 10:57:15 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.112280584; Mon, 31 Jan 2011 14:00:20 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Mon, 31 Jan 2011 14:00:17 -0500 From: "Livingood, Jason" To: "HUANG, JERRY (ATTSI)" Thread-Topic: [v6ops] v6-aaaa-whitelisting-implications -- 7.3,Additional Implications? Thread-Index: AQHLvNsReX7Q919QvkK9EXUvD1vONJPreHsA Date: Mon, 31 Jan 2011 19:00:15 +0000 Message-ID: In-Reply-To: <2FFFD6E98F51BE43878BFED80215F83808B9DC23@misout7msgusr7a.ugd.att.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.227.141] Content-Type: multipart/alternative; boundary="_000_C96C70CD16545jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- 7.3, Additional Implications? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:57:17 -0000 --_000_C96C70CD16545jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good point, and thanks for conducting a review of the document! Jason On 1/25/11 4:58 PM, "HUANG, JERRY (ATTSI)" > wrote: Jason, One of the perhaps unintended consequences of DNS whitelisting is that so= meone connected to an IPv4 ISP whose DNS resolvers may not have been (unive= rsally) whitelisted would not be able to get any IPv6 records, which would = give him the misconception that there is no IPv6 content. As you know, a lo= t of people frequently do =93top one million website IPv6=92ness=94 surveys= . This could apply to people using (non-automatic, non-6to4) IPv6-over-IPv4= tunnel connectivity, such as those provided by tunnel brokers, even though= they have perfectly good IPv6 connectivity. Thanks, Jerry -- Jerry Huang, AT&T Labs, +1 630 719 4389 From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Livingood, Jason Sent: Tuesday, January 25, 2011 15:18 To: v6ops@ietf.org Subject: [v6ops] v6-aaaa-whitelisting-implications -- 7.3,Additional Implic= ations? re http://www.ietf.org/id/draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-01.txt I removed any editorial notes calling for additional implications (such as = in 7.3.2, 7.3.3, etc.), as I have received no suggestions. As a result, I'd= like to make one last call for anyone to suggest additional operational im= plications for inclusion. Not that I'll complain if no one has any more =97= it's less work for me in producing the -02 update. ;=96) Thanks Jason --_000_C96C70CD16545jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <458A577F281CE54ABF6B97C78F61DEBD@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Good point, and thanks for conducting a review of the document!

Jason

On 1/25/11 4:58 PM, "HUANG, JERRY (ATTSI)" <zh1424@att.com> wrote:

Jason,

  One of the perhaps unintended cons= equences of DNS whitelisting is that someone connected to an IPv4 ISP whose= DNS resolvers may not have been (universally) whitelisted would not be able to get any IPv6 records, which would give hi= m the misconception that there is no IPv6 content. As you know, a lot of pe= ople frequently do =93top one million website IPv6=92ness=94 surveys.

 

  This could apply to people using (= non-automatic, non-6to4) IPv6-over-IPv4 tunnel connectivity, such as those = provided by tunnel brokers, even though they have perfectly good IPv6 connectivity.

 

Thanks,

Jerry

--

Jerry Huang, AT&T Labs, +1 630 71= 9 4389

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Tuesday, January 25, 2011 15:18
To: v6ops@ietf.org
Subject: [v6ops] v6-aaaa-whitelisting-implications -- 7.3,Additional= Implications?

 

 

I removed any editorial notes calling for additional implicati= ons (such as in 7.3.2, 7.3.3, etc.), as I have received no suggestions. As = a result, I'd like to make one last call for anyone to suggest additional operational implications for inclusi= on. Not that I'll complain if no one has any more =97 it's less work for me= in producing the -02 update. ;=96)

 

Thanks

Jason

 --_000_C96C70CD16545jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Mon Jan 31 11:10:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33613A6C47 for ; Mon, 31 Jan 2011 11:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=-1.699, 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 ztEqJ+RKMxSo for ; Mon, 31 Jan 2011 11:10:37 -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 CEFB83A6C40 for ; Mon, 31 Jan 2011 11:10:36 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24024670; Mon, 31 Jan 2011 12:24:47 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Mon, 31 Jan 2011 14:13:48 -0500 From: "Livingood, Jason" To: Martin Millnert Thread-Topic: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OJPjZw6AgAB5nQCAAAhtAIAACSCAgACAyQCABwlOgA== Date: Mon, 31 Jan 2011 19:13:47 +0000 Message-ID: In-Reply-To: <1296096402.2763.20.camel@shakira.millnert.se> 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.227.141] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:10:37 -0000 Thanks for the feedback, and for the reference suggested at the end. I'll add that to the -02 update, as well ensure that any speculation is explicitly described as such. BTW, based on your email, sounds like good input for an "Objectives for World IPv6 Day" document! Regards Jason On 1/26/11 9:46 PM, "Martin Millnert" wrote: >Jason, > >On Thu, 2011-01-27 at 01:18 +0000, Livingood, Jason wrote: >> Fair point. It is speculative on my part (and as discussed with other >> ISPs / operators). Given that, is it best discussed elsewhere in the >> document as speculative or removed or something else in your view? >> Open to suggestions on how to resolve this. >>=20 > >I don't think I'm the best person on the plane to answer that. :) > >My 2 cents are, I guess, that the measurements methods deployed, and >more specifically the analysis performed, by participants of the World >IPv6 day should be able to answer this for us "once and for all^Wmost" > >So to the participants of World IPv6 day, it would obviously be >extremely valuable for the community if you could: > 1) Be as open as possible about how you measure the brokenness, state >and explain your assumptions and (if possible), verify/refute as many of >them as possible (I too am interested in the answer to the question on >how many % of Internet users have broken v4 :) ) > 2) Publish the brokenness seen. > 2) Save logs or similar in ways that data can be compared using the >same methods (it wouldn't hurt with a ~simplified w3c-log-parser fed >with logs in an appropriate manner, released to the community), so that >there is an at least pseudo-standardized way for the industry to measure >this, as it conceivably vary between geographical areas/markets, etc. >(comparability / "reproducibility" is quite central to scientific work, >right?) > >I believe the industry share an interest in getting the transition off >its wheels, so I hope something along the lines of what I suggest above >can be done. It would be awesome, simply, IMO. > > >Now with that suggestion out there, I think it is a valid and fair >question to raise in the document, but it should perhaps be explicitly >clear that it is speculative to minimize the % of careless readers who >mistake it for fact? (Make no mistake: I like and want IPv6 deployed!) > Not sure if a specific section on ipv6-% brokeness measurement methods >is appropriate, as you say it might be better discussed elsewhere (and >instead referenced). [While by no means claiming to be any kind of >all-knower on the subject, ] I think the goog-v6-quadrett's paper, >"Evaluating IPv6 adoption in the Internet" >( http://www.google.com/research/pubs/pub36240.html ) is a good >reference to begin with. > >HTH, >Cheers, >Martin > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jason_livingood@cable.comcast.com Mon Jan 31 11:19:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D253A6C52 for ; Mon, 31 Jan 2011 11:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-2.246, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, J_CHICKENPOX_62=0.6, 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 OqIfD1CEKhXQ for ; Mon, 31 Jan 2011 11:19:44 -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 A69353A6C4D for ; Mon, 31 Jan 2011 11:19:44 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24026524; Mon, 31 Jan 2011 12:33:17 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Mon, 31 Jan 2011 14:22:36 -0500 From: "Livingood, Jason" To: Nicholas Weaver Thread-Topic: [DNSOP] draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 Thread-Index: AQHLvNRqPcxWdjbsU0G4DnccijWfJZPjMowAgACM54CAB79UgA== Date: Mon, 31 Jan 2011 19:22:35 +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.227.141] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [DNSOP] draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:19:45 -0000 Nick - Thanks for your feedback and for reviewing the draft! I will add these references to the -02 update. Thanks! Jason On 1/26/11 11:04 AM, "Nicholas Weaver" wrote: > >On Jan 26, 2011, at 4:39 AM, Livingood, Jason wrote: > >> At the last IETF meeting I presented my individual I-D on IPv6 DNS >>whitelisting. This was subsequently adopted as a WG item in v6ops. >>Yesterday, I posted a new -01 version of this draft for WG feedback by >>v6ops and dnsop at >>http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implicat >>ions-01. I expect to receive some feedback, primarily in v6ops, and then >>quickly incorporate that into a =AD02 which will then hopefully be mature >>enough to stand for a WGLC. --> There are several items listed below >>that I am seeking specific dnsop WG feedback on. <-- >>=20 >> 1 - Figure 2 has been updated. As was pointed out at the IETF meeting, >>this was a bit lacking in detail (did not show both A and AAAA queries). >>Let me know if this updated figure is suitable or if it still could use >>some tweaks. >>=20 >> 2 =AD Section 4.2: Any good reference(s) to round robin DNS as a load >>balancing technique? > >Actually far more than just round robin: > >http://www.stanford.edu/~riepel/lbnamed/ > >Described in LISA IX, 1995 > >http://www.stanford.edu/~riepel/lbnamed/lisa95-paper.ps > > >Round robin code in Bind dates back to at least then if not before, the >current usage is the rrset-order option: >http://www.zytrax.com/books/dns/ch7/queries.html#rrset-order > > >> 3 =AD Section 4.2: Any good reference(s) to the technical subject of loa= d >>balancing in general? >>=20 >> 4 =AD Section 4.2: Any good reference(s) to the practice of CDNs varying >>their DNS query responses based on an estimated geographic location? > >There's the IMC measurement paper on DNS which showed very big >differences between local and third party DNS for akamai'ed sites: > >http://conferences.sigcomm.org/imc/2010/papers/p15.pdf > >(Its also a good datapoint for why edns-client-subnet would be a good >idea if you want good results from 3rd party DNS) > >That if you are using your ISP's resolver, you get a lot more results in >the ISP's AS. So they are using NETWORK location of the resolver for >this at least. > > > >You can see the results for geographic as well somewhat if you look at >google's returned results (you get east coast, I get west coast), but I >don't know of a citation for it. > > >>=20 >> Thanks in advace! >> Jason >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > From jason_livingood@cable.comcast.com Mon Jan 31 11:22:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12E63A6C54 for ; Mon, 31 Jan 2011 11:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=-3.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, SARE_LWSHORTT=1.24, 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 bCrc9V-q-iZx for ; Mon, 31 Jan 2011 11:22:20 -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 3A0EC3A6C52 for ; Mon, 31 Jan 2011 11:22:20 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24023868; Mon, 31 Jan 2011 12:20:08 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Mon, 31 Jan 2011 14:09:47 -0500 From: "Livingood, Jason" To: "George, Wes E [NTK]" Thread-Topic: v6-aaaa-whitelisting-implications -- Recommended Practice? Thread-Index: AQHLvNV8QFfOnLCpIUKo3x7PO581OJPjZw6AgACIYYCABzy3UIAATwmA Date: Mon, 31 Jan 2011 19:09:46 +0000 Message-ID: In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E06D9BB@PLSWM12A.ad.sprint.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.227.141] Content-Type: multipart/alternative; boundary="_000_C96C72FF1654Ejasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:22:22 -0000 --_000_C96C72FF1654Ejasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Great =97 thanks for the feedback and for reviewing the document! This chan= ge will be in the =9602 version. Regards Jason On 1/31/11 9:27 AM, "George, Wes E [NTK]" > wrote: Sounds ok to me. I was also one of the ones suggesting that you watch the g= eneric =93some parties=94 language, but in this case I agree that it=92s he= lpful. Thanks, Wes From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Wednesday, January 26, 2011 8:19 PM To: George, Wes E [NTK]; v6ops@ietf.org Subject: Re: v6-aaaa-whitelisting-implications -- Recommended Practice? However, personally I?d remove the reference to Google. As much as I apprec= iate the info that Lorenzo and Erik and company have provided and the work = that they?ve done, let?s keep this company agnostic ? that?s more appropria= te for an IETF draft, and less likely to skew opinions in one direction or = the other. That is a fair point. I was actually trying to react to feedback from Erik = himself on 10/1/2010 to the list where I perceived he wanted to have the nu= merous vague "some parties" made more specific. I want to also be clear tha= t I went to pains in my previous drafts and in my presentations to not cite= specific company names, as this is an industry issue and not a company iss= ue. I will carefully go back through my =9601 version and change these refe= rences back. I will also change this addition as well. (See below) You might also want to at least casually mention world IPv6 day as a way to determine if whitelisting is actually necessary even in the short term. Since this draft will have likely gone to WGLC before that happens, at leas= t a passing reference to it would allow you to perhaps nudge the reader into looking for the information that will become available once everyone analyzes the results of enabling unfettered IPv6 access to their content fo= r the day. Good suggestion. Here is the new text: Opinions in the Internet community concerning whether or not DN= S whitelisting is a recommended practice are understandably quite varied. H= owever, there is clear consensus that DNS whitelisting is at best a useful = temporary measure which a domain may choose to pursue as they prepare for t= he transition to IPv6. In particular, major domains view DNS whitelisting a= s one of the few practical and low risk approaches enabling them to prepare= for the transition to IPv6. Thus, DNS whitelisting is not a recommended pr= actice over the long-term. In addition, DNS whitelisting should be avoided = wherever possible in the short-term and its use is discouraged. Nevertheles= s, major domains may find DNS whitelisting a beneficial temporary tactic in= their transition to IPv6. Such temporary use during the transition to IPv6= is broadly accepted within the community, so long as it does not become a = long-term practice. Finally, World IPv6 Day, which is sponsored by the Internet Soc= iety [ADD REFERENCE] and is scheduled to occur on June 8, 2011, will be an = opportunity for domains to add AAAA resource records to the DNS without usi= ng DNS whitelisting. As a result, this is likely an excellent opportunity f= or domains to evaluate the utility or necessity of DNS whitelisting, even i= n the short-term. // --_000_C96C72FF1654Ejasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <69108AD0190159418F5ABFFD80604825@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Great =97 thanks for the feedback and for reviewing the document! This= change will be in the =9602 version.

Regards
Jason


On 1/31/11 9:27 AM, "George, Wes E [NTK]" <Wesley.E.George@sprint.com> wrote:

Sounds ok to me. I was also one of= the ones suggesting that you watch the generic =93some parties=94 language= , but in this case I agree that it=92s helpful.

 

Thanks,
Wes
 

From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Wednesday, January 26, 2011 8:19 PM
To: George, Wes E [NTK]; v6ops@iet= f.org
Subject: Re: v6-aaaa-whitelisting-implications -- Recommended Practi= ce?

 

However, personally I?d remove the reference to Google. As muc= h as I appreciate the info that Lorenzo and Erik and company have prov= ided and the work that they?ve done, let?s keep this company agnostic ? that?s more appropriate for an IETF draf= t, and less likely to skew opinions in one direction or the other.

 

That is a fair point. I was actually trying to react to feedba= ck from Erik himself on 10/1/2010 to the list where I perceived he wanted t= o have the numerous vague "some parties" made more specific. I want to also be clear that I went to pains in my pre= vious drafts and in my presentations to not cite specific company names, as= this is an industry issue and not a company issue. I will carefully go bac= k through my =9601 version and change these references back. I will also change this addition as well.  (Se= e below)

 

You might also want to at least casually mention world IPv6 da= y as a way to

determine if whitelisting is actually necessary even in the sh= ort term.

Since this draft will have likely gone to WGLC before that hap= pens, at least

a passing reference to it would allow you to perhaps nudge the= reader into

looking for the information that will become available once ev= eryone

analyzes the results of enabling unfettered IPv6 access to the= ir content for

the day.

 

Good suggestion. Here is the new text:

 

            Opinions in = the Internet community concerning whether or not DNS whitelisting is a reco= mmended practice are understandably quite varied. However, there is clear consensus that DNS whitelisting is at best a useful temporary measure whic= h a domain may choose to pursue as they prepare for the transition to IPv6.= In particular, major domains view DNS whitelisting as one of the few pract= ical and low risk approaches enabling them to prepare for the transition to IPv6. Thus, DNS whitelisting is not = a recommended practice over the long-term. In addition, DNS whitelisting sh= ould be avoided wherever possible in the short-term and its use is discoura= ged. Nevertheless, major domains may find DNS whitelisting a beneficial temporary tactic in their transitio= n to IPv6. Such temporary use during the transition to IPv6 is broadly acce= pted within the community, so long as it does not become a long-term practi= ce.

            <= span style=3D"color: black; font-family: Calibri, sans-serif; ">=

            Finally, Wor= ld IPv6 Day, which is sponsored by the Internet Society [ADD REFERENCE] and= is scheduled to occur on June 8, 2011, will be an opportunity for domains to add AAAA resource records to the DNS without using DNS whitelisting. As= a result, this is likely an excellent opportunity for domains to evaluate = the utility or necessity of DNS whitelisting, even in the short-term.=

 

//

 

 

--_000_C96C72FF1654Ejasonlivingoodcablecomcastcom_-- From ichiroumakino@gmail.com Mon Jan 31 12:00:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9683A6C7A for ; Mon, 31 Jan 2011 12:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 yfyOlynv6sf5 for ; Mon, 31 Jan 2011 12:00:03 -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 94A5E3A6C76 for ; Mon, 31 Jan 2011 12:00:02 -0800 (PST) Received: by ewy8 with SMTP id 8so3026861ewy.31 for ; Mon, 31 Jan 2011 12:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=vmyQaSSdvv8MibY3KpBnOKTEunhZQZ9qXmochZMOFek=; b=X8S+idbnOj5EpQvMDhZGv6pbwRw7kMRpkrHEuEofUp/c3Jq5yB/gGzpSaru7WRNdqu lEbYy1PT2l2hhGtv8n5Rac18vL3bB1t3Hz/5TQ55GLsYuCR0KqvdhBt4nIS2TO5L5/kT tebmsqkcrMao4JHMqCidm+cfxTCnLh9ldjJ0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MGYBwKq+z388IpRFleQrys7syqFmKEOUuNOxaquUiufuOv3rVt0tkQcePv9LovFW1l lcTUrDvZBwVv/cvF/CB8L7cRLWiBuHbXC/WzAZe+dYvSYkHd/VTZFwoCMnvhbsBcvTtC W5iqBKOUVDZ9JjWHF6PPIFNPR9J4IbY2+Iho0= Received: by 10.213.4.134 with SMTP id 6mr9055450ebr.14.1296504196386; Mon, 31 Jan 2011 12:03:16 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id t50sm16635209eeh.0.2011.01.31.12.03.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 12:03:15 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 31 Jan 2011 21:03:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:00:06 -0000 lots of (old) proposals in this space: http://tools.ietf.org/html/draft-noisette-zerouter-frmwk-00 http://tools.ietf.org/html/draft-marce-zerouter-archi-00 http://tools.ietf.org/html/draft-linton-zerouter-requirements-00 http://tools.ietf.org/html/draft-dimitri-zospf-00 http://tools.ietf.org/html/draft-chelius-router-autoconf-00 http://tools.ietf.org/html/draft-linton-arcp-00 RFC4903 - Multi-link subnet issues http://tools.ietf.org/html/draft-linton-arcp-00 RFC4389 - ND Proxy = http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation-00 http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf suggested requirements: 1) work in an arbitrary topology (including loops) 2) be zero-configuration 3) support both unicast and multicast routing 4) create correct ULA/multicast and "administrative" boundaries 5) support a network with multiple IPv6 CE router (multi-homed) 6) support distribution of other configuration information=09 any other requirements, that we can use to compare proposed solutions = to? cheers, Ole >=20 > On Jan 31, 2011, at 4:04 PM, Jack Bates wrote: >=20 >> Okay. This makes sense. We need the solution document to point to = with the requirements document. It amazes me that one hasn't been = designed this far into the end game. >=20 > There have been a couple of proposals: >=20 >=20 > (1) http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation >=20 > This is targeted at residential/SOHO networks, and has drawbacks = pointed out in the draft if I recall correctly. >=20 > (2) > http://tools.ietf.org/html/draft-sarikaya-netext-prefix-delegation > http://tools.ietf.org/html/draft-sarikaya-int-area-prefix-delegation > http://tools.ietf.org/html/draft-sarikaya-intarea-prefix-delegation > http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation >=20 > This is targeted at mobile networks. We have discussed it as recently = as IETF-79. In the SurveyMonkey survey we ran at that meeting, 26.7% of = respondents said that the draft was unsalvageable or uninteresting and = should be abandoned, 53.3% said it should be adopted as a working group = draft. and the remainder said it was in the wrong working group or = should be an individual effort. That's an interesting range of opinion. = I think Mr Sarikaya would be interested to discuss it if you think it is = valuable. >=20 > (3) > I'm not finding it, but IIRC Ralph Droms and others put in a document = saying in essence that the ISP should delegate a prefix to its = customer's CPE router, and other routers in the domain should use RFC = 3633 to get a /64 delegated to their various interfaces from the CPE. = The drawback here is that it is a manual process - the CPE must somehow = know what to tell the various routers that enquire of it, and no = procedure is defined for identifying what routers share a LAN in the = home unless that LAN is directly attached to the CPE. >=20 >=20 > =46rom my perspective, (3) makes the most sense for residential/SOHO = routers, but it needs a disambiguation procedure. If you have a = home/residential network that is structured other than as a tree, what = routers share links in a manner that is invisible to the CPE? You could = solve that with an Alternate Tuesday rule, for example.=20 >=20 > Imagine: > | | > | +-----------+ | prefix:1::/64 > +--+ His Office+--+ > | +-----------+ | > | | > +-------+ | | > ISP --------+ CPE +--+ +-----------+ | prefix:2::/64 > | Router| +--+ Her Office+--+ > +-------+ | +-----------+ | > | | > prefix:0::/64 > | +-----------+ | > +--+ A/V Router+--+ > | +-----------+ | prefix:4::/64 > | | >=20 > So the ISP gives the CPE a /60 (say), and the CPE allocates a /64 to = each distinct LAN attached to it (perhaps a wired and a wireless LAN). = The other routers each observe that they have another interface and = don't know what to assign to it, ask the CPE router (the one advertising = an RA to them), and it gives them each another prefix, in the above = tagged as prefix:1::, prefix:2::, prefix:3::, and prefix:4::. Note that = the two offices share connectivity that doesn't go throughout the home, = but we now have two prefixes on it. =46rom one perspective, that's not = really a problem, as IPv6 allows multiple prefixes on a LAN. On the = other hand, it's a bit wasteful, and one could probably find ways to = make things really messy. It would be nice if one of the two gave way to = the other in some predictable way and was returned to the CPE or = re-delegation to some other router should the need arise. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Mon Jan 31 12:01:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230E13A6C4E for ; Mon, 31 Jan 2011 12:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 CG2eYNrqUF7i for ; Mon, 31 Jan 2011 12:01:34 -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 82E603A6C79 for ; Mon, 31 Jan 2011 12:01:26 -0800 (PST) Received: by ewy8 with SMTP id 8so3028067ewy.31 for ; Mon, 31 Jan 2011 12:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=rv2eq7AitiJN4YRPvGqOpwWxQctx70enSIs84i6bFOo=; b=NIi4KYtK6I+9XO+supmNuq29rgldFs8CVtd39H8WeeDlmV7t5fJTfHTkcGILvMBha1 hG9rY/5EIK3SiQmtKQSlryySFtpFYMWWqQJ0aSz1Ui8a6mh/9xBRQ5n3n5MTdYtB2j/9 vfhQ4rDd8WfSXIgx5RElfltTTeTpGG/pNUYtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=FD1XFmYuDBsDuRs/0+VPaSYJK51YVVRjRsyMkEJhAoW5zgyyMWeQ7hyX2OK6E+98A/ 0H0jfi29++1QVlaeNhSxj7RUUyvog+Icf0Cymgg6ju8KQVdn7pg+uUhz5KKSY3x8YXm8 Y5b4Y1iN603iPmKt2Bg0cwT5XOJbbUUF5j81g= Received: by 10.213.27.68 with SMTP id h4mr9108632ebc.10.1296504280942; Mon, 31 Jan 2011 12:04:40 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id q52sm4090837eei.15.2011.01.31.12.04.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 12:04:40 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <928191.3448.qm@web45511.mail.sp1.yahoo.com> Date: Mon, 31 Jan 2011 21:04:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F62914C-0C8F-4A42-9E9C-3D7B70EB9D6D@employees.org> References: <20110124211501.32119.87679.idtracker@localhost> <4433A997-446D-436F-ADF4-E1B0508817B1@employees.org> <928191.3448.qm@web45511.mail.sp1.yahoo.com> To: Gabi Nakibly X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:01:36 -0000 Gabi, > We shall reference rfc 5969 with regard to the mitigation text. > What do mean by "make a difference"? In what way? The routing loop = works the same for both types of mechanisms. for intra-site tunneling like ISATAP or 6rd you can protect the borders = of the tunnelled domain. something you cannot do for global tunnelling = mechanisms like Teredo or 6to4. cheers, Ole > =20 > Gabi >=20 > From: Ole Troan > To: Gabi Nakibly ; Fred L Templin = > Cc: IPv6 Operations > Sent: Wed, January 26, 2011 11:23:22 AM > Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-02.txt >=20 > Gabi, Fred, >=20 > with regards to 6rd. > - update reference to rfc5969 > - reference 5969's looping mitigation text >=20 > in general, make a difference between global tunneling mechanisms like = 6to4 and local tunnel mechanisms like ISATAP and 6rd. >=20 > cheers, > Ole >=20 >=20 > On Jan 24, 2011, at 22:15 , 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 IPv6 Operations Working Group of = the IETF. > >=20 > >=20 > > Title : Routing Loop Attack using IPv6 Automatic = Tunnels: Problem Statement and Proposed Mitigations > > Author(s) : G. Nakibly, F. Templin > > Filename : draft-ietf-v6ops-tunnel-loops-02.txt > > Pages : 13 > > Date : 2011-01-24 > >=20 > > This document is concerned with security vulnerabilities in IPv6-in- > > IPv4 automatic tunnels. These vulnerabilities allow an attacker to > > take advantage of inconsistencies between the IPv4 routing state and > > the IPv6 routing state. The attack forms a routing loop which can = be > > abused as a vehicle for traffic amplification to facilitate DoS > > attacks. The first aim of this document is to inform on this attack > > and its root causes. The second aim is to present some possible > > mitigation measures. > >=20 > > A URL for this Internet-Draft is: > > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-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. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 From jbates@brightok.net Mon Jan 31 13:01:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09713A6C6E for ; Mon, 31 Jan 2011 13:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 wBjXk7fZZrnW for ; Mon, 31 Jan 2011 13:01:41 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id D980C3A6856 for ; Mon, 31 Jan 2011 13:01:40 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VL4rJa010213; Mon, 31 Jan 2011 15:04:54 -0600 (CST) Message-ID: <4D4723F5.9000201@brightok.net> Date: Mon, 31 Jan 2011 15:04:53 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ole Troan References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> In-Reply-To: <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:01:42 -0000 On 1/31/2011 2:03 PM, Ole Troan wrote: > lots of (old) proposals in this space: > > http://tools.ietf.org/html/draft-noisette-zerouter-frmwk-00 > http://tools.ietf.org/html/draft-marce-zerouter-archi-00 > http://tools.ietf.org/html/draft-linton-zerouter-requirements-00 > http://tools.ietf.org/html/draft-dimitri-zospf-00 > http://tools.ietf.org/html/draft-chelius-router-autoconf-00 > http://tools.ietf.org/html/draft-linton-arcp-00 > RFC4903 - Multi-link subnet issues > http://tools.ietf.org/html/draft-linton-arcp-00 > RFC4389 - ND Proxy > http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation-00 > http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf > Is there an existing proposal for provider side? I ask, as the two sorta go hand in hand. As part of my process of determining the most efficient overall scheme, I've written up some starting logic for the DHCPv6 server to adapt to more efficient CPE/ISP/routing abilities. It's VERY rough. http://geekmerc.livejournal.com/1846.html From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 31 13:03:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B013A6C6D for ; Mon, 31 Jan 2011 13:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 tUd0lfHDgDvU for ; Mon, 31 Jan 2011 13:03:25 -0800 (PST) Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id A0C153A6814 for ; Mon, 31 Jan 2011 13:03:24 -0800 (PST) Received: from 219-90-141-60.ip.adam.com.au ([219.90.141.60] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pk0x8-00089l-Cg; Tue, 01 Feb 2011 07:36:26 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 076F13B336; Tue, 1 Feb 2011 07:36:24 +1030 (CST) Date: Tue, 1 Feb 2011 07:36:23 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110201073623.5628b0b9@opy.nosense.org> In-Reply-To: <4D46F5BD.2050704@brightok.net> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:03:26 -0000 On Mon, 31 Jan 2011 11:47:41 -0600 Jack Bates wrote: > > > On 1/31/2011 10:56 AM, Fred Baker wrote: > > There have been a couple of proposals: > > I'll read through them. However, I think we could accomplish most of it > (except for the actual algorithm for finding necessary space in a > delegation). > > draft-ietf-v6ops-ipv6-cpe-router-07 > > > WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating > router the size of the prefix it requires. If so, it MUST > ask for a prefix large enough to assign one /64 for each of > its interfaces rounded up to the nearest nibble and MUST be > configurable to ask for more. > > Really needs to be SHOULD, to support proper support and > interoperability in a chained environment. It is likely that most > providers (though not always) will provide a hard set prefix, while it > is better for chained CPE's to support prefix hinting. If a CPE is to be > fully interoperable with chaining, this actually would need to be MUST. > I disagree (as I have before). The link between the customer and the ISP should be a routing aggregation boundary, so that the customer's topology and topology changes are hidden from the ISP. Allocate a /56 or /48 to the customer (or what ever size the ISP is operationally comfortable with), and then leave it up to them what they do with it. Consider the operational consequences of allowing customers to make dynamic subnet requests - - your customer aggregation routers will now have additional control plane load of processing those requests. This may also create involve additional load on backend authentication servers. Some malicious customers (let's call then "kids") might use this as a DoS vector, for Saturday afternoon entertainment. - you can't as easily predict your customer address space usage, as it is potentially constantly and unpredictably changing over time. - you're going to have to record each and every request and release of /64s, so that you can determine which customer who was using a particular /64 at a particular time in the past, for troubleshooting or law enforcement purposes. Some people may be tempted to mitigate some of the above by reserving a maximum assignment per customer e.g. a /48 per customer and then only facilitating the dynamic /64 requests from within that /48. That mitigates two out of the three above, leaving just the processing of these requests. What value does that processing now add? Why bother? Simplify everything by just giving everybody a /48 (or /56 etc.) and be done with it. > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > prefix size different from what is given in the hint. If the > delegated prefix is too small to address all of its > interfaces, the IPv6 CE router SHOULD log a system management > error. > > > It should also attempt to do multiple delegation requests to support > providers that will happily hand out multiple /64 networks, one per > request. Proper methodology would be to use additional IAIDs. > > Per RFC3633 Section 6, Identity Association for Prefix Delegation > > " The IAID uniquely identifies the IA_PD and must be chosen to be > unique among the IA_PD IAIDs on the requesting router. The IAID is > chosen by the requesting router. For any given use of an IA_PD by > the requesting router, the IAID for that IA_PD MUST be consistent > across restarts of the requesting router. The requesting router may > > > maintain consistency either by storing the IAID in non-volatile > storage or by using an algorithm that will consistently produce the > same IAID as long as the configuration of the requesting router has > not changed. If the requesting router uses only one IAID, it can use > a well-known value, e.g., zero. > " > > Items which are missing are the methodology for staging from one > topology type to another. Some of this is covered under > ipv6-cpe-router-bis, in the form of proxy-ND support. It is my belief > that we could expand upon that with existing RFC's, especially with the > minor changes to draft-ietf-v6ops-ipv6-cpe-router-07. > > A likely sequence of determining the appropriate model is, > > 1) If we receive larger than our HINT, we support subdelegation of what > we've received to downstream IA_PD requestors. > > 2) If we receive exactly the size of our HINT, we perform DHCPv6 Relay > for our downstream requestors > > 3) If we receive smaller than our HINT, we should make additional > requests using additonal IAIDs based on the prefix size we did receive > (this is for completeness, as it should be in cpe-router). > > 4) If we do not receive an IA_PD, we perform proxy-ND (which should be > able to be infinitely chained, even if extremely ugly) > > If we are performing subdelegation, we will need to keep certain things > in mind: > > 1) We should limit the size requested downstream (we're a cpe router, so > getting a /48 request would be excessive) > > 2) If a request exceeds what we have available, we need to request with > another IAID from upstream for another block (we received a /60, between > our assignments and downstream assignments, we can no longer answer a > /63 request, so we must ask upstream for another /60). > > The above creates a model that supports: > > proxy-nd if the ISP or upstream CPE refuses to do DHCPv6-PD. > > multiple exact match prefixes for local use and downstream use if ISP > supports very small prefixes (at the cost that the ISP will have to > support additional routes to the max they will allow the customer > network to have). > > Large delegation from ISP, with all internal network CPEs doing DHCPv6 > relay for exact match prefixes. This increases the customer's internal > routing table (unless over time CPE's recognize subdelegations and > increase their hint?), but allows for extremely efficient use of the > space delegated. > > Thoughts? Opinions? Am I wrong to think that as a whole this could be > covered with minor changes to ipv6-cpe-router and ipv6-cpe-router-bis? > > > > Jack > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 31 13:14:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23103A6C8E for ; Mon, 31 Jan 2011 13:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 eX5VFowwdoKm for ; Mon, 31 Jan 2011 13:14:11 -0800 (PST) Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id 5F99A3A6C6E for ; Mon, 31 Jan 2011 13:14:11 -0800 (PST) Received: from 219-90-141-60.ip.adam.com.au ([219.90.141.60] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pk17i-0000GT-I3; Tue, 01 Feb 2011 07:47:22 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 422DE3B336; Tue, 1 Feb 2011 07:47:22 +1030 (CST) Date: Tue, 1 Feb 2011 07:47:22 +1030 From: Mark Smith To: Ole Troan Message-ID: <20110201074722.51e5b7bc@opy.nosense.org> In-Reply-To: <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:14:13 -0000 On Mon, 31 Jan 2011 21:03:13 +0100 Ole Troan wrote: > lots of (old) proposals in this space: > > http://tools.ietf.org/html/draft-noisette-zerouter-frmwk-00 > http://tools.ietf.org/html/draft-marce-zerouter-archi-00 > http://tools.ietf.org/html/draft-linton-zerouter-requirements-00 > http://tools.ietf.org/html/draft-dimitri-zospf-00 > http://tools.ietf.org/html/draft-chelius-router-autoconf-00 > http://tools.ietf.org/html/draft-linton-arcp-00 > RFC4903 - Multi-link subnet issues > http://tools.ietf.org/html/draft-linton-arcp-00 > RFC4389 - ND Proxy > http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation-00 > http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf > > suggested requirements: > 1) work in an arbitrary topology (including loops) > 2) be zero-configuration > 3) support both unicast and multicast routing > 4) create correct ULA/multicast and "administrative" boundaries > 5) support a network with multiple IPv6 CE router (multi-homed) > 6) support distribution of other configuration information I'd be curious as to what sort of other configuration information is to be distributed. If it is starting to including things like DNS server addresses etc., the above is starting to sound like requirements for both automated topology discovery and service discovery. That's not a bad thing, however it then may be worth reviewing what other previous examples have been capable of distributing to help with defining requirements e.g. Novell's NDS and NLSP, and Apple's NBP and similar. > > any other requirements, that we can use to compare proposed solutions to? > > cheers, > Ole > > > > > On Jan 31, 2011, at 4:04 PM, Jack Bates wrote: > > > >> Okay. This makes sense. We need the solution document to point to with the requirements document. It amazes me that one hasn't been designed this far into the end game. > > > > There have been a couple of proposals: > > > > > > (1) http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation > > > > This is targeted at residential/SOHO networks, and has drawbacks pointed out in the draft if I recall correctly. > > > > (2) > > http://tools.ietf.org/html/draft-sarikaya-netext-prefix-delegation > > http://tools.ietf.org/html/draft-sarikaya-int-area-prefix-delegation > > http://tools.ietf.org/html/draft-sarikaya-intarea-prefix-delegation > > http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation > > > > This is targeted at mobile networks. We have discussed it as recently as IETF-79. In the SurveyMonkey survey we ran at that meeting, 26.7% of respondents said that the draft was unsalvageable or uninteresting and should be abandoned, 53.3% said it should be adopted as a working group draft. and the remainder said it was in the wrong working group or should be an individual effort. That's an interesting range of opinion. I think Mr Sarikaya would be interested to discuss it if you think it is valuable. > > > > (3) > > I'm not finding it, but IIRC Ralph Droms and others put in a document saying in essence that the ISP should delegate a prefix to its customer's CPE router, and other routers in the domain should use RFC 3633 to get a /64 delegated to their various interfaces from the CPE. The drawback here is that it is a manual process - the CPE must somehow know what to tell the various routers that enquire of it, and no procedure is defined for identifying what routers share a LAN in the home unless that LAN is directly attached to the CPE. > > > > > > From my perspective, (3) makes the most sense for residential/SOHO routers, but it needs a disambiguation procedure. If you have a home/residential network that is structured other than as a tree, what routers share links in a manner that is invisible to the CPE? You could solve that with an Alternate Tuesday rule, for example. > > > > Imagine: > > | | > > | +-----------+ | prefix:1::/64 > > +--+ His Office+--+ > > | +-----------+ | > > | | > > +-------+ | | > > ISP --------+ CPE +--+ +-----------+ | prefix:2::/64 > > | Router| +--+ Her Office+--+ > > +-------+ | +-----------+ | > > | | > > prefix:0::/64 > > | +-----------+ | > > +--+ A/V Router+--+ > > | +-----------+ | prefix:4::/64 > > | | > > > > So the ISP gives the CPE a /60 (say), and the CPE allocates a /64 to each distinct LAN attached to it (perhaps a wired and a wireless LAN). The other routers each observe that they have another interface and don't know what to assign to it, ask the CPE router (the one advertising an RA to them), and it gives them each another prefix, in the above tagged as prefix:1::, prefix:2::, prefix:3::, and prefix:4::. Note that the two offices share connectivity that doesn't go throughout the home, but we now have two prefixes on it. From one perspective, that's not really a problem, as IPv6 allows multiple prefixes on a LAN. On the other hand, it's a bit wasteful, and one could probably find ways to make things really messy. It would be nice if one of the two gave way to the other in some predictable way and was returned to the CPE or re-delegation to some other router should the need arise. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jbates@brightok.net Mon Jan 31 13:16:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513F23A6C70 for ; Mon, 31 Jan 2011 13:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] 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 YWEItkVLnRMS for ; Mon, 31 Jan 2011 13:16:17 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 5702F3A6814 for ; Mon, 31 Jan 2011 13:16:17 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VLIh4H013844; Mon, 31 Jan 2011 15:18:43 -0600 (CST) Message-ID: <4D472732.5070104@brightok.net> Date: Mon, 31 Jan 2011 15:18:42 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> In-Reply-To: <20110201073623.5628b0b9@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:16:18 -0000 On 1/31/2011 3:06 PM, Mark Smith wrote: > Consider the operational consequences of allowing customers to make > dynamic subnet requests - > > - your customer aggregation routers will now have additional control > plane load of processing those requests. This may also create involve > additional load on backend authentication servers. Some malicious > customers (let's call then "kids") might use this as a DoS vector, > for Saturday afternoon entertainment. The same can be done with a single device making repetitive requests. Control knobs are necessary to protect the ISP in either case. In this case, the CPE itself can self rate-control such requests. > > - you can't as easily predict your customer address space usage, as it > is potentially constantly and unpredictably changing over time. > This is true, though depending on what they are requesting, sparse allocation can resolve this easily enough. > - you're going to have to record each and every request and release > of /64s, so that you can determine which customer who was using a > particular /64 at a particular time in the past, for troubleshooting > or law enforcement purposes. This you do not have to do. You have the DHCPv6 server record the allocation, not the delegation (we reserve a /48, for example, but give out networks within that to the same customer). > Some people may be tempted to mitigate some of the above by reserving > a maximum assignment per customer e.g. a /48 per customer and then only > facilitating the dynamic /64 requests from within that /48. That > mitigates two out of the three above, leaving just the processing of > these requests. What value does that processing now add? Why bother? > Simplify everything by just giving everybody a /48 (or /56 etc.) and be > done with it. Customer is connected to the ISP with bridged DSL modem. Customer connects a switch to the modem and then connects 2 Linksys to the switch. ISP isn't going to handle the customer 2x /48 networks. Granted, ISP could restrict it and say "Only 1 routed device per connection, period!" However, I see no problem with making it more expansive and not forcing this limitation on an ISP. Requests from CPE doing DHCPv6 relay will not be excessively more than a single CPE being plugged and unplugged (or the connection to it flapping). Rate limits should be applied to protect routers, servers, and authentication systems anyways. Jack From ichiroumakino@gmail.com Mon Jan 31 13:24:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DC53A6AF9 for ; Mon, 31 Jan 2011 13:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 glPQgexkGIr6 for ; Mon, 31 Jan 2011 13:24:46 -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 6E1353A6814 for ; Mon, 31 Jan 2011 13:24:46 -0800 (PST) Received: by eyd10 with SMTP id 10so3151240eyd.31 for ; Mon, 31 Jan 2011 13:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=MokbgGNos3IFrCJ4ZYoOue4Bs64ycYn3788wonDW2nE=; b=pWowbMC0Nghc/xNVNghevDVMAov1x0aw2II0B61PEs2SBZv0TYHgXrOAz6Q2WYg364 I9CQS2BsXK5oy8/8IZSipLAl2zJHFHA+MQ7IxcD9uMpzc+/0kVF76Bm1pqCqiBisvlRB V3lTrXr7vckKY9dZNRi48ybvBfUUvP0WhgJuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qeAXrE+P5nE7Fp3DPRvQcdBp8Cr9UU+mM9hRauoF5iGDz0RAnLzS4Q2ysdigK9mpOV W9YjRc8mzYR0KZDa80ERlSAKQj7VdGuedylN8MoyY9D74oMmXsMPR4D1mW8EcNlha51j my5Raeib/nnxm4VQbg1BvV8Gj/T9ZnKWdDjjM= Received: by 10.14.16.164 with SMTP id h36mr231994eeh.37.1296509280703; Mon, 31 Jan 2011 13:28:00 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id u1sm16705107eeh.16.2011.01.31.13.27.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 13:28:00 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <20110201074722.51e5b7bc@opy.nosense.org> Date: Mon, 31 Jan 2011 22:27:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A3ED66C-6DFD-495E-B5C9-C980F4E1694D@employees.org> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <20110201074722.51e5b7bc@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:24:48 -0000 Mark, >> lots of (old) proposals in this space: >>=20 >> http://tools.ietf.org/html/draft-noisette-zerouter-frmwk-00 >> http://tools.ietf.org/html/draft-marce-zerouter-archi-00 >> http://tools.ietf.org/html/draft-linton-zerouter-requirements-00 >> http://tools.ietf.org/html/draft-dimitri-zospf-00 >> http://tools.ietf.org/html/draft-chelius-router-autoconf-00 >> http://tools.ietf.org/html/draft-linton-arcp-00 >> RFC4903 - Multi-link subnet issues >> http://tools.ietf.org/html/draft-linton-arcp-00 >> RFC4389 - ND Proxy >> = http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation-00 >> http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf >>=20 >> suggested requirements: >> 1) work in an arbitrary topology (including loops) >> 2) be zero-configuration >> 3) support both unicast and multicast routing >> 4) create correct ULA/multicast and "administrative" boundaries >> 5) support a network with multiple IPv6 CE router (multi-homed) >> 6) support distribution of other configuration information >=20 > I'd be curious as to what sort of other configuration information is = to > be distributed. If it is starting to including things like DNS server > addresses etc., the above is starting to sound like requirements for > both automated topology discovery and service discovery. That's not a > bad thing, however it then may be worth reviewing what other previous > examples have been capable of distributing to help with > defining requirements e.g. Novell's NDS and NLSP, and Apple's NBP and > similar. e.g. DNS servers. would there be any point to be able to do automatic prefix assignment = within a network, but not be able to distribute something as vital as = DNS server information? wouldn't that leave you with a network you'd = have to manually configure anyway... cheers, Ole= From ichiroumakino@gmail.com Mon Jan 31 13:26:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4573A6C94 for ; Mon, 31 Jan 2011 13:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 h8sm6pjZnJO7 for ; Mon, 31 Jan 2011 13:26:04 -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 CD0743A6C76 for ; Mon, 31 Jan 2011 13:26:03 -0800 (PST) Received: by eyd10 with SMTP id 10so3152044eyd.31 for ; Mon, 31 Jan 2011 13:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=t/GJbw+ENIwUJzju4NnFvW5kI/oFFXVgOjJAHT964Ms=; b=wByCmSFL8h7HGqObKHfVyAt3HQ9kKxROiuj2vMbZQRsimUMBR2l73r3uVPmKYfAo+P Z+gvqpsgbPC4Wn5hSrdUHH9nAYv4U0FxdqOybdqjq5RatEAzVv+7PaoXwl6KTqyUSoPA jkJEGC+/spuQYW3GdTfa5ktBpXQkwuSuCkH/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=dAU3IwyTSDipfZe5CsKbsLl8mvhzvpmS6gVlHYlnVsgpG3UuX3ofUi+YB4P06lV+Sp Nx1xUDASkR4XGwQfXdZvrQy/EDbWZuQ1aYlLuoZnKa0Q3XAgtiZ2fk0aRsDEWVpSn5s0 zEed0tZaRPiL2R0GndXPO3pICaqOkex4ALjUo= Received: by 10.213.27.136 with SMTP id i8mr9222408ebc.11.1296509358323; Mon, 31 Jan 2011 13:29:18 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id b52sm16711849eei.19.2011.01.31.13.29.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 13:29:17 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D4723F5.9000201@brightok.net> Date: Mon, 31 Jan 2011 22:29:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:26:05 -0000 Jack, >> lots of (old) proposals in this space: >>=20 >> http://tools.ietf.org/html/draft-noisette-zerouter-frmwk-00 >> http://tools.ietf.org/html/draft-marce-zerouter-archi-00 >> = http://tools.ietf.org/html/draft-linton-zerouter-requirements-00 >> http://tools.ietf.org/html/draft-dimitri-zospf-00 >> http://tools.ietf.org/html/draft-chelius-router-autoconf-00 >> http://tools.ietf.org/html/draft-linton-arcp-00 >> RFC4903 - Multi-link subnet issues >> http://tools.ietf.org/html/draft-linton-arcp-00 >> RFC4389 - ND Proxy >> = http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation-00 >> http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf >>=20 >=20 > Is there an existing proposal for provider side? I ask, as the two = sorta go hand in hand. As part of my process of determining the most = efficient overall scheme, I've written up some starting logic for the = DHCPv6 server to adapt to more efficient CPE/ISP/routing abilities. It's = VERY rough. one where there is no administrative boundary between the customer and = the provider you mean? this solution should also handle the case where the end user network is = connected to multiple providers. cheers, Ole= From jbates@brightok.net Mon Jan 31 13:33:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F1E3A6B16 for ; Mon, 31 Jan 2011 13:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 qIk0sXbDcLI9 for ; Mon, 31 Jan 2011 13:33:06 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id E95653A6ABE for ; Mon, 31 Jan 2011 13:33:05 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VLaK68018966; Mon, 31 Jan 2011 15:36:20 -0600 (CST) Message-ID: <4D472B53.7080400@brightok.net> Date: Mon, 31 Jan 2011 15:36:19 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ole Troan References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:33:07 -0000 On 1/31/2011 3:29 PM, Ole Troan wrote: > one where there is no administrative boundary between the customer > and the provider you mean? this solution should also handle the case > where the end user network is connected to multiple providers. > To be honest, there is no administrative boundary in zeroconf CPEs today. Boundaries only form when a customer starts to actually manage their CPE. My only issue is that the current model forces the ISP to do one of two things: 1) Restrict all customers to a single routed CPE interfacing with the ISP (here's your /48, /56, etc but only one) 2) Issue longer prefixes and more of them to the CPE in an on-demand scenario (okay, you've issued 6 /64 requests, and I'll answer those up to 20, then I say you're done). The first is the better option of the 2, but it continues to restrict the provider/customer interface in ways that are not desirable. Jack From jbates@brightok.net Mon Jan 31 13:36:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57DA3A6CA3 for ; Mon, 31 Jan 2011 13:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 mK4Z3F+yeLvH for ; Mon, 31 Jan 2011 13:36:12 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 40E4C3A6CA2 for ; Mon, 31 Jan 2011 13:36:12 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VLdJrC019854; Mon, 31 Jan 2011 15:39:19 -0600 (CST) Message-ID: <4D472C06.9050206@brightok.net> Date: Mon, 31 Jan 2011 15:39:18 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ole Troan References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <20110201074722.51e5b7bc@opy.nosense.org> <5A3ED66C-6DFD-495E-B5C9-C980F4E1694D@employees.org> In-Reply-To: <5A3ED66C-6DFD-495E-B5C9-C980F4E1694D@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:36:13 -0000 On 1/31/2011 3:27 PM, Ole Troan wrote: > would there be any point to be able to do automatic prefix assignment > within a network, but not be able to distribute something as vital as > DNS server information? wouldn't that leave you with a network you'd > have to manually configure anyway... I would think this would still fall into the DHCPv6 family, though. There would be concern of each having it's own local DNS registries, but we are talking about routers, and I don't necessarily see this as bad for zeroconf. Jack From ichiroumakino@gmail.com Mon Jan 31 13:47:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2AA3A6885 for ; Mon, 31 Jan 2011 13:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 LCezOoAgSkPp for ; Mon, 31 Jan 2011 13:47:00 -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 2A75E3A67F7 for ; Mon, 31 Jan 2011 13:47:00 -0800 (PST) Received: by ewy8 with SMTP id 8so3099674ewy.31 for ; Mon, 31 Jan 2011 13:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=mWpqFRJMitxSSYBdJJxqhaTb0AExsLQk9g6VG0ec/2A=; b=lUHCdmmMHRZo6bA57HPU/+NX9kbJhiNkqdcjmAAxA1LmjZGS/cUIjDcBAuUDL3lVV3 NELDCx+oUrHnOGW9UrAFUeUDp3JkJ2jfmx4m5EMTv0qPch7RXb3L7tbgbSkcWb+uP/XO z/HU9/ureaJlaOgUBWSJI0BZsyRwlfmS48UGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=BwS0WXR/f5KyOuZI39ImezN/jstmAhLaK+3VXB6aVd2qxGYbDgNzt8mqLkeySYPb1F efCQXJCKpkms/sr1yH+/9g4RUG2a2zzYyHg7kr1/MJ7CP4Z6DIoE/VkeyuhniM9u6ui8 A699vZxa/xK6dEjwDXfPjSyzGu55OJYfmCwaI= Received: by 10.213.104.136 with SMTP id p8mr9186803ebo.59.1296510614768; Mon, 31 Jan 2011 13:50:14 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id t50sm16710516eeh.0.2011.01.31.13.50.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 13:50:14 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D472B53.7080400@brightok.net> Date: Mon, 31 Jan 2011 22:50:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:47:01 -0000 Jack, >> one where there is no administrative boundary between the customer >> and the provider you mean? this solution should also handle the case >> where the end user network is connected to multiple providers. >>=20 >=20 > To be honest, there is no administrative boundary in zeroconf CPEs = today. Boundaries only form when a customer starts to actually manage = their CPE. the basic IPv6 CE router requirements document certainly specifies a = boundary. I would claim that most routed CPEs implement a boundary for IPv4, by = the fact that they do NAT. > My only issue is that the current model forces the ISP to do one of = two things: >=20 > 1) Restrict all customers to a single routed CPE interfacing with the = ISP (here's your /48, /56, etc but only one) >=20 > 2) Issue longer prefixes and more of them to the CPE in an on-demand = scenario (okay, you've issued 6 /64 requests, and I'll answer those up = to 20, then I say you're done). >=20 > The first is the better option of the 2, but it continues to restrict = the provider/customer interface in ways that are not desirable. one is what you would get from a Basic IPv6 CPE router requirements = compliant CPE. I don't see the restriction. just hand out another /56 or /48 to the = second CPE... cheers, Ole= From brian.e.carpenter@gmail.com Mon Jan 31 13:47:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9712B3A6CA3 for ; Mon, 31 Jan 2011 13:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, 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 dS1SuzfS2P2q for ; Mon, 31 Jan 2011 13:47:06 -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 1348B3A67F7 for ; Mon, 31 Jan 2011 13:47:05 -0800 (PST) Received: by bwz12 with SMTP id 12so6653096bwz.31 for ; Mon, 31 Jan 2011 13:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1k1mYdKJbhPhX07mRipY019ioAglO0z/7wmzMZNSgsw=; b=UjQocLoqxnMTZGnXnrugGbjUuV6xyrlL12rsI/g48KTjP6n1C+HioViy/kK/iTfa9N WCNgzKOt349y/Q/WA4/K5KtH+IMiXmTt7umoi5IU6OQF6NrXp+iEr1cqrj3fPO/lslR/ 4sxTSVWuUmF06IavPM6bLmWv+Y9SiO5rw9uKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BHFaO+KmxZemQeM75NvWI/hYietc70zdy7DleiTAVuAI1lFsIPMLD8kckvSICmAdHF 5Slsts7wWsrCX5YbtTN6XPLK6ih91YmlX6eo/IOVaiwcj6AkFX4y25D8g+myMJRX9arl cqtw8sd5q2sphppt4812TSnZ2ifVhpDdaSqMk= Received: by 10.204.57.197 with SMTP id d5mr1458741bkh.63.1296510620501; Mon, 31 Jan 2011 13:50:20 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 12sm10561013bki.7.2011.01.31.13.50.16 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 13:50:19 -0800 (PST) Message-ID: <4D472E95.4030506@gmail.com> Date: Tue, 01 Feb 2011 10:50:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> In-Reply-To: <20110201073623.5628b0b9@opy.nosense.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:47:08 -0000 On 2011-02-01 10:06, Mark Smith wrote: > On Mon, 31 Jan 2011 11:47:41 -0600 > Jack Bates wrote: > >> >> On 1/31/2011 10:56 AM, Fred Baker wrote: >>> There have been a couple of proposals: >> I'll read through them. However, I think we could accomplish most of it >> (except for the actual algorithm for finding necessary space in a >> delegation). >> >> draft-ietf-v6ops-ipv6-cpe-router-07 >> >> >> WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating >> router the size of the prefix it requires. If so, it MUST >> ask for a prefix large enough to assign one /64 for each of >> its interfaces rounded up to the nearest nibble and MUST be >> configurable to ask for more. >> >> Really needs to be SHOULD, to support proper support and >> interoperability in a chained environment. It is likely that most >> providers (though not always) will provide a hard set prefix, while it >> is better for chained CPE's to support prefix hinting. If a CPE is to be >> fully interoperable with chaining, this actually would need to be MUST. >> > > I disagree (as I have before). The link between the customer and the > ISP should be a routing aggregation boundary, so that the customer's > topology and topology changes are hidden from the ISP. Allocate a /56 > or /48 to the customer (or what ever size the ISP is operationally > comfortable with), and then leave it up to them what they do with it. +1. The customer's subnet structure is nothing to do with the ISP. Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 31 13:53:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9392D3A6885 for ; Mon, 31 Jan 2011 13:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 tLtcDUAzJ4XP for ; Mon, 31 Jan 2011 13:53:04 -0800 (PST) Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id B31943A67F7 for ; Mon, 31 Jan 2011 13:53:04 -0800 (PST) Received: from 219-90-141-60.ip.adam.com.au ([219.90.141.60] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pk1jK-0005CQ-Ao; Tue, 01 Feb 2011 08:26:14 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id BF3B43B336; Tue, 1 Feb 2011 08:26:13 +1030 (CST) Date: Tue, 1 Feb 2011 08:26:13 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110201082613.57306e4e@opy.nosense.org> In-Reply-To: <4D472732.5070104@brightok.net> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472732.5070104@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:53:05 -0000 On Mon, 31 Jan 2011 15:18:42 -0600 Jack Bates wrote: So, taking a step back, what are you going to gain from all this? How is this going to save you or make you money as an ISP? Considering that as an ISP you're going to have a minimum of a /32, or 4.3 billion /64s (for the princely sum of e.g. $2250 per annum from ARIN), is the cost of potentially tracking them and assigning them individually worth the benefit? > On 1/31/2011 3:06 PM, Mark Smith wrote: > > Consider the operational consequences of allowing customers to make > > dynamic subnet requests - > > > > Jack From jbates@brightok.net Mon Jan 31 14:03:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832003A6B2B for ; Mon, 31 Jan 2011 14:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 IrrYXD5iHPQI for ; Mon, 31 Jan 2011 14:03:13 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id A104B3A6814 for ; Mon, 31 Jan 2011 14:03:13 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VM6RY1024074; Mon, 31 Jan 2011 16:06:27 -0600 (CST) Message-ID: <4D473262.8060109@brightok.net> Date: Mon, 31 Jan 2011 16:06:26 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ole Troan References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> In-Reply-To: <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:03:14 -0000 On 1/31/2011 3:50 PM, Ole Troan wrote: > the basic IPv6 CE router requirements document certainly specifies a > boundary. I would claim that most routed CPEs implement a boundary > for IPv4, by the fact that they do NAT. > True, and these boundaries exist in CPE stacked environments that aren't reconfigured (when they actually work by default). I'd expect similar out of IPv6 CPEs. Though I think the biggest thing to view in a zeroconf CPE is the ability to tell when it is behind another CPE versus connected to a provider (so it can change it's behavior automatically). Even with this capability, it should be up to the provider to decide how they deploy prefix deployment in an automated fashion. No provider will accept sending a /48 to each CPE connected direct to it. A /48 per site is fine, but do we really want to limit how the customer connects? This should be site policy, not specification policy. > one is what you would get from a Basic IPv6 CPE router requirements > compliant CPE. I don't see the restriction. just hand out another /56 > or /48 to the second CPE... The argument is that most providers (me included) consider it obscene to issue 2+ /48's to a single customer site because of how they decided to connect the CPE. Yet restricting it to a single /48 per customer interface creates it's own limitations on the customer. I'm much more tolerable of issuing multiple /56 networks, but then we've just promoted issuing smaller networks to customers just in case they plug stuff in a certain way. The workaround is to allow for implementations which can support a more versatile numbering scheme from the ISP itself. From a CPE perspective, it won't matter. If the CPE requests a /63 to number it's 2 LAN interfaces, the ISP can either give it nothing - we'll have to do proxy-nd to the wan /64 - we'll have to issue another request with a different IAID /63 - we're good locally, we can request more if we get a PD request (preferable, and allows for a prefix change request if ISP supports it) or we can do relay if necessary) the ISP hands out a larger (technically shorter) prefix which tells us we're currently good for subdelegations. Even if the prefix runs out, we can request another with a different IAID (if the ISP will permit another, but good for ISPs that did decide to just issue multiple /60 networks). Jack From jbates@brightok.net Mon Jan 31 14:11:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF833A67F7 for ; Mon, 31 Jan 2011 14:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 I-jLOwNB-HpY for ; Mon, 31 Jan 2011 14:11:36 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 3609B3A6885 for ; Mon, 31 Jan 2011 14:11:36 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VMEIln028915; Mon, 31 Jan 2011 16:14:18 -0600 (CST) Message-ID: <4D473439.3090601@brightok.net> Date: Mon, 31 Jan 2011 16:14:17 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472732.5070104@brightok.net> <20110201082613.57306e4e@opy.nosense.org> In-Reply-To: <20110201082613.57306e4e@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:11:37 -0000 On 1/31/2011 3:56 PM, Mark Smith wrote: > So, taking a step back, what are you going to gain from all this? How > is this going to save you or make you money as an ISP? Considering that > as an ISP you're going to have a minimum of a /32, or 4.3 billion /64s > (for the princely sum of e.g. $2250 per annum from ARIN), is > the cost of potentially tracking them and assigning them individually > worth the benefit? > Promotion of versatility in the specifications. An ISP MAY choose to issue only 1 /48 per customer circuit, forcing them to only 1 routed CPE interfaced with the ISP An ISP MAY choose to issue multiple /64, /60, /56, /48 to a customer circuit, allowing multiple routed CPEs interfaced with the ISP at the cost of either wasted space or shortening the customer space, possibly causing multiple requests from a single routed CPE which increases the routing table. An ISP currently CANNOT choose to reserve a /48 for a customer interface and delegate addresses from it to any number of routed CPE devices, with sparse allocation techniques between directly adjacent CPEs to assist routing ISP routing and delegation aggregation, CPE aggregation techniques to increase the size of the networks but reduce their number over time, etc. Jack From newbery@gmail.com Mon Jan 31 14:11:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871D03A6CB1 for ; Mon, 31 Jan 2011 14:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 2LYvwnGP4I2S for ; Mon, 31 Jan 2011 14:11:42 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 84B0A3A6BFF for ; Mon, 31 Jan 2011 14:11:42 -0800 (PST) Received: by gwb20 with SMTP id 20so2550577gwb.31 for ; Mon, 31 Jan 2011 14:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=RZodRYDrnh7xBnxm2tmQTh7VNtVYjCMpy8hJf/9Wxqc=; b=dMliIDA+YR2GA4/KY36quJ2Daq4ZZh1HtqE5Ohi/gGHJUBBQoQmXT1/i+9U0OxgWP5 kxSaq/RcJsJk1I/cvcYf+iCxVjzEmklrvAhktxMPrkssMHgQsCpVpZGCqix+Kr2xSpne 2WIETe/Sv1Q2Dz+zxEwS1rAYwpfGK+xDxzRO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=seYrEXAmb+Q7jsjoYSc0TYQMJ+A09AIOZSIJGr6mnG//BHF6B4mtVxTdA6q04jhypQ blQD1m5bn1jjrIdGIjgrqlYvvhHD6e31eCjRSH0I6vVKl+taObJUXoWbugZm/wPts8iK ZqYKV4JKCL9R22myrKqZfg4FmPztssHdwIb+E= Received: by 10.90.249.31 with SMTP id w31mr9413518agh.169.1296512097388; Mon, 31 Jan 2011 14:14:57 -0800 (PST) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id f73sm4777888yhc.4.2011.01.31.14.14.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 14:14:56 -0800 (PST) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-1-377310491; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 1 Feb 2011 11:14:50 +1300 In-Reply-To: <4D472E95.4030506@gmail.com> To: IPv6 Ops WG References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472E95.4030506@gmail.com> Message-Id: <9C882D91-A6AF-43BC-A5D8-E7A5B44B78E2@gmail.com> X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:11:43 -0000 --Apple-Mail-1-377310491 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1/02/2011, at 10:50 AM, Brian E Carpenter wrote: > On 2011-02-01 10:06, Mark Smith wrote: [snip] >>=20 >> I disagree (as I have before). The link between the customer and the >> ISP should be a routing aggregation boundary, so that the customer's >> topology and topology changes are hidden from the ISP. Allocate a /56 >> or /48 to the customer (or what ever size the ISP is operationally >> comfortable with), and then leave it up to them what they do with it. >=20 > +1. The customer's subnet structure is nothing to do with the ISP. >=20 +1. While a fully managed service is something that a customer may wish = to purchase, that's a whole different service to the normal ISP case, = and keeping a clean demarcation only enhances even a fully managed = service offering.= --Apple-Mail-1-377310491 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMTMxMjIxNDUw WjAjBgkqhkiG9w0BCQQxFgQUZQi/KYQUZjt2vOeQZKC3c6eyqMMwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBACT6a6xtVx5dO6gL6Way4UoVctM4a/IY+v7ntY9cHC3+kBuukSb8dmDZq3fi tRoDiePr0jG81nauYIVDwsMOUllTan4LUmAZ1Bkazfq+ZBVOUkIiwMgWvQZy7TLe/ynKD57FAYk+ NTRZ0N/rrFhL0RWU6mfj2Zc6BinCqe94VapvqbEqgk9TyitAKsqI6k/a93nBBcQmruGrXTBLREqM pJQnrk/k2AkV6kRngi5lSNlqMPMcWFnarRyJZRMxaIQGmLA3DUnEYjhTb46FUZP5+ZUPlkT5EV6t X1d1Fs/FqjjXFEglKGK0aSbgpFd3aDUmDd6TPC0/XCwTzotrR0PEjKoAAAAAAAA= --Apple-Mail-1-377310491-- From jbates@brightok.net Mon Jan 31 14:27:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DC53A6885 for ; Mon, 31 Jan 2011 14:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 bCXSkbSMDCEJ for ; Mon, 31 Jan 2011 14:27:02 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 9D3D53A67F7 for ; Mon, 31 Jan 2011 14:27:02 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VMUGd3029925; Mon, 31 Jan 2011 16:30:17 -0600 (CST) Message-ID: <4D4737F8.3090105@brightok.net> Date: Mon, 31 Jan 2011 16:30:16 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Michael Newbery References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472E95.4030506@gmail.com> <9C882D91-A6AF-43BC-A5D8-E7A5B44B78E2@gmail.com> In-Reply-To: <9C882D91-A6AF-43BC-A5D8-E7A5B44B78E2@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:27:03 -0000 On 1/31/2011 4:14 PM, Michael Newbery wrote: > +1. While a fully managed service is something that a customer may > wish to purchase, that's a whole different service to the normal ISP > case, and keeping a clean demarcation only enhances even a fully > managed service offering. You've also broken a good portion of my customers if they left everything plugged in as is and could upgrade their routers to IPv6 (or I'll be issuing 2-8 /48's for a single customer, as it's not uncommon for multiple routers to be connected into the ISP bridging modem, or even a switch connected to the modem with a string of routers connected to it) We're not talking about changing the demarcation. We're talking about the ability separate allocation to customer from delegation to a router. More specifically, multiple routers, in an automated fashion. There's no additional tracking concerns. 1) Customer has 1 router and it has 1 or more delegations inside of an allocation which can all be summaries as an aggregate. 2) Customer has multiple routers and it has multiple delegations inside of an allocation which can be summaries as a group of aggregates if you need specific router information or as the entire allocation if you only care about the specific customer. I'm not saying that everyone will agree with the model. Yet, to not even support the model? Is there another model you have for supporting this without issuing longer prefixes which can lower the depth of the customer network? Jack From ichiroumakino@gmail.com Mon Jan 31 14:43:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D18E3A6BFF for ; Mon, 31 Jan 2011 14:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxRustgs68lE for ; Mon, 31 Jan 2011 14:43:07 -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 579EA3A6BEB for ; Mon, 31 Jan 2011 14:43:07 -0800 (PST) Received: by eyd10 with SMTP id 10so3186196eyd.31 for ; Mon, 31 Jan 2011 14:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=snAVw1t1a5RmXkojHUatxzB+G0rY8KZ2ACX49NNzOIk=; b=Wiu0c9/aId/ZX1oSnfM0VW+fkwy7T+7Xa2chxuxdi+8S1qFu5OLoJr3pmkr/qEh4YA h8z3/JVkVctAwvCpDEYMShBdOotz0hjghfcBbX0sDPyVOilxoZ1Ur4JPyQGOJ/z9h5ic DUYatb0qqkqNFZFfLjcghroRt/FBpoc+EOL1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=oQqPZVNHPCDQ3kHy49m7eZsgpC74WKIRZrk8UXATx9XxzyMruB4MkIw7Almaq64rkj hHg8zXuX/Tyu7WQCZrmzANUysOEFUOwWcE78CcdeCMDw2QG/FOP/OVYgxOcoXko+21W3 bo2vcmX+E7//VT2etfizgm6TtTGWp7Pb14Ris= Received: by 10.14.17.225 with SMTP id j73mr7568127eej.26.1296513981952; Mon, 31 Jan 2011 14:46:21 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id x54sm16753450eeh.11.2011.01.31.14.46.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 14:46:21 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D473262.8060109@brightok.net> Date: Mon, 31 Jan 2011 23:46:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> <4D473262.8060109@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:43:08 -0000 Jack, >> the basic IPv6 CE router requirements document certainly specifies a >> boundary. I would claim that most routed CPEs implement a boundary >> for IPv4, by the fact that they do NAT. >>=20 >=20 > True, and these boundaries exist in CPE stacked environments that = aren't reconfigured (when they actually work by default). I'd expect = similar out of IPv6 CPEs. >=20 > Though I think the biggest thing to view in a zeroconf CPE is the = ability to tell when it is behind another CPE versus connected to a = provider (so it can change it's behavior automatically). yep, proposals for how this could be done would be appreciated. > Even with this capability, it should be up to the provider to decide = how they deploy prefix deployment in an automated fashion. No provider = will accept sending a /48 to each CPE connected direct to it. A /48 per = site is fine, but do we really want to limit how the customer connects? = This should be site policy, not specification policy. I don't see the limitation you are talking about... >> one is what you would get from a Basic IPv6 CPE router requirements >> compliant CPE. I don't see the restriction. just hand out another /56 >> or /48 to the second CPE... >=20 > The argument is that most providers (me included) consider it obscene = to issue 2+ /48's to a single customer site because of how they decided = to connect the CPE. Yet restricting it to a single /48 per customer = interface creates it's own limitations on the customer. I'm much more = tolerable of issuing multiple /56 networks, but then we've just promoted = issuing smaller networks to customers just in case they plug stuff in a = certain way. >=20 > The workaround is to allow for implementations which can support a = more versatile numbering scheme from the ISP itself. >=20 > =46rom a CPE perspective, it won't matter. If the CPE requests a /63 = to number it's 2 LAN interfaces, the ISP can either give it please see the discussion a month or two ago. the CPE has not = information available to request a certain prefix size. > nothing - we'll have to do proxy-nd to the wan > /64 - we'll have to issue another request with a different IAID > /63 - we're good locally, we can request more if we get a PD request = (preferable, and allows for a prefix change request if ISP supports it) = or we can do relay if necessary) >=20 > the ISP hands out a larger (technically shorter) prefix which tells us = we're currently good for subdelegations. Even if the prefix runs out, we = can request another with a different IAID (if the ISP will permit = another, but good for ISPs that did decide to just issue multiple /60 = networks). how the provider deals with delegating prefixes and the size of the = prefix is up to provider policy. there is nothing stopping a provider from assigning whatever sized = prefix to whatever number of connected CPEs in a single site. you cannot expect to rely on a hint in the PD message to determine the = size to delegate, nor can the provider depend on multiple IAIDs in the = request. cheers, Ole= From jbates@brightok.net Mon Jan 31 14:55:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5B73A6B20 for ; Mon, 31 Jan 2011 14:55:52 -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.183, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 IyhrqrsVDKuu for ; Mon, 31 Jan 2011 14:55:51 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 97ED63A6B16 for ; Mon, 31 Jan 2011 14:55:51 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VMx6xt007278; Mon, 31 Jan 2011 16:59:06 -0600 (CST) Message-ID: <4D473EB9.6010802@brightok.net> Date: Mon, 31 Jan 2011 16:59:05 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ole Troan References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> <4D473262.8060109@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:55:52 -0000 On 1/31/2011 4:46 PM, Ole Troan wrote: > > please see the discussion a month or two ago. the CPE has not > information available to request a certain prefix size. > CPE has the information available to 1) request it's immediate needs if it's virgin 2) request an aggregate of it's needs and all subtending needs if it has active prefix information. As I have mentioned, the ability for a CPE to expand it's prefix with the ISP is also of great benefit in this case. > > how the provider deals with delegating prefixes and the size of the > prefix is up to provider policy. there is nothing stopping a provider > from assigning whatever sized prefix to whatever number of connected > CPEs in a single site. > A mechanism isn't documented for a variable prefix layout. As you said, the CPE (especially virgin) has no idea what it's future needs might be. If the ISP hands it a large prefix, it has what it has to work with. However, an ISP should be able to support more, handing out portions of a /48 to a customer site regardless of how they connect routers to the ISP. > you cannot expect to rely on a hint in the PD message to determine > the size to delegate, nor can the provider depend on multiple IAIDs > in the request. Depend, no. Which is why I wrote up a rough idea of ISP logic which could compensate for a variety of dumb and smart CPEs. The HINT is useful in making determinations. Lack of a HINT can be answered in a number of ways. As for multiple IAIDs, if CPEs aren't FORCED to support this, we will have problems when delegations are too small for what is required (unless we just want to sit back and proxy-nd everything when we are out of prefix space). Jack From ichiroumakino@gmail.com Mon Jan 31 15:32:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471883A6B88 for ; Mon, 31 Jan 2011 15:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8VEHwFxpMxT for ; Mon, 31 Jan 2011 15:32:22 -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 0C7E13A6848 for ; Mon, 31 Jan 2011 15:32:21 -0800 (PST) Received: by ewy8 with SMTP id 8so3139129ewy.31 for ; Mon, 31 Jan 2011 15:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=61mdg5e0vc2LGvoowEJPCl2p8A9NJX+Ktxqhp+JeUEo=; b=jFGOAHUIroPBVpYcUVbIPtse+/d/Ec+oxfv5yTGIMDZZH8rfzmzz6oAlYtCI3Fr6W2 Xhsvuq/v/WAMHMB/mUuzeGvpFM78tA67bNWY0C+aoUs4W+trDGlnY+g0/u584bidGkhe +/X5HT9/cWrpGe+lVg3WYcZKJ+joA7k+9nEH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=yCWLdGyBRem4nW+ANWanfle5/K03+IlVeU1aZjmzwIlJ7O4U2KbjBbZmNjs25XCPs2 UdYu34EB8asKVY7upxU4liIADJX/Qk0t+QjFceKe4ttv6UWPzNKcqASoaen3GEUNUVdH dxPlM/bkSb4naJ0CizAewYC3psVp45XNsauME= Received: by 10.14.52.13 with SMTP id d13mr7655734eec.11.1296516936451; Mon, 31 Jan 2011 15:35:36 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id t5sm16782775eeh.8.2011.01.31.15.35.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 15:35:35 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D473EB9.6010802@brightok.net> Date: Tue, 1 Feb 2011 00:35:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3F0BB162-030F-45EC-B430-9BA9C53A7439@employees.org> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> <4D473262.8060109@brightok.net> <4D473EB9.6010802@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:32:23 -0000 Jack, >> please see the discussion a month or two ago. the CPE has not >> information available to request a certain prefix size. >>=20 >=20 > CPE has the information available to >=20 > 1) request it's immediate needs if it's virgin unless the CPE is configured with this information it has no available = information to know the size required to number the site behind it. > 2) request an aggregate of it's needs and all subtending needs if it = has active prefix information. >=20 > As I have mentioned, the ability for a CPE to expand it's prefix with = the ISP is also of great benefit in this case. "expanding" the site can only be done either by renumbering or doing = flat as in /64s prefix delegation. >> how the provider deals with delegating prefixes and the size of the >> prefix is up to provider policy. there is nothing stopping a provider >> from assigning whatever sized prefix to whatever number of connected >> CPEs in a single site. >>=20 >=20 > A mechanism isn't documented for a variable prefix layout. As you = said, the CPE (especially virgin) has no idea what it's future needs = might be. If the ISP hands it a large prefix, it has what it has to work = with. However, an ISP should be able to support more, handing out = portions of a /48 to a customer site regardless of how they connect = routers to the ISP. then hand out /56s to up to 256 CPEs. >> you cannot expect to rely on a hint in the PD message to determine >> the size to delegate, nor can the provider depend on multiple IAIDs >> in the request. >=20 > Depend, no. Which is why I wrote up a rough idea of ISP logic which = could compensate for a variety of dumb and smart CPEs. The HINT is = useful in making determinations. Lack of a HINT can be answered in a = number of ways. As for multiple IAIDs, if CPEs aren't FORCED to support = this, we will have problems when delegations are too small for what is = required (unless we just want to sit back and proxy-nd everything when = we are out of prefix space). with a /56 a end user site has 2^8 number of prefixes, do we think that = will ever run out? if so, he can justify a request for whatever he = needs. you can either do flat delegation and expose the internal topology of = the end user site to the SP or you can do aggregated delegation. you = _could_ imagine a CE using multiple IAIDs to request additional bits of = address space. but that would complicate sub-delegation a lot. all the = proposals I'm aware of are based on a single site prefix being = subdelegated... in any case I don't think there is anything for the Basic IPv6 CE = document here. but lots of opportunities for a home networking = architecture one, so I look forward to drafts! ;-) cheers, Ole From jbates@brightok.net Mon Jan 31 15:55:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03233A6C8E for ; Mon, 31 Jan 2011 15:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 27ubTWR4czeC for ; Mon, 31 Jan 2011 15:55:15 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id E61193A68B1 for ; Mon, 31 Jan 2011 15:55:14 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VNwTRa020523; Mon, 31 Jan 2011 17:58:29 -0600 (CST) Message-ID: <4D474C98.6000704@brightok.net> Date: Mon, 31 Jan 2011 17:58:16 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ole Troan References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> <4D473262.8060109@brightok.net> <4D473EB9.6010802@brightok.net> <3F0BB162-030F-45EC-B430-9BA9C53A7439@employees.org> In-Reply-To: <3F0BB162-030F-45EC-B430-9BA9C53A7439@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:55:16 -0000 On 1/31/2011 5:35 PM, Ole Troan wrote: > > unless the CPE is configured with this information it has no available information to know the size required to number the site behind it. > It's immediate needs are it's routed interfaces - wan worth of /64. That's easy to know and request. It can even set by the manufacturer going out the door if they don't want the software to count. > > "expanding" the site can only be done either by renumbering or doing flat as in /64s prefix delegation. > Yes, renumbering is one option. Supporting a HINT with prefix + length covering only a duid's range and falling within the network reserved for the customer would also be a nice way to handle it. Then the addressing doesn't have to change behind the first CPE, and it's just the database in the ISP server and the CPE which are correcting themselves. A router should automatically be able to recognize contiguous assignments to a single next-hop and aggregate the route. > > then hand out /56s to up to 256 CPEs. > That is an option; just not a scalable one. > with a /56 a end user site has 2^8 number of prefixes, do we think > that will ever run out? if so, he can justify a request for whatever > he needs. The same thing I'm discussing for the ISP works within a CPE network for zeroconf. Among other things it would better utilize a /56, however, if using sparse delegation model in combination of upgrading requested prefixes when you are handing more out downstream, and keeping routing tables small in the process, a /48 would be better. > you can either do flat delegation and expose the internal topology of the end user site to the SP or you can do aggregated delegation. you _could_ imagine a CE using multiple IAIDs to request additional bits of address space. but that would complicate sub-delegation a lot. all the proposals I'm aware of are based on a single site prefix being subdelegated... > > in any case I don't think there is anything for the Basic IPv6 CE document here. but lots of opportunities for a home networking architecture one, so I look forward to drafts! ;-) With all the things a basic CPE does these days, why not? I thought the point of a basic CPE was to handle zeroconf. Less exposure to the SP is required if you can relabel your prefix length (oops, another subtending router, bump my /63 request to a /60 as he's asking for a /61). This theoretically would be accomplished with a renewal request which just asked the SP for a larger prefix, which the SP could verify didn't conflict with anything else it delegated to the customer. It's not much different than a customer's site asking for multiple IPv4 addresses as they plug in additional CPEs direct to the SP. The main difference comes in the prefix delegation for each of those CPEs and how to best handle that in an automated way which allows providers to set their policies but still allows for plug and play. Honestly, I want off the shelf multi vendor CPEs that I can stack in any combination or order, they handle numbering by themselves, they agree on firewall rules by themselves, and they provide me an easy mDNS selectable interface for connecting to all the management interfaces. Knowing my customers, they want the same thing; plug it in somewhere and it should work (and they really wish if they plugged the DSL modem into a LAN port accidentally, that the router would just work). Jack From sam.silvester@gmail.com Mon Jan 31 19:04:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82803A6CC4 for ; Mon, 31 Jan 2011 19:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 Vsz0SpHPutt2 for ; Mon, 31 Jan 2011 19:04:01 -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 BBFDD3A6A86 for ; Mon, 31 Jan 2011 19:04:00 -0800 (PST) Received: by fxm9 with SMTP id 9so6921660fxm.31 for ; Mon, 31 Jan 2011 19:07:16 -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:content-type:content-transfer-encoding; bh=rFu1ORBCayADcVoiEOUlTeiqkSgZmsAMn5Q+iNJ+kQU=; b=S+8+zsMX7DRfEacasGT8S/ofPC64pAh+x+o064RJsifvMj18tFALmPMcZOlG+t/k44 JOTRUC4LsXBoYIUWc3MqE6jrHLA6pw77Oj9nCasYDwgAP3T61BnVswjAdNIA7KyvIMbK rUYYdd8ehU5r/+fzOH3y4AirNlKe9nmnkur6A= 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 :content-type:content-transfer-encoding; b=nF8+d7w0bM0QwVMGxNiFK+8RjX98/q5Vd8JOSywmnpEoPudyCUDiVlvT1n9XvoWfMo meh9+3YZqCoLlHNOyHu0kvximXDUS49ZQv5SHNeVL6PoZmA3O5oJ4mI9W737tmOcKeg6 deO10w6zOYk9Mxg7g0qCrUxrvFoU/2ccM/Lt0= MIME-Version: 1.0 Received: by 10.223.114.14 with SMTP id c14mr6769778faq.103.1296529635991; Mon, 31 Jan 2011 19:07:15 -0800 (PST) Received: by 10.223.115.207 with HTTP; Mon, 31 Jan 2011 19:07:15 -0800 (PST) In-Reply-To: <4D472732.5070104@brightok.net> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472732.5070104@brightok.net> Date: Tue, 1 Feb 2011 13:37:15 +1030 Message-ID: From: Sam Silvester To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 03:04:02 -0000 On Tue, Feb 1, 2011 at 7:48 AM, Jack Bates wrote: > On 1/31/2011 3:06 PM, Mark Smith wrote: >> >> Consider the operational consequences of allowing customers to make >> dynamic subnet requests - >> >> - your customer aggregation routers will now have additional control >> =A0 plane load of processing those requests. This may also create involv= e >> =A0 additional load on backend authentication servers. Some malicious >> =A0 customers (let's call then "kids") might use this as a DoS vector, >> =A0 for Saturday afternoon entertainment. > > The same can be done with a single device making repetitive requests. > Control knobs are necessary to protect the ISP in either case. In this ca= se, > the CPE itself can self rate-control such requests. I don't know that I'd be comfortable trusting the CPE with this responsibility unless I as the service provider managed it; in fact, in many cases for residential ISPs, the customer owns / manages their own CPE (and are even welcome to bring their own as opposed to buying the one their ISP provides). Sam From jbates@brightok.net Mon Jan 31 19:42:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8052F3A6833 for ; Mon, 31 Jan 2011 19:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 C1-aCM4o5caE for ; Mon, 31 Jan 2011 19:42:34 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 62E673A67D3 for ; Mon, 31 Jan 2011 19:42:33 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p113jm5Z010348 for ; Mon, 31 Jan 2011 21:45:48 -0600 (CST) Message-ID: <4D4781DF.9010009@brightok.net> Date: Mon, 31 Jan 2011 21:45:35 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472732.5070104@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 03:42:35 -0000 On 1/31/2011 9:07 PM, Sam Silvester wrote: > I don't know that I'd be comfortable trusting the CPE with this > responsibility unless I as the service provider managed it; in fact, > in many cases for residential ISPs, the customer owns / manages their > own CPE (and are even welcome to bring their own as opposed to buying > the one their ISP provides). Oh, I agree. I meant that as "in addition to" the ISP controls. There's no reason every step of the process couldn't have DHCPv6 controls to limit excessive requests, especially for DHCPv6-PD. It's precisely the "customer buys own CPE" that raises my issues with the lack of a good diverse model, both for the ISP as well as support in the CPE market. Jack